SQL server-Transaktion (ID) Deadlock

Ich bin vor einem Problem Ich kann nicht lösen, während die Schaffung neuer database durch private Software-Installation.

Deadlock-Fehlerbild

Link zu XML-file der Trace-Tracking der Deadlock- XML-file hier

Ich war in der Lage zu verfolgen, was verursacht die Deadlock und seine, während ich versuche, db Besitzer ändern.

statement: EXEC [ISC_RAS_CD_APP] .dbo.sp_changedbowner @loginame = N'sa ', @map = false

Bildbeschreibung hier eingeben

<deadlock-list> <deadlock victim="process4efa404e8"> <process-list> <process id="process4efa404e8" taskpriority="0" logused="0" waitresource="KEY: 1:281474978545664 (11ea04af99f6)" waittime="4947" ownerId="1284191" transactionname="HkHostCkptEnableDisable" lasttranstarted="2017-02-23T12:51:54.617" XDES="0x4ff1e5be0" lockMode="S" schedulerid="4" kpid="10252" status="suspended" spid="62" sbid="0" ecid="0" priority="0" trancount="1" lastbatchstarted="2017-02-23T12:51:54.610" lastbatchcompleted="2017-02-23T12:51:54.610" lastattention="2017-02-23T12:51:54.580" clientapp="SQL Management" hostname="IDQSRV01" hostpid="8940" loginname="HMS\OrenG" isolationlevel="read committed (2)" xactid="1284156" currentdb="12" lockTimeout="4294967295" clientoption1="673185824" clientoption2="128056"> <executionStack> <frame procname="mssqlsystemresource.sys.sp_changedbowner" line="26" stmtstart="1656" stmtend="1686" sqlhandle="0x0300ff7f12d71ceed5d2350180a4000001000000000000000000000000000000000000000000000000000000"> checkpoint </frame> <frame procname="adhoc" line="1" sqlhandle="0x01000c0069b98f048084f3000500000000000000000000000000000000000000000000000000000000000000"> EXEC [ISC_RAS_CD_APP].dbo.sp_changedbowner @loginame = N'sa', @map = false </frame> </executionStack> <inputbuf> EXEC [ISC_RAS_CD_APP].dbo.sp_changedbowner @loginame = N'sa', @map = false </inputbuf> </process> </process-list> <resource-list> <keylock hobtid="281474978545664" dbid="1" objectname="master.sys.sysdbreg" indexname="clst" id="lock5006efc00" mode="X" associatedObjectId="281474978545664"> <owner-list> <owner id="process4efa404e8" mode="X" /> <owner id="process4efa404e8" mode="S" requestType="wait" /> </owner-list> <waiter-list> <waiter id="process4efa404e8" mode="S" requestType="wait" /> </waiter-list> </keylock> </resource-list> </deadlock> </deadlock-list> 

"sa" ist ein Standardbenutzer, den ich bei der Installation des neuen servers erstellt habe.

meine Aufgabe Priorität ist auf 0 gesetzt, aber jedes Mal gibt es mir eine andere Aufgabe ID so bin ich nicht sicher, ob ich es ändern kann.

Ich war auf jeden einzelnen Antwort online, aber nichts konnte mir helfen, jeder hat eine Idee, was ich tun kann, um es zu beheben?

Weitere Informationen können bei Bedarf geliefert werden.

Grüße

Das ist ein seltsamer Graphen. Die session ist verriegelt und wartet auf eine Ressource, die die Session besitzt.

Sie haben die Profiler-Trace nicht nur die Deadlock-Grafik.

Basierend darauf kann ich das Problem auf 2014 aber nicht 2012 oder 2016 reproduzieren.

Code, der das Problem für mich auf allen 2014 Fällen, die ich getestet habe (mit baut wie unten)

  • (SP1-CU9-DDR) (KB3194722) – 12.0.4487.0 (X64)
  • (SP2) (KB3171021) – 12.0.5000.0 (X64))
  • Microsoft SQL server 2014 (SP2-CU4) (KB4010394) – 12.0.5540.0 (X64)
 IF db_id('FOO') IS NOT NULL BEGIN print 'dropping db' use master alter database [FOO] set single_user with rollback immediate drop database [FOO] END go CREATE DATABASE [FOO] go BEGIN TRANSACTION use [FOO] EXEC [FOO].dbo.sp_changedbowner @loginame = N'sa', @map = false COMMIT 

Ich nehme die Hk in der HkHostCkptEnableDisable (Transaktionsname in der Deadlock-Grafik) bezieht sich auf "Hekaton" so vielleicht war dies ein Problem mit einigen Code-Änderung zur Unterstützung im memory OLTP im Jahr 2014 eingeführt.

Das Problem geht weg, wenn ich die explizite Transaktion los bin. Also ein Ansatz wäre, dies zu tun, um die Sperre freizugeben, die angefochten wird.

Oder alternativ können Sie den Ratschlag in der Abschreibungsbekanntmachung für sp_changedbowner

Diese function wird in einer zukünftigen Version von Microsoft SQL server entfernt. Vermeiden Sie es, diese function in der neuen Entwicklungsarbeit zu verwenden und um Anwendungen zu ändern, die diese function derzeit verwenden. Verwenden Sie stattdessen ALTER AUTORISIERUNG.

sp_changedbowner nennt dies trotzdem aber fügt einen zusätzlichen checkpoint , der das Problem verursacht (ich bekomme auch die Deadlock, wenn ich den Code unten mit der Checkpoint Linie unkommentiert benutze).

 BEGIN TRANSACTION alter authorization on database::[FOO] to [sa] --checkpoint COMMIT 

Der Checkpoint scheint in master.sys.sysdbreg , der ausschließlich durch die alter authorization in der gleichen session gesperrt ist, zu 0x01 (die sid Spalte wird auf 0x01 für die zu dieser database gehörige Zeile aktualisiert) und die Checkpoint-Transaktion ist nicht in der Lage, die Sperre für die Benutzer-Transaktion zu erhalten.