Delen via

Het herstellen van een SQL Server-database met een VDI-toepassing met meerdere striping kan mislukken met fout 3456

  • Artikel

Dit artikel helpt u bij het oplossen van een probleem dat optreedt wanneer u VDI-toepassingen (Virtual Device Interface) gebruikt om uw SQL Server-databases te herstellen.

Symptomen

Wanneer u een volledige back-up van een VDI (Multi-Striped Virtual Device Interface) herstelt op SQL Server 2019 of hoger, krijgt u mogelijk de volgende fout 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).

Oorzaak

Wanneer SQL Server een back-up maakt van VDI, worden gegevens via een buffer doorgegeven aan de VDI. De VDI verwerkt vervolgens de opmaak van het opslaan van die back-up. In veel gevallen kan de VDI-client echter slechts één kopie van elke gegevenspagina verwachten.

Wanneer u een back-up naar VDI stript, vormen meerdere back-upapparaten samen de inhoud van een volledige back-up. De gegevens worden asynchroon geschreven en de volgorde van het kopiëren van gegevens wordt verwerkt door de logica van de VDI-client. Omdat de fase voor het kopiëren van gegevens asynchroon is, kunnen de gegevens uit de volgorde worden geschreven. In een volledig back-upscenario vóór SQL Server 2019 is er echter slechts één kopie per gegevenspagina. Dus wanneer de VDI-client gegevens naar de buffer verzendt waaruit SQL Server leest voor een herstelbewerking, kan SQL Server nog steeds precies weten waar en hoe elke gegevenspagina moet worden hersteld. Met de introductie van vertraagde logboekpinning in SQL Server 2019 zijn er mogelijk meerdere kopieën van de gegevenspagina te vinden in de back-upbestanden. Er bestaan meerdere kopieën als gevolg van een mini differentiële back-up in de volledige back-up (zie de sectie Meer informatie voor meer informatie ). De VDI-client verwacht niet meerdere kopieën van dezelfde gegevenspagina of geeft de gegevenspagina's weer door aan SQL Server in de verkeerde volgorde. Dit gedrag veroorzaakt de herstelfout. De fout 3456 Could not redo log record geeft aan dat SQL Server probeert een logboekrecord toe te passen waarvoor de meest recente versie van de gegevenspagina wordt verwacht, maar een oudere versie wordt gevonden.

Oplossing

  1. Afhankelijk van uw configuratie moet u een of meer traceringsvlagmen inschakelen als opstartparameters voor uw SQL Server-exemplaar:

    • Als u volledige back-ups maakt wanneer het exemplaar fungeert als een primaire replica of een exemplaar zonder beschikbaarheidsgroepen, schakelt u traceringsvlag 3471 in om de functie voor het vastmaken van logboeken uit te schakelen voor volledige back-ups.

    • Als u differentiële back-ups maakt wanneer het exemplaar fungeert als een primaire replica of een exemplaar zonder beschikbaarheidsgroepen, schakelt u traceringsvlag 3475 in om de vertraagde functie voor het vastmaken van logboeken voor differentiële back-ups uit te schakelen.

    • Als u volledige back-ups maakt met COPY_ONLY wanneer het exemplaar als secundaire replica fungeert, schakelt u traceringsvlag 3472 in om de functie voor vertraagde logboekpinning voor differentiële back-ups uit te schakelen.

  2. Start SQL Server opnieuw op.

  3. Neem uw volledige of differentiële back-ups opnieuw.

Notitie

U kunt deze traceringsvlagmen ook tijdelijk inschakelen met behulp van de DBCC TRACEON-opdracht .

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

Deze opdracht kan worden gebruikt om het probleem te verhelpen als u uw SQL Server-exemplaar niet onmiddellijk opnieuw kunt opstarten.

Belangrijk

Vanwege dit probleem zijn bestaande back-ups mogelijk niet herstelbaar als aan de volgende voorwaarden wordt voldaan:

  • De back-up wordt gemaakt met de functie voor het vastmaken van logboeken ingeschakeld.
  • Het back-upprogramma maakt gebruik van VDI.
  • De back-up wordt uitgevoerd met behulp van multi-striping (back-ups maken van meerdere bestanden).

We raden u aan om uw bestaande back-ups op een testserver te herstellen om te controleren of ze kunnen worden hersteld.

Meer informatie

SQL Server 2019 introduceert een functie met de naam vertraagde logboekpinning. Vóór de introductie van deze functie blokkeert SQL Server tijdens een volledige back-up van de database alle transacties (maakt het logboek vast), kopieert de gegevens en het logboek en verwijdert u vervolgens de pincode rechts aan het begin. Als de functie aanwezig is, vertraagt SQL Server transacties die plaatsvinden (maakt het logboek vast) aan het einde van de back-upduur, in plaats van direct aan het begin. Deze functie is ontworpen om een probleem met een volledig transactielogboek (MSSQLSERVER_9002 fout) te voorkomen tijdens een volledige back-up die lang duurt om te voltooien. Omdat het vastmaken van logboeken is vertraagd, kunnen transacties nog steeds worden toegepast op de gegevenspagina's van de database terwijl de back-up wordt uitgevoerd. SQL Server onderhoudt een bitmap om de pagina's te identificeren die zijn gewijzigd sinds de begintijd van de doorlopende volledige back-up, zodat er een mini differentiële back-up van deze pagina's kan worden gemaakt. Op deze manier krijgt het een bijgewerkte kopie van elke gegevenspagina die is gewijzigd terwijl er een back-up van de hele database wordt gemaakt. Dit veroorzaakt een extra kopie van sommige gegevenspagina's. Daarnaast wordt deze extra sectie van de volledige back-up gemaakt.