101214手动 oracle.docx
- 文档编号:6007316
- 上传时间:2023-01-02
- 格式:DOCX
- 页数:23
- 大小:44.16KB
101214手动 oracle.docx
《101214手动 oracle.docx》由会员分享,可在线阅读,更多相关《101214手动 oracle.docx(23页珍藏版)》请在冰豆网上搜索。
101214手动oracle
相当于第10、12、14章
ORACLE的介质恢复,我们已经说过好多次,是以备份的数据文件为基础,在它上面应用所有的重做记录。
介质恢复的两大要素,一是,要有以前的备份。
二,要有相应的日志文件。
如果你没有冷备或热备的数据文件,或你的归档日志不完全,那么,多数情况下数据库将是无法完全恢复的。
注意,备份的数据文件和日志文件,可以好不夸张的说,这是DBA的两个最重要的东西。
因为在DBA所有任务中,备份是最重要的任务。
有很多人经常问调优和备份相比,谁跟重要。
当然是备份。
如果你不能保障数据的安全性,那么,你的数据库再快,又有什么用。
因此,作为DBA,一定要想办法,保障在出现各种意外时,有可有的数据文件的备份,和尽量完整的日志文件。
下面,我们用几个实例,来了解一下ORACLE的恢复流程。
首先介绍一下恢复命令。
一、恢复命令
1.在MOUNT阶段恢复数据库:
Recoverdatabase:
恢复数据库的所有数据文件。
即,从每个数据文件头,读出重做记录地址RBA,在日志文件中,以此为起点进行恢复,直到当前日志文件的未尾。
2.在OPEN阶段恢复某一表空间所属的数据文件:
Recovertablespace表空间名:
对指定表空间所属的数据文件,进行恢复操作。
3.在MOUNT、OPEN阶段恢复某一数据文件:
Recoverdatafile‘数据文件名’:
恢复指定的数据文件。
二、日志文件
恢复操作,离不开日志文件。
ORACLE将自动到LOG_ARCHIVE_DEST_n指定的位置中,寻找归档日志文件。
应用完所有归档日志后,当前日志文件中还会重做记录需要应用。
ORACLE也可以根据内部数据字典中记录的信息,自动的寻找当前日志文件。
如果ORACLE找不到了它所需要的某个日志文件,它会用信息提示信息,让DBA自己输入此日志文件的位置和名字。
第二节备份情况介绍
备份情况,企业采用热备的方式,每个周一的晚间,是数据库最不繁忙的时刻。
DBA利用此时间,对数据库进行热备。
备份文件有所有的数据文件、控制文件和参数文件。
在热备完成后,马上再把热备的文件复制到另外的存储设备中。
这一份额外的热备,将根据情况保留一至三个月左右即可删除。
每个周一进行的热备,都将覆盖上周一的热备。
这样同样的备份,在最近这一周内,将会有两份。
一周前的热备,并不马上删除,还会保留一至三个月,以备不时之需。
因为有时候,需要将数据库恢复到以前的某个状态。
如果客户要求两个月前某个表的数据。
如果你只有一周前的热备文件,是无法将数据库恢复到两个月前的。
所有,保留较远时间前的热备,有时候还是有一定作用的。
而且,近一周的数据,有两份备份,这样更安全一些。
万一其中一份损坏了,我们还一份可以使用。
当然,这还要看公司是否重视数据的安全性。
每多留一份备份,这额外的备份每多留一段时间,这都要占用额外的存储设备。
如果企业没有准备多余的存储设备,也不打算去准备。
那么,只保留一份备份也是可以的。
另外,归档日志文件必须以某个时间备份的数据文件为基础,将归档日志中的重做记录,按顺序应用到数据文件中。
假如企业中保留的最早的数据文件的备份是半年前的。
超过半年前的归档日志文件,将没有什么意义了。
可以删除。
因为日志只能向后应用,而不能向前应用。
好了,关于备份的情况就是这样,有周一时的热备和完整的归档日志文件。
下面,我们讨论几种常见的恢复情况。
第三节恢复案例1
一、情况描述
用户正在正常操作。
用户在EXAM1表空间中,创建了一个表AAA:
sid=42pid=22>createtableaaatablespaceexam1asselect*fromdba_objectswhere0=1;
表已创建。
sid=42pid=22>insert/*+append*/intoaaaselect*fromdba_objects;
已创建11309行。
sid=42pid=22>commit;
提交完成。
然后,用户又在EXAM1表空间中,创建了一个表BBB,并且它的状态是NOLOGGING。
sid=42pid=22>createtablebbbtablespaceexam1nologgingasselect*fromdba_objectswhere0=1;
表已创建。
sid=42pid=22>insert/*+append*/intobbbselect*fromdba_objects;
已创建11310行。
sid=42pid=22>commit;
提交完成。
然后,用户以运行了一些其他操作。
假设这时,EXAM1表空间数据文件所在的磁盘损坏了,因引了数据文件的损坏。
这将出现什么样的情况呢?
为了模拟磁盘损坏,我使用WinHex这款十六进制编号器,将EXAM1表空间的数据文件中E:
\ORACLE\EXAM10G_1.DBF修改一下。
我将数据文件的长度截断,模拟数据的丢失。
现在,回到ORACLE,现在数据库一切正常,通常,只要损坏的不是SYSTEM系统表空间中的数据文件和当前还原表空间,数据库都能正常运行,等待什么时候访问到损坏的数据据文件时,错误就显示出来了。
下面,我显示一下AAA或BBB表:
sid=42pid=22>selectcount(*)fromaaa;
selectcount(*)fromaaa
*
第1行出现错误:
ORA-01115:
从文件5读取块时出现IO错误(块#94)
ORA-01110:
数据文件5:
'E:
\ORACLE\EXAM10G_1.DBF'
ORA-27091:
无法将I/O排队
ORA-27070:
异步读取/写入失败
OSD-04006:
ReadFile()失败,无法读取文件
O/S-Error:
(OS38)到达文件结尾。
错误的数据文件在E:
盘的某个目录中,出现了这样的问题,我们先检查一下E盘是否有损坏,还有没有其他的数据文件受损。
在更换无故障的磁盘后,就可以开始还原数据文件了。
如果是由于软件错误造成的数据文件丢失,直接还原数据文件就行。
通过dba_data_files视图,显示一下失损数据文件
SQL>selectTABLESPACE_NAME,file_name,ONLINE_STATUS
fromdba_data_fileswherefile_name='E:
\ORACLE\EXAM10G_1.DBF';
TABLESPACE_NAMEFILE_NAMEONLINE_
-------------------------------------------------------------------------------------------------
EXAM1E:
\ORACLE\EXAM10G_1.DBFONLINE
E:
\ORACLE\EXAM10G_1.DBF还处在联机状态。
数据文件的恢复要求必许被还原、恢复的数据文件处于脱机状态。
如下命令将指定数据文件至于脱机状态:
alterdatabasedatafile'数据文件名'offline;
当日志切换时或手动执行完全检查时,CKPT进程也会检测到数据文件有严重错误,它会自动将数据文件的状态定为RECOVER状态。
下面我手动的要求ORACLE执行完全检查点:
sid=27pid=26>altersystemcheckpoint;
系统已更改。
再查询DBA_DATA_FILES视图:
sid=42pid=22>colfile_namefora60
sid=42pid=22>selectTABLESPACE_NAME,file_name,ONLINE_STATUSfromdba_data_fileswherefile_name='E:
\ORACLE\EXAM10G_1.DBF';
TABLESPACE_NAMEFILE_NAMEONLINE_
-------------------------------------------------------------------------------------------------
EXAM1E:
\ORACLE\EXAM10G_1.DBFRECOVER
文件状态已经是RECOVER了。
这种状态这脱机差不多,都是不再允许用户访问此数据文件。
如果是CKPT进程检查到文件错误,我们还可以在V$RECOVER_FILE中看到错误信息:
sid=42pid=22>select*fromv$recover_file;
FILE#ONLINEONLINE_ERRORCHANGE#TIME
------------------------------------------------------------------------------------------------------
5FFLINEOFFLINEWRONGFILETYPE0
从V$recover_file可以看到出错误的文件号,是5号文件。
ERROR列是错误的原因,这个列无所谓。
无论什么原因,下面我们都要进行还原、恢复。
二、还原
将热备的EXAM10G_1.DBF文件复制过来,权覆盖出错的文件。
这一步就是还原了。
还原完成后,通过v$recovery_log视图,可以看到如果需要成功恢复,都需要哪些日志文件。
sid=42pid=22>select*fromv$recovery_log;
THREAD#SEQUENCE#TIMEARCHIVE_NAME
-------------------------------------------------------------------------------
12202008-05-2611:
28:
20F:
\ORACLE\ARC\ARC00220_0646396150.001
12212008-05-2617:
10:
08F:
\ORACLE\ARC\ARC00221_0646396150.001
12222008-05-2617:
17:
40F:
\ORACLE\ARC\ARC00222_0646396150.001
显示的结果,ORACLE需要从序列号为220的日志文件开始恢复。
ORACLE可以根据热备数据文件头部的RBA,计算出需要恢复的起点。
在这里,我们热备的数据文件,它头部的RBA中,所记载的恢复的起点是:
220号日志文件。
因此这里共需要使用220、221和222号日志文件。
这些文件ORACLE已经在LOG_ARCHIVE_DEST_n参数设定的位置中找到了。
显示一下当前日志文件的序列号是多少:
sid=27pid=26>selectGROUP#,SEQUENCE#,ARChived,STATUSfromv$log;
GROUP#SEQUENCE#ARCSTATUS
---------------------------------------
1223YESINACTIVE
2224YESINACTIVE
3225NOCURRENT
当前日志文件的序列号是225。
ARChived列显示,224、223号都已经被归档了。
在归档目标位置中,可以找到224号和223号日志的归档。
我们的恢复操作,要一直应用重做记录,直到当前日志文件的最后一条重做记录。
也就是说,223、224和225号日志文件中的重做,都是需要应用的。
但归档文件ORACLE只使用到222。
这是因为ORACLE的恢复尽量使用数据库的重做日志文件,如果重做日志文件无法提供指定序列号的日志信息,ORACLE才会再去归档日志文件中寻找。
这里要使数据文件恢复的最新的状态,需要使用的日志有220号、221、222、223、224和225。
现在223、224和225号日志文件,分别是重做日志文件组1、组2和组3,因此223、224和225不再使用归档日志,而是使用重做日志。
三、恢复
当前数据库处于OPEN阶段,我们可以使用Recovertablespace表空间名命令,恢复整个EXAM1表空间。
也可以使用Recoverdatafile‘数据文件名’命令,只恢复失损数据文件。
如果只是表空间中的个别数据文件损坏,我们应该针对数据文件进行恢复。
如果表空间中大多数数据文件都损坏了,我们可以针对表空间进行恢复。
如果是针对表空间进行恢复的话,表空间中未受损的文件不会有任何影响。
好,下面我针对数据文件进行恢复,只恢复受损的数据文件:
sid=27pid=26>recoverdatafile'E:
\ORACLE\EXAM10G_1.DBF';
ORA-00279:
更改1227831(在05/26/200814:
24:
25生成)对于线程1是必需的
ORA-00289:
建议:
F:
\ORACLE\ARC\ARC00220_0646396150.001
ORA-00280:
更改1227831(用于线程1)在序列#220中
指定日志:
{
(到这里会暂停,ORACLE已经找到了应该应用的日志文件,如果你有更好的位置,可以在此处指定,如果就使用ORACLE找到的,直接敲回车键)
ORA-00279:
更改1249633(在05/26/200817:
10:
08生成)对于线程1是必需的
ORA-00289:
建议:
F:
\ORACLE\ARC\ARC00221_0646396150.001
ORA-00280:
更改1249633(用于线程1)在序列#221中
ORA-00278:
此恢复不再需要日志文件'F:
\ORACLE\ARC\ARC00220_0646396150.001'
指定日志:
{
(应用221号日志,敲回车键)
ORA-00279:
更改1270231(在05/26/200817:
17:
40生成)对于线程1是必需的
ORA-00289:
建议:
F:
\ORACLE\ARC\ARC00222_0646396150.001
ORA-00280:
更改1270231(用于线程1)在序列#222中
ORA-00278:
此恢复不再需要日志文件'F:
\ORACLE\ARC\ARC00221_0646396150.001'
指定日志:
{
(应用222号日志,敲回车键)
已应用的日志。
完成介质恢复。
剩下的223、224和225,ORACLE找到的重做日志文件,不再显示说明。
如果觉得每次应用归档日志时,都要敲一次回车,这样太麻繁,可以在恢复前使用setautorecoveryon命令,它的意思是自动应用日志。
也可以在RECOVER命令后,加一个AUTOMATIC,命令如下:
recoverautomaticdatafile'E:
\ORACLE\EXAM10G_1.DBF';
恢复完成了,再查询v$recovery_log和v$recover_FILE,都变成了空:
sid=42pid=22>select*fromv$recovery_log;
未选定行
sid=42pid=22>select*fromv$recover_file;
未选定行
也就是没有需要恢复的文件了。
最后一步,将数据文件的状态设为联机:
sid=27pid=26>alterdatabasedatafile'E:
\ORACLE\EXAM10G_1.DBF'online;
数据库已更改。
恢复结束。
四、检查恢复结果
在数据文件损坏前,我曾经向EXAM1表空间中创建了两个表,AAA和BBB,还使用批量插入,分别插入了一些行。
其中AAA是在正常状态下进行的插入。
而BBB则是在NOLOGGING状态下,批量插入的行。
下面分别查询一下AAA和BBB:
sid=42pid=22>selectcount(*)fromaaa;
COUNT(*)
----------
11311
查询AAA正常。
AAA已经正常恢复。
sid=42pid=22>selectcount(*)frombbb;
selectcount(*)frombbb
*
第1行出现错误:
ORA-01578:
ORACLE数据块损坏(文件号5,块号172)
ORA-01110:
数据文件5:
'E:
\ORACLE\EXAM10G_1.DBF'
ORA-26040:
数据块是使用NOLOGGING选项加载的
BBB因为是以NOLOGGING插入过行,这个操作因为不成生重做,是不可恢复的。
因此这里显示BBB出错。
为了避免这种情况,建议我们在使用过有效的NOLOGGING操作后,马上热备数据文件。
五、系统表空间和还原表空间的损坏
如果损坏的文件属于系统表空间或还原表空间,数据库将会马上崩溃。
使用WinHex将系统表空间的数据文件破坏掉,然后,我手动触发一次完全检查点:
sid=27pid=26>altersystemcheckpoint;
altersystemcheckpoint
*
第1行出现错误:
ORA-01243:
系统表空间文件出现介质故障
检查到了系统表空间的故障,此时数据库已经被关闭了。
我们随便发布一个查询看看:
sid=27pid=26>select*fromv$recover_file;
ERROR:
ORA-03114:
未连接到ORALCE
我们需要先重新连接:
sid=27pid=26>conn/assysdba
已连接到空闲例程。
再把数据库启动到MOUNT阶段:
idle>startupmount;
ORA-32004:
obsoleteand/ordeprecatedparameter(s)specified
ORACLE例程已经启动。
TotalSystemGlobalArea104857600bytes
FixedSize1247540bytes
VariableSize67110604bytes
DatabaseBuffers33554432bytes
RedoBuffers2945024bytes
数据库装载完毕。
从热备中还原受损文件后,使用下面的命令进行恢复:
idle>recoverautomaticdatafile'F:
\oracle\product\10.2.0\db_1\oradata\three10g\SYSTEM01.DBF';
完成介质恢复。
完成恢复后,重要打开数据库:
idle>alterdatabaseopen;
数据库已更改。
好,恢复结束。
看到没有,只有我们有备份的数据文件,还要相应的归档日志、重做日志,无论数据库出现什么情况都不怕。
下面,我们来看一个没有备份的数据文件时的情况。
第四节恢复案例2
一、情况描述
用户在周三时创建了一个表空间,如下:
idle>createtablespaceexam2datafile'e:
\oracle\exam2_1.dbf'size5m;
表空间已创建。
然后,陆续向此表空间中,插入了一些重要数据:
sid=42pid=22>connuplooking/abcde
已连接。
sid=42pid=22>createtableccctablespaceexam2asselect*fromdba_objectswhererownum<=10;
表已创建。
在周六时,用户访问CCC表遇到错误(为了模拟错误,我仍然使用WinHex破坏数据文件e:
\oracle\exam2_1.dbf):
sid=42pid=22>selectcount(*)fromccc;
selectcount(*)fromccc
*
第1行出现错误:
ORA-00376:
此时无法读取文件2
ORA-01110:
数据文件2:
'E:
\ORACLE\EXAM2_1.DBF'
经检查,由于磁盘故障,EXAM2表空间的数据文件EXAM2_1.DBF损坏了。
但是,由于习惯上周一晚上做热备,因此,在创建完新的表空间后,DBA忘记了做热备。
现在没有EXAM2_1.DBF的备份文件。
但是,有此数据文件创建以来的日志文件。
下面,如何恢复呢?
步1:
按照原来文件的规格,再创建一个新的文件:
idle>alterdatabasecreatedatafile'e:
\oracle\exam2_1.dbf'as'e:
\oracle\exam2_1.dbf';
数据库已更改。
注意,AS'e:
\oracle\exam2_1.dbf'的意思,就是按原来的'e:
\oracle\exam2_1.dbf',创建一个新的文件。
新文件的位置名字可以和原文件不一样。
步2:
确保此数据文件是脱机或RECOVER状态,可以如下查看一下:
sid=42pid=22>selectTABLESPACE_NAME,file_name,ONLINE_STATUSfromdba_data_fileswherefile_name='E:
\ORACLE\EXAM2_1.DBF';
TABLESPACE_NAMEFILE_NAMEONLINE_
-------------------------------------------------------------------------------------------------
EXAM2E:
\ORACLE\EXAM2_1.DBFRECOVER
步3:
介质恢复:
idle>recoverautomaticdatafile'e:
\oracle\exam2_1.dbf';
完成介质恢复。
恢复完成后,数据文件的状态,由RECOVERY变为了脱机:
sid=42pid=22>selectTABLESPACE_NAME,file_name,ONLINE_STATUSfromdba_data_fileswherefile_name='E:
\ORACLE\EXAM2_1.DBF';
TABLESPACE_NAMEFILE_NAMEONLINE_
-------------------------------------------------------------------------------------------------
EXAM2E:
\ORACLE\EXAM2_1.DBFOFFLINE
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 101214手动 oracle 101214 手动