KB3095156 – LØSNING: Feil 9002 og feil 3052 når du prøver å legge til eller sikkerhetskopiere loggfil i SQL Server 2012 eller SQL Server 2014

Symptomer

La oss si at du bruker AlwaysOn-tilgjengelighetsgruppen i en Microsoft SQL Server 2012- eller SQL Server 2014-database, og at det finnes en stor, åpen, aktiv transaksjon som krever mer loggplass. Når loggfilen ikke kan utvides av en av følgende årsaker, mislykkes transaksjonen.

• Mangel på ekstra filplass
• Loggfilen er konfigurert til ikke å vokse
• Loggfilen har nådd den konfigurerte maksimumsstørrelsen

I tillegg får du følgende feilmelding:

Når du har kjørt en sikkerhetskopiering av loggen, får du en ny 9002-feilmelding:

Etter nok en sikkerhetskopiering av loggen, får du en ny 9002-feilmelding etterfulgt av en 5901-feilmelding:

      

Når det påfølgende kontrollpunktet eller sikkerhetskopieringen av loggen deretter tas under tilbakerullingen av transaksjonen, kan du få følgende feilmelding:

Når du mottar disse meldingene, kan du ikke lenger sende inn nye transaksjoner til databasen, og du kan ikke utvide loggfilen eller legge til en ny loggfil.

Oppløsning

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

• Kumulativ oppdatering 3 for SQL Server 2014 SP1
• Kumulativ oppdatering 10 for SQL Server 2014
• Kumulativ oppdatering 8 for SQL Server 2012 SP2

Anbefaling: Installer den nyeste kumulative oppdateringen for SQL Server

Hver nye kumulative oppdatering for SQL Server inneholder alle hurtigreparasjoner og alle sikkerhetsrettinger som fulgte med den forrige kumulative oppdateringen. Vi anbefaler at du laster ned og installerer de nyeste kumulative oppdateringene for SQL Server:

• Den nyeste kumulative oppdateringen for SQL Server 2014 SP1
• Den nyeste kumulative oppdateringen for SQL Server 2014
• Den nyeste kumulative oppdateringen for SQL Server 2012 SP2

      

Midlertidig løsning

Du kan bruke følgende løsning til å avkorte loggene og gjenoppta aktiviteten.

1. Kontroller hver sekundære replika for å bekrefte at den sekundære replikaen last_hardened_lsn (se sys.dm_hadr_database_replica_states) samsvarer med den primære replikaen last_hardened_lsn. Du kan gjøre dette ved å kjøre følgende spørring som er knyttet til den primære replikaforekomsten

   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

   • Fjern databasen fra tilgjengelighetsgruppen.
   • Legg til databasen i tilgjengelighetsgruppen på nytt.

3. På hver sekundære replika

   • Legg til databasen i tilgjengelighetsgruppen på nytt.

Ved å fjerne databasen fra tilgjengelighetsgruppen vil den umiddelbart avkorte loggene og frigjøre loggplass.

Hvis last_hardened_lsn på hver sekundære replika er identisk med den primære replikaen, og det ikke tas noen sikkerhetskopier av loggen i løpet av tiden det tar å fjerne databasen fra tilgjengelighetsgruppen og legge til databasen på nytt på hver sekundære, vil den sekundære replikaen bli lagt til på nytt uten feil eller å måtte gjenopprette sikkerhetskopier av loggen på den sekundære.

Hvis en sekundær replika ikke er oppdatert hos den primære replikaen, og du må fjerne databasen fra tilgjengelighetsgruppen før den sekundære kan ta det igjen, må den sekundære replikaen kanskje ha sikkerhetskopier av loggen gjenopprettet for å ta den igjen før den legges til i tilgjengelighetsgruppen på nytt, eller slippe databasen på den sekundære replikaen og legge den til på nytt med en fullstendig sikkerhetskopi av databasen og transaksjonsloggen.

Status

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