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>

Tags: Database

Similar Questions

  • 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

  • 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

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

  • 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

  • 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

  • Redo Log Buffer 32.8 M, looks great?

    I just took on a database (mainly used for OLTP on 11 GR 1 matter) and I'm looking at the level of the log_buffer parameter on 34412032 (32.8 M). Not sure why it is so high.
    select 
    NAME, 
    VALUE
from 
    SYS.V_$SYSSTAT
where 
    NAME in ('redo buffer allocation retries', 'redo log space wait time');

redo buffer allocation retries     185
redo log space wait time          5180
    (database was for 7.5 days)

    Any advice on that? I normally keep trying to stay below 3 m and have not really seen it above 10 M.

    Sky13 wrote:
    I just took on a database (mainly used for OLTP on 11 GR 1 matter) and I'm looking at the level of the log_buffer parameter on 34412032 (32.8 M). Not sure why it is so high.

    11g, you should not set the log_buffer - only Oracle default set.

    The value is derived relative to the setting for the number of CPUS and the transaction parameter, which can be derived from sessions that can be derived processes. In addition, Oracle will allocate at least one granule (which can be 4, 8 MB, 16 MB, 64 MB, or 256 MB depending on the size of the SGA, then you are not likely to save memory by reducing the size of the log buffer.

    Here is a link to a discussion that shows you how to find out what is really behind this figure.
    Re: Archived redo log size more than online redo logs

    Concerning
    Jonathan Lewis
    http://jonathanlewis.WordPress.com
    Author: core Oracle

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

  • 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

  • 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

  • Separate ASM diskgroup Online redo logs

    Version: 11.2.0.3

    Platform: Solaris 10

    One of the guys support Hitachi suggested to create a group of separate drives for the online redo logs. His reasoning was that ORLs was writing only the files and it would be better to put into a group of separate disk.

    What do you think guys?

    Tom wrote:

    Version: 11.2.0.3

    Platform: Solaris 10

    One of the guys support Hitachi suggested to create a group of separate drives for the online redo logs. His reasoning was that ORLs was writing only the files and it would be better to put into a group of separate disk.

    What do you think guys?

    Well, one additional DG would require additional disks.  Hmm.  And who is the seller who would be purchased these discs?

    I guess that in a situation of extreme performance, there may be some merit in placing redo it online on a separate ASM disk group so that the underlying disks could be managed in a higher priority of the Hitachi (?) SAN.  But that would only be justified if written again online has been the major bottleneck in your system.

  • Increased repository DB redo logging after upgrade EM12cR2?

    Has anyone else noticed increased redo logging in their repository database after upgrade to EM12cR2?

    I'm running on Linux x 86-64 with a 11.2.0.3 repository database. Before the upgrade, I was running 12.1.0.1.0 with BP1, and my repository database produced, on average, about 80-120 MB of archived redo logs / hour. Since the upgrade to 12.1.0.2.0, my product repository database, on average, 450-500 MB of newspapers archived redo / hour.

    Reclassification of deployed agents of 12.1.0.1.0 to 12.1.0.2.0 has not seemed to help; I've updated about 10 of the 15 without any apparent loss of logging of redo.

    I was wondering if it's comparable to what others see, or if I have a local question I should study.

    The following fix has been released for this problem:

    Patch 14726136 - INCREASED REDO LOGGING ON REPOSITORY DB AFTER UPGRADING TO OEM 12.1.0.2

    Kind regards
    Vincent

  • 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

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

  • How do I know if there's bottleneck in the redo logs?

    Hi all

    EBS R12.2

    11 GR 2

    OL 6.5

    We have two groups of log of size 1 GB.

    and oyour archiving logs generates 13 newspapers every hour.

    -rw - r-. 1 oraprod s/n 956896768 Jan 25 14:00 1_3372_898613761.dbf

    -rw - r-. 1 oraprod s/n 1004083200 Jan 25 14:03 1_3373_898613761.dbf

    -rw - r-. 1 oraprod s/n 928530432 Jan 25 14:10 1_3374_898613761.dbf

    -rw - r-. 1 oraprod s/n 928728576 Jan 25 14:12 1_3375_898613761.dbf

    -rw - r-. 1 oraprod s/n 967805952 Jan 25 14:20 1_3376_898613761.dbf

    -rw - r-. 1 oraprod s/n 916065792 Jan 25 14:22 1_3377_898613761.dbf

    -rw - r-. 1 oraprod s/n 951790592 Jan 25 14:30 1_3378_898613761.dbf

    -rw - r-. 1 oraprod s/n 978358272 Jan 25 14:32 1_3379_898613761.dbf

    -rw - r-. 1 oraprod s/n 974519808 Jan 25 14:40 1_3380_898613761.dbf

    -rw - r-. 1 oraprod s/n 960421376 Jan 25 14:42 1_3381_898613761.dbf

    -rw - r-. 1 oraprod s/n 917438976 Jan 25 14:49 1_3382_898613761.dbf

    -rw - r-. 1 oraprod s/n 920794624 Jan 25 14:51 1_3383_898613761.dbf

    -rw - r-. 1 oraprod s/n 920704000 Jan 25 14:59 1_3384_898613761.dbf

    I got this alert saves messages:

    Mon Jan 25 15:08:37 2016

    Filled checkpoint up to RBA [0xd3b.2.10], RCS: 5978324588151

    Mon Jan 25 15:10:57 2016

    Thread 1 cannot allot of new newspapers, sequence 3388

    Private stream flush is not complete

    Currently journal # 1, seq # 3387 mem # 0: /home/oraprod/PROD/data/log01a.dbf

    Currently journal # 1, seq # 3387 mem # 1: /home/oraprod/PROD/data/log01b.dbf

    Beginning log switch checkpoint up to RBA [0xd3c.2.10], RCS: 5978324634623

    Thread 1 Advanced for you connect to sequence 3388 (switch LGWR)

    Currently Journal # 2 seq # 3388 mem # 0: /home/oraprod/PROD/data/log02a.dbf

    Currently Journal # 2 seq # 3388 mem # 1: /home/oraprod/PROD/data/log02b.dbf

    Mon Jan 25 15:11:01 2016

    LNS: Standby redo log file selected for thread 1 sequence 3388 for destination LOG_ARCHIVE_DEST_2

    Mon Jan 25 15:11:04 2016

    Archived journal 6791 extra for each sequence 1 3387 ID thread entry 0 x 12809081 dest 1:

    Mon Jan 25 15:11:17 2016

    Filled checkpoint up to RBA [0xd3c.2.10], RCS: 5978324634623

    Mon Jan 25 15:13 2016

    Additional checkpoint up to RBA to RBA [0xd3c.1a8e82.0] [0xd3c.18d210.0], current journal line

    Mon Jan 25 15:13:04 2016

    Thread 1 cannot allot of new newspapers, sequence 3389

    Private stream flush is not complete

    Currently Journal # 2 seq # 3388 mem # 0: /home/oraprod/PROD/data/log02a.dbf

    Currently Journal # 2 seq # 3388 mem # 1: /home/oraprod/PROD/data/log02b.dbf

    Beginning log switch checkpoint up to RBA [0xd3d.2.10], RCS: 5978324673444

    Thread 1 Advanced for you connect to 3389 (switch LGWR) sequence

    Currently journal # 1, seq # 3389 mem # 0: /home/oraprod/PROD/data/log01a.dbf

    Currently journal # 1, seq # 3389 mem # 1: /home/oraprod/PROD/data/log01b.dbf

    Mon Jan 25 15:13:07 2016

    LNS: Standby redo log file selected for thread 1 sequence 3389 for destination LOG_ARCHIVE_DEST_2

    Mon Jan 25 15:13:09 2016

    Archived journal 6793 extra for each sequence 1 3388 ID thread entry 0 x 12809081 dest 1:

    Mon Jan 25 15:13:11 2016

    Filled checkpoint up to RBA [0xd3d.2.10], RCS: 5978324673444

    Is it a sign of botteneck? Users complained that each 15:00 they encounter performance degradation.

    Kind regards

    JC

    Jenna_C wrote:

    We have two groups of size 1 GB log and our archiving logs generates 13 newspapers every hour.

    Is it a sign of botteneck? Users complained that each 15:00 they encounter performance degradation.

    If your users are complaining about slow at 15:00 then look at what is happening on the system at this point in time.  Use the Active Session history, providing that you have the license, at 3 pm to see if there is a problem.  Or take snapshots of the AWR manually around 15:00 in an attempt to capture any anomaly.  Or capture instant V$ SESSION yourself manually around 15:00 and see so many sessions is pending or not.

    I have seen problems like this on shared physical infrastructure systems where the activity on a system can interfere with each other.  Attention to this kind of thing, because if it is caused by another system then you will never find the cause of the problem inside the Oracle.  Examples include backups are made at a specific time, causing large amounts of sequential disk i/o and slows down access to the drive for everything else.  Such a scenario could cause some writing redo log time to increase significantly.  Or the backup could be another system completely who shares the same disks in the same drive bay or the SAN and Bay drives or SAN is inundated by applications e/s backup.  But as it's another system, that you will not see what is happening on your Oracle database system.

    Or a virtualized with environment sharing CPU and memory where another virtual machine running a CPU intensive job and steals the Oracle system CPU capacity.  I saw the same thing with memory so - Vmware has a strange way to virtualize memory, which means it can use all of the memory on the physical hardware and run out, and then he had to intervene to release somehow little memory.  What ends up slowing things down.

    It could be a network problem - is something that the network of the floods at 15:00?  Still, backups can be a common cause of this, during the transfer of data over the network to another system.  Is there a work extracted regularly data which runs at 15:00 for example extract given OLTP to feed into a data warehouse, which is copied on the network?

    It could be many different things, causing the slowdown.  I would definitely recommend watching any expected sessions know and see if this gets worse around 15:00, or if it remains the same, in which case the problem is elsewhere.  You must also eliminate everything else - the disks, network, etc.

    Good luck

    John Brady

Maybe you are looking for