For elleve dage siden bloggede jeg om, hvordan Adaptive Dynamic Stats tærede ressourcer i mine produktions-RAC-databaser.
Efter at have slukket den brand, skulle jeg undersøge nogle dårligt ydende forespørgsler, der blev rapporteret af vores QA-folk i test- og andre ikke-produktionsdatabaser. Jeg gjorde, som enhver god Oracle DBA ville gøre. Jeg samlede et opkald til lagret procedure, der kopierede problemet. I min session startede jeg en SQL-sporing og kørte den lagrede procedure. Det tog 50 sekunder at fuldføre, da det plejede at tage 5 sekunder eller mindre, før jeg opgraderede fra 11.2.0.4 til 12.1.0.2. Denne lagrede procedure indeholder en række SQL-sætninger, og en SQL-sporing virkede som et logisk sted at starte. Jeg havde brug for at vide, hvilken SQL-sætning i proceduren, der forårsagede problemerne.
Jeg kørte SQL-sporingsfilen gennem TKPROF og blev overrasket over resultaterne. SQL-sætningerne i den lagrede procedure så ud til at køre ret hurtigt. Men jeg blev mødt af mange udtalelser, der ligner følgende:
SELECT /* DS_SVC */ /*+ dynamic_sampling(0) no_sql_tune no_monitoring
optimizer_features_enable(default) no_parallel */ SUM(C1)
FROM
(SELECT /*+ qb_name("innerQuery") INDEX_FFS( "XXX"
"INDEX_NAME") */ 1 AS C1 FROM
"OWNER"."TABLE_NAME" SAMPLE BLOCK(71.048, 8) SEED(1)
"XXX") innerQuery Dette er Dynamic Sampling på arbejdet. Ved at se på alle de dynamiske prøveudsagn, der blev udført i min sporingsfil, var jeg i stand til at bestemme, at disse tegnede sig for 45 sekunder af den samlede kørselstid! Yikes!
Dynamic Sampling skal hjælpe mig. Den tid, der bruges på at få nogle eksempler på statistik, formodes at være meget mindre end den tid, der spares ved at udføre SQL-sætningen med bedre statistik. Hvis det ikke gør det, kan din SQL-sætnings ydeevne lide, som det var mit tilfælde.
Jeg bemærkede en ting, som jeg syntes var interessant, var, at disse dynamiske prøveudtagningsforespørgsler blev udført én gang for hver tabel og én gang for hvert af dens indekser. En af tabellerne involveret i min forespørgsel har 7 indekser på sig, så for den ene tabel havde jeg 8 Dynamisk Sampling-forespørgsler!
I mit blogindlæg for 11 dage siden havde jeg sat parameteren optimizer_dynamic_sampling til 0, hvilket forhindrer disse forespørgsler i at blive udført. Jeg havde endnu ikke lagt den ændring ind i vores testmiljø, så jeg var nødt til at gøre det. Så snart jeg gjorde det, vendte forespørgselsydeevnen tilbage til normal. Standardværdien af denne parameter for min database er 2. Din standardværdi kan variere afhængigt af værdien af indstillingen optimizer_features_enable. Ifølge dette blogindlæg betyder en værdi på 2, at dynamisk sampling starter, når mindst en af tabellerne ikke har nogen statistik. Men for at være ærlig, giver dynamisk sampling mig ingen fordele og forårsager mig kun skade. Så jeg vil bare lade det være i sin helhed indtil videre.