INF: Analýza a předcházení zablokování v SQL Server

Překlady článku Překlady článku
ID článku: 169960 - Produkty, které se vztahují k tomuto článku.
Rozbalit všechny záložky | Minimalizovat všechny záložky

Na této stránce

Souhrn

Microsoft SQL Server udržuje transakční konzistenci a integritu databáze pomocí zámků. SQL Server verze 6.5 volitelně používá uzamykání na úrovni řádku pro operace insert a používá uzamykání na úrovni stránky pro další operace. S libovolného systému relační databáze uzamčení může vést k zablokování mezi uživateli.

Například Předpokládejme uživatel1 (nebo Connection1) má uzamčení na data položky "A" a "B" chce lock položky dat Uživatel_2 zámkem data zboží "B" a nyní chce lock položky dat "A" V tomto scénáři SQL Server uživatel1 nebo Uživatel_2 bude obětí zablokování a ostatní uživatele bude udělen požadovaný zámek.

V SQL Server vývojář aplikace rozhodnout připojení, které budou Release candidate zablokování obětí pomocí SET DEADLOCK_PRIORITY. Pokud vývojář neurčuje prioritu zablokování, SQL Server vybere obětí zablokování výběrem proces dokončí cyklický řetěz zámky.

Databáze aplikace systémů může chovat odlišně při přenést z jednoho relační databáze do jiné, na základě implementace systému relační databáze. Některé z oblastí vyhledat behaviorální změny zamykání. Tento článek vysvětluje, jak analyzovat zablokování v SQL Server a techniky, můžete jim vyhnout.

Další informace

Tento článek zvýrazní analyzovat zablokování pomocí výstupu příznak trasování T1204. Nastavit příznak trasování T1204 vytiskne SQL Server při jeho výskytu okna informace o zablokování. Chcete-li použít tento příznak trasování, použijte následující příkaz příkazového řádku spuštění serveru SQL:
   sqlservr -c -T1204
				

Výsledky trasování jsou odesílány do okna konzoly, pokud nenastavíte příznak trasování T3605, který odešle výstup trasování protokolu chyb.

Zablokování může dojít při aktualizaci tabulek v opačné pořadí dvě připojení. Jedno připojení například vloží do tabulky „ test1"první a do"priklad2", zatímco jiné připojení vloží do tabulky „ priklad2" první a do "test1" v rámci transakce. Příklad situace je užitečné znázorňují, jak se vyhnout zablokování.

Příkazy SQL použité k vytvoření tabulky použité v tomto příkladu jsou následující:
   create table example1 (column1 int, column2 char(20), column3 char(50))
   go
   create table example2 (column1 int, column2 char(20), column3 char(50))
   go
   declare @lvar int
   select @lvar = 0
   while @lvar < 500
   begin
   insert into example1 values (@lvar, 'AAA', 'CCC')
   insert into example2 values (@lvar, 'AAA', 'CCC')
   select @lvar = @lvar + 1
   end
   go
   create unique clustered index ex1ind1 on example1 (column1, column2)
   with fill factor = 90, PAD_INDEX
   go
   create unique clustered index ex2ind1 on example2 (column1, column2)
   with fill factor = 90, PAD_INDEX
   go
				

Příklad 1: Tabulka vložený opačné pořadí

V tomto příkladu dvě tabulky byly vloženy v opačné pořadí a došlo k zablokování. Zablokování může dojít také při dva nebo více připojení provést aktualizace nebo odstraní tabulek v opačné pořadí.
   Connection1 > BEGIN TRANSACTION
   Connection2 > BEGIN TRANSACTION
   Connection1 > INSERT INTO example1 VALUES (100, 'AAAA', 'CCC')
   Connection2 > INSERT INTO example2 VALUES (200, 'AAAB', 'CCC')
   Connection2 > INSERT INTO example1 VALUES (200, 'AAAB', 'CCC')
				

V tomto okamžiku Connection1 může blokovat Connection2, protože řádek vkládání Connection2 může být na stejné stránce Connection1 má již vložili řádek a je stisknuté uzamčení.
   Connection1 > INSERT INTO example2 VALUES (100, 'AAAA', 'CCC')
				

V tomto okamžiku Connection2 může blokovat Connection1, protože řádek vkládání Connection1 může být na stejné stránce Connection2 má již vložili řádek a drží zámek. To způsobuje zablokování.

Výstup trasování příznak 1204 došlo zablokování je následující:
97/04/20 11:51:57.88 spid13   *** DEADLOCK DETECTED with spid 14 ***
   spid 13 requesting EX_PAGE (waittype 0x8005), blocked by:
     EX_PAGE: spid 14, dbid 6, page 0x188, table example2, indid 0x1
     pcurcmd INSERT(0xc3), input buffer: INSERT INTO example2 VALUES (100,
     'AAAA', 'CCC')
   spid 14 waiting for EX_PAGE (waittype 0x8005), blocked by:
     EX_PAGE: spid 13, dbid 6, page 0x180, table example1, indid 0x1
     pcurcmd INSERT(0xc3), input buffer: INSERT INTO example1 VALUES (200,
   'AAAB', 'CCC')
   VICTIM: spid 13, pstat 0x0000 , cputime 30
				

Každý řádek trasování zablokování můžete uživatelům sdělit Další informace o zablokování. Connection1 spid 13 a spid 14 (můžete určit spid přidružené připojení pomocí systémové uložené procedury sp_who) je Connection2.
   >> 97/04/20 11:51:57.88 spid13   *** DEADLOCK DETECTED with spid 14 ***
   The deadlock was detected between spid 13 and spid 14.
   >> spid 13 requesting EX_PAGE (waittype 0x8005), blocked by:
   >>   EX_PAGE: spid 14, dbid 6, page 0x188, table example2, indid 0x1
   >>   pcurcmd INSERT(0xc3), input buffer: INSERT INTO example2 VALUES
   (100, 'AAAA', 'CCC')
				

Spid 13 byl vyžádáním EX_PAGE uzamknout a byl blokován spid 14, které již má EX_PAGE zámek pro stránku 0x188 na tabulce priklad2 dbid 6. Zámek uchovávány na stránce patřící seskupený index.
      Indid Value         Description
-------------------------------------
         0                Data page if there is no clustered index, or the
                          leaf page of a clustered index if there is one
         1                Non-leaf page of the clustered index page
       255                Text/image page
    Any other value       Non-clustered secondary index
				

Aktuální příkaz proveden spid 13 je INSERT a poskytuje část vstupní vyrovnávací paměti trasování.
   >> spid 14 waiting for EX_PAGE (waittype 0x8005), blocked by:
   >>   EX_PAGE: spid 13, dbid 6, page 0x180, table example1, indid 0x1
   >>   pcurcmd INSERT(0xc3), input buffer: INSERT INTO example1 VALUES
   (200, 'AAAB', 'CCC')
				

Spid 14 čekání na zámek EX_PAGE a je blokován spid 13, který již obsahuje EX_PAGE zámku na stejné stránce.
   >> VICTIM: spid 13, pstat 0x0000 , cputime 30
   SQL Server has chosen spid 13 as the deadlock victim.
				

Vysvětlení různých zámky znamenat ve sledování je následující:

SH_INT a EX_INT
Protože je správce uzamčení neví vztah mezi různé typy položek (v tomto případu, stránky a tabulky) mohou být převzaty preventivní zámky pořízené vyšší úrovně položky (například tabulka) před nižší úrovně uzamčení (například stránka). Uzamknout EX_INT byl nebere v tabulce před provedením EX_PAG zámků na stránkách, jiný uživatel trvat uzamčení EX_TAB na stejné tabulce a uzamčení správce by nevíte, že konflikt existoval. Aktuálně SQL Server má preventivní zámky pouze na tabulkách. Existují dva druhy preventivní uzamčení: uzamkne sdílené (SH_INT) a výhradní (EX_INT).

EX_PAGE
Toto je stránky výhradní zámek, která je provedena při stránky je aktualizována z důvodu DELETE, UPDATE, nebo pomocí příkazu INSERT vložit řádek uzamykání na úrovni (IRL) zakázána.

UP_PAGE
Toto je uzamčení stránky aktualizace, která je provedena namísto uzamčení sdílené stránky při naskenované stránky a Optimalizátor ví, že budou aktualizovány na stránku (nebo použít nápovědu pro UPDLOCK).

PR_EXT, NX_EXT, UPD_EXT a EX_EXT
Tyto uzamčení jsou převzaty při přidělení nebo zrušení přidělení místa na disku. Při přidělování nebo navrácení stránky z existující rozsahu je převzata UPD_EXT a ostatní se používají při přidělení nebo zrušení přidělení celý rozsahů.

IX_PAGE a LN_PAGE
Tyto jsou IRL zámky. IX_PAGE je uzamčení záměrem k proveďte řádek zamykání na stránce. LN_PAGE je převzata při stránky, na kterém IRL právě provádí potřebám rozdělit.

RLOCK a XRLOCK
Tyto krátkodobé uzamčení jsou převzaty při přecházení b stromu indexu. Existují dva typy tento druh uzamčení: sdílené (RLOCK) a výhradní (XRLOCK). Sdílené uzamčení jsou převzaty během prohledávání, zatímco výhradní uzamčení jsou převzaty na stránkách indexu během aktualizace.

EX_TAB
Toto je tabulka výhradní zámek, který nastane při prohledání tabulky je nejúčinnější způsob řešení aktualizačního dotazu (například když nejsou žádné indexy na tabulce) určuje Optimalizátor serveru SQL. Uzamčení EX_TAB zobrazí také při uzamčení tabulky s TABLOCKX rada nebo SQL Server escalates uzamčení stránky v tabulce na uzamčení tabulky.

SH_TAB
Toto je sdílené Zámek tabulky použité při Optimalizátor předpokládá, že většina tabulce kontrolovaný (nebo uzamčení stránka escalates) nebo použít nápovědu pro TABLOCK.

Předchozí příklad zablokování lze vyhnout, pokud aktualizaci tabulek v posloupnosti následující dvě připojení:
   Connection1 > BEGIN TRANSACTION
   Connection2 > BEGIN TRANSACTION
   Connection1 > INSERT INTO example1 VALUES (100, 'AAAA', 'CCC')
   Connection2 > INSERT INTO example1 VALUES (200, 'AAAB', 'CCC')
   Connection2 > INSERT INTO example2 VALUES (200, 'AAAB', 'CCC')
   Connection1 > INSERT INTO example2 VALUES (100, 'AAAA', 'CCC')
				

Příklad 2: Vložený na různé části stejné tabulky

Toto zablokování může dojít také při vložení dvě připojení do různých částí stejné tabulky opačné pořadí při řádky sdílení stránek. Například:
   Connection1 > BEGIN TRANSACTION
   Connection2 > BEGIN TRANSACTION
   Connection1 > INSERT INTO example1 VALUES (100, 'AAAA', 'CCC')
   Connection2 > INSERT INTO example1 VALUES (400, 'AAAB', 'CCC')
   Connection1 > INSERT INTO example1 VALUES (400, 'AAAA', 'CCC')
				

V této tabulce příkladu existuje na první sloupec tabulky test1 seskupený index. Řádky s stejné hodnoty prvního sloupce bude mají tendenci připadají na stejné stránce. V příkladu druhého řádku vložen Connection1 bude pravděpodobně připadají na stejné stránce jako první řádek vložena Connection2, protože oba mají hodnotu seskupený index 400. To způsobí Connection2 bloku Connection1.
   Connection2 > INSERT INTO example1 VALUES (100, 'AAAB', 'CCC')
				

Nyní Connection2 může také být blokovány Connection1 úvodní zablokování. Zablokování trasování je následující:
   97/04/20 12:56:01.40 spid16   *** DEADLOCK DETECTED with spid 15 ***
   spid 16 requesting EX_PAGE (waittype 0x8005), blocked by:
     EX_PAGE: spid 15, dbid 6, page 0x2c5, table example1, indid 0
     pcurcmd INSERT(0xc3), input buffer: INSERT INTO example1 VALUES (100,
   'AAAB', 'CCC')
   spid 15 waiting for EX_PAGE (waittype 0x8005), blocked by:
     EX_PAGE: spid 16, dbid 6, page 0x8bd, table example1, indid 0
     pcurcmd INSERT(0xc3), input buffer: INSERT INTO example1 VALUES (400,
   'AAAA', 'CCC')
   VICTIM: spid 16, pstat 0x0000 , cputime 130
				

Požadavek spid 16 uzamčení EX_PAGE stránka 0x2c5 je zablokována spid 15, který již obsahuje uzamčení EX_PAGE stránka 0x2c5 po nebyl první vložit. A spid 15 také obdržel blokovány spid 16 na čekání na zámek EX_PAGE pro úvodní stránka 0x8db k zablokování.

Toto zablokování lze vyhnout povolení IRL test1 tabulky pomocí následující příkaz:
   sp_tableoption 'example1', 'insert row lock', true
				

Příklad 3: Použití IRL vložený

IRL umožňuje dvěma nebo více uživatelům sdílení stránky při pouze vložte operace, často výsledkem je lepší propustnost. Však povolení IRL není vždy snížíte zablokování. V některých případech může IRL zavádět zablokování.
   Connection1 > BEGIN TRANSACTION
   Connection2 > BEGIN TRANSACTION
   Connection1 > INSERT INTO example1 VALUES (100, 'AAAA', 'CCC')
   Connection2 > INSERT INTO example1 VALUES (105, 'AAAB', 'CCC')
				

Obě připojení bude na stránce obsahující dva nové řádky podržte s IRL povoleno uzamčení IX_PAGE. Byl zakázán IRL Connection1 by získali EX_PAGE uzamknout a Connection2 by byly blokovány okamžitě.
   Connection2 > UPDATE example1 SET column3 = 'CCCB' where column1 = 105
   and column2 = 'AAAB'
				

V tomto okamžiku Connection2 potřebuje uzamčení výhradní stránky provést příkaz UPDATE, která je nekompatibilní s jeho Connection1 IX_PAGE uzamčení. Proto bude čekat Connection2.
   Connection1 > UPDATE example1 SET column3 = 'CCCA' where column1 = 100
   and column2 = 'AAAA'
				

Nyní Connection1 mohou být zablokovány Connection2 úvodní zablokování. Zablokování trasování je následující:
   97/04/20 15:13:50.07 spid17   *** DEADLOCK DETECTED with spid 18 ***
   spid 17 requesting UP_PAGE (waittype 0x8007), blocked by:
     IX_PAGE: spid 18, dbid 6, page 0x2c5, table example1, indid 0
     pcurcmd UPDATE(0xc5), input buffer: UPDATE example1 SET column3 =
   'CCCA' where column1 = 100 and column2 = 'AAAA'
   spid 18 waiting for UP_PAGE (waittype 0x8007), blocked by:
     IX_PAGE: spid 17, dbid 6, page 0x2c5, table example1, indid 0
     pcurcmd UPDATE(0xc5), input buffer: UPDATE example1 SET column3 =
   'CCCB' where column1 = 105 and column2 = 'AAAB'
   VICTIM: spid 17, pstat 0x0000 , cputime 20
				

Uzamknout UP_PAGE, což je první krok získávání stránky výhradní zámek čeká spid 17 (připojení jeden). Je blokován nastavením spid 18, který plní IX_PAGE zámku na stránce 0x2c5. Spid 18 UP_PAGE uzamčení čekání na stejné stránce a je blokován uzamčení IX_PAGE držené spid 17. To vede k zablokování protože IX_PAGE uzamčení je sdílet, zatímco UP_LOCK není. Během první vloží i spids obdržel IX_PAGE zámku na stejné stránce a později jejich pokusili upgradu uzamčení UP_PAGE zámku, což není možné, protože je výhradní zámek UP_PAGE.

Jeden způsob, jak předejít zablokování je vložit aktualizovanou hodnotu přímo do tabulky namísto vkládání a aktualizaci řádků v jedné transakce. Pokud to není možné zakázat IRL pomocí následujícího příkazu pomůže předejít zablokování:
   sp_tableoption 'example1', 'insert row lock', false
				

Příklad 4: Vložený do řádků na stejné stránce

Když pracujete spids dva řádky jsou různé, ale patří ke stejné stránce může také dojít k zablokování.
   Connection1 > BEGIN TRANSACTION
   Connection2 > BEGIN TRANSACTION
   Connection1 > INSERT INTO example1 VALUES (100, 'AAAA', 'CCC')
   Connection2 > INSERT INTO example1 VALUES (400, 'AAAB', 'CCC')
   Connection1 > UPDATE example1 SET column3 = 'CCCA' where column1 = 405
   and column2 = 'AAAA'
				

V tomto okamžiku Connection1 mohou být zablokovány Connection2. Této situaci může dojít, protože Connection1 chce aktualizovat řádek stránky, kde Connection2 má již vložili řádek.
   Connection2 > UPDATE example1 SET column3 = 'CCCB' where column1 = 105
   and column2 = 'AAAB'
				

V tomto okamžiku Connection2 může také být blokovány Connection1, který bude vést k zablokování. Této situaci může dojít při Connection2 chce aktualizovat řádek stránky, kde má Connection1 vložen řádek. Zablokování trasování je následující:
   97/04/20 15:48:21.18 spid20   *** DEADLOCK DETECTED with spid 19 ***
   spid 20 requesting UP_PAGE (waittype 0x8007), blocked by:
     EX_PAGE: spid 19, dbid 6, page 0x2c4, table example1, indid 0
     pcurcmd UPDATE(0xc5), input buffer: UPDATE example1 SET column3 =
   'CCCB' where column1 = 105 and column2 = 'AAAB'
   spid 19 waiting for UP_PAGE (waittype 0x8007), blocked by:
     EX_PAGE: spid 20, dbid 6, page 0xc48, table example1, indid 0
     pcurcmd UPDATE(0xc5), input buffer: UPDATE example1 SET column3 =
   'CCCA' where column1 = 405 and column2 = 'AAAA'
   VICTIM: spid 20, pstat 0x0000 , cputime 60
				

Toto zablokování lze vyhnout při rozprostření mimo řádky nad různých stránek. Jedna metoda k tomu je znovu vytvořit seskupený index v této tabulce s faktor vyplnění velký. Příkaz vytvoří seskupený index s faktor vyplnění 50 procent je následující:
   create unique clustered index ex1ind1 on example1 (column1, column2)
   with fill factor = 50, PAD_INDEX
				

Tento příkaz vytvoří seskupený index polovině stránky ponechejte prázdný, včetně úrovní nelistové seskupený index (kvůli možnost PAD_INDEX). Tabulka zabírá dvojité skutečná velikost a počet řádků na stránku jsou polovinu co byly.

Faktor vyplnění není zachováno na tabulce; pouze během času vytvoření indexu je re-organized faktor zaplnění zadané v tabulce. Časem bude řádků na stránce změnit z faktor zaplnění zadané během vytváření indexu. V tomto případě může být vhodné znovu vytvořit seskupený index s faktor vyplnění požadovaného.

Jiné řešení předchozí situaci zablokování vyhnete je plocha tabulku s fiktivní sloupce (například dummy1 char(255)). Tato zvětší velikost řádku a vede k méně řádků na stránku (jako několik jako jeden řádek pro každou stránku). Protože tento typ odsazení obsahu je udržována v čase, není nutné znovu vytvořit seskupený index udržovat odsazení (když chcete znovu vytvořit seskupený index jiných důvodů). Nevýhodou Tato technika je, že na fiktivní polí nevyužita úložný prostor.

Příklad 5: Výplň řádky

Odsazení obsahu řádků vede k méně řádků na stránce (tedy méně zablokování), ale jej není zcela odstraníte zablokování.

V této tabulce příklad test1 ořezán zabírat jeden řádek pro každou stránku. Příkazy použité k vytvoření tabulky v tomto příkladu jsou následující:
   create table example1 (column1 int, column2 char(20), column3 char(50),
   dummy_column4 char (255), dummy_column5 char (255), dummy_column6 char
   (255))
   go
   create unique index ex1ind5 on example1 (column3, column2, column1,
   dummy_column4, dummy_column5, dummy_column6) with fill factor = 85
   go
   Connection1 > BEGIN TRANSACTION
   Connection2 > BEGIN TRANSACTION
   Connection1 > INSERT INTO example1 VALUES (100, 'AAAA', 'CCC', ' ', ' ',
   ' ', ' ')
   Connection2 > INSERT INTO example1 VALUES (400, 'AAAB', 'CCC', ' ', ' ',
   ' ', ' ')
   Connection1 > UPDATE example1 SET column3 = 'CCCA' where column1 = 401
   and column2 = 'AAAA'
				

V tomto okamžiku Connection1 je zablokována Connection2 při aktualizaci řádku. Protože SQL Server musí spravovat stránku řetěz ukazatelů, uzamkne předchozí stránku, další stránky a stránky, který je aktualizován. Protože Connection2 uchovává uzamčení na předchozí stránce, musí Connection1 počkejte, dokud Connection2 potvrdí transakci.
   Connection2 > UPDATE example1 SET column3 = 'CCCB' where column1 = 101
   and column2 = 'AAAB'
				

V tomto okamžiku Connection2 je zablokována Connection1 protože nutné zamknout na předchozí stránku aktuálně uzamčena uživatelem Connection1. Výsledkem je zablokování. Zablokování trasování je následující:
   spid 20 requesting UP_PAGE (waittype 0x8007), blocked by:
     EX_PAGE: spid 19, dbid 6, page 0x12b5, table example1, indid 0
     pcurcmd UPDATE(0xc5), input buffer: UPDATE example1 SET column3 =
   'CCCB' where column1 = 101 and column2 = 'AAAB'
   spid 19 waiting for UP_PAGE (waittype 0x8007), blocked by:
     EX_PAGE: spid 20, dbid 6, page 0x1531, table example1, indid 0
     pcurcmd UPDATE(0xc5), input buffer: UPDATE example1 SET column3 =
   'CCCA' where column1 = 401 and column2 = 'AAAA'
   VICTIM: spid 20, pstat 0x0000 , cputime 300
				

Toto zablokování vyhnout vložením fiktivní řádků mezi řádky, které jsou právě vložili, aktualizována nebo odstraněna. Například pokud Connection1 pracuje s řádku pk (vloží, aktualizace nebo odstraní) = 1 a Connection2 pracuje se řádek pk = 5 vložení řádku mezi tyto dva řádky (například řádek obsahující pk = 3) bude předejít zablokování. Tuto metodu také zvětší velikost tabulky, ale může být nejlepším řešením těchto tabulek fronty kritické aplikace.

Příklad 6: Nonclustered indexy

V některých případech může bez clusterů sekundární indexy zavádět zablokování. V tomto příkladu zavádí údržby indexu sekundární zablokování.

Příkaz použitý k vytvoření indexu sekundární použité v tomto příkladu je následující:
   create index ex1ind2 on example1 (column3) with fill factor = 90,
   PAD_INDEX
   Connection1 > BEGIN TRANSACTION
   Connection2 > BEGIN TRANSACTION
   Connection1 > INSERT INTO example1 VALUES (100, 'AAAA', 'CCBA', ' ', '
   ', ' ', ' ')
   Connection2 > INSERT INTO example1 VALUES (300, 'AAAB', 'CCCZ', ' ', '
   ', ' ', ' ')
   Connection2 > UPDATE example1 SET column3 = 'CCBA' where column1 = 105
				

V tomto okamžiku Connection2 mohou být zablokovány Connection1 protože Connection1 může být podržením uzamčení na stránce indexu sekundární bez clusterů kde Connection2 potřebuje aktualizovat.
   Connection1 > UPDATE example1 SET column3 = 'CCCZ' where column1 = 305
				

V tomto okamžiku Connection1 mohou být zablokovány Connection2 následek zablokování. Této situaci může dojít při Connection1 čekání uzamknout bez clusterů sekundární rejstřík aktualizovat Connection2 má již vložili a zastává uzamčení na této stránce. Trasování zablokování například zablokování je následující:
   97/04/20 19:05:38.75 spid11   *** DEADLOCK DETECTED with spid 12 ***
   spid 11 requesting EX_PAGE (waittype 0x8005), blocked by:
     EX_PAGE: spid 12, dbid 6, page 0x112f, table example1, indid 0x2
     pcurcmd UPDATE(0xc5), input buffer: UPDATE example1 SET column3 =
   'CCCZ' where column1 = 305
   spid 12 waiting for EX_PAGE (waittype 0x8005), blocked by:
     EX_PAGE: spid 11, dbid 6, page 0x1108, table example1, indid 0x2
     pcurcmd UPDATE(0xc5), input buffer: UPDATE example1 SET column3 =
   'CCBA' where column1 = 105
   VICTIM: spid 11, pstat 0x0000 , cputime 50
				

Toto zablokování vyhnout umístěním sekundární indexu. Není možné pro zapisování indexu obsahují jeden řádek pro každou stránku, takže lze této situaci vyhnout pouze vyloučení bez clusterů sekundární indexu nebo úpravou aplikace.

Zablokování může dojít s více než dvě připojení v tomto případě zablokování trasování uvádí spids účastní zablokování a také konfliktní zámky. Zablokování může dojít s RLOCK a XRLOCK uzamčení, které získali během přecházení indexu. Zablokování může také dojít z důvodu uzamčení rozsahu (PR_EXT, NX_EXT, UPD_EXT & EX_EXT).

Další informace o analýze zablokování můžete povolit trasování následující příznaky:

T1200
Vytiskne všechny informace o zámku požadavek a uvolňovat při výskytu, zda je zapojen k zablokování nebo Ne. Toto je z hlediska výkonu nákladné, ale může být užitečné pro analýzu.

T1206
Vytiskne všechny zámky držené zúčastněné spids zablokování.

T1208
Vytiskne název hostitele a název programu zadaný klientem. Toto může pomoci identifikovat klienta účastní zablokování, za předpokladu, že klient určuje jedinečnou hodnotu pro každé připojení.

Vlastnosti

ID článku: 169960 - Poslední aktualizace: 16. října 2003 - Revize: 3.0
Informace v tomto článku jsou určeny pro produkt:
  • Microsoft SQL Server 6.5 Standard Edition
Klíčová slova: 
kbmt kbhowto kbusage KB169960 KbMtcs
Strojově přeložený článek
Důležité: Tento článek byl přeložen pomocí software společnosti Microsoft na strojový překlad, ne profesionálním překladatelem. Společnost Microsoft nabízí jak články přeložené překladatelem, tak články přeložené pomocí software na strojový překlad, takže všechny články ve Znalostní databázi (Knowledge Base) jsou dostupné v češtině. Překlad pomocí software na strojový překlad ale není bohužel vždy dokonalý. Obsahuje chyby ve skloňování slov, skladbě vět, nebo gramatice, podobně jako když cizinci dělají chyby při mluvení v češtině. Společnost Microsoft není právně zodpovědná za nepřesnosti, chyby nebo škody vzniklé chybami v překladu, nebo při použití nepřesně přeložených instrukcí v článku zákazníkem. Společnost Microsoft aktualizuje software na strojový překlad, aby byl počet chyb omezen na minimum.
Projděte si také anglickou verzi článku:169960
Právní omezení pro obsah znalostní báze týkající se produktů, jejichž podpora byla ukončena
Tento článek byl napsán o produktech, pro které společnost Microsoft již neposkytuje nadále podporu. Článek je tedy nabízen v takovém stavu, v jakém je, a nebude již nadále aktualizován.

Dejte nám zpětnou vazbu

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com