Undo retention and tablespace size

Situation:
Oracle 9.2.0.1 configured with undo_retention=10800 but with a 2GB size limit for the
undo tablespace with no autoextend.
As far as i know, with 10800 the undo tablespace could grown to around 10GB
but i'm not sure tho. I REALLY need to know if this is clearly a wrong setup (imho it
is) or could be an acceptable situation in some scenarios.
Thanks heap in advance.

Oracle 9.2.0.1 configured with undo_retention=108003 Hours? This is realy huge undo retention time.
with a 2GB size limit for the undo tablespace with no autoextend.You probably mean datafile not tablespace.
You don't need resize existing datafile you could just add another datafile to undo tablespace.

Similar Messages

Undo retention and ORA-01555

Dear Experts,
Oracle 9.2.0.6 (Hp-ux 11.11).
How undo retention and snapshot too old error are related to each other ?
As per my understanding undo retention is only a request and if a transaction is running out of space, it will use space secured by undo retention.
Thanks & Regards
Sunil Kumar

user13151642 wrote:
Dear Experts,
Oracle 9.2.0.6 (Hp-ux 11.11).
How undo retention and snapshot too old error are related to each other ?
As per my understanding undo retention is only a request and if a transaction is running out of space, it will use space secured by undo retention.
Yes, that's why oracle never said in 9i, where this parameter came into existence for the first time that setting it would completely remove the ora1555 issue. If the space is not there and there are incoming transactions requiring the space for their Undo, Oracle can and will overwrite the previously stored Undo leading to the error. That's the reason, you have the Undo Retention guarantee from 10g onwards which ensures that for the time period mentioned, there won't be any overwriting of the Undo data. But, this comes with an issue as well because since now, there is no overwriting of the previosuly written Undo data. the incoming transactions would fail because they won't be able to log their Undo data anymore.
Aman....

Message deleting and tablespace size

I have run deleting job for xml messages and history. But the size of Oracle tablespace is not reduced.
Is it my mistake or tablespace will be clean later?

i 've had a problem like you..
you know, unfortunately, i did not solve the your problem and i have a face with the problem ...
so, if you had solved the problem, will you give me a information for solving ?
my e-mail : [email protected] ...i hope you had found a solution..

UNDO retention causing excessive I/O ?

New DBA here.
Quick Summary:
We have an oracle 10gR2 DB on AIX 5.3. OS runs from the box, Database runs from a san. Aside from the DB, there is a web based application running on the box, which uses the DB.
System is dedicated to this application.
We have a consulting company that is making suggestions, and I am not sure about some of them.
When we set up the software, the vendor told us to set up the database with undo retention to 10800. So we did.
Our consulting group is telling me that Undo I/O represents 34% of the total database I/O, and that I should reduce the retention time to 1080. *(they also tell me that the longest running query is 100s; I don't quite understand how this is relevent).
Why would reducing the UNDO retention lenght reduce the UNDO I/O ?

First you need to check the concept of UNDO, the main purpose of undo are:
Rollback an active transaction
Recover a terminated transaction
Provide read consistency
Recovery from logical corruptions
http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/logical.htm#sthref449
also check undo retention,
The undo retention period indicates the amount of time that must pass before old undo information—that is, undo information for committed transactions—can be overwritten.
As you can see, there's no direct relationship between undo retention and database I/O. Reduce undo retention will not reduce database I/O.
Besides, the UNDO_RETENTION initialization parameter is ignored unless retention guarantee is enabled.
*(they also tell me that the longest running query is 100s; I don't quite
understand how this is relevent).The relevant here is your undo retention should be longer than longest running query (and undo space is big enough to hold the undo data of longest query) , so that you don't have out-of-space conditions in the undo tablespace and ORA-1555 error for consistent reading.
However again, it's relevant to undo setting not database IO.

Cacluation of undo tablespace size and retenion

How to calaculate the expected size of the undo tablespace and undo retention parameter from the exisitng data.

The easiest way to calculate undo requirementes is using the undo advisor, it is available in 10g and 9i. This is a graphical tool that lets you know the amount of required undo space according to your generated undo data.
Regards.

UNDO Tablespace size

Hi,
We have a production database with size 120GB (DB Version 11.1.0.6), And our UNDO Tablespace size is 30GB.
For the past 4 days the UNDO tablespace utilization is more than 85%.
We have disabled the AUTOEXTEND for the UNDO Tablespace.
So the UNDO RETENTION is dynamically calculated by Oracle itself and the value now is
TUNED_UNDORETENTION
339183
Please suggest how to fix this issue.
Thanks !

Hi,
The UNDO Tablespace size is still increasing. We dont have flashnack enabled for our database.
The database is 11.1.0.6 Standard Edition.
TABLESPACE TOTAL_SIZE_IN_MB FREE_SPACE_IN_MB % FREE %USED
UNDOTBS1 32152 4440 14 86.19
USERS 123784 23120 19 81.32
SYSTEM 1536 465 30 69.73
SYSAUX 1024 449 44 56.15
GGS_DATA 2048 1388 68 32.23
We enabled AUTOEXTEND on for one of the datafiles in UNDO Tablespace.
NAME TYPE VALUE
undo_management string AUTO
undo_retention integer 9000
undo_tablespace string UNDOTBS1
select to_char(begin_time, 'DD-MON-RR HH24:MI') begin_time,
to_char(end_time, 'DD-MON-RR HH24:MI') end_time, tuned_undoretention
from v$undostat order by end_time;
BEGIN_TIME END_TIME TUNED_UNDORETENTION
23-DEC-11 18:15 23-DEC-11 18:25 375077
23-DEC-11 18:25 23-DEC-11 18:35 375678
23-DEC-11 18:35 23-DEC-11 18:45 376278
23-DEC-11 18:45 23-DEC-11 18:51 376578
Please let me know how can i reduce the space consumed by UNDO Tablespace.

How to estimate undo tablespace size in 11g?

I found someone document said, use this sql to estimate undo tablespace:
select (UR*(UPS*DBS))+(DBS*24) as "bytes" from (select value as UR from v$parameter where name='undo_retention'),(select (sum(undoblks)/sum(((end_time-begin_time)*86400))) as UPS from v$undostat),(select value as DBS from v$parameter where name='db_block_size');
but in my 11g database, the "select value as UR from v$parameter where name='undo_retention'" is 0. so above sql is always get 196608(8192*24)
How to estimate undo tablespace size in 11g?
Thanks very much!

for undo segments size you should turn it to be autoextend on as well undo management set to be AUTO
i.e
undo_managment='AUTO'
for retention see that link
Ora-01555, snapshot too old: rollback segment number 2 with name "_SYSSMU1
BTW as hemant stated leave it to be auto which is good approach but make sure enough space on disk has been
dedicated for undo segments are allowed to grow to the size they need to be based on the requested undo_retention.
Khurram

Tablespaces and block size in Data Warehouse

We are preparing to implement Data Warehouse on Oracle 11g R2 and currently I am trying to set up some storage strategy - unfortunately I have very little experience with that. The question is what are general advices in such considerations according table spaces and block size? I made some research and it is hard to find some clear answer, there are resources advising that block size is not important and can be left small (8 KB), others state that it is crucial and should be the biggest possible (64KB). The other thing is what part of data should be placed where? Many resources state that keeping indexes apart from its data is a myth and a bad practice as it may lead to decrease of performance, others say that although there is no performance benefit, index table spaces do not need to be backed up and thats why it should be split. The next idea is to have separate table spaces for big tables, small tables, tables accessed frequently and infrequently. How should I organize partitions in terms of table spaces? Is it a good idea to have "old" data (read only) partitions on separate table spaces?
Any help highly appreciated and thank you in advance.

Wojtus-J wrote:
We are preparing to implement Data Warehouse on Oracle 11g R2 and currently I am trying to set up some storage strategy - unfortunately I have very little experience with that. With little experience, the key feature is to avoid big mistakes - don't try to get too clever.
The question is what are general advices in such considerations according table spaces and block size? If you need to ask about block sizes, use the default (i.e. 8KB).
I made some research and it is hard to find some clear answer, But if you get contradictory advice from this forum, how would you decide which bits to follow ?
A couple of sensible guidelines when researching on the internet - look for material that is datestamped with recent dates (last couple of years), or references recent - or at least relevant - versions of Oracle. Give preference to material that explains WHY an idea might be relevant, give greater preference to material that DEMONSTRATES why an idea might be relevant. Check that any explanations and demonstrations are relevant to your planned setup.
The other thing is what part of data should be placed where? Many resources state that keeping indexes apart from its data is a myth and a bad practice as it may lead to decrease of performance, others say that although there is no performance benefit, index table spaces do not need to be backed up and thats why it should be split. The next idea is to have separate table spaces for big tables, small tables, tables accessed frequently and infrequently. How should I organize partitions in terms of table spaces? Is it a good idea to have "old" data (read only) partitions on separate table spaces?
It is often convenient, and sometimes very important, to separate data into different tablespaces based on some aspect of functionality. The performance thing was mooted (badly) in an era when discs were small and (disk) partitions were hard; but all your other examples of why to split are potentially valid for administrative. Big/Small, table/index, old/new, read-only/read-write, fact/dimension etc.
For data warehouses a fairly common practice is to identify some sort of aging pattern for the data, and try to pick a boundary that allows you to partition data so that a large fraction of the data can eventually be made read-only: using tablespaces to mark time-boundaries can be a great convenience - note that the tablespace boundary need not match the partition boudary - e.g. daily partitions in a monthly tablespace. If you take this type of approach, you might have a "working" tablespace for recent data, and then copy the older data to "time-specific" tablespace, packing it and making it readonly as you do so.
Tablespaces are (broadly speaking) about strategy, not performance. (Temporary tablespaces / tablespace groups are probably the exception to this thought.)
Regards
Jonathan Lewis

Tablespace size report for SQL and oracle servers

Hi All
is it possible to get tablespace size for all sql and oracle server in the form of report in SCOM.
Regards
Madhavi

Oracle: Table size report of Oracle is depend on the MP which yu imported into SCOM
SQL :
1) Create a group which contains folowing dynamic rule
2) Reporting workspace --> Microsoft Gneric Report --> Performace Detail
3) in the parameter area, create a new series, add group which create in step 1) and select the rule: MSSQL XXX: Collect Database Allocated Size(MB)
4) Run the report
5) In the report, click actions and select "Performance details for every object"
Roger

UNDO Retention on 10.2.0.2

We are noticing some of these snapshot too old errors 01555 errors and we are not making use of any of the flashback functionality so I believe we are only interested in the undo table keeping the undo data while the transaction itself is active to ensure read consistency.
Previously we had undo_retention set to 10800 (3 hours) and I am thinking I should shrink this so that we only keep data as long as the transaction is active. If I set the undo retention length to a value like 300 (5 minutes) and a transaction takes 20 minutes am I going to get snapshot too old errors?
I am hoping the behavior is to keep the transaction data in the undo segment as long as the transaction is active for a minimum of undo_retention time and it would keep making use of space until it runs out of space that is not being used by some other transaction and not being held because of the 5 minutes retention. Is this how it will behave or after the 5 minutes will other transactions be able to overwrite this undo data causing an error even if there is other free space?
Some of the documentation seemed to say the undo_retention is a minimum recommendation to oracle. So if I don't care about flashback at all would a setting like 1 be reasonable assuming it would keep stuff as long as the transaction lasts +1 second(suggesting 1 since 0 means use the default of 900 aka 15 minutes)? I saw some other documentation suggesting setting it to the value of your longest transaction but I surely don't want to keep data from shorter transactions as long as my longest transaction as that would require a much larger undo tablespace so I am trying to figure out the most efficient setting to ensure consistency while being as space efficient as possible.
Thanks,
Jared

Thank you for all the replys on this thread those plus some stuff I have read in metalink have been very helpful. Have some follow up related questions.
From what I have read when a block is modified it goes into the undo in one of the segments and has an associated SCN number for each change.
1. If one DB connection does a series of updates to a given block and then disconnects (assume each update autocommits) and then the process is restarted and does more updates to the same block would it re-use the existing undo segment? (assuming that no select statements reference this block and cause it to be flushed) Does a new transaction on a given block imply a segment switch is a new select intersecting with a datablock the only thing that would cause it to change segments?
2. In the same scenario as above with a select happening between the two passes I am assuming that the select would cause it to flush the block (update the actual data) and that the second pass of updates on the same block would do the updates in a different undo segment? Does having a higher retention setting make it more likely to keep rotating segments as opposed to overwriting a previous one? In other words if I have my retention set to some very high amount of time like 10 days would it rotate all of the segments for that block before overwriting the first change?
My application currently has one process that does large queries that could last 5 hours or so at worst(all read only). And another process that does only new inserts.
Trying to figure out the exact behavior of how the undo retention manages switching undo segments to determine what is causing our problems. I have noticed on 10g2 that the number of undo segments is 10 and on 9.2.0.5 it was more like 108 or so and it seems like 10 is more likely to get 1555 errors and I am wondering if this is because it is more likely to cycle all segments and start overwriting blocks that are needed for a long running queries consistency.
Thanks,
Jared

Undo retention is set as too less makes flaskback query fails, why?

Hi All,
I got a email that some important records has benn deleted. I tried to use flaskback query to see those deleted records.
I did not found image of table 2 hours older.
query I am using is
select * from bd_owner.sales as of timestamp systimestamp - interval '120' minute;Now my question is that why I am not able to see back in time 2 hours before.
my flaskback setting is
db_flashback_retention_target        integer     1440       (24 hours)
db_flash_cache_file                  string
db_flash_cache_size                  big integer 0so does this really mean that i can look back old image of data for last 24 hours.
This db is not very active. Undo tablespace is of 2GB size . It was mostly 90% free
Please correct me here..
error i am getting is ora-1555 snapshot too old
ORA-01555: snapshot too old: rollback segment number 26 with name "_SYSSMU26$" too small
Is it due to undo setting not proper
undo_management string AUTO
undo_retention integer 900
undo_tablespace string UNDOTBS1
undo tablespace RETENTION is NOGUARANTEEquestion
1) shall i set undo retention to GUARANTEE.
Is any perfomance impact of this on database?
2) shall increase the undo_retention (15 minutes) equal to DB_FLASHBACK_RETENTION_TARGET ie 1440 (24 hour)
db details
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
PL/SQL Release 11.2.0.1.0 - Production
CORE    11.2.0.1.0      Production
TNS for HPUX: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - ProductionThanks In Advance
for answering these questions

Hi,
I think you are hitting the bug
Bug 9212103 Flashback version query omits deleted rows
Versions confirmed as being affected
11.2.0.1
11.1.0.7
Issue fixed in
This issue is fixed in
12.1 (Future Release)
11.2.0.2 (Server Patch Set)
Kind Regards,
Rakesh jayappa

Doubt on undo retention

Hi Friends,
Just clarification on undo (11g)
I set undo retention to 15 mins.
user A performs transaction without commit and the old data is in undo for read consistency.
when user B performs select query on user A's transaction it gives old data for read consistency from undo.
The time has excedded 15 mins (say 20 mins) without commit so the data in undo is ready for overwrite
user c performs DML statement and it requires space on undo and the user A transaction's old snapshot in undo is overwritten.
Now user D perform's select query on user A's transaction ( i believe he gets snapshoot too old error as the old data is overwritten) pls confirm?
Now when user A perform's roll back what will happen since the old data is already overwritten in undo (by user c's transaction) how the roll back is performed (or) will he get snap shot too old error?
My question:
if the users's are getting snapshot too old because the data is not available in undo then from where the data is rolled back if the user who initiated the DML(beyond undo retention) performs rollback?
Regards,
DB

Read consistency is achieved for committed data by undo_retention parameter exclusively which is specified in seconds ,it determines how much committed's undo data to keep in undo tablespace.Undo retention period mark two state (expired and unexpired) on committed's undo data.Old (committed) undo information that is older than the current undo retention period is said to be expired.Old undo information with an age that is less than the current undo retention period is said to be unexpired.
if (Undo committed data age)< undo_retention then
Undo committed data:='Unexpired'
else
Undo committed data:='Expired'
end if;Whenever there is shortage of undo space then Oracle will first overwrite expired committed's undo data , if the space issue still persist then oracle will start to overwrite unexpired committed's undo data.If yours long running query does not find expired or unexpired committed's undo data then an old snapshot error pop out during the execution of this query.
To safeguard unexpired committed's undo data is called to govern undo_retention,to guarantee the success of long-running queries you can enable retention guarantee.If retention guarantee is enabled, the specified minimum undo retention is guaranteed; the database never overwrites unexpired undo data no matter others transactions fail due to lack of space in the undo tablespace.
Do not relate undo retention period to un committed data.Un committed undo will never overwrite during the life span of yours database instance.
Khurram

UNDO Retention Problem

We have a three node 11.1.0.6 RAC.
Each node has a different undo tablespace specified...these parms:
INST_ID     NAME     VALUE     DISPLAY_VALUE
1     db_flashback_retention_target     1440     1440
2     db_flashback_retention_target     1440     1440
3     db_flashback_retention_target     1440     1440
1     undo_management     AUTO     AUTO
2     undo_management     AUTO     AUTO
3     undo_management     AUTO     AUTO
1     undo_retention     64800     64800
2     undo_retention     64800     64800
3     undo_retention     64800     64800
1     undo_tablespace     UNDOTBS1     UNDOTBS1
2     undo_tablespace     UNDOTBS2     UNDOTBS2
3     undo_tablespace     UNDOTBS3     UNDOTBS3
space in each tablespace is plentiful...each at about 11G expandable to 16G. Only 3GB used in one tablespace...100MB in the other two.
retention guarantee is not set on.
notice undo_retention is at 18 hours.
I do the following
SELECT COUNT(*) FROM MYTABLE as of TIMESTAMP to_timestamp(sysdate - 1/24); --- 1 hour ago.
ORA-01555 snapshot too old.
This appears to be a bug....the UNDO tablespaces are never stressed...not even close. undo retention is set to 16 hours....my query only asks for a measly 1 hour ago.
Why snapshot too old?! Why unexpired undo info gone?!
I wonder if undo info is getting spread across the RAC and when I do the flashback query, it only looks at the session's local node and can't find it. But thats not how RAC is supposed to work......Just shooting in the dark.
does db_flashback_retention_target have to be set higher?....doesn't seem from DOCs like that deals with flashback query, just flashback DB.
Anyone know why this is happening...Remember the UNDO tablespaces never get close to their capacity...never have to auto-expand.
I should not have to (and don't want to) set RETENTION GUARANTEE on...don't suggest that....I want to know why this failed without it.
I expect all undo info from 1 hour ago to have been kept if retention is set to 16 hours and the tablespace is not stressed...correct?
Thanks for any Help you can give.
Edited by: user3233984 on Mar 30, 2011 2:50 PM

The big problem with flashback archive tablespaces that I see is that once you place a table into the archive tablespace you cannot alter the table. We have added hundreds of new data columns to our tables over the last couple of years. Some of them have history tables or archived data associated with them.
The new columns are just null in the history and when archived data is retrieved. I see not being able to alter archived tables as a big problem.
As for the OP problem. Delayed block clean up is supposed to no longer be a problem in 11g though we all know how past statements from Oracle on like claims have played out (that is, sometimes what Oracle says is fixed turns out to be only partially fixed or the fix introduced a new problem).
Another possible issue is if Oracle automatic undo managment offlined or dropped any of the undo segments since the segment was not needed. I believe that undo managment is written to the alert log so it should be worth a look.
IMHO -- Mark D Powell --

(10g) 자동화된 UNDO RETENTION 튜닝

제품 : ORACLE SERVER
작성날짜 : 2004-05-17
PURPOSE
이 문서는 Oracle 10g 에서 자동화된 UNDO RETENTION 기능에 대하여
소개하는 자료이다.
Explanation
- Automatic tuning of undo retention in 10g.
Oracle 9i 에서는 ORA-1555 error가 가끔 발생하여 DBA가 이에 대한
조정을 해줄 필요가 있었다. 그러나, Oracle 10g 부터는 UNDO_RETENTION
에 대한 자동 튜닝 기능을 제공하게 되었다. 따라서, ORA-1555 에러가
발생하지 않도록 자동으로 UNDO RETENTION을 튜닝한다.
- Mandatory setting
1) UNDO_RETENTION=0 (10g: 이 파라미터 값을 0으로 해야 자동 활성화됨)
2) 반드시 SMU(System Managed Undo)를 사용해야 함.
- 자동 튜닝의 방식
UNDO_RETENTION을 0으로 셋팅하면 UNDO_RETENTION의 최소값은 900초가 된다.
즉 15분이다. MMON process가 매 30초마다 query duration을 계산한다.
MAXQUERYLEN 이라는 값을 계산하는데 이 값에 따라서 MMON은
TUNED_UNDORETENTION 이라는 수치를 결정한다. 이것은 새로운 UNDO
RETENTION 값이 TUNED_UNDORETENTION 로 셋팅이 됨을 의미한다.
계산 공식은 다음과 같다.
TUNED_UNDORETENTION = MAXQUERYLEN + 300 Sec.
Example
테스트를 위한 작업 순서는 다음과 같다.
1. 다음 SQL을 이용하여 TB1과 TB2 라는 두 개의 테이블을 생성한다.
create table tb1
     (col1 number not null,
     col2 number,
     col3 number,
     col4 number,
     col5 char(10),
     col6 date,
     col7 char,
     col8 real,
     col9 float,
     col10 float(10))
     tablespace test1;
     begin
     for i in 1..250 loop
     insert into tb1 values (6,1,3,1,'afdfaa','10-SEP-91','g',11.11,10.11,.11);
     insert into tb1 values (7,34,1,23,'faaaa','12-AUG-91','h',11.1,1.11,1.1);
     insert into tb1 values (8,91,17,1,'alkaa','10-AUG-87','i',6.11,31.11,0);
     insert into tb1 values (9,0,8,1,'adfda','12-AUG-91','j',11.11,11.11,11.11);
     insert into tb1 values (10,5,1,1,'advfaa','17-AUG-91','k',1.11,1.11,1111);
     insert into tb1 values (11,5,67,1,'acva','13-AUG-91','l',1.11,13.11,13.11);
     insert into tb1 values (12,7,1,3,'aadfa','14-AUG-90','m',11.11,11.11,11.11);
     insert into tb1 values (13,9,4,1,'ajhka','10-AUG-55','n',11.11,11.41,31.11);
     insert into tb1 values (14,1,1,3,'sdda','10-AUG-91','o',11.11,11.11,11.11);
     insert into tb1 values (15,6,1,3,'sdd332','10-AUG-91','o',11.11,11.11,11.11);
     end loop;
     end;
     create table tb2
     (col1 number not null,
     col2 number,
     col3 number,
     col4 number,
     col5 char(10),
     col6 date,
     col7 char,
     col8 real,
     col9 float,
     col10 float(10))
     tablespace test2;
     begin
     for i in 1..250 loop
     insert into tb2 values (16,100,100,100,'aaaa','10-AUG-95','a',111.11,11.11,11.11);
     insert into tb2 values (27,200,200,200,'bb','11-AUG-95','b',221.22,22.22,22.22);
     insert into tb2 values (38,300,300,300,'ccccccc','12-AUG-99','c',31.333,333.33,3333.3);
     insert into tb2 values (40,400,400,400,'dddddddd','12-AUG-99','d',111.11,11.11,11.11);
     insert into tb2 values (50,33,10000,1000,'aaa','10-AUG-94','f',11.11,111.11,321.11);
     insert into tb2 values (60,1000,3000,10000,'afdfaa','10-SEP-97','g',111.11,144.11,.11);
     insert into tb2 values (70,341,10,2310,'fghfgaaaa','12-AUG-98','h',11.1,11.11,1.1);
     insert into tb2 values (80,0910000,1780,100,'aallkaa','10-AUG-89','i',611.11,311.11,0);
     insert into tb2 values (90,0,80,1000,'adfda','12-AUG-96','j',11.11,11.11,111.11);
     insert into tb2 values (100,51,10,1000000,'advfaa','17-AUG-97','k',11.11,11.11,1111);
     end loop;
     end;
2. 같은 test schema에서 다른 세션을 open한다.
3. test schema에게 DBA 권한을 부여한다.
4. 첫번 째 SESSION에서 다음 SELECT 문장을 수행한다.
SELECT TB1.*, TB2.*
FROM TB1, TB2
WHERE TB1.COL1 > TB2.COL1;
5. 두번 째 SESSION에서 위 4단계 수행후 2~5초 정도 후에 다음 명령을 수행한다.
alter system set "_smu_debug_mode" = 45;
set transaction use rollback segment "_SYSSMU3$";
set echo on;
update tb1 set col1 = col1;
commit;
set transaction use rollback segment "_SYSSMU3$";
update tb1 set col1 = col1;
commit;
set transaction use rollback segment "_SYSSMU3$";
update tb1 set col1 = col1;
commit;
set transaction use rollback segment "_SYSSMU3$";
update tb1 set col1 = col1;
commit;
set transaction use rollback segment "_SYSSMU3$";
update tb1 set col1 = col1;
commit;
set transaction use rollback segment "_SYSSMU3$";
update tb1 set col1 = col1;
commit;
set transaction use rollback segment "_SYSSMU3$";
update tb1 set col1 = col1;
commit;
set transaction use rollback segment "_SYSSMU3$";
update tb1 set col1 = col1;
commit;
set transaction use rollback segment "_SYSSMU3$";
update tb1 set col1 = col1;
commit;
set transaction use rollback segment "_SYSSMU3$";
update tb1 set col1 = col1;
commit;
set transaction use rollback segment "_SYSSMU3$";
update tb1 set col1 = col1;
commit;
set transaction use rollback segment "_SYSSMU3$";
update tb1 set col1 = col1;
commit;
set transaction use rollback segment "_SYSSMU3$";
update tb1 set col1 = col1;
commit;
6. "_SYSSMU3$" 의 사용량을 보기 위해 세번 째 SESSION을 OPEN한다.
7. 세번 째 SESSION에서 다음 query를 수행한다.
select tuned_undoretention, maxquerylen, maxqueryid from v$undostat;
결과는 다음과 같은 형태일 것이다.
===================================
TUNED_UNDORETENTION MAXQUERYLEN MAXQUERYID
2300 2000 gpxxh7pysj4fs
900 1 25z699hs9r3wy
900 1 2syxvjbg8d6s4
900 44 5scq3kj3rm7tz
MAXQUERYLEN 값과 계산된 TUNED_UNDORETENTION 값을 살펴보아야 한다.
(참고) 만약 관련된 query 문을 조회하려고 한다면 다음 SELECT 문을
수행하면 된다.
SQL> Select sql_text from v$sqltext
where sql_id = 'gpxxh7pysj4fs' /* MAXQUERYID value */
8. 다음 SQL 문을 이용하여 SMU 의 증가량을 확인한다.
SQL> select USN, RSSIZE, HWMSIZE, OPTSIZE, SHRINKS, segment_name
from v$rollstat, dba_rollback_segs
where usn=segment_id and segment_name like '%SMU3$';
USN RSSIZE HWMSIZE OPTSIZE SHRINKS SEGMENT_NAME
3 260096 522240 6 _SYSSMU3$
9. Step 5 아래에 있는 script를 반복해서 수행하고, step 8 의 SQL을
다시 반복 수행하면 SMU3 의 증가량을 확인할 수 있을 것이다.
(참고) 이와 같은 Automatic Undo Retention의 튜닝은 ORA-1555 ERROR
발생을 예방해준다. 그러나 undo tablespace가 autoextend off 이면
DML 수행 시 UNDO SPACE 부족과 같은 상황에 처할 수 있다.
UNDO tablespace의 사이즈가 부족하면 UNDO RETENTION 값이 줄어들 수 있다.
어떤 UNDO RETENTION을 가능하게 하기 위해서는 그 만큼의 UNDO 공간이
필요하다. Oracle 9i에서는 DBA가 직접 해주어야 했던 이런 고려를
Oracle Database 10g에서는 Oracle 서버가 대신 해준다.
Reference Documents
<Note:240746.1>

Flashback Drop uses recycle bin...
make sure:
- you didn't create table on SYSTEM + SYSAUX tablespaces.
- You didn't use "purge" when you drop table " drop table xxx purge"
Example:
SQL> show parameter undo_retention
NAME                    TYPE     VALUE
undo_retention               integer     0
SQL> select table_name,tablespace_name from user_tables where table_name='TT';
TABLE_NAME          TABLESPACE_NAME
TT               USERS
SQL> drop table TT;
Table dropped.
SQL> desc TT
ERROR:
ORA-04043: object TT does not exist
SQL> FLASHBACK TABLE TT TO BEFORE DROP;
Flashback complete.
SQL> desc TT
Name                         Null? Type
OWNER                         NOT NULL VARCHAR2(30)
OBJECT_NAME                    NOT NULL VARCHAR2(30)
SUBOBJECT_NAME                     VARCHAR2(30)
Edited by: Surachart Opun (HunterX) on Aug 3, 2009 12:56 PM

R11 and tablespace issue

Hi hussein;
I want to hear your advice about R11 and tablespace issue... I am following :Subject: Oracle Applications Tablespace Model FAQs Doc ID: 269293.1
I can understand which tablespace using for what in R11 but i wonder one thing. Picture this please:
My AOOS_TS_TX_IDX tablaspace has 6 datafile as a_txn_ind06.dbf ... some of this file has %83 usegae 2 of %97 and %96... The quesiton is when we should resize datafile? I mean when we should say " oo the datafile is %?? using so i have to resize it.
One other question is my APPS_UNDOTS1 tablespace's datafile(those are 3 files) are now %100.. Should i resize them or its unncessarry?
Thanks for advice

Hi,
The quesiton is when we should resize datafile? I mean when we should say " oo the datafile is %?? using so i have to resize it.There is no specific answer to this question, and it depends on how this tablespace is utilized and on the size of the tablespace (for example, 70% used space of 1 GB tablespace is different that 70% used space of 100 MB tablespace). So, I would say whenever you believe you need to add more space to the this tablespace (these datafiles).
One other question is my APPS_UNDOTS1 tablespace's datafile(those are 3 files) are now %100.. Should i resize them or its unncessarry?You do not have to -- See (Note: 413732.1 - Full UNDO Tablespace In 10gR2) for details.
Regards,
Hussein

Undo retention and tablespace size

Similar Messages

Maybe you are looking for