Re: Disable logging in tablespace vs using hidden parameter _disable_logging
- From: "Jonathan Lewis" <jonathan@xxxxxxxxxxxxxxxxxx>
- To: "Alex Gorbachev" <gorbyx@xxxxxxxxx>
- Date: Fri, 3 Feb 2006 07:45:56 -0000
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@xxxxxxxxx>
To: <jonathan@xxxxxxxxxxxxxxxxxx>
Cc: <oracle-l@xxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxxxxx>:
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
--
//www.freelists.org/webpage/oracle-l
Other related posts:
