简介： 在 DB2 V9.7.1 的高可用性灾难恢复（High Availability Disaster Recovery ，简称 HADR）功能中，增加了一个新特性，即支持在备机上的只读操作（Reads On Standby， 简称 RoS）。本文的目的是介绍这项功能的具体配置、应用、注意事项以及使用限制，为读者提供一个快速参考。为了更好地理解该项新功能，本文在一开始还简单介绍了 HADR 的基础知识。
在最新的 DB2 V9.7.1 中，引入了一项高可用性灾难恢复（High Availability Disaster Recovery，简称 HADR）环境下的新功能：备机可读（Reads On Standby，简称 RoS）。利用该功能，能够有效分担主机数据库（Primary DB）的工作负载，充分利用备机数据库（Standby DB）运行一些读操作的应用，以达到资源更加优化的目的。
为了更好理解备机可读这一新功能，我们先从高可用性灾难恢复的基本概念开始。
从 V8.2（当时称作 DB2 Universal Database， DB2 通用数据库）开始，DB2 引入了一种新的、源自于 Informix 的高可用性解决方案：高可用性灾难恢复（即 HADR）。在高可用性灾难恢复环境中，通常有两台物理的数据库服务器，即主数据库（Primary DB）和备机数据库（Standby DB），它们分别位于两个有一定距离间隔的数据中心（如图 1 所示）。
主数据库（Primary DB），能够接受日常的增删改查等应用操作，这些操作产生的数据库日志（Log）通过 TCP/IP 协议传送给备机数据库（Standby DB）。由于数据库事务都是基于日志的，备机数据库通过重做（Replay）这些日志，就能够重现主数据库服务器上相应的操作，从而使得两个数据库中的数据能够基本保持在一致的状态。
在主数据库出现宕机，如地震、火灾、断电等灾难或问题，导致数据库不可访问或者损坏的时候，备机数据库能够很快接管（Takeover）主数据库的工作和任务，成为新的主机数据库（如图 2 所示）。由于备机数据库中的数据在主数据库出现问题之前一致保持着与主数据库相接近状态，因此应用程序能够直接连接到新的主数据库（即旧的备机数据库）上，这样就能把业务中断够减小到最低限度。
最初在引入 HADR 作为高可用性方案的时候，备机数据库仅仅是作为主数据库的备用设备，其唯一功能就是重做主数据库传递来的数据库日志，使其数据状态跟主数据库保持一致，以便在主数据库出现问题的时候接管应用。所以，备机数据库一直处于脱机（offline）状态，也就是说，在接管之前，不允许用任何应用程序连接，这样在一定程度上导致了资源的浪费。因此，在最新的 DB2 LUW V9.7.1（DB2 Linux Unix and Windows, Version 9.7 Fix Pack 1）中，引入了备机可读的功能，提高了备机数据库的利用率，这正是本文要讨论的主题。
上文已经提到，在最新的 DB2 版本中，在备机上已经支持可读操作，原先在主数据库上的只读应用，例如生成报告、决策支持、商业智能应用等，现在都可以迁移到备机数据库上进行，这样，即在一定程度上减轻了主数据库的负载，又提高了备机数据库的利用率。如图 3 所示。
接下来，让我们来快速配置一个备机可读的环境，体验一下这项令人激动的新功能吧！
1. 安装 DB2 V9.7.1，并配置高可用性灾难恢复环境。这并不是本文讨论的重点，请读者参考相应文档。
2. 打开高可用性灾难恢复的备机可读功能。
这需要在备机数据库上设置一个 DB2 的注册变量（Registry Variable）—— DB2_HADR_ROS。将该变量设置为 1，或者 yes，或者 on，可将备机可读功能打开；设置为空，或者不设置该注册变量的值，则表示不启用备机可读功能，这时候备机数据库跟之前版本 DB2 中的备机数据库一样，只进行数据库日志重做，不接受任何应用连接。
$ db2set DB2_HADR_ROS=1 |
小窍门：设置DB2中的注册变量
注意：跟其他DB2注册变量一样，设置DB2_HADR_ROS之后，需要重新启动DB2数据库实例（Instance），以使其生效。要重启数据库实例，使用db2stop命令停止DB2数据库实例，然后用db2start启动DB2数据库实例：
$ db2stop SQL1064N DB2STOP processing was successful. $ db2start SQL1063N DB2START processing was successful. |
3. 激活备机数据库
要激活备机数据库，使用 ACTIVATE DB 命令（这里使用名为 HADRDB 的数据库作为例子）：
$ db2 ACTIVATE DB hadrdb DB20000I The ACTIVATE DATABASE command completed successfully. |
小窍门 —— 激活数据库
注意：激活备机数据库与激活主数据库有所不同。通常主数据库或者标准环境下的数据库，不需要显示使用ACTIVATE DB命令激活，该类数据库会在第一个应用连接的时候被激活。在备机可读环境下的备机数据库，需要显示运行ACTIVATE DB命令来激活数据库，才能使数据库处于在线（online）状态。若不使用ACTIVATE DB来激活备机数据库，这时候尝试连接备机数据库会得到以下错误：
$ db2 CONNECT TO hadrdb SQL1776N The command is not supported on an HADR standby database or on an HADR standby database with the current configuration or state. Reason code = "1". |
至此，备机可读环境已经配置完成，接下来验证一下。
首先，在主数据库上建立一张新表，并插入若干条记录：
$ db2 CONNECT TO hadrdb Database Connection Information Database server = DB2/LINUXX8664 9.7.1 SQL authorization ID = XUJING Local database alias = HADRDB $ db2 "CREATE TABLE test(C1 INT, C2 CHAR(1))" DB20000I The SQL command completed successfully. $ db2 "INSERT INTO test VALUES(1, 'A'), (2, 'B'), (3, 'C')" DB20000I The SQL command completed successfully. |
然后在备机数据库上查询该表，如果可以看到这些记录已经出现在备机数据库中了，此时说明高可用性灾难恢复的备机可读已经配置成功：
$ db2 CONNECT TO hadrdb Database Connection Information Database server = DB2/LINUXX8664 9.7.1 SQL authorization ID = XUJING Local database alias = HADRDB $ db2 "SELECT * FROM test" C1 C2 ----------- -- 1 A 2 B 3 C 3 record(s) selected. |
小窍门 尽早提交主数据库上的事务
注意：在验证上述命令时，在主服务器上运行完CREATE TABLE 和 INSERT 命令后， 请务必要提交该事务， 否则会导致备机数据库进入不可读窗口 （Replay Only Window，参见本文第四部分）。要提交事务，可以使用下列两种方法中的任意一种：
- 显示使用COMMIT命令提交事务
- 将命令行选项中的自动提交打开（该参数默认打开）
$ db2 UPDATE COMMAND OPTIONS USING C ON |
打开该选项之后，随后输入的SQL命令都会被自动提交。
在提供备机可读功能之前，要验证高可用性灾难恢复环境是否配置成功，相对来说比较麻烦。类似的，首先在主数据库建表、插入数据，要检查这些数据是否已经传递到备机上，随后必须使备机数据库接管成为新的主数据库之后，才能在上面检查之前的操作是否已经生效。从此可以看出，高可用性灾难恢复的备机可读功能，同时也为快速配置高可用性灾难与恢复环境提供了一个快速有效的验证方法。
在开始介绍备机可读的隔离级别之前，先简单介绍一下隔离级别的基本概念。
在数据库系统中，并发（Concurrency）控制和事务（Transaction）的实现离不开锁（Locks）和隔离级别（Isolation Levels）。在 DB2 中，有以下五种隔离级别：
- 可重复读（Repeatable Read，简称 RR）
- 读稳定（Read Stability，简称 RS）
- 游标稳定（Cursor Stability，简称 CS）
- 当前已提交（Currently Committed，简称 CC，DB2 V9.7 新加入）
- 未提交读（Uncommitted Read，俗成“脏读”，简称 UR）
关于这些隔离级别的具体定义和最佳实践，不是本文讨论的重点，读者如果感兴趣，可以参考相应文档。
一般 DB2 应用程序的默认隔离级别是游标稳定（CS），并且可以根据需要改变隔离级别。在 DB2 中，应用程序的隔离级别可以通过以下几种方式来指定：
1. 在绑定（bind）应用程序时指定隔离级别，例如：
$ db2 BIND sample.bnd ISOLATION UR LINE MESSAGES FOR sample.bnd ------ -------------------------------------------------------------------- SQL0061W The binder is in progress. SQL0091N Binding was ended with "0" errors and "0" warnings. |
2. 在应用程序中使用 SET CURRENT ISOLATION 命令指定隔离级别，例如：
清单 9. 使用 SET CURRENT ISOLATION 设置隔离级别
$ db2 SET CURRENT ISOLATION UR DB20000I The SQL command completed successfully. |
3. 在 SQL 语句中指定隔离级别，例如：
$ db2 "SELECT * FROM test WITH UR" ... 3 record(s) selected. |
通常来说，在 SQL 语句中设置的隔离级别优先级最高，其次是应用程序中使用 SET CURRENT ISOLATION 命令设置的隔离级别，最后才是在绑定时使用的隔离级别，也就是说，在语句中设置的隔离级别，会覆盖当前应用 SET CURRENT ISOLATION 命令所设置的隔离级别；而当前应用 SET CURRENT ISOLATION 命令设置的隔离级别，会覆盖在绑定时设定的隔离级别。
现在，回到高可用性灾难恢复的备机可读功能的主题上来。在备机可读环境下，只读的应用程序只能使用未提交读（UR，即“脏读”）来读取数据，并且该隔离级别不能改变。原因很简单，高可用性灾难与恢复的基础是数据库日志的传输（Log Shipping）。主数据库上的数据操作会产生数据库日志，这些日志通过 TCP/IP 传输到备机数据库，备机数据库通过重做这些操作，重现在主数据库上的数据操作，实现隔离级别的重要工具——锁，并没有从主数据库传递到备机数据库上，因而在备机数据库进行日志重做的时候，也就无法对数据库对象施加锁保护。这时候只读的应用程序连接到备机数据库上，必然只能以未提交读（UR）的隔离界别读取数据，无法用其他更高级别的隔离级别来。
备机可读的环境下，备机数据库不支持第一种指定隔离级别的方式，因为绑定（bind）实质上是一种写操作。如果在备机上运行带有写操作的命令，会得到错误 SQL1773N，原因代码 5，该错误消息的具体含义，请参考 DB2 LUW Information Center V9.7 的在线文档。关于备机可读环境下不支持的操作，请参考本文的第五部分：不支持的操作。
例如，使用绑定在备机上指定隔离级别，会得到以下错误：
$ db2 BIND sample.bnd ISOLATION CS LINE MESSAGES FOR sample.bnd ------ -------------------------------------------------------------------- SQL0061W The binder is in progress. SQL1773N The statement or command requires functionality that is not supported on a read-enabled HADR standby database. Reason code = "5". SQL0082C An error has occurred which has terminated processing. SQL0092N No package was created because of previous errors. SQL0091N Binding was ended with "3" errors and "0" warnings. |
在备机可读的环境下，使用 SET CURRENT ISOLATION 命令设置应用程序的隔离级别为非未提交读（UR），可以设置成功，但是实际上该应用程序还是使用为提交读（UR）的隔离级别。例如：
清单 12. 在备机数据库上通过 SET CURRENT ISOLATION 设置隔离级别
$ db2 SET CURRENT ISOLATION RR DB20000I The SQL command completed successfully. $ db2 VALUES CURRENT ISOLATION 1 -- RR 1 record(s) selected. |
在备机可读环境中，在 SQL 语句中也可指定隔离级别，例如：
$ db2 "SELECT * FROM test WITH RR" C1 C2 ----------- -- 1 A 2 B 3 C 3 record(s) selected. |
类似的，该设置依然不会生效，该查询语句依然使用的是未提交读（UR）的隔离级别。
要验证这些在备机上的查询语句使用的隔离级别是未提交读（UR），步骤比较复杂。
首先，假设在主数据库上已经建好相应的表，此时在主数据库上关闭自动提交，并插入数据，不提交也不回滚，使当前事务处于开放状态。其他事务如果使用非未提交读（UR）隔离级别，就应该看不到当前事务插入的、但是未提交的这些记录，输出如下所示：
清单 14. 在验证备机可读环境下隔离级别时，主数据库上的命令：连接 1
db2 => CONNECT TO hadrdb Database Connection Information Database server = DB2/LINUXX8664 9.7.1 SQL authorization ID = XUJING Local database alias = HADRDB db2 => UPDATE COMMAND OPTIONS USING C OFF DB20000I The UPDATE COMMAND OPTIONS command completed successfully. db2 => INSERT INTO test VALUES(4, 'A'), (5, 'B'), (6, 'C') DB20000I The SQL command completed successfully. |
然后，在主数据库上，再开始一个事务，然后运行如下查询：
清单 15. 在验证备机可读环境下隔离级别时，主数据库上的命令：连接 2
$ db2 connect to hadrdb Database Connection Information Database server = DB2/LINUXX8664 9.7.1 SQL authorization ID = XUJING Local database alias = HADRDB $ db2 "SELECT * FROM test WITH CS" C1 C2 ----------- -- 0 record(s) selected. $ db2 "SELECT * FROM test WITH UR" C1 C2 ----------- -- 4 A 5 B 6 C 3 record(s) selected. $ db2 "INSERT INTO test VALUES ( 0, 'Z')" DB20000I The SQL command completed successfully. |
从上面的结果可以看出，第一条查询语句使用了游标稳定（CS）的隔离级别，读取不到前一个事务中未提交的记录，第二条查询语句使用了未提交读（UR）的隔离级别，得到了前一事务中未提交的记录。
最后，向表中插入一条记录，由于自动提交在这个事务中是打开的，所以这条记录会被自己动提交，能够被其他事务中读取。我们用这条已提交的记录，作为接下来在备机上查询的参考基准。
现在，在备机上运行查询：
清单 16. 在验证备机可读环境下隔离级别时，备机数据库上的命令
$ db2 SET CURRENT ISOLATION CS DB20000I The SQL command completed successfully. $ db2 "SELECT * FROM test" C1 C2 ----------- -- 0 Z 4 A 5 B 6 C 4 record(s) selected. $ db2 "SELECT * FROM test WITH UR" C1 C2 ----------- -- 0 Z 4 A 5 B 6 C 4 record(s) selected. $ db2 "SELECT * FROM test WITH CS" C1 C2 ----------- -- 0 Z 4 A 5 B 6 C 4 record(s) selected. |
从上面的运行结果可以看出，备机上的查询不论是游标稳定（CS）还是未提交读（UR）的隔离级别，都获取了主数据库上未提交和已提交的数据。即使在应用程序中使用 SET CURRENT ISOLATION 命令设置非 UR 的隔离级别，查询依旧能够读取到主数据库上已提交和未提交的数据。能够获取其他事务未提交的数据，应用程序必然是在未提交读（UR）的隔离级别上进行的读操作。从上面的结果我们可以得出结论，事实上在备机上不论指定任何隔离级别，查询都会并且只能以未提交读（UR）的隔离级别运行。
为了控制高可用性灾难恢复的备机可读环境下备机上应用程序的隔离级别，在 DB2 V9.7.1 中引入了一个新的注册变量：DB2_DEFAULT_ISO_SECONDARY。在应用程序使用高于未提交读（UR）的隔离级别读取数据时，通过设置该注册变量的值，能够控制备机数据库的行为。既可以没有任何错误或警告信息，强制把该应用程序的隔离级别转化成未提交读，也可以抛出相应错误消息。
刚才提到，在 DB2 中，应用程序的默认隔离级别是游标稳定（CS）。要改变或设置改默认隔离级别，可以通过设置注册变量 DB2_DEFAULT_ISOLATION_VALUE 来实现。
由此，上述两个注册变量组合起来，备机数据库会有以下几种行为：
- 当 DB2_DEFAULT_ISO_SECONDARY=on, DB2_DEFAULT_ISOLATION_VALUE=any value 时
此时，不论应用程序使用何种隔离级别，都会被强制转换成未提交读（UR）。
- 当 DB2_DEFAULT_ISO_SECONDARY=off, DB2_DEFAULT_ISOLATION_VALUE=not UR 时
使用高于未提交读（UR）隔离级别的应用程序，在备机上运行时，会得到错误消息 SQL1773N，原因代码 1。
- 当 DB2_DEFAULT_ISO_SECONDARY=off, DB2_DEFAULT_ISOLATION_VALUE=UR 时
隔离级别高于未提交读（UR）的动态应用程序，不会收到任何出错消息，隔离级别会被强制转换成未提交读（UR）；对于动态应用程序，若隔离级别高于未提交读（UR），则会收到错误消息 SQL1773N，原因代码 1。
在高可用性灾难恢复的备机可读环境中，由于在备机上的应用程序只能以未提交读的隔离级别进行读操作，有以下几条建议：
- 如果有应用程序需要使用高于未提交读的隔离级别，此时只能在主数据库上进行。
- 在编写应用程序时，如果可能，尽量使用未提交读的隔离级别。
- 对于现有的、隔离级别高于未提交读的应用程序，如果它们在未提交读的隔离级别下也能正常工作，那么，可以设置注册变量 DB2_DEFAULT_ISO_SECONDARY=off
在备机可读的环境下，备机并不是每时每刻都能够接受应用程序的连接、提供查询服务的。备机不能提供连接和查询功能的时间区间，被称为不可读窗口（Replay Only Window，即只重做（日志）窗口）。在此窗口的时间区间内，备机数据库只进行数据库日志重做，不提供连接和只读的服务，类似于没有启用备机可读功能的备机数据库。备机进入此窗口时，对于已经连接到备机数据库上的应用程序，连接会被服务器断开；从此刻开始，应用程序再向备机数据库发起连接的请求会被拒绝。直到不可读窗口结束后，备机才能接受新的连接，进而提供查询服务。
如下所示，在备机数据库上的连接被断开后，尝试访问数据库对象，会得到一下错误信息：
清单 17. 备机数据库处于不可读窗口时，尝试访问备机数据库对象时的错误消息
$ db2 LIST TABLES SQL1224N The database manager is not able to accept new requests, has terminated all requests in progress, or has terminated the specified request because of an error or a forced interrupt. SQLSTATE=55032 |
此时，再尝试连接备机数据库，会得到错误 SQL1776N，错误代码 4，如下所示：
清单 18. 备机数据库处于不可读窗口时，尝试连接备机数据库时的错误消息
$ db2 CONNECT TO hadrdb SQL1776N The command is not supported on an HADR standby database or on an HADR standby database with the current configuration or state. Reason code = "4". |
此时，我们可以使用 db2pd 工具查看不可读窗口的状态：
$ db2pd -d hadrdb -hadr ... ReplayOnlyWindowStatus ReplayOnlyWindowStartTime MaintenanceTxCount Active Wed Apr 14 05:15:44 2010 (1271247344) 1 ... |
在不可读窗口结束后，备机数据库又可以接受新的连接了，如下所示：
$ db2 CONNECT TO hadrdb Database Connection Information Database server = DB2/LINUXX8664 9.7.1 SQL authorization ID = XUJING Local database alias = HADRDB |
在明确什么是不可读窗口之后，现在开始讨论不可读窗口的触发条件。
在主数据库上运行数据定义语言语句（Data Definition Language, DDL）、某些数据处理语言语句（Data Manipulation Language, DML）或某些维护操作（Maintenance Operations），这些命令产生的日志传递到备机数据库，并开始被备机数据库重做时，备机数据库就会进入不可读区间，如图 4 所示。
当主数据库上的所有 DDL 语句所在的事务都已提交，并且所有维护操作全部结束后，相应的数据库日志传递当备机数据库，并且这些日志被重做完毕时，备机数据库的不可读窗口就会结束。也就是说，在同一时间，备机数据库上的不可读窗口可以重叠，只有在所有的不可读窗口都结束后，备机数据库才回到可以接受连接和读应用的状态，如图 5 所示。
图 5. 备机数据库上的不可读窗口（Replay Only Window）
在主数据库上运行后，会在备机数据库上会产生不可读窗口的 DDL（数据定义语言）语句包括但不限于：
- CREATE TABLESPACE 创建表空间
- ALTER TABLESPACE 修改表空间
- DROP TABLESPACE 删除表空间
- CREATE BUFFERPOOL 创建缓冲池
- DROP BUFFERPOOL 删除缓冲池
- CREATE TABLE 创建表
- ALTER TABLE 修改表
- RENAME TABLE 重命名表
- DROP TABLE 删除表
- CREATE VIEW 创建视图
- ALTER VIEW 修改视图
- DROP VIEW 删除视图
- CREATE INDEX 创建索引
- ALTER INDEX 修改索引
- RENAME INDEX 重命名索引
- DROP INDEX 删除索引
详细完整的 DDL 列表，请参考 DB2 LUW V9.7 Information Center。
在主数据库上运行后，会在备机数据库上会产生不可读窗口的 DML（数据处理语言）语句包括但不限于：
- 启用表级压缩的表发生的自动字典创建（Automatic Dictionary Creation, ADC）
- 被分离的分区表上的异步索引清楚（Asynchronous Index Cleanup，AIC）
- 隐式重绑定（Implicit Rebind）
- 隐式索引重建（Implicit Index rebuild）
- 手动修改统计信息（Statistics）
- 后台异步更新表 SYSJOBS 和表 SYSTASKS
在主数据库上运行后，会在备机数据库上会产生不可读窗口的维护操作包括：
- Classic Reorg 离线表 / 索引重组
- Inplace Reorg 在线表重组
- Load 装载数据
- BIND/REBIND 绑定 / 重绑定
- Runstats 采集统计数据
- Online Table move 在线移动表
- Auto statistics 自动统计
- Auto Reorg 自动表 / 索引重组
- Automatic storage management 自动存储管理
- Automatic resizing of tablespaces 表空间调整大小
- Real Time Statistics 实时统计
- IMPORT CREATE/REPLACE 带有创建或者替换模式的导入
请注意，以上维护操作包含一些 DB2 自动运行的操作，例如自动统计，自动重组。如果主数据库打开了这些功能，有可能在执行一些本不会引起不可读窗口的命令时，导致备机数据库进入不可读窗口。要避免这种意外情况的出现，可以在主数据库上关闭这些功能。
例如，使用以下命令在主数据库上关闭自动维护、自动统计和自动重组：
清单 18. 关闭自动维护操作
$ db2 UPDATE DATABASE CFG FOR hadrdb USING AUTO_MAINT OFF AUTO_RUNSTATS OFF AUTO_REORG OFF DB20000I The UPDATE DATABASE CONFIGURATION command completed successfully. |
关于以上操作的具体信息，不是本文讨论的重点，读者如感兴趣，可以参考 DB2 LUW Information Center V9.7 在线文档。
由于在主数据库上运行上述命令，会导致备机数据库上的应用被断开，所以推荐：
- 将会产生不可读窗口的命令尽量集中在一段时间内在主数据库上运行；
- 在主数据库上带有 DDL 的事务中，尽早提交事务，以缩短不可读窗口；
- 在主数据库上关闭主数据库上的自动维护功能
同时，如果主数据库有大量的、不确定时间的、会产生不可读窗口的命令和操作，此时不推荐使用备机可读功能。
在高可用性灾难恢复的备机可读环境下，备机支持只读的应用，但并不是说，备机数据库支持所有的读操作，某些很特别的读操作会被阻止。与此同时，备机数据库也不支持另一些操作，即任何可能会向备机数据库中写入数据的操作都会被阻止。
在备机可读环境下，备机上不支持的常见读操作包括以下几种：
1. 不支持访问以下数据类型的数据：
LONG，LOB，XML，UDT（User Defined Types，包括 distinct types 和 structured types）。在备机数据库上试图访问这些数据类型，会得到错误 SQL1773N，原因代码 3。
2. 不支持 Inspect
由于 Inspect 在检查数据库完整性的时候，会使用高于未提交读（UR）的隔离级别读取数据，但在备机上只支持未提交读（UR）的隔离级别；与此同时，带有某些选项的 Inspect 会向数据库中写入数据，因此，在备机数据库上使用 Inspect 会得到错误 SQL1773N，原因代码 5。
3. 不支持 Federation 联邦数据库
在备机可读环境下，备机不能配置为联邦数据库（Federation Server，SQL1776N， 原因代码 1 ）；同时，在主数据库上建立的昵称（nickname），不能在备机上访问。
4. 不支持访问临时表，包括 DGTT（Declared Global Temporary Tables）和 CGTT（Created Global Temporary Tables）
在主机上创建 CGTT 时，不论是指定带日志（LOGGED）还是不带日志（NOT LOGGED），在备机上 CGTT 都不可访问（错误 SQL1773N，原因代码 4）。
5. 不支持 Explain 工具
Explain 工具是用来检查查询语句的访问计划（Access Plans），它会将相应数据写入数据库表中，因此不被支持（错误 SQL1773N，原因代码 5）。
6. 不支持 db2ReadLog API
在备机上的应用程序如果调用 db2ReadLog API 接口，会得到错误 SQL1773N，原因代码 5。
在备机可读环境下，备机上不支持的常见写操作有以下几类：
1. 不支持绑定和重绑定（bind 和 rebind，包括显式和隐式）
由于绑定和重绑定都会向数据目录（catalog）中写入数据，所以在备机上不支持这两个操作（错误 SQL1773N，原因代码 6）。要将一个应用程序包（package，当然是只含有只读操作的）绑定到备机上，可以先在主数据库上进行绑定，然后将该应用程序的可执行文件拷贝到备机上，再运行。由于绑定会产生相应的数据库日志，在主机上做的绑定操作，会通过日志被传送到备机数据库上。待备机数据库重做完这些日志，相当于在备机数据库上做了绑定操作，这时，该应用程序包的相应信息就会出现在备机数据库的目录（catalog）中，这时候该应用程序就可以在备机上运行了。
2. 不支持 DDL（数据定义语言）语句
在备机上不支持写操作（SQL1773N，原因代码 5）。
3. 不支持插入（INSERT）、更新（UPDATE）、删除（DELETE）等 DML
在备机上尝试运行插入、更新、删除等写操作，会得到错误 SQL1773N，原因代码 5。
4. 不支持维护操作：操作列表参见第四部分中的维护操作列表
5. 不支持数据库备份（BACKUP DB）
在备机上不支持数据库备份，如果要备份数据库，请在主数据库上进行。
要查看在备机数据库上全部不支持操作的列表和详细信息，请参考 DB2 LUW V9.7 Information Center。
以上，我们快速浏览了 DB2 LUW V9.7.1 中的新功能——高可用性灾难备份的备机可读。该新功能为高可用性灾难恢复环境提供了一个更加经济高效的解决方案。通过该方案，能够在一定程度上减轻主数据库的工作负荷，同时增加备机数据库的利用率，从而使系统以更高性价比的运行。
原文链接:http://www.ibm.com/developerworks/cn/data/library/techarticles/dm-1007xuj/index.html
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/15082138/viewspace-671071/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/15082138/viewspace-671071/
扫一扫
3188
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
