Not sure how to do this with Enterprise Manager, but here's how to do it manually:
Pre-requisites for a 24x7 backup/recovery scenario:
a) Gather requirements FIRST. Given the following situations, what is the maximum allowable downtime (if any) during recovery: computer blows up, hard disk crashes, superuser deletes critical file, user deletes rows in table by mistake
b) Learn and understand what the critical files in an Oracle database are, and document how you intend to back them up and recover them for each scenario so that you satisfy the requirements. Document this carefully!
The critical files are:
a) Control files. These contain information about the other datbase files. They can be multiplexed automatically by Oracle.
b) Log files. These contain log-entries for all changes made to database structures. They can be multiplexed automatically by Oracle.
c) Data files. These contain the actual database.
d) Configuration/parameter files. These are simple textfiles that can be recreated manually if needed. init.ora is only used during database startup. tnsnames.ora, listener.ora are used by SQL*Net/Net8, etc.
e) Other files used by the server system. This is what's in your ORACLE_HOME directory and includes everything from shared libraries to error message files. The database won't start without them.
The basic technique used to backup and restore Oracle databases with no data-loss is as follows:
a) The database must be in archive-log mode. This means that every log file is saved and archived to a safe place.
b) A "snapshot" of the database files must exist. This can be either a cold backup (meaning the database is shut down), or a hot backup, meaning the database was open and in use during the backup).
c) A copy of a control file must exist
d) An init.ora parameter file must exist
e) The current and/or un-archived logfiles must exist
If all of these are true, the database can be rolled forward using the archived logs either to a point in time or to a global transaction or simply all the way to the last committed transaction in the current logfile.
Hot tip: Keep an up-to-date list of all of your critical files on a piece of paper on your wall. You will need this if for instance you have to use an old copy of a controlfile during recovery after you have moved datafiles around or renamed them.
How to take a hot backup:
a) Use SQL to ALTER DATABASE BEGIN BACKUP;
For each tablespace (steps b,c &d):
b) Use SQL to ALTER TABLESPACE xxx BEGIN BACKUP;
c) Copy the datafiles belonging to the tablespace somewhere
d) Use SQL to ALTER TABLESPACE xxx END BACKUP;
e) Use SQL to ALTER DATABASE BACKUP CONTROLFILE ...
f) Use SQL to ALTER DATABASE END BACKUP;
g) Copy all the config/param files
You can script this process, or better yet, write it in Pro*C so that you have full control over exception handling, parallel processing and parallel copying.
The worst thing that can happen is that your backup process fails halfway through without issuing the END BACKUP commands per tablespace and for the database. The next time the database is started, it will think that it needs recovery (and demand that you provide all the archived logs since the BEGIN BACKUP commands were issued).
How to recover:
Unfortunately that's beyond the scope of your question. But I have one piece of strong advise: practise! Document what you intend to do, verify it, and time it. The backup method described earlier does NOT protect you against a machine failure - only media failure (disk crash).
The Oracle DBA manual "Media Recovery" section is strongly recommended reading!
Related topics: Oracle parallel server on clusters, hot standby systems, high availability hardware solutions.
Main Topics
Browse All Topics





by: oakPosted on 1998-12-31 at 10:43:37ID: 1083523
Edited text of question