専用 SQL プールの tempdb エラーのトラブルシューティング
適用対象:Azure Synapse Analytics
専用 SQL プールでは、tempdb データベースは、データ移動 (シャッフル移動、トリム移動など)、並べ替え、読み込み、メモリ スピル、その他の操作のために一時テーブルと中間領域に使用されます。 さらに、tempdb データベースと対話する 1 つのセッションでコミットされていないトランザクションを実行すると、ログが他のすべてのセッションをフラッシュしなくなり、ログ ファイルがいっぱいになります。 tempdb データベースは共有リソースであるため、tempdb 領域を大量に使用すると、他のユーザーのクエリが失敗し、エスカレートして新しい接続が確立されないようにすることができます。
専用 SQL プールに接続できない場合はどうすればよいですか?
問題のある接続やクエリを特定するための既存の接続がない場合、新しい接続を作成できないことを解決する唯一の方法は、専用 SQL プール Pause および Resume または Scale です。 このアクションにより、この問題の原因となったユーザー トランザクションが終了し、サービスの再起動時に tempdb データベースが再作成されます。
注: 一時停止操作とスケール操作は、このシナリオで完了するまでに通常よりも時間がかかる可能性があるため、実行中のすべてのトランザクションを元に戻す時間をサービスに追加してください。
完全な tempdb データ ファイルのトラブルシューティング
手順 1: tempdb データベースがいっぱいになるクエリを特定する
ETL フレームワークにログ コンポーネントを実装したり、専用 SQL プール ステートメントを監査したりしていない限り、クエリの実行中に tempdb データベースがいっぱいになるクエリを特定してください。 ほとんどの場合、問題が発生した期間に実行される実行時間が最も長いクエリは、tempdb の領域不足エラーの原因です。 実行時間の長いクエリの一覧を取得するには、次のクエリを実行します。
SELECT TOP 5 *
FROM sys.dm_pdw_exec_requests
WHERE status = 'running'
ORDER BY total_elapsed_time desc;
合理的に疑わしいクエリを作成したら、次のいずれかのオプションを試してください。
- ステートメントを強制終了 します。
- 長いランナーが完了できるように、他のワークロードが tempdb 領域をさらに消費しないようにします。
手順 2: 繰り返しを防ぐ
責任あるクエリを特定してアクションを実行したら、問題が繰り返されないように軽減策を実装することを検討してください。 次の表は、tempdb の完全なエラーの最も一般的な原因の軽減策を示しています。
| 原因 | 説明 | 対応策 |
|---|---|---|
| 不適切な分散プラン | 特定のクエリに対して生成された分散プランでは、テーブル統計の保守が不十分な結果として、頻度の高いデータ移動が誤って発生する可能性があります。 | 関連するテーブルの統計 を更新し、定期的なスケジュールに従って維持されるようにします。 |
| クラスター化列ストア インデックス (CCI) 正常性の悪化 | メモリのスピルにより tempdb 領域が消費されます。 | CCI を再構築し 定期的なスケジュールに従って保持されるようにします。 |
| 大規模なトランザクション | 大量の CREATE TABLE AS SELECT (CTAS) または INSERT SELECT ステートメントが、データ移動操作中に tempdb を満たします。 |
CTAS または INSERT SELECT ステートメントを、複数の小さなトランザクションに分割します。 |
| メモリ割り当てが不十分 | (リソース クラスまたはワークロード グループを介して) 割り当てられたメモリが不足しているクエリは、 tempdbにスピルする可能性があります。 |
より大きなリソースを持つリソース クラスまたはワークロード グループを使用してクエリを実行します。 |
| エンド ユーザーの外部テーブル クエリ | 外部テーブルに対するクエリは、エンジンがデータを処理する前にファイル全体を tempdb に読み取る必要があるため、エンドユーザーのクエリには最適ではありません。 |
永続的なテーブルにデータを読み込み、ユーザー クエリをそこに送信します。 |
| 全体的なリソースが不十分 | 高いアクティビティ中に、専用 SQL プールが最大 tempdb 容量に近い場合があります。 | 上記のいずれかの軽減策と組み合わせて、専用 SQL プールをスケールアップすることを検討してください。 |
完全な tempdb トランザクション ログ ファイルのトラブルシューティング
通常、tempdb トランザクション ログは、クライアント/ユーザーが次のいずれかの場合にのみいっぱいになります。
- 明示的なトランザクションを開きますが、
COMMITやROLLBACKを発行することはありません。 IMPLICIT_TRANSACTION = ONを設定します (特に、AutoCommit 機能を使用する JDBC クライアントとツールの場合)。
手順 1: 開いているトランザクションを識別する
問題のある接続は、トランザクションが開いているが"アイドル状態" になっているクライアントからの接続である可能性があります。 このシナリオを特定するには、次のクエリを実行します。
SELECT *
FROM sys.dm_pdw_exec_sessions
WHERE is_transactional = 1
AND status = 'Idle';
注: このクエリの結果として返されるすべての接続が必ずしも問題になるわけではありません。 実行の間に 15 分を超えるクエリを少なくとも 2 回実行し、この状態で保持される接続を確認します。
手順 2: 問題を軽減して防止する
開いているトランザクションを保持しているクライアントを特定した後、ユーザーと協力して、いずれかまたは両方を変更します。
- ドライバーの構成 (例:
IMPLICIT_TRANSACTIONS = ONを設定するoffへの JDBC AutoCommit 設定) - アドホック クエリの動作 (たとえば、
COMMIT/ROLLBACKなしでBEGIN TRANが正しく実行されない)
または、このシナリオを定期的に検出し、潜在的に問題のあるセッションをする自動化されたプロセスを作成することを検討できます。
リソース
- DMV sys.dm_pdw_errors で、エラーのクエリを実行します。