Re: SELECT table.currval FROM dual faster way to do this???

Hi..
Actually I believe that the results are from your sqlarea.sql script. I found at your web site.
Just tried it out and noticed the results. I'm not sure about the results. Exactly is Ratio a percent I.E: If I see 42 it is .42

The query itself does not look slow it is just that the results look strange.
a) Dual is 1 row.
b) cache_size=20 Default parameter left out.

   ORDER= NOORDER
c) This could be the problem....

   176 sequences in each of 2 Schemas.

   sequence_cache_entries=100
   sequence_cache_hash_buckets=50

I left this one out of Init.ora...So it is default.

   sequence_cache_hash_entries=7

What do you think???

Not Running Parallel Server.

> c) Check the number of sequences you use compared to the
> init.ora values sequence_cache_entries (default 10)
> and sequence_cache_hash_entries (default 7)
>
> BTW - Are you running Oracle Parallel Server ?
>
> In most cases, a sequence call should do no disk read
> and only a couple of logical I/Os. It should certainly
> deliver only 1 row per execute.
>
> --
>
> Jonathan Lewis
> Yet another Oracle-related web site: www.jlcomp.demon.co.uk
>
> tim_mcconechy_at_my-deja.com wrote in message
<7k5dlf$jlt$1_at_nnrp1.deja.com>...
> >Is there a better way to do:
> >SELECT pdmlogseq.currval FROM dual
> >
> >Seems like a lot of disk reads for a simple query?
> >
> >
> >First load time: 1999-06-15/11:42:07
> >Buffer gets: 3565 ratio 6
> >Disk reads: 2102 ratio 3
> >Rows delivered 26857 ratio 42
> >Executions 641
> >Parses 92
> >Memory 18569
> >Sorts 0
> >Invalidations 0
> >
> >
> >Sent via Deja.com http://www.deja.com/
> >Share what you know. Learn what you don't.
>
>

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't. Received on Wed Jun 16 1999 - 06:06:46 CDT