Bug in IDS 11+ sysadmin:alertcleanup function fix

Updated June 2020

Fixed in IDS 12.10.xC6 and 14.10: https://www.ibm.com/support/pages/apar/IT09329

Abstract

Bug in IDS 11: This article describes a bug in a function provided with IBM Informix Dynamic Server (IDS) which could result in disk space being filled. We have reported this to IBM who have assigned defect number (APAR) IT09329. Meanwhile, you can fix your system using code provided below.

Content

An internal scheduler (sometimes known as “dbcron”) was introduced in IDS version 11. With the Open Admin Tool, you can enable or disable scheduled tasks and view the results of previous executions. The scheduler and many tasks are enabled by default, with relevant tables and functions being stored in the “sysadmin” database. Every time a task runs, a row is inserted into one or both of the “ph_alert” and “ph_run” tables. Every day, a Stored Procedure Language (SPL) function is run to clear rows older than a defined number of days (default 30) from these tables, but it leaves rows behind that do not have a matching pair in both. On some systems with rapid execution of custom tasks, this can result in a very large table filling the dbspace (rootdbs by default).

The standard code from 12.10.FC4 (almost unchanged since 11.10) is:

Copy to Clipboard

The suggested fix is:

Copy to Clipboard

DROP FUNCTION AlertCleanup;

CREATE FUNCTION AlertCleanup
    (task_id INTEGER DEFAULT 0, seq_id INTEGER DEFAULT 0)
    RETURNING INTEGER AS rows_processed

-- Rewrite of standard IDS 11+ sysadmin function but with:

-- 1) tables processed independently (not always paired)
    -- 2) transactions of 1000 rows per commit (faster)

-- Doug Lawry, Oninit Consulting, June 2015

DEFINE threshold DATE;
    DEFINE counter INTEGER;
    DEFINE row_id INTEGER;

SELECT current - value::INTERVAL DAY to SECOND
    INTO threshold
    FROM ph_threshold
    WHERE name = 'ALERT HISTORY RETENTION';

LET counter = 0;

BEGIN WORK;

FOREACH cursor_1 WITH HOLD FOR
        SELECT ROWID
        INTO row_id
        FROM ph_alert
        WHERE alert_time < threshold

DELETE FROM ph_alert
        WHERE CURRENT OF cursor_1;

LET counter = counter + 1;

IF MOD(counter, 1000) = 0 THEN
            COMMIT WORK;
            BEGIN WORK;
        END IF

END FOREACH

COMMIT WORK;

BEGIN WORK;

FOREACH cursor_2 WITH HOLD FOR
        SELECT ROWID
        INTO row_id
        FROM ph_run
        WHERE run_time < threshold

DELETE FROM ph_run
        WHERE CURRENT OF cursor_2;

LET counter = counter + 1;

IF MOD(counter, 1000) = 0 THEN
            COMMIT WORK;
            BEGIN WORK;
        END IF

END FOREACH

COMMIT WORK;

RETURN counter;

END FUNCTION;

Conclusion

Run the above SQL as “informix” in the “sysadmin” database on IDS 11 or 12 to avoid accumulating unwanted data. This should fix the bug in IDS 11.

Disclaimer

The code fix suggested above is provided “as is” without warranty of any kind, either express or implied, including without limitation any implied warranties of condition, uninterrupted use, merchantability, fitness for a particular purpose, or non-infringement.