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
Detail
| Atribut | Nilai |
|---|---|
| Nama Produk | SQL Server |
| ID Peristiwa | 3414 |
| Sumber Kejadian | MSSQLSERVER |
| Komponen | SQLEngine |
| Nama Simbolis | REC_GIVEUP |
| Teks Pesan | Terjadi kesalahan selama pemulihan, mencegah database '%.*ls' (ID database %d) dimulai ulang. Diagnosis kesalahan pemulihan dan perbaiki, atau pulihkan dari cadangan yang diketahui baik. Jika kesalahan tidak dikoreksi atau diharapkan, hubungi Dukungan Teknis. |
Penjelasan
Database yang ditentukan telah dipulihkan, tetapi gagal dimulai, karena terjadi kesalahan selama pemulihan. Kesalahan ini telah menempatkan database dalam status SUSPECT. Grup file utama, dan mungkin grup file lainnya, dicurigai dan mungkin rusak. Database tidak dapat dipulihkan selama startup SQL Server dan karenanya tidak tersedia. Tindakan pengguna diperlukan untuk mengatasi masalah. Anda akan melihat status SUSPECT di SQL Server Management Studio (di samping ikon database) dan saat Anda melihat kolom sys.databases.state_desc. Setiap upaya untuk menggunakan database dalam status ini akan mengakibatkan kesalahan berikut:
Msg 926, Level 14, State 1, Line 1
Database 'mydb' cannot be opened. It has been marked SUSPECT by recovery. See the SQL Server errorlog for more information
Perhatikan bahwa ketika kesalahan ini terjadi dalam tempdb, instans SQL Server dimatikan.
Penyebab
Kesalahan ini dapat disebabkan oleh kondisi sementara yang ada pada sistem selama upaya tertentu untuk memulai instans server atau memulihkan database. Kesalahan ini juga dapat disebabkan oleh kegagalan permanen yang terjadi setiap kali Anda mencoba memulai database. Penyebab kegagalan pemulihan biasanya ditemukan dalam kesalahan yang mendahului Kesalahan 3414 di ERRORLOG atau Log Peristiwa. Kesalahan sebelumnya dalam file log berisi nilai n spid<> yang sama. Misalnya, kegagalan pemulihan berikut disebabkan oleh kesalahan checksum saat mencoba membaca blok log. Catatan spid15s ada di semua baris:
2020-03-31 17:33:13.00 spid15s Error: 824, Severity: 24, State: 4.
2020-03-31 17:33:13.00 spid15s SQL Server detected a logical consistency-based I/O error: (bad checksum). It occurred during a read of page (0:-1) in database ID 13 at offset 0x0000000000b800 in file 'C:\Program Files\Microsoft SQL Server\MSSQL10.SQL2008\MSSQL\DATA\mydb_log.LDF'. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.
2020-03-31 17:33:13.16 spid15s Error: 3414, Severity: 21, State: 1.
2020-03-31 17:33:13.16 spid15s An error occurred during recovery, preventing the database 'mydb' (database ID 13) from restarting. Diagnose the recovery errors and fix them, or restore from a known good backup. If errors are not corrected or expected, contact Technical Support
Ada berbagai kesalahan yang dapat menyebabkan pemulihan database gagal. Meskipun Anda harus mengevaluasi setiap kesalahan berdasarkan kasus per kasus, resolusi untuk kegagalan pemulihan database biasanya sama seperti yang dijelaskan di bagian Tindakan Pengguna di bawah ini.
Tindakan pengguna
Untuk informasi tentang penyebab terjadinya kesalahan 3414 ini, periksa Log Peristiwa Windows atau ERRORLOG untuk kesalahan sebelumnya yang menunjukkan kegagalan tertentu. Tindakan pengguna yang sesuai bergantung pada apakah informasi di Log Peristiwa Windows menunjukkan bahwa kesalahan SQL Server disebabkan oleh kondisi sementara atau kegagalan permanen. Pesan kesalahan menyatakan untuk "mendiagnosis kesalahan pemulihan dan memperbaikinya, atau memulihkan dari cadangan yang diketahui baik". Oleh karena itu, Anda dapat mencoba memperbaiki kesalahan yang Anda temui untuk memungkinkan pemulihan selesai (lihat Kesalahan yang dapat dikoreksi dan transaksi yang ditangguhkan).
Jika kesalahan tidak dapat dikoreksi, opsi pertama dan terbaik untuk mengatasi masalah ini adalah memulihkan dari cadangan yang baik. Namun, jika Anda tidak dapat memulihkan dari cadangan, Anda memiliki dua opsi tambahan, yang tidak menjamin pemulihan data penuh: gunakan perbaikan darurat dengan DBCC CHECKDB atau mencoba menyalin data sebanyak mungkin ke database lain.
- Pulihkan dari cadangan database baik terakhir yang diketahui
- Gunakan metode perbaikan darurat yang disediakan oleh DBCC CHECKDB
- Coba salin data sebanyak mungkin ke database lain.
Metode pertama untuk memulihkan cadangan database yang baik adalah pilihan terbaik untuk membawa database ke keadaan konsisten yang diketahui.
Pilihan terbaik kedua, jika tidak ada cadangan yang tersedia, adalah membuat database online dan dapat diakses. Namun, Anda harus menyadari bahwa konsistensi transaksi tidak dapat dijamin karena pemulihan gagal. Tidak ada cara untuk mengetahui transaksi apa yang seharusnya digulung balik atau digulirkan ke depan tetapi tidak diizinkan karena kegagalan pemulihan. Langkah-langkah untuk melanjutkan perbaikan darurat dijelaskan di bagian berjudul Mengatasi Kesalahan Database dalam Mode Darurat dalam dokumentasi DBCC CHECKDB.
Jika perbaikan darurat tidak berfungsi dan Anda ingin mencoba menyelamatkan beberapa data ke database lain, cara untuk mendapatkan akses ke database adalah dengan mengatur database dalam mode darurat melalui perintah ALTER DATABASE <dbname> SET EMERGENCY. Kemudian Anda dapat mencoba menyalin data dari tabel.
Kesalahan yang dapat dikoreksi dan transaksi yang ditangguhkan
Tidak semua kesalahan yang ditemui selama pemulihan database akan mengakibatkan kegagalan pemulihan dan database tersangka:
Kesalahan saat membuka database dan/atau file log transaksi untuk pertama kalinya, terjadi sebelum pemulihan. Contoh kesalahan tersebut adalah 17204 dan 17207. Setelah kesalahan ini diperbaiki, pemulihan mungkin diizinkan untuk melanjutkan (tetapi tidak dijamin selesai jika terjadi kesalahan pemulihan lainnya). Kesalahan seperti 17204 dan 17207 tidak mengakibatkan database SUSPECT. Bahkan, status database RECOVERY_PENDING ketika masalah ini terjadi.
SQL Server memungkinkan pemulihan selesai bahkan ketika kesalahan tingkat halaman terjadi dan masih akan mempertahankan konsistensi transaksi. Proses ini telah mengurangi jumlah skenario yang menghasilkan database SUSPECT. Konsep ini disebut sebagai transaksi yang ditangguhkan.
Jika kesalahan yang ditemui selama pemulihan menunjukkan masalah dengan halaman database, misalnya sebagai kesalahan checksum atau Msg 824, pemulihan mungkin diizinkan untuk menyelesaikan kesalahan yang tertunda. Jika transaksi tidak dilakukan, kesalahan pada halaman dapat mengakibatkan transaksi yang ditangguhkan yang memungkinkan pemulihan selesai.
Entri ERRORLOG berikut menunjukkan contoh kesalahan Msg 824 yang ditemui selama pemulihan tetapi pemulihan diizinkan untuk diselesaikan dengan transaksi yang ditangguhkan. Perhatikan tidak adanya Kesalahan 3414 dalam situasi ini dan pesan bahwa pemulihan telah selesai untuk database:
2010-03-31 19:17:18.45 spid7s SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0xb2c87a0a; actual: 0xb6c0a5e2). It occurred during a read of page (1:153) in database ID 13 at offset 0x00000000132000 in file 'C:\Program Files\Microsoft SQL Server\MSSQL10.SQL2008\MSSQL\DATA\mydb.mdf'. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.
2010-03-31 19:17:18.45 spid7s Error: 3314, Severity: 21, State: 1.
2010-03-31 19:17:18.45 spid7s During undoing of a logged operation in database 'mydb', an error occurred at log record ID (25:100:19). Typically, the specific failure is logged previously as an error in the Windows Event Log service. Restore the database or file from a backup, or repair the database.
2010-03-31 19:17:18.45 spid7s Errors occurred during recovery while rolling back a transaction. The transaction was deferred. Restore the bad page or file, and re-run recovery.
2010-03-31 19:17:18.45 spid7s Recovery completed for database mydb (database ID 13) in 2 second(s) (analysis 204 ms, redo 25 ms, undo 1832 ms.) This is an informational message only. No user action is required.
Jika transaksi yang diterapkan akan digulirkan ke depan, halaman dapat ditandai tidak dapat diakses (setiap upaya di masa mendatang untuk mengakses halaman menghasilkan Msg 829) dan pemulihan dapat diselesaikan. Dalam situasi ini, kesalahan harus diperbaiki dengan memulihkan halaman dari cadangan atau dengan membatalkan alokasi halaman menggunakan DBCC CHECKDB dengan perbaikan.
Lihat juga
MENGUBAH DATABASE (T-SQL)
DBCC CHECKDB (Transact-SQL)
Pemulihan Database Lengkap (Model Pemulihan Sederhana)
Transaksi yang Ditangguhkan
MSSQLSERVER_824
sys.databases (T-SQL)