Lesson 9	Preserve your redo logs
Objective	Identify steps to preserve redo logs.

Oracle recommendations to perserve redo logs in Oracle

In Oracle Database Management Systems, redo logs are critical components for ensuring data integrity and enabling database recovery. Preserving redo logs is essential for several reasons: facilitating media recovery, enabling flashback operations, and satisfying compliance requirements, among others. Here are the sequential steps for preserving redo logs in an Oracle Database:

Configuration and Initialization Parameters
1. Define Log Retention Policy: Set the `FAST_START_MTTR_TARGET` or `LOG_CHECKPOINT_INTERVAL` initialization parameters to control how frequently redo log files are checkpointed and overwritten.
2. Set Archive Mode: If not already in ArchiveLog mode, switch the database to this mode to ensure that online redo logs are archived before they are overwritten. Execute the following commands in SQL*Plus after shutting down the database:
```
SHUTDOWN IMMEDIATE
STARTUP MOUNT
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;
```
3. Configure Archive Destinations: Set the `LOG_ARCHIVE_DEST` and `LOG_ARCHIVE_FORMAT` parameters to specify where and how the archived logs should be stored.
Monitoring and Management
1. Audit Current Redo Log Configuration: Use SQL queries against `V$LOG`, `V$LOGFILE`, and `V$ARCHIVE_DEST` to evaluate the current redo log setup.
```
SELECT * FROM V$LOG;
SELECT * FROM V$LOGFILE;
SELECT * FROM V$ARCHIVE_DEST WHERE STATUS='VALID';
```
2. Monitor Log Switches: Excessive log switching can have performance implications. Monitor the rate by querying `V$SYSSTAT`.
```
SELECT NAME, VALUE FROM V$SYSSTAT WHERE NAME = 'redo log space requests';
```
3. Check Disk Space: Regularly verify that adequate disk space is available for both online and archived redo logs.
Backup and Retention
1. Routine Backups: Conduct frequent backups of redo logs along with data files using RMAN (Recovery Manager).
```
rman> BACKUP ARCHIVELOG ALL;
```
2. Log Deletion Policy: Configure an RMAN retention policy to determine when archived logs can be safely deleted.
```
rman> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF X DAYS;
```
3. Offsite Storage: Consider storing a copy of crucial archived redo logs in an offsite location for disaster recovery purposes.
Purge and Rotation Strategy
1. Automated Purge: Utilize Oracle's automatic purging functionality to remove obsolete logs based on the retention policy.
2. Manual Deletion: If you must manually delete archived logs, use RMAN commands to ensure that the logs are removed consistently and safely.
```
rman> DELETE ARCHIVELOG UNTIL TIME 'SYSDATE-30';
```
Compliance and Documentation
1. Audit Trails: Maintain logs of all operations related to redo log management for auditing and compliance purposes.
2. Documentation: Keep detailed documentation of redo log configurations, backup schedules, and retention policies.
3. Review and Update: Regularly review and update strategies for redo log preservation, taking into account evolving business requirements and Oracle best practices.

By following this structured approach for preserving redo logs, you ensure that the Oracle database can recover from both minor and major failures, meet compliance requirements, and maintain data integrity. It is vital to monitor and periodically review the redo log preservation strategy to adapt to changing needs and potential optimizations.

Oracle Cloud DBA

Redo log files are critical to the process of recovering from a server crash. If you lose your redo log files during a server crash, perhaps due to a disk failure, you will not be able to recover the database. Because the redo log files are so critical, Oracle makes the following recommendations:

Multiplex your redo log files
Place redo log members on separate disks

Multiplexing your redo logs means to have the Oracle software write two or more copies of each log file. The following diagram illustrates a typical multiplexing situation:

Multiplexing redo log groups to have the Oracle software write 2 or more copies of each log file

Multiplexing redo logs: Oracle uses the term redo log group to refer to a multiplexed set of redo log files. Oracle writes the same information to each file in a group. In the above example, redo log files 1 and 2 form one group and contain identical information. Oracle uses the term redo log member to refer to the individual files. You will learn the actual steps that make up the multiplexing process later in the course. Right now you just need to understand why the multiplexing of the redo logs is important.
Placing redo logs on separate disks: Oracle's second recommendation is to place members of a redo log group on separate disks and this is critical. The whole reason for having two or more members in a group is so that you can recover if either of those disks fails. If all your redo log files are on one disk, and that disk fails, you have lost your database.