Running DB2 8.2.6 on AIX 5.3

I recently took on an assignment supporting a DB2 database which supports a Siebel application.

Siebel version is 7.5.3 I have a reorg script that carefully follows Siebel guidance on reorgs and have had great success with it at two other locations.

Quick background; entire database had NEVER been reorged in 6 years with only one table very occasionally been reorged. Siebel guidance on reorg/runstats was ignored. Volatile tables that should not be runstatted were. Reorgchk showed hundreds of tables needing reorg.

Post reorgchk shows data is now in very good condition however there has been some slowing in OLTP performance. A db2rbind was issued as part of the reorg with 143 packages being successfully rebound. A flush package cache dynamic was also issued. This was an offline reorg with no access allowed.

I am now researching possible causes for this degradation of performance..

I am looking hard at the database server resources thinking that maybe an optimized DB2 is overloading the server (Test).

Siebel is typically optimized for OLTP rather than batch so I don't think that's the problem.

Any suggestions as to why this happened and/or what I can be looking at would be appreciated.

Thanks in advance.

Gerry

Have you run RUNSTATS after the reorg?

Do you know if anybody manually updated stats previously? I've worked at clients running Siebel apps that manually updated stats to resolve specific performance issues. You would have wiped out the manually updated stats when you ran Runstats following the Reorgs. If this is the case, you'd need to reapply the manual updates.

Yes I ran a runstats table with distribution and detailed indexes all.

Yes I'm aware of the manually updated stats at certain shops. I seriously doubt that was done here. I mean not much of any type of maintenance was being done at all.

Now I have to prove a negative....that the reorg did NOT cause the slowdown

If you want DB2 to ignoare the actual runstats and use default stats (as if runstats was never run), then alter the table and set it to volatile. See the ALTER TABLE SQL statement.

After meeting with a very experience professional, it seems evident that the reorg optimized the data in db2 which is now flying faster than the system can handle. Their are bottle necks showing up in both I/O and disk usage.