DB2 RTS Usage

Real Time Statistics (RTS)
Overview and Usage at UBS

ab Andr Goetschy
andre.goetschy@ubs.com
Copyright UBS-AG 2005
Contents / Topics
The DB2 for z/OS environment at UBS
Database-objects monitoring and gathering statistics in a DB2 for z/OS
environment
RTS: Overview and characteristics
What can be get out from the RTS-tables ?
Usage and exploitation of RTS at UBS
Summary, conclusion and outlook
Main sources:
'DB2 V8 Administration Guide: Appendix G 'Real-time statistics tables' by IBM, March 2004
'Using Real Time Statistics (RTS)' by Craig S. Mullins, June 2004
'Optimization of the B/R processes and the Housekeeping at UBS' by UBS-KeyTools, February 2005
ab
The DB2 for z/OS environment at UBS (Dec. 2005)

ab
Shared
Global
Z990 with z/OS 1.6

~ 70'000 MIPS
Shared
Divisions
The DB2 at
UBS
WM&BB
IB
Wealth Management
&Business Banking
Investment
Banking
80 TB of DB2
data processed
in // sysplex
environments
65 DB2 subsystems(4 SAP)
ab
APlex2
APlex3
APlex4
London
Asia
RPlex1
JPlex1
IPlex1
MPlex1
Stamford
SPlex1
QPlex1
LPlex1
GCU
Bplex1
Kplex1
WMUS
Weehawken
DPlex
EPlex
FPlex
GPlex
NPlex
UPlex(Prod.)
Local
Plexes
SSP
OPlex
Tplex
Pplex
Shared
Data
17 groupattach
members
for Prod.:
12 way
//-SYSPLEX
(with GDPS)
3
Database-objects monitoring in a DB2 for z/OS

environment
To maintain efficient production DB2-based systems:
we must periodically monitor the DB2 objects that make up those systems
DB-objects monitoring is an essential component of post-implementation
duties because:
the production environment is dynamic
we have fluctuations in business activity
changes in data access patterns
Lack of attention to administrative needs can cause a system to perform
inadequately
An effective strategy for monitoring DB2 objects in the production environment
will catch and forestall problems before they affect performance
One type of DB2 database object monitoring is to query the DB2 Catalog tables
IBM has provided a new feature of DB2 delivers Real Time Statistics
providing up-to-date information about DB2 database objects.
ab
Two methods for gathering statistics in DB2

Real Time Statistics (RTS) is the first step in IBMs grand plans to automate
parts of DB2 database administration
Introduced after the general availability of Version 7, but before Version 8
RTS provides functionality that maintains statistics about DB2 databases on
the fly, without having to run a utility program
Prior to the introduction of RTS, the only way to gather statistics about DB2
database structures was by running the RUNSTATS utility
The RUNSTATS utility collects statistical information about DB2 database
objects and stores this data in the DB2 Catalog
RTS, on the other hand, runs in the background and automatically updates
statistics in two special tables as the data in DB2 databases is modified
RUNSTATS is a 'hands-on' administrative process, RTS is 'hands-off'
ab
RUNSTATS (pictorial view)

Indexspaces
Tablespaces
RUNSTATS utility
DB2 Catalog
systables
systablespace
sysindexes
syscolumns
systablepart
sysindexpart
.
ab
RTS (pictorial view)

DML
REORG
DELETE
Utilities
COPY
RUNSTATS
INSERT
RECOVER
UPDATE
REBUILD INDEX
LOAD
DB2 DB-Services
(xxxDBM1)
Tablespacestats
ab
Indexspacestats
RTS overview and main characteristics

DB2 collects statistics in real time as soon RTS are activated
Data is externalized periodically
Default externalization is 30 minutes
The interval can be updated by modifying the system
parameter STATSINT
In a data-sharing environment each member can have its own interval
No measurable overhead for the collect/externalization
Externalization on tables 'SYSIBM.SYSTABLESPACESTATS' and
'SYSIBM.SYSINDEXPACESTATS' belonging to DB=DSNRTSDB and
TS=DSNRTSTS (in a dedicated bufferpool, e.g. BP49)
Detailed information will be provided in the next foils.
The newest information and details can always be found in the
'DB2 V8 Administration Guide: Appendix G 'Real-time statistics tables'
ab
RUNSTATS versus RTS

RUNSTATS gathers information for individual objects (TS, IX and TB)
and populates the DB2 Catalog
RUNSTATS provides information for the DB2 Optimizer
RUNSTATS influences all applications as the Optimizer determines
access paths for all SQL processing
RUNSTATS has to run as an administrative (housekeeping) utility program
RTS gather information constantly about all objects in a DB2 system
RTS populate tables created for RTS that are not used by the DB2 Optimizer
RTS are used to determine when to run a utility such as a REORG,
COPY or RUNSTATS and can eliminate unnecessary utility runs
and thus application downtime
RTS are NOT a replacement for RUNSTATS
ab
The RTS database

TYPE
-------------------Database
Tablespace
Table
Index
Table
Index
QUALIFIER
NAME
------------------ ----------DSNRTSDB
DSNRTSDB DSNRTSTS
SYSIBM
TABLESPACESTATS
SYSIBM
TABLESPACESTATS_IX
SYSIBM
INDEXSPACESTATS
SYSIBM
INDEXSPACESTATS_IX
DSNT360I +UD01 *******************************************

DSNT361I +UD01 * DISPLAY DATABASE SUMMARY
* GLOBAL
DSNT360I +UD01 ********************************************
DSNT362I +UD01 DATABASE = DSNRTSDB STATUS = RW
DBD LENGTH = 4028
DSNT397I +UD01
NAME
TYPE PART STATUS
PHYERRLO PHYERRHI CATALOG PIECE
DSNRTSTS TS
RW
INDEXSPA IX
RW
TABLESPA IX
RW
******* DISPLAY OF DATABASE DSNRTSDB ENDED
**********************
DSN9022I +UD01 DSNTDDIS 'DISPLAY DATABASE' NORMAL COMPLETION
ab
10
The RTS Tables

1. SYSIBM.TABLESPACESTATS
DBNAME
NAME
PARTITION
DBID
PSID
UPDATESTATSTIME
TOTALROWS
NACTIVE
SPACE
EXTENTS
LOADRLASTTIME
REORGLASTTIME
REORGINSERTS
REORGDELETES
REORGUPDATES
REORGUNCLUSTINS
REORGDISORGLOB
REORGMASSDELETE
REORGNEARINDREF
REORGFARINDREF
STATSLASTTIME
STATSINSERTS
STATSDELETES
STATSUPDATES
STATSMASSDELETE
COPYLASTTIME
COPYUPDATEDPAGES
COPYCHANGES
COPYUPDATELRSN
COPYUPDATETIME
ab
POSITION(00001)
POSITION(00009)
POSITION(00017)
POSITION(00026)
POSITION(00035)
POSITION(00044)
POSITION(00071)
POSITION(00094)
POSITION(00109)
POSITION(00124)
POSITION(00134)
POSITION(00161)
POSITION(00188)
POSITION(00203)
POSITION(00218)
POSITION(00233)
POSITION(00248)
POSITION(00263)
POSITION(00278)
POSITION(00293)
POSITION(00308)
POSITION(00335)
POSITION(00350)
POSITION(00365)
POSITION(00380)
POSITION(00395)
POSITION(00422)
POSITION(00437)
POSITION(00452)
POSITION(00459)
30 columns
CHAR (8)
CHAR (8)
INTEGER EXTERNAL(9)
INTEGER EXTERNAL( 9)
TIMESTAMP EXTERNAL
FLOAT EXTERNAL(22)
INTEGER EXTERNAL(14)
INTEGER EXTERNAL(9)
TIMESTAMP EXTERNAL
TIMESTAMP EXTERNAL
TIMESTAMP EXTERNAL
TIMESTAMP EXTERNAL
CHAR (6)
TIMESTAMP EXTERNAL
11
The RTS Tables

2. SYSIBM.INDEXSPACESTATS
DBNAME
INDEXSPACE
PARTITION
DBID
ISOBID
PSID
UPDATESTATSTIME
TOTALENTRIES
NLEVELS
NACTIVE
SPACE
EXTENTS
LOADRLASTTIME
REBUILDLASTTIME
REORGLASTTIME
REORGINSERTS
REORGDELETES
REORGAPPENDINSERT
REORGPSEUDODELETES
REORGMASSDELETE
REORGLEAFNEAR
REORGLEAFFAR
REORGNUMLEVELS
STATSLASTTIME
STATSINSERTS
STATSDELETES
STATSMASSDELETE
COPYLASTTIME
COPYUPDATEDPAGES
COPYCHANGES
COPYUPDATELRSN
COPYUPDATETIME
ab
POSITION(00001)
POSITION(00009)
POSITION(00017)
POSITION(00026)
POSITION(00035)
POSITION(00044)
POSITION(00053)
POSITION(00080)
POSITION(00103)
POSITION(00113)
POSITION(00128)
POSITION(00143)
POSITION(00153)
POSITION(00180)
POSITION(00207)
POSITION(00234)
POSITION(00249)
POSITION(00264)
POSITION(00279)
POSITION(00294)
POSITION(00309)
POSITION(00324)
POSITION(00339)
POSITION(00354)
POSITION(00381)
POSITION(00396)
POSITION(00411)
POSITION(00426)
POSITION(00453)
POSITION(00468)
POSITION(00483)
POSITION(00490)
32 columns
CHAR (8)
CHAR (8)
INTEGER EXTERNAL(9)
INTEGER EXTERNAL(9)
INTEGER EXTERNAL(9)
INTEGER EXTERNAL(9)
TIMESTAMP EXTERNAL
FLOAT EXTERNAL(22)
INTEGER EXTERNAL(9)
INTEGER EXTERNAL(9)
TIMESTAMP EXTERNAL
TIMESTAMP EXTERNAL
TIMESTAMP EXTERNAL
TIMESTAMP EXTERNAL
TIMESTAMP EXTERNAL
CHAR (6)
TIMESTAMP EXTERNAL
12
Description RTS tables columns

The newest description of the individual columns can be found in the
'DB2 V8 Administration Guide: Appendix G 'RTS tables'
or
'online' via CATEX as demonstrated in the following 'screenshots'
ab
13
ab
14
ab
15
ab
16
ab
17
ab
18
ab
19
When are Real Time Statistics externalized ?

DB2 begins to gather Real Time Statistics as soon as
RTS is applied (by running the proper version or maintenance level of DB2)
The RTS tables must exist in order allow DB2 to externalize the real time
statistics that it gathers
Once the RTS tables have been created and started, DB2 externalizes Real Time
Statistics to the tables at the following times:
When the RTS database is stopped, DB2 first externalizes all RTS values from
memory into the RTS tables before stopping the database
When -STOP DB2 MODE(QUIESCE) is issued, DB2 first externalizes all RTS
values. (Caution: if -STOP MODE(FORCE) no RTS values are externalized,
they are lost when DB2 comes down !)
As specified by the dsnzparm STATSINT value. The default is every 30
minutes
During REORG, REBUILD INDEX, COPY, RECOVER, RUNSTATS and LOAD
utility operations DB2 externalizes the appropriate RTS values impacted by
running that utility
ab
20
Are RTS always accurate ?

In certain situations, the RTS values may not be 100% accurate. Situations that
can cause the real time statistics to be inaccurate include:
Sometimes a restarted utility can cause the RTS values to be wrong
Utility operations that leave indexes in a restrictive state, such as RECOVER
pending (RECP)
A DB2 subsystem failure
A notify failure (e.g. GRECP or LPL) in a data sharing environment
To fix RTS statistics that are inaccurate:
Run a REORG, RUNSTATS, or COPY on the objects for which that
stats are suspect.
NOTE:
If DB2 utilities from a third party vendor other than IBM are used, we have to make
sure that those utilities work with RTS (the third party utilities should be able both to
reset the RTS values and use the RTS stats for recommending when to run utilities).
ab
21
What can be get out from the RTS-tables ? (1/9)

How to check for activity ?
Member 'RTS01' in 'SYS3.KEYTOOLS.SQL':
SELECT DBNAME, NAME, PARTITION, UPDATESTATSTIME
FROM SYSIBM.TABLESPACESTATS
WHERE (JULIAN_DAY(CURRENT DATE) - JULIAN_DAY(UPDATESTATSTIME)) <= 10
AND DBNAME = 'db-name'
To determine whether any activity has happened in the past several days
for a particular table space or index, use the UPDATESTATSTIME column
The above query is an example checking whether any activity has
occurred in the past ten (10) days for a tablespace
(you have just to supply the tablespace-name)
ab
22

How to obtain a basic tablespace information ?
SELECT DBNAME, NAME, PARTITION, TOTALROWS, NACTIVE, SPACE, EXTENTS,
UPDATESTATSTIME, STATSLASTTIME, LOADRLASTTIME, REORGLASTTIME, COPYLASTTIME
WHERE DBNAME = 'db-name'
ORDER BY DBNAME, NAME, PARTITION
The RTS tables contain some good basic information about table spaces
The above query can be run to report on the number of rows, active pages, space
used, number of extents, and when the COPY, REORG, LOAD REPLACE, and
RUNSTATS were last run
Notes:
- Pay particular attention to the timestamps indicating the last time that COPY, REORG, and
RUNSTATS were run. If the date is sufficiently old, consider further investigating whether you
should take an image copy, reorganize the table space, or run RUNSTATS.
- Keep in mind though, that the span of time between utility runs is not the only indicator for
when to copy, reorganize, or capture statistics. For example, RUNSTATS may need to be run
only once on static data; similar caveats apply to COPY and REORG when data does not
change.
ab
23

When to reorganize a tablespace (method 1)?
SELECT DBNAME, NAME, PARTITION, SPACE, EXTENTS, REORGLASTTIME, REORGINSERTS,
REORGDELETES, REORGUPDATES, REORGINSERTS+REORGDELETES+REORGUPDATES
AS TOTAL_CHANGES, REORGDISORGLOB, REORGUNCLUSTINS, REORGMASSDELETE,
REORGNEARINDREF, REORGFARINDREF
WHERE DBNAME = 'db-name' ORDER BY DBNAME, NAME, PARTITION
Helps us to determine when to reorganize a table space include: space allocated, extents, number
of INSERTs, UPDATEs, and DELETEs since the last REORG or LOAD REPLACE, number of
unclustered INSERTs, number of disorganized LOBs, and number of near and far indirect
references created since the last REORG
We may add WHERE clauses that limit the tablespaces returned to just those that exceed a
particular limit :
Specification:
WHERE EXTENTS > 20
WHERE TOT_CHANGES > 100000
WHERE REORGFARINDREF > 50
ab
Description
Table spaces having more than 20 extents
Table spaces with more than 100K changes
Table spaces with more than 50 far indirect references
24

When to reorganize a tablespace (method 2) ?
Another way to get more creative with our RTS queries is to build formulas into
them to retrieve only those table spaces that need to be reorganized. For example,
the following query will return only those table spaces having more than 10% of
their rows as near or far indirect references
We can change the percentage as we wish. After running the following query we
have a list of tablespaces meeting our criteria for reorganization
SELECT DBNAME, NAME, PARTITION, SPACE, EXTENTS
WHERE (((REORGNEARINDREF + REORGFARINDREF) *100)/TOTALROWS) > 10
AND DBNAME = 'db-name' ORDER BY DBNAME, NAME, PARTITION
ab
25

How to examine the impact of a program ?
We can use the TOTALROWS column of SYSIBM.TABLESPACESTATS
to determine how many rows were impacted by a particular program or
process
We have simply to check TOTALROWS for the table space both before
and after the process; the difference between the values is the number
of rows impacted
ab
26

When to 'RUNSTATS' a tablespace ?
SELECT DBNAME, NAME, PARTITION, STATSLASTTIME, STATSINSERTS, STATSDELETES,
STATSUPDATES, STATSINSERTS+STATSDELETES+STATSUPDATES AS TOTAL_CHANGES,
STATSMASSDELETE
The above query shows the number of INSERTs, UPDATEs, and

DELETEs since the last RUNSTATS execution
There are also statistics to help in determining when RUNSTATS
should be executed
ab
27

When to 'IMAGE-COPY' a tablespace ?
SELECT DBNAME, NAME, PARTITION, COPYLASTTIME, COPYUPDATEDPAGES, COPYCHANGES,
COPYUPDATELRSN, COPYUPDATETIME
Basically, as the number of distinct updated pages and changes since the
last COPY execution increase, the need to take an image copy increases
A good rule of thumb to follow is when the percentage of updated pages
since the last COPY is more than 25% of the active pages, then it is time to
COPY the table space. We can add the following WHERE clause to the
above query to limit the output to only these table spaces:
WHERE ((COPYUPDATEDPAGES*100) / NACTIVE) > 25
ab
28

How to obtain a basic Index-space information ?
SELECT DBNAME, INDEXSPACE, PARTITION, TOTALENTRIES, NLEVELS, NACTIVE,

SPACE, EXTENTS, UPDATESTATSTIME, LOADRLASTTIME, REBUILDLASTTIME,
REORGLASTTIME, STATSLASTTIME, COPYLASTTIME
FROM SYSIBM.INDEXSPACESTATS
ORDER BY DBNAME, INDEXSPACE, PARTITION
We have to keep in mind that there are also RTS statistics

gathered on indexes
The above query reports on the number of rows, active pages, space
used, number of extents, and when the COPY, REORG, LOAD REPLACE,
and RUNSTATS were last run
ab
29

When to reorganize an index-space ?
SELECT DBNAME, INDEXSPACE, PARTITION, REORGLASTTIME, LOADRLASTTIME,
REBUILDLASTTIME, TOTALENTRIES, NACTIVE, SPACE, EXTENTS, NLEVELS, REORGNUMLEVELS,
REORGINSERTS, REORGAPPENDINSERT, REORGDELETES, REORGPSEUDODELETES,
REORGMASSDELETE, REORGLEAFNEAR, REORGLEAFFAR
There are index space statistics that can be used to determine when to reorganize indexes
These statistics include the last time REBUILD, REORG or LOAD REPLACE occurred, as well
as statistics showing the number of INSERTs and DELETEs since the last REORG or REBUILD
We get both real and pseudo DELETEs, as well as both singleton and mass DELETE information
RTS also tracks both the number of index levels and index page split information resulting in
near and far indirect references since the last REORG, REBUILD INDEX, or LOAD REPLACE
NOTE :
These statistics should be examined after running jobs or processes that cause heavy data
modification.
Pay particular attention to the REORGAPPENDINSERT column. It contains the number of inserts into
an index since the last REORG for which the index key was higher than any existing key value. If this
column consistently grows, you have identified an object where data is inserted using an ascending
key sequence. Think about lowering the free space for such objects because the free space is wasted
space if inserts are always done in ascending key sequence.
ab
30

When to 'RUNSTATS' an index-space ?
SELECT DBNAME, INDEXSPACE, PARTITION, STATSLASTTIME, STATSINSERTS,
STATSDELETES, STATSMASSDELETE
WHERE DBNAME='db-name'
RTS provides index space statistics to help determine when to run

RUNSTATS similar to the table space statistics
The above query shows the number of INSERTs, UPDATEs, and
DELETEs since the last RUNSTATS execution
ab
31
How to run the above SQL (RTS01-RTS09) ?

You can run the above SQL (RTS01-RTS09) via 'cut and paste' with
an SQL-processor of your choice (SPUFI, QMF,)
or
via the feature SQL within CATEX as demonstrated in
the 'screenshots' below.
ab
32
ab
33
ab
34
ab
35
ab
36
ab
37
DSNACCOR: The RTS Stored Procedure (1/2)

IBM supplies a sample stored procedure called DSNACCOR that can be used
to query the RTS tables and make recommendations based on the statistics
We can use DSNACCOR to recommend when to run a REORG, take an
IMAGE-COPY (FULL or INCR) or run RUNSTATS
Additionally, DSNACCOR can report on the data set extents of table spaces and
index spaces as well as on objects in a restricted/unavailable state (however this
information about possible objects unavailability is by far not so accurate and
precise than the information provided by DB2RCF)
We can specify parameters to indicate to DSNACCOR which table spaces and

indexes to analyze, or just run it without parameters to evaluates all tablespaces and index spaces in the subsystem
We have to keep in mind, that if the RTS values are inaccurate, the recommendations made by
DSNACCOR will not be correct.
Also, DSNACCOR makes recommendations based on general formulas requiring user input about our
maintenance policies. These recommendations might not be accurate for every installation or
subsystem.
ab
38
DSNACCOR: The RTS Stored Procedure (2/2)

The DSNACCOR exception table:
Optionally, the procedure described before can process an exception table
Within this table, an object can be registered along with a freely definable
user text
This user text is printed out by DSNACCOR in a list, together with the
determined objects
How the information should be considered depends on further processing
For instance In an SAP R/3 system, this exception table is already
used. The objects that have to be excluded from the RUNSTATS utility are
defined herein
The exception table represents a unique list in which exclusions or
restrictions for the maintenance processing can be defined. Unfortunately
there are no rules or defaults for the text (e.g., the actual maintenance
restriction) that is entered together with the objects
Note: The DSNACCOR exception table is used at UBS in the 'CARES Automated Reorg.' to exclude,
for instance, some objects from 'Inline- statistics' (RUNSTATS) during the reorg-process to
avoid possible access-path modification.
The newest information and details about 'DSNACCOR' can be found in the
'DB2 V8 Administration Guide: Appendix H 'DB2-supplied stored procedures'
ab
39
Issues of RTS/DSNACCOR for the Housekeeping

at UBS (SSP and SAP)
DSNACCOR
(IBM supplied)
DB2 Catalog
RTS
Tables
Allows to optimize/automate the scheduling of Runstats/

Reorg/IC (generate only when necessary)
Allows to optimize the scheduling of Image Copy
(generate only IIC or FIC when necessary)
CARES (U006)
or
CATEX (HKR)
TS1
TS2
IX1
TS3
IX2
Reorg Runstats
Y
Y
N
N
N
Y
N
Y
N
Y
IC
FIC
IIC
N
N
FIC
Automation
(CARES and DB2ICF)
ab
40
The CATEX function 'HKR'

CATEX exploits the functionality of 'DSNACCOR' within the
'Administrative Functions' for Databases, Tablespaces and
Indexspaces.
This feature is named 'House-Keeping Recommendations' (HKR) and
demonstrated in the 'screenshots' below.
ab
41
ab
42
ab
43
ab
44
ab
45
ab
46
Optimization of the B/R processes and the Housekeeping

at UBS (SSP, SAP and IB)
ALP, BT/BTX, CI, TECH, ...
Arch
Arch
Log
Log
Monday
RTS
IIC
Tuesday
Quiesce
Runstats
RTS
IIC
Quiesce
Runstats
Merge
Merge
FIC
ab
Log
Log
Arch
Log
Log
Arch
Log
Log
Log
Log
Wednesday
Thursday
RTS
RTS
IIC
Quiesce
Runstats
Merge
FIC
Arch
IIC
Log
Log
Quiesce
Runstats
RTS
IIC
Arch
Log
Log
Saturday/Sunday
Friday
RTS
Quiesce
Runstats
FIC
FIC
Reorg
Merge
Merge
FIC
Arch
FIC
FIC
FIC:
Weekly non disruptive Full IC (dual) for all DB's per group
Log/Arch: Permanent Logging (dual) on DASD and Archive on tape
RTS/IIC: According RTS (Real time statistics) the IBM supplied stored procedure
(DSNACCOR triggers IIC's for all DB's which have been updated since last IIC )
Merge:
Mergecopy utility will merge all IIC's since last FIC to a new FIC
Quiesce: Daily QUIESCE before TEV (needed point of consistency for the DB's)
Runstats: According RTS (Real time statistics) the IBM supplied stored procedure
(DSNACCOR triggers Runstats for all DB's which need a "refresh" of the statistics)
Reorg:
According RTS (Real time statistics), CARES (Report U006 using DSNACCOR)
triggers Reorgs incl. Inline Runstats, IC, Rebinds and Dataset-Resizing
47
CARES Automated REORG (Pictural Flow)

DB2 Catalog
Alternative 1
Phase I
TS stats
IX stats
DB2ICF
Alternative 2
RTS
Tables
Runstats via RTS
Phase II
CARES (non RTS)

ICF Catalog
CARES (with RTS)

DSNACCOR
U002
R010
R011
U006
Automation:
for Groups of DB's
according set/reached thresholds
ab
TS/IX Reorgs
Inline Runstats
Inline copy
Automation:
for Groups of DB's
according DSNACCOR
recommendations
DS-Resizing
Rebinds
OPC
48
CARES Automated REORG (Technical Flow)

DB2 Catalog
Statistics Mode
Real Time
Statistics Mode
CARES Reports
CARES Report
CARES Report
CARES Report
Low CLUSTERRATIO on Index /

Table-/Indexspaces candidate
for REORG
Extract of DB2
Table-/Indexspace
datasets
(DECOLLECT)
Compression
switched on/off but
no REORG/LOAD
Extract of Real-Time
Statistics
Recommendations
(DSNACCOR)
U002
R027
U006
R010
R011
Statistics
St
ics
ist
t
a
Ext
ics
Statist
CARES
R010
Table
DB2
Catalog
CARES
R011
Table
fin
De
i ti
s
on
DB2ICF
Grouping
ab
DB-Group
ent
CARES
U002
Table
CARES
R027
Table
CARES
U006
Table
Real-Time
Statistics
Space
USERTS(N)
COMPSWIT(Y)
USERTS(Y)
CARES Automated REORG
Real-Time
Statistics
Tables
49
Summary, conclusion and outlook (1 of 2)

In General:
Real Time Statistics (and DSNACCOR) help DBA's and Monitor Programs
to identify objects for which database maintenance is needed:
Efficient use of DBA time
Improved system and application performance
Reduction of batch window constraints
Indispensable for an efficient administration of 'black-box'
DB2 subsystems like 'SAP'
RTS provide a foundation for DB2 to manage itself in the future
Possible future (in V-next) exploitation by the DB2 Query optimizer
and DB2 Utilities (!?)
ab
50
Summary, conclusion and outlook (2 of 2)

For UBS:
Real Time Statistics have been very early exploited at UBS to
to augment and enrich our DB2 object monitoring processes
to optimize our Backup/Recovery and Housekeeping processes
RTS will become a solid basis for new DB2 features to be developed like
'DB- HISTORY' or 'DB2ETRS' (Event Tracking and Reporting System for DB2)
as well as new functions for the estimation of recovery runtimes.
We will continue to take advantage of the continuously updated RTS values
to improve the administration and performance of our DB2 databases
(SSP/SAP, IB and WMUS) within our approx. 65 DB2 subsystems
ab
51
ab Andr Goetschy
andre.goetschy@ubs.com
Copyright UBS-AG 2005
ab
52

DB2 RTS Usage

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

DB2 RTS Usage

Uploaded by

Copyright:

Available Formats

Real Time Statistics (RTS)

Overview and Usage at UBS

Copyright UBS-AG 2005

The DB2 for z/OS environment at UBS (Dec. 2005)

Z990 with z/OS 1.6

Database-objects monitoring in a DB2 for z/OS

Two methods for gathering statistics in DB2

RUNSTATS (pictorial view)

RTS (pictorial view)

RTS overview and main characteristics

RUNSTATS versus RTS

The RTS database

DSNT360I +UD01 *******************************************

The RTS Tables

The RTS Tables

Description RTS tables columns

When are Real Time Statistics externalized ?

Are RTS always accurate ?

What can be get out from the RTS-tables ? (1/9)

What can be get out from the RTS-tables ? (2/9)

What can be get out from the RTS-tables ? (3/9)

What can be get out from the RTS-tables ? (3/9)

What can be get out from the RTS-tables ? (4/9)

What can be get out from the RTS-tables ? (5/9)

The above query shows the number of INSERTs, UPDATEs, and

What can be get out from the RTS-tables ? (6/9)

What can be get out from the RTS-tables ? (7/9)

SELECT DBNAME, INDEXSPACE, PARTITION, TOTALENTRIES, NLEVELS, NACTIVE,

We have to keep in mind that there are also RTS statistics

What can be get out from the RTS-tables ? (8/9)

What can be get out from the RTS-tables ? (9/9)

RTS provides index space statistics to help determine when to run

How to run the above SQL (RTS01-RTS09) ?

DSNACCOR: The RTS Stored Procedure (1/2)

We can specify parameters to indicate to DSNACCOR which table spaces and

DSNACCOR: The RTS Stored Procedure (2/2)

Issues of RTS/DSNACCOR for the Housekeeping

Allows to optimize/automate the scheduling of Runstats/

The CATEX function 'HKR'

Optimization of the B/R processes and the Housekeeping

CARES Automated REORG (Pictural Flow)

Runstats via RTS

CARES (non RTS)

CARES (with RTS)

CARES Automated REORG (Technical Flow)

Low CLUSTERRATIO on Index /

CARES Automated REORG

Summary, conclusion and outlook (1 of 2)

Summary, conclusion and outlook (2 of 2)

Copyright UBS-AG 2005

You might also like