| Subject | Re: [IBO] IBObject SavePoint method |
|---|---|
| Author | Helen Borrie |
| Post date | 2005-09-07T02:05:38Z |
At 12:39 AM 7/09/2005 +0000, you wrote:
system. However, sweeping frees up the space that was occupied by the
garbage (old record versions) and the database engine will then re-use that
space.
database file after a restore is the best indication of the "real" size of
your database. The difference in size between the old and the new database
gives you an approximate figure for the amount of space that is either
"spare" (free, and waiting for new record versions) or occupied by
garbage. When we see severe differences like yours, we know that the
application code is causing problems for the database.
IBOAdmin components of Lorenzo Mengoni (www.mengoni.it) are made for use
with IBO and they work well. The TIBOValidationService component can be
used to set up a sweep programmatically.
However, service components do NOT work with InterBase 5.x and below.
prevent these old records from being cleaned up.
application code (never performing hard commits) that prevents this garbage
from becoming "uninteresting".
rollbacks and commits are handled, if record versions are in fact stored.
Helen
>Hi there,Yes. InterBase and Firebird never give back disk space to the operating
>
>SavePoint method does commit retaining, and I believe the old records
>created from SavePoint were prevented garbage collection, and so we
>are experiencing database size ballooning from our Delphi software.
>The worst case we had is from 23MB to 4GB in a few weeks time. Through
>IBConsole, we did the following to this ballooned database:
>
>1) a database sweep, but the database file size stays the same.
system. However, sweeping frees up the space that was occupied by the
garbage (old record versions) and the database engine will then re-use that
space.
>2) a database backup/restore, and the database file size was reducedRestore from a gbak file literally creates a new database. The size of the
>from 4GB to some MBs.
database file after a restore is the best indication of the "real" size of
your database. The difference in size between the old and the new database
gives you an approximate figure for the amount of space that is either
"spare" (free, and waiting for new record versions) or occupied by
garbage. When we see severe differences like yours, we know that the
application code is causing problems for the database.
>My questions are:This is a question of application design, not database design.
>
>i) We know a proper database design will be using transaction with
>explicit commit.
>However, apart from re-design the software, and/orIBObjects itself does not have any service components. However, the
>using IBConsole tools, does IBObject provides a way to garbage
>collect the old records created from SavePoint?
IBOAdmin components of Lorenzo Mengoni (www.mengoni.it) are made for use
with IBO and they work well. The TIBOValidationService component can be
used to set up a sweep programmatically.
However, service components do NOT work with InterBase 5.x and below.
>Are these old records remain interesting in the database?Yes.
>ii) Did the Sweep process clean up the old records that were preventedYes; as long as there are no transactions active in the system that will
>garbage collection from Savepoint.
prevent these old records from being cleaned up.
>In the Help document, it statesNot quite. Sweep cannot garbage-collect "interesting" garbage. It is your
>that the Sweep process guarantees all records that are garbage
>collected, including those that were rolled back.
application code (never performing hard commits) that prevents this garbage
from becoming "uninteresting".
>Are there any differences on old records created from Savepoint and Rollback?There are differences between the way the obsolete record versions from
rollbacks and commits are handled, if record versions are in fact stored.
Helen