Geri yüklenemedi (hata 3456)

Anlaması kolay olmayan bir durum var ve başkalarının önerileri olup olmadığını bu forumda soracağımı düşündüm.

SQL Server 2008 R2 Standard SP3'ü Windows Server 2008R2 Enterprise üzerinde çalıştırıyorum.

Bir veritabanının bakım ihtiyacı vardı ve aslında başka bir sunucuya geri yüklemem gerekti. COPY_ONLY artı 4 tlog yedek bir dizi ile yapılan tam bir db yedekleme var.

1. başlamadan önce tlogbackup1 oluşturun
2. değiştirmek FULLiçin BULK_LOGGEDkurtarma modeli
3. yeni dosya grubu ekle
4. newfilegroup'a dosya ekle
5. newfilegroup'u varsayılan olarak ayarla
6. tabloya seç (newfilegroup üzerinde)
7. orijinal tablo bırak
8. orijinal dosyayı sil
9. orijinal dosya grubunu sil
10. yeni tablonun adını orijinal tabloyla eşleşecek şekilde değiştir
11. newfilegroup dosya adını orijinal dosya grubuyla eşleşecek şekilde değiştirme
12. katalogdaki dosya adını orijinal dosya adıyla eşleşecek şekilde değiştirme
13. OS düzeyinde dosya adını orijinal dosya adıyla eşleşecek şekilde değiştirme
14. varsayılan dosya grubunu orijinal olarak ayarla
15. db'yi çevrimiçi getir
16. değiştirmek BULK_LOGGEDiçin FULLkurtarma modeli
17. Tüm adımlar tamamlandıktan sonra tlogbackup2 oluşturun

Geri yükleme sunucusundaki sürücü harfi değişiklikleri nedeniyle tüm yedeklerin geri yüklenmesi WITH MOVE kullanmalıdır.

Kurtarma adımları:

RESTORE database SomeDB FROM DISK = 'D:\REPRO\SomeDB.bak'   
WITH 
MOVE 'SystemData' TO 'D:\SQLDATA\SomeDB.mdf'
,MOVE 'SystemDataPDS' TO 'D:\SqlData\SomeDB.ndf'
,MOVE 'SystemData_log' TO 'D:\SQLLogs\SomeDB.LDF'
,NORECOVERY
,stats = 1

RESTORE LOG SomeDB FROM DISK = 'D:\REPRO\tlogbackup1.trn'   
WITH 
MOVE 'SystemData' TO 'D:\SQLDATA\SomeDB.mdf'
,MOVE 'SystemDataPDS' TO 'D:\SqlData\SomeDB.ndf'
,MOVE 'SystemData_log' TO 'D:\SQLLogs\SomeDB.LDF'
,NORECOVERY
,stats = 1

RESTORE LOG SomeDB FROM DISK = 'D:\REPRO\tlogbackup2.trn'   
WITH 
MOVE 'SystemData' TO 'D:\SQLDATA\SomeDB.mdf'
,MOVE 'SystemDataPDS' TO 'D:\SqlData\SomeDB.ndf'
,MOVE 'SystemData_log' TO 'D:\SQLLogs\SomeDB.LDF'
,NORECOVERY
,stats = 1

Son tlog geri yüklemesi% 100'e ulaşır ve ardından 3456 hatasıyla başarısız olur:

'SomeDB' veritabanı için 368 sayfa işlendi, dosya 1'deki 'SystemData' dosyası.

'SomeDB' veritabanı için 7656520 sayfa işlendi, dosya 1'deki 'SystemDataPDS' dosyası.

'SomeDB' veritabanı için 172430 sayfa işlendi, dosya 1'de 'SystemData_log' dosyası.

Msg 3456, Seviye 16, Durum 1, Hat 1
Günlük kaydı (210388: 123648: 232), işlem kimliği için (0: 1016710921), sayfa (4: 8088), veritabanı 'SomeDB' (veritabanı kimliği 6) . Sayfa: LSN = (0: 0: 1), = 11 yazın. Günlük: OpCode = 4, bağlam 11, PrevPageLSN: (210388: 122007: 1). Veritabanının bir yedekten geri yükleyin veya veritabanını onarın. Msg 3013, Seviye 16, Durum 1, Satır 1 RESTORE LOG anormal olarak sona eriyor.

Sadece tam db yedekleme tamam olduğunu doğrulamak için, o geri yüklendi CHECKDBve hiçbir hata yoktu.

Tüm geri bildirimler memnuniyetle karşılandı.

Şimdiden teşekkürler,

Ned Otter

3456 hatasının neden atılacağını anlamak için, biraz geri adım atmalı ve SQL Server'ın bu kurtarma köşesini nasıl ele aldığını anlamalıyız.

SQL Server bir işlemi yeniden yaparken ve bu yineleme bir sayfa değişikliğiyse, hızlı bir kontrol yapar. Sayfa başlığında, sonuç olarak PageLSN, o sayfayı değiştiren ve sayfa tarafından kaydedilen son LSN'nin bir göstergesi olan a olacaktır . Bu şekilde düşünün, sayfa, üzerinde değişiklik yapan son LSN'yi takip eder. Bu PageLSN.

Her günlüğe kaydedilen sayfa değiştirme işlemi olduğunda, bu günlük kaydı birkaç LSN içerir. Yani, günlük kaydının LSN'si (düşünün ... Geçerli LSN ) ve daha sonra Önceki Sayfa LSN'si ( PrevPageLSNileriye doğru) denir . Dolayısıyla, bir sayfayı değiştirdiğimizde, günlük kaydına yerleştirilen veri parçalarından biri, sayfayı değiştirmeden önce sayfanın en son LSN olduğunu gösterir .

Şöyle düşünün ... Arabanızın üzerinde çalışılması gerekiyor. Mekanik John arabanızda çalışıyor ve motor bölmesinde küçük bir etiketi var ve Mekanik John "John bu arabada en son çalıştı" yazıyor. Ardından bir dahaki sefere arabanızı başka bir dükkana götürdüğünüzde, Mekanik Mark motor bölmesine bakar ve Mekanik John'un en son bu araba üzerinde çalıştığını görür. Veri sayfasında bu bilgileri yazar. SQL Server ile aynı fikir.

Bu yüzden sıralı sayfa değişiklikler aşağıda bu resmin bir göz atın, biraz kafa karıştırıcı olabilir ve nasıl olabilir PageLSNve PrevPageLSNilişki:

Bir sayfadaki bir işlemi yeniden yapmanız gerektiğinde (geri yükleme, kurtarma, HA, vb.) Tüm bunlar devreye girdiğinden geri dönelim . SQL Server bir sayfa işlemini yeniden yapmanız gerektiğinde PageLSN, sayfada PrevPageLSNgünlük kaydının içerdiği ile eşleşip eşleşmediğini görmek için bir sağlık kontrolü yapar . Bu eşit değilse, 3456 hatasının atıldığını göreceksiniz.

Mu PageLSN eşit PrevPageLSN ? Hayır??? Dur ve yükseltme hatası 3456 ...

Aşağıdakileri içeren hata mesajınızı analiz edelim:

İşlem kimliği (0: 1016710921), sayfa (4: 8088), 'SomeDB' veritabanı (veritabanı kimliği 6) için günlük kaydı (210388: 123648: 232) yeniden yapılamadı. Sayfa: LSN = (0: 0: 1) , = 11 yazın. Günlük: OpCode = 4, bağlam 11, PrevPageLSN: (210388: 122007: 1) . Veritabanının bir yedekten geri yükleyin veya veritabanını onarın. Msg 3013, Seviye 16, Durum 1, Satır 1 RESTORE LOG anormal olarak sona eriyor.

Hataya neden olan eşitsizliğe sahip iki veri parçasını kalınlaştırdım. Sen bizim görebiliriz PageLSNolan 1: 0: 0 (bu sayfanın başlığında bulundu) ve bizim PrevPageLSNolan 210.388: 1: 122.007 (bu yeniden yapılması için uğraş günlük kaydında veri bulunmuştur). Bunlar açıkça eşit değildir, dolayısıyla err3456.

Yani öğrenmek için neden bu olayın, bir eşitsizlik burada var olmasının nedenini anlamak olacaktır. Gerçekten sayfa 4: 8088'in yaşam döngüsünü izlememiz ve bağlantıyı kesmenin nerede olduğunu görmemiz gerekiyor. Ne yazık ki daha fazla bilgi veya uygulamalı sorun giderme olmadan, bu kurtarma işleminin arka planını ve hatanın nedenini size verebileceğim başka pek bir şey yok.