Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Oracles streams stability for 9.2.0.5

Re: Oracles streams stability for 9.2.0.5

From: Jonathan Lewis <jonathan_at_jlcomp.demon.co.uk>
Date: Sat, 6 May 2006 08:26:18 +0100
Message-ID: <acadne4W-5wK0sHZnZ2dnUVZ8qWdnZ2d@bt.com>

<jkundu_at_yahoo.com> wrote in message
news:1146837171.834175.254170_at_j33g2000cwa.googlegroups.com...
>I am not sure why you think logging the supplemental information into
> the undo results in a double penalty.

    Because it does. The amount of UNDO increases because the     supplement is added to the UNDO, and of course all changes     to UNDO blocks are logged in the REDO.

> Every block
> change in Oracle
> creates a before image (undo), and an after-image (redo).

    But the before image of a row is (normally) only of the columns     that will be changed - not the whole row, nor the row plus primary     key. So putting the primary key into the UNDO is an overhead.

>
> Supplemental
> information always pertain to the before-image (since the columns are
> not going to change), and is only logged in the before-image part
> (undo).

    But you could equally (arbitrarily) say that: "Supplemental

    information always pertains to the after-image (since the columns have     not changed), and is only logged in the after-image part (redo)."     Neither statement (your version or mine) adds weight to any argument     about implementation mechanisms.

> Having said that, supplemental logging does add an overhead, especially
> for tables that do not have any unique/primary constraints defined.

    Because for tables with no unique/primary key this puts the entire row into

    the UNDO - shades of tthe Oracle 5 BI file! Be careful what you do about     global temporary tables and supplemental logging at the db level. The first

    price you pay is in the UNDO - and GTTs generate UNDO.

> Note if constraint maintenance overhead is the reason that you do not
> want to define such a constraint, you can always define RELY
> constraints to direct the supplemental logging mechanism to log a
> subset of columns that uniquely identify the row, although there is no
> unique/primary constraints being maintained on the table.

    Well spotted: RELY DISABLE NOVALIDATE knows of the     intent and uses the column accordingly.

>
> Regards
> -Joydip
>

-- 
Regards

Jonathan Lewis
http://www.oracle.com/technology/community/oracle_ace/ace1.html#lewis

The Co-operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/faq/ind_faq.html

Cost Based Oracle: Fundamentals
http://www.jlcomp.demon.co.uk/cbo_book/ind_book.html
Received on Sat May 06 2006 - 02:26:18 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US