Subject | Re: [firebird-support] Re: Oldest transaction far behind... |
---|---|
Author | Kjell Rilbe |
Post date | 2011-03-22T08:51:49Z |
karolbieniaszewski skriver:
between ANY of the gstat -h trans numbers of more than 1 when the DB is
idle. I.e. my app seems very well behaved, as it should, being built on
an OO framework that should not "make mistakes" with DB transaction
handling.
Problem is that the DB is 52 Gbyte so a sweep will take several hours,
and a gbak takes about 5-6 hours. A simple file copy (when DB is ensured
to have no connections) using fastcopy.exe at top speed, very close to
hardware limits, takes almost half an hour.
So, I avoid doing ANYTHING that's not absolutely necessary with this
database.
the server because FB seemed to hang. One of the FB processes was
running at top CPU (for one CPU core) but *NO* I/O (according to Task
Manager) for several hours... And I was unable to make new connections
to that DB (although other DB:s worked fine). The DB validated OK
afterwards but I never checked trans numbers or the need for a sweep.
As a final point, the gstat section in the Firebird PDF manual
(http://www.firebirdsql.org/pdfmanual/Firebird-gstat.pdf) says (page 7):
"Snapshot - the ID of the oldest transaction which is currently not
eligible to be garbage-collected. Any transaction with this or a higher
ID cannot, yet, have old record versions removed by a sweep, for example."
I interpreted this as saying that a sweep wouldn't help. Maybe I was
wrong, but in that case I think this document is misleading.
Kjell
--
------------------------------
Kjell Rilbe
DataDIA AB
E-post: kjell.rilbe@...
Telefon: 08-761 06 55
Mobil: 0733-44 24 64
[Non-text portions of this message have been removed]
> --- In firebird-support@yahoogroups.comYes.
> <mailto:firebird-support%40yahoogroups.com>, Kjell Rilbe
> <kjell.rilbe@...> wrote:
> >
> > Den 2011-03-22 07:47 skrev karolbieniaszewski s�h�r:
> > > you have long running transaction
> > > and i see ODS11.1 then i suppose that this is FB2.x series.
> > >
> > > If yes then check
> > > SELECT * FROM MON$TRANSACTION
> > > to check what transaction stops garbage collector - you see date and
> > > time when transaction start
> > > and follow attachment id to see what process on what computer it is
> >
> > Thanks Karol, I'll check! but I stress that this gstat -h was executed
> > with NO OTHER ATTACHMENTS to the database.
> >
> > Yes, this is FB 2.1.x.
>
> What is your "Sweep interval" setting for database?
> Is it 0?
> If yes then you set that you mannually run sweep process if not thenI usually never sweep, because up until now I've never seen a diff
> what is value?
between ANY of the gstat -h trans numbers of more than 1 when the DB is
idle. I.e. my app seems very well behaved, as it should, being built on
an OO framework that should not "make mistakes" with DB transaction
handling.
Problem is that the DB is 52 Gbyte so a sweep will take several hours,
and a gbak takes about 5-6 hours. A simple file copy (when DB is ensured
to have no connections) using fastcopy.exe at top speed, very close to
hardware limits, takes almost half an hour.
So, I avoid doing ANYTHING that's not absolutely necessary with this
database.
> try gfix -sweepI'll try it tonight. Guess it may have happened when I had to shutdown
> and then gstat -h is this now ok?
the server because FB seemed to hang. One of the FB processes was
running at top CPU (for one CPU core) but *NO* I/O (according to Task
Manager) for several hours... And I was unable to make new connections
to that DB (although other DB:s worked fine). The DB validated OK
afterwards but I never checked trans numbers or the need for a sweep.
As a final point, the gstat section in the Firebird PDF manual
(http://www.firebirdsql.org/pdfmanual/Firebird-gstat.pdf) says (page 7):
"Snapshot - the ID of the oldest transaction which is currently not
eligible to be garbage-collected. Any transaction with this or a higher
ID cannot, yet, have old record versions removed by a sweep, for example."
I interpreted this as saying that a sweep wouldn't help. Maybe I was
wrong, but in that case I think this document is misleading.
Kjell
--
------------------------------
Kjell Rilbe
DataDIA AB
E-post: kjell.rilbe@...
Telefon: 08-761 06 55
Mobil: 0733-44 24 64
[Non-text portions of this message have been removed]