温馨提示！由于新浪微博认证机制调整，您的新浪微博帐号绑定已过期，请重新绑定！&&|&&
模块内容加载中...
this.p={b:2,s:2,a:true};
{if !defined('ml')||!ml.length} 专辑 ${an|escape} 没有音乐！ {else} {list ml as x}{/list} {/if}
{if !defined('ll')||!ll.length} 网易博客音乐盒 {else} {list ll as x}${x.v|default:'&'}{/list} {/if}
{if !defined('al')||!al.length} 没有专辑！ {else} {list al as x}{/list} {/if}
& & consistent mode&&是在基于 query mode 下的，oracle有一个一致读的概念& & 也就是说，当查询开始的时候oracle将确立一个时间点，凡是在这个时间点以前提交的数据oracle将能看见，之后提交的数据将不能看见。但查询的时候可能遇上这样的情况，该块中数据已经被修改了，没有提交，或者提交的时间点比查询开始的时间晚，则oracle为了保证读的一致性，需要去回滚段获取该块中变化前的数据。这叫 consistent reads 。
& & Oracle的优化器有两种优化方式,即基于规则的优化方式(Rule-Based Optimization，简称为RBO)和基于代价的优化方式(Cost-Based Optimization，简称为CBO)，在Oracle8及以后的版本,Oracle强列推荐用CBO的方式&&& RBO方式：优化器在分析SQL语句时,所遵循的是Oracle内部预定的一些规则。比如我们常见的，当一个where子句中的一列有索引时去走索引。
set autotrace off&&&set autotrace on&&&set autotrace traceonly&&&&&set autotrace on explain&&&set autotrace on statistics&&&set autotrace on explain statistics&&&&&set autotrace traceonly explain&&&set autotrace traceonly statistics&&&set autotrace traceonly explain statistics&&&&&
好久没登陆博客了，不得不承认在移动互联浪潮的冲刷下，博客这个曾经我们一度迷恋的角落已经渐渐被越来越多的人 所淡忘。就好比曾经陪伴我们走过一段旅程的高中同学，大学同学一样，走出校园，大家在距离与时间的左右下，渐渐成为彼此心中美好的回忆。 我的朋友，相信大家也都一样在为自己的未来而拼搏着吧，经过一年职场的历练，不知大家现在过都如何，是否和我一样时常会回忆起大家以前在学校那段美好的日子呀。朋友们，在努力工作的同时不要忘记工作并非生活的全部。最近请了三天假加上周末，在家里过了个小长假，这种以前唾手可得的生活现在竟成为一种奢侈，父母听到儿子要回家，早早就把房间收拾得干干净净的 ，走进这个久违的房间，仿佛看到高中时候晚
&&&&&&&&2013年2月底，在家里过完了大学最后一个春节，意味着我要走上传说中坎坷的求职路了，学校的围墙隔开了外面世界的是非纷争，父母的的臂膀撑起晴空万里，离开这些，突然发现自己有点不适用，独自来到大学城租了个单间（期间少不了好友饶的帮助），安心下来找工作，记得第一次去北亭参加所谓的计算机自动化专场招聘会，有点失望，到场的企业也不过二十家，那天我就投了个4399，之后的面试，因为自己没学过AS3.0和在面试官面前没有表现出他们所期望的对游戏行业的热爱，所以第一次面试宣告失败，白白等了三天。回到住处大睡了几天，坐等三月三号广工理科专场招聘会，为了熟悉场地，三月二号文科专场的我也去了，3号那天，从开场到招聘会结束，苦苦排了八次队，投了八份简历，或许是自动化出身的我找java的工作真的会招人质疑吧，八份简历就只
& 喜欢PX的男孩 &
近期心愿多多旅游。。哈哈 博客等级
最后登录加载中...
this.p={b:2,ua:26, ub:'http://img.bimg.126.net/photo/DtMEDZQksu_5J9VRnKg8fQ==/587499.jpg',us:'他', friendstatus:'none',followstatus:'unFollow',hmcon:'1',aShowT:'0',guideId:6};
积分 ${data.totalScore} 分，距离下一等级还有 ${data.nextGradeNeedScore}分
心情随笔列表加载中...
this.p={b:2,n:5,r:'http://cjf2270822./blog/#m=1&c=',mset:'000',mcon:'',srk:-100};
{if defined('fl')&&fl.length>0} {list fl as x}
${x.content|xescape:x.id,x.moveFrom} ${x.publishTime|xtime}
{if x.moveFrom&&x.moveFrom=='wap'} && {/if} {if x.moveFrom&&x.moveFrom=='mobile'} && {/if}
{/list} {else} 暂无心情随笔记录！ {/if}
博友列表加载中...
this.p={b:2,m:0};
列表加载中...
this.p={b:2,cn:15};
发现好博客
列表加载中...
this.p={b:2,cn:12,ct:12};
& & & & & &
网易公司版权所有&&
二次元同好交流新大陆
扫码下载App
{list x.l as y}
{/list} {/list}
{if defined('wl')} {list wl as x}{/list} {/if}3950人阅读
Oracle（20）
在Oracle的文档中有这样的解释：Recursive Calls: Number of recursive calls generated at both the user and system level. Oracle Database maintains tables used for internal processing. When it needs to change these tables, Oracle Database generates an internal SQL statement, which in turn generates a recursive call. In short, recursive calls are basically SQL performed on behalf of your SQL. So, if you had to parse the query, for example, you might have had to run some other queries to get data dictionary information. These would be recursive calls. Space management, security checks, calling PL/SQL from SQL&all incur recursive SQL calls.
db block gets：Number of times a CURRENT block was requested.consistent gets：Number of times a consistent read was requested for a block.physical reads：Total number of data blocks read from disk. This number equals the value of "physical reads direct" plus all reads into buffer cache.---------------------------------------------针对以上3个概念进行的说明解释及关系如下：1、DB Block Gets（当前请求的块数目）当前模式块意思就是在操作中正好提取的块数目，而不是在一致性读的情况下而产生的块数。正常的情况下，一个查询提取的块是在查询开始的那个时间点上存在的数据块，当前块是在这个时刻存在的数据块，而不是在这个时间点之前或者之后的数据块数目。2、Consistent Gets（数据请求总数在回滚段Buffer中的数据一致性读所需要的数据块）这里的概念是在处理你这个操作的时候需要在一致性读状态上处理多少个块，这些块产生的主要原因是因为由于在你查询的过程中，由于其他会话对数据块进行操作，而对所要查询的块有了修改，但是由于我们的查询是在这些修改之前调用的，所以需要对回滚段中的数据块的前映像进行查询，以保证数据的一致性。这样就产生了一致性读。3、Physical Reads（物理读）就是从磁盘上读取数据块的数量，其产生的主要原因是：1、 在数据库高速缓存中不存在这些块2、 全表扫描3、 磁盘排序它们三者之间的关系大致可概括为：逻辑读指的是Oracle从内存读到的数据块数量。一般来说是'consistent gets' + 'db block gets'。当在内存中找不到所需的数据块的话就需要从磁盘中获取，于是就产生了'phsical reads'。
觉得还是不够详细，再补充一下：db block gets : number of data blocks read in CURRENT mode ie) not in a read consistent fashion, but the current version of the data blocks. 产生db_block_gets的主要方式：1.DML like Update, Delete will need to access the blocks in the current mode for modification. 2.Most data dictionary calls are done in CURRENT mode. 3.Buffers are often retrieved in current mode for INSERT, UPDATE, and DELETE, and SELECT FOR UPDATE statements. Blocks must be requested in current mode in order to be changed. 4.Also certain classes of blocks, like segment header blocks are always requested in current mode. 5. this will happen when you're doing a FULL TABLE SCAN on a table or a FAST FULL SCAN on an index. In those cases, the segment header is read (usually multiple times for some unknown reason) in current mode.在current mode模式下产生的对block的访问叫db block gets，这些block在SGA中，不需要访问硬盘。db_block_gets counts logical reads in CURRENT mode in the buffer cache and also includes direct read blocks (sort-on-disk) blocks..consistent gets : number of data blocks accessed in READ CONSISTENT mode. When a block is requested in consistent mode, if any changes have been committed or made to that block since the requesting statement (or transaction) began, then they must be rolled back for the purposes of the read, to give a consistent view of the data at that time.(当数据库是在consistent mode模式下被请求的，则假如该数据块的数据修改是在查询语句发出之后被提交的，则此查询语句读到该数据块时，还必须为本次查询将数据回滚，得到查询语句发出时该数据块的值，以便给查询给出一个与该查询有关的所有数据块的一致性视图，这也就是oracle所说的一致性读)&& In order to maintain statement level read consistency, Oracle has to read the blocks in a consistent fashion(as of the snapshot SCN) and hence may fetch from rollback segments , which is also added to this statistic. Buffers are usually retrieved in consistent mode for queries. 如普通的select语句、索引访问而引起的将数据读入到buffer中(也可能为physical read)或直接从buffer中读数据。注意，DML语句也能引起consistent gets，如update tab1 set col_b='Hello world' where col_a=1;，因为该语句需要找到需要被修改的所有数据块，在找数据块的过程中就会引起consistent gets。在Read consistent mode模式下产生的对block的访问叫consistent gets。 Session logical read is: The sum of "db block gets" plus "consistent gets".db_block_changes:db_block_changes counts modifications made to CURRENT blocks 'db block changes' = changes made to current blocks under LOGING ( UPDATE, INSERT, DELETE) + changes made to SORT blocks ( NOLOGING). 'consistent changes' :changes made to block for CONSISTENT READ and changes made to SORT blocks physical reads :Physical( disk and/or filesystem page cache) reads. Basically those that cannot be satisfied by the cache and those that are direct reads.Total number of data blocks read from disk. This number equals the value of "physical reads direct" (direct from disk, excludes buffer cache) plus all reads into buffer cache. physical writes ：Total number of data blocks written to disk. This number equals the value of "physical writes direct" (Number of writes directly to disk, bypassing the buffer cache as in a direct load operation) plus all writes from buffer cache. 要注意Oracle 的physical read 与 physical writes并不总是等于硬盘真正意义上的物理读与物理写，因为现在都存在操作系统高速缓存与磁盘子系统高速缓存，这样及时I/O没有被实际写入磁盘，操作系统I/O子系统或磁盘系统也会确认为一个成功的I/O，所以ORACLE 的physical read 与 physical writes并不是物理上发生读写的次数。redo block size：redo block size is platform specific. There is a method to determine the size by dumping the redo header, refer to note . Redo blocks written does not include archive writes or multiplexed writes.redo entries:The redo log buffer is a circular buffer in the SGA that holds information about changes made to the database. This information is stored in redo entries. Redo entries contain the information necessary to reconstruct, or redo, changes made to the database . Redo entries are used for database recovery, if necessary. Redo entries are copied by Oracle server processes from the user's memory space to the redo log buffer in the SGA. (this copy is what the statistic represents). db block changes包含dml修改的block，也包含为实现rollback功能而修改的block，但是不包含为实现redo功能而修改的block。the number of blocks visited = consistent gets + db block getsthe number of blocks visited相当与logical read，即从内存中都数据块的次数。做一个测试：用下面语句取得统计信息：select sid,value,name from v$sesstat x,v$statname ywhere x.statistic#=y.statistic#and ( name like '%db block%gets%' or name like '%consistent%gets%'or name like '%consistent%change%' or name like '%db block%change%' or name like '%physical writes%' or name like '%physical reads%'or name = 'index fetch by key' or name like '%read%' or name like '%scans%'&&)and sid = 12 and value & 0Lets take an example to illustrate relationship between 'db block gets' and 'db block changes' . create table toto( i number); select sid,value,name from v$sesstat x,v$statname ywhere x.statistic#=y.statistic#and ( name like '%db block%gets%' or name like '%consistent%gets%'or name like '%consistent%change%' or name like '%db block%change%' or name like '%physical writes%' or name like '%physical reads%'or name = 'index fetch by key' or name like '%read%' or name like '%scans%'&&)and sid = 12 and value & 0SID VALUE NAME ---------- ---------- ------------------------------ 11 95 db block gets 11 108 db block changes 11 0 consistent changes select count(*) from toto x, toto y, COUNT(*) ---------- 0 select sid,value,name from v$sesstat x,v$statname ywhere x.statistic#=y.statistic#and ( name like '%db block%gets%' or name like '%consistent%gets%'or name like '%consistent%change%' or name like '%db block%change%' or name like '%physical writes%' or name like '%physical reads%'or name = 'index fetch by key' or name like '%read%' or name like '%scans%'&&)and sid = 11 and value & 0order by valueSID VALUE NAME ---------- ---------- ------------------------------ 11 98 db block gets 11 108 db block changes 11 0 consistent changes Here we can see that a select increment 'db block gets' by 3 and 'db block changes' remains the same : this illustrates that we can get block in current mode ( to have most recent information) without performing any changes." & 这也可以作为current mode的定义。下面这段写的非常好，如果上面的还是不理解，则需要仔细的看一下！A 'consistent get' is your server process telling the database "I need this dba (data block address) consistent with the point in time represented by this SCN, x." So, lots of things can happen here. First, Oracle will look in the buffer cache for a CR (consistent read) buffer of the block that's consistent w/ the requested SCN. It may find it, if it does, that's counted as a 'consistent get' and either a 'consistent gets - no work' or 'consistent gets - cleanouts only', depending on whether the block needed to be cleaned out. (See V$SYSSTAT/V$SESSTAT for the statistics.) If it doesn't, it may take an existing CR buffer and roll it back further, or it may clone the current block and roll it back. If it needs to apply rollback (aka undo) then it will increment 'consistent gets' and either 'consistent gets - rollbacks only' or 'consistent gets - cleanouts and rollbacks'. So, each 'consistent get' is your server process successfully getting access to the contents of a dba consistent w/ a particular SCN. This number should represent the number of buffer gets required to satisfy a particular query. Now, 'db block gets'. A 'db block get' is a copy of the 'current mode block'. That is, the data in the block, as it exists currently, or at this point in time. Note that while multiple CR copies of a block may exist in the buffer cache, there can only ever be one current mode copy of a block in the buffer cache at any one time. (RAC is a special case, w/ shared current and exclusive current, but I'm not going to get into that here.) So, a 'db block get' is a buffer get in current mode. 'db block gets' are usually associated w/ DML, and in that scenario, will implicitly lock one or more rows in that block. Also, there is a notable case where db block gets can occur with a select statement. That will happen when you're doing a FULL TABLE SCAN on a table or a FAST FULL SCAN on an index. In those cases, the segment header is read (usually multiple times for some unknown reason) in current mode.Next, 'physical reads': A physical read will occur any time a consistent get or a db block get goes looking for block and can't find it in the buffer cache. So, for each block read from disk, physical reads will be incremented. Gets which result in physical reads are counted both as as get and as a read in the statistics. So, if you do 10 consistent gets and 5 of them require physical reads, you should see consistent gets incremented by 10 and physical reads incremented by 5. Now, what's up w/ arraysize? Well, arraysize is the client side setting for SQL*Plus specifying the size of the array that will receive result sets. The default, as you learned, is 15. Now, suppose you have a table where there are 30 records per block, and 3,000 rows in the table. But, your arraysize is 15. So, your server process will get the first 15 rows, and return them from the first block buffer. Now, for the next 15, you need to get that same block again, for rows 16-30. So, you need to do two buffer gets per block to get all the rows. For a 3,000 row table, you'll do (approximately) 3,000/15 = 200 buffer gets. If you change your arraysize to 30, you can get away w/ visitng each block only once and do 3,000/30 = 100 buffer gets. So, consider that even after you've optimized a particular SQL statement, if the arraysize is too small, you're going to force your server process to do excess database calls (FETCH calls), and extra buffer gets as well. This can best be illustrated with a test similar to what you did, but try looking at the raw trace file for FETCH calls. The number of FETCH calls ought to be very close to (number of rows returned / arraysize). The 'r=xxx' in the FETCH call data in the trace file is the number of rows returned, which is probably what your arraysize is set to. So, db block gets, consistent gets, and physical reads are all measured in buffers (or blocks). If the same block is requested multiple times, it will be counted that many times in these statistics. Oracle will always access data from the buffer cache by the buffer. All 'get' operations are by the buffer, never by row. After the buffer is 'gotten', Oracle parses the block to get the data for the relevant rows.When a "consistent get" is done, this doesn't necessarily mean that Oracle had to do any rollback/undo of DML in order to get the consistent image. Rather, it just means that Oracle requested a copy of the block as of the point in time that the query was started (a "consistent snapshot"). So, I believe it is quite normal to have many, many consistent gets even if there is NO DML occuring.自己做的一个更详细的测试：用到的查询统计信息的语句;select sid,value,name from v$sesstat x,v$statname ywhere x.statistic#=y.statistic#and ( name like '%db block%gets%' or name like '%consistent%gets%'or name like '%consistent%change%' or name like '%db block%change%' or name like '%physical writes%' or name like '%physical reads%'or name = 'index fetch by key' or name like '%read%' or name like '%scans%'&&)and sid = 11 and value & 0order by valueScott用户登录，但是没有做任何操作，sid为10，在另外一个用户下查询：&& SID && VALUE NAME---------- ---------- --------------------------------&& &&& 11 && && 3 db block gets&& &&& 11 && && 0 physical reads&& &&& 11 && && 4 db block changes&& &&& 11 && && 0 consistent changes&& &&& 11 && && 0 physical writes&& &&& 11 && && 0 physical writes non checkpoint&& &&& 11 && && 0 physical reads direct&& &&& 11 && && 0 physical writes direct&& &&& 11 && && 0 physical reads direct (lob)&& &&& 11 && && 0 physical writes direct (lob)在scott sid=11下运行select * from emp后，结果没有任何变化，这是不应该的，应该有physical reads与db block gets的值变化在scott sid = 11下运行update emp set comm = 10; 在另外一个用户下查询：&& SID && VALUE NAME--------- ---------- ------------------------------&& 11 && && 18 db block gets&& 11 && && 0 physical reads&& 11 && && 33 db block changes&& 11 && && 0 consistent changes&& 11 && && 0 physical writes&& 11 && && 0 physical writes non checkpoint&& 11 && && 0 physical reads direct&& 11 && && 0 physical writes direct&& 11 && && 0 physical reads direct (lob)&& 11 && && 0 physical writes direct (lob)再次在scott sid = 11的同一个session下运行update emp set comm = 10; 在另外一个用户下查询：SID && VALUE NAME------- ---------- -------------------------------&&& 11 && && 32 db block gets&&& 11 && && 0 physical reads&&& 11 && && 61 db block changes&&& 11 && && 0 consistent changes&&& 11 && && 0 physical writes&&& 11 && && 0 physical writes non checkpoint&&& 11 && && 0 physical reads direct&&& 11 && && 0 physical writes direct&&& 11 && && 0 physical reads direct (lob)&&& 11 && && 0 physical writes direct (lob)不要用scott再次登录, sid 为17，在另外一个用户下查询：SID && VALUE NAME------- ---------- --------------------------------&&& 17 && && 3 db block gets&&& 17 && && 0 physical reads&&& 17 && && 4 db block changes&&& 17 && && 0 consistent changes&&& 17 && && 0 physical writes&&& 17 && && 0 physical writes non checkpoint&&& 17 && && 0 physical reads direct&&& 17 && && 0 physical writes direct&&& 17 && && 0 physical reads direct (lob)&&& 17 && && 0 physical writes direct (lob)在scott session 17，下运行select * from emp 后，在另外一个用户下查询：&&& SID && VALUE NAME-------- ---------- --------------------------------&& 17 && && 3 db block gets&& 17 && && 0 physical reads&& 17 && && 5 db block changes&& 17 && && 28 consistent changes&& 17 && && 0 physical writes&& 17 && && 0 physical writes non checkpoint&& 17 && && 0 physical reads direct&& 17 && && 0 physical writes direct&& 17 && && 0 physical reads direct (lob)&& 17 && && 0 physical writes direct (lob)再次在scott session 17，下运行select * from emp 后，在另外一个用户下查询：&& SID && VALUE NAME----- ---------- ---------------------------------17 && && 3 db block gets17 && && 0 physical reads17 && && 6 db block changes17 && && 56 consistent changes17 && && 0 physical writes17 && && 0 physical writes non checkpoint17 && && 0 physical reads direct17 && && 0 physical writes direct17 && && 0 physical reads direct (lob)17 && && 0 physical writes direct (lob)在此在scott sid = 11的同一个session下运行 在另外一个用户下查询：SID && VALUE NAME------ ---------- ------------------------------11 && && 89 db block gets11 && && 0 physical reads11 && &&& 118 db block changes11 && && 0 consistent changes11 && && 0 physical writes11 && && 0 physical writes non checkpoint11 && && 0 physical reads direct11 && && 0 physical writes direct11 && && 0 physical reads direct (lob)11 && && 0 physical writes direct (lob)再次在scott sid = 11的同一个session下运行update emp set comm = 10; 在另外一个用户下查询：SID && VALUE NAME---- ---------- --------------------------------&& 11 && &&& 104 db block gets&& 11 && && 0 physical reads&& 11 && &&& 147 db block changes&& 11 && && 0 consistent changes&& 11 && && 0 physical writes&& 11 && && 0 physical writes non checkpoint&& 11 && && 0 physical reads direct&& 11 && && 0 physical writes direct&& 11 && && 0 physical reads direct (lob)&& 11 && && 0 physical writes direct (lob)再次在scott sid = 11的同一个session下运行 在另外一个用户下查询：SID && VALUE NAME---- ---------- ------------------------------&& 11 && &&& 105 db block gets&& 11 && && 0 physical reads&& 11 && &&& 148 db block changes&& 11 && && 0 consistent changes&& 11 && && 0 physical writes&& 11 && && 0 physical writes non checkpoint&& 11 && && 0 physical reads direct&& 11 && && 0 physical writes direct&& 11 && && 0 physical reads direct (lob)&& 11 && && 0 physical writes direct (lob)经过初步试验，发现如果开始运行select * from emp后，然后再运行select * from emp where empno = 7902, 不管运行多少此，都不会引起physical reads与db block gets的增加。因为db block gets是在current mode模式中产生的。而是只会引起session logical reads与index fetch by key、consistent gets的增加。如运行select sid,value,name from v$sesstat x,v$statname ywhere x.statistic#=y.statistic#and ( name like '%db block%change%' or name like '%db block%get%'or name like '%consistent%change%' or name like '%physical reads%'or name like '%physical writes%' or name like '%scans%'or name = 'index fetch by key' or name like '%read%')and sid = 11 and value & 0order by value查询后，得到：SID && VALUE NAME---- ---------- -------------------------------&& 11 && && 3 db block gets&& 11 && && 4 db block changes&& 11 && && 4 index scans kdiixs1&& 11 && && 5 index fetch by key&& 11 && && 6 table scans (short tables)&& 11 && && 8 no work - consistent read gets&& 11 && && 42 session logical reads将数据库关闭，重新启动后，重新用scott联接，sid = 12立即查询统计信息，得到：SID && VALUE NAME---- ---------- -------------------------------&& 12 && && 6 db block gets&& 12 && && 6 table scans (short tables)&& 12 && && 8 db block changes&& 12 && && 53 cluster key scans&& 12 && && 89 index fetch by key&& 12 && &&& 145 physical reads&& 12 && &&& 163 index scans kdiixs1&& 12 && &&& 337 consistent gets - examination&& 12 && &&& 423 no work - consistent read gets&& 12 && &&& 945 consistent gets&& 12 && &&& 951 session logical reads在sid =12 session中运行select * from emp where empno = 7902;后，得到统计信息：SID && VALUE NAME---- ---------- -------------------------------&& 12 && && 6 db block gets&& 12 && && 6 table scans (short tables)&& 12 && && 8 db block changes&& 12 && && 60 cluster key scans&& 12 && && 98 index fetch by key&& 12 && &&& 150 physical reads&& 12 && &&& 168 index scans kdiixs1&& 12 && &&& 360 consistent gets - examination&& 12 && &&& 439 no work - consistent read gets&& 12 && &&& 990 consistent gets&& 12 && &&& 996 session logical reads再次运行select *则db block gets与physical reads不发生变化将数据库关闭，重新启动后，重新用scott联接，sid = 12立即查询统计信息，得到：SID && VALUE NAME---- ---------- --------------------------------&& 12 && && 6 db block gets&& 12 && && 6 table scans (short tables)&& 12 && && 8 db block changes&& 12 && && 53 cluster key scans&& 12 && && 89 index fetch by key&& 12 && &&& 145 physical reads&& 12 && &&& 163 index scans kdiixs1&& 12 && &&& 337 consistent gets - examination&& 12 && &&& 423 no work - consistent read gets&& 12 && &&& 945 consistent gets&& 12 && &&& 951 session logical reads在sid =12 session中运行select *后，得到统计信息：SID && VALUE NAME--- ---------- -------------------------------12 && && 6 db block gets12 && && 7 table scans (short tables)12 && && 8 db block changes12 && && 60 cluster key scans12 && && 97 index fetch by key12 && &&& 149 physical reads12 && &&& 168 index scans kdiixs112 && &&& 358 consistent gets - examination12 && &&& 441 no work - consistent read gets12 && &&& 992 consistent gets12 && &&& 998 session logical reads再次运行select *则db block gets与physical reads不发生变化
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：153449次
积分：2158
积分：2158
排名：第12160名
原创：35篇
转载：101篇
评论：70条
(1)(1)(3)(11)(3)(1)(1)(2)(1)(8)(5)(4)(1)(1)(1)(3)(2)(2)(2)(11)(6)(18)(7)(15)(8)(2)(3)(1)(6)(4)(4)