复盘RAC-DG实战切换中遇到的问题

整体切换流程概述

本周末给客户做了一次HIS核心库RAC的ADG切换迁移，太久不干数据库的活，有点手生了，复盘了一下操作中遇到的问题。
通过ADG做RAC切换的主要操作内容参考以下这两篇就行，环境是一样的。
实战-RAC迁移项目(1/3)：RAC-RAC的DG搭建
实战-RAC迁移项目(2/3)：RAC-RAC主备切换/IP更换/DG恢复
整个切换的流程为：
1、开工前，做好RMAN全备份、参数文件内容比对、做好其它应用系统的备份、配置好防火墙策略禁止客户端访问（先不启用）。
2、启用防火墙策略，RAC主库关闭一个节点，检查DG状态
3、记录主库当前SCN号，备份一下归档。以备恢复使用。
4、修改好CONVERT参数。
5、和客户约定好，记录几个主要生产表的数据情况。
6、主备切换。
7、关闭主、备所有RAC节点，对调主备库的IP地址。
8、调整RAC参数适配新IP地址。
9、恢复DG，重新调整DG归档相关参数。
10、测试业务。
11、恢复生产。
说说我在这次实际项目中遇到的几个坑！总结一下就其实还是不够细心，发现问题的原因就是不仔细。

错误1-密码延迟认证特性+密码大小写敏感性=大量libary cache lock

先说密码延迟认证特性
在 Oracle 11g 中，为了提升安全性，Oracle 引入了『密码延迟验证』的新特性。这个特性的作用是，如果用户输入了错误的密码尝试登录，那么随着登录错误次数的增加，每次登录前验证的时间也会增加，以此减缓可能对于数据库重复的口令尝试攻击。
但是对于正常的系统，由于口令的更改，可能存在某些被遗漏的客户端，不断重复尝试，从而引起数据库内部长时间的 Library Cache Lock的等待，这种情形非常常见。
如果遇到这一类问题，可以通过Event 28401关闭这个特性，从而消除此类影响，以下命令将修改设置在参数文件中：

ALTER SYSTEM SET EVENT ='28401 TRACE NAME CONTEXT FOREVER, LEVEL 1' SCOPE = SPFILE;

再说密码大小写敏感的问题
在Oracle的11g之前的版本中密码是不区分大小写的（使用双引号强制除外）。在Oracle的11g版本中对此有所增强。从此密码有了大小写的区分，这个大小写敏感特性是通过SEC_CASE_SENSITIVE_LOGON参数来控制的，当值为false时，大小写不敏感。
这个问题普遍发生在数据库由10G升到11G之后。

alter system set sec_case_sensitive_logon = FALSE;

正题-我遇到的故障现象
上面这两个概念说完之后，再说说我遇到的问题。
第1个问题是：切换之后，有的业务系统报错，应用段日志反映用户名密码错误，当时不知道什么原因就重新修改了一下密码，让应用那段也改了一下。
第2个问题是：有些终端反映查询有些卡顿，我这边在sqldeveloper监控数据库看起来也不太正常，administrative显示较高
 

再就是抓了下这其间两个RAC节点的AWR报告，查看libray cache lock比较多
 

 

ASH报告中显示也是如此
 

和群里的小伙伴也沟通探讨了一下，一致的认为是密码这块导致的问题,于是尝试分析一下
参照Library cache lock 案例分析
打开 1017 errorstack，观察日志。

alter system set events '1017 trace name errorstack level 3';

用完记得关闭

alter system set events '1017 trace name errorstack off';

期间结果如下

确实是密码失败！
检查一下我这边新RAC库的参数sec_case_sensitive_logon

结合上述现象，于是选择修改
alter system set sec_case_sensitive_logon=false scope=both;
修改完后，立竿见影，监控指标一下就下来了。。。。

错误2-切换后备库RAC的SCAN-IP无法连接TNS-12541

测试TNSPING服务名都没有问题，使用vip连接数据库也没有问题，便是用SCAN-IP连就不行，仔细检查了一下，备库修改IP之后，在库要修改如下参数

alter system set local_listener='(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.56.203)(PORT=1521))))' scope=both sid='orcl1';
alter system set local_listener='(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.56.204)(PORT=1521))))' scope=both sid='orcl2';

问题就出在这里，IP我写错了，实际IP应该是192.168.50.XX，粗心大意导致。

错误3-切换后发现单机备库无法接收日志

检查发现实际生产中standby为db_unique_name我写成了tns-name了orcldg

alter system set log_archive_config='DG_CONFIG=(orcl,standby,primary)'  scope=both;

所以导致备库RFS进程没有启动，不接收日志，于是重新修改一下配置

错误4-immediate关闭一个主库节点卡住

这个纯是操作失误，应该先把这RAC2节点crsctl stop crs，然后再启停数据库，正常immediate关才比较好弄。
我直接immediate去关闭RAC2节点的实例，结果停了15分钟都没停下来，即使杀了LOCAL=NO，或者直接crsctl stop crs -f都卡在这了。最后杀了PMON进程，才进行下去。
这个注意一下就行，可以提前杀会话，或者crsctl stop crs默认就是shutdown abort，之后再干净关库吧。（纯个人习惯）。

补充一些ADG切换前的检查SQL

1、可在主库、备库执行查看

select INST_ID,NAME,open_mode,LOG_MODE,DATABASE_ROLE,PROTECTION_MODE,DB_UNIQUE_NAME from gv$database;

如果是主库：
OPEN_MODE正常状态为READ WRITE
LOG_MODE正常状态为ARCHIVELOG
DATABASE_ROLE正常状态为PRIMARY
如果是备库：
OPEN_MODE正常状态为READ ONLY WITH APPLY（ADG模式）
LOG_MODE正常状态为ARCHIVELOG
DATABASE_ROLE正常状态为PHYSICAL STANDBY
2、在主备库检查数据库坏块

Select * from v$database_block_corruption;
Select * from v$nonlogged_block;

3、检查主备库创建的最后一个归档日志

select   thread#, max(sequence#) "Last Primary Seq Generated"  
             from     gv$archived_log val, gv$database vdb
             where    val.resetlogs_change# = vdb.resetlogs_change#
             group by thread# order by 1;

4、备库检查日志应用情况，同步的情况下，3、4返回的结果一致

select    thread#, max(sequence#) "Last Standby Seq Applied"
              from     gv$archived_log val, gv$database vdb
              where    val.resetlogs_change# = vdb.resetlogs_change#
              and      val.applied in ('YES','IN-MEMORY')
              group by thread# order by 1;

5、在主库检查备库的日志路径是否正常

col DEST_NAME for a30
select DEST_ID,DEST_NAME,STATUS,RECOVERY_MODE from V$ARCHIVE_DEST_STATUS where DEST_NAME='LOG_ARCHIVE_DEST_2';

status正常状态为VALID ，如果备库停止日志传输，设置defer则status为BAD PARAM。更多详细可以参考这篇：https://blog.csdn.net/cuiyan1982/article/details/79832800
RECOVERY_MODE正常状态为 MANAGED REAL TIME APPLY
6、禁用或启用归档路径

alter system set log_archive_dest_state_2='defer' scope=both;
alter system set log_archive_dest_state_2='enable' scope=both;