You are on page 1of 52

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

2

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

4

Two methods for gathering statistics in DB2
Real Time Statistics (RTS) is the first step in IBM’s 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

5

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

RTS (pictorial view) DML REORG DELETE Utilities COPY RUNSTATS INSERT RECOVER UPDATE REBUILD INDEX LOAD DB2 DB-Services (xxxDBM1) Tablespacestats ab Indexspacestats 7 .

The newest information and details can always be found in the 'DB2 V8 Administration Guide: Appendix G 'Real-time statistics tables' ab 8 .g.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. BP49) Detailed information will be provided in the next foils.SYSINDEXPACESTATS' belonging to DB=DSNRTSDB and TS=DSNRTSTS (in a dedicated bufferpool. e.SYSTABLESPACESTATS' and 'SYSIBM.

COPY or RUNSTATS and can eliminate unnecessary utility runs and thus application downtime RTS are NOT a replacement for RUNSTATS ab 9 .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.

----------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 database TYPE -------------------Database Tablespace Table Index Table Index QUALIFIER NAME -----------------.

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) INTEGER EXTERNAL( 9) TIMESTAMP EXTERNAL FLOAT EXTERNAL(22) INTEGER EXTERNAL(14) INTEGER EXTERNAL(14) INTEGER EXTERNAL(9) TIMESTAMP EXTERNAL TIMESTAMP EXTERNAL INTEGER EXTERNAL(14) INTEGER EXTERNAL(14) INTEGER EXTERNAL(14) INTEGER EXTERNAL( 4) INTEGER EXTERNAL(14) INTEGER EXTERNAL(14) INTEGER EXTERNAL(14) INTEGER EXTERNAL(14) TIMESTAMP EXTERNAL INTEGER EXTERNAL(14) INTEGER EXTERNAL(14) INTEGER EXTERNAL(14) INTEGER EXTERNAL(14) TIMESTAMP EXTERNAL INTEGER EXTERNAL(14) INTEGER EXTERNAL(14) CHAR (6) TIMESTAMP EXTERNAL 11 .The RTS Tables … 1.

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(14) INTEGER EXTERNAL(14) INTEGER EXTERNAL(9) TIMESTAMP EXTERNAL TIMESTAMP EXTERNAL TIMESTAMP EXTERNAL INTEGER EXTERNAL(14) INTEGER EXTERNAL(14) INTEGER EXTERNAL(14) INTEGER EXTERNAL(14) INTEGER EXTERNAL(14) INTEGER EXTERNAL(14) INTEGER EXTERNAL(14) INTEGER EXTERNAL(14) TIMESTAMP EXTERNAL INTEGER EXTERNAL(14) INTEGER EXTERNAL(14) INTEGER EXTERNAL(14) TIMESTAMP EXTERNAL INTEGER EXTERNAL(14) INTEGER EXTERNAL(14) CHAR (6) TIMESTAMP EXTERNAL 12 .The RTS Tables … 2. SYSIBM.

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. COPY. The default is every 30 minutes During REORG. DB2 first externalizes all RTS values from memory into the RTS tables before stopping the database When -STOP DB2 MODE(QUIESCE) is issued. REBUILD INDEX. they are lost when DB2 comes down !) As specified by the dsnzparm STATSINT value. RECOVER. (Caution: if -STOP MODE(FORCE) no RTS values are externalized. RUNSTATS and LOAD utility operations DB2 externalizes the appropriate RTS values impacted by running that utility ab 20 . DB2 first externalizes all RTS values. DB2 externalizes Real Time Statistics to the tables at the following times: When the RTS database is stopped.

NOTE: If DB2 utilities from a third party vendor other than IBM are used. GRECP or LPL) in a data sharing environment To fix RTS statistics that are inaccurate: Run a REORG. 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.Are RTS always accurate ? In certain situations. or COPY on the objects for which that stats are suspect. RUNSTATS. such as RECOVER pending (RECP) A DB2 subsystem failure A notify failure (e.g. 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). the RTS values may not be 100% accurate. ab 21 .

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. NAME.What can be get out from the RTS-tables ? (1/9) How to check for activity ? Member 'RTS01' in 'SYS3. PARTITION. UPDATESTATSTIME FROM SYSIBM. 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 .SQL': SELECT DBNAME.KEYTOOLS.TABLESPACESTATS WHERE (JULIAN_DAY(CURRENT DATE) .

or capture statistics. REORG.KEYTOOLS. similar caveats apply to COPY and REORG when data does not change. For example. NAME. SPACE.TABLESPACESTATS WHERE DBNAME = 'db-name' ORDER BY DBNAME. or run RUNSTATS. ab 23 . If the date is sufficiently old. reorganize. PARTITION. number of extents. REORG.SQL': SELECT DBNAME. space used. STATSLASTTIME. UPDATESTATSTIME. and when the COPY. EXTENTS. REORGLASTTIME.Keep in mind though. NAME. . COPYLASTTIME FROM SYSIBM. reorganize the table space. active pages.What can be get out from the RTS-tables ? (2/9) How to obtain a basic tablespace information ? Member 'RTS02' in 'SYS3. and RUNSTATS were run. 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. that the span of time between utility runs is not the only indicator for when to copy. consider further investigating whether you should take an image copy. RUNSTATS may need to be run only once on static data. LOAD REPLACE. TOTALROWS.Pay particular attention to the timestamps indicating the last time that COPY. NACTIVE. and RUNSTATS were last run Notes: . LOADRLASTTIME.

extents. and DELETEs since the last REORG or LOAD REPLACE. REORGDELETES. number of INSERTs. REORGFARINDREF FROM SYSIBM. SPACE. 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 . PARTITION. REORGUNCLUSTINS. REORGNEARINDREF. REORGDISORGLOB. number of unclustered INSERTs. REORGUPDATES.KEYTOOLS. REORGLASTTIME.What can be get out from the RTS-tables ? (3/9) When to reorganize a tablespace (method 1)? Member 'RTS03' in 'SYS3. number of disorganized LOBs. REORGINSERTS+REORGDELETES+REORGUPDATES AS TOTAL_CHANGES. UPDATEs. PARTITION Helps us to determine when to reorganize a table space include: space allocated.TABLESPACESTATS WHERE DBNAME = 'db-name' ORDER BY DBNAME. REORGINSERTS. REORGMASSDELETE.SQL': SELECT DBNAME. NAME. EXTENTS. NAME.

NAME. PARTITION ab 25 . 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.SQL': SELECT DBNAME. NAME. SPACE. For example. PARTITION. After running the following query we have a list of tablespaces meeting our criteria for reorganization Member 'RTS04' in 'SYS3. EXTENTS FROM SYSIBM.KEYTOOLS.TABLESPACESTATS WHERE (((REORGNEARINDREF + REORGFARINDREF) *100)/TOTALROWS) > 10 AND DBNAME = 'db-name' ORDER BY DBNAME.What can be get out from the RTS-tables ? (3/9) 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.

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 .What can be get out from the RTS-tables ? (4/9) How to examine the impact of a program ? We can use the TOTALROWS column of SYSIBM.

and DELETEs since the last RUNSTATS execution There are also statistics to help in determining when RUNSTATS should be executed ab 27 .KEYTOOLS. STATSUPDATES.TABLESPACESTATS WHERE DBNAME = 'db-name' ORDER BY DBNAME. STATSMASSDELETE FROM SYSIBM. STATSINSERTS. STATSINSERTS+STATSDELETES+STATSUPDATES AS TOTAL_CHANGES. NAME. PARTITION. STATSDELETES. STATSLASTTIME. PARTITION The above query shows the number of INSERTs.What can be get out from the RTS-tables ? (5/9) When to 'RUNSTATS' a tablespace ? Member 'RTS05' in 'SYS3.SQL': SELECT DBNAME. UPDATEs. NAME.

NAME. COPYUPDATELRSN. NAME.What can be get out from the RTS-tables ? (6/9) When to 'IMAGE-COPY' a tablespace ? Member 'RTS06' in 'SYS3. PARTITION Basically. as the number of distinct updated pages and changes since the last COPY execution increase. 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 . COPYCHANGES. COPYUPDATEDPAGES. COPYUPDATETIME FROM SYSIBM. PARTITION. then it is time to COPY the table space.TABLESPACESTATS WHERE DBNAME = 'db-name' ORDER BY DBNAME. COPYLASTTIME.SQL': SELECT DBNAME. 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.KEYTOOLS.

KEYTOOLS. STATSLASTTIME.What can be get out from the RTS-tables ? (7/9) How to obtain a basic Index-space information ? Member 'RTS07' in 'SYS3. number of extents. 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. space used. TOTALENTRIES. NACTIVE. COPYLASTTIME FROM SYSIBM. REBUILDLASTTIME. SPACE. LOAD REPLACE. NLEVELS. UPDATESTATSTIME. LOADRLASTTIME. EXTENTS. and when the COPY.SQL': SELECT DBNAME.INDEXSPACESTATS WHERE DBNAME = 'db-name' ORDER BY DBNAME. PARTITION. REORGLASTTIME. REORG. active pages. and RUNSTATS were last run ab 29 . INDEXSPACE. INDEXSPACE.

Pay particular attention to the REORGAPPENDINSERT column.INDEXSPACESTATS WHERE DBNAME = 'db-name' ORDER BY DBNAME. REORGINSERTS.What can be get out from the RTS-tables ? (8/9) When to reorganize an index-space ? Member 'RTS08' in 'SYS3. NLEVELS. NACTIVE. ab 30 . as well as statistics showing the number of INSERTs and DELETEs since the last REORG or REBUILD We get both real and pseudo DELETEs. REORGMASSDELETE. REORGAPPENDINSERT. REORGDELETES. REORGNUMLEVELS. If this column consistently grows. 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. LOADRLASTTIME. SPACE. EXTENTS. PARTITION.SQL': SELECT DBNAME. 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.KEYTOOLS. REORGLEAFFAR FROM SYSIBM. REORG or LOAD REPLACE occurred. 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. TOTALENTRIES. REBUILDLASTTIME. REBUILD INDEX. INDEXSPACE. you have identified an object where data is inserted using an ascending key sequence. INDEXSPACE. PARTITION There are index space statistics that can be used to determine when to reorganize indexes These statistics include the last time REBUILD. or LOAD REPLACE NOTE : These statistics should be examined after running jobs or processes that cause heavy data modification. REORGLEAFNEAR. REORGLASTTIME. REORGPSEUDODELETES.

and DELETEs since the last RUNSTATS execution ab 31 . STATSMASSDELETE FROM SYSIBM. INDEXSPACE.KEYTOOLS. UPDATEs. STATSINSERTS. STATSDELETES.SQL': SELECT DBNAME. PARTITION. PARTITION 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. STATSLASTTIME. INDEXSPACE.What can be get out from the RTS-tables ? (9/9) When to 'RUNSTATS' an index-space ? Member 'RTS09' in 'SYS3.INDEXSPACESTATS WHERE DBNAME='db-name' ORDER BY DBNAME.

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.…) or via the feature SQL within CATEX as demonstrated in the 'screenshots' below…. QMF. 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. Also. or just run it without parameters to evaluates all tablespaces and index spaces in the subsystem We have to keep in mind. 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 . that if the RTS values are inaccurate. 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. the recommendations made by DSNACCOR will not be correct. take an IMAGE-COPY (FULL or INCR) or run RUNSTATS Additionally.

' to exclude. an object can be registered along with a freely definable user text This user text is printed out by DSNACCOR in a list.g. Unfortunately there are no rules or defaults for the text (e.statistics' (RUNSTATS) during the reorg-process to avoid possible access-path modification. together with the determined objects How the information should be considered depends on further processing For instance In an SAP R/3 system. the procedure described before can process an exception table Within this table. some objects from 'Inline. 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. this exception table is already used.. for instance. The newest information and details about 'DSNACCOR' can be found in the 'DB2 V8 Administration Guide: Appendix H 'DB2-supplied stored procedures' ab 39 . 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.DSNACCOR: The RTS Stored Procedure (2/2) The DSNACCOR exception table: Optionally.

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 .

This feature is named 'House-Keeping Recommendations' (HKR) and demonstrated in the 'screenshots' below…. ab 41 . Tablespaces and Indexspaces.The CATEX function 'HKR' CATEX exploits the functionality of 'DSNACCOR' within the 'Administrative Functions' for Databases.

ab 42 .

ab 43 .

ab 44 .

ab 45 .

ab 46 .

. IC. 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.Optimization of the B/R processes and the Housekeeping at UBS (SSP.. BT/BTX. Inline Runstats. Rebinds and Dataset-Resizing 47 . SAP and IB) ALP. . TECH. CI.

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 s 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 .

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.

65 DB2 subsystems ab 51 . IB and WMUS) within our approx.Summary.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. 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.

com Copyright UBS-AG 2005 ab 52 .ab André Goetschy andre.goetschy@ubs.