Re: CommVault - dedup and software compression

We have the dedup on the client. The production database is actually on a 10GB NIC. Test is on a 1GB NIC. I'm in a hurry up and wait mode to get the NIC replaced. Thank you for the link. We'll review it with our CV admins.

Sandy

On Fri, Oct 21, 2016 at 12:57 PM, carlos castro <ccastro7145_at_gmail.com> wrote:

> 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.
>>
>>

-- 
Sandy B.

--
http://www.freelists.org/webpage/oracle-l