MSSQLSERVER_35250

Articolo
08/21/2023

Si applica a: SQL Server

Dettagli

Attributo	valore
Nome prodotto	SQL Server
ID evento	35250
Origine evento	MSSQLSERVER
Componente	SQLEngine
Nome simbolico	HADR_PRIMARYNOTACTIVE
Testo del messaggio	La connessione alla replica primaria non è attiva. Il comando non può essere elaborato.

Spiegazione

Questo messaggio si verifica quando si tenta di aggiungere database secondari a un gruppo di disponibilità AlwaysOn. L'impossibilità di connettersi all'endpoint può in genere causare questo errore.

Azione utente

Opzione 1: Eseguire i passaggi direttamente in un notebook tramite Azure Data Studio

Aprire il notebook in Azure Data Studio

Informazioni su come installare Azure Data Studio

Opzione 2: seguire il passaggio manualmente**

Nota

Tutti i passaggi seguenti devono essere eseguiti sia nella replica primaria che nelle repliche secondarie problematiche.

1. Verificare che l'endpoint sia stato creato e avviato.

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

Avviso

Prestare attenzione quando si esegue il comando successivo perché può causare un tempo di inattività momentaneo per la replica.

È possibile usare questi comandi per riavviare l'endpoint individuato

ALTER ENDPOINT hadr_endpoint STATE = STOPPED
ALTER ENDPOINT hadr_endpoint STATE = STARTED

2. Controllare se è possibile connettersi all'endpoint

Usare telnet o Test-NetConnection per convalidare la connettività. Se l'endpoint è in ascolto e la connessione ha esito positivo, telnet mostrerà una schermata vuota con un cursore lampeggiante. In caso contrario, verrà visualizzato un errore di connessione da telnet. Per uscire da una connessione telnet riuscita, premere CTRL+]. Se si usa Test-NetConnection cercare o TcpTestSucceeded : True TcpTestSucceeded : False.
```
telnet ServerName <port_number>
telnet IP_Address <port_number>
```
```
Test-NetConnection -ComputerName <ServerName> -Port <port_number>
Test-NetConnection -ComputerName <IP_address> -Port <port_number>
```

Problemi relativi al DNS:

Se telnet/Test-NetConnection riesce all'indirizzo IP ma non riesce a ServerName, è probabile che si verifichi un problema di risoluzione dei nomi o DNS. Vedere Verificare la presenza di problemi di risoluzione dei nomi

Più processi in ascolto sulla stessa porta

Se la connessione telnet/Test-NetConnection funziona usando ServerName ma non riesce usando l'indirizzo IP, potrebbe essere presente più di un endpoint definito in tale server (un'altra istanza di SQL, ad esempio) configurato per l'ascolto su tale porta. Anche se lo stato dell'endpoint nell'istanza in questione mostra "STARTED" un'altra istanza potrebbe effettivamente avere l'associazione di porte e impedire all'istanza corretta di ascoltare e stabilire connessioni TCP. Per trovare il processo proprietario della porta 5022, ad esempio, eseguire questo comando:
```
$port = "5022"
Get-Process -Id (Get-NetTCPConnection -LocalPort $port).OwningProcess |Select-Object Name, ProductVersion, Path, Id
```

Endpoint bloccato (firewall, antivirus)

Se telnet o Test-NetConnection non riesce a connettersi, cercare firewall e/o software antivirus che potrebbe bloccare la porta dell'endpoint in questione. Controllare l'impostazione del firewall per verificare se è consentita la comunicazione della porta dell'endpoint tra le istanze del server che ospitano la replica primaria e la replica secondaria (porta 5022 per impostazione predefinita). Se si esegue SQL Server nella macchina virtuale di Azure, è anche necessario assicurarsi che il gruppo di sicurezza di rete (NSG) consenta il traffico verso la porta dell'endpoint. Controllare l'impostazione del firewall (e del gruppo di sicurezza di rete per la macchina virtuale di Azure) per verificare se è consentita la comunicazione della porta dell'endpoint tra le istanze del server che ospitano la replica primaria e la replica secondaria (porta 5022 per impostazione predefinita)

Eseguire lo script di PowerShell seguente per verificare la presenza di regole di traffico in ingresso disabilitate
```
Get-NetFirewallRule -Action Block -Enabled True -Direction Inbound |Format-Table
```
Acquisire un output netstat o Get-NetTCPConnection e verificare che lo stato sia LISTENING o ESTABLISHED in IP:Port per l'endpoint specificato
```
netstat -a
```
```
Get-NetTCPConnection -LocalPort <port_number>
```
È anche possibile trovare il processo proprietario della porta: eseguire un comando simile al seguente (ad esempio usando la porta 5022)
```
$port = "5022"
Get-Process -Id (Get-NetTCPConnection -LocalPort $port).OwningProcess |Select-Object Name, ProductVersion, Path, Id
```

3. Verificare la presenza di errori nel sistema

È possibile eseguire una query su sys.dm_hadr_availability_replica_states per individuare last_connect_error_number e diagnosticare più facilmente il problema di aggiunta. A seconda della replica in cui si è verificato un problema di comunicazione, è possibile eseguire query sia sul database primario che secondario:
```
select
  r.replica_server_name,
  r.endpoint_url,
  rs.connected_state_desc,
  rs.last_connect_error_description,
  rs.last_connect_error_number,
  rs.last_connect_error_timestamp
from
  sys.dm_hadr_availability_replica_states rs
  join sys.availability_replicas r on rs.replica_id = r.replica_id
where
  rs.is_local = 1
```
Se il database secondario non è riuscito a comunicare con il server DNS, ad esempio o se la endpoint_url di una replica è stata configurata in modo non corretto durante la creazione del gruppo di disponibilità, è possibile ottenere i risultati seguenti nel last_connect_error_description:

DNS Lookup failed with error '11001(No such host is known)'

4. Verificare che l'endpoint sia configurato per la porta/IP corretta per cui è definito il gruppo di disponibilità

Eseguire la query seguente sulla replica primaria e quindi su ogni replica secondaria che non riesce a connettersi. In questo modo è possibile trovare l'URL e la porta dell'endpoint
```
select endpoint_url from sys.availability_replicas
```

Eseguire la query seguente per trovare gli endpoint e le porte

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

Confrontare endpoint_url e porta da ogni query e assicurarsi che la porta del endpoint_url corrisponda alla porta definita per l'endpoint in ogni rispettiva replica

Nota

Se si usano indirizzi IP specifici per l'endpoint in ascolto, rispetto all'impostazione predefinita "Listen all", potrebbe essere necessario definire gli URL che usano l'indirizzo IP specifico anziché il nome di dominio completo.

5. Controllare se l'account del servizio di rete dispone dell'autorizzazione CONNECT per l'endpoint

Eseguire le query seguenti per elencare gli account che dispongono dell'autorizzazione di connessione all'endpoint nei server in questione e per visualizzare l'autorizzazione assegnata a ogni endpoint pertinente.

SELECT 
  perm.class_desc,
  prin.name,
  perm.permission_name,
  perm.state_desc,
  prin.type_desc as PrincipalType,
  prin.is_disabled
FROM sys.server_permissions perm
  LEFT JOIN sys.server_principals prin ON perm.grantee_principal_id = prin.principal_id
  LEFT JOIN sys.tcp_endpoints tep ON perm.major_id = tep.endpoint_id
WHERE 
  perm.class_desc = 'ENDPOINT'
  AND perm.permission_name = 'CONNECT'
  AND tep.type = 4;

SELECT 
  ep.name, 
  sp.state,
  CONVERT(nvarchar(38), suser_name(sp.grantor_principal_id)) AS grantor,
  sp.TYPE AS permission,
  CONVERT(nvarchar(46),suser_name(sp.grantee_principal_id)) AS grantee
FROM sys.server_permissions SP 
  INNER JOIN sys.endpoints ep  ON sp.major_id = ep.endpoint_id
AND EP.type = 4
ORDER BY Permission,grantor, grantee;

6. Verificare la presenza di problemi di risoluzione dei nomi

Convalidare la risoluzione DNS usando nslookup o Resolve-DnsName sull'indirizzo IP e il nome:

nslookup <IP_Address>
nslookup <ServerName>

Resolve-DnsName  -Name <ServerName>
Resolve-DnsName  -Name <IP_address>

Il nome viene risolto nell'indirizzo IP corretto? L'indirizzo IP viene risolto nel nome corretto?
Verificare la presenza di voci di file HOSTS locali in ogni nodo che potrebbe puntare a un server non corretto. Dal prompt dei comandi stampare il file HOSTS usando questo comando:
```
type C:\WINDOWS\system32\drivers\etc\hosts
```
```
Get-Content 'C:\WINDOWS\system32\drivers\etc\hosts'
```
Controllare se sono presenti alias server per l'uso da parte di un client definito nelle repliche

7. Assicurarsi che SQL Server esegua una build recente (preferibilmente la build più recente)

Aggiornare le versioni di SQL Server per evitare problemi come KB3213703.

Per altre informazioni, vedere Creare un gruppo di disponibilità non riuscito con errore 35250 'Failed to join the database'

Condividi tramite