Před jedenácti dny jsem blogoval o tom, jak Adaptive Dynamic Stats spotřebovávaly zdroje v mých produkčních databázích RAC.
Po uhašení požáru jsem se pustil do zkoumání některých špatně fungujících dotazů hlášených našimi pracovníky pro kontrolu kvality v testovacích a dalších neprodukčních databázích. Udělal jsem to, co by udělal každý dobrý Oracle DBA. Shromáždil jsem volání uložené procedury, které duplikovalo problém. Ve své relaci jsem spustil trasování SQL a spustil uloženou proceduru. Dokončení trvalo 50 sekund, zatímco dříve to trvalo 5 sekund nebo méně, než jsem upgradoval z 11.2.0.4 na 12.1.0.2. Tato uložená procedura obsahuje řadu příkazů SQL a trasování SQL se zdálo jako logické místo, kde začít. Potřeboval jsem vědět, který příkaz SQL v proceduře způsobuje problémy.
Spustil jsem trasovací soubor SQL přes TKPROF a byl jsem překvapen výsledky. Zdálo se, že příkazy SQL v uložené proceduře se provádějí docela rychle. Ale uvítalo mě mnoho prohlášení podobných následujícímu:
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 Toto je dynamické vzorkování v práci. Při pohledu na všechny příkazy dynamického vzorkování prováděné v mém trasovacím souboru jsem byl schopen určit, že tyto představovaly 45 sekund celkového běhu! Jejda!
Dynamické vzorkování mi má pomoci. Čas strávený získáním některých ukázkových statistik má být mnohem menší než čas, který ušetříte provedením příkazu SQL s lepšími statistikami. Pokud tomu tak není, výkon vašeho příkazu SQL může utrpět, jako tomu bylo v mém případě.
Všiml jsem si jedné věci, kterou jsem považoval za zajímavou, že tyto dotazy dynamického vzorkování byly provedeny jednou pro každou tabulku a jednou pro každý z jejích indexů. Jedna z tabulek zapojených do mého dotazu má 7 indexů, takže pro tuto jednu tabulku jsem měl 8 dynamických vzorkovacích dotazů!
Ve svém příspěvku na blogu před 11 dny jsem nastavil parametr optimizer_dynamic_sampling na 0, což zastaví provádění těchto dotazů. Do našeho testovacího prostředí jsem tuto změnu ještě nevložil, takže jsem to musel udělat. Jakmile jsem to udělal, výkon dotazů se vrátil k normálu. Výchozí hodnota tohoto parametru pro moji databázi je 2. Vaše výchozí hodnota se může lišit v závislosti na hodnotě nastavení optimizer_features_enable. Podle tohoto blogového příspěvku hodnota 2 znamená, že dynamické vzorkování se spustí, když alespoň jedna z tabulek nemá žádné statistiky. Ale abych byl upřímný, dynamické vzorkování mi nepřináší žádné výhody a pouze mi škodí. Takže to zatím nechám celé.