Question

我正在使用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个问题。

为什么CPU_TIME超过ELAPSED_TIME？我读了一个文档，告诉我ELAPSED_TIME包括等待事件时间。如果是真的，为什么CPU_TIME超过ELAPSED_TIME？
当我在客户端上运行查询时，它会在几毫秒内返回结果集，但我的跟踪文件ELAPSED_TIME是78.70秒。这与FETCH CALL有关吗？如果是，则跟踪文件中的ELAPSED_TIME是获取ArraySize的所有结果集的时间。这是对的吗？
在等待事件部分，它表示SQL*Net message from client的总等待时间为2399秒，但ELAPSED_TIME比此短得多。这是为什么？

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

＆＃34;我的跟踪文件显示我＆＃34; CPU_TIME＆＃34;超过＆＃34; ELAPSED_TIME＆＃34;

0 个答案: