Posted in IT Issues, Oracle DBMS, Personal, RDBMS, Sybase

Working for the Underdog

I always find it interesting that I seem to be in the position of supporting the underdog when it comes to computing, I own Apple’s and work with Sybase. Two systems that can’t manage a marketing strategy to move them into the main stream. Both manage to be on the opposite end of competition with Microsoft Software. I assume that each should be flattered that MS has chosen them to steal code and ideas from, but I’d rather hoped they had the market share back. Set aside the quality issues, credit, vindication and validation of their ideas is sadly lacking in the IT world with the exception of those that work with them.

Advertisements
Posted in Oracle DBMS, RDBMS, Sybase

Oracle Market share

One more point in the Sybase vs Oracle debate is the size of the Oracle installed base. The claim has been made that the reason Oracle is the number one RDBMS, is that the database has been selected for it’s features, reliability and maturity.

Once again this is a false premise as the real reason that Oracle is number one, is Marketing, plain and simple salesmanship. And not generally good salesmanship, but more like that of a pushy used car salesman. I had the occasion of witnessing this, more or less first hand.

At one company I work for they were going through the usually agony of having to upgrade a project costing system. The current one, home made, was failing. The replacement was between Oracle Financial’s and some modules or Deltec Costpoint. The evaluation team went through extensive testing of the features, and the Oracle system came up short, but with Oracle promises to add the missing features. The Costpoint system was nearly a perfect fit. And hence the choice to purchase Costpoint. This set off the first of three Oracle incidents. Oracle having lost the bid, did not take it lightly. They when directly to the CEO of the company and claimed that the evaluation team had made a costly and catastrophic choice for the company which would lead to serious business loss.

The CEO having more or less picked the evaluation team, was not impressed with the Oracle arguments. But this does not complete the story. This same team, was required to also make a choice of RDBMS’s Oracle, or Sybase. And as you might have guested the same Oracle sales reps were involved. The evaluation team after considerable testing Chose Sybase. And guess what? The Oracle reps again approached the CEO claiming that the evaluation team had failed their duties and were taking the company to the brink with their choice of Sybase. And again they were shown the door by the CEO.

This does not close the door. The company operated the Costpoint system on Sybase for many years with absolutely no issues. Until Deltec was, under pressure from Oracle, was forced to migrate to “Oracle only” RDBMS support and as such required all clients to switch to Oracle as part of a Costpoint upgrade. The company was forced to upgrade all the hardware necessary to operate the costpoint system in order to manage the Oracle installation.

Clearly Oracle did not ‘win’ this on features, just pushy sales reps.

And this is not the only example of Oracle strong arm marketing , like the comedian, “I’ve got a million of ’em”!

Posted in Oracle DBMS, RDBMS, SQL, Sybase

Row level Locking

In the Sybase vs Oracle discussion there is always one issue that Oracle used to win. Row level locking. In the early days of Sybase, page level locking was the lowest level of granularity that locks attained. Much of this was due to a conscious choice of increasing the performance of the transaction, rather than ensuring unique row locking in Sybase. After row level locking was added to Sybase at version 11, this was proved to be a false ‘feature’ as most Sybase installations rarely implemented it.

In retrospect most issues relating to row level being a requirement can be traced back to badly implemented transaction clients. which makes this even more evident, is that in many cases, when the client transaction were ‘repaired’ to implement true ACID transactions, the Oracle databases performed better, and the row level locking issues vanished as a requirement.

UPDATE:

One other difference between Oracle and Sybase which doesn’t get much visibility is the business of isolation levels. Oracle allows the ‘dirty’ read and Sybase does not. This is changeable in both databases, but Oracle used this to their advantage in the locking wars as shared, and shared intent locking did not cause the same kind of issues like the ones you would encounter in Sybase.