[20190214]11g Query Result Cache RC Latches.txt

来源:https://www.cnblogs.com/lfree/archive/2019/02/14/10373399.html
-Advertisement-
Play Games

[20190214]11g Query Result Cache RC Latches.txt--//昨天我重覆鏈接http://www.pythian.com/blog/oracle-11g-query-result-cache-rc-latches/的測試，--//按照我的理解如果sql語句密集 ...


[20190214]11g Query Result Cache RC Latches.txt

--//昨天我重覆鏈接http://www.pythian.com/blog/oracle-11g-query-result-cache-rc-latches/的測試，
--//按照我的理解如果sql語句密集執行，使用Result Cache反而更加糟糕，這是我以前沒有註意到的。
--//聯想我們生產系統也存在類似的問題，我們有1個判斷連接的語句select count（*) from test_connect;
--//在業務高峰它執行可以達到1600次/秒。另外一個簡單的select sysdate from dual; 也達到800次/秒。
--//而實際上業務高峰sql語句執行率3000次/秒。這樣的2條語句就占了2400次/秒。我以前一直以為將表設置
--//為result cache,可能提高執行效率，還是通過例子測試看看。

1.環境：
SCOTT@book> @ ver1
PORT_STRING                    VERSION        BANNER
------------------------------ -------------- --------------------------------------------------------------------------------
x86_64/Linux 2.4.xx            11.2.0.4.0     Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

SCOTT@book> show parameter job
NAME                TYPE    VALUE
------------------- ------- ------
job_queue_processes integer 200

SCOTT@book> select * from v$latchname where name like 'Result Cache%';
LATCH# NAME                          HASH
------ ----------------------- ----------
   436 Result Cache: RC Latch  1054203712
   437 Result Cache: SO Latch   986859868
   438 Result Cache: MB Latch   995186388
--//我看到Result Cache名字與作者的不同，命名為Result Cache: RC Latch。

SCOTT@book> select name,gets from v$latch where lower(name) like '%result cache%';
NAME                                 GETS
------------------------------ ----------
Result Cache: RC Latch                  0
Result Cache: SO Latch                  0
Result Cache: MB Latch                  0

SCOTT@book> select count(*) from v$latch_children where lower(name) like '%result cache%';
  COUNT(*)
----------
         0

--//可以註意一個細節,Result Cache沒有children latch。也僅僅1個Result Cache: RC Latch 父latch。從這裡也可以看出如果
--//做了result cache的表，多個用戶併發執行，可能反而不能獲得好的性能,可能出現大量的Result Cache: RC Latch爭用的情況.

2.建立測試例子：

create table t as select rownum id from dual ;
create unique index pk_t on t(id);
--//分析略。

SCOTT@book> create table job_times ( sid   number, time_ela number);
Table created.

--//按照源鏈接的例子修改如下：
create or replace procedure do_work(
 p_iterations in number
) is
 l_rowid  rowid;
 v_t number;
begin
 insert into job_times
  values (sys_context('userenv', 'sid'), dbms_utility.get_time)
  returning rowid into l_rowid;

 for i in 1 .. p_iterations
 loop
     select count(*) into v_t from t;
 end loop;

 update job_times set
   time_ela=dbms_utility.get_time-time_ela
  where rowid=l_rowid;
 commit;
end;
/

3.測試:
--//首先測試不做result cache的情況：
--//alter table t result_cache (mode default);

declare
 l_job number;
begin
 for i in 1 .. 50
 loop
  dbms_job.submit(
   job => l_job,
   what => 'do_work(1000000);'
  );
 end loop;
end;
/

SCOTT@book> commit ;
Commit complete.

--//註意一定要寫提交，不然dbms_job.submit要等很久才執行。

SCOTT@book> select count(*),avg(TIME_ELA),sum(TIME_ELA) from job_times ;
  COUNT(*) AVG(TIME_ELA) SUM(TIME_ELA)
---------- ------------- -------------
        50        9235.1        461755

4.測試:

--///測試做result cache的情況，為了測試的準確，我重啟資料庫。
SCOTT@book> delete from job_times;
50 rows deleted.

SCOTT@book> commit ;
Commit complete.

SCOTT@book> alter table t result_cache (mode force);
Table altered.

--//重啟資料庫.

SCOTT@book> select name, gets, misses, sleeps, wait_time from v$latch where name like 'Result Cache%';
NAME                                 GETS     MISSES     SLEEPS  WAIT_TIME
------------------------------ ---------- ---------- ---------- ----------
Result Cache: RC Latch                  0          0          0          0
Result Cache: SO Latch                  0          0          0          0
Result Cache: MB Latch                  0          0          0          0

declare
 l_job number;
begin
 for i in 1 .. 50
 loop
  dbms_job.submit(
   job => l_job,
   what => 'do_work(100000);'
  );
 end loop;
end;
/

SCOTT@book> commit ;
Commit complete.

SCOTT@book> select count(*),avg(TIME_ELA),sum(TIME_ELA) from job_times ;
  COUNT(*) AVG(TIME_ELA) SUM(TIME_ELA)
---------- ------------- -------------
        50       7135.96        356798

SCOTT@book> select name, gets, misses, sleeps, wait_time from v$latch where name like 'Result Cache%';
NAME                                 GETS     MISSES     SLEEPS  WAIT_TIME
------------------------------ ---------- ---------- ---------- ----------
Result Cache: RC Latch           54232541    3499238          0          0
Result Cache: SO Latch                202          0          0          0
Result Cache: MB Latch                  0          0          0          0

--//很明顯,即使存在Result Cache: RC Latch的爭用,但是WAIT_TIME=0,不過我發現這樣測試的一個缺點,就是50個job並不是同時運行.
--//$ ps -ef | grep ora_[j]|wc ,看看數量是不斷增加的過程.
--//而且採用Result Cache後效果還是增強的.

5.換一個方式測試:
SCOTT@book> delete from job_times;
53 rows deleted.

SCOTT@book> commit ;
Commit complete.

--//設置result_cache=default
SCOTT@book> alter table t result_cache (mode default);
Table altered.

$ seq 50 | xargs -I{} echo 'sqlplus -s -l scott/book <<< "execute do_work(1000000)" & '| bash

--//等全部完成...

SCOTT@book> select count(*),avg(TIME_ELA),sum(TIME_ELA) from job_times ;
  COUNT(*) AVG(TIME_ELA) SUM(TIME_ELA)
---------- ------------- -------------
        50      10588.26        529413

SCOTT@book> delete from job_times;
50 rows deleted.

SCOTT@book> commit ;
Commit complete.

--//設置result_cache=force
SCOTT@book> alter table t result_cache (mode force);
Table altered.

$ seq 50 | xargs -I{} echo 'sqlplus -s -l  scott/book <<< "execute do_work(1000000)" & '| bash

SCOTT@book> select count(*),avg(TIME_ELA),sum(TIME_ELA) from job_times ;
  COUNT(*) AVG(TIME_ELA) SUM(TIME_ELA)
---------- ------------- -------------
        50       8573.28        428664
--//可以看到即使這樣大併發,採用result cache還是要快許多,沒有遇到作者的情況.
--//可以11GR2做了一些改進,不會遇到這樣的情況.

SCOTT@book> column name format a30
SCOTT@book> select name, gets, misses, sleeps, wait_time from v$latch where name like 'Result Cache%';
NAME                                 GETS     MISSES     SLEEPS  WAIT_TIME
------------------------------ ---------- ---------- ---------- ----------
Result Cache: RC Latch          103461569    7263987          0          0
Result Cache: SO Latch                302          0          0          0
Result Cache: MB Latch                  0          0          0          0

6.不過當我拿作者的最後的例子做最後的測試發現,使用result cache慢很多.

SCOTT@book> create cluster hc ( n number(*,0)) single table hashkeys 15000 size 230;
Cluster created.

SCOTT@book> create table hc_t ( n number(*,0), v varchar2(200)) cluster hc (n);
Table created.

SCOTT@book> insert into hc_t select level, dbms_random.string('p', 200) from dual connect by level <= 10000;
10000 rows created.

SCOTT@book> commit;
Commit complete.

--//分析表略.

All we need now is two procedures, one with a regular select and another with a cached select:

create or replace procedure do_hc(
 p_iterations in number
) is
 l_rowid  rowid;
 l_n number;
begin
 insert into job_times
  values (sys_context('userenv', 'sid'), dbms_utility.get_time)
  returning rowid into l_rowid;

 for i in 1 .. p_iterations
 loop
  l_n:=trunc(dbms_random.value(1, 10000));
  for cur in (select * from hc_t where n=l_n)
  loop
   null;
  end loop;
 end loop;

 update job_times set
   time_ela=dbms_utility.get_time-time_ela
  where rowid=l_rowid;
end;
/

Procedure created.

create or replace procedure do_rc(
 p_iterations in number
) is
 l_rowid  rowid;
 l_n number;
begin
 insert into job_times
  values (sys_context('userenv', 'sid'), dbms_utility.get_time)
  returning rowid into l_rowid;

 for i in 1 .. p_iterations
 loop
  l_n:=trunc(dbms_random.value(1, 10000));
  for cur in (select /*+ result_cache */ * from hc_t where n=l_n)
  loop
   null;
  end loop;
 end loop;

 update job_times set
   time_ela=dbms_utility.get_time-time_ela
  where rowid=l_rowid;
end;
/

Procedure created.

The hash cluster will go first:

SCOTT@book> delete from job_times;
4 rows deleted.

SQL> commit;
Commit complete.

declare
 l_job number;
begin
 for i in 1 .. 4
 loop
  dbms_job.submit(
   job => l_job,
   what => 'do_hc(100000);'
    );
 end loop;
end;
/

PL/SQL procedure successfully completed.

SCOTT@book> commit ;
Commit complete.


--allow jobs to complete

SCOTT@book> select case grouping(sid) when 1 then 'Total:' else to_char(sid) end sid, sum(time_ela) ela from job_times group by rollup((sid, time_ela));
SID      ELA
------- ----
41       446
54       437
80       438
94       437
Total:  1758
--//每個測試僅僅需要4秒.

Now let's see if Result Cache can beat those numbers:

SCOTT@book> delete from job_times;
4 rows deleted.

SCOTT@book> commit ;
Commit complete.

SCOTT@book> select name, gets, misses, sleeps, wait_time from v$latch where name like 'Result Cache%';
NAME                                 GETS     MISSES     SLEEPS  WAIT_TIME
------------------------------ ---------- ---------- ---------- ----------
Result Cache: RC Latch           20385043     535762          5         94
Result Cache: SO Latch                  9          0          0          0
Result Cache: MB Latch                  0          0          0          0

declare
 l_job number;
begin
 for i in 1 .. 4
 loop
  dbms_job.submit(
   job => l_job,
   what => 'do_rc(100000);'
    );
 end loop;
end;
/

PL/SQL procedure successfully completed.

SCOTT@book> commit ;
Commit complete.


--allow jobs to complete

SCOTT@book> select case grouping(sid) when 1 then 'Total:' else to_char(sid) end sid, sum(time_ela) ela from job_times group by rollup((sid, time_ela));
SID       ELA
------ ------
41       3850
54       3853
80       3860
94       3863
Total:  15426
--//我的測試使用Result Cache 更加糟糕!!每個測試需要38秒.而作者的測試兩者幾乎差不多.作者用 Nothing (almost) 來表達.

SCOTT@book> select name, gets, misses, sleeps, wait_time from v$latch where name like 'Result Cache%';
NAME                                 GETS     MISSES     SLEEPS  WAIT_TIME
------------------------------ ---------- ---------- ---------- ----------
Result Cache: RC Latch           21768802    1045691     663187   64314325
Result Cache: SO Latch                 17          0          0          0
Result Cache: MB Latch                  0          0          0          0

--//我開始以為這裡有1個將結果集放入共用池的過程,每一次執行都需要放入共用池.再次調用應該會快一些.
create or replace procedure do_rc(
 p_iterations in number
) is
 l_rowid  rowid;
 l_n number;
begin
 insert into job_times
  values (sys_context('userenv', 'sid'), dbms_utility.get_time)
  returning rowid into l_rowid;

 for i in 1 .. p_iterations
 loop
  l_n:=trunc(dbms_random.value(1, 10000));
  for cur in (select /*+ result_cache */ * from hc_t where n=l_n)
  loop
   null;
  end loop;
 end loop;

 update job_times set
   time_ela=dbms_utility.get_time-time_ela
  where rowid=l_rowid;
end;
/

--//再次執行:
declare
 l_job number;
begin
 for i in 1 .. 4
 loop
  dbms_job.submit(
   job => l_job,
   what => 'do_rc(100000);'
    );
 end loop;
end;
/

PL/SQL procedure successfully completed.
SCOTT@book> commit ;
Commit complete.

SCOTT@book> select case grouping(sid) when 1 then 'Total:' else to_char(sid) end sid, sum(time_ela) ela from job_times group by rollup((sid, time_ela));
SID     ELA
----- -----
72     3980
81     3900
96     3936
108    3922
Total 15738

--//問題依舊.我估計不同查詢存在select /*+ result_cache */ * from hc_t where n=l_n的情況下,探查Result Cache: RC Latch持有
--//時間很長,導致使用result cache更慢,這樣看來result_cache更加適合統計類結果不變的語句.而且綁定變數不要變化很多的情況.

--//換成普通表測試看看:
SCOTT@book> rename  hc_t to hc_tx;
Table renamed.

SCOTT@book> create table hc_t as select * from hc_tx ;
Table created.

SCOTT@book> create unique index i_hc_t on hc_t(n);
Index created.

--//分析表略.
--//調用do_hc的情況如下:
SCOTT@book> select count(*),avg(TIME_ELA),sum(TIME_ELA) from job_times ;
  COUNT(*) AVG(TIME_ELA) SUM(TIME_ELA)
---------- ------------- -------------
         4         431.5          1726

--//調用do_rc的情況如下:
SCOTT@book> select count(*),avg(TIME_ELA),sum(TIME_ELA) from job_times ;
  COUNT(*) AVG(TIME_ELA) SUM(TIME_ELA)
---------- ------------- -------------
         4       4027.75         16111

--//結果一樣.刪除索引在測試看看.
SCOTT@book> drop index i_hc_t ;
Index dropped.

--//調用do_hc的情況如下:
--//delete from job_times;
--//commit ;
SCOTT@book> select count(*),avg(TIME_ELA),sum(TIME_ELA) from job_times ;
  COUNT(*) AVG(TIME_ELA) SUM(TIME_ELA)
---------- ------------- -------------
         4          4160         16640

--//調用do_rc的情況如下:
--//delete from job_times;
--//commit ;
SCOTT@book> select count(*),avg(TIME_ELA),sum(TIME_ELA) from job_times ;
  COUNT(*) AVG(TIME_ELA) SUM(TIME_ELA)
---------- ------------- -------------
         4          3828         15312

--//這個時候result cache優勢才顯示出來.總之在生產系統使用要註意這個細節,一般result cahe僅僅只讀表(dml很少的靜態表)外.
--//如果經常使用不同變數查詢表,能使用索引的情況,使用result cache毫無優勢可言.


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • Openstack manila的一些命令
    （本文是測試環境進行的操作：） 1.查看一些信息： [root@openstackcontroller ~]# manila type-list [root@openstackcontroller ~]# manila service-list 因為，新建共用存儲的時候保證服務的正常，否則會失敗。 ...
  • （三）設置mysql允許外部IP連接的解決方法及遇到的坑說明
    用命令查詢埠情況：netstat -an | grep LISTEN 發現mysql用到3306這個埠，只能被127.0.0.1訪問（0.0.0.0的就是每個IP都有的服務，寫明哪個IP的就是綁定那個IP的服務） 網上查了一下預設情況下mysql只允許本地進入設置，如果需要外部IP連接到mysq ...
  • （二）阿裡雲ECS Linux伺服器外網無法連接MySQL解決方法（報錯2003- Can't connect MySQL Server on 'x.x.x.x'(10038)）（自己親身遇到的問題是防火牆的問題已經解決）
    我的伺服器買的是阿裡雲ECS linux系統。為了更好的操作資料庫，我希望可以用navicat for mysql管理我的資料庫。 當我按照正常的模式去鏈接mysql的時候， 報錯提示： 於是，通過查找資料，我找到瞭解決的方法，其實是阿裡雲伺服器為了安全預設不允許從外面鏈接Mysql資料庫。 下麵是 ...
  • （一）MYSQL ERROR 2003 (HY000): Can't connect to MySQL server on '192.168.10.210' (111) 解決方法
    今天在測試MySQL的連接時候，發現連接不通過，並報錯ERROR 2003 (HY000): Can't connect to mysql server on '192.168.10.210' (111) 測試代碼： 谷歌了一下之後，原來是在mysql的my.cnf中有下麵一段代碼： 如果要讓mys ...
  • 【Oracle學習筆記】定時任務(dbms_job)
    一、概述 Oralce中的任務有2種：Job和Dbms_job，兩者的區別有： 1． jobs是oracle資料庫的對象， dbms_jobs只是jobs對象的一個實例， 就像對於tables， emp和dept都是表的實例。 2． 創建方式也有差異，Job是通過調用dbms_scheduler.c ...
  • [20190214]11g Query Result Cache RC Latches補充.txt
    [20190214]11g Query Result Cache RC Latches補充.txt--//上午測試鏈接:http://blog.itpub.net/267265/viewspace-2632907/--//發現自己的一個錯誤,另外寫一篇帖子更正.--//順便複習result cach ...
  • Sql中CHARINDEX用法
    CHARINDEX作用 寫SQL語句我們經常需要判斷一個字元串中是否包含另一個字元串，但是SQL SERVER中並沒有像C#提供了Contains函數，不過SQL SERVER中提供了一個叫CHAEINDX的函數，顧名思義就是找到字元（char）的位置（index），既然能夠知道所在的位置，當然就可 ...
  • MySQL如何修改密碼
    以下幾種方法可供選擇 第一種方式： 最簡單的方法就是藉助第三方工具Navicat for MySQL來修改，方法如下： 1、登錄mysql到指定庫，如：登錄到test庫。 2、然後點擊上方“用戶”按鈕。 3、選擇要更改的用戶名，然後點擊上方的“編輯用戶”按鈕。 4、出現如圖界面，輸入新密碼，並確認新 ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發（一）：使用.NET MAUI開發第一個安卓APP
    移動開發（一）：使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說，近來想嘗試開發一款安卓APP，考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP，畢竟是使用Visual Studio開發工具，使用起來也比較的順手，結合微軟官方的教程進行了安卓 ...
  • wpf ToggleButton選中效果和一個登錄界面
    前言 QuestPDF 是一個開源 .NET 庫，用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫，它徹底改變了我們生成 PDF 文檔的方 ...
  • 彈幕樹洞項目功能新增篇
    項目地址 項目後端地址： https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址： ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址： http://tree ...
  • 第27篇 sqlserver2022詳細安裝步驟
    話不多說，直接開乾 一.下載 1.官方鏈接下載： https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe，運行開始下載SQL server； 二. ...
  • .NET 開源高性能 MQTT 類庫
    前言 隨著物聯網（IoT）技術的迅猛發展，MQTT（消息隊列遙測傳輸）協議憑藉其輕量級和高效性，已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫，為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog文檔翻譯系列（六） - 可用的接收器、增強器、格式化輸出
    Serilog支持多種接收器用於日誌存儲，增強器用於添加屬性，LogContext管理動態屬性，支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項，適用於不同需求。 ...
  • 警惕 Visual Studio 屬性求值副作用導致邏輯不符合預期
    目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據，爬取信息時需要模擬瀏覽器行為，否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下： 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • [使用目前最新版]HybridCLR6.9.0+YooAsset2.2.4實現純C# Unity熱更新方案 (一)
    1.前言 什麼是熱更新 游戲或者軟體更新時，無需重新下載客戶端進行安裝，而是在應用程式啟動的情況下，在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR，Xlua，ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles，Addressable， ...
  • 在 ASP.NET Core Web API 中使用操作篩選器統一處理通用操作
    本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺，其實像阿裡雲，騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後，它會送 ...
  • 第28篇 如何.net中實現高效可靠數據同步api
    通過以下方式可以高效，並保證數據同步的可靠性 1.API設計 使用RESTful設計，確保API端點明確，並使用適當的HTTP方法（如POST用於創建，PUT用於更新）。 設計清晰的請求和響應模型，以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證，確保接收到的數據符合預期格 ...
所有分類