Baze podataka – MySQL, Oracle, PostgreSQL, MS SQL Server, Access, modelovanje podataka …

Oracle sekvence u RAC bazi

Tuesday, 09.09.2008 – Dejan

Pošto aktivno nadgledam bazu (RAC baza sa dvije instance), primijetio sam u određenim situacijama učestala “usporenja“, odnosno “wait events“, koja su se odnosila isključivo na RAC i interkonekciju između RAC instanci.

Prvo da vas smorim suhoparnom teorijom, pa ću detaljno pojasniti “problem” i dati rješenje…

Radi održavanja skalabilnosti i konzistentnosti podataka u bazi, obe instance šalju podatke jedna drugoj preko zajedničke interkonekcije (preko privatnih IP adresa), nastojeći da sadržaj u database buffer cacheu bude gotovo identičan. Zbog toga se preko interkonekcije prenose svi korišteni podaci na nivou database blokova.

E baš zbog tog učestalog prenosa podataka sa jedne instance na drugu i obrnuto, dolazi do “zagušenja”, odnosno do učestalog usporenja u radu određenih aplikacija. Najčešći “wait events” su “global cache wait events“: “gc cr request“, “gc cr block2-way“, “gc current block 2-way” i “gc buffer busy“.

Kao što napisah, ta usporenja su najuočljivija kod aplikacija, koje prilikom unosa veće količine podataka koriste sekvence za generisanje jedinstvenih ID-eva (npr. logovanje pojedinih operacija ili generisanje ID-eva za vještački/surogatni Primary Key).

Postojeće stanje
Kreirana je sekvenca za generisanje surogatnog primarnog ključa u jednoj Logging-tabeli:

CREATE SEQUENCE SEQ_APPLICATION_LOG
  START WITH 1
  MAXVALUE 9999999999999999999
  MINVALUE 1
  NOCYCLE
  NOCACHE
  ORDER;

Kreiran je BEFORE INSERT Trigger, koji za svaki red popunjava taj surogatni ID trenutnom vrijednošću, koju vraća gorenavedena sekvenca:

CREATE OR REPLACE TRIGGER TRG_APPLICATION_LOG
  before insert on TB_APPLICATIONS_LOG
  for each row
declare
  -- local variables here
begin
  SELECT SEQ_APPLICATION_LOG.NEXTVAL
  INTO :NEW.LOG_ID
  FROM DUAL;
end TRG_APPLICATION_LOG;
/

Kada se paralelno pokrenu aplikacije, koje se izvršavaju na različitim instancama i loguju pojedinačne operacije, onda dolazi do ping-pong prenosa podataka preko interkonekcije.
Znači, za svaku generisanu vrijednost iz sekvence, trenutna instanca preko interkonekcije šalje drugoj instanci obavijest, da je generisana ta i ta vrijednost, kako druga instanca ne bi generisala identičnu vrijednost i time ugrozila konzistentnost podataka.

Npr. sekvenca na prvoj instanci generiše vrijednost 2 i šalje drugoj instanci obavijest, da je trenutna vrijednost 2 (CURRVAL) i da je iduća slobodna vrijednost na raspolaganju broj 3 (NEXTVAL). I sad zamislite da se u sekundi generiše stotine takvih vrijednosti i da svaka instanca mora obavijestiti drugu o tim generisanim vrijednostima… Naravno da će doći do zagušenja i laganog usporenja…

Dakle, u čemu je konkretno problem?
Ključ problema leži u sekvenci, odnosno u njenom atributu NOCACHE. U gorenavedenoj sekvenci stoji NOCACHE, zbog čega se vrijednost generiše po potrebi, a ne unaprijed. Da se generišu unaprijed (npr. CACHE 500), onda bi svaka instanca generisala 500 vrijednosti odjednom i SAMO JEDNOM obavijestila drugu instancu o generisanim vrijednostima. Time se sprečava suvišno ping-pong obavještavanje u NOCACHE slučaju i smanjuje se broj “usporenja”, odnosno “global cache events”.

CACHE vrijednost definišite u zavisnosti od raspoložive RAM memorije. Opšta formula ne postoji, ali iz mog iskustva bih mogao empirijski napisati magičnu formulu:

CACHE broj = RAM Gigabyte * 20

Znači za nekih 16 GB RAM-a bi trebalo postaviti CACHE na 320, tj. između 300 i 400. Mi imamo 50 GB RAM-a na raspolaganju za Oracle instance, pa smo sekvence kreirali sa CACHE 1000, nakon čega se broj “gc *” usporenja drastično smanjio.

CREATE SEQUENCE SEQ_APPLICATION_LOG   
  START WITH 1   
  MAXVALUE 9999999999999999999   
  MINVALUE 1   
  NOCYCLE   
  CACHE 1000
  ORDER;