数据仓库的隔离级别

Question

我们正在我们的组织中建立一个数据仓库（以及一些数据集市）。我的 DBA 技能主要用于 OLTP 类型的应用程序，但我正在为我们的组织支持 OLAP。

我们最近遇到了一个问题，我们的一个 ETL 程序（在本例中恰好是一个用 Java 编写的消息驱动 Bean）正在使用可重复读取 (RR) 隔离级别。因此，他们遇到了锁。我显然质疑为什么使用 RR。（编辑：我原本以为是DB2端的RR，后来了解到这是JDBC端的RR，映射到DB2端的RS。此后我们也尝试了JDBC端的RC，也就是DB2端的CS 。这似乎解决了一些锁定问题。）

所以我开始从提要/源端和检索端研究数据仓库的建议隔离级别应该是什么。

我真的找不到太多。我发现有几篇文章提到未提交的读取 (UR) 对查询/检索方面有好处，但没有提到馈送方面。我在想应该使用光标稳定性 (CS) 或最高读取稳定性 (RS)。我会站在 CS 一边，但也许这受到了 OLTP 思维的影响？

在我们的例子中，我们仓库的主要提要现在使用 Java 消息队列“实时”完成。从仓库中检索将使用 ETL 工具（在我们的案例中为 DataStage）完成，可能作为夜间作业开始（一些用于每日报告，其他用于月度或季度报告）。这些报告将基于我们的市场。因此，虽然仓库可能会被“实时”提供，但不会被读取或主动查询（至少现在不是）。

诚然，我们使用 DB2 9.7 FP 4（我们希望在明年某个时候迁移到 10.1），并且每个供应商的某些细节可能不同，但是您对 DBA 推荐的提要和读取的隔离级别是什么？为什么？

此外，任何有关 marts 隔离级别的输入都将不胜感激。

编辑：这样就更容易与其他供应商进行比较。这是映射到 JDBC 隔离级别的 DB2 隔离级别名称表。（这是根据《理解 DB2：通过示例直观地学习》一书，因此版权 IBM。）

+------------------------------+-----------------------+
|            JDBC              |          DB2          |
+------------------------------+-----------------------+
| TRANSACTION_READ_UNCOMMITTED | Uncommitted Read (UR) |
+------------------------------+-----------------------+
| TRANSACTION_READ_COMMITTED   | Cursor Stability (CS) |
+------------------------------+-----------------------+
| TRANSACTION_REPEATABLE_READ  | Read Stability   (RS) |
+------------------------------+-----------------------+
| TRANSACTION_SERIALIZABLE     | Repeatable Read  (RR) |
+------------------------------+-----------------------+

Answer 1

对于大多数数据库（包括数据仓库），已提交读是足够的隔离级别。由于可能出现错误答案，我不会使用未提交的读取。在 SQL Server 上，我们还可以添加读提交快照隔离。此版本行并避免查询被更新阻止。不知道DB2上有没有类似的东西。