SQL Server uygulamanız 'database in recovery' veya 'suspect' moduna geçti. Veri kaybı korkusu hat safhada. Doğru tanılama ve adım adım kurtarma ile çoğu durumda tam restore mümkündür.
Bozulma Belirtileri
SUSPECT veya RECOVERY_PENDING state
Uygulama 'cannot open database' hataları
DBCC CHECKDB hata raporu
Sayfa I/O hataları (823, 824, 825 error)
Adım 1: Anında Yedek
Bozulma tespit edildiğinde HEMEN T-LOG backup alın (mümkünse). Bu son veri kaybı noktanız.
Mevcut .mdf/.ldf dosyalarını ayrı bir konuma kopyalayın — restore başarısızlığa karşı sigorta.
Adım 2: DBCC CHECKDB
DBCC CHECKDB('DB_NAME') WITH NO_INFOMSGS, ALL_ERRORMSGS
Çıktıda 'consistency errors' ve etkilenen object_id, page_id. REPAIR_REBUILD veri kaybı yok ama sınırlı. REPAIR_ALLOW_DATA_LOSS son çare — veri kaybı.
Adım 3: Restore Stratejisi
Tam DB restore + T-Log: Bozulma öncesi son full backup'tan restore, üstüne T-Log apply. Point-in-Time recovery.
Sadece tek tablo bozulmuşsa partial restore. Backup'ı başka instance'a restore edip etkilenen tabloyu BCP ile transfer.
Smyrna Bilgi Teknolojileri olarak İzmir'deki müşterilere SQL Server kurtarma ve veri tabanı bakım hizmeti sunuyoruz.
Sıkça Sorulan Sorular
REPAIR_ALLOW_DATA_LOSS güvenli mi?
İsim açıklayıcı — veri kaybı olur. Sadece backup yoksa ve son çare olarak.
Page Verify ne kullanmalıyım?
CHECKSUM önerilen. Eski TORN_PAGE veya NONE kullanmayın.
Bozulmayı nasıl önlerim?
Düzenli DBCC CHECKDB (haftalık), SQL Server Agent alert, doğru storage subsystem, T-Log düzenli backup.
Yardıma mı ihtiyacınız var?
İzmir Bayraklı merkezli ekibimiz aynı gün yerinde müdahale ediyor.
+90 542 767 00 29 Teklif Alİlgili konular: Yedek Alma · DR Plan