Oprava: Chyba 9002 a chyba 3052 při pokusu přidat nebo zálohovat soubor protokolu v SQL Server 2012 nebo SQL Server 2014

Příznaky

Předpokládejme, že používáte skupiny dostupnosti AlwaysOn v Microsoft SQL Server 2012 nebo SQL Server 2014 databáze a velké otevřené aktivní transakce existuje a vyžaduje místo protokolu další. Když z jednoho z následujících důvodů nelze zvětšit soubor protokolu, transakce se nezdaří.
  • Nedostatek místa pro další soubor
  • Soubor protokolu je nakonfigurován tak, aby růst
  • Soubor protokolu dosáhl maximální nakonfigurovanou velikost
Dále se zobrazí následující chybová zpráva:
Chyba: 9002, závažnosti: 17, stav: 9.
Protokol transakce pro databázi "<název databáze>" je plný kvůli "LOG_BACKUP".
Po spuštění protokolu zálohování jiného 9002 chybová zpráva:
Chyba: 9002, závažnosti: 17, stav: 9.
Protokol transakce pro databázi "<název databáze>" je plný kvůli "ACTIVE_TRANSACTION".
Po dalším záloha protokolu potom jiného 9002 chybová zpráva následovaný chybová zpráva 5901:
Chyba: 9002, závažnosti: 17, stav: 9.
Protokol transakce pro databázi "<název databáze>" je plný kvůli "AVAILABILITY_REPLICA".

Kontrolní záznam v databázi <název databáze> nelze zapisovat, protože protokolu není dostatek místa. Obraťte se na správce databáze chcete zkrátit protokolu nebo přidělit více místa pro soubory protokolu databáze.
Chyba: 5901, závažnosti: 16, stát: 1.
Jedna nebo více jednotek pro zotavení patřící do databáze "<název databáze>" Nepodařilo se vygenerovat kontrolní bod. To je obvykle způsobeno nedostatku systémových prostředků, jako je například disk nebo paměť nebo v některých případech z důvodu poškození databáze. Zkontrolujte předchozí položky v protokolu chyb další podrobnosti o této chybě.
Při následných záloh protokolu kontrolního bodu obnovení nebo jsou pak přijata během vrácení transakce, může se zobrazit následující chybová zpráva:
Msg 3052, úroveň 16 stav 1, řádek 4
Protokol zálohování se nepodařilo přihlásit aktualizace databáze ' <název databáze>'. Následné protokolu zálohy budou přejdete záložní bod z ' <LSN id 1>' k ' <LSN id 2>' po místa protokolu je k dispozici pro protokolování je.
Při přijetí těchto zpráv budete již moci odesílat všechny nové transakce do databáze a nelze zvětšit soubor protokolu nebo přidat další soubor s protokolem.

Řešení

Tento problém byl poprvé opraven v následující kumulativní aktualizace serveru SQL Server:
Doporučení: Nainstalujte nejnovější kumulativní aktualizaci pro SQL Server

Jak potíže obejít

Zkracování protokolů a pokračování činnosti můžete použít následující řešení.
  1. Zkontrolujte každý sekundární repliky ověřte, zda sekundární replika last_hardened_lsn (viz sys.dm_hadr_database_replica_states) odpovídá primární replika last_hardened_lsn. To lze provést spuštěním následujícího dotazu, který je připojen primární repliky instance
    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. Na primární repliky
    • Odebrání ze skupiny dostupnosti databáze.
    • Databázi znovu přidáte do skupiny dostupnosti.
  3. Na každý sekundární repliky
    • Databázi znovu přidáte do skupiny dostupnosti.
Odebráním databáze ze skupiny dostupnosti bude okamžitě zkrátit její protokoly a uvolnit tak místo v protokolu.

Pokud je stejná jako primární replika last_hardened_lsn na každý sekundární replik a žádné zálohy protokolu byla přijata v době odebrání ze skupiny dostupnosti databáze a znovu přidat na každý sekundární databáze, sekundární repliky úspěšně bude znovu přidat bez jakékoli chyby nebo nutnosti obnovení záloh protokolu na sekundární.

Pokud sekundární replika není aktuální s primární replika a odebrání ze skupiny dostupnosti databáze, před sekundární lze zachytit, že sekundární replika může musí mít dohnat před znovu přidat do skupiny dostupnosti nebo zrušení databáze na sekundární replik a znovu osadit obnovit záloh protokolu s úplnou a zálohy protokolu transakce.

Stav

Společnost Microsoft potvrdila, že se jedná o problém v produktech společnosti Microsoft, které jsou uvedeny v části "Platí pro".

Vlastnosti

ID článku: 3095156 - Poslední kontrola: 20. 1. 2017 - Revize: 2

Váš názor