分类导航

程序笔记发布时间：2022-07-20 发布网站：大佬教程 code.js-code.com

大佬教程收集整理的这篇文章主要介绍了三节点DG环境主库单机转RAC（DG主备切换），大佬教程大佬觉得挺不错的，现在分享给大家，也给大家做个参考。

三节点DG环境主库单机转RAC（DG主备切换）

DBhanG 2020-08-24 09:03:22 164 收藏文章标签： linux 数据库 Oracle sql 运维版权生产三节点DG环境主库单机转RAC（DG主备切换）所有数据均以脱敏prod主库（15.91）有关DG环境的参数：

*.db_unique_name='prod'*.fal_client='prod'*.fal_server='proddg'*.log_archive_config='DG_CONFIG=(prod,proddg,proddg2)'*.log_archive_dest_1='LOCATIOn=/data/zjcbss/arch'*.log_archive_dest_2='service=proddg arch async VALID_FOR=(ONLINE_LOGFILES,PRIMary_ROLE) DB_UNIQUE_NAME=proddg'*.log_archive_dest_3='serviCE=proddg2 LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMary_ROLE) DB_UNIQUE_NAME=proddg2'*.log_archive_dest_state_2='ENABLE'*.standby_file_management='AUTO'123456789proddg备库1（15.55）有关DG环境的参数：

*.db_file_name_convert='/data/prod2/data','/oradata/@R_197_11065@'*.log_file_name_convert='/data/prod2/data','/oradata/@R_197_11065@'*.db_unique_name='proddg'*.fal_client='proddg'*.fal_server='prod'*.log_archive_config='DG_CONFIG=(prod,proddg)'*.log_archive_dest_1='LOCATIOn=/oradata/Oracle/arch'*.log_archive_dest_2='serviCE=prod LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMary_ROLE) DB_UNIQUE_NAME=prod'*.log_archive_dest_state_2='ENABLE'*.standby_file_management='AUTO'12345678910proddg2备库2（15.101）有关DG环境的参数：

*.db_file_name_convert='/data/prod2/data','/oradata/zjcbss'*.log_file_name_convert='/data/prod2/data','/oradata/zjcbss/prod2/data'*.fal_client='proddg2'*.fal_server='prod'*.log_archive_config='DG_CONFIG=(prod,proddg,proddg2)'*.log_archive_dest_1='LOCATIOn=/oradata/zjcbss/arch'*.log_archive_dest_2='serviCE=prod LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMary_ROLE) DB_UNIQUE_NAME=prod'*.log_archive_dest_state_2='ENABLE'*.standby_file_management='AUTO'123456789切换后的环境为：

主库proddg2 192.168.15.101 备库proddg 192.168.15.55备库prod 192.168.15.91

//先切换，后修改参数//切换成功后，proddg2为主库，prod为备库，proddg不属于该DG环境中，后续修改参数将proddg加入，将prod剔除123456一：切换前准备：

1.本地杀会话杀客户端进程：ps -ef|grep "LOCAL=NO"|grep -v grep|awk '{print "kill -9 " $2}'| sh --->直接删

查询连接会话数量：ps -ef|grep "LOCAL=NO"| wc -l --> 生产中是杀不干净的，几秒钟连接数又到了几十个

SELEct count(*) from v$session where username is not null;

2.修改crontab删除归档脚本三节点关闭归档日志删除计划任务//注释掉crontabcronbab -l

3.在主库切换归档日志（多次切换，确保备库正常接收）alter system switch logfile

4.standby redolog数据量配置正确：standby redolog=redolog + 1（经检查现环境符合要求，无需修改）12345678910111213141516171819二：开始进行switchover切换

1.主库prod切为备库：

SELEct name,database_role,switchover_status froR_299_11845@ v$database;

NAME database_role SWITCHOVER_STATUS--------- ---------------- --------------------prod PRIMary SESSIONS ACTIVE

如果switchover_status状态是SESSIONS ACTIVE --> 生产下百分百是session active

使用下面命令切换alter database commit to switchover to physical standby with session shutdown; 123456789102.切换完成后数据库会被关闭,重新启动查看切换完的状态：

SELEct name,database_role,switchover_status froR_299_11845@ v$database;

NAME database_role SWITCHOVER_STATUS--------- ---------------- --------------------prod PHYSICAL STANDBY TO PRIMary//如果此时switchover_status显示为recovery needed，则启动日志应用服务alter database recover managed standby database disconnect from session后，再次查看

//在生产上我切换完，他的switchover_status依旧为session active，没有去过多在意

SELEct database_role,protection_mode,protection_level from v$database;

database_role protection_mode PROTECTION_LEVEL---------------- -------------------- --------------------PHYSICAL STANDBY MAXIMUM PERFO@R_197_11065@CE MAXIMUM PERFO@R_197_11065@CE123456789101112131415163.备库proddg2切为主库：

//查看切换状态SELEct database_role,switchover_status froR_299_11845@ v$database;

database_role SWITCHOVER_STATUS---------------- --------------------PHYSICAL STANDBY TO PRIMary（如果此时switchover_status为not allowed，可以尝试进行切换，按错误提示进行处理，一般为ORA-16139: media recovery required尝试进行recover：SQL>recover managed standby database using current logfile disconnect from session;)

//生产上，备库竟然也是session active，并且该库也不是被用于查询使用。

//备库切换为主库alter database commit to switchover to priMary **with session shutdown;** 123456789101112134.查看切换后的状态：

SQL> SELEct name,database_role,protection_mode,protection_level from v$database;

NAME database_role protection_mode PROTECTION_LEVEL--------- ---------------- -------------------- --------------------proddg2 PRIMary MAXIMUM PERFO@R_197_11065@CE UNPROTECTED

SQL> alter database open;1234567三：切换后的参数修改

proddg2：alter system set log_archive_config='DG_CONFIG=(proddg2,proddg)' scope=both;alter system set log_archive_dest_2='serviCE=proddg LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMary_ROLE) DB_UNIQUE_NAME=proddg' scope=both;alter system set log_archive_dest_state_2='ENABLE' scope=both;alter system set fal_server='proddg' scope=both;alter system set fal_client='proddg2' scope=both;alter system set db_file_name_convert='/oradata/@R_197_11065@','/oradata/zjcbss' scope=spfile;alter system set log_file_name_convert='/oradata/@R_197_11065@','/oradata/zjcbss/prod2/data' scope=spfile;12345678proddg：

alter system set log_archive_config='DG_CONFIG=(proddg2,proddg)' scope=both;alter system set log_archive_dest_2='serviCE=proddg2 LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMary_ROLE) DB_UNIQUE_NAME=proddg2' scope=both;alter system set log_archive_dest_state_2='ENABLE' scope=both;alter system set fal_server='proddg2' scope=both;alter system set fal_client='proddg' scope=both;alter system set db_file_name_convert='/oradata/zjcbss','/oradata/@R_197_11065@' scope=spfile;alter system set log_file_name_convert='/oradata/zjcbss/prod2/data','/oradata/@R_197_11065@' scope=spfile;1234567prod无需修改参数，该节点已从DG环境中剔除

四：切换后测试

1.启动proddg的日志应用服务：SQL> alter database recover managed standby database disconnect from session;

2.在新主库proddg2进行几次日志切换，查看alert日志，判断日志是否正常传输SQL> alter system switch logfile;

//如果日志没有正常传输，则

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

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

重新开启一下service传输，再次查看alert日志，判断日志是否正常传输123456789101112133.检查日志应用情况：

SQL> SELEct max(SEQUENCE#) from v$archived_log where applied='YES'; //备库查询SQL> SELEct max(SEQUENCE#) from v$archived_log; //主库查询12五:其他配置

1.在新的DG环境下重新布置归档日志删除脚本将prod的归档日志删除脚本拷贝到proddg2相同目录下,并配置crontab计划任务0,10,20,30,40,50 * * * * /home/Oracle/delArch/delArchivelog.sh >> /home/Oracle/delArch/delArchivelog.log

//注意修改脚本中的SID

2.将proddg的归档日志删除脚本注释打开

3.为了业务不修改service_name即可连接在proddg库中再添加一个service_name=prodalter system set @R_61_1717@=proddg2,prod scope=both;

4.系统业务进行测试是否正常12345678910111213六：遇到的问题汇总：

//主库切换为备库切换完后，他的switchover_status依旧为session active，正常情况应该为to priMary个人理解：切换为备库后，数据库会被关闭，再次启动后，会启动到read only状态，启动后，还是有新会话进行连接查询，所以该状态为session active

当DG切换完成后，日志正常传输以及日志正常应用，由于db_file_name_convert与log_file_name_convert参数被修改，并且该参数无法动态修改，只能使用scope=spfile，所以需要重新启动数据库，当重新启动到mount状态时，启动MRP进行日志应用，前台提示启动MRP成功，后台警告日志滚动将MRP强制关闭，并且后台日志中还出现许多许多找不到数据文件的错误（mount阶段会检测控制文件中记录的数据文件，如果数据文件不存在会在后台日志中报错，当open时，才会在前台报错，无法锁定数据文件。）排查后最终发现，控制文件中记录的数据文件路径不正确，将228个数据文件进行重命名后，错误消失，日志传输正常，MRP进程启动正常。