Ibserver running at 99.955%- Need Advice

[Frankenherder]

We are currently running an application running on Borland Interbase 5.6 database.

The IBSERVER is running at 99.95% for periods up to 2 hours, then the IBSERVER shuts down. The only way to recover is to reboot the server and have all users log back in.

We are an end user of the application and the developer has been trying to resolve this issue for months.

Has anyone ever experienced this before?

Are there any tools that will allow me to monitor who is taking up the IBSERVER process and maxing it max out?

Any logging I can enable to view errors or to see what is taking up the IBSERVER process??

We were told that it was hardware related last year, we upgraded to Pentium 4 2.4 Ghz, 2gb RAM and now it is back.

Thanks in advance

Matt

 

[Svanhooft]

hi,

why donn't you upgrade to IB 6.02, 6,5 or 7.0

version 6.02 is an open source database.
You can use it for free. It is running smoothly on al sorts of windows platorms. Never had any problem.

Steph [Bigglasses]

 

[Frankenherder]

Our software application is only certified for Interbase 5.6. If we change, we can only go to DB2 and it is very $$$$ and I do not believe they have the proper resources to support it yet.

Any other suggestions would be welcomed, I am rebooting the server 2 x daily now.

Matt

 

[Svanhooft]

hi,

did you try to make a backup on the server. The backup resets al lot of value backs to 0.
The backup should be made with the interbase server software: IBConsole

Steph [Bigglasses]

 

[Frankenherder]

Yes, we do this every Sunday night.

We still had the speed issues though Monday at 11 am.

Matt

 

[Svanhooft]

hi,

1. Is forced writes set to true ?
2. Is it possible a database sweep is done during
the use of your database ?
3. Check the database statitics for big difference
between oldest transaction and next transaction
4. Database-File may be corrupt, Checked ?
5. Any entries in your database log-file ?
6. Is there enough free space on the location where the tempory files are stored.

Steph [Bigglasses]

 

[Frankenherder]

You are right Steph, Huge difference from oldest transaction to the next transaction.

Sweep is set to auto at 20,000 but it will not run. There was 300,000 difference in transaction numbers.

Stop and Start took are of it but need the sweep to run automatically. Our developer said that people must not be committing transactions and leaving windows open.

Any thoughts?

Matt

 

[Svanhooft]

hi,

Why not committing the transaction? I never heard that one before. If you start a transaction. You also should commit the database else the updates aren't writen to the database. There is no reason for not committing. So tell the users to commit their work. After you commit your users also can close windows. In your situation a crash from windows would result in loss of data.

So start a transaction, commit the database, and end the transaction

Steph [Bigglasses]

 

[Frankenherder]

Do these settings mean anything to anyone that could explain our spee problems? I stop and started the DB 8 hours before this was taken and we are now slowing down.

Database header page information:
Flags 0
Checksum 12345
Generation 521428
Page size 4096
ODS version 9.1
Oldest transaction 452745
Oldest active 458041
Oldest snapshot 452905
Next transaction 521420
Bumped transaction 1
Sequence number 0
Next attachment ID 0
Implementation ID 16
Shadow count 0
Page buffers 0
Next header page 0
Creation date Aug 3, 2003 23:55:09
Attributes force write

Thanks Matt