redshift dropまたはtruncate table非常に非常に遅い

Question

私のredshiftデータベースで大きすぎないテーブル（4M行）をドロップまたは切り捨てると、完了するまでに非常に長い時間がかかります。誰も同じ問題を経験していますか？

ありがとうございました

Answer 1

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

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

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

希望しました。

Answer 2

Redshiftは非常に高速なI/Oを備えているため、クラスタの種類やサイズによっては動作時間が1秒未満に抑えられます。 diemachtによると、開いているトランザクションと別の接続があるために問題が発生しています。

私は同様の問題を抱えていました。クライアント上のクラッシュにより、トランザクションは「開かれた」状態ですが、到達不能です。 ませデシベルロックがSTV_LOCKSテーブルの上に現れなかった。また

は、何のクエリがまだ実行しなかった（ 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(process) FROM STV_SESSIONS where user_name='user_name' and process != pg_backend_pid(); 

注：SELECT pg_terminate_backend(pid)

またはKILL'EMをALLバージョン：それは使用を殺しますは機能しませんでした！ （クエリはキャンセルされましたが、トランザクションはまだ開いていてロックされていました）。

Answer 3

私の経験では、@ 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ロックです。多くのロックがリストされている場合は、ACCESS EXCLUSIVEを見つけて削除してください。

Answer 4

IMO AccessShareLock on tableはまた、DDLコマンドが停止する原因となります。

を実行し、このクエリAccessShareLock

のPIDを把握するために

select 
    current_time, 
    c.relname, 
    l.database, 
    l.transaction, 
    l.pid, 
    a.usename, 
    l.mode, 
    l.granted 
from pg_locks l 
join pg_catalog.pg_class c ON c.oid = l.relation 
join pg_catalog.pg_stat_activity a ON a.procpid = l.pid 
where l.pid <> pg_backend_pid(); 

キルselect pg_terminate_backend(<pid>);

を使用するプロセスは、すべての接続、したがって、これらのロック、すべての読み取り専用のアプリケーションを閉じて解放していることを確認してください！