At 03:09 PM 18/03/2003 +1000, you wrote:

> > You shouldn't be using any sort of file copy on a database where the
>server
> > is running. Just doing *this* will not just produce a corrupt copy, it
> > will also potentially corrupt the database file which you are copying,
> > because file copy utilities lock sectors of the physical disk, which could
> > contain structures that open transactions are writing to, have uncommitted
> > record versions in, etc.
>
>I knew this in theory, now I know for sure! :-)
>
> > Did you realise that gbak is NOT a file copy utility?
>
>Yep.
>
> > On your questions in later messages, there is nothing *wrong* with doing a
> > gbak backup and a gbak restore once a week if you need to. Performance
> > will tell you how often you need to resort to this type of hygiene.
>
>So I do get more from a backup and restore than from a simple sweep? Does a
>sweep reset the metadata change ids? That is, can you make 250 metadata
>changes, do a sweep and then do another 250? Apparently, 255 is the max
>changes before a backup and restore is required.

Yup. If you have a database that's still under development and you're
hitting the limit regularly, you have no option but gbak and restore to
reset them.

And YES, you get a lot "more" (where less is more) from restoring from a
gbk. You get everything rebuilt from scratch, all tables repopulated
(without firing triggers), all pages reconstructed, all indices
rebuilt. Restore isn't sweep, nor anything like it, and sweeping doesn't
occur during a restore.

> > Restore the gbk file using gbak -c to a *different* place on your
> > filesystem. Connect to it to verify that all is OK; then disconnect and
> > then shut down the server.
>
>I would prefer not having to shutdown the server if it can be avoided....

Then you need a very effective communication system with the users, or even
to detach the server from the network, if you have maverick users. (I've
come across a site where they rename the security database during restores
but, since this affects all databases...shutting down the server seems
simpler...)

I don't know if it's possible to do a gfix -shutdown on a database that's
in the process of being restored, but you could experiment with that on a
database you don't care about.

heLen