I am reading SQL Server lock escalation from MSDN Page about SQL Server lock escalation
My question is, seems the major reason why there is lock escalation is to reduce overhead to maintain more locks (e.g. when more row locks are acquired for a table, then row level lock is escalated to table level). My question is, to maintain more locks will improve concurrency, it is a benefit, why it is an overhead? In my humble idea, lock should be as small as enough to make the db performance better by improving concurrency. Could anyone explain in simple way why lock escalation is needed and what is the so-called lock overhead please?
thanks in advance,
George
When you update a table and lock a row, you need to record this fact somehow: that’s a row, it’s been updated and locked.
When you update million rows, you need to do this million times, and therefore have some space to keep million locks.
SQL Server keeps a list of locks in memory, while Oracle does in on the tablespaces.
This is probably because Oracle is old (older than me), and SQL Server is young compared to Oracle.
Keeping temporary resources (like locks) in a permanent storage is not so obvious solution from designer’s point of view. Just one thing to mention: you may need a disk write to perform a
SELECT FOR UPDATE.Oracle’s core features were developed in early 80’s, when keeping things in memory was not an option at all. They just had to use disk space somehow.
If disk space was to be used anyway, you had to place a lock somewhere on disk.
And where to keep a lock for a row if not within the row itself?
Developers of SQL Server’s lock system, when inventing design of their RDBMS called Sybase, decided to store temporary things (i. e. locks) in the temporary storage (i. e. RAM).
But Oracle’s design is always balanced: if you have a 1,000,000 rows in your database, then you have a storage space for 1,000,000 locks, if you have a billion rows, you may store billion locks, etc.
SQL Server’s design is flawy in this sense, because your RAM and HDD space may be unbalanced. You may easily have 16M of RAM and several terabytes of disk space. And you memory just cannot hold all the locks.
That’s why when the lock count reaches a certain limit, SQL Server decides to escalate the locks: instead of keeping locks for, say, 10 individual rows in a data page (which requires 10 records), it locks the whole data page (which requires 1 record).
Oracle, on the other hand, when updating a row, just writes the lock right into the datapage.
That’s why Oracle’s locks are row-level.
Oracle doesn’t “manage” the locks in a common sense of word: you can’t, say, get a list of locked pages in Oracle.
When a transaction needs to update a row, it just goes to the row and sees if it’s locked.
If it is, it looks which transaction holds a lock (this information is contained within the lock descriptor in the data page) and adds itself to that transaction’s notification queue: when the locking transactions dies, the original one gets notified and locks the data.
From the concurrency’s point of view, lock escalation is totally a poor man’s solution: it adds nothing to concurrency. You can, say, get a lock on a row you didn’t even touch.
From the performance’s point of view, doing things in memory is, of course, faster than doing them on the disk.
But since Oracle caches the datablocks and the actual operations described above are performed in memory anyway, the performance is same or close to it.