db2 dba checklist

The DB2 for Linux, UNIX, and Windows DBAChecklistSkill Level: Introductory

Dwaine Snow ([email protected])Senior DB2 Product ManagerIBM

19 Apr 2004

Updated 10 Aug 2006

Just like a high performance sports car, a database requires some checks to keep itrunning optimally. This article is broken down into tasks or checks that can be run atdifferent intervals on your DB2® for Linux®, UNIX®, and Windows® database, to dojust that. Learn when to monitor and what you should be doing daily, weekly, andmonthly. Updated for DB2 9.

Introduction

While databases are becoming more and more self-aware and self-healing, they stillrequire some monitoring to keep them running as efficiently as possible. Just likeyour car, a database requires some checks to keep it running optimally. Thisdocument is broken down into tasks or checks that you can run at different timeintervals to ensure that your DB2 databases are running optimally, and detectpotential issues before they happen.

The first set of checks or tasks should be run every day to make sure there are nocurrent or imminent problems. The second set should be run weekly to check forissues or problems that may have occurred during the week or are likely to occur inthe coming week. The final set of checks or tasks need not be run every day orweek, but should be run monthly to keep the system running without problems, andto prevent further issues in the event that a problem does occur.

The DB2 for Linux, UNIX, and Windows DBA Checklist© Copyright IBM Corporation 1994, 2007. All rights reserved. of 25

mailto:[email protected]

http://www.ibm.com/legal/copytrade.shtml

Monitoring the system

There are a number of reasons that you should monitor your databases, however,the main reason is to ensure that no problems currently exist with the system or areimminent. It is always better to detect a problem and take actions to prevent it fromhappening than to have to react to a problem once it has happened. By monitoringyour DB2 database systems as described in this article, you will be able to detectmany problems before they happen, and maintain the performance of your system.

Monitoring tools available

You will typically need to combine DB2 and operating system monitoring in order toget the complete picture of what is happening on the database server. DB2 toolsalone normally do not give the complete picture.

When capturing the information for analysis, make sure that the DB2 and operatingsystem information is captured at the same time, as you cannot correlate informationcaptured at different times.

Capturing the system information

When monitoring the system, take the snapshots over a period of time. Taking themfor only a one or two minute period will not give a real view of the system activity. Isuggest that you take the snapshot every one to 5 minutes, for a period of at leastone hour.

Linux and UNIX Tools

For example, to capture the CPU, memory and other operating system usageinformation on UNIX or Linux we use the tool vmstat. To capture the

The parameters of the vmstat and iostat command are as follows.

Parameter 1 The interval, in seconds, at which the tool captures the systeminformationParameter 2 The number of times that the tool should capture the systeminformation

To run vmstat and iostat and capture a snapshot every 5 minutes (300 seconds) for8 hours (28,800 seconds) you can run the following commands:

vmstat 300 28800 > vmstat.outiostat -tx 300 28800 > iostat.out

developerWorks® ibm.com/developerWorks

The DB2 for Linux, UNIX, and Windows DBA Checklist of 25 © Copyright IBM Corporation 1994, 2007. All rights reserved.


NOTE: the -tx option on iostat is not supported on all UNIX/Linux versions, but isuseful since it embeds the timestamp for when the snapshot was taken.

Also make sure to capture the snapshots are normal/average workload times as wellas peak workload times. While it is important to ensure the normal workloads arehandled efficiently, it is also important to ensure that the system can handle the peakworkloads without overloading the server.

Windows Tools

On Windows, you can look at the CPU usage and memory usage in the TaskManager as seen below, but you cannot capture this information into a file like youcan with vmstat and iostat:

Figure 1. Windows Task Manager

ibm.com/developerWorks developerWorks®



DB2 tools

DB2 has a number of tools that can be used to monitor the activity of the databasesand instances. These include:




• The Health Monitor / Health Center

• Snapshot Monitors / SQL Snapshot Functions

• Event Monitors

There are also other tools and logs available that provide information about thedatabases and instances including:

• The administration notification log

• This is a separate file on Linux and UNIX and incorporated into theEvent Log on Windows.

• DB2DIAG.LOG

• Memory Visualizer

1. Health Monitor

In Version 8, DB2 introduced two new features to help you monitor the health of yourDB2 systems: the Health Monitor and the Health Center. These tools add amanagement by exception capability to DB2 9 by alerting you to potential systemhealth issues. This enables you to address health issues before they become realproblems that affect your system's performance.

The Health Monitor runs on the DB2 server and continually monitors the health ofthe DB2 instance and databases. If the Health Monitor detects that a user-definedthreshold has been exceeded (for example, the available log space has droppedbelow a set percentage of the total space available), or if it detects an abnormalstate for an object (for example, the DB2 instance is no longer running), the HealthMonitor will raise an alert.

When an alert is raised two things can occur:

• The alert notification will be sent.

• This can be sent by e-mail or to a pager

• Pre-configured actions can be taken.

• A CLP script or a Task Center task can be executed.

A health indicator is a system characteristic that the Health Monitor checks. TheHealth Monitor comes with a set of predefined thresholds for these health indicators.The Health Monitor checks the state of your system against these health-indicatorthresholds when determining whether to issue an alert. Using the Health Center,commands, or APIs, you can customize the threshold settings of these healthindicators, and define who should be notified and what script or task should be run if




an alert is issued.

The Health Center provides the graphical interface to the Health Monitor. You use itto configure the Health Monitor, and to see the rolled up alert state of your instancesand database objects. Using the Health Center's drill-down capability, you canaccess details about current alerts and obtain a list of recommended actions thatdescribe how to resolve the alert. You can also choose to follow a recommendedaction right inside the tool. The Health Center is easily configured to show status linehealth beacons and/or pop up a dialog box telling you that the Health Center has anobject in alert status.

2. Snapshot Monitors / SQL Snapshot Functions

DB2 maintains data about its operation, its performance, and the applications thatare accessing it. This data is maintained as the database manager runs, and canprovide important performance and troubleshooting information. For example, youcan find out:

• The number of applications connected to a database, their status, andwhich SQL statements each application is executing, if any.

• Information that shows how well the database manager and database areconfigured, and helps you to tune them.

• When deadlocks occurred for a specified database, which applicationswere involved, and which locks were in contention.

• The list of locks held by an application or a database. If the applicationcannot proceed because it is waiting for a lock, there is additionalinformation on the lock, including which application is holding it.

• The list of SQL statements executed against a particular database, howmany times they were executed, how many sorts were performed onbehalf of the statement and the total amount of CPU time used by eachstatement.

• The number of sorts that have occurred and the number currently inprogress.

Because the monitors do add some overhead to the system, the monitor switchescan be enabled or disabled independently. They can also be set for the entireinstance, and all databases in the instance, or can be set within a database session.If the monitor switches are enabled within a session, they are only 'active" for thatsession, and a snapshot taken from another session will not capture the monitorinformation. If the switches are enabled using the DB2 instance configurationparameters, they are enabled for all sessions, unless explicitly turned off within asession.




To set the monitor switches within a session, use the UPDATE MONITORSWITCHES command or the sqlmon() API.

For example, to enable buffer pool, lock, and dynamic SQL statement monitoring,turn on the monitor switches using the following command:

update monitor switches using bufferpool on lock on statement on

NOTE: You must have SYSADM, SYSCTRL, SYSMAINT or SYSMON(new in DB29) authority to update the monitor switches and/or take a DB2 snapshot.

You can access the data that the database manager maintains either by taking asnapshot or by using an event monitor. You can take a snapshot in one of thefollowing ways:

• Using the GET SNAPSHOT command from the command line

• Calling the SQL Snapshot table functions

• Using the Control Center

• Write your own application, that makes the sqlmonss() API call.

3. Event Monitors

Once an event monitor has been created and activated, it will collect informationabout the database and any database applications when the specified event occurs.An event is a change in database activity which can be caused by one of thefollowing:

• A database connect / disconnect

• A deadlock, or lock timeout

• A statement execution

• A transaction start or finish

An event monitor is created based on the type of event that you want it to detect andrecord. For example, a deadlock event monitor waits for a deadlock to occur; andwhen one does occur it will collect and record information about the applications andlocks involved in the deadlock condition.

Event monitors are created using the CREATE EVENT MONITOR statement andwill collect event information only when they are active. An event monitor is activatedand deactivated using the SET EVENT MONITOR STATE statement. TheEVENT_MON_STATE function will return the current state of the specified event




monitor.

When the CREATE EVENT MONITOR statement is executed, the definition of theevent monitor is created and stored in the system catalog tables.

• SYSCAT.EVENTMONITORS: Event monitors defined for the database.

• SYSCAT.EVENTS: Events types being monitored for the database.

• SYSCAT.EVENTTABLES: The names of the target tables for table eventmonitors.

Operating system tools

Database tools / snapshots by themselves typically do not give you the completepicture of your system performance. For example, a database may be 100%optimally tuned, but will not be able to perform well if I/O contention is occurring onthe server. Therefore it is important to look at the complete picture to make sure theentire system is performing well.

Daily procedures

Verify that all instances are up and running

This can be done in a number of ways:

1. Use the Health Center.

2. export/set DB2INSTANCE=instancename

• and run db2start.

3. Attach to all instances.

4. On UNIX or Linux, run ps -ef | grep db2sysc

• Verify there is one db2sysc process for each instance.

5. On Windows, check that the service for each DB2 instance is started.

The attach method can be easily scripted as long as all of the instances (that is,NODEs) are cataloged on your workstation.

To use the ps command on UNIX and Linux you first need to telnet into each of theservers.




Verify that all databases are active or consistent

The definition of consistent can be confusing, and how it is reported by the GET DBCFG command often causes questions.

By definition, a database is consistent when all committed transactions have beenwritten to disk, and any uncommitted transactions are not on disk When a databaseis running with applications connected to it, there will be transactions that havechanged pages, that may have committed, but the changed pages may not havebeen flushed from the buffer pool to disk. Also, there may be transactions that wererolled back but their changes were flushed to disk. In this case the GET DB CFG willreport that the database is inconsistent, but in fact it is fine. Therefore, simply gettingthe database configuration information for all databases is not sufficient.

A good method, because it will also make inconsistent databases consistent andtherefore reduce the times for future connect requests, is to successfully connect toall databases. This also can be easily scripted, as long as all of the databases arecataloged on your workstation.

Look for new Administration Notification Log and/or DB2DIAG.LOG entries

It is important to make sure that there were no problems that occurred overnight.Since Version 8, DB2 has been writing diagnostic messages to two places, theAdministration Notification Log (where the messages intended for DBAs are written),and the DB2DIAG.LOG file (where the messages intended for the DB2 service teamare written).

On Windows, the Administration Notification log is written to the Application EventLog and can be viewed using the Event Viewer by choosing the Application logand looking for events written by the application named DB2.

Figure 2. Windows Event Viewer




On Linux and UNIX, the log is written to a file named <instance_ID>.nfy that islocated in the directory specified by the DIAGPATH instance level configurationparameter. To view the notification log you can:

• Connect to each of the servers using telnet or remote terminal services.

• For each instance, go to the DIAGPATH directory.

• At the command prompt:

• Run the tail command on the notification log to dump the last 100entries

• Edit the file and look at the most recent entries at the bottom of thefile.

Check that the previous night's backups were successful

There is nothing worse than having a problem on your system, and deciding torestore the most recent backup, and then finding that the backup was not taken or isnot complete. Therefore, it is important to check that the previous night's backup(s)were successful and that they have been stored in a safe location.

The first step is to ensure that the backups were successful. This is done using theList History command as follows:

list history backup all for db_name




This can be scripted so that it is run for all databases after the backups complete,and the report emailed to you. You can then simply verify the report each morning.

In the event that the whole server goes down for a sustained period of time, you mayneed to revert to your disaster recovery plan, restore the database to another server,maybe in another location. Therefore it is important that the backup images bestored in a safe site, not only on the server where the backup is taken. This can beeasily accomplished by copying the backup image to a LAN drive, an NFS mounteddrive or to a tape device.

Verify database logs have been archived successfully

If your database is read only, or can be rebuilt from scratch easily, you likely do nothave log retain enabled so you can skip this step. However, for those transactionaldatabases where you can not afford to lose any committed transactions, it isimportant to make sure log retain is enabled, and that the logs are being archivedsuccessfully so that the database can be rebuilt and the transactions replayed in theevent of a disaster.

While recovery may be the primary reason for verifying the logs are being archivedsuccessfully, there is another important reason. If the logs are not archived, they willremain in the LOGPATH. Since the LOGPATH is normally on a file system with a setsize, if the log files are not being archived, as new logs are created the file systemwill be filled up. When this occurs, DB2 will be unable to create any more log filesand will therefore stop.

When a userexit is called to archive a log file, it will write information to two places.The first place will be the userexit audit log where an entry will be written for everyarchive log request received by the userexit. In the event of an error during theuserexit processing, a message will be written to the userexit error log file as well.These log files are in the LOGPATH and are named ARCHIVE.LOG andUSEREXIT.ERR respectively.

To examine these logs you can easily write a script to grab the last 50 to 100 linesfrom these files (using the tail command) for all instances and email them to you.Then you can study them along with the recovery history information each morning.

Check that no DBM and/or DB configuration parameters have changed

Whenever you work with other DBAs there is always a chance that someone elsemight have changed one or more database or database manager configurationparameters and forgot to tell everyone else. Since changes to the database anddatabase manager configurations have a big impact on the system, veryify that theyhave not changed unexpectedly. Capture the DB and DBM configurations into a fileas follows:




get dbm cfgget db cfg for db_name

Make sure that you capture the output of the commands to a file, and name the fileso that is has the date as part of the name, like DB_DBM_CFG.07152006.out. Thenyou can use a tool like diff to compare the current output with the previous day'soutput as follows:

diff DB_DBM_CFG.07142006.out DB_DBM_CFG.07152006.out

This way, if there is a change you will see something like the following:

< Degree of parallelism (DFT_DEGREE) = 1---> Degree of parallelism (DFT_DEGREE) = 4

Check important performance measures based on your workload

While the buffer pool hit ratio is very important for OLTP systems, it is impossible tohave a high buffer pool hit ratio in a database warehouse, so examine the measuresthat are important for your workload. Some of the important performance measures,and how they can be calculated are shown below.

Calculate the data, index and combined buffer pool hit ratios as well as theasynchronous read percentage using the following statement:

select substr(bp_name,1,20) as BP_NAME,int (( 1 - (decimal(pool_data_p_reads) / nullif(pool_data_l_reads,0) )) * 100) as

data_hit_ratio,int (( 1 - (decimal(pool_index_p_reads) / nullif(pool_index_l_reads,0) )) * 100)

as index_hit_ratio,int (( 1 - (decimal(pool_data_p_reads + pool_index_p_reads) /

nullif( (pool_data_l_reads + pool_index_l_reads),0) )) * 100) asBP_hit_ratio,

int (( 1 - (decimal(pool_async_data_reads + pool_async_index_reads) /nullif( (pool_async_data_reads + pool_async_index_reads + direct_reads),0)

)) * 100) as Async_read_pct,int (( 1 - (decimal(direct_writes) / nullif(direct_reads,0) )) * 100) as

Direct_RW_Ratiofrom table (snapshot_bp ('sample', -1) ) as snapshot_bp ;

Note: The nullif function is used in the query above to return a null when the numberinside the bracket (i.e. pool_data_l_reads or pool_index_l_reads) is zero (0),otherwise the calculation would cause a divide by zero error and the statement willfail.




Examine the usage patterns for the tables in your database using the query below.This query examine how many rows were read, written, and the number of overflowrecords accessed using the following statement.

selectsubstr(table_schema,1,8) as Schema,substr(table_name,1,30) as Table_Name,rows_read,rows_written,overflow_accesses

from table (snapshot_table ('sample', -1) ) as snapshot_table;

Examine the overall database usage patterns using the query below. This queryexamines:

• How many rows were read vs. selected

• How many lock waits occurred, the total lock wait time and the averagelock wait time

• How many deadlocks and lock escalations were detected

• How many sorts occurred, the total sort time, and the average sort time,the percent of sorts that overflowed

selectdb_name,SNAPSHOT_TIMESTAMP,rows_read,rows_selected,lock_waits,lock_wait_time,lock_wait_time/nullif(lock_waits,0) as avg_wt_time,deadlocks,lock_escals,total_sorts,total_sort_time,total_sort_time/nullif(total_sorts,0) as avg_sort_time,sort_overflows,sort_overflows/nullif(total_sorts,0) as pct_ovflow_sortsfrom table (snapshot_database (' ', -1) ) as snapshot_database;

Check for automatic actions DB2 has taken on your behalf

With the growing ability for DB2 to adapt to changes in performance and usageautomatically, much of the everyday administration is no longer required, but you stillmight want to look at, and understand, the changes DB2 has made to the databaseconfiguration parameters as well as to the underlying table space allocation.

You can track the changes to the table space allocation using the list tablespacesshow detail command. The changes made by the automatic self tuning memory are




logged in files named stmm.#.log in the stmmlog directory. This directory is underthe SQLLIB directory for the instance owner in Linux and UNIX, under theSQLLIB\Instance directory on Windows.

Ensure there is enough free memory

Another important thing to look at on the server is the memory usage of DB2 and theentire server. On Windows you can determine the amount of RAM on the server byopening My Computer, and then selecting Help and About Windows.

In UNIX and Linux the command free will display the amount of real memory (RAM)on the system, and how much is currently in use and available. In the case belowthere is 1GB of real memory on this server, and approximately 717MB is allocated toapplications.

total used free shared buffers cachedMem: 1036248 717240 319008 0 60200 430736-/+ buffers/cache: 226304 809944Swap: 1048784 0 1048784

Study DB2

Nothing is more valuable in the long run than that a DBA who is widely experienced,and as widely read as possible. This study should include DBA manuals, magazines,newsgroups and mailing lists.

The comp.databases.ibm-db2 news group is a great place to learn from, and shareinformation with, your fellow DBAs.

For more detailed information you should also look for our DB2 Certification Guideseries, as these books are very informative.

Weekly procedures

Look for new objects

It is important to know if people are creating new tables, indexes, stored procedures,etc. in your production database. New objects typically indicate that a newapplication has been installed on the server and any new applications and/or objectswill impact the operational characteristics of your system.

In addition, new objects will consume space within the database, so it is important toidentify these objects before they grow too large and could potentially fill a tablespace. If these objects are not created by a DBA, they very likely may have beencreated in the wrong table space, which can cause space and/or performance




issues.

There are a few alternatives available to check for any new objects within thesystem:

1. Run db2look and write the report to a file every week.

• Check for differences between the new output and the previousweek's output.

2. Select object names from SYSCAT.TABLES, SYSCAT.INDEXES,SYSCAT.PROCEDURES

• Check for differences between the new output and the previousweek's output.

For any differences, you determine the CREATOR of the object from the catalogtable and track the information back to the person that created the object.

Look for new or changed applications

Once you have optimized your database based on your current workload, there isnothing more frustrating than getting a call that the database is not performing well,and finding that the poor performance was caused by a new application, or changesto existing applications that no one told you about. Unfortunately, this happens alltoo often. By monitoring your database for new and/or changed applications you canhopefully detect these changes before they cause performance problems.

To look for new applications you can use the list applications show detailcommand. If you redirect the output of this command to a file and keep these files fora period of time, you can compare the files every week to see if a new applicationname suddenly appears in the output.

To look for changes applications you can see what SQL is running on your systemover time, and look for new SQL that has not been run previously. To do this youcan create a table as follows:

create table SQLstmts(stmt varchar(200),tstamp timestamp not null with default)

You can then retrieve the SQL statements from the current package cache andinsert them into a table for analysis using the following statement:

insert into SQlstmts (stmt)




select substr(stmt_text,1,200) as SQL_Stmtfrom table (snapshot_dyn_sql ('sample', -1) )as snapshot_dyn_sql

You can then examine this table for any SQL statements that have not beenexecuted previously using the statement:

select distinct stmt,count(stmt),tstamp from sqlstmtsgroup by stmt,tstamp

In the output of this statement, any statement with a count of 1, and the timestampcolumn showing the current date is one that has not been run previously.

Look for tables and/or indexes needing REORG

As you insert, update and delete rows in your tables, the data in the tables may needto be REORGed to:

1. Re-cluster the data in the order of your most important index

2. Remove free space interspersed throughout the table

3. Remove overflow records

The reorgchk tool will check your tables and indicate which tables may need to bereorged. You can run the reorgchk tool against a single table, all user tables, alltables in a specific schema, or all system catalog tables. You can also indicatewhether the tool should use the current statistics in the catalog tables as a basis, orgather new statistics first.

To run the reorgchk tool against all of your tables, and ensure you are using thecurrent statistics, use the command:

reorgchk update statistics on table user

You should redirect the output of this command to a file for further analysis.

When viewing the output of the reorgchk tool, find the F1, F2 and F3 columns foryour tables, and the F4, F5, F6, F7, and F8 columns for your indexes. If there is anasterisk (*) in any one of these columns, that indicates that DB2 has calculated thatyour current table and/or indices currently breach that threshold.




It is important to note that for tables, if you see an asterisk in any of the columns,then you typically need to reorg the table. However, since many tables have morethan one index, by definition if one of them is 100% clustered, the other indices willnot be clustered. Therefore you need to investigate the index portion of thereorgchk output in more detail and consider all of the indexes on the table whendetermining whether or not to reorg the index.

The calculations for the measures used by reorgchk are:

F1: the percentage of rows that are overflow records. When this is greater than 5%there will be an asterisk (*) in the F1 column of the output.

F2: the percentage of used space on the data pages. When this is less than 70%there will be an asterisk (*) in the F2 column of the output.

F3: the percentage of pages that contain data that contain some records. When thisis less than 80% there will be an asterisk (*) in the F3 column of the output.

F4: the cluster ratio, i.e. the percentage of rows in the table that are in the sameorder as the index. When this is less than 80% there will be an asterisk (*) in the F4column of the output.

F5: the percentage of space that is used on each index page used for index keys.When this is less than 50% there will be an asterisk (*) in the F6 column of theoutput.

F6: the number of keys that can be stored on each index level. When this is lessthan 100 there will be an asterisk (*) in the F6 column of the output.

F7: the percentage of record IDs (keys) on a page that have been marked asdeleted. When this is more than 20% there will be an asterisk (*) in the F7 column ofthe output.

F8: the percentage of empty leaf pages in the index. When this is more than 20%there will be an asterisk (*) in the F8 column of the output.

When reorganizing a table you can optionally specify which on which index DB2should cluster the data. To reorg the ORG table based on the ORGX index, use thecommand

reorg table org index orgx

The DB2 optimizer uses database statistics to determine the optimal access plansfor your SQL statements. When you make significant changes to the amount of data,or to the data organization in your tables you should use the runstats tool to capture




new statistics and store them in the system catalogs. You should also be sure tocapture statistics for any new table or index.

To capture statistics for the ORG table, and its indexes you can use the command

runstats on table <schema>.org with distribution and detailed indexes all

NOTE: You must specify the schema for the table when using the runstatscommand.

Look for tables and indexes needing RUNSTATS

You can check for any tables or indexes without statistics, or with statistics that areover 7 days old using the following statements:

select substr(name,1,30),substr(creator,1,10),stats_timefrom sysibm.systableswhere stats_time < ((current timestamp) - 7 days)or stats_time is null

select substr(name,1,30),substr(creator,1,10),stats_timefrom sysibm.sysindexeswhere stats_time < ((current timestamp) - 7 days)or stats_time is null

Look for the 10 most active tables

When considering which tables to run reorg or runstats on you should alsoconsider the activity on the tables. To find the 10 most read tables, based on thenumber of rows read, use the following statement:

select substr(table_schema,1,10) as tbschema,substr(table_name,1,30) as tbname,rows_read,rows_written,overflow_accesses,page_reorgsfrom table (SNAPSHOT_TABLE(' ',-1)) as snapshot_tableorder by rows_read descfetch first 10 rows only

To find the 10 most updated tables, based on the number of rows written, use thefollowing statement:

select substr(table_schema,1,10) as tbschema,substr(table_name,1,30) as tbname,rows_read,




rows_written,overflow_accesses,page_reorgsfrom table (SNAPSHOT_TABLE(' ',-1)) as snapshot_tableorder by rows_written descfetch first 10 rows only

These tables are also likely candidates for at least a runstats, if not a reorg and arunstats.

Archive all alert logs and DB2DIAG.LOG files

It is good practice to clean up the diagnostic logs on a regular basis. In the event anerror does occur, you then do not need to go over 6 months of information in thelogs, and the logs are a lot smaller and easier to edit. Before purging the files, makea copy of them in case you want to go back at some time in the future to investigatewhat was occurring on the system at a given time.

On Windows you can save the event log to another file in the Event Viewer byselecting the Action menu, and then choosing the Save Log File As option. Youcan then purge the entries from the log by selecting the Action menu, and thenchoosing the Clear All Events option.

NOTE: It is good practice to name the file with the current date to make it easier tolook back at the files at a later date.

For the DB2DIAG.LOG file as well as the administration notification log file on Linuxand UNIX, you should compress these files, and name then with the current date inthe file name as well.

On Linux or UNIX, you can tar the *.nfy and db2diag.log files together, and then useeither gzip or compress to reduce the size of the resulting file.

Check for software updates

It is always good to know if there are any updates to the software that you arerunning. If your system is running smoothly, you may not want to apply all service toyour server. By reading the information about the fixes contained in the fixpak /service packs, you can make a more educated decision about whether or not toapply the fixpack. If you are encountering issues, you can look at the fix descriptionsto see if one of the available fixes might be the solution to your problems.

From a DB2 perspective, the most important web site is the DB2 for Linux, UNIX,and Windows Technical Support Page:

http://www-3.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/download.d2w/WINV8FP



http://www-3.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/download.d2w/WINV8FP


One way to be sure you find out when a new fixpak becomes available is tosubscribe to DB2 Alerts at this site:

http://www-3.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/db2alert.d2w/report

Monthly procedures

Look for indicators of exceptional growth

Review your tables and table spaces to see how much they have grown in the pastmonth. By knowing how fast the tables and table spaces are growing, and how muchspace is still available, you can detect potential space issues before they happen.

You can retrieve the size of the table space and the amount of space available usingthe statement below.

select substr(tablespace_name,1,120) as TBSPC_NAME,used_pages,free_pages,from table (snapshot_tbs_cfg ('sample', -1) ) as snapshot_tbs_cfg

You can see how big each of your tables is by looking at the system catalog tables.As long as your statistics are current, this information will be accurate. To get thesize of your tables use the statement

select tabname,npagesfrom syscat.tableswhere tabname not like 'SYS%'

NOTE: If statistics have not been captured for a table, it will have a value of -1 fornpages.

Create a history table or a spreadsheet to store this information so that you canscrutinize the space usage for your tables and table spaces over time. An easy wayto do this is to create an export statement using the select statements above, andcreate a delimted ASCII (DEL) file which you can then import directly into aspreadsheet.

Project future performance based on projected growth

Compare the information you have been gathering on the system level CPU,memory, network, and disk utilization, as well as the DB2 object information that youhave been gathering, to identify trends that could lead to contention or a shortage of



http://www-3.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/db2alert.d2w/report


any of these resources in the future.

Based on your analysis of the above information, you can plan for these situationsbefore they happen and take actions to prevent these situations from occurring.

The following appendices contain useful scripts that can be used to monitor yoursystem and database. Note that these scripts were written in files that were runusing the CLP, and therefore contain comments. The comments are preceded bythe double dashes (--) and need to be removed if you are running these commandsdirectly on the command line.

Appendix 1: Table space information script

--Create the table named tablespaceinfo to store information from the table spacesnapshots for analysis.

create table TablespaceInfo(timestmp timestamp,tablespace_name char(128),pct_free int,-- Percent of space free in the table spacetype char(5),-- SMS or DMScontents char(5),total_pages int,-- total # of pagesusable_pages int,-- useable pages, total - tag, etc..used_pages int,-- # of pages usedfree_pages int,-- # of free pagespage_size int);-- page size

-- Insert the snapshot info into the tablespaceinfo table to be stored for analysis.

insert into tablespaceinfoselectcurrent timestamp,substr(tablespace_name,1,120) as TBSPC_NAME,(case-- We can calculate pct free for DMS table spaces only as total_pages isset to 0 for SMS by this stmt...-- Therefore, check if DMS, and then calculate pct_free as 1-(used/total) * 100%when tablespace_type = 0 then (int( (1- (decimal(used_pages) /decimal(total_pages))) * 100) )-- For SMS set pct_free to 100... Could set to any numeric value.else 100end) as pct_free,(case




-- Display the table space type, i.e. DMS or SMS as a string, not the numericvalue in the info.when tablespace_type = 0 then 'DMS'when tablespace_type = 1 then 'SMS'-- Only 0 and 1 are VALID, therefore return an error for anything else.else 'Error'end) as Managed_By,(case-- Display the type of data that can stored in the table space, i.e. TEMP,LARGE/LOB OR ALL,not the numeric value in the info.when tbs_contents_type = 2 then 'TEMP'when tbs_contents_type = 1 then 'LARGE'when tbs_contents_type = 0 then 'ALL' end) as Data_Type,-- Also return the total_pages using the heading ALLOCATED PAGES,total_pages as allocated_pages,usable_pages,used_pages,free_pages,page_sizefrom table (snapshot_tbs_cfg ('sample', -1) ) as snapshot_tbs_cfgorder by pct_free;select tablespace_name,date(timestmp) as dte,pct_freefrom tablespaceinfogroup by tablespace_name, pct_free, timestmp ;

Appendix 2: Table space container information script

-- Report the containers, their size and type associated with each tablespace

-- Group by tablespace_name to get all containers for a table space together-- as the containers will be unique in this report.

-- Set the database name to NULL to get info on currently connected-- database.

selectsubstr(tablespace_name,1,12) as TBSPC_Name,substr(Container_name,1,67) as Cont_Name,(casewhen container_type = 0 then 'SMS Directory'when container_type = 6 then 'DMS File'else 'DMS Device'end) as Container_Type,usable_pagesfrom table (snapshot_container (' ', -1) ) as snapshot_container;

Appendix 3: Buffer pool - Table space information

-- Report the buffer pool name and size along with the size and name of each tablespace




-- assigned to the bufferpool. This can be used to help size the bufferpools moreappropriately.--- Group by bpname first to get all table spaces for a bufferpool together as the tablespaces-- will be unique in this report.

select substr(b.bpname,1,12) as BufferPool,b.npages as BP_Pages,substr(t.tbspace,1,12) as TableSpace,usable_pages as TBSPC_Pagesfrom table (snapshot_tbs_cfg ('sample', -1) ) as snapshot_tbs_cfg ,syscat.tablespaces t, syscat.bufferpools bwhere t.bufferpoolid = b.bufferpoolidand t.tbspace = tablespace_namegroup by b.bpname, t.tbspace, usable_pages, npages;




Resources

Learn

• Visit developerWorks DBA Central to sharpen your skills on installation,migration, administration, problem determination, monitoring, availability,security, and performance.

• Visit the developerWorks resource page for DB2 for Linux, UNIX, and Windowsto read articles and tutorials and connect to other resources to expand yourDB2 skills.

• Learn about DB2 Express-C, the no-charge version of DB2 Express Edition forthe community.

• Stay current with developerWorks technical events and Webcasts.

Get products and technologies

• Download a free trial version of DB2 Enterprise 9.

• Now you can use DB2 for free. Download DB2 Express-C, a no-charge versionof DB2 Express Edition for the community that offers the same core datafeatures as DB2 Express Edtion and provides a solid base to build and deployapplications.

Discuss

• Participate in the discussion forum for this content.

• Participate in developerWorks blogs and get involved in the developerWorkscommunity.

About the author

Dwaine SnowDwaine R. Snow is a senior product manager for DB2 Data Server. In this role, he ishelping to determine the future direction of the product and decide what functionalenhancements need to be made to it to ensure that it meets customer requirements.Dwaine has worked in a DB2 services consultant role with IBM for a number of years.In this role, he has provided on-site assistance with DB2 database and applicationplanning, project planning and execution, large complex OLTP and Decision Supportsystem design, database and application design, and performance tuning, as well asclient/server and legacy system integration. Dwaine has authored or co-authorednumerous articles and books on DB2, including The Advanced DBA CertificationGuide and Reference for DB2 Universal Database for Linux, UNIX, and Windows andUnderstanding DB2: Learning Visually with Examples, and has presented at



http://www.ibm.com/developerworks/db2/zones/dba

http://www.ibm.com/developerworks/db2/zones/db2udb

http://www.ibm.com/software/data/db2/udb/db2express/

http://www.ibm.com/developerworks/offers/techbriefings/?S_TACT=105AGX03&S_CMP=art

http://www.ibm.com/developerworks/downloads/im/udb/index.html?S_TACT=105AGX11&S_CMP=art

http://www.ibm.com/developerworks/downloads/im/udbexp/index.html?S_TACT=105AGX11&S_CMP=art

http://www.ibm.com/developerworks/forums/dw_forum.jsp?forum=842&cat=19

http://www.ibm.com/developerworks/blogs/

http://www.amazon.com/gp/product/0130463884/sr=1-2/qid=1155161045/ref=sr_1_2/002-1492910-6027204?ie=UTF8&s=books

http://www.amazon.com/gp/product/0130463884/sr=1-2/qid=1155161045/ref=sr_1_2/002-1492910-6027204?ie=UTF8&s=books

http://www.amazon.com/gp/product/0131859161/qid=1121269835/sr=1-1/ref=sr_1_1/002-1492910-6027204?s=books&v=glance&n=283155


conferences around the world.




db2 dba checklist

Documents