Oracle RMAN to Hyperscale backups

  • 20 July 2023
  • 5 replies

Badge +1

We are trying to use CommVault to backup an Oracle 19c Database straight to our hyperscale servers ( was backing to as separate SAN disk and then to hyperscale hope to reduce the extra step) backup is working, but a full backup gets all the white space on the data drive instead of only the used space and takes about 13 hrs to complete.   Currently we are thinking that the SBT switch in the RMAN is what is doing this to us.   Anyone else doing this?   The length of time to backup has the DBA’s worried.

5 replies

Badge +1

I work with TS46864 and wanted to clarify. 

HyperScale is technically the storage target but doesn’t really have anything to do with the behavior seen.


Oracle DBAs in the past have ran their RMAN scripts to backup the Oracle databases to disk which to my understanding is SAN volumes mounted to the Unix OS, so “local”. The RMAN scripts when “allocating channels” had a type of “DISK”. To my understanding, with the “DISK” as the type the backups is able to provide efficiencies. Such as, if the database space is 20TB, but the database data is only occupying 10TB, the backup will only read the data and backup the 10TB without parsing through the entire 20TB. Thus, the backup is quite a bit quicker.


Now we are testing having CommVault do the backup with the Oracle agent. When CV does the backup it is parsing through the entire 20TB. I’ve found that the RMAN script CV creates for the backup is allocating the channels with the type of “sbt_tape”. To my limited knowledge of Oracle, this sbt type backup doesn’t have the efficiencies in which gives the ability to only backup the 10TB of database data. Question to the community: is this expected behavior? Is my assumption correct?


Thank you.



Userlevel 7
Badge +16

Hi @TS46864 and @AdamDavenport 

It is correct that DISK and SBT_TAPE have different behavior.
DISK in general will provide a more efficient method, as you have found out, it will only read the data needed for the incremental. SBT_TAPE in general will read the whole file.
I have seen a commvault environment use disk unfortunately, not sure if this is possible as Commvault relies on the SBT_LIBRARY.

That being said, there are some initial ways to manage the DBA’s concerns.

  • Do you have block change tracking within Oracle?
    This will allow the system to track changes and therefore be quicker.

    Incremental Backups

    Best Practice: If you perform an incremental backup on an Oracle database that is version 10G or later, enable the change tracking feature to enhance the backup performance. Add the following to the RMAN script before you run the backup.

    Alter database enable block change tracking using file
    Oracle information on v19:

    Commvault information:

    Also take a look at the other recommendations mentioned on this page and the sub pages.
  • As you have in-guest SAN volumes.
    If block change tracking is already used or doesn't provide enough time reduction.
    Depending your environment you can maybe use Intellisnap to offload the process to a ‘RMAN backup copy’ or ‘Volume copy‘ instead of a streaming backup and prevent hours of impact on your production DB.

    Please note: If you want to use the Oracle RMAN backup copy option by using a proxy server (not required, but will offload the backup copy to another machine), you must contact Oracle for their required licensing.

    To identify this:
    - Is oracle configured with ASM or Non-ASM disks?
    - What brand and type is your SAN storage which is providing the volumes?
    - What is the OS of the Oracle Server?
    - Is it a standalone Oracle server or Clustered?
    - What protocol is used, Fiber Channel?
Badge +1

@Jos Meijer 

Thank you very much for the reply and information. Just to clarify, you stated “I have seen a commvault environment use disk unfortunately”, but did you mean “I haven’t seen...”?


Appreciate all the other information. We’ve looked most of that already and it has been provided to DBA team. The big question was really focused around the DISK vs SBT in which you’ve provided a sanity check for us.


Again, greatly appreciate the reply!

Userlevel 7
Badge +16

Hi @AdamDavenport 

My apologies, this indeed should be: “I haven’t seen”

You are very welcome 👍

Badge +1

Thank you.