専用 SQL プールでの tempdb エラーのトラブルシューティング

適用対象: Azure Synapse Analytics

専用 SQL プールでは、tempdb データベースは、データ移動 (シャッフル移動、トリミング移動など)、並べ替え、読み込み、メモリ スピル、その他の操作のために一時テーブルと中間領域に使用されます。 さらに、tempdb データベースと対話する 1 つのセッションでコミットされていないトランザクションを実行すると、ログが他のすべてのセッションをフラッシュできず、ログ ファイルがいっぱいになります。 tempdb データベースは共有リソースであるため、tempdb 領域が大量に消費されると、他のユーザーのクエリが失敗し、エスカレートして新しい接続が確立されないようにすることができます。

専用 SQL プールに接続できない場合はどうすればよいですか?

問題のある接続やクエリを特定するための既存の接続がない場合、新しい接続を作成できない問題を解決する唯一の方法は、 一時停止 と 再開、または専用 SQL プールの スケーリング です。 このアクションにより、この問題が発生したユーザー トランザクションが終了し、サービスの再起動時に 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 を満たします。	または INSERT SELECT ステートメントをCTAS複数の小さなトランザクションに分割します。
メモリ割り当てが不十分	(リソース クラスまたはワークロード グループを介して) 割り当てられたメモリが不足しているクエリは、 に tempdbスピルする可能性があります。	より大きな リソース クラス またはより多くのリソースを含む ワークロード グループ を使用してクエリを実行します。
エンド ユーザーの外部テーブル クエリ	外部テーブルに対するクエリは、エンジンがデータを処理する前にファイル全体を読み取る必要があるため、エンド ユーザー クエリには tempdb 最適ではありません。	永続的なテーブルにデータを読み込み、そこでユーザー クエリを送信します。
リソース全体が不足している	高いアクティビティ中に、専用 SQL プールが最大 tempdb 容量に近い場合があります。	上記のいずれかの軽減策と組み合わせて、専用 SQL プールをスケールアップすることを検討してください。

完全な tempdb トランザクション ログ ファイルのトラブルシューティング

通常、tempdb トランザクション ログは、クライアントまたはユーザーが次のいずれかの場合にのみいっぱいになります。

• 明示的なトランザクションを開きますが、 または ROLLBACKをCOMMIT発行することはありません。
• セット IMPLICIT_TRANSACTION = ON (特に AutoCommit 機能を使用する JDBC クライアントとツールの場合)。

手順 1: 未処理のトランザクションを識別する

問題のある接続は、トランザクションが開いているが "アイドル" 状態のクライアントからの接続である可能性があります。 このシナリオを特定するには、次のクエリを実行します。

SELECT *
FROM sys.dm_pdw_exec_sessions
WHERE is_transactional = 1
AND status = 'Idle';

注: このクエリの結果として返されるすべての接続が必ずしも問題になるわけではありません。 実行間隔が 15 分を超えるクエリを少なくとも 2 回実行し、この状態で保持される接続を確認します。

手順 2: 問題を軽減して防止する

開いているトランザクションを保持しているクライアントを特定したら、ユーザーと協力して、次のいずれかまたは両方を変更します。

• ドライバーの構成 (例: JDBC AutoCommit 設定を に off設定 IMPLICIT_TRANSACTIONS = ONします)。
• アドホック クエリの動作 (たとえば、 を使用せずに正しく実行 BEGIN TRAN されていません COMMIT/ROLLBACK)

または、このシナリオを定期的に検出し、潜在的に問題のあるセッションを 強制終了 する自動プロセスを作成することを検討することもできます。

リソース

• DMV sys.dm_pdw_errors に対してエラーのクエリを実行します。