Redo Generation Rate

Hi,
I am having problem with the redo generation rate. The size of redo logfiles in my DB is 400MB and log switch happens approximately after every 10 min which i think is very fast interval comparing to the size of my redo logfiles. I have even checked the log miner settings but i did not find any problem with it.
SQL> select SUPPLEMENTAL_LOG_DATA_MIN,SUPPLEMENTAL_LOG_DATA_PK,SUPPLEMENTAL_LOG_DATA_UI from v$database;
SUP SUP SUP
NO NO NO
Plz can anyone tell me what is wrong with the redo generation rate?

First of all, it simply means your system is doing lots of work(generating 400MB redo per 10 minutes), well if you have work to do you need to do it. Besides, 400MB per 10 minutes is not that big for some busy system. So killing sessions may not be a good idea, your system just has so much work to do. If you have millions of rows need to be loaded, you just have to do it.
Secondly, you many query v$sesstat for statistics name called "redo size" periodically (i.e. every 10 minutes) and get some idea when these happen during the day period. And user SQL_TRACE to get those SQL statements in the tkprof trace report, find out if you can optimize SQL to generate less redo, or other alternative ways. Some common options to minimize redo :
insert /*+ append */ hint
create table as (select ...)
table nologging
if updating millions of rows, can it be dont by creating new tables
is it possible to use temp table feature (some applications use permanant tables but indeed they can use temp table)
Anyway, you have to know what your database is doing while generating tons of redo. Until you find out what SQLs are generating the large redo, you can not solve the problem at system level by killing sessions or so.
Regards,
Jianhui

Similar Messages

Question about redo generation

select * from v$version;
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
PL/SQL Release 11.2.0.1.0 - Production
"CORE     11.2.0.1.0     Production"
TNS for Linux: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - ProductionSetup for test
create table parent_1 (id number(12) NOT NULL);
alter table parent_1 add constraint parent_1_pk primary key (id);
create table parent_2 (id number(12) NOT NULL);
alter table parent_2 add constraint parent_2_pk primary key (id);
create table child_table (ref_id number(12) NOT NULL,ref_id2 number(12) NOT NULL, created_at timestamp(6));
alter table child_table add constraint child_table_pk primary key (ref_id, ref_id2);
alter table child_table add constraint child_table_fk1 foreign key (ref_id) references parent_1(id);
alter table child_table add constraint child_table_fk2 foreign key (ref_id2) references parent_2(id);
insert into parent_1 select rownum from all_objects;
insert into parent_2 values (1);
insert into parent_2 values (2);
insert into child_table (select id, 1, systimestamp from parent_1);
insert into child_table (select id, 2, systimestamp from parent_1);
commit;Code version 1:
declare
   type t_ids is table of NUMBER(12);
   v_ids t_ids;
   start_redo NUMBER;
   end_redo NUMBER;
cursor c_data is SELECT id FROM parent_1;
begin
   select value into start_redo from v$mystat where statistic# = (select statistic# from v$statname where name like 'redo size');
   open c_data;
   LOOP
    FETCH c_data
    BULK COLLECT INTO v_ids LIMIT 1000;
    exit;
   end loop;
CLOSE c_data;
    for pos in v_ids.first..v_ids.last LOOP
BEGIN
    insert into child_table values (v_ids(pos), 2, systimestamp);
    EXCEPTION
      WHEN DUP_VAL_ON_INDEX THEN
        update child_table set created_at = systimestamp where ref_id = v_ids(pos) and ref_id2 = 2;
END;
END LOOP;
end;
/Version 2:
declare
   type t_ids is table of NUMBER(12);
   v_ids t_ids;
   start_redo NUMBER;
   end_redo NUMBER;
cursor c_data is SELECT id FROM parent_1;
ex_dml_errors EXCEPTION;
PRAGMA EXCEPTION_INIT(ex_dml_errors, -24381);
pos NUMBER;
l_error_count NUMBER;
begin
   select value into start_redo from v$mystat where statistic# = (select statistic# from v$statname where name like 'redo size');
   open c_data;
   LOOP
    FETCH c_data
    BULK COLLECT INTO v_ids LIMIT 1000;
    exit;
   end loop;
CLOSE c_data;
BEGIN
    FORALL i IN v_ids.first .. v_ids.last SAVE EXCEPTIONS
    insert into child_table values (v_ids(i), 2, systimestamp);
EXCEPTION
    WHEN ex_dml_errors THEN
      l_error_count := SQL%BULK_EXCEPTIONS.count;
      FOR i IN 1 .. l_error_count LOOP
        pos := SQL%BULK_EXCEPTIONS(i).error_index;
        update child_table set created_at = systimestamp where ref_id = v_ids(pos) and ref_id2 = 2;
      END LOOP;
END;
   select value into end_redo from v$mystat where statistic# = (select statistic# from v$statname where name like 'redo size');
dbms_output.put_line('Created redo : ' || (end_redo-start_redo));
end;
/Version 1 output:
Created redo : 682644
Version 2 output:
Created redo : 7499364
Why is version 2 generating significant more redo ?

As both pieces of code erroneously replace non-procedural code by procedural code, ignoring the power of a RDBMS to process sets, and are examples of slow by slow programming,
both pieces of code are undesirable, so the difference in redo generation doesn't matter.
Sybrand Bakker
Senior Oracle DBA

High REDO Generation for enqueue and dequeue

Hi,
We have found high redo generation while enqueue and dequeue. Which is in-turn affecting our database performance.
Please find a sample test result below :
Create the Type:-
CREATE OR REPLACE
type src_message_type_new_1 as object(
no varchar(10),
title varchar2(30),
text varchar2(2000))
Create the Queue and Queue Table:-
CREATE OR REPLACE procedure create_src_queue
as
begin
DBMS_AQADM.CREATE_QUEUE_TABLE
(queue_table => 'src_queue_tbl_1',
queue_payload_type => 'src_message_type_new_1',
     --multiple_consumers => TRUE,
     compatible=>10.1,
     storage_clause=>'TABLESPACE EDW_OBJ_AUTO_9',
comment => 'General message queue table created on ' ||
TO_CHAR(SYSDATE,'MON-DD-YYYY HH24:MI:SS'
     commit;
DBMS_AQADM.CREATE_QUEUE
(queue_name => 'src_queue_1',
queue_table => 'src_queue_tbl_1',
comment => 'Test Queue Number 1'
     commit;
dbms_aqadm.start_queue
('src_queue_1');
     commit;
end;
Redo Log Size:-
select
n.name, t.value
from
v$mystat t join
v$statname n
on
t.statistic# = n.statistic#
where
n.name = 'redo size'
Output:-
595184
Enqueue Message into the Queue Table:-
CREATE OR REPLACE PROCEDURE enque_msg_ab
as
queue_options DBMS_AQ.ENQUEUE_OPTIONS_T;
message_properties DBMS_AQ.MESSAGE_PROPERTIES_T;
message_id raw(16);
my_message dev_hub.src_message_type_new_1;
begin
my_message:=src_message_type_new_1(
'1',
'This is a sample message',
'This message has been posted on');
DBMS_AQ.ENQUEUE(
queue_name=>'dev_hub.src_queue_1',
enqueue_options=>queue_options,
message_properties=>message_properties,
payload=>my_message,
msgid =>message_id);
commit;
end;
Redo Log Size:-
select
n.name, t.value
from
v$mystat t join
v$statname n
on
t.statistic# = n.statistic#
where
n.name = 'redo size'
Output:-
596740
Can any one tell us the reason for this high redo generation and how can this can be controlled?
Regards,
Koushik

Please find my answers below :
What full version of Oracle?
- 10.1.0.5
How large is the average message?
- in some byets only, at max 1-2 KB and not more than this.
What kind of performance problem is 300G of redo causing? How? Have you ran a statspack report? What did it show?
- Actually we are facing some performance issue as a overall prespective for our daily batch processing, which now causing a delay in the batch SLA. So we have produced an AWR report for our database and from there we have found that total redo generation is around 400 GB, amoung which 300 GB has been generated by enqueue-dequeue process.
What other activity is taking place on this instance? That is, is all this redo really being generated as the result of the AQ activity or is some of it the result of the messages being processed? How are the messages created?
- Normal batch process everyday. Batch process also generates REDO but the amount is low compare to enqueue-dequeue process.
Have you looked at providing a separate physical disk stripe for the online redo logs and for the archive log location from the database data file physical disk and IO channels?
- No, as we are not the production DBA so we don't have the direct access to production database.
What kind of file system and disk are you using?
- I am not sure about it. I will try to confirm it by production DBA. Is there any other way to find it out, whether it is on filesystem or raw device?
Can you please provide any help in this topic.
Regards,
Koushik

Excessive Redo Generation After Upgrading on Oracle 10gR2

We had our production database hosted on Oracle 9.2.0. Few months back we have migrated it to Oracle 10.2.0.4.0.
After Migration I have noticed that redo generation has become very very high. In earlier case no. of log files generating in production hours were around 20 where as after migration it become around 200 files per day. I have run statspack report on this database. Statspack report is also saying that log file switch wait is become very high. Parameter timed_statistics has also been set to FALSE. Workload on the database is same before & after upgrade. Queries running in the sessions are also same before & after upgrade. All the parameters & memory structures are same after upgrade. Satatpack report is saying that db block change & disk write is become very high. I had used import export for upgrading the databases. Please provide a solution for this problem.
Thanks In advance for all your favours....

Hi;
Please check below notes which could be helpful for your issue:
Diagnosing excessive redo generation [ID 199298.1]
Excessive Archives / Redo Logs Generation Troubleshooting [ID 832504.1]
Troubleshooting High Redo Generation Issues [ID 782935.1]
How to Disable (Temporary) Generation of Archive Redo Log Files [ID 177218.1]
Regard
Helios

Reducing REDO generation from a current data refresh process

Hello,
I need to resolve an issue where a schema database is maintained with one delete followed by a tons of bulk insert. The problem is that the vast majority of deleted rows are reinserted as is. This process deletes and reinserts about 1 175 000 rows of data!
The delete clause is:
- delete from table where term >= '200705';
The data before '200705' is very stable and doesn't need to be refreshed.
The table is 9 709 797 rows big.
Here is an excerpt of cardinalities for each term code:
TERM      NB_REGS
200001     117130
200005      23584
200009     123167
200101     115640
200105      24640
200109     121908
200201     117516
200205      24477
200209     125655
200301     120222
200305      26678
200309     129541
200401     123875
200405      27283
200409     131232
200501     124926
200505      27155
200509     130725
200601     122820
200605      27902
200609     129807
200701     121121
200705      27699
200709     129691
200801     120937
200805      29062
200809     130251
200901     122753
200905      27745
200909     135598
201001     127810
201005      29986
201009     142268
201101     133285
201105      18075This kind of operation is generating a LOT of redo logs: on average 25 GB per days.
What are the best options available to us to reduce redo generation without changing to much the current process?
- make tables in no logging ? (with mandatory use of append hint?)
- use of a global temporary table for staging and merging against the true table?
- use of partitions and truncate the reloaded one? this not reduce redo generated by subsequent inserts...?
This has not to be mandatory transactionnal.
We use 10gR2 on Windows 64 bits.
Thanks
Bruno

yes, you got it, these are terms (Summer of 2007, beginning at May).
Is the perverse effect of truncating and then inserting in direct path mode pushing the high water mark up day after day while having unused space in truncated partitions? Maybe we should not REUSE STORAGE on truncation...
this data can be recovered easily from the datamart that pushes this data, this means we can use nologging and direct path mode without any «forever loss» of data.
Should I have one partition for each term, or having only one for the stable terms and one for the refreshed terms?

Redo generation high

Hi,
We have a problem with redo generation. Last few days,redo generation is high than normal.No changes in application level.I don't know where to start.I tried to compare AWR report.But i did not get.
1,Is it possilbe to find How much redo generated for a DML statement by Segment wise(table segment,index segment) when it's executed?
For Ex : The table M_MARCH has 19 colums and 6 indexes.Another tables M_Report has 59 columns and 5 indexes.the query combines both tables.
We need to find whether indexex are really is usable or not?
2,Is there any other way to reduce redo geneation?
Br,
Rajesh

High redo generation can be of two types:
1. During a specific duration of the day.
2. Sudden increase in the archive logs observed.
In both the cases, first thing to be checked is about any modifications done either at the database level(modifying any parameters, any maintenance operations performed,..) and application level (deployment of new application, modification in the code, increase in the users,..).
To know the exact reason for the high redo, we need information about the redo activity and the details of the load. Following information need to be collected for the duration of high redo generation.
1] To know the trend of log switches below queries can be used.
SQL> alter session set NLS_DATE_FORMAT='DD-MON-YYYY HH24:MI:SS'; Session altered. SQL> select trunc(first_time, 'HH') , count(*)   2 from   v$loghist   3 group by trunc(first_time, 'HH')   4 order by trunc(first_time, 'HH');   TRUNC(FIRST_TIME,'HH   COUNT(*) -------------------- ---------- 25-MAY-2008 20:00:00          1 26-MAY-2008 12:00:00          1 26-MAY-2008 13:00:00          1 27-MAY-2008 15:00:00          2 28-MAY-2008 12:00:00          1 <- Indicate 1 log switch from 12PM to 1PM. 28-MAY-2008 18:00:00          1 29-MAY-2008 11:00:00         39 29-MAY-2008 12:00:00        135 29-MAY-2008 13:00:00        126 29-MAY-2008 14:00:00        135 <- Indicate 135 log switches from 2-3 PM. 29-MAY-2008 15:00:00        112
We can also get the information about the log switches from alert log (by looking at the messages 'Thread 1 advanced to log sequence' and counting them for the duration), AWR report.
1] If you are in 10g or higher version and have license for AWR, then you can collect AWR report for the problematic time else go for statspack report.
a) AWR Report
-- Create an AWR snapshot when you are able to reproduce the issue: SQL> exec DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT ();   -- After 30 minutes, create a new snapshot: SQL> exec DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT (); -- Now run $ORACLE_HOME/rdbms/admin/awrrpt.sql
b) Statspack Report
SQL> connect perfstat/<Password> SQL> execute statspack.snap; -- After 30 minutes SQL> execute statspack.snap; SQL> @?/rdbms/admin/spreport
In the AWR/Statspack report look out for queries with highest gets/execution. You can check in the "load profile" section for "Redo size" and compare it with non-problematic duration.
2] We need to mine the archivelogs generated during the time frame of high redo generation.
-- Use the DBMS_LOGMNR.ADD_LOGFILE procedure to create the list of logs to be analyzed:     SQL> execute DBMS_LOGMNR.ADD_LOGFILE('<filename>',options => dbms_logmnr.new); SQL> execute DBMS_LOGMNR.ADD_LOGFILE('<file_name>',options => dbms_logmnr.addfile); -- Start the logminer SQL> execute DBMS_LOGMNR.START_LOGMNR(OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG);       SQL> select operation,seg_owner,seg_name,count(*) from v$logmnr_contents group by seg_owner,seg_name,operation;
Please refer to below article if there is any problem in using logminer.
Note 62508.1 - The LogMiner Utility
We can not get the Redo Size using Logminer but We can only get user,operation and schema responsible for high redo.
3] Run below query to know the session generating high redo at any specific time.
col program for a10 col username for a10 select to_char(sysdate,'hh24:mi'), username, program , a.sid, a.serial#, b.name, c.value from v$session a, v$statname b, v$sesstat c where b.STATISTIC# =c.STATISTIC# and c.sid=a.sid and b.name like 'redo%' order by value;
This will give us the all the statistics related to redo. We should be more interested in knowing "redo size" (Total amount of redo generated in bytes)
This will give us SID for problematic session.
In above query output look out for statistics against which high value is appeared and this statistics will give fair idea about problem.

Redo Generation in DDL

I am using oracle 9i and windows xp professional.I enabled autotrace for scott user. Now when i issue select, insert, update,delete it is showing me statistics, but when i issue ALTER TABLE y ADD (XYZ NUMBER(1)); it did'nt give me any statistics. What does it mean:-
1. DDLs do not generate REDO.
2. What to do to get the statistics of every command ?
Thanks & Regards

Hello Sir,
1. alter session set sql_trace=true;
2. DMLs are not showing me information about redo generation
3. set autotrace traceonly statistics; now it is showing statistics.
but i wish to get the information regarding redo generated by DDLs. How ? I mean how much redo generated by DDL.
Thanks
I issued set autotrace traceonly statistics;

Append hint redo generation

Hi,
My question is about redo generation when using append hint . i have a database which is in FORCE loggind mode for standby database.if i use append hint , will it generate any redo ? i wonder will the standby db be same as primary after append hint usage ?
thanks.

Hi,
thanks for answer.
the sentence says
"if the database is in ARCHIVELOG and FORCE LOGGING mode, then direct-path SQL generate data redo for both LOGGING and NOLOGGING tables." . This is my case.
i have opened archive_log with dbms_logmnr but i could not find any redo . So i wonder standby db will not be in synchronize with primary ?
thanks.

Partition table vs redo generation

Hi all,
I'm working with an enterprise 10.2.0.5 Oracle database
I've a huge partitioned table and I'm interested in generate subpartitions.
My question is if this process (create this subpartitions) will generate more redo or undo.
Thanks,
dbajug

If you are only adding new, empty, SubPartitions, the redo generation will be minimal. If and when you load data into these SubPartitions, you will notice undo and redo generation, depending on how the data is loaded.
If you SPLIT a non-empty Partition, Oracle has to "move" rows into the newly created partition. This will generate undo and redo.
What you should do is to run a few tests of your planned actions and monitor the volume of undo and redo generated.
Hemant K Chitale

Redo Log Generation Rate is more as compaired to Single Instacne

Hi Experts,
i need views regarding the experience that i m facing in rac environment. actually we have two node rac 10gr2 running on AIX 6.1
on application side we have a process of 4 hrs and during this process we observed average 110 Gb of logs. but if we run same process on application and single instance DB is being used at back end, then it generates only 40Gb of log. now my question is why same process have different redo log generation values against rac db and single instacne.

Amiabu,
Your question calls for crystal balls, as you have provided way too few details.
Also you didn't use Logminer to find out what is going on. This would have been a sensible approach, even before posting a question which can be paraphrased as 'It doesn't work as expected, why?'.
Two general observations:
if your code doesn't scale, using RAC will make things worse.
Oracle 10g is a heavily instrumented product, assuming you use AWR or ADDM or statspack.
The Cache Fusion feature of RAC can easily result in extra wait events, which in turn are being tracked (INSERTed that is) in the AWR or statspack repository.
Only you can answer the question what was going on by using Logminer.
Sybrand Bakker
Senior Oracle DBA
Edited by: sybrand_b on 16-jun-2011 14:33

High redo generation causing outage to Application

Hi All,
Recently we encountered severe performance issues on one of our mission critical database. The issue was with the database not able to cope up with the amount of redo generated by the application sessions and waited on "checkpoint not complete". We also observed lots of these Deadlocks which are application related errors.
We are very much aware there's an issue with the application function, and the dev team is already working on a fix for these deadlocks. We observed whenever we see these deadlocks database comes to a halt with database taking lots of time to rotate the redo log. We found there's something wrong with the application sessions generating higher redo than normal causing this whole mess. The application sessions run several of these DMLS at relatively shorter time which we were not able to track down specific session which is causing this.
Is there anyway we get find from AWR tables which database session is causing high amount of redo at a specific point in time in the past.
As a workaround we have increased the redo logs and size to overcome the database halt momentarily. But any help to identify the sessions generating high redo, would be very helpful.
These are the error messages seen in the alert log, when database stalls.
Checkpoint not complete
Current log# 5 seq# 70865 mem# 0: /u03/oradata/HUGGES/redo05.rdo
Thu Feb 16 15:57:58 2012
Thread 1 advanced to log sequence 70866 (LGWR switch)
Current log# 6 seq# 70866 mem# 0: /u03/oradata/HUGGES/redo06.rdo
Thu Feb 16 15:58:09 2012
Archived Log entry 143629 added for thread 1 sequence 70865 ID 0x2cd18321 dest 1:
Thu Feb 16 15:58:11 2012
ORA-00060: Deadlock detected. More info in file /opt/oracle/diag/rdbms/SATTLE/HUGGES/trace/HUGGES_ora_25643.trc.
Thu Feb 16 15:58:17 2012
ORA-00060: Deadlock detected. More info in file /opt/oracle/diag/rdbms/SATTLE/HUGGES/trace/HUGGES_ora_28266.trc.
Thu Feb 16 15:58:20 2012
ORA-00060: Deadlock detected. More info in file /opt/oracle/diag/rdbms/SATTLE/HUGGES/trace/HUGGES_ora_5220.trc.
Thanks,
Sen

tkyte wrote:
But from what is observed is Deadlock is just a symptom we are seeing on the database with the root cause being something/some sessions which is running inside the database causing this havoc.
by what logic do you make that claim?
A deadlock is a symptom of an application error - sure, but it is not just a symptom of your extra redo log generation.
In fact, as someone pointed out above, it is the likely culprit of your extra redo log generation. When you are deadlocking you are rolling back at least one statement - if not likely the entire transaction. Which in turn will modify data blocks (the same ones you just modified to get into the deadlock) and generate undo themselves.Tom,
I think the point the OP is trying to make is that there are some session which are updating far more rows than they should be, and when several sessions do this they increase the probability that they deadlock each other because each session tries to update rows that only the other sessions should be updating.
To the OP -
If my interpretation of your comments is correct then you should be able to see the colliding (and, according to my interpretation, erroneous) statements in the deadlock trace files.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
Author: <b><em>Oracle Core</em></b>

Excessive redo generation in Production DB?

my production database is generation lot of redo's since one month.Nearly 45 redo's its archiving per hour.b4 it use to generate 2 redo's per hour.The size of redolog file is 300M and we are having 3 redogroups.I want to know what is causing this much of redo to generate as system is same as before it is one month back.from where and how i have to start the invistigation.
Thankx...

Hello,
can you check if your tablespaces are in backup mode ?
for example like this:
select a.name, b.status from v$datafile a, v$backup b
where a.file# = b.file#;
does it say "ACTIVE" for any of the files ?

Expdp impdp - redo generation?

Friends...
Oracle 11gr2 SE
OS: Linux
I did tried to search in documentation but couldn't find answer.
I'm dropping some tables but before that exporting them for backup, db is in archivelog mode.
Before dropping tables, trying to find whether expdp job generates lots of redo or not since file system only have 20 GB of free space.
Question.
1. If I'm performing expdp of some tables with the size of 80 GB (table size.. index not included), does expdp will generate similar amount of redo or will it generate lots of redo?
2. Does impdp job also generate lots of redo or only during index creation in impdp?
thanks,
Mike

Export do NOT generate any redo. It's just dumping data into files in binary format. Very minimal redo just to maintain data export dump table but very very minimal. IF I have to guess no more than 1 MB.
Import does generate redo logs. Imports run 'Insert' statement behind the scenes and it does generate lot of redo logs. You can use sqlfile to create index definition and than run it manually with NOLOGGING which will reduce some redo. something like
impdp user/password exclude=indexes -- this will import everything but indexes.
impdp user/password include=index sqlfile=index.sql -- this will create a file called index.sql that will contain all of the create statements for the indexes

Why do we need standby redo log on Primary database.

Hi Gurus,
I was going through the document in OBE,
http://www.oracle.com/technology/obe/11gr1_db/ha/dataguard/physstby/physstdby.htm
I have two queries:
1) I noticed the statement -
"Configure the primary database to receive redo data, by adding the standby logfiles to the primary. "
Why do we have to create standby redo log on a primary database?
2) There is another statement --
"It is highly recommended that you have one more standby redo log group than you have online redo log groups as the primary database. The files must be the same size or larger than the primary database’s online redo logs. "
Why do we need one additional standby redo log group than in Primary database.
Could anyone please explain to me in simple words.
Thanks
Cherrish Vaidiyan

Hi,
1. Standby redo logs are used only when the database_role is standby, it is recommended to be added in primary also so that they can be used on role reversal, however during normal working standby redo logs will not be used at all on primary.
2. In case of 3 online redo log groups, it is recommended to use 4 standby redo log group this is in case if log switching is happening frequently on primary and all 3 standby redo logs are still not completely archived on the standby and 4th can be used here as there will be some delay on standby due to network or slowness of arch on standby.
Use of the standby redo log groups depends on the redo generation rate, you can see only 2 standby redo logs are getting used while you have 4 standby redo log groups, when the redo generation rate is less.
So it is recommended to have one more standby redo log group when redo generation rate is high and all of the existing standby redo log group are getting used.
Regards
Anudeep

Exadata redo

Hi, I need advice here.
I created databases on our x3 full rac environment. DB version is 11204.
I did a exachk, and it shows this warning:
The database machine provides extremely high redo generation rates that may make you consider increasing the log file sizes. Following initial deployment, the online log file sizes should be 4GB each.
My current redo log size is 1g, old non-exadata rac envrionment redo log size is 500m.
This environment has huge data, and a lot OLTP plus query , so it is kind of mix environment.
How do I be sure the redo log size is optimal and where should I place the redo logs? On what kind of disks? flash disk or regular disks?
THanks in advance.

Hello user569151,
The key question here is: what is your redo generation rate currently? How frequently are you switching your 1.5GB log files at peak?
As for placement, I generally suggest putting them on rotating disk, especially with the advent of smart flash logging.
Marc

Redo Generation Rate

Similar Messages

Maybe you are looking for