1. Oracle backup and recovery strategy
Catherine Delamare /IT DB
I will now present a brief overview of the Oracle backup and recovery strategy.
Taking backups of an Oracle database is similar to buying insurance on your car: you won’t realize the importance of it unless you get into an accident and the amount of coverage depends on the policy you have got.

2. AGENDA Why plan backups? Overview of backups
Backup implementation in IT/DB
Export/Import
Recovery
We'll warm up by reviewing the motivations behind backup planning and implementation.
We'll then present the different kinds of backups, broadly
categorized into PHYSICAL and LOGICAL backups
We'll then explain one important decision that an Oracle
Database Administrator has to make, which is whether to
run the database in ARCHIVELOG mode or not.
We'll then focus on the backup strategy we have adopted
here and how it is implemented
The last point will present export/import,

3. Why plan backups?

4. Why plan backups? Hardware never fails Oracle never makes a mistake
Users never make mistakes
Programmers never make mistakes
Physicists never make mistakes
Database administrators (DBAs) never make mistakes
Why plan backups?
As you already know, backups are copies of the database that can be used in the event of an accident that causes loss of data.
In other words, the restoration of an Oracle database depends on the presence of these backups.
The word accident may cover a range of various failures,
including:
-media failures, typically a disk crash
In order to protect against disk failure, we use disk mirroring on most machines; but this data redundancy does not protect you against the other failures:
-software failures, commonly known as software bugs. their origin might be the operating system, the database software or the application software.
-human errors
To err is human and DBAs as well as developers can inadvertently delete a database component.
While we may not be able to predict these accidents,
we must be prepared for outages that they cause.
Let's now survey the various backups that can be performed
on an Oracle Database.

5. Why plan backups?
The only insurance you have against failures causing loss of data:
Human errors
Hardware failures
Power failures
Software errors
DBA’s job security!
Why plan backups?
As you already know, backups are copies of the database that can be used in the event of an accident that causes loss of data.
In other words, the restoration of an Oracle database depends on the presence of these backups.
The word accident may cover a range of various failures,
including:
-media failures, typically a disk crash
In order to protect against disk failure, we use disk mirroring on most machines; but this data redundancy does not protect you against the other failures:
-software failures, commonly known as software bugs. their origin might be the operating system, the database software or the application software.
-human errors
To err is human and DBAs as well as developers can inadvertently delete a database component.
While we may not be able to predict these accidents,
we must be prepared for outages that they cause.
Let's now survey the various backups that can be performed
on an Oracle Database.

6. Why plan backups?
This slide is a brief reminder of the Oracle Architecture with a perspective on backup and recovery.
You can see here the DATA FILES which make up the physical repository for all the data in the database.As the database grows and more space is needed, the DBA needs to create and add more data files to the database. These data files are a major concern for backup and space management.
The REDO LOG files are used by Oracle to record changes made to the database.Since these files are open, or online during normal operation of the database,they are called the “online redo log files”.Oracle DBAs have the choice to run the database in ARCHIVELOG mode or NOARCHIVELOG mode.In ARCHIVELOG mode, contents of the online redo log files are copied to an archive area by one of the Oracle background processes.We’ll come back to that.
The control file is a very important piece of the database.This file contains the whole schema of the database: names,location,status and states of all the datafiles and online redo log files.

7. Overview of backups Physical backups Logical backups (or “exports”)
protect against global failure
Cold backups : database needs to be stopped
Hot backups : database keeps on running
Logical backups (or “exports”)
protect against deletion of (a) table(s)
can be run by the user himself
Backups can be broadly categorized into -physical backups and -logical backupsIn a physical backup, the underlying physical files building up the database are copied from disk to disk or from disk to tape. With Oracle, the physical backups can be either "cold" or "hot".The "cold" backup, or "offline"backup, involves shutting downthe Oracle database and backing up all required Oracle database files.The other physical backup is the so-called "hot" or "online" backup, which is taken while the Oracle database is up and running.To be able to run such online backup, the oracle database must be operated in a special mode, called ARCHIVELOG mode, which we will explain in the next slide.This backup mechanism provides "point-in-time" recovery,namely complete recovery up to the very moment of the failure.Let's now switch to the logical type of backup:The logical backup, or EXPORT, creates a logical image ofthe database objects and stores them in a binary file.Unlike physical backups, the EXPORT utility actually readsthe data in the objects using SQL and stores the data in
the binary file.The IMPORT utility uses this file to restore these particular database objects back into the database.A LOGICAL export can be run on a running database,and an export of a table will give a read-constitent view of the table at the time the export was initiated.Any changes made to the table during the export will not be incorporated into the EXPORT file.

8. ARCHIVELOG Mode or not? (1/3)
Definition
All changes are kept in “archived logs”
The more activity, the more archived logs
Central db: 600 logs per week (30M each=18G transactions volume per week)
Advantages of ARCHIVELOG mode
Complete recovery up to the last committed transaction before the failure (“point-in-time” recovery)
Mandatory for mission-critical applications
Pre-requisite to run hot backups
Let's now explain the ARCHIVELOG mode of an Oracle database: Oracle records all changes made to the database in specific files called the online redo log files;
In the default mode which is non ARCHIVELOG mode,
these files are used in a cyclic way; in other words, the past changes made to the database are no longer available in the log files.
If the database is configured to run in ARCHIVELOG mode,
the redo log files are saved on disk before being overwritten
by the next changes.Once saved on disk, they are called the
"archived redo log files".
The main advantage of running in ARCHIVELOG mode
allows you to perform a so-called "point-in-time" recovery;
in other words, it allows to completely recover the database
without losing any data.
This is done by using the physical backup (offline or online)
and re-apply on them all changes stored in the archived
redo log files.
If you don't run in ARCHIVELOG mode,you can restore the database from a backup in case of failure, but cannot roll
forward from that point.
For example, let's assume that you take a cold backup of
the database every Sunday night and run the database in
NOARCHIVELOG mode.
Let's further assume that a media failure occurs on Friday and all the database files are lost.The only option is to
restore the database from Sunday night's backup and restart
the database.All the transactions done between Sunday and
Friday are lost.
With ARCHIVELOG mode, all these transactions could be re-applied, no data would be lost.
The other advantage of ARCHIVELOG mode is to allow
"online backups".This allows users to use the database while backup of the database is being performed.
For mission-critical applications where where loss of data is not acceptable, the ARCHIVELOG mode is highly recommended by Oracle.
This secure mode still comes at a price:
Additional disk space is required to store the archived log
files.
More importantly, the critical side-effect of the ARCHIVELOG
mode is that if the log files accumulate and fill
the archived destination, the database will simply hang.
Adequate tape facilities are used to store the redo log files
and free space on disk.
In other words, the ARCHIVELOG mode gives more work to the DBA, mainly space management and log file tracking.

9. ARCHIVELOG Mode or not? (2/3)
Sunday
Friday
Let's now explain the ARCHIVELOG mode of an Oracle database: Oracle records all changes made to the database in specific files called the online redo log files;
In the default mode which is non ARCHIVELOG mode,
these files are used in a cyclic way; in other words, the past changes made to the database are no longer available in the log files.
If the database is configured to run in ARCHIVELOG mode,
the redo log files are saved on disk before being overwritten
by the next changes.Once saved on disk, they are called the
"archived redo log files".
The main advantage of running in ARCHIVELOG mode
allows you to perform a so-called "point-in-time" recovery;
in other words, it allows to completely recover the database
without losing any data.
This is done by using the physical backup (offline or online)
and re-apply on them all changes stored in the archived
redo log files.
If you don't run in ARCHIVELOG mode,you can restore the database from a backup in case of failure, but cannot roll
forward from that point.
For example, let's assume that you take a cold backup of
the database every Sunday night and run the database in
NOARCHIVELOG mode.
Let's further assume that a media failure occurs on Friday and all the database files are lost.The only option is to
restore the database from Sunday night's backup and restart
the database.All the transactions done between Sunday and
Friday are lost.
With ARCHIVELOG mode, all these transactions could be re-applied, no data would be lost.
The other advantage of ARCHIVELOG mode is to allow
"online backups".This allows users to use the database while backup of the database is being performed.
For mission-critical applications where where loss of data is not acceptable, the ARCHIVELOG mode is highly recommended by Oracle.
This secure mode still comes at a price:
Additional disk space is required to store the archived log
files.
More importantly, the critical side-effect of the ARCHIVELOG
mode is that if the log files accumulate and fill
the archived destination, the database will simply hang.
Adequate tape facilities are used to store the redo log files
and free space on disk.
In other words, the ARCHIVELOG mode gives more work to the DBA, mainly space management and log file tracking.
BACKUP
CRASH 1 2 3 4 5

10. ARCHIVELOG Mode or not? (3/3)
ARCHIVELOG mode implications:
Additional overhead (even more overhead during online backup)
Oracle hangs if the archived disk fills up
Archived logs must be kept in a safe place
Tape facilities implied
More work for the DBA:
Space management
Log files tracking
Let's now explain the ARCHIVELOG mode of an Oracle database: Oracle records all changes made to the database in specific files called the online redo log files;
In the default mode which is non ARCHIVELOG mode,
these files are used in a cyclic way; in other words, the past changes made to the database are no longer available in the log files.
If the database is configured to run in ARCHIVELOG mode,
the redo log files are saved on disk before being overwritten
by the next changes.Once saved on disk, they are called the
"archived redo log files".
The main advantage of running in ARCHIVELOG mode
allows you to perform a so-called "point-in-time" recovery;
in other words, it allows to completely recover the database
without losing any data.
This is done by using the physical backup (offline or online)
and re-apply on them all changes stored in the archived
redo log files.
If you don't run in ARCHIVELOG mode,you can restore the database from a backup in case of failure, but cannot roll
forward from that point.
For example, let's assume that you take a cold backup of
the database every Sunday night and run the database in
NOARCHIVELOG mode.
Let's further assume that a media failure occurs on Friday and all the database files are lost.The only option is to
restore the database from Sunday night's backup and restart
the database.All the transactions done between Sunday and
Friday are lost.
With ARCHIVELOG mode, all these transactions could be re-applied, no data would be lost.
The other advantage of ARCHIVELOG mode is to allow
"online backups".This allows users to use the database while backup of the database is being performed.
For mission-critical applications where where loss of data is not acceptable, the ARCHIVELOG mode is highly recommended by Oracle.
This secure mode still comes at a price:
Additional disk space is required to store the archived log
files.
More importantly, the critical side-effect of the ARCHIVELOG
mode is that if the log files accumulate and fill
the archived destination, the database will simply hang.
Adequate tape facilities are used to store the redo log files
and free space on disk.
In other words, the ARCHIVELOG mode gives more work to the DBA, mainly space management and log file tracking.

11. Offline backup (COLD) Database must be down
Backup of all datafiles, redo log files and control files
Disk space needed

12. Benefits of offline backup
Best guarantee for a restartable database (Oracle recommends a weekly cold backup)
Quick recovery (by replacing all datafiles, redo log files and control files by their backup version)

13. Drawbacks of offline backup
Database must be down
Loss of data between backup and failure if not using ARCHIVELOG mode
Corruption may not be recognized!
Might not backup everything: Backup scripts must be often checked and tested!

14. Online (hot) backup
Meaningful only if database is operating in ARCHIVELOG mode: if not, hot backups are useless for recovery
Database must be up and open
Do a favor to users, schedule it during off hours
The unit of an online backup is a tablespace

15. Benefits of online (hot) backup
Database remains available
Control over what to backup and when
Not all tablespaces need to be backed up at the same time

16. Drawbacks of online (hot) backup
Setup and administration is more complex
Leading cause of recovery problems

17. Online backup procedure
ALTER TABLESPACE tsp BEGIN BACKUP
Copy/Backup all datafiles in the tablespace
ALTER TABLESPACE tsp END BACKUP
ALTER SYSTEM SWITCH LOGFILE
Backup archived log files
ALTER DATABASE BACKUP CONTROLFILE to ‘filespec’

18. Backups implementation (1/3)
Most production databases run in ARCHIVELOG mode
Archived redo logs stored on two different tape devices
Home-grown scripts perform
depending on the service:
daily/weekly cold/hot backup +
daily full export
The way we work with Oracle is based on ARCHIVELOG mode
on most production systems to allow complete recovery.
We have developed a collection of home scripts to store on tape the redo log files.
We copy each log file on two different tapes to enhance security:
the first channel is the IBM ADSM software,
the second channel is the in-house SHIFT software.
The main difference between ADSM and SHIFT is that
ADSM manages for you the tape name and location on tape,
whereas SHIFT does not.
In order to prevent the critical situation when the archive disk gets full, some home made monitoring scripts run in background and trigger GSM calls in case of problem.
Regarding the backup strategy, we run on all services a combination of physical backups (either cold or hot)
and logical (mostly every day).
The type of backup and frequency depends on the service level agreement.

19. Backups implementation (2/3)
On mission-critical systems :
Shutdown the oracle database
Detach the mirrors
Restart the database on one side => service interruption of the order of 1-6 minutes
Backup the frozen side
Reattach the mirrors
E.g.:central cluster, cryogenics, remedy,tape management and radio-frequency databases
On mission critical systems, we use the following approach
which performs a robust cold backup with only several
seconds of service interruption:
This technics requires to use commands inside the disk management tools provided by SUN: either Solstice Disk Suite or Volume Manager.
This approach is used for TMS, the Tape Management System,
cryogenics , remedy and radio-frequency databases.

20. Backups implementation (3/3)
On the central database cluster..
The 2 nodes synchronize a clean rundown of the common database
Node A detaches the database mirrors and restarts DB
Tells node B to restart as well
Performs a cold backup onto disks
Reattaches the mirrors
Service interruption: 6 minutes
Let's now take a closer look at the cluster running the central database service:
The cluster consists of two Enterprise 450 Sun machines;
these 2 independant nodes run the Parallel Server Option of
the Oracle software in order to coordinate access to the
shared databases residing on a D1000 based storage array.
I say "databases" because the cerndb and EDMS databases
coexist on the cluster.
The backup procedure of a cluster is a bit more complex than on a single instance configuration.
As a matter of fact,the 2 nodes have to synchronize the rundown of their common database; the secure protocol ssh is
used for that purpose.
The cold backup is then performed on node A which copies
the raw devices to local disks.
When the copy is finished, node A restarts its instance and
tells his counterpart to do so.
A backup onto tape via ADSM is then initiated.
The service interruption in total is about 15 minutes

21. Oracle EXPORT/IMPORT
The Export and Import Oracle utilities generate a file with a logical copy of the data and application
Export and Import are useful to recover specific items lost due to user errors
Export and Import help migration to different releases of the Oracle RDBMS
Export and Import support object types:
Export writes object type definitions and all of the associated data to the dump file. Import then re-creates items from the dump file.
As far as TYPES are concerned, the definition statements for derived types are exported.
On an import, a subtype may be created before the supertype definition has been imported. In this case, the subtype will be created with compilation errors, which may be ignored.
The type will be revalidated after its supertype is created.

22. EXPORT/IMPORT(cont’d)
Export and Import support object types
Export writes object type definitions and all associated data to the dump file
Import then re-creates these items from the dump file
The definition statements for derived types are exported, same applies to OIDs
Export and Import support object types:
Export writes object type definitions and all of the associated data to the dump file. Import then re-creates items from the dump file.
As far as TYPES are concerned, the definition statements for derived types are exported.
On an import, a subtype may be created before the supertype definition has been imported. In this case, the subtype will be created with compilation errors, which may be ignored.
The type will be revalidated after its supertype is created.

23. EXPORT (logical) Database must be up and running
Export reads the database using SQL
Export file contains create and insert statements
Export provides a Read consistent view of the database
Changes made after export begins are not included
Export and Import support object types:
Export writes object type definitions and all of the associated data to the dump file. Import then re-creates items from the dump file.
As far as TYPES are concerned, the definition statements for derived types are exported.
On an import, a subtype may be created before the supertype definition has been imported. In this case, the subtype will be created with compilation errors, which may be ignored.
The type will be revalidated after its supertype is created.

24. Benefits of export Easy to recover individual items Portable:
can be used to move data from one machine to another
useful in a heterogeneous environment
Unlike backup, export identifies physical data block corruption since it performs a full table scan while exporting a table

25. Drawbacks of export Does not provide point in time recovery
Export/Import are usually long processes.To improve speed:
import with ROWS=Y INDEX=N to restore data
then import with ROWS=N and INDEX=Y to build indexes

26. Export/import examples
Export of a full database (from a DBA): EXP FULL=Y FILE=fullexp.dmp LOG=fullexp.log
Export of a specific schema: EXP USER/PASSWORD TABLES=(RUN1,RUN2) FILE=runs12.dmp LOG=runs12.log

27. Recovery considerations
Media recovery:
Done in response to a RECOVERY command
Has to be done by a DBA after identifying the appropriate recovery action depending on the failure (datafile, tablespace, database)

28. Recovery in NOARCHIVELOG mode
Only offline backup (or export) can be used
What to do:
Restore all copies of datafiles, control files and redo log files
startup the database
You are back in the status when the backup (export) were run

29. Recovery in ARCHIVELOG mode
Only way to perform the point in time recovery
What to do:
Restore from backup the damaged Oracle files
Apply Redo log changes
Database recovery
Tablespace recovery
Datafile recovery

30. Benefits of recovery Database recovery can be complete or not:
recover database (complete)
recover database until time ‘ :10:05:00’
recover database until cancel
recovery of TABLESPACE or DATAFILE can only be complete

31. Implications of recovery
Database is not open to the users
It can take a long time depending on the number of redo log files to be applied.
Must have ALL required files (datafiles, archived redo log files).

32. SUMMARY
5 real cases of Oracle recovery have been performed in the past 7 years (Successful…)
Many items have been recovered from export files to repair accidental deletion of items
WHO WANTS TO TEST NEXT?