frecover time

[Rebecca Hounschell]

I had to backup up Oracle to replace 9gb drives with 18gb drives. I did the backup using "fbackup" and it took 2.5 hours (I have a 5 gb index file and a 23 gb database). After I recreated my volume groups and lvols, I restored Oracle using "frecover". It took over 24 hours to restore the 5 gb index file and approx. 3 hours to restore the 23 gb database file. This just happened to be on a system that was not in production yet (I was preparing it for production by adding the larger drives). Can anyone explain why the frecover took this long?

[Paula J Frazer-Campbell]

Hi

Many things affect backup and recovery, it would be interesting to do another backup and restore and monitor things like memory, disks and processors. Doing this could point you in a direction.


HTH

Paula

[Steffi Jones_1]

Hi rebecca,

as Paula already said a lot of things can cause a slow frecover.
A few things I would recommend is to check the following:

1) see if you have a disk i/o problem
=> run dmesg, check syslog, run dd command
on that disk, etc.
2) check for processes eating up the resources
with e.g. top and/or sar
3) see if the tape you used is ok. Use a new
tape for the next backup

It sounds as if frecover had trouble writing to the disk or not getting any resource to finish the process.
Hope that helps a bit further,

Steffi Jones

[Victor BERRIDGE]

I agree with Paula,
Many things affect the restore from any source:
Machine load, users connected, disks contention and Elapsed time in case of frecover!
More the time passes less the process has privileges...
Now 5Gb indexes is not like 24GB of dbf files (full of empty...)
What type of DDS were you using with what devicefile (compressed?) in can vary drastically in performance (and so elapsed time etc...) ratio 1-4X (I had the case of fbackup DDS1 of an export of 1.6 GB (DB size 16GB)lasting 4 hours and the same using a DDS2 and tar instead lasting 20 min.
What is the size of your full export?

If you were to start again try the renice -n -20 procID (negative nice)

Kind regards
Victor

[CHRIS_ANORUO]

Hi Rebecca,

Modify the /etc/sam/br/fbackup_config file as following:
blocksperrecord 128
checkpointfreq 256
readerprocesses 4
t sounds as if frecover had trouble writing to the disk due to bad tape and dirty tape drive.
If you are using line command to do backup, check the online manual for fbackup on how to specify this file for backup. SAM uses it when backing up.

[Andy Monks]

The other possibility, is that one (or more) of the oracle db files was a sparse file when it was backed up. The backup commands have no way to indentify a sparse file and therefore when it's recovered you end up using lots more disk space and time. As a sparse file compresses quite well (it's got lots of nulls in it) it takes no time to backup.

For an example try the following :-

dd if=/etc/TIMEZONE of=/tmp/tz1 bs=10k seek=10000
du -sk /tmp/tz1
ll /tmp/tz1

It's a really large file, but not taking up any space.

Now do :-

cp /tmp/tz1 /tmp/tz2
du -sk /tmp/tz1 /tmp/tz2
ll /tmp/tz1 /tmp/tz2

The size of the files are the same, but the amount of space they take up is very different.

frecover can actually cope with the. There is a '-s' option that attempts to recover the file as sparse. It's probably not going to be as sparse as it started, but it's a huge improvement.

[justahuman]

Hi Rebecca,
has you solved your problem. I have have a similar Problem and your solution would probably fit for my Problem (slow frecover).
Do you have a message for me ?
If so, please send to:
eberhard.pruem@lvermgeo.rlp.de