TSM General Scheduler behaviour

[lipi]

Hi,

I have a busy server with 15 schedules defined that run every day and with overlapping.
One nodes is only associated with a single schedule.

I have a lot of "client missed its schedule window" messages, but I don't understand why. Now, it's 18:15h and I have 7 schedules that should be running with more than 30 clients associated. All schedules "started" at 13:00h, but only a few nodes associated to some of these schedules are in state completed/failed. All the other nodes are in "Pending" state (as q event shows).

"q session" shows only 1 node that is backing up since 05h in the morning, so no problem of max sessions, resources, etc. Some of the schedules have a window of 4hours and currently I have missed scheds.

Example:
q event D_USER SCH_WIN_HOME_13H f=d
Policy Domain Name: D_USER
Schedule Name: SCH_WIN_HOME_13H
Node Name: PCADM125
Scheduled Start: 21/03/16 13:00:00
Actual Start:
Completed:
Status: Pending
Result:
Reason:


Any tip on how to make all the scheds to run in parallel? I searched on the forum but nothing found

 

[marclant]

I have a lot of "client missed its schedule window" messages, but I don't understand why. Now, it's 18:15h and I have 7 schedules that should be running with more than 30 clients associated. All schedules "started" at 13:00h, but only a few nodes associated to some of these schedules are in state completed/failed. All the other nodes are in "Pending" state (as q event shows).

Issue "query status" and look at "Schedule Randomization Percentage".
Then issue "q schedule {domain_name} {schedule_name} f=d" and look at the "Duration."

The schedules will start in the first "percentage" of the "duration" so that they don't all start at once.

As an example, if the "Schedule Randomization Percentage" is set at 50% and the duration is 4 hours. All the clients associated to that schedule will start at random times in the first two hours of the backup.

 

[marclant]

Any tip on how to make all the scheds to run in parallel? I searched on the forum but nothing found

You don't really want that as the first thing each client does is a large query against the server, so if you can spread them, it's better (see my previous post to see how they are spread".

If you still want them to start at the same time, reduce the duration. (The duration is not how long the backup can run, but the duration in which the schedule can start). You can reduce the "Schedule Randomization Percentage" too. But again, I would not recommend it, except for a few nodes which may have time sensitive backup requirements.

 

[lipi]

You don't really want that as the first thing each client does is a large query against the server, so if you can spread them, it's better (see my previous post to see how they are spread".

If you still want them to start at the same time, reduce the duration. (The duration is not how long the backup can run, but the duration in which the schedule can start). You can reduce the "Schedule Randomization Percentage" too. But again, I would not recommend it, except for a few nodes which may have time sensitive backup requirements.

Hello Marclant,

This parameter is used only for clients with client-polling scheduling mode configured.
https://www.ibm.com/support/knowledgecenter/SSGSG7_7.1.3/srv.reference/r_cmd_randomize_set.html

My clients all have "prompted" option, so it is all decided from the server. I was looking for some parameter like "parallelization factor".

Thanks

 

[marclant]

My clients all have "prompted" option, so it is all decided from the server. I was looking for some parameter like "parallelization factor".

No such thing.

The randomization still applies with prompted in this case:

The randomization occurs at the beginning of the window to allow time for retries, if necessary. When the scheduling mode is not set to polling, randomization does not occur if the client's first contact with the server is after the start time for the event.

source: same one you referenced

So, if the scheduler connects with the server before the schedule start time, the server will still use the randomization. So you should still consider reducing the duration, but not shorter than 10 minutes to give the server the time to contact the client, and retry if the first attempt fails.

DURation
Specifies the number of units that define the length of the startup window of the scheduled operation. This parameter is optional. This value must be from 1 to 999. The default is 1.

Use this parameter with the DURUNITS parameter to specify the length of the startup window. For example, if you specify DURATION=20 and DURUNITS=MINUTES, the schedule must be started within 20 minutes of the start date and start time. The default length of the startup window is 1 hour. The duration of the window must be shorter than the period between windows.

This value is ignored if you specify DURUNITS=INDEFINITE.

Tip: Define schedules with durations longer than 10 minutes. Doing this will give the Tivoli Storage Manager scheduler enough time to process the schedule and prompt the client.

source: https://www.ibm.com/support/knowled...nce/r_cmd_schedule_client_define.html?lang=en