Mengembalikan cadangan diferensial membuat file log DEFUNCT?


11

Ini masalah saya. Saya mencoba untuk memindahkan database ke server baru melalui pemulihan penuh, lalu cutover dengan cadangan / pemulihan diferensial cepat. Saya bisa melakukan pemulihan penuh tanpa masalah, tetapi ketika mengembalikan cadangan diferensial, saya mendapatkan peringatan berikut:

Msg 3127, Level 16, Negara 1, Baris 1 File 'Database_Log2' dari database yang dipulihkan 'DatabaseName' dibiarkan dalam keadaan mati karena database menggunakan model pemulihan sederhana dan file ditandai untuk akses baca-tulis. Oleh karena itu, hanya file baca-saja yang dapat dipulihkan oleh pemulihan sedikit demi sedikit.

Basis data dipulihkan dan dianggap online, tetapi operasi pencadangan gagal karena file DEFUNCT ini dengan kesalahan berikut:

Msg 3636, Level 16, State 2, Line 1 Terjadi kesalahan saat memproses metadata 'BackupMetadata' untuk database id 10 file id 6. Msg 3046, Level 16, State 2, Line 1 Metadata tidak konsisten telah ditemukan. Satu-satunya operasi pencadangan yang mungkin adalah pencadangan log-ekor menggunakan opsi WITH CONTINUE_AFTER_ERROR atau NO_TRUNCATE. Msg 3013, Level 16, Status 1, Baris 1 DATABASE CADANGAN diakhiri secara tidak normal.

Jika saya melakukan RESTORE FILELISTONLY pada penuh dan diferensial keduanya memberi saya output yang sama, yang cocok dengan apa yang saya lihat dari sys.database_files pada sumber database. Server adalah SQL2012 SP1, pada edisi Pengembang.

Saya dapat melakukan pencadangan penuh, dan segera setelah itu melakukan diferensial, dan mengembalikan file-file ini ke database yang berbeda pada server yang sama dan melihat masalah yang sama persis, jadi ada sesuatu dengan bagaimana diferensial dibuat yang menyebabkan ini. Jika saya mengembalikan cadangan penuh DENGAN PEMULIHAN tidak ada masalah. Saya tidak tahu apakah file ini dulu ada di database ini, tetapi sangat mungkin file ini dulu ada dan sudah dihapus sejak lama. Jika saya query sys.database_files pada database yang dipulihkan, file DEFUNCT memiliki nilai untuk drop_lsn, yang sepertinya mengkonfirmasi ini. Saat ini di sumber basis data hanya ada satu filegroup (PRIMARY), 4 file data dan satu file log.

Ada ide?


Bisakah Anda menunjukkan kepada kami pernyataan yang Anda gunakan untuk melakukan pencadangan dan pengembalian?
Jon Seigel

Tidak ada yang luar biasa. RESTORE DATABASE DatabaseName FROM DISK = 'D: \ Full.bak' DENGAN REPLACE, NORECOVERY Kemudian RESTORE DATABASE DatabaseName FROM DISK = 'D: \ Diff.bak' DENGAN PEMULIHAN
FilamentUnities

Jawaban:


5

Berikut adalah langkah-langkah untuk mereproduksi ini, diuji pada SQL 2012 SP1 Edisi Pengembang. Ini tidak terjadi pada SQL 2008. Untuk meringkas, database dibuat di SQL 2012 saat model database dalam pemulihan SEDERHANA, yang memiliki cadangan penuh diambil saat file log tambahan ada, tidak dapat membuat cadangan diferensial yang dapat digunakan jika file log tambahan tersebut pernah dihapus.

ALTER DATABASE [model] SET RECOVERY SIMPLE
GO
CREATE DATABASE [DefunctTest]
GO
ALTER DATABASE [DefunctTest] ADD LOG FILE ( NAME = N'DefunctTest_log2', FILENAME = N'D:\DefunctTest_log2.ldf' , SIZE = 25600KB , FILEGROWTH = 10%)
GO
BACKUP DATABASE [DefunctTest] TO DISK = 'D:\DefunctTestPostLogFile.bak' WITH INIT
GO
ALTER DATABASE [DefunctTest]  REMOVE FILE [DefunctTest_log2]
GO

BACKUP DATABASE [DefunctTest] TO DISK = 'D:\DefunctTestFull.bak' WITH INIT
GO
BACKUP DATABASE [DefunctTest] TO DISK = 'D:\DefunctTestDiff.bak' WITH DIFFERENTIAL, INIT
GO
--Show that the backups only have the one log file.
RESTORE FILELISTONLY FROM DISK = 'D:\DefunctTestFull.bak'
RESTORE FILELISTONLY FROM DISK = 'D:\DefunctTestDiff.bak'
GO
RESTORE DATABASE [DefunctTest2] FROM DISK = 'D:\DefunctTestFull.bak' WITH 
MOVE 'DefunctTest' TO 'D:\DefunctTest2.mdf',
MOVE 'DefunctTest_log' TO 'D:\DefunctTest2_log.ldf', REPLACE, NORECOVERY
GO
--This restore will have the error.
RESTORE DATABASE [DefunctTest2] FROM DISK = 'D:\DefunctTestDiff.bak' WITH RECOVERY
GO

USE [DefunctTest2]
SELECT * FROM sys.database_files
GO

Saya mengirimkan item Connect untuk bug ini di sini . Satu-satunya cara saya dapat menghapus file yang mati ini adalah untuk melepaskan database, dan melampirkan kembali dengan ATTACH_REBUILD_LOG.

UPDATE: Bug yang membuat skenario ini dalam skrip repro saya tampaknya telah diperbaiki oleh KB ini: https://support.microsoft.com/en-us/kb/2830400 . Dari komentar itu muncul perbaikan tambahan tersedia untuk SQL2012 / 2014, skenario tampak sangat mirip: https://support.microsoft.com/en-us/kb/3009576


Saya akan memasukkan skrip Anda dalam komentar terhubung untuk membantu orang mereproduksi.
Kenneth Fisher

1
Saya tidak mendapatkan kesalahan menjalankan skrip Anda pada SQL Server 2012 Enterprise Edition, 11.0.3412 (CU9 untuk SP1)

Skrip repro ada di item Sambungkan, jika Anda mengklik tombol Detail.
FilamentUnities

1
Shawn, melihat melalui perbaikan di CU, saya pikir yang ini mungkin memperbaiki perilaku ini: support.microsoft.com/kb/2830400
FilamentUnities

2
Saya memiliki pertempuran dengan ini minggu lalu dan utas ini membantu saya menyelesaikannya jadi terima kasih. Sepertinya perbaikannya ada di SQL 2012 SP2 CU3: support.microsoft.com/en-us/kb/3009576
Richard
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.