>Svein Erling Tysvaer wrote:
>>
>> Just to be certain - you have checked the queries of the app itself?
>> Poor design (e.g. asking for all too many rows or count to show a
>> progress bar) or poor plans chosen by the optimizer are quite common
>> reasons for poor performance, and fixing such issues have far greater
>> impact than any configuration tweaking.
>>
>> Set

At 10:17 AM 4/01/2008, you wrote:

>Unfortunately I'm no DBA and wouldn't know how to even start. We are
>however hassling the software company who's app it is and they are
>looking at/fixing various issues as they find them.
>
>As the guy looking after the IT there in general, I'm basically just
>trying to get a reasonable config that I can put in there so I can then
>go back to the third party and get them to look further at the application.

DBAs can't fix bad application code. Still, if you're not the creator of the application or the database, it's not a great idea to be fiddling around with the database configuration if you don't understand the significance of things (or even the difference between a Kilobyte and a Megabyte!!) The header info you supplied in another posting makes it obvious that the system was designed for Superserver. Users making their own arbitrary changes without knowing what they're doing are the bane of our lives!!!

I'd strongly recommend that you contact the vendor for support about installing/reinstalling both the application software and the database and ask their advice about changing the server architecture. The transaction statistics indicate that the application seems to be taking reasonably good care of garbage. It looks as though you've been running this database for well over a year. Has it always performed badly?

./heLen