不管物理standby还是逻辑standby，其初始创建都是要依赖primary数据库，因为这个准备工作中最重要的一部分，就是对primary数据库的配置。
将primary数据库置为FORCE LOGGING模式。通过下列语句：
SQL> alter database force logging;
提示：关于FORCE LOGGING
想必大家知道有一些DDL语句可以通过指定NOLOGGING子句的方式避免写redo log(目的是提高速度，某些时候确实有效)，指定数据库为FORCE LOGGING模式后，数据库将会记录除临时表空间或临时回滚段外所有的操作而忽略类似NOLOGGING之类的指定参数。如果在执行force logging时有nologging之类的语句在执行，则force logging会等待直到这类语句全部执行。FORCE LOGGING是做为固定参数保存在控制文件中，因此其不受重启之类操作的影响(只执行一次即可)，如果想取消，可以通过alter database no force logging语句关闭强制记录。
2、创建密码文件(如果不存在的话)
需要注意的是，同一个Data Guard配置中所有数据库必须都拥有独立的密码文件，并且必须保证同一个Data Guard配置中所有数据库服务器的SYS用户拥有相同密码以保证redo数据的顺利传输，因为redo传输服务通过认证的网络会话来传输redo数据，而会话使用包含在密码文件中的SYS用户密码来认证。
3、配置Standby Redo Log
对于最大保护和最高可用性模式，Standby数据库必须配置standby redo log，并且oracle推荐所有数据库都使用LGWR ASYNC模式传输，当然你现在可能还不知道LGWR ASYNC是什么问题，没关系，你很快就会知道了。
Oracle建议你在创建standby时就考虑standby redolog配置的问题。standby redologs与online redologs非常类似，应该说两者只是服务对象不同，其它参数属性甚至操作的命令格式几乎都一样，你在设计standby redologs的时候完全可以借鉴创建online redologs的思路，比如多个文件组啦，每组多个文件冗余之类的。除些之外呢，oracle提供了一些标准的建议如下：
确保standby redo log的文件大小与primary数据库online redo log文件大小相同。
这个很好理解的吧，就是为了接收和应用方便嘛。
创建适当的日志组
一般而言，standby redo日志文件组数要比primary数据库的online redo日志文件组数至少多一个。推荐standby redo日志组数量基于primary数据库的线程数(这里的线程数可以理解为rac结构中的rac节点数)。
有一个推荐的公式可以做参考：(每线程的日志组数+1)*最大线程数
例如primary数据库有两个线程，每个线程分配两组日志，则standby日志组数建议为6组，使用这个公式可以降低primary数据库实例LGWR进程锁住的可能性。
提示：逻辑standby数据库有可能需要视工作量增加更多的standby redo log文件(或增加归档进程)，因为逻辑standby需要同时写online redo log文件。
Standby redo log的操作方式与online redo log几乎一模一样，只不过在创建或删除时需要多指定一个standby关键字，例如添加：
SQL> alter database add standby logfile group 4 ('e:ora10goradatajsspdgSTANDBYRD01.LOG') size 20M;删除也同样简单：
SQL> alter database drop standby logfile group 4;
另外，从可靠性方面考虑，建议在primary数据库也创建standby redologs，这样一旦发生切换，不会影响primary做为standby的正常运行。
验证standby redo log文件组是否成功创建
例如：
SQL> SELECT GROUP#,THREAD#,SEQUENCE#,ARCHIVED,STATUS FROM V$STANDBY_LOG;
4、设置初始化参数
对于primary数据库，需要定义几个primary角色的初始化参数控制redo传输服务，还有几个附加的standby角色的参数需要添加以控制接收redo数据库并应用(switchover/failover后primary/standby角色可能互换，所以建议对于两类角色相关的初始化参数都进行配置)。
|
下列参数为primary角色相关的初始化参数：
| |
|
DB_NAME
|
注意保持同一个Data Guard中所有数据库DB_NAME相同。
例如：DB_NAME=jssweb
|
|
DB_UNIQUE_NAME
|
为每一个数据库指定一个唯一的名称，该参数一经指定不会再发生变化，除非你主动修改它。
例如：DB_UNIQUE_NAME=jssweb
|
|
LOG_ARCHIVE_CONFIG
|
该参数通过DG_CONFIG属性罗列同一个Data Guard中所有DB_UNIQUE_NAME(含primary db及standby db)，以逗号分隔
例如：LOG_ARCHIVE_CONFIG='DB_CONFIG=(jssweb,jsspdg)'
|
|
CONTROL_FILES
|
没啥说的，控制文件所在路径。
|
|
LOG_ARCHIVE_DEST_n
|
归档文件的生成路径。该参数非常重要，并且属性和子参数也特别多(这里不一一列举，后面用到时单独讲解如果你黑好奇，建议直接查询oracle官方文档。Data guard白皮书第14章专门介绍了该参数各属性及子参数的功能和设置)。例如：
LOG_ARCHIVE_DEST_1=
'LOCATION=E:ora10goradatajssweb VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=jssweb'
|
|
LOG_ARCHIVE_DEST_STATE_n
|
指定参数值为ENABLE，允许redo传输服务传输redo数据到指定的路径。该参数共拥有4个属性值，功能各不相同。
|
|
REMOTE_LOGIN_PASSWORDFILE
|
推荐设置参数值为EXCLUSIVE或者SHARED，注意保证相同Data Guard配置中所有db服务器sys密码相同。
|
|
LOG_ARCHIVE_FORMAT
|
指定归档文件格式。
|
|
LOG_ARCHIVE_MAX_PRODUCESSES
|
指定归档进程的数量(1-30)，默认值通常是4。
|
|
以下参数为standby角色相关的参数，建议在Primary数据库的初始化参数中也进行设置，这样在role transition后(Primary转为Standby)也能正常运行：
| |
|
FAL_SERVER
|
指定一个数据库SID，通常该库为primary角色。
例如：FAL_SERVER=jssweb
|
|
FAL_CLIENT
|
指定一个数据库SID，通常该库为standby角色。
例如：FAL_CLIENT=jsspdg
提示：FAL是Fetch Archived Log的缩写
|
|
DB_FILE_NAME_CONVERT
|
在做duplicate复制和传输表空间的时候这类参数讲过很多遍，该参数及上述内容中同名参数功能，格式等完全相同。
|
|
LOG_FILE_NAME_CONVERT
|
同上
|
|
STANDBY_FILE_MANAGEMENT
|
如果primary数据库数据文件发生修改（如新建，重命名等）则按照本参数的设置在standby中做相应修改。设为AUTO表示自动管理。设为MANUAL表示需要手工管理。
例如：STANDBY_FILE_MANAGEMENT=AUTO
|
注意：上面列举的这些参数仅只是对于primary/standby两角色可能会相关的参数，还有一些基础性参数比如*_dest,*_size等数据库相关的参数在具体配置时也需要根据实际情况做出适当修改。
5、确保数据库处于归档模式
SQL> archive log list;
数据库日志模式 存档模式
自动存档 启用
.......
如果当前primary数据库并未处于归档模式，可通过下列命令将数据库置为归档模式：
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE ARCHIVELOG;
SQL> ALTER DATABASE OPEN;
二、手把手的创建物理standby
1、创建备份(手工复制数据文件或通过RMAN) ---primary库操作
2、创建控制文件 --primary库操作
通过下列语句为standby数据库创建控制文件
SQL> alter database create standby controlfile as 'd:backupjsspdg01.ctl';
注意哟，控制文件通常需要有多份，你要么手工将上述文件复制几份，要么用命令多创建几个出来。另外，创建完控制文件之后到standby数据库创建完成这段时间内，要保证primary数据库不再有结构性的变化(比如增加表空间等等)，不然primary和standby同步时会有问题。
3、创建初始化参数文件
创建客户端初始化参数文件
例如：
SQL> create pfile='d:backupinitjsspdg.ora' from spfile;
修改初始化参数文件中的参数
根据实际情况修改吧，注意primary和standby不同角色的属性配置，注意文件路径。
4、复制文件到standby服务器
至少三部分：数据文件，控制文件，修改过的初始化参数文件，注意路径。
5、配置standby数据库
如果你看过三思之前"一步一步学rman"系列，看过"duplicate复制数据库"，或看过"传输表空间复制数据"系列，那么对于创建一个新的数据库应该非常熟悉了，下面再简单描述一下步骤：
1).创建新的OracleService(windows环境下需要)。
2).创建密码文件，注意保持密码与primary数据库一致。
3).配置监听并启动
4).修改primary和standby的tnsnames.ora，各自增加对应的Net Service Name。
5).创建服务器端的初始化文件
6、启动standby
注意哟，咱们前面说过的，物理standby极少情况下可以以read-write模式打开，某些情况下可以以read-only模式打开，所以默认情况下，加载到mount状态即可。
SQL> STARTUP MOUNT;
启动redo应用
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
启动实时应用
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
提示：disconnect from session子句并非必须，该子句用于指定启动完应用后自动退出到命令操作符前，如果不指定的话，当前session就会一直停留处理redo应用，如果想做其它操作，就只能新建一个连接。
7、停止standby
正常情况下，我们停止也应该是先停止redo应用，可以通过下列语句：
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CALCEL;
然后再停止standby数据库
SQL> SHUTDOWN IMMEDIATE;
当然你非要直接shutdown也没问题，dg本来就是用于容灾的，别说你生停standby，就是直接拔电源也不怕。
物理standby创建示例
为了最大的降低硬件需求，此处创建的data guard处于同一台机器，但其创建过程与多机并无区别。做为演示用的示例足够了，我们分两阶段配置，分别是配置primary数据库和配置standby数据库，如下：
一、Primary数据库配置及相关操作
1、确认主库处于归档模式
SQL> archive log list;
数据库日志模式 存档模式
自动存档 启用
存档终点 E:ora10goradatajssweb
最早的联机日志序列 148
下一个存档日志序列 150
当前日志序列 150
SQL>
2、将primary数据库置为FORCE LOGGING模式。通过下列语句：
SQL> alter database force logging;
数据库已更改。
3、创建standby数据库控制文件
SQL> alter database create standby controlfile as 'd:backupjsspdg01.ctl';
数据库已更改。
4、创建primary数据库客户端初始化参数文件
注：主要此处修改项较多，为了方便，我们首先创建并修改pfile，然后再通过pfile重建spfile，你当然也可以通过alter system set命令直接修改spfile内容。
SQL> create pfile from spfile;
文件已创建。
将该初始化参数文件复制一份，做为standby数据库的客户端初始化参数文件
SQL> host copy e:ora10gproduct10.2.0db_1databaseinitjssweb.ora d:backupinitjsspdg.ora
已复制 1 个文件。
SQL>
修改客户端初始化参数文件，增加下列内容
| DB_UNIQUE_NAME=jssweb LOG_ARCHIVE_CONFIG='DG_CONFIG=(jssweb,jsspdg)' LOG_ARCHIVE_DEST_1='LOCATION=E:ora10goradatajssweb VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=jssweb' LOG_ARCHIVE_DEST_2='SERVICE=jsspdg LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=jsspdg' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_STATE_2=ENABLE REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE #--------配置standby角色的参数用于角色转换 FAL_SERVER=jsspdg FAL_CLIENT=jssweb DB_FILE_NAME_CONVERT='oradatajsspdg','oradatajssweb' LOG_FILE_NAME_CONVERT='oradatajsspdg','oradatajssweb' STANDBY_FILE_MANAGEMENT=AUTO |
通过pfile重建spfile
| SQL> shutdown immediate ... SQL> create spfile from pfile='initjssweb.ora'; |
文件已创建。
5、复制数据文件到standby服务器(方式多样，不详述)
注意需要复制所有数据文件，备份的控制文件及客户端初始化参数文件
6、配置listener及net service names(方式多样，不详述)。
完之后重启listener:
E:ora10g>lsnrctl stop
E:ora10g>lsnrctl start
通过tnsping测试tnsnames是否正确有效：
| E:ora10g>tnsping jssweb ... Attempting to contact (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = jss)(PORT = 1521)) (CONNECT_ DATA = (SERVER = DEDICATED) (SERVICE_NAME = jssweb))) OK (30 毫秒) E:ora10g>tnsping jsspdg ... Attempting to contact (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = jss)(PORT = 1521)) (CONNECT_ DATA = (SERVER = DEDICATED) (SERVICE_NAME = jsspdg))) OK (10 毫秒) |
二、Standby数据库配置及相关操作
1、通过ORADIM创建新的OracleService
2、创建密码文件，注意保护sys密码与primary数据库一致。
E:ora10g>orapwd file=e:ora10gproduct10.2.0db_1databasePWDjsspdg
.ora password=verysafe entries=30
3、创建目录
E:ora10gproduct10.2.0adminjsspdg>mkdir adump
4、复制文件，不做过多描述
5、修改初始化参数文件
增加下列参数
| db_unique_name=jsspdg LOG_ARCHIVE_CONFIG='DG_CONFIG=(jssweb,jsspdg)' DB_FILE_NAME_CONVERT='oradatajssweb','oradatajsspdg' LOG_FILE_NAME_CONVERT='oradatajssweb','oradatajsspdg' LOG_ARCHIVE_FORMAT=log%t_%s_%r.arc LOG_ARCHIVE_DEST_1='LOCATION=E:ora10goradatajsspdg VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=jsspdg' LOG_ARCHIVE_DEST_STATE_1=ENABLE #---下列参数用于角色切换 LOG_ARCHIVE_DEST_2='SERVICE=jssweb LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) B_UNIQUE_NAME=jssweb' LOG_ARCHIVE_DEST_STATE_2=ENABLE REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE FAL_SERVER=jssweb FAL_CLIENT=jsspdg STANDBY_FILE_MANAGEMENT=AUTO |
注意同时修改*_dest的路径。
通过该pfile创建spfile
SQL> create spfile from pfile='D:backupinitjsspdg.ora';
文件已创建。
6、启动standby到mount
SQL> startup mount;
ORACLE 例程已经启动。
Total System Global Area 167772160 bytes
Fixed Size 1289484 bytes
Variable Size 62915316 bytes
Database Buffers 96468992 bytes
Redo Buffers 7098368 bytes
数据库装载完毕。
7、启动redo应用
SQL> alter database recover managed standby database disconnect from session;
数据库已更改。
8、查看同步情况
首先连接到primary数据库
| SQL> show parameter instance_name; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ instance_name string jssweb SQL> alter system switch logfile; |
系统已更改。
| SQL> select max(sequence#) from v$archived_log; MAX(SEQUENCE#) -------------- 51 |
连接到standby数据库
| SQL> show parameter instance_name; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ instance_name string jsspdg SQL> select max(sequence#) from v$archived_log; MAX(SEQUENCE#) -------------- 51 |
9、暂停应用
通过下列语句暂停redo应用。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
数据库已更改。
注意，此时只是暂时redo应用，并不是停止Standby数据库，standby仍会保持接收只不过不会再应用接收到的归档，直到你再次启动redo应用为止。
哈哈，成功了!现在你是不是想知道怎么把standby变成primary呢?接着往下看~~~~~~~~~
物理standby角色转换
第1节的时候我们就提到了角色切换，我们也听说了其操作简单但用途广泛，同时我们也猜测其属于primary与standby之间的互动，那么在primary和standby数据库(之一)上都需要有操作，并且切换又分了：switchover和failover，前者是无损切换，不会丢失数据，而后者则有可能会丢失数据，并且切换后原primary数据库也不再是该data guard配置的一部分了.针对不同standby(逻辑或物理)的处理方式也不尽相同。en,内容也挺多地。我们还是先大概了解下概念，然后再通过实战去印证。
角色转换前的准备工作
- 检查各数据库的初始化参数，主要确认对不同角色相关的初始化参数都进行了正确的配置。
- 确保可能成为primary数据库的standby服务器已经处于archivelog模式。
- 确保standby数据库的临时文件存在并匹配primary数据库的临时文件
- 确保standby数据库的RAC实例只有一个处于open状态。(对于rac结构的standby数据库，在角色转换时只能有一个实例startup。其它rac实例必须统统shutdown，待角色转换结束后再startup)
Switchover：
无损转换，通常是用户手动触发或者有计划的让其自动触发，比如硬件升级啦，软件升级啦之类的。通常它给你带来的工作量非常小并且都是可预计的。其执行分两个阶段，第一步，primary数据库转换为standby角色，第二步，standby数据库(之一)转换为primary角色，primary和standby只是简单的角色互换，这也印证了我们前面关于角色转换是primary/standby互动的猜测。
Failover：
不可预知原因导致primary数据库故障并且短期内不能恢复就需要failover。如果是这种切换那你就要小心点了，有可能只是虚惊一场，甚至连你可能损失的脑细胞的数量都能预估，但如果运气不好又没有完备的备份恢复策略而且primary数据并非处于最大数据保护或最高可用性模式地话，黑黑，哭是没用地，表太伤心了，来，让三思GG安慰安慰你，这种情况下呢丢失数据有可能是难免的，并且如果其故障未能修复，那它甚至连快速修复成为standby的机会也都失去了呐，咦，你脑门怎么好像在往外冒水，难道是强效净肤液，你的脸也忽然好白皙哟~~~~
在执行failover之前，尽可能将原primary数据库的可用redo都复制到standby数据库。
注意，如果要转换角色的standby处于maximum protection模式，需要你首先将其切换为maximum performance模式(什么什么，你不知道怎么转换模式?oooo,对对，我们还没有操作过，这块并不复杂，接下来会通过专门章节讨论)，这里先提供透露一下，转换standby数据库到MAXIMIZE PERFORMANCE执行下列SQL即可：
SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;
等standby切换为新的primary之后，你可以再随意更改数据库的保护模式。
你是不是有疑问关于为什么待切换角色的standby不能处于maximum protection模式呢?这个其实很好理解，我们在第一节学习三种保护模式的时候就介绍过其各自的特点，脑袋瓜好使的同学应该还有印象，maximum protection模式需要确保绝无数据丢失，因此其对于提交事务对应的redo数据一致性要求非常高，另外，如果处于maximum protection模式的primary数据库仍然与standby数据库有数据传输，此时alter database语句更改standby数据库保护模式会失败，这也是由maximum protection模式特性决定的。
下面分别演示switchover和failover的过程：
一、物理standby的Switchover
注意操作步骤的先后，很关键的哟。
1、检查是否支持switchover操作 --primary数据库操作
登陆primary数据库，查询v$database视图的switchover_status列。
E:ora10g>set oracle_sid=jssweb
E:ora10g>sqlplus "/ as sysdba"
SQL*Plus: Release 10.2.0.3.0 - Production on 星期四 12月 13 09:41:29 2007
Copyright (c) 1982, 2006, Oracle. All Rights Reserved.
已连接。
SQL> select switchover_status from v$database;
SWITCHOVER_STATUS
--------------------
TO STANDBY
如果该列值为"TO STANDBY"则表示primary数据库支持转换为standby角色，否则的话你就需要重新检查一下Data Guard配置，比如看看LOG_ARCHIVE_DEST_n之类参数值是否正确有效等等。
首先将primary转换为standby的角色，通过下列语句：
SQL> alter database commit to switchover to physical standby;
数据库已更改。
语句执行完毕后，primary数据库将会转换为standby数据库，并自动备份控制文件到trace。
3、重启动到mount --原primary数据库操作
SQL> shutdown immediate
ORA-01507: 未装载数据库
ORACLE 例程已经关闭。
SQL> startup mount
ORACLE 例程已经启动。
Total System Global Area 167772160 bytes
Fixed Size 1289484 bytes
Variable Size 104858356 bytes
Database Buffers 54525952 bytes
Redo Buffers 7098368 bytes
数据库装载完毕。
4、检查是否支持switchover操作 --待转换standby数据库操作
待原primary切换为standby角色之后，检查待转换的standby数据库switchover_status列，看看是否支持角色转换。
E:ora10g>set oracle_sid=jsspdg
E:ora10g>sqlplus " / as sysdba"
SQL*Plus: Release 10.2.0.3.0 - Production on 星期四 12月 13 10:08:15 2007
Copyright (c) 1982, 2006, Oracle. All Rights Reserved.
已连接。
SQL> select switchover_status from v$database;
SWITCHOVER_STATUS
--------------------
TO PRIMARY
SQL>
此时待转换standby数据库switchover_status列值应该是"TO_PRIMARY"，如否则检查其初始化参数文件中的设置，提示一下，比着原primary数据库的初始化参数改改。
5、转换角色到primary --待转换standby数据库操作
通过下列语句转换standby到primary角色：
SQL> alter database commit to switchover to primary;
数据库已更改。
注意：待转换的物理standby可以处于mount模式或open read only模式，但不能处于open read write模式。
6、完成转换，打开新的primary数据库
SQL> alter database open;
数据库已更改。
注：如果数据库处于open read-only模式的话，需要先shutdown然后直接startup即可。
7、验证一下
新的primary数据库
SQL> show parameter db_unique
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_unique_name string jsspdg
SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
--------------
67
SQL> alter system switch logfile;
系统已更改。
SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
--------------
68
新的standby数据库
SQL> show parameter db_unique
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_unique_name string jssweb
SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
--------------
68
转换成功。
二、物理standby的failover
注意几点：
• failover之后，原primary数据库默认不再是data guard配置的一部分。
• 多数情况下，其它逻辑/物理standby数据库不直接参与failover的过程，因此这些数据库不需要做任何操作。
• 某些情况下，新的primary数据库配置之后，需要重新创建其它所有的standby数据库。
另外，如果待转换角色的standby处于maximum protection或maximum availability模式的话，归档日志应该是连续存在的，这种情况下你可以直接从第3步执行，否则建议你按照操作步骤从第1步开始执行。
一般情况下failover都是表示primary数据库瘫痪，最起码也是起不来了，因此这种类型的切换基本上不需要primary数据库做什么操作。所以下列步骤中如果有提到primary和standby执行的，只是建议你如果primary还可以用，那就执行一下，即使它能用你却不执行，也没关系，不影响standby数据库的切换:)
1、检查归档文件是否连续
查询待转换standby数据库的V$ARCHIVE_GAP视图，确认归档文件是否连接：
SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
未选定行
如果返回的有记录，按照列出的记录号复制对应的归档文件到待转换的standby服务器。这一步非常重要，必须确保所有已生成的归档文件均已存在于standby服务器，不然可能会数据不一致造成转换时报错。文件复制之后，通过下列命令将其加入数据字典：
SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';
2、检查归档文件是否完整
分别在primary/standby执行下列语句：
SQL> select distinct thread#,max(sequence#) over(partition by thread#) a from v$archived_log;
该语句取得当前数据库各线程已归档文件最大序号，如果primary与standby最大序号不相同，必须将多出的序号对应的归档文件复制到待转换的standby服务器。不过既然是failover，有可能primary数据库此时已经无法打开，甚至无法访问，那你只好听天由命喽，三思在这里替你默念：苍天啊，大地啊，哪路的神仙大姐能来保佑俺们不丢数据呀!
3、启动failover
执行下列语句：
SQL> alter database recover managed standby database finish force;
数据库已更改。
FORCE关键字将会停止当前活动的RFS进程，以便立刻执行failover。
剩下的步骤就与前面switchover很相似了
4、切换物理standby角色为primary
SQL> alter database commit to switchover to primary;
数据库已更改。
5、启动新的primary数据库。
如果当前数据库已mount,直接open即可，如果处于read-only模式，需要首先shutdown immediate，然后再直接startup。
SQL> alter database open;
数据库已更改。
角色转换工作完成。剩下的是补救措施(针对原primary数据库)，由于此时primary数据库已经不再是data guard配置的一部分，我们需要做的就是尝试看看能否恢复原primary数据库，将其改造为新的standby服务器。具体操作方式可以分为二类：1.重建 2.备份恢复。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/786540/viewspace-1003482/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/786540/viewspace-1003482/
1775
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
