#1
|
|||
|
|||
Deleting large numbers of items
One of my databases is very close to 10GB. I have chosen to prune it and to my surprise the size did not decrease by the expected amount. I am using the beta (3.5) and have never done this size operation before, so I cannot be sure if it is a beta issue.
I deleted (Shift-Del) about 75% of the entries after transferring them to a new database for archiving (man, I WISH we could search across databases!). The recycle bin is empty and when I noticed the size (9.4GB), I compacted it. The size was about the same. I repaired the file using the database repair tool with the same result. Are all the keywords retained in the database? Could that be what is causing the bloat? Jon Last edited by Jon Polish; 03-04-2008 at 01:45 PM. |
#2
|
|||
|
|||
Did you compact?
|
#3
|
|||
|
|||
Yup.
|
#4
|
|||
|
|||
All data related to an item gets removed when an item is permanently deleted. Maybe the largest items in the source database weren't copied or deleted? How much did the destination database grow after copying? Maybe try compacting again (after the repair).
|
#5
|
|||
|
|||
Quote:
First I compacted to very little effect. I then repaired with similarly small changes. Finally, on your suggestion I compacted again with a reduction of 4GB. This is about right because the new database (that is, the one I created by copying the archived items to a blank database) is just under 5GB. The math does not match, but I suppose there are other cosiderations. This database was repaired using your extrnal tool before pruning. I wanted to be sure before undertaking such a large operation. Is there some corruption taking place under these conditions which require another repair before being able to compact successfully? By the way, doesn't your external repair tool repair AND compact? Jon |
#6
|
|||
|
|||
Apparently repairing allowed compact to do its job.
The external repair tool does not compact. |
|
|