http://www.itpub.net/thread-1074410-1-1.html
急求解答:两个相同的数据库的执行计划差别怎么那么大，附带执行计划!!!
­
最近工作中遇到一个很郁闷的问题:
­
前提:
我一个培训环境，一个测试环境，均是AIX 5.3的操作系统，2个CPU ,6G内存,测试环境是1个月前通过rman方式将数据从培训环境中导入的
检查确认参数文件保持一致,表结构一致,数据量差别非常小
问题现象:
一个sql语句在两个配置和表结构相同的数据库中的执行计划不同，而且差别太大,查询结果出来后一个是5秒,一个几分钟
sql语句:
select *
from (
select distinct b.user_name,
a.full_name,
'N' selected,
b.department_description,
b.organization_id
from cux_user_name_v a, cux_department_user_v b
where a.user_name = b.user_name(+)
)
where
user_name in
('EAM_SETUP', 'HAN.XIANGXU', 'XU.JIANZHENG', 'HE.ZEMING', 'GAO.JIEFANG',
'MA.RENJIE', 'YOU.ZHONGQIAN', 'DONG.XUEJUN', 'QU.SHIMIN', 'SONG.YUEHAI',
'ZHANG.JINGYA', 'SHAN.QI', 'CHEN.BAOHAI', 'MU.YONG', 'LIU.XIAOYU',
'LI.ZHIFENG', 'QIAN.MAOYUE')
and organization_id = 3013[@more@]

http://www.itpub.net/thread-1074410-1-1.html
急求解答:两个相同的数据库的执行计划差别怎么那么大，附带执行计划!!!
­
最近工作中遇到一个很郁闷的问题:
­
前提:
我一个培训环境，一个测试环境，均是AIX 5.3的操作系统，2个CPU ,6G内存,测试环境是1个月前通过rman方式将数据从培训环境中导入的
检查确认参数文件保持一致,表结构一致,数据量差别非常小
问题现象:
一个sql语句在两个配置和表结构相同的数据库中的执行计划不同，而且差别太大,查询结果出来后一个是5秒,一个几分钟
sql语句:
select *
from (
select distinct b.user_name,
a.full_name,
'N' selected,
b.department_description,
b.organization_id
from cux_user_name_v a, cux_department_user_v b
where a.user_name = b.user_name(+)
)
where
user_name in
('EAM_SETUP', 'HAN.XIANGXU', 'XU.JIANZHENG', 'HE.ZEMING', 'GAO.JIEFANG',
'MA.RENJIE', 'YOU.ZHONGQIAN', 'DONG.XUEJUN', 'QU.SHIMIN', 'SONG.YUEHAI',
'ZHANG.JINGYA', 'SHAN.QI', 'CHEN.BAOHAI', 'MU.YONG', 'LIU.XIAOYU',
'LI.ZHIFENG', 'QIAN.MAOYUE')
and organization_id = 3013
­
其中表和视图的关系如下:
apps.cux_user_name_v --视图
applsys.fnd_user--(表6815条记录）
APPS.hr_employees--视图
APPS.PER_PEOPLE_F--视图
HR.Per_All_People_f --（表43324条记录）
APPS.PER_ASSIGNMENTS_F --视图
HR.PER_ALL_ASSIGNMENTS_F --（表68825条记录）
HR.PER_ASSIGNMENT_STATUS_TYPES --（表44条记录）
apps.cux_department_user_v --视图
APPS.BOM_DEPT_RES_INSTANCES_EMP_V --视图
PER_ALL_PEOPLE_F --（表43324条记录）
BOM.BOM_RESOURCE_EMPLOYEES --（表5236条记录）
BOM.BOM_DEPT_RES_INSTANCES --（表5400条记录）
APPS.hr_employees --视图
applsys.fnd_user --(表6815条记录）
APPS.bom_departments_all_v
BOM.BOM_DEPARTMENTS --（表623条记录）
BOM.BOM_RESOURCES --（表526条记录）
说明:左边的为右边对象的父对象,举例:apps.cux_user_name_v 由表applsys.fnd_user和视图APPS.hr_employees构成
而APPS.hr_employees由视图APPS.PER_PEOPLE_F,视图APPS.PER_ASSIGNMENTS_F和表HR.PER_ASSIGNMENT_STATUS_TYPES 来构成
­
另外的说明:所有的表和索引都相等并有效
已经做过表和索引的分析
问题相当于本来这个语句在培训环境上是正常的，过了几天,突然发现查询语句变的很慢了，而一个月前的同步到测试环境的数据，执行依旧很快
请各位兄弟姐妹们赶快救命撒!
附件为f5的执行计划和 alter session set events '10046 trace name context forever,level 8' tkp后的日志,
只是从跟踪日志看到培训环境的
239668702 TABLE ACCESS FULL FND_USER 有问题，
而且查询记录总共是1200万多条记录,但是fnd_user上相关的索引确实存在,
­
地址:http://www.itpub.net/thread-1074408-1-1.html
­
­
­
dancingfire1979 上传了这个附件：
2008-10-22 02:59
­
测试库.JPG (107.2 KB)


2008-10-22 02:59
­
培训库.JPG (175.73 KB)


2008-10-22 02:59
­

其实这个问题已经处理过了， 由于这个语句最终的分析是嵌套了8个视图,其实只用了9个表，而且视图是经过了4层的嵌套,所以直接联系开发人员和模块设计部门,减少视图的嵌套,直接采用原表的查询方法,速度变成了2秒.
只是为什么会出现这种情况，我今天克隆了一个数据库，然后通过rman的方式重新建立了一个模拟环境
再次执行表分析后
BEGIN
DBMS_STATS.gather_table_stats(ownname => 'applsys',tabname => 'FND_USER');
END;
查询速度就恢复到了5秒左右，
但是以前我曾经做过分析:
analyze table applsys.fnd_user compute statistics for all indexes
却没有将时间缩短，
请问这两个分析方法有区别么?
__________________
天行者~~~~~~~~~~~~~
­
lhdz_bj：
哦，原来问题就在这里：
DBMS_STATS.gather_table_stats(ownname => 'applsys',tabname => 'FND_USER');
会产生表FND_USER相关的所有统计信息，包括表和索引的。
而analyze table applsys.fnd_user compute statistics for all indexes
这个语句似乎只产生了表上所有索引的统计信息，而没有分析表等统计信息。
所以，收集统计信息最好用DBMS_STATS包，这也是ORACLE官方推荐的方法。