To answer Mark and Carlos in the same response.
You are teasing out what we suspect the root cause of the problem is, it is
a pity that Simpana have not had as much foresight for us.
We think the server holding the SQL server database is possibly
under-powered for such a big extract. It is not maxing out on CPU but it is
certainly using a lot of what is available.
My question was originally to determine if others are having similar
difficulties in recovery VLDB from CV but I might well end up having to
re-platform the underlying CV database onto a larger server. I doubt we
would move it to Oracle as that would be a very significant move affecting
the whole company backup infrastructure.
We could maybe segregate ceratin backups onto a different CV SQl Server
database
John
On 20 July 2017 at 13:39, Mark W. Farnham <mwf@xxxxxxxx> wrote:
So this is primarily a performance tuning question on the SQL Server
database then, right?
(Actual question, not rhetoric).
Rhetoric: I wonder whether there is a way to move your repository for CV
to an Oracle database, possibly with partitioning, whilst still writing and
reading it transparently from CV, or whethere CV has an Oracle RDBMS
respository option.
I’m not fluent in CV, but perhaps there is an option to “shard” your CV
repository in SQL Server so that this large, many pieces database is
isolated and ceases to interfere with the other backups.
Presumably the size of the database is a proxy for the number of file
and/or extent references, unless CV tracks by block or something else very
granular.
Perhaps there is a CV expert on the list who can chime in with more
helpful suggestions.
mwf
*From:* oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@
freelists.org] *On Behalf Of *John Hallas
*Sent:* Thursday, July 20, 2017 8:20 AM
*To:* rogel@xxxxxx
*Cc:* ORACLE-L
*Subject:* Re: Simpana Commvault V10 - large database restores
We don't get an error, RMAN sends a request to the MML and CV interrogates
the SQL Server database to find all the pieces and that interrogation never
completes. It takes about 4 minutes on a 2Tb size database but never
finishes for us -we have run it for 24+ hours and it all it does is cause
problems for other CV backups that are running.
Note this is only on the restore - the backup works fine
On 20 July 2017 at 12:20, <rogel@xxxxxx> wrote:
what's the ORA-error you get ?
*Gesendet:* Donnerstag, 20. Juli 2017 um 13:05 Uhr
*Von:* "John Hallas" <john.hallas@xxxxxxxxxxxxxxxxxx>
*An:* ORACLE-L <oracle-l@xxxxxxxxxxxxx>
*Betreff:* Simpana Commvault V10 - large database restores
We have an 80TB database which we back up successfully to Commvault V10.
However we cannot perform a restore now it has grown to this size.
We did manage to restore at about 40Tb but are struggling now.
It ends up thrashing the CV SQL server database looking for all the pieces.
We are working with Simpana but we have not had much back, in particular
re whether we have hit any database size limitations within CV
The SQL code behind the restore:
EXEC CV_ExecuteSP 'archFileByName', N'
N''9579374_XXXYYY2A_4fs7uujn_29_1'',0,0,5853,0,1,0,0',
'00010012000000000000', 0, 0, 78644, 'DBLog', 'Instance001', 'cvd.exe'
EXEC CV_ExecuteSP 'archFileByName', N'
N''9579374_XXXYYYA_4as7uuj2_114_1'',0,0,5853,0,1,0,0',
'00010012000000000000', 0, 0, 78644, 'DBLog', 'Instance001', 'cvd.exe'
John
------------------------------
--
*Technology Manager - Databases and System Management*
Wm Morrison Supermarkets PLC
Tel 0845 611 4589 (Int. 7949 4589)
Mob: 07876 790540
E-mail: john.hallas@xxxxxxxxxxxxxxxxxx
------------------------------
Wm Morrison Supermarkets Plc is registered in England with number 358949.
The registered office of the company is situated at Gain Lane, Bradford,
West Yorkshire BD3 7DL. This email and any attachments are intended for the
addressee(s) only and may be confidential.
If you are not the intended recipient, please inform the sender by
replying to the email that you have received in error and then destroy the
email.
If you are not the intended recipient, you must not use, disclose, copy or
rely on the email or its attachments in any way.
This email does not constitute a contract in writing for the purposes of
the Law of Property (Miscellaneous Provisions) Act 1989.
Our Standard Terms and Conditions of Purchase, as may be amended from time
to time, apply to any contract that we enter into. The current version of
our Standard Terms and Conditions of Purchase is available at:
http://www.morrisons.co.uk/gscop
Although we have taken steps to ensure the email and its attachments are
virus-free, we cannot guarantee this or accept any responsibility, and it
is the responsibility of recipients to carry out their own virus checks.
------------------------------
