<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
  <channel>
    <title>HelloDBA</title>
    <link>http://www.hellodba.com/blog/index.php</link>
    <description><![CDATA[--- 结束 ---]]></description>
    <copyright>Copyright 2009, Fuyuncat</copyright>
    <managingEditor>Fuyuncat</managingEditor>
    <language>zh-CN</language>
    <generator>HelloDBA</generator>
    <item>
      <title><![CDATA[Oracle 11g 直接IO自动调节]]></title>
      <link>http://www.HelloDBA.com/reader.php?ID=187&amp;lang=cn</link>
      <description><![CDATA[通常来说，直接IO的效率比读入缓存的效率更高，因为它不需要分配内存。在11g中，Oracle有了一个新的特性————直接IO自动调节。它可以基于对象大小、Buffer Cache的大小等条件自动决定是否直接读取数据块。]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.HelloDBA.com/reader.php?ID=187&amp;lang=cn</guid>
      <author>fuyuncat</author>
      <pubDate>Wed, 04 Jan 2012 05:25:31 GMT</pubDate>
      <comments>http://www.HelloDBA.com/reader.php?ID=187&amp;lang=cn</comments>
    </item>
    <item>
      <title><![CDATA[Oracle 11g Direct IO Auto Tune]]></title>
      <link>http://www.HelloDBA.com/reader.php?ID=187&amp;lang=en</link>
      <description><![CDATA[Generally, Direct IO faster than Read into Cache because it does not require to allocate memory. In 11g, Oracle intruduced a new feature --- Direct IO Auto Tuning --- to improve performance of reading/writing large size objects. It will determine whether to read data blocks directly from disk bypassing buffer cache or not, basing on the size of object and size of buffer cache.]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.HelloDBA.com/reader.php?ID=187&amp;lang=en</guid>
      <author>fuyuncat</author>
      <pubDate>Wed, 04 Jan 2012 05:25:31 GMT</pubDate>
      <comments>http://www.HelloDBA.com/reader.php?ID=187&amp;lang=cn</comments>
    </item>
    <item>
      <title><![CDATA[小表临界值测试]]></title>
      <link>http://www.HelloDBA.com/reader.php?ID=186&amp;lang=cn</link>
      <description><![CDATA[我们知道，参数"_small_table_threshold"决定了一个表是否是小表。对于大表而言，在LRU算法中，从其读取的数据块会被放置在LRU链表上不同于小表数据块的位置；而在执行一些大数据量的操作时，如并行查询、直接载入等，大表的数据块是绕过缓存直接从磁盘读取的。]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.HelloDBA.com/reader.php?ID=186&amp;lang=cn</guid>
      <author>fuyuncat</author>
      <pubDate>Thu, 29 Dec 2011 08:53:12 GMT</pubDate>
      <comments>http://www.HelloDBA.com/reader.php?ID=186&amp;lang=cn</comments>
    </item>
    <item>
      <title><![CDATA[Test Around Small Table Threshold]]></title>
      <link>http://www.HelloDBA.com/reader.php?ID=186&amp;lang=en</link>
      <description><![CDATA[We know, the parameter "_small_table_threshold" decides a table is a small table or not. When full scan on large tables, in LRU algorithm, the data blocks will be put in a different position in LRU list other than small tables; while when performing some other data-intensive operations, such as parallel query or direct load, data blocks will be read directly from disk bypassing buffer cache.]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.HelloDBA.com/reader.php?ID=186&amp;lang=en</guid>
      <author>fuyuncat</author>
      <pubDate>Thu, 29 Dec 2011 08:53:12 GMT</pubDate>
      <comments>http://www.HelloDBA.com/reader.php?ID=186&amp;lang=cn</comments>
    </item>
    <item>
      <title><![CDATA[Oracle的排序算法]]></title>
      <link>http://www.HelloDBA.com/reader.php?ID=185&amp;lang=cn</link>
      <description><![CDATA[在进行SQL查询时，排序操作是在特定的内存中完成的，也就是排序工作区。初次进入排序区的数据是无序的，Oracle要选择一项合适的算法对这些无序数据进行排序。
10g之前，由于内存的限制，使得Oracle选择了以个效率不高的排序算法；而随着10g中内存管理方法的大幅改进，Oracle引入了新的排序算法。]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.HelloDBA.com/reader.php?ID=185&amp;lang=cn</guid>
      <author>fuyuncat</author>
      <pubDate>Wed, 16 Nov 2011 08:30:02 GMT</pubDate>
      <comments>http://www.HelloDBA.com/reader.php?ID=185&amp;lang=cn</comments>
    </item>
    <item>
      <title><![CDATA[Oracle Sorting Algorithm]]></title>
      <link>http://www.HelloDBA.com/reader.php?ID=185&amp;lang=en</link>
      <description><![CDATA[Sorting operation is completed in special memory, e.g. sorting work area, when execute SQL query. Data is unsorted when put into this area initially. Oracle should choose an appropriate sorting algorithm to sort them.
Limited by working area size, oracle chose an inefficient algorithm; While introduced a new sorting algorithm due to innovation of memory management.]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.HelloDBA.com/reader.php?ID=185&amp;lang=en</guid>
      <author>fuyuncat</author>
      <pubDate>Wed, 16 Nov 2011 08:30:02 GMT</pubDate>
      <comments>http://www.HelloDBA.com/reader.php?ID=185&amp;lang=cn</comments>
    </item>
    <item>
      <title><![CDATA[Oracle 11g中基于哈希算法对唯一值数（NDV）的估算]]></title>
      <link>http://www.HelloDBA.com/reader.php?ID=184&amp;lang=cn</link>
      <description><![CDATA[字段的统计数据是CBO优化器估算执行计划代价的重要依据。字段的统计数据可以分为两类：概要统计数据（如NDV、字段平均长度ACL、最大、最小值等）和柱状图数据。对于第一类数据，实际上可以通过一次扫描表获取所有字段的统计数据。但是，对于大型表的分析，为减少资源消耗，需要通过采样分析。由于采样具有随机性，对于一些数据分布不均匀的字段，通过采样数据获取统计数据可能会导致获取到的数据与实际数据产生较大差异。而如果增加采样比以提高精度的话，对于NDV的估算会导致PGA的大量消耗。在11g中，Oracle引入了基于哈希算法的估计方法，使得扫描数据量不再导致PGA消耗的线性增加，从而使得全表扫描来获得这类统计数据成为可能。]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.HelloDBA.com/reader.php?ID=184&amp;lang=cn</guid>
      <author>fuyuncat</author>
      <pubDate>Thu, 15 Sep 2011 04:39:58 GMT</pubDate>
      <comments>http://www.HelloDBA.com/reader.php?ID=184&amp;lang=cn</comments>
    </item>
    <item>
      <title><![CDATA[Approximate NDV based on hash algorithm in Oracle 11g]]></title>
      <link>http://www.HelloDBA.com/reader.php?ID=184&amp;lang=en</link>
      <description><![CDATA[Column statistics data is an important factor for CBO to estimate cost of execution plan. There are generally two kinds of statistics data on columns, one is the synopses, such as NDV, ACL and maximum/minimum data; the other is histogram. A single scanning table can get those synopses. To analyze the large tables with low cost, we normally sampling the data. However, sampling is a random process, which will cause large gap between statistics and actual data. Increasing sampling size will increase accuracy, but will also increase PGA consumption to get NDV. In 11g, Oracle introduced a new algorithm based on hash. It will not require more PGA with scanning data increased.]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.HelloDBA.com/reader.php?ID=184&amp;lang=en</guid>
      <author>fuyuncat</author>
      <pubDate>Thu, 15 Sep 2011 04:39:58 GMT</pubDate>
      <comments>http://www.HelloDBA.com/reader.php?ID=184&amp;lang=cn</comments>
    </item>
    <item>
      <title><![CDATA[DISTINCT聚集函数转换]]></title>
      <link>http://www.HelloDBA.com/reader.php?ID=183&amp;lang=cn</link>
      <description><![CDATA[在Oracle 10gR2中，引入了哈希分组的方法来计算聚集函数，在数据量比较大时，这种方法比传统的排序分组方法效率更高。但是，对于那些对唯一值（含有DISTINCT/UNIQUE）的聚集函数，由于要消除重复值，因此还是要使用排序分组的方法。在11gR2，引入了一项新的查询转换技术，将含有DISTINCT的聚集函数转换为一个聚集内联视图，使得查询同样可以利用哈希分组的方法来计算聚集函数。]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.HelloDBA.com/reader.php?ID=183&amp;lang=cn</guid>
      <author>fuyuncat</author>
      <pubDate>Wed, 31 Aug 2011 02:43:30 GMT</pubDate>
      <comments>http://www.HelloDBA.com/reader.php?ID=183&amp;lang=cn</comments>
    </item>
    <item>
      <title><![CDATA[Distinct Aggregate Transformation]]></title>
      <link>http://www.HelloDBA.com/reader.php?ID=183&amp;lang=en</link>
      <description><![CDATA[Hash Group Aggregate was introduced in Oracle 11gR2. It's generally more efficient than the traditional aggregate method, Sort Group Aggregate, especially when compute much of data. However, for those functions with DISTINCT/UNIQUE keyword, for the sake of eliminating duplicated values, it should still adopt the traditional method. While in 11gR2, a new query transformation technical, Distinct Aggregate Transformation, was introduced. It can transform the aggregate functions on DISTINCT data to an aggregate inline view, which can benefit from Hash Group Aggregate.]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.HelloDBA.com/reader.php?ID=183&amp;lang=en</guid>
      <author>fuyuncat</author>
      <pubDate>Wed, 31 Aug 2011 02:43:30 GMT</pubDate>
      <comments>http://www.HelloDBA.com/reader.php?ID=183&amp;lang=cn</comments>
    </item>
    <item>
      <title><![CDATA[FyDB成为开源项目]]></title>
      <link>http://www.HelloDBA.com/reader.php?ID=182&amp;lang=cn</link>
      <description><![CDATA[FyDB成为开源项目，项目主页：https://sourceforge.net/p/fydb/home/

如果你有兴趣加入该项目，请联系：fuyuncat@gmail.com]]></description>
      <category>下载</category>
      <guid isPermaLink="true">http://www.HelloDBA.com/reader.php?ID=182&amp;lang=cn</guid>
      <author>fuyuncat</author>
      <pubDate>Tue, 09 Aug 2011 05:29:19 GMT</pubDate>
      <comments>http://www.HelloDBA.com/reader.php?ID=182&amp;lang=cn</comments>
    </item>
    <item>
      <title><![CDATA[FyDB becomes  an open source project]]></title>
      <link>http://www.HelloDBA.com/reader.php?ID=182&amp;lang=en</link>
      <description><![CDATA[FyDB opens source, now. 

If you want to join this project, please contact me by: fuyuncat@gmail.com]]></description>
      <category>下载</category>
      <guid isPermaLink="true">http://www.HelloDBA.com/reader.php?ID=182&amp;lang=en</guid>
      <author>fuyuncat</author>
      <pubDate>Tue, 09 Aug 2011 05:29:19 GMT</pubDate>
      <comments>http://www.HelloDBA.com/reader.php?ID=182&amp;lang=cn</comments>
    </item>
    <item>
      <title><![CDATA[空还是非空——浅谈非空约束对执行计划以及性能的影响]]></title>
      <link>http://www.HelloDBA.com/reader.php?ID=181&amp;lang=cn</link>
      <description><![CDATA[非空约束是字段的一个重要属性。但是，很多时候，数据库表的设计人员似乎并不十分在意这个属性。最常见的现象就是，除了主键字段外，所有字段都不指定该属性。而在Oracle中，默认是允许为空。
而实际上，优化器在选择执行计划时，非空约束是一个重要的影响因素。为了说明问题，我们建立以下测试表，然后分别说明非空约束在各种情况下对执行计划和性能的影响。]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.HelloDBA.com/reader.php?ID=181&amp;lang=cn</guid>
      <author>fuyuncat</author>
      <pubDate>Thu, 21 Jul 2011 08:01:37 GMT</pubDate>
      <comments>http://www.HelloDBA.com/reader.php?ID=181&amp;lang=cn</comments>
    </item>
    <item>
      <title><![CDATA[NULL or NOT NULL --- NOT NULL constraint impacts on execution plan and performance]]></title>
      <link>http://www.HelloDBA.com/reader.php?ID=181&amp;lang=en</link>
      <description><![CDATA[NULLABILITY is an important property of column. However, many designers do not care naught for this property. In most scenarios, except primary key columns, all columns are not specified nullbility. By default, it's means nullable.
Actually, it's an important factor impacting optimizer choosing execution plan. Let's build below table to further describe this issue.]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.HelloDBA.com/reader.php?ID=181&amp;lang=en</guid>
      <author>fuyuncat</author>
      <pubDate>Thu, 21 Jul 2011 08:01:37 GMT</pubDate>
      <comments>http://www.HelloDBA.com/reader.php?ID=181&amp;lang=cn</comments>
    </item>
    <item>
      <title><![CDATA[FyDB --- 一个分布式内存No-SQL数据库]]></title>
      <link>http://www.HelloDBA.com/reader.php?ID=180&amp;lang=cn</link>
      <description><![CDATA[基于对传统RDMBS的关键特性的实现机制的理解，以及对目前流行的No-SQL的相关理论的探究，我制作了这个小型的数据库系统——FyDB。它支持分布式架构，以及对异构数据源的整合。FyDB数据是存储在内存中的Key-Value映射结构，同时也支持对数据的持久化。依据No-SQL理论，FyDB基本上抛弃了对数据完整性的支持以换取更好的性能和高可用性——即没有父子关系的数据的完整性检查，而数据完整性是传统关系型数据库的关键特性之一。]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.HelloDBA.com/reader.php?ID=180&amp;lang=cn</guid>
      <author>fuyuncat</author>
      <pubDate>Mon, 11 Jul 2011 00:48:21 GMT</pubDate>
      <comments>http://www.HelloDBA.com/reader.php?ID=180&amp;lang=cn</comments>
    </item>
    <item>
      <title><![CDATA[FyDB --- a distributed in-memory no-SQL DB]]></title>
      <link>http://www.HelloDBA.com/reader.php?ID=180&amp;lang=en</link>
      <description><![CDATA[Base on understanding on internal technology of traditional RDBMS's key features, as well as researching on related popular theories of No-SQL, I developed this small No-SQL DB--- FyDB. It supports distributed deployment, and can integrate heterogeneous data sources. Data of FyDB is stroed in memory as key-value structure, and it is also persistent. According to No-SQL theories, FyDB discarded support on Data Integration to gain better performance and high availability, which means it will not check integration of Parent-Children data. While Data Integration is one of the most important features of traditional relationship database.]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.HelloDBA.com/reader.php?ID=180&amp;lang=en</guid>
      <author>fuyuncat</author>
      <pubDate>Mon, 11 Jul 2011 00:48:21 GMT</pubDate>
      <comments>http://www.HelloDBA.com/reader.php?ID=180&amp;lang=cn</comments>
    </item>
    <item>
      <title><![CDATA[FyDB --- 一个分布式内存No-SQL数据库]]></title>
      <link>http://www.HelloDBA.com/reader.php?ID=180&amp;lang=cn</link>
      <description><![CDATA[基于对传统RDMBS的关键特性的实现机制的理解，以及对目前流行的No-SQL的相关理论的探究，我制作了这个小型的数据库系统——FyDB。它支持分布式架构，以及对异构数据源的整合。FyDB数据是存储在内存中的Key-Value映射结构，同时也支持对数据的持久化。依据No-SQL理论，FyDB基本上抛弃了对数据完整性的支持以换取更好的性能和高可用性——即没有父子关系的数据的完整性检查，而数据完整性是传统关系型数据库的关键特性之一。]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.HelloDBA.com/reader.php?ID=180&amp;lang=cn</guid>
      <author>fuyuncat</author>
      <pubDate>Mon, 11 Jul 2011 00:48:21 GMT</pubDate>
      <comments>http://www.HelloDBA.com/reader.php?ID=180&amp;lang=cn</comments>
    </item>
    <item>
      <title><![CDATA[FyDB --- a distributed in-memory no-SQL DB]]></title>
      <link>http://www.HelloDBA.com/reader.php?ID=180&amp;lang=en</link>
      <description><![CDATA[Base on understanding on internal technology of traditional RDBMS's key features, as well as researching on related popular theories of No-SQL, I developed this small No-SQL DB--- FyDB. It supports distributed deployment, and can integrate heterogeneous data sources. Data of FyDB is stroed in memory as key-value structure, and it is also persistent. According to No-SQL theories, FyDB discarded support on Data Integration to gain better performance and high availability, which means it will not check integration of Parent-Children data. While Data Integration is one of the most important features of traditional relationship database.]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.HelloDBA.com/reader.php?ID=180&amp;lang=en</guid>
      <author>fuyuncat</author>
      <pubDate>Mon, 11 Jul 2011 00:48:21 GMT</pubDate>
      <comments>http://www.HelloDBA.com/reader.php?ID=180&amp;lang=cn</comments>
    </item>
    <item>
      <title><![CDATA[当前模式读与一致性读（2）]]></title>
      <link>http://www.HelloDBA.com/reader.php?ID=179&amp;lang=cn</link>
      <description><![CDATA[在前一篇文章里，我用2个特殊例子描述当前模式读和一致性读之间的区别，并提到了“如在事务启动后到数据块被读取之间的这段时间内，相应的数据块发生了改变，那么可能就会有我们意想不到的事情发生”。而这样的意想不到的结果可能能被我们接受，但也可能难以被接受。]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.HelloDBA.com/reader.php?ID=179&amp;lang=cn</guid>
      <author>fuyuncat</author>
      <pubDate>Mon, 02 May 2011 22:33:09 GMT</pubDate>
      <comments>http://www.HelloDBA.com/reader.php?ID=179&amp;lang=cn</comments>
    </item>
    <item>
      <title><![CDATA[Current Mode and Consistent Gets (2)]]></title>
      <link>http://www.HelloDBA.com/reader.php?ID=179&amp;lang=en</link>
      <description><![CDATA[In previous article, I described the difference between DB Gets in Current Mode and Consistent Gets with 2 special cases, and also mentioned that 'if the data blocks were changed during the period time after TX started and before data block read, we will get unexpected result'. Regarding to those 'unexpected results', some of them may be acceptable while others may be unacceptable.]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.HelloDBA.com/reader.php?ID=179&amp;lang=en</guid>
      <author>fuyuncat</author>
      <pubDate>Mon, 02 May 2011 22:33:09 GMT</pubDate>
      <comments>http://www.HelloDBA.com/reader.php?ID=179&amp;lang=cn</comments>
    </item>
    <item>
      <title><![CDATA[当前模式读与一致性读]]></title>
      <link>http://www.HelloDBA.com/reader.php?ID=178&amp;lang=cn</link>
      <description><![CDATA[本文通过2个特殊的例子描述了当前模式读与一致性读之间的区别。]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.HelloDBA.com/reader.php?ID=178&amp;lang=cn</guid>
      <author>fuyuncat</author>
      <pubDate>Mon, 02 May 2011 19:55:10 GMT</pubDate>
      <comments>http://www.HelloDBA.com/reader.php?ID=178&amp;lang=cn</comments>
    </item>
    <item>
      <title><![CDATA[Current Mode and Consistent Gets]]></title>
      <link>http://www.HelloDBA.com/reader.php?ID=178&amp;lang=en</link>
      <description><![CDATA[The paper described difference between Current Mode and Consistent Gets with 2 special cases.]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.HelloDBA.com/reader.php?ID=178&amp;lang=en</guid>
      <author>fuyuncat</author>
      <pubDate>Mon, 02 May 2011 19:55:10 GMT</pubDate>
      <comments>http://www.HelloDBA.com/reader.php?ID=178&amp;lang=cn</comments>
    </item>
    <item>
      <title><![CDATA[select for update 与性能]]></title>
      <link>http://www.HelloDBA.com/reader.php?ID=177&amp;lang=cn</link>
      <description><![CDATA[select for update是用于数据并发控制的语句。执行该语句后，会在表上加持RX锁（Row Exclusive,10gR1之前是Row Share锁），在被选中记录上加行锁。但是，正是因为其加锁的操作，for update子句会导致select查询的性能下降。]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.HelloDBA.com/reader.php?ID=177&amp;lang=cn</guid>
      <author>fuyuncat</author>
      <pubDate>Thu, 13 Jan 2011 00:26:47 GMT</pubDate>
      <comments>http://www.HelloDBA.com/reader.php?ID=177&amp;lang=cn</comments>
    </item>
    <item>
      <title><![CDATA[Select For Update and performance]]></title>
      <link>http://www.HelloDBA.com/reader.php?ID=177&amp;lang=en</link>
      <description><![CDATA["select for update" is used for concurrent data access control. Once executed such SQL, oracle will hold a RX (Row Exclusive, RS in 9i instead) lock on the table, and hold Row Lock on those selected rows. However, such lock holding operation degrades the performance of the statement.]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.HelloDBA.com/reader.php?ID=177&amp;lang=en</guid>
      <author>fuyuncat</author>
      <pubDate>Thu, 13 Jan 2011 00:26:47 GMT</pubDate>
      <comments>http://www.HelloDBA.com/reader.php?ID=177&amp;lang=cn</comments>
    </item>
    <item>
      <title><![CDATA[Oracle 内部函数调用追踪器 for windows(32)]]></title>
      <link>http://www.HelloDBA.com/reader.php?ID=6&amp;lang=cn</link>
      <description><![CDATA[基于以前开发的一个用于监控线程的CPU使用状况的小工具，TopShow，我开发了一个用于追踪Oracle内部函数调用的追踪器——OraTracer. 你可以用该工具追踪监控Oracle多个内部函数的调用情况，还可以尝试探测函数的输入参数的值，也可以打印追踪点被触发时的调用堆栈。追踪可以设置在整个Oracle进程的级别，也可以设置在某个线程以追踪特定的会话。]]></description>
      <category>下载</category>
      <guid isPermaLink="true">http://www.HelloDBA.com/reader.php?ID=6&amp;lang=cn</guid>
      <author>fuyuncat</author>
      <pubDate>Fri, 28 May 2010 00:23:50 GMT</pubDate>
      <comments>http://www.HelloDBA.com/reader.php?ID=6&amp;lang=cn</comments>
    </item>
    <item>
      <title><![CDATA[An Oracle Call Tracer For Windows(32)]]></title>
      <link>http://www.HelloDBA.com/reader.php?ID=6&amp;lang=en</link>
      <description><![CDATA[Base on the my windows threads top CPU usage tool, TopShow, I built another tool, OraTracer, a simple oracle call tracer. You can use this tool to set multiple trace points for known oracle internal calls. And it will log the calling with detected arguments, call stacks corresponding to the trace point setting. The trace could be set in process level or thread level.]]></description>
      <category>下载</category>
      <guid isPermaLink="true">http://www.HelloDBA.com/reader.php?ID=6&amp;lang=en</guid>
      <author>fuyuncat</author>
      <pubDate>Fri, 28 May 2010 00:23:50 GMT</pubDate>
      <comments>http://www.HelloDBA.com/reader.php?ID=6&amp;lang=cn</comments>
    </item>
    <item>
      <title><![CDATA[Oracle 内部函数调用追踪器 for windows(32)]]></title>
      <link>http://www.HelloDBA.com/reader.php?ID=6&amp;lang=cn</link>
      <description><![CDATA[基于以前开发的一个用于监控线程的CPU使用状况的小工具，TopShow，我开发了一个用于追踪Oracle内部函数调用的追踪器——OraTracer. 你可以用该工具追踪监控Oracle多个内部函数的调用情况，还可以尝试探测函数的输入参数的值，也可以打印追踪点被触发时的调用堆栈。追踪可以设置在整个Oracle进程的级别，也可以设置在某个线程以追踪特定的会话。]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.HelloDBA.com/reader.php?ID=6&amp;lang=cn</guid>
      <author>fuyuncat</author>
      <pubDate>Fri, 28 May 2010 00:23:50 GMT</pubDate>
      <comments>http://www.HelloDBA.com/reader.php?ID=6&amp;lang=cn</comments>
    </item>
    <item>
      <title><![CDATA[An Oracle Call Tracer For Windows(32)]]></title>
      <link>http://www.HelloDBA.com/reader.php?ID=6&amp;lang=en</link>
      <description><![CDATA[Base on the my windows threads top CPU usage tool, TopShow, I built another tool, OraTracer, a simple oracle call tracer. You can use this tool to set multiple trace points for known oracle internal calls. And it will log the calling with detected arguments, call stacks corresponding to the trace point setting. The trace could be set in process level or thread level.]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.HelloDBA.com/reader.php?ID=6&amp;lang=en</guid>
      <author>fuyuncat</author>
      <pubDate>Fri, 28 May 2010 00:23:50 GMT</pubDate>
      <comments>http://www.HelloDBA.com/reader.php?ID=6&amp;lang=cn</comments>
    </item>
    <item>
      <title>Look Oracle from inside (tracing internal calls) --- Latches</title>
      <link>http://www.hellodba.com/Doc/Look_Oracle_from_inside_4_en.html</link>
      <description><![CDATA[    Oracle provided many method for us to understand its behaviors, help us to manage and improve it. Such as execution plan, statistics data, dynamic views, and even the events trace and dumping. However, as a DBA, we always want to get more informations to find its secrets, operation details. For example, when we tuning a SQL, we will get the consistent gets (Logical IOs) as an important performance reference. However, sometimes such figure may confuse us. why the logical IOs number is so high eventhough it scans an empty table? Why we get so many logical IOs even it hited index? ... In such scenario, we will want to know what the exact data blocks it got. But this is the Oracle internal behaviors, it did not provide any method to look into it. Now, let's change our view, look it from oracle inside. As we know, all of operations are finally implemented by oracle internal functions. If we can find such functions and trace their calling, we will get what we want. In unix/linux, there are several utilities to trace the call stack, such as pstack. ORADEBUG can also dump the call stacks. But such result may not enough for us. In windows (32), I built a tool (OraTracer) to trace special functions, try to detect their arguments. I will use it get the information we interested in.
]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.hellodba.com/Doc/Look_Oracle_from_inside_4_en.html</guid>
      <author>fuyuncat</author>
      <pubDate>Tue, 15 Jun 2010 06:54:07 GMT</pubDate>
      <comments>http://www.hellodba.com/Doc/Look_Oracle_from_inside_4_en.html</comments>
    </item>
    <item>
      <title>Look Oracle from inside (tracing internal calls) --- Lock (Enqueue)</title>
      <link>http://www.hellodba.com/Doc/Look_Oracle_from_inside_3_en.html</link>
      <description><![CDATA[    Oracle provided many method for us to understand its behaviors, help us to manage and improve it. Such as execution plan, statistics data, dynamic views, and even the events trace and dumping. However, as a DBA, we always want to get more informations to find its secrets, operation details. For example, when we tuning a SQL, we will get the consistent gets (Logical IOs) as an important performance reference. However, sometimes such figure may confuse us. why the logical IOs number is so high eventhough it scans an empty table? Why we get so many logical IOs even it hited index? ... In such scenario, we will want to know what the exact data blocks it got. But this is the Oracle internal behaviors, it did not provide any method to look into it. Now, let's change our view, look it from oracle inside. As we know, all of operations are finally implemented by oracle internal functions. If we can find such functions and trace their calling, we will get what we want. In unix/linux, there are several utilities to trace the call stack, such as pstack. ORADEBUG can also dump the call stacks. But such result may not enough for us. In windows (32), I built a tool (OraTracer) to trace special functions, try to detect their arguments. I will use it get the information we interested in.
]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.hellodba.com/Doc/Look_Oracle_from_inside_3_en.html</guid>
      <author>fuyuncat</author>
      <pubDate>Fri, 11 Jun 2010 07:41:48 GMT</pubDate>
      <comments>http://www.hellodba.com/Doc/Look_Oracle_from_inside_3_en.html</comments>
    </item>
    <item>
      <title>Look Oracle from inside (tracing internal calls) --- Logical IOs</title>
      <link>http://www.hellodba.com/Doc/Look_Oracle_from_inside_2_en.html</link>
      <description><![CDATA[    Oracle provided many method for us to understand its behaviors, help us to manage and improve it. Such as execution plan, statistics data, dynamic views, and even the events trace and dumping. However, as a DBA, we always want to get more informations to find its secrets, operation details. For example, when we tuning a SQL, we will get the consistent gets (Logical IOs) as an important performance reference. However, sometimes such figure may confuse us. why the logical IOs number is so high eventhough it scans an empty table? Why we get so many logical IOs even it hited index? ... In such scenario, we will want to know what the exact data blocks it got. But this is the Oracle internal behaviors, it did not provide any method to look into it. Now, let's change our view, look it from oracle inside. As we know, all of operations are finally implemented by oracle internal functions. If we can find such functions and trace their calling, we will get what we want. In unix/linux, there are several utilities to trace the call stack, such as pstack. ORADEBUG can also dump the call stacks. But such result may not enough for us. In windows (32), I built a tool (OraTracer) to trace special functions, try to detect their arguments. I will use it get the information we interested in.
]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.hellodba.com/Doc/Look_Oracle_from_inside_2_en.html</guid>
      <author>fuyuncat</author>
      <pubDate>Thu, 10 Jun 2010 05:43:58 GMT</pubDate>
      <comments>http://www.hellodba.com/Doc/Look_Oracle_from_inside_2_en.html</comments>
    </item>
    <item>
      <title>Look Oracle from inside (tracing internal calls) --- Execution Plan</title>
      <link>http://www.hellodba.com/Doc/Look_Oracle_from_inside_1_en.html</link>
      <description><![CDATA[    Oracle provided many method for us to understand its behaviors, help us to manage and improve it. Such as execution plan, statistics data, dynamic views, and even the events trace and dumping. However, as a DBA, we always want to get more informations to find its secrets, operation details. For example, when we tuning a SQL, we will get the consistent gets (Logical IOs) as an important performance reference. However, sometimes such figure may confuse us. why the logical IOs number is so high eventhough it scans an empty table? Why we get so many logical IOs even it hited index? ... In such scenario, we will want to know what the exact data blocks it got. But this is the Oracle internal behaviors, it did not provide any method to look into it. Now, let's change our view, look it from oracle inside. As we know, all of operations are finally implemented by oracle internal functions. If we can find such functions and trace their calling, we will get what we want. In unix/linux, there are several utilities to trace the call stack, such as pstack. ORADEBUG can also dump the call stacks. But such result may not enough for us. In windows (32), I built a tool (OraTracer) to trace special functions, try to detect their arguments. I will use it get the information we interested in.
]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.hellodba.com/Doc/Look_Oracle_from_inside_1_en.html</guid>
      <author>fuyuncat</author>
      <pubDate>Wed, 09 Jun 2010 03:52:11 GMT</pubDate>
      <comments>http://www.hellodba.com/Doc/Look_Oracle_from_inside_1_en.html</comments>
    </item>
    <item>
      <title>OraTracer upgrade</title>
      <link>http://www.hellodba.com/Download/OraTracer_upgrade.htm</link>
      <description><![CDATA[New Features:
  Flexible function parameters setting;
  Disassembling to ASM code;]]></description>
      <category>下载</category>
      <guid isPermaLink="true">http://www.hellodba.com/Download/OraTracer_upgrade.htm</guid>
      <author>fuyuncat</author>
      <pubDate>Tue, 01 Jun 2010 08:27:13 GMT</pubDate>
      <comments>http://www.hellodba.com/Download/OraTracer_upgrade.htm</comments>
    </item>
    <item>
      <title>An Oracle Call Tracer For Windows(32)</title>
      <link>http://www.hellodba.com/Download/OraTracer_en.html</link>
      <description><![CDATA[Base on the my windows threads top CPU usage tool, TopShow, I built another tool, OraTracer, a simple oracle call tracer. You can use this tool to set multiple trace points for known oracle internal calls. And it will log the calling with detected arguments, call stacks corresponding to the trace point setting. The trace could be set in process level or thread level.]]></description>
      <category>下载</category>
      <guid isPermaLink="true">http://www.hellodba.com/Download/OraTracer_en.html</guid>
      <author>fuyuncat</author>
      <pubDate>Fri, 28 May 2010 08:23:50 GMT</pubDate>
      <comments>http://www.hellodba.com/Download/OraTracer_en.html</comments>
    </item>
    <item>
      <title>Oracle 内部函数调用追踪器 for windows(32)</title>
      <link>http://www.hellodba.com/Download/OraTracer_cn.html</link>
      <description><![CDATA[基于以前开发的一个用于监控线程的CPU使用状况的小工具，TopShow，我开发了一个用于追踪Oracle内部函数调用的追踪器——OraTracer. 你可以用该工具追踪监控Oracle多个内部函数的调用情况，还可以尝试探测函数的输入参数的值，也可以打印追踪点被触发时的调用堆栈。追踪可以设置在整个Oracle进程的级别，也可以设置在某个线程以追踪特定的会话。]]></description>
      <category>下载</category>
      <guid isPermaLink="true">http://www.hellodba.com/Download/OraTracer_cn.html</guid>
      <author>fuyuncat</author>
      <pubDate>Fri, 28 May 2010 08:15:50 GMT</pubDate>
      <comments>http://www.hellodba.com/Download/OraTracer_cn.html</comments>
    </item>
    <item>
      <title>Query Execution Call Stack Trace</title>
      <link>http://www.hellodba.com/Doc/Query_Execution_Call_stack_trace.html</link>
      <description><![CDATA[As we know, an execution plan decides the functions that access data / generate row source / process row sources. With tracing the call stacks, we can find the internal funcions mapping to execution plan operations.
]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.hellodba.com/Doc/Query_Execution_Call_stack_trace.html</guid>
      <author>fuyuncat</author>
      <pubDate>Wed, 12 May 2010 09:54:07 GMT</pubDate>
      <comments>http://www.hellodba.com/Doc/Query_Execution_Call_stack_trace.html</comments>
    </item>
    <item>
      <title>执行计划(Execution Plan)过程分析</title>
      <link>http://www.hellodba.com/Doc/Execution_Plan_cn.html</link>
      <description><![CDATA[简单点说，执行计划实际上是由一系列数据处理过程构成的一个树型的函数链；那些可以访问到物理数据的函数被称为访问路径（Access Path, 如Index Range Scan, Full Table Scan等）；该树形函数链的最底层（叶子节点）从物理对象中获取到原始数据（Row Source）后，将数据由底向上传递，每一个节点的函数对其进行处理（如JOIN匹配、过滤等）得到一个新的Row Source，并继续向上层传递，直到根节点，此时得到的数据就是查询结果。
我们下面通过对Row Source的产生，对执行计划的运作过程做个简单分析。]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.hellodba.com/Doc/Execution_Plan_cn.html</guid>
      <author>fuyuncat</author>
      <pubDate>Fri, 30 Apr 2010 09:13:41 GMT</pubDate>
      <comments>http://www.hellodba.com/Doc/Execution_Plan_cn.html</comments>
    </item>
    <item>
      <title>SQL Rolling Invalidation</title>
      <link>http://www.hellodba.com/Doc/SQL_Rolling_invalidation_en.htm</link>
      <description><![CDATA[     CBO, we need gather objects statistics data to help optimizer choose the best plan. However, if the schema's statistics data be updated, all of the dependent execution plans may be affected. Before 10g, you just have 2 choices, none or all of them be affected. The inputing parameter is NO_INVALIDATE, the choices are true or false. If you set true, none of the plans will adapt the new statistics to reparse the sql, unless it's swapped out from library cache, or be flushed mannually. For those 24*7 databases, some sql may never be improved as we expected. And if you choose false, all of the related plans will be flushed out from library cache immediately, and all of them will be reparsed at next time execution, which may consume much of CPU. That will be a nightmare if it happens at the time that resource is tight.]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.hellodba.com/Doc/SQL_Rolling_invalidation_en.htm</guid>
      <author>fuyuncat</author>
      <pubDate>Mon, 19 Apr 2010 07:06:26 GMT</pubDate>
      <comments>http://www.hellodba.com/Doc/SQL_Rolling_invalidation_en.htm</comments>
    </item>
    <item>
      <title>布隆过滤器 （Bloom Filter）</title>
      <link>http://www.hellodba.com/Doc/Bloom_Filter.html</link>
      <description><![CDATA[布隆过滤器（Bloom Filter）是用于判断一个元素是否属于一个数据集的数据结构。其基本思想就是用一个或多个hash函数对数据集中的每个成员做映射，映射结果不是存在完整的hash表中，而是一个位向量（bit vector）中。位向量所有位初始都为0，根据hash结果将位向量中相应位置1。对数据集中的所有成员的hash计算完成后，就得到了该数据集的位向量。当需要判断一个元素是否属于该数据集时，也用相同的hash函数对其映射得到它的位向量，然后将其位向量上所有为1的位与数据集位向量上相应位比较，如果发现数据集的位向量上某个位为0的话，可以判断这个元素不属于该数据集，这样的一个结果是肯定的。而如果所有相应位都为1的话，那么该元素可能属于这个数据集。
]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.hellodba.com/Doc/Bloom_Filter.html</guid>
      <author>fuyuncat</author>
      <pubDate>Thu, 25 Mar 2010 08:22:14 GMT</pubDate>
      <comments>http://www.hellodba.com/Doc/Bloom_Filter.html</comments>
    </item>
    <item>
      <title>Oracle的排序</title>
      <link>http://www.hellodba.com/Doc/oracle_sorting_cn.htm</link>
      <description><![CDATA[在Oracle的排序过程中，首先将获取到的数据放入一块私有内存区（Sort Area）中进行排序。如果需要排序的数据太大，无法一次在Sort Area中完成全部数据的排序，就会将Sort Area中排好序的数据直接写入（Direct Write，数据不被cache）临时空间作为一个数据集存在。当所有数据都在内存中排过序并写入了磁盘后，就会将磁盘上的数据集进行合并排序（Merge Sort）。合并排序是一个递归过程，直到所有数据集都被合入一个数据集，排序才算完成。]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.hellodba.com/Doc/oracle_sorting_cn.htm</guid>
      <author>fuyuncat</author>
      <pubDate>Thu, 18 Mar 2010 03:17:15 GMT</pubDate>
      <comments>http://www.hellodba.com/Doc/oracle_sorting_cn.htm</comments>
    </item>
    <item>
      <title>All about oracle sorting</title>
      <link>http://www.hellodba.com/Doc/oracle_sorting_en.htm</link>
      <description><![CDATA[    During sorting, data will first be input into a private memory area named sort area, and be sorted in memory. If the data to be sorted is too large to be handle once, the sorted data will be directly written (no caching) into temporary tablespace as a data set. Once all of data be written into disk, oracle will merge those data sets recursively, till to all data be merged in one data set.
]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.hellodba.com/Doc/oracle_sorting_en.htm</guid>
      <author>fuyuncat</author>
      <pubDate>Thu, 18 Mar 2010 03:11:51 GMT</pubDate>
      <comments>http://www.hellodba.com/Doc/oracle_sorting_en.htm</comments>
    </item>
    <item>
      <title>TIPS:  快速建立OUTLINE</title>
      <link>http://www.hellodba.com/Doc/quick_outline.htm</link>
      <description><![CDATA[  OUTLINE是用于保证语句的执行计划稳定性的一种手段。有的时候，我们也需要借助OUTLINES将一个环境下的语句的执行计划在另外一个环境下（如生产环境下发现的TOP SQL，在测试环境中无法直接重现时）重现，以进行进一步优化。
]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.hellodba.com/Doc/quick_outline.htm</guid>
      <author>fuyuncat</author>
      <pubDate>Mon, 15 Mar 2010 02:46:03 GMT</pubDate>
      <comments>http://www.hellodba.com/Doc/quick_outline.htm</comments>
    </item>
    <item>
      <title>CBO 中如何计算调整的MBRC</title>
      <link>http://www.hellodba.com/Doc/CBO_MBRC_formula_cn.html</link>
      <description><![CDATA[在CBO的IO模式中，全表扫描的IO代价不是直接由MBRC(db_file_multiblock_read_count)计算来的，而是由一个相应的调整的值（ADJMBRC）计算的. 我将在本文中讨论如何由MBRC和Block Size来计算出ADJMBRC.]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.hellodba.com/Doc/CBO_MBRC_formula_cn.html</guid>
      <author>fuyuncat</author>
      <pubDate>Wed, 10 Mar 2010 07:30:12 GMT</pubDate>
      <comments>http://www.hellodba.com/Doc/CBO_MBRC_formula_cn.html</comments>
    </item>
    <item>
      <title> Adjusted MBRC formual in CBO</title>
      <link>http://www.hellodba.com/Doc/CBO_MBRC_formula_en.html</link>
      <description><![CDATA[In IO mode, CBO will calculate IO cost by an adjusted MBRC (ADJMBRC) instead of the MBRC (db_file_multiblock_read_count) directly. We will discuss how to calculate the ADJMBRC with a deduced formula.]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.hellodba.com/Doc/CBO_MBRC_formula_en.html</guid>
      <author>fuyuncat</author>
      <pubDate>Wed, 10 Mar 2010 07:22:26 GMT</pubDate>
      <comments>http://www.hellodba.com/Doc/CBO_MBRC_formula_en.html</comments>
    </item>
    <item>
      <title>CBO代价估算</title>
      <link>http://www.hellodba.com/Doc/CBO_Cost_Estimation_cn.html</link>
      <description><![CDATA[CBO有两种模式来估算查询计划的代价：IO和CPU。在IO模式中，代价估算器仅估算IO代价，不考虑CPU代价；而在CPU模式中，估算器会将IO代价和CPU代价都转换为同一单位：读取一个数据块的时间，然后将两部分结果相加，得到最终估算代价。
]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.hellodba.com/Doc/CBO_Cost_Estimation_cn.html</guid>
      <author>fuyuncat</author>
      <pubDate>Mon, 08 Mar 2010 03:22:28 GMT</pubDate>
      <comments>http://www.hellodba.com/Doc/CBO_Cost_Estimation_cn.html</comments>
    </item>
    <item>
      <title>CBO Cost estimation</title>
      <link>http://www.hellodba.com/Doc/CBO_Cost_Estimation.html</link>
      <description><![CDATA[There are 2 kind of CPU mode in CBO, IO & CPU. In IO mode, only IO cost will be calcualted, while in CPU mode, IO and CPU Cycles of processing blocks and rows will both be converted to the same unit, CPU time of one single block, and then be combined together.
]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.hellodba.com/Doc/CBO_Cost_Estimation.html</guid>
      <author>fuyuncat</author>
      <pubDate>Fri, 05 Mar 2010 08:07:07 GMT</pubDate>
      <comments>http://www.hellodba.com/Doc/CBO_Cost_Estimation.html</comments>
    </item>
    <item>
      <title>NULL IS NOT NULL in execution plan</title>
      <link>http://www.hellodba.com/Doc/NULL_IS_NOT_NULL.html</link>
      <description><![CDATA[NULL IS NOT NULL is means always FALSE. Optimzier will add such filter when it found the logic result of the sub plan tree is FALSE, it will cause to the plan tree will never be executed. When find such filter added by optimizer, it's normally means a logic problem in the SQL.
]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.hellodba.com/Doc/NULL_IS_NOT_NULL.html</guid>
      <author>fuyuncat</author>
      <pubDate>Thu, 04 Mar 2010 03:09:52 GMT</pubDate>
      <comments>http://www.hellodba.com/Doc/NULL_IS_NOT_NULL.html</comments>
    </item>
    <item>
      <title>CBO Statistics data gathering and internal arithmetic analysis -- Sampling</title>
      <link>http://www.hellodba.com/Doc/CBO_STATS_GATHER_INTERNAL_5.html</link>
      <description><![CDATA[Statistics data and histogram data are the basic data for Cost Base Optimizer to calculate the cost. They are correct or not, decide if optimizer can get the best execution plan. I will analyze the statistics data gathering internal process and arithmetic in following papers.
]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.hellodba.com/Doc/CBO_STATS_GATHER_INTERNAL_5.html</guid>
      <author>fuyuncat</author>
      <pubDate>Wed, 20 Jan 2010 07:34:44 GMT</pubDate>
      <comments>http://www.hellodba.com/Doc/CBO_STATS_GATHER_INTERNAL_5.html</comments>
    </item>
    <item>
      <title>CBO Statistics data gathering and internal arithmetic analysis -- Calculating NDV and Density</title>
      <link>http://www.hellodba.com/Doc/CBO_STATS_GATHER_INTERNAL_4.html</link>
      <description><![CDATA[Statistics data and histogram data are the basic data for Cost Base Optimizer to calculate the cost. They are correct or not, decide if optimizer can get the best execution plan. I will analyze the statistics data gathering internal process and arithmetic in following papers.
]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.hellodba.com/Doc/CBO_STATS_GATHER_INTERNAL_4.html</guid>
      <author>fuyuncat</author>
      <pubDate>Mon, 18 Jan 2010 06:23:13 GMT</pubDate>
      <comments>http://www.hellodba.com/Doc/CBO_STATS_GATHER_INTERNAL_4.html</comments>
    </item>
    <item>
      <title>CBO Statistics data gathering and internal arithmetic analysis -- Converting to endpoint value</title>
      <link>http://www.hellodba.com/Doc/CBO_STATS_GATHER_INTERNAL_3.html</link>
      <description><![CDATA[Statistics data and histogram data are the basic data for Cost Base Optimizer to calculate the cost. They are correct or not, decide if optimizer can get the best execution plan. I will analyze the statistics data gathering internal process and arithmetic in following papers.
]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.hellodba.com/Doc/CBO_STATS_GATHER_INTERNAL_3.html</guid>
      <author>fuyuncat</author>
      <pubDate>Wed, 13 Jan 2010 03:06:07 GMT</pubDate>
      <comments>http://www.hellodba.com/Doc/CBO_STATS_GATHER_INTERNAL_3.html</comments>
    </item>
    <item>
      <title>CBO Statistics data gathering and internal arithmetic analysis -- Frequency or Height Balanaced?</title>
      <link>http://www.hellodba.com/Doc/CBO_STATS_GATHER_INTERNAL_2.html</link>
      <description><![CDATA[Statistics data and histogram data are the basic data for Cost Base Optimizer to calculate the cost. They are correct or not, decide if optimizer can get the best execution plan. I will analyze the statistics data gathering internal process and arithmetic in following papers.
]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.hellodba.com/Doc/CBO_STATS_GATHER_INTERNAL_2.html</guid>
      <author>fuyuncat</author>
      <pubDate>Mon, 11 Jan 2010 06:13:34 GMT</pubDate>
      <comments>http://www.hellodba.com/Doc/CBO_STATS_GATHER_INTERNAL_2.html</comments>
    </item>
    <item>
      <title>CBO Statistics data gathering and internal arithmetic analysis -- when will gather histogram data</title>
      <link>http://www.hellodba.com/Doc/CBO_STATS_GATHER_INTERNAL_1.html</link>
      <description><![CDATA[Statistics data and histogram data are the basic data for Cost Base Optimizer to calculate the cost. They are correct or not, decide if optimizer can get the best execution plan. I will analyze the statistics data gathering internal process and arithmetic in following papers.
]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.hellodba.com/Doc/CBO_STATS_GATHER_INTERNAL_1.html</guid>
      <author>fuyuncat</author>
      <pubDate>Thu, 07 Jan 2010 09:47:08 GMT</pubDate>
      <comments>http://www.hellodba.com/Doc/CBO_STATS_GATHER_INTERNAL_1.html</comments>
    </item>
    <item>
      <title>《Oracle IO 问题解析》PDF下载</title>
      <link>http://www.hellodba.com/Download/ORACLE_IO_PDF.html</link>
      <description><![CDATA[为了方便阅读，将部分篇幅较长的本站原创文章整理成PDF文件提供下载。 
 ]]></description>
      <category>下载</category>
      <guid isPermaLink="true">http://www.hellodba.com/Download/ORACLE_IO_PDF.html</guid>
      <author>fuyuncat</author>
      <pubDate>Tue, 05 Jan 2010 09:22:19 GMT</pubDate>
      <comments>http://www.hellodba.com/Download/ORACLE_IO_PDF.html</comments>
    </item>
    <item>
      <title>《Oracle 中 ROWNUM 的使用技巧》PDF下载</title>
      <link>http://www.hellodba.com/Download/ORA_ROWNUM_PDF.html</link>
      <description><![CDATA[为了方便阅读，将部分篇幅较长的本站原创文章整理成PDF文件提供下载。 
 ]]></description>
      <category>下载</category>
      <guid isPermaLink="true">http://www.hellodba.com/Download/ORA_ROWNUM_PDF.html</guid>
      <author>fuyuncat</author>
      <pubDate>Thu, 31 Dec 2009 09:44:54 GMT</pubDate>
      <comments>http://www.hellodba.com/Download/ORA_ROWNUM_PDF.html</comments>
    </item>
    <item>
      <title>TIPS:  如何获取数据的存储大小</title>
      <link>http://www.hellodba.com/Doc/sys_op_opnsize.html</link>
      <description><![CDATA[有些同学在估算数据的物理存储大小时会使用length函数，实际上这不正确，真正用于获取数据物理字节数的函数是sys_op_opnsize (10g)。length函数获取到的是数据的逻辑长度，而非物理长度。例如数字，逻辑长度是按照10进制得到的，而其物理存储是按照16进制。
]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.hellodba.com/Doc/sys_op_opnsize.html</guid>
      <author>fuyuncat</author>
      <pubDate>Wed, 30 Dec 2009 09:10:55 GMT</pubDate>
      <comments>http://www.hellodba.com/Doc/sys_op_opnsize.html</comments>
    </item>
    <item>
      <title>《Oracle 10g特性》PDF文档下载</title>
      <link>http://www.hellodba.com/Download/Oracle_10_features_pdf.html</link>
      <description><![CDATA[为了方便阅读，将部分篇幅较长的本站原创文章整理成PDF文件提供下载。
 
]]></description>
      <category>下载</category>
      <guid isPermaLink="true">http://www.hellodba.com/Download/Oracle_10_features_pdf.html</guid>
      <author>fuyuncat</author>
      <pubDate>Fri, 25 Dec 2009 03:20:19 GMT</pubDate>
      <comments>http://www.hellodba.com/Download/Oracle_10_features_pdf.html</comments>
    </item>
    <item>
      <title>[En] Oracle Row Shipping</title>
      <link>http://www.hellodba.com/Doc/Oracle_row_shipping_en.html</link>
      <description><![CDATA[To reduce workload in server, some features were introduced to move some jobs to client side. Row shipping is one of such features.
There are steps to process SQL, parsing -> optimzating -> Row Source generating -> result producting. In traditional mode, one job of Row Source gernerator is that choose the columns in SELECT clause from the rows return to client, which named Projection. We could find such information from output DBMS_XPLAN (10g later):
]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.hellodba.com/Doc/Oracle_row_shipping_en.html</guid>
      <author>fuyuncat</author>
      <pubDate>Fri, 25 Dec 2009 01:21:17 GMT</pubDate>
      <comments>http://www.hellodba.com/Doc/Oracle_row_shipping_en.html</comments>
    </item>
    <item>
      <title>[中]Oracle Row Shipping</title>
      <link>http://www.hellodba.com/Doc/oracle_row_shipping_cn.html</link>
      <description><![CDATA[为了降低服务端的负荷，oracle引入一些特性，将部分工作移到客户端去处理。Row shipping就是其中之一。
我们知道，Oracle对于SQL的处理由几个步骤组成：解析(Parse)->优化(Optimize)->生产数据源(Row Source Generate)->返回结果(Result Product)。在传统模式下，数据源生成组件(Row Source Generator)要做一步工作就是从记录中找出SELECT子句的中出现的字段，返回给客户端，这一过程称为投射（Projection）。我们可以通过DBMS_XPLAN(10g)查看查询计划中的投射字段信息]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.hellodba.com/Doc/oracle_row_shipping_cn.html</guid>
      <author>fuyuncat</author>
      <pubDate>Thu, 24 Dec 2009 05:26:15 GMT</pubDate>
      <comments>http://www.hellodba.com/Doc/oracle_row_shipping_cn.html</comments>
    </item>
    <item>
      <title>《Oracle 内存全面分析》PDF下载</title>
      <link>http://www.hellodba.com/Download/ora_Memory_pdf.html</link>
      <description><![CDATA[为了方便阅读，将部分篇幅较长的本站原创文章整理成PDF文件提供下载。]]></description>
      <category>下载</category>
      <guid isPermaLink="true">http://www.hellodba.com/Download/ora_Memory_pdf.html</guid>
      <author>fuyuncat</author>
      <pubDate>Tue, 22 Dec 2009 01:12:43 GMT</pubDate>
      <comments>http://www.hellodba.com/Download/ora_Memory_pdf.html</comments>
    </item>
    <item>
      <title>《ORA-01555 错误浅析》PDF下载</title>
      <link>http://www.hellodba.com/Download/ora_1555_pdf.html</link>
      <description><![CDATA[为了方便阅读，将部分较长的本站原创文章整理成PDF文件提供下载。]]></description>
      <category>下载</category>
      <guid isPermaLink="true">http://www.hellodba.com/Download/ora_1555_pdf.html</guid>
      <author>fuyuncat</author>
      <pubDate>Mon, 21 Dec 2009 09:22:44 GMT</pubDate>
      <comments>http://www.hellodba.com/Download/ora_1555_pdf.html</comments>
    </item>
    <item>
      <title>Oracle Redo Strand</title>
      <link>http://www.hellodba.com/Doc/oracle_redo_strand_en.html</link>
      <description><![CDATA[Redo log is a important data to be used to recovery and some other advanced features. A redo entry involved the information about database changing. All of the redo entries should be writen into logfile finally. To avoid disk io waits, oracle allocated a log buffer from sga to cache the redo data. A redo entry is generated in PGA, then it be copied to log buffer by server process. When reach some conditions, LGWR will write the log buffer contents to the logfiles. Log buffer is shared by all of server processes, to protect it, the server process should first request the "redo allocation latch" to allocate buffer from it. Hence, in high concurrent OLTP system, we may observer the redo allocation latch contentions.]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.hellodba.com/Doc/oracle_redo_strand_en.html</guid>
      <author>fuyuncat</author>
      <pubDate>Fri, 18 Dec 2009 06:26:13 GMT</pubDate>
      <comments>http://www.hellodba.com/Doc/oracle_redo_strand_en.html</comments>
    </item>
    <item>
      <title>Oracle Redo  并行机制</title>
      <link>http://www.hellodba.com/Doc/Oracle_redo_strand_cn.html</link>
      <description><![CDATA[Redo log 是用于恢复和一个高级特性的重要数据，一个redo条目包含了相应操作导致的数据库变化的所有信息，所有redo条目最终都要被写入redo文件中去。Redo log buffer是为了避免Redo文件IO导致性能瓶颈而在sga中分配出的一块内存。一个redo条目首先在用户内存(PGA)中产生，然后由oracle服务进程拷贝到log buffer中，当满足一定条件时，再由LGWR进程写入redo文件。由于log buffer是一块“共享”内存，为了避免冲突，它是受到redo allocation latch保护的，每个服务进程需要先获取到该latch才能分配redo buffer。因此在高并发且数据修改频繁的oltp系统中，我们通常可以观察到redo allocation latch的等待。]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.hellodba.com/Doc/Oracle_redo_strand_cn.html</guid>
      <author>fuyuncat</author>
      <pubDate>Fri, 18 Dec 2009 04:05:22 GMT</pubDate>
      <comments>http://www.hellodba.com/Doc/Oracle_redo_strand_cn.html</comments>
    </item>
    <item>
      <title>Unwrap 工具更新</title>
      <link>http://www.hellodba.com/Download/fyunwrap_upgrade.html</link>
      <description><![CDATA[更新了frunwrap，增加了对9i wrap方式的支持。]]></description>
      <category>下载</category>
      <guid isPermaLink="true">http://www.hellodba.com/Download/fyunwrap_upgrade.html</guid>
      <author>fuyuncat</author>
      <pubDate>Mon, 23 Nov 2009 09:28:02 GMT</pubDate>
      <comments>http://www.hellodba.com/Download/fyunwrap_upgrade.html</comments>
    </item>
    <item>
      <title>HowTo: Trace the statistics data gathtering</title>
      <link>http://www.hellodba.com/Doc/trace_stat_gathering.html</link>
      <description><![CDATA[Sometimes, we want to know which objects failed to be gathered the stats data after the gathering job complete? What's the reason? We may set an undocumented parameter "TRACE" to capture such information.]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.hellodba.com/Doc/trace_stat_gathering.html</guid>
      <author>fuyuncat</author>
      <pubDate>Thu, 19 Nov 2009 05:59:21 GMT</pubDate>
      <comments>http://www.hellodba.com/Doc/trace_stat_gathering.html</comments>
    </item>
    <item>
      <title>Oracle 内存回滚 (In Memory Undo)</title>
      <link>http://www.hellodba.com/Doc/Oracle_IMU_CN.html</link>
      <description><![CDATA[在传统的事务更新过程中，如果一条数据记录被更新，就会从buffer cache中读取/分配一块UNDO数据块，并且立即会写入一条UNDO条目。如果同一个事务中有多条记录被更新，则undo buffer数据块中就会写入多条undo条目。引入IMU后，会从shared pool中分配出一个新的内存池——IMU pool。当一条数据记录被更新，仍然会从buffer cache中读取/分配一块undo数据块，但是，这块undo块并不会立即被更新，而是会在IMU pool中产生一个IMU node，IMU节点通过IMU map与数据记录更新对应。如果事务中有多条记录被修改，则IMU pool中就生产多个IMU nodes，而buffer中的undo block不会发生任何变化。当发生IMU commit或IMU flush时，才会通过IMU map将这些IMU node记录的undo信息写入undo buffer block中。并且，所有这些redo信息会和commit vector一起作为一个Redo条目写入Redo log中。整个过程中UNDO所产生的redo信息则大大减少。]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.hellodba.com/Doc/Oracle_IMU_CN.html</guid>
      <author>fuyuncat</author>
      <pubDate>Tue, 17 Nov 2009 03:12:09 GMT</pubDate>
      <comments>http://www.hellodba.com/Doc/Oracle_IMU_CN.html</comments>
    </item>
    <item>
      <title>Oracle In Memory Undo</title>
      <link>http://www.hellodba.com/Doc/Oracle_IMU.html</link>
      <description><![CDATA[In traditional undo update, once record be updated, an undo block will be allocated in the buffer cache, 1 new entry will be inserted into the undo block immediately. If several records be updated in the same transaction, several entries generated in the undo buffer as soon as the record updated. At the mean time, each undo entry will also generate redo log entry. After introduced the IMU, new pools named IMU pools will be allocated from shared pool. Once a record be updated, an undo buffer block still be allocted from buffer cache, but without inserting a new entry into the block immediately. It will generate an undo map in the IMU pool, and one IMU node for the record change. If several records be updated, several IMU nodes will be generated in the IMU pool, and the UNDO map be updated correspondly. All of the changes occur in the IMU pool, not modify the undo buffer block. Once commit or the IMU pool be flushed, it will map the IMU nodes as undo entries into the undo block and write to disk. This process is a batch process, just 1 redo entry generated for these changes.]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.hellodba.com/Doc/Oracle_IMU.html</guid>
      <author>fuyuncat</author>
      <pubDate>Mon, 16 Nov 2009 08:16:22 GMT</pubDate>
      <comments>http://www.hellodba.com/Doc/Oracle_IMU.html</comments>
    </item>
    <item>
      <title>Secret of oracle logical IO: Index Scan</title>
      <link>http://www.hellodba.com/Doc/logic_io_secret_index_scan.html</link>
      <description><![CDATA[How to calculate the io of a query? This question is the most concern of dba&developer when we do performance tuning. We know the IO is affected by many factors in different operations, e.g. , high water mark, index height, extents number of a segment, cr UNDO application and so on. However, for the details of the factors in IO calculation formula, are secrets for us. Even work with 10200 event, we can not count up to the final total CRs, because this trace ignored the meta data reads. By monitoring the buffer cache, we can just guess it also reads the segment header for times, and repeat reads for number of extents. From the fixed table sys.x$kcbwh, sys.x$kcbsw, we can find the buffer cache statisitcs data, which are directly related to the io behaviors. By comparing the statistic data before&after the query, we may peek some internal information for the logic IO. However, this view is a db level statistics data, it will be affected by the backgroup processes, we may not get the truth from it. So, is there any other way to find out the secret? Yes! As we know, for each data reads, it will be pined in the cache, means if we can trace the pin behaviors, we will know IO behaviors. Read which block? For what purpose? How many times a block will be red? The switch is the undocumented parameter, "_trace_pin_time".]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.hellodba.com/Doc/logic_io_secret_index_scan.html</guid>
      <author>fuyuncat</author>
      <pubDate>Wed, 11 Nov 2009 02:29:55 GMT</pubDate>
      <comments>http://www.hellodba.com/Doc/logic_io_secret_index_scan.html</comments>
    </item>
    <item>
      <title>Secret of oracle logic IO: Sorting</title>
      <link>http://www.hellodba.com/Doc/logic_io_secret_sorting.html</link>
      <description><![CDATA[How to calculate the io of a query? This question is the most concern of dba&developer when we do performance tuning. We know the IO is affected by many factors in different operations, e.g. , high water mark, index height, extents number of a segment, cr UNDO application and so on. However, for the details of the factors in IO calculation formula, are secrets for us. Even work with 10200 event, we can not count up to the final total CRs, because this trace ignored the meta data reads. By monitoring the buffer cache, we can just guess it also reads the segment header for times, and repeat reads for number of extents. From the fixed table sys.x$kcbwh, sys.x$kcbsw, we can find the buffer cache statisitcs data, which are directly related to the io behaviors. By comparing the statistic data before&after the query, we may peek some internal information for the logic IO. However, this view is a db level statistics data, it will be affected by the backgroup processes, we may not get the truth from it. So, is there any other way to find out the secret? Yes! As we know, for each data reads, it will be pined in the cache, means if we can trace the pin behaviors, we will know IO behaviors. Read which block? For what purpose? How many times a block will be red? The switch is the undocumented parameter, "_trace_pin_time".]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.hellodba.com/Doc/logic_io_secret_sorting.html</guid>
      <author>fuyuncat</author>
      <pubDate>Tue, 10 Nov 2009 01:14:31 GMT</pubDate>
      <comments>http://www.hellodba.com/Doc/logic_io_secret_sorting.html</comments>
    </item>
    <item>
      <title>Secret of oracle logic IO: Current Mode</title>
      <link>http://www.hellodba.com/Doc/logic_io_secret_Current_Mode.html</link>
      <description><![CDATA[How to calculate the io of a query? This question is the most concern of dba&developer when we do performance tuning. We know the IO is affected by many factors in different operations, e.g. , high water mark, index height, extents number of a segment, cr UNDO application and so on. However, for the details of the factors in IO calculation formula, are secrets for us. Even work with 10200 event, we can not count up to the final total CRs, because this trace ignored the meta data reads. By monitoring the buffer cache, we can just guess it also reads the segment header for times, and repeat reads for number of extents. From the fixed table sys.x$kcbwh, sys.x$kcbsw, we can find the buffer cache statisitcs data, which are directly related to the io behaviors. By comparing the statistic data before&after the query, we may peek some internal information for the logic IO. However, this view is a db level statistics data, it will be affected by the backgroup processes, we may not get the truth from it. So, is there any other way to find out the secret? Yes! As we know, for each data reads, it will be pined in the cache, means if we can trace the pin behaviors, we will know IO behaviors. Read which block? For what purpose? How many times a block will be red? The switch is the undocumented parameter, "_trace_pin_time".]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.hellodba.com/Doc/logic_io_secret_Current_Mode.html</guid>
      <author>fuyuncat</author>
      <pubDate>Mon, 09 Nov 2009 01:02:38 GMT</pubDate>
      <comments>http://www.hellodba.com/Doc/logic_io_secret_Current_Mode.html</comments>
    </item>
    <item>
      <title>Secret of oracle logic IO: Consistent Gets</title>
      <link>http://www.hellodba.com/Doc/logic_io_secret_CR.html</link>
      <description><![CDATA[How to calculate the io of a query? This question is the most concern of dba&developer when we do performance tuning. We know the IO is affected by many factors in different operations, e.g. , high water mark, index height, extents number of a segment, cr UNDO application and so on. However, for the details of the factors in IO calculation formula, are secrets for us. Even work with 10200 event, we can not count up to the final total CRs, because this trace ignored the meta data reads. By monitoring the buffer cache, we can just guess it also reads the segment header for times, and repeat reads for number of extents. From the fixed table sys.x$kcbwh, sys.x$kcbsw, we can find the buffer cache statisitcs data, which are directly related to the io behaviors. By comparing the statistic data before&after the query, we may peek some internal information for the logic IO. However, this view is a db level statistics data, it will be affected by the backgroup processes, we may not get the truth from it. So, is there any other way to find out the secret? Yes! As we know, for each data reads, it will be pined in the cache, means if we can trace the pin behaviors, we will know IO behaviors. Read which block? For what purpose? How many times a block will be red? The switch is the undocumented parameter, "_trace_pin_time".]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.hellodba.com/Doc/logic_io_secret_CR.html</guid>
      <author>fuyuncat</author>
      <pubDate>Sat, 07 Nov 2009 14:57:13 GMT</pubDate>
      <comments>http://www.hellodba.com/Doc/logic_io_secret_CR.html</comments>
    </item>
    <item>
      <title>Secret of oracle logic IO: Full Table Scan: Part 3</title>
      <link>http://www.hellodba.com/Doc/logic_io_secret_FTS_3.html</link>
      <description><![CDATA[How to calculate the io of a query? This question is the most concern of dba&developer when we do performance tuning. We know the IO is affected by many factors in different operations, e.g. , high water mark, index height, extents number of a segment, cr UNDO application and so on. However, for the details of the factors in IO calculation formula, are secrets for us. Even work with 10200 event, we can not count up to the final total CRs, because this trace ignored the meta data reads. By monitoring the buffer cache, we can just guess it also reads the segment header for times, and repeat reads for number of extents. From the fixed table sys.x$kcbwh, sys.x$kcbsw, we can find the buffer cache statisitcs data, which are directly related to the io behaviors. By comparing the statistic data before&after the query, we may peek some internal information for the logic IO. However, this view is a db level statistics data, it will be affected by the backgroup processes, we may not get the truth from it. So, is there any other way to find out the secret? Yes! As we know, for each data reads, it will be pined in the cache, means if we can trace the pin behaviors, we will know IO behaviors. Read which block? For what purpose? How many times a block will be red? The switch is the undocumented parameter, "_trace_pin_time".]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.hellodba.com/Doc/logic_io_secret_FTS_3.html</guid>
      <author>fuyuncat</author>
      <pubDate>Fri, 06 Nov 2009 06:34:48 GMT</pubDate>
      <comments>http://www.hellodba.com/Doc/logic_io_secret_FTS_3.html</comments>
    </item>
    <item>
      <title>Secret of oracle logic IO: Full Table Scan: Part 2</title>
      <link>http://www.hellodba.com/Doc/logic_io_secret_FTS_2.html</link>
      <description><![CDATA[How to calculate the io of a query? This question is the most concern of dba&developer when we do performance tuning. We know the IO is affected by many factors in different operations, e.g. , high water mark, index height, extents number of a segment, cr UNDO application and so on. However, for the details of the factors in IO calculation formula, are secrets for us. Even work with 10200 event, we can not count up to the final total CRs, because this trace ignored the meta data reads. By monitoring the buffer cache, we can just guess it also reads the segment header for times, and repeat reads for number of extents. From the fixed table sys.x$kcbwh, sys.x$kcbsw, we can find the buffer cache statisitcs data, which are directly related to the io behaviors. By comparing the statistic data before&after the query, we may peek some internal information for the logic IO. However, this view is a db level statistics data, it will be affected by the backgroup processes, we may not get the truth from it. So, is there any other way to find out the secret? Yes! As we know, for each data reads, it will be pined in the cache, means if we can trace the pin behaviors, we will know IO behaviors. Read which block? For what purpose? How many times a block will be red? The switch is the undocumented parameter, "_trace_pin_time".]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.hellodba.com/Doc/logic_io_secret_FTS_2.html</guid>
      <author>fuyuncat</author>
      <pubDate>Thu, 05 Nov 2009 09:16:25 GMT</pubDate>
      <comments>http://www.hellodba.com/Doc/logic_io_secret_FTS_2.html</comments>
    </item>
    <item>
      <title>Secret of oracle logic IO: Full Table Scan: Part 1</title>
      <link>http://www.hellodba.com/Doc/logic_io_secret_FTS_1.html</link>
      <description><![CDATA[How to calculate the io of a query? This question is the most concern of dba&developer when we do performance tuning. We know the IO is affected by many factors in different operations, e.g. , high water mark, index height, extents number of a segment, cr UNDO application and so on. However, for the details of the factors in IO calculation formula, are secrets for us. Even work with 10200 event, we can not count up to the final total CRs, because this trace ignored the meta data reads. By monitoring the buffer cache, we can just guess it also reads the segment header for times, and repeat reads for number of extents. From the fixed table sys.x$kcbwh, sys.x$kcbsw, we can find the buffer cache statisitcs data, which are directly related to the io behaviors. By comparing the statistic data before&after the query, we may peek some internal information for the logic IO. However, this view is a db level statistics data, it will be affected by the backgroup processes, we may not get the truth from it. So, is there any other way to find out the secret? Yes! As we know, for each data reads, it will be pined in the cache, means if we can trace the pin behaviors, we will know IO behaviors. Read which block? For what purpose? How many times a block will be red? The switch is the undocumented parameter, "_trace_pin_time".]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.hellodba.com/Doc/logic_io_secret_FTS_1.html</guid>
      <author>fuyuncat</author>
      <pubDate>Wed, 04 Nov 2009 09:10:41 GMT</pubDate>
      <comments>http://www.hellodba.com/Doc/logic_io_secret_FTS_1.html</comments>
    </item>
    <item>
      <title> 事务队列等待（Tx Enqueue）深入分析——其它争用</title>
      <link>http://www.hellodba.com/Doc/TX_enqueue_contention.html</link>
      <description><![CDATA[在TX等待中，还有一些其它不是很常见的情形会导致共享锁的等待，这类等待在10g就被记录为“enq: TX - contention”事件。例如，在以下情形中会出现“enq: TX - contention”等待事件]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.hellodba.com/Doc/TX_enqueue_contention.html</guid>
      <author>fuyuncat</author>
      <pubDate>Tue, 03 Nov 2009 09:55:08 GMT</pubDate>
      <comments>http://www.hellodba.com/Doc/TX_enqueue_contention.html</comments>
    </item>
    <item>
      <title> 事务队列等待（Tx Enqueue）深入分析——外键约束</title>
      <link>http://www.hellodba.com/Doc/TX_enqueue_fk.html</link>
      <description><![CDATA[如果2个表之间建立了主外键关系，那么对它们的数据操作就会受到外键约束，以保证数据完整性：子表插入数据时，外键键值在主表中必须存在；主表删除时，子表中必须已经没有该键值的数据。如果进行这样的数据操作时，相应数据约束在另外事务里面已经满足（或正导致违反约束），但事务未完成，那么这样的数据操作的事务就会进入等待队列]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.hellodba.com/Doc/TX_enqueue_fk.html</guid>
      <author>fuyuncat</author>
      <pubDate>Mon, 02 Nov 2009 09:13:51 GMT</pubDate>
      <comments>http://www.hellodba.com/Doc/TX_enqueue_fk.html</comments>
    </item>
    <item>
      <title> 事务队列等待（Tx Enqueue）深入分析——位图索引维护</title>
      <link>http://www.hellodba.com/Doc/TX_enqueue_bitmap_idx.html</link>
      <description><![CDATA[位图索引（Bitmap Index）是一种特殊索引。在普通B+树索引中，所有表数据记录指针都存储在叶子节点上，每一条非空数据在叶子节点上都存储一条记录，而非唯一索引中，同一键值对应多条记录在索引也存储多条记录，每条索引上都存储了对应表数据记录的物理地址，即ROWID。bitmap索引也是一个树状结构，但是每一个键值，无论是否为空、或者一个键对应多条数据记录，在叶子节点上只有一条记录，而对应的每一条表数据记录的物理地址通过映射函数转换，在索引记录中对应一个“位”（bit），所有对应记录的地址转换成“位”后形成一个位图（bitmap）存储在索引记录中。Bitmap索引不仅大大提高了重复值较多（Low Cardinality）的索引的查询效率——对应一个键值，只需读取一次就可以获取到所有表记录的物理地址，而普通索引可能需要读取多次索引后才能获取到全部数据，还减少了索引的存储空间。但是，由于一个键值对应多个数据记录，这就会造成数据更新的麻烦：当多个事务修改同一键值的数据时，都需要在对应的索引记录上加锁，从而导致事务等待：]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.hellodba.com/Doc/TX_enqueue_bitmap_idx.html</guid>
      <author>fuyuncat</author>
      <pubDate>Wed, 28 Oct 2009 08:07:52 GMT</pubDate>
      <comments>http://www.hellodba.com/Doc/TX_enqueue_bitmap_idx.html</comments>
    </item>
    <item>
      <title> 事务队列等待（Tx Enqueue）深入分析——唯一性约束</title>
      <link>http://www.hellodba.com/Doc/TX_enqueue_unique.html</link>
      <description><![CDATA[唯一性约束是为了保证某个字段或者某一组字段的每一条记录的数据在表中只村子唯一一条的约束。当向表中插入一条记录（或修改记录）时，如果存在唯一性约束，就需要先检查表中是否已经存在该数据，如果不存在，数据才允许插入。而这一检查过程实际上就是对已有数据的一次查询，因此，每一个唯一性约束都会在表中建立一个对应的唯一索引（Unique Index）。而如果一个事务在插入（或修改）一条数据时，新数据已经在另外一个事务中被插入、或者已有数据在另外一个事务中被删除，相应索引数据记录被加上共享锁，但事务并未结束，此时当前事务就需要进入队列等待另外事务结束，并记录"enq: TX - Row lock contention"事件。]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.hellodba.com/Doc/TX_enqueue_unique.html</guid>
      <author>fuyuncat</author>
      <pubDate>Tue, 27 Oct 2009 06:13:59 GMT</pubDate>
      <comments>http://www.hellodba.com/Doc/TX_enqueue_unique.html</comments>
    </item>
    <item>
      <title> 事务队列等待（Tx Enqueue）深入分析——索引争用</title>
      <link>http://www.hellodba.com/Doc/TX_enqueue_idx_contention.html</link>
      <description><![CDATA[索引争用是和索引块分裂直接相关的。当一个事务需要向一个数据块插入数据时，该数据块正好发生了索引分裂，则插入事务需要等待分裂事务
]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.hellodba.com/Doc/TX_enqueue_idx_contention.html</guid>
      <author>fuyuncat</author>
      <pubDate>Fri, 23 Oct 2009 06:24:18 GMT</pubDate>
      <comments>http://www.hellodba.com/Doc/TX_enqueue_idx_contention.html</comments>
    </item>
    <item>
      <title>事务队列等待（Tx Enqueue）深入分析——ITL争用</title>
      <link>http://www.hellodba.com/Doc/TX_enqueue_ITL.html</link>
      <description><![CDATA[我们知道，事务在对数据块中的记录加锁时，需要首先在数据块头部记录下该事务的相关信息，这样一个记录就是一条ITL槽（slot）。ITL TX等待发生在事务请求对数据块中记录加锁时，数据块上没有足够ITL槽。]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.hellodba.com/Doc/TX_enqueue_ITL.html</guid>
      <author>fuyuncat</author>
      <pubDate>Tue, 20 Oct 2009 07:34:11 GMT</pubDate>
      <comments>http://www.hellodba.com/Doc/TX_enqueue_ITL.html</comments>
    </item>
    <item>
      <title>B-Tree 索引中的数据块分裂——等待事件</title>
      <link>http://www.hellodba.com/Doc/Btree_split_6_waits.html</link>
      <description><![CDATA[尽管索引分裂是由递归事务控制的，其资源的请求与释放都很短暂，不受用户事务是否结束的影响，但是，在并发环境中，索引分裂仍然会导致一些等待事件。]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.hellodba.com/Doc/Btree_split_6_waits.html</guid>
      <author>fuyuncat</author>
      <pubDate>Mon, 19 Oct 2009 07:25:54 GMT</pubDate>
      <comments>http://www.hellodba.com/Doc/Btree_split_6_waits.html</comments>
    </item>
    <item>
      <title>B-Tree 索引中的数据块分裂——数据块分配</title>
      <link>http://www.hellodba.com/Doc/Btree_split_5_allocate_block.html</link>
      <description><![CDATA[当索引数据块需要分裂时，会从Freelist中找到空闲的数据块满足分配需要。如果索引数据块上的数据被全部删除，该数据块就会被放置在freelist的前面，但并不从B树结构上删除。]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.hellodba.com/Doc/Btree_split_5_allocate_block.html</guid>
      <author>fuyuncat</author>
      <pubDate>Fri, 16 Oct 2009 07:56:00 GMT</pubDate>
      <comments>http://www.hellodba.com/Doc/Btree_split_5_allocate_block.html</comments>
    </item>
    <item>
      <title>B-Tree 索引中的数据块分裂——分裂事务控制</title>
      <link>http://www.hellodba.com/Doc/Btree_split_3_ITL.html</link>
      <description><![CDATA[索引分裂是导致分裂的用户事务中调用的递归事务控制，其对资源的请求和释放都是在该递归事务中完成的。
在任何一块枝节点数据块上，有且只有一个ITL slot，这个ITL slot不是被用于用户事务（User Transaction）的，而是被用于发生分裂时的递归事务的。同样，在叶子节点上，第一ITL slot，也是用于此目的]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.hellodba.com/Doc/Btree_split_3_ITL.html</guid>
      <author>fuyuncat</author>
      <pubDate>Thu, 15 Oct 2009 06:31:44 GMT</pubDate>
      <comments>http://www.hellodba.com/Doc/Btree_split_3_ITL.html</comments>
    </item>
    <item>
      <title>B-Tree 索引中的数据块分裂——存储参数</title>
      <link>http://www.hellodba.com/Doc/Btree_split_3_storage.html</link>
      <description><![CDATA[在表的数据块中，当数据插入时，要保证数据块上剩余空间大于、等于PCTFREE的比例设置，以用于数据更新和多事务处理，从而减少数据迁移（Row Migration）的发生；而当分配新的数据块时，会根据INITRANS的设置预留相应的ITL slot，保证并发事务能分配到ITL slot。
在索引中，这两个参数仅在有数据时创建或重建索引才会起作用，且仅在叶子节点上起作用。]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.hellodba.com/Doc/Btree_split_3_storage.html</guid>
      <author>fuyuncat</author>
      <pubDate>Wed, 14 Oct 2009 06:54:17 GMT</pubDate>
      <comments>http://www.hellodba.com/Doc/Btree_split_3_storage.html</comments>
    </item>
    <item>
      <title>B-Tree 索引中的数据块分裂——树的生长</title>
      <link>http://www.hellodba.com/Doc/Btree_split_2_grow.html</link>
      <description><![CDATA[当分裂导致B树索引的层数（Btree Level）增加时，我们称之为树的“生长”。当叶子节点分裂时，在其父节点上需要增加一条记录指向新节点，如果此时父节点上没有足够空间，则父节点也会发生分裂，如果如此递归下去，直到根节点也分裂，那么索引的高度就增加了。]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.hellodba.com/Doc/Btree_split_2_grow.html</guid>
      <author>fuyuncat</author>
      <pubDate>Tue, 13 Oct 2009 07:05:10 GMT</pubDate>
      <comments>http://www.hellodba.com/Doc/Btree_split_2_grow.html</comments>
    </item>
    <item>
      <title>B-Tree 索引中的数据块分裂——如何分裂</title>
      <link>http://www.hellodba.com/Doc/BTree_split_1_how.html</link>
      <description><![CDATA[当一个事务需要修改（大多数情况是Insert操作，某些情况下也可能为Delete操作）索引块（枝节点或叶子节点）上的数据，但没有足够空间容纳新的数据（包括索引条目、ITL slot）时，会将原有块上的部分数据放到一个新的数据块上去，这一过程就是索引块分裂。]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.hellodba.com/Doc/BTree_split_1_how.html</guid>
      <author>fuyuncat</author>
      <pubDate>Mon, 12 Oct 2009 08:43:43 GMT</pubDate>
      <comments>http://www.hellodba.com/Doc/BTree_split_1_how.html</comments>
    </item>
    <item>
      <title> 10g中构建“高”索引</title>
      <link>http://www.hellodba.com/Doc/Btree_Idx_height_10g.html</link>
      <description><![CDATA[  B树索引的高度(Btree Level)是影响索引的性能的因素之一，高度的增加，意味着对索引的读的次数的增加。如果索引高度要增加，其必要条件就是左枝或右枝饱和。
  10g中，左分裂的算法被改进，不能再通过左分裂的方法使用少量数据来构建高索引。我们在这的代码以时间换空间，保证在高度增加的同时保持数据量最少。]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.hellodba.com/Doc/Btree_Idx_height_10g.html</guid>
      <author>fuyuncat</author>
      <pubDate>Wed, 07 Oct 2009 01:52:02 GMT</pubDate>
      <comments>http://www.hellodba.com/Doc/Btree_Idx_height_10g.html</comments>
    </item>
    <item>
      <title> Q&amp;A: 为什么在10053Trace文件中没有变量值？</title>
      <link>http://www.hellodba.com/Doc/QA_No_Peek_in_10053.html</link>
      <description><![CDATA[    10053 trace文件为我们分析CBO解析SQL语句的过程提供了非常有用的信息。而在Oracle中，为了提高查询计划的正确性，有一个很重要的特性——绑定变量窥视(Bind Variable Peeking)。10053 Trace文件中跟踪到的“窥视”数据，我们可以更加容易理解优化器为什么会选择某一个查询计划。但是，有时我们却发现在Trace文件没有窥视值，而是显示“No bind buffers allocated”。]]></description>
      <category>文档</category>
      <guid isPermaLink="true">http://www.hellodba.com/Doc/QA_No_Peek_in_10053.html</guid>
      <author>fuyuncat</author>
      <pubDate>Wed, 23 Sep 2009 03:56:27 GMT</pubDate>
      <comments>http://www.hellodba.com/Doc/QA_No_Peek_in_10053.html</comments>
    </item>
  </channel>
</rss>

