Momentálne ste offline a čaká sa, kým sa znova pripojíte na internet

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

DÔLEŽITÉ: Tento článok je preložený pomocou softvéru na strojový preklad od spoločnosti Microsoft a možno ho opraviť prostredníctvom technológie Community Translation Framework (CTF). Microsoft ponúka strojovo preložené články, články upravené komunitou aj články preložené prekladateľmi, aby zabezpečil prístup ku všetkým článkom databázy Knowledge Base vo viacerých jazykoch. Strojovo preložené články aj upravené články môžu obsahovať chyby týkajúce sa slovnej zásoby, syntaxe alebo gramatiky. Microsoft nenesie zodpovednosť za akékoľvek nepresnosti, chyby alebo škody spôsobené neprávnym prekladom obsahu alebo jeho použitím zo strany našich zákazníkov. Ďalšie informácie o technológii CTF nájdete na lokalite http://support.microsoft.com/gp/machine-translation-corrections/sk.

224453
Súhrn
V tomto článku sa pojem "pripojenie" odkazuje na jednej 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 nazýva proces, hoci nie je samostatný proces kontexte v súlade s bežným. Skôr, každú SPID pozostáva zo servera zdrojov a dátové štruktúry potrebné na vybavenie požiadavky jediného pripojenia z daného klienta. Jediný klientska aplikácia môže mať pripojenia. Z pohľadu servera 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 klientske 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.
Ďalšie informácie
Blokovanie je nevyhnutná vlastnosť všetky relačné systém riadenia relačných databáz (RDBMS) s zámok-založené súbežnosti. Na serveri SQL Server blokovanie nastane, keď jeden SPID vlastní zámok na špecifických zdrojov a druhý číslo SPID sa pokúsi získať konfliktné typu uzamknutia na rovnakom prostriedku. Časovom rámci, pre ktoré prvé SPID uzamknutie prostriedkov je zvyčajne veľmi malú veľkosť. Pri vydanie zámok, druhé pripojenie je zadarmo získať jeho vlastný zámok na prostriedku a pokračovať v spracovaní. Toto správanie je normálne a môže sa stať niekoľkokrát v priebehu dňa s viditeľný vplyv na výkon systému.

Trvanie a transakcie kontexte dotaz určiť, ako dlho jeho locks prebieha, a tým ich vplyv na ďalšie otázky. Dotaz sa nevykoná v rámci transakcie (a žiadne zamknúť tipy používajú), locks príkazoch SELECT sa uskutoční len na prostriedku pri skutočne sa číta, nie na trvanie dotaz. Pre INSERT, UPDATE a odstrániť výkazy locks prebiehajú počas dotaz na konzistentnosť údajov a umožniť dotaz na vrátená späť, ak je to potrebné.

Pre dotazy v rámci transakciu, trvanie pre ktoré locks držia určuje typ dotazu, transakcia izolácia úrovni, a či zamknúť tipy používajú v dotaze. 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ý stroj
  • Prispôsobenie uzamknutie a riadok verzií
  • Zámok režimy
  • Zámok kompatibility
  • Riadok verzií-založené izolácia úrovne v databázový stroj
  • Kontrolu transakcií (databázový nástroj)
Keď blokovania a blokovanie zvýšenie k bodu tam, kde je negatívny vplyv na výkon systému, je zvyčajne niektorý z nasledujúcich dôvodov:
  • Číslo SPID vlastní locks súbor prostriedkov pre extendedperiod času pred ich vydaním. Tento typ blokovanie rieši itselfover čas, ale môže spôsobiť výkonu.
  • SPID vlastní zámky na množinu zdrojov a nikdy releasesthem. Tento typ blokovanie nevyrieši sama a zabraňuje prístupu k prostriedkom theaffected natrvalo.
V prvom scenári vyššie, blokovanie problém rieši samotnom časom SPID vydaní locks. Vš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ť.

Zhromažďovanie blokovanie informácie

Čeliť ťažké blokovanie problémov, 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 čase, čo vedie k celkový obraz o problém. Popis ako sledovať, blokovanie s SQL skripty, nájdete v nasledujúcich článkoch databázy Microsoft Knowledge Base:
271509 Ako sledovať, blokovanie SQL Server 2005 a SQL Server 2000
Skripty v tomto článku sa vykonať nasledujúce úlohy. Ak je to možné, je uvedený postup získania tejto informácie z SQL Server Management Studio.
  1. Identifikáciu SPID (identifikácia relácie) vedúci blokovanie reťazca a príkazu SQL.
    Popri pomocou skriptov v spomenuté Knowledge Base, môžete určiť vedúci blokovanie reťazca pomocou funkcie, ktoré sú k dispozícii prostredníctvom SQL Server Management Studio. Na použite jeden z nasledujúcich postupov:
    • Kliknite pravým tlačidlom myši na objekt servera, rozbaľte položku správy, rozbaľte Štandardné správya kliknite na tlačidlo činnosti – všetky blokovanie transakcie. Táto zostava zobrazuje transakcie vedúci blokovanie reťazca. Ak rozbalíte transakcie, v zostave sa zobrazia transakcií, ktoré sú blokované hlava transakcie. 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ý spoločnosť SPID.</spid>
  2. Nájsť úroveň vnorenia transakcie a proces stav blokovania SPID.
    Transakcia Úroveň vnorenia číslo SPID je k dispozícii v the@@TRANCOUNT globálnu premennú. Však to môže stanoviť z externých theSPID dotaze sysprocesses tabuľka takto:

    SELECT open_tran FROM master.sys.sysprocesses WHERE SPID=<blocking SPID number>go						
    Hodnota je hodnota @@TRANCOUNT SPID. Táto showsthe transakcia Úroveň vnorenia pre blokovanie SPID, ktoré zasa explainwhy je držiteľom locks. Napríklad, ak je hodnota väčšia ako nula, theSPID je uprostred transakcie (v prípade očakáva sa, že itretains určité uzamkne ho získal, v závislosti od transakcie isolationlevel).

    Môžete tiež skontrolovať, či sa všetky dlhodobé otvoriť transactionexists v databáze pomocou DBCC OPENTRANdatabase_name.

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

Okrem vyššie uvedených informácií je často potrebné zachytiť Profiler sledovania činností na serveri, aby dôkladne preskúmať blokovanie problém na serveri SQL Server. Ak SPID vykonáva viaceré vyhlásenia transakcie, len posledný statementthat bola odoslaná zobrazí správa, vstupnej medzipamäte alebo activity monitor výstup. Však jeden z predchádzajúcich príkazov môže byť dôvod locks stále uskladnené. Profiler sledovania vám umožní Zobraziť všetky príkazy, ktoré vykonávajú 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. V ponuke súbor ukážte na položku novéa kliknite na tlačidlo sledovania.
  3. Na karte Všeobecné zadajte názov stopy a názov súboru na zachytenie údajov.

    Dôležité upozornenie: Súbor sledovania by zápis disk rýchlo lokálne alebo zdieľané. Vyhnite sledovania na jednotku pomalé disku alebo v sieti. Tiež uistite sa, že Server spracováva sledovania údajov je začiarknuté.
  4. Na Výber udalostí karta, kliknutím vyberte všetky 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 zahŕňať ď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é vyhlásenie príčinou viacerých vyhlásení postupu). 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í
PoložkyUdalosť
Chyby a upozorneniaVýnimka
Chyby a upozorneniaPozornosť
Bezpečnostný AuditPrihlásenie auditu
Bezpečnostný AuditOdhlásiť auditu
RelácieExistujúce pripojenie
Uložené procedúryRPC: spustenie
TSQLSQL:BatchStarting

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

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

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

Preskúmaním 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 používať tieto informácie 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 sledovania udalostí vyššie.

Zobrazenie blokovanie skript výstup

Preskúmať sys.sysprocesses výstupné určiť vedúci blokovanie reťazca
Ak neurčíte rýchly režim pre blokovanie skripty, bude existovať sekciu názvom "SPIDs vedúci blokovanie reťazca" thatlists 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ť theblocking vedúcich na sys.sysprocesses výstup a po hierarchie SPID zobrazená v stĺpci blokovaný.
Preskúmať sys.sysprocesses výstupné informácie o SPIDs vedúci blokovanie reťazca.
Je dôležité posúdiť takto sys.sysprocesses polia:

Stav

Tento stĺpec zobrazuje stav najmä číslo SPID. Zvyčajne spánku stav znamená, že SPID ukončil výkon a čaká na aplikáciu iný dotaz alebo dávky. Spustiteľný, spusteniaalebo sos_scheduler_yield stav naznačuje, že SPID je v súčasnosti spracovanie dotazu. Nasledujúca tabuľka poskytuje stručné vysvetlenie rôznych stavu hodnoty.
StavVýznam
PozadiaSPID je spustený pozadia úlohy, ako napríklad zisťovanie zablokovania.
SpánokČíslo SPID je momentálne neprebieha. Zvyčajne to znamená, že SPID je čakajú príkaz z aplikácia.
SystémČíslo SPID je práve spustený Plánovačom.
SpustiteľnýČíslo SPID je spustiteľný frontu plánovača úloh a čakal na Plánovač čas.
Sos_scheduler_yieldČíslo SPID bol spustený, ale dobrovoľne prinieslo jeho časový úsek plánovačom umožniť iného SPID to acquire time Plánovač úloh.
PrerušenéČíslo SPID čaká na udalosť, napríklad zámok alebo zámok.
Vrátenie zmienČíslo SPID je vrátenie transakcie.
DefwakeupOznačuje, že SPID čaká na zdroj, ktorý je práve uvoľnený. Waitresource oblasti uvádzať daný zdroj.

Open_tran

Toto pole obsahuje transakcia Úroveň vnorenia číslo SPID. Ak je hodnota väčšia než 0, SPID je otvorené transakcie a môžu viesť locks získala akékoľvek vyhlásenie v rámci transakcie.

Lastwaittype a waittype waittime

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

Stručný popis rôznych lastwaittype a waittype hodnoty, nájdete v nasledujúcom článku databázy Microsoft Knowledge base:
822101 Popis waittype a lastwaittype stĺpce v tabuľke master.dbo.sysprocesses SQL Server 2000 a SQL Server 2005
Ďalšie informácie o sys.dm_os_wait_statsnájdete SQL Server Books Online.

Waittime hodnota možno určiť, ak číslo SPID je pokrok. 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, znamená to, že predchádzajúce zámok bol získali vydaný a je teraz čaká na nový zámok (za predpokladu nenulová waittime). To overiť porovnaním waitresource medzi sys.sysprocesses výstup.

Waitresource

Toto pole označuje zdroj že číslo SPID čaká na. Nasledujúca tabuľka zobrazuje bežné waitresource formáty a ich význam:
ProstriedokFormátPríklad
TabuľkaDatabaseID:ObjectID:IndexIDKARTA: 5:261575970:1
V tomto prípade je databáza ID 5 krčmy ukážkovú databázu objekt ID 261575970 je tituly tabuľka a Klastrový index je 1.
StránkaDatabaseID:FileID:PageIDSTRÁNKA: 5:1:104
V tomto prípade je databáza ID 5 krčmy, súbor 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 súboru vlastnosti, pageid, output_option) a pozrite sa na m_objId. Napríklad:
DBCC TRACEON ( 3604 )DBCC PAGE ( 5 , 1 , 104 , 3 )
KľúčDatabaseID:Hobt_id (hodnota Hash index kľúča)KĽÚČ: 5:72057594044284928 (3300a4f361aa)

V tomto prípade je databáza ID 5 krčmy, Hobt_ID 72057594044284928 zodpovedá bez skupinový index_id 2 objekt ID 261575970 (nadpis tabuľky). Použite na zobrazenie zobrazenia s sys.partitions katalóg priradiť hobt_id najmä indexu Identifikácia a Identifikácia objektu. Neexistuje žiadny spôsob, ako unhash indexu kľúčových hash špecifické indexu kľúčové hodnoty.
RiadokDatabaseID:FileID:PageID:Slot(row)HLAVNÝ SERVER RELATÍVNYCH ID: 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 patriace do tituly tabuľka a slot 3 označuje v riadku pozícii na stránke.
KompiláciaDatabaseID:ObjectID [kompilácia]KARTA: 5:834102012 [kompilácia] nejde zamknúť tabuľku, ale skôr kompilácia zámok 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ť locks nájdete v č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 použiteľnosť sa líši v závislosti od okolností problém. Napríklad môžete zistiť, ak sa problém vyskytuje len z určitých klientov (hostname) na niektoré siete knižnice (net_library), keď posledná dávka používateľa SPID bola (last_batch), a tak ďalej.
Preskúmať DBCC INPUTBUFFER výstup.
Pre akékoľvek SPID vedúci blokovanie reťazca alebo anon-nulové waittype, blokovanie skript bude spúšťať DBCC INPUTBUFFER todetermine aktuálny dotaz pre toto číslo SPID.

V mnohých prípadoch ide spôsobuje locks vprílohe blokovanie ostatní používatelia vykonať dotaz. Ak je číslo SPID v rámci atransaction, locks môže získal predtým executed dotazom, nie je aktuálny. Preto by mal zobraziť Profiler výstup pre číslo SPID, nie len inputbuffer.

Poznámka: Pretože blokovanie skript pozostáva z viacerých krokov, je ispossible, SPID môže zobraziť v prvej časti ako vedúci blockingchain, ale v čase DBCC INPUTBUFFER dotaz je spustený, je bez longerblocking a INPUTBUFFER nie je zachytený. To znamená, že blockingis vyriešiť sama, pre toto číslo SPID, a to môže alebo nemusí byť problém. Na thispoint, môžete použiť rýchle verziu blokovanie skript aby zachytiť inputbuffer pred vymaže (hoci nie je stále noguarantee), alebo zobraziť Profiler údaje z tohto časového rámca zistiť whatqueries SPID spustení.

Zobrazovanie údajov Profiler

Zobrazovanie údajov Profiler efektívne je mimoriadne vyriešiť problémy s blokovaním. Najdôležitejšie si uvedomiť, že nemáte pozrieť všetko vzniká; byť selektívne. Poskytuje Profiler, ktoré vám pomôžu účinne Zobraziť zaznamenanom údaje. V dialógovom okne Vlastnosti (v ponuke súbor kliknite na položku Vlastnosti), Profiler umožňuje obmedziť údaje zobrazené odstránením stĺpce údajov alebo udalostí, zoskupovanie (zoradenie) podľa údajov stĺpcov a používanie filtrov. Môžete vyhľadávať celý stopa alebo len určitý stĺpec pre konkrétne hodnoty (v ponuke úpravy kliknite na tlačidlo Hľadať). Môžete tiež uložiť Profiler údajov do tabuľky servera SQL Server (v ponuke súbor ukážte na položku Uložiť ako a kliknite na tlačidlo Tabuľka) a spustiť SQL dotazy proti.

Pozor, že vykonať filtrovanie len na súbor predtým uloženú sledovania. Ak vykonáte tieto kroky na aktívne stopy, riziko straty údajov, ktoré má zachytený od spustenia sledovania. Uložiť aktívne sledovať do súboru alebo tabuľka najprv (v ponuke súbor kliknite na položku Uložiť ako) a znovu otvoriť (v ponuke súbor kliknite na tlačidlo otvorené) pred pokračovaním. Pri práci na súbor uložený sledovania, filtrovanie natrvalo neodstraňuje údaje sú filtrované, jednoducho Zobraziť všetky údaje. Môžete pridať a odstrániť udalosti a stĺpce údajov ako potrebné na zameriavanie vyhľadávania.

Čo hľadať:
  • Aké príkazy sa číslo SPID vedúci blokovanie chainexecuted v rámci súčasných transakcie?
    Filtrovanie údajov sledovania aparticular SPID, ktoré je vedúci blokovanie reťazca (v ponuke súbor kliknite na položku Vlastnosti, na karte filtre uviesť SPID). Potom môžete preskúmať a príkazy ithas vykonané predchádzajúceho času bolo blokovanie iné čísla SPID. Ak použijete theTransaction udalosti, môžete ľahko identifikovať pri transakcie.V opačnom prípade môžete vyhľadávať Text stĺpec BEGIN, SAVE, odovzdanie alebo vrátenie TRANSACTIONoperations. Použite hodnotu open_tran z sysprocesses tabuľka zabezpečiť, aby sa zachytiť všetky transakcie udalosti.Poznať príkazy vykonáva a kontext transakcie vám umožní todetermine, prečo číslo SPID je držiteľom zámky.

    Pamätajte, že môžete removeevents a údaje stĺpce. Namiesto spustenia a completedevents, vyberte jednu. Ak blokovanie SPIDs nie sú uložené procedúry, odstráňteSP: od alebo SP: dokončiť udalosti; SQLBatch a RPC udalostí sa zobrazia volanie procedúry. Iba Zobraziť SP udalostí whenyou potrebujete zobraziť úroveň podrobnosti.
  • Čo je trvanie dotazy na SPIDs headof blokovanie reťaze?
    Ak sú vyplnené udalosti vyššie, trvanie stĺpec zobrazí čas realizácie dotazu. Pomôže vám to youidentify dlho-bežiaci dotazov, ktoré sú príčinou blokovanie. Určiť, prečo thequery pracuje pomalšie, zobrazenie CPU, čítať, a píše stĺpce, ako aj Vykonávania plánu udalosť.

Kategorizovanie bežné blokovanie scenáre

Tabuľka mapy spoločných príznaky na ich pravdepodobné príčiny. Číslo uvedené v scenár stĺpec zodpovedá číslo v časti "Bežné blokovanie scenáre a riešenia" nižšie v tomto článku. Waittype, Open_Tran, a stav stĺpce označovať sysprocesses information. Odstraňuje? stĺpec udáva, či sa zablokovanie vyrieši na jeho vlastné.

ScenárWaittypeOpen_tranStavRieši?Iné príznaky
1Non-nulové> = 0spustiteľnýÁno, keď dotaz dokončí.Physical_IO, CPU alebo Memusage stĺpce budú zvyšovať. Trvanie dotazu budú po dokončení.
20x0000> 0spánokNie, ale môže byť zabitý SPID.Pozornosť signál môže vidieť v Profiler sledovania pre toto číslo SPID, uvádzajúce dotaz timeout alebo zrušiť došlo.
30x0000> = 0spustiteľnýNie. Neodstráni kým klienta presunie všetky riadky alebo zavrie pripojenie. Môže byť zabitý SPID, ale môže trvať až 30 sekúnd.Ak open_tran = 0, číslo SPID vlastní locks transakcie izolácie úrovni je predvolené (čítať COMMMITTED) a je pravdepodobne dôvod.
4Mení> = 0spustiteľnýNie. Neodstráni kým klienta zruší dotazy alebo zavrie pripojenie. SPIDs môže byť zabitý, ale môže trvať až 30 sekúnd.Hostname stĺpec v sysprocesses pre číslo SPID vedúci blokovanie reťazca budú rovnaké ako jeden z SPID je blokovanie.
50x0000> 0vrátenie zmienÁno.Pozornosť signál môže vidieť v Profiler sledovania pre toto číslo SPID, uvádzajúce dotaz timeout alebo zrušiť došlo alebo jednoducho vrátiť späť údaj bol vydaný.
60x0000> 0spánokNakoniec. Keď systém Windows NT určuje relácia už nie je aktívna, SQL Server pripojenie sa preruší.V last_batch hodnota v sysprocesses je oveľa skôr ako aktuálny čas.

Bežné blokovanie scenáre a riešenia

Scenáre nižšie bude mať vlastnosti uvedené v tabuľke. Táto časť obsahuje ďalšie informácie, prípadne, rovnako ako cesty k rozlíšenie.
  1. Blokovanie spôsobené bežne spustený dotaz s dlhú dobu výkonu

    Riešenie:
    Riešenie tohto typu blokovanie problém je pozrieť forways optimalizovať dotaz. Skutočne, táto trieda blokovanie problém môže justbe problému s výkonom a vyžadujú vykonávať ho ako také. Informácie problémov špecifických pomalé spustený dotaz, nájdete v nasledujúcom článku databázy Microsoft Knowledge Base:
    243589 Riešenie pomaly prebiehajúce dotazy SQL Server 7.0 alebo novšie verzie
    Celková aplikácia performancetroubleshooting, nájdete na nasledujúci článok databázy Knowledge Base:
    224587 POSTUP: Riešenie výkon aplikácie SQL Server
    Ďalšie informácie nájdete v téme monitorovanie výkonu a optimalizácia How-to témy SQL Server 2008 Books Online na nasledujúcej webovej lokalite MSDN: Máte dlho-bežiaci dotaz blockingother používatelia a nemôžu byť optimalizované, zvážte presunutím OLTPenvironment rozhodnutia podpora systému.
  2. Blokovanie spôsobené spacie SPID, ktoré stratilo sledovať úroveň vnorenia transakcie

    Tento typ blokovanie často identifikovaný v SPIDthat spánku alebo čaká príkaz, ešte ktorých transakcie úroveň (@@TRANCOUNT, open_tran z sysprocesses) je väčšia ako nula. Táto situácia môže nastať, ak applicationexperiences časový limit dotaz alebo otázky zrušiť bez tiež vydania therequired počet vrátenie a/alebo COMMIT vyhlásenia. Keď SPID prijme aquery timeout alebo zrušiť, sa ukončí aktuálny dotaz a dávky, butdoes automaticky vrátiť alebo potvrďte transakciu. Isresponsible aplikácií, ako SQL Server nemôže prevziať, aby celý transactionmust vráti len z jedného dotazu boli zrušené. Querytimeout alebo zrušiť sa zobrazia ako udalosť pozornosť signál pre SPID v theProfiler sledovania.

    Preukázať tohto problému nasledujúci jednoduchý queryfrom analyzátor dotazu:

    BEGIN TRAN SELECT * FROM SYSOBJECTS S1, SYSOBJECTS S2-- Issue this after canceling querySELECT @@TRANCOUNTROLLBACK TRAN						
    Počas vykonávania dotazu, kliknite na červené tlačidlo Zrušiť . Po zrušení dotazu vyberte @@TRANCOUNT indicatesthat úroveň vnorenia transakcia je jeden. To bolo odstrániť alebo UPDATEquery alebo boli použité HOLDLOCK na vybrať, všetky locks získali wouldstill uskutočniť. Aj s dotaz vyššie, ak iný dotaz získala andheld locks v transakcie, sú stále uskutoční pri aboveSELECT bola zrušená.

    Riešenia:

    • Ž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. Obslužný program chýb klientskej aplikácie, ak predloží @@TRANCOUNT > 0 vrátenie TRAN nasledujúce chyby, aj keď klientska aplikácia neverí transakcie sa otvoriť. Je to potrebné, pretože uloženej procedúry nazýva počas dávky mohli začali transakcie bez vedomia klientskej aplikácie. Poznámka že určité podmienky, napríklad zrušenie dotaz, zabrániť postup uplatňovať minulosti aktuálnom vyhlásení, takže aj keď postup má logika skontrolovať či @@ERROR <> 0 a prerušenie transakcie, tento kód vrátenie sa nespustia 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 Chyba spustenia, toto nastavenie bude prerušiť akékoľvek otvorené transakcie a návrat kontrolu klientovi. Všimnite si, ž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äť do fondu, ako sú napríklad webové aplikácie, dočasne deaktivovať združovanie môže pomôcť zmierniť tento problém až klientskej aplikácie sa mení na spracovanie chýb správne. Zakázaním združovanie uvoľnenie pripojenie spôsobí fyzickej odhlásiť SQL Server pripojenia, výsledkom server vrátiť 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šou, môže byť užitočné. Túto verziu súčasti MDAC pridáva kód ovládač ODBC a poskytovateľ pripojenia 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é klient aplikácia sú neovplyvní), obnoví predvolená databáza, nastaviť možnosti a podobne. Všimnite si, že pripojenie je nenastaví, 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 fondu, ale možno nie opätovne 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 a je odstránený z fondu pripojení. Preto je optimálne klientska aplikácia prerušiť transakcie v ich obslužný program chýb alebo používať SET XACT_ABORT ON sa tejto potenciálne oneskorenie.
    • V skutočnosti táto trieda blokovanie problém môže byť problém s výkonom aj vyžadujú vykonávať ho ako také. Ak dotaz doba vykonávania môže znížiť, dotaz timeout alebo zrušiť by nedošlo. Je dôležité, aby aplikácie mohli spracovať timeout alebo zrušiť scenáre sa vyskytne, ale môžu sa tiež využívať skúmaní výkon dotazu.
  3. Blokovanie spôsobené SPID ktorých zodpovedajúce klientska aplikácia nebol nie Fetch všetky riadky výsledok dokončenie

    Po odoslaní dotazu na server, všetky applicationsmust okamžite fetch všetky riadky výsledok ukončenia. Ak aplikácia doesnot fetch všetky riadky výsledok, locks ostať v tabuľkách blokovanie otherusers. Ak používate aplikáciu, ktorá prehľadne uvádza SQLstatements server, musíte aplikácie fetch všetky riadky výsledok. Ak itdoes nie (a ak to nie je možné nakonfigurovať na to), je možné toresolve blokovanie problém. Sa problém, môžete aby restrictpoorly aplikácie hlásenia alebo rozhodnutia supportdatabase.

    Riešenie:

    Aplikácia musí prepísal načítať všetky riadky výsledok dokončené.
  4. Blokovanie spôsobené distribuovaných Klient/Server zablokovanie

    Na rozdiel od bežných zablokovanie, distribuované deadlockis nie je možné zistiť, použitie RDBMS uzamknutie správcu. Dôvodom je skutočnosť thatonly, jeden z prostriedkov zapojených do zablokovania je zámok SQL Server. Ostatné časti zablokovania je na úrovni aplikácie klienta, ktoré SQLServer nemá žiadnu kontrolu. Uvádzame dva príklady ako to môže nastať, a možné spôsoby aplikácie môžete vyhnúť.

    1. Klient/Server distribuované zablokovanie vláknom jedného klienta
      Ak klient má viacero otvorených spojení a jednej vlákno vykonania, 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 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. Aplikácia potom uvádza inej SQL operácie na dbproc2 a čaká výsledky začať spracovanie vrátených údajov. Keď údaje začína vracať (najprv odpovedá ktorýkoľvek dbproc--prevziať, je to dbproc1), procesy na ukončenie všetkých údajov vrátených v tejto dbproc. To prináša výsledky z dbproc1 až SPID1 dostane blokované na zámok vlastní SPID2 (pretože dve dotazy sú spustený asynchrónne na serveri). V tomto bode dbproc1 neprestane čakať na ďalšie údaje. SPID2 nie je blokovaný na zámok, ale sa pokúša 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 aplikácie sa používa v dbproc1. Výsledkom tohto zablokovanie SQL Server nemôže zistiť alebo vyriešiť pretože iba jeden zdrojov SQL Server prostriedku.
    2. Klient/Server distribuované zablokovanie vláknom za pripojenie

      Aj v prípade, že samostatné vlákno existuje pre každé pripojenie na klient, zmeny v tomto distribuované zablokovanie naďalej vyskytovať uvedené 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 s cieľom riadok-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 (vykonanie INSERT, UPDATE alebo DELETE) zablokuje na zámok vlastní SPID2 (vykonávajú vyberte). SPID2 píše riadka výsledok pre klienta dbproc2. Dbproc2 potom snaží sa preniesť riadok do medzipamäte 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äť spôsobí zablokovanie SQL Server nemôže zistiť alebo vyriešiť pretože iba jeden zdrojov SQL Server prostriedku.
    Oba príklady A a B sú základných otázok vývojári thatapplication musia byť vedomí. Ich musíte kód aplikácie handlethese prípadoch správne.

    Riešenia:

    Dve spoľahlivé riešenia sú querytimeout alebo viazaný pripojenia.

    • Časový limit dotazu
      Keď dotaz timeout bola poskytnutá, ak nastane distribuovaných zablokovanie, bude prerušené 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 klientovi s viacerými pripojenia viažu transakciu miesto, takže pripojenia blokovať navzájom. Ďalšie informácie nájdete "Pomocou viazané pripojenia" tému v SQL Server 7.0 Books Online.
  5. Blokovanie spôsobené SPID v "Golden" alebo vrátenie, štát

    Úprava údajov dotazu, KILLed alebo canceledoutside používateľom definované transakcie sa vráti. To môže tiež occuras vedľajší účinok klientsky počítač reštartovať a jeho sessiondisconnecting siete. Podobne ako obeťou zablokovania dotaz bude rolledback. Úprava vyhľadávania často nemožno vrátiť späť rýchlejšie ako thechanges pôvodne použili. Napríklad, ak odstrániť, vložiť alebo UPDATEstatement bol spustený na hodinu, to môže trvať aspoň hodinu vrátiť. To je očakávané správanie, pretože zmeny musí byť completelyrolled späť alebo kvalifikované a fyzickej integrity databázy by becompromised. 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 deadlockvictim). To identifikovať často pozorovať výstup sp_who, ktoré môže naznačovať príkaz vrátiť späť. Stav stĺpec sys.sysprocesses bude uvádzať vrátiť stav, ktorý sa zobrazí v sp_who výstup alebo SQL Server Management Studio činnosť monitora.
    Riešenie:

    Musíte počkať SPID dokončiť vrátiť thechanges, ktoré boli vytvorené.

    Ak server je vypnúť uprostred tejto operácie, databáza bude v režime obnovenia po reštartovaní a itwill bude dostupná dovtedy, kým sa spracujú všetky otvorené transakcie. Startuprecovery má v podstate rovnaké množstvo času na jednu transakciu ako run-timerecovery a databázy je neprístupný počas tohto obdobia. Preto forcingthe server nadol na opravu SPID v stave vrátiť sa často becounterproductive.

    Takáto situácia, vykonať largebatch INSERT, UPDATE alebo DELETE operácie počas zaneprázdnený hodiny na databázy OLTP systémoch.Prípadne vykonať operácie počas nízkej aktivity.
  6. Blokovanie spôsobené osamotený pripojenia

    Ak klient aplikácie pasce alebo clientworkstation nereštartuje, relácie siete na server môže nie beimmediately účtovať za určitých podmienok. Z hľadiska servera theclient zobrazuje naďalej vyskytovať a všetky locks získali sa beretained. Ďalšie informácie získate po kliknutí na nasledujúce číslo článku publikovaného v databáze Microsoft Knowledge Base:
    137983 Riešenie osamotený pripojenia servera SQL Server

    Riešenie:

    Ak klient odpojený withoutappropriately vyčistenie svojich zdrojov, môžete zrušiť SPID príkazom usingthe ukončenia. Príkaz ukončenia trvá SPID hodnotu ako vstup. Napríklad, zabiť SPID 9, jednoducho zadajte nasledujúci príkaz:

    KILL 9						

    Poznámka: UKONČENIA príkazu môže trvať až 30 sekúnd dokončiť, pretože interval kontroly ukončenia príkazu.

Aplikácia zapojenie blokovanie problémy

Môžu existovať tendencia zamerať na strane servera, ladenie a platforma otázky, keď blokovanie problém. Však to obyčajne viesť k rozlíšenie a schopné absorbovať času a energie lepšie zamerané na preskúmanie klientsku aplikáciu a dotazy uvádza. Bez ohľadu na to, čo úroveň viditeľnosti zobrazeným v aplikácii týkajúce sa databáza vyžaduje vykonáva, blokovanie problém napriek často vyžaduje kontroly presné príkazy SQL, aplikácie 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 na vývoj 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 by sa podrobne preskúmať pred výberom aplikácie vývojový nástroj SQL Server, najmä pre dôležitých obchodných databázy OLTP prostrediach.

Je dôležité, že veľká pozornosť uplatniť počas projektu a konštrukcie fázy databáza a aplikácie. Konkrétne by mal byť vyhodnotený spotreby zdrojov, úroveň izolácie a transakcií cesty pre každý dotaz. Každý dotaz a transakcia by mala byť tak ľahké, ako je to možné. Dobrý pripojenie riadenie disciplíny musí vykonávať. Ak sa tak nestane, je možné, že aplikácia pravdepodobne máte prijateľné výkon na nízkej počet používateľov, ale výkon sa môžu rozkladať významne ako číslo používatelia váhy nahor.

Správne používanie a návrh dotazu, Microsoft SQL Server dokáže podporných tisíce súbežných užívateľov na jednom serveri, s malou blokovanie.

Upozornenie: Tento článok bol preložený automaticky

Vlastnosti

ID článku: 224453 – Posledná kontrola: 03/15/2015 08:58:00 – Revízia: 3.0

  • 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
  • kbsqlsetup kbhowto kbtshoot kbexpertiseinter kbinfo kbmt KB224453 KbMtsk
Pripomienky
ex="0" id="language-">