|
|
|
SSC-Dedicated
           
Group: Administrators
Last Login: Yesterday @ 5:09 AM
Points: 31,526,
Visits: 13,864
|
|
|
|
|
|
SSCrazy Eights
        
Group: General Forum Members
Last Login: 2 days ago @ 6:30 AM
Points: 9,410,
Visits: 6,495
|
|
|
|
|
|
SSCrazy
      
Group: General Forum Members
Last Login: Monday, May 06, 2013 5:31 AM
Points: 2,226,
Visits: 438
|
|
I knew the answer, but I havent thought about that this is a good reason to use partitioning.
/Håkan Winther MCITP:Database Developer 2008
|
|
|
|
|
Ten Centuries
      
Group: General Forum Members
Last Login: Wednesday, June 12, 2013 9:12 AM
Points: 1,167,
Visits: 646
|
|
I went for 'table' escalation only.
Maybe I should have guessed 'partition' as well...
Nice question though.
|
|
|
|
|
SSCrazy
      
Group: General Forum Members
Last Login: Monday, June 17, 2013 10:29 PM
Points: 2,178,
Visits: 3,599
|
|
I thought row level locks would be escalated to table locks only.
I referred the link provided in the answer, but couldn't find any information regarding escalation to partition.
The Database Engine does not escalate row or key-range locks to page locks, but escalates them directly to table locks. Similarly, page locks are always escalated to table locks. In SQL Server 2008, locking of partitioned tables can escalate to the HoBT level for the associated partition instead of to the table lock. A HoBT-level lock does not necessarily lock the aligned HoBTs for the partition.
Did anyone find more information regarding the escalation of row level locks to partition in the link provided?
Mohammed Moinudheen
|
|
|
|
|
SSCommitted
      
Group: General Forum Members
Last Login: Yesterday @ 4:16 AM
Points: 1,635,
Visits: 1,155
|
|
mohammed moinudheen (5/25/2011) I thought row level locks would be escalated to table locks only.
I referred the link provided in the answer, but couldn't find any information regarding escalation to partition.
The Database Engine does not escalate row or key-range locks to page locks, but escalates them directly to table locks. Similarly, page locks are always escalated to table locks. In SQL Server 2008, locking of partitioned tables can escalate to the HoBT level for the associated partition instead of to the table lock. A HoBT-level lock does not necessarily lock the aligned HoBTs for the partition.
Did anyone find more information regarding the escalation of row level locks to partition in the link provided?
I inferred it from the same paragraph that you quoted. If a row lock can escalate to a table lock, and a table lock can escalate to a partition lock then a row lock can cause a partition lock.
|
|
|
|
|
Ten Centuries
      
Group: General Forum Members
Last Login: Tuesday, May 28, 2013 1:34 AM
Points: 1,263,
Visits: 1,080
|
|
mohammed moinudheen (5/25/2011) I thought row level locks would be escalated to table locks only.
I referred the link provided in the answer, but couldn't find any information regarding escalation to partition.
The Database Engine does not escalate row or key-range locks to page locks, but escalates them directly to table locks. Similarly, page locks are always escalated to table locks. In SQL Server 2008, locking of partitioned tables can escalate to the HoBT level for the associated partition instead of to the table lock. A HoBT-level lock does not necessarily lock the aligned HoBTs for the partition.
Did anyone find more information regarding the escalation of row level locks to partition in the link provided?
I'll give it a try (in a technically simplified way): The HoBT level (HoBT = Heap or B-Tree, see http://technet.microsoft.com/en-us/library/ms189849.aspx) is the structure underlying a table. If the table is not partitioned, you could say HoBT(a) = table(a). For a partitioned table, each partition is one HoBT, or HoBT(a1) = p(1)table(a), HoBT(a2) = p(2)table(a), etc. So locking just one HoBT of a partitioned table = locking the partition, but not the entire table.
Or as BOL puts it: A HoBT-level lock does not necessarily lock the aligned HoBTs for the partition. Personally I'd rephrase that to: A HoBT-level lock does not necessarily lock all aligned HoBTs for an entire partitioned table.
Regards, Michael
|
|
|
|
|
SSCrazy
      
Group: General Forum Members
Last Login: Monday, June 17, 2013 10:29 PM
Points: 2,178,
Visits: 3,599
|
|
Thank you Michael and Richard. It is clear to me now
Mohammed Moinudheen
|
|
|
|
|
SSCertifiable
       
Group: General Forum Members
Last Login: Yesterday @ 12:10 PM
Points: 7,185,
Visits: 7,285
|
|
Nice question.
But "partition" locks? Surely Heap locks, B-Tree locks (HoBT locks for short)? I don't think the term "partition lock" occurs anywhere in BoL for SQL 2008 R2.
Tom Is minic a gheibheann béal oscailte dorn dúnta. Is minig a cheapas beul fosgailte dòrn dùinte.
http://es.linkedin.com/in/tomthomsonsoftware
|
|
|
|
|
SSCrazy
      
Group: General Forum Members
Last Login: Monday, June 17, 2013 10:29 PM
Points: 2,178,
Visits: 3,599
|
|
I'll give it a try (in a technically simplified way): The HoBT level (HoBT = Heap or B-Tree, see http://technet.microsoft.com/en-us/library/ms189849.aspx) is the structure underlying a table. If the table is not partitioned, you could say HoBT(a) = table(a). For a partitioned table, each partition is one HoBT, or HoBT(a1) = p(1)table(a), HoBT(a2) = p(2)table(a), etc. So locking just one HoBT of a partitioned table = locking the partition, but not the entire table. Or as BOL puts it: A HoBT-level lock does not necessarily lock the aligned HoBTs for the partition.Personally I'd rephrase that to: A HoBT-level lock does not necessarily lock all aligned HoBTs for an entire partitioned table.Regards, Michael
Excellent explanation really, easy to follow. May be you should add this in that MSDN link
Mohammed Moinudheen
|
|
|
|