H2数据库不断增长：如何分析恢复工具的输出？

Question

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

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

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

通常建议使用H2的恢复工具来分析此类情况（使用开关-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。在我的Recover输出中，有13342条INSERT语句用于提供模式信息。LOB_数据。但是当我在控制台中打开数据库时，这个表只有两行。为什么会有区别？

通常的嫌疑犯是未promise的交易。查看代码自动提交从未关闭，但我还是想检查一下。我的恢复输出有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数据库

Answer 1

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

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