<?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; SQL Tuning</title> <atom:link href="http://structureddata.org/category/oracle/sql-tuning/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 Core Performance Fundamentals Of Oracle Data Warehousing – Set Processing vs Row Processing</title><link>http://structureddata.org/2010/07/20/the-core-performance-fundamentals-of-oracle-data-warehousing-%e2%80%93-set-processing-vs-row-processing/?utm_source=rss&amp;utm_medium=rss&amp;utm_campaign=the-core-performance-fundamentals-of-oracle-data-warehousing-%25e2%2580%2593-set-processing-vs-row-processing</link> <comments>http://structureddata.org/2010/07/20/the-core-performance-fundamentals-of-oracle-data-warehousing-%e2%80%93-set-processing-vs-row-processing/#comments</comments> <pubDate>Tue, 20 Jul 2010 09:00:38 +0000</pubDate> <dc:creator>Greg Rahn</dc:creator> <category><![CDATA[Data Warehousing]]></category> <category><![CDATA[Exadata]]></category> <category><![CDATA[Oracle]]></category> <category><![CDATA[Performance]]></category> <category><![CDATA[SQL Tuning]]></category> <category><![CDATA[VLDB]]></category> <category><![CDATA[Oracle Exadata]]></category> <category><![CDATA[row processing]]></category> <category><![CDATA[set processing]]></category><guid
isPermaLink="false">http://structureddata.org/?p=939</guid> <description><![CDATA[[back to Introduction] In over six years of doing data warehouse POCs and benchmarks for clients there is one area that I frequently see as problematic: &#8220;batch jobs&#8221;.  Most of the time these &#8220;batch jobs&#8221; take the form of some PL/SQL procedures and packages that generally perform some data load, transformation, processing or something similar.  The reason these are so problematic is that developers have hard-coded &#8220;slow&#8221; into them.  I&#8217;m generally certain these developers didn&#8217;t know they had done this when they coded their PL/SQL, but none the less it happened. So How Did &#8220;Slow&#8221; Get Hard-Coded Into My PL/SQL? Generally &#8220;slow&#8221; gets hard-coded into PL/SQL because the PL/SQL developer(s) took the business requirements and did a &#8220;literal translation&#8221; of each rule/requirement one at a time instead of looking at the &#8220;before picture&#8221; and the &#8220;after picture&#8221; and determining the most efficient way to make those data changes.  Many times this can surface as cursor based row-by-row processing, but it also can appear as PL/SQL just running a series of often poorly thought out SQL commands. Hard-Coded Slow Case Study The following is based on a true story. Only the facts names have been changed to protect the innocent. Here is [...]]]></description> <wfw:commentRss>http://structureddata.org/2010/07/20/the-core-performance-fundamentals-of-oracle-data-warehousing-%e2%80%93-set-processing-vs-row-processing/feed/</wfw:commentRss> <slash:comments>21</slash:comments> </item> <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>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>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>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> <item><title>Oracle 11g: Real-Time SQL Monitoring Using DBMS_SQLTUNE.REPORT_SQL_MONITOR</title><link>http://structureddata.org/2008/01/06/oracle-11g-real-time-sql-monitoring-using-dbms_sqltunereport_sql_monitor/?utm_source=rss&amp;utm_medium=rss&amp;utm_campaign=oracle-11g-real-time-sql-monitoring-using-dbms_sqltunereport_sql_monitor</link> <comments>http://structureddata.org/2008/01/06/oracle-11g-real-time-sql-monitoring-using-dbms_sqltunereport_sql_monitor/#comments</comments> <pubDate>Mon, 07 Jan 2008 00:00:13 +0000</pubDate> <dc:creator>Greg Rahn</dc:creator> <category><![CDATA[11gR1]]></category> <category><![CDATA[Execution Plans]]></category> <category><![CDATA[Oracle]]></category> <category><![CDATA[Performance]]></category> <category><![CDATA[SQL Tuning]]></category> <category><![CDATA[Troubleshooting]]></category> <category><![CDATA[DBMS_SQLTUNE.REPORT_SQL_MONITOR]]></category> <category><![CDATA[oracle 11g]]></category> <category><![CDATA[Real-Time SQL Monitoring]]></category><guid
isPermaLink="false">http://structureddata.org/2008/01/06/oracle-11g-real-time-sql-monitoring-using-dbms_sqltunereport_sql_monitor/</guid> <description><![CDATA[Many times a DBA wants to know where a SQL statement is in its execution plan and where the time is being spent. There are a few ways to find out this information, but an 11g new feature makes gathering this information extremely easy. Oracle 11g Real-Time SQL Monitoring allows you to monitor the performance of SQL statements while they are executing as well as see the breakdown of time and resources used for recently completed statements. It is on by default when STATISTICS_LEVEL is set to to ALL or TYPICAL (the default value) and monitors statements that consume more than 5 seconds of CPU or IO time, as well as any parallel execution (PQ, PDML, PDDL). One can override the default actions by using the MONITOR or NO_MONITOR hint. The 11g Documentation has a text version of a SQL Monitor Report but the report output can be html, text or xml. Real-Time SQL Monitoring Report Walkthrough To demonstrate the Real-Time SQL Monitoring feature, I started a parallel query and every 60 seconds or so I captured a Real-Time SQL Monitoring report in html format using DBMS_SQLTUNE.REPORT_SQL_MONITOR. Reports 1 through 4 are captures while the query is executing, Report 5 [...]]]></description> <wfw:commentRss>http://structureddata.org/2008/01/06/oracle-11g-real-time-sql-monitoring-using-dbms_sqltunereport_sql_monitor/feed/</wfw:commentRss> <slash:comments>18</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>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 6/12 queries in 0.044 seconds using disk

Served from: structureddata.org @ 2010-09-09 10:10:32 -->