1

我正在使用 CENTOS 在 11g RAC 上测试我自己的 SQL。

我用这个脚本运行了一个 sql。

alter session set timed_statistics = true;
alter session set STATISTICS_LEVEL = all;
alter session set EVENTS '10046 TRACE NAME CONTEXT FOREVER, LEVEL 12';
alter session set sql_trace=true;

并得到如下跟踪文件...

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

select ISSU_ID
      ,BUYR_CORP_NO
      ,SELR_CORP_NO
      ,BROK_CORP_NO
      ,ISSU_DATE
      ,ISSU_TIME
      ,REGS_DATE
      ,INSERT_DATE
      ,INSERT_TIME
      ,SERV_ID
      ,TAX_TYPE
      ,POPS_CODE
      ,MODY_CODE
      ,IMPT_NO
      ,ACEP_STAT_DATE
      ,ACEP_END_DATE
      ,ISSU_SND_CODE
      ,STAT_CODE
      ,ISSU_SND_VAL
      ,ITEM_QUANT
      ,CHRG_AMT
      ,TAX_AMT
      ,TOTL_AMT
      ,BILL_SEQ_NO
      ,USER_ID
      ,SEND_MSG
      ,RECB_MSG
      ,ACCP_YN
      ,RECP_CODE
      ,MULT_ISSU_ID
      ,REQ_CHNEL
      ,REPT_USER_ID
      ,BFO_ISSU_ID
      ,MAIL_ACP_CODE
      ,ERR_CODE
      ,ERR_MSG
      ,URL_ID
      ,MGR_ID1
      ,MGR_ID2
      ,MGR_ID3
      ,NOTE1
      ,NOTE2
      ,NOTE3
      ,DOC_TYPE
      ,CERT_NTS
      ,BILL_TYPE
 from EGDB_ENC_MSTR
where rownum<10000000

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch   666668     93.85      78.70     424374    1494818          0     9999999
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total   666670     93.85      78.70     424374    1494818          0     9999999

Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 112  (RTAXBILL)
Number of plan statistics captured: 1

Rows (1st) Rows (avg) Rows (max)  Row Source Operation
---------- ---------- ----------  ---------------------------------------------------
   9999999    9999999    9999999  COUNT STOPKEY (cr=1494818 pr=424374 pw=0 time=22043507 us)
   9999999    9999999    9999999   TABLE ACCESS FULL EGDB_ENC_MSTR (cr=1494818 pr=424374 pw=0 time=18632205 us cost=122336 size=3529999647 card=9999999)


Rows     Execution Plan
-------  ---------------------------------------------------
      0  SELECT STATEMENT   MODE: ALL_ROWS
9999999   COUNT (STOPKEY)
9999999    TABLE ACCESS   MODE: ANALYZED (FULL) OF 'EGDB_ENC_MSTR' (TABLE)



Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  SQL*Net message to client                  666668        0.00          1.58
  enq: KO - fast object checkpoint                3        0.00          0.00
  reliable message                                1        0.00          0.00
  direct path read                                2        0.01          0.01
  SQL*Net message from client                666668        0.01       2399.08
  SQL*Net more data to client                     2        0.00          0.00
********************************************************************************

我有 3 个问题。

  1. 为什么CPU_TIME长于ELAPSED_TIME？我读了一个文档告诉我，ELAPSED_TIME其中包括等待事件时间。如果是真的，为什么CPU_TIME比 长ELAPSED_TIME？

  2. 当我在客户端上运行查询时，它会在几毫秒内返回结果集，但我的跟踪文件显示ELAPSED_TIME为 78.70 秒。这与 相关FETCH CALL吗？如果为真，ELAPSED_TIME则在跟踪文件中是获取所有结果集的时间量，而不是ArraySize. 这是正确的吗？

  3. 在等待事件部分，它说总等待时间SQL*Net message from client是 2399 秒，但 ELAPSED_TIME 比这短得多。为什么是这样？

我对 trc 文件中的统计信息非常好奇，但实际上我是 oracle 数据库的新手。任何建议将不胜感激。

4

0 回答 0