[20150924]result cache problem.txt

[20150924]result cache problem.txt

--昨天看了连接,看到一个关于result cache的例子,重复测试看看:
--链接 https://jonathanlewis.wordpress.com/2015/09/22/result-cache/

1.环境:
SCOTT@test> @ver1

PORT_STRING                    VERSION        BANNER
------------------------------ -------------- --------------------------------------------------------------------------------
x86_64/Linux 2.4.xx            11.2.0.3.0     Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production

set serveroutput on;

alter system flush shared_pool;

truncate table gtt1;
drop table gtt1;
create global temporary table gtt1 (n1 number) on commit preserve rows ;

insert into gtt1 values(1);
commit;

execute dbms_stats.gather_table_stats(user,'gtt1');

create or replace function f_cache
return number
result_cache
-- relies_on (gtt1)
is
        m_ret number;
begin
        select max(n1) into f_cache.m_ret from gtt1 ;
        return f_cache.m_ret;
end;
/

SCOTT@test> execute dbms_output.put_line(f_cache);
1

PL/SQL procedure successfully completed.

2.测试1:
--session A:
set serveroutput on
SCOTT@test> execute dbms_output.put_line(f_cache);
1

PL/SQL procedure successfully completed.
--这个正确!

--session B:
set serveroutput on
SCOTT@test> execute dbms_output.put_line(f_cache);
1

PL/SQL procedure successfully completed.
--而这里存在问题。

SCOTT@test> insert into gtt1 values(0);
1 row created.

SCOTT@test> execute dbms_output.put_line(f_cache);
0
PL/SQL procedure successfully completed.

3.测试2:

--Session A:
SQL> truncate table gtt1;
Table truncated.

SQL> execute dbms_output.put_line(f_cache);
1

SCOTT@test> execute dbms_output.put_line(f_cache);
1

PL/SQL procedure successfully completed.
--已经truncate ,依旧存在输出,而是还是1.

--session B:
Session B (where I hadn't yet committed):

SCOTT@test> commit;
Commit complete.

--Session A (where I've done nothing new):

SCOTT@test> execute dbms_output.put_line(f_cache);
PL/SQL procedure successfully completed.

The row has finally "disappeared" because session B committed.

--Session B (where I haven't done anything since committing):

SCOTT@test> execute dbms_output.put_line(f_cache);
PL/SQL procedure successfully completed.

--而实际上这是应该输出0.
--当然这个情况很特殊,gtt1是临时表。仅仅对会话有效,做一个记录。

时间: 2024-07-30 10:52:43

[20150924]result cache problem.txt的相关文章

[20160919]Result cache问题.txt

[20160919]Result cache问题.txt --看了链接http://blog.dbi-services.com/result-cache-side-effects-on-number-of-calls/,重复测试: SCOTT@book> @ &r/ver1 PORT_STRING                    VERSION        BANNER ------------------------------ -------------- -----------

[20141223]result cache 3.txt

[20141223]result cache 3.txt --上午的测试有一些问题,做一些更正. SCOTT@test> @ver1 PORT_STRING                    VERSION        BANNER ------------------------------ -------------- -------------------------------------------------------------------------------- x86

[20151015]关于result cache 2.txt

[20151015]关于result cache 2.txt --11G 开始支持result cache,把执行的结果保存在共享池,从而一定程度减少逻辑读,而那些对象或者那些语句适合做result cache呢? --自己在前一段时间想把一些表设置RESULT_CACHE为MODE FORCE,访问这些对象时,可以利用result cache模式. --另外我本来想一些语句通过sql patch的方式加入提示/*+ result_cache */ ,结果不成功. --参考链接:http://b

[20111230]11Gr2 result cache[1].txt

11G的result cache是一个很吸引人的特性,可以大幅减少逻辑读取,特别对于一些经常执行的语句,而结果不是经常变化的,效果不错,我的测试遇到一个小问题. SQL> select * from v$version; BANNER--------------------------------------------------------------------------------Oracle Database 11g Enterprise Edition Release 11.2.0

[20141219]result cache与view.txt

[20141219]result cache与view.txt --result cache是11g的新特性,能一定程度减少逻辑读,我个人的感觉特别适合很少修改,经常访问的小表,而应用中经常扫描的表, --我经常把这种应用模式叫刷屏软件.... --前一阵子我在做优化工作中,遇到的一些问题,做一些总结: SCOTT@test> @ver1 PORT_STRING          VERSION        BANNER -------------------- --------------

[20151014]关于result cache.txt

[20151014]关于result cache.txt --11G 开始支持result cache,把执行的结果保存在共享池,从而一定程度减少逻辑读,而那些对象或者那些语句适合做result cache呢? --自己在前一段时间想把一些表设置RESULT_CACHE为MODE FORCE,访问这些对象时,可以利用result cache模式. --另外我本来想一些语句通过sql patch的方式加入提示/*+ result_cache */ ,结果不成功. --参考链接:http://blo

[20161216]关于library cache lock.txt

[20161216]关于library cache lock.txt --这几天一直在关注这个链接,http://www.itpub.net/thread-2073170-1-1.html --就是library cache lock导致挂死业务,一般引起这个问题编译包,而应用正好在使用执行这个包,以及11g口令大小写导致无法登录的问题, --我自己很久以前也遇到过一些,那时的系统是10g,http://www.itpub.net/thread-1842463-1-1.html,但是只要分析某个

1223 result cache,sql profile,sql patch

[20141223]result cache 与sql profile,sql patch.txt --前面blog已经提到result cache的好处与缺点,对于第三方优化,sql profile可以改变稳定执行计划,是否可以通过改变提示来稳定 --执行计划,这样对频繁执行的语句较少逻辑读,提高服务器响应有积极意义. --sql patch 也具有相似的作用,看看这种方式是否可行. SCOTT@test> @ver1 PORT_STRING                    VERSIO

oralce 12.1中出现大量Result Cache: RC Latch处理

昨天有个朋友找到我说他们的12.1的库在业务高峰期非常慢,希望我们给予优化支持,经过awr分析,定位到问题为latch free问题,具体定位为:Result Cache: RC Latch.优化之前awr部分信息 awr整体负载情况,证明当前这个库已经比较忙,业务反馈很慢 addr信息和top wait信息,确定是latch free问题比较突出 latch信息统计和ash信息,找出来突出的latch,定位为Result Cache: RC Latch引起该问题 补充大量异常sql 类似sql