Subject | Re: [firebird-support] FB 2.1.1 - gstat x mon$ tables: which is correct? |
---|---|
Author | Helen Borrie |
Post date | 2008-11-11T07:43:53Z |
At 01:48 AM 11/11/2008, you wrote:
There are two other ways to do GC, when the inline methods cannot keep up. One is to perform sweeps; the other is run a backup WITHOUT the -g switch.
./heLen
>1. Now, I am loster than before... :-)so it seems ;-)
>
>2. There is no gargage collection from 04:00 through 22:00.Garbage collection goes on constantly, if it is possible. Pre-v.2, it was performed by a background "worker" thread for Superserver and by the "cooperative" method for Classic. (Cooperative means that processes often get to clean up garbage created by other processes...there is no independendent worker thread..) From v.2 onwards, for Superserver, you have a GCPolicy to set the way the GC is done. Read the notes!
There are two other ways to do GC, when the inline methods cannot keep up. One is to perform sweeps; the other is run a backup WITHOUT the -g switch.
>At midnight, a cron job does backup and restore every day.A daily restore should not be necessary. (although there are cases where badly written applications might cause a daily backup-and-restore to be the only way out of an ever-deepening hole...)
>3. No. :-) Maybe, I wish firebird .conf would have an option that after one transaction were open for a long time, i.g. 15 minutes, it would be automatically commited or rolled back...Hmmm, instead of forever bending and stretching database engine behaviour, to the detriment of performance and workflow for well-written applications, a better solution is for everyone to aim to write applications that don't permit read-write transactions to go uncommitted for indefinite periods.
>When mon$ transactions are commited???? Don't know what this question means...
./heLen