oracle data guard --理论知识回顾02

继上一篇

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

posted @ 2019-06-26 17:24 春困秋乏夏打盹阅读(313) 评论(0) 编辑收藏举报

刷新页面返回顶部

春困秋乏夏打盹

oracle data guard --理论知识回顾02

公告