ANA日本全日空航空公司Oracle 4节点RAC集群性能问题所引发的航空系统故障

 

 

ANA全日空是日本最大的航空公司,亦是世界上少有的五星级航空公司之一。全日空的主要机场位于成田国际机场、东京国际机场、关西国际机场及大坂国际机场。

 

ana01

 

在3月22日上午8:20开始由于系统故障,羽田、大阪以及福冈等地区的机场出现日本国内航线无法办理登机手续的问题。由此,一部分航线被迫取消,大量航班延误。

 

 3月30日、ANAホールディングス(ANAHD)傘下の全日本空輸は30日、22日に発生したシステム不具合を踏まえ、30日付で役員の報酬減額処分を実施したと発表した。全日空の篠辺修社長を1カ月20%、内薗幸一副社長と幸重孝典執行役員を10%の減額とした。写真は都内で2013年1月撮影(2016年 ロイター/Toru Hanai)

 

在ANA的记者会上已经发布了相关事故原因。因为全日本航空的系统故障,导致了刚刚结束节假日连休的机场陷入了混乱状态。

在当日上午11点半左右,系统修复完成。然后办理搭乘手续的业务也终于得以恢复。对此,全日空航空公司表示:“非常抱歉,给大家添麻烦了。”

根据全日本航空给出的数据,受到系统故障影响,羽田机场的航线总计取消116条航班。大约对一万五千人造成影响。

 

QQ截图20160406135309

 

全日空在上个月24号也同样出现了类似的问题,导致全国的机场约30分钟无法办理搭乘手续。

 

具消息人士指出本次的故障是由于对控制4节点RAC的SLB负载均衡器做了不恰当的操作所致。而并非有网友指出的是ORACLE RAC心跳网络的交换器出现了故障而出现了ORA-29740错误。

 

有日本本土的消息人士指出此次故障时由于ANA的核心业务系统,一个4节点的ORACLE RAC中;由于对控制4节点RAC的SLB负载均衡器做了不恰当的操作所致,导致其中一个节点出现严重的性能问题。运维工程师在接到系统告警和投诉后进入了慌乱状态,按照既定的故障诊断手册来修复也完全修复不好。于是到处打电话问对应方法,得到的回答也都与手册相同。

 

对于Oracle数据库你是否有这样一本故障诊断手册? 还没有?

下载 《ORACLE DB数据库常见问题解决及诊断技巧集锦-ORACLE DBA故障修复必备手册》: http://t.cn/Rq4BzBY

 

日本本土的网友对此次全日空的系统故障吐槽说:

 

这时,像我这样的系统工程师都会发出这样的感叹:”哎呀,出现这样的故障的话,现场估计乱得不得了吧?“(我想现场如今就像祭典一样,,系统工程师们要三天不眠不休进行修复工作。而且就算完成了修复,之后还有一系列的工作……)

实际上,比起影响,我更在意幕后的一些隐情。这时说起来可能有点不太准确,但我想,如今在系统故障现场还是一派繁忙景象吧。系统工程师倒是要多少有多少,但我想还没有哪个项目能像这次大故障一样如此繁忙吧。(受到此次影响的客人们也感到非常麻烦吧。)

现场状况用”祭典盛景“来形容是最好不过了。控制中心聚集了大量人员,几乎动员了公司内部所有战斗力量。再没哪次故障能汇集这么多人才了。(在此进行一系列会议,大家在白板上激烈讨论了故障过程、原因、以及修复对策。)

以往办公室都是比较安静的,但故障时,却是一片异样的繁忙盛景。经历过一次故障,系统工程师的能力可以连升很多级。由于大家目标一致,努力奋进于是就出现了这样的景象。(虽然善后要更加令人头疼……)

由此,这次的主题就是介绍系统工程师现场会遭遇的各种情况。

 

是否是系统供应商的人为失误!?

 

这次4台服务器同时终止的原因可能就是因为人为错误。

无论是硬件或者软件出现问题都不可能造成如此的故障。果然原因只可能是人为失误。报导中提到,“控制四台服务器的设备出现了故障”,可能还误操作了负载均衡器SLB。

果然无论最后是操作系统还是终止系统,最终还是人为使然。

无论对设备以及软件进行怎样的优化,也会由于人的使用方法以及使用顺序错误导致出错。并且,无论如何都需要定期维护,维护的同时也经常伴随着误操作的危险。当然,接触到系统的工作也都有一定的操作顺序,因为都会对其进行反复检查,所以基本不会有问题,但并不是不可能发生。

只要基于人来操作的话,无论如何都是会发生错误的。如果这样的失误重复多次,就会导致如这次一样的大规模的故障。

并不是我反复强调,而是系统的确是无法避免地会出现故障。

当然,我们每天也在为了不再出现这样的情况而努力着,但仅凭现在的技术水平来说,还是必须要人工操作的,所以还是必然会有类似故障发生。

我希望大家能够理解,不理解现状,却一味地抨击系统工程师“不像话”的无知评论家以及无良媒体是多么可恶。我对媒体和评论家这些人一提到就开始批判的态度也是实在没有办法,想说什么就说什么,明明自己没有一点点相关知识。

即使修复了系统故障也不会就此终止

我认为,作为全日本航空的系统供应商应该会非常头疼,希望他们好好努力啊。因为即使修复了故障,之后的善后工作也非常麻烦。

修复了基础层的系统后,应用团队就登场了。由于系统故障,需要确认的问题实在太多了:数据状态如何?现有数据是否完好?是否可以继续进行业务?等等等等。

估计至少得通宵达旦2-3天吧。之前提到过的不可思议的祭典状态还将持续。不仅是修复工作最集中的时候,其他时候系统工程师也必须时刻保持昂扬的战斗状态。

之后,就需要检讨这次故障的对策以及开始道歉了。

虽然我们都认为系统故障是不应该发生的,但还是希望大家能够理解,系统是不可能永远不发生故障的。希望大家做的不仅仅是谴责,也不要认为系统正常运行是理所当然的。但这次的故障影响波及范围实在太广泛了,这也是我们必须反省的。

 

 

PRM-DUL终极Oracle数据库恢复工具

PRM-DUL 下载地址:http://zcdn.parnassusdata.com/DUL5108.zip

诗檀软件自主开发的PRM-DUL可以脱离Oracle数据库软件实例的存在直接读取Oracle数据文件datafile中的行数据和LOB等大对象。

当你的数据库因为ORA-00600/ORA-07445或其他ORA-报错,或丢失关键的system表空间数据文件,或ASM diskgroup损坏时均可以考虑采用PRM-DUL来做恢复。PRM-DUL采用独创的DataBridge恢复技术,直接从数据文件中抽取数据后可以像DBLINK那样直接插入到新建数据库中,而无需数据落地成为DMP文件占用空间。

经过诗檀软件4年的研发改进,PRM-DUL的功能已经十分完善,且因为其采用全称GUI图形化界面的方式,对用户而言学习成本非常低,可以说从头到尾只需要点鼠标即可。支持从Oracle 7.3.4到Oracle 12c的所有版本数据库。

到目前为止已经有多大十多个国外企业级别用户购买PRM-DUL 作为其终极恢复工具,所恢复的数据超过100TB。同时也有单库超过10TB的使用例子,这得益于PRM-DUL 内置了小型嵌入式数据库,当索要恢复的ORACLE数据库很大时,PRM-DUL采用嵌入的数据库来存放找到的ORACLE 源数据,这样可以对源数据做索引和灵活的查询。

PRM-DUL软件由诗檀软件自主研发,研发团队自行研究了Oracle datafile的数据结构同时也参考了ORACLE RDBMS数据库软件的内核代码,研发团队具有基于Oracle Kernel内核代码二次开发的技术能力。

欢迎技术合作!

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 : 13764045638 QQ号:47079569 邮箱:service@parnassusdata.com.

 

Oracle DUL_PRM_重建对象实验报告

PRM-DUL抽数据

 

也是就只导入EASKINGDEE用户下,以”T_GL”开头的表:

有70张表被导入,但是其中也就28个表有数据,各个有数据的表的行数和dul的结果是一样的。

 

prmz21

 

SQL> exec

dbms_stats.GATHER_SCHEMA_STATS(OWNNAME=>’test4′);

select table_name,num_rows from user_tables order by num_rows desc;

结果如下:

prmz22

 

4.2 重建database link

 

SELECT ‘create ‘||DECODE(U.NAME,’PUBLIC’,’public ‘)||’database link ‘||CHR(10)

||DECODE(U.NAME,’PUBLIC’,Null, U.NAME||’.’)|| L.NAME||chr(10)

||’connect to ‘ || L.USERID || ‘ identified by ‘

||L.PASSWORD||’ using ”’ || L.host || ””

||chr(10)||’;’ TEXT

FROM link$ L, user$ U

WHERE L.OWNER# = U.USER#;

没有返回行,说明没有database link

4.3 重建synonym

 

SELECT ‘create or replace ‘ || decode(o.owner#, 1, ‘ public ‘) ||

‘ synonym ‘ || decode(o.owner#, 1, ”, u.name || ‘.’) || o.name ||

‘ for ‘ || s.owner || ‘.’ || s.name|| NVL2(S.NODE,’@’,”)||S.NODE|| ‘;’

FROM SYN$ S, OBj$ o, USER$ U

where s.obj# = o.obj#

AND o.dataobj# is null

and s.owner=upper(‘EASKINGDEE’)   and u.user# = o.owner#

没有返回行,说明没有synonym

4.4 重建 view

 

select

‘CREATE OR REPLACE VIEW ‘||O.NAME||’ (‘||

replace(c.cols,’,’,’,’||chr(10))||’)’||CHR(10)||

‘as’||chr(10), v.text

from

user$ u, obj$ o, view$ v,

( SELECT COL.OBJ#, COL.COLS

FROM

(SELECT

OBJ#, COL#, substr(SYS_CONNECT_BY_PATH(NAME,’,’),2) COLS

FROM COL$

WHERE COL# > 0

START WITH COL# = 1

CONNECT BY PRIOR OBJ# = OBJ# AND PRIOR COL# = COL# – 1 ) COL,

(SELECT OBJ#, COUNT(*) COLCNT FROM COL$

WHERE COL# > 0 GROUP BY OBJ#) CN

WHERE COL.OBJ# = CN.OBJ# AND COL.COL# = CN.COLCNT

) C

where u.user#=o.owner# and o.obj# = c.obj#

and v.obj# = o.obj# and u.name=upper(‘EASKINGDEE’);

 

 

结果如下

prmz23

重建job

 

select job,LOWNER,INTERVAL#,next_date,WHAT,SCHEDULER_FLAGS from job$

prmz24

重建index

 

 

SELECT

‘CREATE ‘||decode(bitand(IDX.property, 1), 1, ‘UNIQUE’, ”)||

‘ INDEX ‘||I.NAME||’ ON ‘||T.NAME||'(‘||IDX.PATH||’);’ INDEX_DDL

FROM

USER$ U, OBJ$  T, OBJ$ I,

(

select I.PROPERTY, I.BO#, I.OBJ#, C.POS#,

SUBSTR(sys_connect_by_path(CN.NAME,’,’),2) path

from IND$ I, ICOL$ C, COL$ CN

WHERE I.OBJ# = C.OBJ# AND I.BO# = C.BO#

AND I.BO# = CN.OBJ# AND C.COL# = CN.INTCOL#

start with C.POS#=1

connect by nocycle PRIOR I.OBJ# = I.OBJ#

AND prior C.POS# = C.POS# ) IDX,

(SELECT I.BO#, I.OBJ#, COUNT(*) COLCNT

FROM ICOL$ I GROUP BY I.BO#, I.OBJ# )  IDXC

WHERE

U.USER# = T.OWNER# AND

IDX.BO# = T.OBJ# AND

IDX.OBJ# = I.OBJ# AND

IDX.BO# =  IDXC.BO# AND

IDX.OBJ# = IDXC.OBJ# AND

IDX.POS# = IDXC.COLCNT AND

u.name=upper(‘EASKINGDEE’)

ORDER BY T.NAME, I.NAME;

结果如下:

prmz25

重建trigger

 

select

‘CREATE OR REPLACE TRIGGER ‘|| trigger_name || chr(10)||

decode( substr( trigger_type, 1, 1 ),

‘A’, ‘AFTER ‘, ‘B’, ‘BEFORE ‘, ‘I’,

‘INSTEAD OF ‘ ) ||

triggering_event || ‘ ON ‘ || table_owner || ‘.’ ||

table_name || chr(10) || REF_CLAUSE || chr(10) ||

decode( instr( trigger_type, ‘EACH ROW’ ), 0, null,

‘FOR EACH ROW’), trigger_body

from  (

select trigusr.name owner, trigobj.name trigger_name,

decode(t.type#, 0, ‘BEFORE STATEMENT’,

1, ‘BEFORE EACH ROW’,  2, ‘AFTER STATEMENT’,

3, ‘AFTER EACH ROW’,    4, ‘INSTEAD OF’,

‘UNDEFINED’) trigger_type,

decode(t.insert$*100 + t.update$*10 + t.delete$,

100, ‘INSERT’, 010, ‘UPDATE’, 001, ‘DELETE’,

110, ‘INSERT OR UPDATE’, 101, ‘INSERT OR DELETE’,

011, ‘UPDATE OR DELETE’,

111, ‘INSERT OR UPDATE OR DELETE’,

‘ERROR’) triggering_event,

tabusr.name table_owner, tabobj.name table_name,

‘REFERENCING NEW AS ‘||t.refnewname||’ OLD AS ‘||t.refoldname REF_CLAUSE,

t.whenclause,decode(t.enabled, 0, ‘DISABLED’, 1, ‘ENABLED’, ‘ERROR’) STATUS,

t.definition , t.action# trigger_body

from obj$ trigobj, obj$ tabobj, trigger$ t,

user$ tabusr, user$ trigusr

where (trigobj.obj#  = t.obj# and

tabobj.obj#    = t.baseobject and

tabobj.owner#  = tabusr.user# and

trigobj.owner# = trigusr.user# and

bitand(t.property, 63)    < 8 ))

where table_owner=upper(‘EASKINGDEE’)

order by owner, trigger_name

 

没有返回行,表名在用户EASKINGDEE下的表上没有触发器

4.8 重建sequence

 

SELECT

‘CREATE SEQUENCE ‘|| SEQ_NAME ||

‘ MINVALUE ‘||minval ||

‘ MAXVALUE ‘||MAXVAL ||

‘ START WITH ‘||LASTVAL ||

‘ ‘ || CYC || ‘ ‘ || ORD ||

DECODE(SIGN(CACHE), 1,’ CACHE ‘|| CACHE, ‘NOCACHE’) ||

‘;’ SEQ_DDL

from

(select u.name OWNER, o.name SEQ_NAME,

s.minvalue MINVAL, s.maxvalue MAXVAL,

s.increment$ INC,

decode (s.cycle#, 0, ‘NOCYCLE’, 1, ‘CYCLE ‘) CYC,

decode (s.order$, 0, ‘NOORDER’, 1, ‘ORDER ‘) ORD,

s.cache, s.highwater LASTVAL

from seq$ s, obj$ o, user$ u

where u.user# = o.owner#

and o.obj# = s.obj#

and u.name=upper(‘EASKINGDEE’))

 

没有返回行,表名在用户EASKINGDEE下的表上没有序列

4.9 重建procedurce

 

SELECT DECODE(S.LINE,1,’CREATE OR REPLACE ‘ )||SOURCE SOURCE

FROM

USER$ U, OBJ$  O, SOURCE$ S

WHERE

U.USER# = O.OWNER# AND

O.OBJ# = S.OBJ# and U.NAME =’EASKINGDEE’

ORDER BY S.OBJ#, S.LINE;

结果如下:

prmz26

Hadoop HFTP 指导

本文固定链接:https://www.askmac.cn/archives/hadoop-hftp-guide.html

原文地址:http://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/Hftp.html

1介绍

 

HFTP 是hadoop文件系统用来让你从一个远程的hadoop HDFS集群中读取数据的组件。这个读取是通过HTTP,并且数据源是DataNodes。HFTP是一个只读的文件系统,当你试图用来写入数据或者修改文件系统状态时,会抛出异常。

[Read more…]

Hadoop HDFS 配额指导

本文固定链接:https://www.askmac.cn/archives/hadop-hdfs-quotas-guide.html

原文地址:http://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/HdfsQuotaAdminGuide.html

1概述

 

HDFS允许管理员为名称的数量进行配额限制,并且为单独的目录设置使用空间得大小。

命名限额和空间限额是独立的,但是管理员实施的时候这2者是密切配合的(www.askmac.cn)。

 

 

2.名称限额

 

名称限额是根目录中的目录名称文件的硬性限制。如果达到了这个限制,创建文件和目录将会失败。限额也会在重命名操作上起作用,如果重命名也满足限制条件,这个操作也将失败。即使新的配额已经让当前的目录违反了,这个设置操作任然会成功(设置并不会去校验)。一个新创建的目录不会分配配额。最大的配额是Long.Max_Value。配额强制一个目录保持为空(一个目录的数量就是其自身的配额)

 

在fsimage上,配额是持续性的。当启动时,如果fsimage已经违背了一个配额(也行是fsimage被偷偷的修改),每一个违反都会打印一个警告。设置或删除创建一个日志条目的配额。

[Read more…]

诗檀软件与 Solix 合作大数据项目

诗檀软件与 Solix 合作大数据项目

中国领先的数据库服务公司,基于Apache Hadoop的平台,提供信息生命周期管理(ILM通用数据平台和先进分析。

 

2016 — Santa Clara, Calif. — Solix Technologies, Inc.,  Solix Technologies,提供Apache Hadoop 的信息生命周期管理(ILM)解决方案的领先供应商在今天宣布,中国的数据库服务公司诗檀数据已经选择了Solix的大数据套件,基于Apache Hadoop进行交付归档,应用停用和先进分析。

 

Apache Hadoop是ILM的理想平台,因为它为企业级数据提供了高度可扩展,低成本,大容量存储。诗檀数据将为客户提供Solix的大数据套件,以提高应用程序的性能,降低成本,并满足管理,风险和合规性要求。Solix的大数据套件作为企业共同的数据平台,对大型数据集的结构化和非结构化数据进行高级分析。

 

“Apache Hadoop作为一个通用数据平台,是先进企业分析和ILM应用的理想工具。” John Ottman,Solix Technologies, Inc执行主席说道。“我们非常期待与诗檀数据在大中国区市场的合作。”

 

Solix是目前唯一一家为所有企业数据提供全面的信息生命周期管理(ILM)解决方案的供应商。我们很幸运在中国有这样强大的合作伙伴,诗檀数据CEO Maclean Liu说道。

 

要了解有关Solix大数据套件的更多信息, 点击这里

 

关于Solix Technologies

Solix Technologies, Inc.,提供Apache Hadoop 的信息生命周期管理(ILM)解决方案的领先供应商,通过其优化的基础设施,安全保障和先进分析,帮助企业管理自己的企业信息。 Solix Big Data Suite 是一个ILM应用解决方案架构,包括 Enterprise Archiving Enterprise Data Lake,  Application Retirement, Database Archiving, Test Data Management (数据库子集)和 Data Masking。 Solix Technologies, Inc. 总部位于美国加州的圣克拉拉,通过增值经销商(VAR)和系统集成商构建的网络遍及全球。要了解更多信息,请访问 www.solix.com

 

关于 Parnassus Data

Parnassus Data 是位于上海的一家Oracle 数据库服务公司,提供数据库开发,实施,管理和紧急支持服务。诗檀数据是数据库优化和监控工具开发方面的专家,同时也为Oracle数据库用户提供远程和现场服务。

 

联系 Solix

访问我们的网站:http://www.solix.com

在Twitter上关注我们:@solixedms

加入我们的Facebook: http://www.facebook.com/solixtechnologies

 

媒体联系

Jessica Hasson

PulpPR for Solix

jessica@pulppr.com

Oracle常见备份方案对应使用RMAN恢复场景

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 : 13764045638   QQ号:47079569    邮箱:service@parnassusdata.com

 

使用RMAN恢复场景

 

内容提要

当灾难发生的时候实施Restore/Recovery,可以还原生产数据库到最接近灾难发生前的一致性点。

Restore/Recover测试是备份策略很重要的一部分。当真的需要恢复的时候,确保备份可用并且能克服小毛病。如果需要恢复可以减少生产恢复的时间。

 

本文提供了大多数恢复场景,在灾难发生后的反应。例子的场景不是相关的具体存储。文中提供的场景基于基本的文件系统。稍微改动,就可用于ASM,裸设备,ocfs或其他类型存储。

 

简介

 

Redo Vs Rollback

Rode  Logs:  重做日志被用于前滚提交和未提交的变化

Rollback:  用于undo/rollback(撤销/回滚)未提交的变化

 

 

恢复类型

  • 在线块恢复(进程错误)

Oracle数据库的PMON进程会自动执行恢复。在某个进程修改buffer时异常死掉时发生

Oracle会使用重做日志重建buffer并写入磁盘。

  • 线程恢复 (实例错误)

也是oracle自动执行。发生在打开数据库实例崩溃的时候。

Oracle在线程上应用从上次线程检查点之后发生的所有的redo。

  • 介质恢复.

当一个数据文件从备份中恢复的时候需要进行介质恢复,因为数据文件中的checkpoint和控制文件中的不同,也发生在离线文件没来得及做checkpoint操作和使用备份控制文件的时候。

 

介质恢复类型

 

 

完全介质恢复

称之为完全恢复是因为oracle应用所有的重做日志将数据库回到最近的点,代表性的是应用于数据文件或控制文件的介质损坏。

它可以恢复整个数据库也可以只恢复表空间或数据文件。

 

数据库完全恢复 表空间/数据文件完全恢复
数据库mount 数据库 open
所有数据文件在线 要恢复的表空间/数据文件离线
恢复整个备份 恢复数据文件备份
应用在线或归档日志 应用在线或归档日志

 

场景:

 

丢失数据文件System datafile

run {
shutdown abort; 
startup mount; 
restore datafile 1;
recover datafile 1; 
alter database open; 
}


恢复数据文件到不同的位置

 

run {
shutdown abort; 
startup mount;
set newname for datafile 1 to '/tmp/system01.dbf'; 
restore datafile 1;
switch datafile all; 
recover datafile 1; 
alter database open; 
}



for Non-system datafile

run 
{
sql "alter database datafile 5 offline"; 
restore datafile 5;
recover datafile 4;
sql "alter database datafile 4 online"; 
}

 

 

恢复到不同的位置

run {
sql "alter database datafile  6 offline";
set newname for datafile 6 to '/u01/oracle/app//oradata/orcl/test02.dbf';
restore datafile 6;
switch datafile all; 
recover datafile 6;
sql "alter database datafile 6 online";

}


 

 

 

丢失整个数据库

 

run {
startup nomount;
restore controlfile from  '/u01/oracle/app/fast_recovery_area/ORCL/autobackup/2016_07_19/ o1_mf_s_917622140_crvn3xbh_.bkp';
startup mount; 
restore database; 
recover database;
alter database open resetlogs; 
}


 

不完全介质恢复

称之为不完全恢复是因为oracle不会应用所有的重做日志恢复数据库到之前的点。

应用于下面这些情况:

  • 丢失当前控制文件(备份的控制文件用于打开数据库)
  • 丢失一个或所有的重做日志文件
  • 用户/应用错误和基于时间点恢复
  • 丢失归档日志.

 

不完全介质恢复类型

 

  • 基于时间恢复 : 恢复到指定的时间
  • 基于取消的恢复 : 恢复直到输入cancel (当RMAN不可用的时候).
  • 基于SCN的恢复 : 恢复到指定的SCN
  • 基于日志序号的恢复 : 恢复到指定的日志序号 (只有RMAN不可用的时候).

 

场景:

 

  1. 丢失控制文件

如果使用noresetlogs方式重建控制文件,需要所有的日志文件完整。修改“alter database backup controlfile to trace noresetlogs;”  的输出结果来重建。

 

SQL> startup nomount
SQL> create controlfile … noresetlog … 
SQL> alter database open

 

 

如果你没有备份trace,尝试手工建控制文件。

如果上面的方法都没办法重建控制文件,你不得不从备份中恢复,打开数据库使用resetlogs模式,然后添加临时文件(这是无论你用什么方法重建控制文件都必须做的)。

 

 

run {
shutdown abort; 
startup nomount; 
restore controlfile; 
startup mount; 
recover database;
alter database open resetlogs; 
}

 

 

 

恢复控制文件到一个新的位置

 

 

run {
shutdown abort; 
startup nomount;
restore controlfile to '/tmp/control01.ctl'; 
restore controlfile from '/tmp/control01.ctl'; 
Shutdown immediate;
}

 

 

 

编辑init.ora文件映射控制文件的新位置

 

startup mount;
recover database;
alter database open resetlogs;

 

 

 

2. 丢失部分或全部的日志文件

 

Status Archived
UNUSED, CLEARING, INACTIVE Yes
CURRENT, No
ACTIVE Yes / No

 

 

col member for a50 
set linesize 120
select l.group#,l.thread#, 
lf.member,l.status,l.archived 
from v$log l , v$logfile lf
where l.group# = lf.group#;

 

活动的已归档在线日志

如果系统还没切换到丢失的日志文件,你可以安全的删除日志文件然后添加新的在线日志.

 

 

$ sqlplus '/as sysdba'
SQL> alter database drop logfile group 2;
SQL> alter database add logfile group 2 '/u02/oradata/test10g/redo02.log' size 50M;

 

 

如果数据库已经切换到丢失的日志文件,会报下面的错误:

 

Errors in file
/u01/app/oracle/admin/test10g/bdump/test10g_arc1_32016.trc:
ORA-00313: open failed for members of log group 2 of thread 1
ORA-00312: online log 2 thread 1: '/u02/oradata/test10g/redo02.log'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory Additional information: 3
$sqlplus ‘/as sysdba’
SQL> shutdown abort 
SQL> startup mount
SQL> alter database clear unarchived logfile group 2; 
SQL> Alter database open

 

活动的未归档在线日志

 

 

$sqlplus ‘/as sysdba’ 
SQL> shutdown abort 
SQL> startup mount
SQL> alter database clear unarchived logfile group 2; 
SQL> Alter database open

 

当前的在线日志文件

 

run 
{
startup nomount force;
set until sequence 44; 
# this is the same value of “Current log sequence” 
restore controlfile;
alter database mount; 
restore database; 
recover database;
alter database open resetlogs;
}

 

  1. 用户误操作(删除一个表, 或者错误的DML操作)

表空间基于时间点恢复(TSPITR)功能让你恢复一个或多个表空间到你最想要的一个时间点不同于数据库其他部分:

  • 恢复错误的drop或truncate表操作
  • 恢复一个逻辑损坏的表
  • 恢复一个错误的批处理job或者只影响一个数据库子集的DML语句
  • 恢复一个独立的schema到不同于物理数据库其余部分的时间点
  • 恢复一个表空间在一个很大的数据库而不是从备份中恢复整个数据库并执行一个完整的数据库前滚

 

 

 

在同一个主机上因用户误操作(drop/truncate/update)恢复

  • 拷贝ora文件,然后修改下面这些参数: db_name=’test10g’ # 和生产库名字相同 service_names = ‘testaux’

 

 

db_unique_name = 'testaux' control_files='/u02/oradata/testaux/control01.ctl'
audit_file_dest = '/u01/app/oracle/admin/testaux/adump' (optional) background_dump_dest = '/u01/app/oracle/admin/testaux/bdump' (optional) core_dump_dest = '/u01/app/oracle/admin/testaux/cdump' (optional) user_dump_dest = '/u01/app/oracle/admin/testaux/udump' (optional) log_archive_dest_1 = ‘?/?/?’ (Optional)
log_archive_format = ‘<>’ (optional)

 

 

  1. 对AUX实例设置ORACLE_HOME和ORACLE_SID export ORACLE_HOME=/u01/app/oracle/product/10.2.0/db1

 

export ORACLE_SID=testaux

 

  • 创建密码文件:

orapwd file=orapwtestaux password=oracle10g

  1. 确定sqlnet设置正确并测试连接(ora和listener.ora)
  2. 连接rman从生产库(主库)备份中恢复控制文件到AUX库。

 

rman target sys/oracle10g@test10g catalog rman/rman@rcvcat
run {
set until time "TO_DATE('02/JAN/2009 10:00:00','DD/MON/YYYY HH24:MI:SS')";
restore controlfile to '/u02/oradata/testaux/control01.ctl'; } #同步骤1中指定的位置
exit

 

 

  1. 连接AUX实例恢复所有需要的表空间到指定的点。

 

 

rman target sys/oracle10g@testaux nocatalog 

run {
startup mount;
set until time "TO_DATE('02/JAN/2009 10:00:00','DD/MON/YYYY HH24:MI:SS')";
set newname for datafile 1 to '/u02/oradata/testaux/system01.dbf'; 
set newname for datafile 2 to '/u02/oradata/testaux/undotbs01.dbf'; 
set newname for datafile 3 to '/u02/oradata/testaux/sysaux01.dbf'; 
set newname for datafile 4 to '/u02/oradata/testaux/users01.dbf'; 
restore datafile 1,2,3,4;
switch datafile all;
sql "alter database datafile 1,2,3,4 online"; 
recover database;

# 你需要指定"skip forever tablespace <list of tablespaces> if need to skip some"
# 恢复数据库跳过表空间ts1,ts2;

sql "alter database rename file ''/u02/oradata/test10g/redo01.log'' to ''/u02/oradata/testaux/redo01.log''";
sql "alter database rename file ''/u02/oradata/test10g/redo02.log'' to ''/u02/oradata/testaux/redo02.log''";
sql "alter database rename file ''/u02/oradata/test10g/redo03.log'' to ''/u02/oradata/testaux/redo03.log''";
alter database open resetlogs;
}

 

Note: 你可以使用DB_FILE_NAME_CONVERT

LOG_FILE_NAME_CONVERT 转换文件, 代替 “SET NEWNAME

 

  • 从AUX数据库中导出丢失的表,然后导入到生产库中。
  • 删除AUX数据库(数据文件/控制文件/重做日志文件,Dump目录,ora,密码文件以及整个sqlnet[tnsnames.ora和 sqlnet.ora])

 

TSPITR – 恢复用户误操作 (drop/truncate/update)在别的主机上

同上面相同的步骤,主库的RMAN备份集要进行恢复的主机上可用。

恢复控制文件到一个临时的位置, 然后上传到新的主机上, 然后在新主机上继续执行剩余的步骤。

 

TSPITR –在一个数据库中恢复整个表空间因为用户误操作或者没有影响其他表空的patch job

 

  1. 挑选目标时间: 当不希望的数据库变更发生,你可以使用OracleFlashback Query , Oracle Transaction Query 和Oracle Flashback Version Query去寻找时间点。在这个例子中 (Fri Jan 2 15:05:50 EST 2009)
  2. 确定恢复集: 目标数据文件需要被恢复到指定的时间
  • 分析数据关联在恢复集中

 

select *   from sys.ts_pitr_check
where ( ts1_name in ('torder')  and ts2_name not in ('torder')  ) or  ( ts1_name not in ('torder')  and
ts2_name in ('torder') );

 

如果上述查询返回no rows你可以准备执行TSPITR,否则你需要执行下面这些:

  1. 在你的恢复集中添加表空间包括相关的对象。
  2. 删除关联
  3. 在TSPITR执行期间暂停持续的关联

 

你需要确定TSPITR执行之后会丢失的对象

 

 

select owner, name, tablespace_name ,to_char(creation_time, 'yyyy-mm- dd:hh24:mi:ss')
from ts_pitr_objects_to_be_dropped where tablespace_name in ('users','tools')
and creation_time > to_date('01-jan-09:15:04:00','yy-mon-dd:hh24:mi:ss') order by tablespace_name, creation_time;

 

确定的TSPITR目标

全自动TSPITR: 使用 RMAN 处理TSPITR所有的方面.

 

rman target sys/oracle10g@test10g catalog rman/rman@rcvcat
run {
recover tablespace users until time "to_date('09-Jan-02:15:04:00','yy-mon- dd:hh24:mi:ss')" auxiliary destination '/u01/ray/aux';
sql 'alter tablespace users online'; 
}

 

 

Note:恢复集文件将被恢复到它们原来的位置,然而辅助集将被恢复到指定的位置根据设置。成功完成后,你需要把表空间设置成online然后尽快进行备份。

 

使用自动的辅助实例的自定义 TSPITR: 使用RMAN 处理TSPITR所有的方面. 但是自定义一个或多个behavior方面,例如 定制一个或多个behavior方面, 像辅助集的位置 ,恢复集的位置或指定的初始化参数或RMAN管理和生成辅助实例的通道配置。

 

重命名或重定位你的恢复集数据文件

 

rman target sys/oracle10g@test10g catalog rman/rman@rcvcat 
run {
set newname for datafile 4 to '/u02/oradata/testaux/users01.dbf';
recover tablespace users until time "to_date('09-Jan-02:15:04:00','yy-mon- dd:hh24:mi:ss')" ;
sql 'alter tablespace users online'; 
}

 

 

为一些或所有的辅助集数据文件指定一个除了auxiliary destination

以外的位置

 

rman target sys/oracle10g@test10g catalog rman/rman@rcvcat 

run {
set newname for datafile 4 to '/u02/oradata/testaux/users01.dbf';
recover tablespace users until time "to_date('09-Jan-02:15:04:00','yy-mon- dd:hh24:mi:ss')" auxiliary destination '/u01/ray/aux';
sql 'alter tablespace users online'; 
}

 

提前设置好你数据文件的image copy backup,通过避免从备份中恢复从而加快TSPITR速度.

这意味着你需要image copy backup一周一次用来给TSPITR使用当需要的时候

 

configure auxname for datafile n to auxname_n; # for every datafile

backup as copy datafile n format auxname_n;

 

 

当需要执行TSPITR

 

 

recover tablespace tablespace until time until time “to_date(’09- jan-02:15:04:00′,’yy-mon-dd:hh24:mi:ss’)

 

执行TSPITR使用自己的辅助实例:你负责设置开启, 关闭和 清除 用于 TSPITR的辅助实例, 并且管理 TSPITR 使用一些方法,像”使用自动的辅助实例的自定义 TSPITR :

  • 辅助实例使用不同的通道配置。
  • 指定不同的初始化参数为你的RMAN管理辅助实例。

 

创建密码文件

创建参数文件使用下面的参数

 

db_name='test10g' # THIS IS the same as the production name 
db_unique_name = 'testaux'
remote_login_passwordfile = EXCLUSIVE 
compatible = #The same as in the target database 
db_block_size = #The same as in the target database 
log_file_name_convert =('/a/b/trgt', '/x/y/auxdest')
db_file_name_convert =('/a/b/trgt', '/x/y/auxdest') this is optional if not used set newname control_files='/u02/oradata/testaux/control01.ctl'
audit_file_dest = '/u01/app/oracle/admin/testaux/adump' (optional) 
background_dump_dest = '/u01/app/oracle/admin/testaux/bdump' (optional)
core_dump_dest = '/u01/app/oracle/admin/testaux/cdump' (optional) 
user_dump_dest = '/u01/app/oracle/admin/testaux/udump' (optional)

 

 

准备AUX实例的网络连接         start/nomount aux instance

 

 

rman target sys/oracle10g@test10g auxiliary sys/oracle10g@testaux catalog rman/rman@rcvcat

run {
#指定所有恢复集数据文件的新名字如果db_file_name_convert没指定
set newname for datafile 4 to '/u02/oradata/testaux/users01.dbf';
#指定辅助集的新名字如果db_file_name_convert没指定
# 数据文件有有效的映像副本避免恢复:
set newname for datafile 1 to '/u02/oradata/testaux/system01.dbf'; 
set newname for datafile 2 to '/u02/oradata/testaux/undotbs01.dbf'; 
set newname for datafile 3 to '/u02/oradata/testaux/sysaux01.dbf';
#指定磁盘和管道
allocate auxiliary channel c1 device type disk; allocate auxiliary channel c2 device type disk;
allocate auxiliary channel t1 device type sbt; allocate auxiliary channel t2 device type sbt;
#恢复表空间到24小时前:
RECOVER TABLESPACE users UNTIL TIME "to_date('09-jan- 02:15:04:00','yy-mon-dd:hh24:mi:ss'); 
}


 

丢失归档日志:

DBPITR – 恢复数据库直到最后一个可用的归档日志或最后一个知道的SCN或时间点

 

 

run{
shutdown abort; 
startup mount;
set until sequence=29 thread=1; #将恢复直到 seq 28      
restore database ;
recover database ;
alter database open resetlogs; 
}

 

 

恢复数据库到resetlogs之前的点

例如你不得不使用resetlogs打开数据库无论什么原因

 

run{
shutdown abort; 
startup mount;
set until time "TO_DATE('20/AUG/2001 22:38:00','DD/MON/YYYY HH24:MI:SS')";
set until time 'sysdate-1/24/60*5'; 
restore database ;
recover database ;
alter database open resetlogs; 
}

 

 

使用这些方法获得RESETLOGS SCN:

 

– 运行一个LIST INCARNATION 命令,然后Reset SCN 列的值减1.当然,记下数据库的INC key列所有的值。

 

RMAN> List Incarnation;

DB Key  Inc Key DB Name DB ID         STATUS  Reset SCN  Reset Time

——- ——- ——– —————- — ———- ———-

8053 8054 TEST10G 925414866 PARENT 935646     31-DEC-08
8053 8480 TEST10G 925414866 PARENT 1213793    07-JAN-09
8053 8853 TEST10G 925414866 CURRENT 1216303    07-JAN-09

 

 

RESETLOGS时检查log , 查找关键字 RESETLOGS. 寻找像这样的一行: RESETLOGS after incomplete recovery UNTIL CHANGE 1234. 使用它, 例如

 

Wed Jan  7 13:08:19 2009

Incomplete Recovery applied until change 1216302

 

RESETLOGS之后通过控制文件 (当前控制文件或者resetlogs打开后备份的控制文件), 运行查询:

SELECT (RESETLOGS_CHANGE#)-1 FROM V$DATABASE; (RESETLOGS_CHANGE#)-1

———————

1216302

 

决定目标 incarnation ( list incarnation of database <db name> ) 并记录主键和scn. 在这个场景中目标 incarantion 是 8480

 

RMAN> 
Shutdown immediate 
startup nomount
reset database to incarnation 8480; 
run {
set until scn 1216302; restore controlfile; startup mount;
restore database; recover database;
alter database open resetlogs;
}

 

数据块介质恢复

 

blockrecover corruption list; ##  在视图V$DATABASE_BLOCK_CORRUPTION中显示所有要恢复的块
blockrecover datafile 4 block 999;
blockrecover tablespace ts1 dba <address of the block>

 

 

场景:

======

conn scott/tiger

create table xx as select * from emp;

conn / as sysdba 
select header_block from dba_segments where segment_name='XX';

HEADER_BLOCK
------------
59

dd if=/dev/zero of=/u02/oradata/test10g/users01.dbf bs=8192 conv=notrunc seek=60 count=1
1+0 records in
1+0 records out
8192 bytes (8.2 kB) copied, 0.000177 seconds, 46.3 MB/s




rman target sys/oracle10g@test10g catalog rman/rman@rcvcat backup tablespace users;
RMAN-03009: failure of backup command on ORA_DISK_1 channel at 01/07/2009 12:22:51
ORA-19566: exceeded limit of 0 corrupt blocks for file
/u02/oradata/test10g/users01.dbf




alert.log:
=======
Hex dump of (file 4, block 60) in trace file
/u01/app/oracle/admin/test10g/udump/test10g_ora_21798.trc Corrupt block relative dba: 0x0100003c (file 4, block 60) Completely zero block found during backing up datafile
Reread of blocknum=60, file=/u02/oradata/test10g/users01.dbf. found same corrupt data 
Reread of blocknum=60, file=/u02/oradata/test10g/users01.dbf. found same corrupt data 
Reread of blocknum=60, file=/u02/oradata/test10g/users01.dbf. found same corrupt data 
Reread of blocknum=60, file=/u02/oradata/test10g/users01.dbf. found same corrupt data 
Reread of blocknum=60, file=/u02/oradata/test10g/users01.dbf. found same corrupt data
RMAN> blockrecover datafile 4 block 60; 
RMAN> backup tablespace users;


恢复参数文件

如果实例是启动的

 

 

RMAN> restore spfile to '/tmp/spfiletest10g.ora';
$ mv /tmp/spfiletest10g.ora $ORACLE_HOME/dbs/ spfiletest10g.ora

 

如果实例是关闭的:

===============

创建一个参数文件只使用下面的参数:

 

 

*.db_name='test10g'
*.large_pool_size=8m
*.shared_pool_size=100m
*.db_cache_size=4m
RMAN> Restore spfile from autobackup; 
RMAN> shutdown immediate
删除之前的参数文件
RMAN> startup

 

恢复数据库到新的主机上

Note1:下面的步骤是用来执行DR测试恢复,移动生产库到一个新的主机 ,或者恢复数据库如果recovery catalog被损坏或丢失。

Note2: 下面步骤也用于创建一个目标数据库的副本,推荐使用RMAN Duplicate代替, 因为RMAN会分配新的dbid.如果选择不使用RMAN Duplicate 不要连接指定的recovery catalog在这个例子中, 否则将来恢复你的生产库将受到影响。

Note3:  如果你选择复制数据库使用下面的步骤,考虑以下几个方面:

  • 不要连接recovery catalog
  • 成功后请变更dbidrecovery catalog注册克隆数据库之前。请参考“Restore database in the same host”DBNEWID 部分

 

记录源库的dbid

 

RMAN> list incarnation; or select dbid from v$database;

 

获得源库的数据文件列表用来重命名 col name for a60

 

col member for a60
select file# as "file/grp#", name from v$datafile; 
select group#,member from v$logfile;

 

 

复制源库的参数文件到新主机上

 

scp inittest10g.ora sscnjlnx3:/u01/app/oracle/product/10.2.0/db_1

更改下面这些:

 

control_files='/u01/ray/oradata/control01.ctl' 
background_dump_dest = '/u01/ray/dump/bdump' 
user_dump_dest = '/u01/ray/dump/udump' 
core_dump_dest = '/u01/ray/dump/cdump' 
audit_file_dest = '/u01/ray/dump/adump' 
log_archive_dest_1 = 'location=/u01/ray/arch'

 

上传所有的备份集到新主机,和源库相同的位置. cd /u03/ray/backup

 

scp * sscnjlnx3:/u03/ray/backup
cd /u03
mkdir ray
cd  /
ln -s /d01/backup /u03/ray/backup

 

在新主机上

 

$ export ORACLE_SID=test10g
$ rman target / nocatalog 
RMAN> set dbid 925414866 
RMAN> startup nomount
RMAN> restore controlfile from '/u03/ray/backup/cf_c-925414866-20090112-00';

RMAN> alter database mount; 

RMAN> run {
# 用来恢复文件到不同的位置
# DB_FILE_NAME_CONVERT 可以用来替代
set newname for datafile 1 to '/u01/ray/oradata/new/system01.dbf'; 
set newname for datafile 2 to '/u01/ray/oradata/new/undotbs01.dbf'; 
set newname for datafile 3 to '/u01/ray/oradata/new/sysaux01.dbf'; 
set newname for datafile 4 to '/u01/ray/oradata/new/users01.dbf';
# LOG_FILE_NAME_CONVERT 可以用来替代
set until scn 1352525; 
restore database; 
switch datafile all; 
recover database;

#下面rename部分用来重建在线日志到不同的位置
sql "alter database rename file ''/u02/oradata/test10g/redo01.log'' to ''/u01/ray/oradata/new/redo01.log''";
sql "alter database rename file ''/u02/oradata/test10g/redo02.log'' to ''/u01/ray/oradata/new/redo02.log''";
sql "alter database rename file ''/u02/oradata/test10g/redo03.log'' to ''/u01/ray/oradata/new/redo03.log''"; 
alter database open resetlogs; 
}

 

恢复数据库在相同的主机

拷贝 inittest10g.ora至 initdup10g.ora,修改按照下面:

 

control_files='/u03/ray/dup10g/oradata/control01.ctl' 
background_dump_dest = '/ u03/ray/dup10g/dump/bdump' 
user_dump_dest = '/ u03/ray/dup10g/dump/udump' 
core_dump_dest = '/ u03/ray/dup10g/dump/cdump' 
audit_file_dest = '/ u03/ray/dup10g/dump/adump' 
log_archive_dest_1 = ' location=/u03/ray/dup10g arch' 
db_unique_name=dup10g
$ export ORACLE_SID=dup10g
$ rman target / nocatalog 
RMAN> set dbid 925414866 
RMAN> startup nomount
RMAN> restore controlfile from '/u03/ray/backup/cf_c-925414866-20090112-00'; 
RMAN> startup mount
RMAN> run 
{
set newname for datafile 1 to '/u03/ray/dup10g/oradata/system01.dbf'; 
set newname for datafile 2 to '/u03/ray/dup10g/oradata/undotbs01.dbf'; 
set newname for datafile 3 to '/u03/ray/dup10g/oradata/sysaux01.dbf'; 
set newname for datafile 4 to '/u03/ray/dup10g/oradata/users01.dbf'; 
set until scn 1352525;
restore database; 
switch datafile all; 
recover database;
sql "alter database rename file ''/u02/oradata/test10g/redo01.log'' to ''/u03/ray/dup10g/oradata/redo01.log''";
sql "alter database rename file ''/u02/oradata/test10g/redo02.log'' to ''/u03/ray/dup10g/oradata/redo02.log''";
sql "alter database rename file ''/u02/oradata/test10g/redo03.log'' to ''/u03/ray/dup10g/oradata/redo03.log''";
alter database open resetlogs; 
} 
exit from RMAN
SQL> alter database backup controlfile to trace 
SQL> shutdown immediate
#变更 db_name = edit the controlfile create stmt to “create controlfile reuse set database "dup10g" resetlogs  archivelog ..”
SQL> recover database using backup controlfile until cancel; 
SQL> alter database open resetlogs;
# 创建密码文件

$ orapwd file=orapwdup10g password=oracle10g
# 你可以移除 DB_UNIQUE_NAME=dup10g如果需要#这种情况数据dbid和生产相同, 所以你需要更改dbid使用DBNEWID 功能, 使其能在RMAN注册像下面这样:DBNEWID
# 备份数据库               

SQL> shutdown immediate 
SQL> startup mount$ nid target=sys/oracle10g@dup10g or nid target=/
SQL> startup mount
SQL> alter database open resetlogs




 

 

副本数据库  RMAN使用源数据库备份执行数据库复制

克隆数据库可以:

  1. 完全相同的,
  2. Until point in time in the past within the current incarnation
  3. 包括表空间的子集, 使用SKIP TABLESPACE. (rman 默认跳过离线表空间)
  4. 使用SKIP READONLY 会排除只读表空间
  5. 同源库相同或不同的名字
  6. 不同的主机上有不同或相同的目录结构[NOFILENAMECHECK] (假如在同意主机上复制,必须有不同的目录结构)
  • 可以在不同的或相同的主机上复制
  • 复制数据库可以被来下面这些目的, 例如:
    1. 测试主库备份
    2. 恢复 dropped/truncated 的表 或者恢复错误的 update 对表或者方案直到过去的时间点.
    3. 创建开发/测试用的相同数据库
    4. 创建备库
  • RMAN执行下面这些步骤去复制:
    1. 为副本数据库创建控制文件
    2. 恢复所有的数据文件到副本数据库
    3. 执行不完全恢复 (因为在源库没有备份在线日志)
    4. 使用 RESETLOGS打开副本数据库 (创建standby时跳过)
    5. 为副本数据库产生一个新的,唯一的DBID (创建standby时跳过)
  • 复制期间重命名文件
    1. 控制文件位置和名字取决于 CONTROL_FILES 初始化参数
    2. 数据文件和临时文件名字和位置取决于下面的参数:

 

DB_FILE_NAME_CONVERT DB_CREATE_FILE_DEST

DB_FILE_NAME_CONVERT语句(DUPLICATE SET)

NEWNAME FOR DATAFILE

CONFIGURE AUXNAME

 

重做日志文件名字和位置取决于下面的参数:

 

LOG_FILE_NAME_CONVERT DB_CREATE_ONLINE_DEST_n

DUPLICATE 的LOGFILE 语句 DB_RECOVERY_FILE_DEST

 

 

复制到一个新的主机,有相同的目录结构

在目标主机必须启动辅助实例

使用最小的参数创建服务器参数文件 DB_NAME

CONTROL_FILES

Compatible=<same as source>

sga_target=536870912

 

可选参数:

 

background_dump_dest= /u01/app/oracle/admin/test10g/
bdump user_dump_dest= /u01/app/oracle/admin/test10g/
udump core_dump_dest= /u01/app/oracle/admin/test10g/
cdump audit_file_dest= /u01/app/oracle/admin/test10g/adump

 

创建密码文件

 

orapwd file=orapwtest10g password=oracle10g

 

同 recovery catalog 和目标库建立网络连接

 

test10g =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST =
sscnjlnx5.us.oracle.com)(PORT = 1521)) (CONNECT_DATA =
(SERVER = DEDICATED) (SERVICE_NAME = test10g) (INSTANCE_NAME = test10g)   ) )
rcvcat = (DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST =
sscnjlnx5.us.oracle.com)(PORT = 1521)) (CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = rcvcat) (INSTANCE_NAME = rcvcat)    ) )

 

确保备份的所有数据文件可以被复制(目标/AUX主机)的主机访问

启动AUX到mount状态

$ export ORACLE_SID=test10g

$ sqlplus '/as sysdba'

startup nomount pfile=/u02/oradata/test10g/inittest10g.ora

RMAN 连接3个实例

rman target sys/oracle10g@test10g auxiliary / catalog rman/rman@rcvcat
run {
# allocate at least one aux channel if not configured already allocate auxiliary channel aux1 device type disk;
duplicate target database to test10g NOFILENAMECHECK;
}

 

 

 

Note1: 这种情况下, 你可以添加额外的db参数和网络连接

Note2: RMAN 分配一个新的DBID给复制的数据库          Note3: 复制命令可以在任何一个主机上运行.

Note4: 在这个例子中,复制数据库到新的主机使用相同的数据库名, 你可以更改名字通过指定不同的名字用 “duplicate target database to <>..”

Note5: NOFILENAMECHECK 被使用因为复制数据库使用了相同的目录结构

 

复制到新的主机,使用不同的目录结构                                          

同样的步骤和 “复制到新的主机,使用相同的目录结构”,有一些轻微的变动:

使用 DB_FILE_NAME_CONVERT 和 LOGFILE 在复制脚本中去指定新的日志文件和数据文件

指定 DB_FILE_NAME_CONVERT, LOG_FILE_NAME_CONVERT在辅助实例的参数文件.

你可以用set  newname 去指定数据文件新的位置在rman脚本中

 

 

run{
allocate auxiliary channel aux1 device type disk; 
duplicate target database to test10g
db_file_name_convert=('/u02/oradata/test10g/','/u02/oradata/test10g/new/') logfile
group 1 ('/u02/oradata/test10g/new/redo01.log') size 50m, group 2 ('/u02/oradata/test10g/new/redo02.log') size 50m, group 3 ('/u02/oradata/test10g/new/redo03.log')  size 50m; }

 

在同一主机复制

这种类型的复制不同于其他的; 你必须指定不同的位置和不同的名字。

实施这种类型的复制请参考“复制到新的主机,使用不同的目录结构”.

 

复制数据库作为备库

  • RMAN 不能用来创建逻辑备库, 因为它不是块级复制
  • 手动创建standby库 ora
  • 不挂载控制文件启动备库
  • 设置Oracle Net
  • RMAN 备份必须是可读的对备库来说

 

 

  • 物理备库的备份和主库的备份是可互换的,换句话说:
    • 备库的备份可以用来恢复主库
    • 主库的备份可以用来恢复备库
    • 备库的控制文件备份可以恢复不用重建,如果丢失的话
  • 使用RMAN创建备库的优点
    • RMAN 使用主库备份, 所以在主库的操作是不受影响的
    • RMAN 自动重命名文件
    • RMAN 恢复归档日志文件从备份中然后执行恢复备库同步主库

场景:

确保你有主库的备份并上传到备库上去。

 

 

RMAN> backup database plus archivelog;
使用RMAN创建备库控制文件
$ rman target sys/oracle10g@test10g catalog rman/rman@rcvcat
RMAN> backup current controlfile for standby; 
# 位置取决于之前设置的
或者
RMAN> copy current controlfile for standby to '/u03/ray/backup/sby_control01.ctl';

 

 

选择文件/日志名字给备库数据文件

 

备库主机 目录结构 重命名 重命名选项
和主库相同主机名 和主库主机不同 必要. 1- DB_FILE_NAME_CONVERT 和

LOG_FILE_NAME_CONVERT参数在 init.ora中

2- DB_FILE_NAME_CONVERT

3-  设置新的位置

4-  设置数据文件的AUXNAME

 

和主库相同主机名 和主库主机相同 Illegal. NA
和主库不同主机名 和主库主机相同 不必要. 同上面第一个
和主库不同主机名 和主库主机不同 必要. 同上面第一个

 

 

配置备库参数:

 

DB_NAME=test10g # the same as the primary db 
DB_UNIQUE_NAME=tstsby 
CONTROL_FILES='/u02/oradata/tstsby/new/control01.ctl', '/u02/oradata/tstsby/new/control02.ctl' 
STANDBY_FILE_MANAGEMENT=AUTO
STANDBY_ARCHIVE_DEST = '/u03/ray/incomarch' 
#the location of archive logs arriving from a primary 
LOG_ARCHIVE_DEST_1='location=/u03/ray/arch' 
LOG_ARCHIVE_FORMAT=log%t_%s_%r.arc 
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
CORE_DUMP_DEST='/u01/app/oracle/admin/tstsby/cdump' 
USER_DUMP_DEST='/u01/app/oracle/admin/tstsby/udump' 
AUDIT_FILE_DEST='/u01/app/oracle/admin/tstsby/adump' 
BACKGROUND_DUMP_DEST='/u01/app/oracle/admin/tstsby/bdump' 
LOG_FILE_NAME_CONVERT='/u02/oradata/test10g/', '/u02/oradata/tstsby/new/'

 

 

  • 备库创建密件  orapwd file=orapwtstsby  password=oracle10g
  • 设置网络
    • 添加TNS信息在备库主机用来连接recovery catalog数据库
    • 添加TNS信息在备库主机上用来连接目标库(源库)
    • 添加SID信息在备库的监听上
    • 添加TNS信息在主库主机上为了连接备库
  • 在备库主机上,连接RMAN并运行duplicate

 

$ export ORACLE_SID=tstsby
$ sqlplus '/as sysdba' 
SQL> startup nomount; 
SQL> exit

 

 

创建备库没有恢复的情况下 (默认)

 

$ rman target sys/oracle10g@test10g auxiliary / catalog rman/rman@rcvcat
RMAN> 
run{
allocate auxiliary channel aux1 device type disk; duplicate target database for standby
db_file_name_convert=('/u02/oradata/test10g/','/d01/app/oracle/product/or adata/tstsby/'); 
}

 

 

 

Note:这种情况下RMAN只恢复备库控制文件和数据文件,并且mount备库在没恢复的情况下。你需要恢复数据库并且手动开启自动恢复。

 

你另外能做的是 强制RMAN 恢复到指定的时间, 系统变更号(SCN), 或者 日志文件 sequence number, 或者产生的最后归档日志 如果之前没指定的话

 

RMAN> 
run{
allocate auxiliary channel aux1 device type disk; duplicate target database for standby DORECOVER
db_file_name_convert=('/u02/oradata/test10g/','/u02/oradata/tstsby/new/');
}

 

在这种情况, RMAN 让起 mount 并且不放它处于自动恢复模式

在主库上

 

alter system set log_archive_dest_2=’service=tstsby’ scope=both;

 

在备库上

 

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

停止自动恢复

 

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

 

Note: 不要在 recovery catalog注册备库, 因为这种情况备库还没分配一个新的DBID

 

从物理备库恢复主库

  • 备份被两个系统使用的数据文件和归档日志文件用来恢复
  • 使用备库作为备份主机的优点:
    • 备库备份不会受到生产库事务或者批处理作业的影响. 因此在备库上备份是对生产库影响最小的备份.
    • 备库备份操作不取决于CPU,分配非内存或者其他生产主机的资源 .
  • 只有备库实例产生的归档日志能备份. 如果有归档日志产生在备库开始之前, 必须在主库备份. 例如, 第一个从主库发送到备库的是seq100 thread 1, 然后备份归档日志小于100的必须在主库进行.
  • 主库和备库使用相同的recovery catalog. 尽管有相同的 DBID, RMAN 能区分他们

 

.注意你不需要在catalog注册备库如果主库已经注册. 直接连接备库,然后运行备份命令

  • 最好的练习方法:
    • 控制文件和参数文件 must必须在主库备份,每天都做或者一周一次,取决于应用能忍受丢失程度.总的来说备份主库控制文件当你备份备库的时候

 

RMAN> connect target <primary database> RMAN> backup current controlfile;

 

 

  • 然后备库进行备份 RMAN> connect target <standby database> RMAN> backup database plus archivelog;
  • 如果主库备库重建控制文件 , 主库变成备库或者备份切到主库,你必须catalog所有的归档日志自从上次备份之后。

场景:

恢复在主库丢失的数据文件使用备库的备份

一起上传丢失的数据文件备份和需要的归档日志到主库服务器上

 

run {
sql "alter database datafile 4 offline"; 
restore datafile 4;
recover datafile 4;
sql "alter database datafile 4 online"; 
}


 

恢复备库丢失的数据文件使用备库的备份

 

run {
sql " alter database recover managed standby database cancel;"; 
restore datafile 4;
sql 'alter database recover managed standby database disconnect from session';
}

 

Note: 不需要恢复数据文件,因为MRP进程会自动完成。.

 

恢复备库丢失的控制文件使用备库的备份

Note: 连接RMAN恢复控制文件,会出现下面报错:

 

 

ORA-00210: cannot open the specified control file
ORA-00202: control file: '/d01/app/oracle/product/oradata/tstsby/control01.ctl' ORA-27041: unable to open file
Linux Error: 2: No such file or directory Additional information: 3

 

恢复备库的控制文件:

 

 

SQL> shutdown abort 
run {
startup nomount
restore controlfile from autobackup; 
startup mount
sql 'alter database recover managed standby database disconnect from session';
}

 

你也可以从主库创建控制文件,然后上传到备库:

 

SQL> alter database create standby controlfile as ‘/tmp/ control01.ctl’;

然后上传到备库

 

Note: 你不能停止恢复,如果你这么做了,会出现控制文件错误:

 

SQL> shutdown abort # 在备库操作

SQL> startup mount;

 

然后重命名数据文件如果备库使用不同的路径:

 

SQL> alter system set STANDBY_FILE_MANAGEMENT = MANUAL; 
SQL> alter database rename file '/u02/oradata/test10g/sysaux01.dbf' to '/d01/app/oracle/product/oradata/tstsby/sysaux01.dbf';

SQL> alter database rename file '/u02/oradata/test10g/system01.dbf' to '/d01/app/oracle/product/oradata/tstsby/system01.dbf';

SQL> alter database rename file '/u02/oradata/test10g/undotbs01.dbf' to '/d01/app/oracle/product/oradata/tstsby/undotbs01.dbf';

SQL> alter database rename file '/u02/oradata/test10g/users01.dbf' to '/d01/app/oracle/product/oradata/tstsby/users01.dbf';

SQL> alter system set STANDBY_FILE_MANAGEMENT = AUTO;

 

 

开始应用redo

 

sql> alter database recover managed standby database disconnect from session;

 

或者你可以使用RMAN做这些:

 

RMAN> copy current controlfile for standby to ‘/u03/ray/backup/control01.ctl’;

 

 

  • 上传到备库,
  • 关闭备库实例
  • 挂载控制文件

 

 

  • 禁用文件自动管理 (STANDBY_FILE_MANAGEMENT= MANUAL)
  • 重命名数据文件
  • 启用文件自动管理 (STANDBY_FILE_MANAGEMENT = AUTO)
  • 然后应用redo

 

Note:创建的控制文件丢失所有它创建之前的归档日志。因为RMAN 通过控制文件的的归档日志列表备份,从上次备份之后产生的所有归档日志必须手动catalog。

 

恢复备库丢书的控制文件如果没有可用的备份

从主库创建备库控制文件

 

$rman sys/oracle10g@test10g nocatalog
RMAN> backup current controlfile for standby format '/tmp/stdby2_ctl.bck'; 
exit

 

 

  • 上传到备库 scp  bck nerlinux03:/tmp
  • 执行备库控制文件的恢复

 

 

run {
Startup nomount
restore standby controlfile from '/tmp/stdby2_ctl.bck' alter database mount;
catalog start with '/d01/app/oracle/product/oradata/tstsby/'; switch database to copy;
sql 'alter database recover managed standby database disconnect from session';
}

 

 

Note: Catalog 和 Switch 命令 不需要执行如果备库有相同的目录结构

 

  1. 恢复主库丢失的控制文件

自从你使用备库作为一个备份主机, 假如你丢失主库控制文件你不能使用备库的控制文件恢复主库控制文件因为它不是current。 这就是为什么之前说主库备份控制文件和参数文件非常重要。然而,如果主库的备份不可用,有以下两种方法:

 

  • 重建控制文件使用 NORESETLOGS选项
  1. 在备库上, 使用 NORESETLOGS选项创建trace文件 alter database backup controlfile to trace noresetlogs;
  2. 编辑trace文件并放到适当的位置
  3. 启动主库到nomount
  4. 重建控制文件

 

 

  1. 使用resetlogs打开数据库
  2. 然后添加临时文件,这是无论怎么重建控制文件都要做的

 

  • 如果你不能执行之前的步骤,你可以从备份中恢复控制文件并resetlogs打开数据库:

 

run {
startup nomount; 
restore controlfile; 
startup mount; 
restore database;
alter database open resetlogs; 
}

 

 

恢复主库丢失在线重做日志文件

Inactive Archived

 

你可以删除然后重建,例如:

 

SQL> alter database drop logfile group 2;
SQL> alter database add logfile group 2 '/u02/oradata/test10g/redo02.log' size 50M;
SQL> alter database add logfile member '/u02/oradata/test10g/redo02.log' reuse to group 2;

 

Current 或 Active not archived

你必须切换到备库

 

为了解决归档日志差距问题,对备库做一些差距检查,并上传所有的归档日志到备库。

 

SQL> select thread#, low_sequence#, high_sequence# from v$archive_gap;

 

检查每个线程最大的seq号,然后从主库上传所有高seqence的归档日志:

 

SQL> select unique thread# as thread, max(sequence#)over (partition by thread#) as last  from v$archived_log;

 

注册所有来自步骤1和2的新的归档日志

 

sql> alter database register physical logfile ‘?/?/?xyz.arch’;

 

 

Note:如果执行第三步中来自步骤1的部分,你不能解决归档日志的差距(例如,因为你连接主库失败导致没访问系统),一些数据会丢失在切换期间。

强制恢复结束意味着终止所有inactive redo传输。

 

alter database recover managed standby database finish force;

alter database commit to switchover to primary;

 

 

or alter database activate standby database # 这个将导致一些数据丢失, 如果之前执行reslove gap。

  1. 如果备库自从上次启动之后从没开启到只读模式,你可以“alter database open”
  2. 如果备库自从上次启动之后一直处于只读模式,先shutdown immediate然后startup

 

RMAN 配置

 

自动备份能让RMAN恢复数据库即使当前控制文件,catalog和参数文件丢失。配置控制文件自动备份开启:

 

因为自动备份的文件名使用了众所周知的格式, RMAN 可以不实用知识库去寻找它, 然后恢复参数文件. 通过恢复的参数文件启动实例后, RMAN 可以从自动备份恢复控制文件. 挂载控制文件之后, RMAN 知识库变得可用,RMAN 可以恢复数据文件和寻找归档日志.

 

CONFIGURE CONTROLFILE AUTOBACKUP ON;

 

默认的格式是 c-<dbid>-<timestamp>-<hex sequence>, 如果你像改变格式:

 

CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR

DEVICE TYPE DISK TO ‘/u01/ray/backup/cf_%F’; CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO ‘+dgroup1/%F’;

 

 

  • 配置默认的写介质,格式和并行度

 

CONFIGURE DEFAULT DEVICE TYPE TO disk|sbt; CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT   '/u01/ray/backup/%U';
CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS  'ENV=mml_env_settings' FORMAT   '%U'; CONFIGURE DEVICE TYPE sbt PARALLELISM 3; CONFIGURE DEVICE TYPE DISK PARALLELISM 4;

 

 

 

  • 配置保留策略

保留备份能恢复数据库到过去几天的任何一个时间点,或者保留每个数据文件的备份:

 

CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 20 DAYS;

CONFIGURE RETENTION POLICY TO REDUNDANCY 4;

 

 

  • 配置归档日志的删除策略

确保闪回区删除归档日志被强制应用于备库

CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;

 

 

  • 增加 CONTROL_FILE_RECORD_KEEP_TIME到一个更高的值, 防止你需要目标数据库恢复,但RMAN recover catalog 不可用。
常用RMAN维护命令

 

  • 查询RMAN中备份和副本信息的状态,而不是介质像磁盘或者磁带

EXPIRED =备份没有被找到在备份位置         AVAILABLE =备份是可用的                      UNAVAILABLE =备份是不可用的

 

crosscheck backup; # 核对 备份集 和 映像副本         crosscheck backup of database | controlfile | archivelog all; crosscheck copy of database | controlfile | archivelog all

 

Note:如果EXPIRED备份后来变available,下次crosscheck将标记成AVAILABLE。

 

  • 显示知识库中备份集信息,proxy copies信息, 和映像副本信息

List incarnation of database <db_name>;

 

List BACKUP | backupset | COPY

List backup of database | controlfile | spfile | archivelog all; List backup of database by file|summary

 

List all|global script

List expired backup of database| archivelog all| controlfile |spfile | 3-   去执行RMAN知识库的详细分析结果

Report need backup Report obsolete Report  schema Report unrecoverable;

4- 删除物理备份和副本同时更新目标控制文件并从catalog移除知识库中的记录

Delete noprompt obsolete; Delete noprompt expired; Delete backup |of

Delete copy | of

DELETE backup of database  completed before ‘sysdate -1’;

 

 

5-   删除指定的备份集:

Change backupset <BS_Key> delete;

 

 

 

 

 

 

 

演练:

 

完全介质恢复

  1. 丢失数据文件

场景一:系统层面丢失数据文件有完整的rman备份

SQL> select count(*) from test02.torder;

 

COUNT(*)

———-

1093

 

模拟丢失数据文件

[oracle@dbdao orcl]$ mv test02.dbf  bak.dbf

关闭再打开数据库时报错

ORA-01157: cannot identify/lock data file 6 – see DBWR trace file

ORA-01110: data file 6: ‘/u01/oracle/app/oradata/orcl/test02.dbf’

 

恢复方法:

[oracle@dbdao ~]$ rman target /

run {

shutdown abort;

startup mount;

restore datafile 1;

recover datafile 1;

alter database open;

}

 

打开数据库后查询,发现已经恢复

SQL> select count(*) from test02.torder;

 

COUNT(*)

———-

1093

 

恢复数据文件到不同的位置

run {

shutdown abort;

startup mount;

set newname for datafile 6 to ‘/tmp/test02.dbf’;

restore datafile 6;

switch datafile all;

recover datafile 6;

alter database open;

}

 

 

 

场景二:非系统层面丢失数据文件

SQL> alter database datafile 6 offline drop;

 

Database altered.

 

SQL> select * from test02.torder;

select * from test02.torder

*

ERROR at line 1:

ORA-00376: file 6 cannot be read at this time

ORA-01110: data file 6: ‘/u01/oracle/app/oradata/orcl/test02.dbf’

 

恢复方法

在线直接恢复

RMAN> run{

2> restore datafile 6;

3> recover datafile 6;

4> sql “alter database datafile 6 online”;

5> }

 

SQL> select count(*) from test02.torder;

 

COUNT(*)

———-

1093

 

恢复都不同的位置

RMAN> run{

2>sql “alter database datafile 6 offfline”;

3>set newname for datafile 6 to ‘/u01/oracle/app/oradata/test02.dbf’;

4> restore datafile 6;

5>switch datafile all;

6> recover datafile 6;

7> sql “alter database datafile 6 online”;

8> }

 

 

场景三:丢失整个数据库

删除oradata下面的所有数据文件文件

[oracle@dbdao orcl]$ rm -rf *

 

[oracle@dbdao orcl]$ rman target /

 

RMAN>

run {

startup nomount;

restore controlfile from ‘/u01/oracle/app/fast_recovery_area/ORCL/autobackup/2016_07_19/o1_mf_s_917622140_crvn3xbh_.bkp’;

startup mount;

restore database;

recover database;

alter database open resetlogs;

}

 

Oracle instance started

 

Total System Global Area     839282688 bytes

 

Fixed Size                     2233000 bytes

Variable Size                553651544 bytes

Database Buffers             281018368 bytes

Redo Buffers                   2379776 bytes

 

Starting restore at 19-JUL-16

using target database control file instead of recovery catalog

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=18 device type=DISK

 

channel ORA_DISK_1: restoring control file

channel ORA_DISK_1: restore complete, elapsed time: 00:00:01

output file name=/u01/oracle/app/oradata/orcl/control01.ctl

output file name=/u01/oracle/app/fast_recovery_area/orcl/control02.ctl

Finished restore at 19-JUL-16

 

database is already started

database mounted

released channel: ORA_DISK_1

 

Starting restore at 19-JUL-16

Starting implicit crosscheck backup at 19-JUL-16

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=18 device type=DISK

Crosschecked 7 objects

Finished implicit crosscheck backup at 19-JUL-16

 

Starting implicit crosscheck copy at 19-JUL-16

using channel ORA_DISK_1

Finished implicit crosscheck copy at 19-JUL-16

 

searching for all files in the recovery area

cataloging files…

cataloging done

 

List of Cataloged Files

=======================

File Name: /u01/oracle/app/fast_recovery_area/ORCL/autobackup/2016_07_19/o1_mf_s_917619287_crvkbqtt_.bkp

File Name: /u01/oracle/app/fast_recovery_area/ORCL/autobackup/2016_07_19/o1_mf_s_917622140_crvn3xbh_.bkp

 

using channel ORA_DISK_1

 

channel ORA_DISK_1: starting datafile backup set restore

channel ORA_DISK_1: specifying datafile(s) to restore from backup set

channel ORA_DISK_1: restoring datafile 00001 to /u01/oracle/app/oradata/orcl/system01.dbf

channel ORA_DISK_1: restoring datafile 00003 to /u01/oracle/app/oradata/orcl/undotbs01.dbf

channel ORA_DISK_1: restoring datafile 00007 to /u01/oracle/app/oradata/orcl/test03.dbf

channel ORA_DISK_1: reading from backup piece /u01/oracle/app/fast_recovery_area/ORCL/backupset/2016_07_19/o1_mf_nnndf_TAG20160719T145843_crvmx4vg_.bkp

channel ORA_DISK_1: piece handle=/u01/oracle/app/fast_recovery_area/ORCL/backupset/2016_07_19/o1_mf_nnndf_TAG20160719T145843_crvmx4vg_.bkp tag=TAG20160719T145843

channel ORA_DISK_1: restored backup piece 1

channel ORA_DISK_1: restore complete, elapsed time: 00:00:35

channel ORA_DISK_1: starting datafile backup set restore

channel ORA_DISK_1: specifying datafile(s) to restore from backup set

channel ORA_DISK_1: restoring datafile 00002 to /u01/oracle/app/oradata/orcl/sysaux01.dbf

channel ORA_DISK_1: reading from backup piece /u01/oracle/app/fast_recovery_area/ORCL/backupset/2016_07_19/o1_mf_nnndf_TAG20160719T145843_crvmx42n_.bkp

channel ORA_DISK_1: piece handle=/u01/oracle/app/fast_recovery_area/ORCL/backupset/2016_07_19/o1_mf_nnndf_TAG20160719T145843_crvmx42n_.bkp tag=TAG20160719T145843

channel ORA_DISK_1: restored backup piece 1

channel ORA_DISK_1: restore complete, elapsed time: 00:01:15

channel ORA_DISK_1: starting datafile backup set restore

channel ORA_DISK_1: specifying datafile(s) to restore from backup set

channel ORA_DISK_1: restoring datafile 00004 to /u01/oracle/app/oradata/orcl/users01.dbf

channel ORA_DISK_1: restoring datafile 00005 to /u01/oracle/app/oradata/orcl/test01.dbf

channel ORA_DISK_1: restoring datafile 00006 to /u01/oracle/app/oradata/orcl/test02.dbf

channel ORA_DISK_1: reading from backup piece /u01/oracle/app/fast_recovery_area/ORCL/backupset/2016_07_19/o1_mf_nnndf_TAG20160719T145843_crvmx47m_.bkp

channel ORA_DISK_1: piece handle=/u01/oracle/app/fast_recovery_area/ORCL/backupset/2016_07_19/o1_mf_nnndf_TAG20160719T145843_crvmx47m_.bkp tag=TAG20160719T145843

channel ORA_DISK_1: restored backup piece 1

channel ORA_DISK_1: restore complete, elapsed time: 00:01:35

Finished restore at 19-JUL-16

 

Starting recover at 19-JUL-16

using channel ORA_DISK_1

 

starting media recovery

 

archived log for thread 1 with sequence 4 is already on disk as file /u01/oracle/app/oradata/orcl/redo01.log

archived log for thread 1 with sequence 5 is already on disk as file /u01/oracle/app/oradata/orcl/redo02.log

archived log file name=/u01/oracle/app/oradata/orcl/redo01.log thread=1 sequence=4

archived log file name=/u01/oracle/app/oradata/orcl/redo02.log thread=1 sequence=5

media recovery complete, elapsed time: 00:00:02

Finished recover at 19-JUL-16

 

database opened

 

 

 

 

 

 

 

不完全恢复

  1. 丢失控制文件(noresetlogs)
数据库处于开启状态,模拟丢失控制文件

[root@dbdao orcl]# mv control01.ctl control01.ctl.bak

 

[oracle@dbdao orcl]$ mv control02.ctl control02.ctl.bak

 

恢复过程

使用语句获得跟踪日志

SQL> alter database backup controlfile to trace noresetlogs;

 

Database altered.

 

在alert文件找到跟踪文件位置

alter database backup controlfile to trace noresetlogs

Backup controlfile written to trace file /u01/oracle/app/diag/rdbms/orcl/orcl/trace/orcl_ora_2169.trc

 

获得建立控制文件语句

CREATE CONTROLFILE REUSE DATABASE “ORCL” NORESETLOGS  ARCHIVELOG

MAXLOGFILES 16

MAXLOGMEMBERS 3

MAXDATAFILES 100

MAXINSTANCES 8

MAXLOGHISTORY 292

LOGFILE

GROUP 1 ‘/u01/oracle/app/oradata/orcl/redo01.log’  SIZE 50M BLOCKSIZE 512,

GROUP 2 ‘/u01/oracle/app/oradata/orcl/redo02.log’  SIZE 50M BLOCKSIZE 512,

GROUP 3 ‘/u01/oracle/app/oradata/orcl/redo03.log’  SIZE 50M BLOCKSIZE 512

— STANDBY LOGFILE

DATAFILE

‘/u01/oracle/app/oradata/orcl/system01.dbf’,

‘/u01/oracle/app/oradata/orcl/sysaux01.dbf’,

‘/u01/oracle/app/oradata/orcl/undotbs01.dbf’,

‘/u01/oracle/app/oradata/orcl/users01.dbf’,

‘/u01/oracle/app/oradata/orcl/test01.dbf’,

‘/u01/oracle/app/oradata/orcl/test02.dbf’,

‘/u01/oracle/app/oradata/orcl/test03.dbf’

CHARACTER SET AL32UTF8

;

 

关闭数据库,启动到nomount

SQL> startup nomount

ORACLE instance started.

 

Total System Global Area  839282688 bytes

Fixed Size              2233000 bytes

Variable Size                553651544 bytes

Database Buffers      281018368 bytes

Redo Buffers                 2379776 bytes

 

执行上面的语句,生成控制文件

 

SQL> alter database open;

 

Database altered.

 

丢失控制文件(resetlogs)

关闭数据库,启动到nomount状态

SQL> shutdown abort

ORACLE instance shut down.

SQL> startup nomount

ORACLE instance started.

 

Total System Global Area  839282688 bytes

Fixed Size              2233000 bytes

Variable Size                553651544 bytes

Database Buffers      281018368 bytes

Redo Buffers                 2379776 bytes

 

RMAN> restore controlfile from ‘/u01/oracle/app/fast_recovery_area/ORCL/autobackup/2016_07_19/o1_mf_s_917619287_crvkbqtt_.bkp’;

 

Starting restore at 19-JUL-16

using target database control file instead of recovery catalog

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=1 device type=DISK

 

channel ORA_DISK_1: restoring control file

channel ORA_DISK_1: restore complete, elapsed time: 00:00:01

output file name=/u01/oracle/app/oradata/orcl/control01.ctl

output file name=/u01/oracle/app/fast_recovery_area/orcl/control02.ctl

Finished restore at 19-JUL-16

 

RMAN> startup mount

 

database is already started

database mounted

 

RMAN> recover database;

 

Starting recover at 19-JUL-16

Starting implicit crosscheck backup at 19-JUL-16

using target database control file instead of recovery catalog

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=20 device type=DISK

Crosschecked 3 objects

Finished implicit crosscheck backup at 19-JUL-16

 

Starting implicit crosscheck copy at 19-JUL-16

using channel ORA_DISK_1

Finished implicit crosscheck copy at 19-JUL-16

 

searching for all files in the recovery area

cataloging files…

cataloging done

 

List of Cataloged Files

=======================

File Name: /u01/oracle/app/fast_recovery_area/ORCL/autobackup/2016_07_19/o1_mf_s_917619287_crvkbqtt_.bkp

File Name: /u01/oracle/app/fast_recovery_area/ORCL/archivelog/2016_07_19/o1_mf_1_98_crvkzy4c_.arc

File Name: /u01/oracle/app/fast_recovery_area/ORCL/archivelog/2016_07_19/o1_mf_1_99_crvkzy6d_.arc

File Name: /u01/oracle/app/fast_recovery_area/ORCL/archivelog/2016_07_19/o1_mf_1_100_crvkzyg9_.arc

 

using channel ORA_DISK_1

 

starting media recovery

 

archived log for thread 1 with sequence 100 is already on disk as file /u01/oracle/app/fast_recovery_area/ORCL/archivelog/2016_07_19/o1_mf_1_100_crvkzyg9_.arc

archived log for thread 1 with sequence 101 is already on disk as file /u01/oracle/app/oradata/orcl/redo02.log

archived log file name=/u01/oracle/app/fast_recovery_area/ORCL/archivelog/2016_07_19/o1_mf_1_100_crvkzyg9_.arc thread=1 sequence=100

archived log file name=/u01/oracle/app/oradata/orcl/redo02.log thread=1 sequence=101

media recovery complete, elapsed time: 00:00:01

Finished recover at 19-JUL-16

 

 

RMAN> alter database open resetlogs;

 

database opened

 

 

  1. Active状态的已归档的在线日志
SQL>

select l.group#,l.thread#, lf.member,l.status,l.archived from v$log l , v$logfile lf

2  where l.group# = lf.group#;

 

GROUP#    THREAD# MEMBER                                        STATUS      ARC

———- ———- ——————————————          —————-   —

3         1 /u01/oracle/app/oradata/orcl/redo03.log   CURRENT         NO

2         1 /u01/oracle/app/oradata/orcl/redo02.log   ACTIVE                YES

1         1 /u01/oracle/app/oradata/orcl/redo01.log   INACTIVE         YES

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  1. 用户误操作(删除一个表)在同一个主机上恢复
模拟错误,drop一个表

SQL> drop  table auchan.torder;

 

Table dropped.

 

模拟恢复过程

1.       新建参数文件,并修改部分参数

[oracle@dbdao01 dbs]$ vi initaux.ora

db_name=’dbdao01′

service_names=’aux’

db_unique_name=’aux’

control_files=’/u01/app/oracle/oradata/aux/control01.ctl’

2.       设置ORACLE_SID

[oracle@dbdao01 ~]$ export ORACLE_SID=aux

3.       创建密码文件

[oracle@dbdao01 dbs]$ orapwd file=orapwdaux password=oracle entries=30

4.       配置tnsname和listener

在listener.ora添加

SID_LIST_LISTENER =

(SID_LIST =

(SID_DESC =

(GLOBAL_DBNAME = aux)

(ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1)

(SID_NAME = aux )

)

)

在tnsname.ora添加

aux =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = dbdao01)(PORT = 1521))

(CONNECT_DATA =

(SERVER = DEDICATED)

(SERVICE_NAME = aux)

 

重启监听,配置完毕

5.       连接rman从dbdao01中恢复控制文件到aux库(以启动到nomount,用之前的参数文件)

[oracle@dbdao01 admin]$ rman target / catalog rman/oracle@dbdao02

RMAN> run{

2> set until time “TO_DATE(’21/JUL/2016 14:00:00′,’DD/MON/YYYY HH24:MI:SS’)”;

3> restore controlfile  to ‘/u01/app/oracle/oradata/aux/control01.ctl’ from ‘/u01/app/oracle/fast_recovery_area/DBDAO01/autobackup/2016_07_21/o1_mf_s_917793936_cs0vwjpk_.bkp’;

4> }

6.       恢复数据库到aux实例上

[oracle@dbdao01 ~]$ rman target / nocatalog(为了使用控制文件上的备份信息)

 

run{

startup mount

set until time “TO_DATE(’21/JUL/2016 15:00:00′,’DD/MON/YYYY HH24:MI:SS’)”;

set newname for datafile 1 to ‘/u01/app/oracle/oradata/aux/system01.dbf’;

set newname for datafile 2 to ‘/u01/app/oracle/oradata/aux/sysaux01.dbf’;

set newname for datafile 3 to ‘/u01/app/oracle/oradata/aux/undotabs01.dbf’;

set newname for datafile 4 to ‘/u01/app/oracle/oradata/aux/users01.dbf’;

set newname for datafile 5 to ‘/u01/app/oracle/oradata/aux/example01.dbf’;

restore datafile 1,2,3,4,5;

switch datafile all;

sql “alter database datafile 1,2,3,4,5 online”;

recover database;

sql “alter database rename file ”/u01/app/oracle/oradata/dbdao01/redo01.log” to ”/u01/app/oracle/oradata/aux/redo01.log””;

sql “alter database rename file ”/u01/app/oracle/oradata/dbdao01/redo02.log” to ”/u01/app/oracle/oradata/aux/redo02.log””;

sql “alter database rename file ”/u01/app/oracle/oradata/dbdao01/redo03.log” to ”/u01/app/oracle/oradata/aux/redo03.log””;

alter database open resetlogs;

}

7.       将丢失的表导出再倒回原来的数据库

SQL> select count(*) from auchan.torder;

 

COUNT(*)

———-

91982

数据已经恢复,将表导出

[oracle@dbdao01 ~]$ exp auchan/oracle file=torder.dmp tables=torder

再导入原来的库中

[oracle@dbdao01 ~]$ imp auchan/oracle file=torder.dmp fromuser=auchan touser=auchan tables=torder

 

在查询生产库

SQL> select count(*) from auchan.torder;

 

COUNT(*)

———-

91982

8.       最后删除辅助实例

过程略

  1. 用户误操作恢复到不同的主机上

步骤和上面基本相同,除了恢复控制文件时,恢复到一个指定位置,然后上传到要进行恢复的主机上。

 

  1. 恢复整个表空间
  2. 挑选目标时间,一般根据OracleFlashback Query , Oracle Transaction Query 和Oracle Flashback Version Query去寻找时间点。
  3. 分析数据关联

select * from sys.ts_pitr_check  where ( ts1_name in (‘torder’) and ts2_name not in (‘torder’)) or ( ts1_name not in (‘torder’)  and ts2_name in (‘torder’) );

  1. 确认执行后会丢失的对象

select owner, name, tablespace_name ,to_char(creation_time, ‘yyyy-mm- dd:hh24:mi:ss’) from ts_pitr_objects_to_be_dropped where tablespace_name in (‘users’,’tools’) and creation_time > to_date(’01-jan-09:15:04:00′,’yy-mon-dd:hh24:mi:ss’) order by tablespace_name, creation_time;

 

恢复数据库到新的主机上

  1. 记录源库dbid
SQL> select dbid from v$database;

 

DBID

———-

3800849824

 

  1. 获得源库的文件列表
SQL> col name for a60

SQL> col member for a60

SQL> select file# as “file/grp#”, name from v$datafile;

 

file/grp# NAME

———- ————————————————————

1 /u01/app/oracle/oradata/dbdao01/system01.dbf

2 /u01/app/oracle/oradata/dbdao01/sysaux01.dbf

3 /u01/app/oracle/oradata/dbdao01/undotbs01.dbf

4 /u01/app/oracle/oradata/dbdao01/users01.dbf

5 /u01/app/oracle/oradata/dbdao01/example01.dbf

 

SQL> select group#,member from v$logfile;

 

GROUP# MEMBER

———- ————————————————————

3 /u01/app/oracle/oradata/dbdao01/redo03.log

2 /u01/app/oracle/oradata/dbdao01/redo02.log

1 /u01/app/oracle/oradata/dbdao01/redo01.log

 

  1. 复制源库的参数文件上传到新主机上
[oracle@dbdao01 dbs]$ scp initdbdao01.ora dbdao02:/u01/app/oracle/product/11.2.0/db_1/dbs/

 

 

  1. 上传备份集到新主机,和源库相同位置
[oracle@dbdao01 2016_07_21]$ scp * dbdao02:/u01/app/oracle/fast_recovery_area/DBDAO01/autobackup/2016_07_21/

oracle@dbdao02’s password:

o1_mf_s_917793936_cs0vwjpk_.bkp 100% 9600KB   9.4MB/s   00:00

o1_mf_s_917796181_cs0y2o7q_.bkp 100% 9600KB   9.4MB/s   00:00

 

[oracle@dbdao01 DBDAO01]$ scp backupset/2016_07_21/* dbdao02:/u01/app/oracle/fast_recovery_area/DBDAO02/backupset

oracle@dbdao02’s password:

o1_mf_annnn_TAG20160721T144230_ 100% 4095KB   4.0MB/s   00:00

o1_mf_annnn_TAG20160721T144534_ 100%   22KB  21.5KB/s   00:00

o1_mf_ncnnf_TAG20160721T152257_ 100% 9568KB   9.3MB/s   00:00

o1_mf_nnndf_TAG20160721T144232_ 100% 2115MB  24.6MB/s   01:26

 

  1. 在新主机上进行恢复
[oracle@dbdao02 ~]$ export ORACLE_SID=dbdao01

[oracle@dbdao02 ~]$ rman target / nocatalog

RMAN> set dbid 3800849824

 

executing command: SET DBID

RMAN> startup nomount

 

Oracle instance started

 

RMAN> restore controlfile from ‘/u01/app/oracle/fast_recovery_area/DBDAO01/autobackup/2016_07_21/o1_mf_s_917793936_cs0vwjpk_.bkp’;

output file name=/u01/app/oracle/oradata/dbdao01/control01.ctl

output file name=/u01/app/oracle/fast_recovery_area/dbdao01/control02.ctl

Finished restore at 21-JUL-16

 

RMAN> alter database mount;

 

database mounted

released channel: ORA_DISK_1

 

 

因为路径都完全相同,所以这里直接恢复即可

RMAN> run{

set until scn 1090728;

restore database;

switch datafile all;

recover database;

alter database open resetlogs;

}

 

database opened

 

恢复成功。

 

 

 

恢复数据库在相同的主机

基本同上一个实验,注意设置新的dbid

 

诗檀软件帮助广州某制造企业恢复ORACLE数据库

广州某制造企业的金蝶SHR人力管理系统的后台Oracle数据库出现无法打开OPEN DATABASE的问题:

 

ORA-00600: internal error code, arguments: [3020], [2], [99072], [8487
[], [], [], [], [], [], []
ORA-10567: Redo is inconsistent with data block (file# 2, block# 99072
offset is 811597824 bytes)
ORA-10564: tablespace SYSAUX
ORA-01110: data file 2: 'E:\APP\ADMINISTRATOR\ORADATA\ORCL\SYSAUX01.DB
ORA-10560: block type 'FIRST LEVEL BITMAP BLOCK'

诗檀软件工程师王工基于ORACLE底层数据块至少快速修复了该SHR后台 ORACLE数据库。

金蝶 EAS 财务、SHR人力 系统后台 ORACLE损坏请找 诗檀软件快速恢复!

 

 

 

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 : 13764045638   QQ号:47079569    邮箱:service@parnassusdata.com

【MySQL学生手册】binary备份 vs 文本备份

本文地址:https://www.askmac.cn/archives/mysql-binary-vs-text-backup.html

 

 

11.2 binary备份 vs 文本备份

 

当备份数据库时,你有两种备份格式可选:

  • 二进制(binary)备份是一种对数据库中存储的内容文件的拷贝。这种拷贝实际上使得备份文件格式和MySQL在磁盘上存储的数据库文件格式保持了完全一致。因此此类数据库恢复则涉及将这些文件拷贝回它原有的位置。建立binary备份的技术包括使用文件拷贝命令(如cp或tar),mysqlhotcopy以及InnoDB Hot Backup**。
    ** 需要注意的是mysqlhotcopy从MySQL 5.7及其之后就被去除了,相关功能被融合到了其企业版MySQL Enterprise Backup工具mysqlbackup中。而InnoDB Hot Backup原先是商用软件的一部分,在MySQL Enterprise Backup 3.9之后其相应工具也被融合入mysqlbackup中。
  • 文本备份则是将数据库内容导出(dump)至文件文件中。恢复则涉及到通过处理这些文件的内容将数据返回到数据库中。生成文本备份的技术包括了使用SELECT … INTO OUTFILE 的SQL语句,mysqldump工具等。

 

这两种备份格式有其不同的优缺点。通常选择使用何种备份的考虑因素是对速度和便携性之间的权衡。

 

由于二进制备份仅是对文件进行拷贝操作,它不需要了解文件中的内部结构,因此在速度上这种备份速度会更快。然而,如果需要将这种备份传输到另一个使用不同架构的机器上,那么文件就需要更多考虑二进制的便携性。意思就是这些文件需要平台无关化才行,这样你才能直接拷贝它们,从一个MySQL服务端传输到另一个处于不同服务器上的数据库中,而且这第二个服务端需要能够没有任何问题地访问这些文件的内容。使用二进制备份方法,你还需要确保在进行备份的时候,服务端不会对在被拷贝的文件进行修改。

[Read more…]

Oracle PRM-DUL Undelete Oracle record/rows

Download PRM-DUL http://www.parnassusdata.com/en

On scenarios without valid physical or logical backups, when a mistaken delete occurred in Oracle, it will be given priority to use techniques such as flashback or logminer to recover the data rows in Oracle tables in general, but in many cases even flashback or logminer could not turn the tide.

For the row piece in the underlying data block of Oracle, delete operation only modify the row flag and mark them as deleted. It allows records of the subsequent INSERT to override these data marked as delete, and also allows to destroy the structure of these data that are deleted. In other words, if no operations has been done on tables after delete, it is possible to read the complete data by directly reading those records that are marked as deleted in blocks.

 

In a word, whether it can recover the deleted data or not all depends on whether the deleted data rows in oracle block on the disk have been eventually cleared or not.

 

As soon as it has not been cleared, ORACLE PRM-DUL can attempt to recover the data, and the specific steps has little difference with the ordinary data dictionary mode.

 

Start up the PRM – DUL, click the restore wizard in dictionary mode
prm-undelete1

prm-undelete2

 

 

 

prm-undelete4

prm-undelete5

 

Add all of the Oracle data files, no TEMPFILE, UNDO data files, control files, log files is required.

prm-undelete6

 

Click the load button, PRM will automatically load the data dictionary, i.e. bootstrap operation

 

prm-undelete7

ow on the left of PRM, you will see the object tree, select the corresponding data table under the user that you need to recover, right-click the object and then select unload deleted data.

prm-undelete8

 

prm-undelete9

After completing the recovery of the deleted data, PRM-DUL will write the data to the location of File path in the picture above, the Sample data recovery is as follows.

prm-undelete10

 

沪ICP备14014813号-2

沪公网安备 31010802001379号