刘相兵 邮箱: 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)
【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的装配流水线上
========================================================================分割线
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等逻辑/物理坏块问题
恢复恢复是Oracle中永恒的话题， 只要有数据 就有备份恢复的需求。 而在国内对于备份以及备份的可用性往往被企业所忽视。这造成了再数据库恢复上存在着东西方的差异。 更多的老外DBA把经历花在对Oracle内部原理和性能优化的研究上。
而我们国内 DBA似乎必须要精通一门额外的技术==》 在没有任何备份的情况下 恢复Oracle数据库中数据的技术！ 虽然这在大多数情况下是屠龙之技， 但很多时候却又变成了衡量一个DBA技术水准的标准了，(这样不好.. 不好)。
当然也并不是说 这种无备份下的数据恢复是无技术含金量的，实际上它们很需要对Oracle数据文件、数据块及其数据结构的理解，以及对数据字典构成的了解。
这里我们总结Oracle数据恢复专题的专题，包括一些在无备份情况下的数据恢复：例如DUL和BBED工具恢复等技术。
【数据恢复】利用构造ROWID实现无备份情况下绕过ORA-1578、ORA-8103、ORA-1410等逻辑/物理坏块问题
【数据恢复】ORA-600[kccpb_sanity_check_2]一例
如何清除Oracle控制文件中的无用记录，例如v$archived_log中的deleted归档日志记录
如何找回被create or replace覆盖的PL/SQL对象
Archivelog Completed Before VS UNTIL TIME
ASM丢失disk header导致ORA-15032、ORA-15040、ORA-15042 Diskgroup无法mount
Overcome ORA-600[4xxx] open database
数据恢复:解决ORA-600[kghstack_free2][kghstack_err+0068]一例
如何rename datafile name中存在乱码的数据文件
Oracle数据恢复:解决ORA-00600:[4000] ORA-00704: bootstrap process failure错误一例
Fractured block found during backing up datafile
手动递增SCN号的几种方法：How to increase System Change Number by manual
Visually inspect all cables for proper connectivity.
确认缆线链接正常
[root@dm01db01 ~]# cat /sys/class/net/ib0/carrier
1
[root@dm01db01 ~]# cat /sys/class/net/ib1/carrier
1
确认输出是1
检查这些命令,
ls -l /sys/class/infiniband/*/ports/*/*errors*
/opt/oracle.SupportTools/ibdiagtools 目录包含了verify_topology 和infinicheck工具 运行并确认网络。下面是这些工具的信息：
[root@dm01db01 ~]# cd /opt/oracle.SupportTools/
[root@dm01db01 oracle.SupportTools]# ls
asrexacheck defaultOSchoose.pl firstconf make_cellboot_usb PS4ES sys_dirs.tar
CheckHWnFWProfile diagnostics.iso flush_cache.sh MegaSAS.log reclaimdisks.sh
CheckSWProfile.sh em harden_passwords_reset_root_ssh ocrvothostd setup_ssh_eq.sh
dbserver_backup.sh exachk ibdiagtools onecommand sundiag.sh
[root@dm01db01 oracle.SupportTools]# cd ibdiagtools/
[root@dm01db01 ibdiagtools]# ls
cells_conntest.log dcli ibqueryerrors.log perf_cells.log0 perf_mesh.log1 subnet_cells.log VERSION_FILE
cells_user_equiv.log diagnostics.output infinicheck perf_cells.log1 perf_mesh.log2 subnet_hosts.log xmonib.sh
checkbadlinks.pl hosts_conntest.log monitord perf_cells.log2 README topologies
cleanup_remote.log hosts_user_equiv.log netcheck perf_hosts.log0 SampleOutputs.txt topology-zfs
clearcounters.log ibping_test netcheck_scratch perf_mesh.log0 setup-ssh verify-topology
[root@dm01db01 ibdiagtools]# ./verify-topology -h
[ DB Machine Infiniband Cabling Topology Verification Tool ]
[Version IBD VER 2.c 11.2.3.1.1 120607]
Usage: ./verify-topology [-v|--verbose] [-r|--reuse (cached maps)] [-m|--mapfile]
[-ibn|--ibnetdiscover (specify location of ibnetdiscover output)]
[-ibh|--ibhosts (specify location of ibhosts output)]
[-ibs|--ibswitches (specify location of ibswitches output)]
[-t|--topology [torus | quarterrack ] default is fattree]
[-a|--additional [interconnected_quarterrack]
[-factory|--factory non-exadata machines are treated as error]
Please note that halfrack is now redundant. Checks for Half Racks
are now done by default.
-t quarterrack
option is needed to be used only if testing on a stand alone quarterrack
-a interconnected_quarterrack
option is to be used only when testing on large multi-rack setups
-t fattree
option is the default option and not required to be specified
Example : perl ./verify-topology
Example : ././verify-topology -t quarterrack
Example : ././verify-topology -t torus
Example : ././verify-topology -a interconnected_quarterrack
——— Some Important properties of the fattree cabling topology————–
(1) Every internal switch must be connected to every external switch
(2) No 2 external switches must be connected to each other
——————————————————————————-
Please note that switch guid can be determined by logging in to a switch and
trying either of these commands, depending on availability -
>module-firmware show
OR
>opensm
[root@dm01db01 ibdiagtools]# ./verify-topology -t fattree
[ DB Machine Infiniband Cabling Topology Verification Tool ]
[Version IBD VER 2.c 11.2.3.1.1 120607]
External non-Exadata-image nodes found: check for ZFS if on T4-4 – else ignore
Leaf switch found: dmibsw03.acs.oracle.com (212846902ba0a0)
Spine switch found: 10.146.24.251 (2128469c74a0a0)
Leaf switch found: dmibsw02.acs.oracle.com (21284692d4a0a0)
Spine switch found: 10.146.24.252 (2128b7f744c0a0)
Spine switch found: dmibsw01.acs.oracle.com (21286cc7e2a0a0)
Spine switch found: 10.146.24.253 (2128b7ac44c0a0)
Found 2 leaf, 4 spine, 0 top spine switches
Check if all hosts have 2 CAs to different switches……………[SUCCESS]
Leaf switch check: cardinality and even distribution…………..[SUCCESS]
Spine switch check: Are any Exadata nodes connected …………..[SUCCESS]
Spine switch check: Any inter spine switch links………………[ERROR]
Spine switches 10.146.24.251 (2128469c74a0a0) & 10.146.24.252 (2128b7f744c0a0) should not be connected
[ERROR]
Spine switches 10.146.24.251 (2128469c74a0a0) & 10.146.24.253 (2128b7ac44c0a0) should not be connected
[ERROR]
Spine switches 10.146.24.252 (2128b7f744c0a0) & dmibsw01.acs.oracle.com (21286cc7e2a0a0) should not be connected
[ERROR]
Spine switches 10.146.24.252 (2128b7f744c0a0) & 10.146.24.253 (2128b7ac44c0a0) should not be connected
[ERROR]
Spine switches dmibsw01.acs.oracle.com (21286cc7e2a0a0) & 10.146.24.253 (2128b7ac44c0a0) should not be connected
Spine switch check: Any inter top-spine switch links…………..[SUCCESS]
Spine switch check: Correct number of spine-leaf links…………[ERROR]
Leaf switch dmibsw03.acs.oracle.com (212846902ba0a0) must be linked
to spine switch 10.146.24.252 (2128b7f744c0a0) with
at least 1 links…0 link(s) found
[ERROR]
Leaf switch dmibsw02.acs.oracle.com (21284692d4a0a0) must be linked
to spine switch 10.146.24.252 (2128b7f744c0a0) with
at least 1 links…0 link(s) found
[ERROR]
Spine switch 10.146.24.252 (2128b7f744c0a0) has fewer than 2 links to leaf switches.
It has 0
[ERROR]
Leaf switch dmibsw03.acs.oracle.com (212846902ba0a0) must be linked
to spine switch 10.146.24.253 (2128b7ac44c0a0) with
at least 1 links…0 link(s) found
[ERROR]
Leaf switch dmibsw02.acs.oracle.com (21284692d4a0a0) must be linked
to spine switch 10.146.24.253 (2128b7ac44c0a0) with
at least 1 links…0 link(s) found
[ERROR]
Spine switch 10.146.24.253 (2128b7ac44c0a0) has fewer than 2 links to leaf switches.
It has 0
Leaf switch check: Inter-leaf link check……………………..[ERROR]
Leaf switches dmibsw03.acs.oracle.com (212846902ba0a0) & dmibsw02.acs.oracle.com (21284692d4a0a0) have 0 links between them
They should have 7 links instead.
Leaf switch check: Correct number of leaf-spine links………….[SUCCESS]
确认硬件和固件
cd /opt/oracle.cellos/
[root@dm01db01 oracle.cellos]# ./CheckHWnFWProfile
[SUCCESS] The hardware and firmware profile matches one of the supported profiles
确认平台软件
[root@dm01db01 oracle.cellos]# cd /opt/oracle.SupportTools/
[root@dm01db01 oracle.SupportTools]# ./CheckSWProfile.sh
usage: ./CheckSWProfile.sh options
This script returns 0 when the platform and software on the
machine on which it runs matches one of the suppored platform and
software profiles. It will return nonzero value in all other cases.
The check is applicable both to Exadata Cells and Database Nodes
with Oracle Enterprise Linux (OEL) and RedHat Enterprise Linux (RHEL).
OPTIONS:
-h Show this message
-s Show supported platforms and software profiles for this machine
-c Check this machine for supported platform and software profiles
-I <No space comma separated list of Infiniband switch names/ip addresses>
To check configuration for SPINE switch prefix the switch host name or
ip address with IS_SPINE.
Example: CheckSWProfile.sh -I IS_SPINEswitch1.company.com,switch2.company.com
Check for the software revision on the managed Infiniband switches
in the Database Machine. You will need to supply the password for
admin user.
-S <No space comma separated list of Infiniband switch names/ip addresses>
Example: CheckSWProfile.sh -S switch1.company.com,switch2.company.com
Prints the Serial number and Hardware version for the switches
in the Database Machine. You will need to supply the password for
admin user for Voltaire switches and root user for Sun switches.
[root@dm01db01 oracle.SupportTools]# ./CheckSWProfile.sh -c
[INFO] Software checker check option is only available on Exadata cells.
[root@dm01db01 oracle.SupportTools]# ssh dm01cel01-priv
[root@dm01cel01 oracle.SupportTools]# ./CheckSWProfile.sh -c
[INFO] SUCCESS: Meets requirements of operating platform and InfiniBand software.
[INFO] Check does NOT verify correctness of configuration for installed software.
[root@dm01cel01 oracle.SupportTools]# cd /opt/oracle.cellos/
[root@dm01cel01 oracle.cellos]# ./CheckHWnFWProfile
[SUCCESS] The hardware and firmware profile matches one of the supported profiles
If hardware is replaced, rerun the /opt/oracle.cellos/CheckHWnFWProfile script.
最新回复