Not
Bu sayfaya erişim yetkilendirme gerektiriyor. Oturum açmayı veya dizinleri değiştirmeyi deneyebilirsiniz.
Bu sayfaya erişim yetkilendirme gerektiriyor. Dizinleri değiştirmeyi deneyebilirsiniz.
Details
| Attribute | Value |
|---|---|
| Ürün Adı | SQL Server |
| Olay Kimliği | 3414 |
| Olay Kaynağı | MSSQLSERVER |
| Bileşen | SQLEngine |
| Sembolik Ad | REC_GIVEUP |
| İleti Metni | Kurtarma sırasında bir hata meydana geldi ve veritabanı '%.*ls' (veritabanı kimliği %d) yeniden başlatılmasını engelledi. Kurtarma hatalarını tanılayın ve düzeltin veya bilinen iyi bir yedeklemeden geri yükleyin. Hatalar düzeltilmediyse veya beklenmiyorsa Teknik Desteğe başvurun. |
Explanation
Belirtilen veritabanı kurtarıldı ancak kurtarma sırasında hatalar meydana geldiği için açılmadı. Bu hata veritabanını ŞÜPHELİ durumuna soktu. Ana dosya grubu ve muhtemelen diğer dosya grupları şüphelidir ve zarar görebilir. Veritabanı, SQL Server başlatıldığında kurtarılamadığı için erişilebilir değildir. Sorunu çözmek için kullanıcı hareketi gereklidir. ŞÜPHELİ durumunu hem SQL Server Management Studio (veritabanı simgesinin yanında) hem de sys.databases.state_desc sütununa baktığınızda göreceksiniz. Bu durumda bir veritabanı kullanmaya yönelik herhangi bir girişim aşağıdaki hataya yol açar:
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
Bu hata tempdb'de olduğunda, SQL Server örneği kapanır.
Cause
Bu hata, sunucu örneğini başlatma veya veritabanını kurtarma girişimi sırasında sistemde var olan geçici bir durumdan kaynaklanabilir. Bu hata, veritabanını başlatmaya çalıştığınızda her kez yaşanan kalıcı bir arızadan da kaynaklanabilir. Kurtarma hatasının nedeni genellikle ERRORLOG veya Olay Günlüğü'nde Error 3414'ten önceki hatalarda bulunur. Günlük dosyasındaki önceki hata aynı spid<n> değerini içerir. Örneğin, aşağıdaki kurtarma hatası, bir log bloğunu okumaya çalışırken yapılan bir kontrol toplamı hatasından kaynaklanır. Spid15s tüm satırlarda mevcuttur:
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
Veritabanı kurtarmasında başarısız olmanıza neden olabilecek çok çeşitli hata yelpazesi vardır. Her hatayı vaka bazında değerlendirmeniz gerekirken, veritabanı kurtarma hatasının çözümü genellikle aşağıdaki Kullanıcı Eylemi bölümünde açıklananla aynıdır.
Kullanıcı eylemi
3414 hatası nedeniyle bilgi almak için, belirli bir hatayı gösteren önceki bir hatayı Windows Olay Günlüğü veya ERRORLOG'u inceleyin. Uygun kullanıcı eylemi, Windows Olay Günlüğü'ndeki bilgilerin SQL Server hatasının geçici bir durum veya kalıcı bir arızadan kaynaklandığını gösterip göstermediğine bağlıdır. Hata mesajında "kurtarma hatalarını teşhis et ve düzelt ya da bilinen iyi bir yedekten geri yükleme" diyor. Bu nedenle, karşılaştığınız hatayı düzeltmeye çalışarak kurtarmanın tamamlanmasını sağlayabilirsiniz ( bkz. Düzeltilebilir hatalar ve ertelenmiş işlemler).
Hatalar düzeltilemezse, bu sorunu çözmenin ilk ve en iyi yolu iyi bir yedeklemeden geri yüklemektir. Ancak, bir yedekten kurtarılamıyorsanız, tam veri kurtarma garantisi vermeyen iki ek seçeneğiniz vardır: DBCC CHECKDB ile acil onarım kullanmak veya mümkün olduğunca çok veriyi başka bir veritabanına kopyalamaya çalışmak.
- Son bilinen iyi veritabanı yedeklemesinden geri yükleme
- DBCC CHECKDB tarafından sağlanan acil onarım yöntemini kullanın
- Mümkün olduğunca çok veriyi başka bir veritabanına kopyalamaya çalışın.
İyi bir veritabanı yedeklemesini geri yüklemenin ilk yolu, bir veritabanını bilinen tutarlı bir duruma getirmenin en iyi yoludur.
İkinci en iyi seçim, eğer yedek yoksa, veritabanını çevrimiçi ve erişilebilir hale getirmektir. Ancak, kurtarma başarısız olduğu için işlemsel tutarlılığın garanti edilemediğini bilmelisiniz. Hangi işlemlerin geri alınması veya ileriye alınması gerektiği ama kurtarma hatası nedeniyle izin verilmediği bilinmez. Acil onarıma devam etmek için adımlar, DBCC CHECKDB dokümantasyonundaki Acil Durum Modunda Veritabanı Hatalarını Çözme başlıklı bölümde açıklanmıştır.
Acil onarım işe yaramazsa ve bazı verileri başka bir veritabanına kurtarmaya çalışmak isterseniz, veritabanına erişmenin yolu veritabanını dbnameALTER DATABASE< EMERGENCY komutuyla acil durum moduna >SETalmaktır. Sonra verileri tablolardan kopyalamaya çalışabilirsiniz.
Düzeltilebilir hatalar ve ertelenmiş işlemler
Veritabanı kurtarma sırasında karşılaşılan tüm hatalar kurtarma hatasına ve şüpheli bir veritabanına yol açmaz:
Veritabanı ve/veya işlem günlüğü dosyalarını ilk kez açarken hatalar, kurtarmadan önce meydana gelir. Bu tür hatalara örnekler 17204 ve 17207'dir. Bu hatalar düzeltildikten sonra, kurtarma işlemi devam edebilir (ancak başka kurtarma hataları olursa tamamlanması garanti edilmez). 17204 ve 17207 gibi hatalar SUSPECT veritabanı oluşturmaz. Aslında, bu sorunlar ortaya çıktığında veritabanının durumu RECOVERY_PENDING.
SQL Server, sayfa düzeyinde bir hata meydana geldiğinde bile kurtarmanın tamamlanmasına izin verir ve işlemsel tutarlılığı korur. Bu süreç, SUSPECT veritabanı oluşturan senaryo sayısını azaltmıştır. Bu kavrama ertelenmiş işlemler denir.
Kurtarma sırasında karşılaşılan hata, örneğin kontrol toplamı hatası veya Msg 824 gibi bir veritabanı sayfasında bir sorun olduğunu gösteriyorsa, kurtarma bekleyen hatalarla tamamlanabilir. Bir işlem taahhüt edilmemişse, sayfadaki hata ertelenmiş bir işlem ile sonuçlanabilir ve kurtarma tamamlanabilir.
Aşağıdaki ERRORLOG girişleri, kurtarma sırasında karşılaşılan Msg 824 hatasına örnek vermektedir; ancak kurtarma ertelenmiş bir işlemle tamamlanmasına izin verilmiştir. Bu durumda Error 3414'ün olmamasına ve veritabanı için kurtarmanın tamamlandığına dair mesaja dikkat edin:
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.
Eğer bir taahhüt edilen bir işlem ileriye doğru ileriye taşınacaksa, sayfa erişilmez olarak işaretlenebilir (sayfaya erişim için yapılan gelecekteki girişimler Msg 829 ile sonuçlanır) ve kurtarma tamamlanabilir. Bu durumda, hata sayfayı yedekten geri kazandırarak veya DBCC CHECKDB ile onarım ile sayfayı ayırmadan çıkararak düzeltilmelidir.