HarryH said:
>
> I'm trying to recover a DB from last February 15 and roll forward to
> February 19 (power outage). I have all the log files from 15th to the
> 19th but I'm having problems finding the very first log. Here are the
> relevant sections of the online1.log:
> 21:20:29 Checkpoint Completed: duration was 2 seconds.
> 21:23:43 Logical Log 42438 Complete.
> 21:23:44 Logical Log 42438 - Backup Started
> 21:23:45 Logical Log 42438 - Backup Completed
> 21:23:45 Process exited with return code 142: /bin/sh /bin/sh -c
> /hta/informix/etc/log_full.sh 2 23 "Logical Log 42438 Complete." "
> Logical Log 42438 Complete."
> 21:25:31 Checkpoint Completed: duration was 1 seconds.
> .................................................. ..............
> 23:56:22 Checkpoint Completed: duration was 1 seconds.
>
> Tue Feb 15 00:00:42 2005
>
> 00:00:42 Checkpoint Completed: duration was 1 seconds.
> 00:00:42 Level 0 Archive started on rootdbs, data1_dbs
> 00:05:54 Checkpoint Completed: duration was 0 seconds.
> 00:10:55 Checkpoint Completed: duration was 1 seconds.
> 00:15:57 Checkpoint Completed: duration was 2 seconds.
> 00:21:00 Checkpoint Completed: duration was 2 seconds.
> 00:25:17 Archive on rootdbs, data1_dbs Completed.
> 00:25:20 Checkpoint Completed: duration was 2 seconds.
> .................................................. ..............
> 09:24:25 Checkpoint Completed: duration was 102 seconds.
> 09:28:43 Logical Log 42439 Complete.
> 09:28:45 Process exited with return code 142: /bin/sh /bin/sh -c
> /hta/informix/etc/log_full.sh 2 23 "Logical Log 42439 Complete." "
> Logical Log 42439 Complete."
> 09:28:46 Logical Log 42439 - Backup Started
> 09:28:48 Logical Log 42439 - Backup Completed
> 09:30:18 Checkpoint Completed: duration was 52 seconds.
>
> When I do the restore this is the information displayed:
> Informix Dynamic Server Copyright(C) 1986-1998 Informix Software, Inc.
> Initialization Time 06/28/2000 14:51:03
> System Page Size 2048
> Version 6
> Archive CheckPoint Time 02/15/2005 00:00:42
>
> And the restore seemingly goes perfectly. When I get to the roll
> forward, I get this:
> Please mount tape 1 on /dbs/logicalogs/sdboltp.log and press Return to
> continue ...
>
> Roll forward should start with log number 42439
> Unexpected end of log tape (errno 0), continuing...
>
> We have a cron job that runs rclogs.sh every hour - this copies the
> sdboltp.log to a file with an extension of date.time. I have files for
> times of every hour on 14th and 15th except 1am on 15th. I've every log
> file from 9pm on 14th to 11am on 15th, but it's not accepting any of
> them. I now believe that the file I need is the one from 1am 15th.
>
> So grasping at straws.....
> Is there something I've missed?
> Any ideas of a workaround?
> Any ideas at all?
>
> The basic backup strategy is:
> 1 ontape -s -L 0
> 2. find <filesystems> | cpio

Where is the ontape -a ?

If you haven't got that, then where you are rhymes with bunted.

--
Bye now,
Obnoxio

"C'est pas parce qu'on n'a rien ` dire qu'il faut fermer sa gueule"
- Coluche

did i mention i like nulls? heck, i even go so far as to say that all
columns in a table except the primary key could/should be nullable. this
has certain advantages, for example, if you need to insert a child record
and you don't have a parent row for it, just do an insert into the parent
table with the primary key value (everything else null), and voila,
relational integrity is preserved. but this is, admittedly, a bit
controversial among modellers.

--r937, dbforums.com
sending to informix-list

ahum most likely in log_full.sh which is configured as
alarmprogram in $ONCONFIG.

having this is a recept for disaster...

Superboer.

"Superboer" <superboer7@planet.nl> schrieb:

>ahum most likely in log_full.sh which is configured as
>alarmprogram in $ONCONFIG.
>
>having this is a recept for disaster...

Please explain. What's wrong with calling "ontape -a" from log_full.sh?

Regards, Richard

for one

if the filesystem is full, ontape -a will start writing to nonextisting
stdout
that you have to mount a new tape..... this will also fill up a
filesystem
not to mention eat a cpu.

Most important have seen situations that it missed trx log data making
it
impossible to rollforward.

(can't remember the details could be copying or
moveing the 'ontape-a tapefile' too soon or starting ontape-a too soon
or...
specially with blobs in blobspaces.)


Superboer.

Richard Spitz schreef:

> "Superboer" <superboer7@planet.nl> schrieb:
>
> >ahum most likely in log_full.sh which is configured as
> >alarmprogram in $ONCONFIG.
> >
> >having this is a recept for disaster...
>
> Please explain. What's wrong with calling "ontape -a" from log_full.sh?
>
> Regards, Richard

Superboer wrote:
> for one
>
> if the filesystem is full, ontape -a will start writing to nonextisting
> stdout
> that you have to mount a new tape..... this will also fill up a
> filesystem
> not to mention eat a cpu.

ALARMPROGRAM script/application should handle that before running ontape.
We use my eventalarm.c program here for almos 8 years with no problems.
Eventalarm even correctly handles the situation Martin notes when multiple
logs complete before the initial ontape completes. After the ontape
completes eventalarm renames the archive file to a name that reflects its
contents and recreates the empty LTAPEFILE file ready for the next run.

What we also do is have a cron wake hourly, sweep all log archive files to
another machine using rcp for safety, and delete files older than 7 days.
This insures that every logical log backup file is on two independent
machines in two different data centers. In addition, the nightly FS
archives pick up the files on both machines and archive them to tape. Each
file is on up to 7 day's daily system archive tapes. Eventalarm.c is in
the utils3_ak package in the IIUG Software Repository.

> Most important have seen situations that it missed trx log data making
> it
> impossible to rollforward.

Haven't lost a single logical log archive in 8 years! If for some reason
the ontape fired immediately after the log fills fails, the next log fill
event will archvie both logs. In addition, we run an ontape -a to the same
disk file at server startup.

Art S. Kagel

> (can't remember the details could be copying or
> moveing the 'ontape-a tapefile' too soon or starting ontape-a too soon
> or...
> specially with blobs in blobspaces.)
>
>
> Superboer.
>
> Richard Spitz schreef:
>
>
>>"Superboer" <superboer7@planet.nl> schrieb:
>>
>>
>>>ahum most likely in log_full.sh which is configured as
>>>alarmprogram in $ONCONFIG.
>>>
>>>having this is a recept for disaster...
>>
>>Please explain. What's wrong with calling "ontape -a" from log_full.sh?
>>
>>Regards, Richard
>
>