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

Question

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

在半成品系统中，数据库文件已增长到27 GiB。在对其进行彻底压缩后，该文件只有1.25MiB。这是一个因子>20000！

我理解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，对吗？

下一个问题是关于LOBs的。在我的恢复输出中，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人工事件，但文件也以同样的方式快速增长。

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

• h2.db file keeps growing
• H2 database growing out of control quickly
• H2 database> How to compact / vacuum while running?

Answer 1

对于您分析过的文件，99%的页面是免费的：free 99%, 14108082 page(s)。因此，到那时，我猜99%的数据被删除了(表被截断，表被删除，索引被删除，log被删除，事务日志被截断，临时表被删除，等等)。因此，分析这个文件是没有帮助的。

有趣的是在99%成为自由之前分析一个文件。为此，您可以使用内置备份功能(SQL语句backup to ...)，在程序运行时复制文件。然后分析该文件(在该文件上运行恢复工具)。您可能需要多次这样做，直到您找到99%的文件还没有空闲的地方。