Eddie Awad’s Blog - Latest Comments in DUAL behavior change

Re: DUAL behavior change

Carl r. — Tue, 22 Nov 2005 06:41:19 -0000

hi - great news;
that's what i like in the 10g release - there are also a lot of small changes with big effect.

Carl

Re: DUAL behavior change

UM — Thu, 10 Nov 2005 14:31:08 -0000

Keep in mind that we should not refer to 'dummy' column of Dual table. If we do, plan will revert back to 5 c.gets.

Usually, we don't need to refer dummy column, but I had seen some code like that!

Re: DUAL behavior change

yas — Thu, 10 Nov 2005 06:52:41 -0000

Since I only need the SYSDATE, which is not stored in the DUAL table, why scan (full or not) the DUAL (or any) table?
Definitely. We had this query which is executed more than 2 million times in every half hour.
SELECT SYS_CONTEXT(:B2,:B1) FROM SYS.DUAL
Creating and index on dual made it 1/3. Seems it will be better when we upgrade to 10G.

Re: DUAL behavior change

Eddie Awad — Wed, 09 Nov 2005 18:54:14 -0000

Hi Rob,

I guess it does not matter much in the case of DUAL. However, "0 consistent gets" is better than "3 consistent gets" because, quoting AskTom: "Each consistent get is a latch, latches = contention".

Since I only need the SYSDATE, which is not stored in the DUAL table, why scan (full or not) the DUAL (or any) table?

Re: DUAL behavior change

Robert Vollman — Wed, 09 Nov 2005 18:17:35 -0000

Eddie, I am missing something. DUAL has just one row, why does it matter if Oracle does a full tablescan of a single-row table (that is very likely in the cache anyway)?