Re: Quick questions on direct insert, undo and parallel prosessing

Thanks guys,

I have not touched this parallel stuff lately. I went to an ORACLE 8i class long ago and seem to recall you always have to use the parallel hint for it to work.

As to the undo tbs, I sort of asociate it with AUM. And I don't seem to see a lot of benefits in using AUM. So it makes me wonder why ORACLE come up with this feature. Discussions on UNDO_RETENTION seem to center around flash_back query, which led me to think if ORACLE came up with this to better support log miner and flash_back query. Thoughts?

John

"Anurag Varma" <avdbi_at_hotmail.com> wrote in message news:<0XGlb.606$Z_5.303_at_news02.roc.ny>...
> Comments below:
>
> Anurag Varma
>
> "John" <jbradshaw777_at_yahoo.com> wrote in message news:f2f59d82.0310221432.50cc341f_at_posting.google.com...
> > Hi groups,
> >
> > A few quick confirmations of sort...
> > 1. Direct load insert WILL always generate redo IF ORACLE is in
> > ARCHIVELOG mode.
> direct load insert will generate redo .. albeit minimum.
> Discard your if condition.
>
> > 2. Parallel query processing will not happen (regardless of how your
> > table, database is set up) unless you you hint it in your queries.
> Not exactly true:
> Consider this example (Note: Your database init.ora parameters need
> to be set properly for this to work):
> SQL> create table xyz (a number) parallel 4;
>
> Table created.
>
> SQL> insert into xyz select rownum from user_objects;
>
> 2032 rows created.
>
> SQL> commit;
>
> Commit complete.
>
> SQL> set autotrace traceonly exp
> SQL> select * from xyz;
>
> Execution Plan
> ----------------------------------------------------------
> 0 SELECT STATEMENT Optimizer=CHOOSE (Cost=1 Card=82 Bytes=1066)
> 1 0 TABLE ACCESS* (FULL) OF 'XYZ' (Cost=1 Card=82 Bytes=1066) :Q863000
>
>
> 1 PARALLEL_TO_SERIAL SELECT /*+ NO_EXPAND ROWID(A1) */ A1."A" FRO
> M "XYZ" PX_GRANULE(0, BLOCK_RANGE, D
>
> > 3. Undo tablespace is created more for the purpose of supporting
> > flash-back query than for the purpose of automating rollback
> > management. It does not offer any improvemnet on the chance of you
> > hitting the ORA-01555.
> Not exactly true. Undo does not mean that you won't see 1555's at all.
> However, if set properly, it should minimize their occurence, if not eliminate them.
>
> Also, although Oracle suggests that automatic undo be enabled before using this
> feature, I think it should work even with the old way of rollback segments.
>
> >
> > TIA.
> >
> > John
Received on Thu Oct 23 2003 - 13:09:00 CDT