TSM 6.3 on Windows - Perpetual DB backups running

[darylbnz]

Has anyone seen an issue (and has a resolution) where as soon as one database backup has completed, another automated one begins immediately, and following the completion of that automated backup, another begins and so on until you have no scratch tapes left?

I have read similar issues where there are other files in the active log drive, which make the disk more than 80% full, but that's not the case in this environment. This TSM server is a test DR restore of a production server (prod does not experience the problem), and so there are no backup processes or clients running and almost no activity which would cause any logs to fill. The drives where the logs reside are dedicated to TSM and no other non TSM related files exist on those drives. Have tested the restore process more than once in case I did something silly but with the same result.

From the activity log....
10/16/2012 13:03:47 ANR2017I Administrator SERVER_CONSOLE issued command:
BACKUP DB type=full devc=WLG_LTO_DC (SESSION: 538 )
........
10/16/2012 13:04:23 ANR0984I Process 2 for Database Backup started in the
BACKGROUND at 13:04:23. (SESSION: 538, PROCESS: 2)
10/16/2012 13:04:23 ANR4559I Backup DB is in progress. (SESSION: 538, PROCESS:
2)
10/16/2012 13:04:23 ANR2280I Full database backup started as process 2.
(SESSION: 538, PROCESS: 2)
10/16/2012 13:04:23 ANR4626I Database backup will use 1 streams for processing
with the number originally requested 1. (SESSION: 538,
PROCESS: 2)
.......
10/16/2012 13:43:26 ANR0985I Process 2 for Database Backup running in the
BACKGROUND completed with completion state SUCCESS at
13:43:26. (SESSION: 538, PROCESS: 2)
10/16/2012 13:43:30 ANR4531I An automatic full database backup will be
started. The last log number used is 4458 and the first
log number used is 4259. The log file size is 512
megabytes. The maximum log file size is 32768 megabytes.
(SESSION: 102)

Output from Q log f=d....
Total Space(MB) Used Space(MB) Free Space(MB) Active Log Directory Archive Log Directory
--------------- --------------- --------------- ----------------------------------- -----------------------
32,768 20 101,880 o:\ho_prod\log\actlog p:\ho_prod\log\archlog

Output from MS windows srvinfo....
Drive: [FileSys] [ Size ] [ Free ] [ Used ]
C$ NTFS 61440 7129 54311
G$ NTFS 32765 32650 115 - The TSM instance drive letter
N$ NTFS 524285 304699 219586 - The TSM database drive letter
O$ NTFS 196605 94241 102364 - The TSM Active log drive letter
P$ NTFS 196605 196510 95 - The TSM Archive log drive letter

Any clues where to look next would be greatly appreciated.

 

[marcinek]

Hi, I have the same problem on Linux (TSM 6.3.3, RHEL 6.2) I had to downgrade from RHEL 6.3 to 6.2 - lin_tape driver is not supported on latest RH, so I have exported tsm volume group, reinstalled OS imported a tsm volumegroup, but cleaned actlog archlog and db directories, created a fresh instance and then performed dsmserv restore db from snapshot (i tried full backup as well with the same result). Everything seems to be wirking fine, except now I experience automatic full database backup every 10 minutes. My filesystems are ok, they do not exceed 80%.
Your post is couple months, old so perhaps you already have a solution?

 

[darylbnz]

Resolved.

Hi, I have the same problem on Linux (TSM 6.3.3, RHEL 6.2) I had to downgrade from RHEL 6.3 to 6.2 - lin_tape driver is not supported on latest RH, so I have exported tsm volume group, reinstalled OS imported a tsm volumegroup, but cleaned actlog archlog and db directories, created a fresh instance and then performed dsmserv restore db from snapshot (i tried full backup as well with the same result). Everything seems to be wirking fine, except now I experience automatic full database backup every 10 minutes. My filesystems are ok, they do not exceed 80%.
Your post is couple months, old so perhaps you already have a solution?

Yes I did resolve it. Turned out that the log space in production was significantly larger than the log space defined at the time of restore. The calculation was taking 80% of the original log space and not the newly configured log space. Had to find some more disk space and make the log space the same and the issue went away.

 

[marcinek]

You're right. You solution helped. Thanks.
I have not seen any tech note form IBM about it. Perhaps I'll place PMR on it since it looks like a bug. I have been able to reproduce this problem several times.