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所说，锁定不会出现在<?php if($_product->getResource()->getAttribute('autor')->getStoreLabel()): ?> <a><span class="label"><?php echo $_product->getResource()->getAttribute('autor')->getStoreLabel(); ?></span><span class="titles"><?php echo $this->htmlEscape($_product->getData('autor')); ?></span></a> <?php endif ?>表格中，但它们会显示在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。

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完美运行。

希望它有所帮助。

redshift drop或truncate table非常慢

4 个答案: