Condividi tramite


MSSQLSERVER_35267

Si applica a: SQL Server

Dettagli

Attributo Valore
Nome prodotto SQL Server
ID evento 35267
Origine evento MSSQLSERVER
Componente SQLEngine
Nome simbolico HADR_DISCONNECTED_DB
Testo del messaggio Connessione dei gruppi di disponibilità AlwaysOn con %S_MSG database terminato per %S_MSG database '%.*ls' nella replica di disponibilità '%.*ls' con ID replica: {%.8x-%.4x-%.4x-%.2x-%.2x-%.2x-%.2x%.2x%.2x%.2x%.2x}. Questo è un messaggio informativo. Non è richiesta alcuna azione da parte dell'utente.

Spiegazione

Questo messaggio si verifica quando una replica del gruppo di disponibilità perde la connessione alle repliche remote nell'endpoint del mirroring del database. Ecco alcuni esempi di come è possibile visualizzare questo errore:

Always On Availability Groups connection with secondary database terminated for primary database 'ContosoDb' on the availability replica 'PRODSQL' with Replica ID: {xxxxxxxx-xxxx-xxxx-xxxxx-xxxxxxxxxxxx}. This is an informational message only. No user action is required.
Always On Availability Groups connection with primary database terminated for secondary database 'ContosoDb' on the availability replica 'PRODSQL' with Replica ID: {xxxxxxxx-xxxx-xxxx-xxxxx-xxxxxxxxxxxx}. This is an informational message only. No user action is required.

Come si può notare, l'errore può essere visualizzato nella replica primaria che indica che ha perso la comunicazione con la replica secondaria o viceversa.

L'errore 35267 è in genere intermittente e potrebbe risolversi nel momento in cui la causa sottostante si risolve. Ad esempio, un problema di rete intermittente potrebbe risolversi e la connessione potrebbe ristabilire se stessa.

In molti casi, il nodo remoto a cui il nodo locale sta tentando di connettersi potrebbe anche non essere a conoscenza dell'errore di connessione. Pertanto, è possibile che questo errore venga generato solo in una delle repliche, non entrambe.

L'errore 35267 può talvolta verificarsi insieme all'errore 35206, che viene generato quando è trascorso un periodo significativo senza una connessione riuscita( ad esempio, più di 10 secondi).

A connection timeout has occurred on a previously established connection to availability replica 'PRODSQL' with id [xxxxxxxx-xxxx-xxxx-xxxxx-xxxxxxxxxxxx].  Either a networking or a firewall issue exists or the availability replica has transitioned to the resolving role.

Always On Availability Groups connection with primary database terminated for secondary database 'ContosoHRDb' on the availability replica 'PRODSQL' with Replica ID: {xxxxxxxx-xxxx-xxxx-xxxxx-xxxxxxxxxxxx}. This is an informational message only. No user action is required.
Always On Availability Groups connection with primary database terminated for secondary database 'ContosoFinDb' on the availability replica 'PRODSQL' with Replica ID: {xxxxxxxx-xxxx-xxxx-xxxxx-xxxxxxxxxxxx}. This is an informational message only. No user action is required.
Always On Availability Groups connection with primary database terminated for secondary database 'ContosoMktngDb' on the availability replica 'PRODSQL' with Replica ID: {xxxxxxxx-xxxx-xxxx-xxxxx-xxxxxxxxxxxx}. This is an informational message only. No user action is required.

La terminazione della connessione del gruppo di disponibilità con la replica remota può causare diversi problemi di replica locale. Ad esempio, se il gruppo di disponibilità usa la modalità SINCRONA e la connessione viene persa, la replica locale potrebbe terminare in attesa di conferma dal remoto. Di conseguenza, il log delle transazioni non viene troncato e il log delle transazioni esaurisce lo spazio (errore MSSQLSERVER_9002) e in seguito non sarà più disponibile (errore MSSQLSERVER_9001). Ecco un esempio di gruppo di errori in cui si è verificato questo errore. Il motivo per cui il log delle transazioni è pieno è "AVAILABILITY_REPLICA", ovvero questa replica è in attesa che la replica remota riconosca i record di log applicati.

Error: 9002, Severity: 17, State: 9.
The transaction log for database 'ContosoAnalyticsDb' is full due to 'AVAILABILITY_REPLICA'.
Error: 3314, Severity: 21, State: 3.
During undoing of a logged operation in database 'ContosoAnalyticsDb' (page (1:32573799) if any), an error occurred at log record ID (7672713:36228:159). Typically, the specific failure is logged previously as an error in the operating system error log. Restore the database or file from a backup, or repair the database.
State information for database 'ContosoAnalyticsDb' - Hardened Lsn: '(7672713:38265:1)'    Commit LSN: '(7672712:1683087:46)'    Commit Time: 'JuN  10 2022  5:51AM'

Always On Availability Groups connection with secondary database terminated for primary database 'ContosoAnalyticsDb' on the availability replica 'SQL2019DB' with Replica ID: {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}. This is an informational message only. No user action is required.

Database ContosoAnalyticsDb was shutdown due to error 3314 in routine 'XdesRMReadWrite::RollbackToLsn'. Restart for non-snapshot databases will be attempted after all connections to the database are aborted.

Error during rollback. shutting down database (location: 1).
Error: 9001, Severity: 21, State: 5.
The log for database 'ContosoAnalyticsDb' is not available. Check the operating system error log for related error messages. Resolve any errors and restart the database.

Recovery of database 'ContosoAnalyticsDb' (6) is 0% complete (approximately 60177 seconds remain). Phase 2 of 3. This is an informational message only. No user action is required.

Causa

  • I problemi di connessione di rete possono verificarsi tra le repliche primarie e secondarie
  • Problemi di SQL Server o del sistema operativo nelle repliche primarie o secondarie che causano l'esecuzione dei thread. Alcuni esempi:
    • Problemi dell'utilità di pianificazione del sistema operativo SQL (utilità di pianificazione non yield o deadlock)
    • Memoria insufficiente nel computer che porta alla rimozione del working set di tutti i processi nel sistema, incluso SQL Server
    • Problemi del sistema operativo che causano l'arresto dei processi
  • Problemi di I/O lenti che causano attese intermittenti nella replica primaria o secondaria

Azione utente

Le informazioni seguenti illustrano gli scenari più comuni, ma non è un elenco completo dei passaggi per la risoluzione dei problemi. I motivi specifici per l'occorrenza di questo problema possono includere un lungo elenco di possibilità.

Problemi di connessione

Per verificare la presenza di problemi di connessione da SQL Server in cui viene generato l'errore in SQL Server remoto, è possibile considerare i passaggi seguenti:

Passaggio 1: Verificare che l'endpoint in SQL Server remoto sia attivo

Eseguire la query seguente per individuare l'endpoint

SELECT
 tep.name as EndPointName,
 sp.name As CreatedBy,
 tep.type_desc,
 tep.state_desc,
 tep.port
FROM
 sys.tcp_endpoints tep
INNER JOIN sys.server_principals sp ON tep.principal_id = sp.principal_id
WHERE tep.type = 4

Passaggio 2. Testare la connettività all'endpoint remoto

Usare Test-NetConnection per convalidare la connettività. Se l'endpoint è in ascolto e la connessione ha esito positivo, cercare .TcpTestSucceeded : True Sostituire ServerName o IP_Address con SQL Server remoto e il numero di porta con quello dell'endpoint del mirroring del database.

Test-NetConnection -ComputerName <ServerName> -Port <port_number>
Test-NetConnection -ComputerName <IP_address> -Port <port_number>

Passaggio 3. Raccogliere una traccia di rete

Gli errori di rete intermittenti sono spesso difficili da rilevare, a meno che non si acquisisca una traccia di rete, che mostra le reimpostazioni di rete (pacchetti eliminati) o problemi simili. Per altre informazioni, vedere 0300 Problema di rete intermittente o periodico

Problemi dell'utilità di pianificazione di SQL Server

Se i thread di lavoro di SQL Server sono in esecuzione in problemi dell'utilità di pianificazione per vari motivi, i thread che gestiscono le richieste in ingresso possono interrompere temporaneamente la risposta mentre l'utilità di pianificazione ha problemi per ultimo.

Passaggio 4. Verificare la presenza di problemi dell'utilità di pianificazione in SQL Server

Un problema tipico dell'utilità di pianificazione non yield viene registrato nel log degli errori di SQL Server dopo 70 secondi di stato non restituito. TUTTAVIA, SQL Server controlla lo stato delle utilità di pianificazione più frequentemente rispetto a quello e segnala gli stati intermedi che non producono negli eventi estesi. Se si individuano problemi dell'utilità di pianificazione nel nodo remoto che corrispondono all'ora dell'errore 35267, concentrarsi sulla risoluzione di tali problemi. Ecco come è possibile verificare la presenza di occorrenze di breve durata di problemi dell'utilità di pianificazione che non raggiungono la soglia di 70 secondi, ma si verificano per 10 o 20 secondi.

Usare il file di evento esteso integrità sistema

  1. Individuare il file di evento esteso integrità sistema dall'ora dell'evento.
  2. Fare doppio clic su system_health_0_xxxxxxxxxxxxxxxxxx.xel per aprirlo in SQL Server Management Studio (SSMS). In alternativa, è possibile usare sys.fn_xe_file_target_read_file per visualizzare o importare il file come tabella per semplificare il filtro.
  3. Cercare eventuali occorrenze di scheduler_monitor_non_yielding_ring_buffer_recorded evento. Se vengono rilevati, si tratta di un'indicazione che SQL Server ha rilevato eventi dell'utilità di pianificazione non restituiti e li sta registrando. Questi eventi vengono registrati prima dei dump di memoria dell'utilità di pianificazione non yiedling effettivi e delle voci del log degli errori, che si verificano dopo 60-70 secondi di stato non restituito. In altre parole, è possibile usare il scheduler_monitor_non_yielding_ring_buffer_recorded per rilevare problemi di utilità di pianificazione non di breve durata che non vengono registrati nel log degli errori ma che si sono verificati ancora. Questi potrebbero essere motivi per la mancanza intermittente o di breve durata della connettività tra i nodi del gruppo di disponibilità.

Usare il log di diagnostica

  1. Individuare il log di diagnostica nella directory \Log dal momento dell'evento (applicabile ai sistemi cluster Windows). Il formato del nome file è simile al seguente SERVERNAME_MSSQLSERVER_SQLDIAG_x_xxxxxxxxxxxxxxxxxx.xel.

  2. Fare doppio clic per aprire il file in SQL Server Management Studio (SSMS). In alternativa, è possibile usare sys.fn_xe_file_target_read_file per visualizzare o importare il file come tabella per semplificare il filtro.

  3. Dopo l'apertura in SSMS, individuare un'istanza di component_health_result evento e fare clic con il pulsante destro del mouse sul comando seguente e scegliere Mostra colonna nella tabella: componente state_desc

  4. Fare quindi clic con il pulsante destro del mouse su ogni colonna e scegliere Filtra per questo valore per applicare i filtri seguenti:

    • l'evento component_health_result che deve essere l'unico visualizzato
    • component field='query processing'
    • <> state_desc "pulito".
  5. Fare quindi doppio clic sulla colonna di dati per aprire i dati XML e cercare trackingNonYieldingScheduler il valore nella prima riga.

  6. Se il valore è diverso da 0x0 questo significa che SQL Server ha rilevato i primi segni di un'utilità di pianificazione che non produce e lo segnala qui.

    Di seguito è riportato un esempio in cui SQL Server ha rilevato una condizione senza rendimento con un indirizzo dell'utilità di pianificazione "0x4fedb840040":

     <queryProcessing maxWorkers="9600" workersCreated="2574" workersIdle="1883" tasksCompletedWithinInterval="175591" pendingTasks="3" ... trackingNonYieldingScheduler="0x4fedb840040">
    

Memoria insufficiente del sistema operativo

Potrebbero verificarsi diversi problemi a livello del sistema operativo che attivano tale mancanza intermittente di risposta. Uno comune è memoria insufficiente. Nel nodo del gruppo di disponibilità remoto in cui si verifica il problema sospetto, seguire questa procedura:

Passaggio 5. Verificare la presenza di problemi di memoria del sistema operativo che comportano il paging della memoria di SQL Server su disco

  1. Controllare il registro eventi di sistema di Windows per eventuali errori che indicano memoria fisica o virtuale insufficiente.

  2. Verificare la presenza dell'errore 17890 nel log degli errori di SQL Server o nel registro eventi dell'applicazione di Windows per verificare se la memoria insufficiente nel computer sta causando il taglio del working set di tutti i processi nel sistema, incluso SQL Server. L'errore è simile al seguente:

    A significant part of SQL Server process memory has been paged out. This may result in a performance degradation. Duration: 0 seconds. Working set (KB): 3383250, committed (KB):    9112480, memory utilization: 37%.
    

    Per informazioni dettagliate sui passaggi di ripresa, vedere MSSQLSERVER_17890

Passaggio 6. Configurare correttamente la memoria massima del server e bloccare le pagine in memoria

  1. Configurare la memoria max server di SQL Server su un valore che consente il sistema operativo e l'uso di altro processo hanno memoria disponibile. Valore consigliato in per impostare la memoria massima del server di SQL Server su non più del 75% delle dimensioni della RAM nel sistema. Per altre informazioni, vedere Opzioni di configurazione della memoria del server
  2. Abilitare l'opzione Blocca pagine in memoria (Windows) per impedire il paging di grandi dimensioni della cache del buffer di SQL Server.

I/O su disco lento

In alcuni casi i/O eccessivamente lenti possono causare l'arresto temporaneamente dei thread di SQL Server, che potrebbero causare la disconnessione dell'altra replica del gruppo di disponibilità.

Passaggio 7. Risolvere eventuali problemi di I/O lenti

Se si verificano errori che indicano operazioni di I/O lente, risolvere i problemi di I/O sottostanti.

SQL Server has encountered 2 occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [F:\TLOG\ContosoDb.ldf] in database id 9.  The OS file handle is 0x00000000000003BC.  The offset of the latest long I/O is: 0x0000003d26f600
SQL Server has encountered 2 occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [F:\DATA\t38data\ContosoDb2.mdf] in database id 7.  The OS file handle is 0x000000000000118C.  The offset of the latest long I/O is: 0x00000000012000
SQL Server has encountered 1 occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [F:\DATA\t38data\ContosoDb.mdf] in database id 9.  The OS file handle is 0x000000000000134C.  The offset of the latest long I/O is: 0x00000000012000

Always On Availability Groups connection with primary database terminated for secondary database 'ContosoDb2' on the availability replica 'SQLNODE1\INSTANCE19' with Replica ID: {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}. This is an informational message only. No user action is required.
Always On Availability Groups connection with primary database terminated for secondary database 'ContosoDb' on the availability replica 'SQLNODE1\INSTANCE19' with Replica ID: {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}. This is an informational message only. No user action is required.
  • Aggiornare tutti i driver di dispositivo e il firmware o eseguire altre diagnostica associate al sottosistema di I/O
  • L'accesso al disco può essere rallentato dai driver di filtro, ad esempio un programma antivirus. Per aumentare la velocità di accesso, escludere i file di dati di SQL Server dalle analisi antivirus attive
  • Collaborare con il fornitore dell'hardware e l'amministratore di sistema per diagnosticare e risolvere la causa del rallentamento dell'I/O

Per istruzioni dettagliate, vedere Risolvere i problemi di rallentamento delle prestazioni di SQL Server causati da problemi di I/O e MSSQLSERVER_833.