Administration Made Easier:

Scheduling and Automation in DB2®

Universal Database™

Version 8.1

January 2003

Jason Gartner
Manager, DB2 UDB Administration Tools Development

Subho Chatterjee
DB2 UDB Administration Tools Development
Notices
This information may include technical inaccuracies or typographical errors.

All statements regarding IBM's future direction or intent are subject to change or withdrawal without
notice, and represent goals and objectives only.

Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United
States and/or other countries: AIX, DB2, DB2 Universal Database, IBM

Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the
United States and/or other countries.
UNIX is a registered trademark of The Open Group in the United States and other countries.

Other company, product and service names may be trademarks or service marks of others.

© 2003 International Business Machines Corporation. All rights reserved.

Administration Made Easier

Table of Contents
Executive summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Architectural overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Creating the tools catalog database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Configuring the scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Executing tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Creating tasks using the Task Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Migrating V7 scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Keeping a history of tasks using the journal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Advanced topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Dialog-based tasks and reconstitution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Parallelization and grouping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Scenario: Backing up a partitioned
database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Tips for managing tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Create a naming scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Categorize tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Create customized views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Configuring your scheduling and automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Example of a server scheduling configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Example of a centralized scheduling scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Example of mixed-tier scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Advantages and disadvantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
About the authors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Appendix A: Setup checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Page 3
Administration Made Easier

Executive summary
Automation and scheduling are a major concern for many database shops. With the size and
number of databases continuing to grow, the need for scalable and reliable automation and
scheduling capabilities is even more important. With DB2 Universal Database Version 8.1, a
new set of administration tools is emerging to help you tackle this complex requirement. There
are four major components in DB2 for automation and scheduling:
Client - The administration facility for automation that includes the Task Center, Journal, Control
Center and associated wizards, dialogs and advisors.
Tools catalog database - The physical storage of tasks and related information, including
command script, schedule, execution criteria, and execution history.
Scheduler - The mechanism by which tasks are started. Controlled by the local DB2
Administration Server
DB2 administration server - This controls the scheduler and the actual execution of the task.

Task Center and journal

The Task Center is the administrative interface to automatable and schedulable tasks. The Task
Center is the second generation of automation within the DB2 Administration Tools replacing the
Script Center of Versions 5 to 7. Its capabilities are extensive. It allows:
Ÿ Different tasks to be created and to be run in a multitude of ways with a variety of options.
Ÿ Parallel grouping of tasks, follow-on actions, notification, repeat scheduling, and remote
execution.

The Journal contains the history of all tasks that have run, their status of success or failure, their
output and any notifications that occurred.

Control Center wizards, dialogs, and advisors

Many of the Control Center wizards, dialogs and advisors are integrated with the Task Center
They provide the capability to create complex tasks with added capabilities, such as progress
indication, and a new concept of reconstitution that allows you to edit a task with the originating
dialog.

Tools catalog database

A common tools catalog database shares data among the tool sets and stores all tasks and
information, such as history and schedules.

Scheduler and administrative server

The Scheduler, a component of the DB2 Administration Server, uses the information within the
tools catalog database to run the tasks at the specified time. By using the local DB2
Administration server on the remote system as the execution agent, the Scheduler can be remote
from the system that the task is run against.

In summary, a multitude of configurations are supported, including server-based scheduling and

centralized scheduling to suit individual environments. In this article, I describe the various
configurations to help you get started using DB2 scheduling and automation.

Page 4
Administration Made Easier

Introduction
Administration was revolutionized with the very first scheduling scripts and the introduction of
the cron job. Yet, today many database shops still use the cron, batch programming, and script
automation programs of 30 years ago. Why is this? The answer is simple: simplicity and
reliability. Until now, no automation programs have been introduced that provide the same level
of simplicity and reliability while at the same time adding value to encourage people to move to a
new paradigm. DB2 Universal Database Version 8.1 has engineered a scheduling and automation
solution to bring a comprehensive product that is simple, reliable, and which brings additional
value.

In a previous article, “Administration Made Easier: An Overview of DB2 UDB Version 8.1”
(http://www7b.software.ibm.com/dmdd/library/techarticle/0207gartner/0207gartner.html), I gave
a high level introduction to the multitude of new tools introduced in Version 8.1, including the
Task Center and new wizards. The concept of reconstitution was also introduced. This article is
a continuation of that article and delves deeper into the automation and scheduling capabilities of
the Version 8.1 tools. Here I will explain the concepts and setup, and I will provide scenarios and
specific examples.

Architectural overview
An important design point of any scheduling or automation architecture is server-side execution.
An automatable job is designed to run on the server, completely independent of the client that
created it. DB2’s concept of a task is a stand-alone object that contains all of the necessary
information to execute a given job. Everything from the actual script, to the schedule, to its run
system, to any of its follow-on actions, such as notification.

Page 5
Administration Made Easier

Client v7 or v8

Client Applications
- v8 Task Center
- v7 Script Center
- Control Center
Scheduling System v8

Tools Catalog
Database

Database Server v8
(Run System)
DAS
DB2 Scheduler
Database

DB2
Administration
Server

Figure 1. Architectural overview of scheduling in DB2

As shown in Figure 1, there are four major components (bolded) that make up automation and
scheduling.
Tools catalog database - The physical storage of tasks and their information, including script,
schedule, execution criteria, and execution history
Scheduler - The mechanism by which tasks are kicked off; it is controlled by the local DB2
Administration Server.
DB2 Administration Server - Serves a dual purpose by controlling the Scheduler and executing
the task.
Client - The administration facility of the tasks and includes the Task Center, Journal, Control
Center, wizards, etc.

Creating the tools catalog database

The tools catalog database contains about 80 tables and views which contain information that is
needed to execute a task and to retain its history. You must create the tools catalog on a DB2 for
Linux, UNIX®, or Windows® V8 system. You can create it as a stand-alone database or as
part of an existing database. There are many ways to create the tools catalog database:
Ÿ During the installation of any DB2 server product.
Ÿ Through the command line processor (CLP). (The syntax is shown in Figure 2.)
Ÿ Using the Control Center ( Control Center -> Tools -> Tools Settings, as shown in Figure
3).
Ÿ The first time you create a task using a wizard.

Page 6
Administration Made Easier

Figure 2. Syntax for creating the tools catalog

Figure 3. Creating the tools catalog using the Control Center

The tools catalog database stores the following information about the task:
Ÿ Definition of the task, including grouping, task type, command script
Ÿ Schedule
Ÿ Run system (the system on which the script is to be run)
Ÿ History of execution
Ÿ Information for reconstitution
Ÿ Notification information
Ÿ Other miscellaneous information

Page 7
Administration Made Easier

Configuring the scheduler

The scheduler and the tools catalog database always go hand in hand, and neither can function
without the other. The scheduler is a specific piece of the DB2 Administration Server that acts as
an agent to read the tools catalog database and executes the tasks at their respective times. The
scheduler sends the script component of a task to the Run system for execution by the local DB2
Administration Server. The Scheduler is also responsible for follow-on task actions, notifications,
etc.

You can configure the scheduler through the Admin Server Configuration. As shown in Figure 4,
the Admin Server Configuration tells the Scheduler the location of the tools Catalog Database,
and whether or not the Scheduler should be enabled. By default, when a tools catalog database is
created, its corresponding Admin Server Configuration is updated such that the Scheduler is
configured and ready to use the new tools catalog; there is no need to restart the DB2
Administration Server.

Admin Server Configuration

Authentication Type DAS (AUTHENTICATION) = SERVER_ENCRYPT

DAS Administration Authority Group Name (DASADM_GROUP) =

DAS Discovery Mode (DISCOVER) = SEARCH

Name of the DB2 Server System (DB2SYSTEM) = HOMER

Java Development Kit Installation Path DAS (JDK_PATH) = D:\SQLLIB\java\jdk\

DAS Code Page (DAS_CODEPAGE) = 0

DAS Territory (DAS_TERRITORY) = 0

Location of Contact List (CONTACT_HOST) =

Execute Expired Tasks (EXEC_EXP_TASK) = NO
Scheduler Mode (SCHED_ENABLE) = ON
SMTP Server (SMTP_SERVER) =
Tools Catalog Database (TOOLSCAT_DB) = TEST
Tools Catalog Database Instance (TOOLSCAT_INST) = DB2
Tools Catalog Database Schema (TOOLSCAT_SCHEMA) = SYSTOOLS
Scheduler User ID = JGARTNER

Figure 4. Sample Admin Server configuration file

The tools catalog database can be created on a server that is local or remote from the Scheduler
system. If you create the tools catalog on a remote server, you must catalog it on the scheduler
tools catalog database instance (TOOLSCAT_INST). You set the Scheduler User ID during the
creation of the DB2 Administration Server, or by using the command db2admin
setschedid, so that the scheduler can connect and authenticate with the remote tools catalog.
Full syntax of the db2admin command can be found in the DB2 Command Reference.

64-bit instances: For AIX®, SUN and HP 64-bit instances, you must set an additional
parameter, JDK_64_PATH , with the location of the 64-bit JDK. This parameter will only be

Page 8
Administration Made Easier

available in the first FixPak release of Version 8.1. The original release of Version 8.1 is still
supported by using the existing JDK_PATH parameter.

Executing tasks
The DB2 Administration Server is used for many purposes; however, for the purpose of this
article, I describe only the role it plays with automation and scheduling. Think of the DB2
Administration Server as the underlying base controller by which tasks run and execute. The
scheduler system and the run system may be different. The Scheduler is responsible for sending
the script part of the task to the run system. The run system contains a local DB2 Administration
Server that later executes the script against the system, instance, or partition, depending on
whether it is an operating system script or DB2 script. This model provides the ultimate
flexibility for centralized scheduling and allows a multitude of configurations. Most importantly,
it provides complete server-side execution. In this model, you do not need a client machine to
execute scripts, and if the scheduler system or the client is interrupted, the script that was started
on the server runs to completion.

Creating tasks using the Task Center

The Task Center is the external hub for scheduling and automation. This is where you create,
edit, schedule, reconstitute, and debug tasks. In this section, I describe only those tasks that you
create using the Task Center. Currently the only other type of task which can be created is by the
Control Center called Dialog-based tasks. Dialog-based tasks are described in a further section.

Figure 5. Creating a new task in the Task Center

Page 9
Administration Made Easier

Here are the attributes you can set for a task:

Ÿ The script can be any DB2 command script or an OS script. The default termination character
can be customized using the Tools Settings option.
Ÿ The schedule can be a repeatable schedule based on the criteria of your choice, such as every
third Sunday of the month at 1:00 a.m., or it can be made completely out of custom dates and
times.
Ÿ The run system is the system that the script is to run on. The script does not need to be run
locally.
Ÿ You can indicate that the task execute on a particular instance or partition of the run system.
If you choose more than one partition for the command, it will be run in parallel. If you need
a different command to run on different systems or partitions and that command must be run
in parallel or serially, then create a separate task for that script and use the grouping function,
described in Advanced topics.
Ÿ You can specify that an administrator be notified of the success or failure of the task. You
can determine what codes can be treated as a successful operation of the script. For
example, you may want a task to be successful if its error code is >= 0 and you may
(depending on the task) consider -911 a successful completion of an action. In this case, you
would specify >0, =0, =-911. Essentially, all success codes are OR’d together to create a
full list of successful error codes. For each line of execution, the return code is compared to
the list of successful error codes and if it does not belong to the list, the script execution stops
and is considered a failure. By default, all error codes >=0 are considered successful.
Ÿ You can chain tasks based on the success or failure of the previous task. For example, on a
failed redistribution, you may want to roll back the redistribute to its last known consistency
point; however, on a successful completion of a redistribute, you may wish to run statistics
against a new data skew.
Ÿ Use a “Run Now” scenario for debugging. With “Run Now”, you can temporarily disable
notification and follow-on tasks. This allows you to run a task multiple times while fine
tuning it. The actual task itself retains its original parameters so that when it is scheduled, it
runs in full automation.

Migrating V7 scripts
The Task Center replaces the V7 Script Center. You can migrate Version 7 scripts into Version
8 tasks during the DAS migration, as follows:
1. Install Version 8.
2. Create a tools catalog database.
3. Running the dasmigr command to migrate the DAS and migrate all Version 7 Script Center
scripts to V8 tasks.

Keeping a history of tasks using the journal

Unlike the Task Center, which shows only information about the last execution of a particular
task, the journal keeps a history of all executions of all tasks. You can locate any execution of a
task and find out its output, SQLCODE, notification and follow-on task actions. You can also see
the actual command script that was executed, which may be different from what would be
executed today. You can also directly edit the task from the journal allowing you to modify the
Page 10
Administration Made Easier

task based on the history or outcome of the task. Because the journal saves the execution history
of every task, it can quickly become large. You can easily prune the entries in the journal through
multi-selection deletes of old or unwanted task histories.

Figure 6. Journal

Page 11
Administration Made Easier

Advanced topics
This section describes the following topics:
Ÿ Dialog-based tasks, and reconstitution
Ÿ Parallelization and grouping of tasks
Ÿ Notifications

Dialog-based tasks and reconstitution

Many of the dialogs, wizards and advisors that exist within the Control Center can create
dialog-based tasks that have added capabilities over pure Task Center tasks, including:
Ÿ Reconstitution
Ÿ Progress indication
Ÿ Predefined parallel, serial and follow-on execution capabilities that use the capabilities of the
Task Center

Reconstitution is a simple, yet powerful concept: If you create a task using a wizard, that task can
be edited using the original wizard that created it using Edit ...with Dialog. This means that an
administrator who is unfamiliar with a command and all its options can edit a previously created
script without having to fully understand each and every option within the command. For
example, assume that the Backup Wizard was used to create a task. If the option to quiesce the
database was not originally selected, you do not have to edit the task manually to add it. You can
simply edit the task with the wizard, select the option and re-save the task. You could also
choose to save the task as a new task, thereby preserving the old task in its original state.

Dialog-based tasks also have the unique ability to show progress indicators for certain operations.
As shown in Figure 8, the load utility, for example, can let you know approximately how many
rows have been loaded out of how many yet to be loaded as well as what phase the load currently
is in. Of course, not all utilities support this type of detailed progress indication; for these, the
task progress is shown with basic statistics such as how long the task has been running, when it
started, etc. Wherever the utility supports detailed progress indication, the tools support the
detailed progress as well.

Page 12
Administration Made Easier

Figure 8. Progress details of a Load task created using the Load Wizard

Tasks created by wizards may be complex and not be simple tasks, but may contain many
commands within the script and can possibly contain many tasks to be chained and run in parallel
or serially. This is explored further in the next section on parallelization and grouping.

Parallelization and grouping

Unlike V7, within a single task, a command script can be run against multiple partitions in parallel.
This is for running the exact same command against partitions in parallel, such as updating
database configuration parameters on all partitions. With Version 8 you can now perform many
types of custom actions by using:
Ÿ Follow-on task actions
Ÿ Grouping
Ÿ Instance/Partition field to specify instance and partitions task is to be run

Grouping is the concept of grouping together more than one task and using that grouping of tasks
as a single entity. This single entity is represented by a grouping task. You can then use that
single grouping task as a regular task to control the schedule, perform follow-on actions,
notifications, or even have it executed as a follow-on action. Grouping multiple tasks together

Page 13
Administration Made Easier

gives you the capability to now run a different command scripts on different instances or
partitions. Let’s look at a scenario in which these capabilities are used.

Scenario: Backing up a partitioned database

Assume that you have an eight-partition database on four physical machines. Partitions 1 and 2
are on machine 1, partitions 3 and 4 are on machine 2, partitions 5 and 6 are on machine 3 and
partitions 7 and 8 are on machine 4. To back up the database as quickly as possible you will want
to backup the catalog partition first, then utilize the parallelism of the machines by backing up a
single partition per machine in parallel with each machine. In order to accomplish this you will
want to execute back up tasks in the following order:

1. Quiesce the database.

2. Back up catalog partition 1.
3. Back up partitions 3, 5 and 7 in parallel.
4. Back up partitions 2, 4, 6 and 8 in parallel.
5. Unquiesce the database and activate it again.

Although this is the order, there are different ways to accomplish this.

Example 1. In the first example, shown in Figure 9, the catalog partition must be successfully
backed up, then all of the partitions 3, 5 and 7 have to complete and be successful before any
other partitions are subsequently backed up.

Quiesce Database

Back up Partition 1
(Catalog Partition)

Grouping Task 1

Back up Partition 3 Back up Partition 5 Back up Partition 7

Grouping Task 2

Back up Partition 2 Back up Partition 4 Back up Partition 6 Back up Partition 8

Unquiesce
Database

Figure 9. Each task must complete before proceeding to next task

Example 2. In the second example, shown in Figure 10, the second partition can be backed up
as soon as the first partition is complete. Only after all partitions are backed up can the database
Page 14
Administration Made Easier

be unquiesced. In other words, after the catalog partition is backed up, partitions 2, 3, 5 and 7
begin their backup. When 3 is complete, 4 begin. When 5 is complete, 6 begins, and when 7 is
complete, 8 begins. After 2, 4, 6 and 8 are successfully backed up, the database is unquiesced.

Quiesce Database

Back up Partition 1
(Catalog Partition)

Grouping Task

Back up Partition 3 Back up Partition 5 Back up Partition 7

Back up Partition 2

Back up Partition 4 Back up Partition 6 Back up Partition 8

Unquiesce
Database

Figure 10. A different grouping of parallel tasks

Example 3. The third example accomplishes the same end result, but takes advantage of the fact
that the actual command to be executed on different partitions is the same. By using the
Instance/Partition field in the task properties, you can set a command to be run in parallel across
many systems. In this example, the catalog partition is backed up alone. Once successful, a
follow-on task is executed that backs up partitions 3, 5 and 7 in parallel, by setting the
Instance/Partition field to <instance name> 3,5,7. After all of these partitions are successful,
and only then, partitions 2, 4, 6 and 8 are backed up. This simplified example only works if you
have the exact same command to be run on each partition. If you need a different command to be
run on different partitions, such as for a restore, then you have to revert back to the grouping
examples 1 and 2.

Page 15
Administration Made Easier

Quiesce Database

Back up Partition 1
(Catalog Partition)

Back up Partition
3, 5 7

Back up Partition
2, 4, 6, 8

Unquiesce
Database

Figure 11. Using follow-on tasks to back up. This example works only when using the exact
same command across all of the partitions.

As these examples show, there is no more need for complex error-prone scripts or for polling
scripts to see when a list of parallel actions has completed. All of this functionality is provided
within the Task Center. Even better, if you want to do parallel backup, the Backup Wizard does
all of this for you. The Backup Wizard actually uses Example 3 to achieve parallelism. Many of
the Wizards provide this capability where it makes sense.

Notification
The notification capability in Version 8.1 is one of the true value-adds to the scheduling and
automation capabilities DB2. Notifications are e-mails or pages which are sent by the scheduler
when a task completes, either successfully or not. The notification messages are completely
customizable, which means the e-mail subject and body can contain information to make it easy
for the task to be identified.

You can create a contact list within the Task Center, Control Center, or Health Center. Using
the Contacts window (Figure 12), you can add individual contacts or group contacts which can
contain other contacts or other groups of contacts. These contacts can be e-mail contacts or
pager contacts. Within the Contacts window, you can test the SMTP server and test any address.
The contact list is common, so it is used across all of the centers that provide notification. You
can create a contact list to be associated with a particular scheduler, or you can create a global
contact list.

To set up notification, ensure that you have an SMTP server set up, and specify the SMTP server
TCPIP hostname in the SMTP_SERVER parameter in the Admin Server Configuration. This can be
any unauthenticated SMTP server. If you want to use a global contact list, you must specify the
TCPIP host name of the scheduler that has the global contact list in the CONTACT_HOST
parameter.

Page 16
Administration Made Easier

When would you want to use a global contact list? Global contact lists are of particular interest to
configurations with more than one system. For example, assume you use the server scheduling
setup shown in Figure 15. You could choose one server as your global contact list host. Update
the Admin Server Configuration CONTACT_HOST parameter of the other servers with the host
name of the global contact list host.

Figure 12. Contacts window where new contacts and groups can be added and tested

Tips for managing tasks

Here are a few simple techniques to help you manage a possibly large number of tasks.

Create a naming scheme

Create a naming scheme that you and others can easily understand. The default names of tasks
created for you in a wizard may or may not be useful to you. The default naming scheme is:

<Wizard> - <Timestamp> [ - Subtask]

The <Wizard> - <Timestamp> portion is always editable when creating new tasks; change it if
you need to. [- Subtask] is only used for dialogs and wizards that create multiple tasks. For
example, the Backup Wizard creates tasks such as ‘Backup - 10/2/02 10:42:51 PM EDT -

Page 17
Administration Made Easier

QUIESCE’. Task names must be unique; the timestamp is put into the name to ensure task name
uniqueness. Another easy way to achieve this is to think of all the characteristics that make the
tasks unique. It may be the database name, the instance, the command, etc. The naming scheme I
like to use is:

<database> - <command> - <object name> (details)

For example:
SAMPLE - LOAD - JGARTNER.EMPLOYEE (ixf)
SAMPLE - LOAD - JGARTNER.EMPLOYEE (del employee.del)
SAMPLE - REORG - JGARTNER.EMPLOYEE
SAMPLE - QUIESCE
SAMPLE - ONLINE BACKUP - 1

This way, just given the name, you can easily find the task in question. This also helps protect
you from creating duplicate tasks.

Categorize tasks
You can create and assign tasks to categories. Tasks can be categorized as follows: by database,
by partition, by instance, or by command type.

You can assign a task to one or more categories so that a group of tasks can be sorted in various
ways. By default, all tasks created by the dialogs in the Control Center have a Category name of
‘<Wizard> Tasks’, which is editable. However, all tasks also have a field called ‘Generated By’
that is filled in with the wizard name; that is non-editable. For example, even if you change the
categories of all the tasks created by the Backup Wizard, you can easily find all the tasks created
by this wizard, because the ‘Generated By’ field for these tasks will always be ‘Backup Wizard.’
I recommend that you take advantage of this feature and categorize your tasks in whatever way is
best for you.

The categorization scheme I use is:

<database>, <Overall task>, <Command>, <Object>

For example:
SAMPLE, Backup, QUIESCE
SAMPLE, Backup, BACKUP
SAMPLE, Backup, UNQUIESCE
SAMPLE, Load, LOAD, JGARTNER.EMPLOYEE
SAMPLE, Load, REORG, JGARTNER.EMPLOYEE

With this example, when using the predefined view ‘Overview by Categories’, you can see all
tasks against database SAMPLE, or all chained commands in an overall, or all LOADs grouped
together, or even all tasks against the object JGARTNER.EMPLOYEE.

Page 18
Administration Made Easier

Create customized views

Version 8.1 introduces the ability to create your own customized views with your own
customized columns and sorting orders. As shown in Figure 13, there are nine predefined views
in the Task Center that you can customize according to your personal naming and categorization
scheme. The predefined views are very useful and can easily be selected using the toolbar at the
bottom of the window. You can then further customize these views to your particular need by
adding or removing columns, or you can create further groupings with your own customized sort.
Do this using the View button on the toolbar at the bottom of the window.

Most of these views are self-explanatory; however, one of particular interest is the ‘Generated by’
view. This view groups together all tasks that have been created by particular wizards at a
particular time. If a wizard creates a set of tasks, you can use the ‘Generated by’ view to easily
see and act on these tasks as a whole as opposed to hunting for the different tasks that were
created.

Figure 13. Pre-defined views in the Task Center

Configuring your scheduling and automation

There are many ways to configure your scheduling and automation scheme; however, all
configurations fall into two categories:
Ÿ Server-based scheduling
Ÿ Centralized scheduling

Ay time you create a task within the Task Center or within any of the tools, you can create a task
against any cataloged scheduler. However, the tools provide you with a way to default to a
specified scheme depending on your selection within the Tools Settings. Server scheduling is
based on having a scheduler set up on each database server, while centralized scheduling means
having one or a select number of schedulers used for all systems. If you specify centralized
scheduling and provide a scheduler system, this becomes your default each time you create a task.
With centralized scheduling, authentication is a serious consideration. The ‘runtime
authorization’ of a task is granting the scheduler the ability to start a task on the Run system,
which is the database system. This runtime authorization is not a database connection user ID and
password, but rather the user ID under which the task will run. The user ID must exist on the
Run system, but it does not need to exist on the scheduler system.

Page 19
Administration Made Easier

Example of a server scheduling configuration

Figure 15 shows a typical server scheduling scheme in which a scheduler and tools catalog is
created on each database server.

Client

Client Applications
- Task Center
- Control Center

Database Server 1 Database Server 2 Database Server n

DB2 Tools DB2 Tools DB2 Tools

Catalog Catalog Catalog
Database Database Database
Database Database Database

DB2 Administration Server DB2 Administration Server DB2 Administration Server

Scheduler Scheduler
... Scheduler

Figure 15. DB2 server scheduling scheme

Page 20
Administration Made Easier

Example of a centralized scheduling scheme

Figure 16 shows a typical centralized scheduling scheme in which one scheduler serves multiple
database servers. The tools catalog can be either local or remote to the scheduler. This
configuration is set up by setting the following parameters in the Admin Server Configuration:

Tools Catalog Database (TOOLSCAT_DB) = TEST

Tools Catalog Database Instance (TOOLSCAT_INST) = DB2
Tools Catalog Database Schema (TOOLSCAT_SCHEMA) = SYSTOOLS
Scheduler User ID = JGARTNER

The scheduler user ID is a requirement if the database is not local to the server and can only be set
when the DB2 Administration Server is created.

Client Scheduling System Tools Catalog System

Client Applications DAS

- Task Center Tools Catalog
Database
- Control Center Scheduler

Database Server 1 Database Server 2 Database Server n

DB2 Database DB2 Database DB2 Database

DB2 DB2 DB2

Administration Administration Administration
Server Server
... Server

Figure 16. DB2 centralized scheduling scheme with remote tools catalog

Page 21
Administration Made Easier

Example of mixed-tier scheduling

Figure 17 shows a way to combine centralized and server scheduling into a a mixed-tier setup. It
illustrates the multitudes of possible configurations you could have, depending on the system
layout of your infrastructure. In this example, there are two central servers for tasks and
scheduling. One of the servers also has several databases, the other server has a database and acts
as a remote scheduler for two other databases.

Database Server 2

DB2 Database 2

Database Server 1 DB2

Administration
Tools Server
DB2
Database Catalog
Database Database Server 3

DB2 Database 3
DB2 Administration Server
Client Scheduler
DB2
Administration
Client Applications Server
- Task Center
- Control Center

Database Server 4

DB2 DB2 DB2 Tools

Catalog
Database 4 Database 5 Database 6
Database

DB2 Administration Server

Scheduler

Figure 17. Example of a mixed-tier scheduling scheme

Advantages and disadvantages

Each one of these configurations has advantages and disadvantages. A server-based scheduling
scheme is beneficial for few databases which are different from one another. This allows the
actual scheduling to occur on the database and the maintenance of the scheduling scripts and tasks
to occur on that system. This is a very separated scheme and very straightforward.

A centralized scheduling scheme, although more complex, is beneficial for a large number of
databases. With this, you can have one point of maintenance for all scheduling. You can easily
create and compare tasks of one database to another. With this scheme you will need to use
customized views to separate the many tasks that will be created.

Page 22
Administration Made Easier

Conclusion
The scheduling and automation capabilities in DB2 UDB Version 8.1 are quite extensive and
include many value-add capabilities over the traditional cron jobs and polling scripts. Even if you
are not a “GUI-person” you can see the advantages that such a comprehensive system provides.
The Task Center is a stand-alone tool and can be used in such a way that any other GUI tools are
not required. The DB2 administrative tools have a lot to offer. This article shows you just a
sliver of their capabilities. I encourage you to try out DB2 UDB Version 8.1. I am sure that you
will be as excited as I am about the strides that have been made in minimizing the overall cost of
ownership and in providing you with solutions to many of your administrative problems.

About the authors

Jason Gartner, a Professional Engineer, has worked on DB2 at the IBM Toronto Software Lab
since 1996, his most recent assignment as a technical manager of the DB2 Administration Tools
Development. His focus has been to ensure that the performance and quality of the administration
tools is prioritized, and that the tools fully exploit multipartitioned environments and autonomic
computing technologies.

Subho Chatterjee has worked on DB2 at the IBM Toronto Software Lab since 1998. His focus
has been on providing tools infrastructure such as the DB2 Administration Server and to improve
the usability, performance and up and running experience of the DB2 administration tools. He is
currently part of the autonomic computing effort with responsibilities for various self-monitoring
and self-healing technologies in DB2.

Page 23
Administration Made Easier

Appendix A: Setup checklist

Many configurations may look very different, but in most cases they are very similiar in setup.
With DB2, even complex scheduling systems are just as easy to set up as the simple ones. To
help you create a scheduling scheme that is right for you, I’ve created a checklist for each setup.

Run system (database server)

o Ensure DB2 Administration Server Version 8 is running; check this using the db2admin
command.

Tools catalog system

o Ensure DB2 Version 8 is installed.
o Ensure that the Tools Catalog has been created.

Scheduling system
o Ensure that DB2 Administration Server Version 8 is installed.
o Ensure that the following Admin Server configuration parameters are set:
Parameter Parameter Name Parameter Value Comments
Java™ Development Kit JDK_PATH Path for JDK.
Installation Path
Java Development Kit JDK_64_PATH** Set this only if the scheduler instance is
Installation Path 64-bit 64-bit AIX, SUN or HP.
Location of Contact List CONTACT_HOST Only required if using a global contact list.
Scheduler Mode SCHED_ENABLE* Set to ON.
SMTP Server SMTP_SERVER Set to SMTP Server TCPIP hostname for
notification.
Tools Catalog Database TOOLSCAT_DB* Tools catalog database name.
Tools Catalog Database TOOLSCAT_INST* Tools catalog database instance name.
Instance
Tools Catalog Database TOOLSCAT_SCHEM Tools catalog database schema name.
Schema A*
Scheduler User ID Set this using command db2admin
setschedid; required only if the tools
catalog is not local to the scheduler.
* If the tools catalog is local to the scheduler, these fields should already be set.
** Parm only available in first FixPak of Version 8.1. GA Version uses 32-bit JDK parm

o Ensure that the DB2 Administration server is restarted after changing parameters.
o Ensure that the tools catalog is cataloged on the local tools catalog instance.

Client
o Ensure that the DB2 Version 8 Administration Client has been installed.
o Ensure that the scheduling system has been cataloged.
o Optionally, ensure that the databases you are administering have been cataloged.
o Optionally, select to use centralized scheduling or server scheduling through the Tools ->
Tools Settings menu option.

Page 24