<?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; Execution Plans</title> <atom:link href="http://structureddata.org/category/oracle/execution-plans/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>The Impact Of Good Table And Query Design</title><link>http://structureddata.org/2009/03/19/the-impact-of-good-table-and-query-design/?utm_source=rss&amp;utm_medium=rss&amp;utm_campaign=the-impact-of-good-table-and-query-design</link> <comments>http://structureddata.org/2009/03/19/the-impact-of-good-table-and-query-design/#comments</comments> <pubDate>Thu, 19 Mar 2009 10:00:24 +0000</pubDate> <dc:creator>Greg Rahn</dc:creator> <category><![CDATA[11gR1]]></category> <category><![CDATA[Data Warehousing]]></category> <category><![CDATA[Execution Plans]]></category> <category><![CDATA[Oracle]]></category> <category><![CDATA[SQL Tuning]]></category> <category><![CDATA[VLDB]]></category> <category><![CDATA[pivot]]></category> <category><![CDATA[pivot table]]></category> <category><![CDATA[star schema]]></category> <category><![CDATA[table design]]></category> <category><![CDATA[unpivot]]></category><guid
isPermaLink="false">http://structureddata.org/?p=436</guid> <description><![CDATA[There are many ways to design tables/schemas and many ways to write SQL queries that execute against those tables/schemas. Some designs are better than others for various reasons, however, I think that frequently people underestimate the power of SQL (for both &#8220;good&#8221; and &#8220;evil&#8221;). All too often in data warehouses, I see tables designed for one specific report, or a very select few reports. These tables frequently resemble Microsoft Excel Spreadsheets (generally Pivot Tables), not good Dimensional (Star Schema) or Third Normal Form (3NF) schema design. The problem with such designs is that it severely limits the usefulness of that data, as queries that were not known at the time of design often time become problematic. The following is a simple one table example, derived from a field experience in which I discuss two table designs and provide the SQL queries to answer a question the business is seeking. The Business Question First lets start with the business question for which the answer is being sought. What customers meet the following criteria: do not own PRODUCT1 or PRODUCT2 but have downloaded SOFTWARE do not own PRODUCT2 and it has been more than 90 days between SOFTWARE download and their purchase [...]]]></description> <wfw:commentRss>http://structureddata.org/2009/03/19/the-impact-of-good-table-and-query-design/feed/</wfw:commentRss> <slash:comments>7</slash:comments> </item> <item><title>Managing Optimizer Statistics Paper</title><link>http://structureddata.org/2009/02/16/managing-optimizer-statistics-paper/?utm_source=rss&amp;utm_medium=rss&amp;utm_campaign=managing-optimizer-statistics-paper</link> <comments>http://structureddata.org/2009/02/16/managing-optimizer-statistics-paper/#comments</comments> <pubDate>Mon, 16 Feb 2009 09:00:23 +0000</pubDate> <dc:creator>Greg Rahn</dc:creator> <category><![CDATA[Execution Plans]]></category> <category><![CDATA[Optimizer]]></category> <category><![CDATA[Statistics]]></category> <category><![CDATA[correlated columns]]></category> <category><![CDATA[dynamic sampling]]></category><guid
isPermaLink="false">http://structureddata.org/?p=380</guid> <description><![CDATA[Over the past couple days I&#8217;ve been reading through the recent paper by Karen Morton entitled &#8220;Managing Statistics for Optimal Query Performance&#8220;. In this paper Karen goes over many of the topics I have discussed as well (and a few that I have not) in the following blog posts: Troubleshooting Bad Execution Plans There Is No Time Like ‘NOW%’ To Use Dynamic Sampling Choosing An Optimal Stats Gathering Strategy DBMS_STATS, METHOD_OPT and FOR ALL INDEXED COLUMNS Overall I think Karen does a good job discussing the key issues related to object statistics and has examples to assist in understanding where and why issues can arise. I&#8217;m also a fan of works that do not project an answer, but rather provide information, how to use that information, use working examples, and ultimately leaves the reader with the task of how to best apply the new found knowledge to their environment. I would recommend to all to give it a read. Comments On Dynamic Sampling In section 5.1 on page 22 Karen discusses using dynamic sampling, of particular interest she has a table of statistics from Robyn Sands that compares two different runs of some application jobs both using optimizer_dynamic_sampling=4. One uses [...]]]></description> <wfw:commentRss>http://structureddata.org/2009/02/16/managing-optimizer-statistics-paper/feed/</wfw:commentRss> <slash:comments>7</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>Automatic DB_FILE_MULTIBLOCK_READ_COUNT</title><link>http://structureddata.org/2008/08/14/automatic-db_file_multiblock_read_count/?utm_source=rss&amp;utm_medium=rss&amp;utm_campaign=automatic-db_file_multiblock_read_count</link> <comments>http://structureddata.org/2008/08/14/automatic-db_file_multiblock_read_count/#comments</comments> <pubDate>Thu, 14 Aug 2008 12:00:39 +0000</pubDate> <dc:creator>Greg Rahn</dc:creator> <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[Automatic DB_FILE_MULTIBLOCK_READ_COUNT]]></category> <category><![CDATA[block size]]></category><guid
isPermaLink="false">http://structureddata.org/?p=76</guid> <description><![CDATA[Note: Originally this experiment was from a post I wrote on the Oracle Forum: Database &#8211; General. I recommend that you read Jonathan Lewis&#8217; summarization of the thread instead of reading all 671 posts (as of today). You will spend much less time and get more out of the discussion. One of the new features that was released in 10gR2 is the automatic DB_FILE_MULTIBLOCK_READ_COUNT. Below are portions from the documentation that describe this feature. Oracle Database 10g New Features The DB_FILE_MULTIBLOCK_READ_COUNT parameter controls the amount of block prefetching done in the buffer cache during scan operations, such as full table scan and index fast full scan. The value of this parameter can have a significant impact on the overall database performance. This feature enables Oracle Database to automatically select the appropriate value for this parameter depending on the operating system optimal I/O size and the size of the buffer cache. This feature simplifies manageability by automating the tuning of DB_FILE_MULTIBLOCK_READ_COUNT initialization parameter. Oracle Database Performance Tuning Guide This parameter specifies the number of blocks that are read in a single I/O during a full table scan or index fast full scan. The optimizer uses the value of DB_FILE_MULTIBLOCK_READ_COUNT to cost [...]]]></description> <wfw:commentRss>http://structureddata.org/2008/08/14/automatic-db_file_multiblock_read_count/feed/</wfw:commentRss> <slash:comments>13</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>ANSI Outer Joins And Lateral Views</title><link>http://structureddata.org/2008/02/18/ansi-outer-joins-and-lateral-views/?utm_source=rss&amp;utm_medium=rss&amp;utm_campaign=ansi-outer-joins-and-lateral-views</link> <comments>http://structureddata.org/2008/02/18/ansi-outer-joins-and-lateral-views/#comments</comments> <pubDate>Tue, 19 Feb 2008 02:00:20 +0000</pubDate> <dc:creator>Greg Rahn</dc:creator> <category><![CDATA[Execution Plans]]></category> <category><![CDATA[Optimizer]]></category> <category><![CDATA[Oracle]]></category> <category><![CDATA[SQL Tuning]]></category> <category><![CDATA[Troubleshooting]]></category> <category><![CDATA[ANSI outer join]]></category> <category><![CDATA[lateral view]]></category> <category><![CDATA[Oracle outer join]]></category> <category><![CDATA[wrong results]]></category><guid
isPermaLink="false">http://structureddata.org/2008/02/18/ansi-outer-joins-and-lateral-views/</guid> <description><![CDATA[A few months ago the Oracle Optimizer Team did a blog post entitled Outerjoins in Oracle. In the Lateral View section of that post they go through some examples and discuss how a query is transformed with the ANSI outer join syntax. I thought it would be useful to go through an example that recently came through the Real-World Performance Group. For simplicity purposes and so that you can play along at home, the test case has been recreated to use EMP and DEPT which have been created and populated via the $ORACLE_HOME/rdbms/admin/utlsampl.sql script. The Three Test Cases Consider the following three SQL statements: Query A: Oracle Outer Join Syntax SELECT d.dname, d.deptno, e.ename FROM dept d, emp e WHERE d.deptno = e.deptno(+) and d.deptno in (10,40) Query B: ANSI Outer Join Syntax Version 1 SELECT d.dname, d.deptno, e.ename FROM dept d LEFT OUTER JOIN emp e ON d.deptno = e.deptno WHERE d.deptno in (10,40) Query C: ANSI Outer Join Syntax Version 2 SELECT d.dname, d.deptno, e.ename FROM dept d LEFT OUTER JOIN emp e ON d.deptno = e.deptno and d.deptno in (10,40) Do note the slight difference between the two ANSI versions: Query B has the filter predicate in [...]]]></description> <wfw:commentRss>http://structureddata.org/2008/02/18/ansi-outer-joins-and-lateral-views/feed/</wfw:commentRss> <slash:comments>18</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 4/12 queries in 0.009 seconds using disk

Served from: structureddata.org @ 2010-09-09 10:16:42 -->