Also check whether there was any Online Backup scheduled during the time of "High number of redo log", which may lead to high number of redo log files. Else you need to check Transactions / Jobs which ran during that point of time.
If you are running on Oracle 10g or further release, you can analyze offline redolog files and identify who and what job is responsible about high number of redolog files, by using Oracle LogMiner.
well you will find the SQL that causes the redo with logminer, but you will not see the module like in V$SESSION (either not the responsible ABAP code). If the high amount of redo is generated by short transactions you will even not find it in the ASH (AWR) samples.
@Castro:
The view V$SEGMENT_STATISTICS is suffcient in your case. You can also join the highest redo changes from V$SEGMENT_STATISTICS with V$SQL or V$ACTIVE_SESSION_HISTORY to get a view of the corresponding SQLs and modules.
>> well you will find the SQL that causes the redo with logminer, but you will not see the module like in V$SESSION (either not the responsible ABAP code). If the high amount of redo is generated by short transactions you will even not find it in the ASH (AWR) samples.
You can't find out the responsible ABAP code directly, but figure out it by looking to the SQL statements. That's what I mean.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.