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.
Category: Oracle DBMS
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”!
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.
Sybase vs Oracle
I’ve seen some discussion around the internet about the age old argument about which is best Sybase or Oracle. I have been reading Mr. Talebzedah article on Sybase vs. Oracle: 10 reasons to use Sybase on Linux and I would agree with many of his statements. Having installed and used both over the years, I would pick Sybase. Why more companies don’t use Sybase more, has always been a mystery to me. Sybase is cheaper to install, and operate both in hardware resource usage, and manpower utilization. As an example, which can be repeated ad finite, one of the companies I worked at required 20 DBA’s to support a single Oracle Financials system in version 7 Oracle. And they were terrified to upgrade to Oracle 8 as Oracle does not supply a migration path. Sybase in this same company was used extensively in 7/24 environments, and only had 18 DBA’s supporting more than 800 Sybase databases, with more than 15,000 logins. In Mr Talebzedah article he mentions 2.5 Oracle DBA’s to one Sybase DBA, and since you and I know that 0.5 DBA’s don’t really exist (see mythical man month) I would put that, rounding factors aside, to 3+ Oracle DBA’s to one Sybase DBA.
Oracle supporters always mention the ‘sophistication’ and maturity of Oracle features, and in the same breath include the requirements for learning more, and of it’s complexity. This complexity extends to it’s high requirements in installation, and operating Oracle databases. Ask an Oracle DBA why they have to maintain backup configuration files three or more times to feel safe? As an example of this heavy requirement for installation, Oracle makes more money consulting on how to install it, than selling the actual RDBMS product. As another cost Oracle DBA’s are higher paid than Sybase DBA’s you do have to pay for all this sophisticated knowledge. That’s not a fault of the DBA, but is is still a business expense, and adds to the TCO.
As for the maturity and sophistication, Oracle may win here, but I am not comparing ASE 15 as I have not used this, but in almost every environment I’ve ever worked in, this sophistication is never utilized. This is not a lack of programming skills in the staff. It has to do with not being locked into any particular RDBMS feature. Many companies are completely heterogeneous with regards to Databases, probably due to corporate merger mania. And database transportability is prized much more than any particular database feature. In some cases junior programmers utilize databases more as file systems than RDBMS systems and hence, gain nothing from the mature, sophisticated features Oracle might provide.
Ultimately Oracle grants nothing in the benefits column when the costs are taken into perspective. Oracle is more expensive, fragile and harder to develop applications for. Sybase is cheaper faster, more stable, and requires less hardware and manpower to operate.
My Life
This is my personal log of the Real Randall W. Jordan.
RW_Jordan@Cork.Ireland 