關於trace檔案中的recursive calls , elapse time及cpu time,

Recursive Calls. Number of recursive calls generated at both the user and system level. Oracle Database maintains tables used for internal processing. When it needs to change these tables, Oracle Database generates an internal SQL statement, which in turn generates a recursive call.
In short, recursive calls are basically SQL performed on behalf of your SQL. So, if you had to parse the query, for example, you might have had to run some other queries to get data dictionary information. These would be recursive calls. Space management, security checks, calling PL/SQL from SQL—all incur recursive SQL calls

根據oracle的定義及常見的導致recursive calls 的情景，總結了一下，不知是否準確：  

執行一條SQL語句時，產生的對其他SQL的呼叫，這些額外的語句稱之為''recursive calls''或''recursive SQL statements''.
1. Parse - 硬解析時會出現更多的 recursive calls，軟解析可以避免recursive calls.
2. Security checks - 訪問許可權相關的資料字典表
3. Firing of database triggers - 觸發DB觸發器
4. Handle constraint - Enforcement of referential integrity constraints，引用完整性約束  
5. 資料字典記錄了所有物件的結構、資料資訊，在物件結構、資料發生變化時都會訪問資料字典
6. Space management - 沒有足夠的空間時，Oracle 透過Recursive Call訪問資料字典來動態的分配空間。
7. 執行DDL語句時，ORACLE總是隱含的發出一些recursive SQL語句，來修改資料字典資訊，以便成功執行該語句。
8. 當Shared Pool過小，data dictionary cache 也會相應的過小，沒有足夠的空間儲存ORACLE的系統資料字典資訊時，
    會發生 Recursive calls，這些Recursive calls會將資料字典資訊從硬碟讀入記憶體中。
9. 儲存過程、包、觸發器，函式或匿名PL/SQL塊內如果有SQL呼叫的話，也會產生recursive SQL。
10. Calling PL/SQL from SQL - 從SQL中呼叫PL/SQL

第9 , 10 理解起來比較糾結， 比如  select  max(column_name) from  tab1 where col2=xxx ;   做了一下trace ,  首次執行
會出現一次 recursive calls ,  第二次執行就是 0 了。  procedure 或 packages 中肯定有SQL呼叫， 非SQL部分都是一些遊標
處理，計算等， 稱為NON-RECURSIEVE CALLS ,   目前我們在執行一個packages時，發現 NON-RECURSIEVE CALLS 及 RECURSIEVE CALLS
消耗的時間都比較高， 而且發現所有的執行所花的時間(一個一個相加) 不等於後面的 TOTAL NON-RECURSIEVE CALLS 及
TOTAL RECURSIEVE CALLS 的和 （雖然比較接近）。 不知道這些時間如何計算的 ？  聽Oracle顧問說trace中時間有一定誤差
是存在的 ， 現在可以透過另外一個工具來替代trace .   

trace檔案中 Elapsed times include waiting on following events: 部分的時間消耗和 cpu time, elapsed 是什麼關係 ， 如何計算 ？