Nologging/logging

We have a database in ARCHIVELOG mode.
There are tablespaces that are in nologging and tables that are in nologging.
From my reading, Am I to understand that we could still perform a forward recovery using a weekly backup plus any archived logs for these tables ?
Also,
If one of these tables has a CLOB, and the CLOB definition within the DDL reads nologging, but the table is logging, can we still forward recover the CLOB's.
I understand that if we use direct path loads, Oracle will mark these segments as unrecoverable, but we still should be able to restore all the other data to a point in time ..

The fact that a table is NOLOGGING has no impact on the redo generated by normal DML operations, which is why you would generally be able to roll forward from a backup to the current point in time. NOLOGGING allows you to bypass redo generation only for a very, very small subset of operations (like direct path loads).
Justin

Similar Messages

  • How to update more than 5 million records without error message ORA-00257:

    Hi ,
    I need to update some columns in my table which is contains about 5 million records
    I 've already tried this
    Update AAA_CDR
    Set RoamFload = Null ;
    but the problem is I've got the error message ("ORA-00257: archiver error. Connect internal only,until freed.) and the update consuming about 6 hours with no results ,
    then I do the commands ( Alter system set db_recovery_file_dest_size=50G) and the problem solved .
    but I need to update about 15 columns of this table to be null ,what I should do to overcome this message and update the table in reasonable time
    Please Help Me ,

    The best way would be to allocate sufficient disk space for your archive log destination. Your database is not sized properly. NOLOGGING option will not do much for you because it' only applies to direct load operations when the data inserted into nologging table is selected from another table. UPDATE will be be logged, regardless of the NOLOGGING status. Here is the quote from the manual:
    <quote>
    LOGGING|NOLOGGING
    LOGGING|NOLOGGING specifies that subsequent Direct Loader (SQL*Loader) and direct-load
    INSERT operations against a nonpartitioned index, a range or hash index partition, or
    all partitions or subpartitions of a composite-partitioned index will be logged (LOGGING)
    or not logged (NOLOGGING) in the redo log file.
    In NOLOGGING mode, data is modified with minimal logging (to mark new extents invalid
    and to record dictionary changes). When applied during media recovery, the extent
    invalidation records mark a range of blocks as logically corrupt, because the redo data
    is not logged. Therefore, if you cannot afford to lose this index, you must take a backup
    after the operation in NOLOGGING mode.
    If the database is run in ARCHIVELOG mode, media recovery from a backup taken before an
    operation in LOGGING mode will re-create the index. However, media recovery from a backup
    taken before an operation in NOLOGGING mode will not re-create the index.
    An index segment can have logging attributes different from those of the base table and
    different from those of other index segments for the same base table.
    </quote>
    If you are really desperate, you can try the following undocumented/unsupported command:
    ALTER DATABASE ARCHIVELOG COMPRESS ENABLE;
    That will cause database to compress your archive logs and consume less space. This command is not documented or supported, not even in the version 11.2.0.3 and causes the database to start spewing ORA-0600 in version 10G. DO NOT USE IN A PRODUCTION ENVIRONMENT!!!!

  • APPEND hints

    hi ,
    to my knowledge APPEND hints is to prevent writing to the log file ?
    so my following statement
    insert /*+ APPEND */ into tbl1 SELECT * from tbl2 will prevent the logging ?
    but it gave the following error : ORA-04030: out of process memory when trying to allocate 16504 bytes (pga heap,ksm stack)
    pls advise
    tks & rdgs

    NOLOGGING by Tom Kyte:
    the entire point of nologging is NOT TO GENERATE REDO for many operations --
    these objects are by definition "not recoverable" after these operations until
    you back them up.
    When you create a table or index in nologging -- the initial create is *not
    logged*. Hence, if you restore a backup from BEFORE the time of the create and
    you restore that backup -- all of the blocks that never had redo -- are missing!
    (not corrupt -- missing, purposely -- you told us to make them go away).
    when using a standby database for disaster recovery -- you cannot perform
    nologging operations without performing additional, manual work (in fact, in 9i,
    we can set a flag that says "ignore the request for nologging -- log it anyway"
    on the database to avoid this issue alltogether).

  • 数据库归档模式与非归档模式下各种加载数据方式对redo的影响

    redo
    重做日志文件（redo log file）对Oracle数据库来说至关重要，它们是数据库的事务日志。Oracle维护着两类重做日志文件：
    在线（online）重做日志文件和归档（archived）重做日志文件。这两类重做日志文件都用于恢复；其主要目的是，
    万一实例失败或介质失败，它们就能派上用场。
    如果数据库所在主机掉电，导致实例失败，Oracle会使用在线重做日志将系统恰好恢复到掉电之前的那个时间点。
    如果磁盘驱动器出现故障（这是一个介质失败），Oracle会使用归档重做日志以及在线重做日志将该驱动器上的
    数据备份恢复到适当的时间点。
    归档重做日志文件实际上就是已填满的"旧"在线重做日志文件的副本。系统将日志文件填满时，
    ARCH进程会在另一个位置建立在线重做日志文件的一个副本，也可以在本地和远程位置上建立多个另外的副本.
    如果由于磁盘驱动器损坏或者其他物理故障而导致失败,就会用这些归档重做日志文件来执行介质恢复.
    Oracle拿到这些归档重做日志文件，并把它们应用于数据文件的备份，使这些数据文件能与数据库的其余部分保持一至.
    归档重做日志文件是数据库的事务历史。
    测量redo
    redo管理是数据库中的一个串行点.任何Oracle实例都有一个LGWR，最终所有事务都会归于LGWR，要求这个进程管理它们的redo,
    并COMMIT其事务,LGWR工作越忙,系统就会越慢.通过查看一个操作会生成多少redo,并对一个问题的多种解决方法进行测试,
    可以从中找出最佳的方法。
    与redo有关的视图
    V$MYSTAT，其中有会话的提交信息
    V$STATNAME，这个视图能告诉我们V$MYSTAT中的每一行表示什么（查看的统计名）。
    查询redo大小的语句
    SELECT a.NAME,
    b.VALUE cur_size_byte,
    round(b.VALUE / 1024, 3) || 'KB' cur_size_kb
    FROM v$statname a, v$mystat b
    WHERE a.statistic# = b.statistic#
    AND lower(a.NAME) LIKE '%' || lower('redo size') || '%'
    数据库归档模式
    数据库归档用来保存redo的日志文件副本,一般安装时默认未开启数据库的归档模式。
    在NOARCHIVELOG模式的数据库中,除了数据字典的修改外,CREATE TABLE不会记录日志.
    如果你想在NOARCHIVELOG模式的数据库上看到差别,可以把对表T的DROP TABLE和CREATE TABLE换成DROP INDEX和CREATE INDEX。
    默认情况下,不论数据库以何种模式运行，这些操作都会生成日志。
    因为不同的模式可能导致不同的行为。你的生产系统可能采用ARCHIVELOG模式运行.
    倘若你执行的大量操作在ARCHIVELOG模式下会生成redo,而在NOARCHIVELOG模式下不会生成redo,
    你肯定想在测试时就发现这一点，而不要等到系统交付给用户时才暴露出来！
    查看是否归档
    查看数据库是否开启归档
    select name,log_mode from v$database;
    启用归档
    startup mount
    alter database archivelog;
    alter database open;
    禁止归档
    shutdown immediate
    startup mount
    alter database noarchivelog
    alter database open
    force logging(强制日志)模式：
    如果数据库强制日志模式开启后,则Oracle无论什么操作都进行redo的写入。
    查看强制日志模式
    通过
    select force_logging from v$database
    可以看到当前数据库是否开启了强制日志模式状态
    开启强制日志模式
    如果未开启数据库强制日志模式（默认未开启），则可以通过
    alter database force logging开启,之后Oracle无论什么操作都进行redo的写入,不依赖于数据库的归档模式等其他因素.
    关闭强制日志模式
    如果已经开启了数据库强制日志模式，则可以通过
    alter database no force logging关闭强制日志模式。
    使数据库恢复先前的设置,数据库是否写入redo由数据库的归档模式等其他因素决定
    disable_logging
    那么在Oracle内部还存在一个内部参数：_disable_logging 默认是false
    通过更改为true可以让Oracle在修改表中的记录的时候完全不记录redo,这个参数要甚用,平时,我们只作为性能测试用。
    查看：show parameter disa /disable/_disable_logging
    开启：alter system set "_disable_logging"=true scope=both;
    禁用：alter system set "_disable_logging"=false
    表的归档模式
    查看表的logging模式
    查看表是否是logging状态用如下SQL:
    select table_name,logging from dba_tables where table_name='tablename';
    修改表的logging模式
    修改表的logging状态sql:
    alter table table_name nologging/logging
    减少redo写入
    本节所讲的都是当数据库未开启强制日志模式时的操作。
    对象的操作在执行时会产生重做日志,采用某种方式,生成的redo会比平常(即不使用NOLOGGING子句时)少得多.
    注意,这里说"redo"少得多,而不是"完全没有redo".所有操作都会生成一些redo,不论数据库的日志模式是什么,
    所有数据字典操作都会计入日志。
    如何减少redo
    create table时减少redo的方法
    创建表时crate table as加入nolongging选项减少redo，格式如下
    create table [table_name] nologging as [select表达式]。
    insert into减少redo的方法
    insert 大批量数据时加入/*+append */选项减少redo写入,格式如下
    insert /*+append */ into   [table_name] [select表达式]
    数据库归档模式下生成redo规则
    create table时nologging效果
    归档模式下创建的表，默认为logging模式。
    创建表时crate table as加入nolongging选项减少redo写入明显
    验证
    下面比较以下两种create table as时产生的redo size量。
    SELECT a.NAME,
    b.VALUE cur_size_byte,
    round(b.VALUE / 1024, 3) || 'KB' cur_size_kb
    FROM v$statname a, v$mystat b
    WHERE a.statistic# = b.statistic#
    AND lower(a.NAME) LIKE '%' || lower('redo size') || '%'
    查询当前的重做日志大小记录下来
    create table test_1 as select * from test;
    SELECT a.NAME,
    b.VALUE cur_size_byte,
    round(b.VALUE / 1024, 3) || 'KB' cur_size_kb
    FROM v$statname a, v$mystat b
    WHERE a.statistic# = b.statistic#
    AND lower(a.NAME) LIKE '%' || lower('redo size') || '%'
    查询当前的重做日志大小减去前面记录下来的值计算刚才这个操作产生的redo大小标记为redo_1
    SELECT a.NAME,
    b.VALUE cur_size_byte,
    round(b.VALUE / 1024, 3) || 'KB' cur_size_kb
    FROM v$statname a, v$mystat b
    WHERE a.statistic# = b.statistic#
    AND lower(a.NAME) LIKE '%' || lower('redo size') || '%'
    查询当前的重做日志大小记录下来
    create table test_2 nologging as select * from test;
    SELECT a.NAME,
    b.VALUE cur_size_byte,
    round(b.VALUE / 1024, 3) || 'KB' cur_size_kb
    FROM v$statname a, v$mystat b
    WHERE a.statistic# = b.statistic#
    AND lower(a.NAME) LIKE '%' || lower('redo size') || '%'
    查询当前的重做日志大小减去前面记录下来的值计算刚才这个操作产生的redo大小标记为redo_2
    比较redo_1和redo_2的大小就知道crate table as加入nolongging或不加nologging选项的区别了
    insert into时加入append效果
    表模式logging
    当表模式为logging状态时,无论是append模式还是no append模式,redo都会生成,即加入append选项无法生效。
    验证
    下面比较以下两种insert时产生的redo size量,可以看出redo量是差不多的。
    计算重做大小的方法与上面的一样就不说了
    1、insert /*+append */ into test_1 select * from test;
    commit;
    2、insert into test_1 select * from test;
    commit;
    表模式nologging
    当表模式为nologging状态时,只有加入append模式会明显减少生成redo。
    验证
    1、insert /*+append */ into test_1 select * from test;
    commit;
    2、insert into test_1 select * from test;
    commit;
    数据库非归档模式生成redo规则
    create table 使用nologging对产生redo的影响
    非归档模式下创建的表，默认为nologging模式。
    在NOARCHIVELOG模式的数据库中，除了数据字典的修改外，CREATE TABLE不会记录日志。
    因此创建表时（crate table as）加入nologging选项减少redo写入不明显,即nologging选项加不加都差不多
    验证
    下面比较以下两种create table as时产生的redo size量。
    create table test_1 as select * from test;
    create table test_2 nologging as select * from test;
    insert into时append效果
    表模式logging
    当表模式为logging状态时,加入append模式明显减少生成redo,而no append模式下不会减少生成。
    验证
    insert /*+append */ into test_1 select * from test;
    commit;
    insert into test_1 select * from test;
    commit;
    表模式nologging
    当表模式为nologging状态时，append的模式会减少生成redo,而no append模式不会减少生成。
    验证
    insert /*+append */ into test_1 select * from test;
    commit;
    insert into test_1 select * from test;
    commit;

    Good Post! 代码注意用code模式，
    如何使用code模式
    请参考如何在OTN中文技术论坛提一个问题？

  • Finding which table generated how much redo

    I'm wondering if we can find from any view that during this period a particular table generated how much amount of redo log , other than logminer ?
    We have a particular application and want to know which tables are generating most of the redo.

    from asktom
    see
    http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:477221446020
    and
    http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:366018048216
    Nologging only affects very very specific operations. For exmaple, from the
    alter index syntax statement in the SQL reference:
    LOGGING|NOLOGGING
    LOGGING|NOLOGGING specifies that subsequent Direct Loader (SQL*Loader) and
    direct-load INSERT operations against a nonpartitioned index, a range or hash
    index partition, or all partitions or subpartitions of a composite-partitioned
    index will be logged (LOGGING) or not logged (NOLOGGING) in the redo log file.
    In NOLOGGING mode, data is modified with minimal logging (to mark new extents
    invalid and to record dictionary changes). When applied during media recovery,
    the extent invalidation records mark a range of blocks as logically corrupt,
    because the redo data is not logged. Therefore, if you cannot afford to lose
    this index, you must take a backup after the operation in NOLOGGING mode.
    If the database is run in ARCHIVELOG mode, media recovery from a backup taken
    before an operation in LOGGING mode will re-create the index. However, media
    recovery from a backup taken before an operation in NOLOGGING mode will not
    re-create the index.
    An index segment can have logging attributes different from those of the base
    table and different from those of other index segments for the same base table.
    That also explains why the truncate above generated redo -- The statement
    "minimal logging (to mark new extents invalid and to record dictionary
    changes)." explains where that redo comes from. The blocks that were truncated
    were not logged HOWEVER the changes to the data dictionary itself were.
    .

  • Impact of Logging INDEX on Nologging object(TABLE) at the time of Recoveryt

    Hi All,
    If I have a TABLE which is of NOLOGGING Mode and the index on this table is of LOGGING Mode. If I want to Recover this table in case of its lost. How It will impact? Will it give any Error? Please Explain.....
    Thanks in Advance.

    You could always do this at the time of the backup to ensure no logging objects are recoverable from the backup at that point in time.......
    "alter database force logging "......... this enables the DBA to override no logging to ensure recoverability.

  • Trying to log in using sqlplus /nolog and getting SP2-0640

    Hello, I searched for this problem but not having much luck. I have Oracle 9iR2 running on Solaris 9 workstation. I can log on giving sys/passwd as sysdba and log on using any other user accounts. What I can't do is get into sqlplus using /nolog. I am setting up a dataguard physical clone. The clone is another 9iR2 workstation and i just installed the RDBMS software without creating a database. I can go into this database with sqlplus /nolog. I cannot do this on my intended primary database. I remember being able to get into the database when i first set it up using sqlplus /nolog but have since changed the unix account password and i believe this caused it but when i change the password back to the same one when I created the database, it still does not work. The error I get is SP2-0640: Not connected. Is there a log I can look up that will give me more information? thanks,
    Jim

    Normally this errors occurs, if you have in glogin.sql (located in $ORACLE_HOME/sqlplus/admin) or login.sql statements,which require a working connection.
    Werner

  • Advantage of FORCE LOGGING over NOLOGGING

    Hi,
    Can you please help me on the advantages of using force logging mode with a standby database and the effect of it in indexes etc. Also, it may help if you could also share ideas on difference between the two modes?
    Thanks,
    Jennah

    <i>>>  Can you help me what factors would be sacrificed</i>
    This really depends on your system, in most cases you will not be able to see a difference. However i did a small test:
    - drop index, restart db
    - create index with logging (measure time/redo size)
    - drop index, restart db
    - create index with logging (measure time/redo size)
    Result:
    logging - Elapsed: 00:02:40.68  / Redo size: 800mb
    nologging - Elapsed: 00:02:20.29 / Redo size: 1.5mb
    Here the full test:
    [code]SQL> select a.name, b.value from v$statname a, v$mystat b where a.statistic# = b.statistic# and a.name = 'redo size';
    NAME                                                                  VALUE
    redo size                                                             28304
    SQL> CREATE UNIQUE INDEX "SAPR3"."CDCLS~0" ON "SAPR3"."CDCLS"
    ("MANDANT", "OBJECTCLAS", "OBJECTID", "CHANGENR", "PAGENO")
      PCTFREE 10 INITRANS 2 MAXTRANS 255
      STORAGE(INITIAL 65536 NEXT 65536 MINEXTENTS 1 MAXEXTENTS 2147483645
      PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
      TABLESPACE "PSAPCLUI" LOGGING;
    Index created.
    Elapsed: 00:02:40.68
    SQL> select a.name, b.value from v$statname a, v$mystat b where a.statistic# = b.statistic# and a.name = 'redo size';
    NAME                                                                  VALUE
    redo size                                                         834714816
    SQL> select segment_name, bytes/1024/1024 "Size_MB" from dba_segments where segment_name = 'CDCLS~0'
    SEGMENT_NAME            Size_MB
    CDCLS~0                     800
    drop index / db restart here
    SQL> select a.name, b.value from v$statname a, v$mystat b where a.statistic# = b.statistic# and a.name = 'redo size';
    NAME                                                                  VALUE
    redo size                                                             28992
    SQL> CREATE UNIQUE INDEX "SAPR3"."CDCLS~0" ON "SAPR3"."CDCLS"
    ("MANDANT", "OBJECTCLAS", "OBJECTID", "CHANGENR", "PAGENO")
      PCTFREE 10 INITRANS 2 MAXTRANS 255
      STORAGE(INITIAL 65536 NEXT 65536 MINEXTENTS 1 MAXEXTENTS 2147483645
      PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
      TABLESPACE "PSAPCLUI" NOLOGGING; 
    Index created.
    Elapsed: 00:02:20.29
    SQL> select a.name, b.value from v$statname a, v$mystat b where a.statistic# = b.statistic# and a.name = 'redo size';
    NAME                                                                  VALUE
    redo size                                                           1520824
    SQL> select segment_name, bytes/1024/1024 "Size_MB" from dba_segments where segment_name = 'CDCLS~0';
    SEGMENT_NAME            Size_MB
    CDCLS~0                     800[/code]

  • 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

  • Should we use LOGGING or NOLOGGING for table, lob segment, and indexes?

    We have some DML performance issue on cf contention over the tables that also include LOB segments. In this case, should we define LOGGING on tables, lob segments, and/or INDEXES?
    Based on the metalink note < Performance Degradation as a Result of 'enq: CF - contention' [ID 1072417.1]> It looks we need to turn on logging for at least table and lob segment. What about the indexes?
    Thanks!

    >
    These tables that have nologging are likely from the application team. Yes, we need to turn on the logging from nologging for tables and lob segments. What about the indexes?
    >
    Indexes only get modified when the underlying table is modified. When you need recovery you don't want to do things that can interfere with Oracle's ability to perform its normal recovery. For indexes there will never be loss of data that can't be recovered by rebuilding the index.
    But use of NOLOGGING means that NO RECOVERY is possible. For production objects you should ALWAYS use LOGGING. And even for those use cases where use of NOLOGGING is appropriate for a table (loading a large amount of data into a staging table) the indexes are typically dropped (or at least disabled) before the load and then rebuilt afterward. When they are rebuilt NOLOGGING is used during the rebuild. Normal index operations will be logged anyway so for these 'offline' staging tables the setting for the indexes doesn't really matter. Still, as a rule of thumb you only use NOLOGGING during the specific load (for a table) or rebuild (for an index) and then you would ALTER the setting to LOGGING again.
    This is from Tom Kyte in his AskTom blog from over 10 years ago and it still applies today.
    http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:5280714813869
    >
    NO NO NO -- it does not make sense to leave objects in NOLOGGING mode in a production
    instance!!!! it should be used CAREFULLY, and only in close coordination with the guys
    responsible for doing backups -- every non-logged operation performed makes media
    recovery for that segment IMPOSSIBLE until you back it up.
    >
    Use of NOLOGGING is a special-case operation. It is mainly used in Datawarehouse (OLAP systems) data processing during truncate-and-load operations on staging tables. Those are background or even offline operations and the tables are NOT accessible by end users; they are work tables used to prepare the data that will be merged to the production tables.
    1. TRUNCATE a table
    2. load the table with data
    3. process the data in the table
    In those operations the table load is seldom backed up and rarely needs recovery. So use of NOLOGGING enhances the performance of the data load and the data can be recovered, if necessary, from the source it was loaded from to begin with.
    Use of NOLOGGING is rarely, if ever, used for OLTP systems since that data needs to be recovered.

  • 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

  • NOLOGGING but still generating lot of logs!

    I'm doing a bulk loading using 'sqlldr' with the DIRECT OPTION set to true. The table in question is set no NOLOGGING, yet, I'm getting a lot of redo (resulting in gigabytes of archived logs). The Force Logging option is set to FALSE.
    I really have no clue where is my problem, but I hope someone can shed some light and help me out.

    If you have any indexes on the table, this can result in redo generation. If you have not done so, you may want to use the 'skip_index_maintenance' parameter. This will mark any indexes as unusable. After the load has completed, you can rebuild the indexes in nolooging mode (alter index index_name rebuild nologging)

  • 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

  • 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.

Maybe you are looking for