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, u the information within the ses 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. 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 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)

DB2 Database

DAS

Scheduler

DB2 Administration Server

Figure 1. Architectural overview of scheduling in DB2 As shown i Figure 1, there are four major components (bolded) that make up automation and n 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 DAS Administration Authority Group Name DAS Discovery Mode Name of the DB2 Server System Java Development Kit Installation Path DAS DAS Code Page DAS Territory Location of Contact List Execute Expired Tasks Scheduler Mode SMTP Server Tools Catalog Database Tools Catalog Database Instance Tools Catalog Database Schema Scheduler User ID (AUTHENTICATION) = SERVER_ENCRYPT (DASADM_GROUP) = (DISCOVER) = SEARCH (DB2SYSTEM) = HOMER (JDK_PATH) = D:\SQLLIB\java\jdk\

(DAS_CODEPAGE) = 0 (DAS_TERRITORY) = 0 (CONTACT_HOST) (EXEC_EXP_TASK) (SCHED_ENABLE) (SMTP_SERVER) (TOOLSCAT_DB) (TOOLSCAT_INST) (TOOLSCAT_SCHEMA) = = = = = = = =

NO ON TEST DB2 SYSTOOLS 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 t e DB2 h 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 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 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. Lets 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 2 Back up Partition 4 Back up Partition 6 Back up Partition 8 Back up Partition 5 Back up Partition 7

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
DB2 Database Tools Catalog Database

Database Server 2
DB2 Database Tools Catalog Database

Database Server n
DB2 Database Tools Catalog 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 Tools Catalog Database Instance Tools Catalog Database Schema Scheduler User ID (TOOLSCAT_DB) = TEST (TOOLSCAT_INST) = DB2 (TOOLSCAT_SCHEMA) = SYSTOOLS = 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 - Task Center - Control Center

DAS

Tools Catalog Database Scheduler

Database Server 1
DB2 Database

Database Server 2
DB2 Database

Database Server n
DB2 Database

DB2 Administration Server

DB2 Administration Server

...

DB2 Administration 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 Database Tools Catalog Database

DB2 Administration Server

Database Server 3
DB2 Database 3

DB2 Administration Server

Client

Scheduler
DB2 Administration Server

Client Applications - Task Center - Control Center

Database Server 4
DB2 Database 4 DB2 Database 5 DB2 Database 6 Tools Catalog 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, 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:
Parameter Java Development Kit Installation Path Java Development Kit Installation Path 64-bit Location of Contact List Scheduler Mode SMTP Server Tools Catalog Database Tools Catalog Database Instance Tools Catalog Database Schema Scheduler User ID Parameter Name JDK_PATH JDK_64_PATH** CONTACT_HOST SCHED_ENABLE* SMTP_SERVER TOOLSCAT_DB* TOOLSCAT_INST* TOOLSCAT_SCHEM A* Parameter Value Comments Path for JDK. Set this only if the scheduler instance is 64-bit AIX, SUN or HP. Only required if using a global contact list. Set to ON. Set to SMTP Server TCPIP hostname for notification. Tools catalog database name. Tools catalog database instance name. Tools catalog database schema name. 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