So I wanted to add one last posting to this thread and it can probably be
closed out...
Longer term I think that adding a way to either force the indices on
temporary tables to disk or providing some way of limiting how much
information from the index is maintained in memory is the right way
I didn't store any blobs. I have 177130119 rows in the table. I've copied
it to Postgresql as described above.
Inserting batches into the table of the h2 db took hours, so I decided to
move to a different db.
--
You received this message because you are subscribed to the Google Groups "H2
Depends: how many tweets did you store?
I would be more concerned in case you store blobs in the db, which to me is
inefficient regardless of the db engine.
On Tuesday, May 9, 2017 at 12:57:23 PM UTC+2,
hol...@informatik.htw-dresden.de wrote:
>
> I didn't look at Scriptella. fetch size = 1
I didn't look at Scriptella. fetch size = 1 doesn't improve anything.
Now I'm copying the rows based on their id, using "where id > ... and id <
...", which works.
I suppose h2 isn't made for large data sets.
Am Montag, 8. Mai 2017 16:50:03 UTC+2 schrieb Christian MICHON:
>
> Did you have
Regular backups in order to recover from data corruption. Always a good
practice.
Useful as I had a production db 24/7 for almost 1 year (using 1.3.176) and
Windows updates made the database crash a few times.
As for the txt done by the recover, I guess it's just a debug log of the
recovery
On Tuesday, May 2, 2017 at 10:56:26 PM UTC+2, great_aw...@msn.com wrote:
>
> In regards to the retry option mentioned, is that just added to the URL
> like this?
>
> "jdbc:h2:retry:./dbfilename;"
>
>
Yes. That seems to be the format.
I just ran into this issue... first thought that H2 1.4 is
On Monday, May 8, 2017 at 2:02:04 PM UTC+2, Christian MICHON wrote:
>
> Yes you can use the 1.4 jar to export the script. I've done this already.
>
> I would advice to use the default settings per version. 1.3 uses page
> store, 1.4 the newer store. Do not tweak the defaults settings except
