首页/资讯中心/详情

SQL Server 并发控制：Fabric Warehouse只支持快照隔离

SQL Server 并发控制：Fabric Warehouse只支持快照隔离
📅 发布时间：2026/6/19 3:52:45

Fabric Warehouse只支持快照隔离，这是强制执行的，且不能修改隔离级别，还是默认省略SET ISOLATION SNAPSHOT 语句。

一，Fabric Warehouse 只支持快照隔离级别

不同于传统的数据仓库，Fabric Warehouse对所有事务强制执行快照隔离（Snapshot isolation）。快照隔离是一种基于行的隔离级别，它为数据提供事务级的一致性，并使用存储在 tempdb 中的行版本来选择要更新的行。事务使用事务开始时存在的数据行版本。这确保每个事务都基于事务开始时数据的一致快照进行操作。

在快照隔离中，事务中的查询看到的是相同的版本（或快照），该版本基于事务开始时数据库的状态。在快照隔离中，修改数据的事务不会阻塞读取数据的事务，读取数据的事务也不会阻塞写入数据的事务。这种乐观的非阻塞行为也显著降低了复杂事务发生死锁的可能性。

如果您使用 T-SQL 更改隔离级别，则该更改在查询执行时将被忽略，并应用快照隔离。

SQL Server 和 Fabric Warehouse 快照隔离的基本区别在于：

区别1：在 SQL Server 中，只要没有事务同时尝试更新同一行，多个事务就可以修改同一表中的数据；而在 Fabric 中，这是不可能的——即使不是同一行，多个事务也不能修改同一张表中的任何行。

区别2：Fabric Warehouse的Snapshot Isolation中的锁模式：

  • Locks are at the table level
  • Lock types (modes):
    • SELECT: Schema-Stability (Sch-S)
    • INSERT, UPDATE, DELETE, COPY INTO: Intent Exclusive (IX)
    • DDL: Schema-Modification (Sch-M)

1， 读取数据

在读取数据时使用快照隔离级别，如果我们想要从多个表中读取数据，并确保返回的数据来自同一时间点，那么快照隔离级别就能帮助我们实现这一目标。通过发起事务并读取数据，系统会从表中返回事务发起时的数据。在读取事务期间，表上的数据可以进行修改，但这不会影响最终结果。

image

微软文档指出：“事务还可以用于顺序执行 SELECT 语句，以确保所有涉及的表都包含来自同一时间点的数据。”

读取数据不会阻塞修改操作（Insert，Update和Delete），但是读取到的数据是修改操作开始前的原始数据。不会收到修改操作的影响，即使修改事务的提交时间早于读事务提交的时间。

2，修改数据

如果多个事务同时作用于同一张表，那么最先提交的事务会成功，其他事务将会回滚并返回错误。没错，并非是哪个事务先启动……这意味着，如果你有一个耗时较长的 UPDATE 查询，而另一个 UPDATE 查询在它之前启动并提交，那么很遗憾，你耗时较长的 UPDATE 查询将会失败。

微软文档中写道：“两个或多个并发事务更新表中的一行或多行时产生的冲突，会在事务结束时进行评估。第一个提交的事务会成功完成，其他事务将被回滚并返回错误。”

image

3，插入数据

插入数据时的行为与更新/删除数据时的行为不同。由于多个事务同时插入新数据时，它们会写入新的 Parquet 文件，因此发生冲突的可能性要小得多。对表加锁是为了确保不会对表结构进行任何修改。

微软文档指出：“INSERT 语句总是创建新的 Parquet 文件，这意味着除了 DDL 事务之外，与其他事务的冲突更少，因为 DDL 事务的表结构可能会发生变化。”

image

4，删除数据

删除操作与更新操作的行为方式相同，先提交的删除事务会胜出，即如果发起一个 DELETE 事务，随后又发起并提交了另一个 DELETE 事务，则原始 DELETE 事务由于未提交将回滚并失败。

报错信息和Update操作相同：

Snapshot isolation transaction aborted due to update conflict. Using snapshot isolation to access table ‘DimProducts’ directly or indirectly in database ‘SalesDataWarehouse’ can cause update conflicts if rows in that table have been deleted or updated by another concurrent transaction. Retry the transaction.

二，了解 Fabric Warehouse中的写写冲突

当两个事务尝试对同一张表执行 UPDATE、DELETE、MERGE 或 TRUNCATE 操作时，可能会发生写写冲突。

由于 Fabric 数据仓库使用表级锁定，因此表级也可能出现写写冲突或更新冲突。即使两个事务尝试修改同一张表中的不同行，它们仍然可能发生冲突。

写写冲突主要是由多个用户或进程同时修改同一张表引起的，如果发生写写冲突，您可能会看到如下错误消息：

  • Error 24556: Snapshot isolation transaction aborted due to update conflict. Using snapshot isolation to access table '%.*ls' directly or indirectly in database '%.*ls' can cause update conflicts if rows in that table have been deleted or updated by another concurrent transaction. Retry the transaction.
  • Error 24706: Snapshot isolation transaction aborted due to update conflict. You cannot use snapshot isolation to access table '%.*ls' directly or indirectly in database '%.*ls' to update, delete, or insert the row that has been modified or deleted by another transaction. Please retry the transaction.

如果您遇到这些错误消息，则表示一个或多个事务已成功执行，但一个或多个冲突事务失败。请重试失败的事务。

三，查看Fabric Warehouse的锁

SELECTDB_NAME(resource_database_id) AS DatabaseName,OBJECT_NAME(resource_associated_entity_id) AS ObjectName,resource_type,CASE request_modeWHEN 'IX' THEN 'Intent Exclusive'WHEN 'Sch-S' THEN 'Schema Stability'WHEN 'Sch-M' THEN 'Schema Modification'WHEN 'S' THEN 'Shared'WHEN 'U' THEN 'Update'WHEN 'X' THEN 'Exclusive' WHEN 'IS' THEN 'Intent Shared' WHEN 'IU' THEN 'Intent Update' WHEN 'IX' THEN 'Intent Exclusive'WHEN 'SIU' THEN 'Shared Intent Update' WHEN 'SIX' THEN 'Shared Intent Exclusive' WHEN 'UIX' THEN 'Update Intent Exclusive'ELSE request_modeEND AS LockRequestModeDesc,request_mode,request_type,request_status,request_reference_count,request_session_id,resource_associated_entity_id
FROM sys.dm_tran_locks

四，查看tempdb的使用

在 Microsoft Fabric 中，数据仓库对所有事务都使用快照隔离。当数据被修改时，Fabric 引擎会在 tempdb 中创建并存储行版本，以确保读取的一致性。由于 tempdb 是一个受管系统数据库，您无法直接访问它，但可以通过 Fabric 内置的监控工具来监控和管理 tempdb 的使用情况。

Snapshot Isolation影响tempdb的四种方式：
  • Row versioning: When a SNAPSHOT isolation transaction begins, it receives a transaction sequence number. When that transaction needs to read data, it retrieves the row version from tempdb that was current at the time the transaction started.
  • Copy-on-write: Whenever a row is modified (updated or deleted), a copy of the original committed row is moved to the version store in tempdb before the change is applied to the main table. This allows other transactions to continue reading the original data without being blocked.
  • Write-write conflicts: In Fabric, snapshot isolation operates at the table level for updates and deletes, not just the row level as in traditional SQL Server. This means concurrent modification operations on the same table will cause a write-write conflict and one transaction will be aborted.
  • Long-running transactions: If a transaction is long-running, it can retain a large number of row versions in tempdb, potentially causing excessive disk usage. 
由于 tempdb 由 Fabric 管理，因此您无法像在传统 SQL Server 中那样运行类似 `sys.dm_db_file_space_usage` 的 T-SQL 查询。您必须使用以下工具：
  1. Fabric Capacity Metrics App
  2. Performance Dashboard

 

参考文档：

Transactions and Isolation Levels in Fabric Warehouse

Transactions in Fabric Data Warehouse