Log File - Force Abort

> Version: Ingres 6.4/05
> O/S:  Unix (DRS)
> 
> We are experiencing a problem when the log file reaches the log force
> abort limit and just freezes. No activity can continue until either
> Ingres or one of the slaves is killed. When this happens the log file
> then rollsback the transaction and appears to be ok from that point on.
> There are no messages in the errlog.log file to indicate what has caused
> the freeze.
> Has anyone had a similar experience with the log file when it reaches
> the force abort log limit?
> 
> Any suggestions appreciated.
> 
> Andrew Parsons
> 


Hi Andrew,

    Unfortunatly I have far too much experience of LOG File Force Aborts ditto
    Log full aborts.

    However I've never had to shutdown Ingres or kill a slave to get the
    archiver to drain the log file. In fact the thought of killing a slave
    process ie your disk i/o gives me the creeps! Even shutting down is not
    advisable as until the log is drained you arent coming up again! 
    
    I suspect you may be doing this because of the perceived lack of performance
    from the archiver process. Note that I said 'perceived'. You can confirm
    that the archiver is up by checking the status line of the logging system
    either through IPM or by examination of Logstat output. I reccomend the
    former over the latter! If the word ARCHIVE is listed then the Archiver is
    up and running. 

    However, The Archiver process is just another process and has to compete
    for resources on your host like any other. If all you've hit is the FAL
    then only the oldest open transaction is rolled back and new transactions 
    are permitted. Hence the Archiver is busy draining records off one end of
    the log file while your users are just as busy filling the other end up!

    If your Log file is large and your FAL is high then the amount of work the
    archiver has to do is enormous. I'll expalin more later. Suffice it to say
    here that the best advice is to tell your users to bugger off until the
    %Log in use comes down to some reasonable level (say 1/3 of FAL). 
    Alternativly ask them to limit their work to look only.

    Furthermore, It is worth your while automating a check of the %Log file in
    use and sounding an alarm at the 1/3 level.

    You could also think of setting FAL down to a much lower value. On one
    platform we had with over 200 databases we found that Ingres would go
    belly up and corrupt the log file if the Archiver got a tad to busy to
    handle the situation. Hence on that machine we set FAL to 30% compared to
    the 94% we normally run with.

    You could also ensure the Archiver is invoked more regularly to minimise
    the problem. I think the standard installation invokes the archiver on 5%
    of the log file. I prefer to invoke the Archiver on every 1% myself.

    Another way of monitoring the Archivers process is to execute 
        tail -f $II_SYSTEM/ingres/files/II_ACP.LOG
    This will demonstrate the way the archiver works quite nicely too. You
    will notice that the Archiver works with 8 transaction blocks at a time.
    Each transaction is processed in turn and then (I'm told) the rest of the 
    log file is scanned to see if any of these transactions is the last for 
    the database.  Hence the larger the %log file in use, the longer it takes 
    for the archiver to do its job. -- And if someone with Guru status can
    confirm that I'd be happy. Certainly it would explain the acceleration of
    the process as the log gets drained!

    Have Fun,

    Martin Bowes.
Ingres Q & A
Back to William's Home Page
Email William