Condividi tramite

MSSQLSERVER_988

Applies to:SQL Server

Details

Attribute Value
Product Name SQL Server
Event ID 988
Event Source MSSQLSERVER
Component SQLEngine
Symbolic Name DB_HADRON_DATABASE_NO_QUORUM
Message Text Non è possibile accedere al database '%.*ls' perché manca un quorum di nodi per la disponibilità elevata. Riprovare in un secondo momento.

Symptoms

Quando si tenta di aggiungere un database a un gruppo di disponibilità AlwaysOn o di eseguire operazioni di lettura/scrittura nella replica primaria, è possibile che venga visualizzato l'errore di SQL Server 988 seguente:

Unable to access database '<DB Name>' because it lacks a quorum of nodes for high availability. (Microsoft SQL Server, Error: 988)

Questo errore indica che non è possibile accedere o aggiungere il database perché il numero richiesto di repliche secondarie sincronizzate non è disponibile per eseguire il commit della transazione.

Cause

The REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT setting enforces that the primary replica must wait for a specified number of synchronous secondary replicas to harden each transaction before committing. Se il numero necessario di repliche non è online, connesso e sincronizzato, è possibile che si verifichino i problemi seguenti, che causano scenari di blocco o errore che attivano l'errore 988.

  • La replica primaria non può completare i commit.
  • Un database aggiunto non può completare il processo di join, perché i database secondari non partecipano ancora.

Scenarios

Questo errore può verificarsi negli scenari seguenti:

Scenario 1: Aggiungere un nuovo database

Quando un nuovo database viene aggiunto al gruppo di disponibilità, i database secondari non fanno ancora parte del gruppo e non possono confermare il commit, causando una condizione di blocco.

Scenario 2: Errori di commit di runtime

Quando il valore configurato di REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT è maggiore del numero di repliche secondarie sincrone integre disponibili, il database primario non può procedere con i commit.

Workaround

Per risolvere il problema, usare una delle seguenti possibilità:

Opzione 1: Modificare l'impostazione REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT

La riduzione del valore in consente al 0 database primario di eseguire il commit senza attendere repliche secondarie sincrone.

Warning

Questa opzione migliora la disponibilità, ma aumenta il rischio di perdita di dati negli scenari di failover.

Usare SQL Server Management Studio (SSMS)

  1. Passare al nome del gruppo di disponibilità in SSMS.
  2. Right-click the name and select Properties.
  3. Impostare il valore REQUIRED SYNCHRONIZED SECONDARIES TO COMMIT su 0 o su un valore appropriato.

Use T-SQL

Eseguire la query riportata di seguito:

ALTER AVAILABILITY GROUP [AGNAME] SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 0);

Opzione 2: Effettuare il pre-seeding delle repliche secondarie (per l'aggiunta di database)

Assicurarsi che i database secondari siano pronti prima di aggiungere un database. Then, use automatic seeding, or manually restore the database on each secondary by using the Join only option.

Troubleshooting

Per diagnosticare e risolvere questo problema, seguire questa procedura:

Passaggio 1: Confermare l'impostazione REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT

Per verificare se l'impostazione REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT è abilitata per il gruppo di disponibilità, usare SSMS o T-SQL. Se il valore è 1 o superiore, procedere con il passaggio 2: Verificare lo stato delle repliche secondarie sincrone.

Use SSMS

  1. Passare al nome del gruppo di disponibilità in SSMS.
  2. Right-click the name and select Properties.
  3. Controllare il valore REQUIRED SYNCHRONIZED SECONDARIES TO COMMIT .CHECK the REQUIRED SYNCHRONIZED SECONDARIES TO COMMIT value.

Use T-SQL

Eseguire la query seguente sulla replica primaria:

SELECT name AS Availability_group_name,
       required_synchronized_secondaries_to_commit,
       *
FROM sys.availability_groups;

Note

Questa query può essere eseguita anche se si verifica l'errore 988.

Passaggio 2: Verificare lo stato delle repliche secondarie sincrone

Per verificare se il numero minimo di repliche secondarie sincrone sono connesse, sincronizzate e integre, usare SSMS o T-SQL.

Use SSMS

  1. Aprire dashboard gruppi di disponibilità nella replica primaria.
  2. Esaminare lo stato delle repliche secondarie.

Use T-SQL

Eseguire la query riportata di seguito:

SELECT ag.name AS Availability_group_name,
       drcs.database_name,
       ar.replica_server_name,
       ars.role_desc,
       ars.connected_state_desc,
       ars.synchronization_health_desc,
       ars.last_connect_error_description,
       ars.last_connect_error_number,
       ars.last_connect_error_timestamp,
       ar.endpoint_url
FROM sys.dm_hadr_availability_replica_states AS ars
     INNER JOIN sys.availability_replicas AS ar
         ON ars.replica_id = ar.replica_id
     INNER JOIN sys.availability_groups AS ag
         ON ar.group_id = ag.group_id
     INNER JOIN sys.dm_hadr_database_replica_cluster_states AS drcs
         ON ar.replica_id = drcs.replica_id;

Assicurarsi che il numero di CONNECTEDrepliche , SYNCHRONIZEDe HEALTHY corrisponda all'impostazione REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT .

La sessione eventi estesa seguente acquisisce le impostazioni dei criteri di commit e le modifiche dello stato di sincronizzazione per diagnosticare il motivo per cui le repliche secondarie sincronizzate necessarie impediscono i commit delle transazioni nei gruppi di disponibilità AlwaysOn di SQL Server.

CREATE EVENT SESSION [ag_state_change] ON SERVER
ADD EVENT sqlserver.alwayson_ddl_executed
    (ACTION (sqlos.system_thread_id, sqlserver.session_id, sqlserver.sql_text)),
ADD EVENT sqlserver.hadr_db_commit_mgr_harden
    (ACTION (sqlos.system_thread_id, sqlserver.session_id, sqlserver.sql_text)),
ADD EVENT sqlserver.hadr_db_commit_mgr_set_policy
    (ACTION (sqlos.system_thread_id, sqlserver.session_id, sqlserver.sql_text)),
ADD EVENT sqlserver.hadr_db_commit_mgr_update_harden
    (ACTION (sqlos.system_thread_id, sqlserver.session_id, sqlserver.sql_text)),
ADD EVENT sqlserver.hadr_db_partner_set_policy
    (ACTION (sqlos.system_thread_id, sqlserver.session_id, sqlserver.sql_text)),
ADD EVENT sqlserver.hadr_db_partner_set_sync_state
    (ACTION (sqlos.system_thread_id, sqlserver.session_id, sqlserver.sql_text))
ADD TARGET package0.event_file
    (SET filename = N'ag_state_change')
WITH
(
        MAX_MEMORY = 4096 KB,
        EVENT_RETENTION_MODE = ALLOW_SINGLE_EVENT_LOSS,
        MAX_DISPATCH_LATENCY = 30 SECONDS,
        MAX_EVENT_SIZE = 0 KB,
        MEMORY_PARTITION_MODE = NONE,
        TRACK_CAUSALITY = OFF,
        STARTUP_STATE = OFF
);
GO

The hadr_db_commit_mgr_update_harden event could be used to identify the issue. When the issue occurs, the MinSyncCommitFailure status means there aren't enough synchronization secondaries to meet the configured minimum synchronization count.

  • Last updated on