Fabian Merki wrote:
hi all
i encountered a very strange problem.
today the backup of a small db was 7.4 gb and it filled up my disk.
running "du -s" results in:
105194 backup/2007-10-14 03-09-31/
105214 backup/2007-10-15 03-10-23/
105250 backup/2007-10-16 03-09-40/
105318 backup/2007-10-17 03-09-29/
202713 backup/2007-10-18 03-09-52/
370164 backup/2007-10-19 03-10-36/
deleted the other backups in the meantime (space problems!)
if there were that many rows/data in my db i would not write this mail.
the strangest thing of all is that count(*) on one of the problematic
tables is 141'655 while this table has 571'211 pages while
estimspacesaving is 0 (numfreepages=0, numfilledpages=1).
the row-layout is 2 x bigint + 2 x 255varchar - this is much less than 1 kb
the pagesize is 4kb - more than one row should fit in one page
i run CALL SYSCS_UTIL.SYSCS_BACKUP_DATABASE(...) every day.
can anyone explain why the db started to grow so quickly in size? why
would the numallocpages be more than count(*) - i never delete rows in
this table!?!?
Hello Fabian,
I don't have an answer to your question, but I have a few questions for
you :)
1. How is the data inserted into your database?
2. Do you have multiple connections inserting the data cuncurrently?
3. Have you tried compressing the table(s)?
4. Have you specified any tuning-properties for the storage-layer/-engine?
These are just a few questions to help us understand what's going on.
Hopefully someone will be able to give you a solution to your problem.
It would be interesting to see what happens if you try to compress the
tables.
i'm using db-derby-10.2.2.0-bin and jdk1.5.0_09 (ok, i should update
sometimes...)
Which operating system are you using?
regards,
--
Kristian
thanks for any help
fabian
