超详细的Data Guard之physical standby 搭建

Oracle Data Guard 环境中Standby Database 主要有2种角色，physical standby 和logic standby，这里讲述 physical standby的搭建过程。

Data Guard提供了3种级别的保护模式，无论搭建physical standby还是logic standby，都需要考虑使用什么样的保护模式来保护数据，定义何种保护模式主要就是设置redo的传输方式

（1）最大保护LGWR SYNC

（2）最高可用性LGWR SYNC

（3）最高性能 LGWR ASYNC 或ARCH

具体理论知识见我的blog：

http://5073392.blog.51cto.com/5063392/1297346

Data Gurad 之RMAN备份搭建物理standby：

http://5073392.blog.51cto.com/5063392/1300236

软件环境：

虚拟机：VMware-Workstation-Full-8.0.0-471780

系统： rhel-server-5.4-i386

Oracle：linux_11gR1_database

ip地址：

primary：192.168.31.2

standby：192.168.31.3

实例名

primary：DGWH

standby：DGBJ

一，Data Guard搭建步骤

1.在vmware上安装2台linux虚拟机，按照上面要求设置好IP，然后在2台linux上分别安装oracle软件（linux_11gR2_database),在192.168.31.2创建好数据库实例名为DGWH，先保证实例DGWH能够正常运行，并且两台linux系统可以互相ping通。

2.在主数据库上激活FORCE LOGGING模式，想必大家知道有一些DDL 语句可以通过指定NOLOGGING 子句的方式避免写redo log(目的是提高速度，某些时候确实有效)，指定数据库为FORCE LOGGING 模式后，数据库将会记录除临时表空间或临时回滚段外所有的操作而忽略类似NOLOGGING之类的指定参数。如果在执行force logging 时有nologging 之类的语句在执行，则force logging 会等待直到这类语句全部执行。FORCE LOGGING 是做为固定参数保存在控制文件中，因此其不受重启之类操作的影响(只执行一次即可)，如果想取消，可以通过alter database no force logging 语句关闭强制记录。

SQL> alter database force logging;

Database altered.

3.配置主数据库为归档模式（如果已经归档模式这一步不需要）

SQL> archive log list;

Database log mode No Archive Mode //非归档

Automatic archival Disabled

Archive destination USE_DB_RECOVERY_FILE_DEST

Oldest online log sequence 2

Current log sequence 4

SQL> shutdown immediate;

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL> startup mount;

ORACLE instance started.

Total System Global Area 318046208 bytes

Fixed Size 1299652 bytes

Variable Size 239078204 bytes

Database Buffers 71303168 bytes

Redo Buffers 6365184 bytes

Database mounted.

SQL> alter database archivelog; //激活归档

Database altered.

SQL> alter database open;

Database altered.

4. 为备用数据库创建控制文件，需要重启实例到mount状态执行下列命令

SQL> select status from v$instance;

STATUS

------------

MOUNTED

SQL> alter database create standby controlfile as '/tmp/DGBJ.ctl';

Database altered. //创建standby controlfile

5. 在主数据库生成一个pfile文件，用于配置DG的相关属性（也可以直接通过alter system 语句修改）

SQL> create pfile from spfile;

File created.

6. 关闭数据库

SQL> shutdown immediate;

ORA-01109: database not open

Database dismounted.

ORACLE instance shut down.

7. 到$ORACLE_HOME/dbs下修改pifle文件initDGWH.ora，用vi文本编辑器打开修改后的内容如下

DGWH.__db_cache_size=67108864

DGWH.__java_pool_size=12582912

DGWH.__large_pool_size=4194304

DGWH.__oracle_base='/u01/app/oracle'#ORACLE_BASE set from environment

DGWH.__pga_aggregate_target=130023424

DGWH.__sga_target=188743680

DGWH.__shared_io_pool_size=0

DGWH.__shared_pool_size=100663296

DGWH.__streams_pool_size=0

*.audit_file_dest='/u01/app/oracle/admin/DGWH/adump'

*.audit_trail='db'

*.compatible='11.1.0.0.0'

*.control_files='/u01/app/oracle/oradata/DGWH/controlfile/o1_mf_9361nfg6_.ctl','/u01/app/oracle/flash_recovery_area/DGWH/controlfile/o1_mf_9361nfpk_.ctl'

*.db_block_size=8192

*.db_create_file_dest='/u01/app/oracle/oradata'

*.db_domain=''

*.db_name='DGWH'

*.db_recovery_file_dest='/u01/app/oracle/flash_recovery_area'

*.db_recovery_file_dest_size=2147483648

*.diagnostic_dest='/u01/app/oracle'

*.dispatchers='(PROTOCOL=TCP) (SERVICE=DGWHXDB)'

*.memory_target=316669952

*.open_cursors=300

*.processes=150

*.remote_login_passwordfile='EXCLUSIVE'

*.undo_tablespace='UNDOTBS1'

DB_UNIQUE_NAME=DGWH

LOG_ARCHIVE_CONFIG='DG_CONFIG=(DGWH,DGBJ)'

LOG_ARCHIVE_DEST_1='LOCATION=/u01/arch1/DGWH VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=DGWH'

LOG_ARCHIVE_DEST_2='SERVICE=DGBJ ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=DGBJ'

LOG_ARCHIVE_FORMAT=log%t_%s_%r.arc

LOG_ARCHIVE_DEST_STATE_1=ENABLE

LOG_ARCHIVE_DEST_STATE_2=ENABLE

FAL_SERVER=DGBJ

DB_FILE_NAME_CONVERT='DGWH','DGBJ'

LOG_FILE_NAME_CONVERT='/u01/arch1/DGWH','/u01/arch1/DGBJ'

STANDBY_FILE_MANAGEMENT=AUTO

8.由于我把归档日志的路径改到/u01/arch1/DGWH，因此需要创建这个目录

[oracle@localhost dbs]$ mkdir -p /u01/arch1/DGWH

[oracle@localhost dbs]$ ls -ld /u01/arch1/DGWH

drwxr-xr-x 2 oracle oinstall 4096 Sep 13 21:41 /u01/arch1/DGWH

9.为备用数据库配置参数文件，复制前面修改的initDGWH.ora为initDGBJ.ora

[oracle@localhost dbs]$ cp -a initDGWH.ora initDGBJ.ora

修改后的内容如下

DGBJ.__db_cache_size=67108864

DGBJ.__java_pool_size=12582912

DGBJ.__large_pool_size=4194304

DGBJ.__oracle_base='/u01/app/oracle'#ORACLE_BASE set from environment

DGBJ.__pga_aggregate_target=130023424

DGBJ.__sga_target=188743680

DGBJ.__shared_io_pool_size=0

DGBJ.__shared_pool_size=100663296

DGBJ.__streams_pool_size=0

*.audit_file_dest='/u01/app/oracle/admin/DGBJ/adump'

*.audit_trail='db'

*.compatible='11.1.0.0.0'

*.control_files='/u01/app/oracle/oradata/DGBJ/DGBJ01.ctl','/u01/app/oracle/flash_recovery_area/DGBJ/controlfile/DGBJ02.ctl' //注意这里standby用了2个控制文件，需要手工复制两份即可

*.db_block_size=8192

*.db_create_file_dest='/u01/app/oracle/oradata'

*.db_domain=''

*.db_name='DGWH'

*.db_recovery_file_dest='/u01/app/oracle/flash_recovery_area'

*.db_recovery_file_dest_size=2147483648

*.diagnostic_dest='/u01/app/oracle'

*.dispatchers='(PROTOCOL=TCP) (SERVICE=DGWHXDB)'

*.memory_target=316669952

*.open_cursors=300

*.processes=150

*.remote_login_passwordfile='EXCLUSIVE'

*.undo_tablespace='UNDOTBS1'

DB_UNIQUE_NAME=DGBJ

LOG_ARCHIVE_CONFIG='DG_CONFIG=(DGBJ,DGWH)'

LOG_ARCHIVE_DEST_1='LOCATION=/u01/arch1/DGBJ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=DGBJ'

LOG_ARCHIVE_DEST_2='SERVICE=DGWH ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=DGWH'

LOG_ARCHIVE_FORMAT=log%t_%s_%r.arc

LOG_ARCHIVE_DEST_STATE_1=ENABLE

LOG_ARCHIVE_DEST_STATE_2=ENABLE

FAL_SERVER=DGWH

DB_FILE_NAME_CONVERT='DGWH','DGBJ'

LOG_FILE_NAME_CONVERT='/u01/arch1/DGWH','/u01/arch1/DGBJ'

STANDBY_FILE_MANAGEMENT=AUTO

10. 将参数文件密码文件，standby controlfile，所有的数据库文件复制到备用数据库

（1）复制密码文件（将DGWH的密码文件复制一份重命名为orapwDGBJ，这一步非常重要，而且必须保证密码文件一致，不然可能导致主库通过LNSn进程发送redo失败）和参数文件

[oracle@localhost dbs]$ scp orapwDGBJ initDGBJ.ora 192.168.31.3:/u01/app/oracle/product/11.1.0/db_1/dbs

[email protected]'s password:

orapwDGBJ 100% 1536 1.5KB/s 00:00

initDGBJ.ora 100% 1491 1.5KB/s 00:00

（2）复制standby controlfile

[oracle@localhost dbs]$ scp /tmp/DGBJ.ctl 192.168.31.3:/tmp

[email protected]'s password:

DGBJ.ctl 100% 9520KB 9.3MB/s 00:01

（3）复制所有的数据库文件

[oracle@localhost dbs] cd /u01/app/oracle/oradata/DGWH/datafile

[oracle@localhost datafile]$ cd /u01/app/oracle/oradata/DGWH/datafile

[oracle@localhost datafile]$ scp * 192.168.31.3:/tmp

[email protected]'s password:

o1_mf_sysaux_9361jnkx_.dbf 100% 560MB 6.7MB/s 01:24

o1_mf_system_9361jnkf_.dbf 100% 690MB 7.3MB/s 01:35

o1_mf_temp_9361onbf_.tmp 100% 28MB 5.6MB/s 00:05

o1_mf_undotbs1_9361jnol_.dbf 100% 60MB 5.0MB/s 00:12

o1_mf_users_9361jnpq_.dbf 100% 5128KB 5.0MB/s 00:00

11. 前面的说有操作都是在主库上的操作，下面的操作在备库上执行

（1）首先创建参数文件initDGBJ里面定义的相关目录

[oracle@localhost ~]$ mkdir -p /u01/app/oracle/admin/DGBJ/adump

[oracle@localhost ~]$ mkdir -p /u01/app/oracle/oradata/DGBJ/controlfile

[oracle@localhost ~]$ mkdir -p /u01/app/oracle/oradata/DGBJ/datafile

[oracle@localhost ~]$ mkdir -p /u01/app/oracle/flash_recovery_area/DGBJ/controlfile

drwxr-xr-x 2 oracle oinstall 4096 Sep 7 21:56 /u01/app/oracle/flash_recovery_area/DGBJ/controlfile

（2）将前面通过scp传输到/tmp下的相关文件（数据库文件，standby控制文件，密码文件和参数文件已经通过scp复制到了$ORACLE_HOME/dbs）复制到对应的目录

[oracle@localhost ~]$ mv /tmp/o1_mf_* /u01/app/oracle/oradata/DGBJ/datafile

[oracle@localhost ~]$ cp -a /tmp/DGBJ.ctl /u01/app/oracle/oradata/DGBJ/controlfile/DGBJ01.ctl

[oracle@localhost ~]$ cp -a /tmp/DGBJ.ctl /u01/app/oracle/flash_recovery_area/DGBJ/controlfile/DGBJ02.ctl

（3）启动数据库到mount状态

[oracle@localhost ~]$ export ORACLE_SID=DGBJ

[oracle@localhost ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.1.0.6.0 - Production on Sat Sep 7 22:04:54 2013

Copyright (c) 1982, 2007, Oracle. All rights reserved.

Connected to an idle instance.

SQL> startup mount;

ORACLE instance started.

Total System Global Area 318046208 bytes

Fixed Size 1299652 bytes

Variable Size 243272508 bytes

Database Buffers 67108864 bytes

Redo Buffers 6365184 bytes

Database mounted.

如果无法启动到mount状态，检查控制文件路径是否正确，主备库的db_name是否一致，这里为DGWH，可以查看警告日志文件排查错误。

12. 在主库和备库上配置监听.两边的tnsname.ora和listener.ora一致

（1）listener.ora文件内容如下

# listener.ora Network Configuration File: /u01/app/oracle/product/11.1.0/db_1/network/admin/listener.ora

# Generated by Oracle configuration tools.

LISTENER =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = localhost.localdomain)(PORT = 1521))

)

（2）tnsname.ora文件内容如下

[oracle@localhost admin]$ cat tnsnames.ora

# tnsnames.ora Network Configuration File: /u01/app/oracle/product/11.1.0/db_1/network/admin/tnsnames.ora

# Generated by Oracle configuration tools.

DGBJ =

(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.31.3)(PORT = 1521))

)

(CONNECT_DATA =

(SERVER = DEDICATED)

(SERVICE_NAME = DGBJ)

)

)

DGWH =

(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.31.2)(PORT = 1521))

)

(CONNECT_DATA =

(SERVER = DEDICATED)

(SERVICE_NAME = DGWH)

)

)

13.通过pfile将主数据库启动open状态

SQL> startup pfile=$ORACLE_HOME/dbs/initDGWH.ora

ORACLE instance started.

Total System Global Area 318046208 bytes

Fixed Size 1299652 bytes

Variable Size 243272508 bytes

Database Buffers 67108864 bytes

Redo Buffers 6365184 bytes

Database mounted.

Database opened.

14.到这DG搭建基本完成，验证数据库同步没有问题后，再通过spfile启动DG数据库

（1）在主数据库上验证能否登陆到备库

[oracle@localhost ~]$ sqlplus system/oracle@DGBJ

SQL*Plus: Release 11.1.0.6.0 - Production on Fri Sep 13 23:31:23 2013

Copyright (c) 1982, 2007, Oracle. All rights reserved.

Connected to:

Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL>

（2）在备用数据库验证能否登陆主库

[oracle@localhost ~]$ sqlplus system/oracle@DGWH

SQL*Plus: Release 11.1.0.6.0 - Production on Fri Sep 13 23:32:21 2013

Copyright (c) 1982, 2007, Oracle. All rights reserved.

Connected to:

Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL>

（3）检查归档日志是否同步

主库：

SQL> select NAME,THREAD#,SEQUENCE# from v$archived_log;

NAME THREAD# SEQUENCE#

-------------------------------------------------- ---------- ----------

/u01/arch1/DGWH/log1_4_826058126.arc 1 4

DGBJ 1 4

备库：

SQL> select NAME,THREAD#,SEQUENCE# from v$archived_log;

NAME THREAD# SEQUENCE#

-------------------------------------------------- ---------- ----------

/u01/arch1/DGBJ/log1_4_826058126.arc 1 4

这里归档日志一致

在主库上创建一个表test，并且手动切换日志，检查归档日志是否可以正常传送到备库

SQL> create table test (id int);

Table created.

SQL> insert into test values (1);

1 row created.

SQL> commit;

Commit complete.

SQL> alter system switch logfile;

System altered.

在备库上重新执行下面命令验证

SQL> select NAME,THREAD#,SEQUENCE# from v$archived_log;

NAME THREAD# SEQUENCE#

-------------------------------------------------- ---------- ----------

/u01/arch1/DGBJ/log1_4_826058126.arc 1 4

/u01/arch1/DGBJ/log1_5_826058126.arc 1 5

通过下面的语句可以查询归档日志是否已经应用，,APPLIED的状态为NO代表还没有应用。

SQL> select NAME,THREAD#,SEQUENCE#,APPLIED from v$archived_log;

NAME THREAD# SEQUENCE# APP

-------------------------------------------------- ---------- ---------- ---

/u01/arch1/DGBJ/log1_4_826058126.arc 1 4 NO

/u01/arch1/DGBJ/log1_5_826058126.arc 1 5 NO

（4）应用日志，

SQL> alter database recover managed standby database disconnect from session;

Database altered.

在查询v$archived_log查询日志应用状况

SQL> select NAME,THREAD#,SEQUENCE#,APPLIED from v$archived_log;

NAME THREAD# SEQUENCE# APP

-------------------------------------------------- ---------- ---------- ---

/u01/arch1/DGBJ/log1_4_826058126.arc 1 4 YES

/u01/arch1/DGBJ/log1_5_826058126.arc 1 5 YES

检查alter日志发现日志应用已经记录下来

Clearing online redo logfile 3 complete

Media Recovery Log /u01/arch1/DGBJ/log1_4_826058126.arc

Media Recovery Log /u01/arch1/DGBJ/log1_5_826058126.arc

Mon Sep 09 23:17:32 2013

Media Recovery Waiting for thread 1 sequence 6 (in transit)

这时候备库已经从归档日志完成恢复

SQL> select * from test;

ID

----------

1

（5）验证没有问题后不要忘了使用spfile启动DG环境，注意关闭顺序，先关闭主库再关闭备库

主库执行：

SQL> show parameter spfile;

NAME TYPE VALUE

------------------------------------ ----------- ------------------------------

spfile string

SQL> create spfile from pfile;

File created.

SQL> shutdown immediate;

Database closed.

Database dismounted.

ORACLE instance shut down.

备库执行：

SQL> show parameter spfile;

SQL> create spfile from pfile;

File created.

NAME TYPE VALUE

------------------------------------ ----------- ------------------------------

spfile string

SQL> shutdown immediate;

Database closed.

Database dismounted.

ORACLE instance shut down.

启动先启动备库再启动主库

备库执行：

SQL> startup;

ORACLE instance started.

Total System Global Area 318046208 bytes

Fixed Size 1299652 bytes

Variable Size 243272508 bytes

Database Buffers 67108864 bytes

Redo Buffers 6365184 bytes

Database mounted.

Database opened.

SQL> show parameter spfile;

NAME TYPE VALUE

------------------------------------ ----------- ------------------------------

spfile string /u01/app/oracle/product/11.1.0

/db_1/dbs/spfileDGBJ.ora

主库执行：

SQL> show parameter spfile;

NAME TYPE VALUE

------------------------------------ ----------- ------------------------------

spfile string /u01/app/oracle/product/11.1.0

/db_1/dbs/spfileDGWH.ora

总结： 最高性能保护模式是通过应用归档日志的方式来实现主备库的同步，所以必须在当前redo写满的时候，先归档到主库然后发送到备库，备库需要通过alter database recover managed standby database disconnect from session;语句来完成redo apply

二，配置最高可用性模式

在前面搭建过程中，没有设置redo使用LGWR SYNC的方式传递日志，所以默认是最高性能模式，这种模式下不需要使用standbylog，

查询数据库保护模式

SQL> select protection_mode, switchover_status from v$database;

PROTECTION_MODE SWITCHOVER_STATUS

-------------------- --------------------

MAXIMUM PERFORMANCE TO STANDBY

切换到最高可用性模式必须要standby redo log，这里先不配置，观察会不会有什么样的错误，步骤如下：

1. 配置最高可用性redo传输模式

SQL> alter system set log_archive_dest_2='SERVICE=DGBJ LGWR SYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=DGBJ' scope=both;

System altered.

2. 通过下面命令切换到最高可用性模式，重启数据库到mount状态，在主库执行

SQL> shutdown immediate;

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL> startup mount;

ORACLE instance started.

Total System Global Area 318046208 bytes

Fixed Size 1299652 bytes

Variable Size 281021244 bytes

Database Buffers 29360128 bytes

Redo Buffers 6365184 bytes

Database mounted.

执行切换

SQL> alter database set standby database to maximize AVAILABILITY;

Database altered.

3. 数据库open后，在主库和备库查看保护模式，都会返回下列结果

SQL> select protection_mode from v$database;

PROTECTION_MODE

--------------------

MAXIMUM AVAILABILITY

4. 查看警告日志文件发现有下列错误

Errors in file /u01/app/oracle/diag/rdbms/dgwh/DGWH/trace/DGWH_lgwr_13080.trc:

ORA-16086: standby database does not contain available standby log files

LGWR: Failed to archive log 1 thread 1 sequence 226 (16086)

然后打开/u01/app/oracle/diag/rdbms/dgwh/DGWH/trace/DGWH_lgwr_13080.trc

报：

The primary database is operating in MAXIMUM PROTECTION

or MAXIMUM AVAILABILITY mode, and the standby database does

not contain any viable standby redo logfiles.

ORA-16086: standby database does not contain available standby log files

availability

5. 测试主库的更新是否能够正常在备库上恢复

SQL> select * from test;

ID

----------

1

SQL> insert into test values (2);

SQL> insert into test values (3);

SQL> commit;

Commit complete.

SQL> alter system switch logfile;

System altered.

在主库上查看当前日志序列号为253

SQL> archive log list;

Database log mode Archive Mode

Automatic archival Enabled

Archive destination /u01/arch1/DGWH

Oldest online log sequence 251

Next log sequence to archive 253

Current log sequence 253

在备库上检查也为253

SQL> archive log list;

Database log mode Archive Mode

Automatic archival Enabled

Archive destination /u01/arch1/DGBJ

Oldest online log sequence 251

Next log sequence to archive 0

Current log sequence 253

查询test表发现刚才在主库上更新的两条数据，没有在备库上更新

SQL> select * from test;

ID

----------

1

在备库上检查归档日志应用情况

SQL> select NAME,THREAD#,SEQUENCE#,STANDBY_DEST,APPLIED from v$archived_log where rownum<5 order by SEQUENCE# desc;

NAME THREAD# SEQUENCE# STA APP

-------------------------------------------------- ---------- ---------- --- ---

/u01/arch1/DGBJ/log1_7_826058126.arc 1 7 NO YES

/u01/arch1/DGBJ/log1_6_826058126.arc 1 6 NO YES

/u01/arch1/DGBJ/log1_5_826058126.arc 1 5 NO YES

/u01/arch1/DGBJ/log1_4_826058126.arc 1 4 NO YES

发现日志都已经应用，这里我做了反复的测试，发现要过很久后才能实现数据同步，为什么这样还没找出原因，这里没创建standby redo log主备库也完成同步，好像没什么问题，求解！！！

6. 在备库上创建standby redo log，建议备用Redo日志拥有的redo日志文件必须至少与redo资源库多一个，以适应Redo资源库上的每个Redo线程，查询v$log视图来判断在Redo资源库上的redo日志有多少各个redo日志组，查询V$THREAD视图来判断Redo资源数据库上存在多少个Redo线程。

（1）在redo资源库上查询日志组数量

SQL> select group#,bytes from v$log;

GROUP# BYTES

---------- ----------

1 52428800

2 52428800

3 52428800

（2）在添加standby log前需要关闭redo apply，否则回报ORA-01156错误

SQL> alter database add standby logfile ('/u01/app/oracle/oradata/DGBJ/onlinelog/standby01.log') size 50m;

alter database add standby logfile ('/u01/app/oracle/oradata/DGBJ/onlinelog/standby01.log') size 50m

*

ERROR at line 1:

ORA-01156: recovery in progress may need access to files

SQL> alter database recover managed standby database cancel;

Database altered.

（3）查询主数据redo有3组，所以下面添加4组standy redo

SQL> alter database add standby logfile ('/u01/app/oracle/oradata/DGBJ/onlinelog/standby01.log') size 50m;

Database altered.

SQL> alter database add standby logfile ('/u01/app/oracle/oradata/DGBJ/onlinelog/standby02.log') size 50m;

Database altered.

SQL> alter database add standby logfile ('/u01/app/oracle/oradata/DGBJ/onlinelog/standby03.log') size 50m;

Database altered.

SQL> alter database add standby logfile ('/u01/app/oracle/oradata/DGBJ/onlinelog/standby04.log') size 50m;

（4）在主库写入一条数据

SQL> insert into test values (5);

1 row created.

SQL> commit;

Commit complete.

SQL> alter system switch logfile;

（5）在备库上启用redo apply

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

Database altered.

（6）然后在主库上继续更新，会发现在备库立刻同步完成

主库：

SQL> insert into test values (6);

1 row created.

SQL> commit;

Commit complete.

SQL> insert into test values (7);

1 row created.

SQL> commit;

Commit complete.

备库：

SQL> select * from test;

ID

----------

3

4

1

2

5

6

7

7 rows selected.

SQL> alter system set log_archive_dest_2='SERVICE=DGBJ LGWR SYNC AFFIRM NET_TIMEOUT=30 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=DGBJ' scope=both;

System altered.

（8）前面的设置没有指定AFFIRM的属性，这个属性用于指定直到Redo被写到备用日志后再确认从redo资源库接收到的redo，这里我反复做了实验没有发现这一特性。求解！！！

总结：根据前面的实验分析，配置redo传输为ARCH ASYNC（最高性能模式）方式，必须等待主库的日志归档后，才会同步到备库，然后备库通过alter

database recover managed standby database disconnect from session语句从主库传输过来的归档日志中恢复，使用LGWR SYNC（最高可用性或最大保护）的方式是通过主库传输在线redo，然后写入到备库的在线standby redo log，然后备库可以通过alter database recover managed standby database using current logfile disconnect from session语句立刻从standby redo log恢复。

三，最高保护模式

最大保护模式的redo传输方式与最高性能相同，所以从最高可用性切换到最大保护直接重启主库到mount，执行切换命令即可

（1）重启主库到mount

SQL> shutdown immediate;

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL> startup mount;

ORACLE instance started.

Total System Global Area 318046208 bytes

Fixed Size 1299652 bytes

Variable Size 289409852 bytes

Database Buffers 20971520 bytes

Redo Buffers 6365184 bytes

Database mounte

（2）执行切换

SQL> alter database set standby database to maximize protection;

Database altered.

SQL> alter database open;

Database altered.

在主库和备库验证：

SQL> select protection_mode from v$database;

PROTECTION_MODE

--------------------

MAXIMUM PROTECTION

（3）在最大保护模式下，如果standby database 不可用，主库会自动shutdown

禁用备库的网卡

[root@localhost ~]# ifdown eth0

在主库上执行更新

SQL> insert into test values (9);

1 row created.

SQL> commit;

当执行commit语句后会发现session一直挂起，并且在警告日志文件中有下列错误，这时候主库一直反复连接备库，我找了一下大概有10多次，然后主库就自动shutdown了

Fatal NI connect error 12532, connecting to:

(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.31.3)(PORT=1521))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=DGBJ)(CID=(PROGRAM=oracle)(HOST=localhost.localdomain)(USER=oracle))))

VERSION INFORMATION:

TNS for Linux: Version 11.1.0.6.0 - Production

TCP/IP NT Protocol Adapter for Linux: Version 11.1.0.6.0 - Production

Time: 17-SEP-2013 22:38:18

Tracing not turned on.

Tns error struct:

ns main err code: 12532

TNS-12532: TNS:invalid argument

ns secondary err code: 12560

nt main err code: 502

TNS-00502: Invalid argument

nt secondary err code: 113

nt OS err code: 0

Error 12532 received logging on to the standby

Tue Sep 17 22:38:23 2013

LGWR: Error 12532 attaching to RFS for reconnect

在主库自动shutdown的时候会session会返回下列错误，当然这个insert是不会写入到主库的。

SQL> insert into test values (9);

1 row created.

SQL> commit;

commit

*

ERROR at line 1:

ORA-03113: end-of-file on communication channel

Process ID: 4065

Session ID: 170 Serial number: 7

可见最大保护模式，提供最高级的数据保护，保证数据0丢失。