Sunteți pe pagina 1din 5

Sometimes, database generates lot more archives than the normal.

In this article I will


show you how to find them. Below are the queries to drill down to the root cause and
fix the issue.

1
2
3
4
5
6
7
8
9
1
0
1
1
1
2
1
3
1
4
1
5
1
6
1
7
1
8
1
9
2
0
2
1
2
2
2
3
2
4
2
5
2
6
2
7
2
8
2
9
3
0
3
1
3

Run the below query to find out the archive generation/hour for last one week.
SELECT * FROM (
SELECT * FROM (
SELECT TO_CHAR(FIRST_TIME, 'DD/MM') AS "DAY"
, TO_NUMBER(SUM(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '00', 1, 0)), '999') "00:00"
, TO_NUMBER(SUM(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '01', 1, 0)), '999') "01:00"
, TO_NUMBER(SUM(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '02', 1, 0)), '999') "02:00"
, TO_NUMBER(SUM(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '03', 1, 0)), '999') "03:00"
, TO_NUMBER(SUM(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '04', 1, 0)), '999') "04:00"
, TO_NUMBER(SUM(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '05', 1, 0)), '999') "05:00"
, TO_NUMBER(SUM(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '06', 1, 0)), '999') "06:00"
, TO_NUMBER(SUM(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '07', 1, 0)), '999') "07:00"
, TO_NUMBER(SUM(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '08', 1, 0)), '999') "08:00"
, TO_NUMBER(SUM(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '09', 1, 0)), '999') "09:00"
, TO_NUMBER(SUM(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '10', 1, 0)), '999') "10:00"
, TO_NUMBER(SUM(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '11', 1, 0)), '999') "11:00"
, TO_NUMBER(SUM(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '12', 1, 0)), '999') "12:00"
, TO_NUMBER(SUM(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '13', 1, 0)), '999') "13:00"
, TO_NUMBER(SUM(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '14', 1, 0)), '999') "14:00"
, TO_NUMBER(SUM(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '15', 1, 0)), '999') "15:00"
, TO_NUMBER(SUM(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '16', 1, 0)), '999') "16:00"
, TO_NUMBER(SUM(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '17', 1, 0)), '999') "17:00"
, TO_NUMBER(SUM(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '18', 1, 0)), '999') "18:00"
, TO_NUMBER(SUM(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '19', 1, 0)), '999') "19:00"
, TO_NUMBER(SUM(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '20', 1, 0)), '999') "20:00"
, TO_NUMBER(SUM(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '21', 1, 0)), '999') "21:00"
, TO_NUMBER(SUM(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '22', 1, 0)), '999') "22:00"
, TO_NUMBER(SUM(DECODE(TO_CHAR(FIRST_TIME, 'HH24'), '23', 1, 0)), '999') "23:00"
FROM V$LOG_HISTORY
WHERE extract(year FROM FIRST_TIME) = extract(year FROM sysdate)
GROUP BY TO_CHAR(FIRST_TIME, 'DD/MM')
) ORDER BY TO_DATE(extract(year FROM sysdate) || DAY, 'YYYY DD/MM') DESC
) WHERE ROWNUM < 8;

2
3
3
3
4

If there is a drastic change in redo/archive generation run below queries.. Get the
segment that experienced the most changes during a specific period. This is helpful in
tracking history data.
Note:- Change the date ranges according to the time frame.

1
2
3
SELECT to_char(begin_interval_time,'YYYY_MM_DD HH24:MI') snap_time,
4
dhsso.object_name,
5
sum(db_block_changes_delta)
6
FROM dba_hist_seg_stat dhss,
7
dba_hist_seg_stat_obj dhsso,
8
dba_hist_snapshot dhs
9
WHERE dhs.snap_id = dhss.snap_id
1
AND dhs.instance_number = dhss.instance_number
0
AND dhss.obj# = dhsso.obj#
1
AND dhss.dataobj# = dhsso.dataobj#
1
AND begin_interval_time BETWEEN to_date('2013_10_22 12','YYYY_MM_DD HH24')
1
AND to_date('2013_10_23 12','YYYY_MM_DD HH24')
2
GROUP BY to_char(begin_interval_time,'YYYY_MM_DD HH24:MI'),
1
dhsso.object_name order by 3 desc;
3
1
4

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:

1
2
3
4
5

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


2 i.block_changes
3 FROM v$session s, v$sess_io i
4 WHERE s.sid = i.sid
5 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:

1
2
3
4
5

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

Archive log generation is huge - oracle database troubleshooting

A: check after hot backup any tablespace was left in begin backup mode and failed
to do end backup for any tablespace.

select a.tablespace_name
from sys.dba_data_files a, sys.v_$backup b
where b.status = 'ACTIVE'
and b.file# = a.file_id
group by a.tablespace_name;

Make that tablespace to end backup

B: Check which session is generating more redo.

set pages 1000


set lines 140
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;

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;

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:

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:

SELECT s.sid, s.serial#, s.username, s.program, t.used_ublk, t.used_urec


FROM v$session s, v$transaction t
WHERE s.taddr = t.addr
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.

S-ar putea să vă placă și