Re: Block Change Capture Questions

From: Mladen Gogala <gogala.mladen_at_gmail.com>
Date: Tue, 22 Feb 2022 22:02:45 -0500
Message-ID: <038e8521-46eb-bc2f-f977-5e370b6ee5cc_at_gmail.com>

We use CommVault for database backups.  CommVault interfaces with RMAN.  We do hot backups on prod databases, with one full backup each night and several incrementals throughout the day.  Our CommVault administrator sent a message from CommVault that says:

 

Severity: Minor

          Job ID: 4778016

          Event Date: Mon Feb 21 03:01:11 2022

          Program: ClOraAgent

          Client: rpiddevl2

          Description: Block Change Tracking is found DISABLED on Oracle DB [RPIDDEVL]. Incremental backups may run slow.

 

He wants us to look into this.  We have and are concerned that the overhead will be more than the benefits. 

 

Has anyone turned this on?  If so, what was the overhead?  Did it help with backups?

Hi Scott,

We've corresponded while I worked for CommVault Systems. You should reconsider your backup strategy. The problem with your strategy is that, in case of failure, you must restore the last full backup and all the incremental backups after that. So, the first reduction would be to use one RMAN full backup every night and several full "snapshot backups" every day. I've put the phrase snapshot backup in scare quotes because snapshots are NOT backups. However, they complete very fast and you can restore and recover your database in minutes. Obviously, you would need a SAN or NAS that supports snapshots. Fortunately, almost all of them do support snapshots: NetApp, Pure, Emc, Hitachi, HP 3Par, IBM and most of the well known brands most certainly do support snapshots. Oracle ZFS Appliance also supports storage snapshots and does it rather well. Also, Commvault supports snapshot backup copies to file system and even synthetic full backups. Synthetic full backup is a combination of incremental backups which are merged together into a full backup. Commvault is extremely powerful and can be adjusted to almost any backup strategy. The combination you are using is classic and most frequently found in the data centers but is also terminally obsolete.

Furthermore, restoring backup is your last line of defense. The first line of defense should be Data Guard and physical standby database. Taking several incremental backups per day is a rather costly operation which will almost certainly collide with your data processing. Also, when you have a standby, you can take backups on the standby side. That doesn't interfere with your data processing unless your standby is an active DG standby used for reporting purposes. However, you will still have two copies of the database that you can back up independently. RMAN catalog used DBID as the primary key and will recognize both backups taken on the primary and on the standby as backups of the same database. Both primary and the standby have the same DBID. Long story short, you're devoting much too much time to backups. To paraphrase an old adage about defragmenting, it's time to stop backing up and start living.

Regards

PS:

I no longer work for CommVault Systems.

-- 
Mladen Gogala
Database Consultant
Tel: (347) 321-1217
https://dbwhisperer.wordpress.com

-- http://www.freelists.org/webpage/oracle-l Received on Wed Feb 23 2022 - 04:02:45 CET