Teď jste offline a čekáte, až se znova připojí internet.

Váš prohlížeč není podporovaný.

Pokud chcete používat tento web, musíte si aktualizovat prohlížeč.

Aktualizovat na nejnovější verzi Internet Exploreru

INF: Principy a odstraňování potíží blokování SQL Server

DŮLEŽITÉ: Tento článek je přeložen pomocí softwaru na strojový překlad Microsoft. Nepřesný či chybný překlad lze opravit prostřednictvím technologie Community Translation Framework (CTF). Microsoft nabízí strojově přeložené, komunitou dodatečně upravované články, a články přeložené lidmi s cílem zajistit přístup ke všem článkům v naší znalostní bázi ve více jazycích. Strojově přeložené a dodatečně upravované články mohou obsahovat chyby ve slovníku, syntaxi a gramatice. Společnost Microsoft není odpovědná za jakékoliv nepřesnosti, chyby nebo škody způsobené nesprávným překladem obsahu nebo jeho použitím našimi zákazníky. Více o CTF naleznete na http://support.microsoft.com/gp/machine-translation-corrections/cs.

Projděte si také anglickou verzi článku: 224453
Souhrn
V tomto článku termín "připojení" vztahuje na jedinou relaci přihlášení databáze. Každé připojení se zobrazí jako relace ID (SPID). Všechny tyto identifikátory SPID je často označovány jako proces, ačkoli to není kontextu samostatný proces v obvyklých smyslu. Každé číslo SPID spíše se skládá z prostředků serveru a datových struktur, které jsou nezbytné pro vyřízení žádosti jediného připojení z daného klienta. Jeden klientské aplikace může mít jedno nebo více připojení. Z hlediska serveru SQL Server není žádný rozdíl mezi více připojení z jednoho klienta aplikace na jednoho klientského počítače a více připojení z více klientských aplikací nebo více klientských počítačů. Jedno připojení může blokovat jiné připojení, bez ohledu na to, zda vychází ze stejné aplikace nebo samostatných aplikací na dvou různých klientských počítačů.
Další informace
Blokování je nevyhnutelné znaky typické pro jakýkoli systém řízení relačních databází (RDBMS) s založené na zámek souběžnosti. Na serveru SQL zablokování dochází, když jedno číslo SPID udržuje zámek na konkrétní zdroj a druhé číslo SPID pokusí získat konfliktní typ zámku na stejný zdroj. Časový rámec, jehož první číslo SPID uzamčení prostředku je obvykle velmi malé. Když se uvolní zámek, druhé připojení je zdarma získat vlastní uzamčení prostředku a pokračovat ve zpracování. Toto je normální chování, může dojít opakovaně v průběhu dne se žádný znatelný vliv na výkon systému.

Doba trvání a transakcí kontext dotazu zjistit, jak dlouho jeho zámky a tím jejich dopad na jiné dotazy. Pokud dotaz není spuštěn v rámci transakce (a žádné uzamčení Rady při psaní se používají), zámky pro příkazy SELECT bude pouze konat na prostředku v okamžiku, kdy se skutečně čte, není po dobu trvání dotazu. Pro příkazy INSERT, UPDATE a DELETE zámky po dobu trvání dotazu, jak konzistence dat a chcete, aby dotaz nutno vrátit zpět, pokud je to nutné.

Dotazy provedeny v rámci transakce dobu trvání, pro kterou zámky jsou určeny typem dotazu, úroveň izolace transakce a zda uzamknout pomocné body používají v dotazu. Popis zamykání uzamčení Rady při psaní a úrovních izolace transakcí naleznete v následujících tématech v SQL Server Books Online:
  • Uzamčení v databázovém stroji
  • Přizpůsobení uzamčení a správu verzí řádků
  • Zámek režimy
  • Uzamknout kompatibility
  • Úrovních izolace systémem správy verzí řádku v databázovém stroji
  • Řízení transakcí (databázový stroj)
Při uzamykání a blokování zvýšení bodu je nepříznivý vliv na výkon systému, je obvykle z jednoho z následujících důvodů:
  • Číslo SPID držitelem uzamčení na sadu prostředků pro extendedperiod před jejich uvolněním. Tento typ blokování řeší itselfover čas, ale může způsobit snížení výkonu.
  • Číslo SPID držitelem uzamčení na sadu prostředků a nikdy releasesthem. Tento typ blokování sám nevyřeší a zabraňuje přístupu k prostředkům za neomezeně dlouho.
V prvním scénáři výše blokování problém řeší sám časem jako číslo SPID uvolnění uzamčení. Situaci však může být velmi kapaliny různými identifikátory SPID příčinou blokování na různé zdroje v průběhu času, vytvoření pohyblivé cíle. Z tohoto důvodu může být v těchto případech obtížně řešitelné pomocí SQL Server Enterprise Manager nebo jednotlivé dotazy SQL. Výsledky druhé situace v konzistentním stavu, které lze snáze diagnostikovat.

Shromažďování informací o blokování

K vyvážení obtížnost blokování potíží, můžete použít správce databáze SQL skripty, které neustále sledovat stav uzamykání a blokování na serveru SQL Server. Tyto skripty může poskytnout snímky specifické instance v průběhu času vedoucí k celkový obraz o problému. Popis sledování blokování pomocí skriptů SQL naleznete v následujících článcích znalostní báze Microsoft Knowledge Base:
271509 Sledování blokování na serveru SQL Server 2005 a SQL Server 2000
Skripty v tomto článku provede následující úkoly. Pokud je to možné, je dán metodou k získání těchto informací z SQL Server Management Studio.
  1. Identifikaci (ID relace) číslo SPID v čele blokování řetězce a příkaz SQL.
    Kromě výše uvedených článku znalostní báze Knowledge Base pomocí skriptů, youcan identifikovat hlavy blokování řetězce pomocí funkcí, které jsou k dispozici prostřednictvím SQL Server Management Studio. Chcete-li to provést, použijte jednu z následujících metod:
    • Klepněte pravým tlačítkem myši na objekt serveru, rozbalte sestavy, rozbalte Standardních sestava klepněte na tlačítko aktivity – všechny transakce blokování. Tato sestava zobrazuje transakce v čele blokování řetězce. Pokud rozdělíte transakce, transakce, které jsou blokovány hlavy transakce budou v sestavě zobrazeny. Tato sestava zobrazí také "Blokování příkaz SQL" a "Uzavřeno SQL prohlášení."
    • Pomocí DBCC INPUTBUFFER (<spid>) k nalezení posledního příkazu, který předložila SPID.</spid>
  2. Vyhledejte úroveň vnoření transakce a proces stav blokování SPID.
    Úroveň vnoření transakce číslo SPID je k dispozici v globální proměnné the@@TRANCOUNT. Však může určit, z vnější theSPID dotazem v tabulce sysprocesses takto:

    SELECT open_tran FROM master.sys.sysprocesses WHERE SPID=<blocking SPID number>go						
    Vrácená hodnota je hodnota @@TRANCOUNT pro číslo SPID. Tento showsthe transakce úroveň vnoření pro blokování SPID, které zase mohou explainwhy drží zámky. Například pokud je hodnota větší než nula, theSPID je in the midst of (ve kterém případě se očekává, že itretains některých uzamknul získala, v závislosti na transakci isolationlevel) transakce.

    Můžete také zkontrolovat, zda všechny dlouhodobé otevření transactionexists v databázi pomocí DBCC OPENTRANnázev_databáze.

Získávání informace o trasování SQL Server Profiler

Kromě výše uvedených informací je často nutné zachytit trasování Profiler činností na serveru, aby důkladně prozkoumat problém blokování na serveru SQL Server. Pokud číslo SPID spustí vícenásobné příkazy v rámci transakce, byl odeslán pouze poslední statementthat bude zobrazovat v sestavě, vstupní vyrovnávací paměti nebo výstup sledování aktivity. Však jeden z předchozích příkazů může být důvod, proč stále se zámky. Trasování Profiler vám umožní zobrazit všechny příkazy spustit SPID v rámci aktuální transakce. Následující kroky umožňují nastavit SQL Server Profiler k zachycení trasování.
  1. Otevřete SQL Server Profiler.
  2. V nabídce soubor přejděte na příkaz Novýa potom klepněte na Vektorizovat.
  3. Na kartě Obecné zadejte název trasování a název souboru pro sběr údajů.

    Důležité Soubor trasování by měly být zapsány na disk rychle místní nebo sdílené. Vyhněte se trasování pomalé jednotky disku nebo v síti. Také zkontrolujte, zda že server zpracuje trasovací data je zaškrtnuto.
  4. Na kartě Výběr události klepnutím zaškrtněte políčko Zobrazit všechny sloupce a všechny události .
  5. Na kartě Výběr události přidáte typy událostí, které jsou uvedeny v tabulce 1 v trasování.

    Navíc může obsahovat další typy událostí, které jsou uvedeny v tabulce 2 Další informace. Pokud používáte v prostředí velkých objemů výroby, můžete rozhodnout použít pouze události v tabulce 1 jsou obvykle dostačující pro řešení většiny problémů zablokování. Včetně další události v tabulce 2 mohou usnadnit rychle zjistit příčinu problému (nebo tyto události mohou být nezbytné k identifikaci culprit příkazu v Vícepříkazové procedury). Včetně události v tabulce 2 však také přidat zatížení systému a zvětšit velikost výstupu trasování.
Tabulka 1: Typy událostí
NadpisUdálost
Chyby a upozorněníVýjimka
Chyby a upozorněníPozornost
Audit zabezpečeníAuditu přihlášení
Audit zabezpečeníAuditovat odhlášení
RelaceExistující připojení
Uložené proceduryRPC: počáteční
TSQLSQL:BatchStarting

Tabulka 2: Typy další událost
NadpisUdálost
TransakceDTCTransaction
TransakceSQLTransaction
Uložené proceduryRPC: dokončeno
TSQLSQL:BatchCompleted
Uložené procedurySP:StmtStarting
Uložené procedurySP:StmtCompleted

Další informace o použití nástroje serveru SQL naleznete v dokumentaci SQL Server Books Online.

Identifikace a řešení běžné scénáře blokování

Porovnáním výše uvedené informace lze zjistit příčinu většiny problémů zablokování. Zbývající část tohoto článku je diskusi o tom, jak tyto informace použít k identifikaci a řešit některé běžné scénáře blokování. Předpokládáme, že jste použili blokování skriptů v článku 271509 (odkaz výše) k zachycení informace o blokování identifikátory SPID a provedli trasování Profiler události popsané výše.

Zobrazení výstupu blokování skriptu

Prohlédněte si výstup sys.sysprocesses určit vedoucích blokování řetězy
Pokud jste nezadali rychlého režimu blokování skriptů, bude oddílu s názvem "Identifikátory SPID v čele blokování řetězy" thatlists identifikátory SPID, které blokují další identifikátory SPID ve výstupu ze skriptu.
SPIDs at the head of blocking chains
Pokud jste zadali možnost rychlého, stále můžete určit hlav theblocking pohledem na výstup sys.sysprocesses a následující hierarchii SPID, který je uveden ve sloupci blokované.
Prohlédněte si výstup sys.sysprocesses informace o identifikátory SPID v čele blokování řetězce.
Je důležité vyhodnotit sys.sysprocesses následující pole:

Stav

Tento sloupec zobrazuje stav určité číslo SPID. Stav spánku obvykle označuje, že číslo SPID dokončila spuštění a čeká aplikace odesílat další dotaz nebo dávkové. Stav spustitelného, spuštěnínebo sos_scheduler_yield označuje číslo SPID je aktuálně zpracování dotazu. Následující tabulka uvádí stručné vysvětlení různých hodnot stavů.
StavTj.
PozadíČíslo SPID je spuštěna úloha pozadí, jako je zjišťování zablokování.
V režimu spánkuČíslo SPID aktuálně neprovádí. To obvykle znamená, že číslo SPID čeká na příkaz v aplikaci.
SystémemČíslo SPID je aktuálně spuštěn v plánovač.
SpustitelnéhoČíslo SPID je do spustitelného fronty Plánovač a čekání na načtení Plánovač času.
Sos_scheduler_yieldČíslo SPID byl spuštěn, ale dobrovolně využit jeho časový úsek na Plánovač povolit jiné číslo SPID pro získávání časových plánovač.
PozastavenoČíslo SPID čeká na událost, například zámek nebo zámek.
Vrácení zpětČíslo SPID je vrácení transakce zpět.
DefwakeupOznačuje, že číslo SPID čeká na prostředek, který je v procesu Uvolňovaná. Pole waitresource uvádět dotyčných prostředků.

Open_tran

Toto pole obsahuje úroveň vnoření transakce číslo SPID. Pokud je tato hodnota větší než 0, číslo SPID je v otevřené transakce a může být zámky získané s příkazy v rámci transakce.

Lastwaittype a waittype, Doba_čekání

Pole lastwaittype je řetězec reprezentace pole waittype , což je vyhrazená vnitřní binární sloupec. Pokud waittype je 0x0000, číslo SPID není aktuálně čekání na nic a hodnota lastwaittype označuje poslední waittype , které bylo číslo SPID. Pokud waittype není nula, hodnota lastwaittype označuje aktuální waittype o číslo SPID.

Stručný popis různých lastwaittype a waittype hodnot naleznete v následujícím článku znalostní báze Microsoft Knowledge base:
822101 Popis sloupce waittype a lastwaittype v tabulce master.dbo.sysprocesses v SQL Server 2000 a SQL Server 2005
Další informace o sys.dm_os_wait_statsnaleznete v tématu SQL Server Books Online.

Doba_čekání hodnoty slouží k určení, pokud je číslo SPID učinění pokroku. Při dotazu proti sys.sysprocesses tabulka vrátí hodnotu v Doba_čekání sloupec, který je menší než Doba_čekání hodnoty z předchozího dotazu sys.sysprocesses, to znamená, že byl předchozí zámek získali a uvolnění, a je nyní čeká na nový zámek (za předpokladu Doba_čekání nulová). To lze ověřit porovnáním waitresource mezi sys.sysprocesses výstup.

Waitresource

Toto pole vyznačuje, číslo SPID čeká na prostředek. V následující tabulce jsou uvedeny běžné formáty waitresource a jejich význam:
ZdrojFormátPříklad
TabulkaDatabaseID:ObjectID:IndexIDKARTA: 5:261575970:1
V tomto případě je databáze ID 5 pubs ukázkové databáze a objekt ID 261575970 je tabulka tituly a 1 je seskupený index.
StránkyDatabaseID:FileID:PageIDSTRÁNKA: 5:1:104
V tomto případě je databáze ID 5 pubsprimární datový soubor je soubor ID 1 a stránka 104 je stránka náležející k tabulce tituly .

Chcete-li zjistit identifikátor objektu, které stránka patří, pomocí příkazu DBCC PAGE (dbid fileid, pageid, output_option) a podívejte m_objId. Například:
DBCC TRACEON ( 3604 )DBCC PAGE ( 5 , 1 , 104 , 3 )
KlíčDatabaseID:Hobt_id (Hash hodnota indexu klíče)KLÍČ: 5:72057594044284928 (3300a4f361aa)

V tomto případě je databáze ID 5 Pubs, odpovídá bez seskupený index_id 2 pro id objektu (tabulkanázvů ) 261575970 Hobt_ID 72057594044284928. Pomocí zobrazení katalogu sys.partitions přiřaďte hobt_id konkrétní index id a identifikátor objektu. Neexistuje žádný způsob, jak unhash hash klíčů indexu na hodnotu konkrétního indexu klíče.
ŘádekDatabaseID:FileID:PageID:Slot(row)HLAVNÍ SERVER RELATIVNÍCH ID: 5:1:104:3

V tomto případě je databáze ID 5 pubs primární datový soubor je soubor ID 1, stránka 104 je stránka náležející k tabulce tituly a slot 3 označuje pozici v řádku na stránce.
KompilaceDatabaseID:ObjectID [[KOMPILACE]]Karta: 5:834102012 [[KOMPILACE]] není uzamčení celé tabulky, ale spíše kompilaci zamknout na uloženou proceduru. ID databáze 5 pubs, je objekt ID 834102012 usp_myprocedure uložené procedury. Další informace o blokování způsobené zámky kompilace naleznete v článku 263889 znalostní báze Knowledge Base.
Ostatní sloupce

Zbývající sloupce sys.sysprocesses může poskytnout náhled do kořenové problém také. Jejich užitečnost se liší v závislosti na okolnostech problém. Například můžete určit, pokud problém nastane pouze z některých klientů (hostname) na určitých síťových knihoven (net_library), kdy byl poslední šarže předložené číslo SPID (last_batch) a tak dále.
Prohlédněte si výstup DBCC INPUTBUFFER.
Pro libovolné číslo SPID v čele blokování řetězce nebo s waittype Parametr anon nula blokování skriptu spustí todetermine DBCC INPUTBUFFER dotazu pro dané číslo SPID.

V mnoha případech toto je dotaz, který způsobuje zámky které jsou bylo očekáváno blokování ostatním uživatelům konat. Nicméně pokud číslo SPID je v atransaction, zámky mohou získá dříve provedeného dotazu, není stávající. Proto by měl také zobrazit výstup Profiler pro číslo SPID, nikoli pouze inputbuffer.

Poznámka: Vzhledem k tomu, že blokování skriptů se skládá z více kroků, je ispossible, že číslo SPID může zobrazovat v první části jako hlavy blockingchain, ale DBCC INPUTBUFFER dotaz proveden v době, je bez longerblocking a není zachycen INPUTBUFFER. To znamená, že blockingis vlastní řešení pro dané číslo SPID a mohou nebo nemusí být problém. Na thispoint můžete využít rychlé verze blokování skriptů při pokusu zachytit inputbuffer před tím (i když je stále noguarantee) k tomu nebo zobrazení okna profilování data z tohoto časového rámce k určení whatqueries číslo SPID při spouštění.

Zobrazení dat modulu Profiler

Efektivní zobrazení dat Profiler je mimořádně cenné při řešení problémů blokování. Je velice důležité si uvědomit je, že není nutné podívat se na vše, co je zachycena; vybírejte. Profiler obsahuje funkce, které vám pomohou efektivně zobrazit sebraná data. V dialogovém okně Vlastnosti (v nabídce soubor klepněte na příkaz Vlastnosti), Profiler umožňuje omezit data zobrazená odebráním sloupce dat nebo události, seskupení (třídění) sloupce dat a používání filtrů. Můžete hledat celý trasování nebo určitého sloupce pro určité hodnoty (v nabídce Úpravy klepněte na příkaz Najít). Profilování data můžete uložit také do tabulky serveru SQL Server (v nabídce soubor přejděte na příkaz Uložit jako a potom klepněte na tlačítko tabulky) a dotazy SQL spuštěn.

Dejte pozor, že provádí filtrování pouze na soubor uložený trasování. Pokud se provedení těchto kroků na aktivní sledování rizika ztráty dat, která byla sebrána od spuštění trasování. Uložit aktivní trasování do souboru nebo tabulky nejprve (v nabídce soubor klepněte na příkaz Uložit jako) a pak jej znovu otevřete (v nabídce soubor klepněte na tlačítko Otevřít) před pokračováním. Při práci na soubor uložený trasování, filtrování neodebere trvale filtrovány data, pouze nezobrazuje všechna data. Můžete přidat a odebrat události a data sloupce je potřeba zaměřit hledání.

Co hledat:
  • Příkazy, co má číslo SPID v čele blokování chainexecuted v rámci aktuální transakce?
    Filtrovat data trasování pro aparticular číslo SPID, který stojí v čele blokování řetězce (v nabídce soubor klepněte na příkaz Vlastnosti, na kartě filtry zadejte číslo SPID hodnota). Poté můžete prozkoumat předchozího ithas provedeny příkazy čas ji byla blokování další identifikátory SPID. Pokud zahrnete theTransaction události, mohou snadno identifikovat kdy transakce byla spuštěna.Jinak můžete hledat textový sloupec počáteční uložit potvrzení nebo ROLLBACK TRANSACTIONoperations. Použijte hodnotu open_tran z tabulky sysprocesses zajistit zachytit všechny události transakce.Znalost příkazy provedeny a kontext transakce vám umožní todetermine, proč se zámky číslo SPID.

    Nezapomeňte, že můžete removeevents a data sloupce. Místo hledání při spuštění a completedevents, zvolte jeden. Pokud blokování identifikátory SPID nejsou uložené procedury, odebráníSP: počáteční nebo SP: dokončeno události. SQLBatch a vzdáleného volání Procedur událostí zobrazí volání procedury. Zobrazení pouze whenyou události SP potřebovat zobrazit úroveň podrobností.
  • Co je doba trvání dotazy pro identifikátory SPID v headof blokování řetězy?
    Pokud zahrnete dokončené události výše, Doba trvání sloupec se zobrazí doba provádění dotazu. To může pomoci youidentify Dlouhotrvající dotazy, které jsou příčinou blokování. Chcete-li zjistit, proč zpomalit thequery, zobrazení procesor, čtenía sloupce zapíše , jakož i Plán spuštění události.

Zařazování do kategorií běžné scénáře blokování

Níže uvedená tabulka mapuje běžné příznaky jejich pravděpodobné příčiny. Číslo uvedené ve sloupci scénář odpovídá číslu v části "Společné blokování scénáře a jejich řešení" tohoto článku níže. Sloupce Waittype, Open_Trana stavu získáte sysprocesses . Řeší? sloupec označuje, zda blokování vyřeší sám.

ScénářWaittypeOpen_TranStavŘeší?Další příznaky
1Nenulová> = 0spustitelnéhoAno, po dokončení dotazu.Physical_IO, procesor a/nebo Memusage sloupce zvýší v čase. Doba trvání dotazu bude vysoká po dokončení.
20x0000> 0v režimu spánkuNe, ale může být utracena SPID.Signál pozornost může vidět Profiler trasování pro toto SPID určující časový limit dotazu nebo Storno došlo k chybě.
30x0000> = 0spustitelnéhoNe. Nevyřeší dokud klient načte všechny řádky nebo zavře připojení. SPID může být utracena, ale může trvat až 30 sekund.Pokud open_tran = 0 a číslo SPID držitelem uzamčení úroveň izolace transakce je výchozí (COMMMITTED čtení), je pravděpodobné, že příčinou.
4Se liší> = 0spustitelnéhoNe. Nevyřeší dokud klient zruší dotazy nebo zavře připojení. Identifikátory SPID může být utracena, ale může trvat až 30 sekund.Sloupec název hostitele v sysprocesses pro číslo SPID v čele blokování řetězce budou stejné jako jedno číslo SPID je blokování.
50x0000> 0vrácení zpětAno.Signál pozornost může vidět Profiler trasování pro toto SPID určující časový limit dotazu došlo k zrušení nebo jednoduše vrátit prohlášení bylo vydáno.
60x0000> 0v režimu spánkuNakonec. Při systému Windows NT Určuje že relace je již aktivní, se přeruší připojení serveru SQL Server.Hodnota last_batch v sysprocesses je mnohem starší než aktuální čas.

Běžné scénáře blokování a jejich řešení

Níže uvedené scénáře budou mít ukazatele uvedené v předchozí tabulce. Tato část poskytuje další podrobnosti, případně i cesty k řešení.
  1. Blokování způsobené normálně spuštěn s dlouhou dobu spuštění dotazu

    Řešení:
    Řešení pro problém blokování tohoto typu je oblast forways optimalizace dotazu. Tato třída blokování problém ve skutečnosti, může justbe problémy s výkonem a vyžadují vykonávat jako takové. Informationon odstraňování potíží s konkrétní zpomalit spuštění dotazu naleznete v následujícím článku znalostní báze Microsoft Knowledge Base:
    243589 Řešení problémů s dotazy zpomalit běžící na serveru SQL Server 7.0 nebo novější verze
    Performancetroubleshooting aplikací naleznete v následujícím článku znalostní báze Knowledge Base:
    224587 Postup: Poradce při potížích výkon aplikace se serverem SQL Server
    Další informace naleznete v tématu Sledování výkonu a optimalizace témata týkající se SQL Server 2008 Books Online na webu MSDN: Pokud máte dlouho běžící dotaz, který je blockingother uživatelé a nemůže být optimalizován, zvažte přesunutí dat z OLTPenvironment systém pro podporu rozhodování.
  2. Blokování způsobené spacích SPID, který ztratil sledování úrovně vnoření transakce

    Tento typ blokování lze často určit pomocí SPIDthat je spánku nebo čeká na příkazu, ale jejichž transakce úroveň vnoření (@@TRANCOUNT, open_tran z sysprocesses) je větší než nula. Tato situace může nastat, pokud časový limit dotazu, applicationexperiences nebo zrušení problémy bez také vydávání therequired počet příkazů vrácení nebo potvrzení. Pokud číslo SPID obdrží aquery limitu nebo Storno, ukončí aktuální dotaz a dávkové úlohy, butdoes automaticky vrátit zpět ani potvrzení transakce. Aplikace isresponsible pro to, jak SQL Server nelze předpokládat, že celá transactionmust vrátit zpět pouze z jednoho dotazu stornována. Querytimeout nebo Storno zobrazí jako událost signálu POZORNOST SPID theProfiler trasování.

    Ukazuje to vydat následující jednoduché queryfrom Query Analyzer:

    BEGIN TRAN SELECT * FROM SYSOBJECTS S1, SYSOBJECTS S2-- Issue this after canceling querySELECT @@TRANCOUNTROLLBACK TRAN						
    Při provádění dotazu klepnutím na červené tlačítko Storno . Po dotazu je zrušena, vyberte @@TRANCOUNT indicatesthat úroveň vnoření transakce je. To bylo odstranění nebo UPDATEquery nebo bylo použito HOLDLOCK na výběr, konají se všechny zámky, které získali wouldstill. I s výše uvedený dotaz-li jiný dotaz získá uzamčení andheld dříve v transakci, že by stále koná, pokud aboveSELECT byla zrušena.

    Řešení:

    • Aplikace musí správně spravovat úrovní vnoření transakce, nebo by mohly způsobit blokování problém po zrušení dotazu tímto způsobem. To lze provést několika způsoby:
      1. V obslužné rutině chyby klientské aplikace odeslat IF @@TRANCOUNT > 0 vrácení NAHRA po jakékoli chyby, i když klientská aplikace není věří transakce je otevřete. Totiž, uloženou proceduru volat při dávce může začít transakce bez vědomí klientské aplikace. Všimněte si, že určité podmínky, například zrušení dotazu, zabránit postupu spuštění aktuálního příkazu v minulosti tak i v případě, že procedura má logiku, která v případě @@ERROR <> 0 a přerušení transakce, v takovém případě nebudou provedeny tento kód vrácení zpět.
      2. Pomocí nastavení XACT_ABORT ON, připojení, nebo všechny uložené procedury, které začínají transakce a nejsou čištění po chybě. V případě chyby běhu bude toto nastavení zrušit všechny otevřené transakce a vrácení řízení klienta. Všimněte si, že nebudou provedeny T-SQL příkazy následující příkaz, který způsobil chybu.
      3. Sdružování připojení je používán v aplikaci, která otevře připojení a spustí malý počet dotazů před uvolněním připojení ve fondu, jako je například webová aplikace dočasně zakázat sdružování připojení můžete vyřešit problém dokud klientská aplikace je upravit tak, aby řádně zpracování chyb. Zakázáním sdružování připojení způsobí uvolnění připojení fyzické logout připojení serveru SQL Server, výsledkem je vrácení zpět všechny otevřené transakce serveru.
      4. Pokud je povoleno sdružování připojení a cílový server je SQL Server 2000, může být prospěšné inovaci klientského počítače na součásti MDAC 2.6 nebo novější. Tato verze součástí MDAC přidá kód ODBC ovladače a zprostředkovatele OLE DB tak, aby připojení by "obnovit" než je znovu použít. Toto volání sp_reset_connection přeruší jakékoli server inicioval transakce (transakce koordinátoru DTC iniciováno klienta aplikace nebudou ovlivněny), obnoví výchozí databáze, nastavit možnosti a tak dále. Všimněte si, že připojení není vynulován dokud je znovu z fondu připojení, takže je možné, že uživatel může otevřít transakci a poté uvolněte připojení k fondu připojení, ale nemusí být znovu použity pro několik sekund, během této doby by zůstat otevřené transakce. Pokud připojení nebude znovu použit, bude transakce přerušena, pokud vyprší časový limit připojení a je odebrán z fondu připojení. Proto je optimální pro klientskou aplikaci přerušit transakce v jejich obslužná rutina chyb nebo použít nastavení XACT_ABORT ON Chcete-li zabránit tomuto možnému zpoždění.
    • Ve skutečnosti tato třída blokování problém může také být problémy s výkonem a vyžadují, abyste ji vykonávají jako takové. Pokud může být snížena doba provádění dotazu by dojít k vypršení časového limitu dotazu nebo Storno. Je důležité, aby aplikace schopna zpracovat časový limit nebo zrušit scénáře vznikne jejich, ale mohou také využít posouzení výkonu dotazu.
  3. Blokování způsobené SPID, jehož odpovídající klientské aplikace není načíst všechny řádky výsledek dokončení

    Po odeslání dotazu na server, všechny applicationsmust okamžitě načítat všechny výsledné řádky až do ukončení. Pokud aplikace doesnot načíst všechny řádky výsledek, uzamčení může zůstat na tabulkách, blokování otherusers. Pokud používáte aplikaci, která transparentně SQLstatements odešle na server, aplikace musí načíst všechny řádky výsledek. Pokud itdoes není (a pokud nelze nakonfigurovat tak učinit), může být možné toresolve blokování problém. Se tomuto problému vyhnout, můžete se choval restrictpoorly aplikací vykazování nebo rozhodnutí supportdatabase.

    Řešení:

    Aplikace musí být napsány znovu načíst všechny řádky výsledek až do ukončení.
  4. Blokování způsobené zablokování distribuované Klient/Server

    Na rozdíl od konvenčního zablokování distribuovaných deadlockis, která je nezjistitelná používání RDBMS uzamčení správce. Je to způsobeno thatonly fakt, jeden z prostředků účastní zablokování je uzamčen SQL Server. Theother straně k zablokování je na úrovni aplikace klienta, jehož prostřednictvím SQL Server nemá žádný vliv. Následují dva příklady, jak k tomu může dojít, a možné způsoby aplikace vyhnete.

    1. Klient/Server DFS zablokování s klientem podproces
      Pokud má klient více otevřených spojení a jediný podproces provádění, může dojít k následující zablokování. Pro stručnost pojem "dbproc" použít zde odkazuje na strukturu připojení 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 případě výše uvedenou klientem podproces aplikace má dvě otevřené připojení. Odešle asynchronní operaci SQL na dbproc1. To znamená, že nečeká na návrat před provedením volání. Aplikace potom odešle jiná operace SQL na dbproc2 a čeká na výsledky k zahájení zpracování vrácených dat. Vraceli při spuštění data (nejprve dbproc podle toho, která odpovídá--předpokládá je dbproc1), zpracovává všechna data vrácena na dané dbproc dokončení. Načte výsledky z dbproc1, dokud SPID1 získá blokováno na zámek v držení SPID2 (protože dva dotazy spuštěné asynchronně na serveru). V tomto okamžiku dbproc1 bude čekat nekonečně dlouho další data. SPID2 v zámku není blokován, ale pokusí odeslat data na klienta, dbproc2. Nicméně dbproc2 je účinně blokován na dbproc1 ve vrstvě aplikací jako jediný podproces provádění aplikace je používán dbproc1. To má za následek zablokování, které nelze rozpoznat nebo řešení, protože pouze jeden ze zdrojů potřebných prostředků serveru SQL Server SQL Server.
    2. Klient/Server Distributed zablokování s vláknem za připojení

      I v případě, že samostatný podproces existuje pro každé připojení na straně klienta, variantu tohoto zablokování dochází stále jak je znázorněno v následující.

      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 případ se podobá například A, s výjimkou dbproc2 a SPID2 spuštěn příkaz SELECT s úmyslem provedení řádku na čas zpracování a předávání jednotlivých řádků do vyrovnávací paměti dbproc1 pro INSERT, UPDATE, nebo DELETE výkazu v téže tabulce. Nakonec SPID1 zablokování (provede INSERT, UPDATE nebo DELETE) na zámek v držení SPID2 (provedení výběru). SPID2 zapíše výsledek řádku dbproc2 klienta. Dbproc2 se poté pokusí předat řádku do vyrovnávací paměti dbproc1, ale je zaneprázdněn najde dbproc1 (je blokován čekání na dokončení aktuální INSERT, který je blokováno na SPID2 SPID1). V tomto okamžiku blokován dbproc2 ve vrstvě aplikací podle dbproc1, jehož číslo SPID (SPID1) je blokováno na úrovni databáze SPID2. Znovu to má za následek zablokování, které nelze rozpoznat nebo řešení, protože pouze jeden ze zdrojů potřebných prostředků serveru SQL Server SQL Server.
    Oba příklady A a B jsou základní problémy, které musí být vědomi vývojáři thatapplication. Aplikace na handlethese případy se musí kód odpovídajícím způsobem.

    Řešení:

    Použití querytimeout nebo vázaného připojení jsou dva spolehlivé řešení.

    • Časový limit dotazu
      Při vypršení časového limitu dotazu byla poskytnuta, pokud dojde zablokování, budou přerušení při pak dojde k vypršení časového limitu. Viz knihovny DB-Library nebo ODBC dokumentaci další informace o použití časový limit dotazu.
    • Vázané připojení
      Tato funkce umožňuje klientům s více připojení navázat do jediné transakce vesmíru, takže připojení nepřekážely navzájem. Další informace naleznete v tématu "Použití vázaných připojení" v SQL Server 7.0 Books Online.
  5. Blokování způsobené SPID, který je "Golden" nebo vrácení stavu

    Modifikace dotazu data, KILLed nebo canceledoutside uživatelem definované transakce bude vrácena zpět. Můžete také occuras vedlejším účinkem restartování počítače klienta a jeho sessiondisconnecting sítě. Podobně bude vybrán jako obětí zablokování dotazu rolledback. Modifikace dotazu dat často nelze vrátit zpět všechny rychleji, než bylo původně použito thechanges. Například pokud byly spuštěny odstranit, vložit nebo UPDATEstatement hodiny, může trvat nejméně jednu hodinu při vracení. To je očekávané chování, protože změny musí být zpět completelyrolled nebo becompromised by transakční a fyzické integrity databáze. Vzhledem k tomu, že k tomu musí dojít, SQL Server označí SPID ve stavu "golden" nebo vrácení zpět (což znamená, že nemůže být utracena nebo vybraných jako deadlockvictim). To lze často určit pomocí pozorování výstup sp_who, což může znamenat ROLLBACK příkazu. Sys.sysprocesses sloupci Stav bude označovat stav ROLLBACK, která se také zobrazí ve výstupu sp_who nebo sledování činnosti serveru SQL Server Management Studio.
    Řešení:

    Je nutné vyčkat SPID, k dokončení vracení thechanges, které byly provedeny.

    Pokud je server vypnut v prosbou provoz této databáze bude v režimu zotavení po restartování a itwill být nepřístupné, dokud nejsou zpracovány všechny otevřené transakce. Startuprecovery má v podstatě stejné množství času na transakci jako timerecovery spustit a databáze je nedostupný během tohoto období. Forcingthe server na oprava SPID ve stavu vrácení tedy bude často becounterproductive.

    K této situaci vyhnout, není provedení largebatch INSERT, UPDATE nebo DELETE operace během doby zaneprázdněna OLTP systémech.Pokud je to možné provádění těchto operací během období nízké aktivity.
  6. Blokování způsobená osamocených připojení

    Pokud je restartován depeše aplikace klienta nebo clientworkstation, síťové relace na serveru pravděpodobně není beimmediately zrušena za určitých podmínek. Z pohledu na serveru theclient se stále zdá být přítomen a všechny zámky, které získali může stále beretained. Další informace získáte v následujícím článku znalostní báze Microsoft Knowledge Base:
    137983 Řešení potíží s připojením osamocené v serveru SQL Server

    Řešení:

    Pokud aplikace klienta odpojila withoutappropriately uvolnění svých prostředků, je číslo SPID ukončit příkazem použít DEZAKTIVAČNÍ. Příkaz DEZAKTIVAČNÍ trvá SPID hodnota jako vstup. Například usmrcení SPID 9, jednoduše vydat následující příkaz:

    KILL 9						

    Poznámka: Příkaz DEZAKTIVAČNÍ může trvat až 30 sekund k dokončení, kvůli interval mezi kontrolami pro příkaz DEZAKTIVAČNÍ.

Aplikace zapojení blokování problémy

Mohou existovat tendence zaměřit se na problémy ladění a platformu serverové když blokování problém. Však to obvykle nevede k rozlišení a mohou pojmout čas a energii lépe zaměřené na posouzení klientskou aplikací a dotazy, které ji odešle. Bez ohledu na to, jakou úroveň viditelnosti aplikace zpřístupní týkající se volání databáze prováděny, blokování problém však často vyžaduje kontrolu přesné příkazy SQL předložené žádosti a přesné chování aplikace týkající se zrušení dotazu správy připojení načítání všech řádků způsobit atd. Pokud vývojový nástroj neumožňuje explicitní řídit správu připojení, zrušení dotazu, časový limit dotazu, načítání výsledku a podobně, nemusí být blokující problémy možností vyřešení. Tento potenciál by měly pečlivě přezkoumány před výběrem nástroj pro vývoj aplikací pro SQL Server, zejména u důležitých podnikových prostředích OLTP.

Je důležité, aby velmi pečlivě vykonávají ve fázi návrhu a konstrukce databáze a aplikace. Zejména spotřebu zdrojů, úroveň izolace a délka cesty transakce mají být vyhodnoceny pro každý dotaz. Každý dotaz a transakce by měla být co nejjednodušší. Obor správy dobré připojení musí být uplatňována. Není to je možné, že aplikace se zdá mají přijatelného výkonu při nízké počty uživatelů, ale výkon se může snížit významně zvyšujícím se počtem uživatelů stupnice směrem nahoru.

Správné používání a návrh dotazu je podporovat mnoha tisícům současně připojených uživatelů na jednom serveru s malým množstvím blokování Microsoft SQL Server.

Upozornění: Tento článek je přeložený automaticky

Vlastnosti

ID článku: 224453 - Poslední kontrola: 03/15/2015 03:30:00 - Revize: 9.0

  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • 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 KbMtcs
Váš názor
>ow.location.protocol) + "//c.microsoft.com/ms.js'><\/script>"); &t=">>