Stefan G. Weichinger schrieb am 28.08.2010 um 10:10 (+0200):

> Am 28.08.2010 01:30, schrieb Svein Erling:
>
> > Were these statistics taken from the database at a time when it was
> > slow? I'm asking because it seems it might be the statistics from a
> > freshly restored database, and statistics taken at a time when the
> > database is responsive isn't anywhere near as useful as statistics
> > taken when the database is slow. These statistics indicate that your
> > transactions are well handled, but as I said - if it is taken at a
> > time when the database behaves well, this might not be the entire
> > truth.
>
> This is another output, taken right now and from the DB while people
> are working ...

Okay, I'll try, in the hope of being corrected by the pros if my
assessment is flawed.

> Database header page information:
> Flags 0
> Checksum 12345
> Generation 533500
> Page size 16384
> ODS version 11.1
> Oldest transaction 288095
> Oldest active 288096
> Oldest snapshot 76544
> Next transaction 501810

There's an old transaction running (288096), and possibly more. You
can see it's old because the next one will be 501810, so more than
200,000 transactions inbetween out of 500,000 in toto.

Your old transaction is unlikely to be READ COMMITTED as the oldest
snapshot is even much older, and READ COMMITTED transactions do not
hold on to old snapshots so do not inhibit garbage collection, but
snapshot transactions do, which should, consequently, be committed
quickly.

I don't know if this is related to your machine swapping, but it
looks like something you want to fix in your application: snapshot
transactions need to be committed (or rolled back) in a timely manner.

> Would the "Process Explorer" from sysinternals.com help me to findout
> what leads to swapping?

Or even taskmgr. What are the big memory users?

--
Michael Ludwig