配置DG涉及的参数大致如下：
具体的设置语句可以参考其它的安装DG记录
1.DB_NAME，数据库名字，需要保持同一个Data Guard 中所有数据库DB_NAME相同
2.DB_UNIQUE_NAME，对应数据库的实例名，每一个数据库需要指定一个唯一的名字
ALTER SYSTEM SET DB_UNIQUE_NAME=aaa scope=spfile;
3.LOG_ARCHIVE_CONFIG，该参数通过DG_CONFIG 属性罗列同一个Data Guard 中所有DB_UNIQUE_NAME(含primary db 及standby db)，以逗号分隔
alter system setlog_archive_config="DG_CONFIG=(dg1,dg2)" scope=spfile;
4.CONTROL_FILES，控制文件位置说明，注意要修改到具体的控制文件位置
5.LOG_ARCHIVE_DEST_n，归档文件的生成路径，location代表本地机上，service指明在另一台机器上
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=standby LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=standby scope=spfile;
6.LOG_ARCHIVE_DEST_STATE_n，指定参数值为ENABLE，激活定义的归档日志目录，允许redo 传输服务传输redo数据到指定的路径
7.REMOTE_LOGIN_PASSWORDFILE，推荐设置参数值为EXCLUSIVE 或者SHARED，注意保证相同Data Guard配置中所有db 服务器sys密码相同
8.LOG_ARCHIVE_FORMAT，指定归档文件格式，这里在主备端应保持一样的格式
9.COMPATIBLE，主数据库和备用数据库的oracle版本必须一致，这个参数指明了oracle的版本号
10.FAL_SERVER，指向对方的服务名，
primary端（主库进行设置，是为了在切换后主备角色互换）：
*.FAL_SERVER=ora10gdg
11.FAL_CLIENT，自己的服务名
primary端（主库进行设置，是为了在切换后主备角色互换）：
*.FAL_CLIENT=ora10g
12.DB_FILE_NAME_CONVERT，主数据库和备用数据库的数据文件转换目录对映（如果两数据库的目录结构不一样），如果有多个对映，逐一指明对映关系
格式：*.db_file_name_convert=主数据库数据文件目录，备用数据库数据文件目录
primary端（主库进行设置，是为了在切换后主备角色互换）：
alter system set db_file_name_convert="/u01/oradata/dg","/u01/oradata/dg" scope=spfile;
13.LOG_FILE_NAME_CONVERT，指明主数据库和备用数据库的log文件转换目录对映
格式：*. log_file_name_convert=主数据库log目录，备用数据库目录
altersystem setlog_file_name_convert="/u01/oradata/dg","/u01/oradata/dg"scope=spfile;
14.STANDBY_FILE_MANAGEMENT，如果primary 数据库数据文件发生修改（如新建，重命名等）则按照本参数的设置在standby 中做相应修改。设为AUTO 表示自动管理。设为MANUAL表示需要手工管理
主库向备库传输日志有两种进程： 详见：点击打开链接
LGWR，这个进程只传输redo；一种是ARCn，这个进程负责online redo的归档和把归档日志传输到备库。
具体使用哪种传输需要在log_archive_dest_2参数里指定LGWR或ARCH。
alter system set log_archive_dest_2='SERVICE=db_phystdby
LGWR SYNC AFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=PHYSTDBY
(注：SERVICE=后为tnsnames.ora里指定的备库的tnsname；unique_name可以用show parameter db_unique_name在备库查询）
在主库的log_archive_dest_2上还需要指定SYNC（同步传输）或者ASYNC（异步传输）
同步传输是把主库的操作写入主库的onlin redo的之前触发网络I/O，传送日志条目到备库的standby redolog file，完成后才会COMMIT。
如果备库使用real-time Apply的话，
在写入standby redo后就直接应用到备库。
如果备库没有启用real-time Apply，则备库的arcn进程会等待主库切换日志时把备库的standby redo也做一次归档，同时把这个归档应用到备库上。
异步传输是主库的操作在写入主库的online redo 后，由LNSn进程发送给备库，备库的RFS进程负责接收数据并写入自己的standby redolog file 里，之后就和上面的一样，看
备库是否启用了real-Time Apply来决定何时应用这些传送过来的redo。
#################
SYNC模式的流程图。 参考：http://www.gomudemi.org/?p=176
1、当user 发出 commit命令后，将产生一条 redo record （也称作redo entry）放入SGA中的 redo buffer 中，后台进程LGWR将读取此redo record，将其写入online redo log file。并等待从LNS进程传来的确认信息。
2、LNS（Log Network Server） 进程同样从redo log buffer读取redo record，并将其通过Oracle Net Services传输给standby DB。在standby DB上的RFS后台进程将接收到的redo record写入standby database中。
3、当RFS确定写入所有的redo record到磁盘后，向primary DB的LNS发送确认信息。当LGWR收到LNS转发的确认信息后，才返回commit成功的消息给user。
接下来来看ASYNC：类似于SYNC，只是primary DB上的LGWR可以不必等待LNS的确认信息，而且LNS可以读取online redo log中的redo record。对于ASYNC，就可以考虑使用压缩方式传输redo record，从而节省带宽，但是这会使CPU的利用升高。此外，如果LNS在读取online redo log中记录时刚好遇到online switch，则可能造成standby的archivelog gap。LNS的不同步记录，在提高性能的同时也可能会产生数据的丢失。
启用real-time Apply只需在备库启用redo应用时加入using current logfile,
alter database recover managed standby database using current logfile disconnect from session;
后记：三思笔记中的说明如下——默认情况下，log应用服务会等待单个归档文件全部接收之后再启动应用。但是如果在dest2中指定了lgwr，则发送流程应该是主库lgwr进程把操作写入online redolog file，LNSn进程把redo内容实时的发送向standby端，同时备库的RFS进程负责接收主库发来的redo并写入standby redolog files，当主库有切换日志或归档操作后，备库的ARCn进程也把备库的standby redo进行一次归档操作，同时由MRP或者LSP（这两个进程应该是一个负责real-time Apply,一个负责延时应用）这两个进程
