İşlem günlüğünü yeniden oluşturma

İşlem günlüğü dosyası silinmiş olan çok büyük bir veritabanımız (~ 6 TB) var (SQL Server kapatılırken.

1. Veritabanının sökülmesi ve yeniden takılması; ve
2. İşlem günlüğü dosyasının kaydını silme

... ama şimdiye kadar hiçbir şey işe yaramadı.

Şu anda çalışıyoruz:

ALTER DATABASE <dbname> REBUILD 
LOG ON (NAME=<dbname>,FILENAME='<logfilepath>')

... ancak veritabanının boyutu göz önüne alındığında, bu işlemin tamamlanması birkaç gün sürecektir.

Sorular

• Yukarıdaki komut ile aşağıdaki komut arasında bir fark var mı?

  DBCC CHECKDB ('<dbname>', REPAIR_ALLOW_DATA_LOSS)

• Bunun REPAIR_ALLOW_DATA_LOSSyerine idam mı etmeliyiz ?

Verilerin diğer kaynaklardan elde edildiğine dikkat çekmek önemlidir, bu nedenle veritabanını yeniden oluşturabilir, ancak veritabanını onarmanın tüm verileri yeniden yerleştirmekten çok daha hızlı olacağını düşünüyoruz.

Güncelleştirme

Skoru olanlar için: ALTER DATABASE/REBUILD LOGKomut 36 saat sonra tamamlandı ve şunları bildirdi:

Uyarı: 'dbname' veritabanı günlüğü yeniden oluşturuldu. İşlem tutarlılığı kayboldu. RESTORE zinciri koptu ve sunucunun önceki günlük dosyalarında artık bağlamı olmadığından, ne olduklarını bilmeniz gerekecek.
Fiziksel tutarlılığı doğrulamak için DBCC CHECKDB çalıştırmalısınız. Veritabanı yalnızca dbo moduna geçirildi. Veritabanını kullanıma hazır hale getirmeye hazır olduğunuzda, veritabanı seçeneklerini sıfırlamanız ve fazladan günlük dosyalarını silmeniz gerekir.

Sonra DBCC CHECKDBbaşarılı bir (yaklaşık 13 saat sürdü) koştu . Diyelim ki hepimiz veritabanı yedeklemelerinin önemini öğrendik (ve proje yöneticilerine sunucuya erişim izni veriyoruz ...).

Şüpheli bir veritabanını asla ayırmayın. Her neyse, veritabanını çıkardıktan sonra nasıl eklediniz? Kullanılan CREATE DATABASEile FOR ATTACH_REBUILD_LOGseçeneğiyle?

Bu komutlar hile yapmış olmalı:

ALTER DATABASE recovery_test_2 SET EMERGENCY;   
ALTER DATABASE recovery_test_2 SET SINGLE_USER;  

DBCC CHECKDB (recovery_test_2, REPAIR_ALLOW_DATA_LOSS) 
WITH NO_INFOMSGS, ALL_ERRORMSGS;

Bu durum için bir yazı yazdım:

SQL 2005/2008 Veritabanı Kurtarma Yordamı - Günlük Dosyası Silindi (Bölüm 3)

Arasındaki farkı sordunuz:

• DBCC CHECKDB ('<dbname>', REPAIR_ALLOW_DATA_LOSS) ve
• ALTER DATABASE <dbname> REBUILD LOG ON (NAME=<dbname>,FILENAME='<logfilepath>')

Mesele şu ki, günlük dosyasını yeniden oluşturmak için her ikisini de çalıştırabilirsiniz, ancak CHECKDBgünlüğü yeniden oluşturup veritabanını bütünlük hataları için kontrol edin.

Ayrıca, günlük dosyası kaybolduğunda etkin işlemler (diske yazılmadı) varsa, ikinci (veritabanı değiştir) çalışmaz. Başlatma veya ekleme sırasında, SQL Server, orada olmayan günlük dosyasından kurtarma (geri alma ve geri alma) gerçekleştirmek isteyecektir. Bir disk çöktüğünde veya sunucunun beklenmedik bir şekilde kapanması gerçekleştiğinde ve veritabanı temiz bir şekilde kapatılmadığında oluşur. Sanırım senin durumun değildi ve hepsi senin için iyi sıralandı.

1. DBCC CHECKDB (DBNAME, REPAIR_ALLOW_DATA_LOSS)acil durumda bir veritabanında çalıştırmak veritabanında tutarsızlık hataları olup olmadığını denetler, tutarsızlıkları kurtarmak için önce günlük dosyasını kullanmaya çalışır. Bu eksikse, işlem günlüğü yeniden oluşturulur.

2. ALTER DATABASE REBUILD LOG ON...belgelenmemiş bir yordamdır ve sonraki DBCC CHECKDBhataları düzeltmek için bunu gerektirir .

Evet, bunlar iki farklı ifade, her biri çok farklı şeyler yapıyor.

Dosya silinmiş zaman veritabanının durumuna bağlı olarak, olabilir yukarı ve veritabanını iliştirmek ve kullanarak günlüğünü yeniden tarafından çalışan elde edebilmek:

EXEC sp_attach_single_file_db 'dbname here', 'file path and name here'

Ürün belgelerindeki sp_attach_single_file_db (Transact-SQL) konusuna bakın .

Ayrıca Paul S. Randal'ın bu blog gönderisine de bakınız :

ACİL mod onarımı: en son çare