Results 1 to 8 of 8
  1. #1
    Member
    Join Date
    Jun 2008
    Posts
    8
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default How to terminate scheduled client operation?

    The title says it all.
    One of my clients sometimes takes a lots of time to perform scheduled backup, I guess he retries to backup files that are in use. Usually it is not a problem, but today I have to do something with TSM server that requires restarting machine, and that client is still backuping.
    Not only for today, but also for the future simillar cases, I would like to know how to stop scheduled backup in the less painless manner, and what should I do afterwards to repair possible damage.

    Thanks!

  2. #2
    Member
    Join Date
    Jun 2007
    Posts
    22
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default

    HI Ordinaryblonde,

    You can terminate schedule by canceling sessions (Can sess number).
    Regarding files in used is backuped up, you can specify in include exclude list
    the files you dont want to backup.
    Hope this will help.

  3. #3
    Member
    Join Date
    Jun 2008
    Posts
    8
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default

    Thanks a lot, vija, session is cancelled!

    About exclude these files, I cannot exclude them because I need to have their backup. These files are most of the night idle, but early in the morning some applications start to use them. I am thinking to create a new schedule for that client only that will go before existing one, to be sure that it is backuped first, while his files are not in use yet.

    By the way, can anyone tell me what determines order in which clients perform same scheduled operation, and is there a way to influence that order?

  4. #4
    Member
    Join Date
    Jun 2007
    Posts
    22
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default

    Yes, You can change the priority of the schedules so highest priority will execute first.
    ex: update schedule

  5. #5
    Senior Member
    Join Date
    Dec 2006
    Location
    northern front-range Colorado, USA
    Posts
    600
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default

    I suggest you look at at least that client's serialization. If he's got files he'll be changing all night, does he want them taken as-is or skipped? Waiting through the default three tries in shrdstatic on slowly-changing large files on a server with a lot of files can essentially hold your TSM system hostage forever. Tell him to poop or get off the pot, so to speak.

    I'm running my entire enterprise pure static. One change during a backup and it's skipped. Now that I've got things so smoking fast, I might switch them to pure dynamic, or even get generous and go shrdynamic with changingretries=1.

  6. #6
    Member
    Join Date
    Jun 2008
    Posts
    8
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default

    Currently I'm on shrstatic with changingretries=2, I used to be on changingretries=4. Examining some dsmsched.log files I found that 2 retries is the maximum number, and that files that are not backuped in 2nd retry will not be backuped in 4th as well.
    However, what bothers me is that period between retries varies (for the one particular very big file) between 1 and 7 (!) hours. One hour is ok for me, but with 7 hours I go deeply in working hours, when this file will certainly be in use, and will not be backuped. What is it dependent of?

  7. #7

    Default

    You can specify the following serialization modes in the copygroup of a management class:

    DYNAMIC: If the object changes during backup or archive it is commited the to the TSM server immediately
    SHRDYNAMIC: If the object changes during backup or archive and continues to be changed after a number of retries, the LAST retry commits the object to the TSM server, whether or not it changed during backup or archive.
    STATIC: Specifies that an object having been modified during the backup/archive operation will not be send to TSM server
    SHRSTATIC: Checks after the object is send to the server if it is changed; if it is, it is send to the server again. If the object is modified every attempt than the objet is not backed up or archived at all. This result in the following error: "File XXXX truncated while reading in Shared Static mode."
    You can influence the number of retries of SHRDYNAMIC and SHRSTATIC with the parameters CHAngingretries. By backing up open and/or used files, there is always the danger of "fuzzy" backups.
    Best regards,
    Tommy Hueber
    http://www.tsmblog.org

  8. #8
    Member
    Join Date
    Jun 2008
    Posts
    8
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default

    Quote Originally Posted by syntax44 View Post
    By backing up open and/or used files, there is always the danger of "fuzzy" backups.
    That's exactly why I cling on to shrstatic mode. I just do not get it, why I have to wait so long for another retry? Is it some parameter I can change? Issuing q status i get:
    Query Schedule Period: 6 Hour(s)
    Maximum Command Retries: 10
    Retry Period: 5 Minute(s)
    Scheduling Modes: Any
    Could something of that be of some relevance here?


    Here is the piece from dsmsched.log just to see at what times retries occured:

    06/19/2008 00:54:08 Normal File--> NAMEOFFILE ANS1360I Compressed Data Grew
    06/19/2008 07:07:42 Retry # 1 Normal File--> NAMEOFFILE Changed
    06/19/2008 13:07:39 Retry # 2 Normal File--> NAMEOFFILE ** Unsuccessful **

    (I had option of compress object but not if it grows, today I changed it to no compression, to see what will happen with first backup attempt).

Similar Threads

  1. TSM client scheduled backup hang
    By dev1 in forum Backup / Archive Discussion
    Replies: 6
    Last Post: 08-04-2008, 01:50 PM
  2. One Client out of 10 failing on scheduled backup
    By Nicko in forum Backup / Archive Discussion
    Replies: 1
    Last Post: 10-19-2006, 12:31 PM
  3. Rejected sessions - Solaris 9 Client - scheduled backups
    By noodles in forum Backup / Archive Discussion
    Replies: 9
    Last Post: 12-01-2005, 06:01 AM
  4. ANR4573E - Database backup terminate
    By lot in forum Others
    Replies: 3
    Last Post: 10-12-2005, 06:11 AM
  5. Replies: 10
    Last Post: 01-13-2003, 08:47 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •