Cara Memvalidasi Database SQL Server Setelah Proses Recovery
Recovery database SQL Server belum selesai hanya karena database berhasil online. Setelah proses pemulihan, Anda perlu memvalidasi konsistensi, keterbacaan tabel, transaksi penting, login aplikasi, serta memastikan backup baru dibuat dari kondisi yang sudah diverifikasi.
Tujuannya adalah membedakan “database dapat dibuka” dari “database siap digunakan kembali”. Validasi dilakukan secara bertahap dan sebaiknya dicatat agar setiap temuan dapat ditelusuri.
Mulai dari status database
Periksa apakah database berada pada status yang diharapkan dan tidak menunjukkan recovery pending, suspect, atau kondisi lain yang belum selesai. Jangan langsung mengizinkan aplikasi produksi menulis data baru sebelum pemeriksaan dasar selesai.
Gunakan backup lama sebagai baseline
Jika tersedia, bandingkan ukuran, jumlah tabel, dan beberapa indikator dari backup sehat sebelumnya. Baseline membantu menemukan perubahan yang tidak diharapkan setelah recovery.
Artikel Backup SQL Server Sebelum Recovery membahas persiapan sebelum pemulihan. Artikel ini fokus pada validasi setelah proses selesai.
Periksa tabel dan objek penting
| Area | Yang diperiksa | Contoh hasil |
|---|---|---|
| Tabel inti | Dapat dibaca dan jumlah record masuk akal | Lulus/gagal |
| Index | Dapat digunakan tanpa error | Normal/perlu tindak lanjut |
| View/procedure | Dependensi masih valid | Berhasil/error |
| Login aplikasi | Koneksi dan permission sesuai | Berhasil/gagal |
Jalankan pemeriksaan konsistensi pada lingkungan aman
Gunakan pemeriksaan konsistensi database sesuai prosedur yang berlaku di lingkungan Anda. Jika database hasil recovery masih menjadi satu-satunya salinan, buat backup terlebih dahulu sebelum tindakan yang dapat mengubah struktur.
Verifikasi data yang paling penting
Pilih tabel transaksi atau master yang memiliki nilai tinggi. Bandingkan rentang tanggal, jumlah record, dan beberapa nilai yang diketahui. Jangan hanya memeriksa tabel kecil yang mudah dibuka.
Contoh validasi pasca-recovery
Misalnya database transaksi berhasil online setelah recovery. Tabel pelanggan dapat dibuka, tetapi query laporan bulanan gagal karena satu objek pendukung belum konsisten. Dalam kondisi ini, database belum siap dikembalikan ke aplikasi produksi.
Catat objek gagal, perbaiki pada lingkungan terkendali, lalu ulangi validasi. Hindari mengubah banyak objek sekaligus karena penyebab masalah menjadi sulit ditelusuri.
Periksa transaksi terbaru
Bandingkan transaksi terakhir yang seharusnya ada dengan data hasil recovery. Jika titik pemulihan lebih lama dari insiden, dokumentasikan rentang data yang tidak tersedia agar pengguna aplikasi memahami batasannya.
Uji aplikasi dengan hak akses terbatas
Setelah database konsisten, uji koneksi aplikasi menggunakan akun yang sesuai. Mulailah dari operasi baca sebelum mengizinkan operasi tulis. Pastikan permission tidak berubah selama recovery.
Gunakan pilar Pemulihan Database
Halaman Pemulihan Database dapat digunakan sebagai hub untuk memilih jalur recovery berdasarkan jenis database.
Periksa ulang setelah aplikasi mulai membaca
Monitor error log, query yang gagal, dan perubahan performa. Database yang terlihat normal saat pemeriksaan manual dapat menunjukkan masalah ketika beban aplikasi kembali.
Buat backup baru setelah validasi
Setelah database dinyatakan konsisten dan aplikasi uji berjalan, buat backup baru sebagai baseline pasca-recovery. Jangan menghapus backup lama sebelum backup baru diverifikasi.
Hubungkan dengan jalur SQL Server
Untuk konteks khusus pemulihan SQL Server, gunakan halaman Pemulihan Database SQL Server.
Matriks keputusan sebelum kembali ke produksi
| Temuan | Status | Keputusan |
|---|---|---|
| Consistency check bersih dan tabel utama valid | Baik | Lanjut ke uji aplikasi |
| Tabel dapat dibaca tetapi objek aplikasi gagal | Belum siap | Perbaiki dependensi pada lingkungan uji |
| Data transaksi penting hilang | Risiko tinggi | Bandingkan titik recovery dan backup lain |
| Backup baru belum diuji | Belum selesai | Verifikasi backup sebelum produksi |
Contoh baseline sebelum dan sesudah recovery
Misalnya backup sehat memiliki 120 tabel, 45 view, dan 30 stored procedure. Setelah recovery jumlah tabel sama, tetapi dua view gagal karena referensi objek berubah. Catat perbedaan tersebut dan selesaikan pada salinan kerja sebelum membuka akses tulis aplikasi.
Perbandingan struktur seperti ini membuat hasil recovery dapat diaudit. Anda tidak hanya tahu database “online”, tetapi juga mengetahui objek mana yang sudah diverifikasi dan mana yang masih perlu tindakan.
Checklist validasi SQL Server
- Status database normal.
- Tabel inti dapat dibaca.
- Jumlah record penting masuk akal.
- Pemeriksaan konsistensi selesai tanpa blocker kritis.
- View/procedure yang dibutuhkan berjalan.
- Koneksi aplikasi diuji.
- Rentang data yang hilang didokumentasikan bila ada.
- Backup baru dibuat dan diuji.
Pertanyaan yang sering muncul
Apakah database online berarti recovery selesai?
Tidak. Database masih perlu divalidasi dari sisi konsistensi, data, objek, dan aplikasi.
Apakah backup lama boleh langsung dihapus?
Sebaiknya tidak sampai backup baru dari kondisi sehat selesai diverifikasi.
Apakah semua tabel harus diperiksa satu per satu?
Untuk database besar, prioritaskan objek kritis dan gunakan pemeriksaan konsistensi serta sampel terarah.
Langkah validasi operasional sebelum membuka akses tulis
- Catat status database dan waktu recovery selesai.
- Jalankan pemeriksaan konsistensi pada salinan atau lingkungan aman.
- Uji tabel transaksi, master data, dan objek yang dipakai aplikasi.
- Bandingkan data terbaru dengan titik pemulihan yang diharapkan.
- Uji aplikasi dalam mode baca menggunakan akun dengan permission terbatas.
- Periksa error log dan query penting.
- Buat backup baru setelah hasil dinyatakan konsisten.
- Verifikasi backup baru sebelum membuka kembali akses tulis produksi.
Contoh kasus: database online tetapi laporan gagal
Misalnya database berhasil online dan tabel transaksi dapat dibaca. Namun, report bulanan gagal karena view tertentu tidak dapat menemukan satu field. Dalam kasus ini, jangan menganggap recovery selesai. Bandingkan struktur view dengan backup sehat, periksa perubahan schema, lalu uji ulang report pada lingkungan terkendali.
Jika perubahan field memang terjadi sebelum insiden, perbarui dependensi secara terarah. Jika perubahan tidak diketahui asalnya, tandai sebagai anomali dan telusuri sebelum produksi dibuka.
Ledger verifikasi pasca-recovery
| Objek | Uji | Hasil | Tindakan |
|---|---|---|---|
| Tabel Transaksi | SELECT sampel dan jumlah record | Lulus | Tidak ada |
| View Laporan | Eksekusi query | Gagal | Periksa dependensi |
| Login Aplikasi | Koneksi read-only | Lulus | Lanjut uji fungsi |
| Backup baru | Restore uji | Belum | Wajib sebelum produksi |
Next action: jangan membuka akses tulis produksi sampai semua objek kritis berstatus lulus atau memiliki keputusan mitigasi yang terdokumentasi.
Simulasi rekonsiliasi transaksi setelah point-in-time recovery
Misalnya recovery mengembalikan database ke pukul 10:30, sedangkan insiden diketahui pada 10:42. Sistem bisnis memiliki transaksi penting antara 10:30 dan 10:42. Jangan langsung menyatakan kehilangan 12 menit tersebut sebagai kehilangan final. Bandingkan log aplikasi, antrean integrasi, file ekspor, atau sumber transaksi lain yang memang tersedia di lingkungan internal.
Tujuan rekonsiliasi bukan menulis ulang data secara otomatis, melainkan membuat daftar transaksi yang mungkin perlu diproses ulang. Setiap item harus memiliki bukti asal, waktu, dan status agar tidak tercipta duplikasi setelah layanan dibuka kembali.
Gunakan status per objek untuk keputusan produksi
| Status | Arti | Keputusan |
|---|---|---|
| VALID | Objek diuji dan hasil sesuai baseline | Boleh masuk tahap uji aplikasi |
| REVIEW | Ada perbedaan yang belum dijelaskan | Tahan akses tulis terkait objek |
| FAILED | Objek atau data kritis tidak berfungsi | Perbaiki sebelum produksi |
| NOT_TESTED | Belum diuji | Jangan dianggap lulus |
Next action: gunakan status tersebut pada tabel, view, procedure, dan fungsi aplikasi kritis. Produksi baru layak dibuka ketika seluruh objek yang dibutuhkan alur utama tidak lagi berstatus FAILED atau NOT_TESTED.
Kesimpulan
Validasi SQL Server setelah recovery harus mencakup status database, konsistensi, tabel penting, transaksi, objek aplikasi, permission, dan backup baru. Dengan checklist yang jelas, database tidak dikembalikan ke produksi hanya berdasarkan fakta bahwa file berhasil dibuka.