SQL Server 유출 트랜잭션

로그 공간을 공개하지 않는 것처럼 보이는 TCP를 통한 TDS를 통해 약 50 개의 클라이언트가 데이터베이스에 액세스했습니다. 프로세스 수는 약 50 개 정도이며, 그 중 일부는 수명이 길다 (> 120 일).

데이터베이스에는 이제 로그 공간이 40GB (14GB 데이터 만 있음), 39GB는 사용 가능합니다. 드라이브의 공간 제한으로 인해 더 합리적인 (10gb-ish)로 축소하고 싶습니다. 내가 실행 DBCC SHRINKFILE('db_log', 10000)하면 로그 끝이 사용 중이라는 오류가 반환됩니다.

로그 끝에 자유롭게 액세스하기 위해 다음을 사용하여 데이터베이스를 단일 사용자 모드로 설정하려고 시도했습니다.

ALTER DATABASE db SET SINGLE_USER WITH ROLLBACK IMMEDIATE
GO
ALTER DATABASE db SET MULTI_USER
GO

그러나 스크립트는 수백 번 반복 된 다음 메시지를 반환합니다.

Nonqualified transactions are being rolled back. Estimated rollback completion: 100%.

어딘가에, 나는 일부 거래를 미확정 상태로두고 있다고 믿게합니다. 한 번에이 많은 트랜잭션을 의도적으로 여는 프로세스를 알지 못하므로 시간이 지남에 따라 누적되어 닫히지 않아야한다고 생각합니다.

질문 : 문제가있는 프로세스 또는 스크립트를 찾으려면 어떻게합니까? 또는 로그가 해제되지 않는 이유는 무엇입니까?

sys.dm_tran_active_transactions이해하기 쉬운 목적으로 합리적인 18 건의 거래를 보여주고 있습니다. sp_who내가 아는 프로세스 만 보여줍니다.

SQL Server 버전 :

Microsoft SQL Server 2008 R2 (RTM) - 10.50.1600.1 (X64) 
Apr  2 2010 15:48:46 
Copyright (c) Microsoft Corporation
Enterprise Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor)

서버 버전 :

Windows Server 2008 R2 x64-Datacenter 4 vCPU, 16GB 메모리, 데이터 및 로그를위한 디스크 통과, OS 디스크는 VHD

Hyper-V (Windows Server 2008 R2 SP1 x64 데이터 센터) 듀얼 Intel X5650 (6 코어, 2.67GHz에서 12 스레드) 72GB 메모리

하이퍼 바이저에는 3 개의 VM 만 있으며 리소스 사용량이 많지 않습니다. SQL Server VM은로드시 ~ 40 % CPU와 99 % 캐시 적중을 보여줍니다.

OPEN 트랜잭션을 표시하는 SQL 명령이 있습니다. (DBCC 오픈 트랜)

http://msdn.microsoft.com/en-us/library/ms182792.aspx

지정된 데이터베이스 내에서 가장 오래된 활성 트랜잭션과 가장 오래된 분산 및 비 분산 복제 트랜잭션에 대한 정보를 표시합니다. 활성 트랜잭션이 있거나 데이터베이스에 복제 정보가 포함 된 경우에만 결과가 표시됩니다

어떤 이유로 든 로그 파일을 열어 두는 것이 아무것도없는 것처럼 보입니다. 여러 로그 백업 (> 10)을 실행하면 로그 끝이 해제되어 축소가 발생할 수 있습니다. 왜 그런지 모르겠지만 ... 효과가있었습니다.

backup log db to disk = '\\l-backup1\drop\2012-12-23_db_log.bak' with stats = 1
go 15
dbcc shrinkfile('db_log', 10240)
go

귀하의 질문을 올바르게 이해하고 있다면 39Gb가 무료 인 40Gb 트랜잭션 로그가 있습니까? 로그는 더 작은 가상 로그 파일로 구성된 원형 구조입니다. VLF가 가득 찰 때마다 다음 VLF를 사용하여 SQL이 시작됩니다. VLF가 파일에있는 순서와 반드시 같은 것은 아닙니다. 로그 파일을 축소하면 로그 끝에서 여유 공간이 해제됩니다. 로그의 활성 부분이 끝에 있으면 공간을 확보 할 수 없으며 중간에 있으면 공간의 일부만 회수 할 수 있습니다. DBCC LOGINFO는 로그의 모든 VLF와 현재 VLF에 활성 로그가 포함되어 있음을 보여주는 상태를 보여줍니다. 상태 2가 활성화되어 있고 0이 비활성화되어 있다고 생각합니다. 필요한 경우 Google이 더 많은 정보를 제공 할 수 있다고 확신합니다.

문제가 활성 부분이 현재 끝에 있다는 것이라면 가장 좋은 방법은 다시 시작으로 돌아갈 때까지 기다린 다음 로그를 줄이는 것입니다. 시간이 오래 걸릴 수 있습니다. 인내심을 가지십시오. 도착할 것이다.
또한 VLF의 일부가 현재 활성 상태이면 전체 VLF가 활성 상태로 유지됩니다.

그러나 로그 파일의 크기를 모니터해야합니다. 예기치 않게 다시 커지면 원인을 조사해야합니다. 불필요한 로그 파일 축소를 피해야합니다. 다시 커지면 성능이 저하 될 수 있습니다.

VLF에 대한 자세한 내용은 Kimberly Tripps 블로그 게시물 ( 여기)을 참조하십시오 .