Hi Sandy,
I can think of several things, starting with a Commvault bug, unusable
deduplication database or compression inadvertently inserted somewhere
in the process, by not removing "use storage policy options" from the
storage device form. There is also a file called "SIDB.log" somewhere on
your system. That is the log created by deduplication process. My advice
would be to upload the logs and call in a ticket. Do you want me to
alert your account managers? They could get you support resources really
quickly.
Regards
On 10/21/2016 02:28 PM, Sandra Becker wrote:
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 <mailto: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
<http://kb.commvault.com/article/ORA0001>
Chris..
_____________________________________________________________________
Chris Ruel * Oracle Database Administrator * Lincoln Financial Group
cruel@xxxxxxx <mailto:cruel@xxxxxxx>* Desk:317.759.2172
<tel:317.759.2172> * Cell 317.523.8482 <tel:317.523.8482>
*From:*oracle-l-bounce@xxxxxxxxxxxxx
<mailto:oracle-l-bounce@xxxxxxxxxxxxx>
[mailto:oracle-l-bounce@xxxxxxxxxxxxx
<mailto:oracle-l-bounce@xxxxxxxxxxxxx>] *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.
