189 8069 5689
这篇文章主要介绍“Oracle恢复和介质恢复的方法是什么”，在日常操作中，相信很多人在Oracle恢复和介质恢复的方法是什么问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”Oracle恢复和介质恢复的方法是什么”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！
创新互联建站服务项目包括海勃湾网站建设、海勃湾网站制作、海勃湾网页制作以及海勃湾网络营销策划等。多年来，我们专注于互联网行业，利用自身积累的技术优势、行业经验、深度合作伙伴关系等，向广大中小型企业、政府机构等提供互联网行业的解决方案，海勃湾网站推广取得了明显的社会效益与经济效益。目前，我们服务的客户以成都为中心已经辐射到海勃湾省份的部分城市，未来相信会继续扩大服务区域并继续获得客户的支持与信任！
一、恢复解决方案
错误类型及解决方案
错误分类 | 恢复解决方案 |
介质失败 | 如果是少量的块损坏，使用块介质恢复；如果是大量的块、数据文件、表空间的损坏，可能需要对损坏的数据文件或者表空间执行完全恢复；如果是归档Redo日志文件或者联机Redo日志文件的丢失，那么只需要不完全恢复方式。 |
逻辑损坏 | 如果是程序员错误导致出现的问题，可通过补丁应用修复问题。对于无法修复的问题，也可采用介质恢复手段来恢复数据。 |
用户错误 | 根据不同用户错误，选择不同的Flashback技术恢复，使用Flashback技术恢复用户错误是首选方案。如果Flashback不能很好的恢复数据再考虑使用介质恢复或者表空间时间点恢复。 |
注意：恢复依赖于备份，当生产环境中部署完成就应该确保有一次数据库的全库备份，且确保归档Redo日志被打开。
二、SCN时间机制
SCN（System Change Number，系统改变号）是Oracle内容非常重要的时间机制，一致性、数据恢复都与SCN有着非常密切的关系。Oracle启动时，也是通过SCN的验证来确认数据库是否需要执行实例恢复的。虽然RAC有多个实例，但是只有一个数据库，SCN是对应数据库级别的改变号，所以在不同的实例产生的SCN都必须是唯一的、有序的，这是由SCN生成器完成的工作。系统时间和SCN之间可以非常容易的相互转换，下面是系统时间和SCN相互转换的例子：
SQL> select timestamp_to_scn(sysdate) from dual;
TIMESTAMP_TO_SCN(SYSDATE)
-------------------------
6980593
SQL> select scn_to_timestamp(6980593) from dual;
SCN_TO_ TIMESTAMP (6980593)
-------------------------
02-DES-13 11.12.21.000000000 PM
SQL>
以下为几种常见的SCN：
? 检查点SCN
查询当前最近的检查点SCN：
SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
3.6555E+12
SQL>
每执行一次检查点就由CKPT进程来更新，这个SCN保存在控制文件中。检查点的执行能够确保检查点执行时刻数据的完整性和一致性。实例恢复也是从上一次检查点开始进行恢复，检查点执行的频率决定了Crash恢复或者实例恢复需要花费的时间。当发生日志切换或者请求的SGA空间不足等情况时就会触发检查点。发生检查点，DBWn进程会将所有的脏数据写回磁盘，从而能够确保已提交的一致性数据被写回磁盘。单个联机Redo日志文件越大，发生检查点的间隔时间可能越长，实例恢复的时间也相应地增长，日志文件的丢失也会导致更多的数据丢失。
? 最新SCN
执行以下SQL语句查看数据库最新的SCN：
SQL> select current_scn from v$database;
CURRENT_SCN
------------
3.6555E+12
SQL>
该SCN是最新生成的全局SCN，它在不断更新，并且只会增大不会减小。
? 数据文件SCN
执行以下SQL查看所有数据文件的SCN：
SQL> select checkpoint_change# from v$datafile;
CHECKPOINT_CHANGE#
------------------
3.6555E+12
3.6555E+12
3.6555E+12
3.6555E+12
3.6555E+12
3.6555E+12
6 rows selected.
SQL>
每个数据文件都有一个数据文件SCN，每执行一次检查点便由CKPT进程来更新一次，该SCN保存在控制文件中。
? 启动SCN
执行以下SQL语句查询所有数据文件的启动SCN：
SQL> select checkpoint_change# from v$datafile_header;
CHECKPOINT_CHANGE#
------------------
3.6555E+12
3.6555E+12
3.6555E+12
3.6555E+12
3.6555E+12
3.6555E+12
6 rows selected.
SQL>
每个数据文件都有一个启动SCN，没执行一次检查点都由CKPT进程来更新一次，该SCN存储在数据文件头中。
? 终止SCN
执行下面SQL语句查询所有数据文件的终止SCN：
SQL> select last_change# from v$datafile;
LAST_CHANGE#
------------
6 rows selected.
SQL>
每个数据文件都有一个终止SCN，没执行一次检查点都由CKPT进程更新一次。该SCN保存在控制文件中，当数据库打开时，由于没有终止SCN存在，所以看到的是空，表示无穷大。
数据库启动过程中，首先会检查控制文件和数据文件的检查点执行次数是否一致，如果不一致需要对数据文件进行介质恢复。如果一致，进一步检查数据文件的启动SCN和终止SCN是否相同。如果数据库是非正常关闭，那么终止SCN肯定是空，这个时候需要执行Crash恢复或实例恢复的过程。Crash恢复或实例恢复过程需要用到联机Redo日志和UNDO表空间执行前滚和回滚操作，如果联机Redo日志或者UNDO表空间被损坏，那么数据库可能无法正常打开。如果启动SCN和终止SCN相同，那么数据库就可以正常打开。
? 日志SCN
执行以下SQL语句查询与日志相关的SCN：
SQL> select status,first_time,first_change#,next_time,next_change# from v$log;
STATUS FIRST_TIME FIRST_CHANGE# NEXT_TIME NEXT_CHANGE#
-------------------- -------------- ------------- -------------- ------------
INACTIVE 02-12鏈13 3.6555E+12 02-12鏈13 3.6555E+12
CURRENT 02-12鏈13 3.6555E+12 2.8147E+14
CURRENT 02-12鏈13 3.6555E+12 2.8147E+14
INACTIVE 02-12鏈13 3.6555E+12 02-12鏈13 3.6555E+12
SQL>
在上面查询中，first_time表示该日志组开始的时间，first_change#表示该日志组开始的SCN。可以看到，状态为current的日志组的first_change#值与前面讨论到的检查点的SCN值相同，说明发生日志切换的时候会触发检查点生成一致的检查点SCN。Next_time表述结束日志组的时间，next_change#表示结束日志组的SCN，该SCN值等于下一个日志组的first_change#值。当前日志组的next_time为空，next_change#是一个很大的值。
三、日志线程与联机Redo日志
Redo日志记录了数据的所有操作，以及操作的顺序。Redo日志主要包括联机Redo日志、归档Redo日志和Standby Redo日志三种类型，这三种类型的日志在结构上是完全相同的，只有用途不同而已。
Redo数据只有在数据库恢复时才能体现出它的价值。在RAC环境中，每个实例的归档Redo日志可以存放在本地文件系统，但是恢复的时候需要将所有节点的归档Redo日志放在一起，确保恢复的实例能够访问到所有实例的归档Redo日志。
每个实例都对应一个维护日志的日志线程（Redo thread），单实例只有一个线程号为1的日志线程。对于RAC来说，日志线程与实例的关系可以通过以下SQL语句查询得到。
1） 查询来自控制文件的线程信息：
SQL> select thread#,checkpoint_change#,last_redo_change# from gv$thread;
THREAD# CHECKPOINT_CHANGE# LAST_REDO_CHANGE#
---------- ------------------ -----------------
1 3.6555E+12 3.6555E+12
2 3.6555E+12 3.6555E+12
1 3.6555E+12 3.6555E+12
2 3.6555E+12 3.6555E+12
SQL>
2） 查询线程与实例之间的关系：
SQL> select thread#,instance_name from gv$instance;
THREAD# INSTANCE_NAME
---------- ------------------------------------------------
1 PROD1
2 PROD2
SQL>
3） 查询线程与日志组之间的关系：
SQL> select group#,thread# from v$log;
GROUP# THREAD#
---------- ----------
1 1
2 1
3 2
4 2
SQL>
四、UNDO表空间
UNDO表空间存放的是数据块的前镜像，是块的多版本数据，用于数据库恢复、一致性读和事务回滚，对数据库并发下读一致性起着重要的作用。
在RAC环境中，与连接Redo日志一样，每个实例都有自己的UNDO表空间，UNDO表空间必须放在共享存储上，每个实例都能访问到所有实例的UNDO表空间，以便任一活动实例都能执行所有实例的恢复操作。每个实例都有自己独立的UNDO表空间还能减少实例间对UNDO表空间的争用。
实例对应的Redo日志组由Redo线程来指定，实例对应的UNDO表空间是直接通过初始化参数文件中的参数指定。下面是参数文件中指定UNDO表空间对应实例的参数：
Prod01.undo_tablespace = ‘UNDOTBS1’
Prod02.undo_tablespace = ‘UNDOTBS2’
1. UNDO参数
l UNDO_MANAGEMENT初始化参数
UNDO_MANAGEMENT指定系统使用的UNDO空间管理模式。设置为AUTO，实例打开自动化UNDO管理模式；设置为MANUAL表示使用回滚段的手动管理模式自动UNDO管理（AUM）是从Oracle9i开始引入，以代替回滚段，也可以称为系统管理UNDO（SMU）。自动UNDO管理自动分配和管理DML操作所需空间的UNDO表空间，代替分配很多不同大小的回滚段。
l UNDO_RETENTION初始化参数
UNDO_RETENTION指定的是事务提交之后UNDO数据保留的时间。事务提交之后，UNDO数据不再需要用于回滚或者事务恢复，但一致性读可能还需要用到这些UNDO数据。
l UNDO_TABLESPACE初始化参数
每个数据库可以有多个UNDO表空间，但是对于每个实例只有一个活动的UNDO表空间。在RAC环境中，每个实例都对应一个UNDO表空间，UNDO_TABLESPACE用于指定实例对应的UNDO表空间。UNDO表空间无法进行收缩，如果UNDO表空间过大，只有通过替换的方式缩小UNDO表空间的大小。
l GUARANTEED UNDO RETENTION特性
默认guaranteed undo retention特性是禁用的，如果启动这个特性意味着数据库不能覆盖已提交但保留时间为超过undo_retention指定时间的UNDO数据。启用这个特性需要更大的UNDO表空间来支撑，如果UNDO表空间没有足够的空间会导致DML操作分配UNDO段失败。启用这个特性能够缓解出现ORA-01555错误几率，确保在一定的时间内能够使用部分Flashback特性闪回数据。执行以下SQL语句启用UNDO表空间的RETENTION特性：
SQL> alter tablespace undotbs1 retention guarantee;
2. UNDO视图
l V$undostat视图
V$undostat是v$rollstat的代替和提升，包含很多对UNDO空间的监控和统计信息。这个视图对于了解实例对UNDO空间的使用情况非常有用，能够通过监控估算出当前负载需要的UNDO表空间大小，能够根据统计信息提供建议调整UNDO_RETENTION，还能够找出长时间运行的SQL语句。在系统中，数据也使用这个视图提供的信息调整UNDO表空间的使用。只有自动化UNDO管理模式才能使用该视图。
l dba_undo_extents视图
dba_undo_extents描述了在数据中所有undo表空间包含的区间。这个视图显示UNDO中每个区间大小。执行以下SQL语句显示UNDO表空间中不同区间状态的统计信息。
l v$transaction
l dba_rollabck_segs视图
Oracle实例恢复
属性 | 描述 |
语法 | DB_BLOCK_CHECKSUM={OFF|FALSE|TYPICAL|TURE|FULL} |
默认值 | TYPICAL |
修改范围 | ALTER SESSION,ALTER SYSTEM |
只有当参数值是TYPICAL或者FULL，并且块的最后一次写是存储了一个校验和时，读取这个块，校验和才会被验证。在FULL模式，Oracle用update/delete语句改变数据之前会验证校验和，改变被应用之后还会重新计算校验和。
从Oracle Database 11g开始，大多数日志校验和都是通过前台进程产生的，同时LGWR执行其余的工作，这是为了更好地发挥CPU和缓存的效率。当这个参数设置为FULL，写日志块到磁盘之前，LGWR验证通过前台进程生成的每个日志块的校验和。在Oracle Database 11g之前的版本中，LGWR独自执行日志块校验和。数据文件块的校验和是由DBWR进程负责计算和管理的。
这个参数设置为OFF时，DBWn只为SYSTEM表空间计算校验和，不为用户表空间计算校验和。另外，此时数据库也不会执行日志的校验工作。
校验和可以使Oracle数据库察觉到磁盘、存储系统或者I/O系统引起的损坏。如果设置为FULL,DB_BLOCK_CHECKSUM也会捕捉在内存中的损坏，并停止它们对磁盘的操作。设置这个参数为TYPICAL值只会引起系统额外的1%~2%的负载，设置为FULL会引起4%~5%的负载。Oracle推荐设置DB_BLOCK_CHECKSUM为TYPICAL。为了保持向后兼容性，TRUE和FALSE值被保留，TRUE等同于TYPICAL，FALSE等同于OFF。
如果DB_BLOCK_CHECKSUM不等于FALSE值，每次读取块，Oracle计算校验和，都与存储在块头中的校验和进行对比。如下例子：
Corrupt block relative dba: 0x0380a58f (file 14,block 42383)
Bad check value found during buffer read
……
参数2 DB_BLOCK_CHECKING
DB_BLOCK_CHECKING参数主要是用于数据块的逻辑一致检查，但只是在块内，不包括块间的逻辑检查。主要用于防止在内存中损坏或数据损坏。
无论该参数如何设置，对SYSTEM表空间来说，逻辑一致检查始终处于“打开”状态，在其他表空间该参数默认是关闭的。
DB_BLOCK_CHECKING参数的属性
参数值 | 含义 |
OFF或者FALSE | 对于用户表空间没有任何逻辑一致性检查工作 |
LOW | 块的内容在内存中改变之后，执行基本的块头检查，如UPDATE语句、INSERT语句、磁盘读或者在RAC中内部实例之间的块传递之后发生检查工作 |
MEDIUM | 除了索引以外的所有对象执行LOW检查和完全语义检查，由于索引能在遭遇损坏的情况下的重建，所以可以不考虑对它检查 |
FULL或者TRUE | 所有对象执行MEDIUM检查和完全语义检查 |
Oracle通过遍历在块中的数据来检查一个块，确保它在逻辑上手尾一致。根据系统负载和参数值，块检查通常一起1%~10%的负载。打开块检查，大量的UPDATE或者INSERT将造成更大负载，对于一个繁忙的系统，特别有大量插入或者更新操作的系统来说，性能影响是比较明显的。如果性能负载可以被接受，应该考虑设置DB_BLOCK_CHECKING为FULL。为了保持向后的兼容性，TURE和FALSE参数值同样可以使用，FALSE等同于OFF，TRUE等同于FULL。
如果启用DB_BLOCK_CHECKING参数，在磁盘的块发生逻辑损坏，下一次块更新将作为软损坏标记这个块，之后读取这个块产生ORA-1578的错误。
n 块错位
当Oracle察觉读取块的内容属于不同块但是校验和又是正确的时，会产生错误。
l 逻辑块损坏
若块包含一个正确的校验和，块头以下的结构是损坏的（块内容损坏），这可能引起不同的ORA-600错误。逻辑块损坏的详细损坏描述通常不会打印到告警日志。DBV将报告块具体的逻辑错误。
3. 坏块的检测工具
以下为损坏块的检测工具和使用方法：
l DBVERIRY坏块验证工具
DBVERIRY不能验证联机Redo日志、归档Redo日志、控制文件和RMAN备份集，只能用于数据文件的块验证。
n DBV验证传统数据文件
下面是使用DBV工具验证数据文件块的例子：
$ dbv file=/testdb/test01.dbf blocksize=8192
注意：DBV工具除了用于检测数据文件是否有坏块外，也用于获得坏块的详细信息。
n DBV验证裸设备数据文件
DBV要求file后面跟的必须是一个包含扩展名的文件，所以如果数据库使用裸设备作为存储方式，就必须使用ln命令连接裸设备一个带扩展名的文件，然后使用DBV工具通过对链接文件的验证实现对裸设备数据文件的验证。
n DBV验证ASM存储的数据文件
如果是验证存储在ASM中的数据文件则需要指定用户名和密码，如果不指定用户名和密码，将收到DBV-00008：USERID must bu specified for OSM files的报错。下面是使用DBV工具验证存储在ASM中的数据文件的块的例子：
$ dbv file=+DATAFILE/testdb/datafile/test.234.648839 userid=sys/oracle
l ANALYZE命令
Analyze命令的主要目的是通过分析数据库对象，为优化器收集数据库对象的统计量信息，以便优化器生成准确的执行计划。同时，它也能检查某个表或索引是否存在损坏的情况。Analyze执行坏块检查，但是不会标记坏块为corrupt，检测结果保存在USER_DUMP_DEST目录下的用户trace文件中。Analyze语法：
Analyze table/index / validate structure ;
Analyze命令会验证每个数据块、每条记录和索引的完整性。CASCADE关键字表示验证表及其相关的所有索引。与DBVERIFY不同的是，analyze只验证高水位线以下的数据块，analyze不会对未使用的空间进行验证。
SQL> analyze table fengpin.test validate structure;
l RMAN工具
RMAN是一块备份工具，就像一个过滤器，RMAN需要通过缓存过滤每一个块，其中一个特点就是检查块是否被损坏。如果备份的数据库中包含有坏块，将会收到错误
l EXP工具
对于包含坏块的表执行导出操作，会收到相关的错误信息。对于这种情况，在非归档模式无法通过块恢复修复块的情况下，有如下两种处理方法：
方法1：启用10231事件
通过设置10231诊断事件可以在导出的时候让Oracle忽略表损坏的块，10231是Oracle的内部诊断事件，设置在全表扫描时跳过坏块的数据块，只导出包含正确块的数据，之后把表删除，再把导出的表数据导入新表，从而修复该表。
1） 启用10231诊断事件
SQL> alter system set events=’10231 trace name context forever,level 10’;
2） 禁用10231诊断事件：
SQL> alter system set events=’10231 trace name context forever,level 0’;
方法2：使用DBMS_REPAIR包标记损坏的块。
可以使用DBMS_REPAIR包标记损坏的数据库对象，这样在对损坏的对象执行全表扫描的时候会跳过损坏的块。语法如下：
SQL> exec dbms_repair.skip_corrupt_blocks(‘’,’tablename’);
EXP坏块检查有一定的局限性，不会发现如下类型的坏块：
ü HWM（高水位线）以上的坏块
ü 索引中存在的坏块
ü 数据字典中存在的坏块
l Expdp工具
使用expdp工具不会给出坏块的提示，只会将对象正确的数据导出。
不完全恢复的选项
不完全恢复方式 | RMAN选项 | 用户管理备份选项 |
恢复到某个时间点 | until time | until time |
恢复到某个日志序列号 | until suquence | until cancel |
恢复到某个SCN号 | until SCN | until change |
不完全恢复只能针对整个数据库而言，并不能执行数据文件和表空间的不完全恢复；另外，对于非归档模式的恢复来说，也不能执行不完全恢复。
1） 基于时间点的不完全恢复
RMAN> run {
shutdown immediate;
startup mount;
SQL “alter session set nls_date_format=’’YYYY-MM-DD HH24:MI:SS’’”;（两个单引号之间没有空格）
set until time ‘2013-12-07 17:24:00’;
restore database;
recover database;
alter database open resetlogs;}
SET UNTIL TIME时间可以使用多种表示方式，可以使用TO_DATE函数来表示时间，还可以使用SYSDATE-1方式来表示时间。
注意：不完全恢复是针对整个数据而言，如果在上面的脚本中，还原和恢复的是某个数据文件或表空间，那么脚本将忽略set until time设置，对数据文件或表空间进行完全恢复。对RESTORE命令指定until time或者until scn的意义在于这样可以自动选择最近的RMAN备份来恢复数据，以上的批量命令相当于为RESTORE和RECOVER都指定了until time子句，这样比单命令模式更加简单和合理。基于时间点的恢复不能恢复到最终备份完成时间点以前的时段。
2） 基于序列号的不完全恢复
基于序列号的不完全恢复须指定某个Redo线程的序列号，那么在这个序列号切换时间点之前的所有实例的归档日志都需要的，每个节点的负载不同，其他实例的序列号可能比指定的Redo线程序列号要大。
以下是在RMAN中基于日志序列号的不完全恢复的例子：
RMAN> run {
Shutdown immediate;
Startup mount;
Set until sequence 10350 thread 1;
Restore database;
Recover database;
Alter database open resetlogs;}
注意：指定线程序列号为10350，但是恢复是不包含该序列号的日志的，也就是说恢复只会恢复到thread 1 sequence 10304的日志，时间点和scn恢复同样如此。
3） 基于SCN的不完全恢复
下面是在RMAN中基于SCN的不完全恢复的例子：
RMAN> run {
shutdown immediate;
startup mount;
set until scn 324394;
restore database;
recover database;
alter database open resetlogs;}
注意：对打开的数据库执行的全库备份或者0级备份，即使不完全恢复到执行全库备份或者0级备份的备份时间点也可能需要部分Redo日志，原因在于对打开的数据库执行RMAN备份是一个不一致的备份。
表空间时间点恢复（Tablespace Point-in-time Recovery，TSPITR）特性可以恢复一个或更多的表空间早于数据库其他部分的某个时间点。表空间时间点恢复是表空间的不完全恢复，操作起来比较复杂。
表空间时间点恢复能在不影响数据库其它表空间和对象的情况下，恢复一个或更多的用户表空间到之前的某个时间点。表空间时间点恢复是对某个表空间执行基于某个时间点的恢复，是特殊的不完全恢复。RMAN TSPITR可以用于以下场景：
n 一个不正确的job或者DML语句破坏了数据库其中一个表空间的数据，RMAN TSPITR可用于被破坏表空间的恢复。
n DDL操作改变了表的结构之后，RMAN TSPITR可用于丢失数据的恢复。这种情况不能使用Flashback Table找回表之前的结构的数据，如表结构变化后的一个TRUNCATE表操作。
n 一个表被一个drop语句加了purge选项彻底drop。RMAN TSPITR可用于这种情况的恢复。
n 恢复drop的表空间，当没有使用恢复目录，RMAN能对被drop的表空间执行TSPITR。
n 从一个表的逻辑损坏中恢复。
表空间时间点恢复和Flashback有点类似，在没有介质失败的情况下，数据也可以使用Flashback Database找回，但是Flashback Database会导致整个数据库被闪回到之前的某个时间点。与TSPITR不同的是，Flashback Database特性必须产生Flashback日志，使用Flashback Database闪回数据库比使用TSPITR有更多的限制，TSPITR可以扩展到能找回可用于恢复的更早备份数据。
1） TSPITR的工作原理
TSPITR工作原理的5个步骤：
步骤1 在辅助实例上用目标数据库的备份集还原数据文件。
步骤2 在辅助实例上用目标数据库的归档文件恢复数据文件。
步骤3 在辅助数据库上导出相关数据。
步骤4 修改主库的控制文件。
步骤5 将辅助数据上导出的文件导入目标数据库。
2） RMAN TSPITR模式
表空间时间点恢复使用的是RMAN的RECOVER tablespace命令，执行RMAN TSPITR有几个选项，不同的选项协调各种不同的操作模式之间对特定环境的自动化操作。
a. 全自动化（默认方式）
在这种模式下，RMAN管理整个TSPITR过程。制定表空间的恢复集、辅助目的地、目标时间和允许RMAN管理所有TSPITR的其它方面。
b. 自动化
可以覆盖一些默认RMAN TSPITR设置，但仍然使用RMAN管理辅助实例和辅助目的地。这是默认方式的变种，RMAN TSPITR提供一些固定管理的同事允许手动指定一些参数，主要包含以下两个参数：
n 辅助集或恢复集文件的位置
n 初始化参数文件
除了在TSPITR之后的恢复集文件位置，在TSPITR期间的辅助集文件、通道设置和参数或辅助实例的其它方面等更多控制都推荐使用默认方式。全自动和自动化都是使用RMAN自动管理辅助实例。
c. 非自动化
使用这种模式是手动创建和管理辅助实例的所有方面和一部分TSPITR过程。当必须分配不同的通道或者使用用户管理辅助实例改变参数时，使用这种模式是合适的。
3） 执行全自动化的TSPITR
下面以默认的全自动化模式在目标数据库服务器创建辅助数据库构建TSPITR，恢复在目标数据库对表的一个误操作。目标数据库与辅助数据库都在一台服务器上，下表是两个数据库的实例名和数据库名称对照表：
数据库类型 | 实例名称 | 数据库名称 |
目标数据库 | test | test |
辅助数据库 | test2 | test |
a. 创建模拟环境
步骤1 在目标数据创建测试表空间xy_tbs:
SQL> create tablespace xy_tbs datafile ‘/u01/app/oracle/test/xy_tbs01.dbf’ size 5M;
步骤2 确保目标数据库处在归档模式，使用RMAN查找出xy_tbs表空间的file_id，对它进行备份：
RMAN> report schema;
……
RMAN> backup datafile 5;
步骤3 创建测试用户xiaoyang：
SQL> create user xiaoyang identified by xiaoyang default tablespace xy_tbs tempory tablespace temp;
SQL> grant create session,create table,unlimited tablespace to xiaoyang;
SQL> connect xiaoyang/xiaoyang;
步骤4 创建两个测试表：x1和x2，每个表插入一条测试数据：
SQL> create table x1(D date);
SQL> create table x2(D2 date);
SQL> insert into x1 values(sysdate);
SQL> insert into x2 values(sysdate);
SQL> commit;
步骤5 查看当前时间作为表空间的恢复时间点：
SQL> alter session set nls_date_format=’YYYY-MM-DD HH24:MI:SS’;
SQL> select sysdate from dual;
步骤6 在恢复时间点之后向x2表中插入一条数据和创建一个新表x3，向x3插入一条测试数据：
SQL> insert into x2 values(sysdate);
SQL> create table x3(D3 date);
SQL> insert into x3 values(sysdate);
SQL> commit;
步骤7 手动drop掉表x1：
SQL> drop table x1 purge;
假设drop x1表是一个误操作，现在要通过TSPITR恢复技术恢复该表。
b. 检查表空间是否自关联
执行以下SQL语句检查表空间自关联情况：
SQL> execute dbms_tts.transport_set_check(‘xy_tbs’,true,true);
SQL> select * from transport_set_violations;
如果查询transport_set_violations视图有值返回，说明表空间有自关联，需要手动处理提示的问题。
c. 标识TSPITR之后将会丢失的对象
步骤1 通过时间标识TSPITR之后将会丢失的对象：
SQL> 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(‘xy_tbs’) and creation_time > to_date(‘2013-12-08 09:43:00’,’YYYY-MM-DD HH24:MI:SS’) order by tablespace_name,creation_time;
步骤2 通过SCN标识TSPITR之后将会丢失的对象：
SQL> select owner,names,tablespace_name,to_char(creation_time,’YYYY-MM-DD HH24:MI:SS’) from ts_pitr_objects_to_be_dropped where tablespace_name in(‘xy_tbs’) and creation_time > to_date(to_char(scn_to_timestamp(1638492),’YYYY-MM-DD HH24:MI:SS’),’YYYY-MM-DD HH24:MI:SS’) order by tablespace_name,creation_time;
如果以上两个查询有结果返回，那么在执行TSPITR之前应该先将这些对象进行逻辑备份，TSPITR完成之后，再将这些对象以替换的方式导入，以恢复产生数据丢失的对象。
d. 创建辅助数据库参数文件
转储目标数据库参数文件，将该参数文件拷贝到$ORACLE_HOME目录，重命名为inittest2.ora，参考如下参数文件内容调整inittest2.ora实例的初始化参数文件：
*.audit_file_dest=’/u01/app/oracle/admin/test2/adump’
*.control_files=’/u01/app/oracle/oradata/test2/control01.ctl’
……
db_file_name_convert=(“/u01/app/oracle/oradata/test”,”/u01/app/oracle/oradata/test2”)
log_file_name_convert=(“/u01/app/oracle/oradata/test”,”/u01/app/oracle/oradata/test2”)
log_archive_start=false
lock_name_space=test2
修改test2实例初始化参数文件中的audit_file_dest、control_file参数，确保与原有数据库的存储位置不同。添加db_file_name_convert、log_file_name_convert、log_archive_start和lock_name_space参数设置。
e. 创建目录结构
根据实例test2参数的设置创建相应的目录结构：
$ mkdir –p /u01/app/oracle/admin/test2/adump
$ mkdir –p /u01/app/oracle/oradata/test2
f. 创建test2实例密码文件
$ cd $ORACLE_HOME/dbs/
$ orapwd file=orapwtest2 password=oracle entries=5
g. 创建辅助数据库实例的静态注册
在grid用户下的$GRID_HOME/network/admin/listener.ora文件中修改如下配置：
$ cat listener.ora
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = test2)
(ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1)
(SID_NAME = test2)
)
)
h. 添加Oracle Net本地服务名
在Oracle用户下的$ORACLE_HOME/network/admin/tnsnames.ora文件中添加如下配置：
TEST2 =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = rhel2)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = test2)
)
)
i. 启动辅助数据库到NOMOUNT状态
$ export ORACLE_SID=test2
$ sqlplus / as sysdba
SQL> create spfile from pfile;
SQL> startup nomount
j. 执行TSPITR恢复
使用RMAN同时连接到目标数据库和辅助数据库，使用RECOVER TABLESPACE命令执行TSPITR操作：
$ rman target /
RMAN> connect auxiliary sys/oracle@test2
RMAN> run {
allocate auxiliary channel a1 type disk;
allocate channel c1 type disk;
recover tablespace xy_tbs until time “to_date(‘2013-12-08 09:30:00’,’YYYY-MM-DD HH24:MI:SS’)”;
release channel c1;
}
执行TSPITR需要手动分配auxiliary通道
使目标数据中xy_tbs表空间ONLINE：
SQL> alter tablespace xy_tbs online;
k. 验证恢复结果
SQL> select * from xiaoyang.x1;
SQL> select * from xiaoyang.x2;
SQL> select * from xiaoyang.x3;
到此，关于“Oracle恢复和介质恢复的方法是什么”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注创新互联网站，小编会继续努力为大家带来更多实用的文章！