Corrupt data error when using Windows backup on Oracle

Question

Our SAP servers include a SDLT internal tape drive that we use for doing a complete system backup.  When using Windows Backup we get the following message in the backup log:
WARNING: Portions of "\oracle\T00\sapdata1\protd_2\PROTD.DATA2" cannot be read.  The backed up data is corrupt or incomplete.
This file will not restore correctly.
This is occuring on a couple of different systems but the wierd thing is when this happens in occurs on one Oracle drive in one system and the other Oracle drive on another system i.e. the G: drive on our TST sysytem and the E: drive on another.  The E: and G: drives contain the main Oracle datafiles.
Has anybody ever encounter something like this and what can I do about it?
Thanks;
Gale S.

Answer 1

Especially no backup tool would know about the
fact
that a Oracle block had been changed after it was
copied.
Now I have to contracdict
There are backup tools (e. g. OpenFile Manager from
Legato/EMC), that track the filesystem changes and
makes sure, the backups are consistent in sense of
filesystem blocks. We´re backing up some ORA
databases (non-SAP, 7.3.4 and 8.1.7) for ages now -
and I never saw this kind of corruptions.
Well, these Backup-Tools do perform copies I/O-Consistent. That's different than DB-Block-consistent in the first place. Anyhow due to the fact that the DBMS do have a syncronizing between I/Os and writing out the blocks this leads both to consistent blocks.
I just wonder, how the database would deal with such
"inconsistent" files. Given the fact, you start a
backup at filesystem block 0, the database is being
backed up and a transaction is committed and
something is written to block 100, 200 and 500. The
backup is on block 300. If you now restore the
database, it has the already commited block 500 in
the file but 100 and 200 are not yet written in the
database file. The redo will then find an already
commited transaction on 500. What magic will tell the
engine, that this is due to an online database
backup? I mean, if you set the tablespace to backup,
the engine "knows" the state - but if you just backup
the file, the engine is unaware of that... I´m just
curious how this is handled...
Well the trick here is: we tell the database before we plan to copy the data. When a ONLINE backup is done, the tablespaces are set into BACKUP mode. This changes two things for us:
1. The datafile headers of these tablespaces are not updated anymore although dirty blocks are still written out to these files. Since the control files that keep the SCN (system change number) are updated nevertheless, the database will know at recovery time that these files had been in online backup mode and do need recovery to become consistent again.
2. The UNDO-information is not only written out to the UNDO/ROLLBACK-Tablespace but additionally to the REDOLOGS. So, for the time where the tablespaces are in BACKUP mode, we have all information needed to make a block consistent again - regardless if a transaction had been commited or rolled back - in the redolog. So a full recovery of all changes is possible with
that.
That's basically the "magic" behind this.
If the copy of the datafile is done without this - well, then there's no magician in the world that would been able to get it consistent again. Online Backups with Oracle are only possible with BACKUP mode or RMAN (ok, and possible some 3rd party hacks...).
KR Lars