Skip to content

Oracle恢复 - 9. page

浅谈Oracle 数据库跨平台迁移项目

跨平台的oracle迁移对于企业在目前来讲是比较少碰到的.碰到跨平台项目一般都是碰到数据整合,或者项目升级的情况.这里我以个人的角度浅浅的描述下oracle跨平台迁移涉及到的一些技术以及解决方案,顺便附上关于这方面的资料,只作个人的闲余消遣,更多的是我把我某一个项目中关于oracle迁移的经验思路理出来作分享
Oracle跨平台迁移一般使用手段便是如下所列的几种：

1.使用export工具，包括Datapump，对于Datapump，要求数据库为10.1.0.2以上版本
2.10G 或更高版本可使用 Transportable Tablespaces（TTS）。
3.10G 或更高版本可使用 RMAN Convert Database 功能。
4.Streams 流复制。
5.Create Table As Select (CTAS)
6.Dataguard 基于异构平台的物理主备库。
7.Oracle Golden Gate

每种办法都会有其优势和局限，包括数据类型、所需时间和潜在成本，我列举一个我迁移项目的例子：
(如要转载请标注原创）.

首先平台环境,原始环境平台：

oracle 10203
aix 5203

目标环境平台：

oracle rac 11.2.0.3.8
OElinux 6.1
aix 5203

这是我一个金融行业用户的核心生产要升级的项目,从Ibm的aix平台迁移到linux 平台,单机变双机,数据库版本也横跨了大版本.那么在项目初期,客户的期望就是我要迁过去,这样硬件升级还能有双活节点,有高可用做保障,对于DBA怎么迁移,他可不管,也不会问到非常细的环节(每个客户都是不一样的).那么作为乙方,我认为在处理这样的项目的时候,从接手开始就应该尽量的把你专业的一方面表现出来,尽可能的考虑到各种情况.这个升级项目涉及到的方方面面,在这个项目中我通常首先要了解的是时间窗口、整个DB的数据量,在我这项目中一开始我得到的信息为时间窗口是24小时,数据量是600多g.哟呵,有点儿意思,时间很充足,数据量马马虎虎,在这个行业里算大了,眼看就要想要用什么技术来迁移了.其实还早,时间窗口是用户确定了足信,至于数据量更多时候我一定会到数据库里再确定一次,那么怎么确定正确的数据量?确定数据量的办法挺多,肯定会有人说看dba_data_files的总和减去dba_free_space，剩下的就是实际数据量了，没准还会有更可爱的说看tablespace占了多少.哎呀其实都没错，在一些特定的技术环节下是要看这些，但是这里我想补充2个信息，就是从exp或者datapump的导出dump文件大小以及用rman做备份后的实际的备份集考虑.这只是在选择迁移技术前的信息判断而已,这些信息是越多越好,我最终选择的技术还是使用expdp，没有选择tts或者是dg.

那么为啥呢？别急容我慢慢述来.

1.数据量实际大小为290G,这与用户的描述有出入,经过了解是因为客户是通过sql语句来计算容量的，而实际上客户经常对一些历史表做delete的清理，并未做空间的回收操作，这样就会有大量的空间实际上是没有数据但是确占用着表空间容量的.得出这个数据后我逐测试了下exp和expdp的在生产系统空闲时间段的导出时间,expdp导出大小为270左右,开8个并行耗时80–120分钟.
2.在搭建好的linux平台（未来的核心平台）上测试导入时间，采取并行,索引分离,扩大PGA，分用户（应用用户相对独立）双节点导入等手段,最终在导入时间可以控制在80分钟以内.

那大头为什么不用tts或者dg,ogg,stream呢？
.
1.tts虽然我用的次数挺多,这里不用是因为用户表空间建的较大,整体加起来接近2t,表空间众多,操作繁冗.
2.虽然dg支持aix和linux的异构同步,但是这里对停机时间要求没有很严格，而且如果用dg一开始就要对生产系统停机维护,还需要规避bug.最重要的是,大头对这个技术虽然做过测试,但是经验不足，我不能保证会没有问题.我肯定会选择我可控的胸由成竹的技术.
3.ogg很美好，但是转眼想下，做ogg有必要么？初始化过程就相当于一次迁移了.又不需要无缝停机,即使真的无缝停机,ogg也不大可能会满足要求的,因为注定要经过一翻波折之后ogg才会这服在你额运维手段之下.
4.stream,快要淘的技术了,转眼像在ogg上复活了,ogg我都拒绝了,流再见吧.

理解了大头的用心良苦了么？汇总下上面的信息

项目起始选择迁移方式无外乎要注意几个重点：
1.尽可能多的收集和迁移相关的信息,而且要亲自去确认排除可能的情况
2.如果有测试数据支持,那么方案将更加有说服力
3.尽可能去结合项目的场景要求选择自己熟悉的适合技术,不要为项目,为自己,为技术团队添加意外的风险
4.如果遭遇客户的追问,123就是你的答复.

其实这个项目在使用datapump过程也对工程师的技术要求较高,虽然本身datapump的技术并不复杂,但是需要考虑的方面很多,我总结如下：
1.dblink，无论是出去的，还是进来的dblink都需要做一遍梳理.11.2.0.2之后重建dblink可以使用转换过的密码直接重建哦！
2.函数，同义词与dblink的依赖需要格外关注
3.物化视图迁移到11g后是一起迁移的，需要关注迁移后的物化视图是否为正常状态
4.导出的dump文件传输到目标库的时间是要计算到整个迁移时间的
5.统计信息最好不要一起迁移
6.如果导入过程碰到约束错误不要慌，报错的表可以在后续重新导入
7.在导入完成后需要验证每个用户下的对象信息是否与原库相符,最好有类似veridata软件对比原库和目标库行数信息的工具来支撑，否则就需要应用来做验证数据迁移的完整性
8.迁移的回退工作,万一遭遇datapump的bug,如何快速恢复初始环境？最好是在导入之前做一份目标库的rman全备份.
9.记得把temp表空间设大,把pga调大,把DB的归档关闭.
有不足的地方大家继续补充~欢迎大家斧正.

以上这就是一个最基本的迁移工作要注意的环节，以及datapump的使用注意事项.其他跨平台迁移方式相关资料大家可以参考如下，
luadtou
Note.556636.1 Oracle Server – Export Data Pump and Import DataPump FAQ
Note.351598.1 Export/Import DataPump The Minimum Requirements to Use Export DataPump and Import DataPump (System Privileges)
Note.243304.1 10g : Transportable Tablespaces Across Different Platforms
Note:371556.1 How move tablespaces across platforms using Transportable Tablespaces with RMAN
Note: 413484.1 Data Guard Support for Heterogeneous Primary and Physical Standbys in Same Data Guard Configuration
NOTE:1401921.1 – Cross-Platform Database Migration (across same endian) using RMAN Transportable Database
NOTE:62290.1 – Changing between 32-bit and 64-bit Word Sizes

Oracle Oracle 排障配置与调整 Oracle恢复 浅谈oracle技术系列 | Guang Cai Li | |   dataguard datapump endian

Handling Oracle Database Corruption Issues

官方关于数据库各类损坏的定义以及解决办法

 

Actions

CORRUPTION EXPLANATION
What is a corruption?
Note 840978.1 : Physical and Logical block corruptionHow to force reformat a corrupted block?
Note 336133.1 : How to Format Corrupted Block Not Part of Any Segment		 How to identify corruptions in a database?
Note 472231.1 : How to identify all the Corrupted Objects in the Database reported by RMAN
Note 819533.1 : How to identify the corrupt Object reported by ORA-1578 / RMAN / DBVERIFYKnown corruptions caused by OS/HW Issues
Note 1323649.1 : Known Corruption issues caused by 3rd party Software Provider

KIND OF CORRUPTIONS
SEGMENT CORRUPTED  How to handle Segment Corruptions (Table, Index, LOB, Long, IOT, Temporary)  This section refers to BLOCK CORRUPTION affecting database segments.
Note 428526.1 : Baddata Script To Check Database For Corrupt column data
CONTROLFILE CORRUPTION Note 1072762.6  :  ORA-00227, ORA-00202: BRING UP INSTANCE AFTER MACHINE CRASH
UNDO CORRUPTION Note 281429.1 : Basic Steps to be Followed While Solving ORA-00600 [4194]/[4193] Errors Without Using Unsupported parameter
Note 39283.1 : ORA-600 [4194] “Undo Record Number Mismatch While Adding Undo Record”
Note 431652.1 : How to Change the Existing Undo Tablespace to a New Undo Tablespace
DICTIONARY CORRUPTION Note 136697.1 : “hcheck.sql” script to check for known problems in Oracle8i, Oracle9i, Oracle10g and Oracle 11g
REDO CORRUPTION Note 1031381.6 : How to Dump Redo Log File Information.
ROW & COLUMN CORRUPTION Note 976591.1 : HowTo validate a date/timestamp column
Note 869305.1 : How To identify a ‘corrupt’ row when error is raised b
HOW TO IDENTIFY TABLE/INDEX INCOSISTENCY Note 136620.1 : Sanity Check of Oracle NUMBERS, How to Find and Patch

HOW TO HANDLE SEGMENT CORRUPTIONS
TABLE CORRUPTION Note 28814.1 : Handling Oracle Block Corruptions in Oracle7/8/8i/9i/10g/11g
INDEX CORRUPTION Note 28814.1 : Handling Oracle Block Corruptions in Oracle7/8/8i/9i/10g/11g
Note 438143.1 : Use of dbms_metadata.get_ddl() to extract Index DDL
Note 394143.1 : How Could I Format The Output From Dbms_metadata.Get_ddl Utility?
LOB Note 452341.1 : How to detect Lob Corruption
Note 293515.1 : ORA-1578 ORA-26040 in a LOB segment – Script to solve the errors
LONG ** Contact Oracle Support **  –>> Generic notes about these objects: * None Public*
IOT ** Contact Oracle Support **  –>> Generic notes about these objects: * None Public*
TEMPORARY Note 1332088.1 : How to clear corruption in temporary segment not in temp tablespace
Note 422039.1 : Steps to drop a temporary segment while SMON is not able

PACKAGE INFORMATION AND EXAMPLES
DBMS_REPAIR Note 556733.1 : DBMS_REPAIR script
Note 68013.1: DBMS_REPAIR example
DBMS_METADATA Note 438143.1 : Use of dbms_metadata.get_ddl() to extract Index DDL
Note 394143.1 : Q How Could I Format The Output From Dbms_metadata.Get_ddl Utility?
Note 332077.1 : Why Does DBMS_METADATA.GET_DDL Not Show All Lines?
Note 188838.1 : Using DBMS_METADATA To Get The DDL For Objects

TOOLS
DBV Note 35512.1 : DBVERIFY – Database file Verification Utility (7.3.2 – 10.2)
Note 269028.1 : DBV Reports Corruption Even After Drop/Recreate Object
Note 336133.1 : How to Format Corrupted Block Not Part of Any Segment
EXPORT Note 214369.1 : Using The Export Utility To Check For Database Corruption
RMAN Note 472231.1 : How to identify all the Corrupted Objects in the Database with RMAN
Note 1266059.1 : ABMR: HOW TO TEST AUTOMATIC BLOCK RECOVERY FEATURE
TRANSPORTABLE TABLESPACE Note 733824.1 : HowTo Recreate a database using TTS
DATA RECOVERY ADVISOR note 1317849.1 : Data Recovery Advisor – Corruption Reference Guide
ORA600/7445 Error Lockup tool Note 153788.1 : ORA-600/ORA-7445 Error Look-up Tool

GENERIC LINKS
PATCHSET UPDATES (PSU) & CRITICAL PATCH UPDATES (CPU) Note 268895.1 : Oracle Database Server Patchset Information, Versions: 8.1.7 to 11.2.0
Note 1061295.1 : Patch Set Updates – One-off Patch Conflict Resolution
Note 161549.1 : Oracle Database, Networking and Grid Agent Patches for Microsoft Platforms
Note 756671.1 : Oracle Recommended Patches — Oracle Database
Note 742060.1 : Release Schedule of Current Database Releases
Note 161818.1 : Oracle Database (RDBMS) Releases Support Status Summary

COMMON ERRORS
ORA-1578 ORA-1578 is reported when a block is thought to be corrupt on read.
ORA-1410 This error is raised when an operation refers to a ROWID in a table for which there is no such row.
The reference to a ROWID may be implicit from a WHERE CURRENT OF clause or directly from a WHERE ROWID=… clause.
ORA 1410 indicates the ROWID is for a BLOCK that is not part of this table.
ORA-8103 The object has been deleted by another user since the operation began.
If the error is reproducible, following may be the reasons:-
a.) The header block has an invalid block type.
b.) The data_object_id (seg/obj) stored in the block is different than the data_object_id stored in the segment header. See dba_objects.data_object_id and compare it to the decimal value stored in the block (field seg/obj).
ORA-8102 An ORA-08102 indicates that there is a mismatch between the key(s) stored in the index and the values stored in the table. What typically happens is the index is built and at some future time, some type of corruption occurs, either in the table or index, to cause the mismatch.
ORA-1498 Generally this is a result of an ANALYZE … VALIDATE … command.
This error generally manifests itself when there is inconsistency in the data/Index block. Some of the block check errors that may be found:-
a.) Row locked by a non-existent transaction
b.) The amount of space used is not equal to block size
c.) Transaction header lock count mismatch.
While support are processing the tracefile it may be worth the re-running the ANALYZE after restarting the database to help show if the corruption is consistent or if it ‘moves’.
Send the tracefile to support for analysis.
If the ANALYZE was against an index you should check the whole object. Eg: Find the tablename and execute:
ANALYZE TABLE xxx VALIDATE STRUCTURE CASCADE;
ORA-1499 An error occurred when validating an index or a table using the ANALYZE command.
One or more entries does not point to the appropriate cross-reference.
ORA-26040 Trying to access data in block that was loaded without redo generation using the NOLOGGING/UNRECOVERABLE option.
This Error raises always together with ORA-1578
ORA-600 [12700] Oracle is trying to access a row using its ROWID, which has been obtained from an index.
A mismatch was found between the index rowid and the data block it is pointing to. The rowid points to a non-existent row in the data block. The corruption can be in data and/or index blocks.
ORA-600 [12700] can also be reported due to a consistent read (CR) problem.
ORA-600 [3020] This is called a ‘STUCK RECOVERY’.
There is an inconsistency between the information stored in the redo and the information stored in a database block being recovered.
ORA-600 [4194] A mismatch has been detected between Redo records and rollback (Undo) records.
We are validating the Undo record number relating to the change being applied against the maximum undo record number recorded in the undo block.
This error is reported when the validation fails.
ORA-600 [4193] A mismatch has been detected between Redo records and Rollback (Undo) records.
We are validating the Undo block sequence number in the undo block against the Redo block sequence number relating to the change being applied.
This error is reported when this validation fails.
ORA-600 [4137] While backing out an undo record (i.e. at the time of rollback) we found a transaction id mis-match indicating either a corruption in the rollback segment or corruption in an object which the rollback segment is trying to apply undo records on.
This would indicate a corrupted rollback segment.
ORA-600 [6101] Not enough free space was found when inserting a row into an index leaf block during the application of undo.
ORA-600 [2103] Oracle is attempting to read or update a generic entry in the control file.
If the entry number is invalid, ORA-600 [2130] is logged.
ORA-600 [4512] Oracle is checking the status of transaction locks within a block.
If the lock number is greater than the number of lock entries, ORA-600 [4512] is reported followed by a stack trace, process state and block dump.
This error possibly indicates a block corruption.
ORA-600 [2662] A data block SCN is ahead of the current SCN.
The ORA-600 [2662] occurs when an SCN is compared to the dependent SCN stored in a UGA variable.
If the SCN is less than the dependent SCN then we signal the ORA-600 [2662] internal error.
ORA-600 [4097] We are accessing a rollback segment header to see if a transaction has been committed.
However, the xid given is in the future of the transaction table.
This could be due to a rollback segment corruption issue OR you might be hitting the following known problem.
ORA-600 [4000] It means that Oracle has tried to find an undo segment number in the dictionary cache and failed.
ORA-600 [6006] Oracle is undoing an index leaf key operation. If the key is not found, ORA-00600 [6006] is logged.
ORA-600[6006] is usually caused by a media corruption problem related to either a lost write to disk or a corruption on disk.
ORA-600 [4552] This assertion is raised because we are trying to unlock the rows in a block, but receive an incorrect block type.
The second argument is the block type received.
ORA-600[6856] Oracle is checking that the row slot we are about to free is not already on the free list.
This internal error is raised when this check fails.
ORA-600[13011] During a delete operation we are deleting from a view via an instead-of trigger or an Index organized table and have exceeded a 5000 pass count when we raise this exception.
ORA-600[13013] During the execution of an UPDATE statement, after several attempts (Arg [a] passcount) we are unable to get a stable set of rows that conform to the WHERE clause.
ORA-600[13030]
ORA-600[25012] We are trying to generate the absolute file number given a tablespace number and relative file number and cannot find a matching file number or the file number is zero.
ORA-600[25026] Looking up/checking a tablespace
invalid tablespace ID and/or rdba found
ORA-600[25027] Invalid tsn and/or rfn found
ORA-600 [kcbz_check_objd_typ_3] An object block buffer in memory is checked and is found to have the wrong object id. This is most likely due to corruption.
ORA-600[kddummy_blkchk] & ORA-600[kdblkcheckerror] ORA-600[kddummy_blkchk] is for 10.1/10.2 and ORA-600[kdblkcheckerror] for 11 onwards.
ORA-600[ktadrprc-1]
ORA-600[ktsircinfo_num1] This exception occurs when there are problems obtaining the row cache information correctly from sys.seg$. In most cases there is no information in sys.seg$.
ORA-600[qertbfetchbyrowid]
ORA-600[ktbdchk1-bad dscn] This exception is raised when we are performing a sanity check on the dependent SCN and fail.
The dependent scn is greater than the current scn.

 

 

Oracle Oracle恢复 | Guang Cai Li | |   corruption

12.实例恢复，介质恢复，崩溃恢复的原理理解

OCP教材 042 – 02章

1、media recovery是需要利用以前的备份来进行恢复的，而INSTANCE RECOVERY是不需要的。

2、media recovery通常发生在数据库的数据文件之类发生损坏，需要利用以前的备份来进行的恢复，需要人工处理；

而INSTANCE恢复则是发生在实例不正常关闭情况下的恢复，是INSTANCE自己来的，不需要人工干预的。

Media Recovery 概念：

如果发生数据文件丢失或破坏，就需要用备份和归档日志来进行恢复，这种恢复操作就叫作介质恢复（Media Recovery），这种恢复操作需要有备份、归档日志、联机日志一起才能完成，并分成完全恢复和不完全恢复两种情况。

Instance Recovery概念：

如果实例被SHUTDOWN ABORT方法强行关闭，或者因为断电等事故发生故障。数据文件、控制文件、联机日志都没有丢失，这时数据库再次启动时，要利用联机日志的内容进行恢复，这种恢复就是实例恢复（Instance Recovery）。

Instance Recovery主要包括3个阶段：

1）根据联机日志内容进行ROLLOVER；

2）打开数据库，提供服务；

3）SMON或用户进程进行ROLLBACK。

Crash Recovery：

到了RAC环境下，同样也有Media Recovery和Instance Recovery，并且RAC还有Crash Recovery。

简单地说，Instance Recovery是指所有的实例都发生Crash后进行的Recovery，从发生地点来看，这种Recovery发生在故障实例上，是故障实例重新启动时执行的Recovery。

而Crash Recovery是指某个实例发生了Crash后在其他实例上进行的Recovery。这里最重要的区别是发生地点不是在故障节点，而是在某个健康节点。这种Recovery有一个特殊要求：在健康节点执行Crash Recovery时，必须要保证故障节点不能再对共享数据进行操作，也就是要对故障节点进行IO隔离（IO Fencing），这是由CSS服务来保证的。

在单实例环境下，Crash Recovery和Instance Recovery没有区别。只有在RAC这种多实例环境下，这两个名词的区别才能体现出来。

说明：对于Crash Recovery最重要的是，必须保证在执行Crash Recovery时，故障节点被IO Fencing。

Crash/Instance Recovery与Media Recovery的本质区别在于：

Crash/Instance Recovery针对需要恢复的实例从增量检查点(incremental checkpoint)开始apply redo应用重做日志。由于日志覆盖的先提条件是完成相关日志的logfile switch checkpoint，且从定义上说归档日志总是落后于实例的检查点，所以对于crash/instance recovery崩溃或实例恢复总是只需要访问读取在线的重做日志(online redo logfile)。

介质恢复Media Recovery从旧数据文件的检查点开始apply redo引用重做日志，这些旧的数据文件可能来源于备份。 介质恢复情况下需要用到归档重做日志，因此RMAN或DBA(用户管理的备份)也需要将备份相关的归档日志还原出来。

Crash/Instance Recovery总是保证仅当所有的持久重做数据被应用之后才算恢复完成。 在Oracle保证所有已提交的事务都已经被包含恢复的情况下，才认为崩溃实例完成了恢复工作。

相反，介质恢复有不完全恢复(incomplete recovery)和部分恢复(partial recovery)的提法，以实现恢复数据库(db)到某个时间点的一致性。

Crash/Instance Recovery与Media Recovery的相同点在于：

Crash/Instance Recovery与Media Recovery都是传统的前滚恢复方式(rolling forward)，原理上都是对持久redo log数据的重演。 不管是Crash/Instance Recovery还是Media Recovery的前滚，都需要继之以事务回滚以便回滚未提交的事务，虽然前滚完成后数据库即可以打开而不用等回滚完成，但是仅在回滚完成的时候我们认为数据库是真正一致的。

Oracle恢复 Redo and Undo | Guang Cai Li | |   实例恢复和介质恢复以及崩溃恢复的概念

浅谈RMAN备份中"Unused Block Compression"使用限制

自从Oracle 10g推出Rman备份机制以来，其中的一个重要特性“空块不作备份”一直都深受DBA和广大客户的喜爱，节约空间以及提高备份效率等等，我也是如此喜欢，但是最近在一个项目上测试EMC备份软件备份时候，发现了一个怪事，具体如下描述：

1）数据库DB1通过EMC备份软件（备份方式为STB_TAPE）备出来大小为：780G。
期间尝试修改过3次参数，包括增量备份level=0，普通全备，filesperset参数取消，备份出来的大小均为780G不变。
2）数据库DB1通过Rman备份到本地硬盘（备份方式为DISK）大小为340G。

经过1和2的测试对比发现了明显的异常，通过第三方软件备份多出来了440G大小，随即进行跟踪分析，结果根据和之前做的清理400多G的数据进行联系，当时只是对数据做delete操作，但是并未做move以及空间回收操作，初步判断此次操作和EMC备份异常有关，在数据清理之前数据库的实际大小为700多G，根据Delete的特性可以判断这删掉的400多G的数据原先占有的数据块为空块，但是处于高水位线之下，属于曾经被使用过的块而且当前处于“不可用”状态，到此猜想，

是不是EMC备份把这些空块也一起备份了？
如果备了，那么为什么rman空数据块不被分的特性没有发挥作用么？

经过一番周折终于发现问题所在，这种现象发生在如下版本：

Oracle Server – Enterprise Edition – Version: 10.2.0.1 to 11.2.0.2(Ludatou.com) – Release: 10.2 to 11.2

而且对任何平台都影响。
而且使用“Unused Block Compression”条件有如下限制：
1）备份集存放方式存放在本地硬盘上
2）为0级备份或者量备份或者全备方式中的备份集的一部分
3）数据文件为本地管理方式
4）没有定义还原点的数据库
5）COMPATIBLE设置为10.2以上
6）数据库版本高于（不等于）10.2.0.1

针对COMPATIBLE对“Unused Block Compression”影响官方文档《Oracle Database Backup and Recovery Reference》解释如下：

Oracle Database Backup and Recovery Reference
11g Release 2 (11.2)
Part Number E10643-04
.
Backup
backupTypeSpec

Note:
If COMPATIBLE is set to 10.2, then only tablespaces created with 10.2 compatibility will be optimized to exclude blocks that do not currently contain data. If COMPATIBLE is set to 11.0.0 or higher, however, then the first backup that produces backup sets after COMPATIBLE is set to 11.0.0 or higher will update the headers of all locally managed datafiles so that all locally managed datafiles can be optimized.

经过以上的解释还不能解释为什么EMC备份会出现异常，
而ORACLE的一段关于OSB（Oracle Secure Backup）的描述，则解释了为什么EMC的备份软件没能使用到“Unused Block Compression”特性原因：

When backing up to a media manager that is not Oracle Secure Backup, RMAN copies all the blocks regardless of whether they contain data or not.

就是说再使用MML（Media Management Layer）连接第三方备份软件的方式（包含我们熟悉的赛门铁克的NBU,康孚，IBM的TSM等备份软件）备份数据库，在除了oracle原厂的备份软件Oracle Secure Backup之外都不能够使用到“Unused Block Compression”的特性，到此我们也终于明白为什么EMC备份软件备份出来的ORACLE数据为什么和实际的数据量不一致。

如果不小心使用了原厂之外的第三方备份软件，那么只能寻求其他的解决方案。
解决方案：
1）对相关的datafile/tablespace进行空间回收工作
2）对delete频繁的对象进行move操作
3）对DML操作频繁的大索引定期进行rebuild操作
4）换OSB（Oracle Secure Backup）吧
5）用Rman的方式备到本地，再用files backup的方式备份到磁带（弃用MML的SBT_TAPE备份方式），比如TSM
6）针对“Unused Block Compression”限制的条件进行设置处理

Oracle Oracle恢复 浅谈oracle技术系列 | Guang Cai Li | |   ramn空块备份 SBT_TAPE，scb Unused Block Compression