Date: Tue, 20 May 2014 12:40:10 +0300
Message-ID: <_pFev.40906$SH2.12214_at_uutiset.elisa.fi>
"joel garry" wrote in message
news:609a4cc1-fd8c-4a1d-88aa-113c7d5df5f5_at_googlegroups.com...
On Monday, May 19, 2014 5:59:52 AM UTC-7, Jack wrote:
> "Jack" wrote in message news:sshev.40752$SH2.19490_at_uutiset.elisa.fi...
>
>This isn't really enough information to say, but for whatever reason your
>BS table doing a full scan is a much better plan than a bunch of >nested
>loops. One could guess the statistics or lack of statistics in the XE is
>responsible for that, but better to know than guess. Here is one >simple
>methodology for giving us enough information to tell - and you may work it
>out just following the steps. Ignore the formatting >advice, of course.
>http://oracle-randolf.blogspot.com/2009/02/basic-sql-statement-performance.html
>
>This all assumes you've gotten the basics from the performance tuning
>manual. Jonathan Lewis has a book that explains it in detail, highly
> >recommended.
>
>jg
>--
>_at_home.com is bogus.
>http://www.microscope.co.uk/news/2240220895/Oracle-extends-reach-with-desktop-virtualisation-specialist
Thanks jg for your comment.
Not sooooo interested to read 27 pages report about plan. Well, no hint available to fix it. (or _dbparameter ?) So I made the logic more simple. Leaving some details away. Some exceptions (and extraordinary exceptionals) are now not counted.
But hmm. db 11's costbased optimizer looks very good. No glitches found. Yet. Received on Tue May 20 2014 - 11:40:10 CEST