Welcome to my presentation on DB2 Performance Databases
How to create your own DB2 performance database and then how you can use it!
ABSTRACT: Many vendors of DB2 performance analysis tools offer a "performance
database" which consists of tables where you store db2 trace output as processed
by the analysis tool. When loaded, you can use the power of SQL to easily mine this
valuable information
1
Welcome to my agenda
Manulife is where I work. We are called John Hancock in the USA.
Some shops have been running standard traces for years.. but they never look at the data!
You should look at it… it is interesting
My target audience is DBAs who don’t have a PDB but they hava a DB2 monitor tool which
allows the creation of a PDB.
I hope I am not saying things that are TOO obvious… it is obvious to me now. But it wasn’t
obvious in the beginning.
My goal of this presentation is to give the big picture of a PDB (not reference… good
reference exists). I want to help others understand the value of a PDB
my first DB2 performance database was provided by CA Insight for DB2. It was fine. For
reasons beyond my input or control my shop switched from CA Inisght for DB2 to
Omegamon for DB2.
It turns out they both have “performance databases”. <the names may vary> But the
structure and contents of tables of the performance db was remarkably the same.
But that makes sense (in hindsight), obviously both are built upon the same input source >
the DB2 trace output (via SMF in my case)
Again. Lots of good reference DB2 trace reference information exists. This is a quick
summary on what you see after –DIS TRACE db2 command
I found the IBM reference documentation onTRACE and IFCIDs to not be good at
explaining the big picture. It is excellent reference documentation. It took me a while to get
to my still not-perfect understanding. I had to put the pieces together myself… I am still
putting it together..
I am not telling you what traces to run! Most shops are already running traces. I just want
you to utilize your traces more! And that can be done by putting the trace output in a PDB
Accounting Traces are the best. They provide details on application activity. The
accounting Trace output is generated when a accounting event occurs. This is normally
when a db2 thread completes its activity (ie end of CICS transaction… or batch job step).
But it is not always 1 to 1 even for CICS … ( I have learned to my surprise). And even
more so… distributed db2 activited (DRDA) is often summarized by Db2 according to
DSNZPARM of ACCUMACC value. This is probably important to set so you don’t generate
too much accounting output from high volume web applications. We have ACCUMACC set
to 10… I am thinking of setting it to 100… What do others do? (I would like to know).
There is a accounting trace output field that tells you many distributed acitivites are
summarized into this trace output… it is called PAR_
The differences between the PDB and PWH are explained in many places. It took me a
while to really figure it out. A PDB is totlaly under my control and was relatively easy to
setup. No expensive server to purchase or assign responsibility. Hands on type dbas
probably gravitate towards building a PDB
… maybe with more experience I will switch to PWH
This link is probably redundant… it can be easily googled. Make sure you pick OM XE for
DB2 documentation for your particular Version! For example.. My shop is at V5.2 but V5.3
is already available (with some new PDB tables available… to be mentioned soon)
Reading the PDB reference documentation leads to the obvious question… To File or
Save. It is a good question.
It took me too long to figure out the difference between SAVE and FILE. Using SAVE
produces the most detailed and non-aggreagated data. In my world it was OK. Merely
millions of records.
>> although I do have a new interesting high volume CICS application that is changing from
VSAM to DB2. It will be interesting the amount of new volume of data in my PDB.. I may
have to rethink my strategy….
There are many possible PDB tables. The most valuable and immediate
accounting tables include
DB2PMFACCT_GENERAL, DB2PMFACCT_PROGRAM (*)…
(*) was it a poor decision many years ago to call the
package data table DB2PMFACCT_PROGRAM? I think yes… it should be
package (I think)
The main important statistics table is DB2PM_STAT_GENERAL
And then there are relatively new bonus tables for dynamic and static sql statements.
Fascinating info here… but it may be a bit expensive to constantly gather (ie. Run these
traces)… so think about it.
The reference documentation is not explicit about HOW to build a PDB. What database
name to use? Where to put the db?
And tablespaces? They are ommited in the provided DDL. You make your own … it isn’t
that hard. May as well use UTS PBG (although you could partitioni)
No indexes are suggested in the reference. Build indexes for your anticipated use.
non-unique indexes are ok
in hindisght... my indexes are not the best. not all are used all the time… but it is something
The accounting tables contain lots of data (depending upon your retention rule). Using your
indexes will help your query performance! I keep the index picture handy to remind
myself… or I do a quick explain in data studio to confirm a index is used.
The indexes I built on the STAT tables.
Really… the STAT tables contain relatively little data (often one row per minute per db2
subsystem) so even if you scan the whole table sometimes… not the end of the world
The new PDB tables in V5.3 for deadlock/timeout will be useful. I anticipte using this table
to capture trends.
Sample JCL for processing SMF. It was not obvious in the reference documentation on
how to build the jcl…. It was there… but not obvious (to me). Here is my example
LOAD JCL is easy… it is a simple load (no RI in my PDB) Here is my sample JCL for load.
You really need to think of a purge strategy. And then implement as regular job to
purge/maintain.
(*) I have millions of rows every day. It is lots. but not impossible.
Making a PDB variant is a valuable tool for looking at long term trends!
I built my own (as described above). Very useful to see a popular CICS txn over time… or
a distributed server activity over time.
For my ”OTHER” table, I summarized it by batch job (corrname) … including MAINPACK
would have helped break out the batch job steps. in hindisht, that wouldd have been a
good idea...
After some years of experience… The grouping fields could be refined to be more
general… but the above was a good start. In hindishgt, if I built them new again… they
would be slightly different if I built them new today
The field names are all based upon the source ACCT_GENERAL column names. I do not
change the names to make it more obvious.. It is best to use what IBM provided for later
reference and others!
My only new field name is ACTIVITY_LOCAL_DT which identifies the “date” for all the
summarized GENERAL records.
And DB2PMF_ACCT_GENERAL_CNT is at the end of my tables… to tell me how many
source GENERAL records when into this BYDAY summary.
>> for CICS and DRDA then this CNT will be high… for BATCH it might be one!
IBM PDB table column descriptions. You can assume you know what is the meaning of the
field names… but sometimes it is good to check the reference document from IBM.
The qualtiy of these data dictionary tables could be debated. But it does exist. Does
anyone else really load these data into the tables? It is also debatable if it is easier to use
these data dictionary tables or just use the source PDS member in the SAMP libraries…
whatever works for you!
I hope that IBM DB2PM people have regret for creating a DB2 table with a field called
“TIMESTAMP”. In hindsight, that is not a good name.
REQ_LOCATION is the same as the CLIENT_WSNAME if you connect directly to DB2 for
z/OS - skip the DB2 Connect server
Now the magic question! How to use the PDB? What to do with all this wonderful data you
have now collected?
Remember… if you don’t use it then why do you bother building it? Do something!
DB2 trace output is powerful information… it is now relatively easy to look at now that it is in
the PDB!
Starting with the STAT_GENERAL… what is interesting? Lots is interesting! 741 columns
of data per interval (one minute)
Example 1 looks at cpu by db2 address spaces by day…
Example 2 looks at locks and timeouts by day
ACCT_GENERAL is the key accounting application trace output table.
Again… lots of columns or data for every accounting event
Be careful of TIMESTAMP (did I already say that the column name of TIMESTAMP is
disappointing? Poor name. anyways)
CORRNAME to find a specific job (at least one accounting event per job step! Therefore
possible for a few rows for the same job)
Lots of other great columsn (ziip… deadlocks, timeouts… class1, class2, class3)
Automate a daily query to look at recently loaded data. Send email if the query produces a
“interesting” result! (any exception)
ACCT_PROGRAM
Really about package, not program. It bothered me at first. But that is ok now. I have
accepted the wrong name.
Interesting columns… CLASS7, CLASS8 , SQL_STMTS_ISSUED (total sql statements!
Not broken down)
(sql counts by sql statement type are only populated if you have appropriate trace turned on
… I think acct class(10)) … I assume it is a bit expensive…. But if it is important then gather
it
My favorite ACCT_GENERAL % BYDAY tables.
This is my attempt to extend the supplied PDB tables into something I use for long term
trends
Here are some examples of how I use my BYDAY tables…
Dyanmic sqt statement cache tables are new to my PDB.
But here are examples of some use
Who was in the cache a long time? Perhaps the query could be refined to sort by cpu… or
exec count? Send a alert in some cases
Who was executed the most? Why executed the most? How long was it in the cache?
Which CICS transactions (from my BYDAY) uses lots of daily cpu?
Again, this could be refined to send a email/alert if necessary… when something odd
shows up!
In my BYDAY tables I now have AVG_cpu and MAX_cpu columns at the end of my table..
This is good to look for widely varying performance by day… it helps you learn about the
apps
I think a analytics accelerator would be a very interesting tool to use with the PDB. The
PDB doesn’t have to be too HUGE. So if you can load it into the analytics accelerator then
you can query whatever way you want! No index required
And would IBM Watson be helpful? Interesting idea here…
IBM Data Studio. Really… it is the best thing since sliced bread
Many places exist to find more information on PDB
As a bit of bonus information… here are my thoughts about how to send automated emails
from data in the PDB.
If someone really wants to see my jcl to send emails then I can share a copy of the jcl… it is
basic and non-proprietary.
Honestly… I would appreciate feedback! This is my first presentation! (second time
presenting it) I would appreciate your feedback!
Do you use a PDB today? If yes then I would love to hear from you and hear about how
you use it.
If no, then I would like to hear if my presentation is inspiring you to consider such a
repository? Do you see value in it?
Speaker BIO: Brian Laube has been a DB2 for z/OS application DBA for 18 years
(15+ years with Manulife Financial and 3 years with Bell Canada International (now
part of CGI))
As a application DBA, my primary area of interest is DB2 application performance
and understanding what is going on inside the application and finding ways to make
it more efficient.
39