Dela via

Återställning av en SQL Server-databas med hjälp av ett VDI-program med flera striping kan misslyckas med fel 3456

  • Artikel

Den här artikeln hjälper dig att lösa ett problem som uppstår när du använder VDI-baserade program (Virtual Device Interface) för att återställa dina SQL Server-databaser.

Symptom

När du återställer en fullständig säkerhetskopia av ett VDI(Multi-Striped Virtual Device Interface) på SQL Server 2019 eller senare kan du få felet MSSQLSERVER_3456:

Msg 3456, Level 16, State 1, Line <LineNumber>
Could not redo log record (120600:18965748:1), for transaction ID (0:1527178398), on page (14:1987189), allocation unit 72057761533001728, database 'DB1_STRIPE' (database ID 8).
Page: LSN = (120598:23255372:8), allocation unit = 72057761317781504, type = 1. Log: OpCode = 6, context 2, PrevPageLSN: (120600:18965371:85).

Orsak

När SQL Server säkerhetskopieras till VDI skickar den data till VDI via en buffert. VDI hanterar sedan formateringen av hur säkerhetskopieringen ska lagras. I många fall kan VDI-klienten dock bara förvänta sig en enda kopia av varje datasida.

När du streckar en säkerhetskopia till VDI utgör flera säkerhetskopieringsenheter tillsammans innehållet i en fullständig säkerhetskopia. Data skrivs asynkront och datakopieringsordningen hanteras av VDI-klientens logik. Eftersom datakopieringsfasen är asynkron kan data skrivas i fel ordning. I ett fullständigt säkerhetskopieringsscenario före SQL Server 2019 finns det dock bara en kopia per datasida. Så när VDI-klienten skickar data till bufferten som SQL Server läser från för en återställning, skulle SQL Server fortfarande kunna veta exakt var och hur man återställer varje datasida. Med introduktionen av fördröjd logg fästning i SQL Server 2019 kan flera kopior av datasidan hittas i säkerhetskopieringsfilerna. Det finns flera kopior på grund av att en mini differentiell säkerhetskopia sker i den fullständiga säkerhetskopian (mer information finns i avsnittet Mer information ). VDI-klienten förväntar sig antingen inte flera kopior av samma datasida eller skickar tillbaka datasidorna till SQL Server i fel ordning. Det här beteendet orsakar återställningsfelet. Felet 3456 Could not redo log record anger att SQL Server försöker tillämpa en loggpost som förväntar sig den senaste versionen av datasidan, men den hittar en äldre version.

Åtgärd

  1. Beroende på konfigurationen måste du aktivera en eller flera spårningsflaggor som startparametrar för din SQL Server-instans:

    • Om du gör fullständiga säkerhetskopieringar när instansen fungerar som en primär replik eller en instans utan tillgänglighetsgrupper aktiverar du spårningsflagga 3471 för att inaktivera funktionen för fördröjd logg pinning för fullständiga säkerhetskopior.

    • Om du gör differentiella säkerhetskopior när instansen fungerar som en primär replik eller en instans utan tillgänglighetsgrupper aktiverar du spårningsflagga 3475 för att inaktivera funktionen för fördröjd logginloggning för differentiella säkerhetskopior.

    • Om du tar fullständiga säkerhetskopior med COPY_ONLY när instansen fungerar som en sekundär replik aktiverar du spårningsflagga 3472 för att inaktivera funktionen för fördröjd logginloggning för differentiella säkerhetskopior.

  2. Starta om SQL Server.

  3. Ta dina fullständiga eller differentiella säkerhetskopior igen.

Kommentar

Du kan också tillfälligt aktivera dessa spårningsflaggor med hjälp av KOMMANDOT DBCC TRACEON .

DBCC TRACEON(3471,3472,3475,-1)

Det här kommandot kan användas för att åtgärda problemet om du inte kan starta om SQL Server-instansen omedelbart.

Viktigt!

På grund av det här problemet kanske befintliga säkerhetskopior inte kan återställas om följande villkor är uppfyllda:

  • Säkerhetskopieringen görs med funktionen för fördröjningsloggsstiftning aktiverad.
  • Säkerhetskopieringsverktyget använder VDI.
  • Säkerhetskopieringen görs med multi-striping (säkerhetskopiering till flera filer).

Vi rekommenderar att du återställer dina befintliga säkerhetskopior på en testserver för att kontrollera om de kan återställas.

Mer information

SQL Server 2019 introducerar en funktion som kallas fördröjd logg pinning. Före introduktionen av den här funktionen, under en fullständig databassäkerhetskopia, blockerar SQL Server alla transaktioner från att hända (fäster loggen), kopierar data och loggen och tar sedan bort stiftet direkt i början. Med funktionen som finns fördröjer SQL Server transaktioner från att ske (fäster loggen) mot slutet av säkerhetskopieringens varaktighet, i stället för direkt i början. Den här funktionen är utformad för att undvika ett fullständigt problem med transaktionsloggen (MSSQLSERVER_9002 fel) under en fullständig säkerhetskopia som tar lång tid att slutföra. Eftersom loggens fästning är fördröjd kan transaktioner fortfarande tillämpas på databasens datasidor medan säkerhetskopieringen pågår. SQL Server har en bitmapp för att identifiera de sidor som har ändrats sedan starttiden för den pågående fullständiga säkerhetskopieringen, så att det kan ta en mini differentiell säkerhetskopia av dem. På så sätt får den en uppdaterad kopia av varje datasida som har ändrats när den säkerhetskopierar hela databasen. Detta orsakar en extra kopia av vissa datasidor. Dessutom skapas det här extra avsnittet av den fullständiga säkerhetskopian.