Conference ulysse::rdb_vms_competition

602.0. "Oracle backups" by BEAGLE::GODFRIND (Would you trust Gorbatchev with SETPRV) Wed Mar 28 1990 13:31

This was posted recently in the comp.databases newsgroup. It talks about
deficiencies in the way Oracle handles multi-tape backups and incrementals.

/albert

Article          894
From: [email protected] (Cynthia Mumford)
Subject: Re: Database Backup/recovery techniques?
Organization: Data-Prompt, Silver Spring, MD
 
[quotes deleted]
 
  We are running Oracle Versions 6.0.26 and 6.0.27 on an Amdahl 5860 under
UTS 1.2.3. (soon to be UTS 2.0.1). Currently we have 5 databases:
1 for development, 1 for conversion, 1 for QA, and 2 for production. The
conversion and production databases are each about 2.5 gigabytes. Growth of
the production databases is estimated conservatively at 9 gigabytes per
year.
  Our worst problems currently have been with the backup of the
conversion database. Our backup utilities will not allow a single file to 
span multiple tape volumes, but in order not to exceed the UTS 1.2.3 
limit of 20 open files per process we have had to make the data files 
very large. Oracles's export utility is deficient in its handling of
exports which span multiple tape volumes. Therefore, we had a couple of 
alternatives: split the export into small enough files (doing it table
by table) so that could back up the files, or use a very operator-
intensive and error-prone method based on the volcopy command.  Since
the conversion data was not updated daily, it was agreed that we would
back up on demand and use volcopy. This solution would not be feasible
in a production environment requiring daily backups.
  On the topic of incremental backups, Oracle's version 6.0.26 supposedly
provides that capability. However, their definition of incremental leaves
something to be desired.  If the table has been modified since the last
backup, the entire table will be part of this "incremental" backup. There
is no capability to back up only changed records. On a table containing
millions of records -- an accounting journal, for example -- this does not
do much good. As a matter of fact, we could have written this ourselves. For
this we're paying all this money??
 
  We would also be very interested in any information on backups of large
databases -- actually, any information at all on management and 
administration of large databases.
 
Cindy Mumford
DBA 
Data-Prompt, Inc.
cindy@ uunet!dprmpt