Deploying Oracle Standby Database for Maintaining Redundancy

Oracle’s physical standby database functionality was introduced in Oracle 7.3 to provide database redundancy. In later on versions of Oracle, this concept has been extended to include support for a logical standby database, the enhanced feature is called Oracle database Guard.

This concept of a physical stand-in site is simple – keep a copy of the data files at a second location, ship the redo logs to the second site as they are filled, and apply them to the copy of the database. This process keeps the standby database “a few steps” behind the primary database. If the primary database site fails, the standby database is opened and becomes the production database. The potential data loss is limited to the transactions in any redo logs that have not been shipped to the secondary site.

This physical secondary database can be opened only for read-only access. You can use read-only access to offload reporting, such as end-of-day reports, from the primary server to secondary server. The ability to offload requests provides flexibility for reporting and queries, and it can help performance on the primary server, while making use of the standby site.

While the standby database is being used for reporting, the archived redo information from the primary site is not applied. Recovery can continue then the standby database is closed again. This factor has important implications for the time it will take to recover from an outage with the standby database. If the primary site fails while the secondary site is open for reporting, the archived redo information from the primary database server that accumulated while the secondary database was querying must be applied before the stand-in site is brought online. This application of archived redo information increases the duration of the outage. You will need to weigh the benefits of using the secondary site for reporting against the recovery time and the duration of the outage should a failure occur while archived redo information is not being applied at the stand-in site.

Once a standby database is opened for read/write access, as opposed to read-only access, it can no longer be used as secondary server and you cannot resume applying archived redo information later. The stand-in site must be reconfigured from the primary database if it is opened accidentally in read/write mode.

The Oracle data guard broker provides monitoring and control for physical and logical secondary server and components. A single command can be used to perform fail-over. Oracle Enterprise Manager provides a data guard manager GUI for setting up, monitoring, and managing the stand-in db server tasks.

Source by Gitesh Trivedi

Leave a Reply

Your email address will not be published. Required fields are marked *