[es] - FireBird: povecava se fajl baze posle izvrsenja procedure

ultraKeen
ultraKeen
Zemun

Član broj: 2396
Poruke: 289
*.verat.net.

ICQ: 36109339
Sajt: ultrakeen.blogspot.com

+1 Profil

FireBird: povecava se fajl baze posle izvrsenja procedure

^{16.12.2004. u 22:31 - pre 235 meseci}

Imam pomocnu tabelu koju koristi samo stor.procedura i koja se redovno prazni na njenom kraju.

Koji je razlog da baza sa tom pomocnom tabelom, posle izvrsenja procedure - ipak raste (fajl se fizicki povecava) ?

...i kako to povecanje anulirati?

postoji samo jedan apsolut u logickoj ravni desavanja/vremena:
SVE je RELATIVNO sem:
- osnovnih konstanti svemira
- logike
...i ove tvrdnje
*
Daniel J. Boorstin: The Discoverers, A History of Man’s Search To Known

Napredak nauke zavisice od covekove spremnosti da poveruje u neverovatno, da prekoraci granicu koju namece zdrav razum.

Odgovor na temu

Riste Pejov
Team Leader/Senior Software Developer @
Ein-Sof ltd Skopje
Skopje, Macedonia

Član broj: 128
Poruke: 571
217.16.77.*

Jabber: richie@bagra.net.mk
ICQ: 154236769
Sajt: riste.softver.org.mk

Profil

Re: FireBird: povecava se fajl baze posle izvrsenja procedure

^{17.12.2004. u 07:41 - pre 235 meseci}

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.

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

Odgovor na temu