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>

Similar Messages

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

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.

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

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

WHAT CAUSES FOR AN APPLICATION TO FREEZE DURING INSTALL?

What causes for an application to freeze during install? and how do I fix it

helloWorld pretty much said it all.
When I'm looking for problems like that nothing beats a good trace file. Also don't dismiss the idea of programmer stupidity (of the one that developed the app), I've ran across code where exceptions where caught and nothing done about it, just let thing run merrily along again. The cause is usually farther back in the trace than the point it hangs or appears to start having problems.

High redo log space wait time

Hello,
Our DB is having very high redo log space wait time :
redo log space requests 867527
redo log space wait time 67752674
LOG_BUFFER is 14 MB and having 6 redo logs groups and the size of redo log file is 500MB for each log file.
Also, the amount of redo generated per hour :
START_DATE START NUM_LOGS MBYTES DBNAME
2008-07-03 10:00 2 1000 TKL
2008-07-03 11:00 4 2000 TKL
2008-07-03 12:00 3 1500 TKL
Does increasing the size of LOG_BUFFER will help to reduce the redo log space wait ?
Thanks in advance ,
Regards,
Aman

Looking quickly over the AWR report provided the following information could be helpful:
1. You are currently targeting approx. 6GB of memory with this single instance and the report tells that physical memory is 8GB. According to the advisories it looks like you could decrease your memory allocation without tampering your performance.
In particular the large_pool_size setting seems to be quite high although you're using shared servers.
Since you're using 10.2.0.4 it might be worth to think about using the single SGA_TARGET parameter instead of the specifying all the single parameters. This allows Oracle to size the shared pool components within the given target dynamically.
2. You are currently using a couple of underscore parameters. In particular the "_optimizer_max_permutations" parameter is set to 200 which might reduce significantly the number of execution plans permutations Oracle is investigating while optimizing the statement and could lead to suboptimal plans. It could be worth to check why this has been set.
In addition you are using a non-default setting of "_shared_pool_reserved_pct" which might no longer be necessary if you are using the SGA_TARGET parameter as mentioned above.
3. You are using non-default settings for the "optimizer_index_caching" and "optimizer_index_cost_adj" parameters which favor index-access paths / nested loops. Since the "db file sequntial read" is the top wait event it might be worth to check if the database is doing too excessive index access. Also most of the rows have been fetched by rowid (table fetch by rowid) which could also be an indicator for excessive index access/nested loop usage.
4. You database has been working quite a lot during the 30min. snapshot interval: It processed 123.000.000 logical blocks, which means almost 0.5GB per second. Check the top SQLs, there are a few that are responsible for most of the blocks processed. E.g. there is a anonymous PL/SQL block that has been executed almost 17.000 times during the interval representing 75% of the blocks processed. The statements executed as part of these procedures might be worth to check if they could be tuned to require less logical I/Os. This could be related to the non-default optimizer parameters mentioned above.
5. You are still using the compatible = 9.2.0 setting which means this database could still be opened by a 9i instance. If this is no longer required, you might lift this to the default value of 10g. This will also convert the REDO format to 10g I think which could lead to less amount of redo generated. But be aware of the fact that this is a one-way operation, you can only go back to 9i then via a restore once the compatible has been set to 10.x.
6. Your undo retention is set quite high (> 6000 secs), although your longest query in the AWR period was 151 seconds. It might be worth to check if this setting is reasonable, as you might have quite a large undo tablespace at present. Oracle 10g ignores the setting if it isn't able to honor the setting given the current Undo tablespace size.
7. "parallel_max_servers" has been set to 0, so no parallel operations can take place. This might be intentional but it's something to keep in mind.
Regards,
Randolf
Oracle related stuff:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle:
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/

High redo log buffer wait

Hi,
I can see "high redo log buffer wait" event. The instance spent 23% of its resources waiting for this event. Any suggestion to tune redo log buffer?
DB version : 10.2.0.4.0
Os : AIX
SQL> SELECT name, value FROM v$sysstat WHERE name = 'redo log space requests';
NAME VALUE
redo log space requests 3542
SQL> sho parameter buffer
NAME TYPE VALUE
buffer_pool_keep string
buffer_pool_recycle string
db_block_buffers integer 0
log_buffer integer 14238720
use_indirect_data_buffers boolean FALSE
SQL> select GROUP#,BYTES from v$log;
GROUP# BYTES
1 1073741824
4 1073741824
3 1073741824
2 1073741824
SQL> show parameter sga
NAME TYPE VALUE
lock_sga boolean FALSE
pre_page_sga boolean FALSE
sga_max_size big integer 5G
sga_target big integer 5G
Thanks

Gowin_dba wrote:
I can see "high redo log buffer wait" event. The instance spent 23% of its resources waiting for this event. Any suggestion to tune redo log buffer?
SQL> SELECT name, value FROM v$sysstat WHERE name = 'redo log space requests';
NAME VALUE
redo log space requests 3542 How are you getting from 3,542 "redo log space requests" to 23% of the instance resources waiting for "high redo log buffer wait" (which is not a wait event that can be found in v$event_name in any version of Oracle) ?
"redo log space requests" is about log FILE space, by the way, not about log BUFFER space.
Regards
Jonathan Lewis

"Error model generation: CAUSE: Another deployment is in progress now, ..."

Hello all,
does anybody know how to resolve the error "Error model generation: CAUSE: Another deployment is in progress now, try again later" ?
The log file indicates there's a lock exception before the error described above.
This error is occurring even when a new model is created and tried to deploy.
Can anyone help?
Many thanks in advance!

Hi Norman,
Please try the following:
Log on to NWA (http://<host>:<port>/nwa)
Goto Problem Management --> Locks and try to remove all locks.
Hope this helps.
Regards.
Omer.

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.

Why does my I touch 4th generation glitch out of applications?

Why does my I touch 4th generation glitch out of applications and glitch in general?
Should I do a backup to my computer or format it or somthing?
If this continues is it possible to trade in my I touch 4th genertation for a new I touch 4th generation?
I just want it to stop glitching all the time its no fun to use.

Typically just a software problem
See:
iOS: Troubleshooting applications purchased from the App Store
Contact the developer/go to their support site if only one app.
Restore from backup. See:
iOS: How to back up
Restore to factory settings/new iPod
Apple will exchange your iPod for a refurbished one for $199 for 64 GB 4G and $99 for the otehr 4Gs. They do not fix yours.
Apple - iPod Repair price

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

High redo generation causing outage to Application

Similar Messages

Maybe you are looking for