ADSM-L

Re: [SPAM: 4.815] [ADSM-L] TDP FOR SQL DATABASES 5.2

2005-12-01 12:50:44
Subject: Re: [SPAM: 4.815] [ADSM-L] TDP FOR SQL DATABASES 5.2
From: Leigh Reed <L.Reed AT MDX.AC DOT UK>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 1 Dec 2005 17:50:15 +0000
Laura

You say that LAN free is not an option, therefore you are restoring over
your IP network.

Firstly, can you confirm that you have a GB NIC in your TSM server and
GB NIC in your target restore SQL server.

My maths is not the best but with basic rough calculations at 100M
bits/sec, you get approx 10MBytes/sec. That's 600MB per minute and 36GB
per hour. Your backup statistics would suggest that you are indeed
running at  >100Mbits/sec, although I don't know whether you have set
compression on the TDP and therefore not sending a full 50GB of SQL data
over the network. Generally SQL db's compress fairly well.

Other than the network speed the other key thing that prolongs a TDP SQL
restore is the formatting of the SQL tablespace, so that it is ready for
a restore.  This is out of TSM's hands, it is an SQL operation and can
take some considerable time. You can verify this by identifying that the
restore session goes into a commwait state and stays in this state until
SQL confirms that the area to which the restore is destined has been
formatted and is ready to accept the restore.

You may also need to up your TSM server setting for commtimeout, as if
the tablespace format operation takes longer than your commtimeout
value, the session will be dropped by the server and the restore will
fail.

The only way to circumvent this, is if you have the tablespace
preformatted by SQL before you issue the restore from the TDP.

The 9840B's are not the fastest drives for transferring single large
files (19MB/sec native), but 3 of them running concurrently should
acheive the performance you are looking for.

If you have GB NICs and you also have the tablespace already
preformatted, then your next stop would be the target OS CPU utilisation
(if the db was compressed at source and hence needs to be uncompressed
on the restore) and disk speed.


Leigh


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Laura Mastandrea
Sent: 01 December 2005 17:05
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [SPAM: 4.815] [ADSM-L] TDP FOR SQL DATABASES 5.2


We have been evaluating this product and have not been able to achieve
the
necessary performance throughput on the restores we require.  I'd like
to
know if anyone else out there is successfully using this product.

Environment:

AIX 5.2  and TSM Server 5.2.4.2
6 STK 9840 B tape drives, but we always backup directly to a 1 TB disk
pool
Windows 2003  TSM client 5.3.0.8
SQL Server 2000 SP3
Test database 50 GB

Backup times are 42 minutes and restore times are 73 minutes with 6
stripes.   Our production databases will be 3 to 4 times bigger than
this
test database.  The TSM buffer is 4096.  The node is non-collocated, but
we
have tried with collocated.  The best we could do was get the migration
from disk to "stripe" across 3 volumes.  IBM's recommendation is to go
LAN
free, but that is not an option at this point.

Thank you.








DISCLAIMER:
This communication, along with any documents, files or attachments, is
intended only for the use of the addressee and may contain legally
privileged and confidential information. If you are not the intended
recipient, you are hereby notified that any dissemination, distribution
or copying of any information contained in or attached to this
communication is strictly prohibited. If you have received this message
in error, please notify the sender immediately and destroy the original
communication and its attachments without reading, printing or saving in
any manner. This communication does not form any contractual obligation
on behalf of the sender or, the sender's employer, or the employer's
parent company, affiliates or subsidiaries.

<Prev in Thread] Current Thread [Next in Thread>
  • Re: [SPAM: 4.815] [ADSM-L] TDP FOR SQL DATABASES 5.2, Leigh Reed <=