| redo size [message #557942] |
Mon, 18 June 2012 03:24  |
 |
ashishrnv
Messages: 8
Registered: June 2012
Location: Bangalore
|
Junior Member |
|
|
Hi all,
In one of our envirnoment i could see the redo size is high.Trying to understand why this is more can any one help me here.
|
|
|
|
|
|
|
|
|
|
|
|
| Re: redo size [message #557957 is a reply to message #557955] |
Mon, 18 June 2012 04:42  |
 |
Michel Cadot
Messages: 68737
Registered: March 2007
Location: Saint-Maur, France, https...
|
Senior Member
Account Moderator |
|
|
It is not so high in my opinion.
Anyway, it is at the exact level it has to be for the work you asks Oracle to do.
What is the concern about this number?
Regards
Michel
[Updated on: Mon, 18 June 2012 04:44] Report message to a moderator |
|
|
|
|
|
|
|
| Re: redo size [message #557965 is a reply to message #557958] |
Mon, 18 June 2012 06:13 |
John Watson
Messages: 8965
Registered: January 2010
Location: Global Village
|
Senior Member |
|
|
Ashish, there is no such thing as "high" or "low". Only "higher" or "lower". To put it another way, in performance tuning, the absolute value is meaningless: all that matters is change. You need to compare this figure to the figure from a week, a month, a year ago. Has it changed? If so, perhaps you need to investigate why.
That having been said, 33K per second is trivial.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: redo size [message #558090 is a reply to message #558027] |
Tue, 19 June 2012 06:27 |
John Watson
Messages: 8965
Registered: January 2010
Location: Global Village
|
Senior Member |
|
|
|
I'll try again, man. No end user ever telephoned his DBA to say "the redo generation rate is too high". He might telephone to say "this query takes too long". Until that happens, you need do nothing. When it does happen, follow the advice given in the sticky post at the top of the Performance Tuning forum.
|
|
|
|
|
|
| Re: redo size [message #559106 is a reply to message #557942] |
Thu, 28 June 2012 14:27 |
 |
alan.kendall@nfl.com
Messages: 163
Registered: June 2012
Location: Culver City, California
|
Senior Member |
|
|
I use the following query to see how much redo is being used currently:
SQL > @R
no rows selected
SQL > update alan set total=1;
1 row updated.
SQL > @R
NAME USED_UBLK MEG_UNDO
---------- ---------- ----------
_SYSSMU10_ 1 .0078125
SQL > COMMIT;
Commit complete.
SQL > @R
no rows selected
SQL > update alan set total=1;
1 row updated.
SQL > @R
NAME USED_UBLK MEG_UNDO
---------- ---------- ----------
_SYSSMU5_4 1 .0078125
Notice how the undosegment changes each time a commit occurs.
SQL > commit;
Commit complete.
SQL > @r
no rows selected
SQL > list
1 select s.sid,s.serial#,username,t.used_ublk "UndoBLKS", terminal, osuser,
2 t.start_time, r.name,
3 decode(t.space, 'YES', 'SPACE TX',
4 decode(t.recursive, 'YES', 'RECURSIVE TX',
5 decode(t.noundo, 'YES', 'NO UNDO TX', t.status)
6 )) status
7 from sys.v_$transaction t, sys.v_$rollname r, sys.v_$session s
8 where t.xidusn = r.usn
9* and t.ses_addr = s.saddr
When I have runaway transactions that increase the size of the undo tablespace, I resize the tablespace with the following:
MAXMEG MEG STATUS FILE_NAME
------ ------ --------- --------------------------------------------
9000 9000 AVAILABLE /u02/app/oracle/oradata/CSCDAD/undotbs01.dbf
SQL > alter database datafile '/u02/app/oracle/oradata/CSCDAD/undotbs01.dbf' resize 2000m;
Database altered.
MAXMEG MEG STATUS FILE_NAME
------ ------ --------- --------------------------------------------
9000 2000 AVAILABLE /u02/app/oracle/oradata/CSCDAD/undotbs01.dbf
|
|
|
|
|
|
] 
Blog
Search
Help
Members
Register
Login
Home
