DG 切换步骤

登陆备库,检查同步状态和lag,确保lag应接近于0,同步状态正常:

 

复制代码
select * from v$dataguard_stats

 

select process,status,client_process,thread#,sequence#,block# from v$managed_standby;

 

 多执行几次,确保mrp应用的block#在变化

复制代码

 

检查主库的standby logfile (因为切换完成后,主库需要即成为备库,需要standby logfile)

SQL> select GROUP#,MEMBER from v$logfile where type='STANDBY'

SQL> select THREAD#,GROUP#,BYTES,BLOCKSIZE from v$standby_log;

检查thread#,确保1/2都有
检查大小,确保与备库redo log相同
检查blocksize确保与备库redo相同

 

用户oracle登陆主数据库(一节点)检测其switchover_status状态

复制代码
$sqlplus / as sysdba
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;

返回值需为:TO STANDBY或者SESSIONS ACTIVE
如果返回其他值则说明当前主数据库和备数据库数据同步不正常,需要解决后才能进行SWITCHOVER

复制代码

 

 

登陆主库二节点,关闭二节点实例

$sqlplus / as sysdba
SQL> shutdown immediate

 

主切备

复制代码

1、登陆主库一节点,启动switchover

如果是TO_PRIMARY 在主库的第一节点执行:

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY;

如果是SESSIONS ACTIVE 在主库的第一节点执行:

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN;

 

2、重启主库第一节点数据库实例:

SQL> shutdown immediate –如果已经关闭则不需执行。

SQL> startup nomount

SQL> alter database mount standby database;   --(11.2以后版本standby database可以省略)

 

3、在主库第一节点执行,开始应用日志:

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

 

4、启动主库第二节点实例

SQL> startup nomount

SQL> alter database mount standby database;

复制代码

备切主

复制代码
1、检查备库切换状态:
在备库第一节点执行: SQL> select SWITCHOVER_STATUS from v$database; 输出: • TO PRIMARY,可以继续切换。 • ACTIVE SESSION,在主数据库中存在活动的SQL会话,确定业务是否停止,可继续切换。 • RECOVERY NEEDED,归档日志未完全同步。 • SWITCHOVER LATENT,切换没有完成并返回到主数据库。 • SWITCHOVER PENDING,已收到主数据库切换请求但是还没有处理该请求的备用数据库。
2、为了防止 ORA-00600 [kglpnlt] 报错出现,在备库所有节点执行。 SQL> alter system flush share pool;
3、备库切换主库
如果是TO_PRIMARY,在备库第一节点执行: SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY; 如果是ACTIVE SESSION,在备库第一节点执行: SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN; 4、如果是RECOVERY NEEDED,分下列2个步骤检查: • 主库至备库的归档日志传输是否正常,主库检查v$datagaurd_status日志发送日志信息,备库检查归档路径下是否存在主库传输过来的日志文件。如果v$datagaurd_status存在发送报错,检查主备机之间的网络连通性。 • 如果归档日志已经传输到备机的归档路径下,检查DG应用进程是否启动,检查备库的Alert日志中是否存在DG应用进程相关的报错,根据报错信息继续排查。 如果是SWITCHOVER LATENT或SWITCHOVER PENDING 在备库第一节点执行下列命令: alter database recover managed standby database using current logfile disconnect from session; 等待状态变化为TO_PRIMARY后继续切换。

5、启动新主库:
alter database open;

6、启动新主库2节点
复制代码

 

切换后检查:

复制代码
检查日志传输是否处于实时应用模式
主库上执行
SQL>  SELECT RECOVERY_MODE FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID=2;
如果输出为:MANAGED REAL TIME APPLY,则正常。
否则检查Standby Logfile的大小、组数、logfile block size。
检查备库的Tempfile 检查备库的Tempfile是否生成。 SQL> select name,bytes from v$tempfile; 如果是文件系统 $ ls -l <TEMPFILE>
检查备库的归档清除策略 检查备库归档路径配置是否正确、空间是否充足,是否有定期清理机制。
复制代码

 

附录:

NOT ALLOWED

当前的数据库不是带有备用数据库的主数据库

PREPARING DICTIONARY

该逻辑备用数据库正在向一个主数据库和其他备用数据库发送它的重做数据,以便为切换做准备

PREPARING SWITCHOVER

接受用于切换的重做数据时,逻辑备用配置会使用它

RECOVERY NEEDED

备用数据库还没有接收到切换请求

SESSIONS ACTIVE

在主数据库中存在活动的SQL会话;在继续执行之前必须断开这些会话

SWITCHOVER PENDING

适用于那些已收到主数据库切换请求但是还没有处理该请求的备用数据库

SWITCHOVER LATENT

切换没有完成并返回到主数据库

TO LOGICAL STANDBY

主数据库已经收到了来自逻辑备用数据库的完整的字典

TO PRIMARY

该备用数据库可以转换为主数据库

TO STANDBY

该主数据库可以转换为备用数据库

posted on   数据与人文  阅读(12)  评论(0编辑  收藏  举报

相关博文:
阅读排行:
· 分享4款.NET开源、免费、实用的商城系统
· 全程不用写代码,我用AI程序员写了一个飞机大战
· MongoDB 8.0这个新功能碉堡了,比商业数据库还牛
· 记一次.NET内存居高不下排查解决与启示
· 白话解读 Dapr 1.15:你的「微服务管家」又秀新绝活了
< 2025年3月 >
23 24 25 26 27 28 1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31 1 2 3 4 5

统计

点击右上角即可分享
微信分享提示