[Q]性能问题！

biti_rainy

o

nintyuui

SELECT  COUNT(custID) custID
FROM
DW_VCustEntrust WHERE  uploaddate BETWEEN :1 AND :2  and
  DW_VCustEntrust.entrustType=:3  


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.01       0.00          0          0          0           0
Fetch        1   1005.96    1073.52          0    2232273          0           1
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        3   1005.97    1073.53          0    2232273          0           1

Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 82  (EOSDBA)

Rows     Row Source Operation
-------  ---------------------------------------------------
      1  SORT AGGREGATE
   5694   FILTER
   5694    NESTED LOOPS
  74022     MERGE JOIN CARTESIAN
     13      INDEX FULL SCAN (object id 48671)
  74022      BUFFER SORT
   5694       TABLE ACCESS BY INDEX ROWID DW_CUSTENTRUST
   5988        INDEX RANGE SCAN (object id 48695)
   5694     BITMAP CONVERSION TO ROWIDS
   5694      BITMAP AND
  74022       BITMAP CONVERSION FROM ROWIDS
  74022        INDEX RANGE SCAN (object id 48679)
  18784       BITMAP CONVERSION FROM ROWIDS
582359544        INDEX RANGE SCAN (object id 51660)


Rows     Execution Plan
-------  ---------------------------------------------------
      0  SELECT STATEMENT   GOAL: CHOOSE
      1   SORT (AGGREGATE)
   5694    FILTER
   5694     NESTED LOOPS
  74022      NESTED LOOPS
     13       TABLE ACCESS   GOAL: ANALYZED (BY INDEX ROWID) OF
                  'DW_CUSTENTRUST'
  74022        INDEX   GOAL: ANALYZED (RANGE SCAN) OF
                   'IDX_DW_CE_LOADDT' (NON-UNIQUE)
   5694       TABLE ACCESS   GOAL: ANALYZED (BY INDEX ROWID) OF
                  'DW_CUSTOMER'
   5988        INDEX   GOAL: ANALYZED (UNIQUE SCAN) OF
                   'PK_DW_CUSTOMER' (UNIQUE)
   5694      INDEX   GOAL: ANALYZED (UNIQUE SCAN) OF 'PK_DW_DEPTMAP'
                 (UNIQUE)

********************************************************************************


我在应用程序很慢的情况下，执行
SQL> SELECT COUNT(custID) custID
  2  FROM DW_VCustEntrust
  3  WHERE uploaddate
  4  BETWEEN to_date('2001-10-22','YYYY-MM-DD')
  5  AND to_date('2002-10-22','YYYY-MM-DD')
  6  and DW_VCustEntrust.entrustType=0;

    CUSTID
----------
      5694

很快3秒

SQL> select event,sum(decode(wait_Time,0,0,1)) "Prev",
  2  sum(decode(wait_Time,0,1,0)) "Curr",count(*) "Tot"
  3  from v$session_Wait
  4  group by event order by 4;

EVENT                                Prev       Curr        Tot
------------------------------ ---------- ---------- ----------
SQL*Net message to client               0          1          1
pmon timer                              0          1          1
resmgr:waiting in check2                1          0          1
smon timer                              0          1          1
rdbms ipc message                       0          4          4
SQL*Net message from client             0         21         21

这是当时的等待事件

nintyuui

up

whuijun

What is 'Trace+tkprof'?

nintyuui

Trace跟踪你的操作，生成.trc文件，用tkprof转换成你看的懂得格式

chao_ping

你的结果很奇怪，怎么Trace文件里面同一个语句的执行计划不一样？

你定位你的问题SQL就是那一句？
如果只是这样，尝试：
create Index idx_special_for_this_case
(entrustType, uploaddate )
compress 1
/

analyze table your_tab compute statistics;

然后重新运行你的应用看看。

nintyuui

CREATE OR REPLACE VIEW DW_VCUSTENTRUST ( CLEARMONEY,
EXCHANGEPLACE, EXCHANGEMONEY, FREEZENUMBER, CURRENCYCODE,
SECURITYCODE, SERIALID, ENTRUSTDATETIME, ENTRUSTNUMBER,
EXCHANGECOMMENTS, SECURITYID, SECUACCOID, EXCHANGENUMBER,
APPLYSERIALID, SECUTYPE, ENTRUSTWAYCODE, APPLYCLERK,
EXCHANGEDATE, ENTRUSTTYPE, CANCELDATE, APPLYPRICE,
APPLYDATE, CANCELNUMBER, SECUACCOCODE, ENTRUSTSOURCE,
UPLOADDATE, ENTRUSTPRICE, DEPTCODE, DEPTNAME,
PARENTID, CUSTID, FUNDACCOUNT, CUSTNAME,
CUSTOMERCODE, CUSTMANAGERID ) AS SELECT  a.clearMoney ,a.exchangePlace,a.exchangeMoney,a.freezeNumber,a.currencyCode,a.securityCode,a.serialID,
                a.entrustDateTime,a.entrustNumber,a.exchangeComments,a.securityID,a.secuaccoID,a.exchangeNumber,
                a.applySerialID,a.secuType,a.entrustWayCode,a.applyClerk,a.exchangeDate,a.entrustType,a.cancelDate,a.applyPrice,
                a.applyDate,a.cancelNumber,a.secuaccoCode,a.entrustSource,a.uploaddate,a.entrustPrice,
                b.deptCode, b.deptName,  b.parentID, c.custID, c.fundAccount, c.custName, c.customerCode ,c.custManagerID
FROM dw_custEntrust a, dw_deptmap b, dw_customer c where a.custID=c.custID and b.deptID = c.deptID

SELECT COUNT(custID) custID
FROM
DW_VCustEntrust WHERE uploaddate BETWEEN :1 AND :2 and
DW_VCustEntrust.entrustType=:3

这是对这个试图做查询。

[quote]
你的结果很奇怪，怎么Trace文件里面同一个语句的执行计划不一样？
[quote]
请问怎么看出来的，我怎么没看出来？

[quote]
你定位你的问题SQL就是那一句？
[quote]
根据测试人员的反应，和对STATSPACK报告的初步分析，是这样的，在我的附件有报告。

我用你的方法在试试

我们的数据库是OLTP和OLAP混合在一起的。

nintyuui

SELECT  COUNT(custID) custID
FROM
DW_VCustEntrust WHERE  uploaddate BETWEEN :1 AND :2  and
  DW_VCustEntrust.entrustType=:3  


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        2      0.00       0.01          0          0          0           0
Execute      2      0.02       0.01          0          0          0           0
Fetch        2   2031.10    2101.73         19    4464509          0           2
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        6   2031.12    2101.75         19    4464509          0           2

Misses in library cache during parse: 2
Optimizer goal: CHOOSE
Parsing user id: 82  (EOSDBA)

Rows     Row Source Operation
-------  ---------------------------------------------------
      1  SORT AGGREGATE
   5694   FILTER
   5694    NESTED LOOPS
  74022     MERGE JOIN CARTESIAN
     13      INDEX FULL SCAN (object id 48671)
  74022      BUFFER SORT
   5694       TABLE ACCESS BY INDEX ROWID DW_CUSTENTRUST
   5988        INDEX RANGE SCAN (object id 48695)
   5694     BITMAP CONVERSION TO ROWIDS
   5694      BITMAP AND
  74022       BITMAP CONVERSION FROM ROWIDS
  74022        INDEX RANGE SCAN (object id 48679)
  18784       BITMAP CONVERSION FROM ROWIDS
582359544        INDEX RANGE SCAN (object id 51660)


Rows     Execution Plan
-------  ---------------------------------------------------
      0  SELECT STATEMENT   GOAL: CHOOSE
      1   SORT (AGGREGATE)
   5694    FILTER
   5694     NESTED LOOPS
  74022      NESTED LOOPS
     13       TABLE ACCESS   GOAL: ANALYZED (BY INDEX ROWID) OF
                  'DW_CUSTENTRUST'
  74022        INDEX   GOAL: ANALYZED (RANGE SCAN) OF
                   'IDX_SPECIAL_FOR_THIS_CASE' (NON-UNIQUE)
   5694       TABLE ACCESS   GOAL: ANALYZED (BY INDEX ROWID) OF
                  'DW_CUSTOMER'
   5988        INDEX   GOAL: ANALYZED (UNIQUE SCAN) OF
                   'PK_DW_CUSTOMER' (UNIQUE)
   5694      INDEX   GOAL: ANALYZED (UNIQUE SCAN) OF 'PK_DW_DEPTMAP'
                 (UNIQUE)

应该说执行时间不长，但fetch是特别长。

附上执行时，oracle enterprise manager console 里看到的执行计划。

nintyuui

up

parrotao

重建和你表有关的index看看