【发布时间】：2014-11-27 10:28:50
【问题描述】：
我们将 H2 用于长期运行的进程，它将许多短期“事件”存储到嵌入式 H2 数据库中。插入和删除行的吞吐量很高，但事件的频率会有所不同。
在半生产系统上，数据库文件已增长到 27 GiB。彻底压缩后，文件只有 1.25 MiB。这是一个大于 20000 的系数！
我知道 H2 在运行时不会压缩，而是标记和重用可用空间，我认为这应该没问题。在某些时候应该在已用空间和可用空间之间取得平衡，并且数据库文件不需要进一步增长。
通常建议使用 H2 的 Recover 工具来分析此类情况（使用开关 -transactionLog）。 如何解释恢复工具的输出？
首先是底部的统计部分：
---- Statistics ----
-- page count: 14147341, free: 14106216
-- page data bytes: head 612539, empty 20613944, rows 9040909 (32% full)
-- free 99%, 14108082 page(s)
-- data leaf 0%, 14779 page(s)
-- data node 0%, 241 page(s)
-- btree leaf 0%, 2644 page(s)
-- btree node 0%, 564 page(s)
-- free list 0%, 865 page(s)
-- stream trunk 0%, 39 page(s)
-- stream data 0%, 20124 page(s)
空闲页面计数显示几乎所有空间都被空闲页面占用（默认页面大小为 2 KiB）。
流数据 20124 个页面意味着 40 MiB 用于事务日志，对吧？
下一个问题是关于 LOB 的。在我的恢复输出中，INFORMATION_SCHEMA.LOB_DATA 有 13342 条 INSERT 语句。但是当我在控制台中打开数据库时，这个表只有 2 行。为什么会有差异？
通常的嫌疑人是未提交的交易。查看代码自动提交永远不会关闭，但我还是想检查一下。我的恢复输出有 702431 行事务日志。这在我看来很多吗？这正常吗？ 如何识别未提交的交易？前几行如下所示：
---- Transaction log ----
-- log 164481:8670836 next: 8673913
-- log 164481:8670836/8672265
-- undo page 34939 data leaf (last)
-- undo page 32723 free list
-- undo page 8590631 data node
-- log 164481:8670836/8672266
-- undo page 42949 data node
-- undo page 6686382 data node
-- undo page 44 data node
-- session 1 table 10 - 61593342
DELETE FROM INFORMATION_SCHEMA.LOB_DATA WHERE _ROWID_ = 61593342;
-- commit 1
-- undo page 111 b-tree leaf (last)
-- log 164481:8670836/8672267
-- undo page 62 b-tree node (last)
-- log 164481:8670836/8672268
-- undo page 3566625 b-tree node (last)
-- undo page 48 b-tree node (last)
-- undo page 8590604 data leaf (last)
-- log 164481:8670836/8672269
-- undo page 42802 data node
-- undo page 8187925 data node
-- undo page 49 data node
-- session 1 table 2 - 48272953
DELETE FROM INFORMATION_SCHEMA.LOBS WHERE _ROWID_ = 48272953;
-- commit 1
那两个不是提交成功了吗？为什么它们还在日志中？
H2 版本是 1.3.163。我尝试了 1.3.176 的人工事件，但文件以同样的方式增长得很快。
这些问题是相关的，但并没有真正帮助我：
【问题讨论】：