2013-03-07 304 views
1

在生产中,我面临着这个问题。Informix DELETE查询需要很长时间

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

有什么方法可以找出是什么导致它花费这么多时间,最后出错?

它使用COMMITTED READ隔离。

这也导致了很高的Informix CPU使用率。

编辑

环境 - 在Solaris

我没有看到相关的索引或应用程序逻辑的任何问题,但我怀疑一些Informix的腐败的Informix 9.2。
在执行此DELETE查询时,会话在不同的表上保存8个锁。
但是,我没有看到delete执行表上的任何锁。

会是这样吗,informix无法锁定表格?

+0

您是否试过将'DELETE FROM TABLE WHERE ...'作为'SELECT * FROM Table WHERE ...'(适用于所有列的任何合适的子集)并查看了查询计划?这个工作有多快?表格是否具有斑点列或智能斑点列? DELETE的查询计划是什么?它如何与SELECT计划进行比较?是否有索引缺失可以加快速度?桌上有多少个索引?有那么多的减少索引的数量会提高性能?哪个版本的Informix?在哪个平台上运行? – 2013-03-07 19:30:09

+0

表在2列上具有组索引,删除也基于该2列。 – cppcoder 2013-03-08 07:31:53

回答

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; 

一些语法问题存在,但它是你一个很好的起点块。请记住,随着您使用更多逻辑日志,插入和更新的速度会逐渐变慢。

0

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