Redo entry

Hi Experts,
please tell me when any DDL OR DML command fire in Oracle than this command recoded in Redo log file with time stamp.
please tell me sir what other entry are with Redo entry and can we read it.Oracle How to manage Redo entry???
Regards,
Harshit OCP

928992 wrote:
Hi Experts,
please tell me when any DDL OR DML command fire in Oracle than this command recoded in Redo log file with time stamp.
please tell me sir what other entry are with Redo entry and can we read it.Oracle How to manage Redo entry???
Regards,
Harshit OCPYou are an OCP, you tell us that whether it should go or not ? Better question, in Oracle, how's the time is mapped internally ?
Aman....

Similar Messages

  • How Can I know what is causing a lot of Redo entries ?

    Hi
    My production database began yesterday to generate a lot of archives and I want to know what transactions are causing a lot of Redo entries ?
    I guess it can be a process repeating something a lot times ( insert, deletes, updates, etc... )
    Thanks for helping me

    user2931261 wrote:
    Hi
    My production database began yesterday to generate a lot of archives and I want to know what transactions are causing a lot of Redo entries ?
    I guess it can be a process repeating something a lot times ( insert, deletes, updates, etc... )
    Thanks for helping meDBMS_LOGMNR will reveal DML that produces the REDO

  • Info on "Redo Entries" and "dirty buffers"

    Hi all,
    as per my knowledge, dirty buffers will have changed information and the information related to changed data will be stored in redo entries and these redo entries will be stored in archivelog if archivelog is enabled .
    my question is, what is the use of Redo entries and only the information related to changed data (redo entries) will be storing in archivelog files. during recovery of db how the actual data will be stored from archivelog(bcoz it will have information related to changed data ,not the actual data).
    what is the difference between redo entries and online redologs ?
    please help me ,above things were asked by interviewer.
    Thanks and Regards,
    Mahesh M
    Edited by: Mahesh M on 18 Jul, 2012 12:29 PM

    I would really suggest that you do read the Concepts guide from oracle docs of 11.2 release. That would cleat out a lot of stuff for you.
    Mahesh M wrote:
    Hi all,
    as per my knowledge, dirty buffers will have changed information and the information related to changed data will be stored in redo entries and these redo entries will be stored in archivelog if archivelog is enabled .
    my question is, what is the use of Redo entries and only the information related to changed data (redo entries) will be storing in archivelog files. during recovery of db how the actual data will be stored from archivelog(bcoz it will have information related to changed data ,not the actual data).
    what is the difference between redo entries and online redologs ?Redo entries are actually called change vectors which are generated for your changes in the log buffer and from there are written to the the redo log files. Dirty buffers are within the buffer cache.
    Aman....

  • Redo entry generation for select query

    Does "SELECT" query generate redo entry?
    If yes, Why?

    A SELECT may generate redo for "delayed block cleanout" and "delayed logging block cleanout" when it is querying blocks that were recently updated by a transaction that did not execute a "commit cleanout" completely.
    See http://jonathanlewis.wordpress.com/2009/06/16/clean-it-up/
    Hemant K Chitale

  • Redo Entries

    Hi,
    Oracle9i Database Concepts says
    Redo entries are copied by Oracle server processes from the user's memory space to the redo log buffer in the SGA.
    The term "user's memory" means what memory?
    Regards,
    Sen

    The redo logs record all actions performed against the database. They do not record whether or not the actions were committed. This is what the rollback segments are for. Since the rollback segment is a database object, it is subject to the same risks of damage as any other object. This is why changes to the RBS are immediately recorded in the redo log. When the database is recovered, all transactions from the redo logs are applied, including those affecting the rollback segments. The data in the (newly restored) rollback segments then enables Oracle to "roll back" any transactions that are marked as uncommitted. This is why they are called rollback segments.

  • Redo log entries

    what do you mean by change vectors? what exactly do they contain?

    Thank you for your replay.
    checked out the link suggested and found the following content.
    Online Redo Log Contents
    Online redo log files are filled with redo records. A redo record, also called a redo entry, is made up of a group of change vectors, each of which is a description of a change made to a single block in the database. For example, if you change a salary value in an employee table, you generate a redo record containing change vectors that describe changes to the data segment block for the table, the rollback segment data block, and the transaction table of the rollback segments.
    Redo entries record data that you can use to reconstruct all changes made to the database, including the rollback segments.
    but still i am not clear with this concept
    does it contain address of blocks in data & undo segments or the unit by which the data is changing?

  • Photos in text of blog entry do not port to main blog page

    I have posted before about the photos from my entry page disappearing when ported to my main blog page. I have yet to find a solution so I'm asking for help again.
    I'm am trapped using iWeb 1.1 until I find a solution. I use the Modern Template with modifications. Usually I delete the snowboarding surfer placeholder. Please note I'm not concerned that this photo doesn't port. I don't want it to. I do however need the photos that I have embedded via text wrap within my blog entry to port to the main blog page. They do not.
    I have tried keeping the snowboarder place holder and redoing entries with wrapped text, but my additional photos are still missing. I have checked the box in iWeb 2 that says show photos. My layouts conveted to iWeb 2 look perfect on the entry's page, and horrible with missing photos on the summary page.
    This problem is beyond frustrating. My blog can be seen here, however it is still the iWeb 1.1 format.
    http://web.mac.com/knittsings/iWeb/knittsings/knittsings/knittsings.html
    As you can see, almost all my entries have numerous photos. I want them to display on the main blog page.
    Am I missing something very basic? I have seen others with this same question but no one seems to have had any luck resolving this problem.
    Thanks,
    Kathryn

    And that's the way it should be.
    If you look at this page about navigation you'll see that the main navigation uses eternal links and the sub navigation internal ones....
    http://www.iwebformusicians.com/WebMusic/Navigation.html
    Try the troubleshooting steps under "Fix iWeb" here.....
    http://www.iwebformusicians.com/WebMusic/iWebTips.html

  • Tuning of Redo logs in data warehouses (dwh)

    Hi everybody,
    I'm looking for some guidance to configure redo logs in data warehouse environments.
    Of course we are running in noarchive log mode and use direct path inserts (nologging) whereever possible.
    Nevertheless every etl process (one process per day) produces 150 GB of redo logs. That seems quite a lot compared to the overall data volume (1 TB tables + indexes).
    Actually im not sure if there is a tuning problem, but because of the large amount of redo I'm interested in examining it.
    Here are the facts:
    - Oracle 10g, 32 GB RAM
    - 6 GB SGA, 20 GB PGA
    - 5 log groups each with 1 Gb log file
    - 4 MB Log buffer
    - every day ca 150 logswitches (with peaks: some logswitches after 10 seconds)
    - some sysstat metrics after one etl load:
    Select name, to_char(value, '9G999G999G999G999G999G999') from v$sysstat Where name like 'redo %';
    "NAME" "TO_CHAR(VALUE,'9G999G999G999G999G999G999')"
    "redo synch writes" " 300.636"
    "redo synch time" " 61.421"
    "redo blocks read for recovery"" 0"
    "redo entries" " 327.090.445"
    "redo size" " 159.588.263.420"
    "redo buffer allocation retries"" 95.901"
    "redo wastage" " 212.996.316"
    "redo writer latching time" " 1.101"
    "redo writes" " 807.594"
    "redo blocks written" " 321.102.116"
    "redo write time" " 183.010"
    "redo log space requests" " 10.903"
    "redo log space wait time" " 28.501"
    "redo log switch interrupts" " 0"
    "redo ordering marks" " 2.253.328"
    "redo subscn max counts" " 4.685.754"
    So the questions:
    Does anybody can see tuning needs? Should the Redo logs be increased or incremented? What about placing redo logs on Solid state disks?
    kind regards,
    Mirko

    user5341252 wrote:
    I'm looking for some guidance to configure redo logs in data warehouse environments.
    Of course we are running in noarchive log mode and use direct path inserts (nologging) whereever possible.Why "of course" ? What's your recovery strategy if you wreck the database ?
    Nevertheless every etl process (one process per day) produces 150 GB of redo logs. That seems quite a lot compared to the overall data volume (1 TB tables + indexes).This may be an indication that you need to do something to reduce index maintenance during data loading
    >
    Actually im not sure if there is a tuning problem, but because of the large amount of redo I'm interested in examining it.
    For a quick check you might be better off running statspack (or AWR) snapshots across the start and end of batch to get an idea of what work goes on and where the most time goes. A better strategy would be to examine specific jobs in detail, though).
    "redo synch time" " 61.421"
    "redo log space wait time" " 28.501" Rough guideline - if the redo is slowing you down, then you've lost less than 15 minutes across the board to the log writer. Given the number of processes loading and the elapsed time to load, is this significant ?
    "redo buffer allocation retries"" 95.901" This figure tells us how OFTEN we couldn't get space in the log buffer - but not how much time we lost as a result. We also need to see your 'log buffer space' wait time.
    Does anybody can see tuning needs? Should the Redo logs be increased or incremented? What about placing redo logs on Solid state disks?Based on the information you've given so far, I don't think anyone should be giving you concrete recommendations on what to do; only suggestions on where to look or what to tell us.
    Regards
    Jonathan Lewis

  • Filled redo log files are available to LGWR for reuse

    Hi,
    Oracle version:
    Oracle Database 10g Release 10.2.0.4.0 -
    OS:Windows XP
    In oracle documentation it is mentioned that:
    Filled redo log files are available to LGWR for reuse depending on whether archiving is enabled.
    *> If archiving is disabled (the database is in NOARCHIVELOG mode), a filled redo log file is available after the changes recorded in it have been written to the datafiles*.
    Link for Documentation is:
    http://docs.oracle.com/cd/B28359_01/server.111/b28310/onlineredo001.htm
    My doubt is:
    Redo Records are written to datafiles also??

    user12141893 wrote:
    Does it mean:
    Suppose:
    Online redo log files contains some redo entries and database buffer cache contains some data and this data belong to redo entries of redo log files.
    Now this redo log file can't be reused until those (related) blocks of database buffer cache are written into datafiles.
    This is sort of correct. If the log file would be filled up , LGWR would switch over to the next log group and would initiate a Log Switch which would further trigger DBWR to start checkpointing the content protected by this log group to the data file. By the time this operation would be going on, the Log group's members would have the status of Active and once it would be complete, the status would be marked to Inactive which means that this log group and its members can be reused by LGWR.
    HTH
    Aman....

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

  • Audit dml vs noaudit dml - session stat huge difference in redo size DB 9.2

    Hi,
    I've just finished test ,where compared audit update table, delete table, insert table by user by access with noaudit dml statements.
    DB version is 9.2.0.8 , same test run twice on same configuration and data so its comparable .
    What concerns me the most is difference in redo size ,and redo entries , here goes table with results:
    noaudit            audit              statname
    486 439,00     878 484,00     calls to kcmgas
    40 005,00     137 913,00     calls to kcmgcs
    2 917 090,00     5 386 386,00     db block changes
    4 136 305,00     6 709 616,00     db block gets
    116 489,00     285 025,00     deferred (CURRENT) block cleanout applications
    1,00     3 729,00     leaf node splits
    361 723 368,00     773 737 980,00     redo size
    4 235,00     50 752,00     active txn count during cleanoutCould You explain that differences in statistics, especially in redo size.
    I'm suprissed because in 9.2 DB audit dml doesnt log actual sql statements, only indication of usage .
    Regards.
    Greg

    Hi,
    I've just finished test ,where compared audit update table, delete table, insert table by user by access with noaudit dml statements.
    DB version is 9.2.0.8 , same test run twice on same configuration and data so its comparable .
    What concerns me the most is difference in redo size ,and redo entries , here goes table with results:
    noaudit            audit              statname
    486 439,00     878 484,00     calls to kcmgas
    40 005,00     137 913,00     calls to kcmgcs
    2 917 090,00     5 386 386,00     db block changes
    4 136 305,00     6 709 616,00     db block gets
    116 489,00     285 025,00     deferred (CURRENT) block cleanout applications
    1,00     3 729,00     leaf node splits
    361 723 368,00     773 737 980,00     redo size
    4 235,00     50 752,00     active txn count during cleanoutCould You explain that differences in statistics, especially in redo size.
    I'm suprissed because in 9.2 DB audit dml doesnt log actual sql statements, only indication of usage .
    Regards.
    Greg

  • Select query generating redo

    Hi
    I am trying to run a select query in a database which has performance problems and I get the following stats
    recursive calls     47
    db block gets     0
    consistent gets     36909
    physical reads     203
    redo size     205164
    bytes sent via SQL*Net to client     1873
    bytes received via SQL*Net from client     1716
    SQL*Net roundtrips to/from client     4
    sorts (memory)     2
    sorts (disk)     0
    I get a lot of consistent gets and redo size compare to the same query run on a good performing db(results below). Why should a select query generate a lot of redo? Can some one suggest me where should I be looking at to resolve this issue?
    Thanks
    recursive calls     47
    db block gets     0
    consistent gets     3470
    physical reads     0
    redo size     0
    bytes sent via SQL*Net to client     1885
    bytes received via SQL*Net from client     1725
    SQL*Net roundtrips to/from client     5
    sorts (memory)     2
    sorts (disk)     0
    Edited by: APV on Nov 18, 2008 1:08 PM

    Queries can also generate redo if auditing is enabled. If you don't have auditing enabled and you find that a SELECT statement with no FOR UPDATE clause sometimes generates redo entries, you might be witnessing a case of delayed block cleanout

  • REDO ALLOCATION LATCH와 REDO COPY LATCH에 대해서

    제품 : ORACLE SERVER
    작성날짜 : 2000-08-28
    REDO ALLOCATION LATCH와 REDO COPY LATCH에 대해서
    ========================================================================
    redo log buffer 사용 시 wait 비율이 높은 경우 log buffer의 크기 조정 외에도
    redo에 관한 latch를 조정함으로써 성능을 향상시킬 수 있다.
    여기에서는 redo allocation latch와 redo copy latch의 작동 원리와, tuning
    방법 등을 설명한다. 그리고 8i에서의 변경 사항도 포함하였다.
    1. redo entry를 redo log buffer에 할당하는 방법
    database에 변경 작업을 수행하는 server process는 PGA 부분에 변경 작업에 대한
    redo entry를 만든다. 그리고 이것을 redo log buffer에 옮기는데, 이 때 먼저
    할당될 redo log buffer의 부분을 allocation하고, 그 이후에 allocation 된
    redo log buffer 공간에, PGA 상에 만들어 둔 redo entry를 copy한다.
    Oracle은 SGA 내에서 발생하는 source code의 action의 serialization을 위해서
    latch를 사용한다. 즉, log buffer에서 redo entry를 save시킬 공간을 할당하는
    작업 절차도 먼저 latch를 부여받은 process가 작업하는 것이고, 할당받은
    공간에 redo entry를 copy시키는 작업 절차도 latch를 획득한 다음에만 수행
    가능하다.
    2. redo allocation latch
    모든 redo entry는 db에 수행된 작업 순서대로 redo log file에 기록되어야 한다.
    그러므로 redo log buffer에 redo entry를 할당하는 작업은 항상 serialization을
    유지하여야 하고, 그런 이유로 인해서 redo allocation latch는 instance마다
    하나만이 가능하다.
    server process는 이 redo allocation latch를 잡고, redo buffer 내에 redo
    entry를 저장시킬 위치를 확보한다.
    다음에 설명할 redo copy latch를 사용할 수 없는 환경에서는, redo buffer 내의
    확보한 공간 내에 redo entry를 copy하는 작업도 이 redo allocation latch를
    잡은 후 진행한다.
    3. redo copy latch (LOG_SIMULTANEOUS_COPIES)
    redo allocation latch 하나를 이용하여 redo buffer 내의 공간을 할당하고,
    redo entry를 copy하는 것은, redo buffer에 대한 작업을 모두 serialize시켜
    performance에 지장을 줄 수 있다.
    redo entry가 위치할 공간을 확보하는 작업은 반드시 시간 순서대로 위치해야
    하기 때문에 모두 순서가 유지되어야 하는 작업이지만, 일단 확보한 log
    buffer의 공간에 redo entry를 copy하는 작업은 동시에 수행되어도 지장이
    없다. 이것을 위해 복수 개의 redo copy latch를 지정하여, redo entry를 확보된
    영역에 동시에 copy가 가능하도록 하였다. 단 이러한 copy 작업은 CPU의
    작업이므로 CPU가 한장이면, 동시 작업이 불가능하여 이 redo copy latch를
    사용하는 것이 의미가 없어 사용이 불가능하다.
    즉, redo buffer에 대한 작업이 redo copy latch를 사용하면, 다음과 같은
    절차로 수행된다.
    (1) A server process가 redo allocation latch를 잡고 redo buffer 내의 공간을
    할당한 후 redo allocation latch는 푼다.
    (2) B server process가 redo allocation latch를 잡고 redo buffer의 새로운
    공간을 할당받은 다음 redo allocation latch를 푼다.
    (3) A process가 redo copy latch를 잡고 A process가 만든 PGA 내의 redo
    entry를 (1)번 단계에서 확보한 공간에 copy한다.
    이와 동시에 B process도 또 다른 redo copy latch를 잡고, (2)번 단계에서
    확보한 공간에 redo entry를 copy한다.
    redo copy latch의 갯수는 log_simultaneous_copies parameter에 의해 지정된다.
    CPU가 하나이면 이 값은 0가 되어, redo allocation latch를 이용해 redo
    allocation과 redo copy 작업을 한번에 수행하게 되며, default는 CPU_COUNT 값이
    된다. CPU_COUNT는 operating system layer에 의해 자동으로 결정되며, init.ora
    file에 명시적으로 지정하지 않는 parameter이다.
    즉, multi CPU 환경에서는 자동으로 redo copy latch를 사용하게 되는 것이다.
    default 외의 값을 사용하고자 한다면, $ORACLE_HOME/dbs/initSID.ora file 내에
    다음과 같이 지정하면 된다. 최대값의 제한은 없다.
    log_simultaneous_copies=n
    redo copy latch의 장점을 정리하면, redo buffer의 공간 할당을 위해 선행된
    작업이 redo entry를 copy할 때까지 기다리지 않아도 되며, redo copy 작업 자체도
    병렬도 수행이 가능하다는 것이다.
    4. LOG_SMALL_ENTRY_MAX_SIZE
    CPU를 복수개를 사용하는 경우 redo copy latch를 사용하는 것이 redo log buffer
    내의 작업에 대한 wait는 줄일 수 있음은 위에서 살펴보았다. 그런데 매우 작은
    redo entry의 경우 redo entry를 copy하는 데 시간이 거의 걸리지 않은 상황에서
    굳이 redo allocation과 redo copy를 별도의 latch를 이용하여 두 단계로 나누어
    작업하는 것이 성능 향상에 도움이 되지 않을 수도 있다. 오히려 copy하는 데 시간이
    거의 안 걸린다면 redo allocation latch 하나를 잡고서 redo allocation과 redo
    copy를 모두 수행하는 것이 나을 수도 있다.
    그렇다면 redo copy latch를 사용하는 상황에서 이 latch를 사용하지 않아도 되는,
    작은 redo entry의 기준을 설정할 필요가 있다.
    이것을 결정하는 parameter가 log_small_entry_max_size이다.
    즉, log_small_entry_max_size보다 큰 redo entry는 redo copy를 위해 redo copy
    latch를 사용하지만, 이보다 작은 크기의 redo entry에 대해서는 redo allocation
    latch를 이용하여 redo allocation과 copy를 모두 수행하게 되는 것이다.
    아무리 작은 redo entry라도 redo copy latch를 사용하게 하고 싶다면 이 값을
    0으로 지정하면 된다.
    5. tuning point
    multi-CPU 환경에서 redo copy latch의 갯수를 늘리거나, log_small_entry_max_size
    값을 줄여야 할때는 redo buffer에 contention이 발생하는 경우이다.
    redo buffer에 contention이 발생하는지 확인하는 방법은 다음과 같다.
    SQL>select name, gets, misses from v$latch where name = 'redo allocation';
    이 값의 결과에서 gets에 대한 misses의 비율이 1%를 넘는다면 이것은 contention
    이 존재한다고 판단될 수 있다. 물론 이것은 절대적인 기준은 아니어서, 1% 미만
    이라 하더라도 miss 율을 더 줄이고자 할 수도 있다.
    contention이 발생하면 log_simultaneous_copies의 값을 CPU의 약 두배 정도까지
    증가시키는 것이 권고할 만하고, log_small_entry_max_size의 값도 0에 가까운
    값으로 줄여서 contention의 상황을 지속적으로 살펴보아야 한다.
    6. 8i 에서의 변경 사항
    Oracle 8.1 에서는 위에서 설명한 두 parameter가 모두 나타나지 않는다.
    log_small_entry_max_size parameter는 완전히 없어졌으며,
    log_simultaneous_copies 값은 CPU_COUNT의 두배로 무조건 설정이 된다.
    이 CPU_COUNT는 앞에서 설명한 것과 같이 operating system layer에 의해
    자동으로 결정되는 parameter로 CPU의 갯수를 나타낸다.
    log_simultaneous_copies가 자동으로 CPU 갯수의 2배로 지정되는 것은 모든
    환경에서 대부분 최적이라고 볼 수 있으므로, user가 변경하지 않도록 하기 위해
    parameter 부분에 display가 안 되도록 하였다.

    제품 : ORACLE SERVER
    작성날짜 : 2000-08-28
    REDO ALLOCATION LATCH와 REDO COPY LATCH에 대해서
    ========================================================================
    redo log buffer 사용 시 wait 비율이 높은 경우 log buffer의 크기 조정 외에도
    redo에 관한 latch를 조정함으로써 성능을 향상시킬 수 있다.
    여기에서는 redo allocation latch와 redo copy latch의 작동 원리와, tuning
    방법 등을 설명한다. 그리고 8i에서의 변경 사항도 포함하였다.
    1. redo entry를 redo log buffer에 할당하는 방법
    database에 변경 작업을 수행하는 server process는 PGA 부분에 변경 작업에 대한
    redo entry를 만든다. 그리고 이것을 redo log buffer에 옮기는데, 이 때 먼저
    할당될 redo log buffer의 부분을 allocation하고, 그 이후에 allocation 된
    redo log buffer 공간에, PGA 상에 만들어 둔 redo entry를 copy한다.
    Oracle은 SGA 내에서 발생하는 source code의 action의 serialization을 위해서
    latch를 사용한다. 즉, log buffer에서 redo entry를 save시킬 공간을 할당하는
    작업 절차도 먼저 latch를 부여받은 process가 작업하는 것이고, 할당받은
    공간에 redo entry를 copy시키는 작업 절차도 latch를 획득한 다음에만 수행
    가능하다.
    2. redo allocation latch
    모든 redo entry는 db에 수행된 작업 순서대로 redo log file에 기록되어야 한다.
    그러므로 redo log buffer에 redo entry를 할당하는 작업은 항상 serialization을
    유지하여야 하고, 그런 이유로 인해서 redo allocation latch는 instance마다
    하나만이 가능하다.
    server process는 이 redo allocation latch를 잡고, redo buffer 내에 redo
    entry를 저장시킬 위치를 확보한다.
    다음에 설명할 redo copy latch를 사용할 수 없는 환경에서는, redo buffer 내의
    확보한 공간 내에 redo entry를 copy하는 작업도 이 redo allocation latch를
    잡은 후 진행한다.
    3. redo copy latch (LOG_SIMULTANEOUS_COPIES)
    redo allocation latch 하나를 이용하여 redo buffer 내의 공간을 할당하고,
    redo entry를 copy하는 것은, redo buffer에 대한 작업을 모두 serialize시켜
    performance에 지장을 줄 수 있다.
    redo entry가 위치할 공간을 확보하는 작업은 반드시 시간 순서대로 위치해야
    하기 때문에 모두 순서가 유지되어야 하는 작업이지만, 일단 확보한 log
    buffer의 공간에 redo entry를 copy하는 작업은 동시에 수행되어도 지장이
    없다. 이것을 위해 복수 개의 redo copy latch를 지정하여, redo entry를 확보된
    영역에 동시에 copy가 가능하도록 하였다. 단 이러한 copy 작업은 CPU의
    작업이므로 CPU가 한장이면, 동시 작업이 불가능하여 이 redo copy latch를
    사용하는 것이 의미가 없어 사용이 불가능하다.
    즉, redo buffer에 대한 작업이 redo copy latch를 사용하면, 다음과 같은
    절차로 수행된다.
    (1) A server process가 redo allocation latch를 잡고 redo buffer 내의 공간을
    할당한 후 redo allocation latch는 푼다.
    (2) B server process가 redo allocation latch를 잡고 redo buffer의 새로운
    공간을 할당받은 다음 redo allocation latch를 푼다.
    (3) A process가 redo copy latch를 잡고 A process가 만든 PGA 내의 redo
    entry를 (1)번 단계에서 확보한 공간에 copy한다.
    이와 동시에 B process도 또 다른 redo copy latch를 잡고, (2)번 단계에서
    확보한 공간에 redo entry를 copy한다.
    redo copy latch의 갯수는 log_simultaneous_copies parameter에 의해 지정된다.
    CPU가 하나이면 이 값은 0가 되어, redo allocation latch를 이용해 redo
    allocation과 redo copy 작업을 한번에 수행하게 되며, default는 CPU_COUNT 값이
    된다. CPU_COUNT는 operating system layer에 의해 자동으로 결정되며, init.ora
    file에 명시적으로 지정하지 않는 parameter이다.
    즉, multi CPU 환경에서는 자동으로 redo copy latch를 사용하게 되는 것이다.
    default 외의 값을 사용하고자 한다면, $ORACLE_HOME/dbs/initSID.ora file 내에
    다음과 같이 지정하면 된다. 최대값의 제한은 없다.
    log_simultaneous_copies=n
    redo copy latch의 장점을 정리하면, redo buffer의 공간 할당을 위해 선행된
    작업이 redo entry를 copy할 때까지 기다리지 않아도 되며, redo copy 작업 자체도
    병렬도 수행이 가능하다는 것이다.
    4. LOG_SMALL_ENTRY_MAX_SIZE
    CPU를 복수개를 사용하는 경우 redo copy latch를 사용하는 것이 redo log buffer
    내의 작업에 대한 wait는 줄일 수 있음은 위에서 살펴보았다. 그런데 매우 작은
    redo entry의 경우 redo entry를 copy하는 데 시간이 거의 걸리지 않은 상황에서
    굳이 redo allocation과 redo copy를 별도의 latch를 이용하여 두 단계로 나누어
    작업하는 것이 성능 향상에 도움이 되지 않을 수도 있다. 오히려 copy하는 데 시간이
    거의 안 걸린다면 redo allocation latch 하나를 잡고서 redo allocation과 redo
    copy를 모두 수행하는 것이 나을 수도 있다.
    그렇다면 redo copy latch를 사용하는 상황에서 이 latch를 사용하지 않아도 되는,
    작은 redo entry의 기준을 설정할 필요가 있다.
    이것을 결정하는 parameter가 log_small_entry_max_size이다.
    즉, log_small_entry_max_size보다 큰 redo entry는 redo copy를 위해 redo copy
    latch를 사용하지만, 이보다 작은 크기의 redo entry에 대해서는 redo allocation
    latch를 이용하여 redo allocation과 copy를 모두 수행하게 되는 것이다.
    아무리 작은 redo entry라도 redo copy latch를 사용하게 하고 싶다면 이 값을
    0으로 지정하면 된다.
    5. tuning point
    multi-CPU 환경에서 redo copy latch의 갯수를 늘리거나, log_small_entry_max_size
    값을 줄여야 할때는 redo buffer에 contention이 발생하는 경우이다.
    redo buffer에 contention이 발생하는지 확인하는 방법은 다음과 같다.
    SQL>select name, gets, misses from v$latch where name = 'redo allocation';
    이 값의 결과에서 gets에 대한 misses의 비율이 1%를 넘는다면 이것은 contention
    이 존재한다고 판단될 수 있다. 물론 이것은 절대적인 기준은 아니어서, 1% 미만
    이라 하더라도 miss 율을 더 줄이고자 할 수도 있다.
    contention이 발생하면 log_simultaneous_copies의 값을 CPU의 약 두배 정도까지
    증가시키는 것이 권고할 만하고, log_small_entry_max_size의 값도 0에 가까운
    값으로 줄여서 contention의 상황을 지속적으로 살펴보아야 한다.
    6. 8i 에서의 변경 사항
    Oracle 8.1 에서는 위에서 설명한 두 parameter가 모두 나타나지 않는다.
    log_small_entry_max_size parameter는 완전히 없어졌으며,
    log_simultaneous_copies 값은 CPU_COUNT의 두배로 무조건 설정이 된다.
    이 CPU_COUNT는 앞에서 설명한 것과 같이 operating system layer에 의해
    자동으로 결정되는 parameter로 CPU의 갯수를 나타낸다.
    log_simultaneous_copies가 자동으로 CPU 갯수의 2배로 지정되는 것은 모든
    환경에서 대부분 최적이라고 볼 수 있으므로, user가 변경하지 않도록 하기 위해
    parameter 부분에 display가 안 되도록 하였다.

  • Redo log dump를 통하여 획득한 .trc 파일에 대하여 질문드립니다.

    Oracle 10g R2 버전에서
    Redo Log dump를 통하여 획득한 .trc 파일의 내용중에서
    REDO RECORD - Thread:1 RBA: 0x00002a.00000002.0010 LEN: 0x0220 VLD: 0x05
    REDO RECORD - Thread:1 RBA: 0x00002a.00000003.0040 LEN: 0x00f0 VLD: 0x01
    REDO RECORD - Thread:1 RBA: 0x00002a.00000018.0010 LEN: 0x0740 VLD: 0x0d
    VLD라는 항목이 있습니다.
    VLD 항목이 의미하는 바와
    0x05, 0x0d, 0x01 등의 값들의 의미를 알고 싶습니다.

    안녕하세요. 답변 주셔서 감사합니다.
    링크해주신 사이트는 참고하고 있던 사이트였습니다.
    당시 제 질문의 요지는 VLD 값이 0x05 0x01 0x0d 일때 해당 리두레코드는 어떤 타입을 의미하는 것인지를
    질문드렸었는데 전달이 조금 잘못되었던 것 같습니다. :)
    실제 Redo Log의 바이너리 구조를 분석해보면 위의 VLD에 따라서 구조가 다른것을 확인할 수 있었습니다.
    정확하게 VLD에 따라 그 구조가 구분된다라고 말할 수는 없지만, VLD의 값에 따라 4바이트 Timestamp 데이터의
    존재 여부 등의 차이가 존재하는 것을 확인했습니다.
    사실 오라클이 오픈소스가 아니기 때문에 VLD와 같은 항목이 모두 공개되리라고는 생각하지 않았습니다.
    예전에 조사한 바에 따르면 VLD는 Valid byte in record indicator의 약어라는 것을 알 수 있었습니다.
    이를 바탕으로 볼때 아래와 같은 내용에 맞아 들어가는 부분이 아닐까 추측하고 있습니다.
    The redo copy latch
    1. The redo entry is marked as either VALID or INVALID in the log buffer before the redo copy latch is released
    2. The validity of redo records can be confirmed before they are written to disk by LGWR
    3. Recovery just skips any redo that is marked as INVALID
    여기까지가 당시 Redo Log 파일에 대해 깊숙히 연구해야할 필요가 있어서 진행했던 부분중에 일부입니다.
    앞으로 관련 연구를 하시는 분들께 혹시나 도움이 될까 고민했던 부분을 적어 놓고 갑니다. :)

  • Redo log buffer question

    hi masters,
    this seems to be very basic, but i would like to know internal of this process.
    we all know that LGWR writes redo entries to online redo log files on disk. on commit SCN is generated and tagged to transaction. and LGWR writes this to online redo log files.
    but my question is, how these redo entries comes to redo log buffer??? look all required data is fetched into buffer cache by server process. it is modified there, and committed. DBWR writes this to datafiles, but at what point, which process writes this committed transaction (i think redo entry) into log buffer cache????
    does LGWR do this?? what internally happens exactly???
    if you can plz focus some light on internals, i will be thankfull....
    thanks and regards
    VD

    Hi Vikrant,
    DBWR writes this to datafiles, but at what point, which process writes this committed transaction (i think redo entry) into log buffer cache????Remember that, Before DBWR Acts on flushing the dirty Blocks to Data files, Before this server process, makes sure that LGWR finishes the writing Redo Log Buffer to Online Redo Log files. Since as per ORACLE Architecture poting of Recovering data till point of time @ Crash is important and this is achieved by Online Redo Logs files.
    Rest how the data is Updated in to the Redo Log Buffer Aman had stated the clear steps.
    - Pavan Kumar N

Maybe you are looking for