Is there a 64 bit sqlite3.exe available to avoid out of memory error?
(1) By anonymous on 2021-06-29 11:47:33 [source]
Hi, I'm trying to recover a broken database using the ".recover" feature. I run into a out of memory error while running the command unfortunately.
Is there a workaround for this issue? I thought a 64 bit version of sqlite3.exe may solve the problem as it could allocate more memory.
Any help would be much appreciated.
(2) By Larry Brasfield (larrybr) on 2021-06-29 16:45:34 in reply to 1 [link] [source]
With either of two readily available C compilers, you can build a 64-bit sqlite3.exe . See Compiling The Command-Line Interface. That executable is much less likely to suffer an OOM failure.
(3) By Donald Griggs (dfgriggs) on 2021-06-29 17:16:10 in reply to 1 [link] [source]
Compiling sqlite yourself gives you maximum configurability, but Nalgeon kindly hosts 64-bit CLI's at https://github.com/nalgeon/sqlite/releases/
and also packages some extensions together at: https://github.com/nalgeon/sqlean
(4) By anonymous on 2021-06-29 18:39:16 in reply to 3 [link] [source]
Thanks for the link.
I tried the x64 version... but I still get the same error. The sqlite3 process isn't using more than 6 mb of memory. The broken database has a total size of 142 mb.
So it's probably no real out of memory error.
(5) By Simon Slavin (slavin) on 2021-06-30 14:49:26 in reply to 4 [link] [source]
Agreed. If you want ways to work on this …
Does the .dump command dump any information at all ? Table structure ? Any rows up to the point of corruption ?
Does sqlite3_analyzer.exe tell you anything about the database ?
I don't need to know the answers, but they might tell you something that lets you rescue some of the data.
(6) By anonymous on 2023-11-29 10:14:00 in reply to 1 [link] [source]
I am also encountering this issue even though I am running the 64bit binary. The .db is approximately 300MB in sie. My machine has 32GB of main memory. When running, the executable never uses more than 50MB. Is this a bug? Is there a work-around? I'd also appreciate any advice.
(7) By Richard Hipp (drh) on 2023-11-29 10:52:10 in reply to 6 [link] [source]
Maybe it is a bug somewhere. Because the database is corrupt, there might be some subcomponent that is trying to read part of the database for which the size information is incorrect, prompting the subcomponent to try to allocate some ridiculous amount of memory, raising an OOM error instead of reporting and attempting to fix the problem.
Do you have a repro case that you can send to us? Private email to drh at sqlite dot org is sufficient - you do not need to post it publicly.
(8) By anonymous on 2023-11-29 11:11:30 in reply to 7 [link] [source]
Hi Richard, thank you for your response. As this is customer data, I will have to seek approval which might take a while and is quite uncertain, unfortunately. If the approval is granted I will get back to you. Thank you, Alex
(9) By Richard Hipp (drh) on 2023-11-29 13:57:08 in reply to 8 [link] [source]
The problem should be resolved by https://sqlite.org/src/info/988c3179e978a3a6. Please recompile using the latest trunk code and let us know.
(10) By anonymous on 2023-11-30 13:20:27 in reply to 9 [link] [source]
Hi Richard,
thank you for fixing this so quickly. The oom-error is gone. The recovery now aborts presenting the following message.
sql error: too many columns on lost_and_found (1)
Dumping the DB yields the same message but it lets me at least convert the partial sql dump back to a DB.
Anyway, thank you again. All the best, Alex