Hi Chris,
The SQL tape format uses Microsoft Tape Format. That is why you can see the
backset from Windows Backup. The information in the set is SQL backup
details (dumps of memory pages, they are not the files on disk as such).
I don't know of an easy way of finding out the amount of space used on tape
from SQL but I would like to suggest a simpier way of backing up the data.
Why not backup to disk using a Maintanence plan. You set up one for nightly
backups and then another for transactional backups during working hours.
All of these should backup to disk. This will normally be much quicker then
backing up to tape. Then use BackupExec to backup the backup files after
the SQL backups have finished.
Say the SQL Backups kick off at 1:00am then at 2:00am run the Backup Exec
The only real draw back is that you need to have disk space to store the
backup files.
In this way Backup Exec can handle all backups and manage the tapes.
I hope this helps
--
kind regards
Greg O
Need to document your databases. Use the first and still the best AGS SQL
Scribe
http://www.ag-software.com [quoted text, click to view] "C_Hudson" <CHudson@discussions.microsoft.com> wrote in message
news:A4FF8A32-07E5-4AE5-BD62-3E573162CBD8@microsoft.com...
> I'm adminstering a SQL Server 2000 database on a Dell PowerEdge 1800
> server,
> running MS Win2k3 Server Standard OS. The tape drive is Dell PowerVault
> 100
> / DAT 72, SCSI interface. Dell included, and I installed, Veritas /
> Symantec
> BackupExec QSE, which I had been using to perform daily backups of the
> system.
>
> Once the SQL database was running, we began backups of the data, including
> periodic transaction log backups as the server was running. I implemented
> this feature as a job for the SQL Agent, and it has been working properly.
>
> However, I am unable to find a convenient way to gauge the capacity of the
> Tape as backups occur. Apparently, the format SQL is using is unsupported
> by
> Backup Exec. It's not a problem now - the database is small and backups
> fit
> on one tape - but someday it may grow to become a problem. And I'd like
> to
> be able to find out quickly what's on the tapes.
>
> The tape that SQL is backing up to had been part of a media set used by
> Backup Exec. Before beginning SQL backups, using BackupExec I removed
> this
> tape from its media set, erased the tape's contents, and added the tape to
> a
> newly-created media set, "SQL", of which it was the only member.
> Thereafter,
> SQL has written to this tape exclusively and repeatedly.
>
> BackupExec recognizes the tape as one of its creations, but does not
> recognize the SQL files stored there. Attempts to catalog the tape meet
> with
> failure and the error message "format not supported".
>
> On the other hand, SQL will allow me to view the contents of the tape
> through Enterprise Manager, but short of adding up the size of all the
> backups manually, from the list of existing backups in the "Restore"
> dialog,
> I have no way of knowing how much space is occupied or left on tape.
>
> Digging through BOL I found the SP "Restore Headeronly from tape = 'xxx'"
> and ran this successfullyas a SQL query. It returns a result set,
> however,
> it lists only the size of the complete or differential backups, and does
> not
> appear to include the transaction log backups which are part of the backup
> routine. Also, it takes about 10 minutes to run.
>
> Windows backup (Accessories > System > Backup) appears to recognize the
> tape
> drive, but not the tape. MMC Backup snap-in, same thing. I checked to see
> that the Removable Storage service was running. It wasn't, but starting
> it
> didn't seem to make a difference.
>
> If there were a SQL Stored Procedure that calculated the transaction log
> file backups, that would be enough to solve the problem. Alternately, if
> there were a way to get either Windows or BackupExec to catalog the tape,
> that would be enough as well.
>
> If anyone can shed some light I'd appreciate their input. Thanks.
>
> Charles Hudson
"Grego" <Grego@aa.com> wrote in message
news:%23pLtAuzHGHA.1728@TK2MSFTNGP09.phx.gbl...
> test
> "GregO" <grego@community.nospam.com> wrote in message
> news:ewlD7obHGHA.2948@TK2MSFTNGP10.phx.gbl...
>> Sorry just a test
>>
>
>
