At 07:14 AM 16/02/2005 +0000, you wrote:

>In oracle when the dba performs a shutdown there
>are 3 steps involved

> closing the database

This is what gfix -shut does.

>- dismount - and
>stop the server. In a forced shutdown the server will
>disconnect all connections immediately.

In Firebird's gfix -f, the server first goes around and rolls back
everyone's transactions. Only then will it begin disconnecting those still
connected. Depending on how long the rollbacks took, the connections may
well have timed out by then. I think you are wrong about Oracle. Oracle
doesn't leave uncommitted work behind in a forced shutdown,
either. However, Oracle does have the ability to kill a running
transaction. Firebird currently does not.

>So when the shutdown
>is finished you can be sure that no-one has access to the database.

gfix -f prevents all new transactions or attachments immediately, but it
does give users a timeout to enable them to commit work they have pending.

Firebird has two gentler ways to shutdown. gifx -tr n disallows further
transactions and, after n seconds, will shut down if no existing
transactions are still running. Naturally, no new attachments can be made
during this timeout period, since connecting requires a transaction. gfix
-at n blocks all new attachments until the timeout and will go into full
shutdown if there are no existing connections.

>After shutting down you can do your backup, restore or anything
>else you want to do.

In Firebird you don't have to do a database shutdown to do backups. It has
"hot backup". If you are a mad person, and plan to do a -replace_database
restore, you should not shut down the database, but disconnect everyone,
including SYSDBA.

>In firebird gfix -shut -force 1
>returns immediately without waiting for the shutdown to complete.

How do you know the database is not shutdown? Do you test to see whether
it is?
gstat -h /path/to/db/yourdb.fdb -user sysdba -pass blckaddr

See the Attributes: force write, database shutdown

>So what is the problem with the backup/restore in firebird;
>There are 2 reasons to perform a restore
>1) Your running database is OK but as you said:
> "a restored database is squeaky clean, garbage-free, well
> compacted and all indexes are nicely balanced.
> Kicking over to a restored database is a good thing to do
> once in a while"
>
>2) Your running database is not OK (corrupted, lost etc)
>
>In either case you must have a working copy of the database.
>How can one be sure for that? by taking regular backups to different
>media. In every DBMS no-one can guranatee that the tape or disk
>is not deffective.
>
>So for the restore:
>first step is to take a backup (or two) before the restore.
>Even in case 2 where the database is already corrupted
>I believe taking a backup is a necessity since you may be
>able in an emergency to save some data.

When you have a corrupt database, no-one is connected to it. Take a
file-copy to work on, ALWAYS, when you suspect corruption. You will use
both gbak and gfix to work through, find and fix (if you can) structural
corruption. Physical corruption, nothing will work.

>I believe the best way to do that is to shut the database
>first. PROBLEM 1: gfix returns immediately so no indication
>that shutdown has finished

Use gstat to check/monitor the progress of the shutdown.

>second step is to restore from a backup (with replace option)

No, never restore from a backup with the replace_database option. NEVER.

>PROBLEM 2: you are not sure that during the restore the
>server will not try to do some things before the restore
>is completely finished resulting to a corrupted database.
>
>I start to believe that the main problem is the
>coordination of gfix and the server. gfix (during a shutdown)
>should wait for all activity to the database stops, connections
>to disconnect, server to clean up etc. and then return.
>Also the server (during a restore with gfix) should stop all
>internal activity to the database until restore is complete.

Why don't you re-read the previous message? Why don't you read the
OpGuide? You seem to be making some peculiar wrong assumptions and it's
really hard to separate you from them.

>Firebird gives so much freedom to the backup and restore process
>that in many cases (from what I read in the posts) result in
>a corrupted database. On line backups are fine but .....
>The old fashion way: SHUTDOWN (and I mean SHUTDOWN) the database
>perform your OS level backup/restore and restart is much safer.

Even better is to TAKE NOTICE when an experienced user advises you to
pretend that gbak -replace_database doesn't exist.

By all means, shut down the database to do your backups, if you want
to. People commonly schedule their backups to run from cron (or the win
scheduler) during the night. But - if you shut down during working hours
to do backups, just make sure the users know that it was your arcane choice
to do that...

./hb