原理:
通常,还原所用的时间应与备份所用的时间大致相同,甚至更长。因此,如果您的备份需要 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)
阅读(6823) | 评论(0) | 转发(0) |