SET-ting ALLOW_SNAPSHOT_ISOLATION ON 有何含义？

我应该跑吗

ALTER DATABASE DbName SET ALLOW_SNAPSHOT_ISOLATION OFF

如果暂时不使用快照事务（TX）隔离（iso）？
换句话说，

• 首先为什么要启用它？
• 为什么默认情况下不启用？

在 SQL Server 中启用（但暂时不使用）它的成本是多少？

- 更新：
在数据库上启用快照 TX iso 级别不会将 READ COMMITTED tx iso 更改为默认值。
您可以通过运行来检查它：

use someDbName;
--( 1 )
alter database someDbName set allow_snapshot_isolation ON;
dbcc useroptions;

最后一行显示当前会话的 tx iso 级别为（已提交读取）。

因此，启用快照 tx iso 级别而不更改它不会使用它，等等 为了使用它，应该发出

--( 2 )
SET TRANSACTION ISOLATION LEVEL SNAPSHOT

Update2:
我重复 [1] 中的脚本，但启用了 SNAPSHOT（但未打开），但未启用 READ_COMMITTED_SNAPSHOT

--with enabling allow_snapshot_isolation
alter database snapshottest set allow_snapshot_isolation ON

-- but without enabling read_committed_snapshot
--alter database snapshottest set read_committed_snapshot ON
-- OR with OFF
alter database snapshottest set read_committed_snapshot OFF 
go

执行没有结果/行

select * from sys.dm_tran_version_store

执行 INSERT、DELETE 或 UPDATE 后

您能否向我提供脚本，说明通过 ( 1 ) 启用 SNAPSHOT tx iso 级别但未通过 ( 2 ) 开启会在 tempdb 中生成任何版本和/或增加每行 14 字节的数据大小？
我真的不明白如果版本控制由（1）启用但未使用（未由（2）设置），那么版本控制的意义是什么？

[1]
在 SQL Server 中管理 TempDB：TempDB 基础知识（版本存储：简单示例）
Link https://learn.microsoft.com/en-us/archive/blogs/sqlserverstorageengine/managing-tempdb-in-sql-server-tempdb-basics-version-store-simple-example

一旦在数据库中启用行版本控制（又名快照），所有写入都必须进行版本控制。在什么隔离级别下进行写入并不重要，因为隔离级别总是会影响only读。一旦启用数据库行版本控制，任何插入/更新/删除都将：

• 将数据大小增加为每行 14 字节
• 可能在版本存储（tempdb）中更新之前创建数据的映像

同样，使用什么隔离级别完全无关。请注意，如果满足以下任一条件，也会发生行版本控制：

• 表有一个触发器
• 连接上已启用 MARS
• 在线索引操作正在表上运行

所有这些都在行版本控制资源使用情况 http://msdn.microsoft.com/en-us/library/ms175492.aspx:

每个数据库行最多可以使用 14 行末尾的字节数 版本控制信息。行 版本控制信息包含 交易序列号 提交版本的事务 以及指向版本化行的指针。 这14个字节是添加了第一个 修改行的时间，或者当 插入新行, under any这些条件中：

• READ_COMMITTED_SNAPSHOT 或 ALLOW_SNAPSHOT_ISOLATION 选项是 在。
• 该表有一个触发器。
• 正在使用多个活动结果集 (MARS)。
• 当前正在表上运行在线索引构建操作。

...

行版本必须存储为 只要活跃交易需要 访问它。 ...如果满足any的 以下条件：

• 它使用基于行版本控制的隔离。
• 它使用触发器、MARS 或在线索引构建操作。
• 它生成行版本。

Update

:setvar dbname testsnapshot

use master;

if db_id('$(dbname)') is not null
begin
    alter database [$(dbname)] set single_user with rollback immediate;
    drop database [$(dbname)];
end
go

create database [$(dbname)];
go

use [$(dbname)];
go


-- create a table before row versioning is enabled
--
create table t1 (i int not null);
go
insert into t1(i) values (1);
go

-- this check will show that the records do not contain a version number
--
select avg_record_size_in_bytes 
from sys.dm_db_index_physical_stats (db_id(), object_id('t1'), NULL, NULL, 'DETAILED')
-- record size: 11 (lacks version info that is at least 14 bytes)


-- enable row versioning and and create an identical table
--
alter database [$(dbname)] set allow_snapshot_isolation on;
go

create table t2 (i int not null);
go

set transaction isolation level read committed;
go

insert into t2(i) values (1);
go

-- This check shows that the rows in t2 have version number
--
select avg_record_size_in_bytes
     from sys.dm_db_index_physical_stats (db_id(), object_id('t2'), NULL, NULL, 'DETAILED')
-- record size: 25 (11+14)

-- this update will show that the version store has records
-- even though the isolation level is read commited
--
begin transaction;
update t1 
    set i += 1; 
select * from sys.dm_tran_version_store;
commit;
go

-- And if we check again the row size of t1, its rows now have a version number
select avg_record_size_in_bytes
from sys.dm_db_index_physical_stats (db_id(), object_id('t1'), NULL, NULL, 'DETAILED')
-- record size: 25