Causes of Unplanned Down Time
Software Failures
o Operating system
o Database
o Middleware
o Application
o Network
Hardware Failures
o CPU
o Memory
o Power supply
o Bus
o Disk
o Tape
o Controllers
o Network
o Power
Human Errors
o Operator error
o User error
o DBA
o System admin.
o Sabotage
„h Disasters
o Fire
o Flood
o Earthquake
o Power failure
o Bombing
Causes of Planned Down Time
Routine Operations
o Backups
o Performance mgmt
o Security mgmt
o Batches
Periodic Maintenance
o Storage maintenance
o Initialization parameters
o Software patches
o Schema management
o Operating system
o Middleware
o Network
New deployments
o HW upgrade
o OS upgrades
o DB upgrades
o MidW upgrades
o App upgrades
o Net upgrades
Minimizing Unplanned Downtime Guidelines
Use RAID data storage with mirroring ( 1+0 is a good choice).
Maintain offsite storage of your backups with a reliable vendor. Make is part of your
recovery testing program.
Normally, for a production database, operating in Archivelog mode is a must.
Multiplex the control files on separate disk drives managed by different disk controllers.
Oracle strongly recommends that you multiplex the redo log file.
After every major structural change, back up the control file. You can take backup of the
control file every hour.
If you backup to a tape, backup to two copies. The media might be defective.
Make auxiliary files part of your backup: (SPFILE) or the init.ora, sqlnet.ora,
tnsnames.ora, password and wallet files.
Log your backup operations.
Make every application has its own tablespace.
Use Data Pump utility for supplemental protection.
Make a plan to make sure that the backups are actually readable and valid.
Make database recovery testing plan.
Always keep a redundancy set online (use flash recovery area for this purpose) so you can recover faster. A redundancy set has:
Software Failures
o Operating system
o Database
o Middleware
o Application
o Network
Hardware Failures
o CPU
o Memory
o Power supply
o Bus
o Disk
o Tape
o Controllers
o Network
o Power
Human Errors
o Operator error
o User error
o DBA
o System admin.
o Sabotage
„h Disasters
o Fire
o Flood
o Earthquake
o Power failure
o Bombing
Causes of Planned Down Time
Routine Operations
o Backups
o Performance mgmt
o Security mgmt
o Batches
Periodic Maintenance
o Storage maintenance
o Initialization parameters
o Software patches
o Schema management
o Operating system
o Middleware
o Network
New deployments
o HW upgrade
o OS upgrades
o DB upgrades
o MidW upgrades
o App upgrades
o Net upgrades
Minimizing Unplanned Downtime Guidelines
Use RAID data storage with mirroring ( 1+0 is a good choice).
Maintain offsite storage of your backups with a reliable vendor. Make is part of your
recovery testing program.
Normally, for a production database, operating in Archivelog mode is a must.
Multiplex the control files on separate disk drives managed by different disk controllers.
Oracle strongly recommends that you multiplex the redo log file.
After every major structural change, back up the control file. You can take backup of the
control file every hour.
If you backup to a tape, backup to two copies. The media might be defective.
Make auxiliary files part of your backup: (SPFILE) or the init.ora, sqlnet.ora,
tnsnames.ora, password and wallet files.
Log your backup operations.
Make every application has its own tablespace.
Use Data Pump utility for supplemental protection.
Make a plan to make sure that the backups are actually readable and valid.
Make database recovery testing plan.
Always keep a redundancy set online (use flash recovery area for this purpose) so you can recover faster. A redundancy set has:
- Last backup of all datafiles
- Last backup of the control file
- Multiplexed copies of the current redo log files
- Copies of the current control file
- The archived redo logs since the last backup
- Auxilary files: SPFILE or the init.ora, listener.ora, and tnsnames.ora, pwsd