TSM Training
Showing posts with label TSM Training. Show all posts
Showing posts with label TSM Training. Show all posts

12.3 TSM Administrator daily tasks and activities

05:44 No Comments
Tivoli Storage Manager administrator is supposed to ensure that the Tivoli Storage Manager system is functioning properly. Daily monitoring tasks focus on examining server processes, server database, storage pools, and scheduled operations. You can complete the monitoring tasks by using the command-line interface (CLI) or TSM Operations Center.

The following list describes some of the tasks that are important to monitor daily. 
  • Verify that the database file system has enough space.
  • Examine the database percent utilization, available free space, and free-pages.
  • Verify that there is enough disk space in the file systems that contain these log files.
Active log
Archive log
Mirror log
  • Verify that the instance directory file system has enough space.
  • Verify that the database backups completed successfully, and that they are running frequently enough.
  • Check the database and recovery log statistics.
  • Verify that you have current backup files for device configuration and volume history information. You can find the file names for the backups by looking in the dsmserv.opt file for the DEVCONFIG and VOLUMEHISTORY options. Ensure that file systems where the files are stored have sufficient space.
  • Search the summary table for failed processes.
  • Search the activity log for error messages.
  • For storage pools that have deduplication enabled, ensure that processes are completing successfully.
  • Check the status of your storage pools to ensure that there is enough space available.
  • Check for any failed storage pool migrations.
  • Check the status of sequential access storage pools.
  • Check how many scratch volumes are available.
  • Determine if there are any tape drives offline, or their paths that are offline.
  • Determine if there are any libraries offline, or their paths that are offline.
  • Verify that all of the tapes have the appropriate write-access.
  • Verify the status and settings for disaster recovery manager (DRM).
  • Check for failed or missed schedules.
  • Check the summary table for scheduled client operations such as backup, restore, archive, and retrieve.
  • Check the summary table for scheduled server operations such as migration, reclamation, and expiration.
Also Read: Storage Area Network (SAN) Basic Free Tutorials

 Based upon your backup strategy, you need to create suitable administrative schedules to automate the server process and to make the TSM infrastructure protected. For example if all you backups run in the night time which is common in most scenarios, it is recommended to follow these time order as shown below.

TSM daily monitoring tasks

1) After all the client backups are completed, you should create a admin schedule to backup all primary storage pools
backup stgpool <primary_pool_name> <copypool_name>

2) Next, you have to take the TSM DB Backup 
backup db devclass=<devclass name> type=full nums=n 

use query process (to see when the backups complete)

3) Next, you have to backup volume history and device configuration files
 backup devconfig 
backup volhist

4) If you are using DRM, run move drm command to eject all the offsite tapes including the TSM DB backup tape.
move drmedia * wherestate=mountable tostate=vault

When the data on the offsite tapes gets expired, you need to bring those tapes and reuse them as scratch tapes. Run the following command to bring those tapes and update TSM server
move drmedia * wherestate=vaultretrieve tostate=onsiteretrieve

5) Run DRM prepare command to generate the DRM plan file for that day. You have to send the copy storage pool volumes, server configuration files and DRM plan file regularly to offsite.
prepare source=dbsnapshot

6) Migrate stored data from primary storage pools to the next-level storage pools. This way you will make some space in the disk pools for next backup cycle. If required, you can checkin some scratch tapes during this process.
migrate stgpool <pool_name> lowmig=n%

7) Now, you have to remove expired data from server storage by using expire inventory command. you can customize this process according to your requirements. Since it is a CPU intensive process make sure the server is in good CPU state.
expire inventory duration=60

8) When the expiration is done, you will have empty space in the tape volumes. You have to reclaim  this space from fragmented tapes by consolidating active data.
reclaim stgpool <pool_name> threshold=n

You are also expected to check the DB and log status regularly. Several queries are available to obtain information about the database and log. Use format=detail (f=d) for more detailed information.
  • Querydb
  • Querydbspace
  • Querylog

12.2 Using SQL commands to query TSM DB2 database

04:42 No Comments
You can use SQL queries to get information from the TIvoli storage Manager Database. You can use the SQL SELECT commands to customize a wide variety of queries. Some queries require server time and resources and might impact performance.

IBM Tivoli Storage Manager Version 7 uses the DB2 open database connectivity (ODBC) driver to query the database and display the results. System catalog tables provide information about information that is available in the database. To help you find what information is available in the database, Tivoli Storage Manager provides three system catalog tables.

 Also Read: TSM Administrator Daily routine tasks

 SYSCAT.TABLES
Contains information about all tables that can be queried with the SELECT command.

 SYSCAT.COLUMNS
Describes the columns in each table.

 SYSCAT.ENUMTYPES
Defines the valid values for each enumerated type and the order of the values for each type.

 The simplest form of a SELECT statement is selecting all columns from a table. To use the SQL interface, you need a basic understanding of the SQL SELECT statement. For example to know what are the available tables 
select * from syscat.tables

Some Commonly used SQL Queries on TSM 6 & TSM 7

TSM DB Utilization
SELECT CAST(SUM(100-(free_space_mb*100) / tot_file_system_mb) AS DECIMAL(3,1)) AS PCT_UTILIZED FROM db

 TSM log recovery utilization (%)
SELECT CAST(SUM(used_space_mb *100 / total_space_MB) AS DECIMAL(3,1)) AS PCT_UTILIZED FROM log

 Space and number of files stored per client
 SELECT node_name,CAST(FLOAT(SUM(physical_mb)) / 1024 AS DEC(8,2))as "Space in GB", -
  SUM(num_files)as"Number of files" FROM occupancy GROUP BY node_name

 Information about drives x paths
  SELECT b.source_name, a.library_name, a.drive_name, a.drive_serial, b.device FROM drives a, paths b WHERE a.drive_name=b.destination_name

 Total client data stored (TB)
 SELECT CAST(FLOAT(SUM(logical_mb)) / 1024 / 1024 AS DEC(8,2)) FROM occupancy

Check this website for more TSM SQL queries which can be used in daily monitoring of TSM Server.

 PREVIOUS: 12.1 TSM Server and Client event logs and activity logs Overview
NEXT: 12.3 TSM Administrator daily tasks and activities
ALL CHAPTERS: IBM Spectrum Protect (TSM) Basic Free Tutorials

12.1 TSM Server and Client event logs and activity logs Overview

01:11 No Comments
You can configure Tivoli Storage Manager to log certain client messages as events on the Tivoli Storage Manager server. The purpose of client error logging is to notify the server of problems that are encountered during a client operation. Therefore, client message candidates are those messages that indicate an error condition. For all application programming interface (API) related messages, the API places an appropriate message text into the string buffer.

The following message types are not logged as events:
  • Session, communication, and TCA errors: When encountering a session, communication, or a Trusted Communication Agent (TCA) error, the client is unable to initiate a session with the Tivoli Storage Manager server. Therefore, the client cannot pass any message of this type to the server.
  • Client memory errors: Because of insufficient memory resources, the client is unable to log these types of messages.
  • Informational messages: Informational messages do not contain an error condition and, therefore, are not logged.
  • Server disabled messages: During the client sign-on procedure, the Tivoli Storage Manager server provides information to the client about which messages to log to the server. Disabled messages do not pass to the server.

Messages are shown in the following format:

A N [ R S E ] # # # # [ I W E S]

Type:
R = Server S = Client E = Event

Levels:
I = Info W = Warning E = Error S = Severe

Event receiving
When the server starts, event logging begins automatically for the console and activity log and for any receivers that start automatically, based on entries in the server options file.
Client messages are categorized as either loggable or nonloggable messages. You can enable all loggable messages as events. Unlike client messages, there is no distinction for server events. Any server message that has an associated message number is an event. You can enable or disable all events for the event receivers, regardless of whether they are client or server events.

Each interface that the central logging mechanism supports is an event receiver. Events from clients or servers can pass to one or more of the receivers. It is possible to send the same events to different receivers or to enable a group of events for specific receivers. You can choose any combination that suits your needs.

Begin eventlogging
You can use this command to begin logging events to receivers where event logging does not start automatically when the server starts up. You can also use this command after you disable event logging for one or more receivers.
tsm> begin eventlogging all

If no receiver is specified or if ALL is specified, logging begins for all configured receivers. The following are the receivers
  • ALL: Specifies all receivers that are configured for event logging.
  • CONSOLE: Specifies the server console as a receiver.
  • ACTLOG: Specifies the Tivoli Storage Manager activity log as a receiver.
  • EVENTSERVER: Specifies the event server as a receiver.
  • FILE: Specifies a user file as a receiver. Each logged event is a record in the file, however, a person cannot read each logged event easily.
  • FILETEXT: Specifies a user file as a receiver. Each logged event is a fixed-size, readable line.
  • NTEVENTLOG: Specifies the Windows application log as a receiver.
  • SNMP: Specifies the simple network management protocol (SNMP) as a receiver.
  • TIVOLI: Specifies the Tivoli Management Environment® as a receiver.
  • USEREXIT: Specifies a user-written routine that Tivoli Storage Manager writes information to as a receiver.
Use the enable & disable events by using enable event or disable event command to enable specific events or groups of events for one or more receivers. You cannot disable server events. The command requires the following parameters
  • Receiver name
  • Message number or message severity
  • Node name (optionally)

Querying events and the activity log

Use the query event command to show the status of scheduled events. With the time and date parameters, you can limit the query to events that are scheduled to occur within the specified times and dates. The command syntax differs for queries that apply to scheduled client operations and to scheduled administrative commands.
query event domainname schedname begindate=11/22/2014
  enddate=14/24/2014 exceptionsonly=yes
query event schedname t=a begindate=11/22/2014
  enddate=14/24/2014

Use the query actlog command to show messages that the server generates. The activity log contains all messages that are sent to the server console under normal operation. The results of commands that are entered at the server console are not recorded in the activity log, unless the command affects or starts a background process or client session.Error messages are shown in the activity log.
query actlog begindate=today-1 begintime=15:00:00
  endtime=22:30:00
Tivoli Storage Manager server events are always stored in the activity log and you cannot disable them. Server information in the activity log is often needed to resolve critical situations. By default, all client events are also enabled for the server activity log.

You can prune the activity log, according to the age of the entries by using SET ACTLOGRETENTION command.
SET ACTLOGRETENTION 7

Otherwise, you can prune the log, according to configured maximum allowed size. When maximum size is reached, the log is pruned. The pruning starts with the oldest activity log records and stops when the activity log size no longer exceeds the configured maximum size.
   SET ACTlogretention size in MB MGMTSTYLE=Size
   SET ACTlogretention days MGMTSTYLE=Date

You can use the query status command to show the management type and value of the setting for the activity log.

TSM BA Client log files

By default, these log files are in the client installation directory.

dsmsched.log
• Contains status information for the Tivoli Storage Manager scheduler service.
• Contains Information about the schedule that runs next and the files that are processed.
• Change file name by specifying the schedlog name option in the options file. 

dsmerror.log
• Contains information about errors that occur during processing.
• The errorlogname option specifies the fully qualified path and file name of the file to store information about errors that occur during processing.

dsmwebcl.log
•  Web client messages are written to the web client log file, dsmwebcl.log.
• The dsmwebcl.log files are in the directory that you specify with the DSM_LOG environment variable or in the current working directory.

Audit Logging

You can configure the audit log for either basic or the full level of information. In addition to all of the events that are recorded in the basic level, the full level records information for a file that is excluded or not sent during a progressive incremental backup operation because the file is unchanged. The audit log is not a substitute for either the standard error log (dsmerror.log) or the schedule log (dsmsched.log).

Auditlogging generates an audit log that  has an entry for each file that is processed during an incremental, selective, archive, restore, or retrieve operation. Auditlogname specifies the path and file name for storing audit log information. This option applies when audit logging is enabled. The default name of the audit log is dsmaudit.log. It is in the same directory as the error log, named dsmserror.log.

In the dsm.opt file, you can specify both audit options.
auditlogging OFF|BASIC|FULL
auditlogname  c:\logs\audit.log

11.5 How to configure TSM Administrative Schedules

06:47 No Comments
Tivoli Storage Manager server includes a central scheduling component that you can use to schedule the automatic execution of client functions. This scheduler provides facilities to define, update, query, and delete client schedules, associating schedules with one or more client nodes, and reporting the success or failure for each scheduled event.

A similar mechanism is also provided to automate server operations. Many of the administrative commands can be used to tune server operations and start functions that require significant server or system resources. The Tivoli Storage Manager scheduler  can be used to automate administrative tasks to complete the following administrative tasks
  • Automate server operations.
  • Ensure server resources are available to clients.
  • Ensure that server functions are done with minimal manual intervention.
  • Administrative tasks are not associated with a policy domain.
  • You cannot schedule MACRO or QUERY ACTLOG commands.
Also Read: How to configure TSM Client Backup & Archive Schedules ?

 Each Tivoli Storage Manager schedule can schedule only one administrative command. When the schedule runs, it has the same authority as when the administrator defined it. It might be in the ACTIVE or INACTIVE state. The default is INACTIVE. The active state indicates that the schedule is eligible to run when the specified command window occurs. An administrator can also schedule commands that activate or inactivate other scheduled commands. The following processes are not supported by the administrative command scheduler
  • Command macros, as used on the administrative client
  • Redirection of command output
TSM Admin Schedule Syntax

When you define an administrative command schedule, you must specify the complete command that the schedule processes by using the CMD parameter. For example
define schedule schedname t=a cmd="migrate stg stgname lo=0"  active=yes

Following are some of the example admin schedules you can configure. 
  • You can schedule an administrative command to start migration. When the schedule runs, migration automatically begins. When the predefined threshold is reached, migration ends.
define sched migration_stg t=a cmd="migrate stg diskpool lo=0" startdate=today starttime=21:00 active=yes
  • To improve tape drive usability, ensure that reclamation occurs during hours when backup or threshold migration does not occur. You can schedule a command to lower the threshold for reclamation processing to zero so that when the command runs, reclamation automatically begins.
define sched reclamation_stg t=a cmd="reclaim stg tapepool threshold=0" startdate=today starttime=10:00 active=yes
  • Because file inventory expiration and duplicate identification are CPU-intensive jobs, schedule these tasks so that they run during the hours when the CPU load is low.
define sched expire t=a cmd="expire inventory duration=60" startdate=today starttime=4:00 active=yes
  • You can automate backup of the Tivoli Storage Manager server storage pool volumes.
define sched stg_backup t=a cmd="backup stg prim_stg copy_stg" startdate=today starttime=22:00 active=yes
  • You can automate Tivoli Storage Manager server database backup to ensure that a regularly scheduled backup occurs.
define sched db_backup t=a cmd="backup db devc=devc t=full" startdate=today starttime=20:00 acive=yes
  • You can schedule the PREPARE command to create the Disaster Recovery Plan file after backing up storage pools.
define sched drm_prep t=a cmd="prepare source=dbs" active=yes startdate=today starttime=05:00

Managing TSM Administrative Schedules

  • To view and remove the administrative command schedule status, use the query event and delete event commands. A Type=Administrative command is added to events so that you can discriminate between Type=Client and Type=Administrative commands.
query event schedname t=a
  • Redirection of command output is not allowed, instead, write output to the activity log. Using the administrative client and the query actlog command, you can assign the output and place it in a file to collect at a later time.
  • Schedules that are defined as Type=Client are identified by policy domain and schedule names. Schedules that are defined as Type=Administrative are qualified by only a schedule name. The schedules do not need to be associated to nodes or servers by names.

Additional functions you can do with TSM Admin Schedule

Export-import
You can define export and import admin schedules to export and import node policy, server and admin information.

Changing device class mount point limits
You might want to change device allocation for different server activities, such as migration. For example, you might want fewer devices during the day and more at night because during the day, the devices might be shared with other applications. 

Volume History File Maintenance
Volume history maintenance, deletion of unneeded recordsVolume history records are cumulative. You can delete older records periodically.

Device Configuration File Maintenance
You can schedule a backup of device configuration information to protect the TSM server, which is useful in TSM server recovery.

All administrative commands except query actlog
The output of a scheduled administrative command goes to the console and is recorded in the activity log. Consequently, if you can schedule the query actlog command in Tivoli Storage Manager, the activity log size immediately doubles.

The following client scheduling options do not apply to administrative command schedules
  • Maximum scheduled sessions
  • Schedule randomization percentage
  • Maximum command retries and retry period
  • Scheduling modes

11.4 Additional TSM Client Schedule Options

05:15 No Comments
After configuring the TSM Client schedules, you can manage the performance of these schedules with some additional parameters. Several processing options impact the performance of the client scheduler. 

Additional TSM Client Scheduling Options

You can define most of these options in the client options file, dsm.opt or dsm.sys, on the Tivoli Storage Manager client. You can also set some of these options globally on the Tivoli Storage Manager server by using set opt command for all Tivoli Storage Manager clients. Following are some of them

MAXCMDRETRIES
The MAXCMDRETRIES parameter specifies the maximum number of times that the client scheduler on your workstation attempts to process a scheduled command that fails. The Tivoli Storage Manager administrator can also set this option. If the Tivoli Storage Manager administrator specifies a value for this option, that value overrides the value specified in the client options file. The override occurs only after your client node successfully contacts the Tivoli Storage Manager server. All clients support this option.

RETRYPERIOD
The RETRYPERIOD parameter specifies the number of minutes for the client scheduler to wait between attempts to run a scheduled command that fails or between unsuccessful attempts to report results to the server. The Tivoli Storage Manager administrator can also set this option. If the Tivoli Storage Manager administrator specifies a value for this option, that value overrides your value in the client option file. The override occurs only after your client node successfully contacts the Tivoli Storage Manager server. All clients support this option. For UNIX clients, this option goes in the client system options file.

 Also Read: 11 tips to increase restore performance

Use the Set retryperiod command to specify the number of minutes that the scheduler on a client node waits between retry attempts. The retries occur after a failed attempt to contact the server or after a scheduled command fails to run.

Clients can set their own retry period at the time that their scheduler program starts. You can use the Set retryperiod command to set a global value for the retry period, which overrides the value that all clients specify. The value for the client is overridden only if the client connects with the server. When setting the period between retry attempts, set a time period that permits more than one retry attempt within a typical startup window. Use the Set retryperiod command in conjunction with the set maxcmdretries command to regulate the period of time and the number of retry attempts to run a failed command.

SCHEDLOGNAME
The SCHEDLOGNAME parameter specifies the name and location of a file for Tivoli Storage Manager to store the schedule log. For UNIX clients, this option goes in the client system options file. When you run the schedule command, output from scheduled commands is shown in the window and can be directed to the file that you specify with this option.

SCHEDLOGMAX
The SCHEDLOGMAX parameter specifies the maximum size of the schedule log, in megabytes. Log records are added to the end of the file until the maximum specified size is reached. When the maximum specified size is reached, a Continue at beginning of file log record is placed as the last record in the file. The end of the wrapped log is indicated by an END OF DATA log record. Log messages that are overwritten by wrapping are not saved in a prune file, as they are with the pruning method of log size management. If you change from SCHEDLOGMAX to SCHEDLOGRETENTION, all records in the existing log are copied to the pruned log, dsmsched.pru, the existing log is emptied, and the logging begins under the new log wrapping criterion.

SCHEDLOGRETENTION
The SCHEDLOGRETENTION parameter specifies the number of days to keep entries in the schedule log and whether to save the pruned entries. Tivoli Storage Manager prunes the log after every schedule runs if you specify Tivoli Storage Manager to prune. The default is not to prune the log. For UNIX clients, this option goes in the client system options file.

SCHEDCMDDISABLE
The SCHEDCMDDISABLE parameter specifies whether to disable the scheduling of generic commands that your Tivoli Storage Manager administrator specifies.

MANAGEDSERVICES
The MANAGEDSERVICES parameter specifies whether the Storage Manager Client Acceptor service manages the web client, the scheduler, or both.

MAXSCHEDSESSIONS
An administrator with system privileges can set the MAXSCHEDSESSIONS parameter. Use the SET MAXSCHEDSESSIONS command to regulate the number of sessions that the server can use to process scheduled work. This command specifies the maximum number of scheduled sessions as a percentage of the total number of server sessions that are available.

Additional client polling options       

MAXSCHEDSESSIONS
To check, issue a query status. The MAXSCHEDSESSIONS parameter is shown as a number, not a percentage. Change this setting if client nodes receive messages about server sessions not being available when they try to run scheduled events. If scheduled sessions do not contact the server, you might have a network error.

QUERYSCHEDPERIOD
The QUERYSCHEDPERIOD value for this parameter can be set by each client node at the time the client scheduler program starts. You can set a global value for the period between the attempts by the client to contact the server for scheduled work. This value overrides the value that the client specifies. Use the SET QUERYSCHEDPERIOD command to regulate the frequency that client nodes contact the server to obtain scheduled work. Use this command when the client nodes run in the client polling mode.

 Also Read: 8 commands to efficiently schedule TSM Expire Inventory Process

Use the QUERYSCHEDPERIOD option to specify the number of hours for the client scheduler to wait between attempts to contact the Tivoli Storage Manager server for scheduled work. This option applies only when the DSMC SCHEDMODE option is set to POLLING. Tivoli Storage Manager uses this option only when the dsmc schedule command is running.

Additional server prompted options

TCPCLIENTADDRESS
The TCPCLIENTADDRESS parameter specifies a TCP/IP address if your client node has more than one address, and you want the server to contact a different address than the one from the initial contact with the server. 

TCPCLIENTPORT
The TCPCLIENTPORT parameter specifies a TCP/IP port number if you want the Tivoli Storage Manager server to contact a different port than the one from the initial contact with the server. If the default or specified port is busy, Tivoli Storage Manager attempts to use any other available port. For UNIX clients, this option goes in the client system options file.

Preschedule and Postschedule options

Options are available for preschedule processing and postschedule processing during the client schedule process execution. These options can be overwritten by using the OPTION parameter in the schedule definition. You can run operating system scripts before and after the client schedule by using these 2 options. Remember that if the OS script fails the TSM schedule will also fails. PRESCHEDULECMD and PRENSCHEDULECMD specify client operating system commands that you want run before the Tivoli Storage Manager schedule process. 
  • The PRESCHEDULECMD schedule process waits for the client OS commands to finish before running. For example, preschedulecmd "c:\script.bat"
  • The PRENSCHEDULECMD schedule process does not wait for the client OS commands to finish before running. For example, prenschedulecmd "/tmp/del.sh"

Randomize option

The purpose of randomizing the start time is scattering scheduled work across the startup window. Randomizing balances the load on the server and the load on the networks without having to duplicate schedules, except for their start times. At the start of the backup process, the sever generates a list of the clients that are scheduled for backups. Randomization spreads out the start up times.

The Set randomize command specifies the degree that start times are randomized within the startup window of each schedule for clients that use the client polling mode. The maximum percentage of randomization allowed is 50%. This limit ensures that half of the startup window is available to retry scheduled commands that fail. To set randomization to 50%, enter the following command:   set randomize 50

11.3 TSM Client Schedule Modes Overview

08:32 No Comments
IBM Tivoli Storage Manager provides two types of Client schedule modes
  • Client-polling
  • Server-prompted
This schedule modes indicates how client nodes interact with the server for scheduling operations. With client-polling mode, client nodes poll the server for the next scheduled event. With server-prompted mode, the server contacts the nodes at the scheduled start time.

TSM Client Schedule Modes

By default, the server permits both scheduling modes. The default (ANY) allows nodes to specify either scheduling mode in their client options files. You can modify this scheduling mode. If you modify the default server setting to permit only one scheduling mode, all client nodes must specify the same scheduling mode in their client options file. Clients that do not have a matching scheduling mode will not process the scheduled operations. The default mode for client nodes is client-polling.

 Also Read: Increase TSM server performance by following these guidelines

TSM schedule mode

The scheduler must be started on the client node's machine before a schedule can run in either scheduling mode. You can instead prevent clients from starting sessions by managing these options, and allow only the server to start sessions with clients.  

Client polling Mode

This schedule mode is useful when a high percentage of clients start the scheduler manually on a daily basis. It also suupports randomization, which is the random distribution of scheduled start times. By randomizing the start times, Tivoli Storage Manager prevents all clients from attempting to start the schedule at the same time, which could overwhelm server resources.
  • First, the client queries the server for a scheduled operation.
  • The client waits for start time, then starts the scheduled operation.
  • When the operation completes, the client sends the results to the server.
  • The client node queries the server for its next scheduled operation.

Server prompted Mode

This schedule mode is useful if you change the schedule start time frequently. The new start time is implemented without any action required from the client node. Useful when a high percentage of clients are running the scheduler and are waiting for work. Use this mode if you want to restrict sessions to server-initiated. This mode does not allow for randomization of scheduled start times. Valid only with client nodes that use TCP/IP to communicate with the server.
  • First, the server contacts the client node when scheduled operations need to be performed and a server session is available.
  • When contacted, the client node queries the server for the operation, performs the operation, and sends the results to the server.

Changing TSM Schedule Modes

If you modify the default schedule mode so that the server permits only one scheduling mode for the server, all clients must specify the same scheduling mode in their client options file. Clients that do not have a matching scheduling mode do not process scheduled operations. You can change the schedule mode in both server and client.

 Also Read: Why is it important to use DIRMC option during backups ?

On the TSM server, the administrator with system privileges can specify the central scheduling modes that the server supports. Use the Set SCHEDMODes command to change.
set schedmodes ANY/POLLING/PROMPTED

ANY: Indicates the server can support clients that use either client polling or server prompted scheduling. ANY is the default and suggested value.
POLLING: Indicates that only clients that use client polling are accepted.
PROMPTED: Indicates that only clients that use server-prompted mode are accepted.

On the client, the options file must be updated with the SCHEDMODE option that specifies the mode that the client scheduler operates in. 
SCHEDMODe POlling | PRompted

11.2 How to Configure TSM Client Schedules

10:42 No Comments
You can configure automatic client tasks such as backup, archive, restore etc on the client machines by using TSM Client Schedule features. An administrator, who has either system or policy privileges can create and maintain the schedules in the Tivoli Storage Manager database. 

The schedule must be defined by a define schedule command and apply to a particular policy domain. Administrators use the define association command to associate clients, that are in the domain, with a schedule. You can associate a client with more than one schedule, and can define any number of schedules in a policy domain. A log is maintained on the server, which records information about the scheduled events. The administrator can query the log for information about started, finished, and failed events.

TSM client schedules

How to define TSM Client Schedules

You can define TSM client schedules in 2 different styles. They are

Classic client schedule
In classic schedules, the period might be as small as an hour.  The default type is classic. Example of classic style.
define schedule domainname schedname startdate=04/11/2014 starttime=23:00 duration=4 durunits=hours perunits=weeks dayofweek=saturday options=-quiet

 Also Read: How to configure TSM Server Administrative Schedules ?

Enhanced Client scheduling
The Tivoli Storage Manager scheduler provides calendar-based, or enhanced scheduling for increased flexibility of client and administrative schedules. SCHEDSTYLE defines either the interval between times that a schedule runs or the days that it runs.  Example of enhanced style
define schedule domainname schedname starttime=20:00 action=archive duration=1 durunits=hour schedstyle=enhanced month=mar,jun,sep,dec weekofmonth=last dayofweek=fri

The DEFINE ASSOCIATION command
After defining a client schedule as above, you have to use the define association command to associate one or more clients with a schedule. Client nodes that are associated with a schedule initiate Tivoli Storage Manager functions according to that schedule. This command uses the following parameters
define association domainname schedname node1,node2

Please check the video to learn how to do all these steps...

TSM Client Scheduler Services

When you define a client schedule on the TSM server, you have to run the scheduler services on the client to manage(start & stop) the schedule. There are 2 types of schedule services

Traditional scheduler services
  • Start with the dsmc sched command.
  • They remain active, even after scheduled backup is complete.
  • Require higher use of system resources when idle.
  • Tivoli Storage Manager client options and TSM server override options process only when dsmc sched starts.
  • You must restart the scheduler process for updated Tivoli Storage Manager options to take effect.
Also Read: How to configure DSMCAD service automatic restart in Linux
Client acceptor daemon (CAD) service
  • You have to install and configure the Tivoli Storage Manager client acceptor daemon service (CAD) to manage the scheduler.
  • The CAD serves acts as an external timer for the scheduler.
  • When the scheduler starts, it queries the server for the next scheduled event. The event either runs immediately or the scheduler exits.
  • The CAD restarts the scheduler when it is time to run the scheduled event.
  • Defined using the managedservices schedule option and started with client acceptor daemon services, dsmcad.
  • To specify whether the CAD manages the scheduler, you have to use the managedservices option in your client options file dsm.opt for Windows & dsm.sys for UNIX and Linux.
  • Using client acceptor services reduces the number of background processes.
  • The client acceptor (CAD) is a web client process, which uses an HTTP service that serves the web client Java applet to the web browsers.
  • On Windows, the client acceptor is installed and run as a service.
Schedule Startup window
A schedule has a startup window (DURATION parameter) that defines when a scheduled operation is to start. The client must start the scheduled operation within the startup window. If the client or the network is unavailable during the startup window, the client waits until the next occurrence of the schedule’s startup window to begin the operation. The scheduled operation must start within the window, but the scheduled operation can finish outside of the window.

How to define a one time client schedule from TSM Server

A Tivoli Storage Manager administrator can have a define clientaction command run on a Tivoli Storage Manager client without defining a schedule and associating the schedule with the client. With the define clientaction command, the command runs once only.

You can select clients from multiple domains by the use of the NODE and DOMAIN parameters. You can use pattern matching expressions in the node list specified. If no nodes are selected, the action is sent to all nodes.

When a command is specified with the define clientaction command, the speed at which that command runs depends entirely on the scheduling mode for the desired client. If the client schedule mode is server-prompted, the command runs immediately. If the client uses a schedule mode of POLLING, the action runs the next time that the client queries the server for its schedules, governed by the QUERYSCHEDPERIOD client parameter.

When you use the WAIT=[YES | NO] parameter with the define clientaction command, it specifies whether to wait for a scheduled client operation to finish. The purpose of the parameter is so the clientaction command finishes before the next step processes. This synchronous operation provides the serialization in a script. The default is NO.

The Set clientactduration parameter specifies the duration in days for the schedule and the number of days that the Tivoli Storage Manager database retains the schedule before it is automatically deleted. If this value is set to 0, the schedule duration is indefinite and the schedule and associations are not deleted. Only schedules and associations that are defined by the define clientaction are deleted from the Tivoli Storage Manager database automatically. to check the clientactduration value, use query status command.

define clientaction node1 domain=domainname action=incremental

If you dont mention any nodename or domain name in the above command, the schedule will run on all the registered clients by default. This is a dangerous command.

Managing Client Schedules

Querying and checking the status of a client schedule
You can check of the client schedule details by using query schedule command. Add the format equal detail (f=d) option to the command to request and list the output in a different format and provide more details.
Query schedule domainname schedulename f=d

To check the status of the client schedule, use query event command
query event domainname schedulename 

The COPY SCHEDULE command
You can use the copy schedule command to copy the schedule to another domain. An administrator can define any number of schedules in a policy domain. For example
copy schedule domain1 schedold domain2 sched2

Additional Scheduling options
Several processing options impact the performance of the client scheduler. You can define most of these options in the client options file, dsm.opt or dsm.sys, on the Tivoli Storage Manager client. You can also set some of these options globally on the Tivoli Storage Manager server for all Tivoli Storage Manager clients. Please check the document for more info on these options
  • MAXSCHEDSESSIONS
  • MAXCMDRETRIES
  • RETRYPERIOD
  • QUERYSCHEDPERIOD
  • RANDOMIZE*
  • POSTSCHEDULECMD
  • POSTNSCHEDULECMD
  • PRESCHEDULECMD
  • PRENSCHEDULECMD
  • MANAGEDSERVICES
  • TCPCLIENTADDRESS
  • TCPCLIENTPORT
  • SRVPREPOSTSCHEDDISABLED • SRVPREPOSTSNAPDISABLED
  • SCHEDRESTRETRDISABLED
  • SCHEDCMDDISABLED
  • SCHEDMODE
  • SESSIONINITIATION
  • SCHEDLOGNAME dsm.sys
  • SCHEDLOGRETENTION
All of the above parameters are used to manage and customize and customize the client schedules. use them according to your requirements.


PREVIOUS: 11.1 TSM Central Scheduling Overview
NEXT: 11.3 TSM Client Schedule Modes Overview
Subscribe to: Posts (Atom)