<?xml version="1.0" encoding="UTF-8"?> <rss
version="2.0"
xmlns:content="http://purl.org/rss/1.0/modules/content/"
xmlns:wfw="http://wellformedweb.org/CommentAPI/"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:atom="http://www.w3.org/2005/Atom"
xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
><channel><title>Structured Data &#187; 10gR2</title> <atom:link href="http://structureddata.org/category/oracle/10gr2/feed/" rel="self" type="application/rss+xml" /><link>http://structureddata.org</link> <description>Oracle Database Performance and Scalability Blog</description> <lastBuildDate>Mon, 06 Sep 2010 04:50:38 +0000</lastBuildDate> <language>en</language> <sy:updatePeriod>hourly</sy:updatePeriod> <sy:updateFrequency>1</sy:updateFrequency> <generator>http://wordpress.org/?v=3.0.1</generator> <item><title>10.2.0.5 Patch Set For Oracle Database Server</title><link>http://structureddata.org/2010/04/30/10-2-0-5-patch-set-for-oracle-database-server/?utm_source=rss&amp;utm_medium=rss&amp;utm_campaign=10-2-0-5-patch-set-for-oracle-database-server</link> <comments>http://structureddata.org/2010/04/30/10-2-0-5-patch-set-for-oracle-database-server/#comments</comments> <pubDate>Fri, 30 Apr 2010 18:04:25 +0000</pubDate> <dc:creator>Greg Rahn</dc:creator> <category><![CDATA[10gR2]]></category> <category><![CDATA[Oracle]]></category> <category><![CDATA[10.2.0.5]]></category> <category><![CDATA[patch set]]></category><guid
isPermaLink="false">http://structureddata.org/?p=933</guid> <description><![CDATA[Just a quick post that the 10.2.0.5 patch set for Oracle Database Server was released for x86 &#38; x86-64 platforms on April 29th. The patchset number is 8202632 and is available for download from My Oracle Support.]]></description> <wfw:commentRss>http://structureddata.org/2010/04/30/10-2-0-5-patch-set-for-oracle-database-server/feed/</wfw:commentRss> <slash:comments>8</slash:comments> </item> <item><title>DBMS_STATS, METHOD_OPT and FOR ALL INDEXED COLUMNS</title><link>http://structureddata.org/2008/10/14/dbms_stats-method_opt-and-for-all-indexed-columns/?utm_source=rss&amp;utm_medium=rss&amp;utm_campaign=dbms_stats-method_opt-and-for-all-indexed-columns</link> <comments>http://structureddata.org/2008/10/14/dbms_stats-method_opt-and-for-all-indexed-columns/#comments</comments> <pubDate>Tue, 14 Oct 2008 08:00:26 +0000</pubDate> <dc:creator>Greg Rahn</dc:creator> <category><![CDATA[10gR2]]></category> <category><![CDATA[11gR1]]></category> <category><![CDATA[Data Warehousing]]></category> <category><![CDATA[Execution Plans]]></category> <category><![CDATA[Optimizer]]></category> <category><![CDATA[Oracle]]></category> <category><![CDATA[Performance]]></category> <category><![CDATA[SQL Tuning]]></category> <category><![CDATA[Statistics]]></category> <category><![CDATA[Troubleshooting]]></category> <category><![CDATA[cardinality]]></category> <category><![CDATA[DBMS_STATS]]></category> <category><![CDATA[FOR ALL INDEXED COLUMNS]]></category> <category><![CDATA[gather_table_stats]]></category> <category><![CDATA[METHOD_OPT]]></category> <category><![CDATA[selectivity]]></category><guid
isPermaLink="false">http://structureddata.org/?p=190</guid> <description><![CDATA[I&#8217;ve written before on choosing an optimal stats gathering strategy but I recently came across a scenario that I didn&#8217;t directly blog about and think it deserves attention. As I mentioned in that previous post, one should only deviate from the defaults when they have a reason to, and fully understand that reason and the effect of that decision. Understanding METHOD_OPT The METHOD_OPT parameter of DBMS_STATS controls two things: on which columns statistics will be collected on which columns histograms will be collected (and how many buckets) It is very important to understand #1 and how the choice of METHOD_OPT effects the collection of column statistics. Prerequisite: Where Do I Find Column Statistics? Understanding where to find column statistics is vital for troubleshooting bad execution plans. These views will be the arrows in your quiver: USER_TAB_COL_STATISTICS USER_PART_COL_STATISTICS USER_SUBPART_COL_STATISTICS Depending on if the table is partitioned or subpartitioned, and depending on what GRANULARITY the stats were gathered with, the latter two of those views may or may not be populated. The Bane of METHOD_OPT: FOR ALL INDEXED COLUMNS If you are using FOR ALL INDEXED COLUMNS as part of your METHOD_OPT you probably should not be. Allow me to explain. Using [...]]]></description> <wfw:commentRss>http://structureddata.org/2008/10/14/dbms_stats-method_opt-and-for-all-indexed-columns/feed/</wfw:commentRss> <slash:comments>31</slash:comments> </item> <item><title>Oracle 11g: Incremental Global Statistics On Partitioned Tables</title><link>http://structureddata.org/2008/07/16/oracle-11g-incremental-global-statistics-on-partitioned-tables/?utm_source=rss&amp;utm_medium=rss&amp;utm_campaign=oracle-11g-incremental-global-statistics-on-partitioned-tables</link> <comments>http://structureddata.org/2008/07/16/oracle-11g-incremental-global-statistics-on-partitioned-tables/#comments</comments> <pubDate>Wed, 16 Jul 2008 08:00:08 +0000</pubDate> <dc:creator>Greg Rahn</dc:creator> <category><![CDATA[10gR2]]></category> <category><![CDATA[11gR1]]></category> <category><![CDATA[Data Warehousing]]></category> <category><![CDATA[Execution Plans]]></category> <category><![CDATA[Optimizer]]></category> <category><![CDATA[Oracle]]></category> <category><![CDATA[Statistics]]></category> <category><![CDATA[Troubleshooting]]></category> <category><![CDATA[VLDB]]></category> <category><![CDATA[DBMS_STATS]]></category> <category><![CDATA[gather_table_stats]]></category> <category><![CDATA[Incremental Global Stats]]></category> <category><![CDATA[oracle 11g]]></category> <category><![CDATA[synopsis-based statistics gathering]]></category><guid
isPermaLink="false">http://structureddata.org/?p=70</guid> <description><![CDATA[Previously I blogged about the new and improved DBMS_STATS.AUTO_SAMPLE_SIZE used to calculate NDV in Oracle 11g and now I wanted to touch on another new feature of DBMS_STATS in 11g: Incremental Global Statistics On Partitioned Tables. Before Incremental Global Stats (Two-Pass Method) When DBMS_STATS.GATHER_TABLE_STATS collects statistics on a partitioned table, generally it does so at the partition and table (global) level (the default behavior can be modified by changing the GRANULARITY parameter). This is done in two steps. First, partition level stats are gathered by scanning the partition(s) that have stale or empty stats, then a full table scan is executed to gather the global statistics. As more partitions are added to a given table, the longer the execution time for GATHER_TABLE_STATS, due to the full table scan requited for global stats. Using Incremental Global Stats (Synopsis-Based Method) Incremental Global Stats works by collecting stats on partitions and storing a synopsis which is the statistics metadata for that partition and the columns for that partition. This synopsis is stored in the SYSAUX tablespace, but is quite small (only a few kilobytes). Global stats are then created not by reading the entire table, but by aggregating the synopses from each partition. [...]]]></description> <wfw:commentRss>http://structureddata.org/2008/07/16/oracle-11g-incremental-global-statistics-on-partitioned-tables/feed/</wfw:commentRss> <slash:comments>7</slash:comments> </item> <item><title>Using Bitmap Indexes Effectively</title><link>http://structureddata.org/2008/05/29/using-bitmap-indexes-effectively/?utm_source=rss&amp;utm_medium=rss&amp;utm_campaign=using-bitmap-indexes-effectively</link> <comments>http://structureddata.org/2008/05/29/using-bitmap-indexes-effectively/#comments</comments> <pubDate>Thu, 29 May 2008 08:00:20 +0000</pubDate> <dc:creator>Greg Rahn</dc:creator> <category><![CDATA[10gR2]]></category> <category><![CDATA[11gR1]]></category> <category><![CDATA[Data Warehousing]]></category> <category><![CDATA[Execution Plans]]></category> <category><![CDATA[Optimizer]]></category> <category><![CDATA[Performance]]></category> <category><![CDATA[SQL Tuning]]></category> <category><![CDATA[Statistics]]></category> <category><![CDATA[Troubleshooting]]></category> <category><![CDATA[VLDB]]></category> <category><![CDATA[bitmap index]]></category> <category><![CDATA[cardinality]]></category> <category><![CDATA[execution plan]]></category> <category><![CDATA[i/o throughput]]></category> <category><![CDATA[selectivity]]></category><guid
isPermaLink="false">http://structureddata.org/?p=65</guid> <description><![CDATA[Recently I was reading this thread, &#8220;Trying to make use of bitmap indexes&#8221; on the Oracle Forum. Before I had finished a working example, Jonathan Lewis had posted his response which was on par with my thoughts. Since this is a topic I see frequently, I thought I would finish my experiment and publish it here. What We Are Given The author of the original post had stated that the table in question contains about 16 million rows and states: &#8220;The table contains three IDEAL columns for bitmap indexes the first of which may have only two, the second three and the third four distinct values. I was planning to change the index type on these columns to BITMAP [from B-tree].&#8221; To keep the focus of this post narrow, I&#8217;m only going to discuss whether or not one should consider bitmap indexes for queries, and not discuss potential update related issues. The Data For this experiment, I&#8217;m going to create a table that has three columns with the given NDV from above and add in a few extra filler columns to pad it out a bit. Since I do not know the exact table structure, I&#8217;ll just go with a [...]]]></description> <wfw:commentRss>http://structureddata.org/2008/05/29/using-bitmap-indexes-effectively/feed/</wfw:commentRss> <slash:comments>6</slash:comments> </item> <item><title>Null-Aware Anti-Join</title><link>http://structureddata.org/2008/05/22/null-aware-anti-join/?utm_source=rss&amp;utm_medium=rss&amp;utm_campaign=null-aware-anti-join</link> <comments>http://structureddata.org/2008/05/22/null-aware-anti-join/#comments</comments> <pubDate>Thu, 22 May 2008 08:00:46 +0000</pubDate> <dc:creator>Greg Rahn</dc:creator> <category><![CDATA[10gR2]]></category> <category><![CDATA[11gR1]]></category> <category><![CDATA[Data Warehousing]]></category> <category><![CDATA[Execution Plans]]></category> <category><![CDATA[Optimizer]]></category> <category><![CDATA[Oracle]]></category> <category><![CDATA[Performance]]></category> <category><![CDATA[execution plan]]></category> <category><![CDATA[filter]]></category> <category><![CDATA[lnnvl]]></category> <category><![CDATA[null-aware anti-join]]></category><guid
isPermaLink="false">http://structureddata.org/?p=64</guid> <description><![CDATA[Recently someone showed me a query execution plan with an operation of HASH JOIN ANTI NA. At first, it was thought maybe it was a bug and the operation had a type-o in it, but after further research it was discovered it was a valid operation and a new cost-based query transformation for subquery unnesting in Oracle Database 11g. The NA stands for Null-Aware. There is also a second type of Null-Aware Anti-Join, which is the Single Null-Aware Anti-Join which is displayed in the execution plan as ANTI SNA. The null-aware anti-join may be computed using each of the three types of of join operations: the sort-merge join, hash join and nested loops join. What is the advantage of a Null-Aware Anti-Join? If we look at the patent application for Null-Aware Anti-Joins we will see that paragraph 0006 gives a brief description: [0006] A common type of query that is optimized is a query that contains a subquery whose join condition involves the NOT IN/ALL operator (NOT IN is equivalent to != ALL). In data-warehouses with reporting applications, such queries and subqueries are usually evaluated on very large sets of data. Thus, it is critical to make such queries scale [...]]]></description> <wfw:commentRss>http://structureddata.org/2008/05/22/null-aware-anti-join/feed/</wfw:commentRss> <slash:comments>7</slash:comments> </item> <item><title>Choosing An Optimal Stats Gathering Strategy</title><link>http://structureddata.org/2008/03/26/choosing-an-optimal-stats-gathering-strategy/?utm_source=rss&amp;utm_medium=rss&amp;utm_campaign=choosing-an-optimal-stats-gathering-strategy</link> <comments>http://structureddata.org/2008/03/26/choosing-an-optimal-stats-gathering-strategy/#comments</comments> <pubDate>Wed, 26 Mar 2008 08:00:38 +0000</pubDate> <dc:creator>Greg Rahn</dc:creator> <category><![CDATA[10gR2]]></category> <category><![CDATA[Execution Plans]]></category> <category><![CDATA[Optimizer]]></category> <category><![CDATA[Oracle]]></category> <category><![CDATA[Statistics]]></category> <category><![CDATA[Troubleshooting]]></category> <category><![CDATA[auto_sample_size]]></category> <category><![CDATA[bind peeking]]></category> <category><![CDATA[DBMS_STATS]]></category> <category><![CDATA[histograms]]></category> <category><![CDATA[out-of-range predicates]]></category> <category><![CDATA[stats gathering strategy]]></category><guid
isPermaLink="false">http://structureddata.org/2008/03/26/choosing-an-optimal-stats-gathering-strategy/</guid> <description><![CDATA[Recently the Oracle Optimizer Development Team put out a White Paper entitled Upgrading from Oracle Database 9i to 10g: What to expect from the Optimizer. This paper discusses the main differences between 9i and 10g in the subject area of the Optimizer and Statistics. As G.I. Joe said, &#8220;Now we know! And knowing is half the battle.&#8221; The other half of the battle is successfully applying that knowledge to the databases that you manage. Statistics are input to the Oracle Optimizer and the foundation of good plans. If the statistics supplied to the Oracle Optimizer are non-representative we can probably expect GIGO (Garbage In, Garbage Out). On the other hand, if the statistics are representative, chances quite good that the Oracle Optimizer will choose the optimal plan. In this post I&#8217;d like to discuss my thoughts on how to choose an optimal stats gathering strategy. Suggested Readings If you haven&#8217;t done so already, I would first suggest reading the following: 10g Release 2: Managing Optimizer Statistics Oracle OpenWorld 2005: A Practical Approach to Optimizer Statistics in Oracle Database 10g Upgrading from Oracle Database 9i to 10g: What to expect from the Optimizer Start With A Clean Slate My first recommendation [...]]]></description> <wfw:commentRss>http://structureddata.org/2008/03/26/choosing-an-optimal-stats-gathering-strategy/feed/</wfw:commentRss> <slash:comments>20</slash:comments> </item> <item><title>There Is No Time Like &#039;%NOW%&#039; To Use Dynamic Sampling</title><link>http://structureddata.org/2008/03/05/there-is-no-time-like-now-to-use-dynamic-sampling/?utm_source=rss&amp;utm_medium=rss&amp;utm_campaign=there-is-no-time-like-now-to-use-dynamic-sampling</link> <comments>http://structureddata.org/2008/03/05/there-is-no-time-like-now-to-use-dynamic-sampling/#comments</comments> <pubDate>Wed, 05 Mar 2008 09:00:16 +0000</pubDate> <dc:creator>Greg Rahn</dc:creator> <category><![CDATA[10gR2]]></category> <category><![CDATA[11gR1]]></category> <category><![CDATA[Data Warehousing]]></category> <category><![CDATA[Execution Plans]]></category> <category><![CDATA[Optimizer]]></category> <category><![CDATA[Oracle]]></category> <category><![CDATA[Performance]]></category> <category><![CDATA[SQL Tuning]]></category> <category><![CDATA[Statistics]]></category> <category><![CDATA[VLDB]]></category> <category><![CDATA[5% selectivity]]></category> <category><![CDATA[cardinality]]></category> <category><![CDATA[dynamic sampling]]></category><guid
isPermaLink="false">http://structureddata.org/2008/03/05/there-is-no-time-like-now-to-use-dynamic-sampling/</guid> <description><![CDATA[I recently came across a query in which the Optimizer was making a poor cardinality estimate, which in turn caused inefficient join type, which in turn caused the query to run excessively long. This post is a reenactment of my troubleshooting. The Suspect SQL The original SQL was quite large and had a fairly complex plan so I simplified it down to this test case for the purpose of this blog post: select [...] from fact_table al1 where al1.region = '003' and al1.order_type = 'Z010' and al1.business_type in ('002', '003', '007', '009') and (not (al1.cust_po like '%MATERIAL HANDLING%' or al1.cust_po like '%SECURITY%' or al1.cust_po like '%SUMMER OF CREATIVITY%' or al1.cust_po like '%TEST%')); ---------------------------------------------------------------------------- &#124; Id &#124; Operation &#124; Name &#124; Rows &#124; ---------------------------------------------------------------------------- &#124; 0 &#124; SELECT STATEMENT &#124; &#124; 1 &#124; &#124; 1 &#124; SORT AGGREGATE &#124; &#124; 1 &#124; &#124; 2 &#124; PARTITION LIST SINGLE &#124; &#124; 9 &#124; &#124; 3 &#124; PARTITION HASH ALL &#124; &#124; 9 &#124; &#124;* 4 &#124; TABLE ACCESS BY LOCAL INDEX ROWID&#124; FACT_TABLE &#124; 9 &#124; &#124; 5 &#124; BITMAP CONVERSION TO ROWIDS &#124; &#124; &#124; &#124;* 6 &#124; BITMAP INDEX SINGLE VALUE &#124; FACT_BX10 &#124; &#124; ---------------------------------------------------------------------------- Predicate Information (identified by [...]]]></description> <wfw:commentRss>http://structureddata.org/2008/03/05/there-is-no-time-like-now-to-use-dynamic-sampling/feed/</wfw:commentRss> <slash:comments>11</slash:comments> </item> <item><title>What Are Your System Statistics?</title><link>http://structureddata.org/2008/01/02/what-are-your-system-statistics/?utm_source=rss&amp;utm_medium=rss&amp;utm_campaign=what-are-your-system-statistics</link> <comments>http://structureddata.org/2008/01/02/what-are-your-system-statistics/#comments</comments> <pubDate>Wed, 02 Jan 2008 23:00:55 +0000</pubDate> <dc:creator>Greg Rahn</dc:creator> <category><![CDATA[10gR2]]></category> <category><![CDATA[11gR1]]></category> <category><![CDATA[Execution Plans]]></category> <category><![CDATA[Optimizer]]></category> <category><![CDATA[Oracle]]></category> <category><![CDATA[Performance]]></category> <category><![CDATA[SQL Tuning]]></category> <category><![CDATA[Statistics]]></category> <category><![CDATA[aux_stats$]]></category> <category><![CDATA[system statistics]]></category><guid
isPermaLink="false">http://structureddata.org/2008/01/02/what-are-your-system-statistics/</guid> <description><![CDATA[I&#8217;ve been working on a few test cases and I&#8217;m in search of some real-world data. If your production Oracle database uses system statistics, either Workload Statistics or Noworkload Statistics, and you are willing to share them, please post a comment with the output from the following two queries: select version from v$instance; select pname, pval1 from sys.aux_stats$ where sname = 'SYSSTATS_MAIN'; For example, my noworkload system statistics look like this: SQL> select version from v$instance; VERSION ----------------- 11.1.0.6.0 SQL> select pname, pval1 from sys.aux_stats$ where sname = 'SYSSTATS_MAIN'; PNAME PVAL1 ------------------------------ ---------- CPUSPEED CPUSPEEDNW 726.951 IOSEEKTIM 4.683 IOTFRSPEED 36625.24 MAXTHR MBRC MREADTIM SLAVETHR SREADTIM To help with fixed width formatting (pretty printing), please surround your results in the comment text box with a pre tag like such: &#60;pre&#62; blah blah blah &#60;/pre&#62; Thanks for participating! Quick link to 10.2 System Statistics Documentation for those unfamiliar with it.]]></description> <wfw:commentRss>http://structureddata.org/2008/01/02/what-are-your-system-statistics/feed/</wfw:commentRss> <slash:comments>32</slash:comments> </item> <item><title>Oracle 11g: Enhancements to DBMS_STATS</title><link>http://structureddata.org/2007/09/17/oracle-11g-enhancements-to-dbms_stats/?utm_source=rss&amp;utm_medium=rss&amp;utm_campaign=oracle-11g-enhancements-to-dbms_stats</link> <comments>http://structureddata.org/2007/09/17/oracle-11g-enhancements-to-dbms_stats/#comments</comments> <pubDate>Mon, 17 Sep 2007 19:30:27 +0000</pubDate> <dc:creator>Greg Rahn</dc:creator> <category><![CDATA[10gR2]]></category> <category><![CDATA[11gR1]]></category> <category><![CDATA[Data Warehousing]]></category> <category><![CDATA[Optimizer]]></category> <category><![CDATA[Oracle]]></category> <category><![CDATA[Performance]]></category> <category><![CDATA[Statistics]]></category><guid
isPermaLink="false">http://structureddata.org/2007/09/17/oracle-11g-enhancements-to-dbms_stats/</guid> <description><![CDATA[Many of you are aware of the Oracle 11g Database New Features and while some may be generally interested in new features, one area that I focus on is new features that yield gains in performance. Some of these features can be found in the General Server Performance section of the Oracle 11g Database New Features documentation. There is one area (for now&#8230;) that didn&#8217;t make this list but I feel is worth mentioning &#8211; performance enhancements made to DBMS_STATS. The Necessity of Representative Statistics Representative statistics are the foundation that the Optimizer relies on to make the best decisions when choosing execution plans. One recent blog post from Don Seiler, with the help of Wolfgang Breitling, is a prefect real-world case. This blog post dealt with out-of-range values, but one other case that often causes headaches is data skew. In the Real-World Performance Roundtable, Part II session at OracleWorld 2006, I discussed a basic stats gathering strategy that dealt with the exception case of data skew. When using the DBMS_STATS default of DBMS_STATS.AUTO_SAMPLE_SIZE in 10g and 9i, the NDV (Number of Distinct Values) may be statistically inaccurate when there is significant data skew. In order to deal with this [...]]]></description> <wfw:commentRss>http://structureddata.org/2007/09/17/oracle-11g-enhancements-to-dbms_stats/feed/</wfw:commentRss> <slash:comments>16</slash:comments> </item> </channel> </rss>
<!-- Performance optimized by W3 Total Cache. Learn more: http://www.w3-edge.com/wordpress-plugins/

Minified using disk
Page Caching using disk (user agent is rejected)
Database Caching 6/12 queries in 0.009 seconds using disk

Served from: structureddata.org @ 2010-09-07 02:11:19 -->