Siebel Deployment Planning Guide > Data Integrity and Capacity Planning >

Database Recovery Planning

Follow the RDBMS vendor's recommendations on configuring the database for recovery in case of data corruption, hardware failure, or disaster.

Oracle Database Recovery Planning

Many companies today use RAID storage systems that make Oracle Database online redo log mirroring unnecessary.

If your organization does not use RAID storage systems, then mirror the redo log, at a minimum, because the redo log is essential when a database goes through failure recovery.

Also, when redo logs are mirrored at the RAID storage system level (usually RAID 1 or RAID 0+1), there is usually no need to mirror them at the Oracle Database level, since the RAID controller assures that these volumes can always be recovered. Mirroring at the RAID level usually improves database performance (especially beneficial for read operation).

If you have the resources, then mirror the Oracle Database control files as well. Otherwise, you can put the Oracle Database control files into a RAID 5 device, as it is not heavily accessed and disk performance is not a concern. The information it records, though, is very critical for Oracle Database. Any updates to the control file, such as the current System Change Number (SCN) or transaction tables, ripple across all of the members of the control file specification.

IBM DB2 Recovery Planning

Mirror the transaction log to guarantee database recovery if a single device fails. You must mirror the instance home directory, if resources are available. Hardware or operating system mirroring generally provides the best performance.