I am trying to localize an issue I have
with 2 DBs and their transactional behavior.
I create two DBs on a single SQL Server 2008 R2 instance.
test1
test2
test1 has one table Table_1
test2 has one table Table_2
Both tables have an ID (int) and a value (string) columns.
Both have just one row which has ID=1.
Then in SQL Server Management Studio,
in some window 1 I do
use test1
begin transaction
update test1.dbo.Table_1
set
value = 'TEST-100'
where
ID = 1
update test2.dbo.Table_2
set
value = 'TEST-200'
where
ID = 1
commit transaction --- but I don’t run the commit yet ---
and then in another window 2, I do
select * From test1.dbo.Table_1
with (nolock)
select * From test2.dbo.Table_2
with (nolock)
This way I can see the two uncommitted yet values.
But if in window 2, I do
select * From test1.dbo.Table_1
or
select * From test2.dbo.Table_2
these SELECT staments hang.
So my question is: is that transaction from
window 1, spanning two DBs? Seems so because
select * From test2.dbo.Table_2
hangs too which means to me that test2.dbo.Table_2
is enlisted in the same transaction which I started
in window 1.
But why is this transaction acting like a distributed one?
Is that normal? What is the explanation? Is that some
undocummented feature in SQL Server? Are there any
references which would explain that behavior I am seeing?
When a query spans over 2 databases, then your transaction is promoted to a distributed transaction handled by MSDTC. It's the normal way to be and it happens without explicitly using BEGIN DISTRIBUTED TRANSACTION statement.
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.