Perbaikan Halaman Otomatis (Grup Ketersediaan: Pencerminan Database)
Berlaku untuk:
SQL Server
Perbaikan halaman otomatis didukung oleh pencerminan database dan oleh grup ketersediaan AlwaysOn. Setelah jenis kesalahan tertentu merusak halaman, membuatnya tidak dapat dibaca, mitra pencerminan database (utama atau cermin) atau replika ketersediaan (primer atau sekunder) mencoba memulihkan halaman secara otomatis. Mitra/replika yang tidak dapat membaca halaman meminta salinan baru halaman dari mitranya atau dari replika lain. Jika permintaan ini berhasil, halaman yang tidak dapat dibaca digantikan oleh salinan yang dapat dibaca, dan ini biasanya mengatasi kesalahan.
Secara umum, pencerminan database, dan grup ketersediaan AlwaysOn menangani kesalahan I/O dengan cara yang setara. Beberapa perbedaan secara eksplisit dipanggil di sini.
Catatan
Perbaikan halaman otomatis berbeda dari perbaikan DBCC. Semua data dipertahankan oleh perbaikan halaman otomatis. Sebaliknya, memperbaiki kesalahan dengan menggunakan opsi REPAIR_ALLOW_DATA_LOSS DBCC mungkin mengharuskan beberapa halaman, dan oleh karena itu data, dihapus.
Jenis Kesalahan yang Menyebabkan Upaya Page-Repair Otomatis
Perbaikan halaman otomatis pencerminan database mencoba memperbaiki hanya halaman dalam file data tempat operasi gagal karena salah satu kesalahan yang tercantum dalam tabel berikut ini.
| Nomor kesalahan | Deskripsi | Instans yang menyebabkan upaya perbaikan halaman otomatis |
|---|---|---|
| 823 | Tindakan diambil hanya jika sistem operasi melakukan pemeriksaan redundansi siklik (CRC) yang gagal pada data. | ERROR_CRC. Nilai sistem operasi untuk kesalahan ini adalah 23. |
| 824 | Kesalahan logika. | Kesalahan data logis, seperti penulisan robek atau checksum halaman yang buruk. |
| 829 | Halaman telah ditandai sebagai pemulihan tertunda. | Semua. |
Untuk melihat kesalahan CRC 823 terbaru dan kesalahan 824, lihat tabel suspect_pages dalam database msdb .
Tipe halaman yang tidak dapat diperbaiki secara otomatis
Perbaikan halaman otomatis tidak dapat memperbaiki tipe halaman kontrol berikut:
Halaman header file (ID halaman 0).
Halaman 9 (halaman boot database).
Halaman alokasi: halaman Peta Alokasi Global (GAM), halaman Peta Alokasi Global Bersama (SGAM), dan halaman Ruang Bebas Halaman (PFS).
Menangani Kesalahan I/O pada Database Utama/Utama
Pada database utama/utama, perbaikan halaman otomatis hanya dicoba ketika database berada dalam status DISINKRONKAN dan prinsipal/utama masih mengirim catatan log untuk database ke cermin/sekunder. Urutan dasar tindakan dalam upaya perbaikan halaman otomatis adalah sebagai berikut:
Saat kesalahan baca terjadi pada halaman data di database utama/utama, prinsipal/utama menyisipkan baris dalam tabel suspect_pages dengan status kesalahan yang sesuai. Untuk pencerminan database, perwakilan kemudian meminta salinan halaman dari cermin. Untuk grup ketersediaan AlwaysOn, primer menyiarkan permintaan ke semua sekunder dan mendapatkan halaman dari yang pertama merespons. Permintaan menentukan ID halaman dan LSN yang saat ini berada di akhir log yang dihapus. Halaman ditandai sebagai pemulihan tertunda. Ini membuatnya tidak dapat diakses selama upaya perbaikan halaman otomatis. Upaya untuk mengakses halaman ini selama upaya perbaikan akan gagal dengan kesalahan 829 (pemulihan tertunda).
Setelah menerima permintaan halaman, cermin/sekunder menunggu hingga log di-redone hingga LSN yang ditentukan dalam permintaan. Kemudian, cermin/sekunder mencoba mengakses halaman dalam salinan databasenya. Jika halaman dapat diakses, cermin/sekunder mengirimkan salinan halaman ke utama/utama. Jika tidak, cermin/sekunder mengembalikan kesalahan ke prinsipal/utama, dan upaya perbaikan halaman otomatis gagal.
Prinsipal/utama memproses respons yang berisi salinan baru halaman.
Setelah upaya perbaikan halaman otomatis memperbaiki halaman tersangka, halaman ditandai dalam tabel suspect_pages sebagai dipulihkan (event_type = 5).
Jika kesalahan I/O halaman menyebabkan transaksi yang ditangguhkan, setelah Anda memperbaiki halaman, prinsipal/utama mencoba menyelesaikan transaksi tersebut.
Menangani Kesalahan I/O pada Database Cermin/Sekunder
Kesalahan I/O pada halaman data yang terjadi pada database cermin/sekunder ditangani secara umum dengan cara yang sama dengan pencerminan database dan oleh grup ketersediaan AlwaysOn.
Dengan pencerminan database, jika cermin mengalami satu atau beberapa kesalahan I/O halaman saat mengulangi rekaman log, sesi pencerminan memasuki status SUSPENDED. Dengan grup ketersediaan AlwaysOn, jika replika sekunder mengalami satu atau beberapa kesalahan I/O halaman saat mengulangi rekaman log, database sekunder memasuki status SUSPENDED. Pada saat itu, cermin/sekunder menyisipkan baris dalam tabel suspect_pages dengan status kesalahan yang sesuai. Cermin/sekunder kemudian meminta salinan halaman dari prinsipal/utama.
Prinsipal/utama mencoba mengakses halaman dalam salinan databasenya. Jika halaman dapat diakses, prinsipal/utama mengirimkan salinan halaman ke cermin/sekunder.
Jika cermin/sekunder menerima salinan dari setiap halaman yang dimintanya, cermin/sekunder mencoba melanjutkan sesi pencerminan. Jika upaya perbaikan halaman otomatis memperbaiki halaman tersangka, halaman ditandai dalam tabel suspect_pages sebagai dipulihkan (event_type = 4).
Jika cermin/sekunder tidak menerima halaman yang dimintanya dari prinsipal/utama, upaya perbaikan halaman otomatis gagal. Dengan pencerminan database, sesi pencerminan tetap ditangguhkan. Dengan grup ketersediaan AlwaysOn, database sekunder tetap ditangguhkan. Jika sesi pencerminan atau database sekunder dilanjutkan secara manual, halaman yang rusak akan dipukul lagi selama fase sinkronisasi.
Praktik Terbaik Pengembang
Perbaikan halaman otomatis adalah proses asinkron yang berjalan di latar belakang. Oleh karena itu, operasi database yang meminta halaman yang tidak dapat dibaca gagal dan mengembalikan kode kesalahan untuk kondisi apa pun yang menyebabkan kegagalan. Saat mengembangkan aplikasi untuk database cermin atau database ketersediaan, Anda harus mencegat pengecualian untuk operasi yang gagal. Jika kode kesalahan SQL Server adalah 823, 824, atau 829, Anda harus mencoba kembali operasi nanti.
Cara: Melihat Upaya Page-Repair Otomatis
Tampilan manajemen dinamis berikut mengembalikan baris untuk upaya perbaikan halaman otomatis terbaru pada database ketersediaan tertentu atau database yang dicerminkan, dengan maksimum 100 baris per database.
Grup Ketersediaan AlwaysOn:
sys.dm_hadr_auto_page_repair (T-SQL)
Mengembalikan baris untuk setiap upaya perbaikan halaman otomatis pada database ketersediaan apa pun pada replika ketersediaan yang dihosting untuk grup ketersediaan apa pun oleh instans server.
Pencerminan database:
sys.dm_db_mirroring_auto_page_repair (Transact-SQL)
Mengembalikan baris untuk setiap upaya perbaikan halaman otomatis pada database cermin apa pun pada instans server.
Lihat juga
Mengelola Tabel suspect_pages (SQL Server)
Gambaran Umum Grup Ketersediaan AlwaysOn (SQL Server)
Pencerminan Database (SQL Server)
Saran dan Komentar
Segera hadir: Sepanjang tahun 2024 kami akan menghentikan penggunaan GitHub Issues sebagai mekanisme umpan balik untuk konten dan menggantinya dengan sistem umpan balik baru. Untuk mengetahui informasi selengkapnya, lihat: https://aka.ms/ContentUserFeedback.
Kirim dan lihat umpan balik untuk