对open resetlogs的primary数据库standby的恢复
当primary数据库被以resetlogs打开之后，dg提供了一些方案，能够让你快速的恢复物理standby ，当然这是有条件的，不可能所有的情况都可以快速恢复。 我们都知道alter database open resetlogs之后，数据库的scn被重置，也就是此时其redo数据也会从头开始。当物理standby接收到新的redo数据时，redo应用会自动获取这部分redo数据。对于物理standby而言，只要数据库没有应用resetlogs之 后 的redo数据，那么这个过程是不需要dba手工参与的。
下表描述 其它 情况下如何同步standby与primary数据库。
| Standby数据库状态 | Standby服务器操作 | 解决方案 |
| 没有应用resetlog之前的redo数据 | 自动应用新的redo数据 | 无须手工介入 |
| 应用了resetlog之 后 的redo数据，不过standby打开了flashback。 | 可以应用，不过需要dba手工介入 | 1. 手工flashback到应用之前 2. 重启redo应用，以重新接收新的redo数据。 |
| 应用了resetlog之 后 的redo数据，而且没有flashback。 | 完全无法应用 | 重建物理standby是唯一的选择 |
很绕是吧，举个例子你就明白了：
假设primary数据库当前生成的archive sequence#如下：...26,27,28，然后在28的时候执行了resetlogs，又生成了新的1,2,3.....，那么standby能够正常接收并应用26,27,28及新产生的1,2,3....
如果primary数据库在28的时候发生数据出现故障，recover到27，然后resetlogs，又生成了新的1,2,3.....，这个时候(大家注意，招子放亮点)：如果standby还没有应用28，刚刚应用到27，则standby还可以继续接收新的redo数据1,2,3.....并应用。
如果此时不幸，standby由于是实时应用，已经应用了28的redo数据，那么如果standby打开了flashback，不幸中的万幸啊，这时候只需要dba手工介绍先flashback到27,然后再接收并应用新的1,2,3....
如果此时非常不幸，standby由于是实时应用，已经应用了28的redo数据，并且standby也没有打开flashback，那么，重建物理standby是你唯一的选择。
这下大家都明白了吧，赶紧起立鼓掌感谢yangtingkun大大的友情客串及形象示例，很通俗，很易懂:)。
监控primary/standby数据库
本节主要介绍一些监控dg配置的方式， 先给大家提供一个表格(描述不同事件的不同信息监控途径)：
| primary数据库事件 | primary监控途径 | standby监控途径 |
| 带有enable|disable thread子句的alter database命令 | Ø Alert.log Ø V$THREAD | Ø Alert.log |
| 当前数据库角色，保护模式，保护级别，switchover状态，failover快速启动信息等 | Ø V$DATABASE | Ø V$DATABASE |
| Redo log切换 | Ø Alert.log Ø V$LOG Ø V$LOGFILE的status列 | Ø Alert.log |
| 重建控制文件 | Ø Alert log | Ø Alert log |
| 手动执行恢复 | Ø Alert log | Ø Alert log |
| 表空间状态修改(read-write/read-only,online/offline) | Ø DBA_TABLESPACES Ø Alert log | Ø V$RECOVER_FILE |
| 创建删除表空间或数据文件 | Ø DBA_DATA_FILES Ø Alert log | Ø V$DATAFILE Ø Alert log |
| 表空间或数据文件offline | Ø V$RECOVER_FILE Ø Alert log Ø DBA_TABLESPACES | Ø V$RECOVER_FILE Ø DBA_TABLESPACES |
| 重命名数据文件 | Ø V$DATAFILE Ø Alert log | Ø V$DATAFILE Ø Alert log |
| 未被日志记录或不可恢复的操作 | Ø V$DATAFILE view Ø V$DATABASE view | Ø Alert log |
| 恢复的进程 | Ø V$ARCHIVE_DEST_STATUS Ø Alert log | Ø V$ARCHIVED_LOG Ø V$LOG_HISTORY Ø V$MANAGED_STANDBY Ø Alert log |
| Redo传输的状态和进度 | Ø V$ARCHIVE_DEST_STATUS Ø V$ARCHIVED_LOG Ø V$ARCHIVE_DEST Ø Alert log | Ø V$ARCHIVED_LOG Ø Alert log |
| 数据文件自动扩展 | Ø Alert log | Ø Alert log |
| 执行 OPEN RESETLOGS或CLEAR UNARCHIVED LOGFILES | Ø Alert log | Ø Alert log |
| 修改初始化参数 | Ø Alert log | Ø Alert log |
概括起来 主要 通过二 个方面：
1、 Alert Log
一句话：一定要养成有事没事定期不定期随时查看alert.log的好习惯同时特别注意alert中的提示通常不经意间会发现它的提示能够让你的思路豁然开朗。
2、 动态性能视图
先也是一句话：做为oracle自己自觉主动维护的一批虚拟表它的作用非常明显通过它可以及时获得当前数据库状态及处理进度总之好处多多也需特别关注后面示例也会多处用到大家要擦亮双眼。
l 先来点与恢复进度相关的v$视图应用示例：
A) .查看进程的活动状况--- v$managed_standby
该视图就是专为显示standby数据库 相关进程的 当前 状态信息，例如：
SQL> select process,client_process,sequence#,status from v$managed_standby;
PROCESS CLIENT_P SEQUENCE# STATUS
--------- -------- ---------- ------------
ARCH ARCH 763 CLOSING
ARCH ARCH 762 CLOSING
MRP0 N/A 764 WAIT_FOR_LOG
RFS LGWR 764 IDLE
RFS N/A 0 IDLE
PROCESS列显示进程信息
CLIENT_PROCESS列显示对应的主数据库中的进程
SEQUENCE#列显示归档redo的序列号
STATUS列显示的进程状态
通过上述查询可以得知primary开了两个归档进程，使用lgwr同步传输方式与standby通信，已经接收完763的日志，正等待764。
B) .确认redo应用进度---v$archive_dest_status
该视图显示归档文件路径配置信息及redo的应用情况等，例如：
SQL> select dest_name,archived_thread#,archived_seq#,applied_thread#,applied_seq#,db_unique_name
2 from v$archive_dest_status where status='VALID';
DEST_NAME ARCHIVED_THREAD# ARCHIVED_SEQ# APPLIED_THREAD# APPLIED_SEQ# DB_UNIQUE_
-------------------- ---------------- ------------- --------------- ------------ ----------
LOG_ARCHIVE_DEST_1 1 765 0 0 jsspdg
LOG_ARCHIVE_DEST_2 0 0 0 0 jssweb
STANDBY_ARCHIVE_DEST 1 764 1 764 NONE
C) .检查归档文件路径及创建信息---v$archived_log
该视图查询standby数据库归档文件的一些附加信息，比如文件创建时间啦，创建进程啦，归档序号啦，是否被应用啦之类，例如：
SQL> select name,creator,sequence#,applied,completion_time from v$archived_log;
NAME CREATOR SEQUENCE# APP COMPLETION_TIM
-------------------------------------------------- ------- ---------- --- --------------
E:/ORA10G/ORADATA/JSSPDG/LOG1_750_641301252.ARC ARCH 750 YES 18-1月 -08
E:/ORA10G/ORADATA/JSSPDG/LOG1_749_641301252.ARC ARCH 749 YES 18-1月 -08
E:/ORA10G/ORADATA/JSSPDG/LOG1_751_641301252.ARC ARCH 751 YES 18-1月 -08
E:/ORA10G/ORADATA/JSSPDG/LOG1_752_641301252.ARC ARCH 752 YES 18-1月 -08
E:/ORA10G/ORADATA/JSSPDG/LOG1_753_641301252.ARC ARCH 753 YES 18-1月 -08
E:/ORA10G/ORADATA/JSSPDG/LOG1_754_641301252.ARC ARCH 754 YES 18-1月 -08
D) .查询归档历史---v$log_history
该视图查询standby库中所有已被应用的归档文件信息(不论该归档文件是否还存在)，例如：
SQL> select first_time,first_change#,next_change#,sequence# from v$log_history;
FIRST_TIME FIRST_CHANGE# NEXT_CHANGE# SEQUENCE#
------------------- ------------- ------------ ----------
2008-01-03 12:00:51 499709 528572 18
2008-01-08 09:54:42 528572 539402 19
2008-01-08 22:00:06 539402 547161 20
2008-01-09 01:05:57 547161 560393 21
2008-01-09 10:13:53 560393 561070 22
l 再来点与log应用相关的v$视图应用示例：
A) .查询当前数据的基本信息---v$database信息。
例如，查询数据库角色，保护模式，保护级别等：
SQL> select database_role,db_unique_name,open_mode,protection_mode,protection_level,switchover_status
2 from v$database;
DATABASE_ROLE DB_UNIQUE_NAME OPEN_MODE PROTECTION_MODE PROTECTION_LEVEL SWITCHOVER_STATUS
---------------- ------------------------------ ---------- -------------------- -------------------- --------------------
PHYSICAL STANDBY jsspdg MOUNTED MAXIMUM AVAILABILITY MAXIMUM AVAILABILITY SESSIONS ACTIVE
再比如，查询failover后快速启动的信息
SQL> select fs_failover_status,fs_failover_current_target,fs_failover_threshold,
2 fs_failover_observer_present from v$database;
FS_FAILOVER_STATUS FS_FAILOVER_CURRENT_TARGET FS_FAILOVER_THRESHOLD FS_FAIL
--------------------- ------------------------------ --------------------- -------
DISABLED 0
B) .检查应用模式(是否启用了实时应用)---v$archive_dest_status
查询v$archive_dest_status视图，如果打开了实时应用，则recovery_mode会显示为：MANAGED REAL TIME APPLY，例如：
SQL> select recovery_mode from v$archive_dest_status where dest_id=2;
RECOVERY_MODE
-----------------------
MANAGED REAL TIME APPLY
C) .Data guard事件---v$dataguard_status
该视图显示那些被自动触发写入alert.log或服务器trace文件的事件。通常是在你不便访问到服务器查询alert.log时，可以临时访问本视图查看一些与dataguard相关的信息，例如：
SQL> select message from v$dataguard_status;
MESSAGE
----------------------------------------------------------------------------
ARC0: Archival started
ARC1: Archival started
ARC0: Becoming the 'no FAL' ARCH
ARC0: Becoming the 'no SRL' ARCH
ARC1: Becoming the heartbeat ARCH
Attempt to start background Managed Standby Recovery process
MRP0: Background Managed Standby Recovery process started
Managed Standby Recovery not using Real Time Apply
Media Recovery Waiting for thread 1 sequence 761
调整物理standby log应用频率
调整应用频率说白了就是调整io读取能力，所以通常我们可以从以下几个方面 着 手：
1、 设置recover并行度
在介质恢复或redo应用期间，都需要读取重做日志文件，默认都是串行恢复，我们可以在执行recover的时候加上parallel子句来指定并行度，提高读取和应用的性能，例如：
SQL> alter database recover managed standby database parallel 2 disconnect from session;
推荐parallel的值是#CPUs*2;
2、 加快redo应用频繁
设置初始化参数DB_BLOCK_CHECKING=FALSE能够提高2倍左右的应用效率，该参数是验证数据块是否有效，对于standby禁止验证基本上还是可以接受的，另外还有一个关联初始化参数DB_BLOCK_CHECKSUM，建议该参数在primary和standby都设置为true。
3、 设置PARALLEL_EXECUTION_MESSAGE_SIZE
如果打开了并行恢复，适当提高初始化参数：PARALLEL_EXECUTION_MESSAGE_SIZE 的参数值，比如 4096 也 能提高大概20%左右的性能，不过需要注意增大这个参数的参数值可能会占用更多内存。
4、 优化磁盘I/O
在恢复期间最大瓶颈就是I/O读写，要缓解这个瓶颈，使用本地异步I/O并设置初始化参数DISK_ASYNCH_IO=TRUE会有所帮助。DISK_ASYNCH_IO参数控制到数据文件的磁盘I/O是否异步。某些情况下异步I/O 能降低数据库文件并行读取，提高整个恢复时间。
扫一扫
2271
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
