> >
> > All users are not SYSDBA right?
>
> Yes that´s true.

Then using "shutdown" will not lock users out. I still don't know tha you
are using gfix shutdown???

>
> > So you don't use gbak - you copy the file?
> > How do you validate the copy? Do you then work on this copy? or the
> > original?
>
> I´m using IBPP library inside the application code and I use this
> library to validate the copy ( Repair( m_strDBName, IBPP::RPF(
> IBPP::rpValidateFull ) ). If the validation is ok I use the original
> database.
>
> > I'm not clear what you mean by "this application" and "when a
> client is
> > connected"
> > Is this application the only connection to the database? OR are
> there client
> > applications running as well?
> >
>
> This is a Server aplication and it controls all connections to the
> database. There are several remote client aplications, but none
> connects directly to the database.
> If there are no clients connect the server aplication only inserts
> and deletes records from the database ( it has 4 connections to do
> so ).
> If a client is connect the server aplication can have more 1 to 16
> connections to do queries in the database.
>
> > Bottom line - I would definitely change my procedure to NOT copy
> the
> > database. I would back it up using gbak. Only take the db offline
> when you
> > want to restore from a backup.
> >
> Are there no risks of doing backup while the database is in use?

if you use gbak - you can do backups all day long with no risk - they are
just normal transactions.

>
> The problema about using gbak is that it can take too long and
> during that time my clients can't get the information they need. I
> need to reduce this time to the minimum possible. If I can do the
> backup with active connections ( transactions ) then this problem
> doesn´t apply.
>
>
>
> Elisabete
>

if all you want to do is backup and test the validitiy of the file, then
backup to another file name and restore to yet another filename. The process
of restoration is the best test of db health - not validation as you appear
to be doing.
Again - read the steps below - with gbak as the backup and restore vehicle.
A long process where you finally use the retored version of hte file only
has to be done once or twice a year is all weekly/nightly back/restore steps
are without error.
Alan

>
>
> > See this thread:
> > > Just curious, why the rename steps? They seem superfluous to me.
> > >
> > > -Kevin
> >
> > to ensure noone is connecting/connected to database while restore
> is being
> > done.
> >
> > backup/restore when you want to test restore
> > 1. backup
> > 2. restore to alternate filename
> > 3. all OK - delete restore, archive backup
> >
> > backup/restore when you want to use the rebuilt restore
> > 1. shutdown database (only OK if users don't all connect via
> SYSDBA user)
> > 2. stop server - rename real file to alternate name - this
> absolutely stops
> > further transactions starting on the db which will not be visible
> to the
> > backup transaction.
> > 3. start server
> > 4. backup alternate name file to alternate name .fbk file
> > 5. restore to alternate2 .fdb file
> > 6. all ok, rename alternate2 file to real filename
> > people start connecting
> >
>
> > Alan
> >
> >