Subject | Re: [firebird-support] Analyse database growth |
---|---|
Author | Fabiano Bonin |
Post date | 2007-10-19T14:01:26Z |
Ty,
Now i need some advice on how to analyse it.
I see a table which has actually 20285 records (in the restored
database) and in the old database it is showing 9800802 records:
MV$DST1 (192)
Primary pointer page: 525, Index root page: 526
Average record length: 58.02, total records: 9800802
Average version length: 18.52, total versions: 23, max versions: 2
Data pages: 239097, data page slots: 239097, average fill: 76%
Fill distribution:
0 - 19% = 0
20 - 39% = 0
40 - 59% = 0
60 - 79% = 239030
80 - 99% = 67
Index RDB$PRIMARY55 (0)
Depth: 3, leaf buckets: 14654, nodes: 9800803
Average data length: 1.01, total dup: 0, max dup: 0
Fill distribution:
0 - 19% = 1
20 - 39% = 1
40 - 59% = 0
60 - 79% = 0
80 - 99% = 14652
I know this table has something wrong because i knew what to expect in
the total records, but looking only to the information above, is there
some number(s) that show me there is a lot of garbage in this table?
Regards,
Fabiano.
Now i need some advice on how to analyse it.
I see a table which has actually 20285 records (in the restored
database) and in the old database it is showing 9800802 records:
MV$DST1 (192)
Primary pointer page: 525, Index root page: 526
Average record length: 58.02, total records: 9800802
Average version length: 18.52, total versions: 23, max versions: 2
Data pages: 239097, data page slots: 239097, average fill: 76%
Fill distribution:
0 - 19% = 0
20 - 39% = 0
40 - 59% = 0
60 - 79% = 239030
80 - 99% = 67
Index RDB$PRIMARY55 (0)
Depth: 3, leaf buckets: 14654, nodes: 9800803
Average data length: 1.01, total dup: 0, max dup: 0
Fill distribution:
0 - 19% = 1
20 - 39% = 1
40 - 59% = 0
60 - 79% = 0
80 - 99% = 14652
I know this table has something wrong because i knew what to expect in
the total records, but looking only to the information above, is there
some number(s) that show me there is a lot of garbage in this table?
Regards,
Fabiano.
On 10/18/07, Vlad Khorsun <hvlad@...> wrote:
>
>
>
>
>
>
>
> > Yesterday i had a database with 100mb, and today morning it had 9GB.
> >
> > I'm pretty sure this growth was caused by some recursive trigger or
> > procedure that was kept running for a loong time and then aborted, but
> > i would like to investigate the specific cause of this problem to fix
> > my application.
> >
> > I did a backup/restore and the restored database is with 100MB again.
> >
> > I have a copy of the 9GB database. Is there some way to see what happened there?
>
> gstat -r or IBAnalyst if you prefer GUI.
> It seems you have a lot of record versions (garbage)
>
> Regards,
> Vlad
>
>
>