<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	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:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: Analysing Statspack (1)</title>
	<atom:link href="http://jonathanlewis.wordpress.com/2006/11/29/analysing-statspack-pt1/feed/" rel="self" type="application/rss+xml" />
	<link>http://jonathanlewis.wordpress.com/2006/11/29/analysing-statspack-pt1/</link>
	<description>Just another Oracle weblog</description>
	<lastBuildDate>Thu, 23 May 2013 12:47:17 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: Viewing Figures &#171; Oracle Scratchpad</title>
		<link>http://jonathanlewis.wordpress.com/2006/11/29/analysing-statspack-pt1/#comment-44904</link>
		<dc:creator><![CDATA[Viewing Figures &#171; Oracle Scratchpad]]></dc:creator>
		<pubDate>Fri, 03 Feb 2012 09:32:13 +0000</pubDate>
		<guid isPermaLink="false">http://jonathanlewis.wordpress.com/2006/11/29/analysing-statspack-pt1/#comment-44904</guid>
		<description><![CDATA[[...] Analysing Statspack (1) [...]]]></description>
		<content:encoded><![CDATA[<p>[...] Analysing Statspack (1) [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: 分析 Statspack 1 &#124; xpchild</title>
		<link>http://jonathanlewis.wordpress.com/2006/11/29/analysing-statspack-pt1/#comment-40822</link>
		<dc:creator><![CDATA[分析 Statspack 1 &#124; xpchild]]></dc:creator>
		<pubDate>Tue, 21 Jun 2011 05:15:42 +0000</pubDate>
		<guid isPermaLink="false">http://jonathanlewis.wordpress.com/2006/11/29/analysing-statspack-pt1/#comment-40822</guid>
		<description><![CDATA[[...] 原文：http://jonathanlewis.wordpress.com/2006/11/29/analysing-statspack-pt1/ [...]]]></description>
		<content:encoded><![CDATA[<p>[...] 原文：http://jonathanlewis.wordpress.com/2006/11/29/analysing-statspack-pt1/ [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Statspack/AWR Report Resources &#171; Charles Hooper&#039;s Oracle Notes</title>
		<link>http://jonathanlewis.wordpress.com/2006/11/29/analysing-statspack-pt1/#comment-37728</link>
		<dc:creator><![CDATA[Statspack/AWR Report Resources &#171; Charles Hooper&#039;s Oracle Notes]]></dc:creator>
		<pubDate>Thu, 18 Nov 2010 20:42:03 +0000</pubDate>
		<guid isPermaLink="false">http://jonathanlewis.wordpress.com/2006/11/29/analysing-statspack-pt1/#comment-37728</guid>
		<description><![CDATA[[...] information, I suggest starting here when trying to learn how to read AWR/Statspack reports: http://jonathanlewis.wordpress.com/2006/11/29/analysing-statspack-pt1/  http://www.oracle.com/technology/deploy/performance/pdf/statspack_opm4.pdf  [...]]]></description>
		<content:encoded><![CDATA[<p>[...] information, I suggest starting here when trying to learn how to read AWR/Statspack reports: <a href="http://jonathanlewis.wordpress.com/2006/11/29/analysing-statspack-pt1/ " rel="nofollow">http://jonathanlewis.wordpress.com/2006/11/29/analysing-statspack-pt1/ </a> <a href="http://www.oracle.com/technology/deploy/performance/pdf/statspack_opm4.pdf " rel="nofollow">http://www.oracle.com/technology/deploy/performance/pdf/statspack_opm4.pdf </a> [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jonathan Lewis</title>
		<link>http://jonathanlewis.wordpress.com/2006/11/29/analysing-statspack-pt1/#comment-32735</link>
		<dc:creator><![CDATA[Jonathan Lewis]]></dc:creator>
		<pubDate>Sun, 22 Mar 2009 00:57:20 +0000</pubDate>
		<guid isPermaLink="false">http://jonathanlewis.wordpress.com/2006/11/29/analysing-statspack-pt1/#comment-32735</guid>
		<description><![CDATA[Robert,

I can&#039;t imagine why you would think I would assume your question wasn&#039;t serious, or why I wouldn&#039;t try to supply a serious answer. 

My answer, though, won&#039;t sound entirely serious because it is the answer made famous by Douglas Adams: 42.
(See http://jonathanlewis.wordpress.com/2008/02/28/42/ for the serious justification).

Nigel has made some relevant comments, though, which I agree with.  There is a point at which the data becomes so old that there is no point in holding it for comparison purposes.  You might want to keep 13 months, for example, so that you could compare this Christmas with last Christmas - but you also have to worry about how you might handle creating reports across instance restarts. 

In principle, so long as you remember to include the full, indexed, keys of the tables in your queries, you probably can&#039;t do much harm (in terms of performance) when querying the tables - but I suppose you might still decide to limit the damage by reducing history to one or two snapshots per day and then compacting the tables at regular intervals.

Another alternative is to generate and archive one report per day once the data is over (say) 42 days and then delete the data.]]></description>
		<content:encoded><![CDATA[<p>Robert,</p>
<p>I can&#8217;t imagine why you would think I would assume your question wasn&#8217;t serious, or why I wouldn&#8217;t try to supply a serious answer. </p>
<p>My answer, though, won&#8217;t sound entirely serious because it is the answer made famous by Douglas Adams: 42.<br />
(See <a href="http://jonathanlewis.wordpress.com/2008/02/28/42/" rel="nofollow">http://jonathanlewis.wordpress.com/2008/02/28/42/</a> for the serious justification).</p>
<p>Nigel has made some relevant comments, though, which I agree with.  There is a point at which the data becomes so old that there is no point in holding it for comparison purposes.  You might want to keep 13 months, for example, so that you could compare this Christmas with last Christmas &#8211; but you also have to worry about how you might handle creating reports across instance restarts. </p>
<p>In principle, so long as you remember to include the full, indexed, keys of the tables in your queries, you probably can&#8217;t do much harm (in terms of performance) when querying the tables &#8211; but I suppose you might still decide to limit the damage by reducing history to one or two snapshots per day and then compacting the tables at regular intervals.</p>
<p>Another alternative is to generate and archive one report per day once the data is over (say) 42 days and then delete the data.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jonathan Lewis</title>
		<link>http://jonathanlewis.wordpress.com/2006/11/29/analysing-statspack-pt1/#comment-32732</link>
		<dc:creator><![CDATA[Jonathan Lewis]]></dc:creator>
		<pubDate>Sun, 22 Mar 2009 00:41:52 +0000</pubDate>
		<guid isPermaLink="false">http://jonathanlewis.wordpress.com/2006/11/29/analysing-statspack-pt1/#comment-32732</guid>
		<description><![CDATA[Tutu,

This may give you some idea of the sort of thing you&#039;re looking for:
http://jonathanlewis.wordpress.com/2007/03/07/analysing-statspack-4/#comment-31142]]></description>
		<content:encoded><![CDATA[<p>Tutu,</p>
<p>This may give you some idea of the sort of thing you&#8217;re looking for:<br />
<a href="http://jonathanlewis.wordpress.com/2007/03/07/analysing-statspack-4/#comment-31142" rel="nofollow">http://jonathanlewis.wordpress.com/2007/03/07/analysing-statspack-4/#comment-31142</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nigel</title>
		<link>http://jonathanlewis.wordpress.com/2006/11/29/analysing-statspack-pt1/#comment-32716</link>
		<dc:creator><![CDATA[Nigel]]></dc:creator>
		<pubDate>Tue, 17 Mar 2009 19:40:17 +0000</pubDate>
		<guid isPermaLink="false">http://jonathanlewis.wordpress.com/2006/11/29/analysing-statspack-pt1/#comment-32716</guid>
		<description><![CDATA[@Robert:
You can simply export the PERFSTAT schema then clean-up statspack snapshots like this:

SQL&gt; connect perfstat/perfstat
SQL&gt; @$ORACLE_HOME/rdbms/admin/sppurge &lt;-- Purges a limited range of Snapshot IDs for a given database instance.]]></description>
		<content:encoded><![CDATA[<p>@Robert:<br />
You can simply export the PERFSTAT schema then clean-up statspack snapshots like this:</p>
<p>SQL&gt; connect perfstat/perfstat<br />
SQL&gt; @$ORACLE_HOME/rdbms/admin/sppurge &lt;&#8211; Purges a limited range of Snapshot IDs for a given database instance.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Robert</title>
		<link>http://jonathanlewis.wordpress.com/2006/11/29/analysing-statspack-pt1/#comment-32715</link>
		<dc:creator><![CDATA[Robert]]></dc:creator>
		<pubDate>Tue, 17 Mar 2009 19:29:33 +0000</pubDate>
		<guid isPermaLink="false">http://jonathanlewis.wordpress.com/2006/11/29/analysing-statspack-pt1/#comment-32715</guid>
		<description><![CDATA[Hi Nigel,

Yes. That is the sort of thing I was thinking of.
It is taking up a lot of space, but I am hesitant to get rid of it just because of the potential for analyzing and/or reporting on the high level stuff which could be used to show some sorts of totals or trends.

Thanks,

Robert.]]></description>
		<content:encoded><![CDATA[<p>Hi Nigel,</p>
<p>Yes. That is the sort of thing I was thinking of.<br />
It is taking up a lot of space, but I am hesitant to get rid of it just because of the potential for analyzing and/or reporting on the high level stuff which could be used to show some sorts of totals or trends.</p>
<p>Thanks,</p>
<p>Robert.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nigel</title>
		<link>http://jonathanlewis.wordpress.com/2006/11/29/analysing-statspack-pt1/#comment-32713</link>
		<dc:creator><![CDATA[Nigel]]></dc:creator>
		<pubDate>Tue, 17 Mar 2009 16:47:12 +0000</pubDate>
		<guid isPermaLink="false">http://jonathanlewis.wordpress.com/2006/11/29/analysing-statspack-pt1/#comment-32713</guid>
		<description><![CDATA[Hi Robert - it used to be the case that DBAs were supposed to ignore statspack reports that spanned instance bounces. But, if your system is stable, no patches have been applied, and other such stuff, then I suppose that there may be some high-level stats you could make use of for pie chart sort of &quot;quck glance&quot; reports. The detail, though, is bound to become less and less relevant to earlier snapshots: data has been added/removed; fragmentation may have taken place; parameters changed, etc.]]></description>
		<content:encoded><![CDATA[<p>Hi Robert &#8211; it used to be the case that DBAs were supposed to ignore statspack reports that spanned instance bounces. But, if your system is stable, no patches have been applied, and other such stuff, then I suppose that there may be some high-level stats you could make use of for pie chart sort of &#8220;quck glance&#8221; reports. The detail, though, is bound to become less and less relevant to earlier snapshots: data has been added/removed; fragmentation may have taken place; parameters changed, etc.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Robert Wood</title>
		<link>http://jonathanlewis.wordpress.com/2006/11/29/analysing-statspack-pt1/#comment-32708</link>
		<dc:creator><![CDATA[Robert Wood]]></dc:creator>
		<pubDate>Sat, 14 Mar 2009 01:40:32 +0000</pubDate>
		<guid isPermaLink="false">http://jonathanlewis.wordpress.com/2006/11/29/analysing-statspack-pt1/#comment-32708</guid>
		<description><![CDATA[Mr. Lewis,

This is a serious comment/question to which I very much hope you will reply with a serious answer.

I have been collecting statspack stats hourly at level 7 for about a year. I would like to keep about 3 years of these stats for analyzing trends, comparing historical data, etc. currently I have about 2 years of statspack data (the earlier data was level 5 and possibly not hourly).

Do you think this is excessive and/or a bad idea and/or a waste of time?

I would very much appreciate your comments on saving extensive statspack data for a given database.

Thank you,

Robert Wood.]]></description>
		<content:encoded><![CDATA[<p>Mr. Lewis,</p>
<p>This is a serious comment/question to which I very much hope you will reply with a serious answer.</p>
<p>I have been collecting statspack stats hourly at level 7 for about a year. I would like to keep about 3 years of these stats for analyzing trends, comparing historical data, etc. currently I have about 2 years of statspack data (the earlier data was level 5 and possibly not hourly).</p>
<p>Do you think this is excessive and/or a bad idea and/or a waste of time?</p>
<p>I would very much appreciate your comments on saving extensive statspack data for a given database.</p>
<p>Thank you,</p>
<p>Robert Wood.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: tutu</title>
		<link>http://jonathanlewis.wordpress.com/2006/11/29/analysing-statspack-pt1/#comment-32700</link>
		<dc:creator><![CDATA[tutu]]></dc:creator>
		<pubDate>Tue, 10 Mar 2009 14:52:54 +0000</pubDate>
		<guid isPermaLink="false">http://jonathanlewis.wordpress.com/2006/11/29/analysing-statspack-pt1/#comment-32700</guid>
		<description><![CDATA[Can you help me, please, for writing a sql script in order to generate daily statspack rapport?
(from 0h00 to 23h45)
Thank you in advance 

tutu]]></description>
		<content:encoded><![CDATA[<p>Can you help me, please, for writing a sql script in order to generate daily statspack rapport?<br />
(from 0h00 to 23h45)<br />
Thank you in advance </p>
<p>tutu</p>
]]></content:encoded>
	</item>
</channel>
</rss>
