I would like…. if I may… it take you on a strange journey….
- A SQL Server database with ALLOW_SNAPSHOT_ISOLATION set to true
- A stored procedure that creates a #temp table in tempdb and subsequently drops it
- Multiple calls of this stored procedure (running in Snapshot Isolation mode) happening at the same time
Please tell me how/why I would get this error:
Msg 3961, Level 16, State 1, Procedure CREATETABLE, Line 8
Snapshot isolation transaction failed in database ‘tempdb’ because the object accessed by the statement has been modified by a DDL statement in another concurrent transaction since the start of this transaction. It is disallowed because the metadata is not versioned. A concurrent update to metadata can lead to inconsistency if mixed with snapshot isolation.
Riddle me that!!!! (and yes I saved you the horror of seeing me in skintight green spandex)
SETUP (credit: Loris Chiocca):
CREATE DATABASE [SnapshotIsolationDB]
CONTAINMENT = NONE
( NAME = N'SnapshotIsolationDB', FILENAME = N'C:\TEMP\SnapshotIsolationDB.mdf' , SIZE = 102400KB , MAXSIZE = UNLIMITED, FILEGROWTH = 1024KB )
( NAME = N'SnapshotIsolationDB_log', FILENAME = N'C:\TEMP\SnapshotIsolationDB_log.ldf' , SIZE = 10240KB , MAXSIZE = 2048GB , FILEGROWTH = 10%)
ALTER DATABASE [SnapshotIsolationDB] SET ALLOW_SNAPSHOT_ISOLATION ON
CREATE PROCEDURE [dbo].[ACCESSTABLE]
SELECT * FROM #TEMPORARYTABLE
CREATE PROCEDURE [dbo].[CREATETABLE]
CREATE TABLE #TEMPORARYTABLE (
ID int NOT NULL primary key
waitfor delay '00:00:01'
DROP TABLE #TEMPORARYTABLE
MULTIPLE CONNECTIONS RUNNING CODE BELOW AT THE SAME TIME (credit: Loris Chiocca):
set transaction isolation level snapshot
Keep in mind you’ll probably have to rush-click-execute a few times before being able to produce the error…
So this isn’t my code or my find in the first place.
Why am I talking about it then?
- To hopefully bring more light to this bug
- To hopefully help others who run into this problem and their google-fu wasn’t able to point them to the Microsoft Connect Item.
- Cause it’s a thorn in my ass right now
Check this out…
And the comment of particular concern:
“Thank you for submitting this feedback. After carefully evaluating all of the bugs in our pipeline, we are closing bugs that we will not fix in the current or future versions of SQL Server. The reasons for closing this bug is because the scenario reported in the bug are not common enough and due to the risk of implementing a fix it unfortunately does not meet the bar for the current version of the product.“
If anyone is curious as to how I “fixed” my problem…. I stopped explicitly dropping the #temp tables in my stored procedure and allowed SQL Server to “clean up after itself” as the Snapshot Isolation errors always seemed to have an issue with the:
DROP TABLE #TEMPORARYTABLE
The question outstanding though is if #temp tables are created with the same name by different SPIDs and they exist in tempdb with the unique name that looks like : #temp_____00000090019545666 how can ANOTHER SPID be affected by the creation and dropping of said #temp table???
Enjoy!! (Follow me on Twitter: @ColinStasiuk)