--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@t...>
wrote:

> At 07:00 PM 15/02/2005 +0000, you wrote:
>
>
> >I would like to ask 3 questions, if anyone could help
> >because I have read many posts in various forums and
> >I'm a little bit confused
> >1) When we shutdown the database in force mode with 0 secs wait,
> >are we absolutely sure that no one except SYSDBA and the
> >creator can be/is connected to the database;
>
> No. A wait of 0 give no users any opportunity to complete work.

The

> server will begin cleaning up, by rolling back uncommitted work and
> disconnecting connections. This could well take some time and

greatly

> annoy users who had a big job running. Note that shutdown won't

touch work

> in progress being done under a SYSDBA or Owner login.
>
> Shutting down a database is a way to get into the condition where

SYSDBA or

> Owner can get exclusive access. You shouldn't treat a forced

shutdown as

> an arbitrary way to spoil everyone's day. Always try to do a

controlled

> shutdown by giving a wait period and warning the connected users to

finish

> up.
>
>
> >If yes then are we sure that the server itself doesn't do anything
> >with the database for example garbage collection;
>
> Once the shutdown -f wait period is over, the server will start

cleaning

> up, doing what it has to do to give SYSDBA or Owner the opportunity

to log

> in with exclusive access. If a GC thread or a sweep was running

when the

> timeout ended, it will complete. If the database was involved in a
> cross-database transaction, there will be limbo flagging to do in

the other

> databases...and so on.
>
> >If it does what is the meaning of the replace option in gbak since
> >the only safe way to restore the database
> >is to drop the original one and restore the backup;
>
> This is a non-sequitur. Gbak is the backup program. Gbak
> -replace_database is the UNSAFE way to restore any database, so

much so,

> that many of us think it should be removed as an option. You

should never

> drop the original database until you are sure that you have a

backup that

> can be restored. Gbak -b backs up data, warts and all. Any restore

(

> -create_database or -replace_database ) will croak on inconsistent
> data. You will be in a bad place if you attempt gbak -r and the

restore

> croaks. You have a bad backup and a non-existent database.
>
>
> >If no (shutdown doesn't guarantee that noone except
> >SYSDBA and the db creator can connect)
>
> Another non-sequitur. The purpose of shutdown -f is to prevent any

more

> connections or transactions from being started by non-privileged

users.

>
> >then droping the database and restoring from the backup is
> >the only safe way to restore a database or is there any other
> >way to shutdown the db for all?
>
> Someone has given you a crazy idea, I'm afraid. You can backup the
> database at any time, with or without exclusive access. You can

even gbak

> -r while users are logged in. Gbak -r *begins* by dropping the
> database. It deletes the database file from disk. Please believe

me when

> I tell you that you should NEVER use it on a database you care

about.

>
>
> >2) If have read in many posts that backing up and restoring
> >the database is much better than just gfix it once in a while.
>
> Certainly, 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. Verifying a backup

by

> restoring it -c on another server and connecting to it is something

you

> should do after every backup.
>
> Running gbak -b itself performs GC on the database, unless you set

the -g

> switch to prevent it. You should only set the -g switch if you

plan to

> kick over to a restored database.
>
> In a well-behaved system, restoring a database might be something

you do

> once a year, or maybe only after an earthquake. In some systems,

where

> applications don't behave well, kicking in a restored database

might be a

> regular necessity just to keep things moving. In others, where
> applications behave nicely, restored databases are commissioned

only after

> earthquake, flood or fire.
>
> >But gfix seems to me better in the way it doesn't allow you
> >to do anything unless it can get exclusive access to the
> >database( does this mean excluding access form the server also;).
>
> Gfix is a utility that gives access to a number of tools, including

sweep

> and validate. Gfix -sweep is a very good thing to do as part of

regular

> housekeeping. But you don't need exclusive access to run a sweep.

But

> sweeping is no substitute for maintaining backups.
> Gfix -validate is good to do regularly if you have the kind of

environment

> where users do silly things like unplugging their workstations

without

> disconnecting from the database, because it will clean out

unassigned pages

> and free them up for re-use. It's also useful for finding corrupt
> structures that can occur on dirty networks.
>
> >But, am I missing anything if I just gfix the database regularly

and

> >ofcource perform regular backups and restore only in case of

emergency;

>
> Hard to say. What do you do with gfix regularly?
>
> >3) Finally when gfix doesn't give any messages on the
> >screen, means it has found no problems or something
> >went wrong;
>
> It depends what you are doing with gfix.
>
> ./hb

Helen
thanks very much for your answer to my many
questions. You see I have been working with
oracle for many years and now I decided
to try firebird for a windows app I'm developing.

In oracle when the dba performs a shutdown there
are 3 steps involved closing the database - dismount - and
stop the server. In a forced shutdown the server will
disconnect all connections immediately. So when the shutdown
is finished you can be sure that no-one has access to the database.
After shutting down you can do your backup, restore or anything
else you want to do.

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

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.
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

second step is to restore from a backup (with replace option)
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.

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.

When an DBA exists in every environment you deploy your application
everything will work fine. But this is not always the case. In fact
it is the exception. In most cases you will have ordinary
users doing stupid things (resetting computers, catching viruses etc).
How to ask them to perform a backup - test the backup to
a different server - restore from a working copy - test the copy
etc.

Anyway thanks again for your answers.
John