rman 监控及恢复时的坏块

原理：
通常，还原所用的时间应与备份所用的时间大致相同，甚至更长。因此，如果您的备份需要 10 个小时才能完成，那么恢复到同一主机至少需要 10 个小时。

另一个好的指标是确定您之前的还原/恢复操作的持续时间。

监控日志和视图并观察变化率。还原和恢复操作非常耗费资源，因此了解进程是在工作还是挂起很重要。

从哪里看rman恢复进度呢？Oracle提供了丰富的方式

1. RMAN 日志
默认情况下，RMAN 操作的结果写入标准输出。没有默认的日志文件。您需要使用 SPOOL TRACE 选项捕获结果，或者将标准输出重定向到文件。

从上面我们可以看到：
[1] 恢复开始的日期和时间
[2] v$session 中的数据库会话 ID - 143
[3] 文件将被恢复到的数据文件编号和名称
[4] 备份文件名称和标记
[5] 恢复此数据文件所用的时间，以及使用的通道
[6] 恢复完成的日期和时间

恢复会话输出信息解读


[1] 归档日志恢复到默认归档目的地。在恢复之前，您必须确保有可用空间来恢复这些归档日志
[2] 如果归档日志不在磁盘上，则会从备份中恢复它们
[3] 一旦恢复完成 RMAN 将自动从磁盘中删除它们
[4] 恢复此数据文件所用的时间
[5] 恢复完成的日期和时间


2. 告警日志
只有 RMAN restore 会写入 alert.log。用户管理的 restore 会话不会出现在 alert.log 中，因为它们是在 Oracle 之外执行的。

如果您在 RMAN RESTORE 操作期间在 alert.log 中看到损坏错误（吓人不？），请不要惊慌。在恢复数据文件之前，RMAN 将检查它的存在和有效性。如果文件已经在磁盘上但无效或损坏，oracle会报告它。例如，在Sun Sep 27 08:25:54 2015，我们看到数据文件 1043 被报告损坏：
稍后我们看到文件从有效备份中恢复，并且此数据文件上没有报告进一步的损坏：

所有 recover 会话，无论是用户管理的还是 RMAN 的，也将写入 alert.log。这是 RMAN 恢复会话的示例：

[1] 这实际上是一个压缩的备份。此信息仅显示在 alert.log 而不是 RMAN 还原日志中
[2] 还原存档日志所花费的时间
[3] ORA-279 是信息性的 - 确认恢复所需的存档日志
[4] 以进行完全恢复，Oracle 将还需要从在线日志中应用重做
[5] 结束恢复

3. 用户管理的恢复日志
[1] 使数据文件脱机以准备从用户管理的备份中恢复
[2] 从用户管理的备份中恢复数据文件后，将其恢复
[3] 恢复此文件所需的第一个归档日志
[4] 我们按下了 ENTER 键，因此要求 Oracle 应用请求的日志
[5] 如果要应用的归档日志很多并且它们都在归档目录中，请使用 Oracle 的 AUTO 选项来应用其余所需的归档日志。否则，您将需要手动指定请求的每个存档日志，或在提示输入每个存档日志时按 ENTER
[6] 恢复现已完成
[7] 将数据文件置于联机状态，从而使其再次可用

4. 操作系统命令
正在恢复的文件的大小应该增加，直到其实际大小。随着 Oracle 更新文件，时间戳也应该发生变化。使用诸如“ls -lt”之类的操作系统实用程序来查看此信息。
您还可以使用操作系统实用程序（例如 vmstat、sar 和 iostat）来监控资源利用率。硬件是否满负荷工作？瓶颈在哪里？主机上是否有其他 I/O 密集型操作发生？或者通过osw、nmon。

如果文件正在恢复到 ASM，您还应该能够检查它在 ASM 中的存在。但请注意，您可能只有在完全恢复后才能在 ASM 中看到它（文件系统中会先分配出空间再写入）。

5. 数据字典或视图

所有 RMAN 操作都将有一个相应的数据库会话。因此，您可以查询数据字典以检查其进度。

-- RMAN 会话

set linesize 100 trimspool on

COLUMN sid FORMAT 9999
COLUMN serial#  ALIAS SER# FORMAT 99999
COLUMN spid FORMAT 9999
COLUMN username FORMAT a10
COLUMN status FORMAT a2
COLUMN program FORMAT a32
COLUMN logon_time form a15
COLUMN module form a30
COLUMN action form a35
COLUMN process form a14

SELECT
       s.sid ,
       s.serial# "ser#",
       s.username,
       to_char(s.logon_time,'DD-MM-RR hh24:mi') logon_time,
       s.osuser,
       s.process,
       p.spid ,
       s.machine,
       substr(s.status,1,1) status,
       s.program
FROM v$session s, v$process p
WHERE upper(s.program) like '%RMAN%'
AND s.paddr = p.addr (+)
ORDER by s.logon_time, s.sid
/

间隔5分钟执行1次：

-- 完成百分比
set echo on feedback on
column path format a50
set header off
select sl.sofar, sl.totalwork,
       round(sl.sofar/sl.totalwork*100,2) "% Complete"
from v$session_longops sl, v$session s, v$process p
where p.addr = s.paddr
and sl.sid=s.sid
and sl.serial#=s.serial#
and opname LIKE 'RMAN%'
and opname NOT LIKE '%aggregate%'
and totalwork != 0
and sofar <> totalwork;

看进展有何变化。

--会话等待
set linesize 200 trimspool on

col event form a25
col p1text form a15
col p1 form 999999
col p2text form a15
col p2 form 999999
col p3text form a10
col p3 form 9999
col waited form 9999
col waiting form 9999

select sid, event, p1text, p1, p2text, p2, p3text, p3,
wait_time waited, seconds_in_wait waiting
from gv$session_wait
where event not like 'SQL*Net%'
and event not like '%timer%'
and event not like 'rdbms%'
and event not like 'pipe%'
and event not like 'DIAG%'
and event not like 'Streams AQ%'
and event not like 'VKTM%'
and state = 'WAITING'
order by seconds_in_wait
/

recover 进展如何？V$RECOVERY_PROGRESS 仅在 RECOVERY 正在进行时填充。restore 操作不会填充此视图。因此，如果您认为恢复过程很慢——它真的处于恢复阶段，还是仍在从 RMAN 备份恢复？

select START_TIME,TYPE,ITEM,UNITS,SOFAR,TOTAL from v$recovery_progress;

影响恢复性能的因素
1) 参数PARALLEL_EXECUTION_MESSAGE_SIZE
这个参数的默认值可能不够大，因此考虑增加到它的最大操作系统相关值

SQL> show parameter PARALLEL_EXECUTION_MESSAGE_SIZE
SQL> alter system set parallel_execution_message_size=65535 scope=spfile;

重启生效。
2）硬件级别的本机 I/O 速率
3）恢复并行度

SQL> RECOVER datafile x,y,z parallel (degree 32);
OR
SQL> recover parallel 32;

4）如果在上述调整后，重做应用率仍然不可接受，那么您可以暂时将 db_block_checking 设置为 false 以尝试提高恢复性能。


参考：
监控恢复/恢复进度（文档 ID 1335910.1）