Standby Oracle Databases and Mission Critical Systems

There is a growing need to provide maximum availability of mission critical systems. Oracle provides several alternatives to help maintain high availability. One alternative is the use of standby databases. A standby database is a backup copy of your production database. It is maintained on an identically configured but different machine. The names of the disk drives, directory paths, and files should ideally be the same. As your production system runs, copies of the archive log files are saved to the secondary system and applied to the standby database at regular intervals. This means that the standby database is always a little behind the primary system because there is redo log information that isn't on the secondary system.
In the event of a failure, the secondary system can be activated and the standby database opened for use by your user community. The secondary system becomes your primary system and the standby database becomes your production database. Once the original primary system has been fixed, it can be used as the new secondary system maintaining your standby database.
While the standby database does not contain the most current data, it does maintain high availability with a minimal lose of data.

Oracle 11g provides several technologies and features that enable high availability. These technologies help minimize planned and unplanned downtime, provide redundancy, and ensure data consistency across systems. Some of the key high availability features in Oracle 11g include:

1. Real Application Clusters (RAC): RAC allows multiple instances of the Oracle database to run on different servers within a cluster. This provides high availability, fault tolerance, and load balancing. If one server fails, the workload is redistributed to the remaining servers in the cluster without any downtime.
2. Data Guard: Data Guard is a disaster recovery and data replication solution that maintains a standby database as a copy of the primary database. In case of primary database failure, the standby database can be quickly activated to take over the role of the primary database, ensuring minimal downtime and data loss.
3. Automatic Storage Management (ASM): ASM is a storage management solution that simplifies and automates the management of database storage. It provides features like disk mirroring, striping, and rebalancing to ensure high availability, performance, and fault tolerance.
4. Flashback Technologies: Flashback technologies enable administrators to recover from human errors or logical corruptions by quickly restoring the database to a previous point in time. Some of the Flashback features include Flashback Query, Flashback Table, Flashback Drop, and Flashback Database.
5. Fast Recovery Area (FRA): FRA is a centralized location for storing recovery-related files like archived redo logs, flashback logs, and control files. By managing these files in one place, FRA simplifies backup and recovery operations and helps ensure high availability.
6. Online Reorganization and Redefinition: Oracle 11g allows administrators to perform various maintenance tasks, such as reorganizing tables and rebuilding indexes, without taking the database offline. This helps reduce planned downtime.
7. Recovery Manager (RMAN): RMAN is a backup and recovery utility that automates and simplifies the process of creating, managing, and restoring database backups. It helps ensure data integrity and high availability by providing efficient and consistent backup and recovery operations.
8. Transparent Application Failover (TAF): TAF is a feature of Oracle's connection management that enables automatic failover of client connections to a surviving instance in case of instance failure, ensuring high availability and minimizing application downtime.

You can create a standby database by following these steps:

1. Backup the data files
2. Create the standby control file
3. Archive the current redo log files
4. Copy the standby control file, data files, and archived redo logs to the standby system
5. Bring the standby database up in nomount mode
6. Mount the database as a standby database
7. Apply the archived log files

Note: More information on standby databases is contained in the Oracle8 release documentation set.
The next lesson is the module wrap-up.