备用数据库快照
2013-11-12 10:57
176 查看
1.停止Redo Apply
如果备库正处于Redo Apply过程，需要先取消。
sys@ora11gdg> alter database recover managed standby database cancel;
Database altered.
2.查看当前备库状态确保备库处于MOUNTED状态
sys@ora11gdg> select database_role,open_mode from v$database;
DATABASE_ROLE OPEN_MODE
---------------- --------------------
PHYSICAL STANDBY MOUNTED
此时备库是物理备库角色，运行模式是MOUNTED。
3.确保闪回恢复区已指定
友情提示：实现Snapshot Standby数据库功能并不需要开启主库和备库的闪回数据库（Flashback Database）功能，与是否开启闪回数据库无关。
sys@ora11gdg> show parameter db_recovery_file_dest
NAME TYPE VALUE
--------------------------- ------------ ------------------------------------
db_recovery_file_dest string /u01/app/oracle/flash_recovery_area
db_recovery_file_dest_size big integer 3852M
确认主库闪回功能并未开启
sys@ora11g> select FLASHBACK_ON from v$database;
FLASHBACK_ON
------------------
NO
确认备库闪回功能并未开启
sys@ora11gdg> select FLASHBACK_ON from v$database;
FLASHBACK_ON
------------------
NO
4.调整备库到Snapshot Standby数据库状态
只需要执行一条非常简单的SQL命令便可以将备库调整到Snapshot Standby数据库。
sys@ora11gdg> alter database convert to snapshot standby;
Database altered.
sys@ora11gdg> select database_role,open_mode from v$database;
DATABASE_ROLE OPEN_MODE
---------------- --------------------
SNAPSHOT STANDBY MOUNTED
5.将备库置于对外可读写状态
sys@ora11gdg> alter database open;
Database altered.
sys@ora11gdg> select database_role,open_mode from v$database;
DATABASE_ROLE OPEN_MODE
---------------- --------------------
SNAPSHOT STANDBY READ WRITE
一套全新的可读写数据库展现在我们面前。
6.分析切换过程中的日志信息
ora11g主库alert日志：
Mon July 19 18:46:28 2013
LNS: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (3135)
LNS: Destination LOG_ARCHIVE_DEST_2 network reconnect abandoned
Errors in file /u01/app/oracle/diag/rdbms/ora11g/ora11g/trace/ora11g_nsa2_27302.trc:
ORA-03135: connection lost contact
Error 3135 for archive log file 2 to 'ora11gdg'
Errors in file /u01/app/oracle/diag/rdbms/ora11g/ora11g/trace/ora11g_nsa2_27302.trc:
ORA-03135: connection lost contact
LNS: Failed to archive log 2 thread 1 sequence 50 (3135)
Errors in file /u01/app/oracle/diag/rdbms/ora11g/ora11g/trace/ora11g_nsa2_27302.trc:
ORA-03135: connection lost contact
ora11gdg备库alert日志：
Mon July 19 18:46:26 2013
alter database convert to snapshot standby
Starting background process RVWR
Mon July 19 18:46:26 2013
RVWR started with pid=26, OS id=8824
Allocated 3981204 bytes in shared pool for flashback generation buffer
Created guaranteed restore point SNAPSHOT_STANDBY_REQUIRED_03/19/2013 18:46:26
krsv_proc_kill: Killing 3 processes (all RFS)
Begin: Standby Redo Logfile archival
End: Standby Redo Logfile archival
RESETLOGS after complete recovery through change 1472476
Resetting resetlogs activation ID 4174194338 (0xf8cd26a2)
Online log /u01/app/oracle/oradata/ora11gdg/redo01.log: Thread 1 Group 1 was previously cleared
Online log /u01/app/oracle/oradata/ora11gdg/redo02.log: Thread 1 Group 2 was previously cleared
Online log /u01/app/oracle/oradata/ora11gdg/redo03.log: Thread 1 Group 3 was previously cleared
Standby became priJulyy SCN: 1472474
Mon July 19 18:46:29 2013
Setting recovery target incarnation to 5
CONVERT TO SNAPSHOT STANDBY: Complete - Database mounted as snapshot standby
Completed: alter database convert to snapshot standby
关键的一行提示信息“Created guaranteed restore point SNAPSHOT_STANDBY_REQUIRED_03/19/2013 18:46:26”，这里给出了我们转换成snapshot的时刻，便于后面的回切。
7.测试备库处于Snapshot Standby数据库对主库日志的接收
当主库切换日志时，备库依然可以接收到日志，只是并不应用
1）主库切换日志
sys@ora11g> alter system switch logfile;
System altered.
2）主库记录的alert日志内容
ora11g主库alert日志：
Mon July 19 18:52:00 2013
Thread 1 cannot allocate new log, sequence 52
Private strand flush not complete
Current log# 3 seq# 51 mem# 0: /u01/app/oracle/oradata/ora11g/redo03.log
Mon July 19 18:52:00 2013
ARC3: Standby redo logfile selected for thread 1 sequence 50 for destination LOG_ARCHIVE_DEST_2
Thread 1 advanced to log sequence 52 (LGWR switch)
Current log# 1 seq# 52 mem# 0: /u01/app/oracle/oradata/ora11g/redo01.log
Mon July 19 18:52:03 2013
Archived Log entry 91 added for thread 1 sequence 51 ID 0xf8cd26a2 dest 1:
Mon July 19 18:52:03 2013
LNS: Standby redo logfile selected for thread 1 sequence 51 for destination LOG_ARCHIVE_DEST_2
LNS: Standby redo logfile selected for thread 1 sequence 52 for destination LOG_ARCHIVE_DEST_2
ora11gdg备库alert日志：
Mon July 19 18:52:00 2013
RFS[5]: Assigned to RFS process 9174
RFS[5]: Identified database type as 'snapshot standby': Client is ARCH pid 27296
Mon July 19 18:52:00 2013
RFS[6]: Assigned to RFS process 9176
RFS[6]: Identified database type as 'snapshot standby': Client is ARCH pid 27300
RFS[6]: Selected log 4 for thread 1 sequence 50 dbid -120744030 branch 778023141
Mon July 19 18:52:00 2013
Archived Log entry 47 added for thread 1 sequence 50 ID 0xf8cd26a2 dest 1:
Mon July 19 18:52:03 2013
RFS[7]: Assigned to RFS process 9180
RFS[7]: Identified database type as 'snapshot standby': Client is LGWR ASYNC pid 27302
RFS[7]: Selected log 4 for thread 1 sequence 51 dbid -120744030 branch 778023141
Mon July 19 18:52:04 2013
Archived Log entry 48 added for thread 1 sequence 51 ID 0xf8cd26a2 dest 1:
RFS[7]: Selected log 4 for thread 1 sequence 52 dbid -120744030 branch 778023141
3）查看主库和备库归档目录下的日志文件内容
（1）主库归档日志文件
ora11g@secdb /home/oracle/arch/ora11g$ ls -ltr
total 879M
……省略其他……
-rw-r----- 1 oracle oinstall 1.1M July 19 18:51 1_50_778023141.arc
-rw-r----- 1 oracle oinstall 363K July 19 18:52 1_51_778023141.arc
（2）备库归档日志文件
ora11g@secdb /home/oracle/arch/ora11gdg$ ls -ltr
total 847M
……省略其他……
-rw-r----- 1 oracle oinstall 1.1M July 19 18:52 1_50_778023141.arc
-rw-r----- 1 oracle oinstall 363K July 19 18:52 1_51_778023141.arc
可见，备库已经接受到主库发过来的日志。
8.在Snapshot Standby数据创建用户和表并初始化数据
sys@ora11gdg> create user ocmu identified by ocmu;
User created.
secooler@ora11gdg> grant dba to ocmu;
Grant succeeded.
secooler@ora11gdg> conn ocmu/ocmu
Connected.
ocmu@ora11gdg> create table t (x varchar2(8));
Table created.
ocmu@ora11gdg> insert into t values ('Secooler');
1 row created.
ocmu@ora11gdg> commit;
Commit complete.
ocmu@ora11gdg> select * from t;
X
--------
Secooler
结论，此时备库是一个可任意修改和调整的状态，也就是我们要的“READ WRITE”可读写状态。
特别注意的是，原理上实现Snapshot Standby数据库功能是基于闪回数据原理的，因此任何导致闪回数据库无法回退的动作在这里也要规避，否则Snapshot Standby数据库将无法回到曾经的备库恢复状态。
9.恢复Snapshot Standby数据库为Physical Standby数据库
1）重启备库到MOUNTED状态
ocmu@ora11gdg> conn / as sysdba
Connected.
sys@ora11gdg> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
sys@ora11gdg> startup mount
ORACLE instance started.
Total System Global Area 313860096 bytes
Fixed Size 1336232 bytes
Variable Size 268438616 bytes
Database Buffers 37748736 bytes
Redo Buffers 6336512 bytes
Database mounted.
sys@ora11gdg> select database_role,open_mode from v$database;
DATABASE_ROLE OPEN_MODE
---------------- --------------------
SNAPSHOT STANDBY MOUNTED
2）一条命令恢复原物理备库身份
sys@ora11gdg> alter database convert to physical standby;
Database altered.
3）备库的alert日志清楚的记录了这个切换的过程
Mon July 19 19:30:24 2013
alter database convert to physical standby
ALTER DATABASE CONVERT TO PHYSICAL STANDBY (ora11gdg)
Flashback Restore Start
Flashback Restore Complete
Stopping background process RVWR
Deleted Oracle managed file /u01/app/oracle/flash_recovery_area/ORA11GDG/flashback/o1_mf_7pg3n2jc_.flb
Deleted Oracle managed file /u01/app/oracle/flash_recovery_area/ORA11GDG/flashback/o1_mf_7pg52yst_.flb
Guaranteed restore point dropped
Clearing standby activation ID 4174523254 (0xf8d22b76)
The priJulyy database controlfile was created using the
'MAXLOGFILES 30' clause.
There is space for u
c6f7
p to 27 standby redo logfiles
Use the following SQL commands on the standby database to create
standby redo logfiles that match the priJulyy database:
ALTER DATABASE ADD STANDBY LOGFILE 'srl1.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl2.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl3.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl4.f' SIZE 52428800;
Completed: alter database convert to physical standby
从alert日志中可以得到恢复方法使用的闪回数据库功能实现的，也就是说，即便备库没有运行在闪回数据库状态，依然可以使用闪回数据库功能完成备库的角色转换。
4）重启备库到自动恢复日志状态
（1）此时数据库处于NOMOUNTED状态，需要重新启动数据库。
注意这里是重启数据库，而不是使用alter命令调整，否则会收到如下报错：
sys@ora11gdg> alter database mount;
alter database mount
*
ERROR at line 1:
ORA-00750: database has been previously mounted and dismounted
sys@ora11gdg> shutdown immediate;
ORA-01507: database not mounted
ORACLE instance shut down.
sys@ora11gdg> startup mount;
ORACLE instance started.
Total System Global Area 313860096 bytes
Fixed Size 1336232 bytes
Variable Size 268438616 bytes
Database Buffers 37748736 bytes
Redo Buffers 6336512 bytes
Database mounted.
sys@ora11gdg> alter database recover managed standby database disconnect;
Database altered.
（2）查看备库alert日志，可以清楚的看到恢复的过程。
Mon July 19 19:43:48 2013
Managed Standby Recovery not using Real Time Apply
Parallel Media Recovery started with 4 slaves
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Clearing online redo logfile 1 /u01/app/oracle/oradata/ora11gdg/redo01.log
Clearing online log 1 of thread 1 sequence number 1
Completed: alter database recover managed standby database disconnect
Clearing online redo logfile 1 complete
Clearing online redo logfile 2 /u01/app/oracle/oradata/ora11gdg/redo02.log
Clearing online log 2 of thread 1 sequence number 2
Clearing online redo logfile 2 complete
Media Recovery Log /home/oracle/arch/ora11gdg/1_49_778023141.arc
Media Recovery Log /home/oracle/arch/ora11gdg/1_50_778023141.arc
Media Recovery Log /home/oracle/arch/ora11gdg/1_51_778023141.arc
Media Recovery Log /home/oracle/arch/ora11gdg/1_52_778023141.arc
Media Recovery Log /home/oracle/arch/ora11gdg/1_53_778023141.arc
Media Recovery Log /home/oracle/arch/ora11gdg/1_54_778023141.arc
Media Recovery Waiting for thread 1 sequence 55
（3）查看V$ARCHIVED_LOG动态性能视图查看日志应用情况
sys@ora11gdg> select sequence#, first_time, next_time, applied from v$archived_log order by sequence#;
SEQUENCE# FIRST_TIME NEXT_TIME APPLIED
---------- ----------------- ----------------- ---------
……省略其他数据……
49 20130720 18:32:32 20130720 18:38:03 YES
50 20130720 18:38:03 20130720 18:51:00 YES
51 20130720 18:51:00 20130720 18:52:03 YES
52 20130720 18:52:03 20130720 19:09:57 YES
53 20130720 19:09:57 20130720 19:10:15 YES
54 20130720 19:10:15 20130720 19:10:25 YES
52 rows selected.
10.开启备库到READ ONLY状态验证之前在Snapshot Standby数据库上的操作已撤销
sys@ora11gdg> alter database recover managed standby database cancel;
Database altered.
sys@ora11gdg> alter database open read only;
Database altered.
sys@ora11gdg> select database_role,open_mode from v$database;
DATABASE_ROLE OPEN_MODE
---------------- --------------------
PHYSICAL STANDBY READ ONLY
sys@ora11gdg> select username from dba_users where username = 'OCMU';
no rows selected
之前创建的测试用户OCMU不存在。结论得证。
本文出自 “无双城” 博客，请务必保留此出处http://929044991.blog.51cto.com/1758347/1255180
如果备库正处于Redo Apply过程，需要先取消。
sys@ora11gdg> alter database recover managed standby database cancel;
Database altered.
2.查看当前备库状态确保备库处于MOUNTED状态
sys@ora11gdg> select database_role,open_mode from v$database;
DATABASE_ROLE OPEN_MODE
---------------- --------------------
PHYSICAL STANDBY MOUNTED
此时备库是物理备库角色，运行模式是MOUNTED。
3.确保闪回恢复区已指定
友情提示：实现Snapshot Standby数据库功能并不需要开启主库和备库的闪回数据库（Flashback Database）功能，与是否开启闪回数据库无关。
sys@ora11gdg> show parameter db_recovery_file_dest
NAME TYPE VALUE
--------------------------- ------------ ------------------------------------
db_recovery_file_dest string /u01/app/oracle/flash_recovery_area
db_recovery_file_dest_size big integer 3852M
确认主库闪回功能并未开启
sys@ora11g> select FLASHBACK_ON from v$database;
FLASHBACK_ON
------------------
NO
确认备库闪回功能并未开启
sys@ora11gdg> select FLASHBACK_ON from v$database;
FLASHBACK_ON
------------------
NO
4.调整备库到Snapshot Standby数据库状态
只需要执行一条非常简单的SQL命令便可以将备库调整到Snapshot Standby数据库。
sys@ora11gdg> alter database convert to snapshot standby;
Database altered.
sys@ora11gdg> select database_role,open_mode from v$database;
DATABASE_ROLE OPEN_MODE
---------------- --------------------
SNAPSHOT STANDBY MOUNTED
5.将备库置于对外可读写状态
sys@ora11gdg> alter database open;
Database altered.
sys@ora11gdg> select database_role,open_mode from v$database;
DATABASE_ROLE OPEN_MODE
---------------- --------------------
SNAPSHOT STANDBY READ WRITE
一套全新的可读写数据库展现在我们面前。
6.分析切换过程中的日志信息
ora11g主库alert日志：
Mon July 19 18:46:28 2013
LNS: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (3135)
LNS: Destination LOG_ARCHIVE_DEST_2 network reconnect abandoned
Errors in file /u01/app/oracle/diag/rdbms/ora11g/ora11g/trace/ora11g_nsa2_27302.trc:
ORA-03135: connection lost contact
Error 3135 for archive log file 2 to 'ora11gdg'
Errors in file /u01/app/oracle/diag/rdbms/ora11g/ora11g/trace/ora11g_nsa2_27302.trc:
ORA-03135: connection lost contact
LNS: Failed to archive log 2 thread 1 sequence 50 (3135)
Errors in file /u01/app/oracle/diag/rdbms/ora11g/ora11g/trace/ora11g_nsa2_27302.trc:
ORA-03135: connection lost contact
ora11gdg备库alert日志：
Mon July 19 18:46:26 2013
alter database convert to snapshot standby
Starting background process RVWR
Mon July 19 18:46:26 2013
RVWR started with pid=26, OS id=8824
Allocated 3981204 bytes in shared pool for flashback generation buffer
Created guaranteed restore point SNAPSHOT_STANDBY_REQUIRED_03/19/2013 18:46:26
krsv_proc_kill: Killing 3 processes (all RFS)
Begin: Standby Redo Logfile archival
End: Standby Redo Logfile archival
RESETLOGS after complete recovery through change 1472476
Resetting resetlogs activation ID 4174194338 (0xf8cd26a2)
Online log /u01/app/oracle/oradata/ora11gdg/redo01.log: Thread 1 Group 1 was previously cleared
Online log /u01/app/oracle/oradata/ora11gdg/redo02.log: Thread 1 Group 2 was previously cleared
Online log /u01/app/oracle/oradata/ora11gdg/redo03.log: Thread 1 Group 3 was previously cleared
Standby became priJulyy SCN: 1472474
Mon July 19 18:46:29 2013
Setting recovery target incarnation to 5
CONVERT TO SNAPSHOT STANDBY: Complete - Database mounted as snapshot standby
Completed: alter database convert to snapshot standby
关键的一行提示信息“Created guaranteed restore point SNAPSHOT_STANDBY_REQUIRED_03/19/2013 18:46:26”，这里给出了我们转换成snapshot的时刻，便于后面的回切。
7.测试备库处于Snapshot Standby数据库对主库日志的接收
当主库切换日志时，备库依然可以接收到日志，只是并不应用
1）主库切换日志
sys@ora11g> alter system switch logfile;
System altered.
2）主库记录的alert日志内容
ora11g主库alert日志：
Mon July 19 18:52:00 2013
Thread 1 cannot allocate new log, sequence 52
Private strand flush not complete
Current log# 3 seq# 51 mem# 0: /u01/app/oracle/oradata/ora11g/redo03.log
Mon July 19 18:52:00 2013
ARC3: Standby redo logfile selected for thread 1 sequence 50 for destination LOG_ARCHIVE_DEST_2
Thread 1 advanced to log sequence 52 (LGWR switch)
Current log# 1 seq# 52 mem# 0: /u01/app/oracle/oradata/ora11g/redo01.log
Mon July 19 18:52:03 2013
Archived Log entry 91 added for thread 1 sequence 51 ID 0xf8cd26a2 dest 1:
Mon July 19 18:52:03 2013
LNS: Standby redo logfile selected for thread 1 sequence 51 for destination LOG_ARCHIVE_DEST_2
LNS: Standby redo logfile selected for thread 1 sequence 52 for destination LOG_ARCHIVE_DEST_2
ora11gdg备库alert日志：
Mon July 19 18:52:00 2013
RFS[5]: Assigned to RFS process 9174
RFS[5]: Identified database type as 'snapshot standby': Client is ARCH pid 27296
Mon July 19 18:52:00 2013
RFS[6]: Assigned to RFS process 9176
RFS[6]: Identified database type as 'snapshot standby': Client is ARCH pid 27300
RFS[6]: Selected log 4 for thread 1 sequence 50 dbid -120744030 branch 778023141
Mon July 19 18:52:00 2013
Archived Log entry 47 added for thread 1 sequence 50 ID 0xf8cd26a2 dest 1:
Mon July 19 18:52:03 2013
RFS[7]: Assigned to RFS process 9180
RFS[7]: Identified database type as 'snapshot standby': Client is LGWR ASYNC pid 27302
RFS[7]: Selected log 4 for thread 1 sequence 51 dbid -120744030 branch 778023141
Mon July 19 18:52:04 2013
Archived Log entry 48 added for thread 1 sequence 51 ID 0xf8cd26a2 dest 1:
RFS[7]: Selected log 4 for thread 1 sequence 52 dbid -120744030 branch 778023141
3）查看主库和备库归档目录下的日志文件内容
（1）主库归档日志文件
ora11g@secdb /home/oracle/arch/ora11g$ ls -ltr
total 879M
……省略其他……
-rw-r----- 1 oracle oinstall 1.1M July 19 18:51 1_50_778023141.arc
-rw-r----- 1 oracle oinstall 363K July 19 18:52 1_51_778023141.arc
（2）备库归档日志文件
ora11g@secdb /home/oracle/arch/ora11gdg$ ls -ltr
total 847M
……省略其他……
-rw-r----- 1 oracle oinstall 1.1M July 19 18:52 1_50_778023141.arc
-rw-r----- 1 oracle oinstall 363K July 19 18:52 1_51_778023141.arc
可见，备库已经接受到主库发过来的日志。
8.在Snapshot Standby数据创建用户和表并初始化数据
sys@ora11gdg> create user ocmu identified by ocmu;
User created.
secooler@ora11gdg> grant dba to ocmu;
Grant succeeded.
secooler@ora11gdg> conn ocmu/ocmu
Connected.
ocmu@ora11gdg> create table t (x varchar2(8));
Table created.
ocmu@ora11gdg> insert into t values ('Secooler');
1 row created.
ocmu@ora11gdg> commit;
Commit complete.
ocmu@ora11gdg> select * from t;
X
--------
Secooler
结论，此时备库是一个可任意修改和调整的状态，也就是我们要的“READ WRITE”可读写状态。
特别注意的是，原理上实现Snapshot Standby数据库功能是基于闪回数据原理的，因此任何导致闪回数据库无法回退的动作在这里也要规避，否则Snapshot Standby数据库将无法回到曾经的备库恢复状态。
9.恢复Snapshot Standby数据库为Physical Standby数据库
1）重启备库到MOUNTED状态
ocmu@ora11gdg> conn / as sysdba
Connected.
sys@ora11gdg> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
sys@ora11gdg> startup mount
ORACLE instance started.
Total System Global Area 313860096 bytes
Fixed Size 1336232 bytes
Variable Size 268438616 bytes
Database Buffers 37748736 bytes
Redo Buffers 6336512 bytes
Database mounted.
sys@ora11gdg> select database_role,open_mode from v$database;
DATABASE_ROLE OPEN_MODE
---------------- --------------------
SNAPSHOT STANDBY MOUNTED
2）一条命令恢复原物理备库身份
sys@ora11gdg> alter database convert to physical standby;
Database altered.
3）备库的alert日志清楚的记录了这个切换的过程
Mon July 19 19:30:24 2013
alter database convert to physical standby
ALTER DATABASE CONVERT TO PHYSICAL STANDBY (ora11gdg)
Flashback Restore Start
Flashback Restore Complete
Stopping background process RVWR
Deleted Oracle managed file /u01/app/oracle/flash_recovery_area/ORA11GDG/flashback/o1_mf_7pg3n2jc_.flb
Deleted Oracle managed file /u01/app/oracle/flash_recovery_area/ORA11GDG/flashback/o1_mf_7pg52yst_.flb
Guaranteed restore point dropped
Clearing standby activation ID 4174523254 (0xf8d22b76)
The priJulyy database controlfile was created using the
'MAXLOGFILES 30' clause.
There is space for u
c6f7
p to 27 standby redo logfiles
Use the following SQL commands on the standby database to create
standby redo logfiles that match the priJulyy database:
ALTER DATABASE ADD STANDBY LOGFILE 'srl1.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl2.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl3.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl4.f' SIZE 52428800;
Completed: alter database convert to physical standby
从alert日志中可以得到恢复方法使用的闪回数据库功能实现的，也就是说，即便备库没有运行在闪回数据库状态，依然可以使用闪回数据库功能完成备库的角色转换。
4）重启备库到自动恢复日志状态
（1）此时数据库处于NOMOUNTED状态，需要重新启动数据库。
注意这里是重启数据库，而不是使用alter命令调整，否则会收到如下报错：
sys@ora11gdg> alter database mount;
alter database mount
*
ERROR at line 1:
ORA-00750: database has been previously mounted and dismounted
sys@ora11gdg> shutdown immediate;
ORA-01507: database not mounted
ORACLE instance shut down.
sys@ora11gdg> startup mount;
ORACLE instance started.
Total System Global Area 313860096 bytes
Fixed Size 1336232 bytes
Variable Size 268438616 bytes
Database Buffers 37748736 bytes
Redo Buffers 6336512 bytes
Database mounted.
sys@ora11gdg> alter database recover managed standby database disconnect;
Database altered.
（2）查看备库alert日志，可以清楚的看到恢复的过程。
Mon July 19 19:43:48 2013
Managed Standby Recovery not using Real Time Apply
Parallel Media Recovery started with 4 slaves
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Clearing online redo logfile 1 /u01/app/oracle/oradata/ora11gdg/redo01.log
Clearing online log 1 of thread 1 sequence number 1
Completed: alter database recover managed standby database disconnect
Clearing online redo logfile 1 complete
Clearing online redo logfile 2 /u01/app/oracle/oradata/ora11gdg/redo02.log
Clearing online log 2 of thread 1 sequence number 2
Clearing online redo logfile 2 complete
Media Recovery Log /home/oracle/arch/ora11gdg/1_49_778023141.arc
Media Recovery Log /home/oracle/arch/ora11gdg/1_50_778023141.arc
Media Recovery Log /home/oracle/arch/ora11gdg/1_51_778023141.arc
Media Recovery Log /home/oracle/arch/ora11gdg/1_52_778023141.arc
Media Recovery Log /home/oracle/arch/ora11gdg/1_53_778023141.arc
Media Recovery Log /home/oracle/arch/ora11gdg/1_54_778023141.arc
Media Recovery Waiting for thread 1 sequence 55
（3）查看V$ARCHIVED_LOG动态性能视图查看日志应用情况
sys@ora11gdg> select sequence#, first_time, next_time, applied from v$archived_log order by sequence#;
SEQUENCE# FIRST_TIME NEXT_TIME APPLIED
---------- ----------------- ----------------- ---------
……省略其他数据……
49 20130720 18:32:32 20130720 18:38:03 YES
50 20130720 18:38:03 20130720 18:51:00 YES
51 20130720 18:51:00 20130720 18:52:03 YES
52 20130720 18:52:03 20130720 19:09:57 YES
53 20130720 19:09:57 20130720 19:10:15 YES
54 20130720 19:10:15 20130720 19:10:25 YES
52 rows selected.
10.开启备库到READ ONLY状态验证之前在Snapshot Standby数据库上的操作已撤销
sys@ora11gdg> alter database recover managed standby database cancel;
Database altered.
sys@ora11gdg> alter database open read only;
Database altered.
sys@ora11gdg> select database_role,open_mode from v$database;
DATABASE_ROLE OPEN_MODE
---------------- --------------------
PHYSICAL STANDBY READ ONLY
sys@ora11gdg> select username from dba_users where username = 'OCMU';
no rows selected
之前创建的测试用户OCMU不存在。结论得证。
本文出自 “无双城” 博客，请务必保留此出处http://929044991.blog.51cto.com/1758347/1255180
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- 备用数据库快照
- 人脸识别数据库,转过来的,备用
- SQL Server 创建数据库快照
- 解析SQL Server中数据库快照的工作原理[转]
- 数据库快照 (SQL Server)
- 如何在同一个服务器上克隆出一个备用数据库
- MariaDB数据库介绍之一、备份（mysqldump、lvm2快照、xtrabackup）
- SQL Server 2005 数据库快照（database Snapshot)
- 18.2.2 在不同主机上使用用户管理备份建立物理备用数据库
- 利用oracle快照dblink解决数据库表同步问题
- 19.1 逻辑备用数据库综述
- 两相同方案数据库同步策略(快照)!
- 数据库快照 database snapshot
- (转载)SQL Server 2005 数据库快照（database Snapshot)
- 利用oracle快照dblink解决数据库表同步问题
- 数据库快照的工作方式
- 使用SQL Server发布数据库快照遇到错误：对路径“xxxxx”访问被拒绝的解决方法
- 数据库快照
- SQL基础之数据库快照
- [整理]数据库镜像与数据库快照