INF: Vysvětlení a řešení problémů blokování serveru SQL Server

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

Na této stránce

Souhrn

V tomto článku se pojem "připojení" týká se pouze jednu relaci přihlášení databáze. Každé připojení se zobrazí. jako ID relace (SPID). Každý z těchto identifikátory SPID je často označována jako proces, ačkoli není v kontextu samostatný proces, v tom smyslu, obvyklé. Spíše každou SPID skládá ze zdrojů a datové struktury serveru nezbytné požadavky z jednoho připojení z daného klienta. A jediný klientská aplikace může mít jedno nebo více připojení. Od Perspektiva serveru SQL Server není k dispozici žá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čů. Jeden připojení lze blokovat jiné připojení, bez ohledu na to, zda jsou provozována. z téže aplikace nebo samostatných aplikací na dvou různých klientských počítače.

Další informace

Blokování je nevyhnutelné charakteristika všechny relační systém pro správu databází (RDBMS) s souběžnosti založené na zámek. Na serveru SQL Server blokování dojde k jedné SPID drží zámek na konkrétní zdroj a druhý Číslo SPID se pokusí získat konfliktní typu uzamčení 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 jeho vlastní zámek prostředku a zpracování pokračovalo. Toto chování je očekávané a může dojít mnohokrát během dne se žádný znatelný vliv. na výkon systému.

Doba trvání a transakce kontextu dotaz určit, jak dlouho jeho zámky a tím, jejich dopad na ostatní dotazy. Pokud dotaz není spuštěn v rámci transakce (a žádné uzamčení tipy jsou použity), zámky pro příkazy SELECT budou konat pouze na prostředek na čas, kdy ji skutečně čte, není po dobu trvání dotazu. Pro INSERT, UPDATE a DELETE příkazy, zámky po dobu trvání dotaz, jak konzistence dat a umožňující dotaz vrátit zpět Pokud je to nutné.

Pro dotazy, které jsou spouštěny v rámci transakce doba trvání pro který zámky jsou určeny typem dotazu, úroveň izolace transakcí a zda jsou při uzamčení tipy dotaz. Popis zamykání, zámek rad a izolace transakcí úrovně, naleznete v následujících tématech SQL Server Books Online:
  • Zamykání v databázovém stroji
  • Přizpůsobení uzamčení a správu verzí řádků
  • Zámek režimy
  • Zámek kompatibility
  • Řádek systémem správy verzí úrovních izolace 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 kvůli jedné z z následujících důvodů:
  • SPID obsahuje sadu zdrojů pro rozšířenou zámky dobu před propuštěním. Tento typ blokování řeší sám v průběhu času ale může způsobit snížení výkonu.
  • SPID drží zámky na sadu prostředků a nikdy uvolní. je. Tento typ blokování sám nevyřeší a zabrání přístupu k příslušné zdroje po neomezenou dobu.
V prvním scénáři nad blokování problém řeší sám časem jako číslo SPID uvolnění uzamčení. Situaci lze však velmi kapaliny jako různé identifikátory SPID způsobit blokování různých zdrojů 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šení SQL Server Enterprise Manager nebo jednotlivé dotazy SQL. Na Druhá situace výsledky v konzistentním stavu, který lze snáze diagnostikovat.

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

K vyvážení potíže řešení potíží, blokování problémy, můžete správce databáze SQL skripty, které neustále monitorují stav uzamčení a blokování na serveru SQL Server. Tyto skripty mohou poskytnout. snímky specifické instance v průběhu času, vedoucí k celkové obrázek došlo k potížím. Popis způsobu sledování blokování pomocí skriptů SQL, naleznete Následující články znalostní báze Microsoft Knowledge Base:
271509 Jak sledovat blokování v serveru SQL Server 2005 a SQL Server 2000
Skripty v tomto článku budou provádět úkoly níže. Pokud je to možné, metoda pro získání těchto informací z SQL Server Management Studio je uveden.
  1. Určete číslo SPID (ID relace) v čele blokování řetězce a příkaz SQL.
    Vedle pomocí skriptů ve výše uvedených článku znalostní báze Knowledge Base, který vedoucí blokování řetězci můžete identifikovat pomocí funkcí, které jsou k dispozici prostřednictvím serveru 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 položku Sestavy, rozbalte položku Standardní sestavya 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, budou v sestavě zobrazeny transakce, které jsou blokovány hlavy transakce. Tato sestava zobrazí také "Blokování příkazu SQL" a "Uzavřeno příkazu SQL."
    • Použít DBCC INPUTBUFFER (<spid>) k nalezení posledního příkazu, který byl předán SPID.</spid>
  2. Najděte úroveň vnoření transakce a proces stav blokování číslo SPID.
    Úroveň vnoření SPID je k dispozici v transakci Globální proměnné @@ TRANCOUNT. Však může být stanovena z mimo Číslo SPID dotazem sysprocesses Následující tabulka:

    SELECT open_tran FROM master.sys.sysprocesses WHERE SPID=<blocking SPID number>
    go
    						
    Vrácená hodnota je hodnota @@ TRANCOUNT číslo SPID. Zobrazuje úroveň vnoření transakce pro blokování SPID, které zase mohou vysvětlit Proč to je zámky. Pokud je hodnota větší než nula, například Číslo SPID je v midst transakce (v tom případě je očekávaná že zachová určité zámky, získá, v závislosti na izolace transakcí úroveň).

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

Shromažďovat informace o trasování SQL Server Profiler

Vedle výše uvedených informací je často nezbytné důkladně zachytit Profiler trasování činnosti serveru Prozkoumejte blokování problém na serveru SQL Server. Pokud SPID provede více příkazy v rámci transakce, byla předložena pouze poslední statementthat, se zobrazí sestavy, 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ůvodem stále probíhá zámky. Trasování Profiler umožňuje zobrazit všechny příkazy provedeny SPID v rámci aktuální transakce. Následující kroky lze nastavit zachytit trasování SQL Server Profiler.
  1. Otevřete aplikaci SQL Server Profiler.
  2. V Soubor příkaz Novýa klepněte na tlačítko Trasování.
  3. V Obecné karta, 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 rychlé místní nebo sdílený disk. Vyhněte se trasování pomalé disku nebo síťové jednotky. Také zkontrolujte, zda že server zpracuje je vybrána data trasování.
  4. V Výběr událostí karta, zaškrtněte Zobrazit všechny události a Zobrazit všechny sloupce Zaškrtávací políčka.
  5. V Výběr událostí karta, přidat 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. Používáte-li v prostředí s vysokým objemem výroby, může rozhodnout použít pouze události v tabulce 1 jsou obvykle dostačující většinu problémů s bloková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 problémového výkazu s postupem). Včetně událostí 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í
Zmenšit tuto tabulkuRozšířit tuto tabulku
NadpisUdálost
Chyby a upozorněníVýjimka
Chyby a upozorněníPozornost
Audit zabezpečeníAudit přihlášení
Audit zabezpečeníOdhlášení auditu
RelaceExistující připojení
Uložené proceduryRPC: spouštění
TSQLSQL:BatchStarting

Tabulka 2: Další událost typy
Zmenšit tuto tabulkuRozšířit tuto tabulku
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 na serveru SQL Server Knihy Online.

Identifikace a řešení společného blokování scénáře

Přezkoumání výše uvedených informací, můžete určit příčinu Většina blokující problémy. Zbývající část tohoto článku je diskusi o tom, jak Pomocí těchto informací identifikovat a vyřešit některé běžné scénáře pro blokování. Předpokládáme že použili jste blokování skriptů v článku 271509 (uváděný dříve) k zachycení informace o blokování identifikátory SPID a provedení Profilování trasování událostí popsané výše.

Zobrazení blokování výstupu skriptu

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

Stav

Tento sloupec zobrazuje stav určité číslo SPID. Obvykle v režimu spánku stav označuje, že číslo SPID dokončila spuštění a Čekání na žádost předložit jiný dotaz nebo dávky. A Spustitelné pracovní, spuštění, nebo sos_scheduler_yield stav označuje číslo SPID je aktuálně zpracování dotazu. Na Následující tabulka uvádí stručné vysvětlení různých stavu hodnoty.
Zmenšit tuto tabulkuRozšířit tuto tabulku
StavVýznam
PozadíČíslo SPID je spuštěn na pozadí úlohy, jako je například zjišťování zablokování.
V režimu spánkuČíslo SPID aktuálně není prováděna. To obvykle označuje, že číslo SPID čeká příkazu z aplikace.
SpuštěníČíslo SPID aktuálně běží plánovače.
Spustitelné pracovníČíslo SPID je spustitelné pracovní fronty Plánovač a získat Plánovač času čekání.
Sos_scheduler_yieldČíslo SPID byl spuštěn, ale jeho čas řezu na Plánovač povolit jiné číslo SPID pro získávání časových Plánovač ji dobrovolně využit.
PozastavenoČíslo SPID čeká na událost, například zámek nebo zámek.
Vrácení zpětČíslo SPID je vrácení transakce.
DefwakeupOznačuje, že číslo SPID čeká na prostředek, který je Uvolňovaná. Pole waitresource by měl uvádět dotyčný zdroj.

Open_tran

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

Lastwaittype, waittype a Doba_čekání

Na lastwaittype pole je řetězcové vyjádření waittype pole, které je rezervované interní binární sloupec. Pokud waittype 0x0000, je číslo SPID nečeká aktuálně nic a na lastwaittype hodnota označuje poslední waittype že bylo číslo SPID. Pokud waittype není nula, lastwaittype hodnota označuje aktuální waittype o číslo SPID.

Pro Stručný popis různých lastwaittype a waittype hodnoty, naleznete v následujícím článku Microsoft Znalostní báze Knowledge base:
822101 Popis sloupce waittype a lastwaittype v master.dbo.sysprocesses tabulce serveru SQL Server 2000 a SQL Server 2005
Další informace o sys.dm_os_wait_stats, naleznete v dokumentaci SQL Server Books Online.

Na Doba_čekání hodnoty lze použít 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 z sys.sysprocesses, to znamená, že byl předchozí zámek získali a uvolněna a 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 označuje zdroj že SPID čeká. V následující tabulce jsou uvedeny běžné waitresource formáty a jejich význam:
Zmenšit tuto tabulkuRozšířit tuto tabulku
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 nadpisy tabulky a 1 je seskupený index.
StránkaDatabaseID:FileID:PageIDSTRÁNKA: 5:1:104
V tomto případě je databáze ID 5 pubs, primární datový soubor je soubor ID 1 a 104 je stránka patřící nadpisy Tabulka.

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

V tomto případě databáze ID 5 Pubs, odpovídá index_id 2 bez clusteru pro objekt id 261575970 (Hobt_ID 72057594044284928nadpisy tabulka). Přidružení hobt_id zejména index id a identifikátor objektu pomocí zobrazení katalogu sys.partitions. Neexistuje žádný způsob, jak unhash index algoritmus hash klíče na hodnotu konkrétního indexu klíče.
ŘádekDatabaseID:FileID:PageID:Slot(row)RID: 5:1:104:3

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

Zbývající sys.sysprocesses sloupce můžete poskytnout dokonalý kořen také problém. Jejich použitelnost se liší v závislosti na okolnostech problému. Pro například můžete určit Pokud problém nastane pouze z některých klientů (hostname) v určitých síťové knihovny (net_library), kdy poslední šarže předložené SPID byla (last_batch), atd.
Prohlédněte si výstup DBCC INPUTBUFFER.
Pro libovolné číslo SPID v čele blokování řetězce nebo s waittype nenulová, blokování skriptu spustit DBCC INPUTBUFFER na určení aktuálního dotazu pro dané číslo SPID.

V mnoha případech je dotaz, který způsobuje uzamčení blokuje konat ostatním uživatelům. Ale pokud je číslo SPID transakce, zámky byly pravděpodobně získané předcházející dotaz, Ten není aktuální. Proto by měl také zobrazit výstup Profiler číslo SPID, nikoli pouze inputbuffer.

Poznámka: Blokování skriptů se skládá z několika kroků, proto je možné, že SPID může zobrazovat v první části jako vedoucí blokování řetězce, ale v době spuštění dotazu DBCC INPUTBUFFER, je již blokování a INPUTBUFFER nebylo digitalizováno. To znamená, že blokování je sám řešení pro dané číslo SPID a mohou nebo nemusí být problém. Na tomto bod, můžete použít buď rychlé verze blokování skriptů při pokusu zajistit že sběr inputbuffer před vypne (přestože je stále žádné zajištění), nebo zobrazit data z tohoto časového rámce, určit, co Profiler dotazy provádění číslo SPID.

Zobrazení dat Profiler

Efektivní zobrazení dat Profiler je velmi cenné řešení problémů se blokování. Pro realizaci nejdůležitější je, abyste nesmí mít podívat se na vše, co je zachycena; pečlivě. Poskytuje Profiler funkce, které pomáhají efektivně zobrazit zachycená data. V Vlastnosti Dialogové okno (v Soubor nabídky, klepněte na tlačítko Vlastnosti), Profiler umožňuje omezit data zobrazená odebráním sloupce dat nebo události, seskupení (třídění) sloupce dat a použití filtry. Můžete hledat celý trasování nebo konkrétního sloupce pro specifické hodnoty (na Upravit nabídky, klepněte na tlačítko Najít). Můžete také uložit data do tabulky serveru SQL Profiler (na na Soubor příkaz Uložit jako a potom klepněte na tlačítko Tabulka) a spustit dotazy SQL proti němu.

Buďte opatrní, proveďte filtrování pouze trasování dříve uloženého souboru. Je-li provedení těchto kroků v trasování aktivní, je riziko ztráty dat, která byla sebrána od spuštění trasování. Uložit aktivní trasování do souboru nebo první tabulky (na Soubor nabídky, klepněte na tlačítko Uložit jako) a pak znovu (na Soubor nabídky, klepněte na tlačítko Otevřít) před pokračováním. Při práci na souboru uloženého trasování filtrování neodebere trvale filtrovány data, stačí nemá Zobrazit všechna data. Můžete přidat a odebrat události a sloupce dat jako potřebné pomoci zaměřit hledání.

Co hledat:
  • Jaké příkazy v čele řetěz blokování má číslo SPID provedení v rámci aktuální transakce?
    Filtrovat data trasování konkrétní číslo SPID, který stojí v čele blokování řetězce (na Soubor nabídky, klepněte na tlačítko Vlastnosti; potom v Filtry číslo SPID hodnotu zadat kartu). Potom si prohlédněte příkazy, má provedeny před čas ji byla blokování další identifikátory SPID. Pokud zahrnete Událostí transakce jim umožňuje snadno identifikovat v případě, že transakce byla spuštěna. V opačném případě můžete hledat Text sloupec pro počáteční, ukládání, potvrzení nebo vrácení transakce zpět operace. Použít open_tran Hodnota od sysprocesses Tabulka pro zajištění zachytit všechny události transakce. Znalost provedeny příkazy a kontext transakce vám umožní Zjistěte, proč SPID je zámky.

    Nezapomeňte, že můžete odebrat události a data sloupce. Namísto hledání na obou spuštění a dokončení Zvolte události. Pokud blokování identifikátory SPID nejsou uložené procedury, odebratSP: spouštění nebo SP: dokončeno události; na SQLBatch a VZDÁLENÉ VOLÁNÍ PROCEDUR události se zobrazí volání procedury. Zobrazit pouze události SP při Potřebujete zjistit úroveň podrobností.
  • Co je doba trvání dotazy pro identifikátory SPID v čele zablokování řetězy?
    Pokud zahrnete dokončené události výše, Doba trvání sloupec zobrazí čas spuštění dotazu. To může pomoci Dlouhotrvající dotazy, které jsou příčinou blokování Identifikujte. Chcete-li zjistit, proč dotaz pracuje pomalu, zobrazení CPU, Pro čtení, a Zápisy sloupce, jakož i Plán vykonání událost.

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

V následující tabulce mapuje obvyklé příznaky jejich možné příčiny. Číslo uvedené v Scénář sloupec odpovídá číslu v "společné blokování Scénáře a usnesení"tohoto článku v části níže. Na Waittype, Open_Tran, a Stav sloupce odkázat. sysprocesses informace. Na Řeší? sloupec udává, zda bude na vyřešení blokování jeho vlastní.

Zmenšit tuto tabulkuRozšířit tuto tabulku
ScénářWaittypeOpen_TranStavŘeší?Ostatní Příznaky
1Nenulová>= 0Spustitelné pracovníAno, po dokončení dotazu.Physical_IO procesoru nebo bude zvyšovat Využití_paměti sloupce. Bude doba trvání pro dotaz Vysoká po dokončení.
20x0000> 0v režimu spánkuNe, ale může být utracena číslo SPID.Signál pozornost může vidět v okna profilování došlo k trasování pro toto SPID udávající časový limit dotazu nebo Storno.
30x0000> = 0Spustitelné pracovníNe. Nevyřeší dokud klienta fetches všechny řádky nebo ukončí připojení. Můžete SPID usmrcena, ale může trvat až 30 sekund.Pokud open_tran = 0, a obsahuje číslo SPID uzamčení při izolace transakcí úroveň je výchozí (COMMMITTED čtení), je pravděpodobné příčiny.
4Se liší> = 0Spustitelné pracovníNe. Nevyřeší dokud klienta, zruší dotazy nebo ukončí připojení. Můžete identifikátory SPID být utracena, ale může trvat až 30 sekund.Na název hostitele ve sloupci sysprocesses číslo SPID v čele blokování řetězce budou stejné jako jedno číslo SPID je blokuje.
50x0000> 0vrácení zpětAno.Aplikace pozornost signálu může vidět Profiler trasování pro toto SPID uvede došlo k vypršení časového limitu dotazu nebo Storno nebo byla jednoduše prohlášení vrácení zpět vydáno.
60x0000> 0v režimu spánkuNakonec. Určuje systém Windows NT, relace je žádné aktivní déle, serveru SQL Server připojení se přeruší.Na last_batch hodnota sysprocesses je mnohem starší než aktuální čas.

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

Níže uvedené scénáře budou mít charakteristiky uvedených ve výše uvedené tabulce. Tato část obsahuje další podrobnosti, případně stejně jako cesty k rozlišení.
  1. Blokování způsobené normálně spuštěn dotaz s dlouhou dobu spuštění

    Rozlišení:
    Řešení pro tento typ problému blokování je hledat způsoby optimalizace dotazu. Skutečně může tato třída blokování problém pouze být problémy s výkonem a vyžadují, abyste ji vykonávají jako takové. Informace o odstraňování specifických zpomalit běžící dotaz, naleznete v následujícím článku znalostní báze Microsoft Knowledge Base:
    243589 Jak řešit zpomalit spouštění dotazů serveru SQL Server 7.0 nebo novější
    Výkon aplikací řešení potíží naleznete v následujícím článku znalostní báze Knowledge Base:
    224587 JAK: Poradce při potížích Výkon aplikace SQL Server
    Další informace naleznete Sledování výkonu a optimalizace návody SQL Server 2008 Books Online téma na následujícím webu MSDN:
    http://msdn.microsoft.com/en-us/library/ms187830.aspx
    Máte-li dotaz dlouhotrvající, který blokuje ostatní uživatelé a nemohou být optimalizována, zvažte její přesunutí z OLTP prostředí na 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í SPID je v režimu spánku nebo příkaz, čeká ještě transakce, jejichž úroveň vnoření (@@ TRANCOUNT, open_tran z sysprocesses) je větší než nula. Tato situace může nastat, pokud aplikace dojde k vypršení časového limitu dotazu nebo problémy zrušení bez vydání také požadovaný počet vrácení nebo potvrzení prohlášení. Jakmile SPID obdrží časový limit dotazu nebo na tlačítko Storno, bude ukončena aktuální dotaz a dávky, ale automaticky vrátit zpět ani potvrzení transakce. Aplikace je odpovědné, jako je SQL Server nelze předpokládat, že celá transakce musí být vrácena zpět jednoduše kvůli jediného dotazu stornována. Dotaz časový limit nebo Storno zobrazí jako událost signálu POZORNOST SPID v Trasování Profiler.

    Ukazuje to vydávat následující jednoduchý dotaz z Query Analyzer:

    BEGIN TRAN 
    SELECT * FROM SYSOBJECTS S1, SYSOBJECTS S2
    
    -- Issue this after canceling query
    SELECT @@TRANCOUNT
    ROLLBACK TRAN
    						
    Zatímco je spuštěn dotaz, klepněte na červený Storno tlačítko. Po dotazu je zrušena, označuje vyberte @@ TRANCOUNT úroveň vnoření transakce je jeden. Kdyby to bylo odstranění nebo aktualizace dotaz, nebo kdyby na vyberte použita HOLDLOCK, by všechny zámky, které získali stále probíhají. Dokonce i s dotazem, je-li jiný dotaz získá a zámky držené v transakci, jsou stále bude konat při výše uvedených Výběr byl zrušen.

    Rozlišení:

    • Aplikace musí být řádně spravovat vnoření transakce úrovně, nebo se může způsobit blokování problém po zrušení dotaz tímto způsobem. To lze provést několika způsoby:
      1. V klientské aplikace, obslužná rutina chyb Odeslat Pokud @@ TRANCOUNT > 0 vrácení TRAN následující jakékoli chyby, i když klientská aplikace není věří, že je otevřené transakce. Je požadováno, protože během volat uloženou proceduru nelze spuštění dávky transakce bez vědomí klientské aplikace. Poznámka: určité podmínky, jako je například zrušení dotazu a zabránit provádění postupu v minulosti aktuální prohlášení tak i v případě, že postup obsahuje logiku kontrola Pokud @@ Chyba <> 0 a přerušení transakce, nebude tento kód vrácení zpět provést v takových případech.
      2. Použít nastavení XACT_ABORT na připojení nebo v libovolném uložené procedury, které začínají transakcí a není čištění následující došlo k chybě. V případě, že chyba spuštění toto nastavení bude přerušena všechna otevřená transakce a vrácení řízení klientovi. Poznámka: Tento T-SQL příkazy následující příkaz, který způsobil chybu nebudou provedeny.
      3. Pokud používáte sdružování připojení v aplikace, která otevře připojení a spustí malý počet dotazů před uvolnění připojení zpět do fondu, jako je například webová aplikace dočasně zakázat sdružování připojení může přispět ke zmírnění problému až do klientská aplikace je upravena odpovídajícím způsobem zpracování chyb. Podle zákaz sdružování připojení, uvolnění připojení způsobí fyzického odhlášení připojení serveru SQL Server, výsledkem postupné serveru zpět všechny otevřené transakce.
      4. Pokud je povoleno sdružování připojení a cílový server je SQL Server 2000, inovace v klientském počítači na součásti MDAC 2.6 nebo novější, může být výhodné. Tato verze součástí MDAC přidá kód zprostředkovatele OLE DB a ODBC ovladač tak, aby připojení by "obnovit" dříve, než je znovu použít. Toto volání sp_reset_connection přeruší všechny Server inicioval transakcí (DTC inicializovaná aplikace klienta jsou transakce neovlivní), obnoví výchozí databáze, nastavit možnosti a tak dále. Poznámka: připojení se resetuje, dokud je znovu použít z fondu připojení je tedy možné, že uživatel otevřít transakci a poté uvolněte připojení k fondu připojení, ale pravděpodobně nesmí být opětovně použito pro několik sekund, během této doby by zůstat otevřené transakce. Pokud připojení je opakovaně není, transakce bude ukončeno, když vyprší časový limit připojení a je odebrán z fondu připojení. Proto je optimální pro klienta žádost o přerušení transakce v jejich obslužná rutina chyb nebo použít nastavení XACT_ABORT ON, aby se zabránilo tomuto možnému zpoždění.
    • Skutečně, může být také tato třída blokování problém problémy s výkonem a vyžadují, abyste ji vykonávají jako takové. Pokud dotaz Doba provádění lze snížily, nevyskytuje se časový limit dotazu nebo na tlačítko Storno. Je důležité, aby aplikaci mohli zpracovat časový limit nebo zrušit scénáře by tepny, ale mohou také využívat zkoumání provádění dotazu.
  3. Blokování způsobené SPID, jehož odpovídající klientské aplikace načíst všechny řádky výsledek není k dokončení

    Po odeslání dotazu na server pro všechny aplikace k dokončení okamžitě musí načíst všechny řádky výsledek. Pokud nemá aplikace Nelze načíst všechny řádky výsledek, uzamčení může být ponecháno na tabulkách, blokování jiných uživatelé. Pokud používáte aplikaci, která odešle transparentně SQL příkazy k serveru aplikace musí převzít všechny řádky výsledek. Pokud jej není (a pokud jej nelze nakonfigurovat tak učinit), nebude moci blokování problém vyřešte. Chcete-li problému vyhnout, můžete omezit nedostatečně choval aplikací vytváření zpráv nebo podporu rozhodování databáze.

    Rozlišení:

    Aplikace musí být re-written načítat všechny řádky výsledek na dokončení.
  4. Blokování způsobené zablokování Klient Server

    Na rozdíl od konvenčního zablokování, zablokování není zjistitelné pomocí Správce RDBMS zámku. Je to způsobeno skutečností, že pouze jedna ze zdrojů potřebných pro zablokování je zámek serveru SQL Server. Na druhé straně zablokování je na úrovni aplikace klienta, přes které SQL Server nemá kontrolu. Následují dva příklady, jak k tomu může dojít, a možné způsoby aplikace můžete zabránit.

    1. Zablokování Klient Server s klientem Podproces
      Pokud má klient více otevřených připojení a jedinému podprocesu spuštění, může nastat následující zablokování. Pro stručnost termín "dbproc", které jsou použity se 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 má podprocesu aplikace jednoho klienta dvě otevřené připojení. Odesílá asynchronní operace SQL, na dbproc1. To znamená, že nečeká na návrat před provedením volání. Na Aplikace potom odešle jiná operace SQL na dbproc2 a čeká Chcete-li zobrazit výsledky k zahájení zpracování vrácených datech. Při spuštění dat vraceli (podle dbproc první odpovídá--předpokládá je dbproc1), zpracovává se dokončení vrátí všechna data na tomto dbproc. Je fetches výsledky dbproc1 až SPID1 získá blokováno na zámek v držení SPID2 (protože dvě dotazy jsou spuštěné asynchronně na serveru). V tomto okamžiku bude dbproc1 neomezeně dlouho čekat na další data. SPID2 na zámek nebyl blokován, ale pokusí odešlete data na klienta, dbproc2. Dbproc2 je ale účinně blokován na dbproc1 ve vrstvě aplikací jako jediný podproces provádění aplikace je používán dbproc1. To vede k zablokování serveru SQL Nelze rozpoznat nebo vyřešit, protože se pouze jedna zdrojů potřebných pro SQL Prostředek na serveru.
    2. Zablokování Klient Server s podprocesem, který za Připojení

      I v případě, že existuje samostatný podproces pro každé připojení na Klient, změnu toto zablokování přesto může dojít k uvedené 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 podobný například A, s výjimkou dbproc2 a SPID2 příkaz SELECT s úmyslem provádění řádek v době spuštění zpracování a předání každý řádek pomocí vyrovnávací paměti pro dbproc1 pro vložení, AKTUALIZACI nebo odstranění příkazu v téže tabulce. Nakonec SPID1 (provedení INSERT, UPDATE nebo DELETE) zablokování na zámek v držení SPID2 (provedení výběru). SPID2 dbproc2 klienta zapíše řádku výsledků. Dbproc2 potom pokusí předat řádek do vyrovnávací paměti dbproc1, ale zjistí dbproc1 zaneprázdněn (je blokován čekání na SPID1 dokončení aktuální vložení, který je blokováno na SPID2). V tomto okamžiku je blokován dbproc2 ve vrstvě aplikací podle dbproc1, jehož číslo SPID (SPID1) je blokováno na úrovni databáze SPID2. Znovu To vede k zablokování serveru SQL Server nelze rozpoznat nebo vyřešit, protože pouze jednoho zdroje je zdroj serveru SQL Server.
    Oba příklady a a b jsou základních problémů Vývojáři aplikací musí být vědomi. Že musí kód aplikace pro zpracování tyto případy vhodným způsobem.

    Rozlišení:

    Jsou dva spolehlivé řešení použít buď dotaz časový limit nebo vázané připojení.

    • Časový limit dotazu
      Když byl časový limit dotazu k dispozici, pokud dojde zablokování, bude přerušeno po pak časový limit se stane. Viz knihovny DB-Library nebo Další informace v dokumentaci ODBC o použití časový limit dotazu.
    • Vázané připojení
      Tato funkce umožňuje klientovi s více připojení je tak svázat do jediné transakce prostoru, připojení blokovat navzájem. Další informace naleznete v tématu použití" Vázané připojení"v tématu SQL Server 7.0 Books Online.
  5. Blokování způsobené SPID, V "zlatý" nebo vrácení stavu

    Dotaz změny dat, který je usmrcena nebo zrušena mimo z uživatelem definované transakce bude vrácena zpět. To může nastat také jako vedlejším efektem restartování klientského počítače a jeho síťové relace. odpojení. Podobně bude vrácena dotazu vybrána jako oběť zablokování zpět. Modifikace dotazu dat často nelze vrátit zpět všechny rychlejší než změny byly původně použity. Například pokud odstranění, vložení nebo aktualizaci prohlášení byly spuštěny hodiny, může trvat nejméně hodinu vrátit zpět. Toto chování je očekávané, protože změny musí být zcela vrátit zpět nebo by transakční a fyzické integrity databáze ohrožení zabezpečení. Protože k tomu musí dojít SQL Server označí číslo SPID v "golden" nebo vrácení stavu (což znamená, že nemůže být utracena nebo vybrané jako zablokování oběti). To lze často určit pozorováním výstup sp_who, což může znamenat vrácení zpět příkazu. Na Stav sloupec sys.sysprocesses označí vrácení stavu, který se zobrazí také v sp_who výstupní nebo sledování činnosti serveru SQL Server Management Studio.
    Rozlišení:

    Číslo SPID dokončení vracení musí čekat změny, které byly provedeny.

    Pokud je server vypnut midst z Tato operace bude databázi v režimu zotavení po restartování počítače a budou nepřístupné, dokud jsou zpracovány všechny otevřené transakce. Po spuštění obnovení trvá v podstatě stejné množství času na transakci jako spuštění obnovení a databáze není přístupný během tohoto období. Tedy vynucení. často bude server na opravu SPID ve stavu vrácení zpět kontraproduktivní.

    Chcete-li se této situaci vyhnout, neprovádějte velké během doby zaneprázdněna systémech OLTP dávkové operace INSERT, UPDATE nebo DELETE. Pokud je to možné proveďte tyto operace obdobích nízké aktivity.
  6. Blokování způsobené osamocené připojení

    Pokud pastí klientské aplikace nebo klienta Po restartování pracovní stanice, není pravděpodobně síťové relace serveru okamžitě zrušena za určitých podmínek. Z pohledu na serveru klient stále jeví a může být stále žádné zámky, získali zachovány. Další informace získáte klepnutím na následující číslo článku databáze Microsoft Knowledge Base:
    137983Jak řešit osamocené připojení serveru SQL Server

    Rozlišení:

    Pokud aplikace klienta odpojila bez vhodně čištění svých zdrojů, je číslo SPID ukončit pomocí příkaz DEZAKTIVAČNÍ. Příkaz DEZAKTIVAČNÍ trvá SPID hodnota jako vstup. Například Chcete-li kill 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í náležejících k interval mezi kontrolami DEZAKTIVAČNÍ příkazu.

Aplikace zapojení blokování problémy

Může mít tendenci zaměřit na ladění na straně serveru a Když problém blokování platformu problémy. Ale to nemá obvykle vést k řešení a může absorbovat čas a energii lepší směřovat zkoumání klientskou aplikací a dotazy ji odešle. Bez ohledu na to, co úroveň viditelnosti zpřístupňuje aplikace týkající se databáze zavolá přičemž se blokování problém však často vyžaduje i kontrolu přesné příkazy SQL předložené žádosti a aplikace přesné chování týkající se zrušení dotazu, správy připojení, načítání všechny výsledné řádky atd. Je-li vývojový nástroj neumožňuje explicitní řídit správu připojení, zrušení dotazu, časový limit dotazu, výsledek načítání a tak dále, blokování problémy nemusí být schopna. Tento potenciál by měly být zkoumány těsně před výběrem nástroj pro vývoj aplikací, pro SQL Server, zejména pro podnikové prostředí OLTP.

Je Důležité je, že 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 by měly být hodnoceny pro každou dotaz. Každý dotaz a transakce by měla být co nejjednodušší. Dobrý musí být vykonávána disciplíny řízení připojení. Pokud není provedeno, je možné, že aplikace může za nízké zobrazit přijatelného výkonu počtu uživatelů, ale výkon se může významně snížit jako číslo Uživatelé nahoru stupnic.

Správné používání a návrh dotazu Je-li podporující mnoho tisíce současných Microsoft SQL Server uživatelé na jediném serveru, s malým množstvím blokování.

Vlastnosti

ID článku: 224453 - Poslední aktualizace: 26. dubna 2011 - Revize: 8.0
Informace v tomto článku jsou určeny pro produkt:
  • 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
Klíčová slova: 
kbsqlsetup kbhowto kbtshoot kbexpertiseinter kbinfo kbmt KB224453 KbMtcs
Strojově přeložený článek
Důležité: Tento článek byl přeložen pomocí software společnosti Microsoft na strojový překlad, ne profesionálním překladatelem. Společnost Microsoft nabízí jak články přeložené překladatelem, tak články přeložené pomocí software na strojový překlad, takže všechny články ve Znalostní databázi (Knowledge Base) jsou dostupné v češtině. Překlad pomocí software na strojový překlad ale není bohužel vždy dokonalý. Obsahuje chyby ve skloňování slov, skladbě vět, nebo gramatice, podobně jako když cizinci dělají chyby při mluvení v češtině. Společnost Microsoft není právně zodpovědná za nepřesnosti, chyby nebo škody vzniklé chybami v překladu, nebo při použití nepřesně přeložených instrukcí v článku zákazníkem. Společnost Microsoft aktualizuje software na strojový překlad, aby byl počet chyb omezen na minimum.
Projděte si také anglickou verzi článku:224453

Dejte nám zpětnou vazbu

 

Contact us for more help

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