Příznaky
Předpokládejme, že používáte skupinu dostupnosti AlwaysOn v databázi Microsoft SQL serveru 2012 nebo SQL Server 2014 a existuje velká otevřená aktivní transakce a vyžaduje další místo protokolu. Když se soubor protokolu nedokáže rozrůstat z některého z následujících důvodů, transakce selže.
-
Nedostatek dalšího místa v souboru
-
Konfigurace souboru protokolu neroste
-
Soubor protokolu dosáhl maximální nastavené velikosti.
Zobrazí se také následující chybová zpráva:
Chyba: 9002, závažnost: 17, stát: 9. transakční protokol pro databázi <název databáze> je zaplněný z důvodu LOG_BACKUP.
Po spuštění zálohy protokolu se zobrazí jiná chybová zpráva 9002:
Chyba: 9002, závažnost: 17, stát: 9. transakční protokol pro databázi <název databáze> je zaplněný z důvodu ACTIVE_TRANSACTION.
Po další operaci zálohování protokolu se zobrazí jiná chybová zpráva 9002 s chybovou zprávou 5901:
Chyba: 9002, závažnost: 17, stát: 9. transakční protokol pro databázi <název databáze> je zaplněný z důvodu AVAILABILITY_REPLICA.
Do databáze <> název databáze nelze zapsat kontrolní záznam, protože není dostatek místa v protokolu. Požádejte správce databáze o zkrácení protokolu nebo přidělení většího místa do souborů protokolu databáze. Chyba: 5901, závažnost: 16, stav: 1. jednu nebo víc jednotek obnovení náležejících k databázi <> název databáze se nepodařilo vygenerovat kontrolní bod. Obvykle je to způsobeno nedostatkem systémových prostředků, jako je disk nebo paměť, nebo v některých případech kvůli poškození databáze. Podrobnější informace o této chybě najdete v protokolu chyb v předchozích položkách.
Když se následně v průběhu vrácení transakce převezme další záložní body, může se zobrazit následující chybová zpráva:
Msg 3052, úroveň 16, stav 1, protokol 4BACKUP protokolu nemohl zaznamenat aktualizace pro databázi <> název databáze . Další zálohy protokolu budou muset přejít na místo záložního bodu "<LSN ID 1> ' na ' <hodnotu lsn ID 2> ' po tom, co je místo protokolu k dispozici pro jejich protokolování.
Když dostanete tyto zprávy, nemůžete už v databázi odesílat žádné nové transakce a nemůžete zvětšit soubor protokolu ani přidat další soubor protokolu.
Řešení
Tento problém byl poprvé opraven následující kumulativní aktualizací SQL serveru:
Každá nová kumulativní aktualizace pro SQL Server obsahuje všechny opravy hotfix a všechny opravy zabezpečení, které byly součástí předchozí kumulativní aktualizace. Doporučujeme stáhnout a nainstalovat nejnovější kumulativní aktualizace pro SQL Server:
Alternativní řešení
K zkracování protokolů a aktivit obnovení můžete použít následující alternativní řešení.
-
Zkontrolujte, jestli má každá sekundární replika ověřit last_hardened_lsn sekundární repliky (viz Sys.dm_hadr_database_replica_stateslast_hardened_lsn). To můžete udělat tak, že spustíte následující dotaz, který je připojený k primární instanci repliky
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>'
-
V primární replice
-
Odeberte databázi ze skupiny dostupnosti.
-
Znovu přidejte databázi do skupiny dostupnosti.
-
-
V každé sekundární replice
-
Znovu přidejte databázi do skupiny dostupnosti.
-
Odebráním databáze ze skupiny dostupnosti se okamžitě zkrátí protokoly a uvolní se místo protokolu. Pokud je last_hardened_lsn v každé sekundární replice stejný jako primární replika a v okamžiku odebrání databáze ze skupiny dostupnosti se neberou žádné zálohy v protokolech, bude sekundární replika úspěšně znovu přidaná bez jakýchkoli chyb nebo nebude nutné obnovit zálohy protokolu. Pokud sekundární replika není aktuální s primární replikou a potřebujete ji odebrat ze skupiny dostupnosti před zařazením sekundárního souboru, může se stát, že tato sekundární replika bude mít obnovené zálohy protokolu, aby je zachytila, než ji znovu přidal do skupiny dostupnosti
Stav
Společnost Microsoft potvrzuje, že se jedná o problém v produktech této společnosti, které jsou uvedeny v části Informace v tomto článku jsou určeny pro produkt.
