知识大全一次ORA-4030问题诊断及解决（一）

Posted 2022-07-16 计划

篇首语：劳动教养了身体，学习教养了心灵。本文由小常识网(cha138.com)小编为大家整理，主要介绍了知识大全一次ORA-4030问题诊断及解决（一）相关的知识，希望对你有一定的参考价值。

一次ORA-4030问题诊断及解决（一） 以下文字资料是由(全榜网网www.cha138.com)小编为大家搜集整理后发布的内容，让我们赶快一起来看一下吧！

　　在报表数据库的后台alert文件中发现了这个错误简单记录一下问题的诊断和解决过程数据库版本 for Solaris sparc 　错误信息如下

　　 Errors in file /u /oracle/admin/repdb /bdump/repdb _j _ trc: 　　ORA : error on auto execute of job 　　ORA : out of process memory when trying to allocate bytes (hash join subh kllcqas:kllsltba) 　　ORA : at JSGOV_OLD INSERT_HOS_INFO line 　　ORA : at JSGOV_OLD P_GEN_STAT line 　　ORA : at line

　　这个JOB是昨天才添加到数据库中的而运行这个JOB的用户是从其他数据库迁移到当前数据库中的

　　产生问题的情况有很多种有可能是本地配置和远端配置的区别造成的;也可能是由于源数据库是而当前数据库是版本的差异造成了执行计划改变;还有可能是迁移过程中出现了错误从而引起了问题

　　从错误本身观察是由于无法为HASH JOIN分配 M的内存所导致的观察数据库的PGA内存设置　

　　 SQL> SHOW PARAMETER PGA 　　NAME TYPE VALUE 　　　　pga_aggregate_target big integer

　　对于一个报表系统来说这个设置确实小了一点但是考虑这个数据库在处理很多比当前数据量大得多的情况都未出现这个问题基本上可以确定不是系统参数设置造成的

　　如果排除第一种情况那么无论是迁移出现了问题还是版本差异的问题最大的可能性都是执行计划发生了变化那么现在就需要找到出现问题的SQL语句检查执行计划

　　根据错误信息给出的存储过程名称和位置提示可以轻易的找到出现问题的SQL语句不过由于SQL语句太长而且和问题的关系并不太大这里将SQL语句省略只列出这个SQL语句对应的执行计划　

　　虽然SQL本身写的有缺点但是绝对不应该产生这种包含笛卡儿积的执行计划检查SQL并没有发现缺少关联条件的情况即问题和SQL本身并不大虽然SQL有很多可以优化的地方但是这并不是产生笛卡儿积的关键因素

　　观察执行计划本身除了笛卡儿积之外另人比较疑惑的一点就是返回记录数 Oracle认为全表扫描ORD_HIT_M仅仅返回一条记录这显然是有问题的　

　　 SQL> SELECT COUNT(*) FROM ORD_HIT_M; 　　COUNT(*) 　　　　

　　从这一点上判断可以很容易的断定是统计信息出现了问题检查ORD_HIT_M的统计信息

　　 SQL> SELECT TABLE_NAME NUM_ROWS FROM USER_TABLES 　　 WHERE TABLE_NAME = ORD_HIT_M ; 　　TABLE_NAME NUM_ROWS 　　　　ORD_HIT_M

　　本以为不存在统计信息或者得到一个很小的值没想到统计信息基本上是准确的那么是哪里出现的问题呢

　　观察SQL语句发现对ORD_HIT_M表唯一的限制条件是ENABLE_FLAG= 而这个限制条件其实对过滤数据来说没有多大的意义不过检查执行计划　

　　 SQL> EXPLAIN PLAN FOR SELECT * FROM ORD_HIT_M 　　 WHERE ENABLE_FLAG = ; 　　Explained 　　SQL> SELECT * FROM TABLE(DBMS_XPLAN DISPLAY); 　　PLAN_TABLE_OUTPUT 　　　　　　| Id | Operation | Name | Rows | Bytes | Cost | 　　　　| | SELECT STATEMENT | | | | | 　　| | TABLE ACCESS FULL | ORD_HIT_M | | | | 　　　　Note: cpu costing is off PLAN_TABLE is old version 　　 rows selected 　　看来问题多半出现在ENABLE_FLAG列的统计信息上　　SQL> SELECT COLUMN_NAME NUM_DISTINCT NUM_NULLS DENSITY NUM_BUCKETS 　　 FROM USER_TAB_COLUMNS 　　 WHERE TABLE_NAME = ORD_HIT_M 　　 AND COLUMN_NAME = ENABLE_FLAG ; 　　COLUMN_NAME NUM_DISTINCT NUM_NULLS DENSITY NUM_BUCKETS 　　　　ENABLE_FLAG E

　　在 i的环境 Oracle根据DENSITY来确定返回的记录数因此得到条记录的结果是很正常的　

　　 SQL> SELECT * E FROM DUAL; 　　 * E 　　　　

　　显然这时需要删除错误的统计信息并重新收集统计信息　

　　 SQL> EXEC DBMS_STATS DELETE_TABLE_STATS(USER ORD_HIT_M ) 　　PL/SQL procedure successfully pleted 　　SQL> EXEC DBMS_STATS GATHER_TABLE_STATS(USER ORD_HIT_M ) 　　PL/SQL procedure successfully pleted

　　检查统计信息中的DENSITY值

　　 SQL> SELECT COLUMN_NAME NUM_DISTINCT NUM_NULLS DENSITY NUM_BUCKETS 　　 FROM USER_TAB_COLUMNS 　　 WHERE TABLE_NAME = ORD_HIT_M 　　 AND COLUMN_NAME = ENABLE_FLAG ; 　　COLUMN_NAME NUM_DISTINCT NUM_NULLS DENSITY NUM_BUCKETS 　　　　ENABLE_FLAG

　　下面检查访问ORD_HIT_M的执行计划检查优化器认为的返回记录数

　　现在统计信息已经恢复正常检查一下出现问题的SQL语句执行计划是否正常

cha138/Article/program/Oracle/201311/16912

知识大全 一次ORA-4030问题诊断及解决（一）

知识大全一次ORA-4030问题诊断及解决（一）