Exploring The Sysmaster Database: by Lester Knutsen
Exploring The Sysmaster Database: by Lester Knutsen
by Lester Knutsen
W hen you list all the databases on your INFORM IX server, you will see one called “sysmaster”. This is a special
database and is one o f the new features that first appeared in INFO RM IX-O nLine D SA 6.x and 7.x. T his is a
database that contains tables that can be used for monitoring your system. These are referred to as the System
Monitoring Interface (S MI) tables. In this chapter we will exp lore so me o f the tables and views that are in this
datab ase.
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 OnLine engine. The sysmaster database contains over 120
tables. Only 18 of these tables are documented in the INFORM IX-OnLine Dynamic Server Administrator’s Guide,
Volume 2, Cha pter 38. The rest are undocumented and d escribed by Informix as for internal use. The examples and
references in this article are based on OnLine 7.23. I have also tested some of the examples with versions 7.10, 7.12,
and 7.2 2. The re are som e minor changes between versions in the und ocumented features and structures of these
tables.
A warning: Some of the features discussed in this article are based on undocumented SMI tables and may change or
not work in future versions of INFORMIX OnLine DSA.
This article will focus on users, server configuration, dbspaces, chunks, tables, and monitoring IO using the
sysmaster database. W e will present how to create scripts to monitor the following:
List who is using each da tabase.
Display information about your server configuration.
Display how much free space is available in each dbspace in a format like the Unix df command.
List the status and characteristics of each chunk device.
Display blocks of free space within a chunk. This allows you to plan where to put large tables without
fragmenting them.
Display IO statistics by chunk devices.
Display IO usage of chunk devices as a percent of the total IO, and show which chunks are getting used the
most.
Display tables and the number of extents, and number of pages used.
Present a layout of dbspace, databases, tables, and extents similar to the command “tbcheck -pe”.
Show tab le usage statistics sorted by which tables ha ve the most reads, writes, or locks.
Show statistics of users sessions.
Show lo cks and users who are waiting on locks.
My interest in this database started a couple of years ago, while consulting on a project for a development group
where I need ed to know who had a d ataba se op en and which w orkstation they were using to co nnect to the databa se.
This was a development environment and there were continual changes to the database schemas. In order to make
updates to the database schema, I would have to get the developers to disconnect from the database. The “onstat -u”
utility would tell me which users were connected to the server, but not what database and what workstation they were
using. “O nstat -g ses” told me the use r and workstation, but not the datab ase. “O nstat -g sql told me the session id
and datab ase, but not the user name and wo rkstation. After some d ebugging, I found all the inform ation I wanted in
the sysmaster database. And, because it was a database, I could retrieve it with SQL q ueries. The following query
shows the database, who has it open, the workstation they are connected from, and the session id.
1
Figure 1. Dbwho SQL script
-- dbwho.sql
select sysdatabases.name database, -- Database Name
syssessions.username, -- User Name
syssessions.hostname, -- Workstation
syslocks.owner sid -- Informix Session ID
from syslocks, sysdatabases , outer syssessions
where syslocks.tabname = "sysdatabases" -- Find locks on sysdatabases
and syslocks.rowidlk = sysdatabases.rowid -- Join rowid to database
and syslocks.owner = syssessions.sid -- Session ID to get user info
order by 1;
Every user that opens a database o pens a shared lock on the row in the sysdatab ases table of the sysmaster d atabase
that points to that database. First we need to find all the locks in syslocks on the sysdatabases table. This gives us
the rowid in sysdatabase which has the database name. Finally, we join with the table syssessions to get the
userna me and ho stname. I put all this togethe r in a shell script that ca n be run from the unix p rompt and called it
dbw ho. Figure 2 contains the shell script.
One of the first things you will notice is that this script is slow. This led me to start digging into what was causing
the slow performance. Running this query with set explain turned on (this shows the query optimizer plan) shows
that there is a lot of work going on behind the scenes. Syslocks is a view, and it takes a sequential scan of six tables
to produce the view. A temp table is created to hold the results of the syslocks view, and this is then joined with the
other two tables. The tables sysdatabase and syssessions are also views. And the view syssessions uses a stored
procedure, called bitval. Figure 3 contains the output from turning set explain on. In spite of these queries
sometimes being a bit slow, these tables are a tremendous value and make it much easier to mon itor your database
server.
2
outer("informix".sysrstcb x5 )
where ((((((x0.partnum = x1.partnum )
AND (x0.owner = x2.address ) )
AND (x2.owner = x3.address ) )
AND (x0.wtlist = x5.address ) )
AND (x4.tabname = 'syslcktab' ) )
AND (x4.flags = x0.type ) ) ;
Estimated Cost: 713
Estimated # of Rows Returned: 51
QUERY:
------
select sysdatabases.name database,
syssessions.username,
syssessions.hostname,
syslocks.owner sid
from syslocks, sysdatabases, outer syssessions
where syslocks.rowidlk = sysdatabases.rowid
and syslocks.tabname = "sysdatabases"
and syslocks.owner = syssessions.sid
order by 1
3
The sysmaster database keeps track of information about the database server just like the system tables keep track of
information in each database. This database is automatically created when you initialize OnLine. It includes tables
for tracking two types of information: the System Monitoring Interface (SMI) tables, and the On-Archive catalog
tables. This article will focus on the SMI tables. There is a warning in the documentation not to change any
information in these tables as it may corrupt your database server. Also there is a warning that OnLine does not lock
these tab les, and that all selects from this datab ase will use an isolation leve l of dirty rea d. This mea ns that the data
can change dynamically as you are retrieving it. This also means that selecting data from the sysmaster tables does
not loc k any of your use rs from processing their data. As mentioned above, the SMI tables are described as pseudo-
tables which point directly to the shared memory structures in OnLine where the data is stored. That means they are
not actually on d isk. Ho wever, because m any of the SM I tables are rea lly views, selecting from them does create
temporary tables and generate disk activity.
A scrip t located in you r directory $INF OR MIXD IR/etc. name d sysmaster.sql contains the SQ L statem ents to create
the sysmaster datab ase. The process of creating it is interesting and outlined as follows:
First the script creates real tables with the structures of the pseu do tables.
Then, the table structures of the real tables are co pied to temp tables.
The real tables are then dropped.
The column in systables that contains partnum is updated to indicate they point to pseudo tables in shared
mem ory.
The flags_text table is created which has the interpretations for all the text descriptions and flags used in the
SM I tables.
The stored proced ures are created that are used to create the views, two of which may be interesting:
- bitval() is a stored procedure for getting the boolean flag values
- l2date() is a stored procedure for converting unix time() long values to dates
Finally the script creates the SM I views.
After the sysmaster script is run the system will execute another script to create the on-archive tables and
views in the sysmaster database.
W arning: The sysmaster database is created the first time you go into online mode after you first initialize your
system. Do NOT start creating any other database until this process is complete or you may corrupt your sysmaster
database. You will need 2000 KB of logical log space to create the sysmaster database. If there are problems
creating the sysmaster database, shut your OnLine server down and restart it. This will re-create the sysmaster
database. Monitor your online.log file until you see the messages showing the successful completion of building the
sysmaster database in the online.log (Figure 4).
4
Supported SMI Tables
There are 18 supp orted SM I tables in release 7.23 of INFOR MIX -OnLine DSA . We will discuss the more important
ones and a few unsupported ones in this chapter.
There are several key differences between the sysmaster database and other databases you might create. Reminder
that this is a databa se that points to the serve r’s shared me mory structures and not to tables that are stored on disk.
Some of the differences are:
Yo u cann ot update the sysmaster database. Its purpose is to allow you to read information about the serve r.
Trying to update its tables should generate an error message but may corrupt the server.
You cannot run dbschema on these table to get their structure. This will generate and error message.
You cannot drop the sysmaster database or any tables within it. Again, this should generate an error
message.
The data is dynamic and may change while you are retrieving it. The sysmaster database has an effective
isolation level of dirty read even though it looks like a database with unb uffered logging . This p revents
your queries from locking users and slowing down their processing.
However, because the sysmaster database uses unbuffered logging, its temp tables are logged.
You can create triggers and stored procedures on the sysmaster database, but the triggers will never be
executed. A gain, this is because this is not a real databa se but pointers to shared m emo ry.
The sysmaster database reads the same shared memory structures read by the command line utility “onstat”. The
statistical data is reset to zero when OnLine is shut down and restarted.
It is also reset to zero when the “onstat -z” comm and to reset statistics is used. Individual user statistical data is lost
when a user disconnects from the server.
No w, let’s examine so me o f the mo re interesting tables in the sysm aster databa se and what else can be done with
them.
3. Server Information
This first section will look at how you determine the state and configuration of your INFORMIX-OnLine server from
the sysmaster database. We will look at four tables and how to use them.
5
sysconfig - ON CO NF IG F ile
sysprofile - Server Statistics
syslogs - Logical Logs
sysvpprof - Virtual Processors
The view sysonfig contains configuration information from the OnLine server. This information was read from the
ONC ONFIG file when the server was started. Have you ever needed to know from within a program how your server
was setup? Or, what TAPEDEV is set to?
View sysconfig
Column Data Type Description
cf_id integer unique numeric identifier
cf_name char(18) config parameter name
cf_flags integer flags, 0 = in view sysconfig
cf_original char(256) value in ONCONFIG at boottime
cf_effective char(256) value effectively in use
cf_default char(256) value by default
Example queries:
To find out what the current tape device is:
select cf_effective from sysconfig where cf_name = "TAPEDEV";
The sysprofile table is a view based on values in a table called syshmhdr. Syshmhdr points to the same shared
mem ory are a as the o nstat utility with the -p optio n. W hen you zero out the statistics with “onstat -z”, all values in
the syshmhdr table are reset to zero.
View sysprofile
Column Data Type Description
name char(16) profile element name
value integer current value
One of the best uses of this data is for developing alarms when certain values fall below acceptable levels. The
Inform ix documentation says that tables in the sysmaster database do not run triggers. T his is because the updates to
these tables take place within OnLine shared memory and not through SQL which activates triggers. However, you
can create a p rogram to poll this table at specified intervals to select data and see if it falls below your expectations.
Syslogs is a view based on the table syslogfil. This is an example where the SMI views are a great tool in presenting
the data in a more understandable format. Syslogfil has a field called flags which contains status information
encoded in boolean smallint. The view syslogs decodes that data into six fields: is_used, is_current, is_backed_up,
is_new, is_archived, and is_temp, with a 1 if true or a 0 if false.
View syslogs
Column Data Type Description
number smallint logfile number
uniqid integer logfile uniqid
size integer pages in logfile
used integer pages used in logfile
is_used integer 1 for used, 0 for free
6
is_current integer 1 for current
is_backed_up integer 1 for backuped
is_new integer 1 for new
is_archived integer 1 for archived
is_temp integer 1 for temp
flags smallint logfile flags
Sysvpprof is another view that is more readable than the underlying table sysvplst. As with the view syslogs in the
above paragraph, this view has data that is converted to make it more understandable. This time the flags are
converted to text descriptions from the flags_text table.
View sysvpprof
Column Data Type Description
vpid integer VP id
txt char(50) VP class name
usecs_user float number of unix secs of user time
usecs_sys float number of unix secs of system time
The following query on the base table sysvplst achieves the same results as the view.
SQL Output
vpid class pid usecs_user usecs_sys num_ready
7
4. Dbspace and Chunk Information
Now let’s look at the SMI tables that contain information about your disk space, chunks, and dbspace. There are
four tables that contain this data.
sysdbspaces - DB Spaces
syschunks - Chunks
syschkio - I/O by Chunk
syschfree* - Free Space by Chunk
* Note: Syschfree is not a supported table.
The sysmaster database has three key tables containing db space and chunk information. T he first one is sysdb spaces.
This is a view tha t interpre ts the und erlying tab le sysdb stab. Sysdbspaces serves two purp oses: it translates a b it
field containing flags into separate columns where 1 equa ls yes and 0 equals no, and, it allows the un derlying table to
change b etween releases w ithout having to chang e code . The view is de fined as follows:
View sysdbspaces
Column Data Type Description
dbsnum smallint dbspace number,
name char(18) dbspace name,
owner char(8) dbspace owner,
fchunk smallint first chunk in dbspace,
nchunks smallint number of chunks in dbspace,
is_mirrored bitval is dbspace mirrored, 1=Yes, 0=No
is_blobspace bitval is dbspace a blob space, 1=Yes, 2=No
is_temp bitval is dbspace temp, 1=Yes, 2=No
flags smallint dbspace flags
The columns of type bitval are the flags that are extracted from the flags column by a stored procedure called bitval
when the view is generated.
The syschunks table is also a view based on two actual tables, one for primary chunk information, syschktab, and one
for mirror chun k information, sysmchk tab. The following is the layout of syschunks:
View syschunks
Column Data Type Description
chknum smallint chunk number
dbsnum smallint dbspace number
nxchknum smallint number of next chunk in dbspace
chksize integer pages in chunk
offset integer pages offset into device
nfree integer free pages in chunk
is_offline bitval is chunk offline, 1=Yes, 0=No
is_recovering bitval is chunk recovering, 1=Yes, 0=No
is_blobchunk bitval is chunk blobchunk, 1=Yes, 0=No
is_inconsistent bitval is chunk inconsistent, 1=Yes, 0=No
flags smallint chunk flags converted by bitval
fname char(128) device pathname
mfname char(128) mirror device pathname
moffset integer pages offset into mirror device
mis_offline bitval is mirror offline, 1=Yes, 0=No
mis_recovering bitval is mirror recovering, 1=Yes, 0=No
mflags smallint mirror chunk flags
8
Displaying Free Dbspace
No w, we will take a loo k at several ways to use this dbspace and chunk informatio n. One cap ability I hav e always
wanted is a way to show the amount of dbspace used and free in the same format as the Unix “df -k” command. The
sysmaster database con tains information abo ut the db spaces and chunks, so this can be genera ted with an SQ L scrip t.
The following is an SQL script to generate the amount of free space in a dbspace. It uses the sysdbspaces and
syschunks tables to collect its information.
database sysmaster;
Sample output
dbspace pages_size pages_used pages_free percent_free
rootdbs 50000 13521 36479 72.96
dbspace1 100000 87532 12468 12.47
dbspace2 100000 62876 37124 37.12
dbspace3 100000 201 99799 99.80
database sysmaster;
select
name dbspace, -- dbspace name
is_mirrored, -- dbspace is mirrored 1=Yes 0=No
is_blobspace, -- dbspace is blobspace 1=Yes 0=No
is_temp, -- dbspace is temp 1=Yes 0=No
chknum chunknum, -- chunk number
fname device, -- dev path
offset dev_offset, -- dev offset
is_offline, -- Offline 1=Yes 0=No
is_recovering, -- Recovering 1=Yes 0=No
is_blobchunk, -- Blobspace 1=Yes 0=No
is_inconsistent, -- Inconsistent 1=Yes 0=No
chksize Pages_size, -- chunk size in pages
(chksize - nfree) Pages_used, -- chunk pages used
nfree Pages_free, -- chunk free pages
round ((nfree / chksize) * 100, 2) percent_free, -- free
mfname mirror_device, -- mirror dev path
moffset mirror_offset, -- mirror dev offset
mis_offline , -- mirror offline 1=Yes 0=No
mis_recovering -- mirror recovering 1=Yes 0=No
from sysdbspaces d, syschunks c
where d.dbsnum = c.dbsnum
order by dbspace, chunknum
9
In planning expansions, new databases, or when adding new tables to an existing server, I like to know what blocks
of contiguous free space are available. This allows placing new tables in dbspaces where they will not be broken up
by extents. One of the sysmaster tables tracks the chunk free list, which is the available sp ace in a chunk.
Table syschfree
Column Data Type Description
chknum integer chunk number
extnum integer extent number in chunk
start integer physical addr of start
leng integer length of extent
The next script uses this table to create a list of free space and the size of each space that is available.
database sysmaster;
select
name dbspace, -- dbspace name truncated to fit
f.chknum, -- chunk number
f.extnum, -- extent number of free space
f.start, -- starting address of free space
f.leng free_pages -- length of free space
from sysdbspaces d, syschunks c, syschfree f
where d.dbsnum = c.dbsnum
and c.chknum = f.chknum
order by dbspace, chknum
Sample Output
dbspace chknum extnum start free_pages
rootdbs 1 0 11905 1608
rootdbs 1 1 15129 34871
Inform ix uses a view, syschkio, to collect information about the num ber o f disk reads and writes per chunk. T his
view is based on the tables syschktab and symchktab.
View syschkio
Column Data Type Description
chunknum smallint chunk number
reads integer number of read ops
pagesread integer number of pages read
writes integer number of write ops
pageswritten integer number of pages written
mreads integer number of mirror read ops
mpagesread integer number of mirror pages read
mwrites integer number of mirror write ops
mpageswritten integer number of mirror pages written
The following script displays IO usage of chunk devices. It uses the base tables so the mirror chunks can be
displayed on separate rows. It also joins with the base table that contains the dbspace name.
10
writes,
pagesread,
pageswritten
from syschktab c, sysdbstab d
where c.dbsnum = d.dbsnum
union all
select
name[1,10] dbspace,
chknum,
"Mirror" chktype,
reads,
writes,
pagesread,
pageswritten
from sysmchktab c, sysdbstab d
where c.dbsnum = d.dbsnum
order by 1,2,3;
Sample Output
dbspace chknum chktype reads writes pagesread pageswritten
rootdbs 1 Primary 74209 165064 209177 308004
rootdbs 1 Mirror 69401 159832 209018 307985
A better view of your IO is to see the percent of the total IO that takes place per chunk. This next query collects IO
stats into a temp table, and then uses that to calcu late total IO stats for all chunks. T hen ea ch chu nk’s IO is
com pared with the total to d etermine the p ercen t of IO by chunk. The following script uses the one abo ve as a basis
to show IO by chunk as a percent of the total IO.
11
-- Report showing each chunks percent of total IO
select
dbspace,
chknum,
chktype,
reads,
writes,
pagesread,
pageswritten,
round((reads/total_reads) *100, 2) percent_reads,
round((writes/total_writes) *100, 2) percent_writes,
round((pagesread/total_pgreads) *100, 2) percent_pg_reads,
round((pageswritten/total_pgwrites) *100, 2) percent_pg_writes
from A, B
order by 11;-- order by percent page writes
This view has data on all databases on a server. Have you ever needed to create a pop-up list of databases within a
program? T his table now a llows progra ms to give users a list of databases to select from without resorting to
ESQL/C. The following is the definition of this view:
View sysdatabases
Column Data Type Description
name char(18) database name
partnum integer table id for systables
owner char(8) user name of creator
created integer date created
is_logging bitval unbuffered logging, 1=Yes, 0= No
is_buff_log bitval buffered logging, 1=Yes, 0= No
is_ansi bitval ANSI mode database, 1=Yes, 0= No
is_nls bitval NLS support, 1=Yes, 0= No
flags smallint flags indicating logging
12
The follow ing is a scrip t to list all datab ases, owners, dbsp aces, and logging status. No tice the function d binfo is
used. This is a new function in 7 .X with several uses, one of which is to conve rt the partnum of a da tabase into its
corresponding dbspace. This function will be used in several examples that follow.
Sample Output
dbspace database owner is_logging is_buff_log
rootdbs central lester 0 0
rootdbs datatools lester 0 0
rootdbs dba lester 0 0
rootdbs roster lester 0 0
rootdbs stores7 lester 0 0
rootdbs sunset linda 0 0
rootdbs sysmaster informix 1 0
rootdbs zip lester 1 1
Three tables contain all the data you need from the sysmaster database about tables in your database. The first of
these is a real table defined a s follows:
Table sysptnext
Column Data Type Description
pe_partnum integer partnum for this partition
pe_extnum smallint extent number
pe_phys integer physical addr for this extent
pe_size integer size of this extent
pe_log integer logical page for start
13
lockwts integer lock waits
deadlks integer deadlocks
lktouts integer lock timeouts
isreads integer reads
iswrites integer writes
isrewrites integer rewrites
isdeletes integer deletes
bufreads integer buffer reads
bufwrites integer buffer writes
seqscans integer sequential scans
pagreads integer disk reads
pagwrites integer disk writes
These tables allow us to develop scripts to display tables, the number of extents, and pages used. We can also present
a layout of dbspace, databases, tables, and extents similar to the command “tbcheck -pe”. And finally, we can show
table usage statistics sorted by which tables have the mo st hits based on reads, writes, or locks. T hese sc ripts will
enable a DB A to monitor and tune the database server.
Extents are created when a table’s initial space has b een filled up and it needs more sp ace. O nLine will allocate
additional space for a table. However, the table will no longer be contiguous, and performance will start to degrade.
Informix will display warning messages when a table reaches more than 8 extents. Depending on a number of
factors, at app roxim ately 18 0-23 0 extents a table will not b e able to exp and and no additiona l rows can be inserted .
The following script lists all tables sorted by the number of extents. The tables that show up with many extents may
need to be unloaded and rebuilt.
Sample Output
dbsname tabname num_of_extents total_size
rootdbs TBLSpace 8 400
sysmaster syscolumns 6 56
sunset inventory 3 376
sunset sales_items 3 96
sunset sales_header 3 48
sunset parts 3 48
sunset customer 3 40
sunset syscolumnext 3 32
sunset employee 3 32
Sometimes it is helpful to see how the tables are interspersed on disk. The following script lists by dbspace each
table and the location of each extent. This is similar to the output from “oncheck -pe”.
14
where pe_partnum = partnum
order by dbspace, start;
Sample output
dbspace dbsname tabname start size
rootdbs rootdbs TBLSpace 1048589 50
rootdbs sysmaster sysdatabases 1050639 4
rootdbs sysmaster systables 1050643 8
rootdbs sysmaster syscolumns 1050651 16
rootdbs sysmaster sysindexes 1050667 8
rootdbs sysmaster systabauth 1050675 8
rootdbs sysmaster syscolauth 1050683 8
rootdbs sysmaster sysviews 1050691 8
rootdbs sysmaster sysusers 1050699 8
rootdbs sysmaster sysdepend 1050707 8
rootdbs sysmaster syssynonyms 1050715 8
IO Performance of Tables
Have you ever wanted to kno w which tables have the mo st reads, writes, or locks? The last scrip t in this article
shows the performance profile of tables. By changing the columns displayed and the sort order of the script, you can
display the tables with the most reads, writes, or locks first.
Sample Output
dbsname tabname isreads bufreads pagreads
zip zip 334175 35876509 1111
sysmaster sysviews 259712 634102 1119
sysmaster systables 60999 240018 1878
zip systables 3491 8228 543
sysmaster sysusers 2406 8936 87
sysmaster sysprocauth 1276 5104 12
sunset systables 705 2251 26
sysmaster sysprocedures 640 2562 21
sysmaster syscolumns 637 1512 49
stores7 systables 565 1361 16
sysmaster sysdatabases 534 2073 902
15
6. User Session Information
This last set of SMI tables deals with users and information about their sessions. These tables were used in our
example script “dbwho” at the beginning of this chapter.
syssessions - Session data
syssesprof - User statistics
syslocks - User Locks
syseswts - Wait times
This view co ntains informatio n from two sha red m emo ry structure s, the user contro l and thread contro l table. T his
tells you who is logged in to your server and some basic data about their session.
View syssessions
Column Data Type Description
sid integer Session id number
username char(8) User name
uid smallint User unix id
pid integer User process id
hostname char(16) Hostname
tty char(16) TTY port
connected integer Time user connected
feprogram char(16) Program name
pooladdr integer Pointer to private session pool
is_wlatch integer Flag 1=Yes, 0=No, wait on latch
is_wlock integer Flag 1=Yes, 0=No, wait on lock
is_wbuff integer Flag 1=Yes, 0=No, wait on buffer
is_wckpt integer Flag 1=Yes, 0=No, wait on checkpoint
is_wlogbuf integer Flag 1=Yes, 0=No, wait on log buffer
is_wtrans integer Flag 1=Yes, 0=No, wait on a transaction
is_monitor integer Flag 1=Yes, 0=No, a monitoring process
is_incrit integer Flag 1=Yes, 0=No, in crtical section
state integer Flags
Sample Output
This next query list all users and their session status. The objective is to show who is blocked waiting on another
user, lock, or some other OnLine process. The five fields are yes/no flags where 1 = yes and 0 = no. If all the fields
are 0, then none of the sessions are blocked. In the following example, one session is blocked waiting on a locked
record.
16
Figure 17. SQL script users waiting on resources
-- seswait.sql
select username,
is_wlatch, -- blocked waiting on a latch
is_wlock, -- blocked waiting on a locked record or table
is_wbuff, -- blocked waiting on a buffer
is_wckpt, -- blocked waiting on a checkpoint
is_incrit -- session is in a critical section of transaction
-- (e.g writting to disk)
from syssessions
order by username;
Sample Output
username is_wlatch is_wlock is_wbuff is_wckpt is_incrit
lester 0 1 0 0 0
lester 0 0 0 0 0
lester 0 0 0 0 0
This view syssesprof provides a way to find out at a given point in time how much of your server resources each user
is using. The view contains the following information.
View syssesprof
Column Data Type Description
sid integer, Session Id
lockreqs decimal(16,0) Locks requested
locksheld decimal(16,0) Locks held
lockwts decimal(16,0) Locks waits
deadlks decimal(16,0) Deadlocks detected
lktouts decimal(16,0) Deadlock timeouts
logrecs decimal(16,0) Logical Log records written
isreads decimal(16,0) Reads
iswrites decimal(16,0) Writes
isrewrites decimal(16,0) Rewrites
isdeletes decimal(16,0) Deletes
iscommits decimal(16,0) Commits
isrollbacks decimal(16,0) Rollbacks
longtxs decimal(16,0) Long transactions
bufreads decimal(16,0) Buffer reads
bufwrites decimal(16,0) Buffer writes
seqscans decimal(16,0) Sequential scans
pagreads decimal(16,0) Page reads
pagwrites decimal(16,0) Page writes
total_sorts decimal(16,0) Total sorts
dsksorts decimal(16,0) Sorts to disk
max_sortdiskspace decimal(16,0) Max space used by a sort
logspused decimal(16,0) Current log bytes used
maxlogsp decimal(16,0) Max bytes of logical logs used
This table co ntains data since the user logg ed on. E ach time a user d isconnects their data is lost so you cannot use
this data for charging the user for server usage. Also, when a DB A resets the server statistics with the command
“tbstat -z”, all profile data is reset to zero.
I like to m onitor the num ber o f locks used b y each user and their b uffer usag e. Th e follow ing is an example query.
17
Figure 19. SQL script to monitor resource usage by user
-- sesprof.sql
select username,
syssesprof.sid,
lockreqs,
bufreads,
bufwrites
from syssesprof, syssessions
where syssesprof.sid = syssessions.sid
order by bufreads desc
This view contains information about all active locks on your server. It can be very large; if you have a lot of users
and your server is configured to handle a large number of locks, you could end up with hundreds of thousands or
more reco rds in this view. T his view is comp osed of six tables, and queries on this view will create a temp table
which is logged to yo ur logical log. T he pe rformance may be a bit slow because of the she er volume o f data
produced by this view. However, the data this view contains can be very helpful to understanding how your system
is performing.
View syslocks
Column Data Type Description
dbsname char(18) Database name
tabname char(18) Table name
rowidlk integer Rowid for index key lock
keynum smallint Key number of index key lock
owner integer Session ID of lock owner
waiter integer Session ID of first waiter
type char(4) Type of Lock
Types of Locks
B - byte lock
IS - intent shared lock
S - shared lock
XS - repeatable read shared key
U - update lock
IX - intent exclusive lock
SIX - shared intent exclusive
X - exclusive lock
XR - repeatable read exclusive
Basically there are three types of locks: a shared lock (S), an exclusive lock (X), and an update lock(U). A shared
lock allows other users to also read the data but no ne may change it. An exclusive lock d oes not allow anyone else
to lock that data even in shared mode. An upd ate lock prevents other users from changing data while you are
changing it.
Datab ase - Every user that op ens a datab ase places a sha red lock o n the databa se to preven t someon e else
from dropping the database while it is in use. This shows up as a lock on the sysmaster database and the
sysdatabase tables, and the rowid will point to the record containing database name.
Table - A table lock shows up as a lock on a table with a rowid of 0 and a keynum of 0.
Page - A page level lock shows as a rowid ending in 00. This means all the rows on that page are locked.
Row - A row level lock will show with an actual rowid (not ending in 00).
Key - A key lock will show with a keynum. If a row has indexes that need to be updated this will place
locks on the indexes for that row.
18
One of the key data eleme nts missing from this view is the username and session id (sid) of the user w ho has a lock.
The following query adds the user’s name and session id and uses the underlying tables to improve performance. It
also puts the data into a temp table fro m which you can select subsets of data much mo re quickly than if you were to
repeat the query.
select dbsname,
tabname,
rowidr,
keynum,
type[1,4],
owner,
ownername ,
waiter,
waitname
from A;
The above example SQL output shows the row from syslocks that displays the exclusive lock I created on the temp
table “A ” while ru nning the query.
A more important use of this query is to find out when one user is waiting on the lock owned by another user. When
a user has a database object locked, the first user waiting on the object can be displayed. (This will only occur when
a user has set lock m ode to W AIT ). The following script displays only the users that have loc ks where som eone else
is waiting on their process. There is one key difference between this script and the one above. The tables sysrstcb
and sysscblst in this script do not use an o uter join, so only rows that have waiters will be returned . In this example
19
“linda” has an update lock on a row and “lester” is waiting for that update to complete.
select dbsname,
b.tabname,
rowidr,
keynum,
e.txt type,
d.sid owner,
g.username ownername,
f.sid waiter,
h.username waitname
from syslcktab a,
systabnames b,
systxptab c,
sysrstcb d,
sysscblst g,
flags_text e,
sysrstcb f , sysscblst h
where a.partnum = b.partnum
and a.owner = c.address
and c.owner = d.address
and a.wtlist = f.address
and d.sid = g.sid
and e.tabname = 'syslcktab'
and e.flags = a.type
and f.sid = h.sid
into temp A;
select dbsname,
tabname,
type[1,4],
owner,
ownername ,
waitname
from A;
SQL Output
dbsname tabname type owner ownername waitname
stores7 items U 29 linda lester
This is a supported view that shows all sessions that are blocked and waiting on a database object. It shows the
amount of time a user has been waiting. On a well tuned system this table should be empty. However, when the
table is not empty, it provides useful information on what is causing your performance to slow down.
View sysseswts
Column Data Type Description
sid integer Session ID
reason char(50) Description of reason for wait
numwaits integer Number of waits for this reason
cumtime float Cumulative wait time for this reason
maxtime integer Max wait time for this reason
20
7. Some Unsupported Extras
Seve ral of the SM I tables are no t documented and no t officially supported. T hese could change in future release s.
Two ad ditional unsupported tables I have found helpful are systrans and syssqexplain.
Three of the fields in systrans are very helpful to determine what logical log number a transaction began in, and the
current logical log number in use by a transaction.
This can be used to crea te a scrip t to determine what logical log files have active transactio ns. The output of this w ill
tell you what logical logs are free and available for reuse. This first script lists all user transactions and what logs
they are using.
SQL Output
username sid tx_logbeg tx_loguniq tx_logpos
informix 1 0 16 892952
informix 0 0 0 0
informix 8 0 0 0
lester 53 0 0 0
informix 12 0 0 0
lester 51 14 16 0
This shows that my logical logs num bered 14 to 16 are in use by transactions.
Another helpful use of this view is to summarize the transactions by logical logs. This next script show my
transaction status by logical log.
21
select tx_loguniq, count(*) cnt
from B
where tx_loguniq > 0
group by tx_loguniq
into temp D;
SQL Output
uniqid size is_backed_up is_archived tx_beg_cnt tx_curr_cnt
10 500 1 1
11 500 1 1
12 500 1 1
13 500 1 1
14 500 1 1
15 500 1 1
16 500 0 1 1 2
This shows that all logs are backed up except the current one, and it has two ac tive transactions.
Have you ever wanted to run a query to see what your users were doing? The view syssqexplain contains some of
the data from a user’s session, including the sql that they are currently executing. Try this query on your system
sometime to see your user’s SQL.
SQL Output
username lester
sqx_sessionid 55
sqx_conbno 2
sqx_sqlstatement select username,sqx_sessionid, sqx_conbno, sqx_sqlstatement
from syssqexplain, sysscblst
where sqx_sessionid = sid
username lester
sqx_sessionid 51
sqx_conbno 0
sqx_sqlstatement update items set total_price = 300 where item_num = 1
22
Conclusion
The sysmaster database is a great tool for a DBA to monitor the Informix server. If you have any questions or
suggestions please send me E-mail at [email protected]. Also, if you have any creative scripts for
monitoring your server with the sysmaster database, please send them in and I may include them in the future
publications.
Lester Knutsen
Advanced DataTools Corporation
Web: www.advancedatatools.com
Email: [email protected]
23