Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

CHAPTER 6 ■ LOCKING AND LATCHING 185
were simply reinforced and, furthermore, I learned to treat a lock as a very scarce resource—
something to be coveted. I learned that you should manually escalate locks from row level to
table level to try to avoid acquiring too many of them and bringing the system down, and
bring it down I did—many times.
When I started using Oracle, I didn’t really bother reading the manuals to find out how
locking worked in this particular database. After all, I had been using databases for quite a
while and was considered something of an expert in this field (in addition to Sybase, SQL
Server, and Informix, I had used Ingress, DB2, Gupta SQLBase, and a variety of other databases).
I had fallen into the trap of believing that I knew how things should work, so I thought
of course they would work in that way. I was wrong in a big way.
It was during a benchmark that I discovered just how wrong I was. In the early days of
these databases (around 1992/1993), it was common for the vendors to “benchmark” for really
large procurements to see who could do the work the fastest, the easiest, with the most features.
The benchmark was between Informix, Sybase, SQL Server, and Oracle. Oracle was first.
Their technical people came on-site, read through the benchmark specs, and started setting it
up. The first thing I noticed was that the technicians from Oracle were going to use a database
table to record their timings, even though we were going to have many dozens of connections
doing work, each of which would frequently need to insert and update data in this log table.
Not only that, but they were going to read the log table during the benchmark as well! Being
a nice guy, I pulled one of the Oracle technicians aside to ask him if they were crazy—why
would they purposely introduce another point of contention into the system? Wouldn’t the
benchmark processes all tend to serialize around their operations on this single table? Would
they jam the benchmark by trying to read from this table as others were heavily modifying it?
Why would they want to introduce all of these extra locks that they would need to manage?
I had dozens of “Why would you even consider that?”–type questions. The technical folks
from Oracle thought I was a little daft at that point. That is, until I pulled up a window into
SQL Server or Informix, and showed them the effects of two people inserting into a table, or
someone trying to query a table with others inserting rows (the query returns zero rows per
second). The differences between the way Oracle does it and the way almost every other
database does it are phenomenal—they are night and day.
Needless to say, neither the Informix nor the SQL Server technicians were too keen on the
database log table approach during their attempts. They preferred to record their timings to
flat files in the operating system. The Oracle people left with a better understanding of exactly
how to compete against SQL Server and Informix: just ask the audience “How many rows per
second does your current database return when data is locked?” and take it from there.
The moral to this story is twofold. First, all databases are fundamentally different. Second,
when designing an application for a new database platform, you must make no assumptions
about how that database works. You must approach each new database as if you had never
used a database before. Things you would do in one database are either not necessary or simply
won’t work in another database.
In Oracle you will learn that
• Transactions are what databases are all about. They are a “good thing.”
• You should defer committing until the correct moment. You should not do it quickly to
avoid stressing the system, as it does not stress the system to have long or large transactions.
The rule is commit when you must, and not before. Your transactions should only
be as small or as large as your business logic dictates.