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

Question

短版： 我正在尝试确定哪个是我们场所内 SQL 服务器的最佳事务隔离级别。

长版： 我从 API 调用中提取数据并将其加载到登台表中，然后逐步加载到目标表中。这些目标表有多种使用方式，其中一些在下面提到：

1. 通过 SSIS 将数据加载到 CRM 中
2. Feed PowerBI 报告（计划刷新）
3. 对数据应用业务转换并将其加载到数据仓库中
4. 将数据提取到 Excel 文档中
5. （最重要的是）在初始 ETL 过程之外更改目标表（从 API 到暂存到目标）

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

1. 我通过使用临时表和 CTE 避免了死锁
2. 表更新之间的等待时间很长（因为更新目标表的一个存储过程可能会等待长达一个小时，直到该表未被另一个更新使用）
3. 在更新 SQL 表时，PowerBI 刷新等待时间较长，有时刷新超时
4. 在更新 SQL 表时等待长选择语句

鉴于：

1. 我工作的行业不是银行业，也不是数据需要始终 100% 准确的行业
2. PowerBI 报告每天仅刷新两次
3. 我也迫切需要将这些目标表中的数据用于其他报告目的
4. 数据集包含数百万条记录

什么隔离级别适合这种场合？还是通过表格提示设置单独的隔离级别会更好？

注意1：我的雇主和我不介意我们在报告刷新中是否有一些脏读，只要这意味着报告以随后的方式刷新并且表可以在其他存储过程中使用（读取和更新）无需等待。

注意 2：我们的 SQL 服务器中的 is_read_committed_snapshot_on 为 0。

Answer 1

为数据库设置READ COMMITTED SNAPSHOT ISOLATION的READ COMMITTED可以让读者在不被写者阻塞的情况下读取，防止写者被读者阻塞，并且不会造成脏读。

这是显而易见的第一步。