SQL Server 2014 In Memory OLTP - 事务回滚时的垃圾收集

我对 SIGMOD 论文Hekaton 的理解：SQL Server 的内存优化 OLTP 引擎是它与其他类型的垃圾一样得到处理。

几个相关部分是

6.2.3 事务回滚

事务可以根据用户请求或由于提交处理失败而回滚。回滚是通过使事务创建的所有版本失效并清除事务删除的所有版本的结束时间戳字段来实现的。如果有任何其他事务依赖于回滚事务的结果，则会通知它们。事务的写集再次用于非常有效地执行此操作。

请注意，它说无效而不是垃圾收集。

另请参阅垃圾收集部分（强调我的）

8.1.1 GC正确性

首先，必须注意识别哪些版本可能是垃圾。潜在的垃圾版本可能由两个进程之一创建。首先，如果 a) 它被提交的事务删除（通过显式 DELETE 或通过 UPDATE 操作），并且 b) 该版本不能被系统中的任何事务读取或以其他方式操作，则该版本将成为垃圾。版本变成垃圾的第二种不太常见的方式是，如果它们是由随后回滚的事务创建的. GC 的第一个也是最重要的属性是它可以正确确定哪些版本实际上是垃圾。版本的可见性由其开始和结束时间戳决定。结束时间戳小于系统中当前最旧活动事务的任何版本对任何事务都是不可见的，可以安全地丢弃。GC 线程定期扫描全局事务映射以确定系统中最旧的活动事务的开始时间戳。当 GC 进程被通知它应该开始收集时，自上次 GC 周期以来提交或中止的事务将按其结束时间戳排序。

但在实践中，回滚产生的垃圾似乎比提交更快地被分配，所以也许中止线程至少在某些时候确实清理了自己的垃圾。

为了看到这一点，我创建了以下过程（在内存优化数据库中）

CREATE PROC GetStats
AS
SELECT *
FROM   sys.dm_db_xtp_table_memory_stats
WHERE  object_id = object_id('dbo.Test')

SELECT name AS 'index_name',
       s.*
FROM   sys.dm_db_xtp_hash_index_stats s
       JOIN sys.indexes i
         ON s.object_id = i.object_id
            AND s.index_id = i.index_id
WHERE  i.object_id = object_id('dbo.Test')

SELECT name AS 'index_name',
       s.index_id,
       scans_started,
       rows_returned,
       rows_expired,
       rows_expired_removed
FROM   sys.dm_db_xtp_index_stats s
       JOIN sys.indexes i
         ON s.object_id = i.object_id
            AND s.index_id = i.index_id
WHERE  object_id('dbo.Test') = s.object_id;

然后运行以下命令，尝试切换ROLLBACK和COMMIT

CREATE TABLE [dbo].[Test]
  (
     [Id]     [INT] NOT NULL CONSTRAINT PK PRIMARY KEY NONCLUSTERED HASH WITH (BUCKET_COUNT = 8),
     [String] CHAR(900) COLLATE Latin1_General_100_BIN2 NOT NULL INDEX IX NONCLUSTERED HASH WITH (BUCKET_COUNT = 8)
  ) WITH ( MEMORY_OPTIMIZED = ON )

INSERT INTO [dbo].[Test]
VALUES
    (1,REPLICATE('A',900)),
    (2,REPLICATE('A',900)),
    (3,REPLICATE('A',900)),
    (4,REPLICATE('A',900)),
    (5,REPLICATE('A',900)),
    (6,REPLICATE('A',900)),
    (7,REPLICATE('A',900)),
    (8,REPLICATE('A',900))

/*Get initial position*/
EXEC GetStats

BEGIN TRAN
    UPDATE [dbo].[Test]
    SET    [String] = REPLICATE('B', 900)

/*Mid Transaction*/
EXEC GetStats

COMMIT    

/*Force a scan of both indexes*/
SELECT COUNT(*)
FROM   dbo.Test WITH (INDEX=IX)
EXCEPT
SELECT COUNT(*)
FROM   dbo.Test WITH (INDEX = PK)

EXEC GetStats

DROP TABLE [dbo].[Test]

我一直得到如下总结的结果。

UPDATE对于提交和回滚事务的影响相同memory_allocated_for_table_kb（从 7KB 增加到 15KB）

桶统计

两个测试的初始桶统计数据与

+------------+--------------------+--------------------+------------------+------------------+
| index_name | total_bucket_count | empty_bucket_count | avg_chain_length | max_chain_length |
+------------+--------------------+--------------------+------------------+------------------+
| IX         |                  8 |                  7 |                8 |                8 |
| PK         |                  8 |                  7 |                8 |                8 |
+------------+--------------------+--------------------+------------------+------------------+

中间事务（在回滚或提交之前）桶计数是

+------------+--------------------+--------------------+------------------+------------------+
| index_name | total_bucket_count | empty_bucket_count | avg_chain_length | max_chain_length |
+------------+--------------------+--------------------+------------------+------------------+
| IX         |                  8 |                  6 |                8 |                8 |
| PK         |                  8 |                  7 |               16 |               16 |
+------------+--------------------+--------------------+------------------+------------------+

之后，rollback它们立即恢复到初始计数，但之后commit它们仍保持在第二个表中，表明现在存在垃圾。

显然所有 PK 值散列到的单个桶现在有 16 个链接行，而不是以前的 8 个。

现在另一列的哈希索引有两个桶在使用，每个桶有 8 个链接行（对于 和 的“之前”和“之后”字符串AAA...值BBB...）

行已过期

提交后

+------------+----------+---------------+---------------+--------------+----------------------+
| index_name | index_id | scans_started | rows_returned | rows_expired | rows_expired_removed |
+------------+----------+---------------+---------------+--------------+----------------------+
| IX         |        2 |             1 |             8 |            8 |                    0 |
| PK         |        3 |            10 |            16 |            8 |                    0 |
+------------+----------+---------------+---------------+--------------+----------------------+

回滚后

+------------+----------+---------------+---------------+--------------+----------------------+
| index_name | index_id | scans_started | rows_returned | rows_expired | rows_expired_removed |
+------------+----------+---------------+---------------+--------------+----------------------+
| IX         |        2 |             1 |             8 |            8 |                    8 |
| PK         |        3 |            10 |            16 |            8 |                    8 |
+------------+----------+---------------+---------------+--------------+----------------------+

在这两种情况下都是，但是rows_expired在事务提交之后，而在回滚之后所有这些都被删除了。8rows_expired_removed0