Professional Documents
Culture Documents
db2 Cert9182 PDF
db2 Cert9182 PDF
16 May 2007
Learn to monitor database server activity for IBM® Informix® Dynamic Server (IDS).
Examine various tools to monitor, diagnose problems, and manipulate IDS data. The
second in a series of eight tutorials, use this tutorial to help prepare for the IDS 11
exam 918.
Tuning and configuring an IDS database can be a complex process that sometimes
overwhelms new DBAs. There are, however, a great number of tools, functions, and
applications included with IDS that, once mastered, make this task simple.
This tutorial is designed to introduce you to the set of monitoring tools that are
available with IDS 11 and to show you how each is used to monitor how well (or how
poorly) your database system is operating. In this tutorial:
Objectives
After completing this tutorial, you should be able to:
Prerequisites
IDS 11 installation is covered in part 1 of this tutorial series. If you haven't already
done so, consider downloading and installing a copy of IBM IDS 11. Installing IDS
will help you understand many of the concepts that are tested on the System
Administration for IBM IDS V11 Certification exam.
System requirements
You do not need a copy of IDS to complete this tutorial. However, you will get more
out of the tutorial if you download the free trial version of IBM IDS 11 to work along
with this tutorial.
Administration API
The SQL administration API enables you to perform remote administration using
various, specific SQL commands for tasks such as managing spaces, managing
configuration, running routine jobs, and system validation.
You can use EXECUTE FUNCTION statements to invoke the built-in admin( ) or
task( ) functions to accomplish administrative tasks that are equivalent to
executing various administrative utilities of Dynamic Server.
In the EXECUTE FUNCTION statements, items in the argument list specify the utility
and its command-line arguments. For example, the following SQL statement, which
is equivalent to the oncheck -ce command, instructs the database server to check
the extents:
Sysadmin database
The sysadmin database contains tables that store task properties. You use the task
properties (not configuration parameters) to define the information that the scheduler
collects and the statements that the scheduler runs.
Each row in the ph_task table is a separate task (defined as a single monitoring
event), and each column is a task property. The task properties indicate such items
as when to run an SQL statement, stored procedure, or UDR and how to handle the
task. An example of a task is the automatic running of a particular job every Monday
at midnight.
The scheduler
The scheduler enables the database server to execute database functions and
procedures at predefined times or as determined internally by the server. The
functions and procedures collect information, and monitor and adjust the server,
using an SQL-based administrative system and a set of tasks.
the last log backup) and create corrective actions that run automatically.
• Tasks, which provide the means for running a specific job at a specific
time or interval
• Sensors, which collect and save information
• Startup tasks, which run only once when the database server starts
• Startup sensors, which run only once when the database starts
A set of task properties, which define what needs to be collected or executed,
control the scheduler. The task properties are stored in the ph_task table in the
sysadmin database.
Each row in this table is a separate task, and each column is a task property. The
task properties indicate to the system such things as when to run an SQL statement,
stored procedure, or function and how to handle the task.
For example, you could define tasks to check free log space every hour from 9:00:00
to 19:00:00, daily.
Only task properties, not configuration parameters, define what the scheduler
collects and executes. The scheduler executes tasks at predefined times or as
determined internally, as required by the database server.
Setting up tasks
To set up a task, you need to plan the task first. You need to have:
The following example in Listing 1 shows the code for the creation of a table, called
mon_chunkio, that uses a stored procedure to collect and store data. This task
instructs the database server to collect data every five minutes by executing a stored
procedure called chunkio. The default scheduling policy (for example, 8:00 A.M. to
5:00 P.M., five days a week) is used, but the data expires and is deleted when it
becomes seven days old.
Listing 1. Creating a table that uses a stored procedure to collect and store
data
Setting up sensors
A sensor is a specialized TASK for collecting and saving data. A sensor can be
created the same way as a task by inserting a row in the ph_task table, with some
additional information.
To set up a new sensor, you need to plan first. You need to have:
Modifying tasks
You can modify the tasks by modifying the rows in the tables that begin with the
characters ph_ in the sysadmin database.
Go to the ph_task or other table that you want to modify in the sysadmin database.
Manually change the task information.
When you bring the database server up for the first time, it runs a script called
buildsmi, which is in the $INFORMIXDIR/etc directory. This script builds the
sysmaster database and tables that support SMI. The database server requires
approximately 1750 free pages of logical-log space to build the sysmaster database.
If you receive an error message that directs you to run the buildsmi script, a problem
probably occurred while the database server was building the SMI database, tables,
and views. When you use buildsmi, the existing sysmaster database is dropped and
then recreated.
The sysutils database is the place where OnBar stores information about every
backup/restore it performed. Backup information on every dbspaces and logical logs
is also stored here. OnBar utilizes these tables when performing warm restores.
When you initialize the database server for the first time, it runs a script called
bldutil.sh on UNIX® or bldutil.bat on Windows®. This script builds the sysutils
database. If it fails, the database server creates an output file in the tmp directory.
The output file is bldutil.process_id on UNIX and bldutil.out on Windows. The
messages in this output file reflect errors that occurred during the script execution.
The sysmaster database is described as a pseudo database. That means most of its
tables are not normal tables on disk, but pointers to shared memory structures in the
IDS engine. The sysmaster database contains over 120 tables. Only some of these
tables are documented in the Informix Dynamic Server Administrators Guide. The
rest are undocumented and meant to be as such for internal use.
These are new tables introduced in Version 11. There are many others sysmaster
tables that you can find more details on in the manual.
The SMI consists of tables and pseudo-tables that the database server maintains
automatically. While the SMI tables appear to the user as tables, they are not
recorded on disk as normal tables are. Instead, the database server constructs the
tables in memory, on demand, based on information in shared memory at that
instant. When you query an SMI table, the database server reads information from
these shared-memory structures. Because the database server continually updates
the data in shared memory, the information that SMI provides lets you examine the
current state of your database server.
• Auditing
• Disk usage
• User profiling
• Database-logging status
• Tables
• Chunks
• Chunk I/O
• Dbspaces
• Locks
• Extents
• SQL statement cache statistics
• Virtual-processor CPU usage
• System profiling
The data in the SMI tables changes dynamically as users access and modify
databases that the database server manages.
Any user can use SQL SELECT statements to query an SMI table, but standard
users cannot execute statements other than SELECT. Attempts to do so result in
permission errors. The administrator can execute SQL statements other than
SELECT, but the results of such statements are unpredictable.
Dynamic Server provides the sysadtinfo and sysaudit tables. Only user informix on
UNIX or members of the Informix-Admin group on Windows can query sysadtinfo
and sysaudit.
You cannot use dbschema or dbexport on any of the tables in the sysmaster
database. If you do, the database server generates the following error message:
You can use SELECT statements on SMI tables wherever you can use SELECT
against ordinary tables (from DBAccess, in an SPL routine, with ESQL/C, and so on)
with one restriction: You cannot (meaningfully) reference rowid when you query SMI
tables. SELECT statements that use rowid do not return an error, but the results are
unpredictable.
All standard SQL syntax, including joins between tables, sorting of output, and so
on, works with SMI tables. For example, if you want to join an SMI table with a
non-SMI table, name the SMI table with the following standard syntax:
sysmaster[@dbservername]:[owner.]tablename
Example
Intention:: List of users who had a database open and which workstation they were
using to connect to the database.
• The onstat -u utility would tell which users were connected to the
server, but not what database and what workstation they were using.
• Onstat -g ses would tell the user and workstation, but not the
database.
• Onstat -g sql would tell the session ID and database, but not the user
name and workstation.
Listing 3. Example
the command line. The onstat utility reads data from shared memory and reports
statistics that are accurate for the instant during which the command executes. That
is, onstat provides information that changes dynamically during processing,
including changes in buffers, locks, indexes, and users.
The onstat output heading indicates the database server status. Whenever the
database server is blocked, onstat displays the following line after the banner line:
All onstat output includes a header. The onstat - option displays only the output
header and is useful for checking the database server mode. The header takes the
following form:
Syntax
>>-onstat------------------------------------------------------->
.-----------------------------. V (1)
>--+-+-----------------+----+-------------------------+-+------+->
'-filename_source-' +- -a---------------------+ +-
-b---------------------+
+- -B---------------------+ +- -c---------------------+ +-
-C---------------------+ +- -d---------------------+ +-
-D---------------------+ +- -f---------------------+ +-
-F---------------------+ +- -g--Monitoring options-+ +-
-G---------------------+ +- -i---------------------+ +-
-k---------------------+ +- -K---------------------+ +-
-l---------------------+ +- -m---------------------+ +-
-o--+---------------+--+ '-filename_dest-' +-
-O---------------------+ +-
-p---------------------+ +- -P---------------------+ +-
-r--+---------+--------+ '-seconds-' +-
-R---------------------+ +-
-s---------------------+ +- -t---------------------+ +-
-T---------------------+ +- -u---------------------+ +-
-x---------------------+ +- -X---------------------+ '-
-z---------------------' +-
---------------------------------------------------------+ '-
---------------------------------------------------------
Note: Only one occurrence of each item is allowed. More than one option can be
specified on a single onstat command invocation.
that order
-b Displays information about buffers
currently in use, including number
of resident pages in the buffer
pool
-B Obtains information about all
database server buffers, not just
buffers currently in use. See the
entry for -b in this table
-c Displays the ONCONFIG file: *
$INFORMIXDIR/etc/
$ONCONFIG for UNIX *
%INFORMIXDIR%\etc\
%ONCONFIG% for Windows
-C Prints B-tree scanner information
-d Displays information for chunks in
each storage space
-D Displays page-read and
page-write information for the first
50 chunks in each dbspace
-f Lists the dbspaces currently
affected by the DATASKIP
feature
-F Displays a count for each type of
write that flushes pages to disk
-g Provides monitoring options
-G Prints global transaction IDs
-i Puts the onstat utility into
interactive mode
-j Prints the interactive status of the
active onpload process
-k Displays information about active
locks
-l Displays information about
physical and logical logs,
including page addresses
-m Displays the 20 most recent lines
of the database server message
log
-o Saves copies of the
shared-memory segments to
filename
-O Displays information about the
Optical Subsystem memory
cache and staging-area
blobspace
-p Displays profile counts
-P Displays for all partitions the
partition number and the break-up
of the buffer-pool pages that
belong to the partition
-r Repeats the accompanying
onstat options after they wait
the specified seconds between
each execution. The default value
of seconds is five.
-R Displays detailed information
about the LRU queues, FLRU
queues, and MLRU queues
-s Displays general latch information
-t Displays tblspace information,
including residency state, for
active tblspaces
-T Displays tblspace information for
all tblspaces
-u Prints a profile of user activity
-x Displays information about
transactions
-X Obtains precise information about
the threads that are sharing and
waiting for buffers
-z Sets the profile counts to zero
filename_dest Specifies destination file for the
copy of the shared-memory
segments
filename_source Specifies file that onstat reads
as source for the requested
information
Monitoring options Specifies which onstat -g
monitoring option to use
seconds Specifies number of seconds
between each execution of the
onstat -r command
The following onstat -g options are provided for support and debugging only. You
can include only one of these options per onstat -g command. For more
information, see your IBM Informix Performance Guide.
PER_STMT_PREP memory
duration pools, onstat -g mem
displays information on the
PRP.sessionid.threadid pool and
the EXE.sessionid.threadid pool.
For example output, see the
onstat -g mem pool name
session id option. For more
information, see the IBM Informix
DataBlade API Programmer's
Guide.
-g mgm Prints Memory Grant Manager
resource information. For
example output, see the onstat
-g mgm option.
-g nbm Prints block bit map for the
nonresident segments, one bit per
8-kilobyte block. Bit set indicates
block free. For example output,
see the onstat -g nbm option.
-g nif [modifier] Prints statistics about the network
interface. Useful to determine why
data is not replicating. For more
information and sample output,
see the onstat -g nif option.
-g nsc client id Prints shared-memory status by
client id. If client id is omitted, all
client status areas are displayed.
This command prints the same
status data as the nss command.
For example output, see the
onstat -g nsc client_id
option.
-g nsd Prints network shared-memory
data for poll threads. For example
output, see the onstat -g nsd
Option.
-g nss session id Prints network shared-memory
status by session id. If session id
is omitted, all session status
areas are displayed. This
command prints the same status
data as the nsc command.
-g nta Prints combined network statistics
from -g ntd, -g ntm, -g ntt,
and -g ntu. If MaxConnect is
installed, this command prints
statistics that you can use to tune
MaxConnect performance.
-g ntd Prints network statistics by
Use the filename_source parameter with other option flags to derive the
requested onstat statistics from the shared-memory segments that filename_source
contains. You must first use the onstat -o command to create a file that contains
the shared-memory segments.
Example
Dbspaces
address number flags fchunk nchunks pgsize flags
owner name
ad357e8 1 0x60001 1 1 2048 N B
informix rootdbs
b62a5b0 2 0x60001 2 1 4096 N B
informix dbsp1
2 active, 2047 maximum
Chunks
address chunk/dbs offset page Rd page Wr pathname
ad35948 1 1 0 493 5803
/local0/engines/ol_tuxedo/ifmxdata/rootdbs
b62a710 2 2 0 4 20
/local0/engines/ol_tuxedo/ifmxdata/dbsp1
2 active, 32766 maximum
NOTE: The values in the "page Rd" and "page Wr" columns for
DBspace chunks are
displayed in terms of system base page size.
Expanded chunk capacity mode: always
Interactive execution
To put the onstat utility in interactive mode, use the -i option. Interactive mode
allows you to enter multiple options, one after the other, without exiting the program.
For information on using interactive mode, see onstat -i.>
Use the seconds parameter with the -r option flag to cause all other flags to
execute repeatedly after they wait the specified seconds between each execution.
The oncheck utility is invoked by executing the oncheck command. The simplest
form of the command is shown in Listing 6, below:
oncheck
<-option>
<database | database:owner.table | tablespacenum logical
pagenum ... >
<-x>
<-n>
<-y>
-x Places a shared lock on the table when you check and
print an index
-n Indicates that no index repair should be performed,
even if errors are detected Use with the index
repair options
(-ci, -cI, -pk, -pK, -pl, and -pL).
-y Repairs indexes when errors are detected.
Options
Table 6. Oncheck options
Option Description
-cc Checks system catalog tables for
the specified database
-cd Reads all pages, except simple
large objects from the tblspace for
the specified database, table, or
fragment, and checks each page
for consistency. Also checks
tables that use a user-defined
access method. Does not check
simple or smart large objects.
-cD Same as -cd, but also reads the
header of each blobpage and
checks it for consistency. Checks
simple large objects but not smart
large objects.
-ce Checks each chunk-free list,
corresponding free space, and
each tblspace extent. Also checks
smart-large-object extents and
sbspace metadata. The oncheck
process verifies that the extents
on disk correspond to the current
control information that describes
them.
-ci Checks the ordering of key values
and the consistency of horizontal
and vertical node links for all
• Partition-page statistics
• Bitmap pages
• Partition blobpages
• Blobspace blobpages
• Indexes
• Sbspace pages
• Metadata partitions for sbspaces
If oncheck detects inconsistencies in other structures, messages alert you to these
inconsistencies, but oncheck cannot resolve the problem.
By not placing a shared lock on tables using row locks during index checks, the
oncheck utility cannot be as accurate in the index check. For absolute assurance of
a complete index check, you can execute oncheck with the -x option. With the -x
option, oncheck places a shared lock on the table, and no other users can perform
updates, inserts, or deletes until the check has completed.
The database server message log is an operating system file. The messages
contained in the database server message log do not usually require immediate
action.
Location
To specify the message log path name, set the MSGPATH configuration parameter.
The changes to MSGPATH take effect after you shut down and restart the database
server.
Monitor the message log size, because the database server appends new entries to
this file. Edit the log as needed, or back it up to tape and delete it.
If the database server experiences a failure, the message log serves as an audit trail
for retracing the events that develop later into an unanticipated problem. Often the
database server provides the exact nature of the problem and the suggested
corrective action in the message log.
You can read the database server message log for a minute-by-minute account of
database server processing in order to catch events before a problem develops.
However, you do not need to perform this kind of monitoring.
Message categories
• Routine information
• Assertion-failed messages
• Administrative action needed
• Fatal error detected
Examples of message log messages
Event alarms
attention (for example, unable to allocate memory). To use the event-alarm feature,
set the ALARMPROGRAM configuration parameter to the full pathname of an
executable file that performs the necessary administrative actions.
The database server can execute a program that operates either whenever certain
noteworthy event alarms occur or every time any event alarm occurs. Noteworthy
event alarms include failure of a database, table, index, chunk, or dbspace taken
offline, internal subsystem failure, start-up failure, and detection of long transaction.
You can receive notification of an event alarm through e-mail or pagermail.
• Whether the event-alarm program operates for all or only certain event
alarms
• What actions to take when alarm events occur
Table 7. Event-alarm parameters
Parameter Description
ALRM_ALL_EVENTS Specifies whether
ALARMPROGRAM runs for all
events that are logged in the
MSGPATH or only specified
noteworthy events
ALARMPROGRAM Specifies the location of a file that
is executed when an event alarm
occurs
UNIX tools
System activity reporter (SAR)
The sar command is useful for monitoring CPU utilization, disk activity, and memory
utilization.
$ sar -u 60 10
09:42:17 %usr %sys %wio %idle
09:43:17 1 5 0 94
09:44:17 1 4 0 95
09:45:17 5 3 0 92
09:46:17 4 6 1 89
The UNIX sar command is particularly useful for creating and maintaining long-term
performance histories:
The time and timex commands allow you to time the running of a process. Both
time and timex report on real time as well as user and system CPU time.
ps
$ ps -el
S UID PID PPID STIME TTY TIME CMD
T root 0 0 08:59:54 ? 0:01 sched
S root 1 0 08:59:57 ? 0:00 /etc/init
S root 434 1 09:03:51 ? 0:05 oninit
S root 435 434 09:03:53 ? 0:00 oninit
S root 445 434 09:06:02 ? 0:00 oninit
where PID is Process Id
STIME is process start time
TIME is accumulated CPU time for process
iostat
$ iostat -x 5 1
extended device statistics
device r/s w/s Kr/s Kw/s wait actv svc_t %w %b
sd0 6.2 0.0 21.5 0.0 0.0 0.1 24.1 0 15
sd1 1.8 0.0 14.3 0.0 0.0 0.1 41.6 0 7
sd6 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0
sd30 0.2 0.2 25.7 0.2 0.0 0.1 22.5 0 13
vmstat
The vmstat command provides information about the status of processes, memory
utilization, paging statistics, system activity, and CPU usage.
$ vmstat 5 4
procs memory page disk faults
r b w swap fre re mf pi po ... d0 d1 d2 in sy ...
4 1 0 104512 1792 8 0 288 192 ... 4 6 1 23 15 ...
2 3 0 105184 1952 4 0 96 128 ... 0 2 1 14 15 ...
3 2 0 106688 1952 7 0 256 224 ... 4 4 12 29 21 ...
4 2 0 104672 6240 4 0 384 32 ... 3 1 3 2 75 ...
where w is processes swapped out page outs
swap is Kbytes of swap space available
d0 is # of disk operations/sec
p0 is pageouts
Windows utilities
The following Informix utilities simplify administration of the database server on
Windows.
ixpasswd.exe
ixpasswd.exe changes the logon password for all services that log on as user
informix. You can change the password interactively or on the command line using
the -y option. This utility saves having to manually change the password for each
service whenever you change the informix password.
If you are logged on locally and run ixpasswd, it changes the password for services
that log on as the local informix user. If you are logged on domain and run ixpasswd,
it changes the password for services that log on as domain\informix.
Usage:
ixsu.exe
Launches a command-line window that runs as the specified user. The user is a
local user unless you specify a domain name. If you do not specify a user name, the
default user is informix. You no longer need to log off as the current user and log on
as informix to perform DBA tasks that need to be run as informix. The ixsu utility
requires advanced user rights:
• Increase quotas
• Replace a process-level token
• To configure advanced user rights on Windows NT:
ixsu [[domain\]username]
The ixsu utility is equivalent to the Windows 2000 runas command. To use runas
to run a command shell as another user:
Usage:
ntchname.exe
ntchname.exe changes the registry entries for Dynamic Server from the old
hostname to the new hostname. Run ntchname after you change the hostname.
This utility does not change user environment variables. After you execute
ntchname, edit the %INFORMIXDIR%\%INFORMIXSERVER%.cmd file and change
the INFORMIXSQLHOSTS entry to the new hostname.
Usage:
Section 8. Conclusion
This tutorial introduced you to the set of monitoring tools that are available with IDS
11 and showed you how each are used to monitor how well (or how poorly) your
database system is operating. Database monitoring is a vital activity that, when
performed on a regular basis, provides continuous feedback on the health of a
database system.
The SQL administration API enables you to perform remote administration using
various, specific SQL commands for tasks such as managing spaces, managing
configuration, running routine jobs, and system validation.
The system-monitoring interface (SMI) tables are special tables managed by the
database server that contain dynamic information about the state of the database
server. You can use SELECT statements on them to determine almost anything you
might want to know about your database server.
The onstat utility provides a way to monitor database server shared memory from
the command line. The onstat utility reads data from shared memory and reports
statistics that are accurate for the instant during which the command executes. That
is, onstat provides information that changes dynamically during processing,
including changes in buffers, locks, indexes, and users.
The oncheck utility displays information about the database disk configuration and
usage, such as the number of pages used for a table, the contents of the reserved
The database server message log is an operating system file. You can read the
database server message log for a minute-by-minute account of database server
processing in order to catch events before a problem develops.
Part 3 of the tutorial series helps you troubleshoot the database server problems.
Resources
Learn
• developerWorks Informix zone: Read articles and tutorials and connect to other
resources to expand your Informix skills.
• IBM Informix Dynamic Server Information Center: Learn more about Informix.
• IBM Informix Dynamic Server 11 BETA Information Center: Learn more about
IDS 11.
• developerWorks IDS Experts blog: Find technical notes on Informix Dynamic
Server by a worldwide team of Development and Technical Support engineers.
• IBM Information Management certification page: Learn more about resources
for IDS certification.
• developerWorks Information Management zone: Learn more about Information
Management. Find technical documentation, how-to articles, education,
downloads, product information, and more.
• Stay current with developerWorks technical events and webcasts.
• Technology bookstore: Browse for books on these and other technical topics.
Get products and technologies
• Informix Dynamic Server Enterprise Edition V10.0: Download a free trial
version.
• Informix Dynamic Server 11: Download the free trial version to work along with
this tutorial.
• IBM product evaluation versions: Download and get your hands on application
development tools and middleware products from Information Management,
Lotus®, Rational®, Tivoli®, and WebSphere®.
Discuss
• Participate in the discussion forum for this content.
• Check out developerWorks blogs and get involved in the developerWorks
community.
Sergio R. Eng
Sergio Eng has developed many database applications through the
years. He has also been a DBA and UNIX system administrator for
software development platforms. At IBM, Sergio has provided Informix
database support for IDS users for Versions 7, 9, and 10.