<?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; Troubleshooting</title> <atom:link href="http://structureddata.org/category/oracle/troubleshooting/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>Glenn Fawcetts&#039;s Oracle Analysis 101</title><link>http://structureddata.org/2008/12/10/glenn-fawcettss-oracle-analysis-101/?utm_source=rss&amp;utm_medium=rss&amp;utm_campaign=glenn-fawcettss-oracle-analysis-101</link> <comments>http://structureddata.org/2008/12/10/glenn-fawcettss-oracle-analysis-101/#comments</comments> <pubDate>Wed, 10 Dec 2008 15:53:13 +0000</pubDate> <dc:creator>Greg Rahn</dc:creator> <category><![CDATA[Performance]]></category> <category><![CDATA[Troubleshooting]]></category> <category><![CDATA[10046 event]]></category> <category><![CDATA[AWR]]></category> <category><![CDATA[debug]]></category> <category><![CDATA[oracle performance]]></category> <category><![CDATA[sql trace]]></category> <category><![CDATA[statspack]]></category><guid
isPermaLink="false">http://structureddata.org/?p=316</guid> <description><![CDATA[Glenn Fawcett has put together a nice slide deck entitled &#8220;Oracle Analysis 101&#8221; that discusses techniques to collect and analyze performance data related to Oracle databases. It&#8217;s a good read so check it out. Glenn is also a great resource for Oracle on Sun Niagara 2 Processors (CMT) so be sure to peek at his other blog posts as well.]]></description> <wfw:commentRss>http://structureddata.org/2008/12/10/glenn-fawcettss-oracle-analysis-101/feed/</wfw:commentRss> <slash:comments>1</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>Understanding Performance</title><link>http://structureddata.org/2008/09/08/understanding-performance/?utm_source=rss&amp;utm_medium=rss&amp;utm_campaign=understanding-performance</link> <comments>http://structureddata.org/2008/09/08/understanding-performance/#comments</comments> <pubDate>Mon, 08 Sep 2008 08:50:40 +0000</pubDate> <dc:creator>Greg Rahn</dc:creator> <category><![CDATA[Oracle]]></category> <category><![CDATA[Performance]]></category> <category><![CDATA[Troubleshooting]]></category> <category><![CDATA[assm]]></category> <category><![CDATA[block size]]></category> <category><![CDATA[bug 6918210]]></category> <category><![CDATA[dtrace]]></category> <category><![CDATA[pctfree]]></category> <category><![CDATA[pstack]]></category><guid
isPermaLink="false">http://structureddata.org/?p=88</guid> <description><![CDATA[There has been some debate in forumsphere/blogosphere centered around Steve Karam&#8217;s observation of a 20x elapsed time difference in an update statement &#8220;by only changing the block size&#8221;. At this point in time, it is pretty much understood (I hope) that this performance delta is directly related to bug 6918210. This bug manifests its nasty head when the following conditions exist: table in an ASSM tablespace 16KB or 32KB block size row migrations at the ASSM storage layer You might ask what are &#8220;row migrations&#8220;? Row migrations are generally caused by too low of a PCTFREE setting on the table. When row has grown in length due to an UPDATE and no longer fits in the current block it is migrated to a new block in which there is enough space for it. This migration is an insert followed by an delete at the storage layer. Jonathan Lewis gets the credit for putting the test case (alt. URL) together that reproduces performance bug. Since then I&#8217;ve run the test case numerous times, with some slight modifications, but I would like to note directly some results that I observed by modifying PCTFREE. These tests were executed on 10.2.0.4 using 200,000 rows [...]]]></description> <wfw:commentRss>http://structureddata.org/2008/09/08/understanding-performance/feed/</wfw:commentRss> <slash:comments>5</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>Awareness Test</title><link>http://structureddata.org/2008/03/21/awareness-test/?utm_source=rss&amp;utm_medium=rss&amp;utm_campaign=awareness-test</link> <comments>http://structureddata.org/2008/03/21/awareness-test/#comments</comments> <pubDate>Fri, 21 Mar 2008 21:30:01 +0000</pubDate> <dc:creator>Greg Rahn</dc:creator> <category><![CDATA[Oracle]]></category> <category><![CDATA[Troubleshooting]]></category><guid
isPermaLink="false">http://structureddata.org/2008/03/21/awareness-test/</guid> <description><![CDATA[I came across this video the other day and I immediately thought of rule #3 from my Got Root Cause? post: &#8220;Be detail oriented, but do not become too obsessed with any one detail.&#8220; Watch the video and see if you pass the Awareness Test. Most importantly, remember the punch line of the video the next time you are troubleshooting.]]></description> <wfw:commentRss>http://structureddata.org/2008/03/21/awareness-test/feed/</wfw:commentRss> <slash:comments>2</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>Oracle Myth Busting: Show, Don&#039;t Tell</title><link>http://structureddata.org/2007/12/16/oracle-myth-busting-show-dont-tell/?utm_source=rss&amp;utm_medium=rss&amp;utm_campaign=oracle-myth-busting-show-dont-tell</link> <comments>http://structureddata.org/2007/12/16/oracle-myth-busting-show-dont-tell/#comments</comments> <pubDate>Mon, 17 Dec 2007 07:30:48 +0000</pubDate> <dc:creator>Greg Rahn</dc:creator> <category><![CDATA[Oracle]]></category> <category><![CDATA[Troubleshooting]]></category> <category><![CDATA[oracle information polution]]></category> <category><![CDATA[oracle myths]]></category><guid
isPermaLink="false">http://structureddata.org/2007/12/16/oracle-myth-busting-show-dont-tell/</guid> <description><![CDATA[Richard Foote has recently started blogging (as of December 11th) and one of his recent posts discusses Oracle Myths and Information Pollution. I find this topic very interesting as I&#8217;m always amazed at the number of people who make changes to their production database based on the results from their favorite Internet search engine, and don&#8217;t even bother to test it themselves first! Like Richard, I&#8217;d encourage anyone who gets information from the Internet to do your diligence and understand the why, and not just the results someone else observed. I guess one could associate it to third grade arithmetic, where having the answer (or making a claim) is not sufficient, one must show their work to get full credit. This way even if the answer (or claim) is incorrect, one can understand the line of thought and where the &#8220;miscalculation&#8221; took place. I&#8217;m also adding Richard Foote to my blogroll. Bloggers&#8217; Note: In this post I was going to use a reference to masses of lemmings running off a cliff, but then I found out that is a myth also. Amazing what a little research turns up&#8230;]]></description> <wfw:commentRss>http://structureddata.org/2007/12/16/oracle-myth-busting-show-dont-tell/feed/</wfw:commentRss> <slash:comments>1</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 3/12 queries in 0.069 seconds using disk

Served from: structureddata.org @ 2010-09-07 02:10:24 -->