--> This would cut down backup time (but increase restore time).

While the former statement is true, the latter is incorrect and
misleading. Restore from flat dump will require:
1. Read the file from tape volume on the (TSM) server
2. Write the file to a disk on the SQL server
3. Create SQL server data files (usually takes some time)
4. Read the data from the disk(s)
5. Write the data to SQL data files

Usage of TDP for MS SQL will eliminate steps 2 and 4, i.e. will eliminate
a whole data read-write session. Even for 20 GB this is going to save
about 10 min. If  the dump file is written on same disks as data files, it
will cause disk contention. If separate disks are used, the number of
spindles available to MS SQL (and respectively *both* read and write
performance) will be lower.

Bottom line: properly tuned TDP for MS SQL (or any competitive product)
should perform better!!! This motivates the spending on such products.

Zlatko Krastev
IT Consultant






Todd Lundstedt <Todd_Lundstedt AT VIA-CHRISTI DOT ORG>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
23.09.2003 20:54
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Re: SQL server backups


Yes, but you could stripe the full backup across multiple tape drives (if
you have more than one tape drive).  This spreads the database backup
across multiple tapes, and makes reclamation of those files less
problematic.  Note: if you stripe a backup, you *must* send the backup to
a collocate=filespace storage pool.  Otherwise, reclamation could put more
than one stripe for a particular backup on a tape, making restoration
impossible.
Additionally, TDP will allow you to backup differential backups of the
database, and even transactions logs, directly to TSM storage.  This would
cut down backup time (but increase restore time).
Hope that helps.
Todd

ps.. we are backing up an 800+ GB SQL database using stripe=3 to LTO1
drives via SAN in 3-4 hours.
pps.. if you implement a FULL with DIFF backup from TDP, make sure your
database is not getting dumped to disk at all, or it invalidates the FULL
on tape, but TSM is unaware of it.




Thomas Denier <Thomas.Denier AT MAIL.TJU DOT EDU>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
09/23/2003 12:39 PM
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Fax to:
        Subject:        SQL server backups


My company has a Windows server supporting a very large SQL Server
database.
Before the last hardware upgrade, the database was backed up with the SQL
Server Connect Agent. Since the upgrade the database has been dumped to a
flat file which is then backed up by the backup/archive client. Either way
the backup arrives at the TSM server as a single file containing about
20 gigabytes of data. A single file this size causes a number of problems.
The recovery log gets pinned for hours. Tape reclamation tends to perform
poorly. The system administrator is now considering installing TDP for
SQL Server. Would this software still send the backup as a single huge
file?