BR0334W and BR0274W warnings during Offline Backup.

[Former Member]

Hi,

Title: BR0334W and BR0274W warnings during Offline Backup.

while running the offline Backup, at the beginning i have noticed these warnings. The Backup was finished successfully with warnings.

BR0334W Status of database file /oracle/EBQ/sapdata3/sr5701_2/sr5701.data2 is RECOVER

BR0274W File '/oracle/EBQ/sapdata3/sr5701_2/sr5701.data2' not found

BR0334W Status of database file /oracle/EBQ/sapdata3/sr5701_2/sr5701.data2 is RECOVER

BR0274W File '/oracle/EBQ/sapdata3/sr5701_2/sr5701.data2' not found

When i check at the os level, the file is not at all present and also the directory sr5701_2. Its strange to me. Everything is running well, i dont have problems because of this warning but how can i erase this warning.

Regards,

Mohan.

[Former Member]

Hi Mohan,

This cause has been happen while your data file is removed from OS level in offline mode.

Please check will you shotdown and up your database successfully?

Can u get any dump on application level?

Also check the previous backup log and search in which backup this data file is backup ed successfully?

You can remove this warning from below way.

First restore previous backup in which this datafile is exist. and than after apply all archive logs up to now.

(Now check the location of datafile you can see it)

Make the datafile online from offline

Regards,

Nirav

[Former Member]

Everything is running well, i dont have problems because of this warning but how can i erase this warning.

Strange but I don't accept that everything is working fine. If your datafile is not there then definately you will get dumps errors while accesing the specific file from application, check your system and every execution there must be some data loss due to this.

And this might be a warning in your backup log but an unignorable error and need to be fixed immediately.

Do you have DR configured?, do you have regular backups in place?

Paralelly raise a OSS message with high priority (if it is your Production) else restore the file/database from source.

Regards,

Nick Loy

[Former Member]

Hi Nick,

its also strange for me, no dumps at all, iam not having any problems is may be due to this reason - It was a SRM 5.0 system a month back. Later upgraded to SRM7.0/Netweaver 7.01 and wihin a week again upgraded to SRM7.01/Netweaver7.02

The db is a MCOD database, not a production system, it consists only development, test and training systems.

The datafile corresponds to PSAPSR5701 tablespace. Development system has the Schema owner SAPSR5, test system has the owner SAPSR3 and training system has the owner SAPSR4. So, the problem is in Development system, correct? but i dont see any dumps. After upgrading development system, we have upgraded the test system. Now, if we run a Restore from a old Backup, the upgrade of test system is lost, correct? (the last successful Backup without this warning is a month ago).

What is meaning of DR?

Regards,

Mohan.

[Former Member]

The datafile corresponds to PSAPSR5701 tablespace. Development system has the Schema owner SAPSR5, test system has the owner SAPSR3 and training system has the owner SAPSR4. So, the problem is in Development system, correct?

Yes

if we run a Restore from a old Backup, the upgrade of test system is lost, correct?

Yes

What is meaning of DR?

Disaster Recovery server

If it is a offline drop, check your control file for information. It should have the information on when it was droped from the database.

Regards,

Nick Loy

[volker_borowski2]

 Now, if we run a Restore from a old Backup, the upgrade of test system is lost, correct? (the last successful Backup without this warning is a month ago).

Hi,

concerning this topic, you surely need to get additional knowledge about MCOD DB management.

Since Oracle 10 there are functions in brtools/brrecover to support the so called "Tablespace Point IN Time Recovery" which is designed exactly for such a situation, so that you do not need to reset the entire MCOD DB but only teh tablespaces of a single System.

Basicly it is using the transportable tablespace feature to detach TS from one System off the DB,

recover these TS on a substitute DB, detach them then there and re-attach the recovered files to the original DB. It is really cool reading on help.sap.com about this topic to be found in the brrecover section.

Volker

[former_member197466]

Hi Mohan,

Please read SAP note 328785   ORA-00376: File cannot be read at this time if this helps.

Cheers,

Ivy

[Former Member]

Hi Ivy,

this Note is not valid in my case. Obviously the file cannot be read while the file itself is not there. Anyway, thank you.

Regards,

Mohan.

[former_member197466]

Hi Mohan,

Have a look on  SAP note  491160, point 12. A datafile is lost which provide the steps on what you need to check and solution if a datafile is lost.

Cheers,

Ivy

[volker_borowski2]

Oh oh,

how long are these missing?

You might need to restore these.

If you are lucky, this datafile does not contain segments,

in this case you may be able to drop them, but first,

you need to work out carefully, if something has been lost.

Check system table dba_data_files for the FILE_ID of the file:

SELECT FILE_ID FROM DBA_DATA_FILES where file_name='/oracle/EBQ/sapdata3/sr5701_2/sr5701.data2';

Then check DBA_EXTENTS, if it has records for the given FILE_ID.

SELECT count(*) from DBA_EXTENTS where FILE_ID= ...

If this resturns results, you might still be lucky, if the found segments are only indexes,

but we are going to deal with this later.

If you did a systemcopy, and you missed to integrate the datafiles from the sourcesystem,

because you used an old CONTROL.SQL, there might be no way to fix this.

You can check for this by checking V$DATAFILE for entries with ... NAME LIKE 'MISSING%'

Volker

[Former Member]

Hi Volker,

thank you for your reply. I can answer you only on Monday, please bear with me.

Regards,

Mohan.

[Former Member]

Hi Volker,

i have checked and the result of

SELECT count(*) from DBA_EXTENTS where FILE_ID=26 is 0.

What should i do next? I have no idea.  The result of

select name from v$datafile where name like 'MISSING%';  is - no rows selected.

Regards,

Mohan.

[volker_borowski2]

Hi,

this result suggests, that the datafile is indeed empty!

Seems to be good news.

I mind to remember, that it is possible to drop empty datafiles with todays releases of oracle.

I even think it is possible to do this with brtools, which will check in addition if the file is really empty.

Note 1170233 talks about a bug in this context, but it is quite old, so there is chance, that you have the fixes installed, crosscheck first.

Volker

Re-Thinking: Might not work in State RECOVER. You might need to set the file OFFLINE first.