Automated Standby Database

To set up a standby database in Oracle using the process of Fast-Start Fault Recovery, follow these high-level steps:

1. Prepare the Primary Database:
   • Ensure the primary database is running in ARCHIVELOG mode, as this is necessary for creating a standby database.
   • Configure the primary database initialization parameters to support the standby setup, such as `DB_NAME`, `DB_UNIQUE_NAME`, and `LOG_ARCHIVE_CONFIG`.
2. Enable Forced Logging:
   • Activate forced logging by executing `ALTER DATABASE FORCE LOGGING;` to ensure all changes are logged and available for the standby database.
3. Configure Standby Redo Logs:
   • On the primary database, add standby redo log files. These are similar to online redo logs but are specifically for standby databases.
4. Create a Standby Control File:
   • Generate a standby control file from the primary database using the `ALTER DATABASE CREATE STANDBY CONTROLFILE AS 'filename';` command.
5. Transfer Necessary Files:
   • Copy the standby control file, all data files, and archived redo logs to the standby system.
6. Set Up the Standby Database Initialization Parameters:
   • Configure the standby database initialization parameters, such as

     `FAL_SERVER`, `FAL_CLIENT`, `STANDBY_FILE_MANAGEMENT`
     

     , and ensure `DB_UNIQUE_NAME` is different from the primary database.
7. Start the Standby Database in NOMOUNT State:
   • Start the Oracle instance for the standby database without mounting it.
8. Mount the Standby Database:
   • Mount the standby database using the standby control file created earlier.
9. Configure Recovery Processes:
   • Configure the managed recovery process with

     ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 
     DISCONNECT FROM SESSION;
     

10. Configure Fast-Start Failover (Optional):
    • If using Oracle Data Guard, you can configure Fast-Start Failover to allow automatic failover to the standby database in the event of a primary database failure.
11. Regularly Verify Log Shipping and Apply Status:
    • Regularly check that redo logs are being shipped and applied correctly to the standby database using the `V$ARCHIVED_LOG` and `V$MANAGED_STANDBY` dynamic performance views.
12. Testing the Standby Database:
    • Test the standby database to ensure it is applying logs correctly and can be activated in case of a primary database failure.
13. Monitoring and Maintenance:
    • Implement monitoring for both the primary and standby databases to ensure they are in sync and the log apply services are functioning correctly.
14. Backup Strategy:
    • Establish a backup strategy for the standby database to ensure recoverability in case of a disaster.

These steps provide a broad outline of the process. For detailed instructions, consult the Oracle Data Guard documentation specific to your Oracle Database version and your operating environment. This will ensure that your Fast-Start Fault Recovery setup is robust, reliable, and adheres to Oracle's best practices.

In the event of a

1. power failure,
2. hardware failure, or
3. a physical disaster,

such as fire, flood, or earthquake, that causes an instance to crash, the automated standby database feature within Oracle can be a data lifesaver. While Oracle has provided the standby database feature for a number of years, the technology is significantly extended within Oracle8i. Copying or cloning the production database initially creates a standby database. As archived redo logs are generated on the production database, they are concurrently applied to the standby database. This allows the standby database to remain synchronized with the production database.

Prior to Oracle8i, the archived redo logs had to be manually transported or copied to the standby database and manually applied. With the automated standby database within Oracle8i, the archived redo logs are automatically transferred and applied. This eliminates the need for manual procedures to copy and transmit the redo logs and the need for the operator at the backup site to manually specify which logs to apply. Automating this process eliminates a potential source of human error and increases database and application availability. Up to four standby databases can be maintained in a constant state of media recovery through the automated application of archived redo log files from the primary site. The automated standby database resides at any location, taking over the processing from the primary production database, and providing nearly continuous database availability. In the event of a failure of the primary database, one of the standby systems can be activated, providing immediate system availability. Oracle provides the commands and internal verifications for the creation and maintenance of the standby databases. A standby database uses the archived redo log information from the primary database, so it is ready to perform recovery and go online at any time. When the primary database archives its redo logs, the logs must be transferred to the remote site and applied to the standby database. The standby database is therefore always one or two logs behind the primary database in time and transaction history.

The following are the steps involved in creating a standby database:

1. Make a copy of the primary init.ora file to create a standby init.ora file.
2. Obtain a list of datafiles within the production database by querying the V$DATAFILE system view.
3. Shut down your primary database cleanly.
4. Make a consistent backup of the datafiles of your primary database using an O/S utility.
5. Open the primary database and create the control file for your standby database.
6. Archive the current online redo logs of the primary database.
7. Transfer the standby database control file, archived log files, and backed up datafiles to the standby site/host using operating system commands.

Archiving the current online redo logs ensures consistency among the datafiles, the control file, and the redo log files.

The following steps are involved in placing the standby database in manual recovery mode:

1. Configure the initialization parameters for the standby site
2. Start the standby instance and mount it in standby mode
3. Transfer the archived redo logs to the desired location on the standby host
4. Place the standby database in managed recovery mode

The standby database can be on the same host as the production database or can be on a different host. It is recommended to have the same file structure on the standby database host as in the primary database host.

Moving archived files to either a local or remote host, where the standby database resides, is automated with Oracle8i. Oracle keeps the standby database synchronized with the primary database by waiting for archived logs from the primary and then automatically applying them to the standby. This feature eliminates the need for manually providing the recovery process along with the filenames of the archived logs. For details on operating system changes for creating a standby database, please refer to Oracle’s Operating system-specific manuals. For details on creating a standby database on a different host machine or with a different directory structure, refer to Oracle Backup and Recovery Documentation. The next lesson explains more about read-only databases.