-
-
Community Tip: Forum Rules (PLEASE CLICK HERE TO READ BEFORE POSTING)
Click the link above to access ADSM.ORG Acceptable Use Policy and forum rules which should be observed when using this website. Violators may be banned from this website. This notice will disappear after you have made at least 3 posts.
Backup quota for DB2 API backup node
- Thread starter alansbb
- Start date
Thanks for reply, however as I know retention policies not working well for API/TDP backup, it won't expire unless DBA expire these backup first.
Best way to do this is to set the NUM_DB_BACKUP database parameter setting as per http://publib.boulder.ibm.com/infoc...c=/com.ibm.db2.udb.admin.doc/doc/r0002215.htm
Set this to the number of versions you want to keep and when a backup is done, the oldest version will expire and normal expiration will remove it from TSM.
Set this to the number of versions you want to keep and when a backup is done, the oldest version will expire and normal expiration will remove it from TSM.
Mita201
ADSM.ORG Senior Member
Are you sure that it will expire it from TSM? I think it will not, it will just prune db2 recovery file on db2 system
It looks like a DB2 parameter setting.......
num_db_backups - Number of database backups configuration parameter
After the specified number of backups is reached, old backups are marked as expired in the recovery history file. Recovery history file entries for the table space backups and load copy backups that are related to the expired database backup are also marked as expired. When a backup is marked as expired, the physical backups can be removed from where they are stored (for example, disk, tape, TSM). The next database backup will prune the expired entries from the recovery history file.
The rec_his_retentn configuration parameter should be set to a value compatible with the value of num_db_backups. For example, if num_db_backups is set to a large value, the value for rec_his_retentn should be large enough to support the number of backups set as num_db_backups.
This is the one you want - http://publib.boulder.ibm.com/infoc...?topic=/com.ibm.db2.udb.doc/core/r0002077.htm with the keep option.
That way you can limit the number of DB2 backup versions and have the oldest go inactive. From there, the management class and expire inventory will determine when they actually delete.
Forget my earlier link....
That way you can limit the number of DB2 backup versions and have the oldest go inactive. From there, the management class and expire inventory will determine when they actually delete.
Forget my earlier link....
Mita201
ADSM.ORG Senior Member
Yes, db2adutl is utility that will handle TSM backups of db2.
Best way is to create scripts that will run "db2adutl delete..." right after successful DB2 backup.
Tricky part is that you have to handle archive logs if they are pointed to TSM as primary location, also with db2adutl. It is relatively easy to do it on unices, but I do not know how to script it on windows, so I do it manually where I have to do - delete them from time to time.
Best way is to create scripts that will run "db2adutl delete..." right after successful DB2 backup.
Tricky part is that you have to handle archive logs if they are pointed to TSM as primary location, also with db2adutl. It is relatively easy to do it on unices, but I do not know how to script it on windows, so I do it manually where I have to do - delete them from time to time.
Thanks DazRaz and Mita201.
I understand db2adutl to manage DB2 backup retention, but the tools is for DBA not for TSM adminstrator.
Does anyone has the same issue which DBA keep backing-up DB full backup every day for couple years and refuese to delete? The tape usage for one database is close to 1 PB.
I understand db2adutl to manage DB2 backup retention, but the tools is for DBA not for TSM adminstrator.
Does anyone has the same issue which DBA keep backing-up DB full backup every day for couple years and refuese to delete? The tape usage for one database is close to 1 PB.
Mita201
ADSM.ORG Senior Member
It does not matter who is going to do job, DBA or TSM admin, it has to be done.
As I understand from documentation, IBM has the attitude that db backup is job for DBA, and TSM is a tool.
So, you are going to use db2adutl (db2 adsm utility) for handling number of versions of DB2 backups on TSM. This is the only proper way to do it. It is up to you to arrange it with db2 admin; You can make a script that will do it automatically after successful db2 backup, or he will do it manually, whatever.
Same goes to Oracle, or Informix. backup versions on TSM are handled by db utilities.
As I understand from documentation, IBM has the attitude that db backup is job for DBA, and TSM is a tool.
So, you are going to use db2adutl (db2 adsm utility) for handling number of versions of DB2 backups on TSM. This is the only proper way to do it. It is up to you to arrange it with db2 admin; You can make a script that will do it automatically after successful db2 backup, or he will do it manually, whatever.
Same goes to Oracle, or Informix. backup versions on TSM are handled by db utilities.
The issue you have is essentially a political one rather than technical.
Personally, I would approach the problem by calculating the cost of holding on to all those backups. The retention of all those backups can be done so long as the company is prepared to wear the cost.
A script would automatically take care of the deletions once a decision is made to delete.
If you want to limit the space that can use, you could setup a separate storage pool for the DB2 backup and restrict the size of the pool (maxscratch=???) to a level that is acceptable. This doesn't solve your political issue and that may worsen when backups start failing.
Personally, I would approach the problem by calculating the cost of holding on to all those backups. The retention of all those backups can be done so long as the company is prepared to wear the cost.
A script would automatically take care of the deletions once a decision is made to delete.
If you want to limit the space that can use, you could setup a separate storage pool for the DB2 backup and restrict the size of the pool (maxscratch=???) to a level that is acceptable. This doesn't solve your political issue and that may worsen when backups start failing.
