如何追踪产生大量REDO的来源

从10点到12点数据库中对象块变化排名靠前的对象

select to_char(begin_interval_time,'YYYY_MM_DD HH24:MI') snap_time,

dhsso.object_name,

sum(db_block_changes_delta)

from dba_hist_seg_stat dhss,

dba_hist_seg_stat_obj dhsso,

dba_hist_snapshot dhs

where dhs.snap_id = dhss.snap_id

and dhs.instance_number = dhss.instance_number

and dhss.obj# = dhsso.obj#

and dhss.dataobj# = dhsso.dataobj#

and begin_interval_time between

to_date('2018_12_25 10','YYYY_MM_DD HH24') and

to_date('2018_12_25 13','YYYY_MM_DD HH24')

GROUP BY to_char(begin_interval_time,'YYYY_MM_DD HH24:MI'),

dhsso.object_name

order by 3 desc;

ZQF_LYJ_D42_USR这张表最近几个snap间隔的变化量

select to_char(begin_interval_time,'YYYY_MM_DD HH24:MI') snap_time,

sum(db_block_changes_delta)

from dba_hist_seg_stat dhss,

dba_hist_seg_stat_obj dhsso,

dba_hist_snapshot dhs

where dhs.snap_id = dhss.snap_id

and dhs.instance_number = dhss.instance_number

and dhss.obj# = dhsso.obj#

and dhss.dataobj# = dhsso.dataobj#

and dhsso.object_name = 'ZQF_LYJ_D42_USR'

GROUP BY to_char(begin_interval_time,'YYYY_MM_DD HH24:MI');

历史SQL中关于ZQF_LYJ_D42_USR

select to_char(begin_interval_time,'YYYY_MM_DD HH24'),

dbms_lob.substr(sql_text,4000,1),

dhss.instance_number,

dhss.sql_id,

executions_delta,

dhss.rows_processed_delta

from dba_hist_sqlstat dhss,dba_hist_snapshot dhs,dba_hist_sqltext dhst

where upper(dhst.sql_text) like '%ZQF_LYJ_D42_USR%'

and dhss.snap_id = dhs.snap_id

and dhss.instance_number = dhs.instance_number

and begin_interval_time between

to_date('2018_12_25 10','YYYY_MM_DD HH24') and

to_date('2018_12_25 13','YYYY_MM_DD HH24')

and dhss.sql_id=dhst.sql_id;

SQL: How to Find Sessions Generating Lots of Redo or Archive logs (文档 ID 167492.1)

***Checked for relevance on 13-Oct-2015***

goal: How to find sessions generating lots of redo

fact: Oracle Server - Enterprise Edition 8

fact: Oracle Server - Enterprise Edition 9

fact: Oracle Server - Enterprise Edition 10

fix:

To find sessions generating lots of redo, you can use either of the following

methods. Both methods examine the amount of undo generated. When a transaction

generates undo, it will automatically generate redo as well.

The methods are:

1) Query V$SESS_IO. This view contains the column BLOCK_CHANGES which indicates

how much blocks have been changed by the session. High values indicate a

session generating lots of redo.

The query you can use is:

SQL> SELECT s.sid, s.serial#, s.username, s.program,

i.block_changes

FROM v$session s, v$sess_io i

WHERE s.sid = i.sid

ORDER BY 5 desc, 1, 2, 3, 4;

Run the query multiple times and examine the delta between each occurrence

of BLOCK_CHANGES. Large deltas indicate high redo generation by the session.

2) Query V$TRANSACTION. This view contains information about the amount of

undo blocks and undo records accessed by the transaction (as found in the

USED_UBLK and USED_UREC columns).

The query you can use is:

SQL> SELECT s.sid, s.serial#, s.username, s.program,

2  t.used_ublk, t.used_urec

3  FROM v$session s, v$transaction t

4  WHERE s.taddr = t.addr

5  ORDER BY 5 desc, 6 desc, 1, 2, 3, 4;

Run the query multiple times and examine the delta between each occurrence

of USED_UBLK and USED_UREC. Large deltas indicate high redo generation by

the session.

You use the first query when you need to check for programs generating lots of

redo when these programs activate more than one transaction. The latter query

can be used to find out which particular transactions are generating redo.

How To Determine The Cause Of Lots Of Redo Generation Using LogMiner (文档 ID 300395.1)

APPLIES TO:

Oracle Database - Enterprise Edition - Version 8.1.7.4 to 10.2.0.5 [Release 8.1.7 to 10.2]

Oracle Database - Enterprise Edition - Version 11.2.0.1 and later

Information in this document applies to any platform.

GOAL

This article provides guidelines DBAs can use to determine which OPERATION codes are generating lots of redo information.

This article is intended for DBAs. The article assumes the reader is familiar with LogMiner and has basic skills in mining redo logs.

SOLUTION

--- How to determine the cause of lots of redo generation using LogMiner ---

Using OPERATION Codes to Understand Redo Information

There are multiple operation codes which can generate the redo information, using following guide lines you can identify the operation codes which are causing the high redo generation and you need to take an appropriate action on it to reduce the high redo generation.

NOTE:

Redo records are not all equally sized. So remember that just because certain statements show up a lot in the LogMiner output, this does not guarantee that you have found the area of functionality generating the excessive redo.

What are these OPERATION codes ?

INSERT / UPDATE / DELETE -- Operations are performed on SYS objects are also considered as an Internal Operations.

COMMIT -- This is also "Internal" operation, you will get line "commit;" in the column sql_redo.

START -- This is also "Internal" operation, you will get line "set transaction read write;" in sql_redo INTERNAL -- Dictionary updates

SELECT_FOR_UPDATE - This is also an Internal operation and oracle generates the redo information for "select" statements which has "for update" clause.

In general INTERNAL operations are not relevant, so to query the relevant data, use "seg_owner=' in the "where" clause.

Examples :

How to extract relevant information from the view v$logmnr_contents?

1. This SQL lists operations performed by user SCOTT

SQL> select distinct operation,username,seg_owner from v$logmnr_contents where seg_owner='SCOTT';

OPERATION USERNAME SEG_OWNER

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

DDL SCOTT SCOTT

DELETE SCOTT SCOTT

INSERT SCOTT SCOTT

UPDATE SCOTT SCOTT

2. This SQL lists the undo and redo associated with operations that user SCOTT performed

SQL> select seg_owner,operation,sql_redo,sql_undo from v$logmnr_contents where SEG_owner='SCOTT';

SCOTT DDL

create table LM1 (c1 number, c2 varchar2(10));

SCOTT INSERT

insert into "SCOTT"."LM1"("C1","C2") values ('101','AAAA');

delete from "SCOTT"."LM1" where "C1" = '101' and "C2" = 'AAAA'

and ROWID = 'AAAHfBAABAAAMUqAAA';

SCOTT UPDATE update "SCOTT"."LM1" set "C2" = 'YYY'

where "C2" = 'EEE' and ROWID = 'AAAHfBAABAAAMUqAAE';

update "SCOTT"."LM1" set "C2" = 'EEE' where "C2" = 'YYY'

and ROWID = 'AAAHfBAABAAAMUqAAE';

INSERT / UPDATE / DELETE -- Operations are performed on SYS objects are also considered as an Internal Operations.

3. This SQL lists undo and redo genereated for UPDATE statements issues by user SCOTT

SQL> select username, seg_owner,operation,sql_redo,sql_undo from v$logmnr_contents where operation ='UPDATE' and USERNAME='SCOTT';

UNAME SEG_OW OPERATION SQL_REDO SQL_UNDO

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

SCOTT SYS UPDATE update "SYS"."OBJ$" set "OBJ#" = '1'..... update ....

SCOTT SYS UPDATE update "SYS"."TSQ$" set "GRANTO..... update .......

SCOTT SYS UPDATE update "SYS"."SEG$" set "TYPE#" = '5'.. update......

As per above result user SCOTT has updated SYS objects so, if you query on USERNAME, you may get incorrect result. So, better to query v$logmnr_contents on SEG_OWNER.

4. Identifying Operation Counts

Run the following query to see the OPERATION code row count from v$logmnr_contents, to understand which OPERATION code has generated lots of redo information.

SQL> select operation,count(*) from v$logmnr_contents group by operation;

OPERATION COUNT(*)

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

COMMIT 22236

DDL 2

DELETE 1

INSERT 11

INTERNAL 11

SELECT_FOR_UPDATE 32487

START 22236

UPDATE 480

8 rows selected

5. Identifying User Counts

Run the following query to check user activity and operation counts:

SQL> select seg_owner,operation,count(*) from v$logmnr_contents group by seg_owner,operation;

SEG_OWNER OPERATION COUNT(*)

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

SCOTT COMMIT  22236

SCOTT DDL 2

SCOTT DELETE 1

...

BILLY COMMIT 12899

BILLY DDL 5

BILLY DELETE 2

...

NOTE: 

Be aware of next known issue:

If you are not using "select for update" statements often in your application and yet find a high operation count for operation code "SELECT_FOR_UPDATE" then you might be hitting a known issue.

To confirm this check whether SQL_REDO shows select,update statements on AQ$_QUEUE_TABLE_AFFINITIES and AQ$_QUEUE_TABLES.

If you see these selects and updates, then check the value of the Init.ora parameter AQ_TM_PROCESSES.  The default value is AQ_TM_PROCESSES = 0 meaning that the queue monitor is not created.

If you are not using Advanced Queuing, then set AQ_TM_PROCESSES back to zero to avoid lots of redo generation on objects AQ$_QUEUE_TABLE_AFFINITIES and AQ$_QUEUE_TABLES.