データベース管理者用の診断接続

  • [アーティクル]

SQL Server では、サーバーへの標準の接続が確立できないときに、管理者向けの特殊な診断接続が用意されています。 診断接続を使用することにより、SQL Server が標準の接続要求に応答していない場合でも、管理者は SQL Server にアクセスして診断クエリを実行し、問題のトラブルシューティングを行うことができるようになります。

この DAC (専用管理者接続) では、暗号化やその他の SQL Server のセキュリティ機能がサポートされます。 DAC で実行できるのは、ユーザー コンテキストを別の管理者ユーザーに変更する操作のみです。

SQL Server は DAC の正常な接続を試みますが、極端な状況においては失敗する場合もあります。

DAC による接続

また、既定では、サーバーで実行されているクライアントからしか接続できません。 remote admin connections オプションを指定した sp_configure ストアド プロシージャを使用して構成しない限り、ネットワーク接続は許可されません。

DAC を使用して接続できるのは、SQL Server sysadmin ロールのメンバーのみです。

DAC は、sqlcmd コマンド プロンプト ユーティリティで特殊な管理者スイッチ (-A) を指定することによって使用できます。 sqlcmd の使用方法の詳細については、「sqlcmd でのスクリプト変数の使用」を参照してください。 また、sqlcmd -Sadmin:<instance_name> という形式で、インスタンス名に admin: というプレフィックスを指定することによって接続することもできます。さらに、SQL Server Management Studio クエリ エディターから admin:<instance_name> に接続することによっても DAC を開始できます。

制限事項

DAC の唯一の目的は、ごくまれな状況でサーバーの問題を診断することであるので、この接続には次のようないくつかの制限があります。

  • 接続に使用できるリソースを確保するために、DAC は 1 つの SQL Server のインスタンスにつき 1 つしか許可されません。 DAC 接続が既にアクティブな場合は、DAC を使用して接続する新たな要求は、エラー 17810 で拒否されます。

  • リソースに限りがあるので、SQL Server Express はトレース フラグ 7806 を使用して開始されない限り、DAC ポートでリッスンしません。

  • DAC では、まずログインに関連付けられた既定のデータベースへの接続が試行されます。 既定のデータベースに正常に接続されたら、master データベースに接続できます。 既定のデータベースがオフライン状態であるか、または別の原因で使用できない場合、接続の際にエラー 4060 が返されます。 ただし、代わりに次のコマンドを使用して、既定のデータベースへの接続よりも、master データベースへの接続を優先すると接続に成功します。

    sqlcmd –A –d master

    DAC を使用するときは、master データベースに接続することをお勧めします。これはデータベース エンジンのインスタンスが起動すると master を使用できることが保証されているためです。

  • SQL Server では、DAC で複数のクエリやコマンドを並列実行することは禁止されています。 たとえば、DAC で次のいずれかのステートメントを実行すると、エラー 3637 が生成されます。

    • RESTORE

    • BACKUP

  • DAC では、使用できるリソースが制限されます。 リソースを集中的に消費するクエリ ( 大きなテーブルでの複雑な結合など) や、ブロックされる可能性があるクエリの実行には DAC を使用しないでください。 これは、DAC によって既存のサーバーの問題が悪化するのを防ぐためです。 ブロックする可能性があるクエリを実行しなければならない場合、ブロッキングが発生する状況を回避するには、可能な限りそのクエリをスナップショット ベースの分離レベルで実行します。この分離レベルで実行できない場合は、トランザクションの分離レベルを READ UNCOMMITTED に設定するか、LOCK_TIMEOUT の値を 2,000 ミリ秒などの短い値に設定します。または、両方の設定を行います。 これにより、DAC セッションがブロックされるのを防ぐことができます。 ただし、SQL Server の状態によっては、ラッチで DAC セッションがブロックされることがあります。 Ctrl キーを押しながら C キーを押すことによって、DAC セッションを終了できることもありますが、必ず終了されるわけではありません。 このような場合は、SQL Server の再起動が唯一の選択肢になります。

  • SQL Server では、DAC による接続とトラブルシューティングを確実に行うために、限定されたリソースを確保して DAC で実行されるコマンドを処理します。 通常、次に示す単純な診断関数とトラブルシューティング関数を実行する場合には、この限定されたリソースだけで十分です。

理論上は、DAC で並列に実行する必要のない Transact-SQL ステートメントはすべて実行できますが、次の診断コマンドとトラブルシューティング コマンド以外は使用しないことを強くお勧めします。

  • ロックの状態を確認する sys.dm_tran_locks、キャッシュの正常性をチェックする sys.dm_os_memory_cache_counters、アクティブなセッションと要求を確認する sys.dm_exec_requests および sys.dm_exec_sessions のように、基本的な診断のために動的管理ビューをクエリします。 リソースを集中的に消費する動的管理ビュー (たとえば、sys.dm_tran_version_store ではバージョン ストアの完全なスキャンが実行され、集中的に I/O が行われる可能性があります) や複雑な結合を使用する動的管理ビューは使用しないようにしてください。 パフォーマンスへの影響に関する詳細については、特定の動的管理ビューのリファレンスを参照してください。

  • カタログ ビューのクエリ。

  • DBCC FREEPROCCACHE、DBCC FREESYSTEMCACHE、DBCC DROPCLEANBUFFERS、DBCC SQLPERF などの基本的な DBCC コマンド。 DBCC CHECKDB、DBCC DBREINDEX、DBCC SHRINKDATABASE などのリソースを集中的に消費するコマンドは実行しないでください。

  • Transact-SQL KILL <spid> コマンド。 SQL Server の状態によっては、KILL コマンドは必ずしも成功しません。この場合、SQL Server を再起動するしか方法がありません。 次に一般的なガイドラインをいくつか示します。

    • SELECT * FROM sys.dm_exec_sessions WHERE session_id = <spid> というクエリを実行し、SPID が実際に強制終了されたかどうかを確認します。 行が返されなかった場合は、セッションが強制終了されたことを示します。

    • セッションが依然として確立されている場合は、クエリ SELECT * FROM sys.dm_os_tasks WHERE session_id = <spid> を実行して、このセッションに割り当てられたタスクがあるかどうかを確認します。 タスクが存在する場合は、セッションが現在強制終了中である可能性が高くなります。 この処理には非常に長い時間がかかるため、成功しない場合があることに注意してください。

    • このセッションに関連付けられている sys.dm_os_tasks にタスクが存在しないが、KILL コマンドの実行後に sys.dm_exec_sessions に依然としてセッションが存在する場合は、使用できるワーカーがないことを示します。 現在実行中のタスク (sessions_id <> NULL を指定して sys.dm_os_tasks ビューに一覧されるタスク) のいずれかを選択し、そのタスクに関連付けられているセッションを強制終了して、ワーカーを解放します。 1 つのセッションを強制終了するだけでは不十分で、複数のセッションを強制終了する必要が生じる場合があります。

DAC ポート

SQL Server では、TCP ポート 1434 (使用可能な場合) またはデータベース エンジンの起動時に動的に割り当てられる TCP ポートで DAC をリッスンします。 エラー ログには、DAC がリッスンしているポート番号が含まれています。 既定では、DAC リスナーはローカル ポートでの接続のみを受け入れます。 リモート管理接続をアクティブにするサンプル コードについては、「remote admin connections サーバー構成オプション」を参照してください。

リモート管理接続を構成すると、SQL Server を再起動しなくても DAC リスナーが有効になり、クライアントからリモートで DAC に接続できるようになります。 SQL Server が応答しない場合でも、DAC リスナーを有効にしてリモート接続を受け入れることができます。これを行うには、まず DAC をローカルに使用して SQL Server に接続してから、sp_configure ストアド プロシージャを実行してリモート接続からの接続を受け入れます。

クラスター構成では、DAC は既定でオフになります。 ユーザーは、sp_configure の remote admin connection オプションを実行すると、DAC リスナーを有効にしてリモート接続にアクセスできます。 SQL Server が応答せず、DAC リスナーが有効になっていない場合は、DAC で接続するために SQL Server を再起動する必要が生じる場合があります。 この理由から、クラスター システムでは remote admin connections 構成オプションを有効にすることをお勧めします。

DAC ポートは、起動中に SQL Server によって動的に割り当てられます。 既定のインスタンスに接続する場合、DAC では SQL Server Browser サービスへの SSRP (SQL Server Resolution Protocol) 要求が使用されません。 まず、TCP ポート 1434 経由で接続が試行されます。 接続が失敗した場合、ポートを取得するために SSRP 呼び出しが実行されます。 SQL Server Browser が SSRP 要求をリッスンしていない場合は、接続要求によってエラーが返されます。 DAC がリッスンしているポート番号を確認するには、エラー ログを参照します。 SQL Server がリモート管理接続を受け入れるように構成されている場合、次のように DAC を明示的なポート番号で開始する必要があります。

sqlcmd –Stcp:<server>,<port>

SQL Server のエラー ログには DAC のポート番号が一覧されます。既定のポート番号は 1434 です。 SQL Server がローカルの DAC 接続のみを受け入れるように構成されている場合は、次のコマンドを実行し、ループバック アダプターを使用して接続します。

sqlcmd –S127.0.0.1,1434

使用例

この例では、管理者がサーバー URAN123 が応答していないことに気付き、その問題を診断します。 これを行うには、次のように、ユーザーが sqlcmd コマンド プロンプト ユーティリティをアクティブにし、DAC であることを示す -A を指定して、サーバー URAN123 に接続します。

sqlcmd -S URAN123 -U sa -P <xxx> –A

これで、管理者はクエリを実行して問題を診断し、場合によっては応答していないセッションを終了させることができます。

関連コンテンツ

sqlcmd でのスクリプト変数の使用

sqlcmd ユーティリティ

SELECT (Transact-SQL)

sp_who (Transact-SQL)

sp_lock (Transact-SQL)

KILL (Transact-SQL)

DBCC CHECKALLOC (Transact-SQL)

DBCC CHECKDB (Transact-SQL)

DBCC OPENTRAN (Transact-SQL)

DBCC INPUTBUFFER (Transact-SQL)

サーバー構成オプション

トランザクション関連の動的管理ビューおよび関数 (Transact-SQL)

トレース フラグ (Transact-SQL)