INF: Pochopenie a riešenie problémov blokovanie SQL Server

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

Na tejto stránke

SUHRN

V tomto článku sa pojem "pripojenie" odkazuje na jednotného prihlásení relácie databázy. Každé pripojenie sa zobrazí ako identifikácia relácie (SPID). Každý z týchto SPIDs sa často označuje ako proces, hoci nie je samostatný proces kontexte v bežnom zmysle. Skôr, každú SPID pozostáva zo servera zdrojov a dátové štruktúry potrebné na servisné po?iadavky jediného pripojenia z daného klienta. A jediný klientska aplikácia môže mať jedno alebo viac pripojení. Z perspektívy SQL Server, nie je žiadny rozdiel medzi viaceré pripojenia z jedného klienta aplikácie na jedného klienta počítači a viacnásobné pripojenia z viacerých klientské aplikácie alebo viacerých klientske počítače. Jeden pripojenie môže blokovať iného pripojenia, bez ohľadu na to, či vychádzajú z rovnaké aplikácie alebo samostatné žiadosti na dvoch rôznych klienta počítače.

DALSIE INFORMACIE

Blokovanie je nevyhnutná charakteristika každom relačné databázový systém (RDBMS) s zámok-založené súbežnosti. Na serveri SQL Server blokovanie nastane vtedy, keď jeden SPID drží zámok na špecifických zdrojov a druhý Číslo SPID sa pokúsi získať konfliktné typu uzamknutia na rovnakom prostriedku. Časový rámec pre ktoré prvé číslo SPID zamkne prostriedku je obvykle veľmi malé. Keď ju uvoľňuje zámok, druhé pripojenie je zadarmo získať jeho Vlastný zámok na prostriedku a pokračovať v spracovaní. To je normálne správanie a môže sa stať niekoľkokrát v priebehu dňa s nemalo podstatnejší vplyv na výkon systému.

Trvanie a transakcie kontexte dotaz určiť, ako dlho sa konajú jej zámky a tým, ich vplyv na iné dotazov. Ak dotaz sa nevykoná v rámci transakcie (a žiadne Zamknúť tipy používajú), zámky na príkazoch SELECT sa uskutoční len na prostriedku na v čase, to je skutočne nemohli čítať, nie na trvanie dotaz. Pre INSERT, UPDATE, a odstrániť závierky, zámky sú držané počas trvania dotaz, konzistentnosti údajov, ako aj umožniť dotaz na vrátená späť Ak je to potrebné.

Pre dotazy v rámci transakciu, trvanie pre ktoré zámky držia, sú určované typ dotazu, transakcia izolácia úrovni, a či sú použité zámky tipy v dotaz. Popis blokovania, Zamknúť tipy a transakcie izolácie úrovniach, nájdete v nasledujúcich témach v SQL Server Books Online:
  • Blokovanie v databázový Engine
  • Customizing Zamknutie a riadok verziovania
  • Zámok režimy
  • Zámok kompatibility
  • Riadok verziovania-založené izolácia úrovne v databázový Engine
  • Kontrolu transakcií (databázový Engine)
Keď blokovania a blokovanie zvýšenie k bodu tam, kde je škodlivý účinok na výkon systému, je zvyčajne spôsobené jedným z nasledujúce príčiny:
  • Číslo SPID vlastní zámky na množinu zdrojov pre rozšírený obdobie pred ich uvoľnením. Tento typ blokovanie rieši sama v priebehu času, ale môže spôsobiť výkonu.
  • Číslo SPID vlastní zámky na množinu zdrojov a nikdy uvoľňuje im. Tento typ blokovanie nevyrieši sama a zabraňuje prístupu k postihnutých zdrojov neurčito.
V prvom scenári vyššie, blokovanie problém rieši samotnom časom ako číslo SPID uvoľňuje zámkov. Avšak, môže byť situácia veľmi tekutiny ako rôznych SPIDs spôsobiť blokovanie na rôzne zdroje v priebehu času, vytvorenie pohyblivý cieľ. Z tohto dôvodu týchto situáciách môže byť ťažké riešenie problémov s používaním SQL Server Enterprise Manager alebo jednotlivé SQL dotazov. V druhej situácie výsledky konzistentný stav, ktorý môže byť jednoduchšie diagnostikovať.

Získavajú sa blokovanie informácie

Čeliť ťažkostiam pri riešení problémov, blokovanie problémy, správca databázy môžete použiť SQL skripty, ktoré neustále monitorovať stav blokovania a blokovanie na serveri SQL Server. Tieto skripty môžete poskytnúť snímky špecifických príkladov v priebehu času, čo vedie k celkový obraz o problém. Popis ako sledovať, blokovanie s SQL skripty, pozri nasledujúce články v databáze Microsoft Knowledge Base:
271509 Ako sledovať, blokovanie v SQL Server 2005 a SQL Server 2000
Skripty v tomto článku bude plniť úlohy nižšie. Ak je to možné, spôsobu získania tejto informácie z SQL Server Management Studio je uvedený.
  1. Identifikáciu SPID (identifikácia relácie) na čele blokovanie reťazca a príkazu SQL.
    Popri pomocou skriptov v spomenuté Knowledge Base, môžete vedúci blokovanie reťazca je možné identifikovať pomocou funkcií, ktoré sú poskytované prostredníctvom SQL Server Management Studio. Použite niektorý z nasledujúcich postupov:
    • Kliknite pravým tlačidlom na objekt servera, rozbaľte položku Správy, rozbaľte Štandardné správy, a potom kliknite na tlačidlo Činnosti – všetky blokovanie transakcie. Táto zostava zobrazuje transakcie na čele blokovanie reťazca. Ak rozbalíte transakcie, v zostave sa zobrazia transakcií, ktoré sú blokované hlavu transakcia. Táto zostava zobrazí aj príkazu "blokovanie SQL" a "Blokované SQL výkaz."
    • Použite DBCC INPUTBUFFER (<spid>) nájsť posledného výpisu, ktorý bol predložený SPID.</spid>
  2. Nájsť úroveň vnorenia transakcie a proces stav blokovania SPID.
    Transakcia úroveň vnorenia číslo SPID je k dispozícii v @@ TRANCOUNT globálnej premennej. Avšak, to môže byť stanovená z mimo Číslo SPID zaslanie dotaze sysprocesses Tabuľka takto:

    SELECT open_tran FROM master.sys.sysprocesses WHERE SPID=<blocking SPID number>
    go
    						
    Vrátenú hodnotu je @@ TRANCOUNT hodnotu na číslo SPID. To ukazuje Úroveň vnorenia transakcie pre blokovanie SPID, ktoré zasa môžete vysvetliť Prečo je holding zámky. Napríklad, ak je hodnota väčšia ako nula, Číslo SPID je v uprostred transakcie (v takom prípade sa očakáva že zachováva určitých zámky získal, v závislosti od transakcie izolácie úroveň).

    Môžete tiež skontrolovať, či sa dlhodobo otvoriť transakcie existuje v databáze pomocou DBCC OPENTRANdatabase_name.

Zhromažďovanie SQL Server Profiler sledovania informácií

Popri vyššie uvedených informácií, je často potrebné zachytiť Profiler stopových činností na serveri, aby dôkladne vyšetrovať blokovanie problém na serveri SQL Server. Ak číslo SPID popravených viacerých vyjadrenia v rámci transakcie, iba posledný statementthat bola predložená, bude zobrazovať v správa, vstupnej medzipamäte alebo činnosť monitora výstup. Avšak jeden z predchádzajúcich príkazov môže byť dôvod zámky sú stále zadržiavaná. Profiler stopových vám umožní vidieť všetky príkazy popravený SPID v rámci súčasných transakcie. Nasledujúce kroky pomôže nastaviť SQL Server Profiler zachytiť stopy.
  1. Otvorte SQL Server Profiler.
  2. Na Súbor ponuku, ukážte na Nové, a potom kliknite na tlačidlo Stopový.
  3. Na Všeobecné kartu, stopové meno a názov súboru na zachytenie údajov.

    Dôležité upozornenie Súbor sledovania by byť napísané na rýchle miestnej alebo zdieľané disk. Vyhnite sledovania na jednotku pomalé disku alebo siete. Tiež sa uistite, že Server spracováva stopových údajov je začiarknuté.
  4. Na Výber udalostí karta, kliknutím vyberte možnosť Zobraziť všetky udalosti a Zobraziť všetky stĺpce začiarkavacie políčka.
  5. Na Výber udalostí kartu, pridajte typy udalostí, ktoré sú uvedené v tabuľke 1 na vaše stopa.

    Okrem toho môžu obsahovať ďalšie typy udalostí, ktoré sú uvedené v tabuľke 2, ďalšie informácie. Ak používate v prostredí high-objem výroby, môže rozhodnete použiť iba udalosti v tabuľke 1, ako sú zvyčajne dostatočné na väčšine blokovanie problémov. Vrátane ďalších udalostí v tabuľke 2 môžu ľahšie rýchlo určiť zdroj problému (alebo tieto udalosti môžu byť potrebné na identifikáciu vinníkom vyhlásenie v multi-statement konaní). Však vrátane udalostí v tabuľke 2 tiež pridať na zaťaženie systému a zvýšiť veľkosť výstupu sledovania.
Tabuľka 1: Typy udalostí
Zbaliť túto tabuľkuRozbaliť túto tabuľku
PoložkyUdalosť
Chyby a upozorneniaVýnimka
Chyby a upozorneniaPozornosť
Bezpečnostný AuditAuditu Login
Bezpečnostný AuditLogout auditu
RelácieExistujúce pripojenie
Uložené procedúryRPC: spustenie
TSQLSQL:BatchStarting

Tabuľka 2: Ďalšie udalosti typy
Zbaliť túto tabuľkuRozbaliť túto tabuľku
PoložkyUdalosť
TransakcieDTCTransaction
TransakcieSQLTransaction
Uložené procedúryRPC: dokončené
TSQLSQL:BatchCompleted
Uložené procedúrySP:StmtStarting
Uložené procedúrySP:StmtCompleted

Ďalšie informácie o používaní SQL Server Profiler nájdete na server SQL Server Books Online.

Identifikácii a riešení spoločných blokovanie scenáre

Preskúmanie vyššie uvedených informácií môžete určiť príčinu Väčšina blokovanie problémov. Zvyšok tohto článku je diskusia o tom, ako tieto informácie použiť na identifikovať a vyriešiť niektoré bežné blokovanie scenáre. Tejto diskusie sa predpokladá ste použili blokovanie skripty v článku 271509 (vztiahnut? skôr) zachytiť informácie o blokovanie SPIDs a urobili Profiler stopových s podujatí opísané vyššie.

Prezeranie blokovanie skript výstup

Preskúmať SYS.sysprocesses výstup na určenie hláv blokovanie reťaze
Ak neurčíte rýchly režim pre blokovanie skripty, bude existovať sekciu názvom "SPIDs na čele blokovanie reťazcov" zobrazí SPIDs, ktoré blokujú iných SPIDs skript výstupu.
SPIDs at the head of blocking chains
Ak ste určili rýchle možnosť, môžete ešte určiť blokovanie hlavy sa pozrieme na SYS.sysprocesses výstup a po hierarchie SPID, ktoré sa vykazujú v stĺpci blokovaný.
Preskúmať SYS.sysprocesses výstupné informácie o SPIDs na čele blokovanie reťazca.
Je dôležité zhodnotiť takto SYS.sysprocesses polia:

Stav

Tento stĺpec zobrazuje stav najmä číslo SPID. Typicky, Spací stav znamená, že číslo SPID ukončil výkon a je čakanie na žiadosť predložiť iný dotaz alebo dávky. A runnable, spustené, alebo sos_scheduler_yield stav naznačuje, že číslo SPID je v súčasnosti spracovanie dotazu. V Nasledujúca tabuľka poskytuje stručné vysvetlenie rôznych stavu hodnoty.
Zbaliť túto tabuľkuRozbaliť túto tabuľku
StavZmysle
PozadieČíslo SPID je spustený pozadia úlohy, ako napríklad zisťovanie zablokovania.
SpacíČíslo SPID je momentálne neprebieha. To zvyčajne označuje, že číslo SPID je čakajú príkaz z aplikácia.
SpustenéČíslo SPID je práve spustený plánovačom.
RunnableČíslo SPID je v runnable frontu plánovača úloh a čakal na Plánovač čas.
Sos_scheduler_yieldČíslo SPID bol spustený, ale dobrovoľne prinieslo jeho čas plátok plánovačom umožniť iného SPID to acquire time Plánovač úloh.
PozastavenéČíslo SPID čaká na udalosť, ako napríklad zámku alebo západku.
Vrátenie zmienČíslo SPID je vrátenie transakcie.
DefwakeupOznačuje, že číslo SPID čaká na zdroj, ktorý je v procese bude uvoľnený. Waitresource oblasti uvádzať daný zdroj.

Open_tran

Toto pole vám povie, transakcia Úroveň vnorenia číslo SPID. Ak je hodnota väčšia ako 0, číslo SPID je v rámci otvorené transakcie a držali zámky získala akékoľvek vyhlásenie v rámci transakcie.

Lastwaittype, waittype a waittime

V lastwaittype pole je reprezentácia reťazca waittype pole, ktoré je vyhradené vnútorného binárne stĺpec. Ak waittype je 0x0000, číslo SPID nie je v súčasnosti čaká na čokoľvek a The lastwaittype hodnota udáva posledný waittype že číslo SPID mal. Ak waittype nie je nula, lastwaittype hodnota udáva aktuálne waittype o číslo SPID.

Pre stručný popis rôznych lastwaittype a waittype hodnoty, pozri nasledujúci článok Microsoft Knowledge base:
822101 Popis waittype a lastwaittype stĺpcov v tabuľke master.dbo.sysprocesses SQL Server 2000 a SQL Server 2005
Ďalšie informácie o SYS.dm_os_wait_stats, pozri SQL Server Books Online.

V waittime na určenie, ak číslo SPID je pokrok možno použiť hodnotu. Keď dotaz proti SYS.sysprocesses Tabuľka vráti hodnotu v waittime stĺpec, ktorý je menej ako waittime hodnota z predchádzajúcich dotazu z SYS.sysprocesses, to naznačuje, že predchádzajúce zámok bol nadobudnuté a uvoľní a teraz čaká na nové zámku (za predpokladu nenulová waittime). To overiť porovnaním waitresource medzi SYS.sysprocesses výstup.

Waitresource

Toto pole označuje Zdroj že číslo SPID čaká. Nasledujúca tabuľka zobrazuje bežné waitresource formáty a ich význam:
Zbaliť túto tabuľkuRozbaliť túto tabuľku
ZdrojFormátovaniePríklad
TabuľkaDatabaseID:ObjectID:IndexIDKARTA: 5:261575970:1
V tomto prípade je databáza ID 5 krčmy Ukážková databáza a objekt ID 261575970 je tituly klastrovaný index tabuľky a 1.
StránkaDatabaseID:FileID:PageIDSTRÁNKA: 5:1:104
V tomto prípade je databáza ID 5 krčmy, súboru ID 1 je primárneho súboru údajov a stránku 104 je stránka patriace do tituly Tabuľka.

Na identifikáciu Identifikácia objektu, ktorý stránky patrí k, použite príkaz DBCC stránku (dbid, identifikátor fileid, pageid, output_option) a pozrieť sa na m_objId. Napríklad:
DBCC TRACEON ( 3604 )
DBCC PAGE ( 5 , 1 , 104 , 3 )
KľúčDatabaseID:Hobt_id (Hash hodnota index kľúča)KĽÚČ: 5:72057594044284928 (3300a4f361aa)

V tomto prípade databáza ID 5 je krčmy, Hobt_ID 72057594044284928 zodpovedá non skupinový index_id 2 pre objekt Identifikácia 261575970 (tituly tabuľka). Použitie zobrazenia s sys.partitions katalóg priradiť hobt_id najmä indexu Identifikácia a Identifikácia objektu. Neexistuje žiadny spôsob, ako unhash do indexu kľúčových hash špecifické indexu kľúčové hodnoty.
RiadokDatabaseID:FileID:PageID:Slot(row)ZBAVIŤ: 5:1:104:3

V tomto prípade je databáza ID 5 krčmy, súbor ID 1 je primárneho súboru údajov, stránku 104 je stránka patriacich k tabuľke tituly a prevádzkových intervalov 3 označuje v riadku pozícii na stránke.
KompilácieDatabaseID:ObjectID [[SKOMPILOVAŤ]]ZÁLOŽKA: 5:834102012 [[SKOMPILOVAŤ]] to nie je v tabuľke Zamknúť, ale skôr skompilovať lock uloženej procedúry. Identifikátor databázy 5 je krčmy, objekt ID 834102012 je uložená procedúra usp_myprocedure. Viac informácií o blokovanie spôsobené skompilovať zámky nájdete v časti článku 263889 databázy Knowledge Base.
Ďalšie stĺpce

Zostávajúcich SYS.sysprocesses stĺpce môžu poskytnúť pohľad na koreň problému rovnako. Ich užitočnosť sa líši v závislosti od okolností problém. Pre napríklad môžete určiť, ak problém sa stane len z určitých klientov (hostname) na niektoré siete knižnice (net_library), keď posledný partie predložené číslo SPID bola (last_batch), a tak ďalej.
Preskúmať DBCC INPUTBUFFER výstup.
Pre akékoľvek SPID na vrchole blokovanie reťazca alebo s non-nulové waittype, blokovanie skript bude spúšťať DBCC INPUTBUFFER na určenie aktuálny dotaz pre toto číslo SPID.

V mnohých prípadoch je dotaz, ktorý spôsobuje zámky blokovanie ostatným používateľom konať. Avšak, ak je číslo SPID v rámci transakciu, zámky môže boli nadobudnuté predtým executed dotazom, nie ten súčasný. Preto by mali tiež zobraziť Profiler výstup pre číslo SPID, nie len inputbuffer.

Poznámka: Pretože blokovanie skript pozostáva z viacerých krokov, je možné, že číslo SPID môže zobraziť v prvej časti ako vedúci blokovanie reťazca, ale v čase DBCC INPUTBUFFER dotaz je popravený, je už Blokovanie a INPUTBUFFER nie je zajatý. Naznačuje, že blokovanie je vyriešiť sama, pre toto číslo SPID, a to môže alebo nemusí byť problém. V tomto bod, môžete buď používať rýchle verziu blokovanie skript sa pokúsiť zabezpečenie môžete zachytiť inputbuffer pred vymaže (hoci nie je stále žiadne zaručiť), alebo zobraziť Profiler údaje z tohto časového rámca zistiť, čo dotazy bol vykonávajúci číslo SPID.

Zobrazovanie údajov Profiler

Zobrazovanie údajov Profiler efektívne je mimoriadne cenný pri vyriešiť problémy s blokovaním. Najdôležitejšie si uvedomiť, je, že robíte nemajú sa pozrieť na všetko, čo vás zachytil; byť selektívne. Poskytuje Profiler schopnosti, ktoré vám pomôžu účinne zobraziť zachytené údaje. V Vlastnosti dialógové okno (na Súbor ponuky, kliknite na tlačidlo Vlastnosti), Profiler umožňuje obmedziť údaje zobrazené odstránením stĺpce údajov alebo udalostí, zoskupovanie (triedenie) podľa údajov stĺpcov a uplatňovanie filtre. Môžete vyhľadávať celý stopa alebo len určitý stĺpec pre osobitné hodnoty (na Upraviť ponuky, kliknite na tlačidlo Nájsť). Môžete tiež uložiť Profiler údajov do tabuľky servera SQL Server (na The Súbor ponuku, ukážte na Uložiť ako a potom kliknite na tlačidlo Tabuľka) a spustiť SQL dotazy proti nemu.

Dávajte pozor, aby ste si vykonať filtrovanie len na súbor predtým uloženú sledovania. Ak vykonávate tieto kroky na aktívne stopy, môžete riziko straty údajov, ktorý zachytil, pretože bol začal stopa. Uložiť aktívne sledovať do súboru alebo tabuľka najprv (na Súbor ponuky, kliknite na tlačidlo Uložiť ako) a znovu otvoriť (na Súbor ponuky, kliknite na tlačidlo Otvorené) pred pokračovaním. Pri práci na súbor uložený sledovania, Filtrovanie natrvalo neodstraňuje údaje sú odfiltrované, práve robí Zobraziť všetky údaje. Môžete pridať a odstrániť udalosti a stĺpce údajov ako potrebné pomôcť sústrediť vyhľadávania.

Čo hľadať:
  • Aké príkazy sa číslo SPID na čele blokovanie reťazca popravený v rámci súčasných transakcie?
    Filtrovať údaje sledovania pre najmä číslo SPID, ktorý je na čele blokovanie reťazca (na Súbor ponuky, kliknite na tlačidlo Vlastnosti; potom na Filtre kartu Uveďte hodnotu SPID). Potom môžete preskúmať a príkazy to uskutočnila do času bolo blokovanie iné čísla SPID. Ak zahrniete Transakcia udalostí, môžete ľahko identifikujú keď transakcia bola zahájená. V opačnom prípade môžete vyhľadávať Text stĺpec pre BEGIN, SAVE, COMMIT, alebo ZROLUJE TRANSAKCIU operácie. Použitie open_tran hodnota zo sysprocesses Tabuľka na zabezpečenie toho, že ste chytiť všetky transakcie udalosti. Vedomím príkazy popravený a kontext transakcie vám umožní určiť, prečo číslo SPID je držiteľom zámky.

    Pamätajte si, že môžete odstrániť udalosti a údaje stĺpce. Namiesto z pohľadu na oboch začína a dokončená udalostí, vyberte jeden. Ak blokovanie SPIDs nie sú uložené procedúry, odstrániťPS: spustenie alebo PS: dokončené udalostí; The SQLBatch a RPC udalostí sa zobrazia volanie procedúry. Iba zobraziť SP udalostí pri potrebujete zobraziť úroveň podrobnosti.
  • Čo je trvanie dotazy na SPIDs na čele blokovanie reťaze?
    Ak ste zahŕňajú ukončených udalosti vyššie, Trvanie stĺpec zobrazí čas realizácie dotazu. To vám pomôže určite dlho-bežiaci dotazov, ktoré sú príčinou blokovanie. Určiť, prečo dotaz pracuje pomalšie, zobrazenie CPU, Čítať, a Píše stĺpce, ako aj Vykonávania plánu udalosť.

Categorizing bežné blokovanie scenáre

Nižšie uvedená tabuľka mapy spoločných príznaky na ich pravdepodobného príčiny. Číslo uvedené v Scenár stĺpec zodpovedá číslo v „spoločnej blokovanie Scenáre a rezolúcií"sekcii tohto článku nižšie. V Waittype, Open_Tran, a Stav stĺpce označovať sysprocesses information. V Rieši? stĺpec udáva, či sa zablokovanie vyrieši na jeho vlastné.

Zbaliť túto tabuľkuRozbaliť túto tabuľku
ScenárWaittypeOpen_TranStavRieši?Iné Príznaky
1Non-nulové>= 0runnableÁno, keď dotaz dokončí.Physical_IO, CPU a/alebo Memusage stĺpce budú časom narastať. Bude trvanie dotazu vysoká, keď ukončené.
20x0000> 0Spacínie ale môže byť zabitý SPID.Pozornosť signál môže vidieť v Profiler Vyskytla sa stopa na toto číslo SPID, uvádzajúce dotaz timeout alebo zrušiť.
30x0000> = 0runnableNie. Neodstráni kým klienta privolanie všetky riadky alebo zavrie pripojenie. Číslo SPID môžete byť zabitý, ale to môže trvať až 30 sekúnd.Ak open_tran = 0, a číslo SPID vlastní zámky, zatiaľ čo transakcie izolácie úrovni je predvolené (ČÍTAJ COMMMITTED), je to pravdepodobné príčiny.
4Líši> = 0runnableNie. Neodstráni kým klienta zruší dotazy alebo zavrie pripojenie. Čísla SPID môže byť zabitý, ale môže trvať až 30 sekúnd.V hostname stĺpec v sysprocesses pre číslo SPID na čele blokovanie reťazca budú rovnaké ako jeden z SPID je blokovanie.
50x0000> 0vrátenie zmienÁno.An pozornosť signál môže vidieť v stopových Profiler pre toto číslo SPID, uvádzajúce časový limit pre dotaz alebo zrušiť došlo alebo jednoducho vrátiť späť údaj bol vydané.
60x0000> 0SpacíNakoniec. Keď systém Windows NT Určuje reláciu je žiadne dlhšie aktívny, server SQL Server pripojenie bude rozbité.V last_batch hodnota v sysprocesses je oveľa skôr ako aktuálny čas.

Bežné scenáre blokovanie a uznesenia

Scenáre uvedené nižšie budú mať uvedené ukazovatele. vo vyššie spomínanej tabuľke. Táto časť poskytuje ďalšie podrobnosti, ak je to uplatniteľné, rovnako ako cesty k rozlíšenie.
  1. Blokovanie spôsobené bežne spustený dotaz s dlhú dobu výkonu

    Rozlíšenie:
    Riešenie tohto typu blokovanie problém je pozrieť sa na spôsobov, ako optimalizovať dotaz. Skutočne, táto trieda blokovanie problém môže len byť problému s výkonom a vyžadujú vykonávať ho ako také. Informácie na riešenie problémov špecifických pomalé spustený dotaz, nájdete v nasledovnom článku databázy Microsoft Knowledge Base:
    243589 Riešenie problémov s pomalý chod dotazy na SQL Server 7.0 alebo novších verziách
    Pre celkové uplatňovanie výkon riešenie problémov, pozri nasledujúci článok databázy Knowledge Base:
    224587 AKO: Riešenie uplatňovanie výkonu s SQL Server
    Ďalšie informácie nájdete v téme Sledovaním a ladením How-to témy výkonu SQL Server 2008 Books Online tému na nasledovnej webovej lokalite MSDN:
    http://msdn.Microsoft.com/en-us/library/ms187830.aspx
    Ak máte dlho-bežiaci dotaz, ktorý je blokovanie ostatní používatelia a nemôžu byť optimalizované, zvážte presunutie ho z databázy OLTP prostredie na pomocný systém rozhodovania.
  2. Blokovanie spôsobené spacie SPID, ktoré stratilo sledovať úroveň vnorenia transakcie

    Tento typ blokovanie často identifikovaný číslo SPID ktorá je spí alebo čaká príkaz, ešte ktorých transakcie úroveň (@@ TRANCOUNT, open_tran z sysprocesses) je väčšia ako nula. Tento problém môže nastať ak uplatňovanie skúsenosti časový limit dotaz alebo otázky zrušiť bez tiež vydania požadovaný počet vrátenie a/alebo COMMIT vyhlásenia. Číslo SPID, kedy dostáva časový limit pre dotaz alebo zrušiť, ukončí aktuálny dotaz a dávka, ale automaticky vrátiť späť alebo potvrďte transakciu. Aplikácia je zodpovedný za to, ako SQL Server nemôže predpokladať, že celá transakcia musí byť vrátená späť jednoducho kvôli jeden dotaz, pričom zrušené. Dotaz časový limit alebo zrušiť sa zobrazia ako udalosť pozornosť signál pre SPID v Profiler sledovania.

    To dokázať, vydať nasledujúce jednoduchý dotaz z analyzátor dotazu:

    BEGIN TRAN 
    SELECT * FROM SYSOBJECTS S1, SYSOBJECTS S2
    
    -- Issue this after canceling query
    SELECT @@TRANCOUNT
    ROLLBACK TRAN
    						
    Počas vykonávania dotaz kliknite na červené Zrušiť tlačidlo. Po dotaz je zrušený, vyberte @@ TRANCOUNT označuje že úroveň vnorenia transakcia je jeden. To bolo odstrániť alebo aktualizácia dotazu, alebo boli použité HOLDLOCK na vybrať, všetky zámky nadobudnuté by stále konajú. Aj s dotaz vyššie, ak iný dotaz získala a konať zámky skôr v transakcii, sú stále budú konať keď vyššie Vyberte bol zrušený.

    Uznesenia:

    • Žiadosti riadne spravovať transakcie vnorenia úrovne, alebo môže spôsobiť blokovanie problém po zrušení dotaz týmto spôsobom. To možno vykonať niekoľkými spôsobmi:
      1. V obslužný program chýb klientskej aplikácie, predložiť ak @@ TRANCOUNT > 0 vrátenie TRAN nasledujúce chyby, aj keď klientska aplikácia neverí, transakcia je otvorený. Je to potrebné, pretože uloženej procedúry nazýva počas šarže mohli začali transakcie bez vedomia klientskej aplikácie. Poznámka že určité podmienky, ako napríklad zrušenie dotaz, zabrániť vykonávajúci postup minulosti aktuálnom vyhlásení, takže aj keď postup má logika skontrolovať či @@ CHYBA <> 0 a prerušenie transakcie, tento kód vrátenie nebude popravený v takýchto prípadoch.
      2. Použitie SET XACT_ABORT ON pre pripojenie, alebo v ktorejkoľvek uložené postupy, ktoré začínajú transakcií a nie sú vyčistenie nasledujúce chyba. V prípade ich chyba spustenia, toto nastavenie bude prerušiť akékoľvek otvorené transakcie a návrat kontrolu klientovi. Poznámka že T-SQL výkazy nasledujúceho výkazu, ktorý spôsobil chybu sa nevykoná.
      3. Ak združovanie pripojení používa v aplikácia, ktorá otvára pripojenie a prevádzkuje malý počet dotazov pred uvoľnenie pripojenie späť na bazén, ako sú on-line prihlášky, dočasne deaktivovať združovanie môže pomôcť zmierniť tento problém až klientská aplikácia je modifikovaný primerane zvládnuť chyby. Autor: vypnutie, združovanie pripojení, uvoľňujúce pripojenie spôsobí fyzickú logout SQL Server pripojenia, výsledkom server koľajových späť akékoľvek Otvorte transakcií.
      4. Ak je zapnuté združovanie pripojení a cieľový server je SQL Server 2000, inovácia klientskeho počítača na MDAC 2.6 alebo novšia, môže byť prospešné. Túto verziu súčasti MDAC pridáva kód ovládač ODBC a poskytovateľa OLE DB tak, že pripojenie by byť "reset" predtým sa opätovne používa. Volanie sp_reset_connection zruší akékoľvek iniciované servera transakcií (DTC transakcie iniciované klientská aplikácia sú neovplyvní), obnoví Predvolená databáza, nastaviť možnosti a podobne. Poznámka: pripojenie nevynulovali dovtedy, kým sa opätovne používa z fondu pripojení Takže je možné, že používateľ mohol otvoriť transakciu a potom uvoľnite pripojenie na pripojenie bazén, ale môže sa nemôžu znova použiť pre niekoľko sekúnd, počas ktorých transakcie by zostať otvorená. Ak pripojenie sa nesmú opätovne použiť, transakcia bude zrušené keď pripojenie časový limit uplynul a je odstránený z fondu pripojení. Preto je optimálne pre klienta uplatňovanie prerušiť transakcie v ich obslužný program chýb alebo používať SET XACT_ABORT ON sa zabránilo tohto potenciálu oneskorenia.
    • Skutočne, táto trieda blokovanie problém môže byť výkon problém, a vyžadujú vykonávať ho ako také. Ak dotaz doba vykonávania môže byť znížená, dotaz timeout alebo zrušiť by nedošlo. Je dôležité, aby žiadosti mohli zvládnuť timeout alebo zrušiť scenáre budú vznikať, ale môžu tiež využívať skúmaní výkon dotazu.
  3. Blokovanie spôsobené SPID ktorých zodpovedajúce klientska aplikácia urobil nie Fetch všetky riadky výsledok ukončenia

    Po odoslaní dotaz na server, všetky žiadosti okamžite fetch všetky riadky výsledok dokončenie. Ak žiadosť nie fetch všetky riadky výsledok, zámky môže byť ponechaná na tabuľkách blokovanie iné používatelia. Ak používate aplikáciu, ktorá transparentne tvrdí SQL vyhlásenia na server, žiadosti sa musia zabehnutý všetky riadky výsledok. Ak to nezahŕňa (a ak to nie je možné konfigurovať tak urobiť), môže byť schopný blokovanie problému. Aby sa predišlo problémom, môžete obmedziť zle správal aplikácie správa podáva alebo rozhodnutie podporu databáza.

    Rozlíšenie:

    Žiadosť musí byť re-písomné sehnat všetky riadky výsledok dokončenie.
  4. Blokovanie spôsobené distribuovaných zablokovanie klient/Server

    Na rozdiel od konvenčných slepej uličky, distribuované zablokovanie nie je zistiteľný pomocou správcu RDBMS zamknúť. Je to spôsobené tým, že iba jedna zdrojov začlenených v mŕtvom je zámok SQL Server. V druhej strane mŕtvom je na úrovni aplikácie klienta, nad ktoré SQL Server nemá žiadnu kontrolu. Nasledujú dva príklady ako to môže nastať, a možné spôsoby aplikácie môžete vyhnúť.

    1. Klient/Server distribuované zablokovanie s jedného klienta Vlákno
      Ak klient má viacero otvorených spojení a jednotného vlákno vykonanie nasledujúcich distribuovaných môže zablokovali. Pre krátkosť, pojem "dbproc", používa sa tu odkazuje na pripojenie štruktúru klienta.

       SPID1------blocked on lock------->SPID2
        /\                         (waiting to write results         
        |                           back to client)
        |                                 |
        |                                 |                      Server side
        | ================================|==================================
        |     <-- single thread -->       |                      Client side
        |                                 \/ 
       dbproc1   <-------------------   dbproc2
       (waiting to fetch             (effectively blocked on dbproc1, awaiting
        next row)                     single thread of execution to run)
      								
      V prípade uvedené vyššie, má jedného klienta aplikácie vlákno dve otvorených spojení. Asynchrónne tvrdí SQL prevádzka na dbproc1. To znamená, nečaká na hovor vrátiť pred pokračovaním. V žiadosť potom tvrdí inej SQL operácie na dbproc2 a čaká výsledky začať spracovanie vrátených údajov. Keď údaje začína vraciam (najprv odpovedá ktorýkoľvek dbproc--predpokladať, je to dbproc1), procesy na ukončenie všetkých údajov vrátených v tejto dbproc. Privolanie výsledky z dbproc1 až SPID1 dostane blokované na zámku v držbe SPID2 (pretože dve dotazy sú spustený asynchrónne na serveri). Na tomto mieste bude dbproc1 počkať po neurčitú dobu pre viac údajov. SPID2 nie je blokovaný na zámku, ale snaží sa odoslať údaje do jeho klienta, dbproc2. Avšak, dbproc2 efektívne zablokovaný na dbproc1 vo vrstve aplikácie ako jednom vlákne vykonávania pre žiadosť sa používa v dbproc1. Výsledkom tohto zablokovanie SQL Server nie je možné zistiť alebo vyriešiť, pretože iba jeden zdrojov začlenených SQL Server prostriedku.
    2. Klient/Server distribuované zablokovanie vláknom za Pripojenie

      Dokonca aj vtedy, ak samostatné vlákno existuje pre každé pripojenie na klient, odchýlku v tomto distribuované zablokovanie môžu stále vyskytovať ako zobrazené takto.

      SPID1------blocked on lock-------->SPID2
        /\                         (waiting on net write)        Server side
        |                                 |
        |                                 |
        | INSERT                          |SELECT
        | ================================|==================================
        |     <-- thread per dbproc -->   |                      Client side
        |                                 \/ 
       dbproc1   <-----data row-------   dbproc2
       (waiting on                     (blocked on dbproc1, waiting for it
        insert)                         to read the row from its buffer)
      								
      Tento prípad je podobný príklad A, okrem dbproc2 a SPID2 sú spustený príkaz SELECT na vykonávajúci riadok-na-na-time spracovanie a odovzdanie každý riadok prostredníctvom medzipamäte na dbproc1 pre vložiť AKTUALIZOVAŤ alebo odstrániť vyhlásenie o tej istej tabuľke. Nakoniec, SPID1 (vykonávajúci INSERT, UPDATE alebo DELETE) zablokuje na zámku v držbe SPID2 (vykonávajú vyberte). SPID2 píše riadka výsledok pre klienta dbproc2. Dbproc2 potom snaží sa preniesť riadok v tlmivom roztoku na dbproc1, ale zistí dbproc1 je zaneprázdnený (to je zablokovaná a čaká na SPID1 dokončiť aktuálnu vložiť, ktorá je zablokovaný na SPID2). Na tomto mieste, dbproc2 je blokovaná aplikačná vrstva Autor: dbproc1 ktorých SPID (SPID1) je blokovaný na úrovni databázy SPID2. Opäť, Výsledkom tohto zablokovania, ktorý server SQL Server nemôže zistiť alebo vyriešiť pretože iba jeden z zdrojov začlenených je zdroj servera SQL Server.
    Oba príklady a a b sú základných otázok vývojári aplikácií musí byť vedomí. Musí kód aplikácie zvládnuť tieto prípady primerane.

    Uznesenia:

    Dve spoľahlivé riešenia sú používanie buď dotazu časový limit alebo viazaný pripojenia.

    • Dotaz Timeout
      Ak bol dotaz timeout za predpokladu, ak nastane distribuovaných zablokovanie, bude zlomkovú keď potom časový limit deje. Pozri DB knižnice alebo ODBC dokumentáciu ďalšie informácie pomocou dotazu timeout.
    • Viazané pripojenia
      Táto funkcia umožňuje klientom majú viacnásobné pripojenia k ich naviažte do jediná transakcia priestoru, tak pripojenia Neblokujte navzájom. Ďalšie informácie nájdete v časti používanie" Viazané pripojenia"tému v SQL Server 7.0 Books Online.
  5. Blokovanie spôsobené SPID, že je v "Zlatý" alebo vrátenie, štát

    Údaje modifikácia dotazu, ktorý je zabitý, alebo zrušená mimo s používateľom definované transakciu, bude byť vrátená späť. Môže sa to taktiež stať ako vedľajší účinok klientsky počítač reštartovať a jeho relácie siete odpojenie. Podobne sa bude valcované dotaz vybrané ako obeť zablokovanie späť. Modifikácia dotazu údaje často nemôže byť vrátená späť rýchlejšie ako zmeny boli pôvodne uplatnené. Napríklad, ak odstrániť, vložiť alebo aktualizovať vyhlásenie bol spustený na hodinu, by mohla trvať najmenej hodinu na valec späť. To je očakávané správanie, pretože zmeny musia byť úplne vrátená späť, alebo by bolo kvalifikované a fyzickej integrity v databáze ohrozená. Pretože toto musí nastať, SQL Server značiek SPID v "golden" alebo vrátenie štátu (čo znamená, že nemôže byť zabitý alebo vybraté ako zablokovanie obeť). To identifikovať často pozorovať výstup sp_who, ktoré môže naznačovať príkaz vrátiť späť. V Stav stĺpec SYS.sysprocesses bude uvádzať ROLLBACK stav, ktoré sa premietnu do sp_who výstup alebo SQL Server Management Studio činnosť monitora.
    Rozlíšenie:

    Musíte počkať SPID dokončiť koľajových späť zmeny, ktoré boli vykonané.

    Ak server je vypnúť uprostred Táto operácia databáza bude v režime obnovenia po reštartovaní, a to budú neprístupné až do spracovania všetkých otvorených transakcií. Spustenie zhodnotenie berie v podstate rovnaké množstvo času na jednu transakciu ako run-time zhodnocovanie a databázy je neprístupný počas tohto obdobia. Teda, núti server nadol na opravu SPID v štáte vrátenie budú často kontraproduktívne.

    Chcete predísť tejto situácii, nemôžu vykonávať veľké dávkové INSERT, UPDATE alebo DELETE operácie počas rušné hodiny na databázy OLTP systémoch. Ak je to možné, vykonať takýmito operáciami Nízka aktivita v obdobiach.
  6. Blokovanie spôsobené osamotená pripojenie

    Ak klient aplikácie pasce alebo klienta Pracovná stanica nereštartuje, relácie siete na server nemusí byť okamžite zrušené za niektorých podmienok. Z pohľadu servera, Klient sa stále zdá byť prítomní a akékoľvek zámky nadobudnuté môže byť ešte zachovaný. Ďalšie informácie získate po kliknutí na nasledujúce číslo článku databázy Microsoft Knowledge Base:
    137983Riešenie problémov s osamotená pripojenia v SQL Server

    Rozlíšenie:

    Ak žiadosti klienta odpojila bez vhodne vyčistenie svojich zdrojov, môžete ho ukončiť číslo SPID pomocou príkaz ZABIŤ. Príkaz ZABIŤ trvá SPID hodnotu ako vstup. Napríklad, zabiť SPID 9, jednoducho zadajte nasledujúci príkaz:

    KILL 9
    						

    Poznámka: Príkaz ZABIŤ môže trvať až 30 sekúnd na dokončenie náležite na interval medzi kontrolami pre príkaz ZABIŤ.

Uplatňovanie zapojenie blokovanie problémy

Môžu existovať tendenciu zameriavať na server-bočné ladenie a platforma otázky, keď čelia blokovanie problému. Avšak, to však obyčajne viesť k rozlíšenie a schopné absorbovať času a energie lepšie zamerané na preskúmanie klientsku aplikáciu a dotazy tvrdí. Nezáleží na tom, čo úroveň viditeľnosti zobrazeným v aplikácii týkajúce sa databáza vyžaduje bytosť vyrobené, blokovanie problém napriek často vyžaduje oboch inšpekcie presné príkazy SQL predložilo žiadosť a aplikácie presné správanie týkajúce sa dotaz zrušenia, pripojenie riadenie, načítanie všetky riadky výsledok, a tak ďalej. Ak nástroj rozvoja neumožňuje explicitné kontrolu nad pripojenie riadenie, dotaz zrušenie, dotaz timeout, výsledok Načítanie a tak ďalej, blokovanie problémy možno minim?lneho. Tento potenciál mali by sa podrobne preskúmať pred výberom aplikácie vývojový nástroj na SQL Server, najmä pre dôležitých obchodných databázy OLTP prostrediach.

Je to životne dôležité, že veľká pozornosť uplatniť počas projektu a konštrukcie fázy databáza a uplatňovanie. Najmä resource spotreba, izolácia úroveň a dĺžka dráhy transakciu sa má vyhodnotiť každý dotaz. Každý dotaz a transakcie by mali ako ľahké ako možné. dobrý pripojenie riadenie disciplíny musí vykonávať. Ak sa tak nestalo, je možné, že uplatňovanie môže objaviť mať prijateľný výkon na nízkej počet užívateľov, ale výkon sa môžu rozkladať významne ako číslo používatelia stupníc smerom nahor.

S riadne uplatňovanie a návrh dotazu, Microsoft SQL Server je schopná podporovať mnoho tisíc simultánne používateľov na jednom serveri, s malou blokovanie.

Vlastnosti

ID článku: 224453 - Posledná kontrola: 21. októbra 2011 - Revízia: 2.0
Informácie v tomto článku sa týkajú nasledujúcich produktov:
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL 2005 Server Enterprise
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2008 Developer
  • Microsoft SQL Server 2008 Enterprise
  • Microsoft SQL Server 2008 Standard
  • Microsoft SQL Server 2008 Workgroup
  • Microsoft SQL Server 2000 Developer Edition
  • Microsoft SQL Server 2000 Enterprise Edition
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 7.0 Standard Edition
  • Microsoft SQL Server 2008 R2 Developer
  • Microsoft SQL Server 2008 R2 Enterprise
  • Microsoft SQL Server 2008 R2 Standard
  • Microsoft SQL Server 2008 R2 Workgroup
Kľúčové slová: 
kbsqlsetup kbhowto kbtshoot kbexpertiseinter kbinfo kbmt KB224453 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:224453

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