Príznaky
Predpokladajme, že používate skupinu dostupnosti AlwaysOn v databáze Microsoft SQL Server 2012 alebo SQL Server 2014, a ak je k dispozícii Veľká otvorená aktívna transakcia a vyžaduje sa ďalšie miesto v denníku. Keď súbor denníka nedokáže vyrásť z niektorého z nasledujúcich dôvodov, transakcia zlyhá.
-
Chýbajúci ďalší priestor na súbor
-
Súbor denníka je nakonfigurovaný tak, aby nerástol
-
Súbor denníka dosiahol svoju nakonfigurovanú maximálnu veľkosť.
Zobrazí sa tiež nasledujúce chybové hlásenie:
Chyba: 9002, závažnosť: 17; stav: 9. denník transakcií databázy "<názov databázy>" je plný z dôvodu "LOG_BACKUP".
Po spustení zálohy denníka sa zobrazí ďalšie chybové hlásenie 9002:
Chyba: 9002, závažnosť: 17; stav: 9. denník transakcií databázy "<názov databázy>" je plný z dôvodu "ACTIVE_TRANSACTION".
Po ďalšom zálohovaní denníka sa zobrazí ďalšie chybové hlásenie 9002 a za ním sa zobrazí chybové hlásenie 5901:
Chyba: 9002, závažnosť: 17; stav: 9. denník transakcií databázy "<názov databázy>" je plný z dôvodu "AVAILABILITY_REPLICA".
Nepodarilo sa napísať kontrolný bod v databáze <názov databázy>, pretože denník je mimo priestoru. Požiadajte správcu databázy o skrátenie denníka alebo vyhradenie väčšieho miesta na súbory denníkov databázy. Chyba: 5901, závažnosť: 16, stav: 1. jeden alebo viacero jednotiek obnovenia, ktoré patria do databázy "<názov databázy>" zlyhalo vytvorenie kontrolného bodu. Zvyčajne je to spôsobené nedostatkom systémových zdrojov, ako je napríklad disk alebo pamäť, alebo v niektorých prípadoch z dôvodu poškodenia databázy. Podrobnejšie informácie o tomto zlyhaní Preskúmajte v denníku chýb predchádzajúce položky.
Keď následný kontrolný bod alebo zálohy denníka sa potom vykonajú počas vrátenia transakcie, môže sa zobraziť nasledujúce chybové hlásenie:
MSG 3052, úroveň 16, štát 1, denník 4BACKUP v riadkoch sa nepodarilo prihlásiť aktualizácie databázy <názov databázy>. Ďalšie zálohy denníkov sa budú vyžadovať na prehratie bodu zálohovania z poľa "<LSN ID 1>" na "<LSN ID 2>" po sprístupnení priestoru denníka na ich zapisovanie do denníka.
Po prijatí týchto správ už nebudete môcť odosielať žiadne nové transakcie do databázy a nie je možné pestovať súbor denníka ani pridať ďalší súbor denníka.
Riešenie
Tento problém bol najskôr vyriešený v nasledujúcej kumulatívnej aktualizácii SQL servera:
Každá nová Kumulatívna aktualizácia pre SQL Server obsahuje všetky rýchlych opráv a všetky opravy zabezpečenia, ktoré boli súčasťou predchádzajúcej kumulatívnej aktualizácie. Odporúčame, aby ste si stiahli a nainštalovali najnovšie kumulatívne aktualizácie pre SQL Server:
Alternatívne riešenie
Môžete použiť nasledujúce alternatívne riešenie na skrátenie denníkov a obnovenie aktivity.
-
Skontrolujte, či sú všetky sekundárne repliky na overenie sekundárnej repliky last_hardened_lsn (pozri sys.dm_hadr_database_replica_states) sa zhoduje s primárnou replikou last_hardened_lsn. Môžete to urobiť spustením nasledujúceho dotazu, ktorý je pripojený k inštancii primárnej 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>'
-
Na primárnej replike
-
Odstráňte databázu zo skupiny dostupnosti.
-
Opätovné pridanie databázy do skupiny dostupnosti.
-
-
Na každej sekundárnej replike
-
Opätovné pridanie databázy do skupiny dostupnosti.
-
Odstránením databázy zo skupiny dostupnosti sa okamžite skrátia jeho denníky a uvoľní sa priestor denníka. Ak je last_hardened_lsn na každej sekundárnej replike identická s primárnou replikou a pri odstránení databázy zo skupiny dostupnosti sa neberú do úvahy žiadne zálohy denníkov a opätovné pridanie databázy na všetky sekundárne, sekundárna replika sa bude úspešne opätovne pridať bez chýb alebo s cieľom obnoviť zálohy denníkov na sekundárnom. Ak sekundárna replika nie je aktuálna s primárnou replikou a vy budete musieť odstrániť databázu zo skupiny dostupnosti, kým sa sekundárne môže dohnať, môže sa stať, že sekundárna replika bude musieť mať zálohy denníkov obnovené, aby ju pred opätovným pridaním do skupiny dostupnosti zachytili do skupiny dostupnosti, alebo aby ju opätovne vypracovala s úplným zálohovaním databázy denníka transakcií
Stav
Spoločnosť Microsoft potvrdzuje, že ide o problém v produktoch spoločnosti Microsoft, ktoré sú uvedené v tomto článku v časti Informácie v tomto článku sa týkajú nasledujúcich produktov.
