SQL Server 2014 内存中 OLTP - 事务回滚时的垃圾收集

Question

在 SQL Server 2014 中，内存中 OLTP，如果事务回滚并且不再需要新创建的行版本，会发生什么。垃圾收集器是否有责任删除此类行，或者在事务回滚时会在运行时收集此类垃圾？

Answer 1

我从 SIGMOD 论文Hekaton: SQL Server's Memory-Optimized OLTP Engine中了解到，它的处理方式与其他类型的垃圾相同。

几个相关的部分是

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是8在这两种情况下，但rows_expired_removed在0下面的事务提交，而全部都是在回滚后取出。