Regarding SQL Server Locking Mechanism

Question

Dear GURUs

I would like to ask couple of questions regarding SQL Server Locking mechanism

1. If i am not using the lock hint with SQL Statement, SQL Server uses PAGELOCK hint by default. am I right??? If yes then why? may be its due to the factor of managing too many locks this is the only thing i took as drawback but please let me know if there are others. and also tell me if we can change this default behavior if its reasonable to do.

2. I am writing a server side application, a Sync Server (not using sync framework) and I have written database queries in C# code file and using ODBC connection to execute them. Now question is what is the best way to change the default locking from Page to Row keeping drawbacks in mind (e.g. adding lock hint in queries this is what i am planning for).

3. What if a sql query(SELECT/DML) is being executed without the scope of transaction and statement contains lock hint then what kind of lock will be acquired (e.g. shared, update, exclusive)? AND while in transaction scope does Isolation Level of transaction has impact on lock type if ROWLOCK hint is being used.

4. Lastly, If some could give me sample so i could test and experience all above scenarios my self (e.g. dot net code or sql script)

Thanks Mubashar

Answer 1

1. No. It locks as it sees fit and escalates locks as needed

2. Let the DB engine manage it

3. See point 2

4. See point 2

I'd only use lock hints if you want specific and certain behaviours eg queues or non-blocking (dirty) reads.

More generally, why do you think the DB engine can't do what you want by default?

Answer 2

The default locking is row locks not page locks, although the way in which the locking mechanism works means you will be placing locks on all the objects within the hierarchy e.g. reading a single row will place a shared lock on the table, a shared lock on the page and then a shared lock on the row.

This enables an action requesting an exclusive lock on the table to know it may not take it yet, since there is a shared lock present (otherwise it would have to check every page / row for locks.)

If you issue too many locks for an individual query however, it performs lock escalation which reduces the granularity of the lock - so that is it managing less locks. This can be turned off using a trace flag but I wouldn't consider it.

Until you know you actually have a locking / lock escalation issue you risk prematurely optimizing a non-existant problem.

Answer 3

Dear Andrew

Thanks for reply.

First Paragraph is my actual problem. I am facing too many deadlocks as many thread are performing, read, update and delete simultaneously but none of them are performing select/DML on same ROW i.e. if thread1 is updating ROW1 then Thread2 may be reading or updating ROW-X but not ROW1 and there may be more than 30 concurrent thread involved in all this procedure thats is why i don't want shared lock on Page or Table. So what you suggest considering my situation???