Eerder vandaag werkte ik met een ontwikkelaar aan een query die slecht presteerde. Deze query was groot en complex, en aanvankelijk leek het een ontmoedigende inspanning om erachter te komen waar het prestatieprobleem ligt. Met Explain Plan kunnen we soms de kosten gebruiken om het prestatiepijnpunt van een grote, complexe query te verkleinen.
Als we naar een Explain Plan van deze zoekopdracht kijken, kunnen we zien dat de totale kosten behoorlijk hoog zijn.
Als we naar de details kijken, kunnen we zien dat de FULL-tabelscan (FTS) op de DETAIL_RECORD-tabel hoge kosten heeft van 51018. Merk op hoe de hoge kosten van de FTS zich in het plan verspreiden. Alle bewerkingen boven deze FTS hebben hoge kosten vanwege de hoge kosten van deze toegang tot één tafel. Toegang krijgen tot de CIMS_POLICIES_TO_PROCESS-tabel kost relatief weinig, maar de HASH JOIN-bewerking levert alleen hoge kosten op vanwege de hoge kosten om toegang te krijgen tot de DETAIL_RECORD-tabel.
De totale kosten zijn slechts iets meer dan de kosten om toegang te krijgen tot deze tabel. Het is duidelijk dat de FTS in deze tabel de grootste bijdrage levert aan het pijnpunt van deze query die wordt geanalyseerd.
Door op deze manier naar de Explain Plan-kosten te kijken, konden we ons heel snel concentreren op het ene gebied van een zeer complexe query dat de meeste prestatieproblemen veroorzaakt. Zonder de kostenanalyse die hier is uitgevoerd, zou het veel werk zijn geweest om te bepalen welk deel van de onderstaande zoekopdracht het probleem veroorzaakt.