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.
Someone wrote me and ask if I didn’t make a mistake an mean Sybase database performed better and I responded like this:
But I agreed, that I could have made it more clear.
I just found your blog through a search on sybase + wordpress.
I have a similar background to you 20 years in IT. Most of it with Sybase these days , plenty of Oracle in the old days. I agree with a lot of your points on the Sybase / Oracle debate. I still prefer Oracle though!
One thing that really bugs me in Sybase is the lack of O/S authenticated logins. In Oracle you just use sqlplus /
and your “OPS$” logins remove all the complexity required with having userids and passwords for the database as well as the O/S.
Particulary with batch programs and SOX compliance for Sybase dbs messing around keeping track of the batch userids and logins a real PITA.
Sybase is a true client/server database with it’s origins AS an operating system, hence it’s native user login methods. These methods can be configured in much the same way as any OS. At AT&T we had servers with only a few dozen OS logins, and 15,000 user logins to the databases. Try and admin that many users at the OS level and you will really have fun. However we used Kerberos to manage them, but you can use LDAP, or external OS authentications (now) or a number of other security profiles.