Oi. Ok, all. Here is a quick run down of Oracle's hot backup procedure.
To clear up some problems with the above.
1. Oracle will not hang when the hot backup is running, or runs to long. It will hang when the archive log directory fills up, but provided that this doesn't happen, you can leave a database in hot backup mode forever (don't).
2. The tables/tablespaces/datafiles/etc are not locked. All access to the datafiles is normal, and all queries will run normally. I will go over why this is true below.
3. OS commands work fine against online datafiles. The exception to this would most likely be fbackup, which tries to open a lock on the datafile. Otherwise, 'cpio', 'cp', 'tar', 'gzip', 'compress', etc all work fine and normally.
4. Rman is not a nice tool. Rman is a PITA when running to tape. You have to use a media manager, you have to have a tape drive, and you have to have some patience to get it working right. If you have less than a 50g database, back it up to disk (compressed it will run about 14g per day). If you have more than 50g, and you have enough reason, invest in Business Copy or something like it. If you use rman, specify 4-6 times backup time for the restore, minimum, and hope that it works right.
5. Online backups are consistant provided you have all of the archive logs generated during the backup.
6. Online backups are NOT fuzzy. Fuzzy backups are where the datafile is backed up using a standard backup without putting the database into backup mode.
Ok, got that out of the way.
First, a quick explaination about how Oracle works normally. Whenever an update/insert/delete occurs in Oracle, the change is written to the rollback tablespace, written to the datafile (or cached into memory to wait for a checkpoint), and the change is written into the redolog for eventual archival.
When a datafile is placed into online backup mode, the SCN of the datafile is frozen, the redolog is updated that it is in online backup mode, but all access stays the same. You will be able to query, as well as update/insert/delete rows on the database. However, instead of writing a change into the redolog, the full block of the database is written into the redolog (ie: 8k of information per insert for an 8k block size datafile). It is done this way, because Oracle doesn't know what is being backed up at the time, so it is possible for a backup to be in the middle of a block at the time of the update, so the backup would only have half of the correct information (inconsistant).
After you have completed your backup of the datafile, you have to go back in, and alter the datafile out of online backup mode. This will unfreeze the SCN number, and notify the redolog that the backup is complete for the datafile.
Now, when you restore the datafile, the controlfile (however you get it), reads the SCN number, and finds which archive log is needed to recover the datafile. The archive log is read in, and changes made to the datafile are written in full blocks to the datafile (possible consistancy problem mentioned above). As this is done, the SCN of the datafile is kept frozen, until the redolog passes the end backup command, at which point the SCN is again updated on the datafile (signaling that the datafile is consistant with itself). Once this point is passed, the changes written to the datafile are normal block changes (not full blocks).
As for the original question, do you have a media manager like Omniback available. An easy way to do this is to put all of the tablespaces in backup mode, and use omniback to backup the datafiles to tape, then take them all out. A simple pre/post exec script can do this without a problem. If not, you might want to consider using tar, or doing compressed exports to disk, although this will not give you Point-in-Time recovery.
Let me know if you have any questions.
Thanks,
Brian
