您好,登錄后才能下訂單哦!
本篇內容介紹了“SQL調優的思路是什么”的有關知識,在實際案例的操作過程中,不少人都會遇到這樣的困境,接下來就讓小編帶領大家學習一下如何處理這些情況吧!希望大家仔細閱讀,能夠學有所成!
一般來說,需要關注下面四種Top SQL
消耗最多CPU的(邏輯IO過多)
導致過多物理I/O的
執行次數較頻繁的
執行時間較長的
我們知道,一個語句的響應時間有個很著名的公式:
響應時間=服務時間+等待時間
其中服務時間就是CPU為執行該語句花費的時間。
服務時間=分析時間+遞歸時間+執行時間
分析時間是CPU用于分析語句的時間,遞歸時間是CPU用于語句的遞歸SQL的時間,剩下的則就是CPU用于執行語句的真正時間了。
那么,上面的這些時間信息從哪里來的?Oracle提供的系統統計信息中就有部分的時間統計信息:
服務時間=CPU used by this session
分析時間=parse time cpu
遞歸時間=recursive cpu usage
那么,執行時間就可以根據上面三個統計信息計算得出:
執行時間=CPU used by this session – parse time cpu – recursive cpu usage
如果執行時間在整個響應時間中占較大的比例,那么下一步就是找出那些造成了最多邏輯IO的SQL語句,可以從statspack報告的SQL ordered by Gets部分找到。
如果分析時間在整個響應時間中占較大的比例,那么下一步就是查找哪些SQL分析過多,這在statspack報告中在SQL ordered by Parse Calls中列出。
如果等待時間在整個響應時間中占較大的比例,并且主要是塊讀取相關的等待時,下一步就是找出哪些SQL造成了過多的物理讀,可以查看statspack報告中的SQL ordered by Reads部分。
那么,根據上面列出的一個簡單的原則,我們需要關注三個關于CPU時間的統計信息: CPU used by this session, parse time cpu和recursive cpu usage,以及top5等待事件中和IO相關的等待時間。如果是其他的一些等待事件出現在Top5中,那么可能需要根據不同的等待事件來分析原因了。然后優先調優時間消耗最多的相關SQL。
除了上面的SQL ordered by Gets(邏輯IO最多),SQL ordered by Parse Calls(軟解析過多),SQL ordered by Reads(物理IO過多),statspack還按照其他的一些方式列出了Top SQL,這些Top SQL在某些情況下都是需要給予特別關注的。比如:
SQL ordered by Executions 執行次數超過100的
SQL ordered by Sharable Memory 占用library cache超過1M的
SQL ordered by Version Count 子cursor超過20的
如果沒有statspack,那么根據v$sysstat/v$sesstat中的統計信息,結合v$sql/v$sqlarea,一樣可以得到相關的SQL。
v$sql對于每一個子cursor都有一行統計記錄,而v$sqlarea則對同一個父cursor只有一行統計記錄,也就是v$sqlarea是對v$sql按照父cursor進行group by后的一個結果。這兩個視圖中都有諸如buffer_gets,parse_calls,disk_reads,,executions,sharable_mem等列,和報告列出Top SQL的條件對應。
“SQL調優的思路是什么”的內容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站,小編將為大家輸出更多高質量的實用文章!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。