Question

在制作中，我遇到了这个问题。

有一个delete需要很长时间才能执行，并最终导致-243的SQL错误。
我使用onstat -g获得了查询。

有没有办法找出导致它花费这么多时间的原因并最终出错？

它使用COMMITTED READ隔离。

这也导致了高Informix cpu使用率。

编辑

环境 - Solaris上的Informix 9.2

我没有看到任何与索引或应用程序逻辑相关的问题，但我怀疑某些informix损坏在执行此DELETE查询时，会话在不同的表上保留8个锁但是，我没有看到执行delete的表上有任何锁定。

是不是就像，informix无法锁定桌面？

Answer 1

DELETE不关心你的隔离级别。您正在获得243，因为在您尝试运行删除操作时，另一个进程正在锁定表。

我会将您的删除放入SP并提交每个第X条记录：

CREATE PROCEDURE tmp_delete_sp (
  p_commit_records INTEGER
) 
RETURNING 
  INTEGER, 
  VARCHAR(64);

DEFINE l_current_count INTEGER;

SET LOCK MODE TO WAIT 5; -- Wait 5 seconds if another process is locking the table.

BEGIN WORK;

FOREACH WITH HOLD
  SELECT .....

  DELETE FROM table WHERE ref = ^^ Ref from above;

  LET l_current_count = l_current_count + 1;

  IF (l_current_count >= p_commit_records) THEN
     COMMIT WORK;
     BEGIN WORK;
     LET l_current_count = 0;
  END IF;

END FOREACH;

COMMIT WORK;

RETURN 0, 'Deleted records';
END PROCEDURE;

那里有一些语法问题，但它对你来说是一个很好的起点。请记住，当您使用更多逻辑日志时，插入和更新会逐渐变慢。

Answer 2

Informix被多次重新启动，导致informix不稳定这是根本原因。

Informix DELETE查询需要很长时间

2 个答案: