Membangun kembali log transaksi

Kami memiliki basis data yang sangat besar (~ 6TB), yang file log transaksinya dihapus (sementara SQL Server dimatikan. Kami telah mencoba:

1. Melepaskan dan memasang kembali basis data; dan
2. Membatalkan penghapusan file log transaksi

... tapi tidak ada yang berhasil sejauh ini.

Kami sedang menjalankan:

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

... tetapi mengingat ukuran database, ini mungkin akan memakan waktu beberapa hari untuk selesai.

Pertanyaan

• Apakah ada perbedaan antara perintah di atas dan yang berikut?

  DBCC CHECKDB ('<dbname>', REPAIR_ALLOW_DATA_LOSS)

• Haruskah kita mengeksekusi REPAIR_ALLOW_DATA_LOSS?

Perlu dicatat bahwa data tersebut berasal dari sumber lain sehingga database dapat dibangun kembali, namun kami menduga akan jauh lebih cepat untuk memperbaiki database daripada memasukkan kembali semua data lagi.

Memperbarui

Bagi mereka yang mempertahankan skor: ALTER DATABASE/REBUILD LOGperintah selesai setelah sekitar 36 jam dan dilaporkan:

Peringatan: Log untuk database 'dbname' telah dibangun kembali. Konsistensi transaksional telah hilang. Rantai RESTORE rusak, dan server tidak lagi memiliki konteks pada file log sebelumnya, jadi Anda perlu tahu apa itu.
Anda harus menjalankan DBCC CHECKDB untuk memvalidasi konsistensi fisik. Basis data telah dimasukkan ke mode dbo-only. Saat Anda siap membuat database tersedia untuk digunakan, Anda perlu mengatur ulang opsi database dan menghapus file log tambahan apa pun.

Kami kemudian menjalankan DBCC CHECKDB(mengambil sekitar 13 jam) yang berhasil. Anggap saja kita semua telah belajar pentingnya cadangan basis data (dan memberikan manajer proyek akses ke server ...).

Jangan pernah melepaskan basis data Suspect. Lagi pula, bagaimana Anda melampirkan database setelah melepaskannya? Anda digunakan CREATE DATABASEdengan FOR ATTACH_REBUILD_LOGpilihan?

Perintah-perintah ini seharusnya melakukan trik:

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;

Saya menulis posting untuk situasi ini:

SQL 2005/2008 Prosedur Pemulihan Basis Data - File Log Dihapus (Bagian 3)

Anda bertanya tentang perbedaan antara:

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

Masalahnya adalah Anda dapat menjalankan keduanya untuk membangun kembali file log, tetapi dengan CHECKDBAnda membangun kembali log dan memeriksa database untuk kesalahan integritas juga.

Yang kedua (ubah database) tidak akan berfungsi jika ada transaksi aktif (tidak ditulis ke disk) ketika file log hilang. Saat start-up atau melampirkan, SQL Server akan ingin melakukan pemulihan (rollback dan rollforward) dari file log yang tidak ada. Itu terjadi ketika disk crash atau shutdown server yang tidak terduga terjadi dan database tidak shutdown bersih. Saya kira itu bukan kasus Anda dan semua beres untuk Anda.

1. DBCC CHECKDB (DBNAME, REPAIR_ALLOW_DATA_LOSS)berjalan di database dalam status darurat memeriksa database untuk kesalahan inkonsistensi, coba dulu menggunakan file log untuk memulihkan dari setiap inkonsistensi. Jika ini tidak ada, log transaksi dibangun kembali.

2. ALTER DATABASE REBUILD LOG ON...adalah prosedur tidak berdokumen dan memerlukan prosedur berikutnya DBCC CHECKDBuntuk memperbaiki kesalahan.

Ya, itu adalah dua pernyataan yang berbeda, masing-masing melakukan hal yang sangat berbeda.

Bergantung pada kondisi basis data saat file dihapus, Anda mungkin bisa bangun dan berjalan dengan melampirkan database dan membangun kembali log dengan menggunakan:

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

Lihat sp_attach_single_file_db (Transact-SQL) dalam dokumentasi produk.

Lihat juga posting blog ini oleh Paul S. Randal :

Perbaikan mode DARURAT: pilihan terakhir