We had the opposite experience, but we are replicating between two data
domains. We found we had better performance by switching to using rman to an
NFS mount from the Data Domain (type disk instead of sbt). The impact is that
the replication is now independent of the rman backup (with DD Boost, the
backup does not complete until the replication is complete), the replication
still completes at approximately the same time as it did when the it was
through DD Boost, but the rman job in production completes sooner.
After switching to NFS, it is still important to turn off compression and use
one file per set for the data files. My experience has been that I use less
space on the data domain if I compress the archive logs (and files per set is
your choice as well). The reason appears to be that each archive log is fairly
unique, so the data domain is not able to do much de-duplication on them.
On May 5, 2016, at 10:12 AM, Eric Brown <ebrown2266@xxxxxxxxx> wrote:
We switched our backups from writing to the data domain via NFS to DDBoost
and it cut the backup time by about 75%. Everything is managed natively
using RMAN (rman views DDBoost as a SBTTAPE interface).
We have been quite happy with it. The extra cpu usage during the backup is
offset by the much shorter backup window.
On Wed, May 4, 2016 at 12:12 PM, Jeff Thomas <dbmangler@xxxxxxxxx
<mailto:dbmangler@xxxxxxxxx>> wrote:
Our environment is 11.2.0.4 / OEL 6 / RAC.
Currently we are using Netbackup, compressed incrementals to the FRA, then
backup recovery area to tape.
Our company has purchased the EMC suite of backup tools to replace Netbackup.
My understanding is the optimal use of DD Boost/DD is to turn off
compression, set FILESPERSET to 1, skip backups to the FRA;
going directly via the DD Boost module to DD, essentially using DD as your
tacit FRA.
I would appreciate hearing any experiences with respect to your B/R strategy
using DD Boost / DD.
Thanks...
