* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download Orphaned MSDTC transactions (-2 spids).
Survey
Document related concepts
Microsoft Access wikipedia , lookup
Global serializability wikipedia , lookup
Database model wikipedia , lookup
Relational model wikipedia , lookup
Clusterpoint wikipedia , lookup
Open Database Connectivity wikipedia , lookup
Microsoft Jet Database Engine wikipedia , lookup
Versant Object Database wikipedia , lookup
Extensible Storage Engine wikipedia , lookup
Commitment ordering wikipedia , lookup
Microsoft SQL Server wikipedia , lookup
Transcript
Orphaned MSDTC transactions (-2 spids) Any dba looking after a server that takes part in a distributed transaction will probably have come across situations where a spid that does not show up in master..sysprocesses or sys.dm_exec_sessions (depending on your version of SQL Server) ends up blocking other users. Looking at sp_locks or syslockinfo or sys.dm_tran_locks would show resources being locked by a spid with a value of -2. Spids with a negative cannot be killed in SQL Server. Often, especially in older (pre version 7) versions of SQL Server the only option was to restart SQL Server to clear those locks. Spids with a value of -2 are orphaned distributed transactions. What’s an orphaned distributed transaction? In a nutshell, it’s a distributed transaction for which the transactional state is unknown. A distributed transaction is a database transaction that involves more than one database system (usually) located on different servers. In order to maintain transactional consistency these transactions need to be coordinated, as we can’t have one database involved in the transaction committing the data it has been sent, whilst another database fails to commit the data it has been sent; either all the data is successfully committed by all the databases involved in the transaction, or the entire transaction is rolled back and no data gets committed by any database. The process responsible for coordinating these transactions is the Microsoft Distributed Transaction Coordinator, or MSDTC. You can get to it via Start > Run and typing dcomcnfg. This brings up the Component Services plugin. Click on Component Services > Computers > My Computer. Under My Computer, click on the Distributed Transaction Coordinator folder. Under Local DTC you will find the following information about MSDTC transactions: Transaction List lists active distributed transactions Transaction Statistics reports summary statistics for previous MDTC transactions Both items provide useful information, but in the context of this blog, it’s the Transaction List that we’re interested in. This lists all the currently active transactions that have not been successfully completed, or been successfully rolled back. The status column lists what MSDTC regards as the state of the transaction, and the Unit of Work ID column with those strange GUID type values displays a unique identifier that is assigned to that transaction; this is a very useful value to have as it will allow any MSDTC transactions executing within SQL Server, including transactions that MSDTC has lost control of and thus have a spid value of -2 to be killed by specifying the Unit of Work (UoW) ID in place of the spid number. If the status of the transaction is ‘Active’ then the transaction is currently executing. Figure 1 below, shows an active distributed transaction when viewed in the MSDTC console (the screenshot was taken from a Windows Vista host): Figure 1: The MSDTC Console The problems arises when, for whatever reason, MSDTC loses track of one of these transactions. The transaction will then be marked as indoubt. If this happens, SQL Server will honour the locks the spid bound to that transaction has left, but the spid itself will be assigned a negative value of -2. This means it will no longer appear as an internal process, but will still cause blocking if the original transaction was accessing tables at the time it went awol, as the locks will have been retained. This is because SQL Server does not know whether it can commit or roll back the transaction as MSDTC has control of distributed transactions. Sometimes this can happen because the MSDTC service (Distributed Transaction Coordinator) has been terminated, or is in a hung state. When MSDTC is restarted it will go through its own internal transaction log and try and regain control of transactions that were left open in order to commit them or roll them back. Usually, however, it’s because one or more of the applications involved in the distributed transaction has mis-behaved in some way and has hung or crashed, and the only option there is to try and restart the application(s) concerned and hope that it has a recovery mechanism to deal with any MSDTC transactions that were left unresolved. From time to time, therefore, MSDTC will not be able to regain control of a transaction and it’s status will be marked as ‘in-doubt’ in MSDTC coordinator. Once upon a time (well, before SQL Server 6.5 SP5 at any rate) the only way to resolve this was to restart SQL Server, and because this was once the only way to deal with orphaned spids, it’s become something of a myth that it remains the only way to deal with the issue. However, since Service Pack 5 of SQL Server 6.5 (http://support.microsoft.com/default.aspx/kb/195542) it has been possible to kill an MSDTC transaction by specifying something called the UoW ID, as opposed to just the spid number. The Unit of Work (UoW) ID The UoW ID is a 24 character GUID assigned to each transaction issued by MSDTC, and it is the UoW ID that is used to identify and kill orphaned MSDTC transactions in SQL Server. Killing an MSDTC transaction So, you’ve come up against an MSDTC transaction that the MSDTC service has been unable to successfully commit or rollback. This transaction has now left locks on your data that are associated with an orphaned spid and you’ve got no option but to kill that MSDTC transaction. You first need to retrieve the UoW ID. This should be displayed in the MSDTC console, but to verify it is the correct ID, you can interrogate the syslockinfo system view. Specifically the req_transactionUoW column. The req_spid column in syslockinfo hosts the spid number. So, to pull out the UoW ID for an orphaned MSDTC transaction you just need to run the following query: select req_transactionUoW as [UoW ID] from syslockinfo where req_spid = -2 The above will work in SQL Server 2000 onward, but from SQL Server 2005, it’s more politically correct to use the DMVs, so the table and column names have changed slightly: select request_owner_guid as [UoW ID] from sys.dm_tran_locks where request_session_id = -2 Then to kill it: kill {'UoW ID'} where {UoW ID} is the result of the above select statement. However, this must only be done as an absolute last resort when other methods, such as e.g. restarting the applications/processes involved in that distributed transaction do not resolve the problem. At the end of the day, those locks will have been placed for a reason, so you don’t know if the consistency of the data is now compromised.