LOB changes not wirtten in redo logs?

Hi there,
im just evaluating a one replikation software for syncronizing Oracle Databases. We use a 9.2 Database Standard Edition one.
I was told by a consultant, that LOB tables cannot be syncronized, because the changes are not written into the redologs. Is this true?
Thanks, Sven

Sven,
I belive there is no such restriction in Oracle.
consider the test case (Oracle 9.2.0.6 Ent.Edition, Windows 2003):
SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
Database altered.
SQL> create table test_lob(lob clob) ;
Table created.
SQL> alter system switch logfile;
System altered.
SQL> declare
2 l_lob CLOB ;
3 begin
4 insert into test_lob values (empty_clob()) returning lob into l_lob ;
5 dbms_lob.writeappend(l_lob, 4, 'test') ;
6 end ;
7 /
PL/SQL procedure successfully completed.
SQL> alter system switch logfile;
System altered.
SQL> EXECUTE DBMS_LOGMNR.ADD_LOGFILE( LOGFILENAME =>'j:\orant\archive_logs\Arc1_731.arc', OPTIONS => DBMS_LOGMNR.NEW);
PL/SQL procedure successfully completed.
SQL>
SQL> EXECUTE DBMS_LOGMNR.START_LOGMNR(OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG);
PL/SQL procedure successfully completed.
SQL> select scn, sql_redo from V$LOGMNR_CONTENTS;
returns
1101810606178,set transaction read write;
1101810606178,insert into "OBIDEM00"."TEST_LOB"("LOB") values (EMPTY_CLOB());
1101810606178,update "OBIDEM00"."TEST_LOB" set "LOB" = 'test' where "LOB" = EMPTY_CLOB() and ROWID = 'AAAV7JAABAAAacJAAA';
as you can see the LOB related statements are in the archived log, means they were written in redo log.
The question is how the LOB gets created in your case? If it is loaded through the direct-path load or you are using NOLOGGING option then it is possible that the LOB data would not appear in the redo log. In this case it is not the Oracle restriction, but the peculiarity of your application
Mike

Similar Messages

  • Recursive call with commit not written to redo log

    In my DBA training I was led to the belief that a commit caused the log writer to write the redo log buffer to the redo log file, but I find this is not true if the commit is inside recursive code.
    I believe this is intentional as a way off reducing i/o but it does raise data integrity problems.
    Apparently if you have some PL/SQL (can be sql*plus code or procedure) with a loop containing a commit,
    the commit does not actually ensure that the transaction is written to the Redo log.
    Instead Oracle only ensures all is written to the redo log when control is returned to the application/sqlplus.
    You can see this by checking the redo writes in v$sysstat.
    It will be less than the number of expected commits.
    Thus the old rule of expecting all committed transation to be there after a database recovery is not necessarily true.
    Does anyone know how to force the commit to ensure redo is written
    -inside pl/sql or perhaps a setting in the the calling environment ?
    Thanks

    Thanks for your input
    The trouble is that I believe if you stopped in a debugger the log writer would catch up -
    Or if you killed your instance in the middle of this test you wouldn't be sure how many commits the db thought it did
    ie. the db would recover to the last known commit in the redo logs
    - maybe I should turn on tracing ?
    Since my question I have a found a site that seems to back up the results I am getting
    http://www.ixora.com.au/notes/redo_write_triggers.htm
    see the note under point 3
    Have a look at the stats below and you will see
    redo writes 19026
    user commits 100057
    How I actually tested was to run
    the utlbstat scipt
    then run some pl/sql that
    - mimiced a business transactions (4 select lookup validations, 2 inserts and 1 insert or update and a commit)
    - loop * 100000
    then ran utlestat.sql
    i.e. test script
    @C:\oracle\ora92\rdbms\admin\utlbstat.sql
    connect test/test
    @c:\mig\Load_test.sql
    @C:\oracle\ora92\rdbms\admin\utlestat.sql
    Statistic Total Per Transact Per Logon Per Second
    CPU used by this session 37433 .37 935.83 79.31
    CPU used when call started 37434 .37 935.85 79.31
    CR blocks created 62 0 1.55 .13
    DBWR checkpoint buffers wri 37992 .38 949.8 80.49
    DBWR checkpoints 6 0 .15 .01
    DBWR transaction table writ 470 0 11.75 1
    DBWR undo block writes 22627 .23 565.68 47.94
    SQL*Net roundtrips to/from 4875 .05 121.88 10.33
    background checkpoints comp 5 0 .13 .01
    background checkpoints star 6 0 .15 .01
    background timeouts 547 .01 13.68 1.16
    branch node splits 4 0 .1 .01
    buffer is not pinned count 4217 .04 105.43 8.93
    buffer is pinned count 649 .01 16.23 1.38
    bytes received via SQL*Net 1027466 10.27 25686.65 2176.83
    bytes sent via SQL*Net to c 5237709 52.35 130942.73 11096.84
    calls to get snapshot scn: 1514482 15.14 37862.05 3208.65
    calls to kcmgas 303700 3.04 7592.5 643.43
    calls to kcmgcs 215 0 5.38 .46
    change write time 4419 .04 110.48 9.36
    cleanout - number of ktugct 1875 .02 46.88 3.97
    cluster key scan block gets 101 0 2.53 .21
    cluster key scans 49 0 1.23 .1
    commit cleanout failures: b 27 0 .68 .06
    commit cleanouts 1305175 13.04 32629.38 2765.2
    commit cleanouts successful 1305148 13.04 32628.7 2765.14
    commit txn count during cle 3718 .04 92.95 7.88
    consistent changes 752 .01 18.8 1.59
    consistent gets 1514852 15.14 37871.3 3209.43
    consistent gets - examinati 1005941 10.05 25148.53 2131.23
    data blocks consistent read 752 .01 18.8 1.59
    db block changes 3465329 34.63 86633.23 7341.8
    db block gets 3589136 35.87 89728.4 7604.1
    deferred (CURRENT) block cl 1068723 10.68 26718.08 2264.24
    enqueue releases 805858 8.05 20146.45 1707.33
    enqueue requests 805852 8.05 20146.3 1707.31
    execute count 1004701 10.04 25117.53 2128.6
    free buffer requested 36371 .36 909.28 77.06
    hot buffers moved to head o 3801 .04 95.03 8.05
    immediate (CURRENT) block c 3894 .04 97.35 8.25
    index fast full scans (full 448 0 11.2 .95
    index fetch by key 201128 2.01 5028.2 426.12
    index scans kdiixs1 501268 5.01 12531.7 1062.01
    leaf node splits 1750 .02 43.75 3.71
    logons cumulative 2 0 .05 0
    messages received 19465 .19 486.63 41.24
    messages sent 19465 .19 486.63 41.24
    no work - consistent read g 3420 .03 85.5 7.25
    opened cursors cumulative 201103 2.01 5027.58 426.07
    opened cursors current -3 0 -.08 -.01
    parse count (hard) 4 0 .1 .01
    parse count (total) 201103 2.01 5027.58 426.07
    parse time cpu 2069 .02 51.73 4.38
    parse time elapsed 2260 .02 56.5 4.79
    physical reads 6600 .07 165 13.98
    physical reads direct 75 0 1.88 .16
    physical writes 38067 .38 951.68 80.65
    physical writes direct 75 0 1.88 .16
    physical writes non checkpo 34966 .35 874.15 74.08
    prefetched blocks 2 0 .05 0
    process last non-idle time 1029203858 10286.18 25730096.45 2180516.65
    recursive calls 3703781 37.02 92594.53 7846.99
    recursive cpu usage 35210 .35 880.25 74.6
    redo blocks written 1112273 11.12 27806.83 2356.51
    redo buffer allocation retr 21 0 .53 .04
    redo entries 1843462 18.42 46086.55 3905.64
    redo log space requests 17 0 .43 .04
    redo log space wait time 313 0 7.83 .66
    redo size 546896692 5465.85 13672417.3 1158679.43
    redo synch time 677 .01 16.93 1.43
    redo synch writes 63 0 1.58 .13
    redo wastage 4630680 46.28 115767 9810.76
    redo write time 64354 .64 1608.85 136.34
    redo writer latching time 42 0 1.05 .09
    redo writes 19026 .19 475.65 40.31
    rollback changes - undo rec 10 0 .25 .02
    rollbacks only - consistent 122 0 3.05 .26
    rows fetched via callback 1040 .01 26 2.2
    session connect time 1029203858 10286.18 25730096.45 2180516.65
    session logical reads 5103988 51.01 127599.7 10813.53
    session pga memory -263960 -2.64 -6599 -559.24
    session pga memory max -788248 -7.88 -19706.2 -1670.02
    session uga memory -107904 -1.08 -2697.6 -228.61
    session uga memory max 153920 1.54 3848 326.1
    shared hash latch upgrades 501328 5.01 12533.2 1062.14
    sorts (memory) 1467 .01 36.68 3.11
    sorts (rows) 38796 .39 969.9 82.19
    switch current to new buffe 347 0 8.68 .74
    table fetch by rowid 1738 .02 43.45 3.68
    table scan blocks gotten 424 0 10.6 .9
    table scan rows gotten 4164 .04 104.1 8.82
    table scans (short tables) 451 0 11.28 .96
    transaction rollbacks 5 0 .13 .01
    user calls 5912 .06 147.8 12.53
    user commits 100057 1 2501.43 211.99
    user rollbacks 56 0 1.4 .12
    workarea executions - optim 1676 .02 41.9 3.55
    write clones created in bac 5 0 .13 .01
    write clones created in for 745 .01 18.63 1.58
    99 rows selected.

  • Field Changes not captured in processing log in service request

    Hi Experts,
    I have activated the processing log for service request in CRM, but I am only able to see the changes done to status,notes,attachments. As the field level changes are not shown in processing log in web ui, but the same is visible in the GUI in change log. Is there any specific setting which I need to do capture the field level changes? Please let me know on the same
    Thanks
    Abishek

    Hi Navin,
    Please navigate to the following SPRO path and update the customizing the field that you display in the processing log.
    SPRO->Customer Relationship Management-> Transactions -> Settings for Service Requests -> Settings for Processing Log -> Define Change History for Processing Log.
    Thank you,
    Regards,
    Mayoo

  • GoldenGate Extract Process will not read from redo log with manual help

    Here is my issue.
    I have GoldenGate replication successfully setup one-way from 1 Source to Many Targets. There is 1 source extract on the DB and many pumps that push the trail file data to the Targets. Replication does work but after manual help with starting up the Source Extract process.
    If I execute the command:
    GGSCI> alter extract <source extract name> begin now
    GGSCI> view report <source extract name>
    The extract starts and reads the source trail file but will not process data, I continually see in the ggserr.log file "OGG-01515: Positioning to begin time MMM DD, YYYY, HH:MM:SS" The date and time are irrevelant for this problem.
    When I see this, I SQ*Plus into the database and look in the v$log table for the current log and sequence #.
    I return to GGSCI and issue the following command:
    GGSCI> alter extract <source extract name> thread 1 extseqno <sequence # from v$log query>
    GGSCI> start <source extract name>
    It then works as expected. Why is this so? I thought the alter extract <source extract name> begin now would do the same output.
    We do use ASM but like I said when I issue the:
    GGSCI> alter extract <source extract name> thread 1 extseqno <sequence # from v$log query>
    It works like it should.
    Very weird.
    - Jason

    Yes, supplemental logging is enabled on both the source and the targets, but why would supplemental logging on the targets have any affect on why the Source Extract on the source can't read from the source redo log?
    This is not a RAC database, rather single-instance with one thread. Also, we are using DBLOGREADER functionality as it is an 11.2.0.3 database.
    My issue is simply, when I start the source extract from being down, meaning it isn't running, I issue this command:
    alter <source extract> begin now
    start <source extract>
    view report <source extract>
    OGG-01515 Positioning to begin time <today's date and time> ie Mar 4, 2013, 3:26:39 PM. (this is repeated over and over and over)
    If I perform a
    info <source extract> detail---> I see the following:
    Log Read Checkpoint Oracle Redo Logs 2013-03-04 15:26:39 Thread 1, Seqno 0, RBA 0 (why is it showing 0, becuase it can't read the redo, WHY NOT?)
    Extract Source BEGIN END
    Not Available <today's date> <today's date> (repeat....)
    However, if I retreive the Redo Log number and I issue:
    alter spe thread 1 extseqno (redo log sequence #)
    start spe.
    Then it works okay. I have to manually tell it what redo log to begin reading from. Why?
    - Jason
    Edited by: 924317 on Mar 4, 2013 9:03 AM

  • How to change redo log size in oracle 10g

    Hi Experts,
    Can anybody confirm how to change redo log size in oracle 10g?
    Amit

    Dear Amit,
    You can enlarge the size of existing Online Redo log files, by adding new groups with different size of files (origlog$/mirrlog$) and then carefully droping the old groups with  their associated inactive files.
    Please refer SAP Note 309526 - Enlarging redo log files to perform the activity.
    Steps to perform:
    STEP-1. Analyze the exisiting situation and prepare an action plan.
    A. You have to ensure that no more than one log switch per minute occurs during peak times.
    It may also be necessary to increase the size of the online redo logs until they are large enough.
    Too many log switches lead to too many checkpoints, which in turn lead to a high writing load in the I/O subsystem.
    Use ST04 -> Additional Functions --> Display GV$-Views
    There you can select
    Gv$LOG_HISTORY --->for determing your existing LOG switching frequency.
    GV$LOG -
    > list the status(INACTIVE/CURRENT/ACTIVE) /size/sequence no. of existing online redolog files
    GV$LOGFILE  --- > list the information of existing online  redolog files with their storage paths
    You can document the existing situation of Online Redo Log Fiile management before going to enlarge Redo Log Files.
    It will be helpful, if something goes wrong while performing activities.
    B. Based on above Situation analysis, Plan your New Redo Log Group and there Members with new optimal size.
    e.g.
    Group No.         Redo Log File Locations  u201C/oracle/<SID>/u201D                  Size
                                 /origlogA                  /mirrlogA            
    15                        log_g15m1.dbf         log_g15m2.dbf               100 MB
    17                        log_g17m1.dbf            log_g17m2.dbf               100 MB
                                /origlogB                    /mirrlogB
    16                       log_g16m1.dbf          log_g16m2.dbf            100 MB
    18                       log_g18m1.dbf            log_g18m2.dbf            100 MB
    Continue to next.....

  • Database in log archive mode and redo log file in mode not archive

    Hello,
    I have a dabatabase running in archive log mode, recently changed, I have 5 redo log groups and one of them (the current one) shows in the v$log view, that ARC: NO, I mean, no archiving. All redo logs except it shows ARC:Yes
    What does it mean?
    Am I going to have problems with this redo log file?
    Thanks

    If you do describe on v$log, you'll find that the full column name is Archived (meaning is it archived yet?).
    You could try alter system switch logfile and then check v$log again a few times after.
    Use the docu for finding out more about v$ views and so on
    http://www.oracle.com/pls/db102/print_hit_summary?search_string=v%24log

  • Moving the online redo log files to different location

    We just installed few more drives into our sandbox system and I want to move the online redo log files for better performance.  We've got the SAPARCH directory moved to a different location. 
    Does anyone know how/where I can change the parameters so redo log files are pointed at different drives?  It's not in the <b>init<SID>.ora</b> file...
    Regards,
    Sumit

    Hi Sumit,
    The following link contains information about moving the redo logs:
    http://www.stanford.edu/dept/itss/docs/oracle/9i/server.920/a96521/onlineredo.htm
    Best regards,
    Alwin

  • Logmnr/capure error b'coz of corruption of redo log block

    Hi,
    We all know that capture process reads the REDO entries from redo log files or archived log files. Therefore we need to ahev db in ARCHIVELOG mode.
    In alert log file, I found error saying :
    Creating archive destination LOG_ARCHIVE_DEST_1: 'E:\ORACLE\ORADATA\REPF\ARCHIVE\LOCATION01\1_36.ARC'
    ARC0: Log corruption near block 66922 change 0 time ?
    ARC0: All Archive destinations made inactive due to error 354
    Fri Apr 04 12:57:44 2003
    Errors in file e:\oracle\admin\repf\bdump\trishul_arc0_1724.trc:
    ORA-00354: corrupt redo log block header
    ORA-00353: log corruption near block 66922 change 0 time 04/04/2003 11:05:40
    ORA-00312: online log 2 thread 1: 'E:\ORACLE\ORADATA\REPF\ARCHIVE\REDO02.LOG'
    ORA-00312: online log 2 thread 1: 'E:\ORACLE\ORADATA\REPF\REDO02.LOG'
    As a normal practice, we do have multiplexing of redo log files at diff location, but even that second copy of redo log is of no use to recover the redo log. This explains redo log could not be archived, since it can't be read. Same is true even for Logmnr process, it could not read the redo log file and it failed. Now, we have wae to recover from this situation (as far as DB is concern, not Stream Replication), since the shutdown after this error was IMMEDIATE causing checkpoing, and rollback/rollforward is not required during system startup. (No instance recovery) We can make db NOARCHIVELOG mode, drop that particular group, and create new one, and turn db to ARCHIVELOG mode This will certainly serve the purpose as far as consistency of DB is concern.
    Here is a catch for Stream Replication. The redo log that got corrupted must be having few transaction which are not being archived, and each will be having corresponding SCN. Now, Capture Process read the info sequentially in order of SCN. Few transaction are now missed, and Capture process can't jump to next SCN skipping few SCN in between. So, we have to re-instantiate the objects on the another system which has no erros, and start working on it. My botheration is what will happen to those missed transaction on the another database. It's absolete loss of the data. In development I can manage that. But in real time Production stage, this is a critical situation. How to recover from this situation to get back the corrupted info from redo log ?
    I have not dropped any of the log group yet. B'coz I would like to recover from this situation without LOSS of data.
    Thanx, & regards,
    Kamlesh Chaudhary
    Content of trace files :
    Dump file e:\oracle\admin\repf\bdump\trishul_arc0_1724.trc
    Fri Apr 04 12:57:31 2003
    ORACLE V9.2.0.2.1 - Production vsnsta=0
    vsnsql=12 vsnxtr=3
    Windows 2000 Version 5.0 Service Pack 2, CPU type 586
    Oracle9i Enterprise Edition Release 9.2.0.2.1 - Production
    With the Partitioning, OLAP and Oracle Data Mining options
    JServer Release 9.2.0.2.0 - Production
    Windows 2000 Version 5.0 Service Pack 2, CPU type 586
    Instance name: trishul
    Redo thread mounted by this instance: 1
    Oracle process number: 16
    Windows thread id: 1724, image: ORACLE.EXE
    *** SESSION ID:(13.1) 2003-04-04 12:57:31.000
    - Created archivelog as 'E:\ORACLE\ORADATA\REPF\ARCHIVE\LOCATION02\1_36.ARC'
    - Created archivelog as 'E:\ORACLE\ORADATA\REPF\ARCHIVE\LOCATION01\1_36.ARC'
    *** 2003-04-04 12:57:44.000
    ARC0: All Archive destinations made inactive due to error 354
    *** 2003-04-04 12:57:44.000
    kcrrfail: dest:2 err:354 force:0
    *** 2003-04-04 12:57:44.000
    kcrrfail: dest:1 err:354 force:0
    ORA-00354: corrupt redo log block header
    ORA-00353: log corruption near block 66922 change 0 time 04/04/2003 11:05:40
    ORA-00312: online log 2 thread 1: 'E:\ORACLE\ORADATA\REPF\ARCHIVE\REDO02.LOG'
    ORA-00312: online log 2 thread 1: 'E:\ORACLE\ORADATA\REPF\REDO02.LOG'
    *** 2003-04-04 12:57:44.000
    ARC0: Archiving not possible: error count exceeded
    ORA-16038: log 2 sequence# 36 cannot be archived
    ORA-00354: corrupt redo log block header
    ORA-00312: online log 2 thread 1: 'E:\ORACLE\ORADATA\REPF\REDO02.LOG'
    ORA-00312: online log 2 thread 1: 'E:\ORACLE\ORADATA\REPF\ARCHIVE\REDO02.LOG'
    ORA-16014: log 2 sequence# 36 not archived, no available destinations
    ORA-00312: online log 2 thread 1: 'E:\ORACLE\ORADATA\REPF\REDO02.LOG'
    ORA-00312: online log 2 thread 1: 'E:\ORACLE\ORADATA\REPF\ARCHIVE\REDO02.LOG'
    ORA-16014: log 2 sequence# 36 not archived, no available destinations
    ORA-00312: online log 2 thread 1: 'E:\ORACLE\ORADATA\REPF\REDO02.LOG'
    ORA-00312: online log 2 thread 1: 'E:\ORACLE\ORADATA\REPF\ARCHIVE\REDO02.LOG'
    ORA-16014: log 2 sequence# 36 not archived, no available destinations
    ORA-00312: online log 2 thread 1: 'E:\ORACLE\ORADATA\REPF\REDO02.LOG'
    ORA-00312: online log 2 thread 1: 'E:\ORACLE\ORADATA\REPF\ARCHIVE\REDO02.LOG'
    ORA-16014: log 2 sequence# 36 not archived, no available destinations
    ORA-00312: online log 2 thread 1: 'E:\ORACLE\ORADATA\REPF\REDO02.LOG'
    ORA-00312: online log 2 thread 1: 'E:\ORACLE\ORADATA\REPF\ARCHIVE\REDO02.LOG'
    ORA-16014: log 2 sequence# 36 not archived, no available destinations
    ORA-00312: online log 2 thread 1: 'E:\ORACLE\ORADATA\REPF\REDO02.LOG'
    ORA-00312: online log 2 thread 1: 'E:\ORACLE\ORADATA\REPF\ARCHIVE\REDO02.LOG
    Dump file e:\oracle\admin\repf\udump\trishul_cp01_2048.trc
    Fri Apr 04 12:57:27 2003
    ORACLE V9.2.0.2.1 - Production vsnsta=0
    vsnsql=12 vsnxtr=3
    Windows 2000 Version 5.0 Service Pack 2, CPU type 586
    Oracle9i Enterprise Edition Release 9.2.0.2.1 - Production
    With the Partitioning, OLAP and Oracle Data Mining options
    JServer Release 9.2.0.2.0 - Production
    Windows 2000 Version 5.0 Service Pack 2, CPU type 586
    Instance name: trishul
    Redo thread mounted by this instance: 1
    Oracle process number: 30
    Windows thread id: 2048, image: ORACLE.EXE (CP01)
    *** 2003-04-04 12:57:28.000
    *** SESSION ID:(27.42) 2003-04-04 12:57:27.000
    TLCR process death detected. Shutting down TLCR
    error 1280 in STREAMS process
    ORA-01280: Fatal LogMiner Error.
    OPIRIP: Uncaught error 447. Error stack:
    ORA-00447: fatal error in background process
    ORA-01280: Fatal LogMiner Error
    **********************

    I have the similar problem - I am using Steams environment, and have got this
    "ORA-00353: log corruption near block" errors in the alert.log file
    during capture the changes on the primary database, and Capture
    process became aborted after that.
    Was that transactions lost, or after i've started the Capture process
    again the were captured and send to the target database?
    Have anyone solved that problem?
    Can you help me with it?

  • When is anything written to standby redo logs on standby database?

    I am on Oracle 10.2.0.4 on HP UNIX. I have read Oracle 10.2 concepts guide on technet.oracle.com, have read may article on metalink and internet, yet I am unable to verify when anything is written to standby redo logs on stand by database.
    I have a simple database reconfiguration: a primary database and one standby database.
    I created primary database and set up log_archive_dest_2 to use LGWR SYNC AFFIRM
    I have created standby redo logs on primary.
    alter database add standby logfile GROUP
    I create standby control file on primary.
    I copied all the primary information to create standby database. I have put standby database in managed recovery.
    I did archive log switches, I created a table and inserted information in table.
    I never saw standby redo logs updated on standby database by looking at timestamp of standby redo log files.
    I then setup database in maximum availability mode by running following on primary:
    Alter database set standby database to maximize availability
    When I do insert into my tables, I do see standby redo log files on primary database being updated, but I have never seen standby redo logs on standby database updated. Why?
    I am still at loss when actually standby redo logs are updated on standby database.
    When I read Oracle 9i database documentation on data guard, it says that you do not need standby redo logs on primary instead you need them on standby. Only reason, you need them on primary is from primary changes role to standby database, so standby redo logs on standby database should be updated instead of standby redo logs on primary.

    What is the PROTECTION_MODE ,PROTECTION_LEVEL values of your database.
    As per metalink:--
    Create standby redo log files, if necessary:
    Standby redo logs are necessary for the higher protection levels such as
    Guaranteed, Instant, and Rapid. In these protection modes LGWR from the
    Primary host writes transactions directly to the standby redo logs.
    This enables no data loss solutions and reduces the amount of data loss
    in the event of failure. Standby redo logs are not necessary if you are using
    the delayed protection mode.
    If you configure standby redo on the standby then you should also configure
    standby redo logs on the primary database. Even though the standby redo logs
    are not used when the database is running in the primary role, configuring
    the standby redo logs on the primary database is recommended in preparation
    for an eventual switchover operation.
    Standby redo logs must be archived before the data can be applied to the
    standby database. The standby archival operation occurs automatically, even if
    the standby database is not in ARCHIVELOG mode. However, the archiver process
    must be started on the standby database. Note that the use of the archiver
    process (ARCn) is a requirement for selection of a standby redo log.
    METALINK ID:- Doc ID: Note:219344.1
    Edited by: Anand... on Sep 15, 2008 2:15 AM

  • Whole Database Online + redo log backup: How Long?

    Hi gurus,
    There's something I want to ask about online backup with redo log.
    If i'm correct, redo log file is created everytime there's operation that change datafile right?
    If i schedule this type of backup everyday, it means it will backup all datafiles, along with redo log file when transaction take places, at my pre-defined hours, right?
    Then here's what i'm confused about. When will this backup process finished? Is it when all the datafiles have been backed up? Then how about the redo log files? If there are users that keep making transaction (therefore make change to datafiles), new redo log files will be created on disk, and that will prevent the backup process to finish. Then when will this cycle come to an end?
    Please confirm if my grasp about oracle online backup is correct or not, and provide explanation to satisfy my curiousity.
    Thanks gurus,
    Edited by: Bobby Gunawan on Jan 6, 2009 10:16 AM

    Hello Fidel,
    i am feeling honored
    > Keep in mind that the only thing where a DBA cannot make mistakes is restore/recovery and this depends on your backups
    In general i would say you are right, but i have seen already one case where this statement is not true. 
    Some time ago i got a call from a colleague where his database crashed, the online redolog files were corrupted and the recovery was not working.
    If you don't look really close at this point you are in trouble and can not continue the recovery. Let explain this on a example.
    This demonstration is done on an oracle 10.2.0.4, but it work on every other version too.
    Let's simulate a crash
    SQL> shutdown abort;
    Corrupt/delete a specifc redolog file
    SQL> startup
    ORA-00313: open failed for members of log group 3 of thread 1
    ORA-00312: online log 3 thread 1: '/oracle/TST/oradata/redolog/redo03.log'
    ORA-27037: unable to obtain file status
    Ok - so far so good, lets check the groups and files
    SQL> select GROUP#, STATUS, MEMBER from v$logfile where TYPE = 'ONLINE';
        GROUP# STATUS  MEMBER
             1         /oracle/TST/oradata/redolog/redo01.log
             2         /oracle/TST/oradata/redolog/redo02.log
             3         /oracle/TST/oradata/redolog/redo03.log
    SQL> select * from v$log;
        GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TIM
             1          1         95   52428800          1 NO  CURRENT                5117817 06-JAN-09
             3          1         94   52428800          1 YES ACTIVE                 5117814 06-JAN-09
             2          1         93   52428800          1 YES ACTIVE                 5112855 15-DEC-08
    What's the situation?
    The online redolog file of group 3 is lost/corrupted and this group is needed to perform a complete recovery (see status ACTIVE).
    But you are lucky, because of this group 3 is already archived - so you can perform a complete recovery.
    Now let's perform a complete recovery but with UNTIL clause (because we need to jump between the online and archived redologfiles)
    SQL> recover database until cancel;
    ORA-00279: change 5116194 generated at 01/06/2009 21:06:48 needed for thread 1
    ORA-00289: suggestion : /oracle/TST/oraarch/TST_1_93_6b8c0516_666969185.arc
    ORA-00280: change 5116194 for thread 1 is in sequence #93
    Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
    ORA-00279: change 5117814 generated at 01/06/2009 21:08:47 needed for thread 1
    ORA-00289: suggestion : /oracle/TST/oraarch/TST_1_94_6b8c0516_666969185.arc
    ORA-00280: change 5117814 for thread 1 is in sequence #94
    ORA-00278: log file '/oracle/TST/oraarch/TST_1_93_6b8c0516_666969185.arc' no longer needed for this recovery
    Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
    ORA-00279: change 5117817 generated at 01/06/2009 21:08:51 needed for thread 1
    ORA-00289: suggestion : /oracle/TST/oraarch/TST_1_95_6b8c0516_666969185.arc
    ORA-00280: change 5117817 for thread 1 is in sequence #95
    ORA-00278: log file '/oracle/TST/oraarch/TST_1_94_6b8c0516_666969185.arc' no longer needed for this recovery
    Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
    /oracle/TST/oradata/redolog/redo01.log
    Log applied.
    Media recovery complete.
    Now execute an OPEN NORESETLOGS accidentally (maybe the dba think it is not necessary because of the complete recovery) and try an OPEN RESETLOGS after:
    SQL> alter database open noresetlogs;
    alter database open noresetlogs
    ERROR at line 1:
    ORA-00313: open failed for members of log group 3 of thread 1
    ORA-00312: online log 3 thread 1: '/oracle/TST/oradata/redolog/redo03.log'
    ORA-27037: unable to obtain file status
    SQL> alter database open resetlogs;
    alter database open resetlogs
    ERROR at line 1:
    ORA-01139: RESETLOGS option only valid after an incomplete database recovery
    So now you are lost.. you can't execute an UNTIL CANCEL anymore which would be needed to perform a successful OPEN RESETLOGS.
    In this special case you can do mistakes and you have to restore the whole database and perform the same recovery again and end with OPEN RESETLOGS.
    Just for information
    Regards
    Stefan

  • Redo Log Switch 결과...

    환경 : 8.1.7.3.0 (no archive log 모드)
    log_checkpoint_timeout = 0
    log_checkpoint_interval = 999999999
    redo log size = 200M
    현재 check point는 log switch 상태에서만 가능하도록 설정된 것 같습니다.
    거래량이 적어서 그런지 log switch는 30시간 주기입니다.
    제가 실행한 것은 아래 4번째 로그가 current일때
    alter system checkpoint를 하고 조금 있다가..
    alter system switch logfile를 하여 1번째가 current가 된 상황입니다.
    3/16일 14시 까지도 계속 active상태입니다...
    1. 문제가 생긴건지요??? 도움부탁합니다...
    2. no archive log mode에서도 switch 주기를 줄이는 것이 복구에 도움이 되나요...?
    ===========================================
    STATUS , FIRST_CHANGE#,FIRST_TIME
    CURRENT , 8846777646687,2007-03-15 16:57:55
    INACTIVE, 8846777587798,2007-03-14 10:34:40
    INACTIVE, 8846777609448,2007-03-14 17:17:38
    ACTIVE , 8846777643690,2007-03-15 16:01:22

    no archivemode에서 정상복구를 바라는 것인지요?
    잘못된 정책이란 생각이 듭니다.
    no archive mode에서 v$log의 first_change# 중에 가장 작은 것
    이 v$recover_file의 change# 보다 크거나 같다면 복구불능입니다.
    배치작업이라도 있어서 log switch가 한번의 cycle을 돌게 되면 이전
    백업으로는 복구불능입니다. archive mode로 지금 바로 바꾸시지요..
    log_checkpoint_timeout은 checkpoint에 대한 timeout 시간값을
    지정하는 것입니다.
    LOG_CHECKPOINT_INTERVAL specifies the frequency of checkpoints in terms of the number of redo log file blocks that can exist between an incremental checkpoint and the last block written to the redo log. This number refers to physical operating system blocks, not database blocks.
    checkpoint는 아시는 바와 같이 데이터파일과
    리두로그 컨트롤파일의 SCN을 일치시키는 것입니다. 주요한 것은
    DBWR프로세스가 데이터파일에 write를 하겠구요.
    물론 checkpoint와 인스턴스 복구는 관련이 있습니다. checkpoint timeout을
    적당히주면 instance recovery에서 좀 더 빠르게 instance 복구후 DB가
    open되겠습니다. 만약 설정하신대로 하신다면 DB를 abort로
    내리고 open하게 되면
    instance recovery시에 더 많은 시간이 필요하겠습니다.
    게다가 트랜잭션으로 인한 log switch하는 시간이 30시간보다
    작다면 timeout을 준들 영향을 주지 않겠지요. redo log가 꽉
    차게 되면 log switch를 자동으로 하게 되는데 log switch를
    하기전에 checkpoint를 주게 되어 있으니까요.
    그런데 checkpoint와 물리적/논리적 복구와는 다른 개념입니다.
    checkpoint는 위에서 말씀드린 instance recovery와 관련이 있고
    물리적/논리적 복구에서는 archive file이 떨어져 있는가 current redo log가
    존재하는가에 따라서 복구가능여부를 결정되는 것이지요..
    그리고 ACTIVE 상태라는 것은 문서상의 정의에서는 archive mode일 경우
    archiving이 되는 중일 경우, 그리고 이 상태는 complete recovery시에 redo log
    적용시 필요한 정보가 있다는 것입니다.
    no archive mode에서 복구정책을 적용 하겠다는 것은 위험한 발상인 것 같습니다.
    물론 DSS시스템의 경우에는 이미 정책을 no archive mode로
    만들어두고 주말마다 offline backup을 하기도 합니다.
    하지만 DSS에서는 하루에 300번 이상의 log switch가 일어나는
    경우가 있을 정도이니 아무리 백업이 되어 있다 한들 완전복구는
    불능이겠지요. offline backup을 했을 때까지만 복구가 됩니다.
    $LOG
    This view contains log file information from the control files.
    Column Datatype Description
    GROUP#
    NUMBER
    Log group number
    THREAD#
    NUMBER
    Log thread number
    SEQUENCE#
    NUMBER
    Log sequence number
    BYTES
    NUMBER
    Size of the log (in bytes)
    MEMBERS
    NUMBER
    Number of members in the log group
    ARCHIVED
    VARCHAR2(3)
    Archive status (YES |NO)
    STATUS
    VARCHAR2(16)
    Log status:
    UNUSED - Online redo log has never been written to. This is the state of a redo log that was just added, or just after a RESETLOGS, when it is not the current redo log.
    CURRENT - Current redo log. This implies that the redo log is active. The redo log could be open or closed.
    ACTIVE - Log is active but is not the current log. It is needed for crash recovery. It may be in use for block recovery. It might or might not be archived.
    CLEARING - Log is being re-created as an empty log after an ALTER DATABASE CLEAR LOGFILE statement. After the log is cleared, the status changes to UNUSED.
    CLEARING_CURRENT - Current log is being cleared of a closed thread. The log can stay in this status if there is some failure in the switch such as an I/O error writing the new log header.
    INACTIVE - Log is no longer needed for instance recovery. It may be in use for media recovery. It might or might not be archived.
    no archive mode에서도 복구하는 여러가지 방법들이 있기는 합니다.
    예를들어 current redo log가 깨졌을 때에 recovery 방법이라던지
    등등이 문서에 있긴하지요. 하지만 no archivemode에서 백업을 붓고
    복구하는 방법은 찾아보기 힘드실 것입니다. 위에서도 말씀드렸듯이
    no archive mode에서
    v$recover_file의 CHANGE# > v$logl의 minimum FIRST_CHANGE# 이면 데이터파일은 복구가능합니다.
    그러나 CHANGE# <= minimum FIRST_CHANGE# 이면 복구 불가능합니
    다. 그러니 백업을 붓고 복구를 하는 방법에 대한 문서는 거의
    찾기 힘듭니다. advance 방법에 대한 문서에서만 adjust_scn을 쓴다던지 하는 등이 나와있을 뿐입니다.
    글 수정:
    민천사(민연홍)
    아무래도 졸면서 썼나봅니다.;;
    interval과 timeout은 엄연히 다른데요. 왜 timeout과 interval을
    혼동했는지..;;
    LOG_CHECKPOINT_INTERVAL specifies the frequency of checkpoints in terms of the number of redo log file blocks that can exist between an incremental checkpoint and the last block written to the redo log. This number refers to physical operating system blocks, not database blocks.
    LOG_CHECKPOINT_TIMEOUT specifies (in seconds) the amount of time that has passed since the incremental checkpoint at the position where the last write to the redo log (sometimes called the tail of the log) occurred. This parameter also signifies that no buffer will remain dirty (in the cache) for more than integer seconds.

  • Redo log contains select statement ??

    If i do a select command will that be stored in redolog file?
    If it gets storeed there then during recovery will that select statement will also run and use time in recovery?

    When either more then 1 MB of changes or 1/3 buffer
    if full or other reasons.
    Means uncommited data also get flush to online redo
    log file.
    But ssome persons says only commited sql command gets
    store in log buffer...
    Few other , including my oracle facluty says only
    commited changes are flush from redo log buffer to
    online redo log file.......
    Any one 100% Surety ......I know reading document is not your cup of tea, unfortunately it's most reliable source of information concerning Oracle.
    Oracle Concept mentioned
    Note:
    Sometimes, if more buffer space is needed, LGWR writes redo log entries before a transaction is committed. These entries become permanent only if the transaction is later committed.

  • Standby Redo Log Files ?

    Hi Everyone,
    Today after reading two different sources for Standby Protection Modes i found myself puzzled and stuck. One of the article from Burleson.com says 'Oracle supports the standby redo logs on a logical standby database and can now be configured in maximum data protection modes such as MAXIMUM PROTECTION ...'
    On the other hand on some of the blogs and other resources to read, i found it something opposite to what Burleson Consulting posted on their website.
    [http://4.bp.blogspot.com/-t0G_-xc8EAs/Tpvx9w2t8oI/AAAAAAAAAN4/Jw3U9s89Wtk/s1600/final.JPG|http://4.bp.blogspot.com/-t0G_-xc8EAs/Tpvx9w2t8oI/AAAAAAAAAN4/Jw3U9s89Wtk/s1600/final.JPG]
    or
    Blog from Jeff Hunter
    [http://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_3.shtml|http://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_3.shtml]
    Minimum Requirements for Data Protection Modes
         Maximum Protection      Maximum Availability      Maximum Performance
    Redo Archival Process      LGWR      LGWR      LGWR or ARCH
    Network Transmission Mode SYNC      SYNC      ASYNC when using LGWR process. Not applicable when using ARCH process.
    Disk Write Option      AFFIRM      AFFIRM      NOAFFIRM
    Standby Redo Logs Required?      Yes      Required for physical standby databases only (Standby redo logs are not supported for logical standby databases.)      Required for physical standby databases using the LGWR process.
    Database Type      Physical only      Physical and Logical      Physical and Logical
    Please help me to find true between the two.
    Or please provide any doc to read.
    Thanks
    Prashant Dixit

    Maximum Protection Maximum Availability Maximum PerformanceDepends on Business requirement, By default Performance[most of the clients]
    Redo Archival Process ? ? ?LGWR recommended in Max performance
    Network Transmission Mode ? ? ?Depends. If max performance asynchronous
    Disk Write Option ? ? ?Not clear
    Standby Redo Logs Required? ? ? ?If real time apply - YES
    Database Type ? ? ?not clear,
    Assuming physical or logical? --Depends on requirement , Preferably Physical.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           

  • Increase current redo log size in standby database in mount stage

    We have oracle 10g standby database. The standby database is always running in mount stage while apply logs manually not data guard is used.
    We have increase size or online redo log in primary . Now want to inrease in standby database also.
    how to increase the size of current online redo log in standby database while it in mount stage .
    in mount stage we cant run alter system switch logfile

    user11965804 wrote:
    We have oracle 10g standby database. The standby database is always running in mount stage while apply logs manually not data guard is used.
    We have increase size or online redo log in primary . Now want to inrease in standby database also.
    how to increase the size of current online redo log in standby database while it in mount stage .
    in mount stage we cant run alter system switch logfilein 10g Standby will be always in Mount status when MRP is running.
    When you increase size of online redo log files in primary, You should increase in standby also..
    Standby redo log file size should be equal or higher than primary. You no need to switch log files on Standby.
    You will have only standby redo log files in standby not ORL(online redo log files)
    You can use this below script to add standby redo log files.
    http://www.pythian.com/news/581/oracle-standby-redo-logs/

  • Online redo log switching

    Hello.
    I have a question about online redo logs.
    Assume that I have two small redo log groups in my database. I am processing a big batch load consisting of many inserts, but no checkpoing. The first redo log group gets full, it's switched to the second one. The second one gets full too and it need to be switched to the first. No commit until this time, so (I guess) the data has not been saved to datafiles.
    Is that possible? Will the database hung ?
    If not the first redo log group gets overwritten, doesn't it? What if, after the commit, the database crashes. I will not be able to restore the operations from the first redo group...?

    Depends,
    If you are running in archive log mode then when you fill the first redo log group it is copied to the archvielog destination, then when the second is filled its copied and we switch back to the first if the archiver hasn't completed you will get a short 'hang' whillst the archiver completes then the transaction will proceed.
    if in no archivelog mode you will just switch back and forth between the two log files.
    You may be confused because you think that the datablocks in the buffer cache and datafiles are not updated untill the transaction is completed this is not true, the assumption is that most transactions will be completed and commited for a usefull discussion of the concepts see.
    Re: basic concepts

Maybe you are looking for