<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Oracle stats, update row data only? in Operating System - HP-UX</title>
    <link>https://community.hpe.com/t5/operating-system-hp-ux/oracle-stats-update-row-data-only/m-p/4068992#M736264</link>
    <description>Hi,&lt;BR /&gt;&lt;BR /&gt;DBMS_STATS can use multiple parallel threads utilizing parallel Query to calculate the stats.&lt;BR /&gt;&lt;BR /&gt;It's not just the rowcount that matters but the amount of blocks and esp. the number of blevels of the indexes.&lt;BR /&gt;&lt;BR /&gt;I.e. if you increase the numer of rows, but do not adjust the number of blocks accordingly, the optimizer might very well make wrong decisions because you'll change the "rows per block" ratio wehn doing so.&lt;BR /&gt;&lt;BR /&gt;Worst will be if, i.e. your HUGE table is an item table and you need to join a header table to this item table. Having a high number of rows, but a low number of blocks on the item table can drive the optimizer to select the item table as the first table for the join (which in general is a bad descision, when you want to key-join header and item tables).&lt;BR /&gt;&lt;BR /&gt;Go for real stats and go with 8 or 16 threads to calculate them.&lt;BR /&gt;&lt;BR /&gt;Volker</description>
    <pubDate>Wed, 26 Sep 2007 10:29:46 GMT</pubDate>
    <dc:creator>Volker Borowski</dc:creator>
    <dc:date>2007-09-26T10:29:46Z</dc:date>
    <item>
      <title>Oracle stats, update row data only?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/oracle-stats-update-row-data-only/m-p/4068986#M736258</link>
      <description>I've got stats being calculated on some tables that are HUUUGE, and I feel that the only thing that really matters is that the rowcount statistic gets updated ( and I could very well be wrong ).  Is there is a way to update *just the row count statistic*, leaving all other stats alone?  I'd like to be able to trace and test some runtimes on some queries with this as a tool to see if I could eliminate some huge and long statistics gathering that runs every night.  Or, does anyone else have a suggestion to tackle this same issue in another manner?&lt;BR /&gt;&lt;BR /&gt;Thanks for your assistance.</description>
      <pubDate>Tue, 11 Sep 2007 13:40:02 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/oracle-stats-update-row-data-only/m-p/4068986#M736258</guid>
      <dc:creator>TwoProc</dc:creator>
      <dc:date>2007-09-11T13:40:02Z</dc:date>
    </item>
    <item>
      <title>Re: Oracle stats, update row data only?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/oracle-stats-update-row-data-only/m-p/4068987#M736259</link>
      <description>Hi John&lt;BR /&gt;&lt;BR /&gt;I think it is perfectly reasonable and desirable ti jsut set the stats yourself if you pretty much know what they will be like. No point in counting if you know the outcome.&lt;BR /&gt;&lt;BR /&gt;Oracle provices several procedures for this in the DBMS_STATS package&lt;BR /&gt;&lt;BR /&gt;Check out (google), SET_TABLE_STATS  and perhaps also SET_COLUMN_STATS&lt;BR /&gt;&lt;BR /&gt;hth,&lt;BR /&gt;Hein van den Heuvel&lt;BR /&gt;HvdH Performance Consulting.&lt;BR /&gt;</description>
      <pubDate>Tue, 11 Sep 2007 16:26:07 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/oracle-stats-update-row-data-only/m-p/4068987#M736259</guid>
      <dc:creator>Hein van den Heuvel</dc:creator>
      <dc:date>2007-09-11T16:26:07Z</dc:date>
    </item>
    <item>
      <title>Re: Oracle stats, update row data only?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/oracle-stats-update-row-data-only/m-p/4068988#M736260</link>
      <description>Thanks Hein,&lt;BR /&gt;&lt;BR /&gt;Looks like an example would be:&lt;BR /&gt;exec dbms_stats.set_table_stats(OWNNAME=&amp;gt;'MYUSER',TABNAME=&amp;gt;'MYTABLE',NUMROWS=&amp;gt;'10000000');&lt;BR /&gt;</description>
      <pubDate>Thu, 20 Sep 2007 17:17:25 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/oracle-stats-update-row-data-only/m-p/4068988#M736260</guid>
      <dc:creator>TwoProc</dc:creator>
      <dc:date>2007-09-20T17:17:25Z</dc:date>
    </item>
    <item>
      <title>Re: Oracle stats, update row data only?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/oracle-stats-update-row-data-only/m-p/4068989#M736261</link>
      <description>How are you generating stats now? &lt;BR /&gt;With dbms_stats.gather_schema_stats use&lt;BR /&gt;options=&amp;gt; 'GATHER STALE' &lt;BR /&gt;and it will only generate statistics for tables with the MONITORING flag set to Y.&lt;BR /&gt;Then you can set all the tables that do not require stats to be generated daily to N and the rest to Y.&lt;BR /&gt;&lt;BR /&gt;You could then update row counts manually if necessary.  &lt;BR /&gt;&lt;BR /&gt;Patti</description>
      <pubDate>Mon, 24 Sep 2007 15:05:17 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/oracle-stats-update-row-data-only/m-p/4068989#M736261</guid>
      <dc:creator>Patti Johnson</dc:creator>
      <dc:date>2007-09-24T15:05:17Z</dc:date>
    </item>
    <item>
      <title>Re: Oracle stats, update row data only?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/oracle-stats-update-row-data-only/m-p/4068990#M736262</link>
      <description>Good suggestion Patti!&lt;BR /&gt;&lt;BR /&gt;What defines when a table is stale?  Or is it simply that if the monitoring flag is set, then then the table will always be reviewed, regardless of how old the stats are?&lt;BR /&gt;&lt;BR /&gt;Thanks for the suggestion.</description>
      <pubDate>Tue, 25 Sep 2007 09:34:48 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/oracle-stats-update-row-data-only/m-p/4068990#M736262</guid>
      <dc:creator>TwoProc</dc:creator>
      <dc:date>2007-09-25T09:34:48Z</dc:date>
    </item>
    <item>
      <title>Re: Oracle stats, update row data only?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/oracle-stats-update-row-data-only/m-p/4068991#M736263</link>
      <description>hi John,&lt;BR /&gt;&lt;BR /&gt;Maybe this can shed some more lights.&lt;BR /&gt;&lt;BR /&gt;&lt;A href="http://download-east.oracle.com/docs/cd/A81042_01/DOC/server.816/a76992/stats.htm#25754" target="_blank"&gt;http://download-east.oracle.com/docs/cd/A81042_01/DOC/server.816/a76992/stats.htm#25754&lt;/A&gt;&lt;BR /&gt;&lt;BR /&gt;Basically, when you designate a table for monitoring, Oracle will watch for DML activity on it. It will capture the approximate number of inserts, updates or deletes for the table.&lt;BR /&gt;&lt;BR /&gt;Later, DBMS_STATS can be used to gather stats on "stale" tables.  Tables are classified "stale" by the act of monitoring them.  &lt;BR /&gt;&lt;BR /&gt;It takes a combination of MONITORING and DBMS_STATS with a "gather stale" to update the statistics for stale tables -- monitoring does not analyze the tables themselves, only counts (approximately) the DML hits on it. &lt;BR /&gt;&lt;BR /&gt;The criteria for monitoring implying stales is that the total number of inserts, deletes and updates for the table exceeds 10% of the number of rows in the table as recorded by the last analyze.&lt;BR /&gt;&lt;BR /&gt;Hope this helps!&lt;BR /&gt;&lt;BR /&gt;kind regards&lt;BR /&gt;yogeeraj</description>
      <pubDate>Tue, 25 Sep 2007 11:07:06 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/oracle-stats-update-row-data-only/m-p/4068991#M736263</guid>
      <dc:creator>Yogeeraj_1</dc:creator>
      <dc:date>2007-09-25T11:07:06Z</dc:date>
    </item>
    <item>
      <title>Re: Oracle stats, update row data only?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/oracle-stats-update-row-data-only/m-p/4068992#M736264</link>
      <description>Hi,&lt;BR /&gt;&lt;BR /&gt;DBMS_STATS can use multiple parallel threads utilizing parallel Query to calculate the stats.&lt;BR /&gt;&lt;BR /&gt;It's not just the rowcount that matters but the amount of blocks and esp. the number of blevels of the indexes.&lt;BR /&gt;&lt;BR /&gt;I.e. if you increase the numer of rows, but do not adjust the number of blocks accordingly, the optimizer might very well make wrong decisions because you'll change the "rows per block" ratio wehn doing so.&lt;BR /&gt;&lt;BR /&gt;Worst will be if, i.e. your HUGE table is an item table and you need to join a header table to this item table. Having a high number of rows, but a low number of blocks on the item table can drive the optimizer to select the item table as the first table for the join (which in general is a bad descision, when you want to key-join header and item tables).&lt;BR /&gt;&lt;BR /&gt;Go for real stats and go with 8 or 16 threads to calculate them.&lt;BR /&gt;&lt;BR /&gt;Volker</description>
      <pubDate>Wed, 26 Sep 2007 10:29:46 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/oracle-stats-update-row-data-only/m-p/4068992#M736264</guid>
      <dc:creator>Volker Borowski</dc:creator>
      <dc:date>2007-09-26T10:29:46Z</dc:date>
    </item>
    <item>
      <title>Re: Oracle stats, update row data only?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/oracle-stats-update-row-data-only/m-p/4068993#M736265</link>
      <description>Yogeeraj,&lt;BR /&gt;Thanks for the tips, we are checking this option out.  My concern is that it seems that if a table is monitored, then it must change by 10% before it needs regathering.  Well, with tables that are over 100 gig in size, a change of 10% is 10 Gig, and I won't achieve that change on a daily basis.  Sadly some of these largest tables need gathers done daily to avoid problems, and I wouldn't get that on these.  Which, in itself makes no sense.  Statistically, the largest tables we have have, are not statistically different than before, only 40k rows larger or so.  &lt;BR /&gt;However, your recommendation does suggest to me a hybrid approach which utilizes monitoring for more regularly sized tables, and just specific gathers on large tables.&lt;BR /&gt;&lt;BR /&gt;Volker,&lt;BR /&gt;thanks for your input, but I am already doing these in parallel.  But, your input is appreciated.</description>
      <pubDate>Wed, 26 Sep 2007 10:42:30 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/oracle-stats-update-row-data-only/m-p/4068993#M736265</guid>
      <dc:creator>TwoProc</dc:creator>
      <dc:date>2007-09-26T10:42:30Z</dc:date>
    </item>
    <item>
      <title>Re: Oracle stats, update row data only?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/oracle-stats-update-row-data-only/m-p/4068994#M736266</link>
      <description>hi,&lt;BR /&gt;&lt;BR /&gt;Our database is not as huge as yours and we managed to implement a simple routine that runs every night:&lt;BR /&gt;&lt;BR /&gt;DECLARE&lt;BR /&gt;  X NUMBER;&lt;BR /&gt;BEGIN&lt;BR /&gt;  SYS.DBMS_JOB.SUBMIT&lt;BR /&gt;  ( job       =&amp;gt; X &lt;BR /&gt;   ,what      =&amp;gt; 'dbms_stats.gather_schema_stats( ownname =&amp;gt; user, options =&amp;gt; ''GATHER STALE'' );'&lt;BR /&gt;   ,next_date =&amp;gt; trunc(sysdate+1)+((00+(20/60))/24)&lt;BR /&gt;   ,interval  =&amp;gt; 'trunc(sysdate+1)+((00+(20/60))/24)'&lt;BR /&gt;   ,no_parse  =&amp;gt; FALSE&lt;BR /&gt;  );&lt;BR /&gt;END;&lt;BR /&gt;/&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;Good luck.&lt;BR /&gt;&lt;BR /&gt;kind regards&lt;BR /&gt;yogeeraj</description>
      <pubDate>Fri, 28 Sep 2007 05:35:23 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/oracle-stats-update-row-data-only/m-p/4068994#M736266</guid>
      <dc:creator>Yogeeraj_1</dc:creator>
      <dc:date>2007-09-28T05:35:23Z</dc:date>
    </item>
    <item>
      <title>Re: Oracle stats, update row data only?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/oracle-stats-update-row-data-only/m-p/4068995#M736267</link>
      <description>thanks Yogeeraj for the nice example.&lt;BR /&gt;&lt;BR /&gt;In your example, does it run 20 minutes after midnight tomorrow? And the "interval" parameter is 20 minutes, does it rerun in 20 minutes?</description>
      <pubDate>Mon, 01 Oct 2007 07:51:53 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/oracle-stats-update-row-data-only/m-p/4068995#M736267</guid>
      <dc:creator>TwoProc</dc:creator>
      <dc:date>2007-10-01T07:51:53Z</dc:date>
    </item>
    <item>
      <title>Re: Oracle stats, update row data only?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/oracle-stats-update-row-data-only/m-p/4068996#M736268</link>
      <description>hi,&lt;BR /&gt;&lt;BR /&gt;Answers to your questions:&lt;BR /&gt;&lt;BR /&gt;&amp;gt;does it run 20 minutes after midnight tomorrow? &lt;BR /&gt;Yes.&lt;BR /&gt;SQL&amp;gt;alter session set nls_date_format='dd/mm/yyyy hh24:mi';&lt;BR /&gt;&lt;BR /&gt;Session altered.&lt;BR /&gt;&lt;BR /&gt;SQL&amp;gt;select trunc(sysdate+1)+((00+(20/60))/24) from dual;&lt;BR /&gt;&lt;BR /&gt;TRUNC(SYSDATE+1)&lt;BR /&gt;________________&lt;BR /&gt;04/10/2007 00:20&lt;BR /&gt;&lt;BR /&gt;SQL&amp;gt;&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;&amp;gt; the "interval" parameter is 20 minutes, does it rerun in 20 minutes? &lt;BR /&gt; &lt;BR /&gt;interval =&amp;gt; 'trunc(sysdate+1)+((00+(20/60))/24)'&lt;BR /&gt;&lt;BR /&gt;This always evaluates to the next day at 00:20.&lt;BR /&gt;&lt;BR /&gt;You may wish to make appropriate modifications.&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;hope this helps!&lt;BR /&gt;kind regards&lt;BR /&gt;yogeeraj</description>
      <pubDate>Wed, 03 Oct 2007 03:46:33 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/oracle-stats-update-row-data-only/m-p/4068996#M736268</guid>
      <dc:creator>Yogeeraj_1</dc:creator>
      <dc:date>2007-10-03T03:46:33Z</dc:date>
    </item>
    <item>
      <title>Re: Oracle stats, update row data only?</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/oracle-stats-update-row-data-only/m-p/4068997#M736269</link>
      <description>Thanks once again Yogeeraj.</description>
      <pubDate>Mon, 15 Oct 2007 10:50:22 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/oracle-stats-update-row-data-only/m-p/4068997#M736269</guid>
      <dc:creator>TwoProc</dc:creator>
      <dc:date>2007-10-15T10:50:22Z</dc:date>
    </item>
  </channel>
</rss>

