Rob, Like David said, etc... During SQL-BT setup, you should have created a MC for SQL-BT backups w/ Backup CopyGroup w/ VerExists=1 VerDeleted=0 RetExtra=0 RetOnly=0.
SQL-BT incorporates datime values in its TSM backup filenames so that each backup filename is unique; if you setup SQL-BT to keep 10 versions, you might have 11 dbf backups (uniquely named "Active" TSM backup files) until SQL-BT dtoexpire processing runs. Then, SQL-BT "expires" a backup version by marking the appropriate TSM backup files "Inactive". During the next TSM EXPIre Inventory processing, these Inactive backup files are deleted immediately (because your SQL-BT-MC B-CG has VerD=0.) Some tape space can be "reclaimed immediately" (during EXPIre Inventory processing) iff your tape STGpool is collocated by filespace and one/more tape(s) no longer contain(s) any "Active" SQL-BT backups. Otherwise, you have to run tape reclamation processing for that STGpool to recover the partially available tapes for reuse. -- [EMAIL PROTECTED] (203.432.6693)
David Longo wrote:
It handles expiration like Oracle RMAN (in general). The expiration is done by the client, not the normal "versioning" of TSM. The SQL-BT setup and config should have info on setting up Management Class on TSM for this. I have SQL-BT version 4.2 on AIX Sybase Client. The config on SQL-BT allows you to specify how many versions you want to keep, and SQL-BT "expires" old version each day when it does a backup.
Whether the data went to TSM disk pool first and then to tape or directly to tape has no bearing at all on the expiration.
Hello all,[EMAIL PROTECTED] 01/21/04 10:39AM >>>
How does TSM handle the expiration of SQL Backtrack filespaces if the data was originally written directly to tape, thus never existing on hard disk? We have a situation where these filespaces are not expiring and are not even being marked as inactive yet they are in a MC that is set to retain only ten versions.
TSM Server: 5.1.5.5 OS Version: AIX 5.1 SQL BT Version: 3.4.10
TIA, Rob
