Data retention TDP for SQL

Chimera

Active Newcomer
Joined
Aug 14, 2013
Messages
8
Reaction score
0
Points
0
PREDATAR Control23

I have been investigating the rapid consumption of the Active Data pool & found a significant chunk of the utilisation came from TDP for SQL & am seeking to understand why this is the case.

Investigation into the backup (via select * from backups where node_name like '<nameofsqlnode>') for the most recent backup indicaited (I have removed meta in these examples):

Servername Servername\instance\data\0001 4 ACTIVE_VERSION FILE \dbname\log\20150304034632\000016F0.20150304034632000016F0\ 1 1323458584 2015-03-04 03:46:32.000000
Servername Servername\instance\data\0001 4 ACTIVE_VERSION FILE \dbname\log\20150304034632\000016F0\ 1323458583 2015-03-04 03:46:32.000000

It appears both of these log files are the same, with the only diffrence being an appended datestamp on the second one. The day post the full backup, the same files look like this:

Servername Servername\instance\data\0001 4 ACTIVE_VERSION FILE \dbname\log\20150304034632\000016F0.20150304034632000016F0\ 1 1323458584 2015-03-04 03:46:32.000000
Servername Servername\instance\data\0001 4 INACTIVE_VERSION FILE \dbname\log\20150304034632\000016F0\ 1323458583 2015-03-04 03:46:32.000000 2015-03-04 23:58:34

or

Servername Servername\instance\data\0001 4 INACTIVE_VERSION FILE \dbname\full\ 1273669747 2015-01-29 23:31:26.000000 2015-01-30 23:32:43.000000
Servername Servername\instance\data\0001 4 ACTIVE_VERSION FILE \dbname\full.2015012923312600001818\ 1 1273669749 2015-01-29 23:31:26.000000

This same pattern occurs across the board for all 35 Days (the configured retention period) and as some of these systems run log backups every 15 mins it results in a significant amount of data sitting in the active pool.

I also tested with the active pool disabled & see the same behaviour, it also occurs with TDP for SQL 6.4 - 7.1.1.

The documentation does not contain a lot on information on the active/inactive process, I was under the impression that a Full Backup would inactivate all of the backups that occured prior.
 
PREDATAR Control23

I ended up opening a support case with IBM and it appears the issue is normal for TDP for SQL:
http://www-01.ibm.com/support/docview.wss?uid=swg21695831

with the "Resolution" essentially being to ignore it
During the normal backup processing, the object which is the peer leader of the group will get inactivated, it is not necessary for the temporary object to be deactivated and it remains in an active state.

When the group leader object expires or is removed from the Tivoli Storage Manager server, this will expire all group members. Even if the group members are in an active state, all objects from the peer group will be deleted as soon as its leader is expired/removed.
 
Top