Re: OPTIMIZER CHOOSE vs. FIRST_ROWS

Thanks for your Answer I will check out this.

Greetings Jacques

In article <7u203m$3e$1_at_pheidippides.axion.bt.co.uk>,   "Neil C" <btsscrth_at_bt.com> wrote:
> You say the databases have the same amount of data, but is the data
> distributed in the same way. Was one of the databases populated via an
> import / export of the other database ? FIRST_ROWS tends to favour
index
> access, could the indexes on one of the databases be in need of a
rebuild
> (i.e the height of the index is >=4 or has there been many updates /
deletes
> affecting the index leaf blocks ?) The import to the second database
will
> have rebuilt these indexes.
>
> Have you done an explain plan tkprof on the query to prove that thy
are
> using the same access path ??
>
> HTH
>
> NeilC
> jacksnews_at_my-deja.com wrote in message <7u1ts7
$iud$1_at_nnrp1.deja.com>...
> >Hello,
> >
> >I 've two databases with the same application, on two identical
servers.
> >The databases are containing the same amount of data.
> >They are using the same indexes and datamodels.
> >They are analysed every night.
> >
> >BUT:
> >
> >When I'm using the FIRST_ROWS optimizer the server a is
> >up to 100 times slower than the server b which is using the optimizer
> >first_rows, too. With the optimizer choose on server a
> >it works with the same performance like server b.
> >
> >So, I have to use choose for server a and first_rows for the other
> >one.
> >
> >Can anyone tell me why ?
> >
> >Thanks
> >Jacques
> >
> >
> >Sent via Deja.com http://www.deja.com/
> >Before you buy.
>
>

Sent via Deja.com http://www.deja.com/
Before you buy. Received on Fri Oct 15 1999 - 05:20:04 CDT