Re: CommVault - dedup and software compression

We have not enabled compression on the default backups, only the archivelog backups. We did a little poking around looking at various policy and client settings. Then we looked at the backup history. Every default backup has failed in the last 3 weeks, usually due to space on the CV side of things. We didn't get our allocations correct, but think we have enough space now. Not sure if I got the terminology correct on this, but the backups always failed for a media manager error. My co-DBA and I don't believe we have a good baseline backup so we're not sure dedup can't take place. Is that correct? If we have only partial backups, *can* dedup occur?

Sandy

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

> As long as you have client side dedup enable at the Storage Policie it
> should work.
> After You can make a small test with compression disable to make sure
> dedup is working.
>
> Regards,
>
> Arestas
>
> Em 21/10/2016 20:46, "Sandra Becker" <sbecker6925_at_gmail.com> escreveu:
>
>> 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.
>>
>>

-- 
Sandy B.

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