Secara default, Paket Layanan 1 untuk SQL Server 2014 dan Paket Layanan 3 untuk SQL Server 2012 menyertakan perbaikan ini dan Anda tidak perlu menambahkan bendera pelacakan apa pun untuk mengaktifkan perbaikan. Untuk mengaktifkan perbaikan setelah menginstal salah satu pembaruan kumulatif di bagian Resolusi, Anda harus memulai Microsoft SQL Server dengan menambahkan bendera pelacakan 1236 ke parameter pengaktifan.
Gejala
Asumsikan Anda menjalankan instans Microsoft SQL Server 2014, SQL Server 2012, SQL Server 2008, atau SQL Server 2008 R2 pada komputer yang berisi banyak prosesor. Ketika jumlah kunci (tipe sumber daya = DATABASE) untuk database tertentu melebihi ambang batas tertentu, Anda akan mengalami masalah performa berikut:
Nilai yang ditinggikan terjadi untuk jumlah spinlock LOCK_HASH.
Catatan: Lihat bagian "Informasi Selengkapnya" untuk informasi tentang cara memantau spinlock ini.
Kueri atau operasi yang memerlukan kunci database memerlukan waktu lama untuk diselesaikan. Misalnya, Anda mungkin melihat penundaan kinerja berikut:
- Login SQL Server
- Kueri server tertaut
- sp_reset_connection
- Transaksi
Catatan Untuk menemukan daftar kunci (tipe sumber daya = DATABASE) pada database tertentu, lihat bagian "Informasi Selengkapnya". Nilai ambang batas bervariasi menurut lingkungan.
Resolusi
Informasi pembaruan kumulatif
Masalah pertama kali diperbaiki dalam pembaruan kumulatif SQL Server berikut.
Pembaruan Kumulatif 13 untuk SQL Server 2008 R2 SP2 /en-us/help/2967540
Pembaruan Kumulatif 17 untuk SQL Server 2008 SP3 /en-us/help/2958696
Pembaruan Kumulatif 1 untuk SQL Server 2014 /en-us/help/2931693
Pembaruan Kumulatif 9 untuk SQL Server 2012 SP1 /en-us/help/2931078
Tentang pembaruan kumulatif untuk SQL Server
Setiap pembaruan kumulatif baru untuk SQL Server berisi semua hotfix dan semua perbaikan keamanan yang disertakan dengan pembaruan kumulatif sebelumnya. Lihat pembaruan kumulatif terbaru untuk SQL Server:
- Pembaruan kumulatif terbaru untuk SQL Server 2008 R2 SP2
- Pembaruan kumulatif terbaru untuk SQL Server 2008 SP3
- Pembaruan kumulatif terbaru untuk SQL Server 2014
- Pembaruan kumulatif terbaru untuk SQL Server 2012 SP1
Informasi perbaikan
Hotfix yang didukung tersedia dari Microsoft. Namun, hotfix ini dimaksudkan untuk memperbaiki masalah yang dijelaskan dalam artikel ini saja. Terapkan hotfix ini hanya ke sistem yang mengalami masalah khusus ini.
Jika hotfix tersedia untuk diunduh, terdapat bagian "Unduhan Hotfix Tersedia" di bagian atas artikel Basis Pengetahuan ini. Jika bagian ini tidak muncul, kirim permintaan ke Layanan Pelanggan dan Dukungan Microsoft untuk mendapatkan hotfix.
Catatan Jika terjadi masalah tambahan, atau jika pemecahan masalah diperlukan, Anda mungkin harus membuat permintaan layanan terpisah. Biaya dukungan biasa akan berlaku untuk pertanyaan dan masalah dukungan tambahan yang tidak memenuhi syarat untuk hotfix khusus ini. Untuk daftar lengkap nomor telepon Layanan Pelanggan dan Dukungan Microsoft atau untuk membuat permintaan layanan terpisah, kunjungi situs web Microsoft berikut:
/contactus/?ws=support Catatan: Formulir "Unduhan Hotfix Tersedia" menampilkan bahasa yang tersedia hotfix. Jika Anda tidak melihat bahasa Anda, itu karena hotfix tidak tersedia untuk bahasa tersebut.
Status
Microsoft telah mengonfirmasi bahwa ini adalah masalah dalam produk Microsoft sebagaimana tercantum di bagian "Berlaku untuk".
Informasi Selengkapnya
Saat sebuah aplikasi membuat koneksi ke SQL Server, aplikasi tersebut terlebih dahulu membuat konteks database. Secara default, koneksi akan mencoba mendapatkan kunci DATABASE dalam mode SH. Kunci SH-DATABASE akan dilepaskan saat koneksi dihentikan atau konteks database diubah selama masa koneksi berlangsung. Jika Anda memiliki banyak koneksi aktif yang menggunakan konteks database yang sama, Anda dapat memiliki banyak kunci tipe sumber daya DATABASE untuk database tertentu tersebut.
Di komputer yang memiliki 16 CPU atau lebih, hanya objek tabel yang menggunakan skema penguncian berpartisi. Namun, kunci database tidak dipartisi. Oleh karena itu, semakin besar jumlah kunci database, semakin lama waktu yang dibutuhkan SQL Server untuk mendapatkan kunci pada database. Sebagian besar aplikasi tidak mengalami masalah apa pun yang disebabkan oleh desain ini. Tetapi segera setelah jumlahnya melebihi ambang batas tertentu, kerja dan waktu tambahan diperlukan untuk mendapatkan kunci. Meskipun biayanya hanya mikro detik untuk setiap kunci tambahan, total waktu dapat meningkat dengan cepat karena ember hash kunci dilindungi dengan menggunakan spinlock. Hal ini menyebabkan siklus CPU tambahan dan menunggu pekerja tambahan untuk mendapatkan kunci.
Hotfix ini memperkenalkan partisi kunci DATABASE saat bendera pelacakan T1236 diaktifkan saat memulai. Mempartisi kunci DATABASE menjaga kedalaman daftar kunci tetap dapat dikelola di setiap partisi lokal. Ini secara signifikan mengoptimalkan jalur akses yang digunakan untuk mendapatkan kunci DATABASE.
Untuk memantau spinlock LOCK_HASH, Anda dapat menggunakan kueri berikut. ATUR NOCOUNT AKTIF
BUAT TABEL #spinlock_stats([CaptureTime] tanggalwaktu,[name] nvarchar(512),[tanaman] bigint,
[berputar] bigint,[spins_per_collision] nyata,[sleep_time] bigint,[mundur] int)
NYATAKAN @counter int = 1
SEMENTARA 100 @counter<
BEGIN
SISIPKAN KE #spinlock_stats PILIH GETDATE() sebagai "CaptureTime" , * DARI sys.dm_os_spinlock_stats WHERE [name] = 'LOCK_HASH'
TUNGGU PENUNDAAN '00:00:05'
ATUR @counter +=1
END
PILIH * DARI #spinlock_stats URUTKAN BERDASARKAN [CaptureTime]
DROP TABEL #spinlock_stats Untuk informasi selengkapnya tentang mendiagnosis dan mengatasi persaingan spinlock di SQL Server, buka dokumen berikut:
Mendiagnosis dan Mengatasi Persaingan Spinlock di SQL Server Catatan Meskipun dokumen ini ditulis untuk SQL Server 2008 R2, informasi ini masih berlaku untuk SQL Server 2012.
Referensi
Untuk informasi selengkapnya tentang bendera pelacakan di SQL Server 2012, buka situs web TechNet berikut:
Informasi tentang bendera pelacakan di SQL Server 2012
Untuk informasi selengkapnya tentang cara menemukan jumlah kunci database di pengguna per database, gunakan kueri berikut untuk menghitung nilai ini:pilih Resource_database_id, resource_type, request_mode, request_status,
hitung (*) 'LockCount' dari sys.dm_tran_locks
Kelompokkan berdasarkan Resource_database_id, resource_type, request_mode, request_status