Penguncian sangat penting untuk pemrosesan transaksi SQL Server yang berhasil dan dirancang untuk

memungkinkan SQL Server bekerja dengan lancar di lingkungan multi-pengguna. Mengunci adalah cara
SQL Server mengelola konkurensi transaksi. Pada dasarnya, kunci adalah struktur dalam memori yang
memiliki pemilik, jenis, dan hash sumber daya yang harus dilindungi. Kunci sebagai struktur dalam memori
berukuran 96 byte.

Untuk memahami lebih baik penguncian dalam SQL Server, penting untuk memahami bahwa penguncian
dirancang untuk memastikan integritas data dalam database, karena itu memaksa setiap transaksi SQL Server
untuk lulus tes ACID.

Tes ACID terdiri dari 4 persyaratan bahwa setiap transaksi harus berhasil lulus:

 Atomicity – mensyaratkan bahwa transaksi yang melibatkan dua atau lebih bagian informasi yang
terpisah harus melakukan semua bagian atau tidak sama sekali
 Consistency – mensyaratkan bahwa transaksi harus membuat status data baru yang valid, atau harus
mengembalikan semua data ke status yang ada sebelum transaksi dieksekusi
 Isolation – mensyaratkan bahwa transaksi yang masih berjalan dan belum melakukan semua data,
harus tetap terisolasi dari semua transaksi lainnya
 Durability – mensyaratkan bahwa data yang berkomitmen harus disimpan menggunakan metode
yang akan menjaga semua data dalam keadaan yang benar dan tersedia bagi pengguna, bahkan jika
terjadi kegagalan

Penguncian SQL Server adalah bagian penting dari persyaratan isolasi dan berfungsi untuk mengunci objek
yang dipengaruhi oleh transaksi. Ketika objek dikunci, SQL Server akan mencegah transaksi lain dari
membuat perubahan data yang disimpan dalam objek yang dipengaruhi oleh kunci yang dikenakan. Setelah
kunci dilepaskan dengan melakukan perubahan atau dengan memutar kembali perubahan ke keadaan awal,
transaksi lain akan diizinkan untuk melakukan perubahan data yang diperlukan.

Diterjemahkan ke dalam bahasa SQL Server, ini berarti bahwa ketika transaksi memaksakan kunci pada
suatu objek, semua transaksi lain yang memerlukan akses ke objek itu akan dipaksa untuk menunggu sampai
kunci dilepaskan dan menunggu itu akan didaftarkan dengan menunggu yang memadai mengetik

Kunci SQL Server dapat ditentukan melalui mode kunci dan granularity kunci

Lock modes
Mode kunci mempertimbangkan berbagai jenis kunci yang dapat diterapkan ke sumber daya yang harus
dikunci:

 Exclusive (X)
 Shared (S)
 Update (U)
 Intent (I)
 Schema (Sch)
 Bulk update (BU)

Exclusive lock (X) – Jenis kunci ini, ketika diberlakukan, akan memastikan bahwa halaman atau baris akan
dicadangkan khusus untuk transaksi yang mengenakan kunci eksklusif, selama transaksi memegang kunci.

Kunci eksklusif akan dikenakan oleh transaksi ketika ingin memodifikasi halaman atau data baris, yang
dalam kasus pernyataan DML HAPUS, INSERT dan UPDATE. Kunci eksklusif dapat dikenakan ke
halaman atau baris hanya jika tidak ada kunci bersama atau eksklusif lain yang sudah dikenakan pada
target. Ini secara praktis berarti bahwa hanya satu kunci eksklusif yang dapat dikenakan ke halaman atau
baris, dan sekali dikenakan tidak ada kunci lain yang dapat dikenakan pada sumber daya yang terkunci
Shared lock (S) – jenis kunci ini, ketika diberlakukan, akan memesan halaman atau baris yang hanya
tersedia untuk dibaca, yang berarti bahwa setiap transaksi lain akan dicegah untuk mengubah catatan yang
terkunci selama kunci tersebut aktif. Namun, kunci bersama dapat dikenakan oleh beberapa transaksi pada
saat yang sama pada halaman atau baris yang sama dan dengan cara itu beberapa transaksi
dapat berbagi kemampuan untuk membaca data karena proses membaca itu sendiri tidak akan
mempengaruhi bagaimanapun halaman atau baris data aktual. Selain itu, kunci bersama akan memungkinkan
operasi penulisan, tetapi tidak ada perubahan DDL akan diizinkan

Update lock (U) – kunci ini mirip dengan kunci eksklusif tetapi dirancang agar lebih fleksibel. Kunci
pembaruan dapat dikenakan pada catatan yang sudah memiliki kunci bersama. Dalam kasus seperti itu, kunci
pembaruan akan mengenakan kunci bersama lain pada baris target. Setelah transaksi yang menahan kunci
pembaruan siap untuk mengubah data, kunci pembaruan (U) akan diubah menjadi kunci eksklusif
(X). Penting untuk dipahami bahwa kunci pembaruan tidak simetris dalam hal kunci bersama. Sementara
kunci pembaruan dapat dikenakan pada catatan yang memiliki kunci bersama, kunci bersama tidak dapat
dikenakan pada catatan yang sudah memiliki kunci pembaruan

Intent locks (I) – kunci ini adalah sarana yang digunakan oleh transaksi untuk menginformasikan transaksi
lain tentang niatnya untuk mendapatkan kunci. Tujuan dari penguncian tersebut adalah untuk memastikan
modifikasi data dieksekusi dengan benar dengan mencegah transaksi lain untuk mendapatkan kunci pada
objek hierarki berikutnya. Dalam praktiknya, ketika transaksi ingin mendapatkan kunci di baris, itu akan
mendapatkan kunci niat di atas meja, yang merupakan objek hierarki yang lebih tinggi. Dengan memperoleh
kunci niat, transaksi tidak akan memungkinkan transaksi lain untuk mendapatkan kunci eksklusif pada tabel
itu (jika tidak, kunci eksklusif yang diberlakukan oleh beberapa transaksi lain akan membatalkan kunci
baris).

Ini adalah jenis kunci penting dari aspek kinerja karena mesin database SQL Server akan memeriksa kunci
niat hanya di tingkat tabel untuk memeriksa apakah mungkin untuk transaksi mendapatkan kunci dengan
cara yang aman di tabel itu, dan karenanya kunci niat menghilangkannya. perlu memeriksa setiap kunci baris
/ halaman dalam sebuah tabel untuk memastikan bahwa transaksi dapat memperoleh kunci pada seluruh
table

Ada tiga kunci maksud reguler dan tiga yang disebut kunci konversi:

Regular intent locks:

Intent exclusive (IX) – ketika niat kunci eksklusif (IX) diperoleh itu menunjukkan ke SQL Server bahwa
transaksi memiliki niat untuk memodifikasi beberapa sumber daya hierarki yang lebih rendah dengan
memperoleh kunci (X) eksklusif secara individual pada sumber daya hierarki yang lebih rendah

Intent shared (IS) – ketika niat berbagi kunci (IS) diperoleh itu menunjukkan kepada SQL Server bahwa
transaksi memiliki maksud untuk membaca beberapa sumber daya hierarki yang lebih rendah dengan
memperoleh kunci bersama (S) secara terpisah pada sumber daya yang lebih rendah dalam hierarki

Intent update (IU) – ketika niat berbagi kunci (IS) diperoleh itu menunjukkan ke SQL Server bahwa
transaksi memiliki niat untuk membaca beberapa sumber daya hierarki yang lebih rendah dengan
memperoleh kunci bersama (S) secara terpisah pada sumber daya yang lebih rendah dalam hierarki. Kunci
pembaruan maksud (IU) dapat diperoleh hanya pada tingkat halaman dan segera setelah operasi pembaruan
berlangsung, itu dikonversi ke kunci eksklusif maksud (IX)

Conversion locks:
Shared with intent exclusive (SIX) – ketika diperoleh, kunci ini menunjukkan bahwa transaksi bermaksud
membaca semua sumber daya pada hierarki yang lebih rendah dan dengan demikian memperoleh kunci
bersama pada semua sumber daya yang lebih rendah dalam hierarki, dan pada gilirannya, untuk
memodifikasi bagian dari mereka , tapi tidak semua. Dengan melakukan hal itu, ia akan memperoleh kunci
niat eksklusif (IX) pada sumber daya hierarki yang lebih rendah yang harus dimodifikasi. Dalam praktiknya,
ini berarti bahwa setelah transaksi memperoleh kunci SIX di atas meja, itu akan memperoleh niat kunci
eksklusif (IX) pada halaman yang dimodifikasi dan kunci eksklusif (X) pada baris yang dimodifikasi.

Hanya satu yang dibagikan dengan niat kunci eksklusif (SIX) yang dapat diperoleh pada tabel pada satu
waktu dan itu akan memblokir transaksi lain dari membuat pembaruan, tetapi itu tidak akan mencegah
transaksi lain untuk membaca sumber daya hierarki yang lebih rendah mereka dapat memperoleh maksud
yang dibagikan (IS ) kunci di atas meja

Shared with intent update (SIU) – ini adalah kunci yang sedikit lebih spesifik karena merupakan kombinasi
dari kunci yang dibagikan (S) dan niat memperbarui (IU). Contoh khas dari kunci ini adalah ketika transaksi
menggunakan kueri yang dieksekusi dengan petunjuk dan kueri PAGELOCK, lalu kueri pembaruan. Setelah
transaksi mendapatkan kunci SIU di atas meja, permintaan dengan petunjuk PAGELOCK akan mendapatkan
kunci bersama (S) sementara permintaan pembaruan akan mendapatkan kunci niat memperbarui (IU)

Update with intent exclusive (UIX) – saat kunci pembaruan (U) dan kunci niat eksklusif (IX) diperoleh
pada sumber daya hierarki yang lebih rendah dalam tabel secara bersamaan, pembaruan dengan kunci
eksklusif maksud akan diperoleh pada tingkat tabel sebagai konsekuensinya

Schema locks (Sch) – Mesin database SQL Server mengenali dua jenis kunci skema:: Schema modification
lock (Sch-M) dan Schema stability lock (Sch-S)

 Schema modification lock (Sch-M) akan diperoleh ketika pernyataan DDL dieksekusi, dan itu
akan mencegah akses ke data objek yang dikunci karena struktur objek sedang diubah. SQL Server
memungkinkan kunci modifikasi skema tunggal (Sch-M) pada objek yang terkunci. Untuk
memodifikasi tabel, transaksi harus menunggu untuk mendapatkan kunci Sch-M pada objek
target. Setelah memperoleh kunci modifikasi skema (Sch-M), transaksi dapat memodifikasi objek
dan setelah modifikasi selesai dan kunci akan dirilis. Contoh khas dari kunci Sch-M adalah
pembangunan kembali indeks, karena pembangunan kembali indeks adalah proses modifikasi
tabel. Setelah ID membangun kembali indeks dikeluarkan, kunci modifikasi skema (Sch-M) akan
diperoleh pada tabel itu dan akan dirilis hanya setelah proses pembangunan kembali indeks selesai
(ketika digunakan dengan opsi ONLINE,
 Schema stability lock (Sch-S) akan diperoleh saat permintaan skema tergantung sedang disusun
dan dilaksanakan dan rencana pelaksanaan dihasilkan. Kunci khusus ini tidak akan memblokir
transaksi lain untuk mengakses data objek dan itu kompatibel dengan semua mode kunci kecuali
dengan kunci modifikasi skema (Sch-M). Pada dasarnya, kunci stabilitas skema akan diperoleh oleh
setiap DML dan pilih kueri untuk memastikan integritas struktur tabel (memastikan bahwa tabel
tidak berubah saat kueri berjalan).

Bulk Update locks (BU) – kunci ini dirancang untuk digunakan oleh operasi impor massal ketika
dikeluarkan dengan argumen / petunjuk TABLOCK. Ketika kunci pembaruan massal diperoleh, proses lain
tidak akan dapat mengakses tabel selama eksekusi beban massal. Namun, kunci pembaruan massal tidak
akan mencegah beban massal lainnya diproses secara paralel. Tetapi perlu diingat bahwa menggunakan
TABLOCK pada tabel indeks berkerumun tidak akan memungkinkan impor massal paralel. Rincian lebih
lanjut tentang ini

Locking hierarchy
SQL Server telah memperkenalkan hierarki penguncian yang diterapkan saat membaca atau mengubah data
dilakukan. Hirarki kunci dimulai dengan database di tingkat hierarki tertinggi dan turun melalui tabel dan
halaman ke baris di level terendah
Pada dasarnya, selalu ada kunci bersama pada tingkat database yang dikenakan setiap kali transaksi
terhubung ke database. Kunci yang dibagikan pada tingkat basis data diberlakukan untuk mencegah
menjatuhkan basis data atau mengembalikan cadangan basis data atas basis data yang digunakan. Misalnya,
ketika pernyataan SELECT dikeluarkan untuk membaca beberapa data,kunci bersama (S) akan dikenakan
pada tingkat database, kunci kunci bersama (SI) akan dikenakan pada tabel dan pada tingkat halaman, dan
kunci bersama (S) pada baris itu sendiri

Dalam hal pernyataan DML (yaitu menyisipkan, memperbarui, menghapus) kunci bersama (S) akan
dikenakan pada tingkat database, kunci eksklusif maksud (IX) atau kunci pembaruan maksud (IU) akan
dikenakan di atas meja dan tingkat halaman, dan kunci pembaruan atau eksklusif (X atau U) pada baris
Kunci akan selalu diperoleh dari atas ke bawah seperti dalam cara SQL Server mencegah kondisi ras
yang disebut terjadi.

Sekarang setelah mode kunci dan hierarki kunci telah dijelaskan, mari kita menguraikan lebih lanjut
tentang mode kunci dan bagaimana mereka menerjemahkan ke hierarki kunci.

Tidak semua mode kunci dapat diterapkan di semua level.

Pada level baris, tiga mode kunci berikut dapat diterapkan:

 Exclusive (X)
 Shared (S)
 Update (U)

Untuk memahami kompatibilitas mode-mode tersebut, silakan merujuk ke tabel berikut:

Exclusive (X) Shared (S) Update (U)

Exclusive (X) ✗ ✗ ✗

Shared (S) ✗ ✓ ✓

Update (U) ✗ ✓ ✗

✓ – Compatible ✗ – Incompatible

Di tingkat meja, ada lima jenis kunci:

 Exclusive (X):
 Shared (S)
 Intent exclusive (IX)
  Intent shared (IS)
 Shared with intent exclusive (SIX)

Kompatibilitas mode-mode ini dapat dilihat pada tabel di bawah ini

(X) (S) (IX) (IS) (SIX)

(X) ✗ ✗ ✗ ✗ ✗

(S) ✗ ✓ ✗ ✓ ✗

(IX) ✗ ✗ ✓ ✓ ✗

(IS) ✗ ✓ ✓ ✓ ✓

(SIX) ✗ ✗ ✗ ✓ ✗

✓ – Compatible ✗ – Incompatible

Kunci Schema (Sch) juga merupakan kunci level tabel, tetapi ini bukan kunci terkait data

Untuk lebih memahami kompatibilitas antara jenis kunci ini, silakan lihat tabel ini:

Lock escalation
Untuk mencegah situasi di mana penguncian menggunakan sumber daya terlalu banyak, SQL Server telah
memperkenalkan fitur eskalasi kunci.

Tanpa eskalasi, kunci dapat memerlukan sejumlah besar sumber daya memori. Mari kita ambil contoh di
mana kunci harus dikenakan pada 30.000 baris data, di mana setiap baris berukuran 500 byte, untuk
melakukan operasi penghapusan. Tanpa eskalasi, kunci bersama (S) akan dikenakan pada database, 1
kunci kunci eksklusif (IX) di atas meja, 1,875 kunci kunci eksklusif (IX) pada halaman (halaman 8KB
menampung 16 baris 500 byte, yang membuat 1.875 halaman yang menampung 30.000 baris) dan 30.000
kunci eksklusif (X) pada baris itu sendiri. Karena setiap kunci berukuran 96 byte, 31.877 kunci akan
memakan sekitar 3 MB memori untuk operasi penghapusan tunggal. Menjalankan sejumlah besar operasi
secara paralel dapat memerlukan beberapa sumber daya yang signifikan hanya untuk memastikan bahwa
manajer penguncian dapat melakukan operasi dengan lancar

Untuk mencegah situasi seperti itu, SQL Server menggunakan eskalasi kunci. Ini berarti bahwa dalam situasi
di mana lebih dari 5.000 kunci diperoleh pada tingkat tunggal, SQL Server akan meningkatkan kunci tersebut
ke kunci tingkat tabel tunggal. Secara default, SQL Server akan selalu naik ke tingkat tabel secara langsung,
yang berarti bahwa peningkatan ke tingkat halaman tidak pernah terjadi. Alih-alih memperoleh banyak baris
dan halaman mengunci, SQL Server akan meningkat ke kunci eksklusif (X) pada tingkat table

Meskipun ini akan mengurangi kebutuhan akan sumber daya, kunci eksklusif (X) dalam sebuah tabel berarti
bahwa tidak ada transaksi lain yang dapat mengakses tabel yang dikunci dan semua pertanyaan yang
mencoba mengakses tabel itu akan diblokir. Oleh karena itu, ini akan mengurangi overhead sistem tetapi
akan meningkatkan kemungkinan pertikaian konkurensi

Untuk memberikan kontrol atas eskalasi, dimulai dengan SQL Server 2008 R2, opsi LOCK_EXCALATION
diperkenalkan sebagai bagian dari pernyataan ALTER TABLE

USE AdventureWorks2014 GO

ALTER TABLE Table_name SET (LOCK_ESCALATION = < TABLE | AUTO | DISABLE >

–One of those options)

GO

Masing-masing opsi ini didefinisikan untuk memungkinkan kontrol spesifik atas proses eskalasi kunci:

Table – Ini adalah opsi default untuk setiap tabel yang baru dibuat, karena secara default SQL Server akan
selalu melakukan eskalasi kunci ke tingkat tabel, yang juga termasuk tabel dipartisi

Auto – Opsi ini memungkinkan eskalasi kunci ke tingkat partisi ketika sebuah tabel dipartisi. Ketika 5.000
kunci diperoleh dalam satu partisi, eskalasi kunci akan memperoleh kunci eksklusif (X) pada partisi itu
sementara tabel akan mendapatkan niat kunci eksklusif (IX). Jika tabel tidak dipartisi, eskalasi kunci akan
mendapatkan kunci pada level tabel (sama dengan opsi Tabel ).

Meskipun ini terlihat seperti opsi yang sangat berguna, itu harus digunakan dengan sangat hati-hati karena
dapat dengan mudah menyebabkan jalan buntu. Dalam situasi di mana kami memiliki dua transaksi pada
dua partisi di mana kunci eksklusif (X) diperoleh, dan transaksi mencoba mengakses tanggal dari partisi
yang digunakan oleh transaksi lain, kebuntuan akan dijumpai.
Jadi, sangat penting untuk mengontrol dengan hati-hati pola akses data, jika opsi ini diaktifkan, yang tidak
mudah dicapai, dan inilah mengapa opsi ini bukan pengaturan default di SQL Server

Disable – Opsi ini akan sepenuhnya menonaktifkan eskalasi kunci untuk sebuah tabel. Sekali lagi, opsi ini
harus digunakan dengan hati-hati untuk menghindari manajer kunci SQL Server dipaksa untuk
menggunakan jumlah memori yang berlebihan

Seperti dapat dilihat, kunci eskalasi dapat menjadi tantangan bagi DBA. Jika desain aplikasi mengharuskan
penghapusan atau pembaruan lebih dari 5.000 baris sekaligus, solusi untuk menghindari eskalasi kunci, dan
efek yang dihasilkan, adalah memecah satu transaksi menjadi dua atau lebih transaksi di mana masing-
masing akan menangani kurang dari 5.000 baris, seperti dalam hal ini cara eskalasi kunci dapat dihindari

Get info about active SQL Server locks

SQL Server menyediakan Dynamics Management View (DMV) sys.dm_tran_locks yang mengembalikan
informasi tentang sumber daya manajer kunci yang saat ini digunakan, yang berarti akan menampilkan
semua kunci "langsung" yang diperoleh dari transaksi.

Kolom paling penting yang digunakan untuk identifikasi kunci adalah resource_type, request_mode, dan
resource_description. Jika diperlukan, lebih banyak kolom sebagai sumber daya tambahan untuk informasi
informasi dapat dimasukkan selama pemecahan masalah

Ini adalah contoh query

SELECT resource_type, request_mode, resource_description FROM sys.dm_tran_locks

WHERE resource_type <> ‘DATABASE’

Di mana klausa dalam kueri ini digunakan sebagai filter pada resource_type untuk dihilangkan. dari hasil,
kunci-kunci yang umumnya dibagikan tersebut diperoleh pada basis data karena selalu ada di tingkat basis
data
Penjelasan singkat dari tiga kolom yang disajikan di sini:

resource_type - Menampilkan sumber daya basis data tempat kunci diperoleh. Kolom dapat menampilkan
salah satu dari nilai berikut: ALLOCATION_UNIT, APLIKASI, DATABASE, EXTENT, FILE, HOBT,
METADATA, OBJECT, HALAMAN, KUNCI, RID

request_mode - menampilkan mode kunci yang diperoleh pada sumber daya

resource_description - menampilkan deskripsi sumber daya pendek dan tidak diisi untuk semua mode
kunci. Paling sering kolom berisi id dari baris, halaman, objek, file, dll
 TUGAS
SISTEM MANAJEMEN BASIS DATA
Locking dan Recovery Pada SQL Server

Oleh :
Eko Aji Saputra 92218091
Afan Rais Muharam 92218076
Aldo Fernanda Tahar 92218077
Dewandra Sapto Prasetyo 92218088

Kelas:
55 MMSI 1

Universitas Gunadarma