继上一篇
管理影响物理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能降低数据库文件并行读取，提高整个恢复时间。