it-swarm-eu.dev

"Překročení časového limitu požadavku na zámek překročeno" Chyba při pokusu o zobrazení hierarchií DB

Mám problémy s databází.

  1. Dokážu spouštět základní dotazy, i když mnohem pomaleji než obvykle.

  2. Když se pokusím zobrazit stromy hierarchie pro tabulky, zobrazení nebo procedury v Průzkumníku objektů SSMS, dostanu lock request time out period exceeded.

  3. Moje sestavy SSRS, které běží na objektech v této databázi, se již nedokončují.

  4. Úlohy spojené s procedurami uloženými v této databázi se také nespouštějí.

Zkusil jsem použít sp_who2 najít a zabít všechna připojení v databázi, to však problém nevyřešilo.

Co se to tu děje? Jak to mohu vyřešit?

sql-serversql-server-2008
17
Lloyd Banks

Bylo to způsobeno neustálým vrácením transakce. Musel jsem nakonec restartovat serverový cluster

13
Lloyd Banks

Bez ohledu na Harware, možná budete muset spustit skript pro kontrolu, jaké jsou činnosti zadržující SQL Session, jedním z běžných scénářů není použití Implicit transactions Option v SQL Server Management Studio.

5
Turbot

Tento problém jsem dostal, když jsem začal explicitní transakci, ve které jsem vytvořil tabulku v tempdb ze skriptu spuštěného v jiné databázi (nikoli tempdb). Když jsem provedl transakci, nezdálo se, že by uvolnění zámku na stole, který jsem vytvořil v tempdb.

Díky tato stránka , jsem USEd tempdb a provedl DBCC OPENTRAN a dostal SPID připojení k tempdb, které způsobovalo zámek. Pak já KILL <SPID number> zabít.

Ne moc půvabné a ztratil jsem všechny informace v tabulce, kterou jsem vytvořil v tempdb, ale v mém případě to bylo v pořádku.

3
Baodad

Existuje tolik věcí, že by to mohlo být, že vše, co mohu nabídnout, je několik otázek, které vám pomohou vést k odpovědi.

  1. Je DB na serveru vyhrazena právě spuštěnému serveru SQL? Pokud tomu tak není, mohou jiné procesy narušovat krádež drahocenného času procesoru.

  2. Je DB server v podstatě nedostatek paměti? SQL Server se pokusí přidělit každý bajt, který může, ale pokud je kapacita a vaše dotazy vyžadují načtení více dat, musí se vrátit k použití virtuální paměti, což radikálně zvyšuje množství času, který mohou trvat i jednoduché dotazy.

  3. Je síťová šířka pásma serveru DB malá, aby bylo možné včas přenášet data?

Na konci dne to zní jako stroj, na kterém hostujete SQL Server, je pod velikostí toho, co se snažíte udělat. Je zcela možné, že jste konečně dosáhli těch hardwarových limitů, kde výkon radikálně klesá. Pokud se jedná o tento případ (výše uvedené otázky vám to pomohou určit), budete chtít přesunout DB na server, který je správně dimenzován pro množství dat (a dotazů), které se pokoušíte zpracovat.

To by mohlo znamenat použití rychlejších procesorů, rychlejších jednotek nebo jen instalace více paměti RAM.

1
NotMe

"Když se pokouším zobrazit stromy hierarchie pro tabulky, pohledy nebo procedury v Průzkumníku objektů SSMS, překročila se doba vypršení požadavku na zámek."

Měl jsem úplně stejný problém. Šel jsem do okna provádění dotazu a; zadaný a provedený příkaz ROLLBACK.

Vypadá to, že některé z řady výroků, které jsem před tím provedl, byly otevřené transakce. Konkrétně proto, že některé z nich obsahují příkazy DDL. Jakmile jsem vydal vrácení, hierarchie objektů začaly fungovat.

1
T.S.

Jak již mnozí zdůraznili, obvykle existuje dlouhodobá transakce, většinou způsobila, že mi slečna použila SET IMPLICIT TRANSACTIONS ON, což by se nemělo vůbec používat. Chcete-li zjistit, proč zkontrolovat Brent Ozar je insightfull článek

Seznam následujících trvajících transakcí můžete získat pomocí následujícího dotazu.

SELECT
    [s_tst].[session_id],
    [s_es].[login_name] AS [Login Name],
    DB_NAME (s_tdt.database_id) AS [Database],
    [s_tdt].[database_transaction_begin_time] AS [Begin Time],
    [s_tdt].[database_transaction_log_bytes_used] AS [Log Bytes],
    [s_tdt].[database_transaction_log_bytes_reserved] AS [Log Rsvd],
    [s_est].text AS [Last T-SQL Text],
    [s_eqp].[query_plan] AS [Last Plan]
FROM
    sys.dm_tran_database_transactions [s_tdt]
JOIN
    sys.dm_tran_session_transactions [s_tst]
ON
    [s_tst].[transaction_id] = [s_tdt].[transaction_id]
JOIN
    sys.[dm_exec_sessions] [s_es]
ON
    [s_es].[session_id] = [s_tst].[session_id]
JOIN
    sys.dm_exec_connections [s_ec]
ON
    [s_ec].[session_id] = [s_tst].[session_id]
LEFT OUTER JOIN
    sys.dm_exec_requests [s_er]
ON
    [s_er].[session_id] = [s_tst].[session_id]
CROSS APPLY
    sys.dm_exec_sql_text ([s_ec].[most_recent_sql_handle]) AS [s_est]
OUTER APPLY
    sys.dm_exec_query_plan ([s_er].[plan_handle]) AS [s_eqp]
where [s_tdt].[database_transaction_begin_time] is not null
ORDER BY
    [Begin Time] ASC;

https://www.brentozar.com/archive/2018/02/set-implicit_transactions-one-hell-bad-idea/

0
Julio Nobre