Mastering RMAN Oracle DBA
Mastering RMAN Oracle DBA
Asfaw Gedamu
Introduction
Oracle Recovery Manager (RMAN) is a powerful tool for backup and recovery in Oracle
databases, offering a range of features to ensure data protection and continuity. This document
outlines the procedures for performing full database backups, incremental database backups with
block recovery, and tablespace backups using Oracle Recovery Manager (RMAN). These
backups are crucial for ensuring data recovery in case of system failures or data corruption.
Prerequisites
Ideal Audience
PL/SQL Script:
DECLARE
v_backup_set_name VARCHAR2(100);
BEGIN
-- Set backup set name with timestamp
v_backup_set_name := 'FULL_DB_BACKUP_' || TO_CHAR(SYSDATE,
'YYYYMMDD_HH24MISS');
-- Allocate channels for parallel backup (adjust channel count
as needed)
FOR i IN 1..4 LOOP
EXECUTE IMMEDIATE 'ALLOCATE CHANNEL CH'||i||' DEVICE TYPE
DISK';
END LOOP;
RMAN Script
Explanation:
1. Configuration Section:
• configure backup optimization on;: Enables RMAN backup optimization, which skips
backing up unchanged datafiles.
• configure controlfile autobackup on;: Enables automatic backups of the control file.
• configure controlfile autobackup format for device type disk to '/archiva/backup/%F';:
Sets the format and location for automatic control file backups.
• configure maxsetsize to unlimited;: Removes the limitation on the size of backup sets.
• configure device type disk parallelism 4;: Enables parallel processing with 4 channels for
disk backups.
Overall, this script configures RMAN for optimized, parallel, and compressed incremental
database backups (level 0 includes all data) along with archive logs.
RMAN Script-1:
RUN {
ALLOCATE CHANNEL CH1 DEVICE TYPE DISK;
BACKUP AS '+INCREMENTAL_' || TO_CHAR(SYSDATE,
'YYYYMMDD_HH24MISS')
INCREMENTAL LEVEL 1 DATABASE
BLOCKRECOVERY ALL;
RELEASE CHANNEL CH1;
};
Explanation:
• This script performs an incremental backup capturing changes since the last full backup.
• BLOCKRECOVERY ALL enables block-level recovery for the entire database.
RMAN Script-2:
RMAN Script-1:
RUN {
ALLOCATE CHANNEL CH1 DEVICE TYPE DISK;
BACKUP TABLESPACE <tablespace_name> FORMAT
'<backup_location>/%U_<tablespace_name>_%d_%T_%s_%p';
RELEASE CHANNEL CH1;
};
Replace:
RMAN Script-2:
RMAN Script-1:
RUN {
ALLOCATE CHANNEL CH1 DEVICE TYPE DISK;
BACKUP DATAFILE <datafile_id>|<datafile_spec> FORMAT
'<backup_location>/%U_<datafile_name>_%d_%T_%s_%p';
RELEASE CHANNEL CH1;
};
Replace:
Explanation:
This script allows backing up individual datafiles based on ID or file specification. Modify the
script to include multiple datafiles or use a loop to iterate through a list.
RMAN Script-2:
SQL Script:
BEGIN
DBMS_SCHEDULER.DROP_JOB(job_name => 'RMAN_DELETE_ARCHIVELOG');
DBMS_SCHEDULER.CREATE_JOB(
job_name => 'RMAN_DELETE_ARCHIVELOG',
job_type => 'SCHEDULED',
schedule_type => 'INTERVAL',
interval_expr => 'FREQ=DAILY',
enabled => TRUE,
program_name => 'dbms_scheduler.run_sql(statement =>
''DELETE FROM ARC$ WHERE CREATION_DATE < SYSDATE - 1'')'
);
END;
/
Explanation:
This script creates a scheduled job named "RMAN_DELETE_ARCHIVELOG" that runs daily
(modify INTERVAL_EXPR for different schedules) and deletes archive logs older than 1 day using
DBMS_SCHEDULER.
RMAN Script-2:
RMAN Script-1:
RUN {
ALLOCATE CHANNEL CH1 DEVICE TYPE DISK BACKUP RETENTION POLICY
TO RECOVERY WINDOW OF 1 DAYS;
BACKUP ARCHIVELOG ALL FORMAT
'<backup_location>/%U_arch_%T_%s_%p';
RELEASE CHANNEL CH1;
};
Replace:
Explanation:
This script backs up all archive logs with a retention policy of 1 day using RECOVERY WINDOW.
Adjust the retention period as needed.
RMAN Script-2:
RMAN Script-1:
RUN {
ALLOCATE CHANNEL CH1 DEVICE TYPE DISK;
COPY ARCHIVE FROM '/u02/asm/oracle/archivelog/<archive_name>'
TO '/path/to/mount/point/<archive_name>';
RELEASE CHANNEL CH1;
};
Replace:
Explanation:
This script copies a specific archive log from ASM to a designated mount point. Modify the
script with a loop to copy multiple archives or use wildcards for filenames.
RMAN Script-2:
--- Copy archive log from ASM to regular mount point using RMAN:
--- Connect to RMAN in RAC db
RMAN> copy archivelog '+B2BSTARC/thread_2_seq_34.933' to
'/data/thread_2_seq_34.933';
RMAN Script-1:
RUN {
ALLOCATE CHANNEL CH1 DEVICE TYPE DISK;
BACKUP ARCHIVELOG FROM SEQUENCE <start_seq_num> TO SEQUENCE
<end_seq_num> FORMAT '<backup_location>/%U_arch_%T_%s_%p';
RELEASE CHANNEL CH1;
};
Replace:
• <start_seq_num> with the starting sequence number of the archive logs to be backed up.
• <end_seq_num> with the ending sequence number of the archive logs to be backed up.
• <backup_location> with the desired directory path for storing backups.
Explanation:
This script enables selective backup of archive logs based on their sequence number range.
RMAN Script-2:
--For taking backup of archivelog between seq number 1000 to
1050
RMAN> backup format '/archive/%d_%s_%p_%c_%t.arc.bkp'
archivelog from sequence 1000 until sequence 1050;
--For RAC ,need to mention the thread number also
RMAN> backup format '/archive/%d_%s_%p_%c_%t.arc.bkp'
archivelog from sequence 1000 until sequence 1050 thread 2;
RMAN Script:
Bash Script:
Explanation:
This script enables RMAN tracing within a Bash script. Include your desired RMAN commands
between SET TRACE ON and SET TRACE OFF for detailed logging of RMAN operations.
Oracle 12c introduced the RECOVER TABLE command that allows recovering dropped tables
using RMAN. However, you cannot directly use a script for this. Here's the process:
1. Identify the relevant backup containing the table before it was dropped.
2. Use the RECOVER DATABASE command with the UNTIL TIME clause specifying a point in
time before the drop. This recovers the entire database to an auxiliary instance.
3. Export the recovered table data from the auxiliary instance and import it back into the
primary database.
4. Clean up the auxiliary instance.
Replace:
• 2024_03_25_DROP_TIME with the estimated time the table was dropped (adjust format as
needed).
Additional Steps:
• Export and import the recovered table data manually using tools like expdp and impdp.
• Clean up the auxiliary instance using RMAN DROP AUXILIARY DATABASE.
RMAN Script:
Auxiliary destination – Location where all the related files for auxiliary
instance will be placed
Datapump destination – Location where the export dump of the table will be
placed
• RMAN Output: The RMAN command prompt displays progress information during
backup execution.
• v$session_longops view: This view provides detailed information on running database
operations, including RMAN backups. You can query this view in SQL*Plus.
• Alerting: Configure RMAN to send email or pager notifications upon backup completion
or errors.
SQL Script:
RMAN Script-1:
RUN {
ALLOCATE CHANNEL CH1 DEVICE TYPE TAPE NOREWIND;
RESTORE ARCHIVELOG FROM '/path/to/tape/device' LIKE 'arch_%';
-- Adjust LIKE pattern for specific archive names
RELEASE CHANNEL CH1;
};
Replace:
• /path/to/tape/device with the specific tape device name for your system.
RMAN Script-2:
Note: This script will restore the archive sequences from 7630 to 7640 to
/dumparea location
• RMAN Command Prompt: Enter the command at the RMAN prompt. If there are
syntax errors, RMAN will display an error message.
• SQL*Plus Script (Limited): Wrap the RMAN command within a BEGIN and END;
block in a SQL*Plus script. However, this only validates basic syntax and may not catch
all errors.
Important Note: This Bash script executes the command but won't necessarily highlight syntax
errors. It's for testing basic functionality.
RMAN Script:
$ rman checksyntax
Recovery Manager: Release 12.1.0.2.0 - Production on Sun Jan 29
12:04:24 2017
Copyright (c) 1982, 2014, Oracle and/or its affiliates. All
rights reserved.
Conclusion
Regular RMAN backups are essential for a robust database disaster recovery strategy.
Implementing these scripts ensures consistent and reliable database backups, minimizing
downtime and data loss in the event of unexpected outages. By following these procedures and
customizing scripts as needed, DBAs can effectively safeguard valuable database information.
Note: These scripts are basic examples. Remember to adjust them based on your specific
environment, backup requirements, and retention policies. Hence: