刘相兵 邮箱: liu.maclean@gmail.com 手机: 13764045638, ORA-ALLSTARS Exadata用户组QQ群:23549328
【技术分享】开Oracle调优鹰眼，深入理解AWR性能报告 第二讲
涉及性能优化教学知识：Host CPU、Instance CPU、Wait Class、SQL Statistics、AWR FOR RAC集群特定调优
适合的学员： 对性能优化有兴趣，或给予提升自己Oracle调优技能的同学
预计时长： 2个小时左右
本次公开教学的视频观看：
正式版文档材料已上传：
【Maclean Liu技术分享】开Oracle调优鹰眼，深入理解AWR性能报告 第二讲 正式版 20130.pdf (2.27 MB, 下载次数: 861)
视图 DBA_OPTSTAT_OPERATIONS 记录了详细的DBMS_STATS操作历史，可以看到 包括 gather_database_stats (auto) 、gather_table_stats(到表级别)、copy_table_stats(到表级别)。其数据来源于 WRI$_OPTSTAT_OPR
SQL> select distinct operation from DBA_OPTSTAT_OPERATIONS;
OPERATION
—————————————————————-
copy_table_stats
gather_database_stats
gather_table_stats
lock_table_stats
unlock_table_stats
purge_stats
gather_database_stats (auto)
SQL> select dbms_stats.get_stats_history_availability from dual;
GET_STATS_HISTORY_AVAILABILITY
—————————————————————————
24-APR-13 08.31.36.886874000 AM +00:00
==》最早可用的历史统计信息
SQL> select dbms_stats.get_stats_history_retention from dual;
GET_STATS_HISTORY_RETENTION
—————————
31
==> 统计信息的保留期
exec dbms_stats.alter_stats_history_retention(10);
==》修改统计信息保留期
select * from dba_tab_stats_history
==》查询某张表的 统计信息历史情况， 但是注意dba_tab_stats_history 并不记录实际的历史统计信息数据
function diff_table_stats_in_history(
ownname varchar2,
tabname varchar2,
time1 timestamp with time zone,
time2 timestamp with time zone default null,
pctthreshold number default 10)
return clob;
diff_table_stats_in_history 用以列出 统计信息历史差异
SQL> select to_char(sysdate,’YYYY-MM-DD hh24:mi:ss’) from dual;
TO_CHAR(SYSDATE,’YY
——————-
2013-05-25 09:01:46
SQL> insert into opt_test select rownum from dual connect by level <=10000;
10000 rows created.
SQL> commit;
Commit complete.
SQL> exec dbms_stats.gather_table_stats(user,’OPT_TEST’);
PL/SQL procedure successfully completed.
SQL> set long 999999999
select report, maxdiffpct from table(dbms_stats.diff_table_stats_in_history(‘SYS’,'OPT_TEST’,to_timestamp(’2013-05-25 09:01:46′,’YYYY-MM-DD hh24:mi:ss’)));
/
SQL> select table_name from dba_tables where table_name like ‘%OPTSTAT%’;
TABLE_NAME
——————————————————————————————————————————–
WRI$_OPTSTAT_SYNOPSIS$
WRI$_OPTSTAT_HISTHEAD_HISTORY
WRI$_OPTSTAT_HISTGRM_HISTORY
WRI$_OPTSTAT_SYNOPSIS_HEAD$
WRI$_OPTSTAT_SYNOPSIS_PARTGRP
OPTSTAT_USER_PREFS$
OPTSTAT_HIST_CONTROL$
WRI$_OPTSTAT_OPR_TASKS
WRI$_OPTSTAT_OPR
WRI$_OPTSTAT_AUX_HISTORY
WRI$_OPTSTAT_IND_HISTORY
WRI$_OPTSTAT_TAB_HISTORY
SQL> desc WRI$_OPTSTAT_TAB_HISTORY ==》 实际存放了表的历史统计信息
Name Null? Type
—————————————– ——– —————————-
OBJ# NOT NULL NUMBER
SAVTIME TIMESTAMP(6) WITH TIME ZONE
FLAGS NUMBER
ROWCNT NUMBER
BLKCNT NUMBER
AVGRLN NUMBER
SAMPLESIZE NUMBER
ANALYZETIME DATE
CACHEDBLK NUMBER
CACHEHIT NUMBER
LOGICALREAD NUMBER
SPARE1 NUMBER
SPARE2 NUMBER
SPARE3 NUMBER
SPARE4 VARCHAR2(1000)
SPARE5 VARCHAR2(1000)
SPARE6 TIMESTAMP(6) WITH TIME ZONE
Old statistics reside in SYSAUX
WRI$_OPTSTAT_TAB_HISTORY – for table [partition] stats
WRI$_OPTSTAT_IND_HISTORY – for index [partition] stats
WRI$_OPTSTAT_HISTHEAD_HISTORY – for column stats
WRI$_OPTSTAT_HISTGRM_HISTORY – for histograms
WRI$_OPTSTAT_AUX_HISTORY – for system stats
OPTSTAT_HIST_CONTROL$ – stats history settings
在有充分审计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 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?
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的硬件主要分成三个部分：
如下图：
Oracle Exadata X2-2 and X2-8的 Storage Servers
Oracle Exadata V2 Storage Servers
Exadata真机在SUN的装配流水线上
========================================================================分割线
Exadata Storage Server硬件配置
| V2 | X2-2 | |
| CPU | Nehalem-EP | Westmere-EP |
| DIMMs -compute node | 8 GB at 1066 MHz | 8 GB-LV dimms at 1333 MHz (post-RR) |
| HBA | Niwot with BBU07 | Niwot with BBU08 |
| NIC (compute node only) | No 10 GE ports | Using Niantic 10 GE ports |
| Compute node HDD | 146 GB SAS2 drives | 300 GB SAS2 drives |
| Storage node -SAS | 600 GB SAS2 15 KRPM | Same as V2 |
| Storage node -SATA | 2TB SATA 7.2 KRPM | 2TB FAT-SAS 7.2 KRPM |
| Aura (4x) | V1.0 | V1.0 (V1.1 post-RR) |
| IB | CX | CX2 |
Exadata 上的OS操作系统版本
compute note 数据库服务器操作系统， Solaris或者Linux
Oracle Enterprise Linux (OEL)和Solaris 11(x86)是目前 Exadata db服务器可选的2种OS类型， 当然Solaris仅在Exadata V2之后的机型上可选
用户可以在安装时选择他们更青睐的OS， Exadata 刷机的image 会有这2个版本。
出厂安装的image有linux 和solaris的双启动选项， 用户可以选择默认的启动OS 。
Exadata存储容量 对应不同的配置
| FULL RACK | Half RACK | Quarter RACK | One Cell | |
| Raw Disk Capacity | 432 TB | 216 TB | 96 TB | 24TB |
| Raw Flash Capacity | 6.75 TB | 3.4 TB | 1.5 TB | 0.375 TB |
| Usable Mirrored Capacity | 194 TB | 97 TB | 42.5 TB | 10.75 TB |
| Usable Triple Mirrored Capacity | 130 TB | 65 TB | 29 TB | 7.25 TB |
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 都是写死在代码里的常数值，具体可以参考下表：
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;
or
alter table move partition xxx tablespace;
or
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 数据库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文档： ■这部分有待补充 |
|
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： Oracle Database 11g 11.2.0.3.0 Interim patches (1) : Patch 14727310: applied on Fri Dec 09 10:59:28 EST 2011 Sub-patch 13923374; “Database Patch Set Update : 11.2.0.3.3 (13923374)”<==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 Bugs fixed: |
参考知识：可以参考下面的MOS文档了解每个季度的CPU、PSU、Windows Bundle Patch的具体补丁号：
Note 1454618.1 Quick Reference to Patch Numbers for Database PSU, SPU(CPU), Bundle Patches and Patchsets
ORA-8103是我们Database Consultant 经常要遇到的一个问题，了解ORA-8103的成因非常重要。
【数据恢复】利用构造ROWID实现无备份情况下绕过ORA-1578、ORA-8103、ORA-1410等逻辑/物理坏块问题
简单来说ORA-8103 的主要成因有2类:
针对ORA-8103问题 我们优先推荐一些措施：
ORA-08103问题的诊断最好是能生成8103错误的ERROR STACK TRACE， 在TRACE中会记录具体引发8103的对象的OBJ和OBJD，这便于我们定位可能存在corruption的对象。
问题在于往往前台进程遇到ORA-08103错误不会在后台生成TRACE文件，这需要我们手动设置8103 触发ERRORSTACK的EVENTS:
ALTER SYSTEM SET EVENTS ’8103 TRACE NAME ERRORSTACK LEVEL 3′;
解决思路包括：
1. 通过OBJD和DBA定位到具体的表名和块号
2. 有条件的情况下对该表做一个analyze .. validate structure
3. 有条件的情况下对该表所在tablespace做一个 dbms_space_admin.ASSM_TABLESPACE_VERIFY
4. 有条件的情况下move这张表或者相关的分区，尝试绕过该问题
5. 有条件的情况下降该表或分区移动到MSSM表空间上，绕过该问题
execute dbms_space_admin.tablespace_verify(‘&tablespace_name’)
oradebug setmypid
oradebug tracefile_name
execute dbms_space_admin.assm_tablespace_verify(‘&tablespace_name’,dbms_space_admin.TS_VERIFY_BITMAPS)
oradebug setmypid
oradebug tracefile_name
针对不同的 analyze validate structure 后得到的结果 ， 我们可以得到一些初步的结论：
如果执行 flush buffer cache之后再次analyze validate structure不再报ORA-8103错误则说明：
可能是完全正常的现象，之前的ORA-8103正是也因为对象正在被DROP/TRUNCATE而导致SELECT报ORA-8103。一般来说Call Stack会显示进程正尝试访问该段的segment header。 更多信息可以参考BUG 7441661
也可能该问题仅仅发生在buffer cache层，而没有发生在DISK上。通过flush buffer_cache若能解决，则一般是这种情况，往往是Buffer Cache管理的BUG 。
如果执行 flush buffer cache之后再次analyze validate structure再次报ORA-8103错误则说明：
如果dump对应的数据块发现 该块在逻辑上是完整一致的(也可以用bbed/dbv工具验证)， 则有可能是Lost Write，则不是被其他对象重格式化使用了。
这里判断Lost Write的一个重要手段是 对块做recover/blockrecover，如果recover能修复该块，则说明是因为Lost Write引起了本ORA-8103问题，如果不是则说明99%的可能性是BUG引起的。
常见的一种现象是 使用第三方工具在数据库打开的情况下copy 数据库，这些工具的BUG可能导致copy 老的版本的block到目标新库中。
另一种可能是 extent盘区级别的不一致。 同一个数据块/extent 可能 同时属于 2个数据段segment，这导致其中的一个被后者覆盖。 通过recover的方式是无法修复这种场景的， 因为这种逻辑的讹误发生在表空间级别的extent信息上。 可以检查dba_extents/dba_segments/dba_free_space这些视图来确定问题数据块到底是否同时属于多个对象， 或者 一个数据块 同时出现在dba_extents/dba_segments/dba_free_space 三个视图中， 因为 used extent 不该出现在dba_free_space中，而free extent不该在dba_extents，当然要排除recyclebin中对象的影响。 绝大多数情况下这种extent逻辑不一致的现象， 被称作extent overlap ， 通常是Oracle Space Management空间管理层面的BUG。
在对ORA-8103问题的诊断过程中 定位问题的OBJD异常重要。应当说准确地将ORA-8103错误与BUG定位起来是有难度的，因为这往往需要涉及到redo dump以发现到底是哪些opcode造成了后续的objd 或 block type 不一致。在一些BUG中我们发现，由于可能的变量陈旧，造成objd的结构未合理清除， 之后就发现block上的objd是错的了，可能遇到ORA-8103也可能是ORA-1410， 这引起了后续其他的逻辑讹误，以至于很难通过TRACE/REDO LOG DUMP来定位原始问题所在。 这也是为什么虽然在例如版本10.2.0.4上有几个ORA-8103的bug Note， 但这些BUG最终未被close为real software bug即真的软件BUG ， 大多都是不了了之，因为在用户现场的TRACE和REDO DUMP都未必能真实定位到问题所在，这也是为什么我们要说逻辑讹误的分析和处理原要比物理讹误来的复杂。
Maclean的经验是 在有大量Oracle DB的环境下 一年出个几次的逻辑/物理坏块是很正常的事情， 对于物理讹误 我们只要切实备份即可99%得解决。 而对于逻辑坏块可做的 事情不多， 打最新的补丁 开 db_block_checking、db_block_checksum几件事情而已。
值得一说的是 如果去读一下ORA-8103的一些Bug Note，可以发现使用 LOB、APPEND INSERT、PARALLEL INSERT、exchange partition 、Split partition、advanced compression、HCC 混合列压缩往往是引起ORA-8103的高危操作 ， 但实际我们又不可能放弃上述操作。
目前已知ORA-8103相关的BUG 列表：
| NB | Bug | Fixed | Description |
| 13910420 | 11.2.0.3.BP09, 12.1.0.0 | ORA-8103 during insert / update of basicfile LOB in assm segment using space search cache | |
| 13725395 | 11.2.0.3.BP07, 11.2.0.4, 12.1.0.0 | ORA-600 [kdzhFindHeadPiece: unnewed > 1] from load into HCC table | |
| 13700577 | 11.2.0.3.BP07, 11.2.0.4, 12.1.0.0 | PQ slave dies with ORA-600 [kdblddr_2] | |
| 12747437 | 12.1.0.0 | ORA-600 [ktspfmdb:objdchk_kcbnew_3] after purging single consumer queue table | |
| 12582839 | 11.2.0.3, 12.1.0.0 | ORA-8103/ORA-600 [3020] on RMAN recovered locally managed tablespace | |
| 12321309 | 12.1.0.0 | ORA-600 / ORA-8103 UNUSABLE state of partitioned index is not carried across by TABLESPACE transport using DataPump | |
| 11937253 | 11.2.0.2.6, 11.2.0.2.BP11, 11.2.0.3, 12.1.0.0 | A Parallel query fails with ORA-8103 on an Active Dataguard Enviroment. | |
| 11850492 | 11.2.0.3, 12.1.0.0 | ORA-8103 ORA-600 ORA-3113 on temporary tables using INDEX FAST FULL SCAN and DIRECT read | |
| 10385812 | 11.2.0.3, 12.1.0.0 | ORA-1410 or ORA-8103 by queries with DIRECT READ while concurrent DIRECT INSERT | |
| 10329146 | 11.2.0.1.BP10, 11.2.0.2.2, 11.2.0.2.BP03, 11.2.0.2.GIBUNDLE02, 11.2.0.2.GIPSU02, 11.2.0.3, 12.1.0.0 | Lost write in ASM with multiple DBWs and a disk is offlined and then onlined | |
| + | 10209232 | 11.1.0.7.7, 11.2.0.1.BP08, 11.2.0.2.1, 11.2.0.2.BP02, 11.2.0.2.GIBUNDLE01, 11.2.0.3, 12.1.0.0 | ORA-1578 / ORA-600 [3020] Corruption. Misplaced Blocks and Lost Write in ASM |
| 10136415 | 11.2.0.3, 12.1.0.0 | ORA-8103 on Partitioned IOT after partition maintenance | |
| 9965085 | 11.2.0.3, 12.1.0.0 | ORA-1578 / ORA-8103 Temporary table block corruption / space wastage from PDML | |
| 9659614 | 10.2.0.5.3, 11.2.0.2, 11.2.0.3.5, 11.2.0.3.BP05, 12.1.0.0 | Large trace file for ORA-8103 | |
| 9651350 | 11.2.0.2.2, 11.2.0.2.BP05, 11.2.0.3, 12.1.0.0 | Large redo dump and ORA-308 might be raised due to ORA-8103 | |
| 9275027 | 11.2.0.2, 12.1.0.0 | ORA-600 [kcbnew_3] can occur after TRUNCATE / DROP | |
| 9272086 | 11.1.0.7.4, 11.2.0.1.2, 11.2.0.1.BP06, 11.2.0.2, 12.1.0.0 | ORA-8103 by a query on DBA_EXTENTS. Trace file with Block type: 0×44=NGLOB: Extent Map | |
| 8754670 | 11.2.0.2, 12.1.0.0 | IMP-17 / ORA-8103 transporting a large dictionary managed tablespace | |
| 8740993 | 11.1.0.7.8, 11.2.0.2, 12.1.0.0 | ORA-1410 / ORA-8103 on ADG STANDBY during table scan after DROP/TRUNCATE/SHRINK in PRIMARY | |
| 8725282 | 11.2.0.1.BP08, 11.2.0.2, 12.1.0.0 | Corruption from cross platform transport of tablespace with securefile objects | |
| 8716064 | 11.2.0.2, 12.1.0.0 | Analyze Table Validate Structure fails on ADG standby with several errors | |
| + | 8597106 | 11.2.0.1.BP06, 11.2.0.2, 12.1.0.0 | Lost Write in ASM when normal redundancy is used |
| 8428523 | 11.2.0.2, 12.1.0.0 | Alter Table Rename causes wrong results/ora-8103/hangs on ADG Standby. | |
| 7710827 | 11.2.0.2, 12.1.0.0 | Index rebuild or Merge partition causes wrong results in concurrent reads instead of ORA-8103 | |
| 7519406 | 10.2.0.5.1, 11.2.0.1.2, 11.2.0.1.BP06, 11.2.0.2, 12.1.0.0 | Larger trace than needed for ORA-8103 under kteinicnt1 | |
| P | 12330911 | 12.1 | EXADATA LSI firmware for lost writes |
| 8876094 | 11.1.0.7.2, 11.2.0.2 | ORA-8103 by DBA_UNDO_EXTENTS or DBMS_SPACE_ADMIN.TABLESPACE_VERIFY on Block type: 0×25 | |
| 9167831 | 11.2.0.2 | ORA-8103 instead of ORA-1410 | |
| 7650993 | 11.1.0.7.1, 11.2.0.1 | ORA-8103 in a select at ADG standby database from table stored in ASSM tablespace | |
| 7432556 | 11.1.0.7.1, 11.2.0.1 | ORA-8103 by Parallel Query on Partitioned Tables in BIGFILE Tablespaces | |
| 7390324 | 11.2.0.1 | ANALYZE signals OERI [kcbgtcr_12]/ORA-8103 on bitmap index | |
| 7117200 | 11.2.0.1 | ORA-8103 after TSPITR/PLUGIN tablespace from a restored Level 1 Backup | |
| 8825048 | 11.1.0.7.3 | ORA-308/ORA-27037 when dumping archived log for ORA-8103. Dump when event 10736 level 4 is set | |
| 6337376 | 11.1.0.7 | OERI:kcbgcur_3 / ORA-8103 after truncating a partition table with LOBs | |
| 9711472 | 11.1.0.6 | ORA-8103 on operations for a partitioned LOB if any different partition is dropped | |
| 5637976 | 10.2.0.4, 11.1.0.6 | ORA-8103/ORA-1410 from concurrent INSERT / export on ASSM tables | |
| 5083393 | 10.2.0.4, 11.1.0.6 | DBA_FREE_SPACE FILE_ID / REL_FNO may be wrong | |
| 4592596 | 10.2.0.4, 11.1.0.6 | Corruption (ORA-1410 / ORA-8103) from multi-table insert with direct load | |
| 6864586 | 10.2.0.5 | ORA-8103 on partitioned table with a LOB column during analyze table with concurrent add/drop partition. | |
| 3569503 | 9.2.0.6, 10.2.0.4 | PQ may signal a false ORA-8103 under load | |
| 13618170 | ORA-8103 for create index online when the fix of bug 10027403 is installed | ||
| 3966709 | 9.2.0.7, 10.1.0.4, 10.2.0.1 | Range/object reuse prematurely (ORA-8103) | |
| 3868753 | 9.2.0.7, 10.1.0.5, 10.2.0.1 | Concurrent export / INSERT of ASSM segment can fail with ORA-1410 / ORA-8103 | |
| + | 5523799 | Various OERI (eg kcbgtcr_12) using ASSM managed segments – superceded | |
| P* | 6047085 | Linux x64-64: SGA corruption / crash following any ORA-7445 | |
| * | 3785200 | 9.2.0.6, 10.1.0.2 | Corruption possible in automatic space managed segments |
| 3083560 | 9.2.0.5, 10.1.0.2 | ORA-1410 / ORA-8103 from direct path export if concurrent DML occurs | |
| 2619867 | 9.2.0.3, 10.1.0.2 | OERI:[KCBGTCR_12] / ORA-8103 / ORA-1410 SELECTing from bitmap managed segment | |
| 2551000 | 9.2.0.4, 10.1.0.2 | False ORA-1410 / ORA-8103 possible from ANALYZE COMPUTE/ESTIMATE STATISTICS | |
| 2333731 | 9.2.0.2 | ORA-8103 possible in PQ slave | |
| 2105419 | 9.0.1.3, 9.2.0.1 | ORA-8103 possible from PQ on bitmap managed segments with concurrent inserts | |
| 1998455 | 8.1.7.3, 9.0.1.3, 9.2.0.1 | OERI:KCBGTCR_4 possible from long running DDL if referenced object dropped/truncated | |
| 1804299 | 9.0.1.1, 9.2.0.1 | Rollback of Direct load can corrupt BITMAP managed segments / ORA-8103 | |
| 1698789 | 9.2.0.1 | Wrong results, ORA-1410, ORA-8103, OERI:25012 on SELECT of UNSCOPED REF with ROWID | |
| 1504967 | 9.2.0.1 | ORA-8103 possible on READ ONLY standby after TRUNCATE on primary | |
| 1400739 | 8.1.7.1, 9.0.1.0 | Block corruption/OERI:2023 /ORA-8103 can occur if TRUNCATE is interrupted (Ctrl-C) | |
| 1283521 | 8.1.7.0 | ORA-8103 can occur on TRUNCATED cluster table | |
| 589855 | 7.3.3.6, 7.3.4.1 | ORA:1578 or ORA:8103 selecting invalid ROWID | |
| P | 1053863 | 8.0.5.2, 8.0.6.2 | NCR: ORA-8103 / corrupt read possible using async IO |
对于ORA-8103问题的更多信息可以参考：
MOS文档Note 268302.1 ORA-8103 Diagnostics and Solution
【数据恢复】利用构造ROWID实现无备份情况下绕过ORA-1578、ORA-8103、ORA-1410等逻辑/物理坏块问题
最新回复