We migrated to DB2 9 for z/OS CM on 9/19. We are 2 data sharing members in production. One particular load partition replace job increased in cost by about 25%. Syntax is
LOAD DATA LOG NO SORTKEYS 1500000
- INTO TABLE xxx PART 43 REUSE REPLACE
I'm assuming because the NPI is now being rebuilt instead of updated, is the reason for the CPU increase. Actually, I only thought that would change for online load and reorg. The CPU increase is being captured in CPU_parallel. The index build is parallelizing, just as it was before DB2 9.
A week later the CPU jumped significantly to almost 3 times the original CPU...also recorded in CPU_parallel. It seems the huge jump happens when the load runs on one data sharing member....I'm assuming because most of the application processes are on the other data sharing member. The volume has not changed that much from day to day.
1. Are my assumptions/theories correct in what I stated above?
2. Is there a way to get DB2 to not rebuild the entire NPI? This is shrlevel reference, so I don't believe there is concern about a short outage to the NPI.
3. Is there a way to keep the NPI from becoming GBP dependent during the load? (Alter to GBPCACHE none, perhaps?) Is that a bad idea?
Any help is appreciated.
Discover Financial Services
* IDUG EMEA * Vienna, Austria * 8-12 November 2010 * http://IDUG.ORG/EMEA *
* Your only source for independent, unbiased, and trusted DB2 information. *
How can you expand your staff or do succession planning in this economy?
Mentoring is a proven, economical, way to train the next generation of DB2 Users!
If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's Listserv