官术网_书友最值得收藏!

1.3 如何確定正在發生智能掃描

通過前面的學習可知,全掃描、直接路徑讀取、Exadata存儲是智能掃描的三大先決條件,但它們不是充分條件,也即滿足了這三大條件也并不代表智能掃描一定會發生。那么又該如何判斷智能掃描是否已經發生?

1.3.1 執行計劃中出現全掃描并不代表已經智能掃描

正如以上標題所表明的,雖然在SQL語句的執行計劃中出現了STORAGE FULL等字樣,但這并不代表該SQL語句已經進行了智能掃描操作。

下面通過示例來驗證,即使執行計劃中出現了全掃描也并不代表已經智能掃描,見代碼清單1.15。

代碼清單1.15 驗證即使執行計劃中出現了全掃描也并不代表已經智能掃描(1)

查詢test.hello這張表的數據,從執行計劃可以看出是TABLE ACCESS STORAGE FULL;再查詢另外一張表test.test的數據,從執行計劃可以看出同樣也是T ABLE ACCESS STORAGE FULL。

下面獲取剛執行的這兩條語句的SQL_ID,并從v$sql性能視圖中查詢某條具體的SQL語句是否有IO的數據卸載操作。

代碼清單1.15 驗證即使執行計劃中出現了全掃描也并不代表已經智能掃描(2)

從以上的示例可以看出,執行計劃中出現STORAGE FULL關鍵字,僅僅表示該SQL語句符合智能掃描的條件之一,即進行了full table scans或fast full index scans操作,但這并不意味著SQL語句已經進行了智能掃描,而真正想智能掃描,則還必須進行數據的直接路徑讀取。

數據庫參數cell_offload_plan_display決定了執行計劃中是否顯示storage關鍵字。該參數有3個參數值,見表1.1。

表1.1 cell_offload_plan_display參數說明

1.3.2 如何確認智能掃描已經工作

既然無法從執行計劃層面看出哪些SQL語句已經進行了智能掃描操作,那么有哪些方法可以判斷具體的某條SQL語句是否有智能掃描呢?有以下幾種常見的方法:10046事件、數據庫性能視圖。

1.10046事件

10046事件是Oracle數據庫中任何SQL語句最真實的運行記錄,它會詳細記錄SQL語句運行過程中的等待和花費。通過設置這個事件可以得到Oracle內部執行系統解析、調用、等待、綁定變量等詳細的跟蹤信息,對于分析系統的性能有著非常重要的作用。

同樣,通過10046事件可以捕獲到某條SQL語句是否進行了智能掃描操作。下面通過示例進行說明。在運行某條SQL語句之前,先對該會話設置10046事件,見代碼清單1.16。

代碼清單1.16 10046事件驗證是否發生智能掃描(1)

獲取該SQL語句的10046事件所生成的跟蹤文件名為exadb1_ora_58674.trc。下面分析該10046事件生成的trace文件,其部分內容如下。

代碼清單1.16 10046事件驗證是否發生智能掃描(2)

將10046事件所生成的跟蹤文件使用tkprof工具格式化后的信息如下。

代碼清單1.16 10046事件驗證是否發生智能掃描(3)

從該10046事件生成的跟蹤文件的內容可以看出,該SQL語句的大量等待事件為cell smart table scan。出現這個等待事件,則表明該SQL語句進行了智能掃描。除了cell smart table scan,如果某條SQL語句出現了cell smart index scan等待事件,則表明該SQL語句也進行了智能掃描。

2.v$sql視圖

如果是一條已經運行過的SQL語句,或某些SQL語句不允許通過“再次執行”來重現,就無法再使用10046事件來分析該SQL語句是否已經智能掃描。在這種情況下,可以通過數據庫性能視圖,如v$sql、V$SQLAREA、V$SQLSTATS、V$SQLAREA_PLAN_HASH、V$SQLSTATS_PLAN_HASH等來定位某條SQL語句。

在這些數據庫性能視圖中,主要字段說明如表1.2所示。

表1.2 與v$sql相關的數據庫性能視圖主要字段說明

在前面的章節中,其實已經大量使用該類性能視圖來檢測SQL語句是否使用了智能掃描,這里就不再重復了。有一點需要提醒的是,在很多不同的資料中,計算智能掃描的IO節省比率的公式有兩種。

■ 公式1:智能掃描IO節省比率=(IO_CELL_OFFLOAD_ELIGIBLE_BYTES-IO_INTERCONNECT_BYTES)/IO_CELL_OFFLOAD_ELIGIBLE_BYTES?100%。

■ 公式2:智能掃描IO節省比率=(IO_CELL_OFFLOAD_ELIGIBLE_BYTES-IO_CELL_OFFLOAD_RETURNED_BYTES)/IO_CELL_OFFLOAD_ELIGIBLE_BYTES?100%。

這兩個計算公式其實都沒有什么問題,因為當發生智能掃描時,IO_INTERCONNECT_BYTES字段的值與IO_CELL_OFFLOAD_RETURNED_BYTES字段的值基本相當,而IO_INTERCONNECT_BYTES字段的值會比IO_CELL_OFFLOAD_RETURNED_BYTES字段的值稍稍高一些。

3.v$mystat視圖

除了與v$sql相關的數據庫性能視圖外,還可以通過v$mystat、v$sesstat或v$sysstat性能視圖來判斷某條SQL語句是否進行了智能掃描。如表1.3所示為v$mystat視圖中涉及智能掃描的主要字段說明。

表1.3 v$mystat性能視圖主要字段說明

下面以v$mystat性能視圖為例,來學習如何利用該性能視圖判斷SQL語句是否已經智能掃描,見代碼清單1.17。

代碼清單1.17 v$mystat性能視圖驗證是否發生智能掃描

從以上代碼輸出可以看出,當第一次查詢v$mystat性能視圖時,與智能掃描相關的性能指標全部為0;當執行完SQL語句之后,再次查詢v$mystat性能視圖時,與智能掃描相關的性能指標都發生了變化。這說明剛剛執行的SQL語句已經智能掃描。如果執行完SQL語句之后,與智能掃描相關的性能指標沒有任何變化,則說明剛剛執行的SQL語句沒有發生智能掃描操作。

4.SQL Monitor工具

在Oracle 11g數據庫中有一個新特性——SQL Monitor,可用來查看某一條運行的SQL語句是否使用了智能掃描。

使用方法非常簡單,可以使用命令行來生成HTML格式的SQL Monitor報告,生成的方式見代碼清單1.18。

代碼清單1.18 生成HTML格式的SQL Monitor報告

只需將上述代碼清單中的SQL_ID修改為具體SQL語句所對應的SQL_ID,即可獲取該SQL語句的SQL Monitor報告。

如果SQL語句運行的時間太短,則SQL Monitor特性是不會對其進行監控的。如要針對這種SQL語句進行監控,則需要手動對SQL語句加上/?+monitor?/hint。獲取到的HTML報告如圖1.7所示。

圖1.7 SQL Monitor報告

從SQL Monitor報告中可以看出,如果該SQL語句進行了智能掃描,則Cell Offload Efficiency列會計算出該SQL語句節省的IO百分比。

注意:目前,優化器還不能計算出智能掃描花費的成本,所以是否進行智能掃描并不是在SQL語句分析階段生成執行計劃時決定的,而是一個實時的決策過程。它主要依據以下規則:①首先優化器選擇使用全表掃描或索引快速全掃描,此時不會考慮當前環境是否為Exadata環境;②接著依據表的大小、臟數據塊的多少、已經緩存的數據塊多少、與_small_table_threshold和_serial_direct_read等相關的隱含參數來決定是否進行直接路徑讀取,該算法與非Exadata環境完全一樣;③如果數據存儲在Exadata環境,同時cell_offload_processing參數為默認值,未進行修改,則選擇使用智能掃描。

主站蜘蛛池模板: 文水县| 南开区| 锡林浩特市| 开江县| 平和县| 库尔勒市| 武汉市| 永安市| 长沙市| 淳化县| 玛纳斯县| 西贡区| 海宁市| 丹东市| 明光市| 永宁县| 顺平县| 金山区| 五家渠市| 延川县| 陇川县| 河西区| 兴仁县| 云和县| 罗源县| 平山县| 正蓝旗| 米脂县| 青龙| 桃源县| 合肥市| 广汉市| 阿拉善左旗| 绥滨县| 拉萨市| 广宗县| 东安县| 同德县| 达拉特旗| 咸宁市| 刚察县|