Results 1 to 6 of 6
  1. #1
    Join Date
    Mar 2004

    Unanswered: Reorged slowed performance

    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.


  2. #2
    Join Date
    Jan 2007
    Jena, Germany
    Have you run RUNSTATS after the reorg?
    Knut Stolze
    IBM DB2 Analytics Accelerator
    IBM Germany Research & Development

  3. #3
    Join Date
    Apr 2007
    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.

  4. #4
    Join Date
    Mar 2004

    re Runstats

    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

  5. #5
    Join Date
    May 2003
    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.
    M. A. Feldman
    IBM Certified DBA on DB2 for Linux, UNIX, and Windows
    IBM Certified DBA on DB2 for z/OS and OS/390

  6. #6
    Join Date
    Mar 2004

    Problem 'solved'

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts