Databases Reference
In-Depth Information
WHERE ProductID =1;
--ROLLBACK TRAN;
SELECT resource_type
,resource_subtype
,resource_description
,resource_associated_entity_id
,request_mode
,request_status
FROM sys.dm_tran_locks
WHERE request_session_id = @@spid;
Note the intent locks (
request
_
mode
is
IX
) on page and object in Figure 6-11. Now try to run this
ALTER
TABLE
statement in another query window:
FIGURE 6-11
USE AdventureWorks2012;
/* SESSION 2 */
BEGIN TRANSACTION;
ALTER TABLE Production.Product
ADD TESTCOLUMN INT NULL;
--ROLLBACK TRANSACTION;
The
ALTER
TABLE
statement should be blocked. How do you know this? First, it will take forever
to make that change, as the explicit transaction in Session 1 hasn't been closed. However, more
important, look at row 5 in the output shown in Figure 6-12 (the query for
sys
.
dm
_
tran
_
locks
has been rerun in the Session 1 window but also includes the SPID used for Session 2). Note that
the
request_mode
contains a
schema modify lock
, and that the
request_status
is set to
WAIT
.
This means it is on the wait list, which ties back to the fact that it is blocked. Finally, look at the
resource_type
. It's an object resource request. The database engine checks for the existence of
an object
resource_type
for the same
resource_associated_entity_id
as the one requested.
Because one exists, the
ALTER
TABLE
cannot proceed.
FIGURE 6-12
You might want to roll back those transactions now to release the locks.
Search WWH ::
Custom Search