问题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中涉及的变更，必须马上写入到备库的数据文件）