个人经历建议Dataguard搭建方式为采用LGWR ASYNC的最大性能模式，备库建立standby redo log，备库使用real-time Apply。
原理理解
在primary数据库，DataGuard可以使用归档进程(ARCn)或者日志写进程(LGWR)收集online redo log数据并传输到备库的RFS，备库再看有无standby redolog file，有的话，数据到了备库的RFS同时被备库写入standby redolog file，没有的话，备库的arcn进程会等待主库切换日志时把备库RFS中的数据一并归档。不过不管你选择归档进程也好，日志写进程也好，都由一个核心参数来控制，它就是：LOG_ARCHIVE_DEST_n，定义redo文件的传输的目的地
默认情况下，DataGuard使用ARCn进程传输redo日志。不过ARCn进程只支持最高性能的保护模式。如果standby数据库处于其它类型的保护模式，那你必须使用LGWR传输redo数据，对于最大保护和最高可用性两种模式而言，其实强调的都是一点，redo数据必须实时传输到standby数据库的RFS，备库再看有无standby redolog file以便决定是否同时写入到standby redolog file。
standby上Standby Redo Log完全等同与primary上的Online Redo Log，主库归档Online Redo Log时会触发备库也归档Standby Redo Log
搭建最大可用或最大保护，是在搭建好最大性能的基础上，主库执行alter database set standby database to maximize availability;并重启即可，之后备库应用完归档日志后也自动变成maximize availability，主库宕机后备库还是maximize availability状态
同步传输lgwr sync是把主库的操作写入主库的 online redo的同时就传送到备库的RFS备库再看有无standby redolog file，有就同时写入standby redolog file，如果备库使用real-time Apply的话，在写入standby redo后就直接应用到备库。如果备库没有启用real-time Apply，则备库的arcn进程会等待主库切换日志时把备库的standby redo也做一次归档，同时把这个归档应用到备库上。
异步传输lgwr async是主库的操作在写入主库的online redo 后再传送到备库的RFS备库再看有无standby redolog file，有就同时写入standby redolog file，如果备库使用real-time Apply的话，在写入standby redo后就直接应用到备库。如果备库没有启用real-time Apply，则备库的arcn进程会等待主库切换日志时把备库的standby redo也做一次归档，同时把这个归档应用到备库上。
Real-Time Apply和Redo Apply（即主库数据修改并commit后备库能不能实时查询到修改了）
Redo Apply是备库默认的应用方式,即应用备库的Archive log，主库数据修改并commit后备库不能实时查询到修改了的数据，只有主库归档了带动了备库的归档，这样备库才能查询到
Redo Apply的语句为
alter database recover managed standby database disconnect from session;
real-time Apply应用即应用备库的standby redo log，所以需先在备库建立standby redo log，主库数据修改并commit后备库能实时查询到修改了的数据
Real-time Apply使用如下语句
alter database recover managed standby database using current logfile disconnect from session;
只有备库using current logfile才需要standby redo logs，standby redo logs和主库是否最大可用、最大性能模式无关
SQL> alter database recover managed standby database using current logfile disconnect from session;
ERROR at line 1:
ORA-38500: USING CURRENT LOGFILE option not available without standby redo logs
主库把redo传输到备库后，备库应用redo意思即主库修改的数据是否可以实时在备库select了（已经转化为standby redo log或archivelog）整个这个过程和备库自己创建的online redo log没有关系，因为备库的online redo log无法使用，备库也无法执行alter system switch logfile或alter system archive log current（这两者必须要在open read wirte模式下，open with read only不行）
最大保护模式
这种保护模式确保主数据库故障也不会发生数据丢失。要提供这种级别的保护，主库log buffer数据必须在事务提交之前同时写到本地联机重做日志和至少一个备数据库备重做日志（即数据commit的时候必须保证log buffer传输到备库）。如果故障导致主数据库无法向至少一个远程备重做日志写其重做流，则主数据库会关闭。对于多实例RAC 数据库，如果无法写重做记录到至少一个适当配置的数据库实例，则Data Guard 关闭主数据库。最大保护模式时LOG_ARCHIVE_DEST_n 参数必须使用LGWR、SYNC、和AFFIRM 属性。
主库确保把log buffer写入online redo的同时传输到备机的RFS，但并非这些在RFS的数据需要立即在备库启用，需要看备库是否有standby redo log并且启用了Real-time Apply（能Real-time Apply的前提就是备库已经有了standby redo log），只有两个条件具备才立即在备库启用，否则就等待主库的归档带动备库的归档
当然最大保护模式下，备库宕机或无法连接的情况下，主库会出现hang住或宕机的情况（已经实验过的），所以这样的环境下不要随便关闭备库。
最大可用性模式
这种保护模式提供了可能的最高级别的数据保护，而不用与主数据库的可用性相妥协。如同最大保护模式一样，主库log buffer数据必须在事务提交之前同时写到本地联机重做日志和至少一个备数据库备重做日志（即数据commit的时候必须保证log buffer传输到备库），不过不同的是，如果最后参与的备用数据库变为不可用。例如由于网络连接问题，处理将在主数据库上继续进行而不会出现关闭主机的情况（如果不能保证则降低到最大性能模式，主库的protection_level变成RESYNCHRONIZATION，备库的protection_level变成MAXIMIZE PERFORMANCE）。备用数据库与主数据库相比，可能暂时落在后面，但当它再次变为可用时，备用数据库将自动同步，而不会丢失数据。由于同步重做传输，这种保护模式可潜在地影响响应时间和吞吐量。因此在网络不好的情况下，可能会有较大的性能影响。必须为至少1个备数据库设置LOG_ARCHIVE_DEST_n参数为LGWR、SYNC、和AFFIRM属性。
主库确保把log buffer写入online redo的同时传输到备机的RFS，但并非这些在RFS的数据需要立即在备库启用，需要看备库是否有standby redo log并且启用了Real-time Apply（能Real-time Apply的前提就是备库已经有了standby redo log），只有两个条件具备才立即在备库启用，否则就等待主库的归档带动备库的归档
最大性能模式
最高性能模式是默认的保护模式。它与最高可用性模式相比，提供了稍微少一些的主数据库数据保护，但提供了更高的性能。在任何情况下，均先完成主数据库上的写操作，主数据库的提交操作不等待备用数据库确认接收。如果任意备用目标数据库变为不可用，则处理将在主数据库上继续进行，这对性能只有很小的影响或没有影响。
默认是主库发生redo日志切换后，ARCn才将该日志传送至备库RFS，备库再对RFS的数据归档，备库再应用archivelog。非默认情况下则看主库是lgwr sync还是lgwr async，备库是否启用Real-time Apply（前提必须有standby redo log）。sync则主库确保把log buffer写入online redo的同时传输到备机的RFS，如果备库启用了Real-time Apply则备库可用实时查询到主库修改commit后的数据，否则备库只能等主库的归档带动备库的归档，备库应用归档日志无法实时查询到主库修改commit后的数据。 async则主库把log buffer写入online redo后再传输到备机的RFS，后面的依照上述sync的流程。
三种保护模式的切换出现的一点有意思的问题
主库和备库的都是PROTECTION_MODE、PROTECTION_LEVEL值分别是MAXIMUM AVAILABILITY、MAXIMUM AVAILABILITY，主库修改为MAXIMUM PERFORMANCE后，发现备库永远都不会改变为MAXIMUM PERFORMANCE，说明这种场景依旧是最大性能模式。
主库和备库的都是PROTECTION_MODE、PROTECTION_LEVEL值分别是MAXIMUM PERFORMANCE、MAXIMUM PERFORMANCE，主库修改为MAXIMUM AVAILABILITY后，发现备库会自动改变为MAXIMUM AVAILABILITY。
以上也说明，如果主库降低了保护模式，备库永远不会自动降低，但是整体的保护模式是降低的那种保护模式。
说明保护模式上升，备库会自动上升，保护模式降低，备库不会自动降低只能手工执行降低操作。
根据以上理解三种保护模式、同步异步传输、实时应用三者的关系
实时应用：就是主库数据修改并commit后备库能实时查询到修改了的数据，和三种保护模式无关，只和同步异步传输有关，即只和lgwr sync/async有关
三种保护模式：最大保护、最大可用性只能是lgwr sync，最大性能则可以arch或lgwr sync/async。三者都可以启用实时应用也可以启用archive log应用
同步异步传输：实时应用的话必须是lgwr sync/async
1. 主库使用参数lgwr async并设置为最大可用行吗
可以，不会报错
主库这时的PROTECTION_MODE,PROTECTION_LEVEL分别为MAXIMUM AVAILABILITY、RESYNCHRONIZATION；主库修改的数据并归档后，备库可以查到，备库这时的PROTECTION_MODE,PROTECTION_LEVEL都是MAXIMUM PERFORMANCE
说明这时其实还是运行在最大性能模式下
2. 主库使用参数lgwr sync并设置为最大可用，但是备库不建立standby redo log行吗
可以，不会报错，主库和备库的PROTECTION_MODE、PROTECTION_LEVEL值分别是MAXIMUM AVAILABILITY、RESYNCHRONIZATION
说明这时其实还是运行在最大性能模式下
且alert日志老出现如下
RFS[20]: Identified database type as 'physical standby': Client is LGWR SYNC pid 1550
Primary database is in MAXIMUM AVAILABILITY mode
Standby controlfile consistent with primary
Standby controlfile consistent with primary
RFS[20]: No standby redo logfiles selected (reason:7)
Errors in file /u01/app/oracle/diag/rdbms/slave/testdb1/trace/testdb1_rfs_13732.trc:
ORA-16086: Redo data cannot be written to the standby redo log
3. 主库设置参数lgwr sync并设置为最大可用，备库建立standby redo log，备库可以不实时应用吗
可以，实验过，之前alter database recover managed standby database using current logfile disconnect from session;可以实时应用的，alter database recover managed standby database cancel后alter database recover managed standby database disconnect from session;主库的数据必须archived后备库才可以查到
4. 主库设置参数lgwr sync/async并设置为最大性能模式，备库不建立standby redo log行吗
可以，不过只能alter database recover managed standby database disconnect from session;
5. 主库设置参数lgwr sync/async并设置为最大性能模式，备库建立standby redo log，备库可以实时应用吗
sync下实验过可以
async下也实验过可以
6. 主库设置参数lgwr sync/async并设置为最大性能模式，备库建立standby redo log，备库可以不实时应用吗
sync下实验过可以
async下实验过可以
7. 主库设置参数使用arch进程时，备库建立standby redo log，看能不能实时应用
不能，只能等主库归档后备库才能看到更改的数据
虽然备库可以执行alter database recover managed standby database cancel后alter database recover managed standby database disconnect from session并且不会报错
|
| 最大保护 | 最大可用 | 最大性能 |
| 进程（默认ARCH） | LGWR | LGWR | LGWR或ARCH |
| 网络传输模式 | SYNC | SYNC | LGWR的ASYNC或ARCH的ASYNC |
| 磁盘写操作 （默认NOAFFIRM） | AFFIRM | AFFIRM | LGWR SYNC则AFFIRM LGWR ASYNC和ARCH则NOAFFIRM |
| 备用日志 （默认YES需要） | YES | YES | YES或NO |
| 备用库类型 （默认物理） | 物理 | 物理或逻辑 | 物理或逻辑 |
| 备库应用standby redo log还是archivelog （默认Archivelog） | standby redo log | standby redo log | Archivelog或standby redo log |
ARCH的方式
LGWR 的ASYNC方式
不需要再指定NET_TIMEOUT了，因为LGWR与LNSn之间已无关联，所以指定不指定NET_TIMEOUT就都没任何影响 了，因此对于异步传输而言，即使网络出现故障造成primary与standby之间通信中断，也并不会影响到primary数据库的提交。
LGWR的SYNC方式
ARCH配置最大性能dataguard（不需要在备库创建standby redo log）
主库确保强制归档
alter database archivelog;
alter database force logging;
select name,log_mode,force_logging from v$database
1:主库创建主备的pfile
create pfile='XX.主’ from spfile;
create pfile='XX.备’ from spfile;
主pfile配置增加下面五项，缺一不可（DG_CONFIG谁在逗号前面，谁在逗号后面不影响，DG_CONFIG值是db_unique_name，service值是tns别名）
*.db_unique_name='master'
*.log_archive_config='DG_CONFIG=(master,slave)'
*.log_archive_dest_1='location=/orasoft/ora11g/archivelog'
*.log_archive_dest_2='service=testdg arch db_unique_name=slave' ###没有写sync，默认就是arch sync
*.remote_login_passwordfile='EXCLUSIVE'
备pfile配置增加下面七项，缺一不可（DG_CONFIG谁在逗号前面，谁在逗号后面不影响，DG_CONFIG值是db_unique_name，service值是tns别名，fal_client和fal_server值是tns别名）
*.db_unique_name='slave'
*.log_archive_config='DG_CONFIG=(master,slave)'
*.log_archive_dest_1='location=/orasoft/ora11g/archivelog'
*.remote_login_passwordfile='EXCLUSIVE'
*.fal_client='testdg'
*.fal_server='testdb'
*.STANDBY_FILE_MANAGEMENT='AUTO' //缺少这个参数的话，主库新建data_file后备库会报错ORA-01274
2:主库在mount状态下创建备库的crontrol
alter database create standby controlfile as ‘XX’
3:关闭主库，把主库数据文件、密码文件，备库crontrol拷贝到备库（不用从主库拷贝online redo log，因为备库启动的时候会自动创建online redo log）
4:主库pfile启动
5:备库pfile启动到nomount状态，再依次执行下面三条语句
alter database mount standby database;
alter database open read only;
alter database recover managed standby database disconnect from session;
以上配置是不考虑以后主备进行切换的场景，如果需要主备切换，则需要在主的pfile中增加*.fal_client、*.fal_server，在备的pfile中增加*.log_archive_dest_2
以上如果主备的归档路径不一样，则在各自的log_archive_dest_1设置自己的路径即可，说明归档日志路径不在控制文件中，在参数文件中
如果主备库的数据文件和在线日志文件路径不一样，则在备库的pfile中增加*.db_file_name_convert=’主库数据文件路径’,’ 备库数据文件路径’
*.log_file_name_convert=’主库在线日志文件路径’,’ 备库在线日志文件路径’
LGWR ASYNC配置最大性能dataguard（不需要在备库创建standby redo log）
主库确保强制归档
alter database archivelog;
alter database force logging;
select name,log_mode,force_logging from v$database
1:主库创建主备的pfile
create pfile='XX.主’ from spfile;
create pfile='XX.备’ from spfile;
主pfile配置增加下面五项，缺一不可（DG_CONFIG谁在逗号前面，谁在逗号后面不影响，DG_CONFIG值是db_unique_name，service值是tns别名）
*.db_unique_name='master'
*.log_archive_config='DG_CONFIG=(master,slave)'
*.log_archive_dest_1='location=/orasoft/ora11g/archivelog'
*.log_archive_dest_2='service=testdg lgwr async db_unique_name=slave' ###没有写sync，默认就是arch sync
*.remote_login_passwordfile='EXCLUSIVE'
备pfile配置增加下面七项，缺一不可（DG_CONFIG谁在逗号前面，谁在逗号后面不影响，DG_CONFIG值是db_unique_name，service值是tns别名，fal_client和fal_server值是tns别名）
*.db_unique_name='slave'
*.log_archive_config='DG_CONFIG=(master,slave)'
*.log_archive_dest_1='location=/orasoft/ora11g/archivelog'
*.remote_login_passwordfile='EXCLUSIVE'
*.fal_client='testdg'
*.fal_server='testdb'
*.STANDBY_FILE_MANAGEMENT='AUTO' //缺少这个参数的话，主库新建data_file后备库会报错ORA-01274
2:主库在mount状态下创建备库的crontrol
alter database create standby controlfile as ‘XX’
3:关闭主库，把主库数据文件、密码文件，备库crontrol拷贝到备库（不用从主库拷贝online redo log，因为备库启动的时候会自动创建online redo log）
4:主库pfile启动
5:备库pfile启动到nomount状态，再依次执行下面三条语句
alter database mount standby database;
alter database open read only;
alter database recover managed standby database disconnect from session;
6:备库执行create spfile from pfile //备库虽然是read only，但是也可以创建
发现LGWR ASYNC最大性能dataguard和ARCH最大性能dataguard除了主库的pfile中log_archive_dest_2不一样外，其他配置和备库pfile配置都是一模一样
在上面的基础上升级到最大可用模式
1：主库修改参数Alter system set log_archive_dest_2='service=testdg LGWR SYNC AFFIRM VALID_FOR=
(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=slave'
2：主库执行alter database set standby database to maximize availability; //之后备库应用完归档日志后也自动变成maximize availability，主库宕机后备库还是maximize availability状态
3：主库执行shutdown immediate并startup
4：备库执行alter database recover managed standby database cancel;
5：备库创建standby redo log
先在主库查询有多少组redo log，有N组redo log就建立N+1组standby log，redo log多大，standby log也建立多大
alter database add standby logfile group 4 '/orasoft/ora11g/log/standby_redo04.log' size 50M,group 5 '/orasoft/ora11g/log/standby_redo05.log' size 50M,group 6 '/orasoft/ora11g/log/standby_redo06.log' size 50M,group 7 '/orasoft/ora11g/log/standby_redo07.log' size 50M;
6：备库执行alter database recover managed standby database disconnect from session;（再应用主库重启时产生的归档日志，主库那刻产生的归档日志可能因为主库重启或备库执行alter database recover managed standby database cancel没有应用到）
7：备库执行alter database recover managed standby database cancel;
8：备库执行alter database recover managed standby database using current logfile disconnect from session;
LGWR SYNC配置最大性能dataguard（不需要在备库创建standby redo log）
主库确保强制归档
alter database archivelog;
alter database force logging;
select name,log_mode,force_logging from v$database
1:主库创建主备的pfile
create pfile='XX.主’ from spfile;
create pfile='XX.备’ from spfile;
主pfile配置增加下面五项，缺一不可（DG_CONFIG谁在逗号前面，谁在逗号后面不影响，DG_CONFIG值是db_unique_name，service值是tns别名）
*.db_unique_name='master'
*.log_archive_config='DG_CONFIG=(master,slave)'
*.log_archive_dest_1='location=/orasoft/ora11g/archivelog'
*.log_archive_dest_2='service=testdg lgwr sync affirm VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=slave'
*.remote_login_passwordfile='EXCLUSIVE'
备pfile配置增加下面七项，缺一不可（DG_CONFIG谁在逗号前面，谁在逗号后面不影响，DG_CONFIG值是db_unique_name，service值是tns别名，fal_client和fal_server值是tns别名）
*.db_unique_name='slave'
*.log_archive_config='DG_CONFIG=(master,slave)'
*.log_archive_dest_1='location=/orasoft/ora11g/archivelog'
*.remote_login_passwordfile='EXCLUSIVE'
*.fal_client='testdg'
*.fal_server='testdb'
*.STANDBY_FILE_MANAGEMENT='AUTO' //缺少这个参数的话，主库新建data_file后备库会报错ORA-01274
2:主库在mount状态下创建备库的crontrol
alter database create standby controlfile as ‘XX’
3:关闭主库，把主库数据文件、密码文件，备库crontrol拷贝到备库（不用从主库拷贝online redo log，因为备库启动的时候会自动创建online redo log）
4:主库pfile启动
5:备库pfile启动到nomount状态，再依次执行下面三条语句
alter database mount standby database;
alter database open read only;
alter database recover managed standby database disconnect from session;
6:备库执行create spfile from pfile //备库虽然是read only，但是也可以创建
在上面的基础上升级到最大可用模式
1：主库执行alter database set standby database to maximize availability; //之后备库应用完归档日志后也自动变成maximize availability，主库宕机后备库还是maximize availability状态
2：主库执行shutdown immediate并startup
3：备库执行alter database recover managed standby database cancel;
4：备库创建standby redo log
先在主库查询有多少组redo log，有N组redo log就建立N+1组standby log，redo log多大，standby log也建立多大
alter database add standby logfile group 4 '/orasoft/ora11g/log/standby_redo04.log' size 50M,group 5 '/orasoft/ora11g/log/standby_redo05.log' size 50M,group 6 '/orasoft/ora11g/log/standby_redo06.log' size 50M,group 7 '/orasoft/ora11g/log/standby_redo07.log' size 50M;
5：备库执行alter database recover managed standby database disconnect from session;（再应用主库重启时产生的归档日志，主库那刻产生的归档日志可能因为主库重启或备库执行alter database recover managed standby database cancel没有应用到）
6：备库执行alter database recover managed standby database cancel;
7：备库执行alter database recover managed standby database using current logfile disconnect from session;
RMAN创建最大可用性datagard
主库db_name为testdb，主库不设置db_unique_name，主库数据和online日志路径/orasoft/ora11g/oradata/testdb，备库数据文件路径/orasoft/ora11g/data，online路径/orasoft/ora11g/log，主备的归档日志路径都是/orasoft/ora11g/archivelog
1. 把主库的密码文件拷贝到备库
2. 确保主库force_logging值为yes和log_mod值为archivelog
alter database archivelog;
alter database force logging;
select name,log_mode,force_logging from v$database
3. 配置主备一样的tns文件
testdb =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 10.98.7.41)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = TESTDB)
)
)
testdg =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 10.98.7.39)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = slave)
)
)
4. 主库创建一个pfile文件给备库使用
create pfile='/orasoft/pfile.ora' from spfile;
5. 主库执行rman整库备份
backup database format '/orasoft/full_%U.bak';
6. 主库rman备份standby控制文件
backup current controlfile for standby format '/orasoft/control_%U';
7. 把主库的创建的pfile参数文件和控制文件备份和数据文件备份拷贝到备库，备库存放备份文件的路径和主库一样，都是/orasoft
8. 备库修改拷贝过来的pfile文件，增加下面几项
*.db_unique_name='slave'
*.log_archive_config='DG_CONFIG=(testdb,slave)'
*.log_archive_dest_1='location=/orasoft/ora11g/archivelog'
*.remote_login_passwordfile='EXCLUSIVE'
*.fal_client='testdg'
*.fal_server='testdb'
*.db_file_name_convert='/orasoft/ora11g/oradata/testdb','/orasoft/ora11g/data'
*.log_file_name_convert='/orasoft/ora11g/oradata/testdb','/orasoft/ora11g/log'
*.STANDBY_FILE_MANAGEMENT='AUTO'
9. 备库通过修改后的pfile启动到nomount状态
startup nomount pfile='/orasoft/pfile.ora'
10. 备库rman恢复standby controlfile
restore standby controlfile from '/orasoft/control_09ps9sla_1_1';
11. 备库启动到mount状态
alter database mount;
12. 备库rman恢复数据文件
restore database;
13. 备库创建standby redo log
先在主库查询有多少组redo log，有N组redo log就建立N+1组standby log，redo log多大，standby log也建立多大
alter database add standby logfile group 4 '/orasoft/ora11g/log/standby_redo04.log' size 50M,group 5 '/orasoft/ora11g/log/standby_redo05.log' size 50M,group 6 '/orasoft/ora11g/log/standby_redo06.log' size 50M,group 7 '/orasoft/ora11g/log/standby_redo07.log' size 50M;
14. 主库参数调整
alter system set log_archive_dest_2='service=testdg lgwr sync affirm valid_for=(online_logfiles,primary_role) db_unique_name=slave'
alter system set log_archive_config='dg_config=(testdb,slave)'
15. 备库依次执行如下操作
select sequence#,applied from v$archived_log;查看是否主库的归档日志传输过来了
alter database recover managed standby database disconnect from session;应用归档日志
alter database recover managed standby database cancel;
alter database open read only;
alter database recover managed standby database disconnect from session;
16. 备库执行create spfile from pfile //备库虽然是read only，但是也可以创建
17.主库调整为最大可用模式，依次执行如下
alter database set standby database to maximize availability; //之后备库应用完归档日志后也自动变成maximize availability，主库宕机后备库还是maximize availability状态
shutdown immediate
startup
18.备库依次执行如下
alter database recover managed standby database cancel;
alter database recover managed standby database disconnect from session;
alter database recover managed standby database cancel;
alter database recover managed standby database using current logfile disconnect from session;
Dataguard升级到最大保护模式
MAXIMUM PERFORMANCE可以直接升级到MAXIMUM PROTECTION，而不需要经历先升级到MAXIMUM AVAILABILITY才能再升级到MAXIMUM PROTECTION
MAXIMUM PERFORMANCE升级到MAXIMUM PROTECTION的方法
1. 主库修改参数为(如果之前是MAXIMUM AVAILABILITY或之前就是如下则不用修改了)
lgwr sync affirm valid_for=(online_logfiles,primary_role)
2. 主库关闭并启动到mount状态
3. 主库执行
alter database set standby database to maximize protection;
4. 备库执行(如果之前是MAXIMUM AVAILABILITY或之前就是如下则不用执行)
alter database add standby logfile group 4 '/xx/standby_redo04.log' size 50M,group 5 '/xx/standby_redo05.log' size 50M,group 6 '/xx/standby_redo06.log' size 50M,group 7 '/xx/standby_redo07.log' size 50M;
5. 主库执行（此过程中必须保证所有主库的归档日志已经传输到了备库，否则会报错ORA-03113: end-of-file on communication channel，alert日志显示ORA-16072: a minimum of one standby database destination is required）
Alter database open
6. 备库执行(如果之前是MAXIMUM AVAILABILITY或之前就是如下则不用执行)
alter database recover managed standby database cancel;
alter database recover managed standby database using current logfile disconnect from session;
以上第5步遇到问题则如下操作
主库先执行如下两句
alter database set standby database to maximize PERFORMANCE;
alter database open;
备库查看到所有归档日志都已经收到了并applied为yes后主库再执行后面三句
SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME, APPLIED FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;
主库执行如下三句
shutdown immediate;
alter database set standby database to maximize protection;
alter database open;
MAXIMUM AVAILABILITY升级到MAXIMUM PROTECTION的方法
1. 主库关闭启动到mount状态
2. 主库执行
alter database set standby database to maximize protection;
3. 主库执行
Alter database open
配置Dataguard的相关参数解释:
1. DB_NAME, 数据库名字, 需要保持同一个DataGuard中所有主库和物理备库的DB_NAME相同
primary端和standby端相同:
*.DB_NAME='WENDING'
2. DB_UNIQUE_NAME, 每一个数据库需要指定一个唯一的名字（可以随便定义，不影响db_name和instance_name）
primary端:
*.DB_UNIQUE_NAME=WENDING
standby端:
*.db_unique_name=WDSTD
3. LOG_ARCHIVE_CONFIG, 该参数通过DG_CONFIG 属性罗列同一个DataGuard中所有DB_UNIQUE_NAME(含主库及备库), 以逗号分隔
primary端和standby端相同:（谁在逗号前面，谁在逗号后面不影响）
*.LOG_ARCHIVE_CONFIG='DG_CONFIG=(WENDING,WDSTD)'
4. LOG_ARCHIVE_DEST_n, 归档文件的生成路径, LOCATION代表本地机上, SERVICE指明在另一台机器上，service的值是tns的别名
primary端:
*.LOG_ARCHIVE_DEST_1='LOCATION=/u01/arch/WENDING VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=WENDING'
*.LOG_ARCHIVE_DEST_2='SERVICE=DB_WDSTD LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=WDSTD'
standby端:
*.LOG_ARCHIVE_DEST_1='LOCATION=/u01/arch/WDSTD VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=WDSTD'
*.LOG_ARCHIVE_DEST_2='SERVICE=DB_WENDING LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=WENDING'
5. AFFIRM、NOAFFIRM 、VALID_FOR
AFFIRM：在日志写进程进行之前，所以的归档日志和备库日志必须同步写完
NOAFFIRM:在主库的日志写进程不等所有磁盘IO完成
缺省的是ANOFFIRM
VALID_FOR属性指定传输及接收对象
redo_log_type可设置为：ONLINE_LOGFILE，STANDBY_LOGFILE，ALL_LOGFILES
database_role可设置为：PRIMARY_ROLE，STANDBY_ROLE，ALL_ROLES
默认值:valid_for=(ALL_LOGFILES,ALL_ROLES)
6. LOG_ARCHIVE_DEST_STATE_n, 指定参数值为ENABLE,激活定义的归档日志目录, 允许redo传输服务传输redo数据到指定的路径
primary端:
*.LOG_ARCHIVE_DEST_STATE_1=ENABLE
*.LOG_ARCHIVE_DEST_STATE_2=ENABLE
standby端:
*.LOG_ARCHIVE_DEST_STATE_1=ENABLE
*.LOG_ARCHIVE_DEST_STATE_2=ENABLE
7. REMOTE_LOGIN_PASSWORDFILE, 推荐设置参数值为EXCLUSIVE或者SHARED, 注意保证相同DataGuard配置中所有db 服务器sys密码相同
primary端和standby端相同:
*.REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
8. LOG_ARCHIVE_FORMAT, 指定归档文件格式, 这里在主备端最好保持一样的格式
primary端和standby端相同:
*.LOG_ARCHIVE_FORMAT=log_%t_%s_%r.arc
9. db_file_name_convert、log_file_name_convert
*.db_file_name_convert:
standby和primary的datafile和tempfile路径不一致时，可以通过设置该参数让其自动转换,前面表示转换前对方的路径，后面表示转换后自己的路径。是个备库参数
如果主库的数据文件有多个路径，则设置如下
*.db_file_name_convert='主路径1','备路径1','主路径2','备路径2’
如果主路径1下包含主路径2，比如/master/db下有文件db01.dbf，/master/db/db2下有文件db02.dbf，则还是按上述设置，不能只设置*.db_file_name_convert='主路径1','备路径1'，因为备路径1下面不会自动再建立/db2目录，因为这个参数是针对文件而言，不是针对目录而言
*.log_file_name_convert：
是个备库参数
standby和primary的online redo log文件（不含归档日志）路径不一致时，可以通过设置该参数让其自动转换,前面表示转换前对方的路径，后面表示转换后自己的路径。
如果主库的online redo log的每个group有多个member，则设置如下
*.log_file_name_convert='主路径1','备路径1','主路径2','备路径2’
*.log_file_name_convert='+DATA/testdb/onlinelog','/orasoft/ora11g/log','+ARCH/testdb/onlinelog','/orasoft/ora11g/log2’
db_file_name_convert:数据文件(dba_data_files包含undo)和临时数据文件
log_file_name_convert：在线日志，不包含archive log
db_file_name_convert参数仅适用于physical standby和rman duplicate，对logical standby和普通rman restore无效；
log_file_name_convert参数仅适用于physical standby和rman duplicate,但是不能再duplicate的run命令中直接运行
*.fal_client和*.fal_server
是个备库参数，前者的值是自己，后者的值是对方，值是tns的别名
*.STANDBY_FILE_MANAGEMENT
是个备库参数，设置为*.STANDBY_FILE_MANAGEMENT=’AUTO’
Standb redo log 每次只能查到最近的一个sequence#，如下图
问题1：是否log_archive_dest_2=service 中值为lgwr，备库就一定要standby_redo_log
回答：不是，就算在最大可用或最大保护模式下，备库都不一定要standby_redo_log
问题2：最大可用模式，备机是否可以应用archivelog
回答：可以，不过应用了archivelog后，主库的数据在备库无法实时查询到，只有归档后才可以查询到
问题3：最大可用模式下，备机宕机后，重启备机，dataguard是否可以继续，并且还是最大可用模式
回答：可以，是最大可用模式
如果主机启动后，备机长时间没有实时应用standby redo log，可能有异常，备机需要先执行alter database recover managed standby database disconnect from session;应用归档日志，等归档日志应用完成后再执行alter database recover managed standby database cancel，再执行alter database recover managed standby database using current logfile disconnect from session;应用standby redo log
问题4：最大可用模式下，主机宕机后，重启主机，dataguard是否可以继续，并且还是最大可用模式
回答：可以，是最大可用模式
如果主机启动后，备机长时间没有实时应用standby redo log，可能有异常，备机需要先执行alter database recover managed standby database cancel，再执行alter database recover managed standby database disconnect from session应用归档日志，等归档日志应用完成后再执行alter database recover managed standby database cancel，再执行alter database recover managed standby database using current logfile disconnect from session;应用standby redo log
问题5：最大可用模式下，主机宕机，无法启动，备机是否可以升级为主机
回答：可以
备机执行如下
1. alter database recover managed standby database finish force;
2. alter database commit to switchover to primary with session shutdown;
3. alter database open;
问题6：备库不创建standby redo log是否可以实时应用日志
回答：不可以，实时应用日志的时候会报错ORA-38500: USING CURRENT LOGFILE option not available without standby redo logs
问题7：最大性能模式下，备库是否可以实时应用日志
回答：如果最大性能模式下使用了lgwr来传输日志，备库是可以实时应用日志
问题8：最大可用性模式下，备库是否可以应用archive log
回答：可以
最大可用性模式下，本来备库可以实时接收主库的数据的，不过也可以选择归档进行应用
问题9：主库不设置db_unique_name是否可以正常搭建datagard
回答：可以
因为主库不设置db_unique_name，则主库的db_unique_name和service_name都是默认是db_name
问题10：备库是否可以不设置db_unique_name
回答：可以，如果主库设置了db_unique_name，则备库可以不设置，不过不推荐这样设置
一般主库不设置db_unique_name，备库设置db_unique_name，则在主备的参数文件*.LOG_ARCHIVE_CONFIG='DG_CONFIG=(主db_name,备db_unique_name)'
而且主备的tns中都配置主的service_name=主db_name，备的service_name=备db_unique_name
问题11：搭建一个datagard，测试LOG_AUTO_DELETE为true后，看会不会自动删除归档日志
Exec DBMS_LOGSTDBY.APPLY_SET('LOG_AUTO_DELETE', 'TRUE');
回答：不会，不知道是不是在逻辑环境下可以
物理standby情况下，备库无法执行该语句，主库执行该语句后，日志应用完后，主库和备库的日志都没有见删除
问题12：搭建dataguard时不拷贝主库的在线日志，那备库到什么时候开始创建online redo log
回答：在备库执行alter database recover managed standby database disconnect from session或alter database recover managed standby database using current logfile disconnect from session后，如果备库的*.log_file_name_convert参数设置正确，则备库开始创建online redo log
只要备库执行了recover，备库就开始创建online redo log
问题13：搭建dataguard时使用rman备份进行恢复，备库alter database recover managed standby database disconnect from session时会用到增量备份包吗
回答：不会，如果使用了0级备份和1级备份2级备份，备库还原使用了0级备份，recover时不会使用1级和2级备份包，而是使用了自0级备份以来的所有归档日志
问题14：搭建datagard和操作系统用户名密码有关系吗
回答：没有，只和oracle的用户名和密码有关，一般只和sys用户有关
问题15：datagard可以通过rman命令自动删除归档日志吗
回答：可以
执行这样的脚本就行delete noprompt archivelog until time "sysdate-30";
问题16：配置好主备库后，备库还没有开始应用归档日志之前，备库通过0级备份restore的，会不会主库所有0级备份后的归档日志都会拷贝过来，是不是alter database recover managed standby database disconnect from session需要所有归档日志都拷贝过来了才能进行
回答：不会，会拷贝一部分
不是，只有主库0级备份后的归档日志都还在，并且0级备份后的第一个归档日志传输到了备库，备库就开始recover，在recover的过程中，需要哪个归档日志就从主库去获取哪个归档日志，如果主库归档日志丢失了，那就会报错了
问题17：此类报错是不是只是因为主备库的密码文件不一致导致
FAL[client, USER]: Error 1031 connecting to mierpdb2 for fetching gap sequence
ORA-01031: insufficient privileges
ORA-01031: insufficient privileges
回答：不一定，有时是因为备库recover归档日志时，获取不到主库的归档日志也会报这样的错。
问题18：下列问题如何处理
FAL[client]: Failed to request gap sequence
GAP - thread 1 sequence 168065-168066
DBID 3642507004 branch 645772988
FAL[client]: All defined FAL servers have been attempted.
回答：说明备库缺少sequence为168065和168066的归档日志
解答1：如果主库也缺少了这个日志并且再也找不回来，则datagard无法继续了，需要重做，如果主库有这个日志的备份，则还原这个归档日志的备份，并把还原出来的归档日志拷贝到备库，并执行以下语句注册归档日志, 如果V$ARCHIVED_LOG已经有了这些日志，但是长时间没有应用可能某个MRP进程挂了，则执行alter database recover managed standby database cancel后再执行alter database recover managed standby database disconnect from session; --应用备库的归档日志或alter database recover managed standby database using current logfile disconnect from session;--应用备库的standby redo日志
SQL>ALTER DATABASE REGISTER PHYSICAL LOGFILE '/mierp/arch/1_168065_836701255.dbf';
SQL>ALTER DATABASE REGISTER PHYSICAL LOGFILE '/mierp/arch/1_168066_836701255.dbf';
解答2：如果主库不缺少这日志，这又如何理解呢？实践中碰到过这种情况，当时168065之前的归档日志是一段时间从主库获取的，这之后主库与备库的日志传送被我禁用，之后，当主库到了168066之后的日志点后，重新开启了主库与备库的日志传送，这样子168065-168066的归档日志就缺失了，也出现了以上的报错。这个问题出来后，采取了如下的措施：将FAL_SERVER数据库传送备库归档日志路径禁用掉，之后经过一段时间重新将该归档路径启动，结果发现归档日志又自动开始传送了。在备库可以看到如下的日志，可以清楚地看到备库日志传送进程RFS重启了。据此，理解是，RFS[10]和RFS[11]这两个备库日志传送进程在启动时并没有获取备库缺少某些旧归档日志的信息，因此它只获取168164之后，由主库新生成的日志，而在备库恢复到168065这个归档日志时，才发现还缺少一些旧的日志，但RFS[10]和RFS[11]不会被告知这个信息，因此它们不会去获取旧的日志。而当重启日志传送后，RFS[12]和RFS[13]这两个新的日志传送进程会被告之备库目前还缺一些旧的日志，这两个进程就去主库尝试获取前面缺的日志，发现后，就开始了旧日志的传送。
问题19：datagard备库的归档日志是怎么个生成流程
回答：
1.主库lgwr，备库还没有到应用归档日志的过程即还未执行alter database recover语句（即还没有真正的online redo log文件在备库），备库不建立standby，主库执行alter system archive log current看归档会到备库吗
1.会
得出结论：只要备库打开至mount状态（甚至没有restore database），主库就会把归档日志传输到备库，主库日期切换后，最新的归档也会传输到备库
备库没有restore database即没有任何数据文件和online redo log和standby redo log也可以查询v$log，查询的结果和主库基本一致
但是查询v$standby_log则没有结果，因为没有建立standby redo log
2.主库lgwr，备库不应用归档日志，备库建立standby redo log，主库执行alter system archive log current看standby redo的sequence是否变化
2.会变化
3. 主库arch，备库不应用归档日志，备库不建立standby，主库执行alter system archive log current看归档会到备库吗
3.会
答案：所有备库的归档日志是通过备库的RFS->ARCN生成，如果备库有standby redo log，则流程是备库RFS->standby redo log->ARCN，和备库自己的online redo log没有关系，因为至始至终都是主库的LOG_ARCHIVE_DEST_N决定了把主库的redo日志存放到哪台备库的RFS，因为就算备库没有online redo log也可以查到v$log的信息，而这样v$log的信息其实是主库的，就算在ARCN传输模式下，也不是通过ARCN把归档日志从主库拷贝到备库相应的位置，因为主库拷贝文件到备库是通过OS的，是需要OS的用户名密码验证的。而实际上我们并没有看到备库产生归档日志的时候，是需要OS的用户名密码的。
问题20：最大可用性模式下，备库mount后并restore database并创建了standby redo log，主库归档日志传输到了备库，但是还没有应用过，是否可以跳过先应用归档日志直接应用standby redo log
回答：可以
问题21：dataguard备库select name from v$datafile和select member from v$logfile都正常， select tablespace_name from dba_tablespaces会出现ORA-03113: end-of-file on communication channel错误，根据告警日志，信息是ERROR: slave communication error with ASM; terminating process 7610，怎么产生的，怎么解决
回答：是因为*.db_file_name_convert只配置了数据文件，没有配置temp文件导致，可以重新配置备库的pfile并重启解决，也可以执行select name from v$tempfile找到临时文件，再执行alter database tempfile '+DATA/ /temp.263.868896343' drop including datafiles删除tempfile，再创建一个tempfile即可。alter tablespace temp add tempfile '/data01/ibm186/data01/temp.dbf' size 4096M;
问题22：dataguard主库的文件是通过OMF创建，备库也通过OMF创建，备库是否可以在*.db_file_name_convert只配置主库和备库的db_create_file_dest即可
回答：不可，因为主库备库的db_create_file_dest目录的子目录名称可能不一样，会导致无法创建文件，因为OMF创建文件规则是db_create_file_dest\实例名\datafile或tempfile\文件名称
问题23：最高可用性模式，主库故障后，备库进行Failover的切换，是否必须按以下四步进行
1. 备库执行ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;
2. 备库执行alter database recover managed standby database finish force;
3. 备库执行alter database commit to switchover to primary with session shutdown;
4. 备库执行alter database open;
回答：是的，虽然可以跳过第一步，但是不建议这样做
根据问题8，得出结论
对于最大保护和最高可用性两种模式而言，其实强调的都是一点，redo数据必须实时传输到standby数据库（这句话可能是这样理解，主库的redo必须能够让备库实时使用到，但并不是说主库的redo中涉及的变更，必须马上写入到备库的数据文件）
dataguard-什么时候创建redo日志
standby在mount状态下不会创建redo日志，在如下
alter database recover managed standby database disconnect from session; 或alter database open read only;会创建redo日志
Fetching gap sequence in thread 2, gap sequence 78606-78705
以上以100个sequence单位来进行，如果很多日志都没有到达，则处理完这100个后，会继续报后面100个，依次类推
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/30126024/viewspace-2121946/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/30126024/viewspace-2121946/
853
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
