DB2 Runstats and Reorgs
DB2 Runstats and Reorgs
DB2 provide multiple tools and utilities for the maintenance, with these tools and utilities, it's more convenient for DBA to manage the DB2 database.
1. runstats and reorgs
runstats
is for collecting indexes and tables statistics information which to enable the DB2 optimizer to generate efficient access plan.reorgs
is for reorganizing tables and indexes.
1.1 runstats
Collect table and indexes information, including data distribution information:
1
|
db2 runstats on table db2inst1.employee on all columns with distribution and detailed indexes all
|
Collect indexes statistics information:
1
|
db2 runstats on table db2inst1.employee for indexes all
|
Collect table and indexes statistics information:
1
|
db2 runstats on table db2inst1.employee and detailed indexes all
|
Collect table statistics information with histogram distribution of column empid and empname, and give the table with read access:
1
|
db2 runstats on table db2inst1.employee with distribution on columns ( empid, empname ) allow read access
|
Verify if the tables have statistics or not:
1
|
[db2inst1@db2srv db2backup]$ db2 "select char(tabname,10) as tabname, stats_time from syscat.tables where tabname='EMPLOYEE'"
|
Scripts for generate the runstats:
1
|
#!/bin/bash
|
1.2 reorgs and reorgchk
Use reorgchk to determine if a table/index need to be reorged or not.
1
|
db2 reorgchk on table db2inst1.employee
|
if the column of reorgchk output F1~F3 marked as "", it means the tables need to be reorged, if the F4~F8 columns marked as "", it means the indexes need to be reorged
There have two different ways to reorgs, for 24*7 mission critical database, recommend the in-place reorgs, but it will generate lots of logs, and it can be terminated at any time; another way is called classic reorgs, with more fast and indexes will be built in more perfect order.
In-place | Classic | |
---|---|---|
Advantages | Allow applications access during reorgs | Fastest |
Can be paused and resumed | Index built in perfect order | |
Disadvantage | Imperfect indexes reorganization | Large space required |
Longer time to complete | Limited table access | |
Required more logs space | All or nothing process |
- Classic reorgs
The offline reorgs phases: 1. Sort, 2. Build, 3. Replace or copy, 4. Index rebuild
Specify temporary tablespace
1
|
db2 reorg table db2inst1.employee use TEMPSPACE1
|
Use the original tablespace which the table reside in
1
|
db2 reorg table db2inst1.employee
|
- In-place reorgs
1
|
db2 reorg table db2inst1.employee index i1 inplace allow write access
|
Monitoring the reorgs
1
|
[db2inst1@db2srv db2backup]$ db2 get snapshot for tables on testdb |grep -i employee -A 25
|
EOF