Penyempurnaan DBCC CHECKDB di SQL Server 2008

DBCC digunakan untuk mengetahui database corruption lebih dini, yang pada umumnya terjadi karena masalah I/O. Pada saat DBCC CHECKDB diexecute, pertama-tama dia akan mengecek apakah ada corrupt pada databasenya. Kalau ada corrupt, dia akan mengecek ulang dari awal dengan lebih detail untuk mengetahui lokasi bagian yang corrupt tersebut (DEEP DIVE). Sayangnya, process ini akan memakan resource yang cukup banyak dengan waktu yang relatif lama.
Di SQL Server 2005 SP 2, apabila terjadi DEEP DIVE, DBCC akan menghasilkan error output:

DBCC CHECKDB is performing an exhaustive search of indexes for possible inconsistencies. This is an informational message only. No user action is required.

Di SQL server 2008, nama-nama table yang sedang di scan untuk kedua kalinya (DEEP DIVE), akan tertulis di Error output tersebut. Hal ini membantu kita untuk lebih cepat mengetahui tabel mana yang memiliki bagian yang corrupt.

Error 823, 824 dan 829 pada database mirroring di SQL Server 2008

Di SQL Server 2008, apabila ada yang mencoba mengakses page yang corrupt pada principal di database mirroring, otomatis akan diperbaiki dengan mencari bagian hilang di mirror-nya (begitu juga sebaliknya). Hal ini dianggap sebagai P3K (Pertolongan Pertama Pada Kecelakaan... hehehe) yang dilakukan untuk menjaga availability dari database tersebut.

Error yang akan diterima apabila page yang kita akses ternyata corrupt (atau terdeteksi dengan menggunakan DBCC), yaitu:

1. Error 823: SQL request ke OS untuk baca page-nya, tapi OS tidak bisa retrieve page tersebut; atau Error 824: OS bisa baca page-nya, tapi SQL men-deteksi kalau ternyata page tersebut corrupt.
2. Error 829: selama perbaikan (yang otomatis dilakukan oleh SQL) masih berlangsung, apabila ada yang melakukan query ke page yang sedang diperbaiki tersebut, maka akan dikirim Error 829 ini sebagai resultnya.

Selama perbaikan, event log akan mencatat:

Database mirroring is attempting to repair physical page in database by requesting a copy from the partner
dan kemudian,
Database mirroring successfully repaired physical page in database by obtaining a copy from the partner

Pesan dari sponsor:
Perbaikan ini dilakukan secara otomatis, tapi bukan berarti perkejaan kita selesai. Kita tetap punya PR untuk mencari tahu sumber kerusakan yang menyebabkan data corrupt ini.

Dedicated Administrator Connection

Kadang kita tidak bisa menarik data / connect ke database server yang load-nya cukup padat, bahkan RDP pun kadang2 nggak memungkinkan. Beberapa orang berpikir "Lebih baik gw restart servernya dan server kembali active". Sayangnya, cara ini terlalu terburu-buru dan tidak akan menemukan sumber masalah yang potential akan berulang berkali-kali. (Kecuali kalau perintah "KILL" tidak berfungsi)
Untuk menggunakan DAC, kita harus meng-configure SQL Server untuk dapat menerima DAC secara remote, dengan menjalankan:

sp_configure "remote admin connections", 1
GO
RECONFIGURE WITH OVERRIDE
GO

tapi anda bisa juga meng-configure melalui SQL Server Surface Configuration.
Untuk masuk melalui DAC, kalau menggunakan SQL Server Management Studio, di field "Server Name" kita tinggal menambahkan "ADMIN:" + nama server, menjadi: "ADMIN:[Server\Instance Name]".
Setelah connect ke Server melalui DAC, ada beberapa hal yang bisa kita lakukan dalam meng-investigasi apa yang menyebabkan kita tidak bisa connect ke server tersebut melalui port biasa, antara lain:

1. Query ke DMV [Dynamic Management View]:
   a. sys.dm_tran_locks: mengetahui resources mana yang sedang di-lock atau yang masih "waiting"
   b. sys.dm_os_memory_cache_counters: mengetahui keadaan cache (snapshot)
   c. sys.dm_exec_requests: menunjukan semua request yang sedang dieksekusi'
   d. sys.dm_exec_sessions: menunjukan semua session yang ada di serve
2. Gunakan DBCC:
   a. DBCC FREEPROCCACHE: Membebaskan plan yang ada di plan cache
   b. DBCC FREESYSTEMCACHE: Membebaskan cache yang sudah tidak terpakai
   c. DBCC DROPCLEANBUFFERS: Menghapus semua buffer yang tidak terpakai lagi dari buffer pool
   d. DBCC SQLPERF: mengetahui detail log dari semua database
3. Gunakan T-SQL: "KILL"