Pinal,
Can you help explain the following:

SESSION 52:
use tempdb
go
create table tableA (col1 int identity(1,1) not null primary key)
go
begin tran
insert into tableA default values
waitfor delay ’1:00′
rollback tran

SESSION 53:
USE TEMPDB
GO
alter table tableA add col2 int

SESSION 55:
insert into tableA default values
/* insert is immediately successful */

SESSION 58:
EXEC SP_LOCK (omiited some data to make it viewable)
spid ObjId Type Mode Status
52 938157062 TAB IX GRANT
52 938157062 PAG IX GRANT
52 938157062 KEY X GRANT
53 938157062 TAB Sch-M WAIT
53 938157062 TAB Sch-M GRANT
53 938157062 TAB Sch-M GRANT
53 938157062 TAB Sch-M GRANT
53 938157062 TAB Sch-M GRANT
53 938157062 TAB Sch-M GRANT
58 1131151075 TAB IS GRANT

So, the inserts require a table level IX lock and aren’t blocked by the table level Sch-M lock.

Let’s try this again with a DELETE.

SESSION 52:

USE tempdb
GO
drop table tableA
GO
create table tableA (col1 int identity(1,1) not null primary key)
go
insert into tableA default values
insert into tableA default values
insert into tableA default values
GO

SESSION 53:
BEGIN TRAN
DELETE TABLEA WHERE COL1=1
WAITFOR DELAY ’1:00′
ROLLBACK TRAN

SESSION 55:
ALTER TABLE TABLEA ADD COL2 INT

SESSION 57:
DELETE TABLEA WHERE COL1=2
/* NOW IT’S BLOCKED */

SESSION 61:
spid dbid ObjId Type Mode Status
53 2 0 PAG IX GRANT
53 2 1066157518 TAB IX GRANT
53 2 0 KEY X GRANT
53 2 1002157290 TAB IX GRANT
54 7 0 DB S GRANT
55 2 1066157518 TAB Sch-M GRANT
55 2 1066157518 TAB Sch-M GRANT
55 2 1066157518 TAB Sch-M GRANT
55 2 1066157518 TAB Sch-M GRANT
55 2 1066157518 TAB Sch-M GRANT
55 2 1066157518 TAB Sch-M GRANT
55 2 1066157518 TAB Sch-M GRANT
55 2 1066157518 TAB Sch-M GRANT
55 2 1066157518 TAB Sch-M WAIT
55 2 1066157518 TAB Sch-M GRANT
55 2 1066157518 TAB Sch-M GRANT
55 2 1066157518 TAB Sch-M GRANT
55 2 1066157518 TAB Sch-M GRANT
57 2 1066157518 TAB IX WAIT
61 7 0 DB S GRANT
61 1 1131151075 TAB IS GRANT
62 7 0 DB S GRANT

So, the insert was fine as we saw before but now with a DELETE.. it’s blocked… Note the wait for the TAB level, IX on session 57. Session 57 is blocked by 55, the alter table statement. But why didn’t this occur on the INSERT, in the previous example.

In addition, the lock compatibility matrix (http://msdn.microsoft.com/en-us/library/ms186396.aspx) says that IX and SCH-M locks are not compatible. As a result, the ALTER should not have granted any SCH-M locks on the same table object.

I tried this with UPDATES and the result is the same as with DELETES.

SESSION 52:
use tempdb
go
create table tableA (col1 int identity(1,1) not null primary key)
go
begin tran
insert into tableA default values
waitfor delay ’1:00′
rollback tran

SESSION 53:
USE TEMP
GO
alter table tableA add col2 int

SESSION 55:
insert into tableA default values
/* insert is immediately successful */

SESSION 58:
EXEC SP_LOCK (omiited some data to make it viewable)
spid ObjId Type Mode Status
52 938157062 TAB IX GRANT
52 938157062 PAG IX GRANT
52 938157062 KEY X GRANT
53 938157062 TAB Sch-M WAIT
53 938157062 TAB Sch-M GRANT
53 938157062 TAB Sch-M GRANT
53 938157062 TAB Sch-M GRANT
53 938157062 TAB Sch-M GRANT
53 938157062 TAB Sch-M GRANT
58 1131151075 TAB IS GRANT

So, the inserts require a table level IX lock and aren’t blocked by the table level Sch-M lock.

Let’s try this again with a DELETE.

SESSION 52:

USE tempdb
GO
drop table tableA
GO
create table tableA (col1 int identity(1,1) not null primary key)
go
insert into tableA default values
insert into tableA default values
insert into tableA default values
GO

SESSION 53:
BEGIN TRAN
DELETE TABLEA WHERE COL1=1
WAITFOR DELAY ’1:00′
ROLLBACK TRAN

SESSION 55:
ALTER TABLE TABLEA ADD COL2 INT

SESSION 57:
DELETE TABLEA WHERE COL1=1
/* NOW IT’S BLOCKED */

SESSION 61:
spid dbid ObjId Type Mode Status
53 2 0 PAG IX GRANT
53 2 1002157290 TAB IX GRANT
53 2 0 KEY X GRANT
54 7 0 DB S GRANT
55 2 1002157290 TAB Sch-M GRANT
55 2 1002157290 TAB Sch-M GRANT
55 2 1002157290 TAB Sch-M GRANT
55 2 1002157290 TAB Sch-M GRANT
55 2 1002157290 TAB Sch-M GRANT
55 2 1002157290 TAB Sch-M GRANT
55 2 1002157290 TAB Sch-M WAIT
55 2 1002157290 TAB Sch-M GRANT
55 2 1002157290 TAB Sch-M GRANT
55 2 1002157290 TAB Sch-M GRANT
55 2 1002157290 TAB Sch-M GRANT
55 2 1002157290 TAB Sch-M GRANT
55 2 1002157290 TAB Sch-M GRANT
57 2 1002157290 TAB IX WAIT
61 7 0 DB S GRANT
61 1 1131151075 TAB IS GRANT
62 7 0 DB S GRANT

So, the insert was fine as we saw before but now with a DELETE.. it’s blocked… Note the wait for the TAB level, IX on session 57. Session 57 is blocked by 55, the alter table statement. But why didn’t this occur on the INSERT, in the previous example.

In addition, the lock compatibility matrix (http://msdn.microsoft.com/en-us/library/ms186396.aspx) says that IX and SCH-M locks are not compatible. As a result, the ALTER should not have granted any SCH-M locks on the same table object.

I tried this with UPDATES and the result is the same as with DELETES.

We all go through the phase where we learn.

Kind Regards,
Pinal

I do follow your blog and you are very true, your Top 10 Junior DBA interview tips are good. There are few, which even Sr. DBA can get wrong too :)

It is all about *real* experience and I am sure there are very few people like the same.

Kind Regards,
Pinal

It appears simple at first but actually requires some thought and problem solving. Important traits in a good SQL Developer or DBA.

On the subject of interviewing SQL Server data professionals, you may be interested to read my “Top 10 Junior DBA Interview Tips”.

http://www.johnsansom.com/index.php/2010/02/top-10-junior-dba-interview-tips/

If Truncate Table is a DDL statement, why its behaving like this. But when i executed Drop Table or Create Table , schema locking occurring normally.

Thnks lot.