INF: Analyzovaním a Nedostať v SQL Server

Preklady článku Preklady článku
ID článku: 169960 - Zobraziť produkty, ktorých sa tento článok týka.
Rozbaliť všetko | Zbaliť všetko

Na tejto stránke

SUHRN

Microsoft SQL Server tvrdí transakčné integrity a databázy konzistencia pomocou zámkov. SQL Server verzie 6.5 voliteľne používa riadok- úroveň zamknutie vložiť operácií a použitie strana-úrovni zamykania pre ostatné operácie. Rovnako ako u akéhokoľvek relačnej databázy systému zamykania môže viesť k uviaznutiu medzi užívateľmi.

Predpokladajme, že napríklad používateľ1 (alebo Connection1) má zámok na údaje tovar "A" a chce zámok na údajová položka "B." POUŽÍVATEĽ2 má zámok na údajová položka "B" a teraz chce zámok na údajová položka "A." V tomto scenári SQL Server, buď používateľ1 alebo POUŽÍVATEĽ2 bude obeť zablokovanie a druhý používateľ bude poskytnutá požadované uzamknutie.

V SQL Server, môžete rozhodnúť vývojár aplikácie, ktoré pripojenie bude byť kandidát na mŕtvom bode obeť pomocou nastaviť DEADLOCK_PRIORITY. Ak vývojár neurčí prioritou pre uviaznutiu, SQL Server vyberie zablokovanie obeť výberom procesu, dopĺňajúci obežník reťazec zámky.

Databázové aplikácie systémy môžu správajú inak, keď portován z jedného relačné databázy do druhej, založené na vykonávanie relačný databázový systém. Jednou z oblastí sa pozrieť na behaviorálne zmeny je zamykanie. Tento článok vysvetľuje, ako analyzovať uviaznutiu v SQL Server a techniky možno použiť sa im vyhnúť.

DALSIE INFORMACIE

Tento článok zdôrazňuje pomocou výstup stopových príznak T1204 analyzovať uviaznutiu. Keď je nastavený príznak stopových T1204, SQL Server tlačí informácie o zablokovania, ak sa vyskytne. Chcete použiť tento stopových príznak, použite do príkazového riadka nasledovný príkaz na spustenie servera SQL Server:
   sqlservr -c -T1204
				

Stopové výsledky sú zaslané okna konzoly, pokiaľ nenastavíte stopových vlajkou T3605, ktoré zašle stopových výstupný denník chýb.

Uviaznutiu môže dôjsť, keď dve pripojenia aktualizovať tabuliek v opačnom poradí. Napríklad jedno pripojenie vloží do tabuľky "example1" prvý a potom do "example2", zatiaľ čo iný pripojenie vložky do tabuľky "example2" prvý a potom do "example1" v rámci transakcie. Príklad scenáre je užitočné pre ilustráciu, ako sa vyhnúť uviaznutiu.

Nasledujúce sú príkazy SQL na vytvorenie tabuľky na tento účel používajú Príklad:
   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
				

Príklad 1: Tabuľka vložené v opačnom poradí

V tomto príklade boli vložené dve tabuľky v opačnom poradí a zablokovanie vyskytla. Uviaznutiu môže tiež vyskytnúť, keď dve alebo viac pripojení vykonať aktualizuje alebo odstráni na tabuľkách v opačnom poradí.
   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')
				

Na tomto mieste, Connection1 môže blokovať Connection2, pretože riadok Connection2 je vkladanie môže byť na rovnakej stránke, kde má Connection1 už vložený riadok a je holding zámku.
   Connection1 > INSERT INTO example2 VALUES (100, 'AAAA', 'CCC')
				

Na tomto mieste, Connection2 môže blokovať Connection1, pretože riadok Connection1 je vkladanie môže byť na rovnakej stránke, kde má Connection2 už vložený riadok a je holding zámku. Toto spôsobí zablokovanie.

Takto je výstup pre stopové vlajkou 1204, keď došlo k mŕtvom:
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ý riadok zablokovanie stopových, môžete oznámiť používateľom viac o zablokovanie. Connection1 je spid 13 a Connection2 je spid 14 (môžete určiť číslo SPID spojené s pripojením pomocou sp_who systému uložené postup).
   >> 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')
				

Číslo SPID 13 bol požadujúci EX_PAGE zámok a blokovaný programom spid 14, ktoré dbid 6 už EX_PAGE zámok pre stránku 0x188 tabuľka example2. V zámok sa koná na stránke patriacich do klastrovaný 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álnom príkaze popravený spid 13 je vložiť a dáva stopy časť vstupnej medzipamäte.
   >> 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')
				

Číslo SPID 14 čaká na EX_PAGE zámok a je blokovaný spid 13, ktoré už vlastní EX_PAGE zámku na rovnakej stránke.
   >> VICTIM: spid 13, pstat 0x0000 , cputime 30
   SQL Server has chosen spid 13 as the deadlock victim.
				

Toto je vysvetlenie, čo v znamená rôznych zámky trace:

SH_INT a EX_INT
Zámeru zámky, ktoré sú prijaté na vyššej úrovni položku (napríklad tabuľku) pred nižšej úrovne zámky (napríklad, strana) možno prijať, pretože LOCK manager je nevedia o vzťahu medzi rôzne typy položky (v tomto prípade, stránky a tabuľky). Ak EX_INT zámku nebrali Tabuľka pred prijatím EX_PAG zámky na stránkach iný používateľ mohol vziať EX_TAB zámok na tej istej tabuľke a manažéra Zamknúť by nevedeli, že konflikt existovala. V súčasnosti SQL Server má zámeru zámky iba na tabuľky. Existujú dva druhy zámeru zámky: zdieľané (SH_INT) a exkluzívne (EX_INT) zámky.

EX_PAGE
Toto je exkluzívny stránku Zamknúť, aby uskutočnili po aktualizovaní stránku kvôli DELETE, UPDATE alebo vložiť vyhlásenie s Vložiť riadok-úrovni blokovania (IRL) vypnuté.

UP_PAGE
Toto je aktualizácia stránky zámku, že je prijaté v mieste shared page zámkou po naskenovaní stránku a optimalizáciu vie, že stránky budú aktualizovať (alebo UPDLOCK nádychom sa používa).

PR_EXT, NX_EXT, UPD_EXT a EX_EXT
Tieto zámky sa berú pri prideľovaní alebo uvoľnenie miesta na disku. UPD_EXT je brať pri prideľovaní alebo zrušenie vyhradenia stránku z existujúcej miery a ostatné sa používajú pri prideľovanie alebo zrušenie vyhradenia celý ukladacích priestorov.

IX_PAGE a LN_PAGE
Tieto sú IRL zámky. IX_PAGE je zámer na-robiť-riadok-blokovanie zámok na stránke. LN_PAGE je brať pri stránku, na ktorých sa vykonáva IRL potreby rozdelené.

RLOCK a XRLOCK
Tieto krátkodobé zámky odoberú, keď prechádzajúcej indexom b-tree. Existujú dva typy tohto druhu zámok: zdieľané (RLOCK) a exkluzívne (XRLOCK). Zdieľané zámky sa odoberajú počas skenovania, kým výhradné zámky prijímajú index stránky počas aktualizácie.

EX_TAB
Toto je exkluzívny tabuľky zámku, ktorý sa vyskytuje pri SQL Server optimalizácia Určuje, že tabuľky skenovanie je najúčinnejší spôsob, ako vyriešiť aktualizáciu dotaz (napríklad, keď neexistujú žiadne indexy na tabuľku). EX_TAB zámky zobraziť aj keď zamknete tabuľka s TABLOCKX nádychom alebo SQL Server Escalates stránku zámkov na tabuľku tabuľka otočeným.

SH_TAB
Toto je zdieľaný tabuľky zámku, ktorý sa používa pri optimalizácia predpokladá, že Väčšina z tabuľky bude skenovaná (alebo stránke blokovania escalates) alebo TABLOCK tip sa používa.

V predchádzajúcom príklade zablokovanie sa dá vyhnúť, ak obe pripojenia aktualizovať tabuľky v nasledovnom poradí:
   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')
				

Príklad 2: Vložené do rôznych častí tej istej tabuľke

Toto môže tiež zablokovali pri dvoch spojeniach vložte do rôznych časti toho istého stola v opačnom poradí, keď riadky zdieľanie stránok. Pre Prí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 tejto tabuľke, napríklad, je na prvý stĺpec klastrovaný index example1 tabuľka. Riadky s rovnakými hodnotami pre prvý stĺpec bude tendenciu klesať na rovnakej stránke. V príklade druhý riadok vložen Connection1 pravdepodobne padne na rovnakej stránke ako prvý riadok vložiť Autor: Connection2, pretože oba majú klastrovaný index hodnotu 400. Toto spôsobuje Connection2 bloku Connection1.
   Connection2 > INSERT INTO example1 VALUES (100, 'AAAB', 'CCC')
				

Connection2, môžu teraz Connection1, čo vedie k zablokovanie tiež zablokované. Zablokovanie sledovania je:
   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
				

Číslo spid 16 žiadosti o EX_PAGE zámok pre stránky 0x2c5 je blokovaný spid 15, ktoré už vlastní EX_PAGE zámok pre stránku 0x2c5 po to urobil prvý Vložiť. A číslo spid 15 tiež dostal zablokované spid 16 na čaká na EX_PAGE zámok pre stránku 0x8db vedúce k uviaznutiu.

Toto zablokovanie sa dá zabrániť pomocou príkazu umožniť IRL pre tabuľky example1:
   sp_tableoption 'example1', 'insert row lock', true
				

Príklad 3: Vložené pomocou IRL

IRL umožňuje dvaja alebo viacerí používatelia zdieľať stránku, keď len vložiť operácie, ktoré často za následok lepšie priepustnosť. Avšak, umožňujúce IRL nebude vždy znižovať uviaznutiu. V niektorých prípadoch môžu zaviesť IRL uviaznutiu.
   Connection1 > BEGIN TRANSACTION
   Connection2 > BEGIN TRANSACTION
   Connection1 > INSERT INTO example1 VALUES (100, 'AAAA', 'CCC')
   Connection2 > INSERT INTO example1 VALUES (105, 'AAAB', 'CCC')
				

S IRL zapnuté, obe pripojenia budú držať IX_PAGE zámku na stránke obsahuje dva nové riadky. Ak bola deaktivovaná IRL, by mali Connection1 nadobudnuté EX_PAGE zámok a Connection2 by boli zablokované okamžite.
   Connection2 > UPDATE example1 SET column3 = 'CCCB' where column1 = 105
   and column2 = 'AAAB'
				

Na tomto mieste, Connection2 potrebuje výhradné stránku Zamknúť urobiť AKTUALIZÁCIU vyhlásenie, ktoré je nezlučiteľné s Connection1 na IX_PAGE zámku. Preto bude čakať Connection2.
   Connection1 > UPDATE example1 SET column3 = 'CCCA' where column1 = 100
   and column2 = 'AAAA'
				

Teraz Connection1 môže byť zablokované Connection2, čo vedie k zablokovanie. V nasledujúce je zablokovanie sledovania:
   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
				

Číslo SPID 17 (pripojenie, jeden) čaká na UP_PAGE zámku, ktorý je prvým krok k získaniu výhradné stránku zamknúť. To je blokovaný spid 18, ktorých vlastní IX_PAGE zámku na stránke 0x2c5. Číslo SPID 18 čaká na UP_PAGE zámku na rovnakej stránke, a je blokovaný IX_PAGE zámku v držbe spid 17. Toto vedie k zablokovanie, pretože IX_PAGE zámok je deliteľný, keďže UP_LOCK nie je. Počas prvého vložky, obe spids dostal IX_PAGE zámku na rovnakú stránku, a neskôr sa snažili upgrade zámok na UP_PAGE zámku, ktoré nie je možné, pretože UP_PAGE zámok je exkluzívny.

Jeden spôsob, ako sa zabránilo uviaznutiu je vložiť aktualizovaná hodnota priamo do tabuľky namiesto vkladania a potom aktualizácie riadka v tom istom transakcie. Ak to nie je možné, pomocou nasledovného príkazu vypnúť IRL pomôže sa zabránilo uviaznutiu:
   sp_tableoption 'example1', 'insert row lock', false
				

Príklad 4: Vložené do riadkov na tej istej strane

Zablokovanie vyplynúť aj keď sú riadky dva identifikátory SPID pracujú na odlišné ale patria k rovnakej stránke.
   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'
				

Na tomto mieste, Connection1 môže byť zablokované Connection2. Táto situácia môže vyskytnúť preto, Connection1 chce aktualizovať riadkov na stránku kde Connection2 už vložil riadok.
   Connection2 > UPDATE example1 SET column3 = 'CCCB' where column1 = 105
   and column2 = 'AAAB'
				

Na tomto mieste, Connection2 môže tiež byť zablokované Connection1, ktoré budú viesť k zablokovanie. Táto situácia môže nastať, ak chce Connection2 aktualizovať riadkov na stránku, kde Connection1 vložil riadok. Nasledujúce je zablokovanie sledovania:
   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 zablokovanie môžete zabrániť rozmiestnenie riadkov cez rôzne stránky. Jedna metóda na to sa znova vytvoriť klastrovaný index na Táto tabuľka s faktorom veľké výplne. Nasledujúce je vyhlásenie, vytvorí klastrovaný index s faktorom výplne 50 percent:
   create unique clustered index ex1ind1 on example1 (column1, column2)
   with fill factor = 50, PAD_INDEX
				

Toto vyhlásenie sa vytvorí klastrovaný index opúšťa polovica stránky prázdny, vrátane-leaf úrovní klastrovaný index (kvôli PAD_INDEX možnosť). Tabuľka zaberá dvojité skutočnej veľkosti, a počet riadkov na stranu sú polovica aké boli.

Výplne faktor sa neudrží na tabuľky; tabuľka je re-organized uvoľní pri istom plniacom faktorom iba počas index vytvorenie čas. V priebehu času, riadkov na stránku sa zmení z výplne faktora špecifikovaných počas indexu vytvorenie. Keď k tomu dôjde, môže byť dobrý nápad, znova vytvoriť klastrovaný index s faktorom požadovanú výplne.

Ďalším riešením predchádzajúcich zablokovanie situácie je podložky Tabuľka s figuríny stĺpce (napríklad dummy1 char(255)). To zvyšuje veľkosť riadkov a vedie k menej riadkov na stranu (len jeden riadok za strana). Pretože tento typ čalúnenia udrží časom, nemusíte potrebné znova vytvoriť klastrovaný index zachovať čalúnenia (aj keď ste chcete znova vytvoriť klastrovaný index z iných dôvodov). V Nevýhodou tejto techniky je, že úložný priestor je zbytočne figuríny polia.

Príklad 5: Padding riadkov

Padding riadky vedie k menej riadkov na stranu (teda menej uviaznutiu), ale nie úplne eliminovať uviaznutiu.

V tejto tabuľke príklad example1 čalúnená obsadiť jeden riadok na stranu. V vyhlásenia na vytvorenie tabuľky v tomto príklade sú nasledovné:
   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 momente je zablokované Connection1 Connection2 počas aktualizácie riadok. Pretože SQL Server musí udržiavať stránky reťazca ukazovatele, nezapadne predchádzajúcu stránku nasledujúcu stranu a stranu, ktorá je aktualizovaná. Pretože Connection2 drží zámku na predchádzajúcu stránku, Connection1 musia čakať až do Connection2 zaväzuje transakcie.
   Connection2 > UPDATE example1 SET column3 = 'CCCB' where column1 = 101
   and column2 = 'AAAB'
				

V tomto momente je Connection2 blokovaný Connection1, pretože musí Zamknúť predchádzajúcu stránku, ktorá je práve zamknutý Connection1. Výsledkom je zablokovanie. Zablokovanie sledovania je:
   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 zablokovanie dá vyhnúť vložením figuríny riadky medzi riadkami, sa vkladajú, aktualizovaná alebo odstránené. Napríklad, ak Connection1 funguje (vloží, aktualizuje alebo odstráni) s riadok pk = 1 a Connection2 diel s riadok pk = 5, vkladaní riadka medzi tieto dva riadky (napríklad riadok obsahujúce pk = 3) bude zabránilo uviaznutiu. Táto metóda tiež zvyšuje veľkosť tabuľky, ale môže byť najlepším riešením pre tých frontu tabuliek kritické uplatňovanie.

Príklad 6: Nonclustered indexy

V niektorých prípadoch-klastrované vedľajšie registre môžu zaviesť uviaznutiu. V v tomto príklade údržby indexu sekundárne zavádza zablokovania.

Takto je vyhlásenie použité na vytvorenie indexu sekundárne používa v v tomto príklade:
   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
				

Na tomto mieste, Connection2 môže byť zablokované Connection1 pretože Connection1 môže byť nachádza zámok na sekundárne-klastrované index stránky kde Connection2 vyžaduje aktualizáciu.
   Connection1 > UPDATE example1 SET column3 = 'CCCZ' where column1 = 305
				

V tomto bode môže byť Connection1 zablokované Connection2 výsledkom zablokovanie. Táto situácia môže nastať, keď Connection1 čaká na zámok aktualizáciu-klastrované sekundárne indexu kde Connection2 už vložené a vlastní zámku na tejto stránke. Takto je zablokovanie stopa v tomto príklade zablokovanie:
   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 zablokovanie sa dá vyhnúť kvapkadlová sekundárne indexu. Nie je možné podložky register obsahovať jeden riadok na stranu, tak táto situácia je možné zabrániť iba odstránením-klastrované sekundárne indexu alebo prostredníctvom úprava žiadosti.

Uviaznutiu môže vyskytnúť s viac ako dvoma pripojenia, v takom prípade zablokovanie stopových zobrazí spids podieľajú na mŕtvom a tiež konfliktné zámky. Uviaznutiu môže vyskytnúť s RLOCK a XRLOCK zámky, ktoré sú získané počas NAT registra. Uviaznutiu môže dôjsť aj z dôvodu rozsah zámky (PR_EXT, NX_EXT, UPD_EXT & EX_EXT).

Ďalšie informácie o analýze uviaznutiu môžete zapnúť Tieto stopové príznaky:

T1200
Všetky informácie, žiadosť/release Zamknúť vytlačí, keď sa tam vyskytne, či zablokovanie je zapojený, alebo nie. Je to drahé z hľadiska výkonu, ale môže to byť užitočné pre analýzu.

T1206
Vytlačí všetky zámky v držbe zúčastnených spids v mŕtvom.

T1208
Vytlačí názov hostiteľa a názov programu poskytnutých klientom. To môže pomôcť identifikovať klienta, ktoré sa podieľajú na zablokovanie, za predpokladu, že klient určuje jedinečnú hodnotu pre každé pripojenie.

Vlastnosti

ID článku: 169960 - Posledná kontrola: 18. októbra 2011 - Revízia: 2.0
Informácie v tomto článku sa týkajú nasledujúcich produktov:
  • Microsoft SQL Server 6.5 Standard Edition
Kľúčové slová: 
kbhowto kbusage kbmt KB169960 KbMtsk
Strojovo preložené
DÔLEŽITÉ: Tento článok bol preložený pomocou softvéru na strojový preklad od spoločnosti Microsoft, nie prekladateľom. Spoločnosť Microsoft ponúka články preložené prekladateľmi aj strojovo preložené články, vďaka čomu máte možnosť prístupu ku všetkým článkom databázy Knowledge Base vo svojom jazyku. Strojovo preložený článok však nie je vždy perfektný. Môže obsahovať chyby týkajúce sa slovnej zásoby, syntaxe alebo gramatiky, podobne ako cudzinec môže robiť chyby, keď rozpráva vašim jazykom. Spoločnosť Microsoft nenesie zodpovednosť za akékoľvek nepresnosti, chyby alebo škody spôsobené akýmkoľvek nepresným prekladom obsahu alebo jeho použitím zo strany zákazníkov. Spoločnosť Microsoft softvér na strojový preklad pravidelne aktualizuje.
Pokiaľ chcete vidieť anglickú verziu článku, kliknite sem:169960
Upozornenie na neaktuálny obsah článku databázy KB
Tento článok obsahuje informácie o produktoch, pre ktoré spoločnosť Microsoft už neposkytuje technickú podporu. Z tohto dôvodu je tento článok publikovaný ako nezmenený a už nebude aktualizovaný.

Odošlite odozvu

 

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