ITPub博客

--关于SQL*Net message from client or SQL*Net more data from client一，第一个原因就是网络存在问题导致客户端和DBMS之间的网络通信存在问题，这里不过多讨论。二，SQL执行次数异常高导致的情况。[@more@] 执行次数过多，客户端和DBMS间的网络通信频繁地发生，因此网络相关的等待时间可能会延长。这时Oracle需要等待从客户端发送的响应， 所以等待QL*Net message from client or SQL*Net more data from client,如果整个等待时间中，SQL*Net more data from client 占据着相当比重的等待时间，就可以怀疑过多的执行次数引起的

关于多个会话引起唯一键冲突发生唯一键冲突时会发生TX锁争用，进程a执行insert后，若进程b执行insert会引发唯一键冲突，进程b要以shared 模式获取TX锁，发生等待，进程b会等到进程a提交或者回滚为止，若进程a上完成提交，则b上出现ora-0001。若进程a完成了回滚，则进程b的insert成功完成。Session A:[@more@]--关于多个会话引起唯一键冲突发生唯一键冲突时会发生TX锁争用，进程a执行insert后，若进程b执行insert会引发唯一键冲突，进程b要以shared 模式获取TX锁，发生等待，进程b会等到进程a提交或者回滚为止，若进程a上完成提交，则b上出

*Tree索引的叶节点以排序形式存储索引条目，每个索引条目指向各自的一个Rowid，所以唯一键冲突外，索引条目之间不发生争用。而Bitmap index的叶子节点具有‘Column+Start rowid+End rowid+bitmap’的结构。所以，一个叶节点管理大范围的Rowid。当建有[@more@]Bitmap index的表被修改时，对位图索引相应的列值每次都要重新计算行所属叶子节点的位图。因而，如果两个会话同时对相同的叶节点执行位图运算时，为了保障顺序，要获取TX锁。如果特定会话以Exclusive模式获得TX锁后，执行了位图运算，但没有commit，则其它会话以Shared模式获取TX锁

关于shared pool latch，它起到保护共享池堆结构的作用，为了查找到共享池中的free chunk，检索空闲列，分配适当的chunk都只能在获得shared pool latch后才能操作。比如hard parse，一条sql解析的时候要分配空间用来存储sql statement等信息。当多个session同事分配chunk时，为了获得shared pool latch就会发生争用。另外，hard parse严重时，会发生大量的分割chunk的现象，导致共享池碎片化。会延长在空闲列上查找chunk的时间，导致shared pool latch竞争。11g里面shared pool有很多组件，主要的还是包括sql area，library cahce，dictio

要描述下修改行的过程，便于理解buffer busy wait。1.为了查找要修改的行相应的块存在的位置，请求cache buffer chains latch。2.对载入块的缓冲区请求buffer block，释放cache buffer chains latch。3.请求tx锁，有则修改行，未得到tx锁，则释放buffer lock。4.修改行释放buffer block。---测试select引起的buffer lock---创建测试环境create tablespace bfw_tablespace datafile'/opt/app/oracle/oradata/liqian/bfw_tablespace.dbf'size 50M autoextend on extent management local uniform size 1M[@more@]segment space management a

对与DML操作oracle在内部按如下顺序执行：1，相应事务分配回滚段(undo segment).2,分配回滚段后，在回滚段头上创建事务表slot(transaction table slot).ROWID FNO BLKNO------------------ ---------- ----------AAAQ+LAAEAAAAAfAAA 4 31file number是4，block number是31，dump 这个block。[@more@]对与DML操作oracle在内部按如下顺序执行：1，相应事务分配回滚段(undo segment).2,分配回滚段后，在回滚段头上创建事务表slot(transaction table slot).3.创建事务表后会生出TXID(TransactionID

库高速缓存的基本结构是hash table-bucket-chain-handle-object。oracle对库缓存中的对象生成hash函数，对相同hash值的对象分配bucket，并且通过chain来管理[@more@]库高速缓存的基本结构是hash table-bucket-chain-handle-object。oracle对库缓存中的对象生成hash函数，对相同hash值的对象分配bucket，并且通过chain来管理。也存在一个library cache handle(句柄)来管理library chache object(LCO)。handle里面包含library cache object的元数据和指针等信息。library cache object实际包含一下及部分信息：1.dependency table:当前LCO依

先看个SQL:SQL> set pagesize 200SQL> set linesize 400SQL> col plan_table_output for a200SQL> explain plan for[@more@]SQL> set pagesize 200SQL> set linesize 400SQL> col plan_table_output for a200SQL> explain plan for 2 SELECT /*+ PARALLEL(4) */ customers.cust_first_name, customers.cust_last_name, 3 MAX(QUANTITY_SOLD), AVG(QUANTITY_SOLD) 4 FROM sales, customers 5 WHERE sales.cust_id=customers.cust_id 6 GROUP BY customers.cust_first_name, customers.cust_last_name

SQL语句执行的几个步骤：1.parsing 解析 2.optimization 优化 3.row source generation 产生行源4.execution 执行[@more@]SQL语句执行的几个步骤：1.parsing 解析 2.optimization 优化 3.row source generation 产生行源4.execution 执行首先SQL语句必须被解析并且被放到library cache。SQL解析包括一下步骤：1.语法检查，检查sql语句的语法正确性，比如from不能是form等。2.语义检查，包括引用object的有效性，验证用户权限等。3.共享池检查，对于每一条sql语句数据库用hash算法产生已个hash value，也就是v$sql中sql_id.当用户提交一条s

行预取(Row Prefetching)，当客户端从数据库获取数据的时候，可以一行一行的读取，也可以同时读取多行。[@more@]行预取(Row Prefetching)，当客户端从数据库获取数据的时候，可以一行一行的读取，也可以同时读取多行。每次客户端请求从数据库返回1条记录的时候，会预取多条记录并将它们存储在客户端的内存中，这样可以减少数据库调用读取数据的次数，降低网络传输次数，提高效率。SQL*PLUS中，通过系统变量arraysize管理行预取行数。默认值是15.行预取对数据访问产生的逻辑读影响是非常大的，看下面的例子。SYS@lipei> select num_rows

/*绑定变量对执行计划的影响及隐式转换对索引的影响探索There are three things to keep in mind about using EXPLAIN PLAN that make it susceptible to producing plan output that won’t match the actual execution plan:1.EXPLAIN PLAN produces plans based on the environment at the moment you use it.2.EXPLAIN PLAN doesn’t consider the datatype of bind variables (all binds are VARCHAR2).3.EXPLAIN PLAN doesn’t “peek” at bind variable values.[@more@]/*绑定变量对执行计划的影响及隐式转换对索引的影响探索Ther

Historically it has been common practice to say that a good index has a low clustering_factor, and a badindex has a high clustering_factor.There is obviously a degree of truth in this comment, especially in the light of what the clustering_factorrepresents.[@more@]However, I have always had an aversion to words like low, high, small, large, and expressions like closeto zero, when talking about Oracle. After all, is 10,000 a low clustering_factor or a high clustering_factor? It’s low if you have