Undo tablespace space usage

I am sorry If someone asked this question before
Oracle version : 10.2.0.3.0
OS : Linux
Tablespace Name           Tablespace Size (in MB)       Used (in MB)       Free (in MB) Pct. Used
UNDOTBS1                                    2,000              1,826                174        91
SELECT tablespace_name TSPACE, status, COUNT(*) AS Segments, sum(bytes)/1024/1024 as "TOTAL_SIZE(MB)"
FROM dba_undo_extents
GROUP BY tablespace_name, status
SQL> SQL>   2    3    4
TSPACE               STATUS                 SEGMENTS TOTAL_SIZE(MB)
UNDOTBS1             EXPIRED                     464      1825.9375My all undo segments are expired but undo tablespace shows as 91 % used. Is there any workaround for avoiding this?
Thanks
Nisanth V.S

This could be a normal situation: see http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:676925300346249247#711734500346983254. A 2 GB undo tablespace is a small one and I would not worry about having a lot of expired undo segments.
You can also use V$UNDOSTAT to check undo tablespace usage for the last 7 days.

Similar Messages

Monitor tablespace space usage, excluding UNDO

Hi
I tried to setup a monitoring template that enables me to monitor the space usage of all tablespaces but UNDO. It seems to me that Grid Control does not provide this built-in feature and I cannot customize. It monitors ALL tablespaces usage.
If I create RULE, then I need to check all tablespaces names except UNDO. I have almost 200 databases. If doing that, it consumes huge amounts of time.
Any solutions???
Any input is appreciated.
Kevin

The current setting is
Tablespace Space Used (%)
UNDOTBS > 101 101 None Every 5 Minutes
All others > 5 10 None Every 5 Minutes
Does that mean that if UNDOTBS is 101% full, which never happens, I will get email.
OEM will not evaluate the second condition if the first condition dissatisfies. If that is the case, I shall never get email.
Then I think I shall reverse the order. When I tried to use [Reorder] button, I cannot reverse the order. Probably, OEM considers [All Others] as the last execution conditionl.
Kevin

Undo tablespace reached to 99.99 %

Hi all,
I am using Oracle Apex 3.1 & Database oracle 10g Release 1002000100 on HP-Unix
my Undo Tablespace is increasing Regularly, I turned off its auto Extent,
On Querying thru v$Session
user APEX_PUBLIC_USER,osuser Apache are
logged on for 16 times,
my Undo tablespace reached to 99.99 %
I now added more 500 MB,
Again it occupied to 99.99 %
I didnt temper with Undo tablespace,
usinG Default Settings except i did Auto EXTENT Turned off,
please Suggest me the Fixing & cause for this
many thanks
-Khaja
Edited by: ahuja on Feb 7, 2009 3:26 PM

Hi all
i tried with the Following
SQL> SELECT SUM(a.bytes) "UNDO_SIZE"
2 FROM v$datafile a,
3 v$tablespace b,
4 dba_tablespaces c
5 WHERE c.contents = 'UNDO'
6 AND c.status = 'ONLINE'
7 AND b.name = c.tablespace_name
8 AND a.ts# = b.ts#;
UNDO_SIZE
1.4680E+10
SQL>
SQL> SELECT MAX(undoblks/((end_time-begin_time)*3600*24))
2 "UNDO_BLOCK_PER_SEC"
3 FROM v$undostat;
UNDO_BLOCK_PER_SEC
59.7333333
SELECT d.undo_size/(1024*1024) "ACTUAL UNDO SIZE [MByte]",
SUBSTR(e.value,1,25) "UNDO RETENTION [Sec]",
ROUND((d.undo_size / (to_number(f.value) *
g.undo_block_per_sec))) "OPTIMAL UNDO RETENTION [Sec]"
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'
ACTUAL UNDO SIZE [MByte] UNDO RETENTION [Sec] NEEDED UNDO SIZE [MByte]
14000 900 420
Now my Undo tablespace reached 99% Again, i wanted to know the what is eating my Undo tablespace Space
Do I need to drop and recreate a new undo tablespace? I don't want to do this until I understand what is eating all the space. Please help me here
please Help me out
many many thanks
- Khaja
Edited by: ahuja on Feb 14, 2009 4:42 PM
Edited by: ahuja on Feb 14, 2009 4:44 PM

(10gR2)Full UNDO tablespace

(10gR2)Full UNDO tablespace
============================
PURPOSE
10gR2 에서 UNDO tablespace 을 NO AUTOEXTEND로 생성한 경우 ,
transaction 이 실행중인 database 에서는 UNDO tablespace 가
FULL인 현상을 보게 됩니다.
이는 10gR2 에서 max retention 을 보장하는 undo retention 의
메카니즘이 소개되어 autoextend off 인 경우의 UNDO tablespace
에서 나타나는 현상입니다.
dba_undo_extents 에서 많은 UNEXPIRED undo segment 가 보이는 것이
확인되고 UNDO tablespace 가 100% full 인것처럼 나타나는 현상을 볼 수
있으며 그럼에도 불구하고 ORA-1555 나 ORA-30036 에러는 발생하지 않습니다.
Explanation
다음과 같이 많은 UNEXPIRED undo segment 가 조회됩니다.
SQL> select count(status) from dba_undo_extents where status = 'UNEXPIRED';
COUNT(STATUS)
463
SQL> select count(status) from dba_undo_extents where status = 'EXPIRED';
COUNT(STATUS)
20
SQL> select count(status) from dba_undo_extents where status = 'ACTIVE';
COUNT(STATUS)
21
dba_free_space 을 조회 결과 UNDO tablespace 의 free space 가 존재합니다.
SUM(BYTES)/(1024*1024) TABLESPACE_NAME
3 UNDOTBS1
58.4375 SYSAUX
3 USERS3
4.3125 SYSTEM
103.9375 USERS04
Transaction 이 실행되면 UNDO tablespace 에 free space 가 조회되지 않는
FULL 인것처럼 보입니다.
SUM(BYTES)/(1024*1024) TABLESPACE_NAME
58.25 SYSAUX
98 USERS3
4.3125 SYSTEM
87.9375 USERS04
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
다음은 AUM 에서의 Undo Block 할당 알고리즘은 다음과 같습니다.
1. current extent 에 free block 이 있으면 다음 free block 이
할당됩니다.
2. 그러나, free block 이 없으면, next extent 가 expired 되었다면 next extent 을
warp 한후 그 next extent 의 처음 block 을 return 합니다.
3. 만약 next extent 가 expired 되지 않았다면 UNDO tablespace 로부터 먼저
space 을 찾습니다. 이때 free extent 가 존재한다면 이를 transaction table 에
할당하고 해당 next extent 의 첫번째 block 을 return 합니다.
4. 만약 UNDO tablespace 에 free extent 가 없다면 offline 된 transaction table
에서 steal 합니다.
offline 된 transaction table 에서 extent 을 deallocate 한후 이를
current transaction table 에 add한후 그 add 한 extent 의 첫번째 free block 을
return 합니다.
5. offline 된 transaction table 에서 찾을수 없으면 , online 되어 있는
transaction table 에서 steal 합니다. offline 된 transaction table 에서 extent 을
deallocate 한후 이를 current transaction table 에 add한후 , 그 add 한 extent 의
첫번째 free block 을 return 합니다.
6. 1번~5번 까지 하여도 free block 을 얻지 못하면 이제 UNDO tablespace 의 file 을
extend 합니다.
file 이 extend 된다면 이후 current transaction table 에 extent 을 add 한후 ,
그 extent 의 첫번째 free block 을 return 합니다.
7. 6번 에서 UNDO tablespace 의 file 을 extend 하지 못했다면 , 자기의 transaction table
에서 unexpired 된 extent 을 재사용합니다. 그런데 이때 모든 extent 가 busy 하다면
즉 모두 uncommitted 된 정보라면 8번으로 갑니다. 아니라면 wrap 하여 unexpired 된
extent 을 사용합니다.
8. offline 된 transaction table 에서 unexpired 된 extent 을 steal 합니다. 이것이
실패한다면 online 된 transaction table 에서 unexpired 된 extent 을 steal 합니다.
9. 8 번까지 수행하고도 free block 을 얻지 못하면 이때서야 오라클에서는
"ORA-30036 unable to extend segment by %s in undo tablespace '%s' " 에러를
뿌리며 실패합니다.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
fixed size UNDO tablespace 라 함은 autoextend 가 off 라 datafile 을 자동으로
더 이상 확장할 수 없음을 말합니다.
autoextend 가 off 인 경우 10.2 부터는 max retention 이 36 시간 입니다.
undo_retention 을 900 초(15 분) 으로 설정을 한다고 해도 10gR2 에서는
max retention 이 36 시간이라 이에 해당하는 undo extent 을 UNEXPIRED 으로 만듭니다.
그러나 이것이 가용한 undo extent 가 없다는 것이 아니고 , transaction 이 실행되게 되면
UNEXPIRED undo segment 을 재사용하게 됩니다.
References
< Note 413732.1 - Full UNDO Tablespace In 10gR2 >

A undo tablespace almost full is not necessarily a problem with Oracle 10g ... unless you have some ORA-XXXX errors in the database instance alert.log or in client programs connected to the instance. Is this the case ?
You should also have a look to V$UNDOSTAT which stores undo statistics for the last 7 days.
This view has also 2 interesting columns about possible errors related to undo space:
SOLDERRCNT NUMBER Identifies the number of times the error ORA-01555 occurred. You can use this statistic to decide whether or not the UNDO_RETENTION initialization parameter is set properly given the size of the undo tablespace. Increasing the value of UNDO_RETENTION can reduce the occurrence of this error.
NOSPACEERRCNT NUMBER Identifies the number of times space was requested in the undo tablespace and there was no free space available. That is, all of the space in the undo tablespace was in use by active transactions. The corrective action is to add more space to the undo tablespace.

Free space in UNDO tablespace

Hi,
in DB version 9.2.0, after all transactions are committed, the occupied blocks in UNDO tablespace will be free or not ?
The same just after startup, before any transaction the free space in UNDO tablespace would be at max ?
Many thanks.

Hello Dear copy this script and paste in the sql prompt and it will show your how much total space table have, or how much is used and how much it is free
SELECT Total.name "Tablespace Name",
nvl(Free_space, 0) Free_space,
nvl(total_space-Free_space, 0) Used_space,
total_space
FROM
(select tablespace_name, sum(bytes/1024/1024) Free_Space
from sys.dba_free_space
group by tablespace_name
) Free,
(select b.name, sum(bytes/1024/1024) TOTAL_SPACE
from sys.v_$datafile a, sys.v_$tablespace B
where a.ts# = b.ts#
group by b.name
) Total
WHERE Free.Tablespace_name(+) = Total.name
ORDER BY Total.name

How to exclude undo and temp from "Tablespace Space Used (%)"

Dear All
Is it possible to exclude undo and temp tablespace monitoring from "Tablespace Space Used (%)" matric?
Thanks & Regards
Quazi Abdur Rab

If you use TEMP >=100 as Warning, this warning can still be raised.
What version of the database is it? If Oracle 10g, Grid Control (the agent) searches the alert table in the database for alerts, so the database raises the alert and the agent just passes this alert to Grid Control.
If you are using Oracle 10g, you can use the following statement (connected as sys):
DBMS_SERVER_ALERT.SET_THRESHOLD(
metrics_id => DBMS_SERVER_ALERT.TABLESPACE_PCT_FULL,
warning_operator => DBMS_SERVER_ALERT.OPERATOR_GT,
warning_value => '90',
critical_operator => DBMS_SERVER_ALERT.OPERATOR_GT,
critical_value => '100',
observation_period => 1,
consecutive_occurrences => 1,
instance_name => NULL,
object_type => DBMS_SERVER_ALERT.OBJECT_TYPE_TABLESPACE,
object_name => 'TEMP');
This will create the GT (Greater Than) instead of GE (Greater Equal).
Kind regards,
Dave
ps. I'm using GC 10.2.0.3.0, so thanks for the note that 10.2.0.4 doesn't take 100+ values.

UNDO Tablespace usage

Hi All,
My undo tablespace is 97% full.
Is there any way to check which process is using more undo tablespace.
Thansk in Advance for your response.
Regards,
Ashwani N.

# UNDO tablespace usage
select a.process, a.program, a.module, a.machine, b.USED_UREC, c.sql_text
from v$sql c, v$session a, v$transaction b
where b.addr = a.taddr
and a.sql_address = c.address
and a.sql_hash_value = c.hash_value
order by b.USED_UREC;
SELECT s.sid , s.username , t.used_ublk
FROM v$transaction t
, v$session s
WHERE 1 = 1
AND t.ses_addr = s.saddr
column username format a15;
column segment_name format a15;
SELECT s.sid , s.username , t.used_ublk, round((t.used_ublk*8)/1024) size_in_MB_8kb_Block_size, round((t.used_ublk*16)/1024
) size_in_MB_16kb_Block_size
FROM v$transaction t
, v$session s
WHERE 1 = 1
AND t.ses_addr = s.saddr;
SELECT distinct rpad(s.sid,3) "SID",S.USERNAME,
E.SEGMENT_NAME,
T.START_TIME "Start",
rpad(T.STATUS,9) "Status",
round((t.used_ublk*8)/1024) "Size(MB)"
--T.USED_UBLK||' Blocks and '||T.USED_UREC||' Records' "Rollback Usage"
FROM DBA_DATA_FILES DF,
DBA_EXTENTS E,
V$SESSION S,
V$TRANSACTION T
WHERE DF.TABLESPACE_NAME = E.TABLESPACE_NAME AND
DF.FILE_ID = UBAFIL AND
S.SADDR = T.SES_ADDR AND
T.UBABLK BETWEEN E.BLOCK_ID AND E.BLOCK_ID+E.BLOCKS AND
E.SEGMENT_TYPE in( 'ROLLBACK','TYPE2 UNDO'source:-
http://blog.contractoracle.com/2008/08/undo-tablespace-usage.html

Undo tablespace growing without reusing space

Hi,
I'm running an Oracle9i database on Solaris. I am using the automatic undo management and I have one undo tablespace. The UNDO_RETENTION value is 900. I have created the undo tablespace this way (clause in create database statement):
UNDO TABLESPACE "UNDOTBS1" DATAFILE '/u04/oracle/oradata/my_dbname/undotbs01.dbf' SIZE 200M REUSE AUTOEXTEND ON NEXT 5120K MAXSIZE UNLIMITED
The undo tablespace datafile is now close to 3G. I have other servers running the same setup, and their undo datafile size is still 200M. There is currently no active transaction in the database. Any idea why this is happening? Is there any tables I can check for clues?
Many thanks,
Gloria

Should Oracle automatically shrink the undo tablespace (datafile) when it is not needed anymore? Say at one point the database really needs 3G of undo tablespace, but afterwards only 10M is needed, would the datafile be 'shrunk' back?
Also, how can I check if the database really needed the 3G of undo tablespace at one point? (I guess it's checking the level of activities in the database, but how do I do that for past data?)
I'm trying to decide whether the undo tablespace really grew due to a need at some point or is it a case of Bug 2660394 (documented in metalink note271119.1). The bug basically says that "An auto extensible undo tablespace MAY grow before reusing expired extents leading to more space use than actually needed".

UNDO tablespace increase more more .... spaces

I checked my Oracle database. I found undo tablespace increase more more spaces.
from 10G , now 40G
undo_retention = 15 minutes
Please help me
How I tune and monitor for track this problem?

Hello HunterX,
You have not indicated which version of database & on what platform. The Version number & platform is very important...I tell you why. Because i had the same issue with my database and handled successfully.
Please check the BUG No. Note:2660394.8 & also note no. 271119.1.
This explains that Undo tablespace is used and after the expiry of 15 minutes it does not use the EXPIRED extents. It again allocates the NEW extents out of your segment of the tablespace....And leads to continuous growing of UNDO Tablespace...
Do the follwoing i feel would be appropriate...Rest you can decide it better....
1. Create a New UNDO Tablespace may be undo_new of smaller size..
2. Do not keep autoextend ON and put some max size...may be 1 GB. Do not put it unlimited.
3. Stop the DB Instance
4. Change the name of new UNDO Tablespace in INIT.ORA file
5. Restart the DB Instance.....
6. drop the Old Tablespace UNDO & delete the datafile...
If stopping of DB Instance is not possible...(for production server), i hv few command which does the above on-line. But i do not remember them at this time...I will hv to refer my docs. If you feel i can try that for you...otherwise you may follwo above points.
Hope that helps to you. Thanks.
Regards,
Kamesh Rastogi

Drop undo tablespace but space not release (du and df show different value)

hi guys,
i just change my undo and drop the previous 1.
create undo tablespace UNDOTBS4 DATAFILE '/u03/oradata/starhub/undotbs4.dbf' size 2g;
Tablespace created.
SQL> ALTER SYSTEM SET UNDO_TABLESPACE = undotbs4;
System altered.
SQL> drop tablespace undotbs3 including contents and datafiles;
Tablespace dropped.
SQL>
However, when i check my diskspace using df -h , it is still showing. 32 gig is used. where infact, only 30G should be used.
71G 32G 37G 47% /u03
when i check using du -h, it is showing only
30G ./oradata
I have to bounce the database to get my 2G back, why ?
Is there anyway to get my 2G back without bouncing the DB ?
Regards,
Noob

Oracle has the file still open, so the i-node of that file is still in use, so the file shows up.
Learn your Unix!
Sybrand Bakker
Senior Oracle DBA

Problem with UNDO tablespace

Hi guys.
Our database has 50GB of undo tablespace. I decided to create a second undo tablespace and switch to the new one. Since doing that yesterday, the size of the old undo is 49GB (was thinking that the values will drop to zero) and the new tablespace keeps increasing in size! Its size now is about 20GB. I do have the following question.
a) If I restart the database, it the value of the old undo going to fall to zero?
b) undo_retention=86400. Setting this value to a lesser value say 800seconds, it is going to act the performance of the database? Is it going to release the space on the old undo?
Thanks and any help is appreciated.
David

The undo tablespace will not automatically shrink size, since you have a new undo tablespace in place. You can drop the old one if you don't plan to use it.
Set lower undo_retention will certainly help to contain the undo space usage. However you should query v$undostat and v$rollstat to estimate the amount of undo space required for the current workload then size the undo tablespace accordingly. Turn off the auto extend on undo tablespace.

Oracle 11.2.0.3 - Lob space usage

Hi Everyone,
I would like some advise about how to interrupt LOB space usage given the following statistics. And would appreciate any feedback on whether my understanding of the following is correct:
We have a table with BLOB column which is located on a LOB segment.
This the DDL to create the table and the LOB:
CREATE TABLE BLOB_TEST
TEST_ID      NUMBER NOT NULL,
TEST         BLOB
LOB (TEST) STORE AS (
TABLESPACE USERS
ENABLE      STORAGE IN ROW
CHUNK       8192
RETENTION
NOCACHE
LOGGING
      STORAGE    (
                  INITIAL          64K
                  NEXT             1M
                  MINEXTENTS       1
                  MAXEXTENTS       UNLIMITED
                  PCTINCREASE      0
                  BUFFER_POOL      DEFAULT
                  FLASH_CACHE      DEFAULT
                  CELL_FLASH_CACHE DEFAULT
TABLESPACE USERS
RESULT_CACHE (MODE DEFAULT)
PCTUSED    0
PCTFREE    30
INITRANS   10
MAXTRANS   255
STORAGE    (
            INITIAL          64K
            NEXT             1M
            MINEXTENTS       1
            MAXEXTENTS       UNLIMITED
            PCTINCREASE      0
            BUFFER_POOL      DEFAULT
            FLASH_CACHE      DEFAULT
            CELL_FLASH_CACHE DEFAULT
LOGGING
NOCOMPRESS
NOCACHE
NOPARALLEL
MONITORING;
The statistics for this table is as follows:
The size of the test blob is:
A.
select sum(dbms_lob.getlength (test))/1024/1024 mb from BLOB_TEST
= 4860 mb
Space above HWM ( using dbms_space.unused_space):
B.
TOTAL_BLOCKS = 778368
TOTAL_BYTES = 6376390656
UNUSED_BLOCKS = 0
UNUSED BYTES = 0
LAST_USED_EXTENT_FILE_ID = 12
LAST_USED_EXTENT_BLOCK_ID = 3383296
LAST_USED_BLOCK = 8192
Space below HWM (using dbms_space.used_space):
C.
TOTAL_BLOCKS = 778368
TOTAL_BYTES = 6376390656
UNUSED_BLOCKS = 0
UNUSED BYTES = 0
LAST_USED_EXTENT_FILE_ID = 12
LAST_USED_EXTENT_BLOCK_ID = 3383296
LAST_USED_BLOCK = 8192
Unformatted Blocks = 0
FS1 Blocks = 0
FS2 Blocks = 0
FS3 Blocks = 0
FS4 Blocks = 0
Full Blocks = 777114
Using the above, this is what I'm interrupting and need your help on this to make sure that this is right.
From A, the total size of the test blob data is: 4806 MB.
From B, the amount of free space ABOVE HWM is 0. This is because there is 0 in the unused_blocks.
From C, the amount of free space BELOW HWM is 0, because all the FS's are 0 and so is UNUSED_BLOCKS as well.
The amount of full blocks = 777114 blocks. This means that 615168 blocks (from 4806MB) is for data. The rest is for undo space as there is 0 for free space?
In addition to this, 778368 - 777114 = 1254 blocks = 9.8 mb (approx) of? I'm not sure what is this.
Am I on the right track here?
Thanks

Pavel wrote:
Hello!
I have Oracle 11.2.0.3 on Aix 64bit installed and see symptoms of bug 13443029 ,
have I downgrade to 11.2.0.2 to appling the patch for fixing this bug ?
README for *13443029*
Patch Details
Oracle Database 11g Release *11.2.0.2.0*
ORACLE DATABASE Patch for Bug# 13443029 for AIX5L Platforms
Released: 13 Jan, 2012Thanks and regards,
PavelOpen SR . you will get help and send you patch if they think its need that .

Unable to shrink undo tablespace... Help!

Hi,
I have problems to shrink the system undo tablespace, which has grown up to 14 GB.
I use 9.2. Table space owner is 'SYSTEM', undo_management = AUTO.
I tried to shrink the greatest rollback segments by the commands
ALTER SESSION SET UNDO_SUPPRESS_ERRORS = TRUE;
ALTER ROLLBACK SEGMENT "_SYSSMU6$" SHRINK TO 20 M;
Oracle confirmed these commands, but nothing happened.
What am I doing wrong?
Hermann Mueller

You have seen the discussion about the undo segments, on the temporary tablespaces, you should be aware that the sort segment of a given temporary tablespace is created at the time the first sort operation takes place. The sort segment continues to grow by means of extent allocation until the segment size has reached the total storage demands of all of the active sorts running on the instance. Oracle will keep on allocating temporary space on demand unless the physical limit states otherwise.
Temporary segments are produced each time a sort operation (explicit -order by- or implicit -aggregation, reindexing-) requires to sort a set that cannot fit into memory. So if you detect excesive sort usage you should aim your monitors towards the sort operations (reports, reindexing, max, min, aggregations, order by ...). If your system has a DDS behaviour, this kind of operations are frequent as a massive sorting has to be peformed against millions of rows.
A Temporary tablespace will almost always appear to be near 100% full, that's because once oracle has allocated temporary space it doesn't release it back to the free space, it keeps it allocated even when the sort operation has finished. Criteria behind this fact is similar to the one oracle used to have when the rollback segments were in use, Oracle only allocated space and the dba should perform manual actions to release space, and the criteria is performance. Once it has allocated space this big, there are possibilities that the same circumstances that raised the temporary usage high water mark to this level are repeated, so if oracle keeps the mamimum allocated space, it won't have to allocate the same storage once more.
Main concern with temporary tablespace growth is not free space itself, but the reasons why this amount of space was allocated, so I suggest you to track the sql statements with sort operations. If you are certain the circumstances that motivated this amount of temporary resources to be allocated won't be repeated again, then you could think of resizing down your temporary tablespace. I suggest you to create a new temporary tablespace with the desired size, and alter the default tempoary tablespace to point to this newly crated temporary tablespace, and finally get rid of the original temporary TS.
~ Madrid

Oracle DB : UNDO tablespace filled 99%

Hi,
That's not a problem (I hope) but just a question on Livecycle ES DataBase.
The Undo tablespace set to 4Gb, always filled 99%.
Is it normal ? is there preconized size for it ? Does we have to maintain it ...
The LiveCycle configuration is :
ES (1) version 8.2.1 SP3, Jboss
Oracle 10g
The server is running on Windows Server 2003 Ent OS.
Thank you for your response !

It very much depends on the tool used to determine the usage of the UNDO tablespace. Many tools do not take into account that the UNDO tablespace and the TEMP tablespace may seem to be full (have correctly formatted blocks) while still having a lot of functional space available inside of those blocks.
In other words, if the tool calculates the usage in the same way as data tablespaces, it will be reporting the wrong value. Ideally, the UNDO tablespace will always be close to 100% full using traditional calculation.
Assuming the tool is doing it's calculation correctly, the second thing to note is that UNDO is the core to Oracle Consistent Read mechanism. (Which is, in turn, the core to many of the Flashback techniques.) The UNDO data, which is created at transaction time, must be available after the transaction has committed if a consistent read or flashback is invoked. The more UNDO, the further back in 'time' you can flash back.
So the correct way to tune the UNDO is to specify the amount of time you require UNDO to exist. And you verify that using the DBA_UNDO_EXTENTS view and the STATUS column. Totally free space in the undo occurs when the STATUS is EXPIRED. If you have no EXPIRED extents, they can not be reused (except in a pinch) and the system will allocate more space to the UNDO tablespace if possible.
A great reference is the thread at http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:6894817116500
I am curious - is 4GB UNDO really an issue?

Is there so call "dedicated" UNDO tablespace in Oracle 9i and higher?

Since one of our applicaions needs to process large amounts of data, we have been using a dedicated rollback segment in order to avoid the "snapshot too old" problem.
Recently our DB upgraded to Oracle 9i and DBA asked us to use "undo" tablespace.
Based the Oracle 9i Doc., it only allows to select ONE undo tablespace at a time.
If so, DBA has to make the only UNDO as large as our Cash large transactions
need(adjust the UNDO_RENTION), which inevitably waste lots of space.
Does Oracle 9i allow to have one dedicated UNDO tablespace for large transactions while another one for regular transactions just like we use the old rollback segments.
Thanks in advance

Why have multiple UNDO tablespaces? You can only use one at a time, and when the other one is not being used, it still consumes storage space.
Spend a little time determining how much undo you need and size undo tablespace and undo retention around those values and you should be able to resolve the problems you are experiencing now.
http://download-east.oracle.com/docs/cd/B10501_01/server.920/a96521/undo.htm#9505

Undo tablespace space usage

Similar Messages

Maybe you are looking for