Symptomen
U wordt aangeraden om de AlwaysOn-beschikbaarheidsgroep te gebruiken in een Microsoft SQL Server-2012-of SQL Server 2014-database en er is een grote, actieve transactie met logboekruimte vereist. Als het logboekbestand niet kan worden opgegroeid om een van de volgende redenen, mislukt de transactie.
-
Onvoldoende extra bestandsruimte
-
Het logboekbestand is geconfigureerd om te groeien
-
Het logboekbestand heeft de geconfigureerde maximumgrootte bereikt
Bovendien wordt het volgende foutbericht weergegeven:
Fout: 9002, Ernst: 17, provincie: 9. het transactielogboek voor database ' <databasenaam> ' is vol vanwege ' LOG_BACKUP '.
Als u een back-up van het logboek hebt uitgevoerd, wordt een ander foutbericht van 9002 weergegeven:
Fout: 9002, Ernst: 17, provincie: 9. het transactielogboek voor database ' <databasenaam> ' is vol vanwege ' ACTIVE_TRANSACTION '.
Na een andere back-up van het logboek ontvangt u vervolgens een ander foutbericht van 9002, gevolgd door een 5901-foutbericht:
Fout: 9002, Ernst: 17, provincie: 9. het transactielogboek voor database ' <databasenaam> ' is vol vanwege ' AVAILABILITY_REPLICA '.
Kon geen controlepuntrecord schrijven in de database <databasenaam> omdat het logboek onvoldoende ruimte is. Neem contact op met de databasebeheerder om het logboek af te kappen of meer ruimte toe te wijzen aan de logboekbestanden in de database. Fout: 5901, Ernst: 16, status: 1. een of meer herstel eenheden die deel uitmaken van de database ' <databasenaam> ' kon geen controlepunt genereren. Dit wordt gewoonlijk veroorzaakt door onvoldoende systeembronnen, zoals de schijf of het geheugen, of in sommige gevallen als gevolg van de database beschadigd. Bekijk eerdere vermeldingen in het foutenlogboek voor uitgebreide informatie over deze fout.
Wanneer het volgende controlepunt of logboekback-up wordt gemaakt tijdens de terugdraaiactie van de transactie, wordt mogelijk het volgende foutbericht weergegeven:
Bericht 3052, niveau 16, status 1, 4BACKUP logboek kon geen updates voor de <database> worden vastgelegd. Verdere back-up van Logboeken is nodig om het back-uppunt te verschuiven van ' <LSN id 1> ' naar ' <lsn id 2> ' nadat de logboekruimte beschikbaar is voor logboekregistratie.
Wanneer deze berichten worden weergegeven, kunt u niet langer nieuwe transacties indienen in de database en kunt u het logboekbestand niet vergroten of een ander logboekbestand toevoegen.
Oplossing
Het probleem is voor het eerst opgelost in de volgende cumulatieve update van SQL Server:
Elke nieuwe cumulatieve update voor SQL Server bevat alle hotfixes en alle beveiligingsoplossingen die zijn opgenomen in de vorige cumulatieve update. U wordt aangeraden de nieuwste cumulatieve updates voor SQL Server te downloaden en te installeren:
Tijdelijke oplossing
U kunt de volgende tijdelijke oplossing gebruiken om de logboeken te afkappen en de activiteit te hervatten.
-
Controleer elke secundaire replica om de secundaire replica last_hardened_lsn (Zie sys.dm_hadr_database_replica_states) komt overeen met de primaire replica last_hardened_lsn. U kunt dit doen door de volgende query uit te voeren die is verbonden met het primaire exemplaar van de replica
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>'
-
Op de primaire replica
-
Verwijder de database uit de groep met beschikbaarheid.
-
Voeg de database opnieuw toe aan de groep met beschikbaarheid.
-
-
Voor elke secundaire replica
-
Voeg de database opnieuw toe aan de groep met beschikbaarheid.
-
Wanneer u de database uit de beschikbaarheidsgroep verwijdert, worden de logboeken direct afgebroken en wordt de logboekruimte vrijgemaakt. Als de last_hardened_lsn op elke secundaire replica identiek is met de primaire replica en er geen logboekback-ups worden gemaakt tijdens het verwijderen van de database uit de beschikbaarheidsgroep en de database opnieuw toe te voegen op de secundaire versie, wordt de secundaire replica zonder fouten opnieuw toegevoegd of moet u logboekback-ups terugzetten op de secundaire replica. Als een secundaire replica niet is bijgewerkt met de primaire replica en u de database uit de beschikbaarheidsgroep moet verwijderen voordat de secundaire versie kan worden opgevangen, moet u de back-up van de back-up van Logboeken terugzetten om deze te kunnen opheffen voordat u deze opnieuw toevoegt aan de groep met beschikbare transactielog gegevens.
Status
Microsoft heeft bevestigd dat dit probleem zich kan voordoen in de Microsoft-producten die worden vermeld in de sectie Van toepassing op.
