För elva dagar sedan bloggade jag om hur Adaptive Dynamic Stats förbrukade resurser i mina produktions-RAC-databaser.
Efter att ha släckt den branden skulle jag undersöka några dåligt presterande frågor som rapporterats av våra QA-personal i test- och andra icke-produktionsdatabaser. Jag gjorde som vilken bra Oracle DBA som helst skulle göra. Jag samlade ett lagrat procedursamtal som duplicerade problemet. Under min session startade jag en SQL-spårning och körde den lagrade proceduren. Det tog 50 sekunder att slutföra, när det brukade ta 5 sekunder eller mindre innan jag uppgraderade från 11.2.0.4 till 12.1.0.2. Denna lagrade procedur innehåller ett antal SQL-satser och en SQL-spårning verkade vara ett logiskt ställe att börja. Jag behövde veta vilken SQL-sats i proceduren som orsakade problemen.
Jag körde SQL-spårningsfilen genom TKPROF och blev förvånad över resultatet. SQL-satserna i den lagrade proceduren verkade köras ganska snabbt. Men jag möttes av många uttalanden som liknar följande:
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 Detta är Dynamic Sampling på jobbet. När jag tittade på alla Dynamic Sampling-satser som körs i min spårningsfil, kunde jag fastställa att dessa stod för 45 sekunder av den totala körtiden! Hoppsan!
Dynamisk sampling är tänkt att hjälpa mig. Tiden som ägnas åt att få viss exempelstatistik antas vara mycket mindre än den tid som sparas genom att köra SQL-satsen med bättre statistik. Om den inte gör det kan prestanda för din SQL-sats lida, vilket var mitt fall.
Jag noterade en sak som jag tyckte var intressant var att dessa dynamiska samplingsfrågor kördes en gång för varje tabell och en gång för vart och ett av dess index. En av tabellerna som är involverade i min fråga har 7 index, så för den ena tabellen hade jag 8 dynamiska samplingsfrågor!
I mitt blogginlägg för 11 dagar sedan hade jag satt parametern optimizer_dynamic_sampling till 0, vilket hindrar dessa frågor från att köras. Jag hade ännu inte lagt in den förändringen i vår testmiljö så jag behövde göra det. Så snart jag gjorde det återgick frågeprestanda till det normala. Standardvärdet för denna parameter för min databas är 2. Ditt standardvärde kan variera beroende på värdet för inställningen optimizer_features_enable. Enligt detta blogginlägg betyder ett värde på 2 att dynamisk sampling kommer att slå in när minst en av tabellerna inte har någon statistik. Men för att vara ärlig, dynamisk sampling ger mig inga fördelar och orsakar mig bara skada. Så jag lämnar det i sin helhet tills vidare.