Accedi con Microsoft
Accedi o crea un account.
Salve,
Seleziona un altro account.
Hai più account
Scegli l'account con cui vuoi accedere.

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à.

  1. 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>'
  2. Nella replica primaria

    • Rimuovere il database dal gruppo disponibilità.

    • Aggiungere di nuovo il database al gruppo di disponibilità.

  3. 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".

Serve aiuto?

Vuoi altre opzioni?

Esplorare i vantaggi dell'abbonamento e i corsi di formazione, scoprire come proteggere il dispositivo e molto altro ancora.

Le community aiutano a porre e a rispondere alle domande, a fornire feedback e ad ascoltare gli esperti con approfondite conoscenze.

Queste informazioni sono risultate utili?

Come valuti la qualità della lingua?
Cosa ha influito sulla tua esperienza?
Premendo Inviare, il tuo feedback verrà usato per migliorare i prodotti e i servizi Microsoft. L'amministratore IT potrà raccogliere questi dati. Informativa sulla privacy.

Grazie per il feedback!

×