• Like
Real liferecoverypresentation
Upcoming SlideShare
Loading in...5
×

Real liferecoverypresentation

  • 157 views
Uploaded on

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 …

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

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
157
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
4
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Real Life Recovery:Perspective, Preparation &PerformanceRMOUG Training Days ‘99Daniel W. Fink7S 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 RevenueModel 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 PanicFor more information, www.orcldba.com