Oracle Open Floor Questions for a northwest customer of DDBEA:

Make sure the mtree is set to type "Oracle1".  The process to setup oracle is in the DDOS CLI manual.

Number of Files Per Set and Channels?

• 4 files per set is the best practice, but depends on the size of DB and Hardware. Requires an internal block size of 8k or 16k. Files per set can be lower or even higher depending on impact to backup/DB speed. If the DB is using higher or lower block sizing, file per set changes will work but deduplication rates may drop.

• 1 channel per CPU. Best practice is 1 channel per CPU, but can be as high as 2 per CPU. Again – start with 1 per CPU and you can test if 2 makes backups faster.

That's is all configurable by inside Oracle. The DDBEA for RMAN agent just write out what Oracle tell it, like it was basically a NAS target.  When you setup the channels and filesperset it will reuse the channel.

Thanks for that reply - good info there.

Is there any way to "predict" how many "pieces" Oracle will break the backup into? My customer is also concerned about the number of channels not matching up optimally with the number of pieces that Oracle processes during the backup, and having one or more channels "sitting around doing nothing" while other channels are processing the last pieces of the backup.

I know that "it's not our job" to deal with the Oracle side of things, but if you have any insight as to how it is configured inside Oracle, that would be appreciated - all I'm looking for is info I can pass on to the customer with the understanding that they need to make their own decisions relative to Oracle best practices.

One other thing - can that mtree option you mentioned be set "dynamically"? I certainly wouldn't try to set it while backups were running to the Oracle SU, but are there any "side effects" of changing the value?

Relative to making sure ' the mtree is set to type "Oracle1" ' (I'm guessing you mean the app optimized compression setting), should I be concerned about this message that I see when trying to change that parameter?

Changing this setting will cause dedup issues for the next backup.

Please ensure that this system has enough space before applying this setting.

Or is that just a warning relative to using the new compression "algorithm" and how well data will dedupe in the near term?

Yes you need to be careful. The oracle1 change is going to change the stored format and get better compression in the future, but not change any existing backups. so it  could ruin the overall dedup for a short time until all previous RMAN backups get cycled off.

Understood - but I thought I read something that seemed to imply that existing data would get "re-compressed" during the weekly cleaning?

Or was that likely just something that wasn't written as well as it could have been, and actually was trying to say that as data was cleaned off, things would get better?

(I'll try to find the reference and list it here)