Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> c.d.o.server -> Backup and Recovery

Backup and Recovery

From: <>
Date: 7 Nov 2005 04:30:10 -0800
Message-ID: <>


unfortunately I don't know enough about backup and restore of an Oracle database. I know, keep your hands away from this topic when you don't know enough!

But I'm forced to develop a "strategy" to backup the database, and I'd like to know whether it works what I'm suggesting to the implementing DBA's...

Our system:

2-CPU-Hp/UX-machine (64 bit)
Oracle 10g (database in ARCHIVELOG mode)

The database contains 12 completely different and separate schemas (for 12 customers) where each customer has its own set of tablespaces which are used solely by him.
Each customer has a different "monthly" production, i.e. all of his tablespaces are read-only for almost whole month, then we produce new data and add them within 6 hours (tablespace set to read-write, add data, tablespace set to read-only).

The first customer has its monthly production on the 1. of each month, the second customer a day after, etc..., so at the 12. of each month we are finished.

I'd like to do the following:
1. Make an "almost full backup" of the database, i.e. a full backup without any customer specific tablespace (i.e. only the SYSTEM, SYSAUX, ADMIN tablespace, TEMP tablespace, control file, etc.). 2. For each customer: Make a backup for the customer right after the new monthly data has been produced (on the read-only tablespaces) using the transportable tablespace feature.

So is it possible to do (1)? I.e. is it possible to make a "partial full backup"? Actually, I know it's possible to backup, but the problems arise when we'd like to restore Are we able to restore the database and tell Oracle during restore that it should not care about missing data files for tablespaces? From the control file Oracle knows that there are tablespaces and their datafiles, but we'd like to "reconstruct" them later on using the transportable tablespace feature...

>From what I've written one could ask why we actually want (1): Well,
it's because view defintions, sequence definitions, packages, functions, procedures, types, grants, users, their passwords, etc. are all stored in the data dictionary, thus NOT in the tablespaces of a customer schema, thus won't be restored by the TT mechanism...

Best regards,
  Alex Received on Mon Nov 07 2005 - 06:30:10 CST

Original text of this message