问题描述
嗨,汤姆,
要验证 “无解析” 和 “软解析”,请执行以下测试。
“软解析” 的执行时间和使用的锁存器都比 “无解析” 好 (见下文)。
你能提出原因吗?
设置 “无解析” 情况有问题吗?
谢谢
问候
托马斯
下降表t;
创建表t (x varchar2(30) );
-软解析与无解析
执行运行状态 _ pkg.rs_start;
alter会话集会话 _ 缓存 _ 游标 = 50;
开始
我在1 ..10000
循环
插入到t(x) 值 (i) 中;
结束循环;
结束;
/
执行运行状态 _ pkg.rs_middle;
声明
M _ 光标号;
M_rows_proced number;
开始
光标: = dbms_sql.open_cursor;
dbms_sql.parse(m_cursor,'插入到t(x) 值 (:n)',dbms_sql.native );
对于我在1 .. 10000循环
dbms_sql.bind_variable_char(m_cursor,':n',i);
M_rows_procedued: = dbms_sql.execute(m_cursor);
结束循环;
dbms_sql.close_cursor(m_cursor);
结束;
/
执行运行状态 _ pkg.rs_stop(50);
Run1在120 hsecs中运行
Run2在183 hsecs中运行
运行1运行在65.57% 的时间
名称运行1运行2差异
STAT...db块更改20,291 20,240 -51
STAT...db块从cach 10,345 10,293 -52获取
STAT...db块获取10,345 10,293 -52
STAT...DB时间131 184 53
统计。一致获得pin (fa 42 97 55
统计... 一致得到引脚42 97 55
STAT... 呼叫star 127 183 56时使用的CPU
统计... 一致得到74 130 56
统计... 来自ca 74 130 56的一致获取
统计... 无工作-一致re 8 66 58
STAT... 此sessio 120使用的CPU 183 63
锁存器.SQL内存管理器工作70 3 -67
LATCH.cache buffers链51,261 51,175 -86
STAT...KTFB分配时间 (ms) 142 50 -92
STAT... 缓冲区未固定co 3 100 97
STAT... 表扫描磁盘非IMC 321 0 -321
STAT... 表扫描行获得321 0 -321
STAT... 通过SQL * Net发送的字节1,485 990 -495
STAT... 撤消更改向量大小686,508 685,944 -564
STAT... 通过SQL * 2,545 1,969 -576接收的字节
LATCH.simulator哈希锁存器20 1,361 1,341
STAT... 重做大小2,624,228 2,619,620 -4,608
STAT... 非空闲等待计数12 10,009 9,997
STAT... 会话光标缓存hi 10,004 6 -9,998
STAT... 打开游标累积10,012 7 -10,005
STAT... 来自 #
STAT...KTFB分配空间 (块1,179,648 65,536-1,114,112
Run1闩锁总数与运行-差异和pct
运行1运行2差异Pct
62,371 63,474 1,103 98.26%
PL/SQL过程成功完成。
要验证 “无解析” 和 “软解析”,请执行以下测试。
“软解析” 的执行时间和使用的锁存器都比 “无解析” 好 (见下文)。
你能提出原因吗?
设置 “无解析” 情况有问题吗?
谢谢
问候
托马斯
下降表t;
创建表t (x varchar2(30) );
-软解析与无解析
执行运行状态 _ pkg.rs_start;
alter会话集会话 _ 缓存 _ 游标 = 50;
开始
我在1 ..10000
循环
插入到t(x) 值 (i) 中;
结束循环;
结束;
/
执行运行状态 _ pkg.rs_middle;
声明
M _ 光标号;
M_rows_proced number;
开始
光标: = dbms_sql.open_cursor;
dbms_sql.parse(m_cursor,'插入到t(x) 值 (:n)',dbms_sql.native );
对于我在1 .. 10000循环
dbms_sql.bind_variable_char(m_cursor,':n',i);
M_rows_procedued: = dbms_sql.execute(m_cursor);
结束循环;
dbms_sql.close_cursor(m_cursor);
结束;
/
执行运行状态 _ pkg.rs_stop(50);
Run1在120 hsecs中运行
Run2在183 hsecs中运行
运行1运行在65.57% 的时间
名称运行1运行2差异
STAT...db块更改20,291 20,240 -51
STAT...db块从cach 10,345 10,293 -52获取
STAT...db块获取10,345 10,293 -52
STAT...DB时间131 184 53
统计。一致获得pin (fa 42 97 55
统计... 一致得到引脚42 97 55
STAT... 呼叫star 127 183 56时使用的CPU
统计... 一致得到74 130 56
统计... 来自ca 74 130 56的一致获取
统计... 无工作-一致re 8 66 58
STAT... 此sessio 120使用的CPU 183 63
锁存器.SQL内存管理器工作70 3 -67
LATCH.cache buffers链51,261 51,175 -86
STAT...KTFB分配时间 (ms) 142 50 -92
STAT... 缓冲区未固定co 3 100 97
STAT... 表扫描磁盘非IMC 321 0 -321
STAT... 表扫描行获得321 0 -321
STAT... 通过SQL * Net发送的字节1,485 990 -495
STAT... 撤消更改向量大小686,508 685,944 -564
STAT... 通过SQL * 2,545 1,969 -576接收的字节
LATCH.simulator哈希锁存器20 1,361 1,341
STAT... 重做大小2,624,228 2,619,620 -4,608
STAT... 非空闲等待计数12 10,009 9,997
STAT... 会话光标缓存hi 10,004 6 -9,998
STAT... 打开游标累积10,012 7 -10,005
STAT... 来自 #
STAT...KTFB分配空间 (块1,179,648 65,536-1,114,112
Run1闩锁总数与运行-差异和pct
运行1运行2差异Pct
62,371 63,474 1,103 98.26%
PL/SQL过程成功完成。
专家解答
很难得到一个 “足够接近” 的比较,因为显然它需要CPU周期和类似的东西来运行PLSQL,所以你有 (因为它的解释) 的PLSQL代码的数量最终有一个轴承。
所以也许这里有一个更好的方法来比较影响
测试1: 会话缓存游标 = 0
测试2: 会话缓存游标 = 50
测试3: 会话缓存游标 = 0
我从tkprof那里得到这个
并通过以下方式验证命中计数
<代码>
选择
s、名称,圣值
从v $ statname s,v $ sesstat st st
其中st。统计 # = s。统计 #
和st.sid = sys_context('USERENV','SID')
和s.name = '会话光标缓存命中';
<代码>
因此,请尝试在您的机器/数据库上进行这些排列,看看如何
所以也许这里有一个更好的方法来比较影响
测试1: 会话缓存游标 = 0
for i in 1..50000 loop dbms_sql.parse(m_cursor, 'insert into t(x) values(:n)', dbms_sql.native ); dbms_sql.bind_variable_char(m_cursor, ':n', i); m_rows_processed := dbms_sql.execute(m_cursor); end loop;
测试2: 会话缓存游标 = 50
for i in 1..50000 loop dbms_sql.parse(m_cursor, 'insert into t(x) values(:n)', dbms_sql.native ); dbms_sql.bind_variable_char(m_cursor, ':n', i); m_rows_processed := dbms_sql.execute(m_cursor); end loop;
测试3: 会话缓存游标 = 0
dbms_sql.parse(m_cursor, 'insert into t(x) values(:n)', dbms_sql.native ); for i in 1..50000 loop dbms_sql.bind_variable_char(m_cursor, ':n', i); m_rows_processed := dbms_sql.execute(m_cursor); end loop;
我从tkprof那里得到这个
insert into t(x) values (:n) call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 49999 0.37 0.51 0 0 0 0 Execute 49999 1.49 1.46 1 50347 152067 49999 Fetch 0 0.00 0.00 0 0 0 0 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 99998 1.87 1.98 1 50347 152067 49999 insert into t(x) values (:n) call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 50000 0.37 0.28 0 0 0 0 Execute 50000 1.37 1.41 0 50347 152062 50000 Fetch 0 0.00 0.00 0 0 0 0 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 100000 1.76 1.69 0 50347 152062 50000 insert into t(x) values (:n) call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 1 0.00 0.00 0 0 0 0 Execute 50000 0.95 0.80 0 644 52144 50000 Fetch 0 0.00 0.00 0 0 0 0 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 50001 0.95 0.80 0 644 52144 50000
并通过以下方式验证命中计数
<代码>
选择
s、名称,圣值
从v $ statname s,v $ sesstat st st
其中st。统计 # = s。统计 #
和st.sid = sys_context('USERENV','SID')
和s.name = '会话光标缓存命中';
<代码>
因此,请尝试在您的机器/数据库上进行这些排列,看看如何
「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。




