有個不大的表 資料量大於百萬級別 這是類似ip位址範圍查詢. 表的查詢量很大.數實時生成,有時會被更新
該錶上的索引 主鍵和表 都被我keep進記憶體了.
查詢速度 基本保持在50-30毫秒之間.
該錶的資料 一天要查500萬次以上.同時被重複查詢的次數也蠻多子.
鑑於這個原因 所以向開發人員提出 在sql 增加提示
/*+ result_cache */
結論是 結果快取通過表的依賴而失效,也就是說相應表發生了資料變化那麼就重新從表獲取.
相比時間 比普通
45毫秒 高很多 達到
945毫秒
. 難道它不曉得從記憶體中獲取嗎
? 還是覺得表資料有變化,直接從硬碟上讀取才是真!
declare
b1 varchar2(20
);b2
number
;org
number(10
);s
timestamp
;e
timestamp
;r
timestamp
;begin
b2:=12;
b1:=
668239581895
;for
i in
1..100
loop
s:=systimestamp
;select
/*+ result_cache */
use_ip
into
ipfrom
(select
a.use_ip
a.ip_type
from
back_ip a
where
a.ip_type in(
3, 5,
9)andip_legn = b2
anda.start_ip <= b1
anda.end_ip >= b1
order
bya.disp_date
desc
,a.create_time
desc
)where
rownum
<= 1;
e:=systimestamp
;dbms_output.put_line(to_char(e-s));
dbms_lock.sleep(
10);
endloop
;end
;測試結果 不很理想 波動性太大了.
+00000000000:00:00.090374000
+00000000000:00:00.102860000
+00000000000:00:00.000237000
+00000000000:00:00.000139000
+00000000000:00:00.000135000
+00000000000:00:00.000163000
+00000000000:00:00.000170000
+00000000000:00:00.000206000
+00000000000:00:00.000173000
+000000000 00:00:00.000171000
+00000000000:00:00.000170000
+00000000000:00:00.000139000
+00000000000:00:00.000267000
+00000000000:00:00.000171000
+00000000000:00:00.000160000
+00000000000:00:00.000180000
+00000000000:00:00.000161000
+00000000000:00:00.000183000
+00000000000:00:00.000182000
+00000000000:00:00.000139000
+00000000000:00:00.000147000
+00000000000:00:00.000160000
+00000000000:00:00.000212000
+00000000000:00:00.000353000
+00000000000:00:00.094454000
Oracle診斷檔案 11g
通過diagnostic desc引數檢視adr的根目錄。show parameter diagnostic dest 通過v diag info檢視檢視adr目錄結構的細節。select name,value from v diag info 檢視報警檔案的儲存位置 show parameter ...
ORACLE PLSQL 基本迴圈（11g）
迴圈原則 如果迴圈內部必須執行一次，則使用基本迴圈 如果知道迴圈次數，則使用for迴圈 如果必須在每次迴圈開始時判斷條件，則使用while迴圈 1 基本迴圈 sql declare 2 i number 0 3 begin 4 loop 5 dbms output.put line i 6 i i ...
測試11g壓縮效能
測試11g壓縮效能 綜合結果 在11g 上針表設定 compress 後預設是 enabled direct load only 既只有通過直接路徑插入 才可以壓縮，壓縮比率與正常 move compress 最佳比率一致，無明顯區別 oracle 按插入型別分類，直接插入型別壓縮演算法一致 當表設...