Flags 0
Checksum 12345
Generation 21374673
Page size 4096
ODS version 11.0
Oldest transaction 21374659
Oldest active 21374660
Oldest snapshot 21374660
Next transaction 21374667
Bumped transaction 1
Sequence number 0
Next attachment ID 12
Implementation ID 16
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 1
Creation date Feb 13, 2008 20:13:13
Attributes force write
Variable header data:
Sweep interval: 20000
*END*

I read these statistics as indicating that your database is not corrupt (correct checksum), has a sensible page size and correctly has set forced writes on, has run lots of transactions, but have no transaction problem since oldest transaction is very close to next transaction. Well, actually, with numbers above 20 million and a gap of less than 10 transactions, I actually get suspicious and wonder whether these statistics were actually taken from a live database that had been running for a while or if you shut down your database just before generating the statistics. To get useful information regarding whether you have a transaction management problem or not, you have to obtain these statistics on a live database that has run for a while. If you have a system that gradually slows down over time, that indicates a transaction problem, but to confirm that you have to run gstat while things are slow and nothing has been stopped.

ABFRAGESOURCE isn't an interesting table, it has too few records to really cause any problems (if I interpret things correctly, I don't normally read this kind of statistics). Though the index IXTYPE_208 is probably useless, with 249 records and 248 of them having the same value, the only case I can think of where such an index is useful is if these 248 records store historical information and that you're normally only interested in the one record that has a different value (but then you probably wouldn't need any of the other indexes). Whenever you're interested in some of the duplicates, this index slows things down. The rest of the indexes for this table seem more sensible.

The ABSTRACTORDNER table is also a very small table of not too much interest. I wouldn't normally have the index you show here either (the most common value being registered for almost half the records), though it may be useful in some cases when you're interested in other values.

What is interesting, is if you identify some reason for your programs being slow, probably either a large gap between oldest transaction and next transaction or a particular query. In the latter case, it would be good if you posted the SQL here together with statistics for the tables/indexes mentioned in the PLAN. There are, of course, other reasons that things may be slow as well (like trying to access things over a slow network connection and possibly AntiVirus/Firewall trying to control Firebird). Programs should only ever try to transfer interesting information, that is limit the number of fields and records to fields and records that you actually need (that's the big difference between desktop and client/server databases), if you transfer everything, Firebird will appear to be a slow database.

HTH,
Set

---

Analyzing database pages ...
ABFRAGESOURCE (229)

Index IXTYPE_208 (1)
Depth: 1, leaf buckets: 1, nodes: 249
Average data length: 0.01, total dup: 248, max dup: 248
Fill distribution:
0 - 19% = 1
20 - 39% = 0
40 - 59% = 0
60 - 79% = 0
80 - 99% = 0

Index IX_208_208_0_0 (2)
Depth: 1, leaf buckets: 1, nodes: 249
Average data length: 0.69, total dup: 128, max dup: 38
Fill distribution:
0 - 19% = 0
20 - 39% = 1
40 - 59% = 0
60 - 79% = 0
80 - 99% = 0

Index IX_208_208_1_0 (3)
Depth: 1, leaf buckets: 1, nodes: 249
Average data length: 0.86, total dup: 104, max dup: 13
Fill distribution:
0 - 19% = 0
20 - 39% = 1
40 - 59% = 0
60 - 79% = 0
80 - 99% = 0

Index PK_208 (0)
Depth: 1, leaf buckets: 1, nodes: 249
Average data length: 1.24, total dup: 0, max dup: 0
Fill distribution:
0 - 19% = 0
20 - 39% = 1
40 - 59% = 0
60 - 79% = 0
80 - 99% = 0

ABSTRACTORDNER (136)

Index IXTYPE_105 (1)
Depth: 2, leaf buckets: 2, nodes: 1104
Average data length: 0.01, total dup: 1096, max dup: 541
Fill distribution:
0 - 19% = 0
20 - 39% = 0
40 - 59% = 2
60 - 79% = 0
80 - 99% = 0

How do i have to interpret this?

Do i have to upload the hole file?

Greetings from Switzerland

Haija