--- In firebird-support@yahoogroups.com, "Alan McDonald" <alan@m...>
wrote:

> > > do you have forced writes on this db set to ON? if not then do

it

> > and see if
> > > you get the same result. I would think not.
> > > IF you do have forced writes set to ON, then I think you will

need

> > to tell
> > > us more about whta these processes are doing. If it's always

the

> > same
> > > process which crashes, then let's talk more about that one.
> > > When it crashes, do you still see CPU activity running on that
> > > process/thread?
> > > The process whcih crashes, is it dealing with inserts? or are

all

> > processes
> > > only selects?
> > > You can see there are is a lot more info to provide.
> > > Alan
> >
> > I have forced writes ON and it is not always the same process

that

> > crashes. For the logs that my aplications write I can see that

the

> > processes are not crashing because of the database but when this
> > happens the connections to the database are oppened and most of

the

> > times inserting records.
> >
> > The database has 43 tables. This tables are divided in 3 logical
> > groups (A, B and C). The tables in this groups are not related in
> > the database, this means that inserting in a table of A does not
> > afect the B or C tables.
> >
> > The configuration of this aplications is as foillows:
> > 1) This aplication is always running and inserting records in all
> > tables from the 3 groups. It uses one connection to insert

records

> > in A, one connection to insert records in B, one connection to
> > insert records in C and one connection to delete the old records
> > from A, B and C. It also has several connections to query the
> > database but this only happens when a client is connected to the
> > aplication. At the end of the day this aplications does a backup

of

> > the database. It closes all opened connections, shutdow the
> > database, copy the database file, open the database and validate

the

> > copy.
>
> All users are not SYSDBA right?

Yes that´s true.

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

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

> 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
>
>
>
> >
> > 2) This aplication runs once a week and uses only tables in

group A.

> > It has a list of files in disk and tests the tables to see if the
> > files (path) exist in the database if not the aplication inserts

the

> > records in the database. This has 16 simultaneous connections to

the

> > database.
> >
> > The statistics from a non corrupted database (this is one of the
> > databases that has more records ) are:
> >
> > Database header page information:
> > Flags 0
> > Checksum 12345
> > Generation 1822942
> > Page size 4096
> > ODS version 10.1
> > Oldest transaction 1822898
> > Oldest active 1822899
> > Oldest snapshot 1822899
> > Next transaction 1822900
> > Bumped transaction 1
> > Sequence number 0
> > Next attachment ID 0
> > Implementation ID 16
> > Shadow count 0
> > Page buffers 0
> > Next header page 0
> > Database dialect 3
> > Creation date Jun 7, 2005 12:36:38
> > Attributes force write
> >
> > Variable header data:
> > Sweep interval: 20000
> > *END*
> > Database file sequence:
> >