Re: EMC Data Deduplication

From: Amaral, Rui <>
Date: Fri, 5 Nov 2010 07:10:45 -0400
Message-ID: <AD1FD82AC6BFBE4C8913E32286D9C70D080C369F37_at_EX7T2-SV05.TDBFG.COM>

Backing up to dedup device is precisely the same as backing up to a san ... From our point of view. The important thing is understanding the compression on the device. Higher compression means slower backup performance which you "might" offset by using parallel streams to the device. That's one. Two: you will need to make sure your tcp settings are set up correctly as per the "best practices". Three: if you have many backups being written and deleted regualarly then you need to run a regular procedure on the device to defrag it (I don't know the procedure off the top of me head right now).

Like Hemant pointed out BCT is primarily performance related and I think most effective on level 1 backups (makes sense). But remember, those devices dedup AND compress so you can leverage one or both simultaneously.

From: Hemant K Chitale [] Sent: Friday, November 05, 2010 06:20 AM To: <> Cc: <> Subject: Re: EMC Data Deduplication

RMAN Incremental doesn't need BCT to reduce the size of the Backup file. It uses BCT to improve the performance of the backup -- BCT helps identify the modified blocks.

If the number of blocks modified since the last backup is a very large proportion of the total size, then the Incremental Level 1 backup would still be nearly as large as the L0 backup.

So what matters is the number of modified blocks.

Deduplication may also find that a large portion of the database has been modified !

Hemant K Chitale

On Fri, Nov 5, 2010 at 5:55 PM, Jason Khym <<>> wrote: I am an oracle DBA at a large ulitity company in the Southeastern US. Our IT shop is considering buying this product for our server,email and database backups. It would replace Veritas Netbackup Server and Tape libraries. I was wondering if anyone on the list has any experience with the product.

We current at taking full level 0 hot backups on all of our production databases every night. So I know a dedup product like this would save us alot of backup space. I also realize that RMAN incremental backups with Block Change Tracking would give us the same benefit with less cost. We haven't had time to implement this as a backup standard yet. Our db engineer tried using incremental backups back in 8i or 9i and said it was not reducing the backup size. He later found out he needed to enable BCT to see the full size reduction. Our IT engineers want us(DBAs) to write RMAN backups directly to this dedup servers. I am not sold on that idea. I would like to continue to write our backup to ATA SAN storage and have the backups pulled to the dedup devices.

Overall, what do you think of this product? Any gotchas or leasons learned that can be shared?


Hemant K Chitale

NOTICE: Confidential message which may be privileged. Unauthorized use/disclosure prohibited. If received in error, go to for instructions. AVIS : Message confidentiel dont le contenu peut être privilégié. Utilisation/divulgation interdites sans permission. Si reçu par erreur, allez au pour des instructions.
-- Received on Fri Nov 05 2010 - 06:10:45 CDT

Original text of this message