Subject | RE: [firebird-support] over-sweeping?? |
---|---|
Author | Helen Borrie |
Post date | 2004-03-09T00:06:19Z |
At 10:18 AM 9/03/2004 +1100, you wrote:
more or less correct in the context of automatic sweeps - at least the
piece you quoted. Someone who is doing 3 a.m. sweeps isn't talking about
auto-sweeping...
My take on auto-sweeping is that the 20000 default sweep interval is going
to be a safety net for the neglectful DBA in the general case but that one
needs to get ones head around the whole housekeeping picture when deploying
-- especially into environments where nobody is monitoring the condition of
the database - and provide easy tools for the users to keep things going
smoothly.
I've encountered such deployments: the vendor has shipped the database
with the sweep interval set to 0 (because of misinterpreting the docs, in
many cases); and with applications that simply prevent any reasonable
garbage collection; where the only thing available to the users to fix
the outcome the (frequent) freezes and crashes is backup and restore (and
it is *scary* how often this is just "Backup" and "Restore", no
intermediate gbak -c).
With a DBMS that runs sweetly and doesn't need a SYSDBA on site, it's
tempting for developers to think *they* can treat the live database as a
black box and ignore the dynamic effects of changes in database
content. The real trick is do the right stuff in development so that the
users can treat it as a black box (more or less...as long as they press the
right buttons on or near the right day)
/hb
>Helen,What it says in the manual (over which we have no control whatsoever!!) is
>if that's correct, then, maybe the manual, which has had this information in
>it since I can remember (maybe 1994) should finally be corrected and have it
>removed?
more or less correct in the context of automatic sweeps - at least the
piece you quoted. Someone who is doing 3 a.m. sweeps isn't talking about
auto-sweeping...
My take on auto-sweeping is that the 20000 default sweep interval is going
to be a safety net for the neglectful DBA in the general case but that one
needs to get ones head around the whole housekeeping picture when deploying
-- especially into environments where nobody is monitoring the condition of
the database - and provide easy tools for the users to keep things going
smoothly.
I've encountered such deployments: the vendor has shipped the database
with the sweep interval set to 0 (because of misinterpreting the docs, in
many cases); and with applications that simply prevent any reasonable
garbage collection; where the only thing available to the users to fix
the outcome the (frequent) freezes and crashes is backup and restore (and
it is *scary* how often this is just "Backup" and "Restore", no
intermediate gbak -c).
With a DBMS that runs sweetly and doesn't need a SYSDBA on site, it's
tempting for developers to think *they* can treat the live database as a
black box and ignore the dynamic effects of changes in database
content. The real trick is do the right stuff in development so that the
users can treat it as a black box (more or less...as long as they press the
right buttons on or near the right day)
/hb