FireBird: povecava se fajl baze posle izvrsenja procedure

Kako sto sam nekad negde opisao system multi generational arhitekture (MGA) Firebirda, koji funkcionira na principu da svaka transakcija vidi svoju kopiju recorda koji zakljucava. Znaci jedan record moze postojati u nekolku verzija koje postoje u zavisnosti transakcija koje su ga zakljucale.

Primer ako to isto uradis sa SQL serverom recimo (koji uzput nema MGA vec koristi transaction log file - TLF) fajl baze ce biti iste velicine ali zatoa ce se transaction log falj povecati.

Znaci posto FB nema TLF vec MGA arhitekturu, transakcija ne uvek moze posle svojeg kraja obrisati verzije zakljucenih recorda, posto uzput i druga transakcija cuva verzije istih recorda. Tako da ponekad se desava kod FB-a da postoje vise verzije istog recorda, koje postoje u bazi ali se ne vide.

Za da se obrisu mrtvi recordi iz transakcija treba se izvrsiti Sweep (tako je nazvano pozivanje internog Firebird-ovog garbage kolektora). Znaci svaka baza ima svoj sweep interval koji oznacava kada treba da se pozove interni garbage kolektor da pokupi mrtve verzije recorda.

U principu GC skoro uvek pokupi mrtve verzije recorda, ali ponekad se desava da tranakcije vise kao ne-komitirani i onda GC ne moze da pokupi mrtve verzije recorda. Zato moja preporuka je da zaboravis AutoCommit transakcije i da sve sto ti treba postavis u transakciji u kojoj ces na pocetku pozvati Begin i na kraju Commit.

Pored toga mozes izvrsiti manuelni sweep, recimo u scheduleru postavis da jednom dnevno u 00:00 sati da se uradi manuelni sweep.

A recimo FB je alocirao odredjeni prostor za verzije recorda, i kada GC pokupi mrtve recorde onda prostor stoji na raspolaganju DB servera ali fajl se ipak ne smanjuje. Ne trebase se uopste zamarati sa velicine fajla jer to imas kad radis sa kojom bilom bazom. Samo se potrudi da sta god uradis imas na kraju hard commit, za da moze GC da pokupi sve sto je mrtvo.

Potpis

People who think they know everything tend to irritate those of us who do.