Korriger: Feil 9002 og feil 3052 når du prøver å legge til eller ta sikkerhetskopi av loggfilen i SQL Server 2012 eller SQL Server-2014

Symptomer

Anta at du bruker AlwaysOn tilgjengelighet gruppe i en Microsoft SQL Server 2012 eller 2014 for SQL Server-database, og en stor aktive transaksjonen, som finnes, og krever ekstra loggplassen. Når loggfilen ikke kan bli for én av følgende årsaker, mislykkes transaksjonen.

• Mangel på ekstra plass

• Loggfilen er konfigurert til ikke å vokse

• Loggfilen har nådd sin maksimale størrelse konfigurerte

I tillegg får du følgende feilmelding:

Når du kjører en sikkerhetskopiering, får du en annen 9002-feilmelding:

Etter at du har en annen sikkerhetskopiering får du deretter et annet 9002 etterfulgt av en 5901-feilmelding:

Når det tas deretter sikkerhetskopier av etterfølgende kontrollpunkt eller loggen under tilbakeføring av transaksjonen, kan du få følgende feilmelding:

Når du mottar disse meldingene, du ikke lenger kunne sende noen nye transaksjoner i databasen, og du kan ikke vokse loggfilen eller legge til en annen fil.

Oppløsning

Problemet ble først løst i den følgende kumulative oppdateringen av SQL Server:

• Samleoppdatering 3 for SQL Server 2014 SP1

• Kumulativ oppdatering 10 for SQLServer 2014

• Kumulativ oppdatering 8 for SQL Server 2012 SP2

Løsningen

Du kan bruke følgende løsning å avkorte loggene og gjenopptar arbeidet.

1. Kontroller hver sekundære replika for å kontrollere sekundære replika last_hardened_lsn (se sys.dm_hadr_database_replica_states) samsvarer med den primære replika- last_hardened_lsn. Du kan gjøre dette ved å kjøre følgende spørring som er koblet til den primære replika-forekomsten

   SELECT ags.name as AGGroupName,    ar.replica_server_name as InstanceName,
       hars.role_desc,
       db_name(drs.database_id)as DBName,
       drs.last_hardened_lsn, drs.log_send_queue_size,
       drs.synchronization_state_desc as SyncState,
       ar.availability_mode_desc as SyncMode,
       CASE drs.is_local WHEN 1 THEN drs.database_id ELSE NULL END as database_id
       FROM sys.dm_hadr_database_replica_states drs
       LEFT JOIN sys.availability_replicas ar ON drs.replica_id = ar.replica_id
       LEFT JOIN sys.availability_groups ags  ON ar.group_id = ags.group_id
       LEFT JOIN sys.dm_hadr_availability_replica_states hars
           ON ar.group_id = hars.group_id and ar.replica_id = hars.replica_id
         WHERE db_name(drs.database_id) = '<database name>'
   

2. På den primære replikaen

   • Fjerne databasen fra gruppen tilgjengelighet.

   • Legge til databasen på nytt i gruppen tilgjengelighet.

3. På hver sekundære replika

   • Legge til databasen på nytt i gruppen tilgjengelighet.

Ved å fjerne databasen fra gruppen tilgjengelighet, vil det umiddelbart avkorte loggene og frigjøre loggplass.

Hvis last_hardened_lsn på hver sekundære replika er identisk med den primære replikaen, og ingen Gjenopprettingsmodellen, tas tiden fjerne databasen fra gruppen tilgjengelighet og legge til databasen på hvert sekundære, vil sekundær replikaen lykkes legges til på nytt uten feil, eller at du trenger å gjenopprette Gjenopprettingsmodellen på sekundært.

Hvis en sekundær replika som ikke er oppdatert med den primære replikaen, og du må fjerne databasen fra gruppen tilgjengelighet før sekundært kan fange, må kanskje sekundære replikaen har Gjenopprettingsmodellen for å fange den før du legger den på nytt i tilgjengelighet-gruppen, eller slette databasen på den sekundære replika og så på nytt med en fullstendig og databasesikkerhetskopi loggen for transaksjonen.

Status

Microsoft har bekreftet at dette er et problem i Microsoft-produktene som er oppført i delen "Gjelder for".