itech

Hi, the WSUS DB (MSSQL Express 2005) of a customer won’t start after a hardware failure and bluescreen. Here are the steps which recovers the database back in an usable state. The SQL Server Instance logs errors like this "Could not redo log record (183366:6166:54), for transaction ID (0:117029942), on page (1:657511), database 'SUSDB' (database ID 5). Page: LSN = (183267:2976:260), type = 2. Log: OpCode = 2, context 3, PrevPageLSN: (183366:1717:287). Restore from a backup of the database, or repair the database." in  “C:\Windows\SYSMSI\SSEE\MSSQL.2005\MSSQL\LOG\ERRORLOG”  and the database is down. First connect to the DB Instance using a named pipe c:\> sqlcmd -S np:\\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query and see state of the Database. Replace SUSDB with the Databasename of your DB. Try to repair the Database. The repair attempt fails… DBCC CHECKDB ('SUSDB') WITH NO_INFOMSGS, ALL_ERRORMSGS; go Error MEssage: Database ‘SUSDB’ cannot be opened

Zaman zaman dataguardlarda production ortamlarda yaşanan archive kayıplarından dolayı senkronizasyonun durması problemiyle kaşılaşırız. Alında bu durumun birden fazla nedeni olabilmektedir. Production ortamda disk doluluğu gibi bir durumla karşılaşıldığında henüz apply olmamış bir logun silinmesi veya DG tarafı düzgün bir periyod ile kontrol edilmediğinde gap’ de kalmış olabileceği ve productiondaki archive’ ların ezilmesi gibi durumlarda DG’ ımız artık ilerleyemeyeceği için işlevselliğini bir ölçüde kaybetmiş oluyor. Bu problemi aşmanın yolu Dg ‘ nın kalmış olduğu noktayı tespit edip, o noktadan itibaren PROD ortamdan (incremantal) backup alıp DG ortamına recover etmekdir. Bahsettiğimiz işlemi adım adım nasıl yapabileceğimizden bahsedelim ; Öncelikle Standby tarafında apply işlemini durdurup kalınan sequence noktasını tespit ediyoruz. Bu noktayı tespit ederken aşağıdaki 3 sql’ den faydalanıyoruz. Bu 3 sql ‘den gelen değerlerden en düşük olan hangisi ise o noktayı dikkate alıyoruz.

Hemen hemen her prod ortamın aslında bir test ortamı bulunuyor ancak kimi zaman test ortamlarındaki data büyüklüğü veya test ortamının bulunduğu sunucunun özelliklerinden dolayı test ortamında yapılan bir test PROD ortama implemente edildiğinde test ortamındaki ile benzer sonuçları veremeyebiliryor. Bu yüzden kimi zaman (DG’ ında bulunduğu sunucunun donanım özellikleri prod ile çoğu zaman aynı olamayabiliyor ancak en azından aynı data üzerinde işlem yapabilme şansını sağlıyor) gerçeğe daha yakın sonuçlar alabilmek adına DG ortamlarını test ortamı gibi kullanabilmemiz gerekebiliyor. Bu tarz durumlarda karşılaştığımız da DG’ ı nasıl test ortamına dönüştürebileceğimizden ve sonrasında tekrar nasıl DG yapabileceğimizden bahsetmek istiyorum; -- Öncelike standby database’ imizde flash_recovery_file_dest ve file_dest_size parametrelerimizin tanımlı olduğundan emin olmamız gerekiyor. BU parametreler database’ i flashback moda alabilmemiz için gerekiyor. Daha önce bu parametreler set edilmemi