Alter database noarchivelog;
will change the entire database.
see the following for detailed information:
http://technet.oracle.com/docs/products/oracle8i/doc_index.htm
HTH, Jim
-Original Message-
To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
Date: Wednesday, March 2
i discuss this in my advanced logminer class but the gist is this,
nologging has no impact on DML.
only the following operations can make use of the NOLOGGING option:
alter table...move partition
alter table...split partition
alter index...split partition
alter index...rebuild
alter ind
that has nothing to do with the question. But anyway, try ALTER TABLE
NOLOGGING instead.
oli
[EMAIL PROTECTED] wrote
> Alter database noarchivelog;
>
> will change the entire database.
>
> see the following for detailed information:
>
> http://technet.oracle.com/docs/products/oracle8i/doc_ind
Yes you can issue the alter table nologging but it will only be relevant for
certain operations not all UPDATE, DELETE, conventional path INSERT
statements.
Jim
Reference the following I found on metalink:
Doc ID: Note:1038660.6
Type: PROBLEM
Status: PUBLISHED
Content Type: TEXT/PLAIN
Crea
ÌÌÌ
X-Declude-Sender: [EMAIL PROTECTED] [63.26
Hi Greg,
Delete isn't an operation that supports nologging. So you should see exactly the
same performance.
Regards,
Mike Hately
Oracle DBA
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author:
INET: [EMAIL PROTECTED]
Fat City Network Services-- (858) 538-5051
Hi Greg,
Yes, you should get a improve performance due to the nologging option in the
delete wont write redo log information.
Ramón Estévez
*809-565-3121 x 225
* [EMAIL PROTECTED]
-Mensaje original-
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Greg Solomon
En
Ramon,
That is not true. Setting NOLOGGING at the object
level only reduces the amount of redo generated for
bulk INSERT operations with the /*+ APPEND */ hint,
certain partition administration operations and of
course during the creation of the object itself. It
does not eliminate generation of
Title: RE: NOLOGGING
True,
but somebody on the list talked about "delete nologgin". I did not find immense benifit in this option. Any views on this?
-Original Message-
From: Gaja Krishna Vaidyanatha [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 26, 2001 6:10 AM
To
nombre de Gaja Krishna
Vaidyanatha
Enviado el: Monday, 25 June, 2001 9:10 PM
Para: Multiple recipients of list ORACLE-L
Asunto: RE: NOLOGGING
Ramon,
That is not true. Setting NOLOGGING at the object
level only reduces the amount of redo generated for
bulk INSERT operations with the /*+ APPEND
DELETE is not a finction that NOLOGGING has any effect on. You can't reduce the
amount of redo generated in a delete by making the object NOLOGGING. It is a
common misconception :-) that NOLOGGING pertains to all types of DML and DDL.
Please consult the following section of the Concepts Manual:
You're right Jeremiah,
tks
Ramon Estevez
*809-565-3121 x 225
* [EMAIL PROTECTED]
-Mensaje original-
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Jeremiah
Wilton
Enviado el: Tuesday, 26 June, 2001 11:16 AM
Para: Multiple recipients of list ORACLE-L
Asunt
Hi Raj
RTFM is a relational trace file management system. Originally released as
an add-on with 8.0.0.6, I think it now comes standard with 9i.
Cheers
Greg
-Original Message-
Sent: Monday, 25 June 2001 09:52
To: Greg Solomon
Greg
I'm curious.. Whats RTFM is??
Raj
-Original Mes
Greg,
In 9i our good old Relational Trace File Management has been renamed to Real
Trace File Management.
Worse than that. The Logical Oracle Listener option is now called Real Oracle
Transmission Failover Listener Management Advanced Option.
Regards,
Mike Hately
Oracle DBA
Greg Solomon <[
And the in 9i the old ora-00600 errors are now known as Strategic Open
Licensing.
joe
[EMAIL PROTECTED] wrote:
>
> Greg,
>
> In 9i our good old Relational Trace File Management has been renamed to Real
> Trace File Management.
>
> Worse than that. The Logical Oracle Listener option is now ca
: Multiple recipients of list ORACLE-L
<[EMAIL PROTECTED]>
Sent by: cc:
[EMAIL PROTECTED] Subject: RE: NOLOGGING F
There was similar Q from Vikas@innoventry a few days back
You cannot turn off logging.
Reason: Search through your mails dated 3 days back.
Rajaram.
-Original Message-
From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]]
Sent: Monday, May 14, 2001 12:36 PM
To: Multiple recipients o
Thanks Rajaram !
Here's the bottom line :
NOLOGGING doesn't apply to conventional DML at all ! It applies only to
CREATE/ALTER objects and Direct Load Inserts such as using SqlLoader or
INSERT as SELECT
-Original Message-
Sent: Monday, May 14, 2001 10:56 AM
To: Multiple recipients of
thanks
-Original Message-
Sent: Monday, May 14, 2001 2:39 PM
To: Multiple recipients of list ORACLE-L
Thanks Rajaram !
Here's the bottom line :
NOLOGGING doesn't apply to conventional DML at all ! It applies only to
CREATE/ALTER objects and Direct Load Inserts such as using SqlLoader
Hi, Igor,
Direct-path insert does not work for IOTs. This is documented in SQL Reference
for INSERT.
Whether it works for a table without NOLOGGING set (i.e. LOGGING) is not clear
to me. Documentation says the table has to be NOLOGGING, or its tablespace has
to be so. But Tom Kyte seems to show u
Yong,
M.b. my question was not clear.
I know, "nologging" doesn't work with IOTs.
What I'd like to know, if there are any "tricks" (similar to
direct-path) to minimize undo/redo when inserting into IOT.
Igor Neyman, OCP DBA
[EMAIL PROTECTED]
-Original Message-
Yong Huang
Sent: Wednesda
I see. Sorry for misreading.
How about direct path load? sqlldr direct=true. But this means your data source
is on the filesystem.
What is M.b.?
Yong Huang
--- Igor Neyman <[EMAIL PROTECTED]> wrote:
> Yong,
>
> M.b. my question was not clear.
> I know, "nologging" doesn't work with IOTs.
> Wha
Yong,
If the database is in ARCHIVELOG mode, then the table must be set to NOLOGGING
for append hint to work. If the database is in NOARCHIVELOG mode, then the table
setting does not matter.
Tom has not specified whether the database he tested against was in
NOARCHIVELOG mode or whether the t
Unfortunately my source is another table.
By the way (btw.), will " sqlldr direct=true" work with IOT?
"m.b" - may be.
Igor Neyman, OCP DBA
[EMAIL PROTECTED]
-Original Message-
Yong Huang
Sent: Wednesday, November 05, 2003 12:25 PM
To: Multiple recipients of list ORACLE-L
I see. Sorry
Thanks, Denny. That's it. I imagine Tom's test database is running in
noarchivelog mode and the tablespace is logging.
Yong Huang
--- Denny Koovakattu <[EMAIL PROTECTED]> wrote:
> Yong,
>
> If the database is in ARCHIVELOG mode, then the table must be set to
> NOLOGGING
> for append hint to wo
Yes, direct-path load works on IOTs, at least in 9.2 running in Solaris 2.8.
Yong Huang
--- Igor Neyman <[EMAIL PROTECTED]> wrote:
> Unfortunately my source is another table.
> By the way (btw.), will " sqlldr direct=true" work with IOT?
>
> "m.b" - may be.
>
> Igor Neyman, OCP DBA
> [EMAIL PRO
A trick, use a regular table and create an index that has all the needed
columns.
Waleed
-Original Message-
Sent: Wednesday, November 05, 2003 10:29 AM
To: Multiple recipients of list ORACLE-L
Yong,
M.b. my question was not clear.
I know, "nologging" doesn't work with IOTs.
What I'd li
Well, that's not a trick -:)
I wouldn't be asking, if I had enough space for both table and index.
It's a huge "narrow" table, which never gets updated (only
inserts/deletes) - perfectly fits IOT.
Igor Neyman, OCP DBA
[EMAIL PROTECTED]
-Original Message-
Khedr, Waleed
Sent: Wednesday, N
works and generates redo
-Original Message-
Sent: Wednesday, November 05, 2003 2:04 PM
To: Multiple recipients of list ORACLE-L
Yes, direct-path load works on IOTs, at least in 9.2 running in Solaris 2.8.
Yong Huang
--- Igor Neyman <[EMAIL PROTECTED]> wrote:
> Unfortunately my source i
Dennis,
We have set particular indexes to nologging when building them. These are
indexes that we drop every night for our warehouse load.
It is a hassle because whenever we clone this database to our QA box, those
nologged indexes get corrupt and we have to rebuild them. Takes us three
hou
Cherie
Thanks for the input. This would be an OLTP database, with continual
inserts/updates/deletes. I guess that CREATE INDEX NOLOGGING would save
something in the redo logs. I'm not convinced that having a tablespace
containing only indexes set to NOLOGGING would save redo. Since redo i
My understanding is...
If an INSERT into the table also inserts an entry into the index, that's
logged. An index is a data file, so if it changes that's going to be
logged. This will happen even if the index is NOLOGGING.
Creation of the index and some other operations won't be logged if NOLOG
SQL loader(direct load),direct inserts,
and create table as select...will not generate redo/undo by using NOLOGGING.
Your Transaction is logged while deleting rows, can't be blocked.
correct me if I am wrong.
Sunil Nookala
Database Analyst
Dell Corp
Austin, TX
-Original Message-
Sen
Title: RE: Nologging and redo generation
> -Original Message-
> From: Smith, Ron L. [mailto:[EMAIL PROTECTED]]
>
> Can I use the nologging option on simple inert and deletes to
> eliminate
> rollback problems and redo generation?
Which version of Oracle?
From
This is normal. When a transaction is set to
nologging, minimal redo is written because of Data
Dictionary changes that are occurring.
James
--- [EMAIL PROTECTED] wrote:
>
>
> I have been testing logminer and noticed that when I
> alter a table to
> NOLOGGING, txns are still recorded in the
John -
I had this same question not too long ago. This is what I found in
the documentation.
Only the following operations can make use of the NOLOGGING option:
alter table...move partition
alter table...split partition
alter index...split partition
alter index...rebuild
alter
Only "nologging supported" operations will not result
in logging eg create index, direct load insert and
other such operations...
hth
connor
--- [EMAIL PROTECTED] wrote: >
>
> I have been testing logminer and noticed that when I
> alter a table to
> NOLOGGING, txns are still recorded in the
37 matches
Mail list logo
