Fragmentation in Undo TBS

Hi all experts,
I want to know if found fragmentation in undo tablespace.
Is it recommaned to treat it the same way as usual permanent non system fragmented TBSs.
i.e. do fragmentation
I wonder if temp/undo tbs needs to be defragmented.
Looking for your kind and professional advices and references.
Thanks

Being Locally Managed, TEMP and UNDO are self-managed by Oracle.
I also wonder if you are "de-fragmenting" other tablespaces. If they are Locally Managed and Allocation_Type is either UNIFORM or AUTO, you do not need to "de-fragment" them. If using UNIFORM, set the appropriate Extent Size when you create the Tablespace.
If your Tablespace has been converted from Dictionary Managed to Locally Managed, the Extent Management may appear as "USER" -- in which case you have odd-sized extents brought forward from DMT. Again, "fragmentation" is not an issue once they are Locally Managed.
You could consider rebuilding the tablespaces as LMT with UNIFORM or AUTO when you get an opportunity. (Obviously : TEST, TEST , TEST and measure the effort and downtime -- it may not be justifiable to even expend that effort).
Hemant K Chitale

Similar Messages

UNDO tbs requirement

How would I know what is the required UNDO tbs space for a job to run successfully.
I cannot view the code of the job.
How can I calculate the UNDO tbs requirement for that particular job.
Following is the error I am facing while running that job :
*** Starting go_ifs_gb_publish_data_det.sh at Fri Feb 12 14:13:21 EST 2010.
BEGIN fdw.gb_rpt_publish_data; END;
ERROR at line 1:
ORA-30036: unable to extend segment by 4 in undo tablespace 'UNDOTBS'
ORA-06512: at "FDW.GB_RPT_PUBLISH_DATA", line 140
ORA-06512: at line 1
Job Failed: go_ifs_gb_publish_data_det Error Code: 84
*** go_ifs_gb_publish_data_det.sh Ending at Fri Feb 12 20:49:56 EST 2010.

There is no thumb rule for setting size of the undo for any trasaction or transactions.
few suggestions : monitor for few days in peak time of usage of undo and adjust as per requirement.
: try to do a intermediate commit for transaction instead of running long transactions.
Below query will give you some help in tuning the undo tablespace and retention ( Check the feasiblity , as said there is no thumb rule )
SELECT d.undo_size/(1024*1024) "ACTUAL UNDO SIZE [MByte]",
SUBSTR(e.value,1,25) "UNDO RETENTION [Sec]",
(TO_NUMBER(e.value) * TO_NUMBER(f.value) *
g.undo_block_per_sec) / (1024*1024)
"NEEDED UNDO SIZE [MByte]"
FROM (
SELECT SUM(a.bytes) undo_size
FROM v$datafile a,
v$tablespace b,
dba_tablespaces c
WHERE c.contents = 'UNDO'
AND c.status = 'ONLINE'
AND b.name = c.tablespace_name
AND a.ts# = b.ts#
) d,
v$parameter e,
v$parameter f,
SELECT MAX(undoblks/((end_time-begin_time)*3600*24))
undo_block_per_sec
FROM v$undostat
) g
WHERE e.name = 'undo_retention'
AND f.name = 'db_block_size'
Regards,
Anil Malkai
if it is help ful or answered your query mark it as answered.
Edited by: Anil Malkai on Feb 15, 2010 3:32 AM

2 Undo Tablespace both ONLINE, How to drop previous undo tbs

Hello Team,
Undo management=auto
After Cloning :-
To reclaim space i created another undo tablespace, but now both are online, but as per oracle as soon as you switch undo tablespace, previous undo TBS gets in Pending offline mode,offline mode, (So that transaction get finished)
But in my case Both UNDO Tablespaces are online
Previous Undo TBS1:- 600 GB
New UNDo Tb2s:- 100GB
Please suggest how to drop this online undo TBS1
TABLESPACE_NAME ONLINE_
APPS_UNDOTS1 ONLINE
APPS_UNDOTS1 ONLINE
APPS_UNDOTS1 ONLINE
APPS_UNDOTS1 ONLINE
APPS_UNDOTS1 ONLINE
APPS_UNDOTS1 ONLINE
APPS_UNDOTS1 ONLINE
APPS_UNDOTS1 ONLINE
APPS_UNDOTS1 ONLINE
APPS_UNDOTS2 ONLINE
APPS_UNDOTS2 ONLINE
TABLESPACE_NAME ONLINE_
APPS_UNDOTS2 ONLINE

Hi As per
select segment_name,owner,tablespace_name,status from dba_rollback_segs where tablespace_name like 'UNDOTBS1';
All Are offline for UNDOTBS1(Previous)
SEGMENT_NAME OWNER TABLESPACE_NAME STATUS
SYSSMU49861044602693$ PUBLIC APPS_UNDOTS1 OFFLINE
SYSSMU4893847838046$ PUBLIC APPS_UNDOTS1 OFFLINE
SYSSMU48682660477388$ PUBLIC APPS_UNDOTS1 OFFLINE
SYSSMU47753309457002$ PUBLIC APPS_UNDOTS1 OFFLINE
SYSSMU47131240212364$ PUBLIC APPS_UNDOTS1 OFFLINE
434 rows selected.

Someone eating my UNDO tbs

Hello all,
I have 11gr2 with r12.
we have 60GB undo tbs, retention is 900s set.
since last 2 days our undo is showing 98% used, no recent changes done.
I googled, lots of sql's are there to know what is consuming UNDO, but the list what I am getting as an output result are in KB's.
for example:
select * from V$SYSMETRIC_HISTORY;
select
s.username
,s.sid
,s.serial#
,s.osuser
,s.logon_time
,s.status
,s.machine
,t.used_ublk
,t.used_ublk*8192/1024 undo_usage_kb
from v$session s
,v$transaction t
where t.addr = s.taddr;
above query is giving me num of sessions but all are in kb's, then where is undo been consumed.
Please help me to find out the culprit.
Thanks in ADV

DOA wrote:
Thanks for the prompted reply.
I was just wanted to know the transaction which are currently running are consuming how much UNDO space ?
second while checking EXPIRED I am getting around 3000 count.
Plz suggest.
Thanks!
Nothing is consuming any undo space if all the extents are EXPIRED. An extent in use by transaction is ACTIVE. An extent that was used by transaction that committed less recently than your undo_retention is UNEXPIRED. Clear?

What roolback trans is inside undo tbs

We got a ORA-30036 last night. UNDO tbs jump to 54 GB, it only has 1 datafile and has fillup the whole drive.
I want to know what exact transcation cause the fillup. Is there any system tables where I can see the rollback transcation in UNDO??
Thanks in Advanced
carlton

You can check V$UNDOSTAT to see whats the statistics for the particular undo. There would be 10 default undo segments created for any undo tablespace. For each of them you can see whether it has expired or not from DBA_ROLLBACK_SEGS.
From V$TRANSACTION, you can see the transaction id and lot other information about the transaction along with the ses_adr which you can combine with v$session to see who is using that transaction. in V$SESSION you have address and hash_value of the sessions latest sql which you can combine with V$SQLAREA or V$SQLTEXT to get the exact SQL which is performing the DML operation.
HTH

How to expdp table with a BLOB field when table is larger than UNDO tbs?

We have a 4-node RAC instance and are at 11.1. We have a 100 gig schema with a few hundred tables. One table contains about 80 gig of data. the table has pictures in it (BLOB column). Our 4 node RAC has 4 12 gig undo tablespaces.
We run out of undo when export a schema or just this table due to the size of the table.
According to metalink note ID 1086414.1 this can happen on fragmented tables. According to segment advisor, we are all good and not fragmented at all.
I also followed the troubleshooting advice in ID 833635.1 and ID 846079.1, but everything turned out ok.
LOBs and ORA-01555 troubleshooting [ID 846079.1]
Export Fails With ORA-02354 ORA-01555 ORA-22924 and How To Confirm LOB Segment Corruption Using Export Utility? [ID 833635.1]
initially we tried just to export it without special parameters.
expdp MY_SCHEMA/********@RACINSTANC DUMPFILE=MYFILE.dmp PARALLEL=8 directory=DATA_PUMP_DIR SCHEMAS=MY_SCHEMA
ORA-31693: Table data object "MY_SCHEMA"."BIGLOBTABLE" failed to load/unload and is being skipped due to error:
ORA-02354: error in exporting/importing data
ORA-01555: snapshot too old: rollback segment number 71 with name "_SYSSMU71_1268406335$" too small
then tried to export just the table into 8 files of 8G each (the failing table is about 90% of the schema size)
expdp MY_SCHEMA/******@RACINSTANCE DUMPFILE=MYFILE_%U.dmp PARALLEL=8 FILESIZE=8G directory=DATA_PUMP_DIR INCLUDE=TABLE:\"IN ('BIGLOBTABLE') \"
ORA-31693: Table data object "MY_SCHEMA"."BIGLOBTABLE" failed to load/unload and is being skipped due to error:
ORA-02354: error in exporting/importing data
ORA-01555: snapshot too old: rollback segment number 71 with name "_SYSSMU71_1268406335$" too small
We eventually resorted to exporting chunks out of the table by using the QUERY parameter
QUERY=BIGLOBTABLE:"WHERE BIGLOBTABLEPK > 1 AND BIGLOBTABLEPK <=100000"
and that worked but it is a kludge.
Since we will have to export this again down the road I was wondering if there is an easier way to export.
Any suggestions are appreciated.

Note that undo data for LOB is not stored in UNDO tablespace but in LOB segments. So I am not sure ORA-1555 is directly linked to LOB data.
What is your undo_retention parameter ?
How long does EXPDP run before getting ORA-1555 ?
You could try to increase undo_retention parameter to avoid ORA-1555.
Are you running Entreprise Edition ? If yes, trying to transport the tablespace storing the table could be a solution.

Undo TBS

Hi all, I am using Oracle 10gR2 on Solaris 10.
The application using my DB does a lot of commits and rollbacks, because of which my undo tablespace is always full. I have a RAC with two nodes, so two undo tablespaces, which are always full. Now, when Oracle has no room to write into the undo, it stops processing the application processes, because of which there are a lot of INACTIVE sessions and they keep increasing because the application sends them to be processed but they are not.
NAME                                 TYPE        VALUE
undo_management                      string     AUTO
undo_retention                       integer     900
undo_tablespace                      string      UNDOTBS1Should I reduce my undo_retention so that Oracle does not keep the undo info for that long and it empties up space faster?
Regards.....

Generally the users ask DBA's before running such a long tansactions..Not being funny mate, but in my experience too often people have no idea about undo and the affect their changes have. But the DBA has to gently talk, cajole, persuade them to change their ways and not used 100GB of resource; "please please pretty please don't do that" then they do it again anyway.... Even if you resort to less polite methods....
Summing up for the OP yes you need to identify the users/batch using undo and attempt to change the usage of those.
Hope this helps, a script another DBA gave me;
no idea who the original author is....
but as it helped me I'm passing on to help others.
select distinct r.name rollname,
l.sid loc_sid,
s.sid session_sid,
l.addr lock_addr,
l.kaddr lock_kaddr,
nvl(s.username,'Internal') username,
decode(s.command,2,'Insert',3,'Select',6,'Update',7,'Delete',44,'Commit',45,'Rollback','Other') trans_type
from
v$lock l,
v$process p,
v$rollname r,
v$session s,
sys.user$ sysuser,
sys.obj$ sysobj
where l.sid = s.sid
and sysobj.obj# = decode(L.ID2,0,L.ID1,1)
and sysuser.user# = sysobj.owner#
and trunc(l.id1(+)/65536) = r.usn
and s.type != 'BACKGROUND'
order by r.name
/

Undo tbs corrupted

i have oracle 9i release 2 on unix box. The database is up but the undo tablespace got corrupted which i can see using v$recover_file view. End users have begin performing DML activities but at the midst of the transaction undo got corrupted . I have a backup of undo .
what should i do shall i shutdown and recover at the mount mode or recover the undo tablespace online??
please help me
its very urgent

You don't need to go for offline recovery.Do you mind elaborating that.
Question, let us say undo is corrupted, can we do a online recovery?
My reserach says
rman>restore datafile '/u02/undotbs01.dbf';--will complain about enqueue.
Also, You cannot take a undo tablespace offline.
You cannot drop a undo tablespace while it is in use.
My thoughts :- Take the database to mount state. Restore/recover.

Query abort with ora-30036 after more than 20 hours and 180g of undo

Dear all,
A developper transmits me a query. It fails after more than 20 hours and an undotbs of 180g (i change undo-retention, size of undo tbs, without results). That query makes a lot of inserts. How can i rewrite it to be more performant (my database is on 10.2.0.3 and i can't change it).
here's the query :
set serveroutput on size unlimited
set pages 0
set trims on
set lines 1000
set feed off
set pagesize 50
set linesize 1000
set head off
set echo off
set verify off
set feedback off
WHENEVER SQLERROR EXIT SQL.SQLCODE
DECLARE
v_annee VARCHAR(4) := '2012';
v_dkm_id NUMBER := '108';
v_entretien NUMBER;
v_nb_feuilles_cr NUMBER := 0;
v_nb_etats_cr NUMBER := 0;
v_action_id NUMBER;
v_rm_id NUMBER;
v_personne_id NUMBER;
CURSOR c_evaluation IS
     SELECT E.ID# AS E_ID, W.ID# AS WF_ID , E.NATURE_ECHELON AS ECHELON
     FROM T_EVALUATION E
     JOIN T_DKM_LOCALE L ON L.ID#=E.DKM_LOCALE_ID
     JOIN T_WORKFLOW W ON (W.CODE=E.CODE_WORKFLOW_INITIAL AND W.ANNEE=v_annee )
     WHERE L.DKM_NAT_ID=v_dkm_id;
r_evaluation c_evaluation%ROWTYPE;
BEGIN
SELECT ID#
INTO v_personne_id
FROM T_PERSONNE
WHERE ID_FONCTIONNEL = 'herve.collin';
dbms_output.put_line('===== MAJ evaluations / statut_harmo_shd =============');
dbms_output.put_line('===== Creation des feuilles ==========================');
SELECT ID# MOTIF_ID
INTO v_entretien
FROM T_REF_MOTIF_TENUE_ENTRETIEN
WHERE CODE='PLA';
OPEN c_evaluation;
LOOP
     FETCH c_evaluation INTO r_evaluation;
     EXIT WHEN c_evaluation%NOTFOUND;
IF r_evaluation.ECHELON = 'T'
THEN
SELECT ID#
INTO v_rm_id
FROM T_REF_REDUCMAJO
WHERE ANNEE = v_annee
AND CATEGORIE_GRADE = 'ET'
AND CODE = 'V1';
END IF;
IF r_evaluation.ECHELON = 'F' OR r_evaluation.ECHELON = 'V'
THEN
SELECT ID#
INTO v_rm_id
FROM T_REF_REDUCMAJO
WHERE ANNEE = v_annee
AND CATEGORIE_GRADE = 'FV'
AND CODE = 'R1';
END IF;
UPDATE T_EVALUATION
SET STATUT_HARMO_SHD = 'C' , REF_REDUCMAJO_PROP_SHD_ID = v_rm_id
WHERE DKM_LOCALE_ID IN ( SELECT ID# FROM T_DKM_LOCALE WHERE DKM_NAT_ID = v_dkm_id );
INSERT INTO T_FEUILLE(ID#, REF_MOTIF_TENUE_ENT_ID, EVALUATION_ID, WORKFLOW_ID)
VALUES (S_FEUILLE.NEXTVAL , v_entretien , r_evaluation.E_ID, r_evaluation.WF_ID);
v_nb_feuilles_cr := v_nb_feuilles_cr + 1;
END LOOP;
CLOSE c_evaluation;
dbms_output.put_line(' -> '||v_nb_feuilles_cr||' feuilles crees');
COMMIT;
END;
set serveroutput off
exit
What is the bester choice ? drop the indexes on the table before insert, start the insert without fetching the data in cursor ?
nb: sorry for my bad english
Best regards
Catherine Andre
@mail: [email protected]

user4443606 wrote:
Thanks for your reply !
I'll try to grow the undo tbs space but i stay convinced that the problem is in the query.You can be convinced & wrong at the same time.
row by row INSERT is slow by slow.
It can be done as single INSERT; but that won't change the amount of UNDO that is required.

Drop Undo Tablespace taking more than 1 hr

Hi,
To give you background, I had given an "insert into .. select" command which was inserting 3 millions of rows of rowidth approx 5000 bytes. The window on which it was given, was closed by mistake.
After sometime when I checked the size of undo_tablespace, it was 5.5GB. I decided to create a new one and drop the old undo_tbsp.
I have successfully created new undo tablespace and changed the same in spfile also.
now when i am dropping the old undo tablespace, its taking long time. its almost an hour, but the tablespace has not been dropped yet.
I have given following command
drop tablespace undotbs_01 including contents;
Any idea, why is it taking so much time, and how long should I wait?
If someone can give me any other idea on how can I drop the tablespace, that will be great.
Regards,
Archana.

To give you background, I had given an "insert into .. select" command which was inserting 3 millions of rows of rowidth approx 5000 bytes. The window on which it was given, was closed by mistake.This could be the cause.
I wonder the killed/closed session doesn't hangup with a latch or lock.
Since the old undo tbs had active transaction, it might have to pending offline status. If so, you can drop it.
Jaffar

Undo tablespace is getting increased

Hi All,
Oracle 9.2.0.1.0 version.
The undo tablspace is getting increased, it gone more than 10 GB.
Thanks for you suggestions

Turn AUTOEXTEND OFF on your undo tbs and check DML operations on big tables.

Undo tablespace growth

Hi ..
My undo tablespace is Growing rapidly from 1gb to 10 gb with an Hour.
Is there any ways to find out which operation Generates More Undo ..
Can i able to restrict it...

hi,
there is parameter that control the aging out of undo blocks that leverages size of UNDO tbs:
UNDO_RETENTION
You can guarantee that unexpired undo data is not overwritten even if it means that future operations that need to generate undo data will fail. This is done by specifying the RETENTION GUARANTEE clause for the undo tablespace when it is created by either the CREATE DATABASE or CREATE UNDO TABLESPACE statement. Alternatively, you can later specify this clause in an ALTER TABLESPACE statement.
more: UNDO RETENTION GUARANTEE

Undo growth

Hi,
Data base Relaease : 9.2.0.4.0
OS : Suse linux 2.4.21-198-smp
One of my production database size is 16GB (including all the system objects + used & unused space + undo tablespace). Approximately used space is 13 GB. my problem is i am not able to control the growth of undo tablespace. From that 16GB of my database the 5GB is reserved for my undo tablesapce. Last week i have seen my undo tbs had 1307MB free space but now its having only 1074MB. My undo_retention=10800. Can you please give me the suggestions and valuable comments to solve this problem and way to approach and reason for this problem?
and for your clear analyze i have enclosed my current v$undostat output
BEGIN_TIME END_TIME UNDOTSN UNDOBLKS TXNCOUNT MAXQUERYLEN MAXCONCURRENCY
02-04-07:12:10:06 02-04-07:12:15:24 1 0 1242181 5819 0
02-04-07:12:00:06 02-04-07:12:10:06 1 0 1242179 5503 0
02-04-07:11:50:06 02-04-07:12:00:06 1 0 1242174 4901 0
02-04-07:11:40:06 02-04-07:11:50:06 1 0 1242157 4299 0
02-04-07:11:30:06 02-04-07:11:40:06 1 0 1242117 3704 0
02-04-07:11:20:06 02-04-07:11:30:06 1 0 1242115 3102 0
02-04-07:11:10:06 02-04-07:11:20:06 1 0 1242113 2503 0
02-04-07:11:00:06 02-04-07:11:10:06 1 1 1242108 1902 1
02-04-07:10:50:06 02-04-07:11:00:06 1 0 1242096 1300 0
02-04-07:10:40:06 02-04-07:10:50:06 1 0 1242087 704 0
02-04-07:10:30:06 02-04-07:10:40:06 1 1 1242075 100 1
02-04-07:10:20:06 02-04-07:10:30:06 1 0 0 0 0
02-04-07:10:10:06 02-04-07:10:20:06 1 3 1242013 24 1
02-04-07:08:40:06 02-04-07:10:10:06 1 0 0 0 0
02-04-07:08:30:06 02-04-07:08:40:06 1 121 1241862 0 1
02-04-07:08:10:06 02-04-07:08:30:06 1 0 0 0 0
02-04-07:08:00:06 02-04-07:08:10:06 1 2 1241729 0 1
02-04-07:07:50:06 02-04-07:08:00:06 1 1 1241703 12 1
02-04-07:06:10:06 02-04-07:07:50:06 1 0 0 0 0
02-04-07:06:00:06 02-04-07:06:10:06 1 1 1241619 0 1
02-04-07:01:00:06 02-04-07:06:00:06 1 0 0 0 0
02-04-07:12:50:06 02-04-07:01:00:06 1 1 1241560 0 1
01-04-07:08:40:06 02-04-07:12:50:06 1 0 0 0 0
01-04-07:08:30:06 01-04-07:08:40:06 1 59 1241508 0 1
01-04-07:09:20:06 01-04-07:08:30:06 1 0 0 0 0
01-04-07:09:10:06 01-04-07:09:20:06 1 1 1241315 0 1
01-04-07:09:00:06 01-04-07:09:10:06 1 0 0 0 0
01-04-07:08:50:06 01-04-07:09:00:06 1 1 1241311 0 1
01-04-07:08:10:06 01-04-07:08:50:06 1 0 0 0 0
01-04-07:08:00:06 01-04-07:08:10:06 1 1 1241296 0 1
01-04-07:02:50:06 01-04-07:08:00:06 1 0 0 0 0
01-04-07:02:40:06 01-04-07:02:50:06 1 1 1241233 0 1
31-03-07:06:10:06 01-04-07:02:40:06 1 0 0 0 0
31-03-07:06:00:06 31-03-07:06:10:06 1 1 1241127 0 1
31-03-07:05:50:06 31-03-07:06:00:06 1 0 0 0 0
31-03-07:05:40:06 31-03-07:05:50:06 1 1 1241123 0 1
31-03-07:04:30:06 31-03-07:05:40:06 1 0 0 0 0
31-03-07:04:20:06 31-03-07:04:30:06 1 1 1241106 0 1
31-03-07:03:40:06 31-03-07:04:20:06 1 0 0 0 0
31-03-07:03:30:06 31-03-07:03:40:06 1 1 1241096 0 1
31-03-07:12:40:06 31-03-07:03:30:06 1 0 0 0 0
31-03-07:12:30:06 31-03-07:12:40:06 1 1 1241061 0 1
31-03-07:09:00:06 31-03-07:12:30:06 1 0 0 0 0
31-03-07:08:50:06 31-03-07:09:00:06 1 1 1241019 0 1
31-03-07:07:40:06 31-03-07:08:50:06 1 0 0 0 0
31-03-07:07:30:06 31-03-07:07:40:06 1 0 1240993 36044 0
31-03-07:07:20:06 31-03-07:07:30:06 1 14 1240962 35798 1
31-03-07:07:10:06 31-03-07:07:20:06 1 15 1240481 35199 1
31-03-07:07:00:06 31-03-07:07:10:06 1 15 1239976 34599 1
31-03-07:06:50:06 31-03-07:07:00:06 1 47 1239445 33998 1
31-03-07:06:40:06 31-03-07:06:50:06 1 34 1237875 33398 1
31-03-07:06:30:06 31-03-07:06:40:06 1 49 1236645 32798 2
31-03-07:06:20:06 31-03-07:06:30:06 1 71 1235001 32196 1
31-03-07:06:10:06 31-03-07:06:20:06 1 70 1232730 31597 1
31-03-07:06:00:06 31-03-07:06:10:06 1 76 1230442 30998 1
31-03-07:05:50:06 31-03-07:06:00:06 1 84 1227894 30398 1
31-03-07:05:40:06 31-03-07:05:50:06 1 76 1225075 29796 1
31-03-07:05:30:06 31-03-07:05:40:06 1 73 1222488 29197 1
31-03-07:05:20:06 31-03-07:05:30:06 1 68 1220060 28599 1
31-03-07:05:10:06 31-03-07:05:20:06 1 84 1217758 27998 1
31-03-07:05:00:06 31-03-07:05:10:06 1 89 1214851 27400 1
31-03-07:04:50:06 31-03-07:05:00:06 1 83 1212051 26800 1
31-03-07:04:40:06 31-03-07:04:50:06 1 80 1209236 26196 1
31-03-07:04:30:06 31-03-07:04:40:06 1 89 1206529 25596 1
31-03-07:04:20:06 31-03-07:04:30:06 1 97 1203482 24997 1
31-03-07:04:10:06 31-03-07:04:20:06 1 71 1200410 24399 1
31-03-07:04:00:06 31-03-07:04:10:06 1 67 1197954 23798 1
31-03-07:03:50:06 31-03-07:04:00:06 1 45 1195795 23199 1
31-03-07:03:40:06 31-03-07:03:50:06 1 47 1194212 22600 2
31-03-07:03:30:06 31-03-07:03:40:06 1 41 1192715 21997 2
31-03-07:03:20:06 31-03-07:03:30:06 1 37 1191248 21397 1
31-03-07:03:10:06 31-03-07:03:20:06 1 36 1189931 20799 1
31-03-07:03:00:06 31-03-07:03:10:06 1 44 1188796 20197 2
31-03-07:02:50:06 31-03-07:03:00:06 1 43 1187383 19599 1
31-03-07:02:40:06 31-03-07:02:50:06 1 39 1185915 18998 1
31-03-07:02:30:06 31-03-07:02:40:06 1 31 1184599 18396 1
31-03-07:02:20:06 31-03-07:02:30:06 1 28 1183467 17799 1
31-03-07:02:10:06 31-03-07:02:20:06 1 49 1182421 17197 1
31-03-07:02:00:06 31-03-07:02:10:06 1 42 1180868 16599 1
31-03-07:01:50:06 31-03-07:02:00:06 1 32 1179471 15997 1
31-03-07:01:40:06 31-03-07:01:50:06 1 28 1178359 15397 1
31-03-07:01:30:06 31-03-07:01:40:06 1 22 1177398 14798 1
31-03-07:01:20:06 31-03-07:01:30:06 1 31 1176637 14200 1
31-03-07:01:10:06 31-03-07:01:20:06 1 22 1175647 13598 1
31-03-07:01:00:06 31-03-07:01:10:06 1 24 1174905 12998 1
31-03-07:12:50:06 31-03-07:01:00:06 1 29 1174035 12399 1
31-03-07:12:40:06 31-03-07:12:50:06 1 28 1173182 11799 1
31-03-07:12:30:06 31-03-07:12:40:06 1 29 1172238 11196 1
31-03-07:12:20:06 31-03-07:12:30:06 1 41 1171218 10597 1
31-03-07:12:10:06 31-03-07:12:20:06 1 36 1169858 9996 1
31-03-07:12:00:06 31-03-07:12:10:06 1 37 1168712 9400 1
30-03-07:11:50:06 31-03-07:12:00:06 1 29 1167462 8800 1
30-03-07:11:40:06 30-03-07:11:50:06 1 36 1166494 8198 1
30-03-07:11:30:06 30-03-07:11:40:06 1 15 1165322 7595 1
30-03-07:11:20:06 30-03-07:11:30:06 1 33 1164731 7000 1
30-03-07:11:10:06 30-03-07:11:20:06 1 34 1163662 6398 1
30-03-07:11:00:06 30-03-07:11:10:06 1 19 1162536 5799 1
BEGIN_TIME END_TIME UNDOTSN UNDOBLKS TXNCOUNT MAXQUERYLEN MAXCONCURRENCY
30-03-07:10:50:06 30-03-07:11:00:06 1 3 1161912 5198 1
30-03-07:10:40:06 30-03-07:10:50:06 1 21 1161684 4600 1
30-03-07:10:30:06 30-03-07:10:40:06 1 15 1160961 3994 1
30-03-07:10:20:06 30-03-07:10:30:06 1 22 1160471 3398 1
30-03-07:10:10:06 30-03-07:10:20:06 1 14 1159912 2797 1
30-03-07:10:00:06 30-03-07:10:10:06 1 19 1159306 2197 1
30-03-07:09:50:06 30-03-07:10:00:06 1 22 1158660 1599 2
30-03-07:09:40:06 30-03-07:09:50:06 1 23 1157932 998 1
30-03-07:09:30:06 30-03-07:09:40:06 1 310 1157252 397 1
30-03-07:09:20:06 30-03-07:09:30:06 1 639 1147136 8982 1
30-03-07:09:10:06 30-03-07:09:20:06 1 656 1126682 8466 1
30-03-07:09:00:06 30-03-07:09:10:06 1 614 1105445 7872 1
30-03-07:08:50:06 30-03-07:09:00:06 1 530 1086027 7273 1
30-03-07:08:40:06 30-03-07:08:50:06 1 592 1068894 6673 1
30-03-07:08:30:06 30-03-07:08:40:06 1 523 1049506 6071 1
30-03-07:08:20:06 30-03-07:08:30:06 1 495 1032303 5469 1
30-03-07:08:10:06 30-03-07:08:20:06 1 453 1016034 4872 1
30-03-07:08:00:06 30-03-07:08:10:06 1 596 1001203 4270 1
30-03-07:07:50:06 30-03-07:08:00:06 1 608 981490 3673 1
30-03-07:07:40:06 30-03-07:07:50:06 1 538 961665 3072 1
30-03-07:07:30:06 30-03-07:07:40:06 1 672 943888 2470 1
30-03-07:07:20:06 30-03-07:07:30:06 1 514 921746 1872 1
30-03-07:07:10:06 30-03-07:07:20:06 1 626 904991 1272 1
30-03-07:07:00:06 30-03-07:07:10:06 1 639 884520 673 1
30-03-07:06:50:06 30-03-07:07:00:06 1 1152 863391 71 2
30-03-07:06:40:06 30-03-07:06:50:06 1 1372 826601 1 1
30-03-07:06:30:06 30-03-07:06:40:06 1 1388 782802 1 2
30-03-07:06:20:06 30-03-07:06:30:06 1 1112 738525 1 1
30-03-07:06:10:06 30-03-07:06:20:06 1 868 703117 1 1
30-03-07:06:00:06 30-03-07:06:10:06 1 893 675366 1 1
30-03-07:05:50:06 30-03-07:06:00:06 1 928 647203 1 1
30-03-07:05:40:06 30-03-07:05:50:06 1 947 617581 1 1
30-03-07:05:30:06 30-03-07:05:40:06 1 978 587484 1 1
30-03-07:05:20:06 30-03-07:05:30:06 1 936 556226 1 1
30-03-07:05:10:06 30-03-07:05:20:06 1 918 526276 1 1
30-03-07:05:00:06 30-03-07:05:10:06 1 932 497074 1 1
30-03-07:04:50:06 30-03-07:05:00:06 1 927 467362 2 1
30-03-07:04:40:06 30-03-07:04:50:06 1 1329 438582 1 1
30-03-07:04:30:06 30-03-07:04:40:06 1 1351 397740 1 1
30-03-07:04:20:06 30-03-07:04:30:06 1 1369 356486 1 1
30-03-07:04:10:06 30-03-07:04:20:06 1 1176 314700 1 1
30-03-07:04:00:06 30-03-07:04:10:06 1 1050 278472 1 1
30-03-07:03:50:06 30-03-07:04:00:06 1 830 246238 1 1
30-03-07:03:40:06 30-03-07:03:50:06 1 829 220880 1 1
30-03-07:03:30:06 30-03-07:03:40:06 1 836 195269 1 1
30-03-07:03:20:06 30-03-07:03:30:06 1 820 169657 1 1
30-03-07:03:10:06 30-03-07:03:20:06 1 811 144400 1 1
30-03-07:03:00:06 30-03-07:03:10:06 1 839 119539 1 2
30-03-07:02:50:06 30-03-07:03:00:06 1 793 93792 1 1
30-03-07:02:40:06 30-03-07:02:50:06 1 319 69540 18 1
30-03-07:02:10:06 30-03-07:02:40:06 1 0 0 0 0
30-03-07:02:00:06 30-03-07:02:10:06 1 1 59711 15 1
30-03-07:01:50:06 30-03-07:02:00:06 1 5 59611 0 2
30-03-07:01:40:06 30-03-07:01:50:06 1 64 59471 17 2
30-03-07:01:30:06 30-03-07:01:40:06 1 87 57401 45 1
30-03-07:01:20:06 30-03-07:01:30:06 1 67 56335 1 1
30-03-07:01:10:06 30-03-07:01:20:06 1 32 53993 1 1
30-03-07:01:00:06 30-03-07:01:10:06 1 111 52889 1 1
30-03-07:12:50:06 30-03-07:01:00:06 1 117 49106 1 1
30-03-07:12:40:06 30-03-07:12:50:06 1 120 45084 1 1
30-03-07:12:30:06 30-03-07:12:40:06 1 25 40969 1 1
30-03-07:12:20:06 30-03-07:12:30:06 1 123 40059 1 2
30-03-07:12:10:06 30-03-07:12:20:06 1 122 35881 1 1
30-03-07:12:00:06 30-03-07:12:10:06 1 124 31654 6 1
30-03-07:11:50:06 30-03-07:12:00:06 1 116 27421 5 1
30-03-07:11:40:06 30-03-07:11:50:06 1 121 23301 1 1
30-03-07:11:30:06 30-03-07:11:40:06 1 118 19286 3 1
30-03-07:11:20:06 30-03-07:11:30:06 1 124 15105 1 1
30-03-07:11:10:06 30-03-07:11:20:06 1 116 10981 1 1
30-03-07:11:00:06 30-03-07:11:10:06 1 108 6843 1 1
30-03-07:10:50:06 30-03-07:11:00:06 1 1 3272 0 1
30-03-07:10:40:06 30-03-07:10:50:06 1 0 0 0 0
30-03-07:10:30:06 30-03-07:10:40:06 1 73 3110 1 1
30-03-07:10:20:06 30-03-07:10:30:06 1 12 591 2 1
30-03-07:08:30:06 30-03-07:10:20:06 1 0 0 0 0
30-03-07:08:20:06 30-03-07:08:30:06 1 8 7 1 1
all the reamining columns are 0 in v$undostat
Regards,
Karthik
Message was edited by:
karthi_knk

Hi,
Is it development database or production? if it is development then check the pl/sql coding for undo generation. undo is generated by DML statements and there is rule exists for Optimal sizing of undo.. Kindly check for the commits at the proper places?? (if you can get the chance to tune the codes would be great .. go through the logics of the codes and create sub-procedure to commit after every 50000 records insertion/deletion/modfication)
if you are using Enterprise manager then follow this
http://www.oracle.com/technology/products/oracle9i/daily/may14.html
and follow this otherwise:
http://www.iselfschooling.com/FREE_Oracle_Training/03_DBAs/02_Performance/lesson10.html
Thanks
--Raman

Undo tablespace in RAC

hi all,
In RAC environment, if iam having two nodes, why i have to maintain two undotablespaces in shared area? is it not possible to use one undo tablespace for both the instances instead of two undo tablespaces?
thank you

Hello Buddy,
It is not possible use one UNDO tablespace for more than one instance in RAC architecture.
Unless that you implement rollback segs (forget it, totally unrecommended), then the entire database can use only one rollbackseg on shared storage.
You must maintain unless one undo tbs per instance on your cluster database cause consistent reads on local instances.
Best Regards,
Rodrigo Mufalani
http://mufalani.blogspot.com

Unable to extend segment by 8 in undo tablespace 'UNDOTBS1'

Hi All,
I have enabled the Oracle flashback data archive.
Undo tbs size is unlimited. Whenevr i enable FBDA i am getting the below error. when i disable this feature the error is not coming.
My Oracle version is 11.0.2.0
ORA-30036: unable to extend segment by 8 in undo tablespace 'UNDOTBS1'
ORA-02002: error while writing to audit trail
ORA-00604: error occurred at recursive SQL level 1
ORA-30036: unable to extend segment by 8 in undo tablespace 'UNDOTBS1'
; nested exception is java.sql.SQLException: ORA-00604: error occurred at recursive SQL level 1
can anyone help me to solve the issue would be very much helpful.
thanks
Mohan

ORA-30036: unable to extend segment by 8 in undo tablespace 'UNDOTBS1'
30036, 00000, "unable to extend segment by %s in undo tablespace '%s'"
// *Cause:   the specified undo tablespace has no more space available.
// *Action: Add more space to the undo tablespace before retrying
//           the operation. An alternative is to wait until active
//           transactions to commit.

Fragmentation in Undo TBS

Similar Messages

Maybe you are looking for