administration made easier - scheduling and automation in db2

8/9/2019 Administration Made Easier - Scheduling and Automation in DB2

1/24

Administration Made Easier:Scheduling and Automation in DB2

Universal Database

Version 8.1

January 2003

Jason GartnerManager, DB2 UDB Administration Tools Development

Subho ChatterjeeDB2 UDB Administration Tools Development


2/24

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 withoutnotice, and represent goals and objectives only.

Trademarks

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

Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in theUnited 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.


3/24

Table of Contents

24Appendix A: Setup checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23About the authors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22Advantages and disadvantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22Example of mixed-tier scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21Example of a centralized scheduling scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20Example of a server scheduling configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19Configuring your scheduling and automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19Create customized views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18Categorize tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17Create a naming scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17Tips for managing tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14

Scenario: Backing up a partitioned

database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13Parallelization and grouping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12Dialog-based tasks and reconstitution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12Advanced topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10Keeping a history of tasks using the journal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10Migrating V7 scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9Creating tasks using the Task Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9Executing tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8Configuring the scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6Creating the tools catalog database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5Architectural overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4Executive summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Administration Made Easier

Page 3


4/24

Executive summaryAutomation and scheduling are a major concern for many database shops. With the size andnumber 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 journalThe 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 CenterThey 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 DB2Administration 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


5/24

IntroductionAdministration 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 anew 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 ofreconstitution 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 overviewAn 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. DB2s 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 runsystem, to any of its follow-on actions, such as notification.


Page 5


6/24

Client Applications

- v8 Task Center

- v7 Script Center

- Control Center

Tools CatalogDatabase

DAS

DB2Administration

Server

DB2Database

Client v7 or v8

Scheduling System v8

Database Server v8

(Run System)

Scheduler

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 executingthe task.

Client - The administration facility of the tasks and includes the Task Center, Journal, Control

Center, wizards, etc.

Creating the tools catalog databaseThe 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 forLinux, 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


7/24

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


8/24

Configuring the schedulerThe 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 DB2Administration 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) = DB2Tools 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 theDB2 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


9/24

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 tasksThe 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 DB2Administration 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 onwhether 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 CenterThe 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


10/24

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

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 ORd 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 finetuning it. The actual task itself retains its original parameters so that when it is scheduled, it

runs in full automation.

Migrating V7 scriptsThe Task Center replaces the V7 Script Center. You can migrate Version 7 scripts into Version8 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 journalUnlike 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 seethe 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


11/24

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


12/24

Advanced topicsThis section describes the following topics: Dialog-based tasks, and reconstitution

Parallelization and grouping of tasks

Notifications

Dialog-based tasks and reconstitutionMany 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 canbe 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 currentlyis 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


13/24

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 groupingUnlike 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


14/24

gives you the capability to now run a different command scripts on different instances or

partitions. Lets look at a scenario in which these capabilities are used.

Scenario: Backing up a partitioned databaseAssume 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 anyother partitions are subsequently backed up.

Grouping Task 1

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

Quiesce Database

UnquiesceDatabase

Back up Partition 2

Grouping Task 2


Back up Partition 1(Catalog Partition)

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


15/24

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.

Grouping Task


Quiesce Database

UnquiesceDatabase

Back up Partition 2



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


16/24

Back up Partition3, 5 7

Back up Partition2, 4, 6, 8

Quiesce Database

UnquiesceDatabase


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

NotificationThe 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 completelycustomizable, 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 orpager 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 unauthenticatedSMTP server. If you want to use a global contact list, you must specify theTCPIP host name of the scheduler that has the global contact list in the CONTACT_HOST

parameter.


Page 16


17/24

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 tasksHere are a few simple techniques to help you manage a possibly large number of tasks.

Create a naming schemeCreate 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:

- [ - Subtask]

The - portion is always editable when creating new tasks; change it ifyou 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


18/24

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:

- - (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 tasksYou 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 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:

, , ,

For example:

SAMPLE, Backup, QUIESCE

SAMPLE, Backup, BACKUP

SAMPLE, Backup, UNQUIESCESAMPLE, 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


19/24

Create customized viewsVersion 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 viewsin 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 byadding 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 automationThere are many ways to configure your scheduling and automation scheme; however, allconfigurations 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 centralizedscheduling 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


20/24

Example of a server scheduling configurationFigure 15 shows a typical server scheduling scheme in which a scheduler and tools catalog is

created on each database server.

Client Applications

- Task Center

- Control Center

Client

...

ToolsCatalog

Database

DB2Database

Database Server 1

DB2 Administration Server

Scheduler

ToolsCatalog

Database

DB2Database

Database Server n


Scheduler

ToolsCatalog

Database

DB2Database

Database Server 2


Scheduler

Figure 15. DB2 server scheduling scheme


Page 20


21/24

Example of a centralized scheduling schemeFigure 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. Thisconfiguration is set up by setting the following parameters in the Admin Server Configuration:

Tools Catalog Database (TOOLSCAT_DB) = TESTTools Catalog Database Instance (TOOLSCAT_INST) = DB2

Tools Catalog Database Schema (TOOLSCAT_SCHEMA) = SYSTOOLSScheduler 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 Applications- Task Center

- Control Center

Tools CatalogDatabase

Client Scheduling System

DB2Administration

Server

DB2 Database

Database Server 1

DB2Administration

Server

DB2 Database

Database Server n

DB2Administration

Server

DB2 Database

Database Server 2

...

DAS

Scheduler

Tools Catalog System

Figure 16. DB2 centralized scheduling scheme with remote tools catalog


Page 21


22/24

Example of mixed-tier schedulingFigure 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 systemlayout 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.

Client Applications

- Task Center

- Control Center

Client

DB2Administration

Server

DB2 Database 2

Database Server 2

DB2Administration

Server

DB2 Database 3

Database Server 3

ToolsCatalog

Database

DB2Database 6

Database Server 4

DB2Database 5

DB2Database 4

ToolsCatalog

Database

DB2Database

Database Server 1


Scheduler


Scheduler

Figure 17. Example of a mixed-tier scheduling scheme

Advantages and disadvantagesEach 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 tasksto 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 easilycreate 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


23/24

ConclusionThe 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 asliver 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 ofownership and in providing you with solutions to many of your administrative problems.

About the authorsJason 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 focushas 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


24/24

Appendix A: Setup checklistMany 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, Ive 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:

Set this using command db2admin

setschedid; required only if the tools

catalog is not local to the scheduler.

Scheduler User ID

Tools catalog database schema name.TOOLSCAT_SCHEMA*

Tools Catalog DatabaseSchema

Tools catalog database instance name.TOOLSCAT_INST*Tools Catalog Database

Instance

Tools catalog database name.TOOLSCAT_DB*Tools Catalog Database

Set to SMTP Server TCPIP hostname fornotification.

SMTP_SERVERSMTP Server

Set to ON.SCHED_ENABLE*Scheduler Mode

Only required if using a global contact list.CONTACT_HOSTLocation of Contact List

Set this only if the scheduler instance is

64-bit AIX, SUN or HP.

JDK_64_PATH**Java Development Kit

Installation Path 64-bit

Path for JDK.JDK_PATHJava Development Kit

Installation Path

Parameter Value CommentsParameter NameParameter

* 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

administration made easier - scheduling and automation in db2

Documents