How to terminate scheduled client operation?

[Ordinaryblonde]

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!

 

[vija]

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.

 

[Ordinaryblonde]

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?

 

[vija]

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

 

[n9hmg]

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.

 

[Ordinaryblonde]

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?

 

[syntax44]

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.

 

[Ordinaryblonde]

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).