Prerequisiti e elenco di controllo consigliati per la risoluzione dei problemi di connettività di SQL Server

Si applica a: SQL Server
Numero KB originale: 4009936

Prerequisiti consigliati

Per risolvere efficacemente i problemi di connettività, raccogliere le informazioni seguenti:

• Testo del messaggio di errore e dei codici di errore. Controllare se l'errore è intermittente (si verifica solo a volte) o coerente (si verifica sempre).

• Registri eventi dell'applicazione e del sistema dai sistemi SQL Server e client. Questi log possono essere utili per verificare se si verificano problemi a livello di sistema in SQL Server.

• Se le connessioni hanno esito negativo da un'applicazione, raccogliere i stringa di connessione dall'applicazione. Queste stringhe sono in genere disponibili nei file Web.config per le applicazioni ASP.NET.

• Raccogliere ed esaminare i log degli errori di SQL Server per altri messaggi di errore ed eccezioni.

• Se si dispone dell'accesso amministratore al computer SQL Server, raccogliere ed esaminare le impostazioni del computer e gli account di servizio correnti usando la procedura seguente:

  1. Scaricare la versione più recente di SQLCHECK.

  2. Decomprimere il file scaricato in una cartella, ad esempio C:\Temp.

  3. Eseguire il prompt dei comandi come amministratore per raccogliere i dati e salvarli in un file. Ad esempio: SQLCHECK > C:\Temp\server01.SQLCHECK.TXT.

  Note

  Se si stanno risolvendo i problemi di connettività da un client remoto o si riso riguardano le query del server collegato, eseguire lo strumento SQLCHECK in tutti i sistemi coinvolti.

Elenco di controllo rapido per la risoluzione dei problemi di connettività

Opzione 1

Se si ha accesso all'output dello strumento SQLCHECK indicato nella sezione Prerequisiti consigliati ed esaminare le informazioni contenute in varie sezioni del file di output (Computer, Client Security e SQL Server), usare le informazioni per risolvere i problemi che contribuiscono al problema. Vedere gli esempi seguenti:

Opzione 2

Se non è possibile eseguire SQLCHECK nel computer SQL Server, è possibile controllare gli elementi seguenti prima di eseguire una risoluzione dettagliata dei problemi:

1. Assicurarsi che SQL Server sia avviato e che venga visualizzato il messaggio seguente nel log degli errori di SQL Server:

   SQL Server è pronto per le connessioni client. Questo è un messaggio informativo. Non è richiesto alcun intervento da parte dell'utente.

   Usare il comando seguente in PowerShell per controllare lo stato dei servizi di SQL Server nel sistema:

   Get-Service | Where {$_.status -eq 'running' -and $_.DisplayName -match "sql server*"}
   

   Usare il comando seguente per cercare nel file di log degli errori la stringa specifica "SQL Server è ora pronto per le connessioni client. Si tratta di un messaggio informativo; non è richiesta alcuna azione da parte dell'utente.":

   Get-ChildItem -Path "c:\program files\microsoft sql server\mssql*" -Recurse -Include Errorlog |select-string "SQL Server is now ready for client connections."
   

2. Verificare la connettività di base sull'indirizzo IP e verificare eventuali anomalie: ping -a <SQL Server machine>, ping -a <SQL Server IP address>. Se si verificano problemi, rivolgersi all'amministratore di rete. In alternativa, è possibile usare Test-NetConnection in PowerShell:

   $servername = "DestinationServer"
   Test-NetConnection -ComputerName $servername
   

3. Controllare se SQL Server è in ascolto sui protocolli appropriati esaminando il log degli errori:

    Get-ChildItem -Path "c:\program files\microsoft sql server\mssql*" -Recurse -Include Errorlog |select-string "Server is listening on" , "ready to accept connection on" -AllMatches
   

4. Verificare se è possibile connettersi a SQL Server usando un file UDL. Se funziona, potrebbe verificarsi un problema con il stringa di connessione. Per istruzioni sulla procedura di test UDL, vedere Testare la connettività OLE DB a SQL Server usando un file UDL. In alternativa, è possibile usare lo script seguente per creare e avviare un file UDL-Test.udl (archiviato nella cartella %TEMP% ):

   clear
   
   $ServerName = "(local)"
   $UDL_String = "[oledb]`r`n; Everything after this line is an OLE DB initstring`r`nProvider=MSOLEDBSQL.1;Integrated Security=SSPI;Persist Security Info=False;User ID=`"`";Initial Catalog=`"`";Data Source=" + $ServerName + ";Initial File Name=`"`";Server SPN=`"`";Authentication=`"`";Access Token=`"`""
   
   Set-Content -Path ($env:temp + "\UDL-Test.udl") -Value $UDL_String -Encoding Unicode
   
   #open the UDL
   Invoke-Expression ($env:temp + "\UDL-Test.udl")
   

5. Verificare se è possibile connettersi a SQL Server da altri sistemi client e account di accesso utente diversi. Se è possibile, il problema potrebbe essere specifico per il client o l'account di accesso che riscontra il problema. Controllare i registri eventi di Windows nel client problematico per altri puntatori. Controllare anche se i driver di rete sono aggiornati.

6. Se si verificano errori di accesso, assicurarsi che esista un account di accesso (entità server) e che disponga CONNECT SQL delle autorizzazioni per SQL Server. Assicurarsi inoltre che il database predefinito assegnato all'account di accesso sia corretto e che l'entità di database mappata disponga CONNECT delle autorizzazioni per il database. Per altre informazioni su come concedere CONNECT autorizzazioni all'entità di database, vedere GRANT Database Permissions. Per altre informazioni su come concedere CONNECT SQL autorizzazioni all'entità server, vedere GRANT Server Permissions. Usare lo script seguente per identificare queste autorizzazioni:

   clear
   ## replace these variables with the login, user, database and server 
   $server_principal = "CONTOSO\JaneK"  
   $database_principal = "JaneK"
   $database_name = "mydb"
   $server_name = "myserver"
   
   Write-Host "`n******* Server Principal (login) permissions *******`n`n"
   sqlcmd -E -S $server_name -Q ("set nocount on; SELECT convert(varchar(32),pr.type_desc) as login_type, convert(varchar(32), pr.name) as login_name, is_disabled,
     convert(varchar(32), isnull (pe.state_desc, 'No permission statements')) AS state_desc, 
     convert(varchar(32), isnull (pe.permission_name, 'No permission statements')) AS permission_name,
     convert(varchar(32), default_database_name) as default_db_name
     FROM sys.server_principals AS pr
     LEFT OUTER JOIN sys.server_permissions AS pe
       ON pr.principal_id = pe.grantee_principal_id
     WHERE is_fixed_role = 0 -- Remove for SQL Server 2008
     and name = '" + $server_principal + "'")
   
   Write-Host "`n******* Database Principal (user) permissions *******`n`n"
   sqlcmd -E -S $server_name -d $database_name -Q ("set nocount on; SELECT convert(varchar(32),pr.type_desc) as user_type, convert(varchar(32),pr.name) as user_name, 
     convert(varchar(32), isnull (pe.state_desc, 'No permission statements')) AS state_desc, 
     convert(varchar(32), isnull (pe.permission_name, 'No permission statements')) AS permission_name 
     FROM sys.database_principals AS pr
     LEFT OUTER JOIN sys.database_permissions AS pe
       ON pr.principal_id = pe.grantee_principal_id
     WHERE pr.is_fixed_role = 0
     and name = '" + $database_principal + "'")
   
   Write-Host "`n******* Server to Database Principal mapping ********`n"
   sqlcmd -E -S $server_name -d $database_name -Q ("exec sp_helplogins '" + $server_principal + "'")
   

7. Se si stanno risolvendo i problemi correlati a Kerberos, è possibile usare gli script in Come determinare se il tipo di autenticazione è Kerberos.

Problemi di connettività comuni

Dopo aver eseguito i prerequisiti e l'elenco di controllo, vedere problemi di connettività comuni e selezionare il messaggio di errore corrispondente per i passaggi dettagliati per la risoluzione dei problemi.