我们将 H2 用于长期运行的进程，该进程将许多短暂的“事件”存储到嵌入式 H2 数据库中。插入和删除行的吞吐量很高，但事件的频率各不相同。

在半生产系统上，数据库文件已增长到 27 GiB。彻底压缩后，文件只有1.25 MiB。这是一个大于 20000 的因子！

我知道 H2 在运行时不会压缩，但会标记和重用可用空间，我认为这应该没问题。在某些时候，已用空间和可用空间之间应该存在平衡，数据库文件应该不需要进一步增长。

通常建议使用 H2 的 Recover 工具来分析此类情况（使用 switch -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。在我的恢复输出中，有 13342 个用于 INFORMATION_SCHEMA.LOB_DATA 的 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 的人为事件，但文件以同样的方式快速增长。

这些问题是相关的，但并没有真正帮助我：

• h2.db 文件不断增长
• H2 数据库快速增长失控
• H2数据库>如何在运行时压缩/清理？

解决方案

对于您分析过的文件，所有页面的 99% 都是免费的：free 99%, 14108082 page(s). 所以我猜到那时 99% 的数据都被删除了（表被截断、表被删除、索引被删除、LOB 被删除、事务日志被截断、临时表被删除，等等）。因此，分析此文件将无济于事。

有趣的是在99% 的文件免费之前分析文件。为此，您可以在程序运行时使用内置备份功能（SQL 语句backup to ...）复制文件。然后分析该文件（对该文件运行恢复工具）。您可能需要多次执行此操作，直到找到 99% 的文件尚未空闲的位置。