Recover standby database after primary resetlogs

简介: 一般在主库需要恢复并open resetlogs 方式打开的情况下,备库需要重做来构建主备同步架构,但有些情况其实不必大费周章,只需要备库开启flashback功能,就可以在较短的时间内恢复主备同步进程。
一般在主库需要恢复并open resetlogs 方式打开的情况下,备库需要重做来构建主备同步架构,但有些情况其实不必大费周章,只需要备库开启flashback功能,就可以在较短的时间内恢复主备同步进程。

(一)
在当主库resetlogs 之后,查询当时的RESETLOGS_CHANGE#(SCN),若小于备库SCN ,可以通过闪回备库到RESETLOGS_CHANGE#(SCN),直接修复备库
(二)
主库状态查询

SQL>  select dbid,current_scn,RESETLOGS_CHANGE#,flashback_on from v$database;

      DBID CURRENT_SCN RESETLOGS_CHANGE# FLASHBACK_ON
---------- ----------- ----------------- ------------------
1520403684     2109683           2108651 YES

备库状态查询

# 同步中
SQL> select max(sequence#),applied,archived from v$archived_log group by applied,archived;

MAX(SEQUENCE#) APPLIED   ARC
-------------- --------- ---
             6 IN-MEMORY YES
             5 YES       YES

SQL>  select dbid,current_scn,RESETLOGS_CHANGE#,flashback_on from v$database;

      DBID CURRENT_SCN RESETLOGS_CHANGE# FLASHBACK_ON
---------- ----------- ----------------- ------------------
1520403684     2110296           2108651 YES

(三)
主库

# 备份数据库
RMAN> backup database;

#创建还原点
SQL> create restore point BEFORE_UPDATE;

#执行更新操作
SQL>  delete  from  baiyang.t where id = 99;

6 rows deleted.

SQL> commit;

# 查询当前数据库状态
SQL> select dbid,current_scn,RESETLOGS_CHANGE#,flashback_on from v$database;

      DBID CURRENT_SCN RESETLOGS_CHANGE# FLASHBACK_ON
---------- ----------- ----------------- ------------------
1520403684     2110440           2108651 YES

# 关闭数据库
SQL> shutdown immediate

# 恢复数据库
SQL> startup mount  

RMAN> 
run {
restore database;
recover database until restore point BEFORE_UPDATE;
}

# 打开数据库
SQL> alter database open RESETLOGS;

# 查看数据库状态
SQL> select dbid,current_scn,RESETLOGS_CHANGE#,flashback_on from v$database;

      DBID CURRENT_SCN RESETLOGS_CHANGE# FLASHBACK_ON
---------- ----------- ----------------- ------------------
1520403684     2110715           ***2110399*** YES

# 查询表数据
SQL> select count(*) from  baiyang.t where id = 99;

  COUNT(*)
----------
         6

在进行一系列令人窒息的操作之后,主库表baiyang.t 被删除的数据重新回来了
(四)
备库

#查看当前备库状态,SCN大于主库RESETLOGS_CHANGE#,可以通过闪回来恢复备库同步

SQL> select dbid,current_scn,RESETLOGS_CHANGE#,flashback_on from v$database;

      DBID CURRENT_SCN RESETLOGS_CHANGE# FLASHBACK_ON
---------- ----------- ----------------- ------------------
1520403684     ***2110533***           2108651 YES

# 实时应用日志进程已经停止,在告警日志中可以看到MRP0进程已经停止的信息

SQL> select max(sequence#),applied,archived from v$archived_log group by applied,archived;

MAX(SEQUENCE#) APPLIED   ARC
-------------- --------- ---
             7 YES       YES
             2 NO        YES
          

(五)
备库,现在闪回数据库

SQL> shutdown immediate
SQL> startup mount

# 闪回数据库
RMAN> flashback database until scn 1922219;
SQL> alter database open;

# 开始实时应用
SQL> select max(sequence#),applied,archived from v$archived_log group by applied,archived;

MAX(SEQUENCE#) APPLIED   ARC
-------------- --------- ---
             3 IN-MEMORY YES
             7 YES       YES

(六)
如果备库SCN小于主库resetlogs 之后的情况,是不是需要闪回呢?
不需要。
考虑一种情况,在主库出现故障之前,备库已经停止同步,那么主库恢复并resetlogs之后,直接重启备库日志应用进程即可。

**(七)
那主库出现什么故障的时候,备库需要重做呢?**

目录
相关文章
|
5月前
|
SQL 移动开发 Java
“\r\n### Error updating database. ,解决问题的思路在于认真参考给的错误提示,看错误提示,这里我的数据表,没有写primary key 导致的
“\r\n### Error updating database. ,解决问题的思路在于认真参考给的错误提示,看错误提示,这里我的数据表,没有写primary key 导致的
|
SQL Java 关系型数据库
spring boot集成mybatis只剩两个sql 并提示 Cannot obtain primary key information from the database, generated objects may be incomplete
spring boot集成mybatis只剩两个sql 并提示 Cannot obtain primary key information from the database, generated objects may be incomplete
157 0
spring boot集成mybatis只剩两个sql 并提示 Cannot obtain primary key information from the database, generated objects may be incomplete
|
SQL 监控 关系型数据库
mysql主从复制错误:Last_SQL_Error: Error 'Duplicate entry '327' for key 'PRIMARY'' on query. Default database: 'xxx'. Query:
这个算不算解决,我都不太清楚,因为我感觉网上的说法,只是把错误忽略了,不表示以后用从库时不会出问题!!! 解决的办法是在从库上执行: mysql> slave stop; mysql> set GLOBAL SQL_SLAVE_SKIP_COUNTER=1; mysql> slave s...
1306 0
|
Oracle 关系型数据库 Unix
ORA-15061 reported while doing a file operation with 11.1 or 11.2 ASM after PSU applied in database
ORA-15061 reported while doing a file operation with 11.1 or 11.2 ASM after PSU applied in database home [ID 1070880.
1010 0
|
Oracle 关系型数据库 Unix
Ora-12547: Tns:Lost Contact Creating Database After Clean Installation
Ora-12547: Tns:Lost Contact Creating Database After Clean Installation [ID 744512.
1158 0