註意:分析sql的方法有很多種，還有根據優化器和sql執行計劃。
Sql_TRACE可以將Sql執行的過程輸出到壹個跟蹤文件中。
首先設置自己定義的跟蹤文件的logo，方便查找。
alter session set trace file _ identifier = ' mytest '；
然後為當前會話啟動SQL_TRACE。最好不要壹直開著開關，成本高。
alter session set sql _ trace = true
然後我們執行壹條sql語句。
最後，關閉開關的狀態。
alter session set SQL _ trace = false；
我們可以從目錄% Oracle _ base %/diag/RDBMS/orcl/orcl/trace下載(版本11g的路徑，如果是10g，應該是不壹樣的)。
找到自己的跟蹤文件。
原始跟蹤文件的可讀性不高，所以我們通常使用oracle自帶的工具tkprof來處理這個跟蹤文件。可以查看tkprof的幫助。
tkprof orcl _ ora _ 3820 _ mytest . TRC out . txt
讓我們看看剛剛生成的跟蹤文件。標題信息描述了tkprof的版本以及報告中某些列的含義。對於任何sql語句，都應該包括Parse—sql分析階段、Execute—sql執行階段和Fetch—數據提取階段。橫欄如圖，包括cpu耗時0.00秒，總運算時間0.04秒，物理讀取0個數據塊，當前模式下不讀取(壹般情況下，
解析期間庫緩存中的未命中:0表示這是壹個軟分析(硬分析和軟分析將在後面討論)。
優化器模式:ALL_ROWS表示oracle的優化器模式是ALL_ROWS。這是前面提到的另壹種分析方法優化器。
下面是sql執行的具體計劃。可以看到執行計劃選擇了全表掃描。
處理後的跟蹤文件真的很好理解，有助於我們分析sql的性能問題。
我通過壹個trace的例子來解釋為什麽OLTP系統中需要變量綁定機制。
當用戶與數據庫建立連接並發送sql語句時，oracle會對sql進行哈希函數操作(哈希算法提供了壹種快速訪問數據的方法，它用壹種算法建立鍵值與實值的對應關系，每個實值只能有壹個鍵值，但壹個鍵值可以對應多個實值，以便於訪問)，得到壹個哈希值，然後到* *共享池查找是否有匹配的哈希值sql。如果不是，oracle會認為這是壹條新的sql語句，然後按照語法分析、語義分析、生成執行計劃、執行sql的步驟，最後將結果返回給用戶。這些步驟也被稱為硬分析。可以想象，如果減少硬分析，可以大大減少數據庫花費在sql解析上的資源開銷。
讓我們首先執行壹個sql 1000次，比較綁定變量和未綁定變量之間的差異。得到結果後，為了計算實際消耗，我們需要累計所有非遞歸語句的所有總計和所有遞歸語句的所有總計的時間。前者表示數據字典表的相關信息，包括權限控制，後者表示從sql派生的遞歸sql語句的信息。可以看到變量是綁定的。整個語句的執行時間為0.22+0.02=0.24秒，CPU時間為0.18+0.03=0.21秒，分析次數為3次，執行次數為1003次。當變量未綁定時，整個語句的執行時間為0.28+1.29=1.57秒，CPU時間為0.31.26 = 1.57秒，分析次數為1002次，執行次數為65438次。可見綁定變量確實可以帶來更低的開銷。如何設計數據庫中使用的綁定變量也與系統密切相關，很多數據庫問題從設計開始就存在。
應用級優化分析:
就三層架構而言，中間件層可以起到緩沖池的作用。如果並發用戶數達到3000的量級，中間件可以控制不是所有用戶都可以直接連接到數據庫。當然，這裏的程序會快速響應用戶請求，保證緩沖池的隊列不會等待很長時間。
應用層的優化主要集中在app程序、中間件監控、集群配置等方面。如果發現應用級的問題，首先要分析是配置問題還是程序本身的問題。如果並發用戶數量很大，中間件線程池的最大配置太小，就會導致請求隊列的堆積，表現在線程監控視圖中。壹般可以通過調整線程池的最大配置來解決。我們來看看weblogic的監控視圖。
考慮到如果為每個請求創建壹個新的線程，則很難在系統中實現足夠數量的線程。無限制地創建線程可能會耗盡系統資源，因此引入了線程池。線程池的思想是在進程開始時創建壹定數量的線程，並將它們放入壹個池中，線程在池中等待工作。當服務器收到請求時，它從池中喚醒壹個線程(如果有可用的線程)來處理請求。壹旦線程服務完成，它就返回線程池等待後面的工作。
對於線程池來說，使用現有線程來處理請求比等待線程被創建要快，並且線程池限制了線程的數量。
如果我們懷疑是程序問題，我們通常可以通過java自帶的工具來幫助分析。有很多工具。這裏我主要提壹個jdk1.6之後附加的jvisualvm。
我們打開jdk1.6找到並運行jvisualvm.exe。
我們發現應用程序分為本地和遠程兩部分。本地包括本地運行的java進程，遠程可以通過配置連接遠程服務器上的java進程。先開個雄貓吧。您可以看到本地應用程序已經打開了壹個帶有tomcat和進程id的菜單。雙擊打開。這裏我們壹般關心兩種觀點。監控，線程。
其中，monitoring視圖更關註垃圾收集活動(顧名思義，回收程序中不再使用的內存空間)和堆內存變化。如果壓力測試時堆內存的變化是壹個上升的趨勢，並且在反復手動gc回收後還保持這個趨勢，說明內存泄露的可能性很大。如果有內存泄漏，可以分析java的堆轉儲。JVM (java虛擬機)記錄問題發生時系統的運行狀態，並存儲在轉儲文件中。堆轉儲就是這樣壹種文件形式。
thread視圖關註線程的當前執行狀態，這裏可以生成另壹個轉儲文件Java dump。Java轉儲，也稱為線程轉儲，是JVM故障診斷中最重要的轉儲文件之壹。使用該文件可以診斷JVM的許多問題，其中典型的問題包括線程阻塞、CPU利用率高、JVM崩潰、堆內存不足和類加載。線程阻塞更為常見。