Real liferecoverypresentation
- 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