lbi File Growing Like Mad - how to diagnose - Forum - OpenEdge RDBMS - Progress Community

lbi File Growing Like Mad - how to diagnose


lbi File Growing Like Mad - how to diagnose

This question has suggested answer(s)

Yesterday & today, I am plagued with an lbi file that is growing and filling the hard disk. The code base has been stable, so it must be something in the current data that is looping, calling recursively, etc.

Is there any way to tell what process/user/program is associated with a given lbi file? I'm running with -t so the lbi files are visible, but all of them are owned by root. I did a "strings lbixxx |pg" on the big one and saw some program names in all caps, and a few lines of report output, but they did not lead me to a smoking gun yet.

Any advice?  ProTop to the rescue ??

This is 11.7.1 on RHEL. Thx in advance --

(And yes, this is urgent!)

All Replies
  • ProTop might be able to rescue you in that the user who is doing this is probably a pretty active user and is likely at or near the top of the "User IO Activity" screen.  And you could enable the client statement cache (perhaps for just one user) to see what such a user is doing.

    However... that assumes that the user is actually doing stuff with the db.  And they might not be.  So what you really want to do is to run:

    sudo fuser filename

    This will give you a list of process ids that have that file open.  Since it is an LBI file I expect that there will only be a single PID.

    The next thing to do would be to get a 4gl stack trace with:

    proGetStack <pidFromAbove>

    Tom Bascom

  • Examples:

    28828 ls -l --time-style=full-iso lbitaoXQc 
    -rw-r--r--. 1 root root 0 2019-11-20 20:04:21.612734866 +0300 lbitaoXQc
    28828 tail -2 sports.lg
    [2019/11/20@20:04:03.811+0300] P-28275      T-140480595711808 I ABL     5: (452)   Login by root on /dev/pts/5. 
    [2019/11/20@20:04:21.618+0300] P-28748      T-140480595711808 I ABL     5: (7129)  Usr 5 set name to root. 

    Timestamps: 20:04:21 (wrong example, see below )


    $ fuser lbitaoXQc
    lbitaoXQc: 28748


    $ lsof lbitaoXQc 
    _progres 28748 root    5u   REG    8,2        0 416428 lbitaoXQc

    Update: Example with 'ls' command is wrong: the common filesystems used in Linux don't store the creation time. But the ext4 file system does store it: stat -c %W lbi*

  • lbi is created by vars and TTs which have defaulted to "undo" instead of having  a 'no-undo' phrase added.

    If you have "undo" elements in your code and the structure of the data you're processing has changed, that could be the cause of this "all of the sudden".

  • KB on lbi:

    In addition to "undo" vars and TTs, lbi is also used for subtransactions:

    Only subtransactions (a transaction block nested within another transaction block) and UNDO objects (variables and temp tables) are written to the ABL client local-before-image (lbi) file.