<?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; Statistics</title> <atom:link href="http://structureddata.org/category/oracle/statistics/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>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>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 Optimizer Development Team Starts A Blog</title><link>http://structureddata.org/2007/12/05/oracle-optimizer-development-team-starts-a-blog/?utm_source=rss&amp;utm_medium=rss&amp;utm_campaign=oracle-optimizer-development-team-starts-a-blog</link> <comments>http://structureddata.org/2007/12/05/oracle-optimizer-development-team-starts-a-blog/#comments</comments> <pubDate>Wed, 05 Dec 2007 18:30:56 +0000</pubDate> <dc:creator>Greg Rahn</dc:creator> <category><![CDATA[Execution Plans]]></category> <category><![CDATA[Optimizer]]></category> <category><![CDATA[Oracle]]></category> <category><![CDATA[Performance]]></category> <category><![CDATA[Statistics]]></category> <category><![CDATA[Troubleshooting]]></category> <category><![CDATA[cbo]]></category><guid
isPermaLink="false">http://structureddata.org/2007/12/05/oracle-optimizer-development-team-starts-a-blog/</guid> <description><![CDATA[Since the introduction of the Cost Based Optimizer (CBO) in Oracle 7.0, people have been both fascinated and terrified by it and the statistics that feed it. There has long been a belief that a degree in witchcraft or black magic is required to successfully work with the CBO. Some people feel this shroud of mystery is caused in part by the lack of documentation or detailed examples about the Optimizer. In order to help remove this shroud and the black magic that surround the Optimizer, the development team responsible for it have started a blog. The blog postings will give in-depth descriptions of the technology behind the CBO, as well as practical advice like best practices for using the Optimizer. Their first blog post, Why are there more cursors in 11g for my query containing bind variables? went up on December 3rd and it discusses the controversial topic of Bind Peeking and how it has been enhanced in 11g. I recommend you check out their blog at http://optimizermagic.blogspot.com.]]></description> <wfw:commentRss>http://structureddata.org/2007/12/05/oracle-optimizer-development-team-starts-a-blog/feed/</wfw:commentRss> <slash:comments>8</slash:comments> </item> <item><title>Troubleshooting Bad Execution Plans</title><link>http://structureddata.org/2007/11/21/troubleshooting-bad-execution-plans/?utm_source=rss&amp;utm_medium=rss&amp;utm_campaign=troubleshooting-bad-execution-plans</link> <comments>http://structureddata.org/2007/11/21/troubleshooting-bad-execution-plans/#comments</comments> <pubDate>Wed, 21 Nov 2007 10:00:12 +0000</pubDate> <dc:creator>Greg Rahn</dc:creator> <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[DBMS_STATS]]></category><guid
isPermaLink="false">http://structureddata.org/2007/11/21/troubleshooting-bad-execution-plans/</guid> <description><![CDATA[One of the most common performance issues DBAs encounter are bad execution plans. Many try to resolve bad executions plans by setting optimizer related parameters or even hidden underscore parameters. Some even try to decipher a long and complex 10053 trace in hopes to find an answer. While changing parameters or analyzing a 10053 trace might be useful for debugging at some point, I feel there is a much more simple way to start to troubleshoot bad execution plans. Verify The Query Matches The Business Question This seems like an obvious thing to do, but I&#8217;ve seen numerous cases where the SQL query does not match the business question being asked. Do a quick sanity check verifying things like: join columns, group by, subqueries, etc. The last thing you want to do is consume time trying to debug a bad plan for an improperly written SQL query. Frequently I&#8217;ve found that this is the case for many of those &#8220;I&#8217;ve never got it to run to completion&#8221; queries. What Influences The Execution Plan I think it&#8217;s important to understand what variables influence the Optimizer in order to focus the debugging effort. There are quite a number of variables, but frequently [...]]]></description> <wfw:commentRss>http://structureddata.org/2007/11/21/troubleshooting-bad-execution-plans/feed/</wfw:commentRss> <slash:comments>30</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.010 seconds using disk

Served from: structureddata.org @ 2010-09-07 02:23:32 -->