In this module, we discussed the manual and automatic archiving of your redo log files. You should now be familiar with the following concepts:
- Normal
ARCH processing
- Manual archiving of redo log files
- Automatic archive log file options
- Obtaining archive log information
- Standby databases
You can also review the init.ora parameters that were covered up to this point.
Standby databases in Oracle are used as part of a high-availability and disaster recovery strategy called Data Guard. Oracle Data Guard provides a robust solution for maintaining a synchronized copy of the primary database, ensuring data protection and minimizing downtime during planned or unplanned outages.
A standby database is a replica of the primary database, which is kept up-to-date by applying redo data received from the primary database. Standby databases can be used for several purposes:
- Disaster recovery: In the event of a disaster or a failure affecting the primary database, the standby database can be activated (known as failover) to take over the role of the primary database, minimizing downtime and data loss.
- High availability: Standby databases can be used to offload the primary database, improving performance and availability. For example, you can use a standby database for reporting, querying, or backups, reducing the load on the primary database.
- Data protection: Standby databases provide an additional layer of data protection by maintaining a synchronized copy of the primary database. In case of data corruption or human errors in the primary database, the standby database can be used as a source of truth to recover the lost or corrupted data.
- Planned maintenance: Standby databases can be used during planned maintenance activities, such as hardware or software upgrades, patching, or database migrations. You can perform the maintenance on the primary database while the standby database continues to serve the application, minimizing downtime.
There are two types of standby databases in Oracle:
- Physical Standby Database: A physical standby database is an exact, block-for-block copy of the primary database. Redo data received from the primary database is applied directly to the physical standby database. Physical standby databases are typically used for disaster recovery and high availability scenarios.
- Logical Standby Database:
| init.ora parameter | Description |
LARGE_POOL_SIZE | This is how you create the Large Pool. When the Instance starts, it allocates the requested memory in the SGA. |
LARGE_POOL_MIN_ALLOC | This is the smallest chunk that is allocated. |
ARCH_IO_SLAVES | This is the number of IO slaves used for log archiving. |
BACKUP_DISK_IO_SLAVES | This is the number of IO slaves used by RMAN for copy, backup, and restore. |
BACKUP_TAPE_IO_SLAVES | If True, then one IO slave is used to perform asynchronous IO to and from tape when doing an RMAN backup and restore. |
LOG_ARCHIVE_DEST | This parameter indicates where the archive log files will be written. |
LOG_CHECKPOINT_INTERVAL | This parameter causes a checkpoint when the specified number of OS blocks have been written to the redo log files since the last checkpoint. |
LOG_CHECKPOINT_TIMEOUT | This parameter causes a checkpoint when the specified number of seconds has elapsed since the last checkpoint. |
USER_DUMP_DEST | This is the directory that contains the output from your trace commands. |
LOG_ARCHIVE_DEST | This is the location for archive log files. |
LOG_ARCHIVE_FORMAT | This is the format of the name for the archive log files. |
LOG_ARCHIVE_DUPLEX_DEST |
This is the location for duplexed archive log files. |
LOG_ARCHIVE_MIN_SUCCESS_DEST | If your are duplexing your archive log files, this determines how many of the destination archive log files must succeed either 1 or 2. |
LOG_ARCHIVE_START | This starts automatic archiving of the redo logs when the instance starts. |