SQL Server 接続の問題をトラブルシューティングするための推奨される前提条件とチェックリスト

適用対象: SQL Server
元の KB 番号: 4009936

推奨される前提条件

接続の問題を効果的にトラブルシューティングするには、次の情報を収集します。

• エラー メッセージとエラー コードのテキスト。 エラーが断続的 (場合によっては発生のみ) か、一貫性があるか (常に発生する) かどうかを確認します。

• SQL Server とクライアント システムからのアプリケーションおよびシステム イベント ログ。 これらのログは、SQL Server でシステム全体の問題が発生しているかどうかを確認するのに役立ちます。

• アプリケーションからの接続が失敗している場合は、アプリケーションから接続文字列を収集します。 これらの文字列は、通常、ASP.NET アプリケーションの Web.config ファイルにあります。

• SQL Server エラー ログを収集し、他のエラー メッセージと例外を確認します。

• SQL Server コンピューターへの管理者アクセス権がある場合は、次の手順に従って、現在のコンピューター設定とサービス アカウントを収集して確認します。

  1. 最新バージョンの SQLCHECK をダウンロードします。

  2. ダウンロードしたファイルをフォルダー ( C:\Temp など) に解凍します。

  3. 管理者としてコマンド プロンプトを実行してデータを収集し、ファイルに保存します。 例: SQLCHECK > C:\Temp\server01.SQLCHECK.TXT。

  注:

  リモート クライアントからの接続の問題のトラブルシューティングやリンク サーバー クエリのトラブルシューティングを行う場合は、関係するすべてのシステムで SQLCHECK ツールを実行します。

接続の問題をトラブルシューティングするためのクイック チェックリスト

オプション 1

「 推奨される前提条件 」セクションで説明されている SQLCHECK ツールの出力にアクセスし、出力ファイル (コンピューター、クライアント セキュリティ、および SQL Server) のさまざまなセクションの情報を確認できる場合は、この情報を使用して問題の原因となる問題に対処します。 次の例を参照してください。

オプション 2

SQL Server コンピューターで SQLCHECK を実行できない場合は、詳細なトラブルシューティングを行う前に、次の項目を確認できます。

1. SQL Server が起動されていること、および SQL Server エラー ログに次のメッセージが表示されていることを確認します。

   これで、SQL Server でクライアント接続の準備ができました。 これは情報メッセージです。ユーザーアクションは必要ありません。

   PowerShell で次のコマンドを使用して、システム上の SQL Server サービスの状態を確認します。

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

   次のコマンドを使用して、エラー ログ ファイルで特定の文字列 "SQL Server はクライアント接続の準備ができました。 This is an informational message; no user action is required." (SQL Server はクライアント接続の準備ができました。これは情報メッセージです。ユーザー 操作は必要ありません。) という文字列を検索します。

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

2. IP アドレス経由の基本的な接続を確認し、異常がないか確認します。 ping -a <SQL Server machine>, ping -a <SQL Server IP address> 問題が発生した場合は、ネットワーク管理者と協力してください。 または、PowerShell でを使用 Test-NetConnection することもできます。

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

3. エラー ログを確認して、SQL Server が適切なプロトコルでリッスンしているかどうかを確認します。

    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. UDL ファイルを使用して SQL Server に接続できるかどうかを確認します。 動作する場合は、接続文字列に問題がある可能性があります。 UDL テスト手順の手順については、「 UDL ファイルを使用して SQL Server への OLE DB 接続をテストする」を参照してください。 または、次のスクリプトを使用して 、UDL-Test.udl ファイル ( %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. 他のクライアント システムと異なるユーザー ログインから SQL Server に接続できるかどうかを確認します。 可能であれば、問題が発生しているクライアントまたはログインに固有の問題である可能性があります。 問題のあるクライアントの Windows イベント ログで、より多くのポインターを確認します。 また、ネットワーク ドライバーが最新の状態であるかどうかを確認します。

6. ログインエラーが発生している場合は、ログイン (サーバー プリンシパル) が存在し、 CONNECT SQL SQL Server へのアクセス許可があることを確認してください。 さらに、ログインに割り当てられている既定のデータベースが正しいことを確認し、マップされたデータベース プリンシパル CONNECT にデータベースへのアクセス許可があることを確認します。 データベース プリンシパルにアクセス許可を付与 CONNECT する方法の詳細については、「 GRANT Database Permissions」を参照してください。 サーバー プリンシパルにアクセス許可を付与 CONNECT SQL する方法の詳細については、「 GRANT Server Permissions」を参照してください。 これらのアクセス許可を特定するには、次のスクリプトを使用します。

   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. Kerberos 関連の問題をトラブルシューティングする場合は、「 認証の種類が Kerberos かどうかを判断する方法」のスクリプトを使用できます。

一般的な接続の問題

前提条件とチェックリストを確認したら、 一般的な接続の問題 に関するページを参照し、対応するエラー メッセージを選択して、トラブルシューティングの詳細な手順を確認してください。