Transaksi Bocor SQL Server

Saya memiliki database yang diakses oleh sekitar 50 klien melalui TDS melalui TCP yang sepertinya tidak akan merilis ruang log. Jumlah proses tetap di sekitar 50 yang diharapkan, dan beberapa di antaranya berumur panjang (> 120 hari).

Basis data sekarang memiliki 40 gb dalam ruang log (hanya memiliki 14 gb data), 39 gb gratis. Karena keterbatasan ruang pada drive, saya ingin menyusut ke sesuatu yang lebih masuk akal (10gb-ish). Ketika saya mengeksekusi DBCC SHRINKFILE('db_log', 10000), ia mengembalikan kesalahan bahwa akhir log sedang digunakan.

Untuk membebaskan akses ke akhir log, saya berusaha menempatkan database dalam mode pengguna tunggal dengan yang berikut ini:

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

tetapi skrip mengembalikan pesan berikut yang diulang ratusan kali:

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

Yang membuat saya percaya bahwa di suatu tempat, saya meninggalkan beberapa transaksi tanpa komitmen. Saya tidak mengetahui adanya proses yang akan dengan sengaja membuka banyak transaksi ini pada satu waktu, jadi saya pikir mereka harus menumpuk dari waktu ke waktu, tidak pernah ditutup.

Pertanyaan: Bagaimana cara menemukan proses atau skrip yang menyinggung atau mengapa log tidak dirilis?

sys.dm_tran_active_transactionsmenunjukkan 18 transaksi yang wajar dengan tujuan yang dapat dimengerti. sp_whohanya menunjukkan proses yang saya sadari.

Versi 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)

Versi Server:

Windows Server 2008 R2 x64 - Datacenter 4 vCPUs, memori 16GB, Lewati disk untuk data dan log, disk OS adalah VHD

pada Hyper-V (Windows Server 2008 R2 SP1 x64 Datacenter) Dual Intel X5650 (6 inti, 12 utas pada 2.67GHz) memori 72 GB

Hypervisor hanya memiliki tiga VM dan tidak menunjukkan penggunaan sumber daya yang tinggi. SQL Server VM menunjukkan ~ 40% CPU dalam beban dan 99% cache hit.

Ada perintah SQL yang akan menampilkan transaksi OPEN. (DBCC OPENTRAN)

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

Menampilkan informasi tentang transaksi aktif tertua dan transaksi terdeplikasi terdistribusi dan tidak terdistribusi, jika ada, dalam database yang ditentukan. Hasil ditampilkan hanya jika ada transaksi aktif atau jika database berisi informasi replikasi

Untuk alasan apa pun, tampaknya tidak ada yang menahan file log terbuka. Dengan menjalankan beberapa cadangan log (> 10), akhir log dilepaskan dan penyusutan dapat terjadi. Tidak yakin mengapa ... tapi itu berhasil.

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

Jika saya memahami pertanyaan Anda dengan benar, Anda memiliki log transaksi 40Gb dengan 39Gb gratis? Log adalah struktur melingkar, terdiri dari File Log Virtual yang lebih kecil. Setiap kali VLF penuh, SQL mulai menggunakan VLF berikutnya. (Tidak harus dalam urutan yang sama dengan VLF di file). Ketika Anda mengecilkan file log itu melepaskan ruang kosong dari AKHIR log. Jika bagian aktif dari log ada di akhir, tidak ada ruang yang bisa dibebaskan, jika ada di tengah-tengah suatu tempat maka Anda hanya akan dapat memperoleh kembali sebagian ruang tersebut. DBCC LOGINFO akan menunjukkan kepada Anda semua VLF di log dan status yang menunjukkan bahwa VLF saat ini berisi semua log aktif. Saya percaya bahwa status 2 aktif dan 0 tidak aktif. Saya yakin google dapat memberikan informasi lebih lanjut jika diperlukan.

Jika masalah Anda hanyalah bahwa porsi aktif saat ini di akhir maka taruhan terbaik Anda hanya menunggu sampai bergulir kembali ke awal, kemudian susutkan log. Ini bisa memakan waktu yang mengejutkan, bersabarlah. Itu akan sampai di sana.
Juga ingat bahwa jika bagian APAPUN dari VLF saat ini aktif maka seluruh VLF tetap aktif.

Namun Anda harus memantau ukuran file log, jika tiba-tiba tumbuh lagi maka Anda perlu melakukan investigasi penyebabnya. Anda harus menghindari penyusutan yang tidak perlu dari file log, ketika itu tumbuh lagi itu dapat memperlambat kinerja.

Informasi lebih lanjut tentang VLF dapat ditemukan di posting blog Kimberly Tripps di sini .