DB 계층을 보려고 할 때 "잠금 요청 시간 초과 기간이 초과되었습니다"오류

데이터베이스에 문제가 있습니다.

1. 평소보다 훨씬 느리지 만 기본 쿼리를 실행할 수 있습니다.

2. SSMS Object Explorer에서 테이블, 뷰 또는 프로 시저의 계층 구조 트리를 보려고하면을 얻습니다 lock request time out period exceeded.

3. 이 데이터베이스의 개체에서 실행되는 SSRS 보고서가 더 이상 완료되지 않습니다.

4. 이 데이터베이스에 저장된 프로 시저와 연관된 작업도 실행되지 않습니다.

sp_who2데이터베이스에서 모든 연결을 찾아서 종료 하려고했지만 문제가 해결되지 않았습니다.

무슨 일이야? 이 문제를 어떻게 해결할 수 있습니까?

트랜잭션의 영구 롤백으로 인해 발생했습니다. 결국 서버 클러스터를 다시 시작해야했습니다

Harware 고려 사항을 제외하고 SQL 세션을 보류하는 활동이 무엇인지 확인하기 위해 스크립트를 실행해야 할 수도 있습니다. 일반적인 시나리오 중 하나는 Implicit transactions OptionSQL Server Management Studio에서 를 사용하지 않는 것 입니다.

tempdb가 아닌 다른 데이터베이스에서 실행되는 스크립트에서 tempdb에 테이블을 생성하는 명시 적 트랜잭션을 시작할 때이 문제가 발생했습니다. 트랜잭션을 커밋 할 때 커밋은 tempdb에서 만든 테이블의 잠금을 해제하지 않는 것 같습니다.

이 페이지 덕분에 나는 USEtempdb를 만들고 실행 DBCC OPENTRAN하여 잠금을 발생시키는 tempdb에 대한 연결의 SPID를 얻었습니다. 그럼 난 KILL <SPID number>죽일 거야

매우 우아하지는 않았고 tempdb에서 만든 테이블의 모든 정보를 잃어 버렸지 만 제 경우에는 괜찮습니다.

제가 제공 할 수있는 모든 것은 답변을 향한 안내를위한 몇 가지 질문입니다.

1. 서버의 DB가 SQL Server를 실행하기위한 전용입니까? 그렇지 않은 경우 다른 프로세서가 소중한 프로세서 시간을 훔쳐 간섭 할 수 있습니다.

2. DB 서버에 본질적으로 메모리가 부족합니까? SQL Server는 가능한 모든 단일 바이트를 할당하려고 시도하지만 용량이 충분하고 쿼리에 더 많은 데이터를로드해야하는 경우 가상 메모리를 사용하여 대체해야하므로 간단한 쿼리에 걸리는 시간도 크게 늘어납니다.

3. 적시에 데이터 전송을 처리하기 위해 DB 서버의 네트워크 대역폭이 작습니까?

하루가 끝나면 SQL Server를 호스팅하는 컴퓨터가 수행하려는 작업의 크기가 부족한 것처럼 들립니다. 성능이 급격히 떨어지는 하드웨어 한계에 도달했을 가능성이 있습니다. 이 경우 (위의 질문이이를 판단하는 데 도움이 될 것입니다.) 처리하려는 데이터 (및 쿼리)의 크기에 따라 적절한 크기의 서버로 DB를 이동해야합니다.

이는 더 빠른 프로세서, 더 빠른 드라이브 사용 또는 더 많은 RAM 설치를 의미 할 수 있습니다.

"SSMS 개체 탐색기에서 테이블, 뷰 또는 프로 시저의 계층 구조 트리를 보려고하면 잠금 요청 시간 초과 기간이 초과되었습니다."

나는 정확히 같은 문제가 있었다. 쿼리 실행 창으로갔습니다. 입력하고 실행 한 ROLLBACK명령문.

그 전에 내가 실행 한 일련의 진술 중 일부가 열린 거래를 유지 한 것처럼 보입니다. 특히 DDL 문이있는 곳도 있기 때문입니다. 롤백을 실행하면 객체 계층이 작동하기 시작했습니다.

많은 사람들이 이미 지적했듯이, 일반적으로 오래 지속되는 트랜잭션이 있는데, 대부분 내가 놓친 SET IMPLICIT TRANSACTIONS ON을 사용했기 때문에 전혀 사용해서는 안됩니다. Brent Ozar의 통찰력 기사 를 확인하는 이유를 보려면

어쨌든 다음 쿼리를 사용하여 오래 지속되는 보류 트랜잭션 목록을 얻을 수 있습니다.

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/