fbackup(3009) errors on Oracle binaries

[Brett Schubert]

Everynight for the past couple of weeks we have been getting fbackup(3009) errors on different files in the same directory.

Today
fbackup(3009): WARNING: File number 8346 (/u01/apps/oracle/product/8.1.7/bin/rmanO) was not successfully backed up

Sep 29th
fbackup(3009): WARNING: File number 8325 (/u01/apps/oracle/product/8.1.7/bin/otrccol) was not successfully backed up
fbackup(3009): WARNING: File number 8326 (/u01/apps/oracle/product/8.1.7/bin/otrccol0) was not successfully backed up

Sep 28th
WARNING: File number 8326 (/u01/apps/oracle/product/8.1.7/bin/otrcfmt)

Sep 27th
WARNING: File number 8351 (/u01/apps/oracle/product/8.1.7/bin/svrmgrlO

Sep 26th
WARNING: File number 8314 (/u01/apps/oracle/product/8.1.7/bin/otrccol)

Sep 25th
WARNING: File number 8314 (/u01/apps/oracle/product/8.1.7/bin/otrccol)

Sep 24th
WARNING: File number 8314 (/u01/apps/oracle/product/8.1.7/bin/otrccol)

Sep 23rd
WARNING: File number 8350 (/u01/apps/oracle/product/8.1.7/bin/tnslsnrO)
WARNING: File number 22246 (/u01/apps/oracle/product/8.1.7/ctx/data/enlx/droldUS.dat)

Sep 22nd
WARNING: File number 8309 (/u01/apps/oracle/product/8.1.7/bin/otrccref0)
WARNING: File number 8310 (/u01/apps/oracle/product/8.1.7/bin/otrcfmt)

Sep 21st
WARNING: File number 8304 (/u01/apps/oracle/product/8.1.7/bin/otrccol)

These oracle files are binaries that should not be locked for writing. The dates on these files are the original creation dates from 2002.
What is going on here?

Your help would be much appreciated.

Thankyou

Brett Schubert
DBA

[Adisuria Wangsadinata_1]

Hi,

Is the Oracle has been shutdown when you run the fbackup ?

The fbackup is not design for the open file(s), so you need to shutdown the oracle first before run the fbackup.

Hope this information can help you.

Cheers,
AW

[Ingo Duschl]

you better create another kind of backup for oracle.perhaps copying the data files or do en everynight export with archiving on.best do both......

[James R. Ferguson]

Hi Brett:

I would expect to see these warnings for any filesystem with files that were actively changing during a backup.

When 'fbackup' starts to backup a file, it first notes the checksum of the file as it resides on disk. It then copies the file to tape. When the transfer of that file is complete, it compares the file's original checksum to one just computed. If they are the same, 'fbackup' moves on to copying the next file.

If the two checksums differ, however, 'fbackup' marks the copy it moved to tape as "bad" and proceeds to checksum/copy/checksum again. This retry process will be tried 'maxretries' times. By default, 'maxretries' is equal to five (5). If the value is exceeded, you are warned that the file was not "sucessfully backed up". You can control the number of retires with 'fbackup's configuration file (see the manpages), but in this case, the default value of five is more than adequate. You need to quiesce the database if you are going to use 'fbackup'.

Regards!

...JRF...

[Brett Schubert]

Hi Guys.
Thanks for the quick replies.
To answer your questions

We shutdown all Oracle databases everynight for 6 hours to run the backups.
The backups begin and end within this 6hr gap.
Therefore, you would think, no oracle files would be open. If the database was open I would get warnings and errors on the data files themselves as well, which I am not.

My understanding, is that oracle executables (as with most executables) are never opened and updated during normal processes. They are only read into memory and executed. My oracle executable binaries date stamp is back in 2002.

[Sreedhar Nathani]

Hello Brett,

The reason for Fbackup warning 3009 because these files are opened
during the fbackup, thats why these files are not able to backup.

You already mentioned you are stopping the oracle prior to backup.

Today
fbackup(3009): WARNING: File number 8346 (/u01/apps/oracle/product/8.1.7/bin/rmanO) was not successfully backed up

Sep 29th
fbackup(3009): WARNING: File number 8326 (/u01/apps/oracle/product/8.1.7/bin/otrccol0) was not successfully backed up
Sep 28th
WARNING: File number 8326 (/u01/apps/oracle/product/8.1.7/bin/otrcfmt)
Sep 27th
WARNING: File number 8351 (/u01/apps/oracle/product/8.1.7/bin/svrmgrlO
Sep 26th
WARNING: File number 8314 (/u01/apps/oracle/product/8.1.7/bin/otrccol)
Sep 25th
WARNING: File number 8314 (/u01/apps/oracle/product/8.1.7/bin/otrccol)
Sep 24th
WARNING: File number 8314 (/u01/apps/oracle/product/8.1.7/bin/otrccol)
Sep 23rd
WARNING: File number 8350 (/u01/apps/oracle/product/8.1.7/bin/tnslsnrO)
WARNING: File number 22246 (/u01/apps/oracle/product/8.1.7/ctx/data/enlx/droldUS.dat)
Sep 22nd
WARNING: File number 8309 (/u01/apps/oracle/product/8.1.7/bin/otrccref0)
WARNING: File number 8310 (/u01/apps/oracle/product/8.1.7/bin/otrcfmt)
Sep 21st
WARNING: File number 8304 (/u01/apps/oracle/product/8.1.7/bin/otrccol)


otrccref, otrccol, otrcfmt these are oracle trace executables.

rman is oracle backup/restore utility

I would like you to check the following before backup

a. Ensure all the databases are shutdown
b. No oracle users are logged in
c. stop the oracle traces, listener service

After that try doing fbackup

[Stephen Keane]

You might also want to read

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=338531

[Brett Schubert]

Hi Guys

Just a thought.
We run two backups concurrently at night. One for DRP (Disaster Recovery) and one "FULL" backup. Obviously there would some overlap of backed up files. If one file is being accessed by on fbackup process, would this lock the file from allowing another fbackup process to access it?

Cheers
Brett

[Patrick Wallek]

That is possible.

Is there any way to run only one backup at a time? I would think if you were running them both simultaneously that you would see some performance hit as well.

[Brett Schubert]

We have a 6hr backup window. Currently the FULL takes 3hrs and the DRP takes 4hrs (these timings most likely include the interference overhead).

Have staggered the backup starting times. Will inform you if this solves the problem for the time being.

Cheers
Brett