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@xxxxxxxxx> 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@xxxxxxxxx>
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@xxxxxxxxx> 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@xxxxxxx>
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@xxxxxxx * Desk:317.759.2172 * Cell 317.523.8482
*From:* oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@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.
