何も変更されていないのに、Amazon Redshift のクエリステータスが「完了」から「中止」に変わったのはなぜですか?

簡単な説明

データを操作したりデータベースオブジェクトを作成したりする SQL ステートメントは、トランザクションがコミットされるまで存続しません。これは、暗黙的に COMMIT を実行する TRUNCATE ステートメントには当てはまりません。

Amazon Redshift コンソールには、SQL ステートメントがまだオープントランザクションにある場合、そのクエリのステータスが「Completed」と表示されます。トランザクションがロールバックされると、ステータスが「中止」に変わります。STL_QUERY システムテーブルには、中止された列の値が 0 のときに SQL ステートメントが正常に完了したことも示されています。

トランザクションが後でコミットされると、変更が表示されます。ただし、トランザクションをコミットできない場合、Amazon Redshift コンソールにはクエリが中止されたことが表示されます。トランザクションをコミットできない理由を特定するには、STL システムテーブルを確認してください。

解決策

トランザクションがコミットされたかロールバックされたかを確認するには、SVL_STATEMENTTEXT システムテーブルで次のクエリの出力を使用します。次に、SQL ステートメントのトランザクション ID (xid) でフィルタリングします。

SELECT *
FROM SVL_STATEMENTTEXT
WHERE xid IN (SELECT xid FROM STL_QUERY WHERE query = [Query ID]) ORDER BY starttime, sequence;

クエリの出力には、ロールバックされたトランザクションの「Undoing 1 transaction」ステートメントが表示されます。

トランザクションが BEGIN ステートメントで始まる場合、そのステートメントはユーザーまたはアプリケーションによって明示的に開かれたものです。ステートメントも明示的にコミットする必要があります。BEGIN ステートメントで開始されていないトランザクションは、通常、SQL クライアントまたはドライバーの AUTO COMMIT オプションによって自動的にコミットされます。このオプションが無効になっている場合、ユーザーは明示的に COMMIT を送信する必要があります。

トランザクションが適切にコミットされると、トランザクションの変更は永続的 (永続的) になり、COMMIT ステートメントの後に開始された他の XID からも確認できます。詳細については、「シリアル化可能な分離」を参照してください。

SVL_STATEMENTTEXT システムテーブルに END、COMMIT、または「1 件のトランザクションを取り消しています」というメッセージが表示されない場合は、XID がまだ開いている可能性があります。SVV_TRANSACTIONS ビューを使用して、開いているトランザクションと LOCK 競合を識別します。

システムテーブル STL_COMMIT_STATS と STL_UNDONE を使用して、トランザクションが COMMIT または ROLLBACK のどちらで終了したかを確認することもできます。

次のクエリを実行して、変更がコミットされたかどうかを確認します。

SELECT q.query, q.xid, NVL2 (cs.endtime, cs.endtime::text, 'NO COMMIT') AS commit_endtime
FROM STL_QUERY q LEFT JOIN STL_COMMIT_STATS cs ON q.xid = cs.xid AND cs.node = -1
WHERE q.query = [QUERY ID];

次のクエリを実行して、変更がロールバックされたかどうかを確認します。

SELECT *
FROM STL_UNDONE
WHERE xact_id_undone IN (SELECT xid from STL_QUERY where query = [QUERY ID]);

明示的な ROLLBACK コマンドが原因で、または完了するまで実行されない場合、トランザクションの変更は保持されません。シリアライズ可能な分離違反がある場合、明示的なロールバックは発生しません。また、管理者がセッションを終了したり、クエリをキャンセルしたりした場合も発生しません。ネットワーク接続でタイムアウトが発生すると、トランザクションの変更が持続しなくなることもあります。

ロールバックが発生すると、クライアントは詳細を記載したエラーメッセージを受け取ります。エラーをログするようにクライアントを設定するのがベストプラクティスです。詳細については、「ロギングの設定 (JDBC)」または「ログレベル (ODBC)」を参照してください。

関連情報

STL_DDLTEXT