﻿<?xml version='1.0' encoding='UTF-8'?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/"><channel><title>SQLServerCentral / SQL Server 2005 / SQL Server 2005 Strategies  / READ_COMMITTED_SNAPSHOT &amp; TRUNCATE TABLE / Latest Posts</title><generator>InstantForum.NET v2.9.0</generator><description>SQLServerCentral</description><link>http://www.sqlservercentral.com/Forums/</link><webMaster>notifications@sqlservercentral.com</webMaster><lastBuildDate>Thu, 23 May 2013 09:45:39 GMT</lastBuildDate><ttl>20</ttl><item><title>RE: READ_COMMITTED_SNAPSHOT &amp; TRUNCATE TABLE</title><link>http://www.sqlservercentral.com/Forums/Topic1399620-361-1.aspx</link><description>[quote][b]GilaMonster (12/26/2012)[/b][hr][quote][b]Sean Lange (12/26/2012)[/b][hr]The locking you are seeing is because of lock escalation. [/quote]It's not lock escalation.Truncate table locks at the table level because there's no other sensible level to lock at (and iirc it takes an Sch-M lock too)Lock escalation would be if the truncate first started taking row or page locks, got over the threshold and converted the locks to table[/quote]Thanks for the correction Gail. I knew the locking was at the table level but my incorrect terminology certainly made it unclear. :w00t:</description><pubDate>Wed, 26 Dec 2012 13:07:33 GMT</pubDate><dc:creator>Sean Lange</dc:creator></item><item><title>RE: READ_COMMITTED_SNAPSHOT &amp; TRUNCATE TABLE</title><link>http://www.sqlservercentral.com/Forums/Topic1399620-361-1.aspx</link><description>[quote][b]Sean Lange (12/26/2012)[/b][hr]The locking you are seeing is because of lock escalation. [/quote]It's not lock escalation.Truncate table locks at the table level because there's no other sensible level to lock at (and iirc it takes an Sch-M lock too)Lock escalation would be if the truncate first started taking row or page locks, got over the threshold and converted the locks to table</description><pubDate>Wed, 26 Dec 2012 13:04:35 GMT</pubDate><dc:creator>GilaMonster</dc:creator></item><item><title>RE: READ_COMMITTED_SNAPSHOT &amp; TRUNCATE TABLE</title><link>http://www.sqlservercentral.com/Forums/Topic1399620-361-1.aspx</link><description>[quote][b]geoffrey crombez (12/21/2012)[/b][hr]Hi,when I use the READ_COMMITTED_SNAPSHOT and use DELETE FROM table the other session is not locked when SELECTING data.However when I use TRUNCATE TABLE it does block the other session SELECTING data.The difference I see is that the TRUNCATE does a X lock on PAGE level and the DELETE an IX on PAGE level.So I know not to use TRUNCATE in such scenario, but I would like to understand what is different internally.Kind RegardsGeoffrey[/quote]The difference in what those two statements do. Delete simply deletes rows where a truncate removes the pages. The locking you are seeing is because of lock escalation. A truncate will lock the entire table because all of the pages are being removed. Of course truncate is a lot faster because of the minimal logging involved so the locking should be very short.</description><pubDate>Wed, 26 Dec 2012 07:31:48 GMT</pubDate><dc:creator>Sean Lange</dc:creator></item><item><title>READ_COMMITTED_SNAPSHOT &amp; TRUNCATE TABLE</title><link>http://www.sqlservercentral.com/Forums/Topic1399620-361-1.aspx</link><description>Hi,when I use the READ_COMMITTED_SNAPSHOT and use DELETE FROM table the other session is not locked when SELECTING data.However when I use TRUNCATE TABLE it does block the other session SELECTING data.The difference I see is that the TRUNCATE does a X lock on PAGE level and the DELETE an IX on PAGE level.So I know not to use TRUNCATE in such scenario, but I would like to understand what is different internally.Kind RegardsGeoffrey</description><pubDate>Fri, 21 Dec 2012 15:45:46 GMT</pubDate><dc:creator>geoffrey crombez</dc:creator></item></channel></rss>