Yes, an unexpected, many-minute wait can be disturbing. My DVR's latest firmware ditched an orderly front-panel reboot, and cycling the power takes /forever/! If your embedded platform has some kind of maintenance interface, you might offer the option to rebuild, noting the time required. I see "Rebuild index functionality" on the Roadmap.
On Dec 19, 8:21 am, Alex <[email protected]> wrote: > This is not a very good solution for us. On our embedded platform > recreating that index can take 5-6 minutes. > I don't see how this can be a safety "feature" keeping 24 MB of > trailing zeroes in the index file for 1 MB of data :) > > On Dec 19, 3:17 am, trashgod <[email protected]> wrote: > > > It may not be so much a bug as a safety feature. I see that deleting > > the index.db file causes indexes to be rebuilt when the database is > > next opened. Why not make that part of your recovery process? > > > On Dec 18, 11:24 am, Alex <[email protected]> wrote: > > > > The index does get much small when recreated. > > > > I think this is some kind of a bug in the recovery code. > > > > Under the normal operation the index file size in our database is > > > about 60% of the data size. > > > However after several power failures it grows to some very > > > unreasonable size (in some cases it is 25 times the data size). > > > We are implementing a work-around that would delete the index file if > > > the size is unreasonable, but I'd much rather have the recovery / > > > store code fixes. > > > > Alex > > > > On Dec 17, 10:12 pm, trashgod <[email protected]> wrote: > > > > > On Dec 16, 5:12 pm, Alex <[email protected]> wrote: > > > > > > I have a fairly small database one table has 1400 rows and the other > > > > > table is about 3500 rows. I have 3 primary key indexes and 5 indexes > > > > > on BIGINT column types. > > > > > > The data file size is about 1 MB, however the index size grows to > > > > > about 25+ MB. I don't have the entire diagnostic information yet, but > > > > > I think that it has to do with the power failures and the recovery of > > > > > the index after the failure. > > > > > > The problem is that the larger this index file is the longer it takes > > > > > to recover from the failure next time around. I also looked at the > > > > > index file with the HEX viewer. It appears that beyond the first > > > > > 5%-8% of the file the rest is filled with zeroes. > > > > > > What is the expected data / index size ratio in H2? Is there anything > > > > > short of recreating the index to get it compacted? What can be > > > > > causing most of the index file to have zeroes in it? > > > > > Why not drop and recreate the constraints & indexes? See if it gets > > > > smaller. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "H2 Database" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/h2-database?hl=en -~----------~----~----~----~------~----~------~--~---
