programmera.net -> oracledba -> normal     för utskrift      info@programmera.net

Library Cache

1. Library Cache
2. Unika SQL-satser
3. Bind-variabler
4. Konfigurera Library Cache

1. Library Cache

Minnesarean Library Cache lagrar följande:

  • Exekveringsplaner för SQL: Library cache är en plats där serverprocesserna letar efter redan parsade SQL-satser, eller lagrar parsade SQL-satser (en parsad SQL-sats kallas för en exekveringsplan "execution plan").
  • Exekveringsplaner för PL/SQL: Library cache lagrar inte bara exekveringsplaner för vanlig SQL utan också för PL/SQL, detta medför triggers, procedurer, funktioner, paket och anonyma block.
När en serverprocess tar emot en förfrågan att köra en SQL-sats från klienten så letar den först i Library Cache efter exekveringsplanen för denna SQL-sats. Först om exekveringsplanen inte hittas i Library Cache så parsar serverprocessen SQL-satsen. Fördelen med att alla serverprocesser delar på samma Library Cache är att sessioner kan utnyttja andra sessioners redan parsade SQL-satser. Om man t.ex. har 100 sessioner som alla kör samma SQL-sats så kommer SQL-satsen att parasas bara en gång, detta sparar mycket CPU.

2. Unika SQL-satser

Oracle identifierar SQL-satser i Library Cache genom att beräkna en hashnyckel utifrån SQL-strängen. Om det finns en exekveringsplan i Library Cache som mappar mot denna hashnyckel kommer den funna exekveringsplanen att utnyttjas, annars påbörjar serverprocessen en parsning av SQL-satsen. Vi tittar på några SQL-satser: 

SELECT * FROM emp WHERE empid=14;
SELECT * FROM emp WHERE empid=13;
SELECT empid FROM emp WHERE empid=13;
Eftersom dessa 3 satser inte har exakt identisk SQL kommer de generera olika hashnycklar och ses av Library Cache som unika SQL-satser. För att Library Cache ska fungera bra får det inte finnas för många unika SQL-satser. Eftersom varje unik SQL-sats kommer att parsas och exekveringsplanen lagras i Library Cache konsumerar varje unik SQL-sats en viss mängd resurser. Kostnaden för varje unik SQL-sats är:

  1. CPU och minne som går åt för att parsa SQL-satsen.
  2. CPU och minne som går åt för att administrera exekveringsplanen i Library Cache.
Ett exempel:
  • Om vi tänker oss att varje SQL-sats som anropas av klienterna är unik kommer serverprocessen alltid att misslyckas med att hitta en inkommande SQL-sats i Library Cache. Satsen måste alltså parsas och exekveringsplanen lagras sedan i cachen. Till slut kommer Library Cache till slut bli helt full och när detta sker kommer lagrade exekveringsplaner att kastas ut från cachen baserat på LRU (Least Recently Used). Denna process kallas för "aging out" och är ganska kostsam i termer av CPU. I värsta fall kommer någon DBA manuellt öka storleken på Library Cache eftersom det verkar som att storleken är för liten. Detta stjäl minne från andra delar av systemet och gör att Library Cache blir ännu långsammare (eftersom exekveringsplanerna aldig återanvänds).
Alltså: Om varje SQL-sats är unik är det bättre att ha en mycket liten Library Cache, så att man slipper den overhead som krävs för att administrera en stor mängd lagrade exekveringsplaner som aldrig används.

3. Bind-variabler

Hur kan vi då få ner antalet unika SQL-satser? Svaret är att använda Bind-variabler i SQL-satserna.

4. Konfigurera Library Cache