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中
指定日志:
{=suggested|filename|AUTO|CANCEL}
（到这里会暂停，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'
指定日志:
{=suggested|filename|AUTO|CANCEL}
（应用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'
指定日志:
{=suggested|filename|AUTO|CANCEL}
（应用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
升级会员 