SQL Server ve MySQL Veritabanı Kurtarma: MDF, InnoDB ve Suspect Mode

Hızlı cevap: Veritabanınız açılmıyorsa veya suspect moduna düştüyse panikle DROP/REPAIR komutu çalıştırmayın. Önce veritabanı dosyalarının (MDF/LDF ya da InnoDB sayfaları) güvenli bir kopyasını alın. SQL Server'da DBCC CHECKDB ile hasar haritalanır, MySQL'de InnoDB recovery seviyeleri denenir. Ancak repair komutları veri kaybettirebilir. Kritik bir veritabanında profesyonel destek şarttır. DSET, Ankara Hacettepe Teknokent Beytepe laboratuvarında veritabanı kurtarıyor: +90 536 662 38 09.

Veritabanı dosyaları nasıl çalışır?

Microsoft SQL Server verisini iki ana dosyada tutar: MDF (ana veri dosyası) ve LDF (transaction log, işlem günlüğü). MDF tablolarınızı ve indekslerinizi barındırır, LDF ise henüz kalıcılaşmamış işlemleri kaydederek tutarlılığı sağlar. İkisi birlikte tutarlı bir bütün oluşturur. LDF'yi kaybetmek çoğu zaman MDF'yi yarım bırakır.

MySQL tarafında iki ana depolama motoru vardır. InnoDB modern varsayılandır, işlem desteği (ACID) ve kilit yönetimi sunar, verisini ibdata dosyaları ve tablo başına .ibd dosyalarında tutar. MyISAM ise eski ve daha basittir, her tabloyu .MYD (veri) ve .MYI (indeks) olarak ayrı saklar. Bozulma davranışları çok farklıdır.

Sistem Veri dosyası Log/indeks İşlem desteği
SQL Server MDF LDF Var
MySQL InnoDB ibdata, .ibd redo log Var (ACID)
MySQL MyISAM .MYD .MYI Yok

Suspect mode ve sayfa bozulması nedir?

SQL Server bir veritabanını açarken tutarlılık kontrolü yapar. Eğer LDF okunamıyorsa ya da kurtarma işlemi tamamlanamıyorsa veritabanını SUSPECT olarak işaretler ve erişime kapatır. Bu bir koruma mekanizmasıdır, sistem bozuk veriyle çalışmamayı tercih eder.

Sayfa bozulması (page corruption) ise daha sinsidir. SQL Server veriyi 8 KB'lik sayfalar halinde saklar. Disk hatası, denetleyici arızası ya da ani kapanma bir sayfayı bozduğunda, o sayfaya dokunan sorgu hata verir ama veritabanı bütün olarak ayakta kalabilir. DBCC CHECKDB tam da bu sayfa düzeyindeki hasarı haritalamak için vardır.

DBCC CHECKDB ve onarım komutlarının tehlikesi

DBCC CHECKDB, SQL Server'ın yerleşik tutarlılık denetleyicisidir. Mantıksal ve fiziksel bütünlüğü tarar, bozuk sayfaları ve indeksleri raporlar. Buraya kadar güvenlidir, çünkü sadece okur ve rapor verir.

Tehlike onarım seçeneklerindedir. REPAIR_ALLOW_DATA_LOSS parametresi adından da anlaşılacağı gibi veri kaybına izin verir. Bozuk sayfaları onaramazsa siler. Bu komut bazen veritabanını açar ama içindeki kritik kayıtları yok edebilir. Microsoft bunu son çare olarak ve mutlaka yedek aldıktan sonra önerir. Kritik bir üretim veritabanında bu komutu körlemesine çalıştırmak veri kurtarmada veriyi yok eden hataların tipik bir örneğidir.

MySQL InnoDB tarafında benzer bir araç innodb_force_recovery seviyeleridir. 1'den 6'ya kadar artan agresiflikte kurtarma denenir ama 4 ve üzeri seviyeler veriyi kalıcı bozabilir. MyISAM'da ise myisamchk aracı .MYI indeksini onarır.

Neden RAID üstündeki veritabanı iki katmanlı kurtarma ister?

Kurumsal veritabanları neredeyse her zaman RAID dizisi üzerinde çalışır. RAID 5 veya RAID 10 dizilerinde veri birden çok diske paylaştırılır. Bir disk arızalandığında dizi çökerse, önce RAID seviyesinin kurtarılması gerekir.

İşte kritik nokta: RAID kurtarması ile veritabanı kurtarması iki ayrı katmandır. Önce diziyi doğru parametrelerle (şerit boyutu, disk sırası, parite dönüşü) yeniden inşa edip tutarlı bir blok seviyesi imaj elde etmelisiniz. Ancak bu imaj doğruysa üzerindeki MDF veya InnoDB dosyaları anlamlı olur. RAID yanlış kurulursa veritabanı dosyaları bozuk görünür ve insanlar boş yere DB onarımıyla uğraşır. Bu yüzden RAID üstü veritabanı vakaları uzmanlık ister. Konunun temeli için veri kurtarma nedir rehberimize bakabilirsiniz.

Yedek ve transaction log neden bu kadar önemli?

En iyi veritabanı kurtarması, hiç gerekmeyen kurtarmadır. Düzenli tam yedek artı transaction log yedeği alan bir sistemde, bir bozulma anında belirli bir zamana geri dönmek (point-in-time recovery) mümkündür. LDF zinciri sağlamsa, son tutarlı andan itibaren işlemleri yeniden oynatabilirsiniz.

Bu yüzden kuralımız nettir: bir veritabanı bozulduğunda LDF veya redo log dosyalarına asla dokunmayın, silmeyin, taşımayın. Çoğu kurtarılabilir vaka, panikleyen birinin log dosyasını silmesiyle kurtarılamaz hale gelir.

Sık Sorulan Sorular (SSS)

Suspect moduna düşen veritabanını nasıl açarım? Önce dosyaların kopyasını alın. EMERGENCY moduna alıp DBCC CHECKDB ile hasarı görmek ilk adımdır, ama REPAIR_ALLOW_DATA_LOSS veri kaybettirir. Kritik veride uzmana danışın.

MDF dosyam var ama LDF kayboldu, kurtarılır mı? Çoğu durumda evet, SQL Server LDF olmadan da MDF'den veritabanını yeniden kurabilir ama tutarlılık riski vardır. Tamamlanmamış işlemler kaybolabilir.

MySQL ibdata dosyam bozuldu, ne yapmalıyım? Önce sunucuyu durdurun ve tüm veri klasörünün kopyasını alın. innodb_force_recovery düşük seviyeden denenir, ama yüksek seviyeler tehlikelidir. Mümkünse mysqldump ile veriyi dışa aktarın.

DBCC CHECKDB hata verdi, veritabanım gitti mi? Hayır. CHECKDB sadece raporlar, silmez. Hata mesajındaki sayfa numaraları kurtarma stratejisini belirler. Asıl tehlike onarım komutundadır.

Veri çıkmazsa ücret alıyor musunuz? Hayır. DSET'te ilk teşhis ücretsizdir ve veri kurtarılamazsa ücret alınmaz. Gizlilik ve süreç için güvenlik yazımızı okuyun.

Kaynaklar