存储过程的效率问题！！（今晚在线等）

biti_rainy

select FREELISTS      from  user_tables where table_name = ???;
如果查出来freelists = 1
如果你的数据库是816以上版本
init中
compatible     =  8.1.6    或者以上
则修改

SQL>  alter table t storage(freelists 20);

Table altered.

SQL>


对于你的主键和表相关的所有索引
也是如此
从 user_indexes 中查询 freelists
select  freelists from user_indexes where table_name = ???  

SQL> alter index t_index storage(freelists 20);

Index altered.

SQL>
btw: 注意主键生成的索引名字可能是系统自己命名的

biti_rainy

我觉得一个一个问题的挤很累的说

SQL> show parameters area_size

NAME                                 TYPE    VALUE
------------------------------------ ------- ------------
bitmap_merge_area_size               integer 1048576
create_bitmap_area_size              integer 8388608
hash_area_size                       integer 131072
sort_area_size                       integer 65536
SQL>

你的存储过程中是不是有 排序/表连接(hash join),如果是可考虑加大
sort_area_size or  hash_area_size

mypengchen2000

select FREELISTS from user_tables where table_name = ???;
我随便查了一个表,结果是:
FREELISTS
----------
         1
select freelists from user_indexes where table_name = ???

结果也是:
FREELISTS
----------
         1

我的数据库是817的,是否我要将库里所有的表和索引都要改过来呢????
还有,freelists具体是什么意思?请大致说一下!
数据库没有删除数据文件之前和之后好象并没有修改这个参数的!!

mypengchen2000

sort_area_size       65536
hash_area_size     131072
bitmap_merge_area_size  1048576
create_bitmap_area_size   8388608
存储过程中确实有表连接(还较多),还有union all等操作!

mypengchen2000

这是其中的一个sql语句:
DELETE FROM ABC_PAY WHERE CAL_DATE=V_CAL_DATE;
  INSERT INTO ABC_PAY(CAL_DATE,DEVELOP_DEPT_NO,USER_KIND,AGE_RANGE,SEX,USER_DINNER,REG_PAY_TYPE,FACT_PAY_TYPE,CREDIT_DINNER,TOTAL_USERS,TOTAL_FEE)
    SELECT V_CAL_DATE,B.DEVELOP_DEPT_NO,B.USER_KIND,C.CL_ID,B.SEX,B.USER_DINNER,B.PAY_TYPE,A.PAY_TYPE,B.CREDIT_DINNER,COUNT(*),SUM(CHARGE/D.COUNT_USERS)
    FROM (SELECT PAY_TYPE,SUM(CHARGE) CHARGE,PAY_NO FROM UC_LOG_PAY
      WHERE STATE_DATE<V_SYSDATE+1 AND STATE_DATE>=V_SYSDATE
      GROUP BY PAY_NO,PAY_TYPE
    )A,
     MV_USER_INFO B,UC_RANGE C,
   (SELECT PAY_NO,COUNT(*) COUNT_USERS FROM MV_USER_INFO GROUP BY PAY_NO) D
    WHERE B.CUSTOMER_NAME<>'广州' AND B.CUSTOMER_NAME<>'广州市'
      AND B.PAY_NO=A.PAY_NO AND B.PAY_NO=D.PAY_NO
      AND C.MIN_LMT<= DECODE(LENGTH(B.BIRTHDAY),8,TO_NUMBER(TO_CHAR(V_SYSDATE,'YYYY'))-TO_NUMBER(SUBSTR(B.BIRTHDAY,1,4)),-1)
      AND C.MAX_LMT>DECODE(LENGTH(B.BIRTHDAY),8,TO_NUMBER(TO_CHAR(V_SYSDATE,'YYYY'))-TO_NUMBER(SUBSTR(B.BIRTHDAY,1,4)),-1) AND C.CL_SCM_ID=4
      AND B.IN_NET_DATE<V_SYSDATE+1
    GROUP BY B.DEVELOP_DEPT_NO,B.USER_KIND,C.CL_ID,B.SEX,B.USER_DINNER,B.PAY_TYPE,A.PAY_TYPE,B.CREDIT_DINNER
    UNION ALL
    SELECT V_CAL_DATE,B.DEVELOP_DEPT_NO,B.USER_KIND,C.CL_ID,B.SEX,B.USER_DINNER,B.PAY_TYPE,'全部',B.CREDIT_DINNER,COUNT(*),SUM(CHARGE/D.COUNT_USERS)
    FROM (SELECT SUM(CHARGE) CHARGE,PAY_NO FROM UC_LOG_PAY
      WHERE STATE_DATE<V_SYSDATE+1 AND STATE_DATE>=V_SYSDATE
      GROUP BY PAY_NO
    )A,
     MV_USER_INFO B,UC_RANGE C,
    SELECT PAY_NO,COUNT(*) COUNT_USERS FROM MV_USER_INFO GROUP BY PAY_NO) D
    WHERE B.CUSTOMER_NAME<>'广州' AND B.CUSTOMER_NAME<>'广州市'
      AND B.PAY_NO=A.PAY_NO AND B.PAY_NO=D.PAY_NO
     AND C.MIN_LMT<= DECODE(LENGTH(B.BIRTHDAY),8,TO_NUMBER(TO_CHAR(V_SYSDATE,'YYYY'))-TO_NUMBER(SUBSTR(B.BIRTHDAY,1,4)),-1)
      AND C.MAX_LMT>DECODE(LENGTH(B.BIRTHDAY),8,TO_NUMBER(TO_CHAR(V_SYSDATE,'YYYY'))-TO_NUMBER(SUBSTR(B.BIRTHDAY,1,4)),-1) AND C.CL_SCM_ID=4
      AND B.IN_NET_DATE<V_SYSDATE+1
    GROUP BY B.DEVELOP_DEPT_NO,B.USER_KIND,C.CL_ID,B.SEX,B.USER_DINNER,B.PAY_TYPE,B.CREDIT_DINNER;
   
  COMMIT;

mypengchen2000

继续帮我看看,比较急的说
!要不要该freelists的值呢?freelists具体表示什么意思?
还有,我的几个area_size是否设置合理呢??我贴出了sql语句供参考

iamcoldwind

的确是非常奇怪的事情，如果说存储过程没有改变过，那么可能出现这种情况的原因应该是ORACLE数据库的配置问题了。既然存储过程在发生误删除数据文件事件的前后都用到了索引，那么是否证明是数据库的参数被改变了？在对数据库进行修复的过程中，是否对数据库的设置进行了修改，从而导致效率降低？

iamcoldwind

freelist?  为什么提其它了？

mypengchen2000

在对数据库进行修复的过程中，是否对数据库的设置进行了修改??
在这个过程中,有没有对数据库的设置进行修改,现在我还不清楚,不过会尽快和客户方面的DBA确认这个问题,但我想这种可能性不大,因为,他只是恢复数据,并没有必要去修改数据库的各种参数.但是,可以肯定的是前后的效率差别太大!!

mypengchen2000

麻烦biti_rainy 继续帮我看看,我的sql帖出来了一部分,是否要该freelists呢?