fbackup x Oracle hot backup

[Vogra]

Hi All!
last night my Fbackup routine get the msg:
----------------------
fbackup(3009): WARNING: File number 474729 (/u03/oradata/vsdb/baan_i01.dbf)was not successfully backed up
----------------------
well, when I check the log file br_index.full, the file baan_i01.dbf is there.
My Db is in archive log mode.
I know fbackup don't copy open file, and I put tablespace in begin backup.
I know (I read) that in really Oracle write in datafiles when in backup mode, but my doubt is: this error is significant if the number of blocks is same to another datafile that was successfully backud up ?

Thanx,
LIMA.

[Robert Thorneycroft]

The number of blocks writen will be the same as another datafile if they are the same size!

This does NOT mean you successfully backed up the file.

The reason for the file not being backed up could be something to do with the database having not successfully placed the file into backup mode by the time the backup was completed, or maybe a faulty disk, in any case I would place the tablespace into backup mode (Check it is definitely in backup mode) and backup this file to see if this is a recurring error.
If you can backup this file successfully then you just better hope everything doesn't die before you can get your next backup done, else you might be recovering from REDO logs for a long time ;)
If you still cannot backup the file I would suggest you might have some kind of disk problem and would check to see if any faults are logged against the disk in cstm or get HP to check it out for you.

Kind regards,
Robert Thorneycroft

[James R. Ferguson]

Hi:

'fbackup' writes its index of files it *intends* to backup to the beginning of the tape.

When a file is ready to be transferred from disk to the tape, 'fbackup' notes the modification timestamp of the file. Upon trnsfer to tape the timestamp is interrogated again. If it is the same as that first noted, the copy is considered successful. If the timestamp is found to be different, the tape copy is marked "bad" and 'fbackp' retries the transfer again, until 'maxretries' are exhausted.

If a file cannot be successfully copied to tape after 'maxretries' attempts, an error is issued as noted. If you were to attempt to recover the file using 'frecover' you would find that 'frecover' would reject it.

Regards!

...JRF...

[john korterman]

Hi Lima,

The file for which you have a warning is not on your tape, but the explanation is a bit long:
Before writing anything to the tape fbackup makes a list of the files to be included in the backup. The list is - apart from the fbackup header itself - the first real data written to the tape. The content corresponds to br_index.full, which can be viewed as a list of "what fbackup should try to include", but as it is made before writing the first "real" file on the tape, it is not a list of the real content.
Before fbackup starts writing a file to tape it notices the last modification time of the file in question. After some writing - for a big file I think fbackup does not wait until it has written the whole file - it checks if the last mod. time of the file has changed. If yes, fbackup tries/retries until a successful store has been made, or until the number of "maxretries" have been exhausted (based on another of your postings I assume this is defined in /etc/sam/br/fbackup_config).
As the message is that the file was not successfully backed up, it means that fbackup has tried, but failed. Although fbackup may have tried the number of times to which "maxretries" has been set to, you may think that there maust be some data on the tape, which there is, but frecover will not let you restore it. If you try, you will get the message that "frecover(4301) could not complete recover of file ".

regards,
John K.

[T G Manikandan · Accepted solution]

THere have been many posted questions on this forum and probably the solution suggested was to increase the


retries in etc/sam/br/fbackup_config
file.

Probably the reason could be that after the datafile is put into the hot backup mode the fbackup could not get a consistent picture of the file and after the maximum re-tries exhausted it skipped the file.
You can increase the maxretries in the config file to 30.

My best way would be going with Oracle family for the backups.
Why don't you switch to RMAN.
It has wonderful features for backup.
Infact the datafile does not require to be put into backup mode for hot backup.

Also check these links

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0xba9406295e00d6118ff40090279cd0f9,00.html
http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x831e36e69499d611abdb0090277a778c,00.html

[Robert Thorneycroft]

One other question, where did you read the following?

I know (I read) that in really Oracle write in datafiles when in backup mode, but my doubt is: this error is significant if the number of blocks is same to another datafile that was successfully backud up ?

It is my understanding that when in backup mode Oracle will allow reads, but will not allow writes to a datafile. If Oracle did allow writes then you would never be able to backup a consistent file as there would be no way of knowing if part of a file that had previously been backed up had been modified by the time the end of the file was backed up, which in a relational database would be disasterous.

I just cannot see how the backup can work any other way? If you could paste a link or whatever source I would be interested to have a read.

Kind regards,

Robert Thorneycroft

[James R. Ferguson]

Hi (again):

If you have altered the tablespace for backup before you begin your 'fbackup', then you should be able to get a static copy of that structure. Oracle still allows writes but simply does then to the re-do log for application to the real table after it is taken out of backup mode.

As for 'fbackup' and its 'maxretries', the maxiumum value for this option is <5>.

Given what has already been said about 'maxretries' and timestamps for files, remember that every retry (re-copy) wastes not only time but tape!

Regards!

...JRF...

[Robert Thorneycroft]

This was my understanding also that the REDO logs were used to store all of the write information for updates after the backup has completed, this is why your database will start producing logs at a vastly increased rate for the duration of the backup procedure.

Thanks for confirming this James I was starting to get a little worried that I might have to take another look at my backup scripts ;)

Regards,

Robert Thorneycroft

[Vogra]

well,
I do not have backup window during the day. I changed maxretries to 30 and next backup will at night - tomorrow I will see; I'm looking for URL about oracle allow write on tablespace diring backup mode.
Now I will get the points...
Thanx to all.
Lima.

[Volker Borowski]

Hi folks,

just to put some light on ORACLE's
BEGIN BACKUP.

Basicly this does NOT suspend the write access the the entire data file !!!! It would be impossible to continue online processing in an OLTP database if it would.

In fact, it suspends writes to the first block of a datafile, which usually is updated upon checkpoints to make oracle aware, from which SCN this datafile might need recovery.
In addition, redologing ist changed a little, but not dramaticly, to store some additional information concerning recovery.

This frozen headerblock will show oracle a mismatch between the controlfile and the datafile as far as the SCN of the last chekcpoint is concerned and that the database has to take care about it during recovery. This is the reason, why you will need to do a real recovery, when your database crashed while a tablespace is in backup mode. The DB thinks the datafile has just been restored. If the tablespace is not in backup mode, and the file is not restored from an OFFLINE backup, the SCN from the last checkpoint in the controlfile and the headerblock of the datafile will match. So Oracle will be able to do a normal automatic instance recovery upon startup.

Online backups are easier to handle with a backup command, that does not take care if the file is open. So usually tar,cpio or dd do their job quite ok.

But:
- do an "end backup"
- do an "alter system switch logfile"
- do an "alter database backup controlfile ..."
- finally backup the archivelogs and the controlfile in addition

Hope this helps
Volker

[Vogra]

Hi All,
well, I altered maxretries to 30 and my backup is ok now.

to James, thanks to remember in possibility to wast tape and to Roberto, I think the explanation from Volker is ok...
I will send URL...
Thanx to every one.
LIMA.