51

Redshift データベースであまり大きくないテーブル (4M 行) を削除または切り捨てると、完了するまでに非常に長い (数時間) かかります。誰も同じ問題を経験していますか?

ありがとう

4

4 に答える 4

77

Redshift は非常に高速な I/O を備えているため、クラスターのタイプやサイズに関係なく、操作にかかる時間は 1 秒未満です。diemacht が言ったように、この問題は、開いているトランザクションとの別の接続があるために発生します。

同様の問題がありました。クライアントでのクラッシュにより、トランザクションが「開いた」ままになりましたが、到達できませんでした。STV_LOCKS テーブルに db ロックが表示されませんでした: (使用select table_id, last_update, lock_owner, lock_owner_pid from stv_locks;)

また、クエリはまだ実行されていませんでした: (でチェック: select pid, trim(user_name), starttime, query , substring(query,1,20), status from stv_recents where status='Running';)

したがって、解決策はユーザーセッションをリストすることでした:SELECT * FROM STV_SESSIONS そして、次を使用してそれを強制終了します:SELECT pg_terminate_backend(pid)

またはKILL'EM ALLバージョン：

SELECT pg_terminate_backend(process) FROM STV_SESSIONS where user_name='user_name' and process != pg_backend_pid();

CANCEL {pid}うまくいかなかったことに注意してください！(クエリはキャンセルされましたが、トランザクションはまだ開いていてロックされていました)。

于 2014-06-17T15:10:36.627 に答える
41

私の経験では、@Gerardo Grignoli が言うように、ロックはstv_locksテーブルに表示されませんが、pg_locks. 環境によっては、 にリストされている任意の長時間実行セッションを強制終了することが受け入れられない場合がありますstv_sessions。pg_locksこのタイプのロックを検出するには、テーブルが非常に信頼できることがわかりました。

select * from pg_locks where relation = (select oid from pg_class where relname = 'the_table')
select pg_cancel_backend(pid)

通常、問題はACCESS EXCLUSIVEテーブルをデッドロックしているロックです。そのため、多数のロックがリストされている場合は、1 つを見つけて削除しACCESS EXCLUSIVEます。

于 2015-12-22T00:20:36.477 に答える
6

私は同じ問題を経験しました。他の場所から実行されたトランザクションが開かれていることが判明しました。

たとえば、redshift シェルで 2 つのシェルを開いている場合、2 番目のシェルで開いているトランザクションに参加する最初のシェルからテーブルを削除することはできません。

2番目のウィンドウでコミット/ロールバックした後、切り捨ては完全に機能しました。

それが役に立ったことを願っています。

于 2013-11-20T14:16:37.733 に答える