How to mine an RMAN Log

I recently performed a Proof of Concept (POC) to compare and contrast Oracle Recovery Manager (RMAN) backup performance between an existing NFS setup and a NEW backup appliance. By running the same backup—changing only the backup tag—and mining the resulting logs, I was able to gather the data necessary to evaluate a potential migration.

1. The Proof of Concept (POC) Strategy

To ensure a fair comparison, the RMAN script remained identical for both environments. I used compressed backupsets and incremental level 0 backups with section sizes to optimize the workload.

The RMAN Backup Command 

connect target; show all; backup as compressed backupset check logical incremental level 0  section size 32G database tag NEW_LEVEL0 filesperset 8; list backup summary; exit 

2. Storage Architecture and Channel Allocation

The primary difference between the two environments lies in the mount point configuration and channel parallelism. While the NFS setup utilized a single mount, the NEW appliance was configured with four mounts to better distribute the I/O.

NFS Channel Configuration (Single Mount)

CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/mnt/backup_nfs/bkp/%d_%I_%T_%U' MAXOPENFILES 1; 

NEW Backup Appliance Configuration (4 Mounts)

For the NEW appliance, I allocated 16 channels distributed across four distinct mount points (/mnt/backup_new_0 through /mnt/backup_new_3). 

CONFIGURE CHANNEL 1 DEVICE TYPE DISK FORMAT '/mnt/backup_new_0/bkp/%d_%I_%T_%U' MAXOPENFILES 1; CONFIGURE CHANNEL 2 DEVICE TYPE DISK FORMAT '/mnt/backup_new_1/bkp/%d_%I_%T_%U' MAXOPENFILES 1; CONFIGURE CHANNEL 3 DEVICE TYPE DISK FORMAT '/mnt/backup_new_2/bkp/%d_%I_%T_%U' MAXOPENFILES 1; CONFIGURE CHANNEL 4 DEVICE TYPE DISK FORMAT '/mnt/backup_new_3/bkp/%d_%I_%T_%U' MAXOPENFILES 1; CONFIGURE CHANNEL 5 DEVICE TYPE DISK FORMAT '/mnt/backup_new_0/bkp/%d_%I_%T_%U' MAXOPENFILES 1; -- ... [Channels 6-15 omitted for brevity] ... CONFIGURE CHANNEL 16 DEVICE TYPE DISK FORMAT '/mnt/backup_new_3/bkp/%d_%I_%T_%U' MAXOPENFILES 1; 

3. Benchmarking the Results: NFS vs. NEW

After mining the logs, we can see how the two storage solutions handled the 172 database data files.

Backup Duration and Timing

Metadata and File Distribution

The log mining revealed 141 backup pieces for the NFS run and a similar distribution for the NEW run, though the NEW appliance spread those pieces across the four mounts.

NFS Sample Piece:

141 piece handle=/mnt/backup_nfs/bkp/DB_NAME_105164007_20190610_npu3o1e7_10_1 tag=NFS_LEVEL0

NEW Sample Pieces (Multi-mount):

piece handle=/mnt/backup_new_0/bkp/...

piece handle=/mnt/backup_new_1/bkp/...

piece handle=/mnt/backup_new_2/bkp/...

piece handle=/mnt/backup_new_3/bkp/...

Final Storage Footprint

Interestingly, the total backup size remained nearly identical, with the NEW appliance showing a slight optimization in space.

• NFS Total: 768G (Single mount)
• NEW Total: 766G (Distributed as 194G, 174G, 188G, and 212G across 4 mounts)

4. Automating Log Analysis

To perform the comparison efficiently, I used a shell script called compare_backup_logs.sh. This script extracts timing, backup piece counts, and size information directly from the RMAN logs. 

#!/bin/sh ls -lht ~/working/dinh/backup_rman* export log1=~/working/dinh/backup_rman.log.nfs export log2=~/working/dinh/backup_rman.log.new  echo "### Backup duration NFS" egrep 'Starting backup|Finished backup' $log1 echo "### Backup duration NEW" egrep 'Starting backup|Finished backup' $log2  echo "### Backup piece at target NFS" grep -c "piece handle" $log1 grep "piece handle" $log1| sort  echo "### Backup piece at target NEW" grep -c "piece handle" $log2 grep "piece handle" $log2| sort  echo "### Backup sets created NFS" grep -c "specifying datafile(s) in backup set" $log1 echo "### Backup sets created NEW" grep -c "specifying datafile(s) in backup set" $log2  echo "### Backup datafile at DB" grep -c "input datafile file number" $log1| sort -u grep "input datafile file number" $log2| sort -u  echo "### Backup size at target NFS" du -shc /mnt/backup_nfs/bkp echo "### Backup size at target NEW" du -shc /mnt/backup_new_?/bkp exit 

5. Making the Migration Decision

Having sufficient data gathered and analyzed makes it easy to compare performance and decide if there is any significant gain. While the NEW appliance offers better I/O distribution through multi-mount parallelism, the data allows for an objective choice on whether to migrate existing backups to the new hardware.

Oracle Database Consulting Services

Ready to optimize your Oracle Database for the future?