Focus On Oracle

Installing, Backup & Recovery, Performance Tuning,
Troubleshooting, Upgrading, Patching

Oracle Engineered System


当前位置: 首页 » 技术文章 » Oracle

How to Convert Physical Standby to Snapshot Standby

Snapshot Standby Database

A snapshot standby database is a fully updatable standby database. A snapshot standby database receives and archives, but does not apply, redo data from a primary database. Redo data received from the primary database is applied when a snapshot standby database is converted back into a physical standby database, after discarding all local updates to the snapshot standby database.

A snapshot standby database typically diverges from its primary database over time because redo data from the primary database is not applied as it is received. Local updates to the snapshot standby database will cause additional divergence. The data in the primary database is fully protected however, because a snapshot standby can be converted back into a physical standby database at any time, and the redo data received from the primary will then be applied.

A snapshot standby database provides disaster recovery and data protection benefits that are similar to those of a physical standby database. Snapshot standby databases are best used in scenarios where the benefit of having a temporary, updatable snapshot of the primary database justifies increased time to recover from primary database failures.


当前环境信息

主库:两节点RAC11.2.0.4+ASM

备库:单实例11.2.0.4+本地文件系统


当前主备库状态信息

[oracle@pccb1 ~]$ dgmgrl sys/oracle
DGMGRL for Linux: Version 11.2.0.4.0 - 64bit Production

Copyright (c) 2000, 2009, Oracle. All rights reserved.

Welcome to DGMGRL, type "help" for information.
Connected.
DGMGRL> show configuration;

Configuration - dg_pccb

  Protection Mode: MaxPerformance
  Databases:
    pccb   - Primary database
    pccbdg - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS


将Physical Standby转化为Snapshot Standby

DGMGRL> help convert

Converts a database from one type to another

Syntax:

  CONVERT DATABASE <database name> TO
     {SNAPSHOT STANDBY|PHYSICAL STANDBY};

DGMGRL> convert database pccbdg to snapshot standby;
Converting database "pccbdg" to a Snapshot Standby database, please wait...
Database "pccbdg" converted successfully
DGMGRL> show configuration;

Configuration - dg_pccb

  Protection Mode: MaxPerformance
  Databases:
    pccb   - Primary database
    pccbdg - Snapshot standby database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS

DGMGRL>


Standby database alert

2017-03-17 07:54:25.595000 +08:00
Archived Log entry 111 added for thread 2 sequence 657 ID 0x71a0901 dest 1:
2017-03-17 08:08:36.933000 +08:00
RFS[9]: Selected log 8 for thread 1 sequence 684 dbid 119141633 branch 930070081
Media Recovery Waiting for thread 1 sequence 684 (in transit)
Recovery of Online Redo Log: Thread 1 Group 8 Seq 684 Reading mem 0
  Mem# 0: /oradata/pccbdg/stdredo02.log
2017-03-17 08:08:40.220000 +08:00
Archived Log entry 112 added for thread 1 sequence 683 ID 0x71a0901 dest 1:
2017-03-17 09:26:06.162000 +08:00
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL
MRP0: Background Media Recovery cancelled with status 16037
Errors in file /pccb/ordb/log/diag/rdbms/pccbdg/pccbdg/trace/pccbdg_pr00_10006.trc:
ORA-16037: ?????????????????????
Managed Standby Recovery not using Real Time Apply
Recovery interrupted!
Recovered data files to a consistent state at change 3159534075
MRP0: Background Media Recovery process shutdown (pccbdg)
2017-03-17 09:26:08.165000 +08:00
Managed Standby Recovery Canceled (pccbdg)
Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL
All dispatchers and shared servers shutdown
CLOSE: killing server sessions.
CLOSE: all sessions shutdown successfully.
2017-03-17 09:28:08.364000 +08:00
SMON: disabling cache recovery
alter database convert to snapshot standby
Starting background process RVWR
RVWR started with pid=18, OS id=7964
2017-03-17 09:28:11.610000 +08:00
Allocated 15937344 bytes in shared pool for flashback generation buffer
Created guaranteed restore point SNAPSHOT_STANDBY_REQUIRED_03/17/2017 09:28:08
Killing 8 processes with pids 9952,9955,9973,9977,9981,9983,10103,9987 (all RFS) in order to disallow current and future RFS connections. Requested by OS process 9946
2017-03-17 09:28:12.705000 +08:00
idle dispatcher 'D000' terminated, pid = (17, 1)
2017-03-17 09:28:13.719000 +08:00
Begin: Standby Redo Logfile archival
End: Standby Redo Logfile archival
RESETLOGS after incomplete recovery UNTIL CHANGE 3159534075
Resetting resetlogs activation ID 119146753 (0x71a0901)
Online log /oradata/pccbdg/redo01.log: Thread 1 Group 1 was previously cleared
Online log /oradata/pccbdg/redo02.log: Thread 1 Group 2 was previously cleared
Online log /oradata/pccbdg/redo03.log: Thread 1 Group 3 was previously cleared
Online log /oradata/pccbdg/redo04.log: Thread 2 Group 4 was previously cleared
Online log /oradata/pccbdg/redo05.log: Thread 2 Group 5 was previously cleared
Online log /oradata/pccbdg/redo06.log: Thread 2 Group 6 was previously cleared
Standby became primary SCN: 3159534073
Setting recovery target incarnation to 2
AUDIT_TRAIL initialization parameter is changed back to its original value as specified in the parameter file.
CONVERT TO SNAPSHOT STANDBY: Complete - Database mounted as snapshot standby
Completed: alter database convert to snapshot standby
2017-03-17 09:28:15.163000 +08:00
ALTER DATABASE OPEN
Data Guard Broker initializing...
Data Guard Broker initialization complete
Assigning activation ID 127286592 (0x7963d40)
Thread 1 opened at log sequence 1
  Current log# 1 seq# 1 mem# 0: /oradata/pccbdg/redo01.log
Successful open of redo thread 1
ARC6: Becoming the 'no SRL' ARCH
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
ARC7: Becoming the 'no SRL' ARCH
SMON: enabling cache recovery
[9946] Successfully onlined Undo Tablespace 2.
Undo initialization finished serial:0 start:746248684 end:746248894 diff:210 (2 seconds)
Dictionary check beginning
Dictionary check complete
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
SMON: enabling tx recovery
Database Characterset is ZHS16GBK
2017-03-17 09:28:16.255000 +08:00
No Resource Manager plan active
Starting background process SMCO
SMCO started with pid=33, OS id=7972
2017-03-17 09:28:17.568000 +08:00
Redo thread 2 internally disabled at seq 1 (CKPT)
ARC2: Becoming the 'no SRL' ARCH
ARC2: Archiving disabled thread 2 sequence 1
Archived Log entry 113 added for thread 2 sequence 1 ID 0x0 dest 1:
ARC3: Becoming the 'no SRL' ARCH
Starting background process QMNC
QMNC started with pid=34, OS id=7974
LOGSTDBY: Validating controlfile with logical metadata
LOGSTDBY: Validation complete
2017-03-17 09:28:19.797000 +08:00
Completed: ALTER DATABASE OPEN
RFS[11]: Assigned to RFS process 7996
RFS[11]: Selected log 7 for thread 1 sequence 685 dbid 119141633 branch 930070081
RFS[12]: Assigned to RFS process 7998
RFS[12]: Selected log 8 for thread 1 sequence 684 dbid 119141633 branch 930070081
RFS[13]: Assigned to RFS process 8000
RFS[13]: Selected log 11 for thread 2 sequence 658 dbid 119141633 branch 930070081
RFS[14]: Assigned to RFS process 8004
RFS[14]: Selected log 12 for thread 2 sequence 659 dbid 119141633 branch 930070081
Starting background process CJQ0
CJQ0 started with pid=46, OS id=8006
2017-03-17 09:28:21.060000 +08:00
Active Session History (ASH) performed an emergency flush. This may mean that ASH is undersized. If emergency flushes are a recurring issue, you may consider increasing ASH size by setting the value of _ASH_SIZE to a sufficiently large value. Currently, ASH size is 8388608 bytes. Both ASH size and the total number of emergency flushes since instance startup can be monitored by running the following query:
 select total_size,awr_flush_emergency_count from v$ash_info;
ARC4: Becoming the 'no SRL' ARCH
2017-03-17 09:28:22.839000 +08:00
Archived Log entry 114 added for thread 2 sequence 658 ID 0x71a0901 dest 1:
2017-03-17 09:28:24.448000 +08:00
ARC5: Becoming the 'no SRL' ARCH
2017-03-17 09:28:25.431000 +08:00
Archived Log entry 115 added for thread 1 sequence 684 ID 0x71a0901 dest 1:
adrci>


注意以下节点

A.备库处于mount/read only/read only with apply等状态,所以备库自身不会产生redo日志

B.将Physical Standby转化为Snapshot Standby,可以看到是在备库上创建了一担保还原点(guaranteed restore point),与启用不启用flashback database没有直接性的关系。转化之后,Snapshot Standby database为继续接受来自主库的日志


Reference

http://docs.oracle.com/database/121/SBYDB/manage_ps.htm#SBYDB4801




关键词:maa dg 11g rac 

相关文章

Oracle 19c新特性之Automatic Flashback
Oracle 19c新特性之RAC Automatic Failback Service
Install Oracle RAC Database 19c Step by Step
Oracle事务卫士(Transaction Guard)和应用连续性(Application Continuity)
PDB Migration/Failover in Dataguard
Install Oracle Domain Service Cluster Step by Step
Oracle RAC and Third Party Cloud
ORA-12514 During DataPump Export/Import In RAC
How to config IB network listener
Oracle MAA汇总
Oracle Exadata ADG & GDS
在OEL6.8上安装12.2 RAC
Top