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

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.

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