Tuning SQL areas. (Pase Calls).

Problemer med antallet af parses (og manglende anvendelse af bind variable) er ikke usædvanlige og det kan give god effekt på den generelle performance at få nedsat belastningen.

Et select statement behandles normalt i følgende rækkefølge:
PARSE
EXECUTE
WHILE more rows
  FETCH
END WHILE

Statements af typen INSERT, UPDATE, DELETE behandles normalt som nedenfor:
PARSE
EXECUTE

Jeg har andrig før set et eksempel som dit select * from mechanics.reghours hvor executions ikke bliver talt op, min fornemmelse er at du enten har fundet en fejl i Oracle eller at applikationsprogrammet har en fejl hvor der aldrig udføres en execution selvom statement passes 26 gange.

Parsning er ikke per automatik et problem, som nogle sommetider giver udtryk for. Dom dancni antyder skal et statement parses mindst een gang per connection til databasen, før det kan eksekveres. At parsningen på ofte anvendte statements så helst skal være en soft parse, der ikke genberegner eksekverings planen, men genbruger den eksekverings plan der allerede ligger i library cachen.
Der hvor parsning giver problemer er hvis der skal hard parses (dvs. beregnes eksekveringsplan) for ofte, idet hard parse taget meget længere tid end soft parse, og man holder library cache latchen under parsningen.
Hvis du vil undersøge om du har problemer med parsning, ville jeg kikke lidt på library latchen, og kikke på get/miss ratio.
For meget hard parsing opstår ofte enten ved for megen brug af litterals i statements (dvs. at statements ikke kan genbruges ret ofte) eller ved en AL for lille shared pool.

Jeg ville også begynde at kikke lidt mere overordnet på performance istedet for at dykke ned et tilfældigt sted som f. eks. parsing, idet du meget ofte kan udlede hvor tiden på systemet bliver brugt ved at kikke på event interfacet. Prøv evt. at læse Anjo Kolk's YAPP papir, det er ret interessant læsning. Du kan finde det på http://www.oraperf.com/links/get_url.php?id=54.
Du skal selvfølgelig registrere dig der. Alternativt mener jeg at det også kan findes på www.miracleas.dk et eller andet sted.

Efter at have besvaret dit spørgsmål fandt jeg det rigtige svar på http://asktom.oracle.com.

Den formodenlige grund til at executions feltet = 0 er formodenligt at statementet er "aget" ud af sql-area. Der er normalt at Oracle rydder op efter en LRU algoritme og i dette tilfælde bliver executions feltet nulstillet.