版本升级

达梦数据库产品注重向下兼容性，虽然版本不断地更新升级，但在绝大多数情况下，使用高版本的执行码启动低版本的数据库时，会自动执行一系列更新升级动作。对于待升级的数据库，用户只需要保证它之前是正常退出的即可。

在数据库升降级操作前，建议先进行数据备份。

本章节中的升级步骤，是基于待升级的老库版本号等于或者高于 V7.1.6.11 的前提来写的。需要注意的是，DM 进行的三项较大的功能改进（V8.1.1.15 开始支持 RLOG_PKG 日志格式、V8.1.1.101 开始支持回滚管理段、V8.1.1.171 开始调整了数据页格式），使得待升级的库在跨这三个版本进行升级时需要进行额外的升级操作，下面进行详细的说明。

9.1 日志格式升级

从 V8.1.1.15 版本开始，DM 对 REDO 日志格式进行了升级，与老的日志格式不兼容，因此要求数据库在执行升级操作前，必须是使用之前版本的执行码执行正常退出后的库，以此来保证所有数据都已经刷盘，否则使用新版本的执行码启动数据库时，无法根据老的 REDO 日志对故障重启的数据库执行重做 REDO 日志、归档文件修复等动作，无法正常完成数据库升级。

9.1.1 版本说明

支持 DM7、DM8 老版本的库升级到 V8.1.1.15 或更高的数据库版本。

DM8 老版本的库正常退出后，允许直接启动升级到 V8.1.1.15 或者更高版本的 DM8，但必须要严格遵守 9.1.2 升级步骤中的升级步骤。

DM7 老版本的库，针对不同版本有一些升级限制，具体说明如下：

● V7.1.6.11 之后的版本（包括 V7.1.6.11）

允许直接启动升级到 V8.1.1.15 或者更高版本的 DM8，同样也需要严格遵守升级步骤。

● 低于 V7.1.6.11 的版本

需要先升级到 V7.6.0.183 或者更高版本的 DM7，对日志版本号进行升级，然后才允许升级到 V8.1.1.15 或者更高版本的 DM8。需要注意的是，V7.1.5.125 以及更低版本的库，如果打开了日志加密，则不再支持升级到 V8.1.1.15 或更高的数据库版本。

低于 V7.1.6.11 的版本需要升级两次，这两次版本升级的步骤是完全相同的，“升级到 V7.6.0.183 或者更高版本的 DM7”的步骤可以参考下文中描述的升级步骤，只是将升级步骤中的版本号替换为“V7.6.0.183 或者更高版本的 DM7”。

9.1.2 升级步骤

数据守护版本号从 V1.0 开始，目前已经支持到 V4.0，如果是只升级到 V3.0 或者 V3.0 之前的版本，配置文件和 dmwatcher.ctl 控制文件都可以向下兼容，REDO 日志格式也可以兼容，操作相对比较简单，这里不再对其进行说明。

此处只对升级到 V4.0 的操作步骤进行说明，V4.0 取消了 dmwatcher.ctl 控制文件的大部分功能，将其转移到 SYSOPENHISTORY 系统表上，守护进程的判断逻辑也随之做了较大改动，因此升级到 V4.0 时需要严格按照本文说明的操作步骤执行，否则升级过程中可能会出现守护进程或者监视器异常。

在执行升级步骤之前，需要特别注意以下几项说明：

  1. V4.0 和 V3.0 的数据库 REDO 日志格式不兼容，因此要求数据库在执行升级操作之前，必须是使用之前版本的服务器执行码按照数据守护的退出顺序正常退出的库，包括主库和备库，对 DSC 集群，要求所有节点都处于 Ok 状态并正常退出。
  2. 升级后老的归档日志文件不再可用，因此需要确保备库在升级前和主库的数据处于一致状态，否则升级完成后，主库无法再从老的归档文件中收集数据同步到备库上，这种情况下只能对升级后的主库进行备份，再还原到备库上。
  3. 升级后老的归档日志文件不再可用，因此必须在执行升级前先将归档日志文件全部从归档目录中移走，避免升级后再次降级时，误判归档日志文件不连续。
  4. 主备库在升级过程中，需要重建 SYSOPENHISTORY 系统表，备库通过重演 REDO 日志进行重建，在此期间守护进程、监视器无法获取到主备库有效的 Open 历史信息，有可能会出现强制退出，因此要求守护进程和监视器一定要放到最后启动，必须严格按照升级步骤执行。
  5. V4.0 要求主备库的 DB_MAGIC 不能相同，升级前如果备库和主库的 DB_MAGIC 相同，则升级完成后主备库之间将无法正常同步数据，此时只能对升级后的主库进行备份，再还原到备库上完成升级。
  6. V4.0 中异步备库的配置方式和 V3.0 不同，如果升级前有异步备库，升级后需要参考《DM8 数据守护与读写分离集群 V4.0》调整异步备库的配置方式。
  7. 如果升级中遇到操作不当导致备库没有同步升级，则可以先单独升级主库，对升级后的主库进行备份，再还原到备库上，完成备库升级。
  8. DSC 数据守护的升级，同样要求所有节点都是 Ok 状态并正常退出，DM7 不支持 DSC 数据守护，因此不涉及 DCR 磁盘和 VOTE 磁盘的重新初始化。

数据守护环境必须严格按照升级步骤执行，否则升级过程无法正常完成。数据守护环境升级步骤如下：

  1. 确保主备库数据一致的情况下按照正确的退出顺序退出整个数据守护环境，包括主库、备库、守护进程和监视器。
  2. 手动修改主备库 dm.ini 中的 ALTER_MODE_STATUS 为 1，如果是 DSC 集群，则每个节点的 dm.ini 都要修改。
  3. 使用 V8.1.1.15 或者更高版本的执行码，Mount 方式启动所有主备库。
  4. 使用 Disql 强制 Open 所有备库，如果备库是 DSC 集群，则需要依次连接每个节点执行。
SQL> Alter database open force;

注意：备库必须在主库之前 Open，否则备库无法重演主库升级产生的 REDO 日志，会导致备库无法完成升级。

  1. 使用 Disql 登录主库，依次执行以下语句，如果主库是 DSC 集群，则需要依次连接每个节点执行。

1）设置 DSC 备库的控制节点为归档目标节点。

如果不存在 DSC 备库，则可跳过此步骤，示例中的实例名是 DSC 备库的控制节点名称。

注意：DSC 备库只有控制节点允许接收主库的 REDO 日志，因此此处的归档目标只能设置为 DSC 备库的控制节点，如果设置成普通节点，会导致 DSC 备库无法完成升级，用 V8.1.1.15 或者更高版本的执行码在未升级的 DSC 备库上执行操作可能会引发异常。

SQL> SP_SET_ARCH_STATUS('实例名', 0);

2）强制 Open 主库。

SQL> Alter database open force;
  1. 主备库全部 Open 完成后，可分别连接主备库查询是否都存在 SYSOPENHISTORY 表，验证主备库是否正确升级。

备库重演 REDO 日志可能有一定延时，可通过分别查询主备库的 PKG_SEQ、LSN 信息确认主备库数据一致的情况下，再查询备库上是否存在 SYSOPENHISTORY 系统表。

主备库数据一致的判断方式：备库重演到的 PKG_SEQ 为主库的 GLOBAL_NEXT_SEQ 减 1，APPLY_LSN 与主库的 FILE_LSN 相同，备库重演到的 P_DB_MAGIC 与主库的 DB_MAGIC 相同。如果不满足此条件，则需要分别在主备库上重复多次查询，主库可能 GLOBAL_NEXT_SEQ 和 FILE_LSN 还在增长，不一定第一次查询就能满足条件，如果查询结果确实无法匹配，只要能观察到备库的重演 PKG_SEQ 和 APPLY_LSN 在随主库增长，就可以尝试查询是否存在 SYSOPENHISTORY 表。

查询主库：

SQL> SELECT DB_MAGIC, GLOBAL_NEXT_SEQ, FILE_LSN FROM V$RLOG;
行号       DB_MAGIC    GLOBAL_NEXT_SEQ      FILE_LSN
---------- ----------- -------------------- --------------------
1          460099052   4427                 106610

SQL>SELECT * FROM SYSOPENHISTORY;

查询备库：

SQL> SELECT P_DB_MAGIC, PKG_SEQ_ARR, APPLY_LSN_ARR FROM V$RAPPLY_LSN_INFO;
行号       P_DB_MAGIC           PKG_SEQ_ARR APPLY_LSN_ARR
---------- -------------------- ----------- -------------
1          460099052            (4426)      (106610)

SQL>SELECT * FROM SYSOPENHISTORY;

执行到这个步骤，主库已经升级完成，如果备库上没有查到 SYSOPENHISTORY 系统表信息，或者查询动态视图时备库出现异常退出情况，则说明备库没有升级成功，有可能是前面执行的升级步骤不对，或者备库 DB_MAGIC 和主库相同，或者备库升级前和主库数据不完全一致导致无法同步数据，这种情况下，只能正常退出主库和所有备库，对主库进行备份后再还原到备库上，完成备库升级，然后从步骤（9）开始继续执行。

  1. 在步骤 6 查询结果正确的情况下，正常退出主库。
  2. 正常退出所有备库。
  3. 重新修改主备库 dm.ini 中的 ALTER_MODE_STATUS 为 0，如果是 DSC 集群，则每个节点的 dm.ini 都要修改。
  4. 使用 V8.1.1.15 或者更高版本的执行码，Mount 方式启动所有主备库。
  5. 启动所有主备库本地的守护进程。
  6. 启动监视器。

至此，整个数据守护环境升级完成，可以通过执行监视器 show 命令观察守护系统是否运行正常，主备库如果都运行在 Open 状态，则说明升级成功。

如果升级过程中遇到服务器、守护进程或者监视器异常退出，说明没有严格按照上述的升级步骤执行，此时主备库数据可能已经不一致，如果要继续完成升级，只能先单独将主库升级完成，再备份还原到备库上。

单独升级主库，再备份还原到备库的执行步骤如下：

  1. 使用 V8.1.1.15 或者更高版本的执行码，Mount 方式启动主库。
  2. 依次执行以下语句 Open 主库。

如果主库是 DSC 集群，则需要依次连接每个节点执行。

SQL> SP_SET_ALL_ARCH_STATUS(1);

SQL> SP_SET_PARA_VALUE(1, 'ALTER_MODE_STATUS', 1);

SQL> ALTER DATABASE OPEN FORCE;

SQL> SP_SET_PARA_VALUE(1, 'ALTER_MODE_STATUS', 0);
  1. 正常退出主库，完成主库升级。
  2. 对主库进行脱机备份，再重新还原到备库上。
  3. 使用 V8.1.1.15 或者更高版本的执行码，Mount 方式启动所有主备库。
  4. 启动所有主备库本地的守护进程。
  5. 启动监视器。

至此，整个数据守护环境升级完成，可以通过执行监视器 show 命令观察守护系统是否运行正常，主备库如果都运行在 Open 状态，则说明升级成功。

9.2 回滚管理段升级

DM 从 V8.1.1.101 版本开始支持回滚管理段，用于存放事务信息，在系统故障重启或者 DSC 故障处理时，通过扫描回滚管理段收集事务信息，以达到缩减事务收集时长的目的。

此版本增加了一个建库参数（PSEG_MGR_FLAG）表示是否仅使用回滚管理段记录事务信息，取值 0、1，默认为 0。取值含义说明如下：

● 0：除了使用回滚管理段记录事务信息外，在事务的首个回滚页上也记录事务信息。

● 1：仅使用回滚管理段记录事务信息，事务的首个回滚页上不再记录。

老版本的库升级时，一律采用 PSEG_MGR_FLAG=0 的方式进行升级，老版本库在升级时会自动创建回滚管理段，升级成功后，不允许再使用老执行码启动升级后的库。

9.2.1 版本说明

具体的升级版本限制说明如下：

● 升级前的老版本库是 DM8，版本号等于或者高于 V8.1.1.15

老版本库已支持升级后的日志格式，本次升级仅需要升级回滚管理段。

● 升级前的老版本库是 DM8，版本号低于 V8.1.1.15；或者升级前的老版本库是 DM7

老版本库不支持升级后的日志格式，本次升级需要先升级日志格式，再升级回滚管理段。

对这个版本范围的老版本库，升级前首先需要满足“9.1 日志格式升级”的各项升级条件，然后还要满足回滚管理段的升级条件才能升级。

9.2.2 升级步骤

回滚管理段的升级必须满足以下两个条件：

  1. 要求升级前按照顺序正常退出整个数据守护环境，退出前主备库必须都是 Open 状态。
  2. 如果有 DSC 集群，则要求升级前不存在故障节点，并且所有节点均正常退出。

如果老库已支持升级后的日志格式（版本号等于或者高于 V8.1.1.15），在满足这两个条件之后，直接使用 V8.1.1.101 或者更高版本的执行码启动整个数据守护环境（启动顺序没有严格要求，主备库的 dmserver、dmwatcher、dmmonitor 全部正常启动即可），主备库都能够正常 Open、守护进程都处于 Open 状态、备库归档状态有效则说明升级成功。

需要注意的是，如果老库升级前已支持升级后的日志格式（版本号等于或者高于 V8.1.1.15），则本次回滚管理段升级前后的日志格式是兼容的，因此不要求升级前备库和主库数据一致，也就是不要求备库归档状态有效，回滚管理段升级完成后，主库仍然可以正常同步日志到备库。

如果老库还未支持升级后的日志格式，则需要同时满足日志格式和回滚管理段的升级条件，具体执行升级时，要根据老库当前的版本号，严格按照 9.1 日志格式升级中的方式进行升级，只需要将其中的 V8.1.1.15 替换为 V8.1.1.101 即可，V8.1.1.101 可以同时完成日志格式和回滚管理段的升级。

9.3 数据页格式升级

DM 从 V8.1.1.171 版本开始将修改数据页的节点信息（FRESH_EP）持久化到了数据页上，相应的对数据页上的页类型字段长度进行了缩减，同时将库版本号（DB_VERSION）由 0x0007000B 升级到了 0x0007000C。

新增的 FRESH_EP 字段主要用在 DMDSC 集群中，通过持久化的方式能够准确获取到修改数据页的前序节点，从而能够构建出正确的日志包依赖关系，以准确检测到是否存在日志缺失，解决备库重演卡住或者重演超时主动关闭等一系列问题。

特别要说明的是，对 DMDSC 集群、DMDSC 集群的备库、DMDSC 集群还原恢复后的库，升级成功后不支持再回退到升级前的版本。

9.3.1 版本说明

具体的升级版本限制说明如下：

● 升级前的老版本库是 DM8，版本号等于或者高于 V8.1.1.101

老版本库已支持升级后的日志格式和回滚管理段，本次升级仅需要升级数据页格式。

● 升级前的老版本库是 DM8，版本号等于或者高于 V8.1.1.15

老版本库已支持升级后的日志格式，本次升级需要同时完成回滚管理段和数据页格式两项升级内容，因此升级前需要同时满足“9.2 回滚管理段升级”和“9.3 数据页格式升级”的各项升级条件才能够升级成功。

● 升级前的老版本库是 DM8，版本号低于 V8.1.1.15；或者升级前的老版本库是 DM7

老版本库不支持升级后的日志格式，本次升级需要完成日志格式、回滚管理段和数据页格式三项升级内容。因此对这个版本范围的老版本库，升级前需要同时满足“9.1 日志格式升级”和“9.2 回滚管理段升级”以及“9.3 数据页格式升级”的各项升级条件才能够升级成功。

9.3.2 升级步骤

本小节内容仅适用于老库版本号等于或者高于 V8.1.1.101 的情况，如果是更低版本的老库升级，则需要同时参考 9.1 日志格式升级和 9.2 回滚管理段升级的内容。

数据页格式的升级必须满足以下条件：

  1. 要求升级前按照正常的退出顺序退出整个数据守护环境，退出前主备库必须都是 Open 状态。
  2. 如果升级前的数据守护环境中没有 DMDSC 集群，则升级前不要求主备库数据完全一致（单节点环境下，日志包不存在依赖关系，不会影响到归档连续性校验），但是要求主备库必须都正常退出。
  3. 如果升级前的数据守护环境中包含有 DMDSC 集群，则升级前要求主备库数据必须完全一致（避免升级完成后使用到升级前的归档日志，无法准确判断日志依赖关系，引发备库重演卡住等问题），同时要求 DMDSC 集群升级前不存在故障节点，并且所有节点均正常退出。

满足以上条件后，直接使用 V8.1.1.171 或者更高版本的执行码启动整个数据守护环境（主备库启动顺序没有严格要求），主备库都能够正常 Open、守护进程都处于 Open 状态、备库归档状态有效则说明升级成功。

注意，本次升级完成后，对 DMDSC 集群、DMDSC 集群的备库、DMDSC 集群还原恢复后的库，不允许再回退到升级前的版本。

9.4 HUGE 表空间升级

9.4.1 版本说明

从 V8.1.2.101 版本开始，DM 对 HUGE 表空间进行了升级改造。本节中低版本是指 V8.1.2.101 之前的库，高版本是指 V8.1.2.101 或更高的版本。

不使用 HUGE 表的用户可以不用升级 HUGE 表空间。需要特别注意的是，升级后将不支持继续使用低版本库下所创建的 HUGE 表。若用户库中已有正在使用的 HUGE 表，建议谨慎升级。自定义混合表空间由用户可根据自己需要创建。本章升级对象为 MAIN 系统混合表空间。

高版本与低版本之间的差异如下：

● 用户自定义混合表空间

在低版本中，表空间分为普通表空间和 HUGE 表空间。

从高版本中，对 HUGE 表空间进行了升级改造，废除了 HUGE 表空间的概念，取而代之的是混合表空间的概念。在高版本中，表空间分为普通表空间和混合表空间。

使用 <HUGE 路径子句 > 创建的表空间为混合表空间，未使用 <HUGE 路径子句 > 创建的表空间即为普通表空间。普通表空间只能存储普通表（非 HUGE 表）；而混合表空间既可以存储普通表又可以存储 HUGE 表。HUGE 数据文件存储在 <HUGE 路径子句 > 指定的路径中，普通（非 HUGE）数据文件存储在 < 数据文件子句 > 指定的路径中。HUGE 表对应的辅助表为普通表，因此，HUGE 辅助表数据存在 < 数据文件子句 > 指定的路径中。

若创建 HUGE 表使用自定义的混合表空间，则需要用户先创建一个混合表空间。自定义混合表空间创建方法参考《DM8_SQL 语言使用手册》CREATE TABLESPACE 语法。

例 创建 HUGE 表 T1，使用自定义的混合表空间 TS1。

CREATE TABLESPACE TS1 DATAFILE 'd:\TS1.dbf' SIZE 128 WITH HUGE PATH 'D:\TS1\HUGE1';
CREATE HUGE TABLE T1(C1 INT, C2 INT)STORAGE(ON TS1);

● 系统 MAIN 表空间

在低版本中，普通表用户默认表空间 MIAN 为一个普通表空间。HUGE 表默认表空间 HMAIN 为一个 HUGE 表空间。

在高版本中，取消了 HMAIN 表空间。普通表和 HUGE 表用户默认表空间统一为 MAIN 表空间，MAIN 为一个混合表空间。

例 创建 HUGE 表 T2，缺省使用系统默认的 MAIN 混合表空间。

CREATE HUGE TABLE T2(C1 INT, C2 INT) ;

9.4.2 升级步骤

数据守护环境下 HUGE 表空间升级分为三种情况。

● 现有的主备库升级

对于数据守护环境中，对现有的低版本主备库升级需分别单独进行，各节点的升级方法和单节点一样。

● 在升级后的单节点基础上搭建主备或增加备库

需先将低版本单节点库进行升级。为了达到主备库完全一致的效果，先对升级后的库进行备份，通过还原恢复的方式搭建另外一个库，另搭建后无需再升级。

● 在未升级的单节点基础上搭建主备或增加备库

未升级的低版本数据库（简称 A）中的 MAIN 表空间为普通表空间。通过高版本的库软件对未升级的库进行备份还原后，新库（简称 B）中 MAIN 表空间会被初始化为高版本的混合表空间。此时，AB 两个库中的 MAIN 表空间就存在不一致的情况，A 库需要升级。例如，如果将 MAIN 混合表空间所在的 B 库作为主库时，主库可以成功创建 HUGE 表语句，但是备库 A 处于低版本而无法完成，可能会导致宕机。

此时，需对低版本 A 库采用脱机方式进行升级。高版本 B 库不用升级。

温馨提醒：当数据守护集群中节点数很多，DBA 无法区分哪个节点为带升级的低版本时，可通过查看控制文件来解决。如果控制文件中 MAIN 表空间的描述信息中包含 HUGE PATH 内容即为高版本库，无需升级；如果无 HUGE PATH 内容即为低版本库，需要升级。

微信扫码
分享文档
扫一扫
联系客服