Redo log size of the defect of EBS

Similar Questions

• Redo log entries to the online redo log files

  Hello

  I'm a little confused about the redo log entries.

  I learned that LGWR writes redo log entries in the SGA, in redo log files in the following situation:

  -3 seconds after the last validation

  -redo log buffer has 1 MB

  -redo log buffer data 1/3

  When I take a transaction and if I change the wrong data, I have to cancel this transaction BUT the right now,

  What happens if the LGWR writes redo log disk entries?

  Is the bad transaction committed at all times?

  2791011 wrote:

  Hello

  I'm a little confused about the redo log entries.

  I learned that LGWR writes redo log entries in the SGA, in redo log files in the following situation:

  -3 seconds after the last validation

  -redo log buffer has 1 MB

  -redo log buffer data 1/3

  When I take a transaction and if I change erroneous data, I have to cancel this transaction at this time, BUT

  What happens if the LGWR writes redo log disk entries?

  Is the bad transaction committed at all times?

  DML changes are "permanent" after that VALIDATION is issued.

  When any COMMIT is issued, then changes can be undone.

• Files redo log by using the optimal_logfile_size to design view.

  Concerning
  
  I have a specific question about the size of the log file. I have deployed a database of test and I was exploring some aspects regarding the selection of the optimal size of recovery for performance logs by using the view v$ instance_recovery optimal_logfile_size. My main goal is necessary for example to reduce the bytes redo recovery. Currently I have not been able to optimize the size of redo log file. Here are the steps I followed: -.
  
  In order to use the view v$ instance_recovery, I had to put the fast_start_mttr_target parameter which is by default do not then I did as follows: -.
  
  (1) SQL > sho parameter fast_start_mttr_target;
  
  VALUE OF TYPE NAME
  ------------------------------------ --------------------------------- ------------------------------
  fast_start_mttr_target integer 0
  
  (2) setting the fast_start_mttr_target requires destroy deferred to the following parameters: -.
  SQL > show parameter log_checkpoint;
  
  VALUE OF TYPE NAME
  ------------------------------------ --------------------------------- ------------------------------
  log_checkpoint_interval integer 0
  log_checkpoint_timeout around 1800
  log_checkpoints_to_alert boolean FALSE
  
  SQL > select ISSES_MODIFIABLE, ISSYS_MODIFIABLE, ISINSTANCE_MODIFIABLE, ISMODIFIED parameter of $ v where name like 'log_checkpoint_timeout;
  
  ISSES_MODIFIABL ISSYS_MODIFIABLE ISINSTANCE_MODI ISMODIFIED
  --------------- --------------------------- --------------- ------------------------------
  IMMEDIATE FALSE TRUE FALSE
  
  SQL > alter system set log_checkpoint_timeout = 0 scope = both;
  
  Modified system.
  
  SQL > show parameter log_checkpoint_timeout;
  
  VALUE OF TYPE NAME
  ------------------------------------ --------------------------------- ------------------------------
  log_checkpoint_timeout integer 0
  
  (3) setting fast_start_mttr_target now
  
  SQL > select ISSES_MODIFIABLE, ISSYS_MODIFIABLE, ISINSTANCE_MODIFIABLE, ISMODIFIED parameter of $ v where name like 'fast_start_mttr_target;
  
  ISSES_MODIFIABL ISSYS_MODIFIABLE ISINSTANCE_MODI ISMODIFIED
  --------------- --------------------------- --------------- ------------------------------
  IMMEDIATE FALSE TRUE FALSE
  
  Definition of the fast_mttr_target to 1200 = 20 minutes of the control point of switching on the recommendation of the Oracle
  
  Ask the view v instance_recovery $
  
  (4) SQL > select ACTUAL_REDO_BLKS, TARGET_REDO_BLKS, TARGET_MTTR, ESTIMATED_MTTR, OPTIMAL_LOGFILE_SIZE, CKPT_BLOCK_WRITES from v$ instance_recovery;
  
  ACTUAL_REDO_BLKS TARGET_REDO_BLKS TARGET_MTTR ESTIMATED_MTTR OPTIMAL_LOGFILE_SIZE CKPT_BLOCK_WRITES
  ---------------- ---------------- ----------- -------------- -------------------- -----------------
  276 165888 * 93 * 59 361 16040
  
  Here target MTTR was 93 so I put the fast_mttr_target to 120
  
  SQL > alter system set fast_start_mttr_target = 120 scope = both;
  
  Modified system.
  
  The size of the log file suggested by v$ instance_recovery is now 290 MB
  
  SQL > select ACTUAL_REDO_BLKS, TARGET_REDO_BLKS, TARGET_MTTR, ESTIMATED_MTTR, OPTIMAL_LOGFILE_SIZE, CKPT_BLOCK_WRITES from v$ instance_recovery;
  
  ACTUAL_REDO_BLKS TARGET_REDO_BLKS TARGET_MTTR ESTIMATED_MTTR OPTIMAL_LOGFILE_SIZE CKPT_BLOCK_WRITES
  ---------------- ---------------- ----------- -------------- -------------------- -----------------
  59 165888 93 59 290 16080
  
  After you change the size of the logfile to 290 as indicated below by v$ log view;
  
  SQL > select GROUP #, THREAD #, SEQUENCE #, BYTES of the log v$.
  
  GROUP # THREAD # SEQUENCE # BYTES
  ---------- ---------- ---------- ----------
  1 1 24 304087040
  2 1 0 304087040
  3 1 0 304087040
  4 1 0 304087040
  (5) after you change the size, I observed the anomaly as redo log blocks to be applied for the recovery went to * $ 59 to 696 * v instance_recovery view is now also now offers the size of the log file of * 276 MB *. Have I misunderstood something
  
  SQL > select ACTUAL_REDO_BLKS, TARGET_REDO_BLKS, TARGET_MTTR, ESTIMATED_MTTR, OPTIMAL_LOGFILE_SIZE, CKPT_BLOCK_WRITES from v$ instance_recovery;
  
  ACTUAL_REDO_BLKS TARGET_REDO_BLKS TARGET_MTTR ESTIMATED_MTTR OPTIMAL_LOGFILE_SIZE CKPT_BLOCK_WRITES
  ---------------- ---------------- ----------- -------------- -------------------- -----------------
  * 696 * 646947 120 59 * 276 * 18474
  
  If please specify the output above, that I'm unable to optimize the size of the log file and have not been able to achieve the goal of reducing the redo log blocks to apply for recovery, any help is appreciated in this regard.

  I don't think that test for the optimum size of redo's CTD. Maybe if you did each week, as a regular or something, but the unique initial setup and sometimes check in production? N ° but it will be iterative as part of a deployment of init.ora Exchange.

  In addition, it is part of the DBA job to understand the recovery and what to expect. Which includes the understanding of all these parameters, init and tests for the environment. It also includes an understanding of the characteristics of the application and its load.

• Redo Log size recommended

  Hello all,.
  
  For a while I myself have wondered what would be the correct redologsize for a database.
  I found the note
  the new 10g feature: REDO LOG SIZING ADVISORY [ID 274264.1]
  
  who says:
  '+ Rule switching newspapers maximum once every fifteen minutes. + »
  
  Well, I came across a DB with about 3 logswitches per minute (OEL 4.6 environment RAC 10 g 2).
  Do you think that this number is WAY over what it should be? What are your redolog sizes?
  
  The note mentioned also using the instance_recovery view v$ to give advice on the size redolog, which takes into account the MTTR.
  
  Thank you.
  ARO
  Pinela.
  
  Published by: Pinela on November 7, 2011 14:42

  Pinela wrote:
  Thank you all for you comments,

  jgarry,
  Yes, it is a good idea. For the moment, no, there are no errors, messages or complaints. In this case, the impact of the size redolog, refers to restore and cloning operations.

  Aman,
  "more than 4-5 swithces an hour - in general is considered correct". Interestingly, it is a good basis.

  Give more context. The DB in questions about 800 GB, redologs with 50 MB in size and is logswitches 3/4 times each minute (as mentioned earlier) and 1,200 users.

  With these new values, do you everything keep or change your mind?
  I would recommend changing the size redolog to 1 or 2 GB.

  500 MB is very small for a database of ~ 800 GB. For about 2-3 GB of the size of redo log file should be a good start. But please note that only affecting the size of the log file again X value cannot solve the problem. Would be also filled too quickly? If IMO as well as to define the size of redo log to about 3 GB file, you should consider the parameter ARCHIVE_LAG_TARGET so a value which you should expect to maintain for the switching log (as already suggested by others). This would let you control the speed of switching rather than being dependent on the size of the log file or database activity.

  HTH
  Aman...

• ADDM-Redo log size increase on asm

  HII,
  I ran addm and next msg.
  
  CONCLUSION 4: 5.8% impact (762 seconds)
  ------------------------------------
  Switch to the log file operations consumed in times of important data while
  pending the completion of the control point.
  
  RECOMMENDATION 1: Configuration of the DB, 5.8% enjoy (762 seconds)
  ACTION: Check if extra shipping has been used for sleep
  databases.
  
  RECOMMENDATION 2: Configuration of the DB, 5.8% enjoy (762 seconds)
  ACTION: Increase the size of the log files to 1839 to hold at least 20 M
  minutes of redo information.
  
  
  My database is in log mode archive... and I asm storage... How increase the size of the redo log file... can I do when the instance is open?
  or I should have gone to mount the mode to do this.

  To increase the size of redologfiles online, you will need to drop and create them again. But you can't drop current/active group, you can drop the Group inactive and unused. To provide what you need by using alter system switch logfile; change checkpoint system; for example

  SQL> select member from v$logfile;
  
  MEMBER
  --------------------------------------------------------------------------------
  
  D:\ORACLE\PRODUCT\10.2.0\ORADATA\SB\REDO3.LOG
  D:\ORACLE\PRODUCT\10.2.0\ORADATA\SB\REDO2.LOG
  D:\ORACLE\PRODUCT\10.2.0\ORADATA\SB\REDO1.LOG
  
  SQL> select group#,status from v$log;
  
      GROUP# STATUS
  ---------- ----------------
           1 INACTIVE
           2 CURRENT
           3 INACTIVE
  
  SQL> alter database drop logfile group 1;
  
  Database altered.
  
  SQL> alter database add logfile group 1 ('D:\ORACLE\PRODUCT\10.2.0\ORADATA\SB\RE
  DO1.LOG') size 60M reuse;
  
  Database altered.
  
  SQL> select group#,status from v$log;
  
      GROUP# STATUS
  ---------- ----------------
           1 UNUSED
           2 CURRENT
           3 INACTIVE
  
  SQL> alter system switch logfile;
  
  System altered.
  
  SQL> alter system checkpoint;
  
  System altered.
  
  SQL> select group#,status from v$log;
  
      GROUP# STATUS
  ---------- ----------------
           1 CURRENT
           2 INACTIVE
           3 INACTIVE
  
  SQL> alter database drop logfile group 2;
  
  Database altered.
  
  SQL> alter database add logfile group 2 ('D:\ORACLE\PRODUCT\10.2.0\ORADATA\SB\RE
  DO2.LOG') size 60M reuse;
  
  Database altered.
  
  SQL>
  

• Connect the switch to Oracle 9iR2 - redo log size too small?

  Hi all!
  
  I just ran a report of Diagnostic Agent service RDA (Remote) and have found a lot of information on our company database system.
  
  Among the interesting findings is that newspaper that shows recovery logs archiving.
  
  It seems that it is quite often archiving. This means that our recovery logs is too small (they are 50 MB)? Please check the date and time stamp of the columns in the papers below for details.
  
  Also, sorry for the column headers and columns being not very well aligned. I hope that it is readable for you anyway.
  
  
  Information from V$ Logfile and V$ Log
  
  V$ Logfile
  Group # member status
  1 null value /prog26/ORACLE/X4450/redo_01.log
  2 null value /prog26/ORACLE/X4450/redo_02.log
  3 null value /prog26/ORACLE/X4450/redo_03.log
  
  V$ Log
  Group # Thread # sequence # bytes members archived first change state # first time
  1 1 19394 52428800 1 NO CURRENT 9944095405700 March 4, 2009 14:24:40
  YES 2 1 19392 52428800 1 INACTIVE 9944095397506 4 March 2009 14:23:49
  3 1 19393 52428800 1 YES ON 9944095402911 March 4, 2009 14:24:06
  
  
  
  
  Status of data protection
  Gravity installation Dest Id Message Num Code legend Timestamp Error Message
  Connect the control Services of carriage 40075 0 0 YES March 4, 2009 08:19:53 ARC0: complete archiving 3 thread 1 sequence 19339 journal
  Log of information Transport Services 0 0 40076 No. 4 March 2009 08:20:07 ARC0: Evaluating archive log 1 thread 1 sequence 19340
  Log Transport Services 0 40077 Control 0 YES March 4, 2009 08:20:07 ARC0: starts to archive log 1-wire 1 sequence 19340
  Log of information Transport Services 0 0 40078 No. 4 March 2009 08:20:07 destination creation of archive LOG_ARCHIVE_DEST_1: ' / prog26/oracle/admin/X4450/arch/archX4450.log1_19340.dbf'
  Log Transport Services 0 40079 Control 0 YES March 4, 2009 08:20:09 ARC0: completed archive connect 1 thread 1 sequence 19340
  Log of information Transport Services 0 0 40080 No. 4 March 2009 08:20:23 ARC0: Evaluating archive log 2 wire 1 sequence 19341
  Log Transport Services 0 40081 Control 0 YES March 4, 2009 08:20:23 ARC0: starts to archive log 2 wire 1 sequence 19341
  Log of information Transport Services 0 40082 0 no. 4 March 2009 08:20:23 destination archive creation LOG_ARCHIVE_DEST_1: ' / prog26/oracle/admin/X4450/arch/archX4450.log1_19341.dbf'
  Log Transport Services 0 40083 Control 0 YES March 4, 2009 08:20:25 ARC0: completed thread 1 archiving of Journal 2 sequence 19341
  Log of information Transport Services 0 0 40084 No. 4 March 2009 08:20:39 ARC0: Evaluating archive log 3 wire 1 sequence 19342
  Log Transport Services 0 40085 Control 0 YES March 4, 2009 08:20:39 ARC0: starts to archive log 3 wire 1 sequence 19342
  Log of information Transport Services 0 0 40086 No. 4 March 2009 08:20:39 destination creation of archive LOG_ARCHIVE_DEST_1: ' / prog26/oracle/admin/X4450/arch/archX4450.log1_19342.dbf'
  Connect the control Services of carriage 40087 0 0 YES March 4, 2009 08:20:41 ARC0: complete archiving 3 thread journal 1 sequence 19342
  Log of information Transport Services 0 0 40088 No. 4 March 2009 08:20:55 ARC0: Evaluating archive log 1 thread 1 sequence 19343
  Log Transport Services 0 40089 Control 0 YES March 4, 2009 08:20:55 ARC0: starts to archive log 1-wire 1 sequence 19343
  Log of information Transport Services 0 40090 0 no. 4 March 2009 08:20:55 destination archive creation LOG_ARCHIVE_DEST_1: ' / prog26/oracle/admin/X4450/arch/archX4450.log1_19343.dbf'
  Log Transport Services 0 40091 Control 0 YES March 4, 2009 08:20:57 ARC0: completed archive connect 1 thread 1 sequence 19343
  Log of information Transport Services 0 0 40092 No. 4 March 2009 08:21:11 ARC0: Evaluating archive log 2 wire 1 sequence 19344
  Log Transport Services 0 40093 Control 0 YES March 4, 2009 08:21:11 ARC0: starts to archive log 2 wire 1 sequence 19344
  Log of information Transport Services 0 40094 0 no. 4 March 2009 21:08:11 destination archive creation LOG_ARCHIVE_DEST_1: ' / prog26/oracle/admin/X4450/arch/archX4450.log1_19344.dbf'
  Log Transport Services 0 40095 Control 0 YES March 4, 2009 08:21:13 ARC0: completed thread 1 archiving of Journal 2 sequence 19344
  Log of information Transport Services 0 0 40096 No. 4 March 2009 08:21:27 ARC0: Evaluating archive log 3 wire 1 sequence 19345
  Log Transport Services 0 40097 Control 0 YES March 4, 2009 08:21:27 ARC0: starts to archive log 3 wire 1 sequence 19345
  Log of information Transport Services 0 40098 0 no. 4 March 2009 08:21:27 destination archive creation LOG_ARCHIVE_DEST_1: ' / prog26/oracle/admin/X4450/arch/archX4450.log1_19345.dbf'
  Log of information Transport Services 0 0 40099 No. 4 March 2009 08:21:43 ARC1: Evaluating archive log 3 wire 1 sequence 19345
  Log Transport Services WARNING 0 40100 1 No. 4 March 2009 08:21:43 ARC1: impossible to archive log 3 thread 1 sequence 19345
  Log of information Transport Services 0 40101 0 no. 4 March 2009 08:21:43 Log Archived actively by another process
  
  
  
  History of archives
  Stamp RecId name Dest Id Thread # sequence # Resetlogs change # Resetlogs time first change # Primo next change # next time blocks block size creator Registrar Dest applied archived standby status deleted end time dictionary dictionary tip tip of Redo Backup Begin archiving Thread # Activation County #.
  9408 674554239 /prog26/oracle/admin/X4450/arch/archX4450.log1_9408.dbf 1 1 9408 9085999921960 23 August 2008 21:12:37 9091063265490 December 27, 2008 08:10:23 9091063265585 December 27, 2008 08:10:37 102398 512 ARCH ARCH no YES NO a December 27, 2008 08:10:39 NO NO NO 0 1 3017662510
  9409 674554252 /prog26/oracle/admin/X4450/arch/archX4450.log1_9409.dbf 1 1 9409 9085999921960 23 August 2008 21:12:37 9091063265585 December 27, 2008 08:10:37 9091063265684 December 27, 2008 08:10:50 102398 512 ARCH ARCH no YES NO a December 27, 2008 08:10:52 0 1 3017662510 NO NO NO
  9410 674554266 /prog26/oracle/admin/X4450/arch/archX4450.log1_9410.dbf 1 1 9410 9085999921960 23 August 2008 21:12:37 9091063265684 December 27, 2008 08:10:50 9091063265783 December 27, 2008 08:11:03 102398 512 ARCH ARCH no YES NO a December 27, 2008 08:11:06 0 1 3017662510 NO NO NO
  9411 674554279 /prog26/oracle/admin/X4450/arch/archX4450.log1_9411.dbf 1 1 9411 9085999921960 23 August 2008 21:12:37 9091063265783 December 27, 2008 08:11:03 9091063265884 December 27, 2008 08:11:17 102398 512 ARCH ARCH no YES NO a December 27, 2008 08:11:19 0 1 3017662510 NO NO NO
  9412 674554293 /prog26/oracle/admin/X4450/arch/archX4450.log1_9412.dbf 1 1 9412 9085999921960 23 August 2008 21:12:37 9091063265884 December 27, 2008 08:11:17 9091063265980 December 27, 2008 08:11:31 102398 512 ARCH ARCH no YES NO a December 27, 2008 08:11:33 0 1 3017662510 NO NO NO
  9413 674554306 /prog26/oracle/admin/X4450/arch/archX4450.log1_9413.dbf 1 1 9413 9085999921960 23 August 2008 21:12:37 9091063265980 December 27, 2008 08:11:31 9091063266072 December 27, 2008 08:11:44 102398 512 ARCH ARCH no YES NO a December 27, 2008 08:11:46 0 1 3017662510 NO NO NO
  9414 674554506 /prog26/oracle/admin/X4450/arch/archX4450.log1_9414.dbf 1 1 9414 9085999921960 23 August 2008 21:12:37 9091063266072 December 27, 2008 08:11:44 9091063287590 27 December 2008 08:15:01 102398 512 ARCH ARCH no YES NO a 27 December 2008 08:15:06 0 1 3017662510 NO NO NO
  9415 674563077 /prog26/oracle/admin/X4450/arch/archX4450.log1_9415.dbf 1 1 9415 9085999921960 23 August 2008 21:12:37 9091063287590 December 27, 2008 08:15:01 9091063833538 December 27, 2008 10:37:54 102398 512 ARCH ARCH no YES NO a December 27, 2008 10:37:57 0 1 3017662510 NO NO NO
  9416 674570183 /prog26/oracle/admin/X4450/arch/archX4450.log1_9416.dbf 1 1 9416 9085999921960 23 August 2008 21:12:37 9091063833538 December 27, 2008 10:37:54 9091064440549 December 27, 2008 12:36:17 102398 512 ARCH ARCH no YES NO a December 27, 2008 12:36:23 0 1 3017662510 NO NO NO
  9417 674582409 /prog26/oracle/admin/X4450/arch/archX4450.log1_9417.dbf 1 1 9417 9085999921960 23 August 2008 21:12:37 9091064440549 December 27, 2008 12:36:17 9091065119444 December 27, 2008 16:00:03 102398 512 ARCH ARCH no YES NO a 27 December 2008 16:00:09 0 1 3017662510 NO NO NO
  9418 674585288 /prog26/oracle/admin/X4450/arch/archX4450.log1_9418.dbf 1 1 9418 9085999921960 23 August 2008 21:12:37 9091065119444 December 27, 2008 16:00:03 9091065291305 December 27, 2008 16:48:06 102398 512 ARCH ARCH no YES NO a 27 December 2008 16:48:08 0 1 3017662510 NO NO NO
  9419 674586049 /prog26/oracle/admin/X4450/arch/archX4450.log1_9419.dbf 1 1 9419 9085999921960 23 August 2008 21:12:37 9091065291305 December 27, 2008 16:48:06 9091065312654 27 December 2008 17:00:44 102398 512 ARCH ARCH no YES NO a 27 December 2008 17:00:49 0 1 3017662510 NO NO NO
  9420 674600023 /prog26/oracle/admin/X4450/arch/archX4450.log1_9420.dbf 1 1 9420 9085999921960 23 August 2008 21:12:37 9091065312654 December 27, 2008 17:00:44 9091068116124 27 December 2008 20:53:38 102386 512 ARCH ARCH no YES NO a 27 December 2008 20:53:43 0 1 3017662510 NO NO NO
  9421 674620207 /prog26/oracle/admin/X4450/arch/archX4450.log1_9421.dbf 1 1 9421 9085999921960 23 August 2008 21:12:37 9091068116124 December 27, 2008 20:53:38 9091068973106 December 28, 2008 02:30:02 102398 512 ARCH ARCH no YES NO a December 28, 2008 02:30:07 0 1 3017662510 NO NO NO
  9422 674632413 /prog26/oracle/admin/X4450/arch/archX4450.log1_9422.dbf 1 1 9422 9085999921960 23 August 2008 21:12:37 9091068973106 December 28, 2008 02:30:02 9091069195751 December 28, 2008 05:53:29 64635 512 ARCH ARCH no YES NO a December 28, 2008 05:53:33 0 1 3017662510 NO NO NO

  From what I can understand with so many archives (8) in the id space 3-5 minute too high. You need to think about increasing the size redolog say about 500 MB in your case. The rule says 1 switch journal every 20 minutes... It IS a statistic of rush hour?

  And in this mode, your Dataguard works?

  Protection maximum/availability/performance?

  Published by: Maran Viswarayar March 10, 2009 10:22

• SIZE OF THE REDO LOG FILE

  
  Hello

  I got an error message when I add me new group. log files I searched and found the answer on the form. Ago 4 M minimum size of 11 g R2 log file size.

  My question is why a log file size depends on DB_BLOCK_SIZE? This parameter is set to the component structures of memory that create an instance when a log file is an operating system file that depend on the version of the OS not DB_BLOCK_SIZE.

  Thank you.

  
  SQL > alter database add logfile group 4 'c:\app\asif\oradata\employee\redo04.log' size 1 m;
  alter database add logfile group 4 'c:\app\asif\oradata\employee\redo04.log' size 1 m
  *
  ERROR on line 1:
  ORA-00336: 2048 blocks the size of the log file is minimum lower than 8192 blocks

  
  SQL > show parameter db_block_size

  VALUE OF TYPE NAME
  ------------------------------------ ----------- ------------------------------
  Whole DB_BLOCK_SIZE 8192
  SQL >

  You are assuming that the redo log block size is the same as the database block size. This is not correct.

  The error indicates that 8192 is the minimum number of blocks of a redo log file. The documentation states that the minimum size is 4 M. For example, you can deduct your redo log block size is 512 bytes.

  Here's some more information about the size of redo log, the documentation block.

  Unlike the database block size, which can always be between 2 K and 32 K, redo log default files to a block size that is equal to the size of physical sector of the disk. Historically, it is usually 512 bytes (512 b).

  Some new large disks offer 4K sizes byte (4K) to increase sector efficiency improved format and ECC capabilities. Most of the Oracle database platforms are able to detect this bigger sector size. The database then automatically creates files redo log with a block size of 4 K of these discs.

• Question about the size of the redo log buffer

  Hello
  
  I am a student in Oracle and the book I use says that having a bigger than the buffer log by default, the size is a bad idea.
  
  It sets out the reasons for this are:
  
  >
  The problem is that when a statement COMMIT is issued, part of the batch validation means to write the contents of the buffer log for redo log to disk files. This entry occurs in real time, and if it is in progress, the session that issued the VALIDATION will be suspended.
  >
  
  I understand that if the redo log buffer is too large, memory is lost and in some cases could result in disk i/o.
  
  What I'm not clear on is, the book makes it sound as if a log buffer would cause additional or IO work. I would have thought that the amount of work or IO would be substantially the same (if not identical) because writing the buffer log for redo log files is based on the postings show and not the size of the buffer itself (or its satiety).
  
  Description of the book is misleading, or did I miss something important to have a larger than necessary log buffer?
  
  Thank you for your help,
  
  John.
  
  Published by: 440bx - 11 GR 2 on August 1st, 2010 09:05 - edited for formatting of the citation

  A commit evacuates everything that in the buffer redolog for redo log files.
  A redo log buffer contains the modified data.
  But this is not just commit who empty the redolog buffer to restore the log files.
  LGWR active every time that:
  (1) a validation occurs
  (2) when the redo log is 1/3 full
  (3) every 3 seconds
  It is not always necessary that this redolog file will contain validated data.
  If there is no commit after 3 seconds, redologfile would be bound to contain uncommitted data.

  Best,
  Wissem

• optimal size of redo log

  Hi all
  
  Recently we migrated 9.2.0.4 to 10.2.0.4 and performance of the database is slow in a newer version, log alerts of the audit, we found that: -.
  
  Thread 1 cannot allocate new logs, Checkpoint 1779 sequence is not complete
  Currently Journal # 6 seq # 1778 mem # 0: /oradata/lipi/redo6.log
  Currently Journal # 6 seq # 1778 mem # 1: /oradata/lipi/redo06a.log Wed Mar 10 15:19:27 2010 1 thread forward to log sequence 1779 (switch LGWR)
  Currently journal # 1, seq # 1779 mem # 0: /oradata/lipi/redo01.log
  Currently journal # 1, seq # 1779 mem # 1: /oradata/lipi/redo01a.log Wed Mar 10 15:20:45 2010 1 thread forward to log sequence 1780 (switch LGWR)
  Currently Journal # 2 seq # 1780 mem # 0: /oradata/lipi/redo02.log
  Currently Journal # 2 seq # 1780 mem # 1: /oradata/lipi/redo02a.log Wed Mar 10 15:21:44 2010 1 thread forward to log sequence 1781 (switch LGWR)
  Currently Journal # 3 seq # 1781 mem # 0: /oradata/lipi/redo03.log
  Currently Journal # 3 seq # 1781 mem # 1: /oradata/lipi/redo03a.log Wed Mar 10 15:23 2010 Thread 1 Advanced to save sequence 1782 (switch LGWR)
  Currently Journal # 4, seq # 1782 mem # 0: /oradata/lipi/redo04.log
  Currently Journal # 4, seq # 1782 mem # 1: /oradata/lipi/redo04a.log Wed Mar 10 15:24:48 2010 1 thread forward to log sequence 1783 (switch LGWR)
  Currently journal # 5 seq # 1783 mem # 0: /oradata/lipi/redo5.log
  Currently journal # 5 seq # 1783 mem # 1: /oradata/lipi/redo05a.log Wed Mar 10 15:25 2010 1 thread cannot allocate new journal, sequence 1784 Checkpoint ends not
  Currently journal # 5 seq # 1783 mem # 0: /oradata/lipi/redo5.log
  Currently journal # 5 seq # 1783 mem # 1: /oradata/lipi/redo05a.log Wed Mar 10 15:25:27 2010 1 thread forward to log sequence 1784 (switch LGWR)
  Currently Journal # 6 seq # 1784 mem # 0: /oradata/lipi/redo6.log
  Currently Journal # 6 seq # 1784 mem # 1: /oradata/lipi/redo06a.log Wed Mar 10 15:28:11 2010 1 thread forward to log sequence 1785 (switch LGWR)
  Currently journal # 1, seq # 1785 mem # 0: /oradata/lipi/redo01.log
  Currently journal # 1, seq # 1785 mem # 1: /oradata/lipi/redo01a.log Wed Mar 10 15:29:56 2010 1 thread forward to log sequence 1786 (switch LGWR)
  Currently Journal # 2 seq # 1786 mem # 0: /oradata/lipi/redo02.log
  Currently Journal # 2 seq # 1786 mem # 1: /oradata/lipi/redo02a.log Wed Mar 10 15:31:22 2010 1 wire could not be allocated for new newspapers, private part of 1787 flush sequence is not complete
  Currently Journal # 2 seq # 1786 mem # 0: /oradata/lipi/redo02.log
  Currently Journal # 2 seq # 1786 mem # 1: /oradata/lipi/redo02a.log Wed Mar 10 15:31:29 2010 1 thread forward to log sequence 1787 (switch LGWR)
  Currently Journal # 3 seq # 1787 mem # 0: /oradata/lipi/redo03.log
  Currently Journal # 3 seq # 1787 mem # 1: /oradata/lipi/redo03a.log Wed Mar 10 15:31:40 2010 1 thread cannot allocate a new journal, sequence 1788 Checkpoint ends not
  Currently Journal # 3 seq # 1787 mem # 0: /oradata/lipi/redo03.log
  Currently Journal # 3 seq # 1787 mem # 1: /oradata/lipi/redo03a.log Wed Mar 10 15:31:47 2010 1 thread forward to log sequence 1788 (switch LGWR)
  Currently Journal # 4, seq # 1788 mem # 0: /oradata/lipi/redo04.log
  Currently Journal # 4, seq # 1788 mem # 1: /oradata/lipi/redo04a.log
  
  so my point is, we should increase the redo log size to set the checkpoint ends not message, if yes, then what should be the optimum size of the redo log file?
  
  Piyush

  The REDO LOG file must contain at least 20 minutes of data, the log file will be every 20 minutes.
  It is the best practice, otherwise he must log frequent switching and increasing the e/s and waiting.

  The optimum size can be obtained
  by querying the column OPTIMAL_LOGFILE_SIZE of the view V$ INSTANCE_RECOVERY.

  Published by: adnanKaysar on March 11, 2010 17:03

• Adding more large size Redo log groups in RAC, ASM

  Hi people,
  
  Version of database - 10.1.0.4.0
  Version of the OS - AIX 5.3
  Node 2 RAC and ASM
  
  We had 4 groups of log roll forward of any size on the two nodes.yesterday, I added 4 new larger size groups using pl/sql developer tool and deleted the old 2 redolog groups. But I'm not able to remove the rest of the 2 groups of old.
  
  ORA-01567 a log2 fall would have less than 2 log files for example 1.
  
  Our redolog files are the SAN and the two points of the same storage node. When I pulled this command line query
  
  SELECT v$ logfile.member, v$ logfile.group #, v$ log.status, v$ log.bytes
  V $ log v$ logfile
  WHERE v$ log.group # v = $logfile.group #;
  
  I had the same result for both nodes.
  
  The problem that I think, is that all 4 new newspaper groups are added to instance 2 and its old 2 grouips are are also deleted.
  
  
  Now my question is that:
  
  1 should I I added groups of redo log separately on the two nodes of storage is the same for both nodes?
  2 redologs groups are defined separately for each node?
  
  How can I assign 2 new groups of newspapers to instantiate redo 1?
  
  Kind regards

  Redo log group should minus 2 groups each of the thread.
  But it is good to use 3 groups... each of the threads.

  and 2 members on each of the groups.

  all redo check journal... from v$ session, v$ logfile, v$ archvied_log

  If you mean the idea to determine approximately the size of the log to roll forward... you can check newspaper alerts.

  or

  ALTER session set nls_date_format = "YYYY/MM/DD HH24:MI:SS;
  Select INST_ID select, name, control gv completion_time $ archived_log by 3.1.

  Good luck

• Questions about the parameters of database using a fast recovery area and the writing of two copies of archived redo logs.

  My databases are 11.2.0.3.7 Enterprise Edition. My OS is AIX 7.1.

  I am to convert databases to use individual zones of rapid recovery and have two questions about what values to assign to database settings related to archived redo logs. This example refers to a database.

  I read that if I specify

  Log_archive_dest_1 =' LOCATION = USE_DB_RECOVERY_FILE_DEST'

  the names of newspapers archived redo written in the default quick recovery area is '% t_%S_%r.dbf '.

  In the past my archived redo logs have been appointed based on the parameter

  log_archive_format='GPAIDT_archive_log_%t_%s_%r.arc'

  I think log_archive_format will be ignored for logs archived redo written in the fast recovery area.

  I am planning to write a second copy of the archived redo logs based on the parameter

  ALTER system set log_archive_dest_2 = ' LOCATION = / t07/admin/GPAIDT/arch.

  If I do this, the copy of logs placed in /t07 will be called '% t_%S_%r.dbf' or 'GPAIDT_archive_log_%t_%s_%r.arc '?

  Before my use of a fast recovery area, I used the OEM 12 c Console to specify settings of backup of database that has been deleted and archived redo logs after 1 backup. Oracle manuals say rather specify a deletion of "none" policy and allow Oracle delete newspapers in the area of fast recovery if necessary. Since I got to keep a second copy of these log files in /t07 should I keep the policy that says to delete logs after 1 backup? If I don't do that, how will they removed from /t07?

  Thank you

  Bill

  If I do this, the copy of logs placed in /t07 will be called '% t_%S_%r.dbf' or 'GPAIDT_archive_log_%t_%s_%r.arc '?

  They will be "GPAIDT_archive_log_%t_%s_%r.arc". LOG_ARCHIVE_FORMAT is only ignored for directories under OMF.

  Since I got to keep a second copy of these log files in /t07 should I keep the policy that says to delete logs after 1 backup? If I don't do that, how will they removed from /t07?

  You can hold the deletion policy as it is. Oracle documentation, defining the STRATEGY of the ARCHIVELOG DELETION: "the deletion of archived newspaper policy applies to logs archive destinations, including the area of fast recovery."

• Best location for the archived redo logs

  Hello

  I am OOF instructions and I want to make life for the DBA, that looks like my job easier.

  So, as the title says what is the location of the "standard/Best Practice' for archived redo logs? particularly the dest_1 which is usually local on the same server

  Thank you.

  Hello

  For you, I recommend the use of the Flash/fast recovery area.

  Configuration of the archived of Redo Log locations

  Oracle recommends that you use fast area recovery to an archive location, because the archived logs are managed automatically by the database. The file names generated for the newspapers archived in the fast recovery area correspond to Oracle managed files and are not determined by the parameter LOG_ARCHIVE_FORMAT . Whatever archiving scheme you choose, it is always advisable to create multiple copies of archived redo logs.

  Ref 1:

  http://docs.Oracle.com/CD/E11882_01/backup.112/e10642/rcmconfb.htm#CHDEHHDH

  Ref 2:

  http://docs.Oracle.com/CD/E11882_01/server.112/e17157/unplanned.htm#BABEEEFH

  REF 3:

  http://docs.Oracle.com/CD/E11882_01/backup.112/e10642/rcmconfb.htm#BRADV89418

  Kind regards

  Juan M

• I have to create the new group for waiting for redo log files?

  I have 10 group of files redo log with 2 members of each group for my primary database, I need to create new group for redo log files for the database of relief pending

  Group # members

  ==============

  1              2

  2              2

  3             2

  4             2

  5             2

  6             2

  7             2

  8             2

  9             2

  2 of 10

  If so, the following statement is correct? or nto

  ALTER DATABASE ADD STANDBY LOGFILE GROUP 1 ('D:\Databases\epprod\StandbyRedoLog\REDO01.) LOG',D:\Databases\epprod\StandbyRedoLog\REDO01_1.log');

  Please correct me if am doin wrong

  because when I run the statement I have error message saying: the group is already created.

  Thanks John

  I just found the answer

  Yes, it of recomeded to add the new group, for instnace if I have 10 group of 1 to 10, then the wait should be from 11 to 20

  Thanks I found the answer.

• Clusterware and/or CARS on separate storage, synchronized by applying the redo logs?

  Hello Experts,

  I am doing research on architectures high availability to meet high service LEVEL requirements (> = uptime of 99.7 percent and "without loss of important data") for a client.

  I have few resources for the implementation of this architecture: two physical database servers running 11g Standard Edition (so Data Guard is not an option), Enterprise Edition is not an option because of the price. Data storage will be on a San.

  The ideal solution would be an architecture whose node redundancy (Clusterware / RAC) and redundancy of the data (as in physical Standby: application of redo logs instead of data mirroring (corrupt physical) files).

  I did research Clusterware and CARS, but they use a shared storage. I'll use a SAN for storage, but this will not prevent physical mirroring of the corrupt data files.

  Is it possible to set up a PAP/Clusterware architecture with each separate storage node, where the two databases are synchronized by applying the redo logs?

  Is it possible to instantly apply redo logs to minimize the loss of data in case of automatic failover?

  If we need more information, I'll give you a pleasure it.

  Thanks in advance,

  Peter

  A RAC cluster still need a shared storage for database files: each cluster node cannot have its own separate storage.

  You need at least a physical database server 3rd for the standby database that can function without Data Guard as long as you use you own scripts to send and apply archived redo logs or use a product like dbvisit.

  I don't think it's possible to apply again immediately without Data Guard.

• datafiles and redo logs on the same drive

  Hi guys,.
  
  http://docs.Oracle.com/CD/E11882_01/server.112/e25494/onlineredo002.htm#i1306224
  
  >
  
  Data files should also be placed on different disks of redo log files to reduce contention in writing of the data blocks and redo records.
  >
  
  I really think if he actually any challenge when the first of all oracle can only writes files 1 redo log at a time.
  http://docs.Oracle.com/CD/E11882_01/server.112/e25494/onlineredo001.htm
  >
  Database only Oracle uses redo log files at the same time to store redo records written since the restore log buffer by progression. Log roll forward LGWR is preparing actively to is called the log during recovery.
  >
  
  If the process flow, I got after reading the chapters is
  
  When LGWR fills a log file of redo (roll forward records) then there will be a log switch + control points where writing for data blocks occur. There seems to be a flow series rather than a simultaneous sort of flow. So I don't really understand it when he speaks of contention will take place when records of data and files written redo which is the redo log file are on the same disks.
  
  Just to confirm with you guys, whenever there is a switch of newspaper one point of control occurs too right.
  http://docs.Oracle.com/CD/E11882_01/server.112/e25494/onlineredo002.htm? You can search checkpoint to access the section she made mention of this documentation.

  Think about this:

  Restore means to keep the information around in case you need to re-do (recovery or standby mode, i.e. the continuous collection). Updates as you do in a broad sense will be so potentially being twice, once for the data files and once to do it again. I'm sure you understand that the data is written in memory, and then later to the data by the writer of the db files, while there could be many more group of writing data, or they may even be long delayed. In addition, the data files are read at random, so you can't really think again in series compared to the data. Do it again is series, archiving is set, but the data is random, and random how depends on how your system is used.

  So that means all the type of reads and writes per redo and archive is fundamentally different from data and cancel. In the first case, you want to be able to breath out as I/O that you can, for the latter, you want to be able to randomly reading or writing at different times, with Oracle being smart enough to do a bit of it in memory and optimistic enough to make assumptions on when to do things and quite lazy for not doing everything right. Roll forward is critical.

  A while ago, someone pointed out that the e/s modern buffered in memory, do not really worry about this, because all the work required to set up and maintain it after spending records, fees are not much better than striping and mirroring everything (you can google SAMI). This is true to a point, and we can debate endlessly about RAID types and their effects on performance and how their buffering makes [url http://www.baarf.com/] useless BAARF. But the real debate is, where is the point that you should use separate to redo and data devices? In the real world, we often receive a standard hardware configuration, which works very well until it's not. A disk or controller will puff in a RAID-5 can happen "is not" real quick.

  You should probably take two thoughts:

  The docs are pretty General, and some old tips do not apply, may have transformed into myth or perhaps too general to be meaningful.

  There is always something in the db, and the more things underway, less you can make generalizations about the serialization.