We had a REORG job run for 22 hours before we killed it. The table has 13 million rows and 2 indexes have been defined on it. By the time I got to look at the problem a db2stop had been issued and I did not get to run any snapshots. However on restarting database and on making the first connect to the database , DB2 did a crash recovery and started rebuilding the indexes. I ran application snapshot and noticed that the 'rows read' and 'rows inserted' count go up quickly (in about about 1/2hr) to 26mill and then the 'rows read' count would slow down to about a couple of hundred per sec. I let the index rebuild run for about 3 hours and the 'row count' after the initial 26 million was upto a few hundred thousand at which point I killed it. It almost appears that whatever was causing the REORG to run slow was also causing the index rebuild to run slow. We finally dropped the indexes and built them from scratch and that process finished in 1/2 hour. I'm concerned that we will have this problem next week during the next REORG. The REORG runs weekly and this is the first week after we had our H/W upgrade - we went from 6cpu to 12 cpu on an S80 box and have upped the memory to 6 gig from 2 gig. We have not yet changed DB2 parameters to take the advantage of the hardware upgrade. We are on version 6.1 EE fixpack 5. My questions are: 1. Anyone out there who may have faced similar problems ? And what did you do to fix it? 2. How do you monitor REORG or index rebuild progress? 3. Could the HW upgrade have adversely impacted REORG's performance even though we have not yet change DB2's parameters ? 4. Any suggestions as to how we can improve REORG performance Thanks, Manas. ===== To unsubscribe, send 'unsubscribe' to [EMAIL PROTECTED] For other info (and scripts), see http://people.mn.mediaone.net/scottrmcleod
