トラブルシューティングタスク¶

このセクションでは、期待どおりに実行されないタスクをトラブルシューティングするための体系的なアプローチについて説明します。

このトピックの内容：

タスクが実行されなかった¶

ステップ1: タスクが実行されなかったことを確認する¶

TASK_HISTORY テーブル関数をクエリして、タスクが実行されなかったことを確認します。タスクは正常に実行されたが、タスク定義の SQL ステートメントが失敗した可能性もあります。特に、スケジュールされた時間と完了した時間、およびエラーコードとメッセージに注意してください。

タスクに先行タスクがある場合（タスクグラフ内）、先行タスクが正常に完了したかどうかを確認します。

ステップ2: タスクが再開されたことを確認する¶

タスク（またはタスクグラフ内の各タスク）の状態が RESUMED であることを確認します（ DESCRIBE TASK または SHOW TASKS を使用）。

個々のタスクを再開するには、 ALTER TASK ... RESUME を実行します。ルートタスクに関連付けられたすべての依存タスクを再帰的に有効にするには、各タスクを個別に有効にするのではなく、 SYSTEM$TASK_DEPENDENTS_ENABLE 関数をクエリします。

タスクの詳細を確認しているときに、タスクにスケジュールがある場合は、cron式も確認してください。スケジュールされた時間の少なくとも1つが経過したことを確認します。

ステップ3: タスクの所有者に付与された権限を確認する¶

タスクの所有者（つまり、タスクに対してOWNERSHIP権限を持つロール）が、タスクの実行に必要な次の権限を持っていることを確認します。

オブジェクト	権限	注意
アカウント	EXECUTE TASK	ロールが所有するタスクを実行するために必要です。ロールの EXECUTE TASK 権限を取り消すと、以降のすべてのタスクの実行はそのロールで開始できなくなります。
データベース	USAGE
スキーマ	USAGE
タスク	OWNERSHIP
ウェアハウス	USAGE

SHOW GRANTS TO ROLE role_name を使用して、ロールに付与されている権限を確認します。

ステップ4: 条件を確認する¶

タスクに SYSTEM$STREAM_HAS_DATA 条件の WHEN 句が含まれる場合は、指定されたストリームに、タスクの実行が最後にスケジュールされたときに変更データキャプチャ（CDC）記録が含まれていることを確認します。ストリームの履歴データは、 AT | BEFORE 句を使用してクエリできます。

タスクがタイムアウトしたか、スケジュールウィンドウを超過した¶

タスクの1回の実行には、60分のデフォルトの制限があります。この制限は、終了しないタスクに対する保護手段として実装されました。 TASK_HISTORY テーブル関数をクエリします。タスクがキャンセルされたか、タスクにスケジュールされたウィンドウを超えた場合、原因のほとんどはウェアハウスが小さすぎることです。ウェアハウスのサイズを確認して、スケジュールウィンドウまたは1時間の制限内に収まるようにサイズを増やすことを検討します。

または、 ALTER TASK ... SET USER_TASK_TIMEOUT_MS = <数> を実行して、タスクのタイムアウトの制限を増やすことを検討します。USER_TASK_TIMEOUT_MS パラメーターが特定のタスクに設定されているかどうかを判別するには、次のステートメントを実行します。

SHOW PARAMETERS LIKE 'USER_TASK_TIMEOUT_MS' IN TASK <task_name>;

Copy

ここで、 <タスク名> は、タイムアウト制限を調整しているタスクの名前です。ステートメントが記録を返さない場合、タスクには現在、デフォルトの 3600000 ミリ秒（60分）のタイムアウトがあります。

クエリの並列化に問題がある場合は、ウェアハウスのサイズを増やしたり、タイムアウト制限を増やしたりしても効果がない可能性があることに注意してください。タスクによって実行される SQL ステートメントを書き換える別の方法を検討してください。