问当业务规则不严格时，最佳合适的事务隔离级别

EN

简短版本:我正在尝试确定我们的处所中的SQL服务器的最佳事务隔离级别。

长版本:我从API调用中提取数据并将其加载到暂存表中，然后将这些表增量加载到目标表中。这些目标表以多种方式使用，其中一些如下所述：

refreshes)

• Apply

• 通过SSIS

• Feed PowerBI报告将数据加载到CRM中(对数据进行计划的documents

• (Most业务转换并将其加载到excel documents

• (Most中，重要的是)对初始ETL流程之外的目标表进行更改(从API到过渡到Destination)

)。

由于数据集庞大，我面临的问题是：

1. 死锁，我通过使用临时表和CTEs
2. 来避免这种死锁(因为更新目标表的一个存储过程可能会等待一个小时，直到另一个更新不使用该表)，
3. ，长PowerBI刷新等待，有时刷新超时，当SQL表被更新时，
4. 长选择语句等待，当SQL表被更新时

G 221

鉴于此：

1. --我从事的行业不是银行业，也不是一种数据需要100%准确的行业，
2. PowerBI报告每天只刷新两次
3. 我迫切需要利用这些目标表中的数据用于其他报告目的
4. 数据集包含数百万条记录(

G 231)

这个场合适合的隔离程度是多少？还是通过表提示设置单独的隔离级别更好呢？

Note1 :我和我的雇主不介意我们在报告刷新中进行一些脏的读取，只要这意味着报表以相应的方式刷新，并且这些表可以在其他存储过程(读取和更新)中使用，而无需等待。

Note2 :Note2服务器中的is_read_committed_snapshot_on为0。