Identifikation af ASH-sekvenskondition i RAC

I kapitel 3 i Oracle RAC Performance Tuning viste jeg, hvordan ukorrekte CACHE-værdier for sekvenser kan forårsage dårlig ydeevne i Oracle RAC. Jeg viste også, hvordan man kan se sekvensstridigheder, når man ser på en sessions ventebegivenheder.

I dag arbejdede jeg sammen med en udvikler, som var ved at lave en ny sekvens. Udvikleren havde en CACHE-værdi på 100, hvilket gjorde, at jeg til at begynde med var en for lav værdi. Jeg opdagede denne lave indstilling under kodegennemgang. Udvikleren mener, at CACHE-værdien er fin, men jeg er ikke overbevist. Vi tester dette under belastning for at se, om CACHE-værdien skal justeres.

I mellemtiden tænkte jeg "hvad nu hvis jeg gik glip af dette under kodegennemgang?" Og et opfølgende spørgsmål, "hvad nu hvis vi ikke bemærkede noget under belastningstestning?" Jeg vil gerne være i stand til at gå tilbage og bestemme, hvilke sekvenser, hvis nogen, ville være kandidater til at have en forkert CACHE-indstilling. Jeg kunne bestemt spore sessioner og analysere sporingsfilerne, men det ville være for smertefuldt. Så jeg udtænkte et script, som jeg kan køre mod Active Session History for at hjælpe med at bestemme kandidatsekvenser.

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;

Dette er ikke en perfekt videnskab på grund af arten af ​​ASH-indsamling. Sessionen, der oplever konflikten, skal fanges på det helt rigtige tidspunkt for at være i tabellen DBA_HIST_ACTIVE_SESSION_HISTORY. Men SQL-sætningen ovenfor giver mig nogle kandidater til overvejelse. Ikke alle sekvenser, der tilgås i de returnerede SQL-sætninger, skal have deres CACHE-værdier justeret. Yderligere analyse ville være nødvendig. Dette giver mig dog en liste over dem, jeg skal overveje. Og det kan hjælpe med at besvare mine indledende spørgsmål. Hvis jeg gik glip af sekvensoprettelsen under kodegennemgang, kan jeg forhåbentlig finde den senere, hvis sekvensen er et problem for applikationens ydeevne.