optimal size of redo log

Similar Questions

• recommended OS size for redo log block

  Hello
  
  AIX platform
  Oracle 10.2.0.4
  
  Is there any system recommended filesystem blocksize where redo log should be placed?
  We tested with 512 bytes to 4 096 bytes. We got the best performance over 512 bytes in terms of waiting avg on synchronization of log file.
  There's recommendation on the same oracle/AIX?

  978881 wrote:
  Hello

  AIX platform
  Oracle 10.2.0.4

  Is there any system recommended filesystem blocksize where redo log should be placed?
  We tested with 512 bytes to 4 096 bytes. We got the best performance over 512 bytes in terms of waiting avg on synchronization of log file.
  There's recommendation on the same oracle/AIX?

  The recommendation is to create logs of recovery on a mount with agblk = 512bytes. Please refer following link (page 60) which is an oracle + IBM technical brief:

  http://www-03.IBM.com/support/techdocs/atsmastr.nsf/5cb5ed706d254a8186256c71006d2e0a/bae31a51a00fa0018625721f00268dc4/ $FILE/Oracle%20Architecture%20and%20Tuning%20on%20AIX%20 (v%202.30) .pdf

  Kind regards
  S.K.

• Archive logs always smaller in size then redo logs

  I'm on 10.2.0.3.
  
  My recovery logs (3 groups of 2 members each) is 50 M, while my archive logs is mostly between 30 M and 40 M & never reach 50. Journal Apprently switches are too often produce.
  You guys have an idea, what could cause one - and how to fix it?
  
  TIA.
  
  GROUP # THREAD # SEQUENCE # BYTES MEMBERS OF ARC STATUS FIRST_CHANGE # FIRST_TIME
  ---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ------------------
  YES 1 1 25679 52428800 2 INACTIVE 5176999019 5 MARCH 09
  2 1 25678 52428800 2 YES INACTIVE 5176976984 5 MARCH 09
  3 1 25680 52428800 2 NO CURRENT 5177009713 5 MARCH 09
  
  -rw - r - 1 oracle dba 36288512 5 March 10:45 arch1_25635_669756456.arc
  -rw - r - 1 oracle dba 35852288 5 March 10:45 arch1_25636_669756456.arc
  -rw - r - 1 oracle dba 38668288 5 March 10:45 arch1_25637_669756456.arc
  -rw - r - 1 oracle dba 40915968 5 March 10:45 arch1_25638_669756456.arc
  -rw - r - 1 oracle dba 35852288 5 March 10:45 arch1_25639_669756456.arc
  -rw - r - 1 oracle dba 44192768 5 March 10:45 arch1_25640_669756456.arc
  -rw - r - 1 oracle dba 46884864 5 March 10:45 arch1_25641_669756456.arc
  -rw - r - 1 oracle dba 35852288 5 March 10:46 arch1_25642_669756456.arc
  -rw - r - 1 oracle dba 35848192 5 March 10:46 arch1_25643_669756456.arc
  -rw - r - 1 oracle dba 38760448 5 March 10:46 arch1_25644_669756456.arc
  -rw - r - 1 oracle dba 35851264 5 March 10:47 arch1_25645_669756456.arc
  -rw - r - 1 oracle dba 41501696 5 March 10:47 arch1_25646_669756456.arc
  -rw - r - 1 oracle dba 44226560 5 March 10:47 arch1_25647_669756456.arc
  -rw - r - 1 oracle dba 41139200 5 March 10:47 arch1_25648_669756456.arc
  -rw - r - 1 oracle dba 35852288 5 March 10:47 arch1_25649_669756456.arc
  -rw - r - 1 oracle dba 36099072 5 March 10:47 arch1_25650_669756456.arc
  -rw - r - 1 oracle dba 43916288 5 March 10:47 arch1_25651_669756456.arc
  -rw - r - 1 oracle dba 43497472 5 March 10:47 arch1_25652_669756456.arc
  -rw - r - 1 oracle dba 36912128 5 March 10:47 arch1_25653_669756456.arc
  -rw - r - 1 oracle dba 35848192 5 March 10:53 arch1_25654_669756456.arc
  -rw - r - 1 oracle dba 36176896 5 March 10:56 arch1_25655_669756456.arc
  -rw - r - 1 oracle dba 36613120 arch1_25656_669756456.arc March 5 from 11:00
  -rw - r - 1 oracle dba 36086784 5 March 11:10 arch1_25657_669756456.arc
  -rw - r - 1 oracle dba 35859456 5 March 11:15 arch1_25658_669756456.arc
  -rw - r - 1 oracle dba 39876608 5 March 11:16 arch1_25659_669756456.arc
  -rw - r - 1 oracle dba 37593088 5 March 11:18 arch1_25660_669756456.arc
  -rw - r - 1 oracle dba 37158912 5 March 11:24 arch1_25661_669756456.arc
  -rw - r - 1 oracle dba 38323200 5 March 11:25 arch1_25662_669756456.arc
  -rw - r - 1 oracle dba 36100096 5 March 11:25 arch1_25663_669756456.arc
  -rw - r - 1 oracle dba 35860480 5 March 11:35 arch1_25664_669756456.arc
  -rw - r - 1 oracle dba 35848192 5 March 11:48 arch1_25665_669756456.arc
  -rw - r - 1 oracle dba 36048896 5 March 11:56 arch1_25666_669756456.arc
  -rw - r - 1 oracle dba 35852288 5 March 12:05 arch1_25667_669756456.arc
  -rw - r - 1 oracle dba 35990528 5 March 12:07 arch1_25668_669756456.arc
  -rw - r - 1 oracle dba 36060160 5 March 12:12 arch1_25669_669756456.arc
  -rw - r - 1 oracle dba 35888128 5 March 12:16 arch1_25670_669756456.arc
  -rw - r - 1 oracle dba 36460544 5 March 12:18 arch1_25671_669756456.arc
  -rw - r - 1 oracle dba 35857408 5 March 12:21 arch1_25672_669756456.arc
  -rw - r - 1 oracle dba 37536768 5 March 12:31 arch1_25673_669756456.arc
  -rw - r - 1 oracle dba 50753536 5 March 12:32 arch1_25674_669756456.arc
  -rw - r - 1 oracle dba 35850240 5 March 12:38 arch1_25675_669756456.arc
  -rw - r - 1 oracle dba 35854336 5 March 12:53 arch1_25676_669756456.arc
  -rw - r - 1 oracle dba 35875840 5 March 12:56 arch1_25677_669756456.arc
  -rw - r - 1 oracle dba 35873792 5 March 13:07 arch1_25678_669756456.arc
  -rw - r - 1 oracle dba 35852288 5 March 13:19 arch1_25679_669756456.arc

  Hi Grex,

  Refer to metalink Doc ID: 388627.1.

  HTH
  Anand

• What are the causes of archivedlog of size to be different from the size of the online redo log?

  11 GR 2 on RHEL 6.2

  4 GB is our size of Redo Log online.

  SQL > select bytes/1024/1024/1024 GB of log v$.

  GB

  ----------

  4

  4

  4

  4

  But the archive logs are 3.55 GB in size instead of 4 GB. Some of the archivelogs that are smaller than 3.55 below must be caused by

  Archive log backup RMAN offers jobs at 10:00, 16:00 and 22:00 that initiates log switching (I guess)

  SQL > select (blocks * block_size/1024/1024/1024) GB of v$ archived_log where status = 'A ';

  GB

  ----------

  3.55978966

  3.31046581

  3.55826092

  3.55963707

  1.39474106

  3.561553

  3.55736685

  3.55881786

  .135155678

  3.55546999

  .054887295

  1.88027525

  .078295708

  1.97425985

  3.55703735

  3.55765438

  .421986103

  3.55839968

  < snipped >

  It has something to do with the parameter FAST_START_MTTR_TARGET ? It is set to zero in this PB anyway.

  SQL > show parameter mtt

  VALUE OF TYPE NAME

  ------------------------------------ ----------- ------------------------------

  fast_start_mttr_target integer 0

  SQL >

  He could carry on public discussions and private discussions as Jonathan Lewis points out in the other discussion that Mihael provides a link to.

  It could concern the parameter archive_lag_target

  It could be the result of the BACKUP of RMAN commands

  It may be a programmed script / who commands ALTER SYSTEM ARCHIVE LOG of employment issues.

  Oracle can create an archivelog that is smaller than the redo log, if it isn't a switch or command before archive the redo log is full.

  Hemant K Collette

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

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

• 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 in Oracle RAC 11G

  Hello

  I work with oracle RAC 11gr2.0.3.

  We have an expectation to top event 'parallel log file reading', and other types of waiting as 'log sequential read', 'log file sync '...

  When I check the size of redo log = 50 M, while in the old database oracle 10 g 2 (no CARS), the size of redo log = 150 M.

  So, I want to know if I should increase our redo log in our Oracle RAC database, or not?

  Should be again small use connect oracle RAC, oracle RAC without difference?

  Thank you for your help.

  No matter the size, it is recommended to use at least 3 groups of newspapers by thread. This is particularly important if the archive log mode is activated.

  See you soon,.

  Brian

• Redo log sizing

  Hi all
  
  OEL 5.6
  
  Oracle 9.2.0.6
  
  Are just my recovery for his number and connects the size based on the delay time of switching? Thank you
  

  -rw-r--r-- 1 oraprod dba    10486272 Jan  3 23:24 log01a.dbf
  -rw-r--r-- 1 oraprod dba    10486272 Jan  3 23:24 log01b.dbf
  -rw-r--r-- 1 oraprod dba    10486272 Jan  3 23:09 log02a.dbf
  -rw-r--r-- 1 oraprod dba    10486272 Jan  3 23:09 log02b.dbf

  In the alerts log switching frequency:
  

  Beginning log switch checkpoint up to RBA [0x21186.2.10], SCN: 0x056e.66a6d05f
  Thread 1 advanced to log sequence 135558
    Current log# 1 seq# 135558 mem# 0: /u02/oracle/oaproddata/log01a.dbf
    Current log# 1 seq# 135558 mem# 1: /u02/oracle/oaproddata/log01b.dbf
  Thread 1 cannot allocate new log, sequence 135559
  Checkpoint not complete
    Current log# 1 seq# 135558 mem# 0: /u02/oracle/oaproddata/log01a.dbf
    Current log# 1 seq# 135558 mem# 1: /u02/oracle/oaproddata/log01b.dbf
  Wed Jan  2 20:37:01 2013
  Completed checkpoint up to RBA [0x21186.2.10], SCN: 0x056e.66a6d05f
  Wed Jan  2 20:37:01 2013
  Beginning log switch checkpoint up to RBA [0x21187.2.10], SCN: 0x056e.66a6d5e4
  Thread 1 advanced to log sequence 135559
    Current log# 2 seq# 135559 mem# 0: /u02/oracle/oaproddata/log02a.dbf
    Current log# 2 seq# 135559 mem# 1: /u02/oracle/oaproddata/log02b.dbf
  Thread 1 cannot allocate new log, sequence 135560
  Checkpoint not complete
    Current log# 2 seq# 135559 mem# 0: /u02/oracle/oaproddata/log02a.dbf
    Current log# 2 seq# 135559 mem# 1: /u02/oracle/oaproddata/log02b.dbf
  Wed Jan  2 20:37:07 2013
  Completed checkpoint up to RBA [0x21187.2.10], SCN: 0x056e.66a6d5e4
  Wed Jan  2 20:37:07 2013
  Beginning log switch checkpoint up to RBA [0x21188.2.10], SCN: 0x056e.66a6e3f2
  Thread 1 advanced to log sequence 135560
    Current log# 1 seq# 135560 mem# 0: /u02/oracle/oaproddata/log01a.dbf
    Current log# 1 seq# 135560 mem# 1: /u02/oracle/oaproddata/log01b.dbf
  Wed Jan  2 20:37:18 2013
  Thread 1 cannot allocate new log, sequence 135561
  Checkpoint not complete
    Current log# 1 seq# 135560 mem# 0: /u02/oracle/oaproddata/log01a.dbf
    Current log# 1 seq# 135560 mem# 1: /u02/oracle/oaproddata/log01b.dbf
  Wed Jan  2 20:37:18 2013
  Completed checkpoint up to RBA [0x21188.2.10], SCN: 0x056e.66a6e3f2
  Wed Jan  2 20:37:18 2013
  Beginning log switch checkpoint up to RBA [0x21189.2.10], SCN: 0x056e.66a6f0a4
  Thread 1 advanced to log sequence 135561
    Current log# 2 seq# 135561 mem# 0: /u02/oracle/oaproddata/log02a.dbf
    Current log# 2 seq# 135561 mem# 1: /u02/oracle/oaproddata/log02b.dbf
  Wed Jan  2 20:40:14 2013
  Completed checkpoint up to RBA [0x21189.2.10], SCN: 0x056e.66a6f0a4
  Wed Jan  2 20:40:53 2013
  Beginning log switch checkpoint up to RBA [0x2118a.2.10], SCN: 0x056e.66a70cb2
  Thread 1 advanced to log sequence 135562
    Current log# 1 seq# 135562 mem# 0: /u02/oracle/oaproddata/log01a.dbf
    Current log# 1 seq# 135562 mem# 1: /u02/oracle/oaproddata/log01b.dbf
  Wed Jan  2 20:43:24 2013
  Completed checkpoint up to RBA [0x2118a.2.10], SCN: 0x056e.66a70cb2

  And also I see frequently repeated ORA-1555 on the same statement in the alerts log, how can I avoid this?
  Is this cause also of small redo logs?
  

  Beginning log switch checkpoint up to RBA [0x211b2.2.10], SCN: 0x056e.70580afc
  Thread 1 advanced to log sequence 135602
    Current log# 1 seq# 135602 mem# 0: /u02/oracle/oaproddata/log01a.dbf
    Current log# 1 seq# 135602 mem# 1: /u02/oracle/oaproddata/log01b.dbf
  Wed Jan  2 21:26:14 2013
  Completed checkpoint up to RBA [0x211b2.2.10], SCN: 0x056e.70580afc
  Wed Jan  2 21:26:16 2013
  ORA-01555 caused by SQL statement below (Query Duration=2913 sec, SCN: 0x056e.66a6f853):
  Wed Jan  2 21:26:16 2013
   INSERT INTO RA_INTERFACE_ERRORS
   (INTERFACE_LINE_ID,
    MESSAGE_TEXT,
    INVALID_VALUE)
  SELECT
  INTERFACE_LINE_ID,
  :b_err_msg6,
  'trx_number='||T.TRX_NUMBER||','||'customer_trx_id='||TL.CUSTOMER_TRX_ID
  FROM RA_INTERFACE_LINES_GT IL, RA_CUSTOMER_TRX_LINES TL, RA_CUSTOMER_TRX T
  WHERE  IL.REQUEST_ID = :b1
  AND    IL.INTERFACE_LINE_CONTEXT = 'ORDER ENTRY'
  AND    T.CUSTOMER_TRX_ID =TL.CUSTOMER_TRX_ID
  AND  IL.INTERFACE_LINE_CONTEXT = TL.INTERFACE_LINE_CONTEXT
  AND IL.INTERFACE_LINE_ATTRIBUTE1 = TL.INTERFACE_LINE_ATTRIBUTE1
  AND IL.INTERFACE_LINE_ATTRIBUTE2 = TL.INTERFACE_LINE_ATTRIBUTE2
  AND IL.INTERFACE_LINE_ATTRIBUTE3 = TL.INTERFACE_LINE_ATTRIBUTE3
  AND IL.INTERFACE_LINE_ATTRIBUTE4 = TL.INTERFACE_LINE_ATTRIBUTE4
  AND IL.INTERFACE_LINE_ATTRIBUTE5 = TL.INTERFACE_LINE_ATTRIBUTE5
  AND IL.INTERFACE_LINE_ATTRIBUTE6 = TL.INTERFACE_LINE_ATTRIBUTE6
  AND IL.INTERFACE_LINE_ATTRIBUTE7 = TL.INTERFACE_LINE_ATTRIBUTE7
  AND IL.INTERFACE_LINE_ATTRIBUTE8 = TL.INTERFACE_LINE_ATTRIBUTE8
  AND IL.INTERFACE_LINE_ATTRIBUTE9 = TL.INTERFACE_LINE_ATT
  Wed Jan  2 21:26:22 2013
  Beginning log switch checkpoint up to RBA [0x211b3.2.10], SCN: 0x056e.7062ba10
  Thread 1 advanced to log sequence 135603
    Current log# 2 seq# 135603 mem# 0: /u02/oracle/oaproddata/log02a.dbf
    Current log# 2 seq# 135603 mem# 1: /u02/oracle/oaproddata/log02b.dbf
  Wed Jan  2 21:26:22 2013

  How can I configure management automatic cancellation in 9i?
  
  Thank you

  If UNDO_RETENTION has no impact on the ORA-01555 error, this error message you will get in this scenario?

  UNDO_RETENTION = 1800
  Query running time = 1900

  Works SQL and requires a block of data to read cancellation that has been updated there are 1900. Meanwhile, other users are using the system and the cancellation expired (anything above 1800) was crushed. User request will be error, and I would say that this will be an ORA-01555? Correct me if I'm wrong.

  As pointed out by bby Viswarayar Maran, your UNDO_RETENTION must be on the longer duration of the query. It's what he's there for. Yes, it can happen when you commit inside a loop, but it may happen in this case, too, I think.

  Actions:

  1 increase the size of REDO logs
  2. take another report statspack for the same period of time on a comparable day (in terms of workload, running processes, etc.) and see what it looks like

  Question: Your statspack report is from 22:00 - midnight, what are your pics to load? You have a working window batch during the night which is and then charge during the day? If so, we will need to look at this time for the statspack report, too.

• Restore the size of the log in Data Guard configurations

  DB version: 11.2
  Platform: Solaris 10
  
  We have currently a DB production which is not Dataguard.It has a load of joint working: some processing OLTP and batch.
  Its size of redo log is * 100 * MB.
  
  We will create a database with the requirement very similair but this DB will have primary standby (Data guard) and real time applies.
  
  To adapt to the requirements of dataguard, we should reduce the size of the recovery online newspapers? That is to say. Transport of small pieces of roll forward is better than carrying more. Right?

  Hello;

  If you use "real-time applies" the key is not the size so that the standby Redo Logs.

  In most cases, 100 MB is fine. Newspapers to sleep again must be the same size that it again.

  With 'real time applies' SRL act as a buffer.

  Unless you have a real problem with the size of do it again I would not change it.

  An excellent source of information on this is 'Restore the Services of Transport' in ' Data Guard Concepts and Administration 11 g Release 2 (11.2) "E10700-02".

  If you believe that your logs are too big departure "Troubleshooting performance problems with the database and base/MFG MRP [ID 100964.1]"

  Best regards

  mseberg

  Published by: mseberg on May 31, 2012 11:33

• How to resize Redo log groups

  Windows Server 2008 64 bit - Oracle 11g (11.02.0)
  
  We have our first oracle database implementation.
  The go live is supposed to happen in March or April.
  Our Oracle courses will begin next week, but because of the performance, I need to change the size of redo log groups.
  Users are just load data of the year 2010 in the database, but the performance is terrible.
  I would like to know if it is possible to do using the Manager of the company.
  I was able to modify the storage spaces and their files, but I don't succeed with redo log groups.
  I have 3 groups with 50 MB each. I would change the 500 MB each.
  When I try to change groups, it does not open the possibility of change.
  Do I have to stop the database? do I have to clean the Group? How can I change the size of them?
  
  Eduardo

  Hello

  As vmalepati says, you can't resize redo log groups.
  Create three new newspaper groups, with the size you need.
  As the database is through the loggroups, you will be able to drop the 'old' (small ones).

  (1) find the instance in OEM
  2) enter the tab "Server".
  (3) with the 'storage', press 'Redo log groups'
  (4) connect the database with a strong user
  (5) use the "create as.
  (6) change the size and all the other things you need and press "ok".
  (7) repeat 5 & 6 until you have the number of new redo log groups you need
  (8) remove the old redologs. Choose those showing "inactive".

  To force a logswitch, newspaper in sqlplus as user hard (System, for example) and run the command
  alter system switch logfile;

  Best regards
  Anders.

• Redo log size of the defect of EBS

  Hi all

  EBS R12.2.4

  11 GR 2

  Rhel6.5

  I noticed that the installation by dΘfaut of EBS has only two 1 GB size redo log groups.

  Is this acceptable to perform better?

  Your comment is very much appreciated.

  Thank you very much

  JC

  Protection for the primary database in three ways:

  Maximum availability: Transactions on the primary do not commit to redo information was written for the online redo log and newspapers awaiting restoration by progression of at least a place to sleep. If no location intelligence is available, it in the same way as the maximum performance mode until a standby is available again.
  Maximum performance: Transactions on the validation of primary as soon as redo information has been written for the online redo log. Transfer of information to roll forward to the standby server is asynchronous, so it has no impact on the performance of the primary.
  Maximum protection: the Transactions on the primary do not commit to redo information was written for the online redo log and newspapers awaiting restoration by progression of at least a place to sleep. If the standby not suitable location is available, the primary database stops.

  By default, a newly created Eve, the primary database is in maximum performance mode.

  I suggest to use the maximum performance with delay mode in the application of 15 minutes. You can drop the idea of delay if you are not comfortable with data loss

  concerning

  Pravin

• importance of the size of the Redo Log

  Hi guys,.

  What is the importance of the size of the size of Redlog?

  whether large or small size?

  Thanks in advance

  REDA

  What is the importance of the size of the size of Redlog?

  Setting up a database of Performance

  Manage the Redo Log

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

• 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