Re: Disable logging in tablespace vs using hidden parameter _disable_logging

That is correct, and that is why the only way the _disable_logging feature affects things is by not doing the final write from buffer to file.

It does introduce the interesting question of how the forward change vectors for global temporary tables are "avoided".

Regards

Jonathan Lewis

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

http://www.jlcomp.demon.co.uk/cbo_book/ind_book.html Cost Based Oracle: Fundamentals

http://www.jlcomp.demon.co.uk/appearances.html Public Appearances - schedule updated 10th Jan 2006

• Original Message ----- From: "Alex Gorbachev" <gorbyx_at_gmail.com> To: <jonathan_at_jlcomp.demon.co.uk> Cc: <oracle-l_at_freelists.org> Sent: Thursday, February 02, 2006 11:23 PM Subject: Re: Disable logging in tablespace vs using hidden parameter _disable_logging

Jonathan,
If I am not mistaken Oracle first generates change vector writing it to the log buffer and then applies it. At least, this is what I've been taught.
If this stands correct than there is no way to really bypass redo log generation inside an Oracle instance. Is that correct? Thanks,
Alex

2006/2/2, Jonathan Lewis <jonathan_at_jlcomp.demon.co.uk>:
>
>
> For a large import, the point I was making about
> commits is pretty irrelevant. I was only thinking
> about the usual potential for latch collision and
> redo wastage for highly concurrent systems, and
> 'row at a time' batch processing.
>
> Everything that could normally cause a redo-related
> problem still can cause a problem with _disable_logging
> set to true apart from one little detail, which is the
> log file write time.
>
> Regards
>
> Jonathan Lewis

--
http://www.freelists.org/webpage/oracle-l