1. Forum Rules (PLEASE CLICK HERE TO READ BEFORE POSTING) Click the link 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 message will disappear after you have made at least 12 posts. Thank you for your cooperation.

TSM 6.3 on Windows - Perpetual DB backups running

Discussion in 'TSM Database' started by darylbnz, Oct 17, 2012.

  1. darylbnz

    darylbnz New Member

    Joined:
    Sep 12, 2012
    Messages:
    2
    Likes Received:
    1
    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.
     
  2.  
  3. marcinek

    marcinek New Member

    Joined:
    Sep 14, 2004
    Messages:
    41
    Likes Received:
    0
    Occupation:
    TSM & AIX Consultant
    Location:
    Warsaw, Poland
    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?
     
  4. darylbnz

    darylbnz New Member

    Joined:
    Sep 12, 2012
    Messages:
    2
    Likes Received:
    1
    Resolved.

    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 likes this.
  5. marcinek

    marcinek New Member

    Joined:
    Sep 14, 2004
    Messages:
    41
    Likes Received:
    0
    Occupation:
    TSM & AIX Consultant
    Location:
    Warsaw, Poland
    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.
     

Share This Page