V kapitole 3 Oracle RAC Performance Tuning jsem ukázal, jak mohou nesprávné hodnoty CACHE pro sekvence způsobit špatný výkon v Oracle RAC. Také jsem ukázal, jak odhalit spor o sekvenci při pohledu na události čekání relace.
Dnes jsem pracoval s vývojářem, který vytvářel novou sekvenci. Vývojář měl hodnotu CACHE 100, takže jsem měl zpočátku příliš nízkou hodnotu. Toto nízké nastavení jsem zaznamenal během kontroly kódu. Vývojář si myslí, že hodnota CACHE je v pořádku, ale nejsem přesvědčen. Vyzkoušíme to při zátěži, abychom zjistili, zda je třeba upravit hodnotu CACHE.
Mezitím jsem přemýšlel:„Co když jsem to přehlédl během kontroly kódu? A navazující otázka „co kdybychom si během zátěžového testování ničeho nevšimli?“ Chci být schopen se vrátit a určit, které sekvence, pokud nějaké, by byly kandidáty na nesprávné nastavení CACHE. Určitě bych mohl sledovat relace a analyzovat sledovací soubory, ale to by bylo příliš bolestivé. Vymyslel jsem tedy skript, který mohu spustit proti Active Session History, aby pomohl určit kandidátní sekvence.
select sh.sql_id,to_char(st.sql_text),count(*) from dba_hist_active_sess_history sh join dba_hist_sqltext st on sh.sql_id=st.sql_id where st.sql_text like '%NEXTVAL%' and (event='row cache lock' or event like 'gc current block %-way') group by sh.sql_id,to_char(st.sql_text) order by count(*) desc;
Vzhledem k povaze sběru ASH to není dokonalá věda. Relace, ve které dochází k sporu, by musela být zachycena ve správný čas, aby byla v tabulce DBA_HIST_ACTIVE_SESSION_HISTORY. Ale výše uvedený příkaz SQL mi dává několik kandidátů na zvážení. Ne každá sekvence, ke které se přistupuje v vrácených příkazech SQL, musí mít upravené hodnoty CACHE. Bylo by zapotřebí další analýzy. To mi však dává seznam těch, které je třeba zvážit. A může pomoci odpovědět na mé první otázky. Pokud jsem zmeškal vytvoření sekvence během kontroly kódu, doufejme, že ji najdu později, pokud bude sekvence problémem pro výkon aplikace.