Re: Q: Backups

Chuck Fetters (cfetters_at_iac.net) wrote:
: I'm on a team that just finished development of a system that acts
: as a repository for data that is collected from other systems. Some
: of the data is stored in an ORACLE database and some is stored as
: text or TIFF files. The system is about to go into production so
: they want me to come up with a backup stagegy.
 

: The database is 3Gig and is on RAID 5. The text and TIFF files will
: eventually (in about 3 months) add up to about 3Gig and is also
: on RAID5. (Text and TIFF files more than 3 months old are moved to
: optical and don't need to be addressed in the backup stategy.)
 

: Since we really want 7x24 availability, we don't want to bring
: down the database for backups. Also since we're on RAID, we're
: hoping that we'll rarely need to restore. Finally, almost all of
: our data is coming from other computer systems and they could
: send of duplicate copies of recent data in the event of a catastrophe.
 

: We're considering doing backups just once a week. But we don't really
: want to incur the overhead of being in archivelog mode all the time.
: What would happen if we use NOarchivelog mode all week, changed to
: archivelog mode, did online backups, then changed back to NOarchivelog
: mode?

Yes, you could, but realize that you need to umount/mount the db each time you want to change archive mode, so you effectively need to bump users on the system off twice to do so. so that basically does not allow you to do true 24x7.

: Since I also need to backup the text/TIFF files at the same time as
: the DB. I want the DB backup to be consistent with the other file
: backups. Does archivelog mode plus telling Oracle that I'm starting
: a backup prevent the tablespace data files from changing during the
: backup?

no, Oracle marks the datafiles and control files as having tablespace XYZ being hot-backed up, but that does not guarantee that the datafile will not be changing during the backup. Oracle also adjusts redo logging to dump the whole, modified db block to a redo log during hot backups.

: The only other alternative I've come up with is to change all application
: program (written in Pro*C) so that they have a "read-only" mode. But that
: means trusting the programs to not update the DB while I'm backing up.
: This sounds too error prone to be trustworthy.
 

: Any suggestions?

I'm not entirely understanding your last paragraph above...is your application a read-only application? If you, why do you need to do backups of your database?

The only way I can see to _guarantee_ a consistent backup given your situation is to have no one modifying any of the files during the backup period. You can have people read-access it during the backup period, but no read/writes. The reason this, I believe, is your only option is because there's no mechanism to guarantee consistency with data within a database and data outside a database.

Johnny Chan
Independent Oracle Specialist Received on Thu Jul 20 1995 - 00:00:00 CEST