有一個數(shù)據(jù)庫應用程序存在過多的解析問題，因此需要找到產(chǎn)生大量硬解析的主要語句。

什么是硬解析

Oracle數(shù)據(jù)庫中的硬解析（Hard Parse）是指在執(zhí)行SQL語句時，數(shù)據(jù)庫需要重新解析該SQL語句，并創(chuàng)建新的執(zhí)行計劃的過程。這個過程涉及到對SQL語句的完整解析、編譯和生成執(zhí)行計劃，是數(shù)據(jù)庫性能優(yōu)化中的一個重要環(huán)節(jié)。以下是硬解析的詳細過程：

• 語法、語義及權限檢查：Oracle首先會對SQL語句進行語法檢查，確保語句的拼寫和結構正確無誤。接著進行語義檢查，驗證語句中引用的對象是否存在以及執(zhí)行語句的用戶是否具有相應的權限。
• 查詢轉換：Oracle會應用不同的轉換技巧，將SQL語句轉換為語義上等價的其他形式。例如，COUNT(1)可能會被轉換為COUNT(*)，以優(yōu)化查詢性能。
• 根據(jù)統(tǒng)計信息生成執(zhí)行計劃：這是硬解析中最耗時的步驟。Oracle會根據(jù)數(shù)據(jù)庫的統(tǒng)計信息，如表的大小、索引的統(tǒng)計數(shù)據(jù)等，來確定執(zhí)行SQL語句的最佳路徑，即成本最低的執(zhí)行計劃。
• 將游標信息（執(zhí)行計劃）保存到庫緩存：一旦執(zhí)行計劃生成，Oracle會將這個執(zhí)行計劃保存在共享池（Shared Pool）的庫緩存（Library Cache）中，以便后續(xù)相同的SQL語句可以重用這個執(zhí)行計劃，減少硬解析的發(fā)生。

硬解析的觸發(fā)條件包括：

• 首次執(zhí)行某個SQL語句時，因為數(shù)據(jù)庫尚未為其生成解析結果，必須進行硬解析。
• 如果一個已經(jīng)硬解析過的SQL語句對應的解析結果在共享池中被替換或因其他原因失效（例如，相關的數(shù)據(jù)庫對象元數(shù)據(jù)發(fā)生變化），那么下次執(zhí)行該語句時需要重新進行硬解析。
• 即使對于相同的SQL文本，如果其綁定變量值或會話環(huán)境（如當前用戶的權限、NLS設置等）發(fā)生變化，導致生成的解析樹或執(zhí)行計劃與緩存中的不一致，也會觸發(fā)硬解析。
• 某些類型的SQL語句，如DDL（數(shù)據(jù)定義語言）語句，由于它們的操作通常是不可緩存的，因此總是進行硬解析。

硬解析對數(shù)據(jù)庫性能有顯著影響，因為它會消耗大量的CPU資源和內(nèi)存，增加磁盤I/O，延長查詢響應時間，降低用戶體驗。因此，在數(shù)據(jù)庫性能優(yōu)化中，通常建議盡量減少硬解析的發(fā)生，通過使用綁定變量、優(yōu)化SQL語句結構等方式來提高軟解析的比例，從而提升數(shù)據(jù)庫的整體性能。

當必須將 SQL 語句加載到共享池中時，會發(fā)生硬解析。在這種情況下，Oracle Server 必須在共享池中分配內(nèi)存并解析語句。

當共享池太小時，或者當您有沒有綁定變量的不可重用 SQL 語句時，可能會發(fā)生過多的硬解析。

我們可能會想到 AWR 報告，其中有一節(jié)標題為“SQL ordered by Parse Calls”，但是這里的數(shù)值不僅是硬解析調用，而且還包含了軟解析。

因此我們可以使用查詢表中dba_hist_active_sess_history IN_HARD_PARSE='Y' 的語句，查出真正的硬解析語句。

查詢一段時間以來硬解析次數(shù)最高語句

select INSTANCE_NUMBER,TOP_LEVEL_SQL_ID,SQL_ID,count(*)
from dba_hist_active_sess_history
where IN HARD_PARSE='Y'
and snap_id>=39072 and snap_id<=39073
and sample_time>to_date('20240814 09:09','yyyymmdd hh24:mi')
and sample_time<to_date('20240814 10:10','yyyymmdd hh24:mi')
group by INSTANCE_NUMBER,TOP_LEVEL_SQL_ID,SQL_ID
having count(*)>10
order by count(*) desc;

查詢一段時間以來所有實例硬解析top語句???????

select TOP_LEVEL_SQL_ID,SQL_ID,count(*
from dba_hist_active_sess_history
where IN_HARD_PARSE='Y'
and snap_id>=39072 and snap_id<=39093
and sample_time>to_date('20240814 09:08','yyyymmdd hh24:mi')
and sample_time<to_date('20240814 16:15','yyyymmdd hh24:mi')
group by TOP_LEVEL_SQL_ID,SQL_ID
having count(*)>10
order by count(*) desc;

TOP_LEVEL_SQL_ID和SQL_ID

很多時候面對包或者存儲過程，我們看到的"sql_id"僅僅是包或者存儲過程本身的"sql_id"，但對于包以及存儲過程里面到底包含了哪些sql是不知道的，這時候就可以利用這一列，查出包或者存儲過程里的一系列sql_id。

查詢存儲過程中那些sql語句慢

查詢出硬解析語句為存儲過程時，如何查看存儲過程中的sql語句

###查詢存儲過程中那些語句慢
set verify on
set echo on
set lines 250
set head on
set tab off
WITH snaps AS
 (SELECT /*+ materialize*/
   snap_id, dbid
    FROM dba_hist_snapshot
   WHERE begin_interval_time > SYSDATE - &days),
obj AS
 (SELECT /*+ materialize*/
   object_id, subprogram_id
    FROM DBA_PROCEDURES
   WHERE object_name = UPPER ('&package_name')
                AND procedure_name = UPPER('&procedure_name'))
SELECT /*+  push_subq(snp) opt_param('_optimizer_use_feedback' 'false') */
 t.*
  FROM (SELECT sql_id,
               event,
               a.SQL_PLAN_HASH_VALUE,
               COUNT(DISTINCT sql_exec_id || sql_exec_start) calls,
               count(1) cnt
          FROM dba_hist_active_sess_history a
         WHERE (PLSQL_ENTRY_OBJECT_ID, PLSQL_ENTRY_SUBPROGRAM_ID) IN
               (SELECT object_id, subprogram_id FROM obj)
           AND (dbid, SNAP_ID) IN (SELECT /*+qb_name(snp)*/
                                    dbid, SNAP_ID
                                     FROM snaps)
         GROUP BY sql_id, SQL_PLAN_HASH_VALUE, event) t
 ORDER BY sql_id, SQL_PLAN_HASH_VALUE, event, cnt DESC
 /
 CLEAR COLUMNS

到此這篇關于Oracle數(shù)據(jù)庫如何找到 Top Hard Parsing SQL 語句？的文章就介紹到這了,更多相關Oracle Top Hard Parsing SQL 語句內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論