LOGGING/NOLOGGING Clause

I am running an insert statement, my insert statement selects 8 million rows from table B and inserts into table A
insert into tableA (...)
select ... from tableB
I have altered both the tables to have NOLOGGING option.
Do you think this is the right way to do or I should turn NOLOGGING on tableA and LOGGING on tableB
Since it involves the insert and select of 8 millions I am converned about the performance and time it takes for the Insert to complete
Any suggestions and inputs would help
Thanks

Nologging work only with specific operations.
http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:485221567528
http://asktom.oracle.com/pls/ask/f?p=4950:8:10968141687231771204::NO::F4950_P8_DISPLAYID,F4950_P8_CRITERIA:5280714813869
In the am444's case, if table A is in nologging mode, he need use insert /*+ APPEND */ to not generate redo.
Nicolas.
Message was edited by:
N. Gasparotto

Similar Messages

Use of nologging clause

Hi, I was trying to use nologging clause to improve performance of DML on one of the table. however I observed that table with nologging option actually decreases the performance :(
please refer to following log.
SQL> create table test_log(id int, name char(40))
2 /
Table created.
Elapsed: 00:00:00.03
SQL> create table test_nolog(id int, name char(40)) nologging
2 /
Table created.
Elapsed: 00:00:00.00
SQL> insert into test_log select ROWNUM*-1,DBMS_RANDOM.STRING('A',1) FROM DUAL CONNECT BY LEVEL <=1000000
2 /
1000000 rows created.
Elapsed: 00:00:13.46
SQL> insert into test_nolog select ROWNUM*-1,DBMS_RANDOM.STRING('A',1) FROM DUAL CONNECT BY LEVEL <=1000000
2 /
1000000 rows created.
Elapsed: 00:00:16.95
SQL> update test_log set id=100
2 /
1000000 rows updated.
Elapsed: 00:00:46.35
SQL> update test_nolog set id=100
2 /
1000000 rows updated.
Elapsed: 00:00:49.43

Insert and update have no impacts whether the tables are created with NOLOGGING or LOGGING clause
It generates the same amount of redo for insert stmts as well as UPDATE stmts
NOLOGGING can help only for the following things
1.CTAS
2.SQL*Loader in direct mode
3.INSERT /*+APPEND*/ ...
SYSTEM@rman 15/12/2008> truncate table test_log;
Table truncated.
Elapsed: 00:00:01.49
SYSTEM@rman 15/12/2008> truncate table test_nolog;
Table truncated.
Elapsed: 00:00:00.67
SYSTEM@rman 15/12/2008> insert into test_nolog select ROWNUM*-1,DBMS_RANDOM.STRING('A',1) FROM DUAL CONNECT BY LEVEL <=1000000;
1000000 rows created.
Elapsed: 00:00:39.80
Execution Plan
Plan hash value: 1731520519
| Id | Operation                     | Name | Rows | Cost (%CPU)| Time     |
|   0 | INSERT STATEMENT              |      |     1 |     2   (0)| 00:00:01 |
|   1 | COUNT                        |      |       |            |          |
|* 2 |   CONNECT BY WITHOUT FILTERING|      |       |            |          |
|   3 |    FAST DUAL                  |      |     1 |     2   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - filter(LEVEL<=1000000)
Statistics
       3081 recursive calls
      41111 db block gets
       8182 consistent gets
          0 physical reads
   60983504 _redo size_
        674 bytes sent via SQL*Net to client
        638 bytes received via SQL*Net from client
          3 SQL*Net roundtrips to/from client
          2 sorts (memory)
          0 sorts (disk)
    1000000 rows processed
SYSTEM@rman 15/12/2008> commit;
Commit complete.
Elapsed: 00:00:00.03
SYSTEM@rman 15/12/2008> insert into test_log select ROWNUM*-1,DBMS_RANDOM.STRING('A',1) FROM DUAL CONNECT BY LEVEL <=1000000;
1000000 rows created.
Elapsed: 00:00:38.79
Execution Plan
Plan hash value: 1731520519
| Id | Operation                     | Name | Rows | Cost (%CPU)| Time     |
|   0 | INSERT STATEMENT              |      |     1 |     2   (0)| 00:00:01 |
|   1 | COUNT                        |      |       |            |          |
|* 2 |   CONNECT BY WITHOUT FILTERING|      |       |            |          |
|   3 |    FAST DUAL                  |      |     1 |     2   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - filter(LEVEL<=1000000)
Statistics
       3213 recursive calls
      41323 db block gets
       8261 consistent gets
          2 physical reads
   60993120 _redo_ size
        674 bytes sent via SQL*Net to client
        636 bytes received via SQL*Net from client
          3 SQL*Net roundtrips to/from client
          2 sorts (memory)
          0 sorts (disk)
    1000000 rows processed
SYSTEM@rman 15/12/2008> commit;They simply generate the same anount of redo
If you use APPEND hint you can reduce the INSERT stmt timings
SYSTEM@rman 15/12/2008> truncate table test_nolog;
Table truncated.
Elapsed: 00:00:00.28
SYSTEM@rman 15/12/2008> INSERT /*+ APPEND */ into test_nolog select ROWNUM*-1,DBMS_RANDOM.STRING('A',1) FROM DUAL CONNECT BY LEVEL <=100
1000000 rows created.
Elapsed: 00:00:28.19
Execution Plan
ERROR:
ORA-12838: cannot read/modify an object after modifying it in parallel
SP2-0612: Error generating AUTOTRACE EXPLAIN report
Statistics
       3125 recursive calls
       8198 db block gets
        929 consistent gets
          0 physical reads
     161400 redo size
        660 bytes sent via SQL*Net to client
        652 bytes received via SQL*Net from client
          3 SQL*Net roundtrips to/from client
          2 sorts (memory)
          0 sorts (disk)
    1000000 rows processed
SYSTEM@rman 15/12/2008> You can aslo notice significant time difference/redo generated between INSERT and INSERT with append on a NOLOGGING table

NOLOGGING CLAUSE

Hi,
I would like to know that if we have our database in FORCE LOGGING mode with standby databases,could cause some kind of conflicts if we create then objects with the NOLOGGING clause?? , something like corrupt the standby databases??
The objects that we would like to create with NOLOGGING clause are temporary tables for example, which ones, we don't need a log for they. And it seems it could help to the performance if we set it in NOLOGGING those objects.
But we are not sure if this clause will be ignored or if it could cause confusion??
Thanks in advance,

>
CREATE TABLE TABLE_NAME (column_name varchar(2)...) NOLOGGING
Now, using this, the table will be populated, it will be used and then the information will be deleted.
It doesn't matter if the information is not logged and recovered in a recovery database, due to that for us is like a temporary table.
So, the question is: There will be some impact in the database or in the db recovery if we use the object above using NOLOGGING clause??
>
As the table that you are creating is a permanent table, and the database is in logging mode, as written by you in your very first post , the redo will be generated.As the database is in FORCE LOGGING mode, the information will be logged into the redo.So, this information will also be archived and applied to the DR.The NOLOGGING clause won't be having any effect.
Secondly, if the table is going to be populated and then the whole table is going to be deleted then why not use TEMPORARY TABLE.
Refer to [http://download.oracle.com/docs/cd/B14117_01/server.101/b10739/tables.htm#sthref1862]
Anand

INSERT WITH NOLOGGING CLAUSE

CAN WE ROLLBACK TRANSACTION IF WE YOU INSERT WITH NOLOGGING CLAUSE ???

ORACLE 'STUDNET',
IT IS APPRECIATED YOU STUDY ORACLE BY READING MANUALS, AND TRYING THINGS YOURSELF, INSTEAD OF REQUESTING BEING SPOON FED FOR EVERY QUESTION YOU HAVE.
ALSO IT IS APPRECIATED YOU DON'T Y E L L YOUR QUESTIONS!!!
Sybrand Bakker
Senior Oracle DBA

Materialized View Log - Compress Clause for List Partition

Hi All,
In Syntax diagram it states that Compress Clause for List Partition of Materialized View Log is valid , but when we run any script with compress clause for list partition on Materialized view log then Database throws error as ORA-14020: this physical attribute may not be specified for a table partition
So in any chance we can have the compress clause for the partition of materialized view log.
Thanks in advance,
Manu.

The "CREATE MATERIALIZED VIEW LOG" syntax refers to the "Table Partitioning" section of the CREATE TABLE documentation.
The "Table Partitioning" section refers to "table_partition_description" which then refers to "table_compression". "table_compression" then states that you can specify compression for entire table in the physical_properties clause and for range partition / list partition in the "table_partition_description". The Restrictions section on Table Compression says "You cannot define table compression explicitly for hash partitions or hash and list subpartitions" which implies that you can define partition for list partitions.
Moreover, error 14020 lists valid options for Range or Composite Range and for Hash partitoins -- which implies that all other Table physical attributes are applicable for List partitions. (But then, is Compression a physical attribute -- it is really part of "physical properties" not "physical attributes").
I think that the documentation isn't explicit enough and needs to be fixed.
N.B : Referencing the 10.2 documentation.
Hemant K Chitale
Edited by: Hemant K Chitale on Feb 1, 2010 4:12 PM

Logging/nologging

what is the usage of creating table with nologging, by default logging while creating table .
kindly temme the solution

Morgan, Please check the following:
a.     log_mode from v$database
b.     Is the database configured to be in force logging?
c.     Is the tablespace on which the table reside, configured to be in force logging?
In addition, here is the complete example (including ctas), using Tom Kyte mystats script:
SQL> create table nolog nologging as
2 select cast(' ' as char(2000)) as str
3 from dual connect by level <=1000;
Table created.
SQL> @c:\mystats "redo size"
NAME                                  VALUE
redo size                         8,662,356
SQL> create table yeslog logging as
2 select cast(' ' as char(2000)) as str
3 from dual connect by level <=1000;
Table created.
SQL> @c:\mystats2
NAME                                    V DIFF
redo size                        11466672        2,804,316Using the nologging in the ctas we avoided from generating a 2,804,316 of redo!
another one:
SQL> alter table nolog move;
Table altered.
SQL> @c:\mystats "redo size"
NAME                                  VALUE
redo size                        11,530,252
SQL> alter table yeslog move;
Table altered.
SQL> @c:\mystats2
NAME                                    V DIFF
redo size                        14340152        2,809,900Using the nologging in the "alter table move" we avoided from generating a 2,809,900 of redo!
and here is another one:
SQL> create index nolog_a1 on nolog(str) nologging;
Index created.
SQL> @c:\mystats "redo size"
NAME                                  VALUE
redo size                        14,409,096
SQL> create index yeslog_a1 on yeslog(str) logging;
Index created.
SQL> @c:\mystats2
NAME                                    V DIFF
redo size                        18141176        3,732,080and here is another one:
SQL> alter index nolog_a1 rebuild nologging;
Index altered.
SQL> @c:\mystats "redo size"
NAME                                  VALUE
redo size                        18,219,204
SQL> alter index yeslog_a1 rebuild logging;
Index altered.
SQL> @c:\mystats2
NAME                                    V DIFF
redo size                        21959552        3,740,348Don't forget to backup your objects, after all this nologging actions!
Amiel

Archive log / nologging/ direct path insert

Could you please confirm if following are true or correct me if my understanding is wrong:
1 ) Archive log mode and LOGGING is needed to deal with media recovery; it was not needed for instance recovery.
2) IF insert is in NO APPEND mode , redo is generated even if table is in nologging mode and database is in noachive log mode. This redo is needed for instance recovery.
3) Direct path insert skips undo generation and may skip redo generation if the object is in nologging mode.
Thanks.
In case if it is relevant , I am using Oracle 11.2.0.3.

1) Yes, Archive logs are needed for media recovery.
2 and 3) Even if the table is in nologging mode , it generates little bit of redo for index maintenance and dictionary data. Upon a restart from a failure - Oracle will read the online redo logs and replay any transaction it finds in there. That is the "roll forward" bit. The binary redo information is used to replay everything that did not get written to the datafiles. This replay included regenerating the UNDO information (UNDO is protected by redo).
After the redo has been applied, the database is typically available for use now - and the rollback phase begins. For any transaction that was being processed when the instance failed - we need to undo its changes, roll it back. We do that by processing the undo for all uncommitted transactions.
The database is now fully recovered.
Also read he following link
http://docs.oracle.com/cd/B19306_01/server.102/b14220/startup.htm
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:5280714813869

Is imp logging/nologging aware ?

Hi,
I'm looking a way to reduce redo generation during import via imp utility in oracle 10g (imp because exp was done in 9i so no impdp allowed).
And I wonder if setting table to NOLOGGING after importing with rows=n can reduce redo generation rate when
doing second step which is imp ... GRANTS=n INDEXES=N ROWS=y CONSTRAINTS=n ANALYZE=n commit=y ignore=y buffer=8388608 recordlength=65535 ...
Regards.
Greg

Please read Re: import with no logging option

Confusion on nologging clause - for create table

hi guys,
just 1 simple question.
q1) when i create a table via no logging, is the CREATION of the table not logged as well ?
Regards,
Noob

OracleWannabe wrote:
q1) when i create a table via no logging, is the CREATION of the table not logged as well ?If the table is created empty (as in not using a create table as select or CTAS) then there is no difference in the create step. The difference between LOGGING and NOLOGGING takes place for direct path operations.
The Oracle Docs give a very good explanation:
http://download.oracle.com/docs/cd/B28359_01/server.111/b28313/usingpe.htm#i1009116
Regards,
Greg Rahn
http://structureddata.org

Error during altering a domain index - 10gr2

10.2.0.5 on RHEL-4
I would like to reduce some redo entries to prevent huge generation of archive-logs.
select index_name, table_owner, table_name, tablespace_name from user_indexes where index_type='DOMAIN' and logging='YES';
SQL> alter INDEX ISE_HIST#LOC nologging;
alter INDEX ISE_HIST#LOC nologging
ERROR at line 1:
ORA-29871: invalid alter option for a domain index
Why I am unable to convert into no-logging mode ? What is the correct way of doing this?
Thanks!

>
I would like to reduce some redo entries to prevent huge generation of archive-logs.
select index_name, table_owner, table_name, tablespace_name from user_indexes where index_type='DOMAIN' and logging='YES';
SQL> alter INDEX ISE_HIST#LOC nologging;
alter INDEX ISE_HIST#LOC nologging
ERROR at line 1:
ORA-29871: invalid alter option for a domain index
Why I am unable to convert into no-logging mode ? What is the correct way of doing this?
>
As the exception message says you can't use the logging/nologging clause for domain indexes. Oracle doesn't support that functionality.
See ALTER INDEX in the SQL Language doc
>
index
Specify the name of the index to be altered.
Restrictions on Modifying Indexes The modification of indexes is subject to the following restrictions:
•If index is a domain index, you can specify only the PARAMETERS clause, the RENAME clause, the rebuild_clause (with or without the PARAMETERS clause), the parallel_clause, or the UNUSABLE clause. No other clauses are valid.
•You cannot alter or rename a domain index that is marked LOADING or FAILED. If an index is marked FAILED, the only clause you can specify is REBUILD.
>
The first bullet point above itemizes the clauses you can specify for a domain index and LOGGING/NOLOGGING is not one of them. As that point says 'No other clauses are valid'.
There are no workarounds.

Create table with logging clause....

hi,
just reading this http://docs.oracle.com/cd/B19306_01/server.102/b14231/tables.htm#ADMIN01507
it mention under Consider Using NOLOGGING When Creating Tables:
The NOLOGGING clause also specifies that subsequent direct loads using SQL*Loader and direct load INSERT operations are not logged. S*ubsequent DML statements (UPDATE, DELETE, and conventional path insert) are unaffected by the NOLOGGING attribute of the table and generate redo.*
Help me with my understanding. Does it mean that when you create a table using logging clause and then when you need to do a direct loads, you can specify nologging to reduce the redo log. The nologging part will only work for this activity but not on DML operation even when you specify nologging?

sybrand_b wrote:
Nologging basically applies to the INSERT statement with the APPEND hint. Direct load means using this hint.
All other statements are always logging regardless of any table setting.>
Sybrand Bakker
Senior Oracle DBAi did a few test :
create table test
(id number) nologging;
Table created.
insert into test values (1);
1 row created.
commit;
Commit complete.
delete from test;
1 row deleted.
rollback;
Rollback complete.
select * from test;
ID
1there is no logging on table- level and tablespace - level. So what i am doing is to check -> Subsequent DML statements (UPDATE, DELETE, and conventional path insert) are unaffected by the NOLOGGING attribute of the table and generate redo."
the above makes me confuse cos isn't rollback related to UNDO tablespace not redo log. So one can still rollback even when it is in no logging.
REDO log is for rolling forward , recovery when there is a system crash... ..

Removing NOLOGGING and not explicitly designating LOGGING

We have a table that was created similar to:
create table aTableName
( col1 integer,
colN
) tablespace someName nologging;
Is there an alter command that will put the status of logging for the table the same as if it were created
create table aTableName
( col1 integer,
colN
) tablespace someName;
Also, are there three states for logging:
1. LOGGING
2. NOLOGGING
3. (undefined)
I think I am asking to put logging in the third (undefined) state?

Kent Waldrop wrote:
Is there an alter command that will put the status of logging for the table the same as if it were createdNo. All you can do is explicitly set table to LOGGING or NOLOGGING:
ALTER TABLE table_name [NO]LOGGING;
Also, are there three states for logging:
1. LOGGING
2. NOLOGGING
3. (undefined)
No, there is only LOGGING or NOLOGGING. Just open docs and you will see that default value is LOGGING. So if you create table without specifying LOGGING/NOLOGGING table will be created with LOGGING:
SQL> create table test_logging(x number)
2 /
Table created.
SQL> select logging
2 from user_tables
3 where table_name = 'TEST_LOGGING'
4 /
LOG
YES
SQL> SY.

Set logging to NO for all index in primary DB

Hi,
can i set the logging option to NO for all index in primary DB (versus standby DB).
Because the execute plan of queries changes with this option and the time it's very long for geats tables if the option logging it's YES.
Regards.

Hi,
personally I have never seen that execution plan changes if objects in nologging mode. Could you show sql statements that have changed execution plans due to nologging clause.
Thanks,
Andrey

Online backups on BIW systems, every update is logged?

Some years ago I was at an SAP BIW installation, they performed Oracle online backups dayly.
For some reason, they had to restore and recover DB, and after using an online backup as a restore basis, some indexes were not usable, because they had been updated without archive log information.
Finally, the easiest way for the system administator was using an offline backup.
I got to know there were some updates (not critical) not being logged in the DB, so online backups, as well as standby DB would not be as useful as on OLTP systems.
Does somebody know if this is or this is not the same nowadays? Is everything logged on a BW system? Is that a tunable configuration for some indexes? Is an online backup really useful after restoring and recovering?
Thanks very much for your experience and answers !!
Eva

Hello Eva,
> For some reason, they had to restore and recover DB, and after using an online backup as a restore basis, some indexes were not usable, because they had been updated without archive log information.
This behaviour is absolutely normal.
In a BW system the indexes are created / rebuild with the NOLOGGING clause, because of some performance reasons.
> Finally, the easiest way for the system administator was using an offline backup.
The easiest yes - but concurrently the worst one. He can identify the "new" indexes since the last online backup and only recreate this ones.
> Does somebody know if this is or this is not the same nowadays?
Yes the NOLOGGING clause is still used nowadays.
> Is everything logged on a BW system?Is that a tunable configuration for some indexes?
You can "deactivate" the NOLOGGING clause.. but then you can have some performance impacts in your BW load processes.
Check sapnote #442763 for the customizing.
> Is an online backup really useful after restoring and recovering?
Yes, of course .. the ONLINE backup is the preferred method.
If you recover your database with the BR*Tools .. your unusable indexes are automatically rebuild.
Check sapnote #849485 for that feature.
Regards
Stefan

Reduce amount of archived log generated.

RDBMS version : 9.2.0.8
SQL> SELECT tablespace_name, force_logging FROM dba_tablespaces;
TABLESPACE_NAME FORCE_LOGGING
SYSTEM NO
Above is what status of database, but when I do maintenance work of rebuilding index tablespace I get day or two worth of archived log files.
and I dont' think ALTER DATABASE no force logging will reduce the amount of log generated.
Is there any other method available?
thanks

Hi,
if you force logging for a tablespace or for the database, then this means only that any nologging clause that comes with statements related to segments in that tablespace/database is ignored. No force logging is the default.
In order to reduce the amount of redo protocol, you may consider to use NOLOGGING for the rebuild of your indexes:
create index <indexname> on <table(column)> nologging;Or you put the tablespace in NOLOGGING in which the indexes are created in:
alter tablespace <indextablespace> nologging;Or (perhaps even better) simply leave the indexes as they are. Most indexes do not need a rebuild anyway.
Kind regards
Uwe
http://uhesse.wordpress.com

LOGGING/NOLOGGING Clause

Similar Messages

Maybe you are looking for