Database Backups

Bill Murray bmurray at snf.stanford.edu
Tue Jan 21 08:32:57 PST 2003


John and Mike,

(I have copied MIT since they face the same issues and/or may have solved
the problem.)

Based on our experience last week, Mike has proposed some changes to our
backups of the database including more frequent tape changes.  I have a
couple of other suggestions that I'll work with Mike on implementing when
we move to atu over the next two weeks.  (However, with the RAID, this
should be much less of a problem.)

In addition to traditional tape backups, I would like to rotate through
a set of 5 to 7 exports of the database done on a daily basis when the
lab is least active.  We may need to lock the database or shut down the
servers briefly to insure consistent data.  The advantage to exports is
that we could quickly move to any machine, check out all the Coral source 
and compile it (if necessary), run the sql scripts (lab_dba, lab_db) to
create the managers and tablespaces, and do an import.  I suspect this
may be faster than a restore from tape and may be less dependent on the
configuration of the file system and disk partitions.  I would also propose
that we back the exports up to tape.  If done carefully, this could allow
us to return to a snapshot of the database at almost any regular interval
(in case of undetected corruption).

The other item is related to tape backups.  Based on recent experience,
I fear that our current tape backups may be inconsistent if done without
shutting down the Oracle database server.  We had asssumed that we were
ok because we did not get open file errors.  However, with control files 
and redo logs, it is possible to get no open file errors, but still have
the database in an inconsistent state.  So we need to revisit this issue.

Thanks,
Bill 




More information about the coral mailing list