管理日志传输服务
==================================
1.检查日志传输服务
SQL> select thread#,instance_name from gv$instance; --检查实例名称对应的线程号
SQL> select thread#,dest_id,max(sequence#) --查询每个实例所有目的地生成的日志的最大序列号
from v$archived_log
group by thread#,dest_id
order by thread#;
（注：dest_id等于1对应初始化参数配置中的log_archive_dest_1，表示本地归档目的地；等于2对应初始化参数配置中的
log_archive_dest_2，表示远程Standby数据库目的地）
测试例子：
SQL> alter system archive log current;
SQL> r
SQL> select thread#,dest_id,max(sequence#)
from v$archived_log
group by thread#,dest_id
order by thread#;
（注：RAC所有实例的日志成功归档到所有目的地，证明RAC的日志传送服务工作正常）
问题排查：
SQL> select error from v$archive_dest_status;
（注：如果日志传输服务没有正常工作，可以通过此表查看原因）
2.查看Standby数据库Standby Redo日志的使用情况
说明：在日志的实时传输过程中，需要使用到Standby数据库的Standby Redo日志。
SQL> select thread#,sequence#,archived,status from v$standby_log; --stnadby数据库端执行
SQL> select thread#,sequence#,status from v$log; --主数据库端执行
（注：如果主数据库的current联机Redo日志与Standby数据库的active状态的Standby Redo日志序列号相同，证明启用了实时传输）
3.监控日志传输性能
a.在Redo源数据库执行以下SQL语句显示目的地2的响应时间柱状图
SQL> select frequency,duration
from v$redo_dest_resp_histogram
where dest_id = 2
and frequency > 1
（注：可以看出响应时间为xx秒的命中率为xx秒）
b.在Redo源数据库执行以下SQL语句显示目的地2的最慢响应时间
SQL> select max(duration)
from v$redo_dest_resp_histogram
where dest_id = 2
and frequency > 1;
c.在Redo源数据库执行以下SQL语句显示目的地2的最快响应时间
SQL> select min(duration)
from v$redo_dest_resp_histogram
where dest_id = 2
and frequency > 1;
4.自动发现和解决日志缺失
当Redo传送恢复时，Redo传输服务可自动察觉Redo缺失，以下为减少Redo缺失解决时间的方式：
a.Redo传输压缩
使用LOG_ARCHIVE_DEST_n参数的COMPRESSION属性，明确在传输到目的地之前压缩Redo数据
b.并行Redo传输网络会话
使用LOG_ARCHIVE_DEST_n参数的MAX_CONNECTIONS属性，明确创建更多的会话用于发送Redo，解决Redo缺失
5.手动解决日志缺失
1）物理Standby数据库日志缺失
SQL> select * from v$archive_gap; --在物理Standby数据库执行
SQL> select name --在主数据库执行
from v$archive_log
where thread# = 1
and dest_id = 1
and sequence# >= 7 and sequence# <= 10;
拷贝日志到物理Standby数据库，并在物理Standby数据库执行：
SQL> alter database register logfile '/physical_standby/thread1_dest/arcr_1_7.arc';
SQL> alter database register logfile '/physical_standby/thread1_dest/arcr_1_8.arc';
SQL> alter database register logfile '/physical_standby/thread1_dest/arcr_1_9.arc';
SQL> alter database register logfile '/physical_standby/thread1_dest/arcr_1_10.arc';
2)逻辑Standby数据库日志缺失
SQL> select thread#,sequence#,file_name --在逻辑Standby数据库执行
from dba_logstdby_log L
where next_change# not in
(select first_change# from dba_logstdby_log where L.thread# = thread#)
order by thread#,sequence#;
拷贝日志到逻辑Standby数据库，并在逻辑Standby数据库执行：
SQL> alter database register logical logfile '/disk1/oracle/dba/log-129880008_7.arc';
SQL> alter database register logical logfile '/disk1/oracle/dba/log-129880008_8.arc';
SQL> alter database register logical logfile '/disk1/oracle/dba/log-129880008_9.arc';
SQL> alter database register logical logfile '/disk1/oracle/dba/log-129880008_10.arc';
6.Redo传输服务等待事件
等待事件 描述
LNS wait on ATTACH 创建连接到所有ASYNC和SYNC Redo传输目的地的Redo传输会话话费的总时间
LNS wait on SENDREQ Redo数据被写到所有ASYNC和SYNC传输目的地话费的总时间
LNS wait on DETACH 终止连接到所有ASYNC和SYNC Redo传输目的地的传输Redo数据话费的总时间
==================================
监控/管理日志应用服务
==================================
1.检查告警日志
Fri Sep 21 00:42:36 2012
alter database recover managed standby database disconnect
Attempt to start background Managed Standby Recovery process (racdg)
Fri Sep 21 00:42:36 2012
MRP0 started with pid=24, OS id=4536
MRP0: Background Managed Standby Recovery process started (racdg)
started logmerger process
Fri Sep 21 00:42:41 2012
Managed Standby Recovery not using Real Time Apply
Parallel Media Recovery started with 8 slaves
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
2.查询数据字典
SQL> select process,status,thread#,sequence#,block#,blocks --在Standby数据库执行
from v$managed_standby where process!='ARCH';
（注：MRP0为介质恢复进程）
3.启动Redo Apply
SQL> alter database recover managed standby database; --在前台启动Redo Apply
（注：如果开始一个前台会话，控制权不会返回到命令提示符）
SQL> alter database recover managed standby database disconnect from session; --在后台启动Redo Apply
（注：以上语句开始一个单独的服务器进程，立即返回控制权给用户。当恢复进程在后台运行时，执行RECOVER语句的窗口能继续执行其它工作
disconnect from session选项表示Redo Apply在后台会话中进行，以上两种方式都只会在发生日志切换的时候才应用日志）
SQL> alter database recover managed standby database using current logfile; --在前台启动实时应用
（注：using current logfile子句，表示Redo在接收到的时候就应用）
SQL> alter database recover managed standby database using current logfile disconnect from session; --在后台启动Redo实时应用
4.停止Redo Apply
SQL> alter database recover managed standby database cancel;
==================================
修改Data Guard保护模式
==================================
1.验证参数配置
不同保护模式对应LOG_ARCHIVE_DEST_n参数的配置要求
最高可用性 最大性能 最大保护
AFFIRM NOAFFIRM AFFIRM
SYNC ASYNC SYNC
DB_UNIQUE_NAME DB_UNIQUE_NAME DB_UNIQUE_NAME
2.设置数据保护模式
启动主数据库在MOUNT模式，如果是RAC数据库，关闭所有的节点，只启动一个节点在MOUNT模式
SQL> alter database set standby database to maximize {availability|performance|protection}; --在主数据库修改
SQL> alter database open;
最后打开RAC的其它节点的实例
3.查看数据库保护模式
SQL> select protection_mode,protection_level from v$database; --在主数据库执行查看主数据库的保护模式
SQL> select dest_id,database_mode,recovery_mode,protection_mode --在主数据库执行查看目的地的数据库模式
from v$archive_dest_status
where dest_id = 2;
==================================
快照Standby数据库
==================================
1.将物理Standby数据库转换为快照Standby数据库
步骤1： 停止物理Standby数据库的Redo Apply
步骤2： 如果物理Standby数据库是RAC，关闭所有实例，只保留一个实例
步骤3： 确保Standby数据库在MOUNT模式，且没有被打开
步骤4： 确保闪回恢复区被配置
步骤5： 执行以下命令将物理Standby数据库转换为快照Standby数据库：
SQL> alter database convert to snapshot standby;
2.将快照Standby数据库转换为物理Standby数据库
步骤1： 如果Standby数据库是RAC，关闭所有实例只保留其中一个实例
步骤2： 确保数据库在MOUNT模式，但是没有打开
步骤3： 执行以下命令将快照Standby数据库转换为物理Standby数据库
SQL> alter database convert to physical standby;
（注：转换之后数据库被卸载，必须重启。当Redo Apply开始启用时，快照Standby数据库接收到的Redo数据将自动被应用）
==================================
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/29339097/viewspace-1064842/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/29339097/viewspace-1064842/
361
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
