MSSQL Server Suspect Olmuş Veritabınını Kurtarma

Bu makalede suspect moduna girmiş olan bir veritabanı için neler yapılması gerektiğini sırasıyla görmüş olacağız. Öncelikle veritabanı neden suspect moduna geçer  buna değinelim. Suspect moduna geçen veritabanı erişilemez duruma gelmektedir. Genel olarak suspect moduna girme sebebi veritabanının birincil ve ikincil dosyalarının bozuk olmasından kaynaklanmaktadır.  Özetlemek gerekirse Sql server veritabanı aşağıdaki sorunlardan dolayı suspect moduna düşer.

• Corrupt olmuş MDF, NDF veya LDF dosyaları.
• Veritabanının erişilemeyen veri dosyaları.
• Sistemin aniden kapanması veya yanlış bir şekilde kapatılması.
• Rollback ve roll forward işlemlerinin tamamlanamaması.
• Storage’daki disk alanının çok düşük kalması.
• Sistem sorunları.
• Ani elektrik kesintileri.
• Donanım arızası.

Recovery Pendig ve Suspect mode arasındaki farklar. Suspect modundaki page bazında işlemler recovery pending modun da çalışmaya bilir.

Recovery Pending	Suspect Pages
Veritabanı geri yüklenemiyor (log tamamlanamıyor)	Bozuk page’ler tespit edildi (örn: checksum hatası)
MDF/LDF sorunları nedeniyle recovery işlemi yarım kalıyor	Fiziksel page bozuklukları (disk hatası, torn page, vb.)
msdb.dbo.suspect_pages genelde boş olabilir	msdb.dbo.suspect_pages dolu olur
DBCC CHECKDB çalışmaz (önce emergency moda almalısın)	DBCC CHECKDB çalışır ve bozuk page’leri listeler

Yukarıdaki sebeplerden dolayı suspect moduna girin veritabanı aşağıdaki yöntemler ve  sıralamalarla kurtarılır. Şunu da  belirtmek gerekirse suspect moduna giren bir veritabanının kurtarma aşamasında veri kaybını göz önünde bulundurmanız gerekmektedir. Tüm bu adımları yapmanız için sysadmin olmanız gerekmektedir.

Not: Suspect moduna alınan veritabanının bu haliyle backup almak için copy-only yöntemi ile backup alınması gerekmektedir.

Veritabanınız suspect mode’a düştüğünü aşağıdaki komut ile teyit ederiz.

SELECT DATABASEPROPERTYEX (N'Database_Name', N'STATUS') AS N'Status';

Yöntem 1:

Veritabanını Yedekten Geri Yükleme. Eğer veri kaybına tahammülünüz yoksa veritabanı ile ilgili elinizde bir yedek varsa yedeklemeden kolaylıkla dönülebilir. Bu işlem veritabanınızın boyutuna göre biraz zaman alabilir.

RESTORE DATABASE DatabaseName 

FROM DISK = 'backup_path\backupname.bak ;

Full backup’tan dönmek yerine sadece suspect olmuş page’leri bulup bu page’leri restore edebilirsiniz. Aşağıdaki script yardımıyla suspect olmuş page’leri bulabilirsiniz. İlgili makalede okunabilir. İlgili page hataları düzeltildikten sonra tekrardan kontrol etmek adına dbcc checkdb ve databasepropertyex komutlarıyla  kontrol işlemleri yapılmış olunur. Bu yöntem ile sonuç alınamıyorsa full backup’dan dönülebilir.

select * from msdb..suspect_pages

Yöntem 2:

DBCC CHECKDB komutunu kullanarak suspect modundan veritabanını kurtarma. Aşağıdaki adımlardan önce suspect modunda olan veritabanının yedeği alınması tavisye edilmektedir.

1.Adım

Suspect modu sıfırlamak için aşağıdaki komut kullanılır.

EXEC SP_RESETSTATUS 'DatabaseName';

2. Adım
Veritabanı bakımını güvenli bir şekilde yapmak için emergency modu kullanılır.

ALTER DATABASE DatabaseName SET EMERGENCY

Not: Bu moda alınamıyorsa 3. Adıma geçilebilir. Emergency moduna alındıktan sonra en son adım olarak online moda veritabanının  alınması gerekmektedir.

3. Adım
Veritabanı üzerinde fiziksel ve mantıksal hataların tespiti ve veritabanını tutarlı yapıya getirmek için dbcc komutu kullanılmaktadır.  Eğer tutarlılık kontrolünün hızlı yapılmasını istersek sadece fiziksel olarak tutarlılık tespiti yapılabilir.

Veritabanının hangi sebepten dolayı suspect moda düştüğünü aşağıdaki komutlar ile teyit edilir.

DBCC CHECKDB (N'Database_Name') WITH NO_INFOMSGS, ALL_ERRORMSGS;

DBCC CHECKDB ('DatabaseName') WITH PHYSICAL_ONLY;

4.Adım
Aşağıdaki komutla veritabanımızı tek kullanıcı moduna alıyoruz. Ardından veritabanı üzerinde veri kaybına sebep olabilecek ve bütün hataları düzeltecek repair_allow_data_loss komutunu kullanıyoruz. Bu komutu çalıştırdığımız zaman veritabanımız hemen suspect modundan çıkmaktadır. Daha sonra tekrardan veritabanımızı multi user moduyla kullanıma açıyoruz.

ALTER DATABASE DatabaseName SET SINGLE_USER WITH ROLLBACK IMMEDIATE

DBCC CHECKDB (' DatabaseName', REPAIR_ALLOW_DATA_LOSS)

ALTER DATABASE DatabaseName SET online;-- Başlangıçta veritabanımızı emergency moduna aldığımız için tekrardan online moduna alıyoruz.

ALTER DATABASE DatabaseName SET MULTI_USER

Not: Yukarıdaki dbccc checkdb(‘db_name’) komutundan sonra   repair_rebuild önerilirse ilgili komutun kullanılması gerekmektedir. Yani repair allow data loss komutu kullanılmaz. 4. Adımdaki komutlar yerine aşağıdaki komutlar kullanılır.

ALTER DATABASE DatabaseName SET SINGLE_USER WITH ROLLBACK IMMEDIATE
DBCC CHECKDB (' DatabaseName', REPAIR_REBUILD)
ALTER DATABASE DatabaseName SET online
ALTER DATABASE DatabaseName SET MULTI_USER

Not: Suspect olmuş veritabanı yanlışlıkla detach edilirse tekrardan restore edip kurtarma işlemi yapamıyacağımız için aynı isimde bir veritabanı oluşturup daha sonra sql servisi durdurulur ve mdf ldf dosyası aynı isimle oluşturulmuş system dosyalarının üzerine kopyalanır. Daha sonra ssms’den yukarıdaki işlemlerin aynısı yapılabilir.

Not: Veritabanı başlangıçta single_user yerine resricted_user modunada alına bilmektedir.

Bu makalede sql server üzerinde bulunan veritabanının suspect moduna düştükten sonra yapılması gereken işlemleri ele almış olduk.

Başka bir makalede görüşmek dileğiyle..

“Konumunla övünme, Firavun’a bak!”  Yûnus-91