Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Berlaku untuk:
SQL Server
Perbaikan halaman otomatis didukung oleh pencerminan database dan oleh grup ketersediaan AlwaysOn. Setelah jenis kesalahan tertentu menyebabkan halaman menjadi rusak sehingga tidak dapat dibaca, mitra pencerminan basis data (utama atau cermin) atau replika ketersediaan (primer atau sekunder) berupaya 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 menyelesaikan kesalahan.
Secara umum, pencerminan database dan grup ketersediaan AlwaysOn menangani kesalahan I/O dengan cara yang setara. Beberapa perbedaan secara eksplisit disebutkan di sini.
Catatan
Perbaikan halaman otomatis berbeda dari perbaikan DBCC. Semua data tetap tersimpan berkat perbaikan halaman otomatis. Sebaliknya, memperbaiki kesalahan dengan menggunakan opsi DBCC REPAIR_ALLOW_DATA_LOSS mungkin mengharuskan beberapa halaman, dan oleh karena itu data, harus dihapus.
Jenis Kesalahan yang Menyebabkan Upaya Perbaikan Halaman Otomatis
Perbaikan halaman otomatis pada pencerminan database hanya mencoba memperbaiki halaman dalam file data yang mengalami kegagalan operasi karena salah satu kesalahan yang tercantum dalam tabel berikut.
| Nomor kesalahan | Deskripsi | Kejadian yang menyebabkan upaya perbaikan halaman otomatis |
|---|---|---|
| 823 | Tindakan hanya diambil jika sistem operasi melakukan pemeriksaan cyclic redundancy check (CRC) terhadap data dan pemeriksaan tersebut gagal. | ERROR_CRC. Nilai sistem operasi untuk kesalahan ini adalah 23. |
| 824 | Kesalahan logis. | Kesalahan data logis, seperti penulisan robek atau checksum halaman yang buruk. |
| 829 | Halaman telah ditandai sebagai menunggu pemulihan. | 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 jenis halaman kontrol berikut:
Halaman header berkas (ID halaman 0).
Halaman 9 (halaman boot database).
Halaman alokasi: halaman Global Allocation Map (GAM), halaman Shared Global Allocation Map (SGAM), dan halaman Page Free Space (PFS).
Menangani Kesalahan I/O pada Basis Data Primer/Utama
Pada database prinsipal/primer, perbaikan halaman otomatis hanya dicoba ketika database berada dalam status SYNCHRONIZED dan prinsipal/primer masih mengirim rekaman log untuk database ke cermin/sekunder. Urutan dasar tindakan dalam upaya perbaikan halaman otomatis adalah sebagai berikut:
Ketika terjadi kesalahan baca pada halaman data di database principal/primer, principal/primer menambahkan satu baris ke tabel suspect_pages dengan status kesalahan yang sesuai. Untuk pencerminan database, server principal kemudian meminta salinan halaman dari server mirror. Untuk grup ketersediaan Always On, replika primer menyebarkan permintaan ke semua replika sekunder dan mengambil halaman dari replika yang pertama merespons. Permintaan tersebut menentukan ID halaman dan LSN yang saat ini berada di akhir log yang telah di-flush. 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, mirror/sekunder menunggu hingga penerapan ulang log mencapai LSN yang ditentukan dalam permintaan. Kemudian, mirror/secondary mencoba mengakses halaman tersebut di dalam salinan basis datanya. Jika halaman dapat diakses, server mirror/sekunder mengirim salinan halaman tersebut ke server utama/primer. 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 berhasil memperbaiki halaman yang dicurigai, halaman tersebut ditandai dalam tabel suspect_pages sebagai telah dipulihkan (event_type = 5).
Jika kesalahan I/O pada halaman menyebabkan transaksi yang ditangguhkan, setelah Anda memperbaiki halaman tersebut, prinsipal/primer 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, server mirror/sekunder menambahkan satu baris ke tabel suspect_pages dengan status kesalahan yang sesuai. Replika/sekunder kemudian meminta salinan halaman tersebut dari utama/primer.
Prinsipal/utama mencoba mengakses halaman dalam salinan databasenya. Jika halaman dapat diakses, primer/utama mengirimkan salinan halaman tersebut ke mirror/sekunder.
Jika cermin/sekunder menerima salinan setiap halaman yang dimintanya, cermin/sekunder mencoba melanjutkan sesi pencerminan. Jika upaya perbaikan halaman otomatis memperbaiki halaman yang dicurigai, halaman tersebut ditandai di tabel suspect_pages sebagai dipulihkan (event_type = 4).
Jika mirror/sekunder tidak menerima halaman yang dimintanya dari principal/utama, upaya perbaikan halaman otomatis gagal. Dengan pencerminan database, sesi pencerminan tetap ditangguhkan. Dengan Always On Availability Groups, basis data sekunder tetap dalam keadaan ditangguhkan. Jika sesi pencerminan atau basis data sekunder dilanjutkan secara manual, halaman yang rusak akan kembali ditemukan 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 basis data tercermin atau basis data ketersediaan, Anda harus menangkap pengecualian untuk operasi yang gagal. Jika kode kesalahan SQL Server adalah 823, 824, atau 829, Anda harus mencoba kembali operasi nanti.
Cara: Melihat Upaya Perbaikan Halaman 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 satu baris untuk setiap upaya perbaikan halaman otomatis pada database ketersediaan apa pun di replika ketersediaan yang dihosting oleh instans server untuk grup ketersediaan apa pun.
Pencerminan database:
sys.dm_db_mirroring_auto_page_repair (T-SQL)
Mengembalikan satu baris untuk setiap upaya perbaikan halaman otomatis pada database yang dicerminkan mana pun di instans server.