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

DŮLEŽITÉ: Tento článek je přeložen pomocí softwaru na strojový překlad Microsoft. Nepřesný či chybný překlad lze opravit prostřednictvím technologie Community Translation Framework (CTF). Microsoft nabízí strojově přeložené, komunitou dodatečně upravované články, a články přeložené lidmi s cílem zajistit přístup ke všem článkům v naší znalostní bázi ve více jazycích. Strojově přeložené a dodatečně upravované články mohou obsahovat chyby ve slovníku, syntaxi a gramatice. Společnost Microsoft není odpovědná za jakékoliv nepřesnosti, chyby nebo škody způsobené nesprávným překladem obsahu nebo jeho použitím našimi zákazníky. Více o CTF naleznete na http://support.microsoft.com/gp/machine-translation-corrections/cs.

Projděte si také anglickou verzi článku: 3095156
Příznaky
Předpokládejme, že používáte skupiny dostupnosti AlwaysOn v databázi serveru Microsoft SQL Server 2012 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.
Transakční protokol databáze.Název databáze> "je plný kvůli"LOG_BACKUP".
Po spuštění protokolu zálohy jiného 9002 chybová zpráva:
Chyba: 9002, závažnosti: 17, stav: 9.
Transakční protokol databáze.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.
Transakční protokol databáze.Název databáze> "je plný kvůli"AVAILABILITY_REPLICA".

Záznam kontroly nelze zapsat do databázeNázev databáze> protože protokolu není dostatek místa. Obraťte se na správce databáze, zkrátit protokolu nebo přidělit více místa pro soubory protokolu databáze.
Chyba: 5901, závažnosti: 16, stav: 1.
Jedna nebo více jednotek pro zotavení patřící do databáze "Název databáze> "Nepodařilo se generovat kontrolní bod. To je obvykle způsobeno nedostatkem 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 pro podrobnější informace 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 protokolu aktualizace databáze "Název databáze>'. Následné protokolu zálohy je nutné předem záložní bod z "LSN id 1> "k"LSN id 2> "po prostoru protokolu pro protokolování je k dispozici.
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
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:
Jak potíže obejít
Zkracování protokolů a pokračovat v činnosti, můžete použít následující řešení.
  1. Zkontrolujte každý sekundární repliky ověřte 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í replika 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í replika
    • Odebrání ze skupiny dostupnosti databáze.
    • Databázi znovu přidáte do skupiny k dispozici.
  3. V každé replice sekundární
    • Databázi znovu přidáte do skupiny k dispozici.
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_lsnna každý sekundární replik a žádné zálohy protokolu byla přijata v době odebrání 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 je nutné jej odebrat 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 přímá databáze na sekundární replik a znovu osadit obnovit záloh protokolu s úplnou a zálohy protokolu transakce.
Prohlášení
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: 09/22/2015 02:55:00 - Revize: 1.0

Microsoft SQL Server 2012 Service Pack 2

  • kbqfe kbsurveynew kbfix kbexpertiseadvanced kbmt KB3095156 KbMtcs
Váš názor