Backup and Recovery Configuration Notes

Pre-requisite Steps for Backup and Recovery Configuration

1. Configure for Maximum Recoverability:

o Remember to schedule backups frequently to ensure maximum recoverability.

o Determine the maximum recoverability time based on your data's criticality and
backup frequency.

2. Multiplex Control Files:

o By default, Oracle provides two control files. Consider adding a third control file on a
different disk with a different controller.

o Tip: Ensure control files are stored on separate disks to prevent data loss.

3. Multiplex Redo Log Groups:

o Create approximately three redo log groups, each with three files, stored on different
disk groups.

o Remember to keep the number of files in each redo log group balanced.

4. Enable Archive Log Mode:

o Ensure archive log mode is enabled to retain logs for recovery.

o Store archive logs in a readily accessible location for quick recovery.

Execution Steps

1. Configure Fast Recovery Area (FRA):

o Identify the area for storing backup and recovery files, known as the Fast Recovery
Area (FRA).

o Calculate the necessary storage space for FRA considering archive logs, backup files,
and potential growth.

o Remember to ensure the FRA size is adequate for storing backups, archive logs,
flashback logs, and control files.

2. Set DB_RECOVERY_FILE_DEST Parameter:

o Configure the DB_RECOVERY_FILE_DEST parameter to specify the FRA location. This

can be set during database creation or modified later.

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST = '/u02/backups/fast_recovery_area';

3. Calculate FRA Size:

o Estimate the size of your backups and plan for future growth.

o Monitor file growth over time to determine the average size.

4. Configure Retention Policy:

o Set up a retention policy for backups and archive logs to prevent indefinite retention.
 o Key Advice: Retain backups and logs for a few days before offloading to tape and
removing them from the physical system.

5. Monitor FRA Capacity:

o Continuously monitor the FRA to ensure it doesn't reach capacity.

o Remember to check reclaimable space regularly to manage archive log and backup
file retention.

Post-execution Steps

1. Monitor Recovery Area:

o Use the V$RECOVERY_FILE_DEST view to monitor FRA capacity and usage.

o Utilize GUI tools like Enterprise Manager Cloud Control for detailed monitoring.

2. Define Appropriate Retention Levels:

o Set and maintain retention levels for data stored in the FRA.

o Ensure reclaimable space is managed by writing data to tape and deleting it from
FRA when no longer needed.

3. Reclaimable Space Management:

o Manage reclaimable space by offloading archive logs and backup files to tape, then
deleting them from the FRA.
Key Points

 Remember: Frequent backups are essential for maximum recoverability.

 Tip: Multiplex control files and redo logs across different disks to prevent data loss.

 Remember: Configure and monitor the FRA size and capacity to avoid system halts during
backups.

Multiplexing Control Files and Redo Logs Notes

Why Multiplex Control Files?

 Remember: The control file is read by your database whenever it starts up.

 Key Role: Controls information about all of the files on your system.

 Purpose of Multiplexing:

o If one control file fails, you can use another copy to replace it.

o Multiple copies exist in different locations; if one is lost, the system can be recovered
using another copy.

o Benefit: Allows quick recovery by using identical copies.

Number of Control File Copies

 At least two control files are required; three is optional but not mandatory.

 Each copy should be on a different system disk controller.

  ASM (Automatic Storage Management): Oracle handles control file copies, requiring at least
two.

Handling Control File Loss

 If a control file is lost, the system may crash.

 Remember: Shut down the database in abort mode if control file loss occurs.

 Replace the corrupted control file with a good copy, then restart the database.

Multiplexing Redo Logs

Purpose of Redo Logs

 Redo logs store redo information when changes are committed in the database.

 Multiplexing Reason: Prevents single points of failure.

Number of Redo Log Members and Groups

 At least two members per redo log group.

 Multiple groups ensure continuous data recording and switching between groups as needed.

Steps to Multiplex Redo Logs

 1. Adding a New Member:

o Use Enterprise Manager Database Express, Enterprise Manager Cloud Control, or

command line.

2. Command Line Example:

o Add a new log member:

ALTER DATABASE ADD LOGFILE MEMBER '/u01/app/oracle/oradata/ORCL/redo1A.log' TO GROUP 1;

Enabling Archive Log Mode

Importance of Archive Log Mode
  Remember: Archiving ensures that you have a permanent copy of redo logs.

 Helps in performing recovery up to the current point in time.

Configuring Archive Log Mode

1. Switch Database to Archive Log Mode:

o Database must be in mount mode.

o Command to enable archive log mode:

ALTER DATABASE ARCHIVELOG;

ALTER DATABASE OPEN;

2. Setting Archive Destination:

o Default destination is the Fast Recovery Area (FRA).

o Use LOG_ARCHIVE_DEST parameter to specify the archive log destination:

ALTER SYSTEM SET LOG_ARCHIVE_DEST='/path/to/archive/logs';

Multiple Archive Log Locations

 Key Tip: Use LOG_ARCHIVE_DEST_N parameters for multiple archive log destinations.

 Recommended to have multiple locations across different disks.

Summary of Key Points

  Remember: Control files and redo logs should be multiplexed to prevent data loss.

 Important: Enable archive log mode to retain permanent copies of redo logs.

 Monitor and manage the Fast Recovery Area (FRA) to ensure sufficient space for backups and
logs.

 Ensure regular backups and have a clear recovery plan in place.

Real-Life Problem Scenarios

1. Scenario 1: Control File Corruption

o Problem: One of your control files is corrupted, and the database won't start.

o Solution:

 Pre-requisite Steps:

 Ensure you have a valid backup of the control files.

 Know the location of the good control file.

 Execution Steps:

 Shut down the database in abort mode:

SHUTDOWN ABORT;

 Copy a good control file to the location of the corrupted file:

cp /u01/app/oracle/oradata/ORCL/control01.ctl /u01/app/oracle/oradata/ORCL/control02.ctl

 Start the database:

STARTUP;

2. Scenario 2: Insufficient Space in FRA

o Problem: FRA is full, causing backup operations to halt.

o Solution:

 Pre-requisite Steps:

 Monitor FRA usage regularly.

 Have a plan for reclaiming space.

 Execution Steps:

 Check current FRA usage:

SELECT * FROM V$RECOVERY_FILE_DEST;

 Increase FRA size:

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE = '100G';

 Delete obsolete backup files:

RMAN> DELETE OBSOLETE;

3. Scenario 3: Archive Log Mode Configuration

o Problem: Database is not in archive log mode, risking data loss.

o Solution:

 Pre-requisite Steps:

 Ensure the database is in mount mode.

 Execution Steps:

 Switch to mount mode:

SHUTDOWN IMMEDIATE;

STARTUP MOUNT;

 Enable archive log mode:

ALTER DATABASE ARCHIVELOG;

ALTER DATABASE OPEN;

Configuring the Fast Recovery Area (FRA)

Pre-requisite Steps

1. Log in as SYSDBA:
 o Connect to your database as sysdba:

sqlplus / as sysdba

Execution Steps

1. Check Current FRA Configuration:

o Show the current settings for the database recovery file destination:

SHOW PARAMETER db_recovery_file_dest;

o This command displays two parameters:

 db_recovery_file_dest: The current destination for recovery files.

 db_recovery_file_dest_size: The size allocated for the recovery file

destination.

2. Increase FRA Size:

o Increase the size of the FRA to accommodate all backups and files:

ALTER SYSTEM SET db_recovery_file_dest_size = 30G SCOPE=BOTH;

o Key Advice: Set the scope to BOTH to address changes in both memory and the SP
File.

3. Verify Parameter Changes:

o Confirm the changes by displaying the parameters again:

SHOW PARAMETER db_recovery_file_dest;

Post-execution Steps

1. Monitor Recovery Area:

o Ensure the settings have taken effect and monitor the FRA to prevent reaching its
capacity.

o Remember: Regular monitoring of the FRA helps in managing space and ensuring
continuous operations.

Real-Life Problem Scenarios

4. Scenario 4: FRA Configuration Check and Adjustment

o Problem: Need to configure and verify the Fast Recovery Area settings.

o Solution:

 Pre-requisite Steps:

 Log in as sysdba.

 Execution Steps:

 Show current FRA settings:

SHOW PARAMETER db_recovery_file_dest;

 Increase FRA size:

ALTER SYSTEM SET db_recovery_file_dest_size = 30G SCOPE=BOTH;

 Verify the parameter changes:

SHOW PARAMETER db_recovery_file_dest;

Adding Another Control File to Your File System

(Multiplexing a Control file):
Pre-requisite Steps

First check the db is using spfile or pfile with command:

if in the value column there is address given then db is using a spfile otherwise pfile. Here it is using
spfile so we need to create a pfile from spfile using the same location where spfile is located like this

And we can view this newly created file from:

In this initorcl.ora is the newly created file pfile from spfile .

1. Log in as SYSDBA:

o Connect to your database as sysdba:

sqlplus / as sysdba
Now db is using pfile as there is not value in the value column.

2. Check Current Control Files:

o Show the current control files and their locations:

SELECT name FROM v$controlfile;

Execution Steps

1. Shut Down the Database:

o Shut down the database in a consistent mode:

SHUTDOWN IMMEDIATE;

2. Copy a Good Control File:

3. Edit the PFILE:

o Go to the Oracle home DBS directory:

cd $ORACLE_HOME/dbs

o Open the initorcl.ora file using vi editor:

vi initorcl.ora

o Add the new control file location to the control_files parameter with s single quote:
 o Save and exit the vi editor.

4. Create a New SPFILE from PFILE:

o Log in to SQL*Plus as sysdba:

sqlplus / as sysdba

startup nomount;

o Create the SPFILE from the updated PFILE:

CREATE SPFILE FROM PFILE;

Then set parameter for the controlfiles:

ALTER SYSTEM SET CONTROL_FILES='/u01/app/oracle/oradata/ORCL/control01.ctl',

'/u01/app/oracle/oradata/ORCL/control02.ctl', '/u02/backups/control03.ctl' SCOPE=SPFILE;

5. Start the Database:

o Start the database and ensure it mounts all control files:

STARTUP;

Post-execution Steps

1. Verify New Control File:

 o Check that the new control file is recognized:

SELECT name FROM v$controlfile;

Multiplexing Redo:
Steps to Add a New Redo File to a Redo Group

1. Log in as SYSDBA:

o Connect to your database as sysdba:

sqlplus / as sysdba

startup;

2. Check Current Redo Logs:

o To view the redo logs and their groups:

SELECT GROUP#, STATUS, MEMBER FROM v$logfile;

 Group 1: /u01/app/oracle/oradata/ORCL/redo01.log

 Group 2: /u01/app/oracle/oradata/ORCL/redo02.log

 Group 3: /u01/app/oracle/oradata/ORCL/redo03.log

3. Add New Redo Log Files:

 o Group 1:

ALTER DATABASE ADD LOGFILE MEMBER '/u01/app/oracle/oradata/ORCL/redo01b.log' TO GROUP 1;

o Group 2:

ALTER DATABASE ADD LOGFILE MEMBER '/u01/app/oracle/oradata/ORCL/redo02b.log' TO GROUP 2;

o Group 3:

ALTER DATABASE ADD LOGFILE MEMBER '/u01/app/oracle/oradata/ORCL/redo03b.log' TO GROUP 3;

4. Verify New Redo Log Files:

o Run the query again to ensure the new files have been added:

SELECT GROUP#, STATUS, MEMBER FROM v$logfile;

5. Perform Log Switches:

o To allow the system to recognize the new files, perform log switches:

ALTER SYSTEM SWITCH LOGFILE;

ALTER SYSTEM SWITCH LOGFILE;

ALTER SYSTEM SWITCH LOGFILE;

6. Verify Log Switches:

o Check the log groups and their current status to ensure the new files are recognized:

SELECT GROUP#, STATUS, MEMBER FROM v$logfile;

7. Check Log Group Status:

o Verify which log group is currently being used:

SELECT GROUP#, STATUS FROM v$log;