Eskalasi Kunci SQL Server

Pengantar

Database relasional mengikuti properti ACID dalam cara mengimplementasikan transaksi – Atomicity, Consistency, Isolation, dan Durability. Isolasi diperlukan untuk memastikan bahwa beberapa transaksi tidak dapat menyebabkan perubahan pada data dan membuat hasil akhirnya tidak konsisten. Untuk menjamin bahwa operasi tetap terisolasi, SQL Server menerapkan mekanisme Penguncian.

Mode Kunci dan Hirarki

Mekanisme SQL Server untuk kontrol konkurensi terlibat. Untuk mengoptimalkan kinerja dalam hal lock wait, deadlock, dan sejenisnya, Anda harus membuat keputusan berdasarkan skenario tertentu.

Di SQL Server, kunci dapat ditahan dengan berbagai cara, dan pada beberapa tingkat perincian. Mode Kunci adalah cara khusus yang harus dilakukan, dan levelnya adalah Hirarki Kunci.

Gambar 1 menunjukkan Mode Kunci yang tersedia di SQL Server untuk tingkat Isolasi Transaksi default (BACA BERKOMITMEN):

Ringkasan Eskalasi Penguncian

SQL Server dapat mengunci sumber daya di beberapa tingkatan. Itu tergantung pada tindakan yang paling efisien sesuai dengan sifat beban kerja. Tabel 1 menunjukkan sumber daya yang dapat dikunci.

• Kunci pada tingkat yang lebih terperinci (mis., Kunci Tingkat Baris) memungkinkan konkurensi yang lebih tinggi dan lebih sedikit pemblokiran.
• Kunci pada level yang lebih tinggi (mis., Kunci Level Tabel) mengurangi konkurensi. Mereka dapat menyebabkan lebih banyak pemblokiran, tergantung pada berapa lama pernyataan yang sebenarnya berlangsung.

SQL Server memilih tingkat penguncian yang diperlukan sesuai dengan metrik internal.

Eskalasi Kunci terjadi ketika kunci diubah dari tingkat granularitas yang lebih halus ke tingkat yang lebih kasar.

Misalnya, mengubah kunci baris menjadi kunci tabel (Lihat Tabel 1).

Alasan untuk Eskalasi Penguncian

Kunci di SQL Server bisa sangat mahal. Untuk setiap kunci yang diperoleh Manajer Kunci, SQL Server harus mencadangkan memori – 64 byte atau 128 byte. Jumlahnya tergantung pada apakah kita berurusan dengan sistem 32-bit atau 64-bit, masing-masing.

Karena jumlah kunci baris pada tabel meningkat, SQL Server harus memperoleh lebih banyak memori. Oleh karena itu, proses lain kelaparan, kehabisan memori.

Masuk akal untuk mengubah kunci baris dan kunci halaman menjadi kunci tingkat tabel (objek) tunggal. Itu terjadi ketika jumlah kunci untuk tabel itu melebihi 5000.

Kompromi terjadi ketika seluruh tabel tidak lagi tersedia untuk sesi lain dalam proses transaksi.

Menunjukkan Eskalasi Kunci

Kita dapat mendemonstrasikan Lock Escalation menggunakan kode di Listing 1.

Pertama-tama mari kita jelaskan tabelnya sedikit. Produksi.ProdukI adalah meja yang relatif kecil yang memuat sekitar 7777 baris. Elemen bangunan adalah kumpulan yang sama dari 77 baris yang digandakan 101 kali. Kode di Daftar 1 terdiri dari tiga versi pernyataan pembaruan yang sama, masing-masing terlampir dalam transaksi.

-- Listing 1: Demonstrating Lock Escalation

-- Update very few rows
BEGIN TRAN

use TSQLV4
GO
UPDATE Production.ProductsI SET unitprice='100.00'
WHERE unitprice='18.00';

ROLLBACK

-- Update a large number of rows
BEGIN TRAN

use TSQLV4
GO
UPDATE Production.ProductsI SET unitprice='100.00'
WHERE unitprice>'18.00';

ROLLBACK

-- Update over 5000 rows
BEGIN TRAN

use TSQLV4
GO
UPDATE Production.ProductsI SET unitprice='100.00';

ROLLBACK 

Untuk lebih jelasnya, kami akan merinci isi Listing 1.

Sebelum itu, mari kita amati Listing 2 – kueri untuk menampilkan kunci yang disimpan di database TSQLV4.

Tindakan pertama kami adalah mengeksekusi Listing 1a. Kemudian, kami menggunakan Listing 2 untuk memeriksa bagaimana Lock Manager melakukan penguncian dalam skenario. Kami mengeksekusi Listing 1a tanpa mengeluarkan pernyataan rollback. Dengan cara ini, kami mempertahankan kunci cukup lama, sehingga kueri di Daftar 2 dapat menangkapnya.

-- Listing 1a: Demonstrating Lock Escalation
-- Update very few rows

BEGIN TRAN

use TSQLV4
GO
UPDATE Production.ProductsI SET unitprice='100.00'
WHERE unitprice='18.00';

ROLLBACK

-- Listing 2: Displaying Locks Held in Database TSQLV4

USE TSQLV4
GO
SELECT 
resource_type
, DB_NAME (resource_database_id) database_name
--, OBJECT_NAME(resource_associated_entity_id) resource_name
, request_mode
, request_type
, request_status
, request_reference_count
, request_session_id
, resource_associated_entity_id
, OBJECT_NAME(resource_associated_entity_id) [object_name] --small obj ids
, getuser.login_name
FROM sys.dm_tran_locks
CROSS APPLY dmv.dbo.getuser(request_session_id) as getuser
WHERE DB_NAME (resource_database_id)='TSQLV4';

Saat kita menjalankan kueri di Listing 1a, dan kemudian memeriksa kunci menggunakan kueri di Listing 2, SQL Server mengembalikan hasil yang ditunjukkan pada Gambar 2.

404 baris dalam tabel memiliki unitprice='18.00' . Manajer Kunci mengunci baris-baris ini bersama dengan kunci lain dari tingkat mana pun yang diperlukan. Ini membuat jumlah baris Gambar 2 menjadi 467.

-- Listing 1b: Demonstrating Lock Escalation
-- Update a large number of rows
BEGIN TRAN

use TSQLV4
GO
UPDATE Production.ProductsI SET unitprice='100.00'
WHERE unitprice>'18.00';

ROLLBACK

Kami mengamati perilaku serupa ketika kami menjalankan kueri di Listing 1b. Kali ini, kita berurusan dengan 4406 baris. Ini mencerminkan jumlah baris pada tabel Production.ProductI memiliki harga satuan>18.00.

-- Listing 1c: Demonstrating Lock Escalation
-- Update over 5000 rows
BEGIN TRAN

use TSQLV4
GO
UPDATE Production.ProductsI SET unitprice='100.00';

ROLLBACK

Ketika kita melangkah lebih jauh dan mengeksekusi kode di Listing 1c, kita melihat perilaku yang berbeda (lihat Gambar 4).

Mencantumkan 1c mencoba memperbarui semua 7777 baris dalam tabel Production.ProductI. SQL Server menentukan bahwa mengunci begitu banyak baris tidak lagi efisien untuk menjamin isolasi. Sebaliknya, seluruh tabel terkunci.

Selengkapnya tentang Eskalasi Kunci

Kunci tabel menyiratkan bahwa tidak ada sesi lain yang dapat mengubah barisnya selama durasi transaksi, yang mungkin terjadi bahkan saat sesi pemblokiran tidak memanipulasi semua baris dalam tabel.

Perlu juga disebutkan bahwa faktor lain dapat memengaruhi cara kunci diperoleh dan ditingkatkan di SQL Server. Itu adalah tingkat isolasi yang dikonfigurasi, pengindeksan, dan tanda pelacakan.

Tanda jejak T1211 dan T1224 dapat diterapkan untuk menonaktifkan Eskalasi Kunci sepenuhnya. Eskalasi Kunci juga dapat dinonaktifkan dan diaktifkan untuk tabel tertentu dengan kode berikut:

-- Listing 5: Disable and Enable Lock Escalation

ALTER TABLE Production.ProductsI SET (LOCK_ESCALATION=DISABLE);

ALTER TABLE Production.ProductsI SET (LOCK_ESCALATION=TABLE);

Seseorang mungkin ingin melakukannya untuk mengurangi pemblokiran terkait penguncian seluruh tabel. Karena dampaknya pada memori, itu harus dipertimbangkan untuk sementara.

Kesimpulan

SQL Server menggunakan Eskalasi Kunci untuk mengontrol dampak penguncian yang lebih terperinci pada sumber daya server. Untuk menampilkan cara terjadinya penguncian ini – penguncian baris, penguncian halaman, penguncian objek, dll. – kueri tampilan manajemen dinamis sys.dm_tran_locks. Ini memberikan banyak informasi tentang penguncian, selain Eskalasi Kunci.

Meskipun dimungkinkan untuk memanipulasi perilaku Lock Manager, sangat penting untuk melakukannya dengan sangat hati-hati. Penting juga untuk mengetahui dampak kinerja yang tepat dari setiap upaya yang diarahkan untuk membuat modifikasi tersebut.

Referensi

1. Korotkevitch, D., 2016. Internal Pro SQL Server. Florida:Dmitri Korotkevitch
2. Skenario Kunci Menggunakan Sys.dm_tran_locks
3. Panduan Penguncian Transaksi dan Pembuatan Versi Baris