Archives for 十月 2014

Oracle Optimizer Hint优化器提示分类表

Oracle Optimizer Hint优化器提示分类表

 

 

 

分类 9i R1 9i R2 10g R1 10g R2 11g R1 11g R2
优化器模式 ALL_ROWS ALL_ROWS ALL_ROWS ALL_ROWS ALL_ROWS ALL_ROWS
FIRST_ROWS(n) FIRST_ROWS(n) FIRST_ROWS(n) FIRST_ROWS(n) FIRST_ROWS(n) FIRST_ROWS(n)
CHOOSE CHOOSE
RULE RULE RULE ※askmaclean.com
Hints OPTIMIZER_FEATURES_ENABLE
针对访问路径 FULL FULL FULL FULL FULL FULL
access path的HINT ROWID ROWID
CLUSTER CLUSTER CLUSTER CLUSTER CLUSTER CLUSTER
HASH HASH HASH HASH HASH HASH
INDEX INDEX INDEX INDEX INDEX INDEX
NO_INDEX NO_INDEX NO_INDEX NO_INDEX NO_INDEX NO_INDEX
INDEX_ASC INDEX_ASC INDEX_ASC INDEX_ASC INDEX_ASC INDEX_ASC
INDEX_COMBINE INDEX_COMBINE INDEX_COMBINE INDEX_COMBINE INDEX_COMBINE INDEX_COMBINE
INDEX_JOIN INDEX_JOIN INDEX_JOIN INDEX_JOIN INDEX_JOIN INDEX_JOIN
INDEX_DESC INDEX_DESC INDEX_DESC INDEX_DESC INDEX_DESC INDEX_DESC
INDEX_FFS INDEX_FFS INDEX_FFS INDEX_FFS INDEX_FFS INDEX_FFS
AND_EQUAL AND_EQUAL NO_INDEX_FFS NO_INDEX_FFS NO_INDEX_FFS NO_INDEX_FFS
INDEX_SS INDEX_SS INDEX_SS INDEX_SS
NO_INDEX_SS NO_INDEX_SS NO_INDEX_SS NO_INDEX_SS
INDEX_SS_ASC INDEX_SS_ASC INDEX_SS_ASC INDEX_SS_ASC
INDEX_SS_DESC INDEX_SS_DESC INDEX_SS_DESC INDEX_SS_DESC
关于转换的HINT NO_QUERY_TRANSFORMATION NO_QUERY_TRANSFORMATION NO_QUERY_TRANSFORMATION NO_QUERY_TRANSFORMATION
USE_CONCAT USE_CONCAT USE_CONCAT USE_CONCAT USE_CONCAT USE_CONCAT
NO_EXPAND NO_EXPAND NO_EXPAND NO_EXPAND NO_EXPAND NO_EXPAND
REWRITE REWRITE REWRITE REWRITE REWRITE REWRITE
EXPAND_GSET_TO_UNION
NOREWRITE NOREWRITE NO_REWRITE NO_REWRITE NO_REWRITE NO_REWRITE
MERGE MERGE MERGE MERGE MERGE MERGE
NO_MERGE NO_MERGE NO_MERGE NO_MERGE NO_MERGE NO_MERGE
STAR_TRANSFORMATION STAR_TRANSFORMATION STAR_TRANSFORMATION STAR_TRANSFORMATION STAR_TRANSFORMATION STAR_TRANSFORMATION
NO_STAR_TRANSFORMATION NO_STAR_TRANSFORMATION NO_STAR_TRANSFORMATION NO_STAR_TRANSFORMATION
FACT FACT FACT FACT FACT FACT
NO_FACT NO_FACT NO_FACT NO_FACT NO_FACT NO_FACT
UNNEST UNNEST UNNEST UNNEST
NO_UNNEST NO_UNNEST NO_UNNEST NO_UNNEST
JOIN order HINT LEADING LEADING LEADING LEADING
ORDERED ORDERED ORDERED ORDERED ORDERED ORDERED
STAR STAR
JOIN操作HINT USE_NL USE_NL USE_NL USE_NL USE_NL USE_NL
NO_USE_NL NO_USE_NL NO_USE_NL NO_USE_NL
USE_NL_WITH_INDEX USE_NL_WITH_INDEX USE_NL_WITH_INDEX USE_NL_WITH_INDEX
USE_MERGE USE_MERGE USE_MERGE USE_MERGE USE_MERGE USE_MERGE
NO_USE_MERGE NO_USE_MERGE NO_USE_MERGE NO_USE_MERGE
USE_HASH USE_HASH USE_HASH USE_HASH USE_HASH USE_HASH
NO_USE_HASH NO_USE_HASH NO_USE_HASH NO_USE_HASH
DRIVING_SITE DRIVING_SITE (参见其他HINT) (参见其他HINT) (参见其他HINT) (参见其他HINT)
LEADING LEADING
HASH_AJ、MERGE_AJ、NL_AJ HASH_AJ、MERGE_AJ、NL_AJ
HASH_SJ、MERGE_SJ、NL_SJ HASH_SJ、MERGE_SJ、NL_SJ
特殊 CHANGE_DUPKEY_ERROR_INDEX
IGNORE_ROW_ON_DUPKEY_INDEX
RETRY_ON_ROW_CHANGE
并行执行HINT PARALLEL PARALLEL PARALLEL PARALLEL PARALLEL PARALLEL
NOPARALLEL NOPARALLEL NO_PARALLEL NO_PARALLEL
PQ_DISTRIBUTE PQ_DISTRIBUTE PQ_DISTRIBUTE PQ_DISTRIBUTE PQ_DISTRIBUTE PQ_DISTRIBUTE
PARALLEL_INDEX PARALLEL_INDEX PARALLEL_INDEX PARALLEL_INDEX PARALLEL_INDEX PARALLEL_INDEX
NOPARALLEL_INDEX NOPARALLEL_INDEX NO_PARALLEL_INDEX NO_PARALLEL_INDEX NO_PARALLEL_INDEX NO_PARALLEL_INDEX
其他HINT APPEND APPEND APPEND APPEND APPEND APPEND
NOAPPEND NOAPPEND NOAPPEND NOAPPEND NOAPPEND NOAPPEND
APPEND_VALUES
CACHE CACHE CACHE 诗檀软件 CACHE CACHE CACHE
NOCACHE NOCACHE NOCACHE NOCACHE NOCACHE NOCACHE
UNNEST UNNEST
NO_UNNEST NO_UNNEST
PUSH_PRED PUSH_PRED PUSH_PRED PUSH_PRED PUSH_PRED PUSH_PRED
NO_PUSH_PRED NO_PUSH_PRED NO_PUSH_PRED NO_PUSH_PRED NO_PUSH_PRED NO_PUSH_PRED
PUSH_SUBQ PUSH_SUBQ PUSH_SUBQ PUSH_SUBQ PUSH_SUBQ PUSH_SUBQ
NO_PUSH_SUBQ NO_PUSH_SUBQ NO_PUSH_SUBQ NO_PUSH_SUBQ NO_PUSH_SUBQ
QB_NAME QB_NAME QB_NAME QB_NAME
ORDERED_PREDICATES ORDERED_PREDICATES
CURSOR_SHARING_EXACT CURSOR_SHARING_EXACT CURSOR_SHARING_EXACT CURSOR_SHARING_EXACT CURSOR_SHARING_EXACT CURSOR_SHARING_EXACT
DYNAMIC_SAMPLING DYNAMIC_SAMPLING DYNAMIC_SAMPLING DYNAMIC_SAMPLING DYNAMIC_SAMPLING
SPREAD_MIN_ANALYSIS
MODEL_MIN_ANALYSIS MODEL_MIN_ANALYSIS MODEL_MIN_ANALYSIS
DRIVING_SITE DRIVING_SITE DRIVING_SITE DRIVING_SITE

PRM-DUL成功案例:帮助北京某政府机构恢复硬盘损坏的Windows服务器上的oracle数据库

PRM-DUL成功案例:帮助北京某政府机构恢复硬盘损坏的Windows服务器上的oracle数据库。

 

该数据库版本为11.2.0.1,由于硬盘机械故障 存在较多的坏道,导致ORACLE实例无法正常启动 打开数据库,OPEN会因为ORA-01115、ORA-01110、ORA-27070、OSD-04006、O/S-Error:等错误而终止:

 

ORA-01115: IO error reading block from file  (block # )
ORA-01110: data file 3: 'ORCL\UNDOTBS01.DBF'
ORA-27070: async read/write failed
OSD-04006: ReadFile() 失败, 无法读取文件
O/S-Error: (OS 23) 数据错误(循环冗余检查)。

 

通过PRM-DUL直接使用字典模式加载所有数据文件后,直接绕过了无法读取的坏道数据块数据,成功加载数据字典,并恢复了用户Schema下的数据:

 

QQ截图20141128154838

 

 

QQ截图20141128155026

 

 

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 : 13764045638   QQ号:47079569    邮箱:service@parnassusdata.com

ORACLE PRM是诗檀软件独立研发的ORACLE数据库灾难恢复软件,其具有全程图形化界面、简单高效等特点。

欢迎下载使用ORACLE PRM。 下载地址:http://parnassusdata.com/sites/default/files/ParnassusData_PRMForOracle_3206.zip

PRM用户使用手册。http://www.parnassusdata.com/sites/default/files/ParnassusData%20Recovery%20Manager%20For%20Oracle%20Database%E7%94%A8%E6%88%B7%E6%89%8B%E5%86%8C%20v0.3.pdf

 

津岛博士的性能讲座 第五回 优化与优化统计的收集

津岛博士的性能讲座

第5次 优化与优化统计的收集

 
这次我将对于优化统计的收集进行说明(用Statspack等等收集的话情报会有区别,所以为了生成优化的执行计划所要用到的东西,我将称之为优化统计信息)。最近,我有听到如下关于优化统计信息的问题,我将在此进行说明。

 

“因为近来变得只有CBO了,所以就必须进行优化统计收集,对象太多的话就不能小看收集时间了。为了缩短收集时间,就缩小样本尺寸,减少收集频率,从而导致执行计划不是最合适的情况,实在让人困扰。请告诉我优化统计的收集的方法。
对此,因为没有说“只要这么做就万事大吉”的方法,我想大家都应该对此挺烦恼的。对此,我整理了我的想法,希望能作为大家的参考。

 

首先我们说明下到底优化器optimizer是什么。从optimizer statistics 统计信息开始计算成本,然后选出其中成本最低的执行计划来执行就是CBO。(对此,直接由SQL文本所决定的执行计划就是RBO。以前的版本两种说法都可以使用,但现在只推荐用CBO了。

优化器统计信息分为如下几种

  1. Table表统计(行数、块数、平均行长等等)
  2. 列统计(基数,NULL数,最大值,最小值,历史数据等等。没有历史数据 情况时,用最小值和最大值将数据分布均一化。)
  3. 索引统计(叶块数Leaf block、树tree的高度、集群化洗漱等等索引的有效性。)
  4. 系统统计(CPU性能、I/O性能等等)

 

使用这个概念,CBO就是怎样考虑的(全扫描或索引扫描,以怎样的顺序怎样结合等等),以及如何使得成本最小化(使得访问行数最少)。如果这里出现纰漏的话,就做不出较好的执行计划(比如如图A的的数据分布,因为没有收集偏差部分的历史数据,就无法判断是否均一)。优化统计信息对于性能是非常重要的情报。

 

1

 

图(数据分布)

上述表的行A和行B是分别由各自的索引被制成的状态,假设用下述的1和2的SQL文执行的话,从选择率上来看,使用1的索引的B效率会更好。2是使用A的缩影效率会更好。如果A的数据分布均一化了请选择1的A索引。

 

那么要怎么去收集优化统计才好呢?基本上,使用如之后所述的准则来实行。因为其中有性能劣化的情况,我将在之后对此进行说明。

使用DBMS_STATS包package

 

ANALUZE命令也因为下位互换的原因被留下来了,所以请使用DBMS_STATS包package(将正确的统计情报会被效率地收集起来,历史管理也会自动执行。

对每个对象指定合适的收集频率

对于对象的变更量,根据因此优化统计变得不正确的等级来决定收集频率。这时,请注意对于静态的数据不要做没用的收集。我想这样表述大家还是很难明白,通常请按照下面的方法执行。(适合在Oracle里执行。)

存储暂时表和挥发性很高的数据的Table表频繁地大量行的DELETE或者被TRUNCATE的Table)是用动态的采样来执行(删除统计情报后,ROCK可以经常执行动态采样。观察以下的SQL文,我们可以确认统计ROCK状态的对象,

2

3

Table有合适的样本尺寸统计

因为在Table的统计收集中有必要执行分类处理,大规模的Table之中,这样的操作非常耗费时间。因此我们会设定Table的样本 尺寸来执行。(通常有5%的样本尺寸就没问题了)。

DBMS_STATS包的参数的值也,从Oracle Database 10g开始默认变成是estimate_percent=>DBMS_STATS.AUTO_SAMPLE_SIZE(依存于对象的行数的估计采样尺寸),所以我认为这里不存在问题(收集优化统计的的时候的样本尺寸是用以下SQL文来确认。)

 

4

索引中的完全统计

因为索引已经完成分类了(没必要分类处理),可以完全(100%)收集。

从Oracle Database 10g开始,制作索引或者再构筑时,优化统计会被自动收集。(Oracle9i中索引制作或者再构筑时,通过指定COMPUTE STATISTICS选项来完成收集)所以没有必要制作完成后再次收集。

这边的DBMS_STATS 包的参数值也是,Oracle Database 10g默认是cascade=>DBMS_STATS.AUTO_CASCADE(是否有必要去收集索引的统计以及醉适合的样本尺寸是什么是由Oracle决定的),我认为这里没有问题。用以下的SQL文来确认索引的优化统计。

 

 

5

数据中有偏差的列用直方图统计

像在WHERE语句的条件中 使用数据分布中有偏差的列的SQL文有不是最合适的执行计划的可能一样(像上次课程一样,姓是铃木和林的搜索结果不同一样,最适合的实行计划也有不同的可能性,有必要收集正确的数据分布。)

DBMS_STATS包的参数值也通常是用method_opt=>’FOR ALL COLUMNS SIZE AUTO’(从Oracle Database 10gR2开始的默认),我们可以判断没有问题。直方图的直方数用以下的SQL文来确认

 

SQL文的WHERE语句之中选定复数的列的话,会有列统计出现错误的情况,根据情况,请检查复数列的统计。

另外,在Oracle Database 10g以后追加的新功能也有让统计情报更便利的功能

以下我将介绍这些新功能,请大家一定要好好活用。

 

  • (1)自动优化统计收集

Oracle Database10g以后的版本中,默认的自动优化统计收集功能十分有效。因此,如下的优化就被自动收集到优化统计之中。

还没有收集到优化统计的对象。

有优化统计不是最新的状态的对象(10%以上的行被更新了)

 

被事先定义为周一到周五是22:00到第二天早上的2:00,周六周日是6:00到第二天早上的2:00之间收集(Oracle Database 10g以后之中周末是周六0点到周日的23:59:59之间),请调整时间使用。在之后的SQL文中可以确认自动维护任务窗口、执行日期、状态。

6

 

这时,dbms_stats.gather_database_stats_job_proc存储过程(与dbms_stats.gather_database_stats (options=>GATHER AUTO)的执行几乎同时)就会被同时执行。因为是使用被Table表的PARALLEL句指定的默认并列度,对于大规模Table表,想加速收集时间的时候,请调整对象Table的默认并列度)。要确认或者变更这些默认值,请使用get_prefs存储过程与set_*_prefs存储过程来执行。(直到Oracle Database 10g是使用dbms_stats.get_param和dbms_stats.set_param来运行),下面的SQL文就是变更和确认的例子。

7

 

(2)动态采样(初始化参数OPTIMIZER_DYNAMIC_SAMPLING)

优化统计不足的话,执行SQL文时就会自动地采样优化统计制作执行计划。(优化统计是被存储在词典Dictionary之中的删除共有区域的话就会被再次执行。因此,访问对象Table的SQL文很多的情况时,请手动收集)

Oracle Database 10g开始的默认之中(初始化参数Oracle Database 10g),所有没有被优化统计收集的Table表都将被执行动态采样。(因为采样被访问的块数从OD10g开始变成了64块。)通常这没有问题。(但是,复杂的SQL文等等需要在默认以外去做。关于这个我将另行说明。)

通常一直对Table表进行动态采样的情况下,如下图所示,请删除优化统计后再LOCK,这样,初始化参数OPTIMIZER_DYNAMIC_SAMPLING=2以上时通常就会被动态采样。

8

 

(3)复数列的统计

选定SQL文的WHERE语句里的复数列作为条件时,会出现列统计不正确的情况。比如如下图SQL文所示,制成c1和c2的复数列索引的情况时,判断进行索引扫描或全扫描时,在各自的列单独的统计中有无法正确判断的情况。如果不是根据两个列的组合决定数据分布的话就无法得出正确结果。(因为对两个列的值有必要估计到底有多少件是HIT的)8

9

 

 

这样的情况是收集Oracle Database 11g开始的复数列的统计(作为列Group的统计)(Oracle Database 10g以前有必要调整提示文)比如,假设将上述SQL文中WHERE语句里的c1列和c2列作为条件指定的话,就能如下所示一般收集。

11

 

 

  • 性能劣化的情况

优化统计和CBO也不是完美的。(也会有所有的优化统计不能说是完全正确的情况,以及即时使用完全的优化统计,CBO选择的执行计划也不是最适合的情况。因此,也有收集优化统计然后性能产生劣化的情况,出现这种情况时,请使用以下对策。

 

22

 

收集正确的优化统计(扩大样本尺寸和直方图的直方)

完全收集样本尺寸后,性能被改善了的话,然后就接着收集。(时间上出现问题时,将样本尺寸一点一点缩小,尽量不影响执行计划来进行调整。)

使用提示文来回避问题点

比较劣化前的执行计划,对于有差异的地方来插入提示文。比如,想使用索引ix_tab01_c1的时候如后图所示,插入INDEX提示(红字的部分)。

33

 

这样使用中性能出现急剧劣化的话很让人困扰,也能常常听到不想频繁改变执行计划。最后我将对此进行说明。

 

  • 不想改变实行计划

因为是用CBO,所以有可能让优化统计的执行计划发生改变。无论如何不想改变的话,按下述事项来做的话,也有不变更的方法。

提示文(无法变更SQL文且无法植入提示文的情况使用计划稳定性Plan Stability)

计划稳定性Plan Stability(为了实现执行计划的概要。作成“之后植入的提示文的集合”,执行时,在SQL文植入概要)

还有Table的数据分布等等发生改变,效率降低的情况,请在数据分布的倾向不发生改变的情况下使用。(比如列c1的索引访问效率较好,而改变数据分布之后效率就变差了)因此,改变数据分布的情况,请确认现在的执行计划是没有问题的。

因为也有上述这样的情况,Oracle Database 11g的话就如图一样使用SQL计划管理(SPM:SQL Plan Management)。执行实行计划的历史管理,就能采用最合适的执行计划。

44

 

  • 总结

这次我们对于优化统计的收集进行了各种各样的说明,正确把握所有数据是非常困难的。所以充分进行提前测试,再分别处理就显得很有必要了

有其他问题的话尽管来问,我在这里恭候大家。

那么,下次见。

Oracle数据库技术交流和知识转移

 oracle-kt

序号 名称 天数 服务对象 特点及主要内容
 1 数据库和SQL语言基础课程 2 初级开发人员 面向初级开发人员的入门级课程,讲述数据库基本原理、SQL基本操作,介绍SQL应用优化基本原理、常见性能问题和案例分析
2 PL/SQL语言基础课程 2 初、中级开发人员 介绍PL/SQL概述、PL/SQL变量声明、常用SQL语句编写、条件和循环语句编写、复合数据类型处理、游标使用、异常处理等,并介绍PL/SQL编写经验和相关案例
3 PL/SQL语言高级课程 3 高级开发人员 系统介绍PL/SQL开发高级技术。包括存储过程、函数、包的编写,Oracle主要内置包的介绍,动态SQL语句编写,大对象管理等,并介绍PL/SQL高级技术运用经验和相关案例
4 数据库逻辑设计及建模 2 数据库设计、开发人员和DBA 系统介绍数据库规范化设计理论,并通过SQL Developer Data Modeler工具的运用,结合案例讲述数据流程图设计和实体关系图(E-R)设计过程,提高客户数据库设计水平
序号 名称 天数 服务对象 特点及主要内容
 5 数据库物理设计 2 数据库设计、开发人员和DBA 全面介绍Oracle数据库物理设计过程,包括表空间、表、索引等物理设计,适合于海量数据管理的分区、ASM等技术和方案设计,10g/11g相关新特性,并介绍若干实际案例
6 DBA基础课程 3 初、中级DBA 介绍Oracle数据库体系结构,以及DBA日常运行维护操作。如数据库对象管理、备份/恢复、安全性基本管理、网络管理、性能监控和分析,以及AWR、ADDM等基本工具使用和分析
7 DBA高级课程 3 高级DBA 面向高级DBA,结合大量实战案例,在系统级和SQL应用级分别介绍性能优化高级技术,并讲述分区技术方案,故障诊断方法和实用技巧,以及Oracle最大高可用性(MAA)体系结构及技术方案
8 SQL应用优化高级课程 3 中高级DBA和应用开发人员 基于Oracle性能优化方法论,结合大量实战案例,系统介绍SQL应用优化技术,如索引策略、优化器原理,针对OLTP和OLAP不同类型系统的优化技术运用过程等

 

 

序号 名称 天数 服务对象 特点及主要内容
 9 Oracle分区技术 2 中高级DBA和应用开发人员 系统介绍适合于海量数据管理的Oracle分区技术。包括分区表和分区索引技术、分区技术运用、11g分区新特性、分区实施经验和案例分析等
10 故障诊断高级课程 2 高级DBA 系统介绍Oracle数据库故障诊断方法论,并介绍常见数据库故障诊断工具(RDA、AWR、ADDM、ASH、OSW、database dump、Hang analysis、diagcollect、CHM)、数据库坏块处理流程、数据库Hang的处理、ORA-4031内存错误的处理、RAC故障诊断方法,以及大量故障诊断实战案例
11 Oracle 11g数据库应用优化高级课程 3 中高级DBA和应用开发人员 系统介绍11g在应用优化方面的新技术。包括优化器高级操作优化、自动SQL优化功能、SQL Tuning Advisor、SQL Access Advisor、SQL PLAN 管理功能、HINT使用技巧,以及大量实战性能优化案例
12 Oracle RAC原理及实施 3 高级DBA 全面介绍Oracle RAC体系结构、RAC安装过程、RAC高可用性测试、RAC运行维护经验、RAC性能分析和优化等,并介绍ASM原理、实施经验等,以及11g在RAC和ASM方面新特性及相关实施案例

 

序号 名称 天数 服务对象 特点及主要内容
 13 Oracle OEM 3 高级DBA 系统介绍Oracle集中监控管理平台OEM的EM Repository、Grid Console、Agent三层架构设计,数据库基本管理功能,数据库在线诊断和优化包使用,报表方案设计,并介绍OEM实施案例
14 Oracle数据库安全性 3 高级DBA 全面介绍Oracle数据库安全体系结构,并介绍Oracle数据库安全加密技术,Oracle DB Vault,Oracle DB Mask,Oracle Audit Vault 等典型技术及实施案例
15 数据仓库设计和建模 3 数据仓库设计、开发和管理人员 面向数据仓库系统,介绍业务和逻辑模型设计、多维数据模型、物理模型、容量规划、典型ETL技术、汇总管理等内容,以及数据仓库实施案例
16 Oracle容灾课程 2 高级DBA 介绍Oracle容灾产品Data Guard的体系结构,物理Data Guard和逻辑Data Guard实施过程和日常运行维护管理,Data Guard优化技术和11g新特性,以及Data Guard若干实施案例

 

序号 名称 天数 服务对象 特点及主要内容
 17 11g新特性 3 数据库设计、开发人员和DBA 系统介绍11g新特性,包括SQL自动性能优化技术、SQL PLAN、Database Replay、SPA、分区新技术、SecureFiles、SQL Result Cache、RMAN新特性、安全性新技术等,以及11g实施案例
18 12c新特性 2 数据库设计、开发人员和DBA 介绍12c若干新特性:CDB和PDB概念和架构、CDB和PDB日常管理;以及信息生命周期管理新技术,如Heat Map和ADO技术、数据归档新技术等。
19 Oracle综合高级技术 3 数据库设计、开发人员和DBA 围绕11g新特性、11g升级解决方案、性能优化、分区技术、Oracle容灾解决方案等高级技术进行介绍,并介绍相关实施案例
20 Exadata 2 高级DBA 介绍Exadata原理和体系结构,Exadata 安装和配置,Exadata Database Michine和Exadata Storage Server日常运行维护、常见故障诊断,Exadata备份恢复,迁移至Exadata技术方案等,并介绍相关实施案例
21 Oracle TimesTen内存数据库 2 高级DBA 介绍Oracle TimesTen内存数据库基本原理,TimesTen内存数据库日常管理、并发控制和性能优化,TimesTen复制技术、TimesTen高可用性方案,以及相关实施案例。
22 Oracle云计算及数据整合技术 2 高级DBA Oracle云计算总体策略,数据库云计算平台(DBaaS),Oracle虚拟机技术,云计算的容灾和安全性,主要数据整合和迁移技术等,以及相关实施案例

 

 

ORACLE DB数据库常见问题解决及诊断技巧集锦 – ORACLE DBA故障修复必备手册

ORACLE DBA故障修复必备手册 本文地址:http://www.askmaclean.com/archives/oracle-troubleshooting.html

 

 

关于Oracle数据库问题诊断信息获取

在对Oracle数据库相关情况及问题进行诊断及信息捕获时, 请:

 

  1. 请确认MAX_DUMP_FILE_SIZE 参数设置, 这将避免用以诊断的追踪文件(trace file)因为空间不足而被截断 !!!

 

  1. 上传alert.log文件。11g中,文本形式的alert.log是放在ADR home相应”trace”目录下。而XML形式的alert.log则是放在ADR home下的”alert”目录下。如需验证ADR home确切位置,可以执行”select * from v$diag_info” 并从其输出中找到。
    请看下页诊断追踪文件目录地址信息。

 

  1. 获取RDA收集信息 (版本4.2x以上更佳). 请查看MOS文档 330363.1314422.1以了解更多信息。

 

  1. 请对所遇问题提供详尽描述以便于分析并更快找到问题原因。

对于 较为严重的问题, 请提供:

  • 相关业务及技术评估
  • 两名24×7联系人,并提供相关人员邮件及电话联系方式(askmaclean.com)。
  • 一名相关管理联系人,需提供其邮件及电话联系方式。

 

问题细节描述:

  • 受影响日期时间
  • 相关报错号及其文本信息。
  • 相关问题影响 – 数据库实例奔溃, 进程失败等.?
  • 错误出现频率?
  • 错误是否可重演。
  • 错误是否总在特定日期时间发生?
  • 错误发生是否与数据库相关活动有关?如备份或高负载处理时.
  • 错误是否总是来自于某个应用或某位用户?
  • 第一次产生此错误是在何时?当时是否正在做何改动?
  • 当时是否有其他错误发生(例如ORA-7445 或 ORA-600错误)?
  • 最近系统是否有任何改变?

 

  1. 如果你还不确定set events操作会带何种影响,请不要设置。

 

  1. 随着Oracle 11g诊断追踪文件默认地址的改变。下表展示了以前(10g以及之前版本)和最新11g(ADR)的跟踪文件目录位置。

 


诊断追踪文件目录地址

 

诊断数据文件 之前版本文件路径 ADR中文件路径
Foreground process traces USER_DUMP_DEST $ADR_HOME/trace
background process traces BACKGROUND_DUMP_DEST $ADR_HOME/trace
Alert log data BACKGROUND_DUMP_DEST $ADR_HOME/alert&trace
Core dumps CORE_DUMP_DEST $ADR_HOME/cdump
Incident Dumps USER|BACKGROUND_DUMP_DEST $ADR_HOME/incident/incdir_n

 

Oracle数据库11g并没有对前台和后台追踪文件做区分。两种类型文件都放在$ADR_HOME/trace目录下。

 

  1. 请注意BDE及其开发需要11g漏洞 IPS打包服务. 在11g中IPS(Incident Packaging Service事件打包服务) 提供了一种对诊断信息打包的简便方法。

 

所有数据库事件(严重错误)的跟踪文件都被存储在Oracle自动诊断库(Automatic Diagnostic Repository: ADR)中。其提供的ADRCI工具被用于打包所有文件并上传给Oracle支持。从OEM中也能找到IPS相关链接服务。请参考以下文档了解更多相关信息:

 

Note:422893.1 – 11g Understanding Automatic Diagnostic Repository.

Note:443529.1 – 11g Quick Steps to Package and Send Critical Error

Note:1091653.1 – 11g Quick Steps – How to create an IPS package using Support Workbench

 

并非11g中所有问题都需生成诊断包. 但对于以下相关11g错误及SR应该考虑获取相关诊断包(askmaclean.com)。
Manageability:

ORA-600 & ORA-7445

ORA-4030 & ORA-4031

 

DB Admin:

ORA-600, ORA-700 & ORA-7445

 

HA:

ORA-600 & ORA-7445

ORA-8103 – Object no longer exists

ORA-1410 – Invalid ROWID

ORA-1578 – Oracle data block corruption

ORA-376 – File cannot be read at this time

ORA-353 – There is a log corruption near a block, change, and time

 

以下是一个例子 à

 

客户看见alert.log中出现以下错误:

Errors in file d:\oracle\diag\rdbms\twn11g\twn11g1\trace\twn11g1_ora_201116.trc:

ORA-00600: internal error code, arguments: [17099], [], [], [], [], [], [], [], [], [], [], []

Errors in file d:\oracle\diag\rdbms\twn11g\twn11g1\trace\twn11g1_ora_201116.trc (incident=19569):

ORA-00600: internal error code, arguments: [17099], [], [], [], [], [], [], [], [], [], [], []

Incident details in: d:\oracle\diag\rdbms\twn11g\twn11g1\incident\incdir_19569\twn11g1_ora_201116_i19569.trc

 

…因此我们看见事件号为 19569.
在正确设置11g环境变量后,通过ADRCI(命令)进入IPS打包处理服务:

 

% adrci

 

因为我们已经知道事件号为19569, 那执行下一步:

 

adrci> ips pack incident 19569

 

…这样就在当前目录下建立了zip压缩包.如果你希望压缩包保存在其它目录中, 那么可以在命令后加上路径信息:

 

adrci> ips pack incident 19569 in D:/tmp/whatever

 

此命令会提示信息产生了包含事件号19569相关信息的IPS打包文件。这个zip压缩文件之后需要被上传到SR上。

 

诊断数据库挂起(HANG)事件

请具体表述问题。并询问用户是否能“解冻”数据库?如何做到的?

  • 使用以下命令生成HANGANALYZE追踪文件 ==>

 

$ sqlplus “/ as sysdba”

SQL> oradebug hanganalyze 3

… Wait 90 seconds (to 2 minutes) to give time to identify process state changes.

SQL> oradebug hanganalyze 3 (level 4 dumps leaf nodes as well and may be useful, but there is more impact on the system)

 

使用以下语法在执行RAC级HANGANALYZE:

 

ORADEBUG setmypid

ORADEBUG setinst all

ORADEBUG -g all hanganalyze 3

 

 

2) 在运行Hanganalyze之后,登入一个新SQL会话来生成系统状态转储(dump)文件==>

 

$ sqlplus “/ as sysdba”

SQL> oradebug setmypid

SQL> oradebug unlimit

SQL> oradebug dump systemstate 266

… wait 90 seconds

SQL> oradebug dump systemstate 266

… wait 90 seconds

SQL> oradebug dump systemstate 266

 

Level 266和267包含了一些堆信息。Level 266是对单实例的信息转储,而Level 267则是对RAC系统systemstate转储。请看Note:300870.1对事件10998了解更多信息。

 

**Note: 我们同样可以通过使用Hang File Generator (HANGFG) 工具来完成以上1)和2)中使用hanganalyze和systemstate收集信息的操作。HANGFG工具提供了一系列UNIX shell脚本命令来自动化收集和生成hanganalyze和sysemstate追踪文件。在使用HANGFG生成并收集追踪文件时需要考虑到需要在已处于性能退化的系统中进行诊断的影响。由于影响级别作为此工具参数被传给HANGFG, 所以用户需要做出决定, 在启用此工具时,何种级别的影响是可接受的。当用户选择轻度影响或中等影响(选项1 或2)作为参数时, HANGFG工具同样有能力做出调整以适应用户做出的决定。HANGFG是RAC自识别的,并且能在RAC和非RAC环境中运行。请看Note:362094.1 (the HANGFG User Guide)以了解其相关信息。

 

3) 当hang事件发生后,获取到的Statspack或AWR/ASH(10g/11g)报告是否具有时效性取决于做Statspack快照频繁程度。举个例子,如果你每隔1小时做一次快照,在下一次快照前发生了5分钟的数据库挂起事件。那么快照由于显得时间跨度太长而很难用于分析当时5分钟发生的情况。

 

AWR/ASH报告上的其他相关信息可以在“数据库性能”章节中找到。

 

有时在尝试连接数据库时,你的调试会话也会挂起在那里。这时留给你3种可选方法==>

 

1) 找一个之前已连上的可用会话。

2) 如果你正在使用10g/11g,那么你可以使用-prelim选项来登录数据库:

SQL*Plus. Eg:

sqlplus -prelim / as sysdba

oradebug setmypid

oradebug unlimit;

oradebug dump systemstate 266;

3) 使用操作系统调试器来查看运行进程

  • 获取服务器oracle先关影子进程ID (请注意并非oracle后台进程,调试后台进程可能导致数据库奔溃)…”ps –ef | grep ora”
  • 使用当前系统级调试器(如dbx, adb, gdb等)来获取systemstate:

$ gdb $ORACLE_HOME/bin/oracle <process ID>

(gdb) print ksudss(267)

 

括号中的数字(267)是你希望转储systemstate的级别.

 

**对于RAC挂起事件请看“RAC性能”部分中对于racdiag脚本的使用**

 

通过以下systemstate命令可在同一时点转储所有RAC节点状态:

SQL> oradebug -g all dump systemstate 267

 

总结,你可以上传以下文件:

 

– Hanganalyze输出

– Systemstate 转储(dumps)

– hangfiles.out (如果使用 HANGFG工具命令)

– alert.log

– 在一个很短时间内的Statspack/AWR/ASH 报告

– 可用的系统调试监控输出

 

更多信息,请查阅以下文档:

 


Process Spins (进程消耗CPU资源达100%)

当进程出现spinning现象,可使用以下命令:
(** Busy spin术语解释: 由于程序导致进程不断地检查是否条件为true)

 

sqlplus / as sysdba

SQL> oradebug setospid <OSPID of spinning process>

SQL> oradebug unlimit

SQL> oradebug dump errorstack 3

— wait for 1 minute

SQL> oradebug dump errorstack 3

 

从 pstack命令输出中获取进程call信息:

 

$ pstack <process id of spinning process>

 

可以使用Strace命令来记录系统进程的系统调动及相关进程输入信号等信息:

 

$ strace –p <process id of spinning process>

 

对于RAC系统,可以使用systemstate命令转储相关状态,此命令的使用在“诊断数据库挂起事件”部分有提到。


 ORA-4031错误分析

当试图在共享池中分配大块连续内存而失败时,Oracle会首先从池中清理当前不用的对象从而使得空闲内存碎片(chunk:内存块)得以合并。如果这样仍然没有足够大的单个chunk来满足分配需要,则会产生ORA-04031报错。有许多ORA-04031错误直接原因都是由于共享池的大小或调整不当造成的。

 

Note:ORA-4031错误的进程并不总是内存消耗的元凶。错误的发生仅是因为此进程无法得到所需内存而造成的(askmaclean.com)。

 

如果已经按所有步骤正确设置了共享池大小(SHARD_POOL_SIZE) , 但此问题仍然产生时,除了从应用(例如:使用绑定变量查询替代静态SQL等)入手进行分析解决问题外,也可从其他trace文件中获得共享池的一些快照信息==>

 

修改init.ora参数文件,增加以下事件以从追踪文件中获取相关问题信息:

event = “4031 trace name errorstack level 3”

event = “4031 trace name HEAPDUMP level 3”

 

注意:除非重启实例,否则这个参数文件设置不会起效。从Oracle 9.2.0.5版本起,除了在请求heapdump时使用level 1,2,3 或32 你同样可以使用相同等级并加值536870912.这样将会在此等级上再进一步显示5个最大的subheaps同时每个subheap下显示相关5个最大的heap areas.

如果问题可以重现,则可在执行有问题的SQL语句前,在会话级别对事件进行设置:

SQL> alter session set events ‘4031 trace name errorstack level 3’;

SQL> alter session set events ‘4031 trace name HEAPDUMP level 536870914’;

 

Level 536870912 转储5个最大subheaps并且对应每个subheap将显示其5个最大heap areas。由于ORA-04031错误可能在不同池中发生(共享池,大池,java池,流池等),其level值的设置可参照如下:

 

 

Component Level
PGA 1
SGA 2
Large Pool 32
Streams Pool   64
Java Pool      128

 

Note:  如果4031错误出现频繁,在实例级设置此事件(heapdump 536870914)将会产生许多大的trace文件.  这不仅会影响数据库性能而且可能使数据库挂起 (某些情况下可能会使得数据库崩溃).  因此有必要及时使用以下语句关闭此事件追踪:

 

alter system set events ‘4031 trace name HEAPDUMP off’;

 

我们也通过Library cache转储来帮助确认产生ora-4031问题的游标:

 

sqlplus / as sysdba

SQL> oradebug setmypid

SQL> oradebug unlimit

SQL> oradebug dump library_cache 10

 

请注意:在Oracle 9.2.0.5+, 10g和11g版本中,4031 trace文件默认会在ORA-4031发生时产生并存放于user_dump_dest目录。如果你的数据库版本是其中的一个,那么你就不需要进行相关设置来生成4031 trace 文件。

 

ORA-4031 诊断 à

  • 检查Alert日志并查看错误是否记录。注意不是所有ORA-4031错误都会记录在alert日志中。
  • 如果错误被记录,请检查SGA的哪部分收到此错误。是共享池,大池,java池或streams池?
  • 查询v$sgastat以检查是否有组件表现出非正常增长.
  • 查询v$librarycache并检查:

– 有无无效对象 (多为DDL语句)

– 有无重载 (Library cache可能不够大)

– 内存命中率 (低命中率可能是非共享游标造成的)

  • 检查是否存在高Version Counts的游标。 可通过v$sql_shared_cursor查询. 如果存在某父游标下有许多子游标的情况,检查不可共享的原因. 大量子游标会加快共享池的碎片化. 请确认应用正在使用绑定变量方式查询.

 

更多信息,请看:


ORA-4030 报错

这个错误原因是Oracle服务器进程不能从操作系统上分配出更多内存。含有PGA(程序全局区)的进程其内存的分配取决于服务器的设置。对于dedicated服务器进程,其包含了stack堆栈和UGA(用户全局区), 保存有用户会话信息、游标信息和数据分类排序区。在多线程模式配置(shared服务器)中,UGA是在SGA中进行分配,所以不对ORA-4030报错负责。

 

因此ORA-4030是对需要更多内存(用于stack UGA或PGA)来完成工作的进程而言的。

 

请记住产生ORA-4030错误的进程并非总是内存损耗的元凶,错误的发生仅仅是因为此进程无法取得所需的内存造成的。

 

当你碰到这个错误时,意味着你已不能从系统中分配内存。这可能是由于你的进程本身导致的(如果你的进程正需求很多内存),也可能是其他原因导致操作系统内存被耗尽(如过大的SGA或者太多进程占用了系统的物理内存和虚拟内存)。如何处理此问题?

 

  1. 确定是否还有足够可用内存?使用系统专用工具来检查内存使用情况 (如vmstat, top等).
  2. 是否存在操作系统设定限制? 检查ulimit命令检查当前资源限制.
  3. 是否存在Oracle限制设置? 检查pga_aggregate_target和相关会话的pga内存值.
  4. 找出当前哪个进程正在要求大量内存, 可通过v$statname 和v$sesstat以了解当前最忙的进程.

 

当进程正在稳定增长其所需内存时,我们可以观察它们的运行:

– 通过v$sql_area可以看到哪些命令正被执行:

SQL> select sql_text  from v$sqlarea a, v$session s where a.address = s.sql_address and s.sid = <SID>;

– 你也可以通过heapdump转储来查看它们:

SQL> oradebug setorapid 10 (10是Oracle进程Id, 使用setospid 以设置当前调试进程)

SQL> oradebug unlimit

SQL> oradebug dump heapdump 5

– 如果报错问题间歇性发生或者由于进程失败太快以至于难以捕获(但又很可能是内存大量消耗的根本原因),则我们可以设置事件来获取heapdump转储信息:

SQL> alter sssion set events ‘4030 trace name heapdump level 5’;

…或者直接在 init.ora文件中设置event.

 

更多其他相关信息请看:

  • Note:1 – Diagnosing and Resolving ORA-4030 errors
  • Note:1 – FAQ: ORA-4030


ORA-600错误

理解ORA-600错误含义对于评估客户数据库中可能存在的问题非常重要。ORA-600报错的第一个参数指出了问题所在的相关位置 (如 ORA-600 [XXXX]).对于此错误:

 

  • 至少需要提供相关的 trace文件和log文件.
  • 操作系统错误/消息日志 (如果可用的话, 像坏块问题等)

 

对此问题也有一些新工具可用于加快原因查找。工具使用及其他相关信息支持文档请看:

  • Note:390293.1 – Introduction to 600/7445 Internal Error Analysis
  • Note:153788.1 – Troubleshoot an ORA-600 Error Using the ORA-600 Argument Lookup Tool

 

此外,如果可能,请设法提供测试用例,数据库历史改变细节和出错频繁程度等情况。并查找Oracle在当时自动转储的任何system状态信息文件。

 

 


ORA-1801错误

ORA-1801报错是指日期格式字符串太长以至无法做转换处理. 这仅发生在当几个长字符串按字面值被转换为一个日期部分时。如果当前没有相关错误的trace文件, 我们可以设置以下事件来获取errorstack和 heapdump ==>

 

对应实例级需在init.ora中设置:

event=”1801 trace name errorstack level 3; name heapdump level 13325″

或在系统级设置:

alter system set events ‘1801 trace name errorstack level 3; name heapdump level 13325’;

或在会话级设置:

alter session set events ‘1801 trace name errorstack level 3; name heapdump level 13325’;

 


ORA-7445 错误

当Oracle服务器进程做了某些错误的处理(以至于触发了某种形式的信号违背signal violation)时,会抛出ORA-7445这样一个通用错误, (就像UNIX下的SIGSEGV). 对我们来说,当碰到ORA-7445报错的时候,最重要的事情就是从trace文件中找到call stack trace信息,因为它告诉我们相关违背行为是在哪里发生的。

 

  • 提供相关trace 文件
  • 如果可以的话,请一并提供相关操作系统错误消息日志
  • 如果存在相关core文件, 请从其中抓取出stack trace信息。

 

更多相关其它信息请看:

 

另外,如果可能的话,请提供如测试用例,数据库历史改变信息以及错误放生频繁程度信息等相关信息。请查找当时Oracle自动生成的systemstate转储文件。

 

 


其它ORA-NNNN报错

这里我们讨论下如何诊断一些未预料的Oracle错误(ORA-NNNN)。
在诊断问题前,做一些例行询问(按经验总结,尝试形成一种模式). 例如:

  1. 是否总是同一个用户/应用造成的?
  2. 是否是在数据导入时发生?
  3. 问题是在做了哪些操作或修改了哪些之后产生的?

 

之后,我们需要收集更多信息以了解错误是如何产生的,甚至到哪些语句触发了此问题(如果问题是由一个递归SQL语句造成的话)。为了达到此目的我们需要在会话级或实例级建立Errorstack事件. 如果你能很容易地重现问题,那么用会话级,否则则需要在实例级建立事件。

 

因此,假设我们收到一个ORA-904  “invalid column”报错,我们可以使用:

 

alter session set events ‘904 trace name errorstack level 3’;

alter system set events ‘904 trace name errorstack level 3’;

event = “904 trace name errorstack level 3”  (in the init.ora)

 

一旦我们获取了trace文件,我们就能从以下对象中找出实际产生错误的SQL语句:

  1. “当前执行的SQL”
  2. “当前执行的游标”

然后你就能直接通过这些找到的SQL来重现问题。而这已经足以用来确认出原因。

 

更多相关其他信息请看:


Database Performance数据库性能问题

为诊断数据库性能问题所要收集的信息:

  • 提供对以下问题的回答 à
  • 性能退化影响到了哪些方面?
  • 是否DBA能登陆并检查v$视图?
  • 你是否能将性能回复到正常? 如何做到的?
  • 提供STATSPACK/AWR/ADDM 报告以能对性能问题做一些短期快照. 请不要跑得报告时间段过长超出问题发生时间. 对实例来说,如果问题持续了半小时,那么抓取那个时间段中20分钟的状态为佳。如果你能精确把握整个时间过程,那么在性能问题发生前获取第一个快照,然后在产生性能问题的过程段中获取另一个快照。请不要在两个快照间重启实例,因为这将使得获取的结果变得无意义。
  • 你也可以在系统运行得“不错”的时候做一个快照(相同时间长度),这个快照可以作为和有性能问题的快照对比时基准。
  • 如果我们需要一个更短时间片上信息(不如当前当前的分析需要5到10分钟的详细活动信息), 那么可以查看ASH (Active Session History活动的会话历史) 报告输出. ASH报告工具在判断活动会话数量,查询会话从事的任务和在一段时间最活跃的SQL语句时很有用。它特别擅长用于分析短暂的性能问题。  运行此报告的ashrpt.sql脚本可以在 $ORACLE_HOME/rdbms/admin目录中找到。
  • 收集操作系统参数来衡量其活动(在运行正常和性能不佳时):
  • CPU
  • 磁盘I/O
  • Memory/Swap
  • 进程活动
  • 操作系统监控程序OS Watcher输出
  • 提供 2个 Hanganalyze报告和 3 个Systemstate转储信息报告 (具体请看“数据库挂起”部分章节)。
  • 提供系统RDA收集报告。
  • 提供Oracle LTOM工具收集的信息。

 

更多其他相关信息请看:

 

 


监听器挂起及性能问题

当监听器(Listener)发生性能问题时设置一个级别16的客户端连接追踪。

 

在客户端sqlnet.ora文件中设置参数:

TRACE_LEVEL_CLIENT=16

TRACE_FILE_CLIENT=CLIENT

TRACE_DIRECTORY_CLIENT=full path to directory where you want the trace file created.

TRACE_TIMESTAMP_CLIENT=on

TRACE_UNIQUE_CLIENT=on

 

获取这几分钟监听器进程(tnslsnr)的truss命令输出以及(发生问题的时间段)不同时间点上pstack信息输出。

 

====================================================

 

Truss ==> truss -o /tmp/mytruss -faed -p <pid of listener process>

…这个工具会一直保持追踪直到你终止它。可以使用ctrl-c来终止truss。如果你是在后台运行此工具命令,那么可以通过kill来杀掉truss进程以终止它的运行。

 

Process stack ==> pstack <pid of listener process>

…执行3次此命令,之间间隔30秒左右

 

如果可以的话,做一个短暂的监听器追踪:

=============================================

 

在服务器端sqlnet.ora文件中设置参数::

 

TRACE_LEVEL_SERVER=16

TRACE_DIRECTORY_SERVER=<some_known_directory>

TRACE_FILE_SERVER=server

TRACE_TIMESTAMP_SERVER=ON

TRACE_FILELEN_SERVER=<file_size_in_Kbytes>

TRACE_FILENO_SERVER=<number_of_files>

 

…后2个参数是为了避免服务器上的监听器trace文件过多而设的. 举例如果你在客户端设置了以下参数:

TRACE_FILELEN_SERVER=100

TRACE_FILENO_SERVER=2

 

…那么客户端上的2个100K的trace文件会被先后填满。之后客户端会切换回第一个trace文件继续写入trace信息,覆盖原有的trace内容,当写满后,再到第二个trace文件中写,如此往复。因此在trace信息被覆盖前,你需要将这些文件拷贝到其他目录。

 

我们也可以通过使用LSNRCTL 来对监听器进行追踪,并且此工具会一直运行会话结束(除非你主动关闭它).在 LSNRCTL 命令中不存在“=”符号.

 

LSNRCTL set current_listener listenername

LSNRCTL SET TRC_LEVEL 16

…好了,这样LSNRCTL就开始追踪了. 让它跑一会,这样我们就能看到追踪到的行为信息以及相关的延迟了。

 

在跑了至少5分钟后, 关闭LSNRCTL:

LSNRCTL set current_listener listenername

LSNRCTL SET TRC_LEVEL OFF

 

在使用 LSNRCTL进行追踪时, 在listener.ora文件中设置 ADMIN_RESTRICTIONS_listener_name=ON 以禁止运行时其参数的修改. 这样,监听器就会拒绝SET命令对其参数的修改了。更多信息请看 Note:272633.1.

 

如果需要改变listener.ora中包括ADMIN_RESTRICTIONS_listener_name本身以及其他参数的设置。我们将不得不手工修改listener.ora文件并用RELOAD命令使得参数起效。

 

请注意:  服务器端的追踪并不会在你改了Oracle Net(服务器端) tracing参数为OFF后关闭。它会随着客户端tracing的关闭而自动关闭。如果tracing由于疏忽一直保持启用, 则它可能将导致非常巨大trace文件的产生并损耗服务资源。为了正确关闭Oracle Net server tracing, 在设置tracing参数值为OFF后主动 stop并restart Oracle Net server 进程. 这可能会导致一些进程的关闭并引发数据库重启,严重程度取决于当前涉及到的会话数量。

 

因此,你需要上传以下文件:

 

– 客户端sqlnet trace文件

– 对于客户端低效连接的Pstack trace

– 监听器进程的Truss输出

– 3个对监听器进程的Pstack traces (3 of them).

– alert.log

– listener.log

– listener traces

 

更多其他相关信息请看:


SQL性能问题

对于SQL语句性能问题诊断, 我们需要了解:

  • 对于存在性能问题的SQL语句. 你能否通过使得性能回归正常? 如何修改?
  • 提供SQL在良好和较差性能下的执行计划输出.
  • 设置级别12的事件10046追踪以生成trace文件(在良好和较差性能情况下) à

alter session set events ‘10046 trace name context forever, level 12’;

  • 在良好和较差性能情况下的SQL运行 Tkprof输出
  • 在良好和较差性能情况下的SQL运行时间
  • 在执行计划输出中对涉及对象的定义 (如 DDL).
  • 在执行计划输出中对涉及基表的行数统计
  • 在良好和较差性能情况下的事件10053的trace输出à

 

ALTER SESSION SET EVENTS ‘10053 trace name context forever, level 1’;

 

…为了获取有效 10053 trace信息, 就不可避免需要对SQL语句进行硬解析。我们可以通过改变SQL语句的大小写或空格多少来达到此目的或通过清空共享池(在生产环境中并不推荐)来实现。

 

Oracle 10g及以上版本:

  • 你能使用AWR/Statspack报告和awrsqrpt.sql脚本来获取2个AWR快照之间的SQL语句执行计划。从AWR/StatsPack报告中, 定位产生性能问题的语句的SQL_ID并生成以下:

— 对应SQL_ID的AWR SQL报告

— 以SYSDBA登陆SQL*Plus

— SQL> @?/rdbms/admin/awrsqrpt.sql

— 请确保所使用AWR快照都是来自于获取的SQL_ID地方。

 

  • 对AWR报告中相应SQL_ID的查询提供数据字典信息:

— 以SYSDBA 登陆SQL*Plus.

— SQL> SELECT PLAN_TABLE_OUTPUT FROM

TABLE(DBMS_XPLAN.DISPLAY_CURSOR(‘<sqlid>’));

 

其它信息收集 (特别对于bug) à

对于执行计划的查询性能问题,请收集所有相关查询对象输出转储和其统计参数,通过使用这些信息,我们可以及时重现这些良好和较差的执行计划。

 

更多其它相关信息请看à

  • Note:21154.1 – EVENT: 10046 “enable SQL statement tracing (including binds/waits)”
  • Note:225598.1 – How to Obtain Tracing of Optimizer Computations (EVENT 10053)
  • Note:41634.1 – TKProf Simplistic Overview
  • Note:372431.1 – TROUBLESHOOTING: Tuning a New Query
  • Note:398838.1 – FAQ: Query Tuning Frequently Asked Questions
  • Note:163563.1 – TROUBLESHOOTING: Advanced Query Tuning
  • Note:208340.1 – Troubleshooting SQL Tuning
  • Note:215187.1 – SQLT (SQLTXPLAIN) – Enhanced Explain Plan and related diagnostic info for one DML SQL statement

 

如果由于数据库升级导致的查询性能退化,请看 à

  • Note:160089.1 – Server Upgrade Results in Slow Query Performance
  • Note 258167.1 – Upgrading from 8.1.X to 9.X – Potential Query Tuning Related Issues
  • Note 295819.1 – Upgrading from 9i to 10g – Potential Query Tuning Related Issues
  • Note:752662.1 – TROUBLESHOOTING Query Tuning
  • Note:748200.1 – Slow Performance of Queries After Upgrading To 10g

 


安装/升级/重连问题

对于数据库在安装或重连时发生问题的信息收集:

  • /tmp/OraInstall/oraInstall.err
  • /tmp/OraInstall/oraInstall.out
  • ../oraInventory/logs/installActions.log
  • $ORACLE_HOME/install/make.log
  • 对于补丁安装的OPATCH工具日志

 

更多其他相关信息请看 à


RAC 性能问题

请具体描述问题. 当提到问题发生时间时,请尽量精确,如某个特定时间等。

 

请提供RAC配置细节:

  • 在集群中节点号
  • 确定是否第三方集群件正和集群就绪服务(CRS)一起被使用
  • 注册盘和表决盘的存储类型
  • 确认ASM是否正被使用
  • 每个节点上数据库实例的数量

 

RAC 诊断(racdiag.sql)脚本被用于提供用户友好向导并对RAC挂起会话及低性能情景进行问题排查。脚本包括了用于判断RAC挂起原因而进行收集大量重要调试信息的相关操作信息。此脚本在转储hanganalyze信息的同时,并会在本地目录中建立一个racdiag<timestamp>.out文件。

 

除了从查询输出中判定锁和等待会话之外,racdiag脚本还会动态生成 systemstate 转储和 hanganalyze信息输出。此外, racdiag还提供了内部连接性能的主要度量标准。

 

从文档 135714.1中对于 racdiag的描述 à 这个脚本应该能在RAC环境中出现会话或系统级挂起时运行。脚本应该以SYS用户运行。在运行racdiag脚本前, catparr.sql应该已经以SYS运行过,以在受影响的数据库中建立相关GV$视图。有一些系统挂起类型事件能够阻止racdiag脚本的运行。 如果此脚本跑不起来,那么建议以SYS用户在每个节点获取systemstate转储信息以帮助调试问题。

 

请上传以下文件:

  1. sql脚本输出文件
  2. 每个节点的AWR/ASH报告或 Statspack输出
  3. 操作系统监控器输出(如果此监控器正运行在当前系统上)

 

相关racdiag脚本及其他信息请看à

  • Note:135714.1 – Script to Collect RAC Diagnostic Information (racdiag.sql)
  • Note:412894.1 – Diagnosing Hangs and Troubleshooting Performance Issues in a RAC Environment
  • Note:556679.1 – Data Gathering for Troubleshooting RAC Issues
  • Note:810394.1 – RAC Assurance Support Team: RAC Starter Kit and Best Practices

 


RAC实例驱逐问题

请具体描述问题. 当提到问题发生时间时,请尽量精确,如某个特定时间等。

请提供RAC配置细节:

  • 集群中的节点数量
  • 是否有第三方集群件正和集群就绪服务(CRS)一起被使用
  • 注册盘和表决盘的存储类型
  • 确认ASM是否正被使用
  • 每个节点上数据库实例的数量

 

对于实例驱逐被踢(Eviction)问题的诊断– 如ORA-29740错误, 请参考以下文档来做数据收集工作:

  • Note 219361.1 – Troubleshooting ORA-29740 in a RAC Environment
  • Note:412884.1 – Data Gathering for Instance Evictions in a RAC environment

 

至少你需要上传:

  1. 对于此类问题,除了上传数据库实例后台进程相关trace文件以外, 也要上传(每个实例)RAC特定后台进程 (如LMON, LMS, LCK, LMD, DIAG 等) 相关trace文件.

注意: 如果问题导致实例重起, 请确保以上上传文件来自重起之前的实例。

  1. 每个实例的告警日志文件
  2. 获取被踢的每个实例AWR/ASH报告或 Statspack输出
  3. 使用pl工具来收集Oracle集群件日志. 更多详情请看文档 330358.1. 运行diagcollection.pl时,使用 ‘–nocore’参数选项可降低输出的文件大小.
  4. 系统消息日志,具体文件位置取决于所使用的操作系统:

– Linux: /var/log/messages

-Windows: 使用事件查看器查看保存的应用日志和系统日志TXT文件。 – Sun: /var/adm/messages

– IBM: /bin/errpt -a (被重定向到messages.out文件)

– HP-UX: /var/adm/syslog/syslog.log

– Tru64: /var/adm/messages

  1. 如果有操作系统监控器运行,则也请获取所有节点的监控器输出

 

注意:Oracle实例被启动后,每个相关后台进程(PMON,SMON,LMS,DIAG等)会产生一个trace文件。之后仅当需要转储trace文件时,才会继续对这个trace 文件进行写入。请不要删除这些文件。如果你删除了属于某个后台进程的Trace文件, Oracle trace信息仍会保持向这个节点位置中写入。这造成了有用的诊断信息被丢失。如果你发现属于某个Oracle数据库后台进程trace文件被删除,请按My Oracle Support文档中提供的步骤来重建它:

Note:394891.1 – How to recreate background trace file(s) that may have been accidentally deleted


Oracle集群就绪服务(CRS)问题

对于CRS问题:

 

  • 如果正在使用第三方提供的clusterware (SFRAC, SUN Cluster等.), 首先判断是否第三方cluster正在运行 (参考文档 803661.1).

 

  • 检查当前CRS是否正在运行:

◦ crsctl check crs

◦ crs_stat –t

 

  • 检查是否所有私有内连接都起了并可ping通

◦ ifconfig –a

◦ traceroute <private interconnect IP>

 

  • 检查表决盘(voting disks)和注册盘(OCR)都可以从所有节点访问到

◦ ocrcheck

◦ ls –l <full path of voting disk>

 

  • 请提供以下信息:
  • sql输出
  • CLUVFY (Cluster 验证工具) 输出.
  • 系统消息日志. 其存放位置取决于当前操作系统:

– Linux: /var/log/messages

– Windows: 使用事件查看器查看保存的应用日志和系统日志TXT文件。

– Sun: /var/adm/messages

– IBM: /bin/errpt -a (重定向到 messages.out文件)

– HP-UX: /var/adm/syslog/syslog.log

– Tru64: /var/adm/messages 如果监控工具正在运行,其操作系统监控输出将存放在此目录中

  • 从每个cluster节点上的三个目录树中收集所有CRS日志文件, trace文件和core转储文件 :

– $CRS_HOME (css/log css/init crs/log crs/init evm/log evm/init srvm/log racg/dump log)

– $ORACLE_HOME (racg/dump admin/*/hdump)

– $ORACLE_BASE (admin/*/hdump)

…也可以用另一种方法获取打包的trace文件:

$CRS_HOME/bin/diagcollect.pl

 

其他相关信息请看:

  • Note 339939.1 – Running Cluster Verification Utility to Diagnose Install Problems
  • Note 272332.1 – CRS 10g Diagnostic Collection Guide
  • Note 330358.1 – CRS 10gR2/ 11gR1/ 11gR2 Diagnostic Collection Guide
  • Note:289690.1 – Data Gathering for Troubleshooting CRS Issues
  • Note:783456.1 – CRS Diagnostic Data Gathering: A Summary of Common tools and their Usage
  • Note:556679.1 – Data Gathering for Troubleshooting RAC Issues
  • Note:357808.1 – Diagnosability for CRS / EVM / RACG as directed by Oracle support


Data Guard 日志传输和物理应用

– 确认归档日志是否成功被传送到备库。

– 判断Data Guard设置是非级联设置的还是级联设置,物理备库设置还是逻辑备库设置。- 确认主库是归档日志模式并已开启自动归档。

– 确认归档有足够空间。

– 判断是否产生错误的条件都满足。

– 确认备库处于mounted状态。

– 确认managed recovery 正在运行.

 

其他相关信息请看:

  • Note:237213.1 – Troubleshooting Data Guard
  • Note:312434.1 – Oracle10g Data Guard SQL Apply Troubleshooting
  • Note:814417.1 – Dataguard Information gathering to upload with the Service Requests
  • Note:241374.1 – Script to Collect Data Guard Primary Site Diagnostic Information
  • Note:241438.1 – Script to Collect Data Guard Physical Standby Diagnostic Information


Data Guard网络故障

– 检查系统瓶颈: CPU (sar -u), I/O (iostat), Memory (vmstat)

– 数据库等待事件 (ARCH 传输, SYNC传输等.)

– 查看Statspack Stats报告 (重做率”redo rate”, 事务率”transaction rate”, 平均重做写大小”average redo write size”,…)

– 检查网络 (备库是否可连?, 是否有网络错误?, 网络带宽是否足够?)

– 检查alert.log (主库和备库)文件中的所有错误.

– 检查系统消息日志中的错误. 日志文件位置取决于你所用的系统:

– Linux: /var/log/messages

– Windows: 应用日志和系统日志被保存为 .TXT文件并使用事件查看器查看

– Sun: /var/adm/messages

– IBM: /bin/errpt -a (重定向到文件 messages.out)

– HP-UX: /var/adm/syslog/syslog.log

– Tru64: /var/adm/messages

 

更多其他信息请看:

 

 


Streams 错误及问题

对于问题解决及原因分析,请à

 

  • 具体描述问题。
  • 描述Streams设置信息 – local capture or downstream capture, number of Streams database, unidirectional or bi-directional replication, etc.
  • 来自源和目标系统的Alert 文件.
  • 当报告Streams问题时,请提供源和目标数据库健康检查报告 (请看 Note 273674.1)
  • 运行Streams 故障发现查询脚本. 参考 Note 729860.1.
  • 对于STREAMS 性能问题:

◦ 请参考Streams Performance recommendations (Note 335516.1).

◦ 请参看Note 290605.1在源和目标数据库运行STRMMON.

◦ 生成源及目标数据库当时时段AWR/ASH/ADDM报告.

 

更多其他信息请看à

  • Note:746247.1 – Troubleshooting Streams Capture when status is Paused For Flow Control
  • Note:335502.1 – How To Reinstantiate a Single Table in a Streams Environment
  • Note:749036.1 – How to re-synchronize the streams replicated objects online
  • Note:405541.1 – Print the LCR’s listed in the Error Queue
  • Note:291686.1 – LogMiner Utility Release 8.1.x – 10g

 

 


Streams 应用(Apply)

当对Streams Apply进程进行问题诊断时,我们需要注意以下3种情况:

 

1) 没有事务到达目的地

  • 检查apply进程状态并确认其是启用的
  • 确认apply进程是否还没使事务出队列。
  • 检查队列的传播是否有发送事务到应用端
  • 检查相关规则是否有在global, schema和table每个级别上正确建立以控制(获取capture, 传播propagation, 应用apply)
  • 检查 init.ora文件
  • 检查BACKGROUND_DUMP_DEST下的trace文件

 

2) 事务到达了目的地端, 但没有出队列.

  • 确认是否 apply进程没有让任何事务出队列
  • 检查出错队列
  • 检查是否有定义冲突的方案
  • 检查对象实例化SCN
  • 检查当前数据库 SCN值
  • 检查BACKGROUND_DUMP_DEST下的trace文件

 

3) 事务到达目的地端并出队列, 但没有被应用.

  • 检查apply进程延迟
  • 检查出错队列
  • 检查是否有定义冲突的方案
  • 检查对象实例化SCN
  • 检查当前数据库 SCN值
  • 检查BACKGROUND_DUMP_DEST下的trace文件

 

注意: 任何情况下, 请通过Streams健康检查脚本以提供报告输出。

 

请看以下文档以便了解与上文相关的更详细信息 à

  • Note:230898.1 – How To Troubleshoot the Streams Apply Process
  • Note:273674.1 – Streams Configuration Report and Health Check Script
  • Note:730036.1 – Overview for Troubleshooting Streams Performance Issues
  • Note:418755.1 – 10gR2 Streams Recommended Configuration
  • Note:789913.1 – Streams Troubleshooting guide step by step
  • Note:779801.1 – Streams Conflict Resolution
  • Note:265201.1 – Troubleshooting Streams Apply Error ORA-1403, ORA-26787 or ORA-26786

 

 


高级队列传播(AQ propagation)问题

如果你碰到高级队列传播问题 (很慢或卡住), 请收集以下信息:

 

sqlplus / as sysdba

 

oradebug setospid  <spid of the j00 background process executing the schedule>

oradebug unlimit

oradebug Event 10046 trace name context forever, level 12

–等待10分钟

oradebug Event 10046 trace name context off

exit

 

sqlplus / as sysdba

oradebug setospid  <spid of the j00  background process executing the schedule>

oradebug unlimit

oradebug Event 24040 trace name context forever, level 10

–等待10分钟

oradebug Event 24040 trace name context off

exit

 

oracledebug tracefile_name命令能显示trace文件在哪里生成

 

当传播问题发生,我们需要从所有实例中获取相关systemstate转储信息à

 

sqlplus / as sysdba

oradebug setmypid

oradebug unlimit

oradebug -g all dump systemstate 266

— 等大约2分钟

oradebug -g all dump systemstate 266

 

 

相关其他信息请看 à

  • Note:233099.1 – Troubleshooting Advanced Queuing Propagation
  • Note:102926.1 – Performance Tuning Advanced Queuing Databases and Applications


复制问题(Replication)

相关信息请看:

  • Note:1035874.6 – Troubleshooting Guide: Replication Propagation
  • Note:122039.1 – Troubleshooting Basics for Advanced Replication
  • Note:231499.1 – Multi-Master Replication: Diagnostic Information Required & What To Check

 

 


 ASM 问题诊断 (包括在空闲空间存在并可用时的 ASM磁盘空间耗尽报错)

====================================================================

 

▪请执行My Oracle Support Note:351117.1 中的ASM调试脚本 (收集诊断ASM空间问题所需信息)

 

▪ 提供ASM alert.log文件, traces 及操作系统消息文件 (可能同时需要数据库和 ASM alerts 和traces文件)

 

更多其他信息请看à

  • Note:340417.1 – Data Gathering for Troubleshooting ASM Issues
  • Note:309815.1 – Configuring Oracle ASMLib on Multipath Disks
  • Note:284646.1 – Creating and using the kfed utility to view ASM disk header

 

 


消息网关(Message Gateway)问题

当消息网关不处理任何信息,请获取以下诊断信息进行分析:

 

对Hang问题及 系统State进行信息收集及转储à

 

sqlplus / as sysdba

oradebug setmypid

oradebug unlimit

oradebug –g all hanganalyze 3;

 

等待30秒后再次运行hanganalyze…
oradebug setmypid

oradebug unlimit

oradebug –g all hanganalyze 3;

 

Sqlplus / as sysdba;

oradebug setmypid;

oradebug unlimit;

oradebug –g all dump systemstate 266;

 

等待30秒后再次运行hanganalyze…

 

oradebug setmypid;

oradebug unlimit;

oradebug –g all dump systemstate 266;

 

当消息网关不处理消息时,扩大gateway日志级别以收集更多gateway进程相关信息。

 

sqlplus / as sysdba;

SELECT * FROM MGW_GATEWAY;

exec DBMS_MGWADM.SET_LOG_LEVEL (3);

 

上传MGW trace文件.

 

获取MGW Java进程相关thread转储文件:

 

ps -ef | grep mgwextproc

 

使用以下脚本命令得到JVM下的thread转储信息

 

for pids in `ps -ef | grep mgwextproc | awk ‘{print $2}’`

do

echo $pids

kill -3 $pids

done

Trace文件会在当前工作目录中产生。请上传这些trace文件。

 

 

ORA-3113错误

ORA-3113错误通常产生自Oracle客户端工具。此错误意味着客户端未能和Oracle影子进程进行通讯。此错误常常需要我们收集更多的信息来帮助分析原因,且原因也多种多样。因此这种“oracle影子进程通讯失败”错误是一种“普遍涉及”类型。ORA-3113常发生在当由于某些原因致Oracle服务器进程死亡时。

 

我们需要更多信息用来判断错误成因:

 

  1. 错误是发生在尝试建立数据库连接时或在一个已经建立的连接上?
  2. 在USER_DUMP_DEST(或11g上的$ADR_HOME/trace)目录下存在相关失败会话的trace文件。
  3. 此错误是因为特定命令造成的或是随机产生的? 如果是由于特定命令造成的,在会话级别开启 SQL_TRACE以找到问题命令.

 

其他相关信息,请看 à

 

 


数据库/实例崩溃

为方便解决及原因分析, 请提供以下内容 à

 

  • BACKGROUND_DUMP_DEST或$ADR_HOME/trace下的Alert.log文件
  • Alert log文件中最新涉及的错误(如ORA-600或ORA-7445)相关的trace文件.
  • 当时Oracle自动收集的系统状态转储文件
  • RDA (Remote Diagnostic Agent远程诊断代理)输出,可参考Note 314422.1

 


数据库块讹误(Corruption)

有很多原因可能造成坏块,其包括:

– IO硬件损坏

– 操作系统问题

– Oracle造成的问题

– 对数据库中已使用”UNRECOVERABLE”或”NOLOGGING”关键字命令操作的数据恢复(这种情况会提示ORA-1578错误)

 

Oracle发现并报错的时间可能晚于数据最初产生讹误的时间。

由于并非总能了解当时坏块产生的原因,而多数情况下,关键业务需求数据库立即响应并再次开始运行,因此以下步骤用于处理当前问题:

 

  • 判断数据讹误问题的影响程度及范围,是临时的还是永久不可恢复的错误。如果坏块大范围出现或者错误在各处不断产生,那么就需要先集中精力先确定问题原因(如检查硬件设备等)。这一点很重要,如果你的硬件本身出了问题,那怎么操作都无法恢复系统。

 

  • 替换或移走(可能)存在问题的硬件设备。

 

  • 判断哪些数据库对象收到了影响。

 

  • 选择最恰当的数据库恢复/数据解救方案。

 

 

为方便解决及原因分析, 请提供以下内容à

 

  • BACKGROUND_DUMP_DEST 或 $ADR_HOME/trace下的Alert.log文件
  • Alert log文件中最新涉及的错误(如ORA-600或ORA-7445)相关的trace文件
  • Block转储及其他相关诊断信息,可参考 Note 28814.1
  • RDA (Remote Diagnostic Agent远程诊断代理)输出,可参考Note 314422.1

 

更多相关信息请看à

  • Note:1088018.1 – Master Note for Handling Oracle Database Corruption Issues
  • Note:28814.1 – Handling Oracle Block Corruptions in Oracle7/8/8i/9i/10g/11g
  • Note:412566.1 – Basics of Debugging/Getting Dumps on Windows and Unix Platforms for Internals/Corruption Analysts
  • Note:76375.1 – Prevention, Detection and Repair of Database Corruption

 

 


RMAN 报错

问题解决及原因分析à

 


Oracle企业管理器 / 网格控制(OEM/Grid Control)

 

为方便问题解决及原因分析,请à

 

  • 具体描述问题
  • 对于EM Agent问题:

– 打包压缩并上传$AGENT_HOME/sysman/log中的文件

– $AGENT_HOME/sysman/config/emd.properties文件

Note 229624.1 – How to Log and Trace the EM 10g Management Agents

  • 对于OMS错误及问题:

– 打包压缩并上传$OMS_HOME/sysman/log中的文件

– $AGENT_HOME/sysman/config/emoms.properties文件

Note 229627.1 How to Log and Trace the EM 10g Management Service

Note 421053.1– EMDiagkit Download and Master Index

 

更多相关信息请看 à

 

 


SQL*Net 报错

问题解决及原因分析à

 

  • Note:16564.1 – SQL*Net V2 on Unix – A Quick Guide to Setting Up Client Side Tracing
  • Note:219968.1 – SQL*Net, Oracle Net Services – Tracing and Logging at a Glance
  • Note:67983.1 – Oracle Net Performance Tuning

 

 


补丁应用问题

问题解决及原因分析à

 

为了调试检查补丁问题,需要设置:

◦ export OPATCH_DEBUG=TRUE

◦ export PERL_DL_DEBUG=1

 

请看相关信息 à

 

 


JDBC事件

问题解决及原因分析 à

 

 

 


Memory Leaks内存泄漏

内存泄漏是指当进程始终不能归还其做临时使用而分配的内存时,可用内存在这种分配下逐渐损失的情况。内存泄漏最终可导致可用内存不断变少最终耗尽。如果不做检查,那些正受到内存泄漏的进程将不断增长对内存的需求直到其达到当前系统对用户模式下进程设置所允许的最大值。因此,对内存基线需求和内存泄漏之间的判断就很必要了。当然内存使用的增长并不一定归因于内存泄漏。

 

问题解决及原因分析à

 

  • Note:477521.1 – How To Troubleshoot Memory Leaks on Microsoft Windows
  • Note:477522.1 – How To Troubleshoot Memory Leaks on UNIX
  • Note:1003841.1 – Diagnosing swap full problems/possible memory leak issues
  • Note:166490.1 – Diagnosing Oracle memory on HP using GLANCE
  • Note:163763.1 – Diagnosing Oracle memory on Sun Solaris using PMAP
  • Note:166491.1 – Diagnosing Oracle Memory on AIX using SVMON
  • Note:403584.1 – Understanding and Diagnosing ORA-600 [729] Space Leak Errors

 

 

 

 

 

dbDao.com支付遇到问题?

dbDao.com支付遇到问题?

PRM-DUL成功助力安徽某乙方恢复了用户数据库

PRM-DUL成功助理安徽某乙方恢复了用户涉及到大量图片BLOB的数据库,该数据库由于存储异常且无任何备份导致无法打开和恢复:

 

最新版PRM-DUL下载地址: http://parnassusdata.com/sites/default/files/ParnassusData_PRMForOracle_3206.zip

免费的PRM-DUL License :http://www.parnassusdata.com/zh-hans/node/122 

 

 

prm-dul win 2 prm-dul win3 prm-dul win1

【Oracle数据库恢复】ORA-00600 [4194]: 内部错误代码, 参数: [4194]又一例

某用户11.1.0.6的系统在系统断电重启后遭遇了ORA-600 [4194]错误:

 

Starting background process QMNC
Wed Dec 10 21:26:24 2014
QMNC started with pid=21, OS id=2932
Errors in file d:\app\administrator\diag\rdbms\erp\erp\trace\erp_smon_3612.trc (incident=33600227):
ORA-00600: 内部错误代码, 参数: [4194], [60], [59], [], [], [], [], []
Incident details in: d:\app\administrator\diag\rdbms\erp\erp\incident\incdir_33600227\erp_smon_3612_i33600227.trc
Doing block recovery for file 3 block 4378
Block recovery from logseq 1, block 127 to scn 1309041534
Recovery of Online Redo Log: Thread 1 Group 1 Seq 1 Reading mem 0
Mem# 0: D:\APP\ADMINISTRATOR\ORADATA\ERP\REDO01.LOG
Block recovery stopped at EOT rba 1.129.16
Block recovery completed at rba 1.129.16, scn 0.1309041534
Doing block recovery for file 3 block 121
Block recovery from logseq 1, block 127 to scn 1309041531
Recovery of Online Redo Log: Thread 1 Group 1 Seq 1 Reading mem 0
Mem# 0: D:\APP\ADMINISTRATOR\ORADATA\ERP\REDO01.LOG
Block recovery completed at rba 1.128.16, scn 0.1309041533
Errors in file d:\app\administrator\diag\rdbms\erp\erp\trace\erp_smon_3612.trc:
ORA-01595: 释放区 (2) 回退段 (8) 时出错
ORA-00607: 当更改数据块时出现内部错误
ORA-00600: 内部错误代码, 参数: [4194], [60], [59], [], [], [], [], []
LOGSTDBY: Validating controlfile with logical metadata
LOGSTDBY: Validation complete
Wed Dec 10 21:26:26 2014
Trace dumping is performing id=[cdmp_20141210212626]
Wed Dec 10 21:26:31 2014
Sweep Incident[33600227]: completed
Wed Dec 10 21:26:31 2014
Errors in file d:\app\administrator\diag\rdbms\erp\erp\trace\erp_m004_4524.trc (incident=33600347):
ORA-00600: 内部错误代码, 参数: [4194], [60], [59], [], [], [], [], []
Incident details in: d:\app\administrator\diag\rdbms\erp\erp\incident\incdir_33600347\erp_m004_4524_i33600347.trc
Trace dumping is performing id=[cdmp_20141210212632]
Doing block recovery for file 3 block 4378
Block recovery from logseq 1, block 127 to scn 1309041534

ump of buffer cache at level 4 for tsn=2, rdba=12587290
BH (0x000000016BFB7308) file#: 3 rdba: 0x00c0111a (3/4378) class: 32 ba: 0x000000016B7EA000
set: 11 bsz: 8192 bsi: 0 sflg: 2 pwc: 51 lid: 0x00000000,0x00000000
dbwrid: 0 obj: -1 objn: 0 tsn: 2 afn: 3
hash: [0x00000001E2F7DCC0,0x00000001E2F7DCC0] lru: [0x000000016BFB74C8,0x000000016BFB7268]
obj-flags: object_ckpt_list
ckptq: [0x000000016BF8F7F8,0x000000016BFB7478] fileq: [0x00000001E3BDB698,0x000000016BFB7488] objq: [0x000000016BFEAFC8,0x000000016BF821D8]
use: [0x00000001D8653448,0x00000001D8653448] wait: [NULL]
st: XCURRENT md: EXCL tch: 0
flags: buffer_dirty mod_started gotten_in_current_mode
change state: ACTIVE
change count: 1
LRBA: [0x14.7d.0] LSCN: [0x0.4e0c7c32] HSCN: [0x0.4e0c7c32] HSUB: [65535]
cr pin refcnt: 0 sh pin refcnt: 0
buffer tsn: 2 rdba: 0x00c0111a (3/4378)
scn: 0x0000.4e0662ff seq: 0x02 flg: 0x04 tail: 0x62ff0202
frmt: 0x02 chkval: 0xa54a type: 0x02=KTU UNDO BLOCK
*** ktuc_diag_dmp: dump of redo for rdba 0x00c0111a
Cleaning up copy latch 0
Copy latch cleanup completed
DUMP REDO
Opcodes *.*
DBAs (file#, block#):
(3, 4378) .
SCNs: scn: 0x0000.00000000 thru scn: 0xffff.ffffffff
**NOTE: Only Dumping Redo less then 12 hours**
Times: 12/10/2014 21:23:27 thru eternity

*** 2014-12-11 09:23:27.382
SCN Start Scan Point: scn: 0x0000.4e0bd8c2 (1309399234)
INCARNATION:
START: scn: 0x0000.4e0662ee (1309041390) Timestamp: 12/10/2014 21:26:17
END: scn: 0xffff.ffffffff
descrip:"Thread 0001, Seq# 0000000018, SCN 0x00004e0bd8c2-0x00004e0c295e"

REDO RECORD - Thread:1 RBA: 0x000012.00000002.0010 LEN: 0x0070 VLD: 0x05
SCN: 0x0000.4e0bd8c4 SUBSCN: 1 12/11/2014 09:19:10
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:17.3
descrip:"Thread 0001, Seq# 0000000019, SCN 0x00004e0c295e-0x00004e0c79f5"

REDO RECORD - Thread:1 RBA: 0x000013.00000002.0010 LEN: 0x0070 VLD: 0x05
SCN: 0x0000.4e0c2960 SUBSCN: 1 12/11/2014 09:20:14
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:17.3
descrip:"Thread 0001, Seq# 0000000020, SCN 0x00004e0c79f5-0xffffffffffff"

REDO RECORD - Thread:1 RBA: 0x000014.00000002.0010 LEN: 0x0070 VLD: 0x05
SCN: 0x0000.4e0c79f7 SUBSCN: 1 12/11/2014 09:23:13
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:17.3
END OF DUMP REDO
Incident 35120409 created, dump file: d:\app\administrator\diag\rdbms\erp\erp\incident\incdir_35120409\erp_ora_548_i35120409.trc
ORA-00600: 内部错误代码, 参数: [4194], [60], [59], [], [], [], [], []

Error 607 in redo application callback
Dump of change vector:
TYP:0 CLS:32 AFN:3 DBA:0x00c0111a OBJ:4294967295 SCN:0x0000.4e0662ff SEQ: 2 OP:5.1
ktudb redo: siz: 208 spc: 1094 flg: 0x0012 seq: 0x91a4 rec: 0x3b
xid: 0x0008.01d.001511ce
ktubl redo: slt: 29 rci: 0 opc: 11.1 objn: 74 objd: 74 tsn: 0
Undo type: Regular undo Begin trans Last buffer split: No
Temp Object: No
Tablespace Undo: No
0x00000000 prev ctl uba: 0x00c0111a.91a4.39
prev ctl max cmt scn: 0x0000.4e065bc8 prev tx cmt scn: 0x0000.4e065be6
txn start scn: 0xffff.ffffffff logon user: 0 prev brb: 12587289 prev bcl: 0 BuExt idx: 0 flg2: 0
KDO undo record:
KTB Redo
op: 0x04 ver: 0x01
compat bit: 4 (post-11) padding: 0
op: L itl: xid: 0x000d.012.000346f7 uba: 0x00c01d8e.1899.2a
flg: C--- lkc: 0 scn: 0x0000.4e0c7c3e
KDO Op code: URP row dependencies Disabled
xtype: XAxtype KDO_KDOM2 flags: 0x00000080 bdba: 0x00400222 hdba: 0x00400221
itli: 1 ispac: 0 maxfr: 4863
tabn: 0 slot: 8(0x8) flag: 0x2c lock: 0 ckix: 0
ncol: 10 nnew: 9 size: 0
Vector content:
col 1: [ 2] c1 02
col 2: [ 2] c1 02
col 3: [ 2] c5 15
col 4: [ 2] c1 02
col 5: [ 1] 80
col 6: [ 2] c3 02
col 7: [ 5] c4 06 4a 13 0b
col 8: [32]
2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d
2d 2d 2d 2d 2d 2d 2d
col 9: [ 1] 80
Block after image is corrupt:
buffer rdba: 0x00c0111a
scn: 0x0000.4e0662ff seq: 0x02 flg: 0x04 tail: 0x62ff0202
frmt: 0x02 chkval: 0xa54a type: 0x02=KTU UNDO BLOCK
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x000000016B7EA000 to 0x000000016B7EC000
16B7EA000 0000A202 00C0111A 4E0662FF 04020000 [.........b.N....]

 

 

 

该ORA-00600: 内部错误代码, 参数: [4194]错误我们之前有多次提过,

【Oracle数据恢复】通过BBED修复ORA-600[4193]和ORA-600[4194]的例子

【Oracle数据恢复】ORA-600[4194]错误一例

 

ORA-600[4194]内部错误一般由重做记录与回滚记录不匹配引发。Oracle在验证Undo record number时,会对比redo change 和回滚段中的undo record number,若发现2者存在差异则报该4194错误。其错误argument[a][b],a代表回滚块中的最大undo record number,b代表重做日志中记录的undo record number。这个错误可能由回滚段或者redo log日志文件讹误引起。

ORA-00600[4194]错误的根本原因是 redo记录与回滚段(rollback/undo)记录之间的不一致。当ORACLE在验证undo记录时相对应的变化需要应用到undo数据块的最大undo记录上,此时若检验出错则会报ORA-00600[4194]

 

ORA-600[4194]的2个的含义:

Arg [a] Maximum Undo record number in Undo block
Arg [b] Undo record number from Redo block

 

以上可以通过trace定位到可能存在触发该UNDO问题的数据块是rdba: 0x00c0111a (3/4378), 该问题一般可以通过设置EVENT、隐藏参数或BBED来修复。

 

 

 

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

 

诗檀软件专业数据库修复团队

 

服务热线 : 13764045638   QQ号:47079569    邮箱:service@parnassusdata.com

沪ICP备14014813号

沪公网安备 31010802001379号

TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569