1

本番環境では、この問題に直面しています。

deleteの実行に時間がかかり、最終的に の SQL エラーをスローする があります-243。
を使用してクエリを取得しましたonstat -g。

これほど時間がかかり、最終的にエラーになる原因を突き止める方法はありますか?

COMMITTED READアイソレーションを使用しています。

これにより、Informix の CPU 使用率も高くなります。

編集

環境- Solaris 上の Informix 9.2

インデックスやアプリケーション ロジックに関連する問題は見当たりませんが、informix の破損が疑われます。
このDELETEクエリの実行中、セッションは異なるテーブルで 8 つのロックを保持します。
しかし、実行されたテーブルにロックが表示されませんdelete。

Informix がテーブルのロックを取得できないようなものでしょうか?

4

2 に答える 2

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;

そこにはいくつかの構文の問題がありますが、それはあなたにとって良い出発点です. 挿入と更新は、論理ログを使用するほど遅くなることに注意してください。

于 2013-03-07T05:37:05.807 に答える
0

Informix は何度も不用意に再起動されたため、informix が不安定になりました。
これが根本原因でした。

于 2013-04-04T07:31:26.800 に答える