Subject | FW: RE: [IB-Architect] trouble with sweep |
---|---|
Author | Dmitry Yemanov |
Post date | 2002-10-19T09:41:07Z |
Sent on behalf of Robbi. I should notice that his post pretty much
corresponds to my one.
-----Original Message-----
From: Robbi [mailto:esser.r@...]
Sent: Saturday, October 19, 2002 1:38 PM
To: dimitr@...
Subject: Re: [IB-Architect] trouble with sweep
Hi all,
please consider the following while you're intensively talking about the
priority of the GC and sweep processes:
Like my partner Michael Gast and me wrote in different support threads this
year, there are some generally problems with these processes:
1) We are able to reproduce the situation where sweep destroys the database
integrity in SS and CS when a linux server regulary shuts down, the IB/FB
stop skripts are executed and the sweep process is active.
2) Even without any user connections the sweep process (manually started at
the server console) doesn't come to an end within 3 days on a 5 GB database,
that had a minimum of activities and rollbacks after the last restore.
Restore needs (on a 1 GHz SCSI server) about 2 hours for 5 files and a size
of 5GB, sweep needs more than 3 days (maybe it never will finish because we
stopped it).
1) and 2) are not acceptable in 24x7 environments. So we decided to
deactivate sweep with the resulting effect, that xx days after the last
rollback we are running into permanent cpu consumation of 99% by the
ibserver process.
In our opinion 1) is the most critical error and risk because even with an
ups, the server may shut down while GC or sweep are active!
I'm pretty sure, that both effects can't be solved only by a decision about
lower or higher priorities. There are more architectural issues to be
solved.
Robbi
corresponds to my one.
-----Original Message-----
From: Robbi [mailto:esser.r@...]
Sent: Saturday, October 19, 2002 1:38 PM
To: dimitr@...
Subject: Re: [IB-Architect] trouble with sweep
Hi all,
please consider the following while you're intensively talking about the
priority of the GC and sweep processes:
Like my partner Michael Gast and me wrote in different support threads this
year, there are some generally problems with these processes:
1) We are able to reproduce the situation where sweep destroys the database
integrity in SS and CS when a linux server regulary shuts down, the IB/FB
stop skripts are executed and the sweep process is active.
2) Even without any user connections the sweep process (manually started at
the server console) doesn't come to an end within 3 days on a 5 GB database,
that had a minimum of activities and rollbacks after the last restore.
Restore needs (on a 1 GHz SCSI server) about 2 hours for 5 files and a size
of 5GB, sweep needs more than 3 days (maybe it never will finish because we
stopped it).
1) and 2) are not acceptable in 24x7 environments. So we decided to
deactivate sweep with the resulting effect, that xx days after the last
rollback we are running into permanent cpu consumation of 99% by the
ibserver process.
In our opinion 1) is the most critical error and risk because even with an
ups, the server may shut down while GC or sweep are active!
I'm pretty sure, that both effects can't be solved only by a decision about
lower or higher priorities. There are more architectural issues to be
solved.
Robbi