Re: CommVault - dedup and software compression

From: carlos castro <ccastro7145_at_gmail.com>
Date: Fri, 21 Oct 2016 19:57:44 +0100
Message-ID: <CAA00uRMuo3boFdXLSWjAQxKVSrtHEWgcT4RA7Pg8BT2PVJ-Ltw_at_mail.gmail.com>



Hello.

Do you have dedup on the client or Media Agent. Remember that at the Storage Policie level you need to have client side dedup enable.

Since your bottleneck here is network (1GB) take a look at client side cache.

https://documentation.commvault.com/commvault/v10/article?p=features/deduplication/online_help/r_client_dedup_settings.htm

Regards

Arestas

Em 21/10/2016 19:29, "Sandra Becker" <sbecker6925_at_gmail.com> escreveu:

> No, we are not using RMAN compression or encryption. We have gone ahead
> and done compression, no dedupe on the archivelog only backups, but we're
> using dedupe, no compression on the default backups.
>
> Sandy
>
> On Fri, Oct 21, 2016 at 11:47 AM, Ruel, Chris <Chris.Ruel_at_lfg.com> wrote:
>
>> Are you using RMAN compression or encryption on the datafiles as they
>> come out of the database for backup? It is often recommended to turn these
>> features off for dedup activity to perform it’s best.
>>
>>
>>
>> For reference: http://kb.commvault.com/article/ORA0001
>>
>>
>>
>>
>>
>> Chris..
>>
>>
>>
>> _____________________________________________________________________
>>
>> Chris Ruel * Oracle Database Administrator * Lincoln Financial Group
>>
>> cruel_at_lfg.com * Desk:317.759.2172 * Cell 317.523.8482
>>
>>
>>
>> *From:* oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freeli
>> sts.org] *On Behalf Of *Sandra Becker
>> *Sent:* Friday, October 21, 2016 11:16 AM
>> *To:* oracle-l
>> *Subject:* CommVault - dedup and software compression
>>
>>
>>
>> CommVault v11
>>
>> Oracle Database versions 11g and 12c
>>
>> We have been configuring clients and scheduling backups in CommVault for
>> about 3 months now. While most backups work well and dedup as expected, we
>> have concerns about two very large Exadata databases. The production
>> database is 34T and the backup is taking 4-5 days. After pruning as much
>> data as possible in the test database, it is down to 9T, with the latest
>> backup taking just over 23 hours. Prior to pruning, backups were taking
>> 3-4 days. It doesn't appear that the dedup feature is actually being used
>> for either backup. I know that our CV admin opened a ticket with support,
>> who in turn killed my production backup so they could test something. I
>> was not happy since I was never consulted before they killed the backup.
>> But I digress. Unfortunately, we have only a 1GB NIC to handle most of the
>> backup traffic which means throttling our backups more severely than
>> originally planned. We do have a request to replace the 1GB with a 10GB,
>> but it doesn't look like that will happen any time soon. So, a couple of
>> questions:
>>
>> 1. What would cause the dedup feature to not be used? I know for the
>> test database we imported several hundred GB of data in the past week and
>> obviously, that would not be deduped. The production database is a data
>> warehouse, loading less than 100GB per day. Any other possible causes?
>>
>> 2. If we turn on software compression on the client, what effect/impact
>> will that have, if any, on the deduplication?
>>
>> I haven't been able to find the answers in the documenation yet. Any
>> help would be greatly appreciated.
>>
>>
>> --
>>
>> Sandy B.
>>
>> Notice of Confidentiality: **This E-mail and any of its attachments may
>> contain
>> Lincoln National Corporation proprietary information, which is
>> privileged, confidential,
>> or subject to copyright belonging to the Lincoln National Corporation
>> family of
>> companies. This E-mail is intended solely for the use of the individual
>> or entity to
>> which it is addressed. If you are not the intended recipient of this
>> E-mail, you are
>> hereby notified that any dissemination, distribution, copying, or action
>> taken in
>> relation to the contents of and attachments to this E-mail is strictly
>> prohibited
>> and may be unlawful. If you have received this E-mail in error, please
>> notify the
>> sender immediately and permanently delete the original and any copy of
>> this E-mail
>> and any printout. Thank You.**
>>
>
>
>
> --
> Sandy B.
>
>

--
http://www.freelists.org/webpage/oracle-l
Received on Fri Oct 21 2016 - 20:57:44 CEST

Original text of this message