Oracle Nordic AppsDays - Skalinformation

T I P S & T R I C K S › d a t a b a s o p t i m e r i n g
Stored outlines – när det var bättre förr (del 2)
I förra numret berättade jag om när jag fick anledning för första
gången att använda mig av stored outlines. Kunden hade
en selectsats vars svarstid blev så pass mycket längre efter en
uppgradering från 9.2.0 till 10.2.0 att det orsakade stora problem
för affärsverksamheten. Det visade sig efter lite analys att
tidstjuven var att en dold parameter (_push_join_union_view2)
hade bytt default värde från false till true. Eftersom jag varken ville
sätta parametern till false (det gamla värdet som den hade i 9.2.0)
för hela instansen eller skapa en logon trigger som satte parametern
för aktuell session och det gick inte heller att ändra på select:n för
att lägga till hinten opt_param( ’_push_join_union_view2’ ’FALSE’),
så återstod bara en lösning: stored outline eller ”plan stability” som
det kallas i Oracles performance tuning manual.
Vad är stored outlines?
Stored outline eller plan stability skyddar prestandan för en applikation
så att den inte påverkas av förändringar i databasmiljön. Som
t ex, förändringar av statistiken på objekt, förändringar av parametervärden,
storleken på olika minnesstrukturer (som sort_area_size
och hash_area_size) samt tillkomsten av nya index. Om en stored
outline är skapat för att använda ett visst index och det indexet tas
bort så kommer självklart prestandan att påverkas. Så man är inte
skyddad mot att index tas bort. Hur hänger då execution plan stability
och stored outline ihop? Jo, plan stability lagrar den kompletta
exekveringsplanen i stored outlines. En stored outline är implementerad
som en grupp hintar för en specifik SQL sats. Om en stored
outline är aktiv för en SQL sats så kommer Oracle automatiskt att
utgå från dessa hintar och använda sig av de när optimeraren skapar
exekveringsplanen för den SQL satsen.
Om du använder dig av bind variabler så tänk på att det råder ett
ett-till-ett förhållande mellan en SQL sats och en stored outline.
Vilket betyder att om du använder dig av olika värden i ett villkor
så behöver du ha en stored outline per värde (eller använda dig av
bind variabler).
Sätter man parametern cursor_sharing till force eller similar (jag
rekommenderar starkt att man aldrig sätter den till similar) så hindrar
man outlines, som innehåller konstanta värden och som var
skapade med cursor_sharing satt till exact, från att användas. För
att använda outlines med cursor_sharing satt till force så måste
cursor_sharing var satt till force - samt att man satt create_stored_outlines
parametern - när man skapar outline.
Oracle använder sig av tre dictionary tabeller för att lagra informationen
om stored outlines: ol$, ol$hints och ol$nodes. Om
dessa tabeller ligger i system tablespace och man kommer att skapa
många stored outlines så är det värt att flytta dessa tabeller till
ett annat tablespace (antingen ett eget eller sysaux).
Det finns fyra publika vyer: DBA|USER_OUTLINES och
DBA|USER_OUTLINE_HINTS. I tabell 1 ser ni hur DBA vyerna är
beskrivna i referensmanualen.
Hur kan man se om en outline har använts? Så fort en outline har
använts så sätts dba_outlines.used till USED. Ligger SQL:n kvar i
library cache:n (sql arean) så kan visa den genom att köra select *
from v$sql where outline_category = ’’; Kör man
explain plan (eller något motsvarande kommando) så innehåller
plan_table.remarks; vilket visas om man sedan kör dbms_xplan för
att få se exekveringsplanen.
Jag ska nu visa hur jag gick till vägen för att knyta en viss exekve-
ringsplan till en viss stored outline. Detta kommer jag att visa på en
tabell i min databas för att inte visa avslöja någon kundinformation.
Se tabell 3.
1DBA_OUTLINES
Column Datatype Description
Name Varchar2(30) User-specified or generated name of the stored outline.
Owner Varchar2(30) Name of the user who created the outline.
Category Varchar2(30) User-definied name of the category to which the outline
belongs.
Used Varchar2(6) Indicates whether the outline has ever been used (USED)
or not (UNUSED).
Timestamp Date Timestamp of outline creation.
Version Varchar2(64) Oracle version that created the outline.
Sql_text Long SQL text of the query, including any hints that were a part
of the original statement. If bind variables are included, the
variable names are stored as SQL text, not the values that
are assigned to the variables.
Signature Raw(16) Signature uniquely identifying the outline SQL text.
Compatible Varchar2(12) Indicates whether the outline hints were compatible across
a migration (COMPATIBLE) or not (INCOMPATIBLE).
Enabled Varchar2(8) Indicates whether the outline is enabled (ENABLED) or
disabled (DISABLED).
Format Varchar2(6) Normal or local
2DBA_OUTLINE_HINTS
Column Datatype Description
Name Varchar2(30) Name of the outline.
Owner Varchar2(30) Name of the user who created the outline.
Node Number ID of the query or subquery to which the hint applies. The
top-level query is labeled 1. Subqueries are assigned
sequentially numbered labels, starting with 2.
Stage Number Outline hints can be applied at three different stages during
the compilation process. This column indicates the stage at
which the hint as applied.
Join_pos Number Position of the table in the join order. The value is 0 for all
hints except access method hints, which identify a table to
which this hint was applied.
Hint Varchar2(512) Text of the hint.
3Skapa
outline och bytt dess exekveringsplan mot den vi önskar
Först måste jag hitta SQL:ns hash_value och child_number:
SELECT hash_value hv, child_number cno, executions x, outline_category,
parsing_schema_name psn
FROM v$sql
WHERE sql_text = ’SELECT * FROM OBJECTS WHERE OBJECT_NAME = :B1’;
HV CNO X OUTLINE_CATEGORY PSN
1761605448 0 1 JOCKE
Sedan skapar jag en outline för original SQLen. Detta gör jag för att jag behöver fånga dess
signatur m m.
ALTER SESSION SET create_stored_outlines = ’NATTBATCH’;
EXECUTE dbms_outln.create_outline( 1761605448, 0, ’NATTBATCH’ )
ALTER SESSION SET create_stored_outlines = FALSE;
Nu har jag en stored outline med ett systemgenererat namn och som ligger i kategorin
nattbatch. Så nu skapar jag en stored outline för en SQL som genererar den exekveringsplan
som jag vill ha. I mitt fall så kunde jag inte lösenordet till användaren JOCKE men eftersom jag
körde som SYS så satte jag om aktuellt schema. Denna outline ger jag ett vettigt namn som jag
själv hittar på men kategorin sätter jag till TEMP (lägg den inte i samma kategori som original
SQLen).
ALTER SESSION SET current_schema = jocke;
CREATE OR REPLACE PUBLIC OUTLINE get_object FOR CATEGORY temp ON
SELECT /*+ OPT_PARAM( ’_push_join_union_view2’ ’FALSE’ ) */ *
FROM objects WHERE object_name = :B1;
ALTER SESSION SET current_schema = sys;
SELECT hintcount, ol_name, category, signature FROM outln.ol$
WHERE category IN( ’NATTBATCH’, ’TEMP’ );
Hintcount
8 SYS_OUTLI-
NE_09021600210254602
Ol_name Category Signature
NATTBATCH 924FD0857B3C2A07B98A-
3E4D6FD50409
9 GET_OBJECT TEMP 241F818600BC6A6D9442AC
9F0C6391C3
Hur ser det ut i OL$HINTS tabellen:
SELECT ol_name, COUNT( * ) FROM outln.ol$hints GROUP BY ol_name;
OL_NAME COUNT(*)
SYS_OUTLINE_09021600210254602 8
GET_OBJECT 9
Nu har SYS_OUTLINE_nnn den signatur som applikationen använder sig av men fel
exekveringsplan och GET_OBJECT har rätt exekveringsplan men en signatur som gör så att
applikationen aldrig kommer att välja den. Så jag ska nu byta namn på dessa två outlines
samt sätta hintcount till 9 (eftersom önskad exekveringsplan har 9).
UPDATE outln.ol$
SET ol_name = DECODE( ol_name, ’GET_OBJECT’, ’SYS_OUTLINE_09021600210254602’,
’GET_OBJECT’ ),
hintcount = 9 -- Här sätter vi det värde som tillhör den SQL som har rätt/önskad
exekveringsplan
WHERE ol_name IN( ’GET_OBJECT’, ’SYS_OUTLINE_09021600210254602’ );
Ni kanske undrar varför jag inte använder DECODE på hintcount kolumnen? Nu blir det ju fel!
Men det är ingen fara. Eftersom den outline som vi har kvar det gamla hintcount på kommer
vi snart att ta bort. Skulle vi använda oss av DECODE på hintcount och sätta värdena i fel
ordning så blir det inte så kul. Hur ser det ut nu innan vi gör commit?
SELECT hintcount, ol_name, category, signature
FROM outln.ol$
WHERE category IN( ’NATTBATCH’, ’TEMP’ );
Hintcount Ol_name Category Signature
9 GET_OBJECT NATTBATCH 924FD0857B3C2A07B98A-
3E4D6FD50409
9 SYS_OUTLI-
NE_09021600210254602
TEMP 241F818600BC6A6D9442AC9
F0C6391C3
Nu tillhör outline GET_OBJECT kategorin NATTBATCH, har rätt signatur och nio hintar under sig
i OL$HINTS.
d a t a b a s o p t i m e r i n g › T I P S & T R I C K S
20 21
COMMIT;
Nu tar vi bort den outline som är kopplad till den gamla exekveringsplanen:
DROP PUBLIC OUTLINE SYS_OUTLINE_09021600210254602;
Vi skapar en logon trigger för alla som loggar på som JOCKE och som sätter parametern
use_stored_outlines till nattbatch. Sedan flushar vi shared pool så att all SQL måste hård
parsas och på så sätt tvinga optimeraren att skapa nya exekveringsplaner.
CREATE OR REPLACE TRIGGER jocke.after_logon_enable_ol
AFTER LOGON ON jocke.SCHEMA
BEGIN
EXECUTE IMMEDIATE ’alter session set use_stored_outlines = nattbatch’;
END;
/
ALTER SYSTEM FLUSH shared_pool;
Vi ser till att någon kör applikationen så att vi kan kolla om den problematiska SQLen hittar
vår outline.
SELECT hash_value hv, child_number cno, executions x, outline_category,
parsing_schema_name psn
FROM v$sql
WHERE sql_text = ’SELECT * FROM OBJECTS WHERE OBJECT_NAME = :B1’;
HV CNO X OUTLINE_CATEGORY PSN
1761605448 0 1 NATTBATCH JOCKE
Anledningen till att antalet exekveringar visar ett är för att när jag flushade shared pool så
försvann SQLen och all dess statistik från library cachen. När applikationen sedan parsade
och körde frågan så laddades SQLen in med sina nya exekveringsplan. Så statistiken visar att
frågan har körts en gång sedan den laddades in i librarycachen.
Jag rekommenderar för den som vill veta mer att läsa kapitel 20,
Using Plan Stability, i manualen Oracle Database Performance Tuning
Guide.
I 11g vill Oracle att man ska gå över och börja använda SQL plan
management som i sin tur skapar SQL plan baselines, som visst
ska vara mycket bättre när det gäller både prestanda och stabilitet.
Har du redan stored outlines så kan du migrera dem till SQL
plan baselines genom att köra någon av procedurerna load_plans_
from_cursor_cache eller load_plans_from_sqlset som bägge ligger
i paketet dbms_spm.
Jocke Treugut jobbar på Aircom
International med design, utveckling
och optimering av data
warehouse åt telekomföretag
runt om i världen. Han driver
också sitt egna konsultföretag
Treugut Tuning & Learning AB
som har specialiserat sig på
prestandaproblem, resursoptimering,
problemlösning, troubleshooting,
skriva effektiv SQL och PL/SQL, utbildning/coaching
av DBA:er/utvecklare, samt allt annat internt och hemligt i
Oracle. Han har varit teknisk granskare för följande böcker: Optimizing
Oracle Performance, Cary Millsap och Mastering Oracle
SQL and SQL*Plus, Lex De Haan. Han är medlem i the OakTable
Network (www.oaktable.net). Mejla gärna vad du vill läsa om i
kommande nummer till Jocke@Treugut-Tuning.com.