I should also have pointed out that for an
array insert, Oracle has an optimisation
strategy that allows it to generate one undo
record and one redo record per block,
rather than one for each row created in
that block. So the OP is seeing the absence
of an optimisation (which is a bug in GTTs
in 9.2) rather than the presence of a new
overhead.
--
Regards
Jonathan Lewis
http://www.jlcomp.demon.co.uk
The Co-operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/faq/ind_faq.html
March 2004 Hotsos Symposium - The Burden of Proof
Dynamic Sampling - an investigation
March 2004 Charlotte OUG (www.cltoug.org) CBO Tutorial
April 2004 Iceland
June 2004 UK - Optimising Oracle Seminar
"Jonathan Lewis" <jonathan_at_jlcomp.demon.co.uk> wrote in message
news:c2444u$sb3$1_at_hercules.btinternet.com...
>
> Notes inline
>
> --
> Regards
>
> Jonathan Lewis
> http://www.jlcomp.demon.co.uk
>
> The Co-operative Oracle Users' FAQ
> http://www.jlcomp.demon.co.uk/faq/ind_faq.html
>
> March 2004 Hotsos Symposium - The Burden of Proof
> Dynamic Sampling - an investigation
> March 2004 Charlotte OUG (www.cltoug.org) CBO Tutorial
> April 2004 Iceland
> June 2004 UK - Optimising Oracle Seminar
>
>
> "srivenu" <srivenu_at_hotmail.com> wrote in message
> news:1a68177.0403022222.47899f13_at_posting.google.com...
> > Whereas for an update, each block is pinned in current mode once for
> > every row updated. so if you have to update 10 rows in a block, the
> > block in pinned in current mode 10 times. There must be some reason
> > why all the rows in a block are not updated at one go while the block
> > is pinned in current mode.
>
> On an update, Oracle
> Generates a redo record for the log buffer
> acquires space in the log buffer
> pins the undo block and the data block
> writes the record into the log buffer
> updates the undo block
> updates the data block
> releases the pins
> Then repeats the process for each index
> affected by the row update.
>
> It would not be a trivial exercise for Oracle Corp.
> to modify the code to handle multiple updates to
> a single block as a single event. However, it does
> appear to have been done in (at least some cases in)
> 10g.
>
>
Received on Wed Mar 03 2004 - 02:23:26 CST
