Bu makalemizde Database Suspect olayini inceleyip, database de meydana gelen hatalarin onarilarak verilerin kurtarilmasi islemlerinden bahsedecegiz.

Suspect olayi hangi durumlarda gerçeklesir önce olasilari siralayalim.

# Database birden fazla .mdf ve .log dosyasindan olusabilir.

# Database’in alani yetmedigi için parçalamis olabilir.

# Database özelliklerinde belirtilen bu dosyalar dogru yollarda olmayabilir.

# Database de asiri sisme olabilir.

Simdi böyle bir durumla karsilastigimizda neler yapmaliyiz?

Asagida bu gibi durumlarin üstesinden gelebilmenizi saglayacak birkaç farkli yöntem anlatilmakta fakat yöntemlerimize geçmeden önce bilmemiz gereken bazi terimlerden bahsedelim.

DBCC CHECKDB: Veritabaninda meydana gelen hatalari kontrol etmemizi saglayan bir prosedürdür ve suspect modunda oldugu gibi herhangi bir veritabani bozulma durumlarinda kullaniriz.

Asagida bir kaç örnek CHECKDB prosedürleri yer almaktadir.

Use master
DBCC CHECKDB (’ASIRuleSvc’)
DBCC CHECKDB (’EventHistory’)
DBCC CHECKDB (’Meta’)
DBCC CHECKDB (’OPCLoad’)
DBCC CHECKDB (’Object’)
DBCC CHECKDB (’ObjectEvents’)
DBCC CHECKDB (’ObjectQueues’)
DBCC CHECKDB (’RODM’)
DBCC CHECKDB (’RODMLoad’)
DBCC CHECKDB (’WebServer’)
DBCC CHECKDB (’model’)
DBCC CHECKDB (’msdb’)
GO

CHECKDB yapilirken karsilasilan sorunlardan min. hata ve 0 veri kaybi olacak sekilde kurtulabilmek için bazi komutlardan yararlanilir.

Kullanilan bu komutlarin genel islevlerine göz atalim isterseniz.

REPAIR_FAST: Geriye dönük veri onarim islevini gerçeklestirir. Veri kaybi olmaz fakat hata alma olasiligi digerlerine göre daha fazladir.

REPAIR_REBUILD: Bir önceki islevden bir sonuç alinamadigi zaman kullanilabilir, veri kaybi olmaz fakat hata alma olasiligi vardir.

REPAIR_ALLOW_DATA_LOSS: Rebuild yaptiginiz halde hata almissaniz bu islemi deneyebilirsiniz fakat veri kaybi olasiligi vardir. Bu nedenle öncesinde yedekleme yapilmalidir.

Önemli bir hatirlatma yapalim; suspect modundaki veritabanini sakin "Detach" etmeyin yoksa bir daha "Attach" edemezsiniz. Bu durumda öncelikle .mdf ve .log dosyalarini yedekleyerek asagidaki yöntemleri sirayla deneyerek herhangi birisiyle sonuca ulasabilirsiniz.

Genelde ilk yöntemden olumlu sonuç alinan suspect olaylariyla karsilasiliyor. Bu nedenle önceligi bu siraya göre yazmaya çalistim. Ayrica herbir yöntemin sonunda SQL Server’i restart etmeyi unutmayin.

1.Yöntem için asagidaki komutlari ard arda çalistirmayi deneyin.

EXEC SP_RESETSTATUS ’DatabaseName’;

ALTER DATABASE DatabaseName SET EMERGENCY

DBCC CHECKDB(’DatabaseName’)

ALTER DATABASE DatabaseName SET SINGLE_USER WITH ROLLBACK IMMEDIATE

DBCC CHECKDB (’DatabaseName’, REPAIR_ALLOW_DATA_LOSS)

ALTER DATABASE DatabaseName SET MULTI_USER

2.Yöntem, yukaridaki islem sonuç vermediyse asagidakini deneyebilirsiniz.

DBCC CHECKDB (‘DatabaseName’, REPAIR_ALLOW_DATA_LOSS)
DBCC CHECKDB (‘DatabaseName’)
DBCC CHECKDB (‘DatabaseName’, REPAIR_REBUILD)

3.Yöntem,

USE master;
GO
EXEC sp_resetstatus’DatabaseName’;
USE DatabaseName;
DBCC CHECKDB WITH NO_INFOMSGS;

4.Yöntem,

USE master;
GO
ALTER DATABASE DatabaseName SET EMERGENCY

ALTER DATABASE DatabaseName SET SINGLE_USER

DBCC CHECKDB(DatabaseName, REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS;

USE DatabaseName;
DBCC CHECKDB WITH NO_INFOMSGS;

Herkese iyi çalismalar...