RE: IDS 7.31: Backing up logical logs to disk
Thanks Mark
2 logs need to complete within 5 seconds for this to occur. This is not the
case with our client.
We found the sleep necessary, presumably to allow time for the log to be
released by ontape / unix.
The log backup method (ontape here) could be anything that you want to use.
One can easily stop 2 occurring with creating a "in_use" file at the
beginning (deleting when complete), testing for this file at the start of
the script and exiting if the file exists.
And it also highlights that any procedure for archiving and log backup needs
to be tested carefully and monitored when put live. We did have an accident
here when during a week of very heavy database activity the filesystem
collecting the logs filled up! This resulted in each ontape process
remaining "hung" waiting on the file and Enter key. When we corrected the
situation the next log file contained a number of logs as Mark described.
(No problem here).
Someone else I know ran "onmode -l; ontape -a" every hour in cron. He
never did run out of logs during 1 hour - but he did get close once.
MW
-----Original Message-----
From: Mark D. Stock [mailto:mdstock@mydas.freeserve.co.uk]
Sent: Friday, May 12, 2000 10:17 AM
To: murray@quanta.co.nz
Cc: richard.spitz@ana.med.uni-muenchen.de; informix-list@iiug.org
Subject: Re: IDS 7.31: Backing up logical logs to disk
Murray Wood wrote:
>
> Richard
>
> We use the following which results in separate files in the log directory
> for each log with the log number attached to the file:
>
> PROG=`basename $0`
> USER_LIST=informix
> BACKUP_CMD="onbar -l"
> EXIT_STATUS=0
>
> EVENT_SEVERITY=$1
> EVENT_CLASS=$2
> EVENT_MSG="$3"
> EVENT_ADD_TEXT="$4"
> EVENT_FILE="$5"
>
> case "$EVENT_CLASS" in
> 23)
> # onbar assumes no operator is present,> # so all messages are written to the activity
> # log and there shouldn't be any output, but
> # send everything to /dev/null just in case
> touch /logs/scott/current
> chown informix /logs/scott/current
> chgrp informix /logs/scott/current
> ontape -a < /home/informix/llog.txt >/dev/null 2>&1
> s=$?
> sleep 2
> cd /logs/scott
> e=`echo "$EVENT_MSG" | sed 's/Logical Log //' | sed 's/
Complete.//'`
> mv current llog$e
> EXIT_STATUS=$s
> ;;>
> # One program is shared by all event alarms. If this ever gets expanded
to
> # handle more than just archive events, uncomment the following:
> *)
> # EXIT_STATUS=1
> ;;
> esac
>
> exit $EXIT_STATUS
>
> LTAPEDEV is /logs/scott/current
> llog.txt contains a couple of enter keystrokes
> $e contains the log number
> It creates file llog123 when log 123 is backed up etc
>
> These files are backed up normally and purged after a couple of weeks in
> this case.
This script may work for you, but is extremely dangerous. Well, maybe
that's a bit strong, as your logs will get backed up (probably), but
they may not end up where you think they should.
If your logs fill rapidly, then it is possible for this script to
attempt to run multiple ontape -c commands. I think the rest will fail,
but will still attempt the log move.
If your logs fill at a rapid rate, then you will backup multiple logs to
a single file. Then your next file will contain the next batch and so
on.
For example, logs 1, 2 & 3 could trigger a backup to a file called
llog1. Then logs 4, 5, 6 & 7 could get backed up to a file called llog3,
or you might be lucky and store them in llog4.
If a backup is triggered just as you move the tape file, the OnTape will
probably keep prompting for a tape. You could eliminate the touch, chown
& chmod by using cp, instead of mv. However, the log file could be
written to before you get a chance to copy it.
This may all seem a bit pessimistic, especially if it currently works
for you, but people may try it on their own systems. ;-)
Cheers,
--
Mark.
+----------------------------------------------------------+-----------+
| Mark D. Stock mailto:mdstock@mydas.freeserve.co.uk |//////// /|
| http://www.informix.com http://www.informixhandbook.com |///// / //|
| http://www.iiug.org +-----------------------------------+//// / ///|
| |What year 2000 bug? year 2000 bug? |/// / ////|
| |year 2000 bug? year 2000 bug? year |// / /////|
| |2000 bug? year 2000 bug? year 1900 |/ ////////|
+----------------------+-----------------------------------+-----------+