Sintomi
Supponiamo che tu usi un gruppo di disponibilità AlwaysOn in un database di Microsoft SQL Server 2012 o SQL Server 2014 e che esista una grande transazione attiva aperta e che richieda spazio di log aggiuntivo. Quando il file di log non può aumentare per uno dei motivi seguenti, la transazione non riesce.
-
Mancanza di spazio aggiuntivo per i file
-
Il file di log è configurato per non aumentare
-
Il file di log ha raggiunto la dimensione massima configurata
Inoltre, viene visualizzato il messaggio di errore seguente:
Errore: 9002, gravità: 17, stato: 9. il log delle transazioni per il database "<nome database>" è completo a causa di "LOG_BACKUP".
Dopo aver eseguito un backup del log, viene visualizzato un altro messaggio di errore di 9002:
Errore: 9002, gravità: 17, stato: 9. il log delle transazioni per il database "<nome database>" è completo a causa di "ACTIVE_TRANSACTION".
Dopo un altro backup del log, viene visualizzato un altro messaggio di errore di 9002 seguito da un messaggio di errore di 5901:
Errore: 9002, gravità: 17, stato: 9. il log delle transazioni per il database "<nome database>" è completo a causa di "AVAILABILITY_REPLICA".
Non è stato possibile scrivere un record checkpoint in database <nome database> perché il log non è più disponibile. Contattare l'amministratore del database per troncare il log o allocare più spazio ai file di log del database. Errore: 5901, gravità: 16, stato: 1. una o più unità di ripristino appartenenti al database ' <nome database>' non è riuscito a generare un checkpoint. Ciò è in genere causato dalla mancanza di risorse di sistema, ad esempio disco o memoria, o in alcuni casi a causa del danneggiamento del database. Esaminare le voci precedenti nel log degli errori per informazioni più dettagliate su questo errore.
Quando il checkpoint successivo o i backup del log vengono quindi eseguiti durante il rollback della transazione, potrebbe essere visualizzato il messaggio di errore seguente:
Msg 3052, livello 16, stato 1, linea 4BACKUP LOG non è riuscito a registrare gli aggiornamenti per il database "<nome database>". I backup del log successivi saranno necessari per spostare il punto di backup da "<ID LSN 1>" a "<id LSN 2>" dopo aver reso disponibile lo spazio del log per la registrazione.
Quando si ricevono questi messaggi, non è più possibile inviare nuove transazioni al database e non è possibile aumentare il file di log o aggiungere un altro file di log.
Risoluzione
Il problema è stato risolto per la prima volta nel seguente aggiornamento cumulativo di SQL Server:
Ogni nuovo aggiornamento cumulativo per SQL Server contiene tutti gli hotfix e tutti gli aggiornamenti della sicurezza inclusi nell'aggiornamento cumulativo precedente. È consigliabile scaricare e installare gli aggiornamenti cumulativi più recenti per SQL Server:
Soluzione alternativa
È possibile usare la soluzione alternativa seguente per troncare i registri e riprendere l'attività.
-
Controllare ogni replica secondaria per verificare che la last_hardened_lsn di replica secondaria (Vedi sys.dm_hadr_database_replica_states) corrisponda alla last_hardened_lsndi replica primaria. A questo scopo, è possibile eseguire la query seguente connessa all'istanza di replica primaria
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>'
-
Nella replica primaria
-
Rimuovere il database dal gruppo disponibilità.
-
Aggiungere di nuovo il database al gruppo di disponibilità.
-
-
In ogni replica secondaria
-
Aggiungere di nuovo il database al gruppo di disponibilità.
-
Rimuovendo il database dal gruppo di disponibilità, i log verranno immediatamente troncati e liberati. Se il last_hardened_lsn di ogni replica secondaria è identico alla replica primaria e non viene eseguito alcun backup del log durante il periodo di rimozione del database dal gruppo di disponibilità e l'aggiunta di un nuovo database in ogni secondario, la replica secondaria verrà aggiunta di nuovo senza errori o non sarà necessario ripristinare il backup del log sul secondario. Se una replica secondaria non è corrente con la replica primaria e si deve rimuovere il database dal gruppo di disponibilità prima che il secondario possa raggiungerlo, è possibile che la replica secondaria debba avere ripristinato i backup del log per recuperarlo prima di aggiungerlo di nuovo al gruppo di disponibilità oppure eliminare il database nella replica secondaria e reinizializzarlo con un backup completo e del database del log delle transazioni.
Stato
Microsoft ha confermato che questo problema si verifica nei prodotti elencati nella sezione "Si applica a".
