redshift drop 或 truncate table 非常非常慢答案

【问题标题】：redshift drop or truncate table very very slowredshift drop 或 truncate table 非常非常慢
【发布时间】：2013-11-03 06:49:06
【问题描述】：

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

谢谢

【问题讨论】：

能否提供一些其他信息，例如表格宽度、集群设置等？
如果 Gerardo 的回答解决了您的问题，您应该接受它。

标签： amazon-web-services amazon-redshift

【解决方案1】：

我也遇到过同样的问题。原来是从其他地方运行的打开事务。

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

在我在第二个窗口中提交/回滚后，截断工作完美。

希望对您有所帮助。

【讨论】：

【解决方案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(pid)

杀死它

或 KILL'EM ALL 版本：

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

请注意，CANCEL {pid} 不起作用！（查询已取消，但事务仍处于打开状态并处于锁定状态）。

【讨论】：

SELECT pg_terminate_backend(process) FROM STV_SESSIONS where user_name='user_name' and process != pg_backend_pid(); 现在不起作用。它返回INFO: Function "pg_terminate_backend(integer)" not supported. 消息。
@masashimiyazaki, pg_terminate_backend 在从 Redshift 表中选择时不起作用。还有另一条消息表明该函数在 Redshift 表上不可用。获取 pid 列表并将 pg_terminate_backend() 分别应用于每个。也许这种行为自父帖子以来发生了变化。
不能只为 WLM 中的用户查询添加超时吗？

【解决方案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 一个。

【讨论】：

【解决方案4】：

表上的 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>);杀死进程

确保所有只读应用程序关闭并释放所有连接，从而释放这些锁！

【讨论】：

对我来说也是 AccessShareLock 造成了问题。