Ontape restore hangs
Doug Lawry
IDS 11.10.FC2 on SUSE 10.1. Migrating development instance to another server
and storage array (same OS, version and onconfig). 130GB uncompressed ontape
backup made on old system will not restore on the new machine. Standard
output stops after listing the dbspaces. Message log stops on first
checkpoint after starting physical restore. Process running but nothing
further happening 5 hours later.
Tried both restore from directory device (ontape -p -d) and piped
(ontape -p -t STDIO). No different with "-r" instead of "-p". TAPEBLK 32,
TAPESIZE 0, ulimit unlimited. Shared memory checked clear beforehand using
"ipcs". No error messages other than the following which we always get on
startup (100 x 20MB logical logs):
WARNING! Logical log layout may cause Dynamic Server to get into
a locked state. Recommended smallest logical log size
is 16 times maximum concurrent user threads.
Worked around the problem using dd | rsh | dd and instance started fine on
first attempt, so dbspaces (or anything other than ontape) not the problem.
Any ideas? Cannot easily reproduce or run further diagnostics with ontape
running as the new system is now in use. Will raise with IBM unless you guys
come up with a theory.
Regards,
Doug Lawry
TBP
Just trying to think this through ...
You did an ontape backup ... to where? i.e. What was TAPEDEV set to? A DIRECTORY (presumably) or a FILE or STDIO?
You then attempt a restore ... from a local (or nfs mounted) filesystem?
The workaround involved a combination of dd rsh and dd ... so where was the backup?
Doug Lawry
news:GZqBk.15822$a01....@newsfe15.ams2...
Originally to a directory which was then copied across and referenced in
TAPEDEV. This didn't work, so used:
rsh otherhost ". ./.profile ; ontape -s -L 0 -t STDIO" | ontape -p -t
STDIO -v
This produced the same result, i.e. hung.
> You then attempt a restore ... from a local (or nfs mounted) filesystem?
See above.
> The workaround involved a combination of dd rsh and dd ... so where was
> the backup?
The following worked just fine, obviously while the source instance was
off-line:
rsh otherhost "dd if=devicepath bs=2k" | dd of=devicepath bs=2k
Doug Lawry
increasing TAPESIZE makes all the difference even when using backup images
on disk. It may be peculiar to this disk array (Dell PowerVault MD3000).
Astonishingly, with TAPESIZE 1024 (the largest suggested value I had seen)
instead of 32 (the default), the restore completed in 55 minutes (about the
same as "dd") instead of several hours, so I'll be making this change
everywhere else!
Top tip from this news group: use "onstat -D" to monitor "ontape" progress.
"Doug Lawry" <la...@nildram.co.uk> wrote in message
news:XfOdnWpJ7rK1vkvV...@pipex.net...
Doug Lawry
"Doug Lawry" <la...@nildram.co.uk> wrote in message
news:N5mdnfW0JLeCrkfV...@pipex.net...
Captain Pedantic
> This turned out just to be slow performance rather than a hung ontape, and
> increasing TAPESIZE makes all the difference even when using backup images
> on disk. It may be peculiar to this disk array (Dell PowerVault MD3000).
>
> Astonishingly, with TAPESIZE 1024 (the largest suggested value I had seen)
> instead of 32 (the default), the restore completed in 55 minutes (about
> the same as "dd") instead of several hours, so I'll be making this change
> everywhere else!
You should get a top Informix consultant called Paul Watson in for a day.
He's always banging on about the performance benefits of large TAPEBLK ...!
Obnoxio The Clown
Keith Simmons
> Informix-list mailing list
> Inform...@iiug.org
> http://www.iiug.org/mailman/listinfo/informix-list
>
Beware having too large a BLK however. I've crashed an AIX box with a
large BLK on a fibre attached drive. Use dd with varying block sizes
to determine the largest that works before implementing it.
Keith
Doug Lawry
news:mailman.1801.12222632...@iiug.org...
Thanks :-)