oracle foreign key primary key constraints performance tuning MTS IOT 9i block size backup rman corrupted column drop rename recovery controlfile backup clone architecture database archives export dump dmp duplicate rows extents segments fragmentation hot cold blobs migration tablespace locally managed redo undo new features rollback ora-1555 shrink free space user password link TNS tnsnames.ora listener java shutdown sequence

1. Real Life Recovery:
Perspective, Preparation &
Performance
RMOUG Training Days ‘99
Daniel W. Fink
7S Consulting, Inc.

2. Introduction
Perspective
Shifting the Paradigm
Preparation
Decision-making and Practice
Performance
Executing the recovery

3. Perspective
Traditional New
• Focus is on • Focus on properly
backing up the recovering a
database database
• Technology Staff • Business staff
makes decisions makes decisions
• If you care about • Backup &
data, use Recovery strategy
archiving is a business
exercise

4. Cost v. Lost Revenue
Model
Business process
Balance Costs against Risks
Educated decision-making
Clear, documented understanding
of what is possible, probable and
what is not

5. Educate Users
Identify the appropriate decision-
makers
Oracle 101
• Transactions and related structures
• Types of backups, archiving and
recoveries

6. Set Boundaries
Budget
• Time
• Money
Pick 2
• Good
• Fast
• Cheap
Allowable data loss/downtime

7. Service Level Agreement
Backup Procedures
• Type
• Frequency
• Storage policies
Data loss & downtime
• Allowable
• Expected
Anticipated Scenarios
Contact Points

8. Backup Principles
Never have 2 points of failure
Never backup a file to the same physical
device or controller
Always have at least 3 control files
Redo Logs should be multiplexed at the Oracle
level
Archived redo logs must be backed up to at
least 2 separate tapes
OFA Installation eases backup management

9. Backups
Offline (cold)
Online (hot)
Logical (export)

10. Offline Backup
Benefits Costs & Risks
• Easy to implement • Database is down
• Copy direct to if process fails
tape • Cannot detect
• Can be performed datablock level
as part of system corruption
backup
• Not all
tablespaces must
be backed up

11. Online Backup
Benefit Costs & Risks
• Required for 24x7 • Additional disk
Systems and processes
• Database is up if required
process fails • More difficult to
implement
• Special care
required if
database crashes
• Cannot detect
datablock level
corruption

12. Logical Backup
Benefits Costs & Risks
• Easy extraction of • Cannot be used to
individual objects recover
• Can expose data transactions
corruption • Requires target
• Useful for database to insert
upgrades, objects
database • Cannot backup
copies/moves complete
database

13. No Archiving
Benefits Costs & Risks
• Default state of • All data since last
database backup is lost
• Minimal • Restoration
management & requires all
performance database files
impact

14. Archiving
Benefits Costs & Risks
• Transactions can • Increased
be recovered management
• Only affected files • Additional disk
must be restored and processes
• Required for
Online backups
Optional for
Offline backups

15. Restore
Copying files required for instance
restart or database recovery
If final state of recovery process,
committed transactions since last
backup are lost

16. Recover
Apply committed transactions
since last backup
• Automatic - using redo logs
• Manual - using keyboard or other
source for data
Database returned to state after
last backup/before failure

17. Rebuild & Reload
Using export or source data to
recreate the database
Appropriate for non-volatile
databases

18. Practice, Practice, Practice
Only method of verifying backup
procedure effectiveness is to
perform several different
recoveries
The first performance should not
be on a live, down database
Titanic Syndrome - No backup is
‘unsinkable’

19. Recovery
Follow established guidelines
Take time to do it right the first time,
there may not be a second!
Have the Right people in the Right place
at the Right time
Double-check and document each move
If time and circumstances permit,
backup database before attempting
recovery

20. Stop Panicking
Calm is critical, don’t make a
mistake by being too hasty
Accept the pressure of downtime
Refer to documented steps for
each type of anticipated failure
• Loss of disk or other hardware
• Loss of datafile, redo log, archived log,
controlfile
• Loss of table

21. Identify Cause of Failure
Differentiate between symptoms
and causes
Know how to determine if problem
is internal or external to Oracle

22. Correct Cause of Failure
If the failed component can be
replaced, e.g. new disk, a spare
should be easily accessible
Be prepared to bypass the failed
component
Restoring files to a bad disk will
require another recovery

23. Restore affected files
Restore only those files to be
recovered, this will minimize
downtime
If no archiving is being done, all
files must be restored

24. Perform proper recovery
Cause of failure usually determines
the type of recovery
Complete - up to the point of
failure
Incomplete - prior to point of
failure
• Required if hole exists in archive logs
• Know when failure occurred for time-
based

25. Post-mortem
Number 1 issue - What could have
been done to prevent failure and
minimize downtime and data loss?
Document recovery execution and
critique
Recovery caused by preventable
scenario is a waste of valuable
time

26. Conclusion
Shift the focus
Practice, Practice, Practice
Don’t Panic
For more information,
www.orcldba.com