次の方法で共有

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

  • [アーティクル]

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

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

SQL Server は DAC の正常な接続を試みますが、極端な状況においては失敗する場合もあります。
適用対象: SQL Server (SQL Server 2008 から現在 バージョン)、SQL Database V12。

DAC による接続

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

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

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

制限

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

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

  • リソースを節約するために、トレース フラグ 7806 で開始されない限り、SQL Server Express は DAC ポートでリッスンしません。

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

    sqlcmd -A -d master

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

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

    • RESTORE

    • BACKUP

  • DAC では、使用できるリソースが制限されます。 DAC を使用して、リソースを大量に消費するクエリ (大規模なテーブルでの複雑な結合など) やブロックする可能性のあるクエリを実行しないでください。 これは、DAC によって既存のサーバーの問題が悪化するのを防ぐためです。 ブロックする可能性があるクエリを実行しなければならない場合、ブロッキングが発生する状況を回避するには、可能な限りそのクエリをスナップショット ベースの分離レベルで実行します。この分離レベルで実行できない場合は、トランザクションの分離レベルを READ UNCOMMITTED に設定するか、LOCK_TIMEOUT の値を 2,000 ミリ秒などの短い値に設定します。または、両方の設定を行います。 これにより、DAC セッションがブロックされるのを防ぐことができます。 ただし、 SQL Server の状態によっては、ラッチで DAC セッションがブロックされることがあります。 Ctrl</localizedText> キーを押しながら <localizedText>C</localizedText> キーを押すことによって、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 にリモートで接続できるようになります。 最初に DAC をローカルで使用して SQL Server に接続し、次に sp_configure ストアド プロシージャを実行してリモート接続からの接続を受け入れることで、SQL Server が応答しない場合でも、DAC リスナーがリモートで接続を受け入れるようにすることができます。

クラスター構成では、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 であることを示す URAN123 を指定して、サーバー -A に接続します。

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

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

関連コンテンツ

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

sqlcmd Utility

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)

サーバー構成オプション (SQL Server)

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

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