Oracle数据库数据恢复、性能优化、故障诊断来问问Maclean » – ORACLE数据库数据恢复、性能优化、故障诊断来问问MACLEAN

如何在无审计的环境中追踪Truncate/Drop等危险的DDL操作

Maclean Liu — Sat, 18 May 2013 13:39:35 +0000

在有充分审计Audit SQL的情况下，定位某条DROp/Truncate DDl还是比较容易的。

问题是没有任何SQL审计时呢？

首先需要明确的是对于关键的产品数据库系统而言有效的审计非常重要，不能将以下的方法当做审计选项来用。

其次对于重要的环境和重要的对象，一般推荐创建一个DDL Trigger 让直接运行的DDL报错，而需要先将对应的DDL Disable之后才能成功执行DDL，这样可以降低表/索引因为人为失误导致的误操作。

最简单的仍是通过 dba_objects 定位其最后的DDL时间，虽然这个LAST_DDL_TIME 未必是真实的案发时间了，但如何与应用程序报错结合起来还是能大致了解问题发生的时间段的，而这个时间段对于问题追查至关重要。此外对于DROP命令而言显然弄不到这个LAST_DDL_TIME。

接着可以通过ASH 视图 DBA_HIST_ACTIVE_SESS_HISTORY和 V$ACTIVE_SESSION_HISTORY来定位一些DDL语句，由于ASH默认是1秒采样一次，所以如果遇到了一些例如RAC 中truncate/drop 常见的 DFS Lock Handle、Enqueue Lock等等待，那么一般ASH都能捕捉到这个DDL，当然这也看运气，毕竟ASH不是审计功能。

SQL_OPCODE 12 为DROP TABLE 10为 DROP INDEX、85为TRUNCATE TABLE、86为TRUNCATE CLUSTER

select USER_ID, SQL_OPCODE, XID, SAMPLE_TIME,MODULE,MACHINE
from v$active_session_history
where SQL_OPCODE in (12, 10, 85, 86)
and SAMPLE_TIME between xx and xx;

select USER_ID, SQL_OPCODE, XID, SAMPLE_TIME,MODULE,MACHINE
from dba_hist_active_sess_history
where SQL_OPCODE in (12, 10, 85, 86)
and SAMPLE_TIME between xx and xx;

如果上述查询给出少量精准结果(例如MACHINE和MODULE很特殊)，那么一般就很容易定位了。如果查出大量结果，一般优先排除应用程序模块例如 JDBC Thin，如果应用程序本身有BUG导致莫名的DDL，那么理论上应当经常发生。如果看到一些例如SQLPLUS、PL/SQL Developer认为登陆执行上述命令的记录，则需要特别关注。

由于DDL语句不作为共享SQL保存在V$SQL、V$SQLAREA中所以就算你获得了SQL_ID还是看不到这些SQL语句的，所以无法通过SQL_TEXT来定位这些SQL到底是什么样子。

这个时候往往需要做Logminer了，但好在我们有大致的Sample Time和XID 这样定位SQL就很简单。

EXECUTE DBMS_LOGMNR.ADD_LOGFILE( LOGFILENAME => ‘/oracle/logs/log1.f’, OPTIONS => DBMS_LOGMNR.NEW);

EXECUTE DBMS_LOGMNR.ADD_LOGFILE( LOGFILENAME => ‘/oracle/logs/log2.f’, OPTIONS => DBMS_LOGMNR.ADDFILE);
execute DBMS_LOGMNR.START_LOGMNR(DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG+DBMS_LOGMNR.COMMITTED_DATA_ONLY);
SELECT (XIDUSN || ‘.’ || XIDSLT || ‘.’ || XIDSQN) AS XID,
USERNAME, SQL_REDO FROM V$LOGMNR_CONTENTS WHERE XID=’XXX’;

EXECUTE DBMS_LOGMNR.END_LOGMNR;

此外在没有审计的情况下值得参考的数据还有 Listener监听器的日志、OS登陆的Shell日志等。

【Maclean Liu技术分享】拨开Oracle优化器迷雾探究Histogram之秘

Maclean Liu — Mon, 13 May 2013 15:53:41 +0000

【Maclean Liu技术分享】拨开Oracle CBO 优化器迷雾, 探究Histogram直方图之秘,讲座文档正式版已上传
http://t.askmaclean.com/thread-2172-1-1.html

预计时长：　1.5个小时

适合参与成员：　对于性能调优和CBO优化器有兴趣的同学，或急于提升SQL调优技能的同学。

教学视频已上传，收看请猛击下面的地址：

http://www.tudou.com/programs/view/TGvP2pIyvwI/

【Maclean Liu技术分享】Histogram直方图技术演示脚本如下：

【Maclean Liu技术分享】Histogram直方图技术演示脚本.txt (9.93 KB, 下载次数: 65)

讲座材料presentation 当前正式版本下载:

【Maclean Liu技术分享】拨开Oracle CBO优化器迷雾,探究Histogram直方图之秘 20130429.pdf (1.11 MB, 下载次数: 3646)

Exadata Database Machine数据库一体机专题

Maclean Liu — Sat, 04 May 2013 13:47:21 +0000

什么是Exadata?

Exadata是软硬件结合的数据库一体机，在出厂前完成预配置，在运达用户现场后开封上电即可使用。

由SUN 提供的硬件！

由Oracle提供的软件， Database Server和 Exadata Storage Server software SAGE

Exadata的出现意味着大规模并行化，最高的RDBMS性能标杆，容错能力和可扩展能力。

Exadata的历史

版本 Version 1

在2008年OOW期间开始宣传，是Oracle和HP合作开发的。是当时世界上最快的数据仓库一体机。为顺序物理读提供了额外的性能优化，比其他硬件平台上的Oracle数据仓库快10倍。

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

版本 Version 2

于2009年9月份发布, 由 Oracle和SUN 联合开发。是当时世界上最快的OLTP一体机。为随机读提供了额外的性能优化。比Version 1的Exadata在DW上快5倍。引入注目的新 Exadata Storage Software能力。

Exadata的最大卖点无意是其Smart Scan Processing智能扫描技术

Smart Scan Processing智能扫描技术的核心在于offloading，offload很难翻译，但你可以理解为将一部分扫描处理交给Exadata的存储节点来完成。

本来要扫描1GB的数据表，实际符合查询条件的仅10MB数据。传统架构总是无法避免要让Database Server去扫描那1GB的数据。

而Exadata将这部分load off到Exadata Cell存储节点上，由cell来扫描那1GB数据，而仅仅返回10MB给Database Server，这样分工是由于存储节点更精于物理扫描也更接近物理磁盘。

真正实现Smart Scan智能扫描的是Oracle Exadata Storage Software 代号Sage，开发时间估计在2006或更早就开始了！

Oracle Exadata Storage Software SAGE是 Exadata的灵魂，是Oracle自主研发的能听懂数据库SQL语言的智能存储软件。由于SAGE软件才是Exadata的灵魂，所以光靠堆积flashcard、Infiniband等硬件是无法山寨Exadata数据库一体机的。

Exadata目前的一用户包括 StartBucks 、Facebook、华为、中国移动、上海银行、工商银行、Apple苹果、三星电子、LG、法国巴黎银行、韩国电信、韩亚航空、澳大利亚联邦银行、日本软银集团、海尔、喜达屋集团、尼桑、PayPal、土耳其电信、神奈川県警察本部、株式会社三井住友銀行、中国华夏银行、中国人民人寿保险股份有限公司、深圳市人社局、青岛市人社局、乌鲁木齐市人社局、本溪市人社局、新疆电信、广东移动、辽宁移动、福建移动、神华集团、东风汽车、海尔集团、中冶赛迪重庆信息技术有限公司、上海研发公共服务平台、中远集装箱运输有限公司、内蒙古电网、启融普惠(北京)科技有限公司、印孚瑟斯技术有限公司和香港房屋署等等。

Exadata的硬件主要分成三个部分：

Database Server 有时候也叫做Compute Node
Storage Server 也叫做Cell Node
Infiniband Switch 简写IB SW

如下图：

Oracle Exadata X2-2 and X2-8的 Storage Servers

Oracle Exadata V2 Storage Servers

Exadata真机在SUN的装配流水线上

========================================================================分割线

【CBO Optimizer优化器】IX_SEL索引选择率

Maclean Liu — Mon, 29 Apr 2013 15:34:15 +0000

ix_sel – Index selectivity 索引选择率是Oracle中CBO 基于成本优化器重要的参考指标，反应了符合谓词条件通过索引主导列访问表上数据行的比例。(ix_sel – Index selectivity. Fraction of the table rows accessed by the indexes leading column in order to meet the predicate supplied. (10053)。

注意仅仅leading column即索引的主导列用作计算ix_sel

举一个简单的计算ix_sel的例子：

SQL> create index ind_maclean on sh.sales( prod_id,CUST_ID,TIME_ID);

Index created.

SQL> exec dbms_stats.gather_table_stats(‘SH’,'SALES’,cascade=>true,method_opt=>’FOR ALL COLUMNS SIZE 1′);

PL/SQL procedure successfully completed.

SQL> oradebug setmypid
Statement processed.
SQL> oradebug event 10053 trace name context forever ,level 1;
Statement processed.
SQL> explain plan for select * from sh.sales where prod_id=13 and CUST_ID=987;

Explained.

BEGIN Single Table Cardinality Estimation
—————————————–
Column (#1): PROD_ID(NUMBER)
AvgLen: 4.00 NDV: 72 Nulls: 0 Density: 0.013889 Min: 13 Max: 148
Column (#2): CUST_ID(NUMBER)
AvgLen: 5.00 NDV: 5828 Nulls: 0 Density: 1.7159e-04 Min: 2 Max: 100989
Table: SALES Alias: SALES
Card: Original: 924076 Rounded: 2 Computed: 2.20 Non Adjusted: 2.20
—————————————–
END Single Table Cardinality Estimation
—————————————–
Access Path: TableScan
Cost: 414.20 Resp: 414.20 Degree: 0
Cost_io: 389.00 Cost_cpu: 215902675
Resp_io: 389.00 Resp_cpu: 215902675

www.askmaclean.com
Access Path: index (RangeScan)
Index: IND_MACLEAN
resc_io: 5.00 resc_cpu: 37017
ix_sel: 2.3831e-06 ix_sel_with_filters: 2.3831e-06
Cost: 5.00 Resp: 5.00 Degree: 1

ix_sel= 1/ (72*5828)=2.3831e-06

对于 Equality predicates 且变量可见(硬绑定或绑定可窥视) IX_SEL=1 / (NDV1* NDV2*..)

同样变量可见情况下>、<开放范围 IX_SEL=(MAX- 代入的范围值) / (MAX-MIN)

而变量不可见(cursor_sharing=FORCE、_optim_peek_user_binds=false)的情况:

1、Equality predicates 等式谓词情况下，IX_SEL一般等于列的Density

2、对于> <大于、小于的开放范围谓词 ix_sel一般恒等于0.009，对于 (object_id>:i and object_id<:b;)的闭包则恒等于 0.0045

例如：

select count(*) from test where object_id>:i

Access Path: index (IndexOnly)
Index: TEST_IDX
resc_io: 3.00 resc_cpu: 160764
ix_sel: 0.009 ix_sel_with_filters: 0.009
Cost: 3.02 Resp: 3.02 Degree: 1
Best:: AccessPath: IndexRange Index: TEST_IDX
Cost: 3.02 Degree: 1 Resp: 3.02 Card: 3869.30 Bytes: 0

select count(*) from test where object_id>:i and object_id<:b

Access Path: index (IndexOnly)
Index: TEST_IDX
resc_io: 2.00 resc_cpu: 84043
ix_sel: 0.0045 ix_sel_with_filters: 0.0045
Cost: 2.01 Resp: 2.01 Degree: 1
Best:: AccessPath: IndexRange Index: TEST_IDX
Cost: 2.01 Degree: 1 Resp: 2.01 Card: 193.47 Bytes: 0

ix_sel的 0.009和0.0045 都是写死在代码里的常数值，具体可以参考下表：

/* defaults */

/* Default selectivities are set low to

keep cost values low for future resource limiter use

keep cost values low for permutation cutoff in kko

Defaults are used for bind variables, general expressions and

unanalyzed tables, except for equality where defaults are not

needed for bind variables.

#define KKEDSREL 0.05 /* default selectivity for < <= > >= */

#define KKEDSEQ 0.01 /* default selectivity for = */

#define KKEDSNE 0.05 /* default selectivity for != */

#define KKEDSDF 0.05 /* default selectivity for all other ops */

#define KKEDSIRL 0.009 /* default selectivity for relation on indexed col */

#define KKEDSBRL 0.009 /* def sel for relation with bind var on index col*/

#define KKEDSIEQ 0.004 /* default selectivity for = on indexed col */

#define KKEDMBR 8 /* default multiblock read factor */

#define KKEDMBW 8 /* default multiblock write factor */

#define KKEDFNR 100.0 /* default – fixed table cardinality */

#define KKEDFRL 20 /* default – fixed table row length */

#define KKEDDNR 2000.0 /* default – remote table cardinality */

#define KKEDDRL 100 /* default – remote table avg row length */

#define KKEDDNB 100 /* default – default # of blocks */

#define KKEDDSC 13.0 /* default – default scan cost */

#define KKEDILV 1 /* default – default index levels */

#define KKEDILB 25 /* default – number of index leaf blocks */

#define KKEDLBK 1 /* default – number leaf blocks/key */

#define KKEDDBK 1 /* default – number of data blocks/key */

#define KKEDKEY 100 /* default – number of distinct keys */

#define KKEDCLF (KKEDDNB*8) /* default – clustering factor */

#define KKECRI 1.5 /* remote table access cost increase factor */

#define KKECFSC 1.0 /* fixed table scan cost */

#define KKECFNB 0 /* fixed table number of blocks */

#define KKECMXB 15 /* maximum byte length for normalization */

#define KKECBBS 256.0 /* base for byte sequence normalization */

#define KKECSPC ‘ ‘ /* space byte value */

#define KKECSPD 86400.0 /* seconds per day */

#define KKESROH 10.0 /* sort per row overhead in bytes */

#define KKESAUT 0.75 /* sort area utilization */

#define KKESROP 0.10 /* sort row overhead percent */

#define KKESRML 2.0 /* sort run multiple */

#define KKESTP 0×01 /* single table predicate */

#define KKETEQ 0×02 /* equi join */

#define KKETBCPJ 0×04 /* Cartesian product join */

#define KKESOK 0×08 /* input swap ok */

#define KKESWP 0×10 /* inputs swapped */

#define KKEEQP 0×20 /* equipartitioned */

#define KKELKNWC 0×01 /* LIKE no wild card */

#define KKELKTWC 0×02 /* LIKE trailing wild card */

#define KKELKEWC 0×04 /* LIKE embedded wild card */

#define KKELKLWC 0×08 /* LIKE leading wild card */

#define KKELKOWC 0×10 /* LIKE only wild card */

【数据恢复】详解ORA-1410错误

Maclean Liu — Sun, 28 Apr 2013 15:18:32 +0000

ORA-1410 invalid rows错误是与ORA-8103相似的Oracle数据库逻辑层面的讹误。

了解ORA-1410逻辑坏块问题的成因，以及有效的解决手段十分重要。

解决方案之一：

可以通过如下PL/SQL过程将健康数据复制到新建表中，对于问题数据块中的数据将被跳过，对于能够容忍数据丢失的场景可以考虑这样恢复，之后truncate 原表/分区并将健康数据加载进去。具体的脚本见下面的链接：

【数据恢复】利用构造ROWID实现无备份情况下绕过ORA-1578、ORA-8103、ORA-1410等逻辑/物理坏块问题

oerr ora 1410
01410, 00000, “invalid ROWID”
// *Cause:
// *Action:

如果对ORA-1410做errorstack 一般会看到下面的LOG:

OBJD MISMATCH typ=6, seg.obj=%d, diskobj=%d, dsflg=%d, dsobj=%d, tid=%d, cls=%d

触发ORA-1410错误的stack call一般都是： kcbgtcr=>kcbzib=>kcbz_check_objd_typ，即在对数据块做逻辑读时运行到kcbz_check_objd_typ函数时，检测到OBJD 不一致的问题。由于seg.obj和diskobj不一致，而10g以后的kcbz_check_objd_typ函数负责验证块上的objd是否mistmatch，若不一致则触发ORA-1410错误。

造成objd mimatch的主要可能有几种：

1、写丢失 Lost Write，写丢失造成相关数据块没有为现有对象正常格式化，导致虽然该数据块的checksum是正确的,但对应数据字典却是不一致的。写丢失也可能由磁盘或卷组镜像同步软件的不完整复制造成。

If the on-disk objd is < kcbdsobj, then there is possibility of Oracle messing up or IO layer (OS Cache, Volume mgr etc) missing writes.

对于Lost Write在10g版本中没有太好的预防方案，隐藏”_db_lost_write_checking”控制在DBWR写数据文件后立即去读被写的块以便检测出Lost Write，但是该参数对性能的损耗较大，不建议设置。

11g中引入了DB_LOST_WRITE_PROTECT参数配合Data Guard使用可以有效检测出Lost Write问题。

DB_LOST_WRITE_PROTECT enables or disables lost write detection. A data block lost write occurs when an I/O subsystem acknowledges the completion of the block write, while in fact the write did not occur in the persistent storage.

When the parameter is set to TYPICAL on the primary database, the instance logs buffer cache reads for read-write tablespaces in the redo log, which is necessary for detection of lost writes.

When the parameter is set to FULL on the primary database, the instance logs reads for read-only tablespaces as well as read-write tablespaces.

When the parameter is set to TYPICAL or FULL on the standby database or on the primary database during media recovery, the instance performs lost write detection.

When the parameter is set to NONE on either the primary database or the standby database, no lost write detection functionality is enabled.

2、一些DDL操作例如Exchange Partition 造成block级别的不一致，同一个数据块被2个数据对象所使用，而当这2个对象被使用时都可能覆盖问题数据块。实际上这种情况也可能是Lost Write所引起的。

3、文档Summary Of Bugs Containing ORA 1410 (Doc ID 422771.1)介绍了引起ORA-1410的主要BUG，其中BUG 4592596(Corruption (ORA-1410) from multi-table insert with direct load) 和 BUG 3868753 (Concurrent export / INSERT of ASSM segment can fail with ORA-1410 / ORA-8103)均为对表的Direct path/Parallel INSERT引起后续对表的SELECT操作报ORA-1410错误。

这说明了Direct Path/Parallel Insert操作有小概率引发ORA-1410错误发生的可能，而常规的conventional insert则不会引发ORA-1410。

4、 objd mimatch也可能仅仅是Oracle Buffer Cache内存中的block存在不一致，而Disk磁盘上的block仍是完好的。这一般是Oracle Buffer层的BUG引起的，对于该种现象一般flush buffer_cache即可解决问题。虽然在本例中flush buffer_cache未能解决问题，但是若问题仅仅发生在Memory层，则仍建议先考虑flush buffer_cache。

针对该由于OBJD MISMATCH所引起的ORA-1410问题可以采取如下措施：

1、尝试刷新buffer cache:

alter system flush buffer_cache; ==>如果是RAC建议2个实例都要flush

刷新后再次运行触发ORA-1410错误的语句，若不再报错则说明刷新BUFFER_CACHE有效

2、若flush buffer_cache解决不了问题，那么做analyze validate structure 和收集errorstack操作，分析原因：

alter session set events ’1410 trace name errorstack level 3′;

运行会触发ORA-1410的语句，收集生成的trace文件

analyze table XXX validate structure online; ==>在线validate structure

@?/rdbms/admin/utlvaild ==>对于分区对象需要运行utlvaild脚本

analyze table XXX partition (partition_name) validate structure online;

3、对于已经在磁盘上形成OBJD MISMATCH现象的数据对象：

a. 考虑通过move table、partition、subpartition来尝试解决该问题

alter table xxx move tablespace;

alter table move partition xxx tablespace;

alter table move sunpartition xxx tablespace;

ORA-1410问题相关的一些BUG罗列如下:

Bug 5637976
Abstract: ORA-8103/ORA-1410 from concurrent INSERT / export on ASSM tables
This occurs in 10gR2 when there are concurrent inserts and direct path exports. The newly created/updated blocks are not being flushed to disk, so the export is getting a stale version of the block from disk.
Fixed in 10.2.0.4 and 11.1.0.6

Unpublished Bug 4592596
Abstract: Corruption (ORA-1410) from multi-table insert with direct load
This error occurs if a SQL plan is compiled for a parallel run with a Degree of Parallelism (DOP) > 1, but at the time of running, due to lack of resources, it runs serial. Then the problem of invalid rowid will happen.
Fixed in 10.2.0.4 and 11.1.0.6.

Bug 5596325
Abstract: Text query gives wrong results or fails with ORA-1410 ORA-29903
If CONTAINS queries return ORA-1410: invalid rowid errors, and there are more than 200,000,000 documents in the index, then you may have encountered this bug.
Fixed in 10.2.0.4 and 11.1.0.6

Unpublished Bug 6444339
Abstract: TRUNCATE/PURGE DOES NOT CLEAN DEPENDENCIES PROPERLY.
DDL statements to an object were not invalidating all dependencies, so a stale rowid could remain in cache and produce a ORA-1410 if used.
Fixed in 11.2 and 10.2.0.5

Bug 8740993
Abstract: ORA-1410 OCCURRED ON ADG STANDBY DATABASE DURING TABLE SCAN.
This bug applies to standby databases and occurs when the standby is re-applying DDL for table drops/truncates/shrinks. The buffer cache is not being updated for the new object numbers.
Fixed in 12.1, 11.2.0.2

【转Oracle补丁】老托的Oracle 数据库Patch概念性小常识

Maclean Liu — Sun, 28 Apr 2013 15:06:23 +0000

老托的Oracle 数据库Patch概念性小常识，初学者可以参考该图来了解Oracle中补丁的分类知识，感谢Oracle ALLSTARS群中的老托同学的分享。

也可以点击这里下载老托的Oracle 数据库Patch概念性小常识

名称	说明
Release	¤ 标准产品发布。如Oracle Database 10g Release 2的第一个发行版本为10.2.0.1,可以在OTN、edelivery等站点上公开下载
Patch Set Release	¤ 就是早期大家常说的PSR。这是在主版本号上发布的补丁集，修复了较多的Bug，可能会包含一些增强功能（Enhancement）。比如11.2.0.1是一个主版本，那么11.2.0.2、11.2.0.3就是2个不同的Patch set。这种补丁集经过了严格的集成测试，也是累积型的。所以推荐安装最新的Patch Set。
Patch Set Update	¤ 就是DBA&DMA们常论道的PSU。Oracle 选取在每个季度用户下载数量最多，并且得到验证具有较低风险的补丁放入到每个季度的PSU中，修复比较严重的一些问题，包含每个季度的CPU，是累积型的。虽然在描述PSU的时候会用到数据库版本第5位，比如Database PSU 11.2.0.3.5，但实际上打完PSU后并不会真正改变数据库的版本，从v$version中看到的版本还是4位的(11.2.0.3.0)，第5位仍然是0。 ¤ 注意 (1)Windows上没有CPU和PSU，对于Windows和Exadata，Oracle使用Bundle Patch代替PSU，Bundle Patch会包含PSU的内容 (2)从11.2.0.2版本开始，一个新的补丁策略被引入，11.2.0.1之后发布的Patch Set本身就是一个完整的安装包，不再需要基础的Release 版本安装。
Critical Patch Update	¤ 这个指的就是CPU补丁。每季度发布一次，用来修复安全方面的一些补丁，是累积型的。目前(2012年10月）已经更名为Security Patch Update (SPU) ¤ 这类问题本来不属于软件错误,在正常使用中不会出现任何问题。但是别有用心的人可以通过运行非常精巧设计的代码，绕过数据库系统的安全管理机制,达到非授权存取的目的。 ¤ 重要补丁公告参见这里.
Interim Patch/One-Off Patch	¤ 是我们常说的小补丁，为了修复某(几)个Bug而发布的补丁。这种补丁推荐在测试库上测试无误后再安装在生产库上。
Merged Patch	¤ 合并的补丁。当几个小补丁之间有冲突，不能同时安装的时候，需要提供这种Merged Patch。补丁冲突主要是由于2个或者多个补丁修改同一个文件，但是修改的内容是不同的。
Bundle Patch(BP)	¤ 补丁集，修复多个Bug。在Windows平台上的Oracle没有小补丁，只有这种Bundle Patch。这种累积型的补丁集会周期性的发布（至少每季一次）,也就是每个Bundle Patch会包含之前所有的Bundle Patch。比如Windows Bundle Patch 16，它会包含之前所有15个Bundle Patch，所以我们总是推荐安装最新的Bundle Patch。Oracle的集群软件和数据库软件的Window Bundle Patch是同一个，比如Windows Bundle Patch 16(补丁号16167942，既可以打在集群上，也可以打在数据库上) 。 ■要了解Windows Bundle Patch的补丁号，可以参考MOS文档： Note 161549.1 Oracle Database, Networking and Grid Agent Patches for Microsoft Platforms ■这部分有待补充
Diagnostic Patch	诊断补丁。顾名思义，这类补丁不是用来解决问题的，而是用来寻找问题的原因的。这类补丁只在Oracle技术支持部门要求安装时，才需要安装。在得到需要的诊断信息后，应立即卸载这一补丁。
Composite Patch	¤ 从2012年4月份的Database PSU 11.2.0.3.2和11.2.0.2.0.7开始，推出一种新的概念叫Composite Patches。这是一种新型的补丁包，它不同于其他的累积型补丁包。如果是第一次安装Composite Patches，那么该Composite Patches所包括的全部补丁都会被安装，后续安装的Composite Patches，只会安装对比前一次Composite Patches有变化的部分和新增加的补丁。 ¤ Composite Patche的改进包括减少补丁安装时间，减少回滚以前应用的overlay patches的需要。新的Composite Patches格式，使以前PSU应用的overlay patches和新安装的PSU并存成为可能。更多信息，请参考Document 1376691.1 ‘Composite Patches for Oracle Products’ 和Oracle Database Support NEWS April edition. ■ PSU就是一种Composite Patch ¤第一次安装的composite patch为PSU 11.2.0.3.5： Installed Top-level Products (1): Oracle Database 11g 11.2.0.3.0 There are 1 products installed in this Oracle Home. Interim patches (1) : Patch 14727310: applied on Fri Dec 09 10:59:28 EST 2011 Patch Description: “Database Patch Set Update : 11.2.0.3.5 (14727310)” <==变化和新增的部分 Created on 14 Jan 2013, 07:56:00 hrs PST8PDT Sub-patch 14275605; “Database Patch Set Update : 11.2.0.3.4 (14275605)”<==Sub-patch Sub-patch 13923374; “Database Patch Set Update : 11.2.0.3.3 (13923374)”<==Sub-patch Sub-patch 13696216; “Database Patch Set Update : 11.2.0.3.2 (13696216)”<==Sub-patch Sub-patch 13343438; “Database Patch Set Update : 11.2.0.3.1 (13343438)”<==Sub-patch Bugs fixed: 13566938, 13593999, 10350832, 14138130 … ¤安装下一个composite patch PSU 11.2.0.3.6时，只需要安装有变化的部分和新增加的patches，不需要再安装之前已经安装的11.2.0.3.1 、11.2.0.3.2,11.2.0.3.4和11.2.0.3.5，之前已经安装的这部分就称为sub-patch： Patch 16056266: applied on Sun Apr 28 12:42:57 CST 2013 Patch Description: “Database Patch Set Update : 11.2.0.3.6 (16056266)” <==变化和新增的部分 Created on 12 Mar 2013, 02:14:47 hrs PST8PDT Sub-patch 14727310; “Database Patch Set Update : 11.2.0.3.5 (14727310)”<==Sub-patch Sub-patch 14275605; “Database Patch Set Update : 11.2.0.3.4 (14275605)”<==Sub-patch Sub-patch 13923374; “Database Patch Set Update : 11.2.0.3.3 (13923374)”<==Sub-patch Sub-patch 13696216; “Database Patch Set Update : 11.2.0.3.2 (13696216)”<==Sub-patch Sub-patch 13343438; “Database Patch Set Update : 11.2.0.3.1 (13343438)”<==Sub-patch Bugs fixed: 13616375, 14035825, 12861463, 12834027, 15862021, 13632809, 13377816 … ¤在MOS文档中有针对Composite Patches详细的说明：Note 1376691.1 Composite Patches for Oracle Products

参考知识：可以参考下面的MOS文档了解每个季度的CPU、PSU、Windows Bundle Patch的具体补丁号：

Note 1454618.1 Quick Reference to Patch Numbers for Database PSU, SPU(CPU), Bundle Patches and Patchsets