RE: Currval and buffer gets

Waleed,
I am using 81714 under NT4.

I can NOT duplicate the problem you're seeing (but I ran it logged in as sys and used sys.x$dual). ie - I can run your script from 2 simultaneous windows & it works ok. What platform & patch are you on?

Timing wise - the version using sys.x$dual took 500 or 600cs whilst the one using plain dual took 900 or 1000 cs.

I then created a view (x_$dual) on sys.x$dual and granted select to another user. Running from that other (DBA) user I again could not reproduce the problem you see.

The performance in this case (using a view) was not noticeably different to being logged in as sys.

What error does your second session get?

Regards
Bruce Reardon

-----Original Message-----
Sent: Wednesday, 24 April 2002 10:43

No, I couldn't duplicate this effect (8.1.7.0.0/Linux and 9.0.1.1.1/Win2k) - 1) first test 2 simultaneous sessions and then 2) second test 3 simultaneous sessions running.

Regards
Lyubomir Petrov

-----Original Message-----
Sent: Wednesday, 24 April 2002 9:43

Never mess up with Oracle's memory:

It seems that x$dual is not designed for concurrent access. When I try to run the code below in two simultaneous windows the first one comes back and the second crash (8173):

declare
nn number;
ss1 date;
ss2 date;
begin

---
ss1 := sysdate;
for i in 1..100000 loop
select 2 into nn from sys.x_$dual;
end loop;
ss2 := sysdate;
dbms_output.put_line('run time using table dual in centiseconds='||(ss2 -
ss1 ) * 24 * 60 * 60 * 100);
end;


If the x$dual gets replaced by dual it works fine.
Can any one duplicate this?

Thanks
Waleed

-----Original Message-----
Sent: Tuesday, April 23, 2002 6:49 PM

I am writing a paper on application efficiency and I have a number of simple
tests in that paper that illustrates that in a very efficient application
the
switch to x$dual can make around a 70-80 percent improvent. But beaware: the
test suite only accesses x$dual and not other tables so the impact is large
and the application is written in the most efficient way.  Running the same
test but in a worse efficiency case. shows only a 2-3 percent gain ......

Anjo.


"Khedr, Waleed" wrote:



> Can you guys tell me about all the overhead to resolve the view definition

> to reach the magical X$dual table?

>

> Waleed

>

> -----Original Message-----

> Sent: Tuesday, April 23, 2002 12:58 PM

> To: Multiple recipients of list ORACLE-L

>

> Redefine the view to work on dual and pay the price !!!

> Checked it on oracle 8.1.6 and 9.0.1.

> I will take the risk that maybe in some future date this will not work

> if it can save a lot of resources now.

>

> Yechiel Adar

> Mehish

>

> ----- Original Message -----

> To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>

> Sent: Tuesday, April 23, 2002 3:13 PM

>

> > what would you do if Oracle removed this x$dual or made it multiple row

> > table in future upgrades?

> >

> > -----Original Message-----

> > To: Multiple recipients of list ORACLE-L

> > Sent: 4/23/02 4:08 AM

> >

> > Hello Gaja

> >

> > Thanks for the detailed info.

> > I created a view and did grant to public.

> > I did 10 selects and they did only 2 buffers get.

> > BTW - describe on x$dual does not work but select * works.

> >

> > Yechiel Adar

> > Mehish

> >

> > ----- Original Message -----

> > To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>

> > Sent: Monday, April 22, 2002 8:15 PM

> >

> >

> > > Hello Yechiel,

> > >

> > > X$DUAL is an Oracle-internal table "in the SGA" and

> > > will not be shown in an ALL_OBJECTS listing.

> > > Obviously, you need to be SYS to see this. You can do

> > > a describe as SYS and you will see it. Which is the

> > > reason why I recommended creating a view and a public

> > > synonym on the view, so that the application may

> > > reference it without any issues.

> > >

> > > Cheers,

> > >

> > > Gaja

> > >

> > > --- Yechiel Adar <adaryechiel_at_hotmail.com> wrote:

> > > > Hello Gaja

> > > >

> > > > I could not find x$dual. Did select on all_objects

> > > > got zip.

> > > > Oracle 8.1.6.3.4 on NT.

> > > >

> > > > Yechiel Adar

> > > > Mehish

> > > >

> > > > ----- Original Message -----

> > > > To: Multiple recipients of list ORACLE-L

> > > > <ORACLE-L_at_fatcity.com>

> > > > Sent: Sunday, April 21, 2002 8:28 PM

> > > >

> > > >

> > > > > Hi Yechiel,

> > > > >

> > > > > Any full-table-scan in Oracle 8i (or below)

> > > > consumes 4

> > > > > LIOs to the segment header. This number has

> > > > reduced to

> > > > > 2 in 9i. Given that the 1 row that you are going

> > > > after

> > > > > is in 1 data block, there is 1 LIO for the data

> > > > block

> > > > > itself, given you a total of 5 LIOs. You can

> > > > verify

> > > > > this by setting 10046 for the session and looking

> > > > at

> > > > > the trace output.

> > > > >

> > > > > The workaround is to reference x$dual in your

> > > > > application. Alternatively, you can create a view

> > > > on

> > > > > x$dual, create a synonym for it and then go from

> > > > > there. You will incur some I/O for the first

> > > > access of

> > > > > the query (with the synonym), but subsequent

> > > > accesses

> > > > > will incur 0 LIOs against x$dual.

> > > > >

> > > > > Cheers,

> > > > >

> > > > > Gaja

> > > > > --- Yechiel Adar <adaryechiel_at_hotmail.com> wrote:

> > > > > > I did two statspack snapshots, one hour and

> > > > forty

> > > > > > minutes apart.

> > > > > > Then I generated a report and loaded it into

> > > > > > oraperf.com.

> > > > > > In the report I saw that the two SQL statements

> > > > that

> > > > > > where executed the most

> > > > > > times where:

> > > > > >

> > > > > > Select xxxx.currval from dual;

> > > > > >

> > > > > > Select xxxx.nextval from dual;.

> > > > > >

> > > > > > Each one was executed about 90,000 times with 5

> > > > > > buffer gets per execution.

> > > > > > The net result was about 950,000 buffer get for

> > > > > > nextval and currval.

> > > > > >

> > > > > > My question is:

> > > > > > Why should there be about 5 buffer gets per

> > > > > > execution?

> > > > > >

> > > > > > Yechiel Adar

> > > > > > Mehish

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Reardon, Bruce (CALBBAY)
  INET: Bruce.Reardon_at_comalco.riotinto.com.au

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).