redshift drop或truncate table非常慢

Question

在我的redshift数据库中删除或截断一个不太大的表(4M行)时,需要很长时间(小时)才能完成.有人遇到同样的问题吗？

谢谢

Answer 1

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(pid)

或者KILL​​'EM ALL版本:

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

注意,CANCEL {pid}没有用!(查询已取消,但事务仍处于打开状态并已锁定).

Answer 2

根据我的经验,正如@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 3

表上的IMO AccessShareLock也会导致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>);

确保所有只读应用程序关闭并释放所有连接,因此锁定!

Answer 4

我遇到了同样的问题.事实证明,打开的交易从其他地方运行.

例如,如果您使用redshift shell打开了2个shell,则无法从第一个shell中删除参与第二个shell中的打开事务的表.

在第二个窗口中提交/回滚后,truncate完美地工作.

希望它有所帮助.