Tidligere i dag arbejdede jeg med en udvikler på en forespørgsel, der havde dårlig ydeevne. Denne forespørgsel var stor og kompleks, og i starten lignede det en skræmmende indsats for at finde ud af, hvor ydeevneproblemet ligger. Med Explain Plan kan vi nogle gange bruge omkostningerne til at indsnævre ydeevnesmertepunktet for en stor, kompleks forespørgsel.
Når vi ser på en forklaringsplan for denne forespørgsel, kan vi se, at dens samlede omkostninger er ret høje.
Når vi ser på detaljerne, kan vi se, at FULL table scan (FTS) på DETAIL_RECORD tabellen har en høj pris på 51018. Læg mærke til, hvordan de høje omkostninger ved FTS udbreder planen. Alle operationer over denne FTS har høje omkostninger på grund af de høje omkostninger ved denne enkeltbordsadgang. Adgang til CIMS_POLICIES_TO_PROCESS-tabellen har en relativt lav pris, men HASH JOIN-operationen modtager kun sine høje omkostninger på grund af de høje omkostninger for at få adgang til tabellen DETAIL_RECORD.
De samlede omkostninger er kun lidt mere end prisen for at få adgang til denne tabel. Det er klart, at FTS på denne tabel er den største bidragyder til smertepunktet for denne forespørgsel, der analyseres.
Ved at se på Explain Plan-omkostningerne på denne måde, var vi i stand til meget hurtigt at fokusere på det ene område af en meget kompleks forespørgsel, der forårsager den største ydelse. Uden omkostningsanalysen, der er udført her, ville det have været meget arbejde at bestemme, hvilken del af forespørgslen nedenfor, der forårsager problemet.