继上一篇
管理影响物理standby的事件
1 创建表空间或数据文件
初始化参数standby_file_management用来控制是否自动将primary数据库增加表空间或数据文件的改动，传播到standby服务器AUTO/MANUAL
AUTO:自动传播到standby
MANUAL:需要手动复制文件到standby，并更新控制文件
SQL> set sqlprompt "primary>"
primary>show parameter standby_file
NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------
standby_file_management string AUTO
--select * from v$parameter where name like 'standby%';
2 删除表空间
--对于表空间和数据文件的操作，STANDBY_FILE_MANAGEMENT=AUTO，无须手工干预
3 重命名数据文件
--需要手工干预，STANDBY_FILE_MANAGEMENT=AUTO/MANUAL
在主库rename datafile文件，从库需要手动操作
主库
alter tablespace new_dg2 offline;
mv /u01/app/oracle/oradata/hongquan/hongquantest/new_dg2.dbf /u01/app/oracle/oradata/hongquan/hongquantest/new_dg2_test.dbf
alter tablespace new_dg2 rename datafile
'/u01/app/oracle/oradata/hongquan/hongquantest/new_dg2.dbf' to
'/u01/app/oracle/oradata/hongquan/hongquantest/new_dg2_test.dbf';
alter tablespace new_dg2 online;
alter system switch logfile;
select name from v$datafile;
备库
alter database recover managed standby database cancel;
mv /u02/app/oracle/oradata/hongquan1/hongquantest/new_dg2.dbf /u02/app/oracle/oradata/hongquan1/hongquantest/new_dg2_test.dbf
alter database recover managed standby database disconnect from session;
select name from v$datafile;
4 添加或删除redologs文件
--需要手工干预改文件的删除和创建
无论主库端对日志组或日志文件的操作是否传播到了standby端，也不会影响到standby的运行。
在主库增加或删除redo logs时，一定记得手工同步相关物理standby中的相关设置，保证standby log比primary redolog多一组操作要将STANDBY_FILE_MANAGEMENT=MANUAL
保证standby redologs比online redologs多一组
5垮open_resetlogs的应用
在某些情况下，主库以resetlogs打开数据库，也不会影响dg的配置，standby数据库不需要人工参与，自动应用open resetlogs的操作。
并非所有条件下有这样，在alter database open resetlogs之后，数据库的INCARNATION被重置，此时其standby数据库的
sequence序号也会从头开始，物理standby数据库不需要关注。
在不完全恢复情况下
监控primary 和物理standby
###带有enable|disable thread子句的alter database命令
V$THREAD --This view contains thread information from the control file.
###当前数据库角色，保护模式，保护级别，switchover 状态，failover快速启动信息等
select * from v$database;
--LOG_MODE,CONTROLFILE_TYPE,OPEN_MODE,PROTECTION_MODE,DATABASE_ROLE,SWITCHOVER_STATUS,FORCE_LOGGING,FLASHBACK_ON,DB_UNIQUE_NAME
--controlfile_type=CURRENT/STANDBY
--PROTECTION_MODE=MAXIMUM PROTECTION/MAXIMUM AVAILABILITY/RESYNCHRONIZATION/MAXIMUM PERFORMANCE/UNPROTECTED
--DATABASE_ROLE=LOGICAL STANDBY/PHYSICAL STANDBY/PRIMARY
--DATAGUARD_BROKER=ENABLED/DISABLED
###redo log 切换
V$LOG/V$LOGFILE
###重建控制文件,手工执行恢复
alert.log
SQL> select * from v$diag_info;
/u01/app/oracle/diag/rdbms/orcl/orcl/trace
###表空间状态修改(read write/read only,online/offline)
select * from dba_tablespaces;
###创建删除表空间或数据文件
select * from dba_data_files;
###表空间或数据文件offline
select * from dba_tablespaces;
select * from v$recover_file; --This view displays the status of files needing media recovery
###重命名数据文件
select * from v$datafile;
###未被日志记录或不可恢复的操作
select * from v$datafile;
select * from v$database;
###恢复的进程
select * from v$archive_dest_status; --主库
select * from v$archived_log;
select * from v$log_history;
select * from v$managed_standby;
###redo传输的状态和进度
select * from v$archive_dest_status; --主库
select * from v$archive_dest; --主库
select * from v$archived_log; --主库
select * from v$archived_log;
###数据文件自动扩展
/u01/app/oracle/diag/rdbms/orcl/orcl/trace
###执行open resetlogs或clear unarchived logfiles，修改初始化参数
/u01/app/oracle/diag/rdbms/orcl/orcl/trace
监控恢复进度
1 查看进程的活动状态
standby > select process,client_process,sequence#,status from v$managed_standby;
ARCH ARCH 1846 CLOSING
ARCH ARCH 0 CONNECTED
MRP0 N/A 1847 APPLYING_LOG
RFS UNKNOWN 0 IDLE
RFS UNKNOWN 0 IDLE
RFS LGWR 1847 IDLE
RFS UNKNOWN 0 IDLE
--
PROCESS:进程名称，如ARCH\RFS\MRP0等
CLIENT_P:对应的primary数据库中的进程，如ARCH\LGWR等
SEQUENCE#:归档序号
STATUS:进程的当前状态，常见的有：
ALLOCATED:整准备连接primary库
ATTACHED:正在连接primary库
CONNECTED:已连接到primary库
IDLE:空闲中
RECEIVING:归档文件接收中
OPENING:归档文件处理中
CLOSING:归档文件处理完，收尾中
WRITING:REDO数据库写想归档文件中
WAIT_FOR_LOG:等待新的redo数据中
WAIT_FOR_GAP:归档有中断，正等待中断的那部分redo数据
APPLYING_LOG:应用redo数据中
数据库开了1个归档进程，使用ARCH同步传输方式与物理standby通信，已经接收并收尾处理1846号日志，正在应用1847号日志
2 检查redo应用进度
standby > select dest_name,archived_thread#,archived_seq#,applied_thread#,applied_seq#,db_unique_name,destination from v$archive_dest_status where status='VALID';
LOG_ARCHIVE_DEST_1 1 1846 0 0 cadbk C:\app\Administrator\fast_recovery_area\cadbk\ARCHIVELOG
LOG_ARCHIVE_DEST_2 0 0 0 0 CAD cad_192.168.19.97
STANDBY_ARCHIVE_DEST 1 1846 1 1846 NONE C:\app\Administrator\fast_recovery_area\cadbk\ARCHIVELOG
3 检查归档文件路径和创建信息
standby > select name,creator,sequence#,applied,completion_time from v$archived_log;
C:\APP\ADMINISTRATOR\FAST_RECOVERY_AREA\CADBK\ARCHIVELOG\1_1845_976879612.ARCH ARCH 1845 YES 2019/6/26 6:04:33
C:\APP\ADMINISTRATOR\FAST_RECOVERY_AREA\CADBK\ARCHIVELOG\1_1846_976879612.ARCH ARCH 1846 IN-MEMORY 2019/6/26 8:17:32
4 查询归档历史
standby > select first_time,first_change#,next_change#,sequence# from v$log_history;
--查询到最后应用的归档文件
standby > select thread#,max(sequence#) as "last_applied_log" from v$log_history group by thread#;
thread# last_applied_log
1 1846
--也可以通过v$archived_log中的app列表获得相同的功能
standby > select thread#,sequence#,applied from v$archived_log;
1 1844 YES
1 1845 YES
1 1846 IN-MEMORY
5 查看物理standby数据库未接收的日志文件
在primary端获取，日志文件的发送是通过log_archive_dest_n参数来控制，因此只需要对比本地生成的归档和远端生成的归档的差异即可
primary > select local.thread#,local.sequence# from
(select thread#,sequence# from v$archived_log where dest_id=1) local
where local.sequence# not in
(select sequence# from v$archived_log where dest_id=2 and thread#=local.thread#);
监控日志应用服务
1 查询当前数据库的基本信息
standby > select database_role,db_unique_name,open_mode,protection_mode,protection_level,
switchover_status from v$database;
PHYSICAL STANDBY cadbk READ ONLY WITH APPLY MAXIMUM PERFORMANCE MAXIMUM PERFORMANCE NOT ALLOWED
--查询failover后快速启动的信息
standby > select fs_failover_status,fs_failover_current_target,fs_failover_threshold,
fs_failover_observer_present from v$database;
2 查询当前redo应用和redo传输服务的活动状态
standby > select process,status,thread#,sequence#,block#,blocks from v$managed_standby;
ARCH CLOSING 1 1846 90112 347
ARCH CONNECTED 0 0 0 0
MRP0 APPLYING_LOG 1 1848 1156 102400
RFS IDLE 0 0 0 0
RFS IDLE 0 0 0 0
RFS IDLE 1 1848 1157 2
3 检查应用模式（是否启用了实时应用）
standby > select recovery_mode from v$archive_dest_status where dest_id=1;
MANAGED REAL TIME APPLY ##打开了实时应用
4 data guard事件(v$dataguard_status)
该视图显示那些被自动触发写入alert.log或服务器trace文件的事件
standby > select message from v$dataguard_status;
Media Recovery Waiting for thread 1 sequence 1847 (in transit)
ARC0: Beginning to archive thread 1 sequence 1847 (40070728-40088719)
Media Recovery Waiting for thread 1 sequence 1848 (in transit)
ARC0: Completed archiving thread 1 sequence 1847 (0-0)
调整物理standby端redo数据应用频率
--调整I/O读取能力
-设置recover并行度
在介质恢复或redo应用期间，都需要读取redo log，默认是串行恢复，可以在recover的时候加上parallel来指定并行度。
standby > recover standby database parallel 2;
##建议parallel的值为#cpus*2
注意：该值设置仅对当前环境有效，oracle数据库重启之后，默认情况下并行度会恢复到初始值，
如果dba每次执行很麻烦，要通过初始化参数parallel_max_servers来设置默认的并行度
-加快redo应用频率
设置初始化参数db_block_checking=false能够提高2倍左右的应用效率，该参数设置是否验证数据块的有效性，
对于物理standby数据块，禁止验证基本上开始可以接受（paiarmy数据块强力建议该值为true，默认就是true），
动态参数，修改直接生效，不需要重启数据库
-设置parallel_execution_message_size
如果打开了并行恢复，适当提高初始化参数，比如4096也能提高大概20%左右的性能，增大这个参数可能会占更多内存
-优化磁盘I/O
在恢复期间最大的瓶颈就是I/O读写，要缓解这个瓶颈，使用本地异步I/O并设置初始化参数disk_asynch_io=true会有所
帮助，disk_asynch_io控制数据文件的磁盘I/O是否异步，某些情况下异步I/O能降低数据库文件并行读取，提高整个恢复时间。