MSSQL Server suspect olan vt'yi kurtarmak

[pro_imaj]

Merhaba arkadaşlar,

MSSQL Server bazen teknik sorunlardan dolayı daha doğrusu restore işlemi sırasında suspect oluyor ve vtye artık ulaşamıyorsunuz. (Ayvayı yiuoruz) Bunun stored procedure ile yapıldığını öğrendim SQl server yardımında ve nette araştırdım ama böyle bişeye rastlamadım.

Suspect olan datanın kurtarıldığına şahit oldum ama nasıl yapıldığını bilmiyorum. MSSQL hakıında çok iyi bilgileri olan arkadaşlardanda fikir aldım onların bu konudan bilgileri bile yok.

Teşekkür ederim

[Kuri_YJ]

Suspect mi???? Yoksa Suspend mi????

[pro_imaj]

Merhaba

suspect hocam.


Not:arasındaki farkı bilmiyorum ama Bu sorun galiba ldf dosyasının bozulması gibi bir durumdan meydana geliyor diye düşünüyorum.

[Hakan Can]

SQL Server Service Manager'dan servisi durdurunuz.
Veritabanının (Data ve Log) yedeğini alınız. (Normal kopyalayarak)
Bilahare Veritabanının LOG dosyasını siliniz.
SQL Server Service Manager'dan servisi tekrar başlatınız.
Enterprise Manager'ı Açınız veya açıktıysa kapatıp tekrar açınız.
Eğer veritabanı hala Suspect olarak görünüyorsa veritabanını Detach edip bilahare Attach ediniz.

Eğer başka bir problem yoksa veritabanınız geri gelecektir.

İyi çalışmalar.

[pro_imaj]

SQL Server Service Manager'dan servisi durdurunuz.
Veritabanının (Data ve Log) yedeğini alınız. (Normal kopyalayarak)
Bilahare Veritabanının LOG dosyasını siliniz.
SQL Server Service Manager'dan servisi tekrar başlatınız.
Enterprise Manager'ı Açınız veya açıktıysa kapatıp tekrar açınız.
Eğer veritabanı hala Suspect olarak görünüyorsa veritabanını Detach edip bilahare Attach ediniz.

Eğer başka bir problem yoksa veritabanınız geri gelecektir.

İyi çalışmalar.

Merhaba hocam. cevabınız için tşk ederim.

öncelikle birkaç bişey soracam sakıncası yoksa
1-Veritabanının (Data ve Log) yedeğini alınız. (data ve log derken hengi dosyalrı kasdediyorsunuz yani belli bir yolumu var bu dosyaların)

2-Bilahare Veritabanının LOG dosyasını siliniz. (veritabanı log dosyası nerede tutuluyor acab.

3-Eğer veritabanı hala Suspect olarak görünüyorsa veritabanını Detach edip bilahare Attach ediniz. (Detach nedir ve attach işlemiyle birlik bu işlemi nereden nasıl yapabilirim.)

Kusurumu mazur görün.
Teşekkür ederim

[Hakan Can]

MS SQL'de yeni bir veritabanı oluşturulduğunda normalde iki dosya oluşturulur. Diyelim oluşturmak istediğiniz veritabanının adı "Veritabani" olsun, bu durumda "Veritabani_Data.MDF" ve "Veritabani_log.LDF" adında bilgisayarınızda iki dosya oluşacaktır. Eğer özel olarak başka bir adres vermezseniz bu iki dosyayı şu adreslerde tutacaktır:

C:\Program Files\Microsoft SQL Server\MSSQL\data\Veritabani_Data.MDF
C:\Program Files\Microsoft SQL Server\MSSQL\data\Veritabani_log.LDF

Adından da anlaşılacağı gibi ikincisi yani "Veritabani_log.LDF" LOG dosyasıdır.
Suspect problemi birçok nedenden kaynaklanabilir. Bunlardan bir tanesi de Data dosyası ile Log dosyasının uyumsuzluğudur. SQL Server veritabanına bağlanılmaya çalışıldığında bu iki dosyayı kontrol eder.
Eğer uyumsuzluk varsa "Enterprise Manager"da Suspect olarak gösterir.
Normalde LOG dosyaları asıl veri dosyaları değildir. Eğer "SQL Server Service Manager" programını açıp servisi durdurur, bu LOG dosyasını siler, servisi tekrar çalıştırıp "Enterprise Manager"a tekrar girerseniz bu LOG dosyası otomatik olarak tekrar oluşturulur. Bu da probleminizin (Suspect) çözüldüğü anlamına gelir. Eğer Suspect durumu hala devam ediyorsa başka bir yöntem (detach-attach) yöntemi deneyebilirsiniz. Ama önce ilk söylediğim yöntemi bir deneyiniz.

Yalnız herşeyden önce Data ve LOG dosyalarının yedeklerini alınız. Yani "SQL Server Service Manager" programını açıp servisi durdurup başta belirttiğim iki dosyanın yedeklerini (normal kopyalayarak) alınız ki bir terslik olursa verileri tamamen kaybetmeyiniz.

İyi çalışmalar.

[pro_imaj]

İlginiz için tşk ederim @Hakan Can hocam.

Yaptınız açıklamalar ile belirttiğinz şekilde yaptım. Ama sonuç alamadım SQL server log dosyasını tekrar oluşturmadı. Ve değişen bişey yok

Not: SQL server Database'nin üzerinde (Loading/suspect) yazıyor.
bu sorun yedek dönerken oluşmuştu. yani yedeğin iptal edilmesinden kaynaklanmış olabilr diye düşünüyor.

Çalışmalarınızda başarılar üstad saolun.

[pro_imaj]

Merhaba,
@Hakan Can hocam.

Müsait olduğunuzda (detach-attach) metodunuz yazarsanız çok memnun olurum hocam. Diğer yöntem işe yaramdıda.

[Kuri_YJ]

Bir bilgi daha ekleyeyim, Eğer DB Suspect konumunda ise, Bring Online yapmayı deneyin belki de yanlışlıkla, Take Offline yapmış olabilirsiniz.

[pro_imaj]

@Kuri_TLJ Hocam belirtiğiniz sorun diil daha doğrusu online ofline kadar basit bir proplem diil.

Teşekkürler

[doganzorlu]

Selam,

Daha once sys tablolarini elle duzenleyerek yapiliyordu ama simdi birkac script koymuslar;

sp_resetstatus adlı scripti çalıştırın. Ardından dbcc dbrecovery yapın.

Yada ne olduğunu anlamak isterseniz ;

sp_configure "allow updates", 1
use master
begin transaction
update sysdatabases set status = status & ~256
where name="database_name"
commit transaction
sp_configure "allow updates", 0
checkpoint
shutdown

İşlemler bundan ibaret...

[pro_imaj]

Merhaba @doganzorlu hocam.

Dediğiniz şekilde yapamya çalıştım ilk olarak
sp_resetstatus çalıştırdım ama şöyle bir proplem var. Ben mssql serverda master daki sp_resetstatus çalıştırıyorum (benim vtde bu yok daha doğrusu silmişler (link programının vt si) birde hocam bunu mssql server run durumdayken çalıştırınca

Kod: Tümünü seç

Ad hoc updates to system catalogs are not enabled. The system administrator must reconfigure SQL Server to allow this. 
yukarıdaki hayatı veriyor.

Kapalı durumda çalıştırınca ise

Kod: Tümünü seç

[Microsoft][ODBC SQL Server Driver][DBNETLIB]SQL Server yok veya erişim engellendi.
[Microsoft][ODBC SQL Server Driver][DBNETLIB]ConnectionOpen (Connect()).

Connection Broken

Yukarıdaki hatayla karşılaşıyorum.

ikinici olarakta dbcc dbrecovery bunun ne olduğunu bilmediğim için deneyemedim.

teşekkür ederim yardımlarınız için