使用SQL APPLY升级oracle DG版本(11g to 12c)

一 升级介绍

您可以使用逻辑备用数据库执行Oracle数据库软件的滚动升级。

在滚动升级期间,您可以在主数据库和逻辑备用数据库上运行不同版本的Oracle Database,一次升级一个库,使主数据库的停机时间最少。

对于源于Oracle Database 12c Release 1(12.1)的第一个修补程序集的数据库,使用现有物理备用数据库执行滚动升级的首选方法是使用DBMS_rolling PL/SQL包,请参考https://docs.oracle.com/en/database/oracle/oracle-database/12.2/sbydb/using-DBMS_ROLLING-to-perform-rolling-upgrade.html#GUID-70C09F5B-90BE-4C8C-96A5-45A52E05D380

1.1 使用SQL Apply滚动升级的好处

  • 您的生产数据库几乎没有停机时间。总的停机时间与执行切换所需的时间一样少。
  • 您可以消除由于PL/SQL重新编译而导致的应用程序停机。
  • 您可以在不影响主数据库的情况下验证升级的数据库版本。
  • 逻辑备库在升级过程中接收归档日志,这提供了更高级别的灾难保护。

二 使用SQL Apply执行滚动升级的要求

在生产环境升级之前,先在测试环境升级下,做好测试(Database Replay,Sql Perforance Analyzer,sql计划管理等),确保没问题后,再在生产进行版本升级。

--可参考https://blog.csdn.net/yabingshi_tech/article/details/107255462

2.1 禁用代理配置

如果数据库是Oracle Data Guard代理配置的一部分,请在滚动升级之前禁用代理配置

DGMGRL> DISABLE FAST_START FAILOVER;

DGMGRL> DISABLE CONFIGURATION;

2.2 Data Guard保护模式必须设置为最大可用性或最大性能

select PROTECTION_LEVEL  from V$DATABASE;

设置命令:

ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE {AVAILABILITY | PERFORMANCE};

2.3 LOG_ARCHIVE_DEST_n初始化参数不得设置为MANDATORY

show parameter log_archive_dest;

2.4 在主数据库上设置的兼容初始化参数必须与升级前的软件版本匹配

因此,从release x到release y的滚动升级需要将主数据库上的COMPATIBLE initialization参数设置为release x。滚动升级备用数据库的兼容初始化参数必须设置为x或更高。

show parameter compatible;

三 滚动升级

3.1 环境

角色

DB_UNIQUE_NAME

数据库版本

目标升级版本

主库

orcl

11.2.0.4

12.2.0.1

备库

bakorcl

3.2 升级步骤

使用现有的逻辑备用数据库执行滚动升级请参考:

https://docs.oracle.com/en/database/oracle/oracle-database/12.2/sbydb/using-sql-apply-to-perform-rolling-upgrade.html#GUID-5995DF99-5268-43BE-BD63-D0DEAA8241EC

 

本次升级的数据库是Physical Standby database,所以参考的是:

https://docs.oracle.com/en/database/oracle/oracle-database/12.2/sbydb/using-sql-apply-to-perform-rolling-upgrade.html#GUID-C5DF6148-C1E9-4ADF-A975-AC95FC64E0C4

 

3.2.1 准备主数据库以进行滚动升级

① 启用闪回数据库(如果尚未启用):

SQL> SHUTDOWN IMMEDIATE;

SQL> STARTUP MOUNT;

SQL> ALTER DATABASE FLASHBACK ON;

SQL> ALTER DATABASE OPEN;

SQL> select flashback_on from v$database;

 

FLASHBACK_ON

------------------

YES

 

② 创建有保证的还原点:

SQL> CREATE RESTORE POINT pre_upgrade GUARANTEE FLASHBACK DATABASE;

3.2.2 将物理备库转换为逻辑备库

① 检查数据库是否是open状态

select open_mode from v$database;

如果备库是open状态,需要重启数据库至mount状态:

shutdown immediate;

startup nomount;

alter database mount standby database;

 

② 停止redo apply

alter database recover managed standby database cancel;

 

③ 在主库上生成数据字典,防止下面的转换命令长时间没反应

exec dbms_logstdby.build;

 

④ 转换为逻辑standby

ALTER DATABASE RECOVER TO LOGICAL STANDBY KEEP IDENTITY;

SQL> select database_role from v$database;

 

DATABASE_ROLE

----------------

LOGICAL STANDBY

 

⑤ 启动数据库到open状态

ALTER DATABASE OPEN;

 

⑥ 在逻辑备库中禁用自动删除外部存档日志

EXECUTE DBMS_LOGSTDBY.APPLY_SET('LOG_AUTO_DELETE', 'FALSE');

如果在使用恢复区域存储远程存档日志,则必须确保它有足够的空间来容纳这些日志,否则会影响逻辑备用数据库的正常操作。

 

⑦ 请确保捕获主数据库上运行的逻辑备用数据库不支持的事务的相关信息。运行以下存储过程将信息捕获并作为事件记录在DBA_LOGSTDBY_events表中:

SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('MAX_EVENTS_RECORDED', -

 DBMS_LOGSTDBY.MAX_EVENTS);

SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('RECORD_UNSUPPORTED_OPERATIONS', 'TRUE');

 

⑧ 第一次启动SQL APPLY

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

3.2.3 升级逻辑备库,并追赶上主数据库

3.2.3.1 准备滚动升级

① 关闭sql apply

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;

3.2.3.2 升级逻辑备库

当逻辑备库正在升级时,它不接受来自主数据库的重做数据。

在主库上插入条测试数据,到时验证下是否能同步到从库上。

SQL> insert into scott.t(id) values(6);

 

1 row created.

 

SQL> commit;

 

Commit complete.

 

SQL> select * from scott.t;

 

       ID

----------

        1

        2

        3

        4

        5

        6

 

6 rows selected.

3.2.3.2.1 为新版本数据库安装Oracle数据库软件

3.2.3.2.1.1 解压安装包

安装包下载地址:https://www.oracle.com/database/technologies/oracle-database-software-downloads.html

unzip linuxx64_12201_database.zip

chown -R oracle:oinstall database

3.2.3.2.1.2 新建静默安装的应答文件

su - oracle

vi 12201_db_install.rsp

添加:

oracle.install.responseFileVersion=/oracle/install/rspfmt_dbinstall_response_schema_v12.2.0

oracle.install.option=INSTALL_DB_SWONLY

ORACLE_HOSTNAME=PC

UNIX_GROUP_NAME=oinstall

INVENTORY_LOCATION=/u01/app/oraInventory

SELECTED_LANGUAGES=en

ORACLE_HOME=/u01/app/oracle/product/12.2.0.1/db_1

ORACLE_BASE=/u01/app/oracle

oracle.install.db.InstallEdition=EE

oracle.install.db.DBA_GROUP=dba

oracle.install.db.OPER_GROUP=oper

oracle.install.db.BACKUPDBA_GROUP=dba

oracle.install.db.DGDBA_GROUP=dba

oracle.install.db.OSRACDBA_GROUP=dba

oracle.install.db.KMDBA_GROUP=dba

oracle.install.db.config.starterdb.password.ALL=oracle

DECLINE_SECURITY_UPDATES=true

oracle.installer.autoupdates.option=SKIP_UPDATES

3.2.3.2.1..3 静默安装软件

cd /download/12c_software/database/

./runInstaller  -silent -responseFile /home/oracle/12201_db_install.rsp

使用SQL APPLY升级oracle DG版本(11g to 12c)_第1张图片

 

按提示用root用户执行以下脚本:

As a root user, execute the following script(s):

       1. /u01/app/oracle/product/12.2.0.1/db_1/root.sh

 

3.2.3.2.2 开始Oracle数据库升级之前要完成的数据库准备任务

3.2.3.2.2.1 收集优化器统计信息以减少Oracle数据库停机时间

如果您的数据库包含数千个字典表,那么Oracle强烈建议您在开始升级前一天晚上收集统计信息:

SQL> EXEC DBMS_STATS.GATHER_DICTIONARY_STATS;

3.2.3.2.2.2 升级前验证物化化视图刷新是否完成

升级Oracle数据库之前,必须等到所有具体化视图都已完成刷新。

SQL> SELECT s.obj#,o.obj#,s.containerobj#,lastrefreshdate,pflags,xpflags,o.name,o.owner#,

bitand(s.mflags, 8) from obj$ o, sum$ s WHERE o.obj# = s.obj# AND o.type# =

42 AND bitand(s.mflags, 8) = 8;

3.2.3.2.2.3 确保升级前没有文件处于备份模式

SQL> SELECT * FROM v$backup WHERE status != 'NOT ACTIVE';

如果此SQL语句指示文件仍在备份中,请等待备份完成,或者在尝试升级之前中止任何不需要的备份。

3.2.3.2.2.4 确保升级前没有文件需要做介质恢复

SQL> SELECT * FROM v$recover_file;

3.2.3.2.2.5 升级之前解决未完成的分布式事务

您可以通过首先查询以查看任何挂起的事务,然后提交这些事务来完成此操作。必须等到所有挂起的分布式事务都已提交。

SQL> SELECT * FROM dba_2pc_pending;

如果上一步中的查询有返回行,则运行以下语句:

SQL> SELECT local_tran_id FROM dba_2pc_pending;

SQL> EXECUTE dbms_transaction.purge_lost_db_entry('');

SQL> COMMIT;

3.2.3.2.2.6 升级之前清空回收站释放存储空间

在升级过程中,数据库回收站必须为空,以避免可能的ORA-00600错误,并将升级时间减至最少。

PURGE DBA_RECYCLEBIN;

3.2.3.2.2.7 复制透明加密Oracle钱包

如果您使用Oracle wallet with Transparent Data Encryption(TDE),并使用Database Upgrade Assistant(DBUA)升级数据库,则复制sqlnet.ora把钱包文件放到新的ORACLE目录里。

你必须复制sqlnet.ora和钱包文件手动启动升级。

拷贝sqlnet.ora file, and the wallet file, ewallet.p12到新的Oracle目录里。

3.2.3.2.2.8 升级Oracle数据库时对Oracle Net Services的建议

在Oracle database12c中,新的底层netservices参数支持数据压缩,这减少了通过sqltcp连接传输的会话数据单元的大小。

压缩参数:

SQLNET.COMPRESSION

SQLNET.COMPRESSION_LEVELS

SQLNET.COMPRESSION_THRESHOLD

这些新参数在早期版本中不受支持,仅在Oracle Database 12c中可用。

3.2.3.2.2.9 了解密码区分大小写和升级

1: 默认情况下,Oracle Database 12c release 2(12.2)升级为独占模式。独占模式不支持不区分大小写的基于密码的身份验证。

当服务器以独占模式运行时,只有10G密码版本的帐户将无法访问。

在以前的Oracle数据库版本中,可以将身份验证协议配置为允许基于密码的不区分大小写的身份验证,方法是设置SEC_case_SENSITIVE_LOGON=FALSE。从Oracle Database 12c release 2(12.2)开始,默认的基于密码的身份验证协议配置不使用不区分大小写的10G密码版本,因为在默认情况下SQLNET.ORA参数SQLNET.ALLOWED_LOGON_VERSION_SERVER值为12,这是独占模式。

为了提高安全性,Oracle建议您启用区分大小写的基于密码的身份验证。这是默认值。但是,在升级到Oracle Database 12c release 2(12.2)期间,可以暂时禁用区分大小写的身份验证。升级后,您可以决定是否要启用区分大小写的基于密码的身份验证功能,作为实施计划的一部分来管理密码版本。

升级之前,Oracle建议您执行以下检查,以确定您是否受此对基于密码的默认身份验证协议配置的更改的影响:

确定您的帐户是否只使用10G不区分大小写的密码验证版本。

确定您是否有Oracle Database 11g release 2(11.2.0.3)数据库或未应用关键修补程序更新CPUOct2012或更高版本修补程序更新的更早版本的客户端,以及是否拥有任何不区分大小写的10G密码版本的帐户。

请确保没有将SEC_CASE_SENSITIVE_LOGON设置为FALSE。将此参数设置为FALSE可防止使用区分大小写的密码版本(11G和12C密码版本)进行身份验证。

 

2:如果您的用户帐户只有不区分大小写的10G密码版本,则必须选择以下选项之一:

升级之前,请更新每个只有10G密码版本的帐户的密码版本。您可以使用10G密码版本使用户密码过期,然后请求这些用户登录到他们的帐户。当他们尝试登录时,服务器会自动更新这些用户的密码版本列表,其中包括区分大小写的密码版本。

更改SQLNET.ORA参数SQLNET.ALLOWED_LOGON_VERSION_SERVER为非独占模式的设置。例如:SQLNET.ALLOWED_LOGON_VERSION_SERVER=11

3.2.3.2.2.10 检查帐户是否使用不区分大小写的密码版本

1:查找使用不区分大小写(10G)版本的用户帐户

SELECT USERNAME,PASSWORD_VERSIONS FROM DBA_USERS;

使用SQL APPLY升级oracle DG版本(11g to 12c)_第2张图片

 

2:修复密码大小写不敏感的用户

① 查找只有10g密码版本的用户

      select USERNAME

         from DBA_USERS

        where ( PASSWORD_VERSIONS = '10G '

               or PASSWORD_VERSIONS = '10G HTTP ')

          and USERNAME <> 'ANONYMOUS';

② 修改sqlnet.ora中参数:

SQLNET.ALLOWED_LOGON_VERSION_SERVER=11

③ 让该用户过期

ALTER USER username PASSWORD EXPIRE;

④ 用该用户登陆重置密码

当这些用户登录时,系统会提示他们重置密码。除了10G密码版本外,系统会在内部为其帐户生成丢失的11G和12C密码版本。10G密码版本仍然存在,因为系统在许可模式下运行。

⑤ 确保用户正在连接的客户端软件具有O5L_NP标签

所有Oracle Database release 11.2.0.4及更高版本的客户端,以及所有Oracle Database release 12.1及更高版本的客户端都具有O5L_NP功能。其他客户端需要CPUOct2012补丁来获得O5L_NP功能。

O5L_NP capability标志记录在SQLNET.ALLOWED_LOGON_VERSION_SERVER。

⑥ 在所有客户机都具有O5L_NP功能之后,使用以下过程将服务器的安全性提升回独占模式

将SEC_CASE_SENSITIVE_LOGON设置为TRUE

SQLNET.ALLOWED_LOGON_VERSION_SERVER = 12

⑦ 检查确认是否还有10g密码版本的用户

       select USERNAME

         from DBA_USERS

        where PASSWORD_VERSIONS like '%10G%'

          and USERNAME <> 'ANONYMOUS';

 

3:检查SEC_CASE_SENSITIVE_LOGON的值

SQL> SHOW PARAMETER SEC_CASE_SENSITIVE_LOGON

 

NAME                                 TYPE        VALUE

------------------------------------ ----------- ------------------------------

sec_case_sensitive_logon             boolean     FALSE

如果是false,将其改为true。

SQL> ALTER SYSTEM SET SEC_CASE_SENSITIVE_LOGON = TRUE;

 System altered.

3.2.3.2.3 使用Pre-Upgrade tool分析数据库

Pre-Upgrade Information Tool在在新版本Oracle home中的文件路径中:ORACLE_HOME/rdbms/admin/preupgrade.jar。

但是,该工具执行的检查是在早期版本的Oracle Database home上执行的。

语法:

$Earlier_release_Oracle_home/jdk/bin/java -jar $New_release_Oracle_home

/rdbms/admin/preupgrade.jar [FILE|TERMINAL] [TEXT|XML] [DIR output_dir]

示例:

su - oracle

/u01/app/oracle/product/11.2.0.4/db_1/jdk/bin/java -jar /u01/app/oracle/product/12.2.0.1/db_1/rdbms/admin/preupgrade.jar FILE TEXT DIR /home/oracle/

执行完后产生了一些文件:

Preupgrade generated files:

    /home/oracle/preupgrade.log

    /home/oracle/preupgrade_fixups.sql

    /home/oracle/postupgrade_fixups.sql

 

登录升级前的11g数据库执行@/home/oracle/preupgrade_fixups.sql修复问题;

使用SQL APPLY升级oracle DG版本(11g to 12c)_第3张图片

 

但我这里运行该脚本报错,只好手动按照/home/oracle/preupgrade.log的错误提示进行修复了。

preupgrade.log部分内容:

==============

BEFORE UPGRADE

==============



  Run /preupgrade_fixups.sql to complete all

  of the BEFORE UPGRADE action items below marked with '(AUTOFIXUP)'.



  REQUIRED ACTIONS

  ================

   + Adjust TABLESPACE SIZES as needed.

                                                Auto      12.2.0.1.0       

     Tablespace                        Size     Extend    Min Size    Action

     ----------                     ----------  --------  ----------  ------



     SYSAUX                             510 MB  ENABLED      1423 MB  None 

     SYSTEM                             760 MB  ENABLED      1250 MB  None 

     TEMP                                29 MB  ENABLED       150 MB  None 

     UNDOTBS1                            70 MB  ENABLED       400 MB  None 



     Note that 12.2.0.1.0 minimum sizes are estimates.

     If you plan to upgrade multiple pluggable databases concurrently,

     then you must ensure that the UNDO tablespace size is equal to at least

     the number of pluggable databases that you upgrade concurrently,

     multiplied by that minimum.  Failing to allocate sufficient space can

     cause the upgrade to fail.



   + Update NUMERIC INITIALIZATION PARAMETERS to meet estimated minimums.



     Parameter                         12.2.0.1.0 minimum

     ---------                         ------------------

     processes                                        300

alter database datafile '/u01/app/oracle/oradata/bakorcl/sysaux01.dbf' resize 1430M;

alter database datafile '/u01/app/oracle/oradata/bakorcl/system01.dbf' resize 1250M;

alter database tempfile '/u01/app/oracle/oradata/bakorcl/temp01.dbf' resize 152M;

alter system set processes=500 scope=spfile

3.2.3.2.4 备份数据库

RUN

{

    ALLOCATE CHANNEL chan_name TYPE DISK;

    BACKUP DATABASE FORMAT '/home/oracle/bak/%U' TAG before_upgrade;

    BACKUP CURRENT CONTROLFILE FORMAT 'controlfile location and name';

}

 

RMAN> list backup of database;

……

3.2.3.2.5 升级数据库

3.2.3.2.5.1 拷贝11g数据库参数文件到12c库下

create pfile='/u01/app/oracle/product/11.2.0.4/db_1/dbs/initbakorcl_20200719.ora' from spfile;

cp /u01/app/oracle/product/11.2.0.4/db_1/dbs/initbakorcl_20200719.ora /u01/app/oracle/product/12.2.0.1/db_1/dbs/initbakorcl.ora

3.2.3.2.5.2 关闭11g数据库

shutdown immediate;

3.2.3.2.5.3 修改环境变量,指向12c数据库

su - oracle

vi .bash_profile

#ORACLE_HOME=$ORACLE_BASE/product/11.2.0.4/db_1;

ORACLE_HOME=$ORACLE_BASE/product/12.2.0.1/db_1;

 

#使修改生效

source /home/oracle/.bash_profile

3.2.3.2.5.4 启动12c数据库

startup pfile='/u01/app/oracle/product/12.2.0.1/db_1/dbs/initbakorcl.ora' upgrade;

create spfile from pfile;

#此时就能查到11g库里的数据了:

使用SQL APPLY升级oracle DG版本(11g to 12c)_第4张图片

 

3.2.3.2.5.5 升级数据库

cd $ORACLE_HOME/bin

./dbupgrade -l $ORACLE_HOME/diagnostics

会提示生成了一些文件:

 

……

*******************   Migration   ******************

Serial   Phase #:109  [orcl] Files:1    Time: 46s

Serial   Phase #:110  [orcl] Files:1    Time: 0s

Serial   Phase #:111  [orcl] Files:1    Time: 61s

*****************   Post Upgrade   *****************

Serial   Phase #:112  [orcl] Files:1    Time: 891s

****************   Summary report   ****************

Serial   Phase #:113  [orcl] Files:1    Time: 2s

Serial   Phase #:114  [orcl] Files:1    Time: 0s

Serial   Phase #:115  [orcl] Files:1     Time: 25s

 

Grand Total Time: 3727s

 

 LOG FILES: (/u01/app/oracle/product/12.2.0.1/db_1/diagnostics/catupgrd*.log)

 

Upgrade Summary Report Located in:

/u01/app/oracle/product/12.2.0.1/db_1/diagnostics/upg_summary.log

 

Grand Total Upgrade Time:    [0d:1h:2m:7s]

 

 

#使用Post-Upgrade Status Tool进行检查

SQL> @/u01/app/oracle/product/11.2.0.4/db_1/rdbms/admin/utlu112s.sql

.

Oracle Database 11.2 Post-Upgrade Status Tool            07-10-2020 11:41:42

.

Component                        Current      Version  Elapsed Time

Name                                 Status          Number       HH:MM:SS

.

Oracle Server

.                                    VALID      12.2.0.1.0  00:16:59

JServer JAVA Virtual Machine

.                                    VALID      12.2.0.1.0  00:00:01

Oracle Workspace Manager

……

PL/SQL procedure successfully completed.

执行完升级命令后,数据库自动关闭了。

3.2.3.2.5.6 启动数据库

cp /u01/app/oracle/product/11.2.0.4/db_1/network/admin/tnsnames.ora /u01/app/oracle/product/12.2.0.1/db_1/network/admin/tnsnames.ora

cp /u01/app/oracle/product/11.2.0.4/db_1/dbs/orapwbakorcl $ORACLE_HOME/dbs/

SQL> startup;

lsnrctl stop

lsnrctl start

3.2.3.2.6 升级后任务

3.2.3.2.6.1 执行修复sql

@/home/oracle/postupgrade_fixups.sql

3.2.3.2.6.2 重新编译无效对象

@$ORACLE_HOME/rdbms/admin/utlrp.sql

--执行下面sql检查是否存在无效对象

select owner, object_name, object_type from dba_invalid_objects order by owner, object_type;

3.2.3.2.6.3 确保ORACLE_HOME等环境变量指定的是新版本数据库

echo $ORACLE_HOME

3.2.3.2.6.4 修改oratab文件

#修改/etc/oratab,将11.2.0.4改为12.2.0.1

vi /etc/oratab

orcl:/u01/app/oracle/product/12.2.0.1/db_1:Y

3.2.3.2.6.5 收集字典统计信息

#非CDB:

SQL> EXEC DBMS_STATS.GATHER_DICTIONARY_STATS;

#CDB

$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl -l /tmp -b gatherstats -- --x"exec dbms_stats.gather_dictionary_stats"

3.2.3.2.6.6 收集固定对象统计信息

固定对象是X$表及其索引。V$performance视图是通过X$表定义的。收集固定对象统计信息对数据库性能很有价值,因为这些统计信息有助于优化器生成良好的执行计划,从而提高数据库性能。未能获得具有代表性的统计数据可能导致执行计划不理想,这可能会导致严重的性能问题。

SQL> execute dbms_stats.gather_fixed_objects_stats;

3.2.3.2.6.7 备份数据库

RUN

{

    ALLOCATE CHANNEL chan_name TYPE DISK;

    BACKUP DATABASE FORMAT '/home/oracle/bak/%U' TAG after_upgrade;

    BACKUP CURRENT CONTROLFILE FORMAT 'controlfile location and name';

}

 

这里只列举了部分升级后任务,详细可参考:

https://docs.oracle.com/en/database/oracle/oracle-database/12.2/upgrd/post-upgrade-tasks-oracle-database.html#GUID-637ADBD0-866B-4B64-9513-4C7CDE84895C

 

 

--这里主要参考了12c官方升级文档:

https://docs.oracle.com/en/database/oracle/oracle-database/12.2/upgrd/index.html

 

3.2.3.3 在升级的逻辑备用数据库上重新启动SQL Apply

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

在主系统上累积的重做数据会自动传输并应用到新升级的逻辑备用数据库上。

3.2.3.4 监视升级的备用数据库上的事件

要监视备库赶上主库的速度,请查询备库上的V$LOGSTDBY_PROGRESS视图。例如:

SQL> ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MON-YY HH24:MI:SS';

Session altered.

 

SQL> SELECT SYSDATE, APPLIED_TIME FROM V$LOGSTDBY_PROGRESS;

 

TO_CHAR(SYSDATE, TO_CHAR(APPLIED_

---------------- ----------------

2020-07-19 12:13 2020-07-19 12:13

 

#检查下之前在主库上插入的测试数据是否同步到了从库上:

SQL> select * from scott.t where id=6;

 

        ID

----------

         6

建议您经常查询DBA_LOGSTDBY_EVENTS视图,以了解是否有任何DDL和DML语句尚未应用于备库。

SQL> SET LONG 1000

SQL> SET PAGESIZE 180

SQL> SET LINESIZE 79

SQL> SELECT EVENT_TIMESTAMP, EVENT, STATUS FROM DBA_LOGSTDBY_EVENTS -

 ORDER BY EVENT_TIMESTAMP;

 

EVENT_TIMESTAMP

---------------------------------------------------------------------------

EVENT

--------------------------------------------------------------------------------

STATUS

--------------------------------------------------------------------------------

24-MAY-05 05.18.29.318912 PM

CREATE TABLE SYSTEM.TST (one number)

ORA-16226: DDL skipped due to lack of support

 

24-MAY-05 05.18.29.379990 PM

"SYSTEM"."TST"

ORA-16129: unsupported dml encountered

 

在前面的示例中:

ORA-16226错误显示了不受支持的DDL语句。在这种情况下,它不受支持,因为它属于内部架构。

ORA-16129错误表明没有应用DML语句。

 

如果您确定逻辑备用数据库和主数据库之间的差异是可以接受的,则继续执行升级过程。如果没有,请停止并重新初始化数据库B,并在其他时间执行升级过程。

3.2.4 主备切换

#在主库上执行:

ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY;

此语句必须等待现有事务完成。为了尽可能减少完成切换所需的时间,仍连接到主数据库的用户应立即注销。

 

#检查主从状态

select database_role from v$database;

 

#在现主库bakorcl上插入两条测试数据,到时验证下是否能同步到现备库orcl上。

insert into scott.t(id) values(11);

insert into scott.t(id) values(12);

commit;

3.2.4.1 导入升级过程中修改的所有表

步骤3.2.3.4 描述了如何列出正在修改的不受支持的表。如果在主数据库上发出了不受支持的DML语句,则使用导入实用程序(如Oracle Data Pump)导入这些表的最新版本。

示例:

impdp SYSTEM NETWORK_LINK=databasea TABLES=scott.emp TABLE_EXISTS_ACTION=TRUNCATE

3.2.4.2 完成切换并激活用户应用程序

① 在备库上查询SWITCHOVER_STATU

SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;

 

SWITCHOVER_STATUS

--------------------

TO PRIMARY

② 当SWITCHOVER_STATUS列显示为PRIMARY时,通过在备库上发出以下语句来完成切换:

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

③ 激活新主库上的用户应用程序和服务,该数据库现在以主数据库角色运行。

切换后,无法将重做数据从运行新数据库软件版本的新主数据库发送到运行旧软件版本的新备用数据库。

 

在这些步骤的最后,数据库B是运行Oracle软件升级版本的主数据库,数据库A成为逻辑备用数据库。

3.2.5 将原主库闪回到保证的还原点

SQL> SHUTDOWN IMMEDIATE;

SQL> STARTUP MOUNT;

SQL> FLASHBACK DATABASE TO RESTORE POINT pre_upgrade;

SQL> SHUTDOWN IMMEDIATE;

lsnrctl stop

3.2.6 使用新版本的Oracle软件mount原主库

此时,请切换原主库以使用更高版本的Oracle软件。您不需要运行升级脚本,因为原主库变成了物理备用,并且在应用新主库生成的重做数据时自动升级。

参考‘3.2.3.2.1 为新版本数据库安装Oracle数据库软件’。

 

SQL> create pfile='/u01/app/oracle/product/11.2.0.4/db_1/dbs/initorcl_20200719.ora' from spfile;

cp /u01/app/oracle/product/11.2.0.4/db_1/dbs/initorcl_20200719.ora /u01/app/oracle/product/12.2.0.1/db_1/dbs/initorcl.ora

cp /u01/app/oracle/product/11.2.0.4/db_1/network/admin/tnsnames.ora /u01/app/oracle/product/12.2.0.1/db_1/network/admin/tnsnames.ora

cp /u01/app/oracle/product/11.2.0.4/db_1/dbs/orapworcl $ORACLE_HOME/dbs/

 

su - oracle

vi .bash_profile

将$ORACLE_HOME指向12c数据库目录:

ORACLE_HOME=$ORACLE_BASE/product/12.2.0.1/db_1

source .bash_profile

 

SQL> STARTUP MOUNT;

create spfile from pfile;

lsnrctl start

3.2.7 将原主库转为物理standby

SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;

SQL> SHUTDOWN IMMEDIATE;

3.2.8 在原主库上开启managed recovery

orcl在应用bakorcl生成的重做数据时自动升级。

SQL> STARTUP MOUNT;

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE  DISCONNECT FROM SESSION;

 

#检查日志应用情况

select name,applied from v$archived_log;

3.2.9 切回主从

3.2.9.1 验证目标备用数据库是否准备好进行切换

新的switchover语句有一个VERIFY选项,该选项导致对切换所需的许多条件执行检查。检查的项目包括:Redo Apply是否在切换目标上运行;切换目标的发布版本是否为12.1或更高版本;切换目标是否同步;以及是否运行MRP。

SQL> ALTER DATABASE SWITCHOVER TO orcl VERIFY;

ORA-16475: succeeded with warnings, check alert log for more details

日志报错:SWITCHOVER VERIFY WARNING: switchover target has dirty online redo logfiles that require clearing.

不影响,可以略过。

3.2.9.2 切换主从

SQL> ALTER DATABASE SWITCHOVER TO orcl;

Database altered.

3.2.9.3 启动新主库orcl

SQL> ALTER DATABASE OPEN;

#检查下之前在bakorcl上插入的数据是否同步过来:

SQL> l

  1* select * from scott.t where id in(11,12)

SQL> /

 

       ID

----------

       11

       12

3.2.9.4 启动新备库bakorcl

sql>startup nomount;

sql>alter database mount standby database;

sql>alter database open;

3.2.9.5 在新备库bakorcl上开启Redo Apply

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

 

#检查主从同步情况

select name,applied from v$archived_log;

3.2.10 清理在主库orcl中创建的保证还原点

SQL> DROP RESTORE POINT PRE_UPGRADE;

 

本篇文章参考自oracle 12c DG文档’ 13 Using SQL Apply to Upgrade the Oracle Database

四 后续操作

4.1 配置DG BROKER

发现升级后,DG BROKER的配置被清空了,所以这里重新配置下DG BROKER

[oracle@db2 dbs]$ dgmgrl sys/orcl@orcl

DGMGRL> CREATE CONFIGURATION 'DRSolution' AS PRIMARY DATABASE IS 'orcl' CONNECT IDENTIFIER IS orcl;

Configuration "DRSolution" created with primary database "orcl"

DGMGRL> ADD DATABASE 'bakorcl' AS CONNECT IDENTIFIER IS bakorcl;

Error: ORA-16698: member has a LOG_ARCHIVE_DEST_n parameter with SERVICE attribute set

 

Failed.

sql>alter system set log_archive_dest_2='';

再重新添加bakorcl不再报错了。

DGMGRL>ENABLE CONFIGURATION;

DGMGRL>ENABLE DATABASE 'bakorcl';

DGMGRL> EDIT DATABASE 'bakorcl' SET PROPERTY 'LogXptMode'='SYNC';

 

Property "LogXptMode" updated

 

DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;

 

Succeeded.

 

DGMGRL> EDIT DATABASE 'orcl' SET PROPERTY 'LogXptMode'='SYNC';

 

Property "LogXptMode" updated

 

DGMGRL> EDIT DATABASE 'orcl' SET PROPERTY FastStartFailoverTarget='bakorcl';

 

Property "faststartfailovertarget" updated

 

DGMGRL> ENABLE FAST_START FAILOVER;

Warning: ORA-16827: Flashback Database is disabled

开启备库闪回:

SHUTDOWN IMMEDIATE;

SQL> startup nomount;

ORACLE instance started.

 

Total System Global Area 1811939328 bytes

Fixed Size                 8621808 bytes

Variable Size         1207959824 bytes

Database Buffers     587202560 bytes

Redo Buffers             8155136 bytes

SQL> alter database mount standby database;

 

Database altered.

 

SQL>  ALTER DATABASE FLASHBACK ON;

 

Database altered.

 

SQL> alter database open;

 

Database altered.

 

SQL> alter database recover managed standby database using current logfile disconnect from session;

再重新ENABLE FAST_START FAILOVER就可以了。

 

#启动observer

dgmgrl -logfile $ORACLE_HOME/observer.log sys/orcl@orcl "start observer" &

4.2 验证DG BROKER故障转移

--本篇文章主要参考了:

https://docs.oracle.com/en/database/oracle/oracle-database/12.2/sbydb/using-sql-apply-to-perform-rolling-upgrade.html#GUID-290F632F-5295-47F3-AEF1-2D37C69C00D7

及https://blog.csdn.net/yabingshi_tech/article/details/107255462

 

你可能感兴趣的:(2,ORACLE,学习,#,ORACLE,安装配置)