i5 OS rocks

Hoe DB2 UDB ontworpen is, moet toch wel respect afdwingen!
Zie dit architectuurplaatje:

De Classis Query Engine (CQE) en de nieuwere SQL Query Engine (SQE).

Voor (veel) meer informatie zie: http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=/rzajq/queryoptimize.htm

Tips te over en meten is weten:
http://www.mcpressonline.com/tips-techniques/sql/techtip-processing-sql-statements.html
"The best tool for answering this question is the Detailed Database Monitor. You can initiate a database monitor collection by using the Start Database Monitor (STRDBMON) command or by using the Detailed SQL Performance Monitor in iSeries Navigator."

Nog meer leesvoer: http://www.redbooks.ibm.com/redbooks/pdfs/sg246654.pdf
En vergeet niet het systeem te "tunen":

Hoe complex de materie kan zijn, blijkt uit het gemis aan kennis van de roadrunner.
Een voorbeeld: ooit gehoord van de systeemwaarde en dito job QDBFSTCCOL.
"The system value QDBFSTCCOL controls who is allowed to create statistics in the background." Oftewel database file statistics collection.

By the way: hoe vreselijk zijn de nederlandse vertalingen van technische begrippen.
"Statistieken databasebestand verzamelen" rijmt niet en vloekt dus met het commando QDBFSTCCOL.

En ooit gelezen of gehoord, dat de pagesize van een SQL index 64k is versus 8k voor een Logical File (LF)? En wat daar de impact van kan zijn op wat kleinere machines?

Of van SPM oftwel Symmetric Multi Processing?
"Control parallel processing for queries
There are two types of parallel processing available. The first is a parallel I/O that is available at no charge. The second is DB2® UDB Symmetric Multiprocessing, a feature that you can purchase. You can turn parallel processing on and off."

Indexes, column statistics, access plans teveel om echt te bevatten.
En dan de terminologie:
"If your data is constantly changing, the Statistics Manager may need to rely on stale column statistics."

En dan zijn er nog de guru's met hun tips en trucs.
http://www.itjungle.com/guruo/guruo011102.html
"Here is the problem: Many iSeries and AS/400 shops have numerous logical files built over their physical files, so formulating an access plan can be a very expensive operation. (What? You thought it was magic?) The system must look at the access paths and determine if any of them can speed up data retrieval, and that means lots of I/O. Since formulating the plan is an I/O-intensive operation, you should avoid that process in production environments as if it was the black plague. A package file can come in handy for helping to avoid unnecessary and repetitive optimizations."

Waar deze guru's onvoldoende op wijzen, is het feit dat een aap makkelijk een trucje kan worden bijgebracht. Maar als het trucje niet goed wordt begrepen, wordt dat trucje te pas en te onpas toegepast.
Wat te denken van een SQL package dat verkeerd adviseert, omdat er inmiddels indexen extra zijn aangemaakt? Die worden dan niet gebruikt!

En wat te denken van nieuwere OS releases die weer andere eigenaardigheden kennen?
Stilstaan betekent achteruit hollen!

Jawel, het is magic!

"There are two approaches to index creation: proactive and reactive. As the name implies proactive index creation involves anticipating which columns will be most often used for selection, joining, grouping and ordering; and then building indexes over those columns. In the reactive approach, indexes are created based on optimizer feedback, query implementation plan, and system performance measurements."

Een (standaard!)applicatie bouwen is een klus, maar hem vervolgens nog laten speren is ook een klus!
En dat is zeker zo op een klant systeem dat enkel legacy kende ...
Met dus hardware die node CPU's, main storage (RAM) en DASD (schijven) mist.
Voor een dubbeltje op de eerste rij zitten, betekent in de praktijk slechte response tijden en het platform (...), de programmatuur (of nog erger de programmeur) de schuld geven.

Het leven is hard en ... duur.