关闭 HADR 对的建议顺序

警告： 

    尽管可对主数据库和/或备用数据库使用 STOP HADR 命令来停止 HADR，但应谨慎使用。

    如果要停止指定的数据库，但仍然想保留其 HADR 主数据库角色或备用数据库角色，请不要发出 STOP HADR 命令。 

    如果发出 STOP HADR 命令，那么该数据库将变为标准数据库，并且可能需要重新初始化才能继续作为 HADR 数据库运行。请改为发出 DEACTIVATE DATABASE 命令。


如果只想关闭 HADR 操作，那么下面是关闭 HADR 对的建议方法：

  1. 取消激活主数据库

  2. 对主数据库停止 DB2

  3. 取消激活备用数据库

  4. 对备用数据库停止 DB2


启动HADR,则刚好相反：

1、启动备库，备库启动后进入local catchup，remote catchup pending，会一直尝试连接主库。

2、启动主库，等待接收备库的连接，如果在规定的时间（hadr_timeout）不能收到备库的连接，则启动失败，这样是为了防止脑裂 brain split.一旦备库连接上主库，进入remote catchup状态。重放完主库传过来的日志后，进入peer状态。


HADR的索引：

建议：对于 HADR 数据库，将 logindexbuild 数据库配置参数设置为 ON，以确保为索引的创建、重新创建和重组记录完整的信息。虽然，这意味着在主系统上的索引构建可能需要更长时间和更多日志空间，但是在 HADR 日志重放期间，将在备用系统上重建索引，而且当发生故障转移时索引仍可用。否则，由于日志记录没有包含足够信息来填充新索引，因此，重放索引构建或重建事件时，备用系统会将索引标记为无效。如果不记录主系统上的索引构建，而且发生故障转移，那么在故障转移完成之后所剩的任何无效索引都必须重建，然后才能对其进行访问。当重新创建索引时，任何应用程序都无法对表进行访问。（访问具有无效索引的表的用户必须等待重建索引）

indexrec:

  • RESTART

  • indexrec 的缺省值。将在显式或隐式发出 RESTART DATABASE 命令时重建无效的索引。在前滚或 HADR 日志重放期间将重做任何完全记录的索引构建。当启动了 HADR 且发生 HADR 接管时，会在接管结束时重建任何无效的索引。


ADM5572I

One or more indexes on table tableName are marked invalid and require rebuilding.

Explanation

The DB2 data server will automatically rebuild the invalid indexes on this table. The rebuild is either for nonpartitioned indexes on a partitioned table or for indexes on a nonpartitioned table.

A super exclusive Z lock will be held on the table for the duration of the index rebuild and the unit of work in which the rebuild occurs.


创建index的并发（create index不同于重建index）：

Concurrent read/write access to the table is permitted while an index is being created, except when the EXTEND USING clause is specified. However, the default index creation behavior differs for indexes on nonpartitioned tables, nonpartitioned indexes, and partitioned indexes:

  • For indexes on nonpartitioned tables, once the index has been built, changes that were made to the table during index creation time are forward-fitted to the new index. Write access to the table is then briefly blocked while index creation completes, after which the new index becomes available.

  • For nonpartitioned indexes, once the index has been built, changes that were made to the table during index creation time are forward-fitted to the new index. Write access to the table is then briefly blocked while index creation completes, after which the new index becomes available.

  • For partitioned indexes, once the index partition has been built, changes that were made to the partition during creation time of that index partition are forward-fitted to the new index partition. Write access to the data partition is then blocked while index creation completes on the remaining data partitions. After the index partition for the last data partition is built and the transaction is committed, all data partitions are available for read and write.

即只有在最后将在index创建期间发生的更改应用到index时，会对表写锁定，then解除锁定。


drop index:

涉及该index的静态包，包高速缓存中的动态SQL，都会标记为无效。应用程序不受影响。


(HADR) 环境进行升级

  • 将主数据库升级到 DB2 V10.5 时，会将数据库角色从主数据库更改为标准数据库。不支持将备用数据库升级到 DB2V10.5，这是因为这些数据库处于前滚暂挂状态。由于存在这些限制，因此将 HADR 环境升级到 DB2 V10.5 时，要求您停止 HADR，对主数据库所在的 DB2 服务器进行升级，然后重新初始化 HADR。大版本不能实现滚动升级。

  • 升级到v10.5，因为sql语句的语法可能发生变化，clp的命令可能发生变化，编目表结构变化，api可能变化，应用程序用到的数据库驱动版本也不一致，所以要升级应用程序的数据库驱动，并且要测试才能上到prd。大版本升级，不仅instance升级（db2iupdt），database也要升级(db2updv10)


小版本升级（应用修订包），database升级是可选的，HADR可以实现滚动升级（先升级备库，takeover,在升级原主库）。



HADR的限制：

没有log记录的操作不会shipping到备库：如：

db2 update dbm cfg

db2 update db cfg for db

lob-options

      .-LOGGED-----.     .-NOT COMPACT-.      
|--●--+------------+--●--+-------------+--●---------------------|
      '-NOT LOGGED-'     '-COMPACT-----'

如果create table 对大字段指定了not logged，则该字段的DML不会记日志，则不会ship到备库；


备库的lobs存储在单独的表空间，对lobs的读取会失败，除非指定该lobs是inline，inline意味着lobs与常规数据在一个page


不支持load 的copy no模式，需要设定db2set db2_hadr_copy_no_override,将copy no自动转换为copy yes，同时load 的copy  yes产生的p_w_picpath应该是主、备都可以访问的point，通常主库挂载一个NFS,执行standby的本地fs


db2_hadr_ros:

db2_standby_iso:将隔离级别强制为UR

但是，比 UR 更高的隔离级别所需的锁不会传输到备用数据库，读取程序在重放日志记录时不会获取任何锁。简言之，备用数据库上的数据不受任何锁保护，所以备用数据库上的应用程序只能在 UR 隔离级别下读取。


不能备份库，日志不能归档

自动维护、stmm是无效的





会ship的操作：所有记录log的操作，

如runstats会在编目表插入数据，该操作记日志，所以备库的统计信息表会被更新；

在线reorg会记录日志 ，所以备库上回replay该操作，此时进入only-replay-window，备库的连接会被强制断开；online reorg由于是逐步提交，所有备库不会落后主库太远；


但是offline reorg也会ship到standby，那么在主库整个重组操作之后生成单一日志记录。此方式在最大程度上影响备用数据库与主数据库保持同步的功能（即备库会落后主库很大，这依赖于offline reorg有多长时间，offline reorg表是同步的）。备用数据库从主数据库接收日志记录之后，将开始执行整个重组过程。


在主库上对程序包的绑定，会产生insert操作，会ship到standby。


可以使用 ALTER TABLESPACE REBALANCE 或 ALTER TABLESPACE USING STOGROUP 语句来在主数据库上启动重新平衡操作。将在备用数据库上重放该语句，并且将启动相应的重新平衡操作。

在重新平衡操作期间，可以指定带 REBALANCE SUSPEND 子句的 ALTER TABLESPACE 语句来暂挂主数据库上的重新平衡操作。要恢复已暂挂的重新平衡操作，请指定带 REBALANCE RESUME 子句的 ALTER TABLESPACE 语句。

备用数据库在重放 ALTER TABLESPACE REBALANCE SUSPEND 语句时仍然处于活动状态。因为在主数据库上暂挂了重新平衡，所以当备用数据库作为新的主数据库进行接管时，将暂挂新的主数据库上的重新平衡操作，并且将隐式恢复新的备用数据库上的重新平衡操作。

降低高水位：

v9.5 db2dart db_name /DHWM   #dump high water mark infor

   db2dart db_name /LHWM  #给出low hwm的suggestion

   db2 reorg table  or  export and load/import 

   db2dart db_name /RHWM

V9.7 db2 alter tablespace tbspace_name reduce max   #auto storage,async

   db2 alter tablespace tbspace_name lower high water mark  #DMS,async



trancate table tb_name drop storage immediate #DDL,隐式提交，不可undo，不对每个record记录日志，是以page为单位释放space，速度快，不占log空间，但是依然会log该操作，所以可以rollforward，所以仍然可以ship 该operation到备库进行replay

implort from /dev/null replace into test_table #功能类似trancate

  • REPLACE

  • Deletes all existing data from the table by truncating the data object, and inserts the imported data.All inserts are logged.

明白一点：不能undo != 不能rollforward