OATM uniform extent strategy

In my first pass of the OATM (Oracle Apps Tablespace Model) utility in release 11.5.10.2, the database actually grew by almost 40G to 285G. Not huge growth, but not quite what I expected. We migrated to uniform extents of either 128k or 1mb, depending on the tablespace. After the migration, many of the empty/unused tables took a larger initial extent than they had before the migration. The old initial extent was usually either 80k or 40k. I counted over 20,000 objects (tables, indexes, lobs) that grew from their old initial allocation to either 128k or 1mb. So, I'm thinking of migrating by schema instead of all schemas at once and migrating the unused schemas to a few tablespaces with smaller initial extents. Has anybody else pursued a similar strategy? That means that future DBA's might have the task of migrating the unused tables to active tablespaces if those products ever do become licensed here, which seems to be one of the downsides of that strategy. I'm also considering migrating some of the larger objects to a 10mb initial extent.

Hi;
Please check below notes for extent strategy
Oracle Applications Tablespace Migration Utility User Documentation 269291.1
Oracle Applications Tablespace Model Release 11i - Tablespace Migration Utility 248857.1
Oracle Applications Tablespace Model FAQs 269293.1
New Oracle Applications Tablespace Model and Migration Utility 248173.1
Oracle® Applications Concepts Release 11i (11.5.10) Part No. B13892-01
Hope it heps
Regard
Helios

Similar Messages

Why use uniform extent allocation?

version- 11.2.0.2.0
Hello guys, I've been reading UNIFORM vs AUTOALLOCATE extent allocation.
I've read the following articles.
https://blogs.oracle.com/datawarehousing/entry/parallel_load_uniform_or_autoallocate
Ask Tom: On Loading and Extents
https://forums.oracle.com/thread/2518951
From what I understood, autoallocate trumps the uniform in all scenarios (unless I am missing something).
In the thread "AUTOALLOCATE vs UNIFORM SIZE"
for the benefits of autoallocate and uniform size allocation Kh$n wrote
Benefits of AUTOALLOCATE
* Prevents space fragmentation.
Benefits of UNIFORM extent sizes
* Prevents fragmentation.
(I dont understand what is the difference between those two fragmentation prevention, are those benefits one and the same?)
even in scenarios where we know exactly how much data will be loaded, there is always a chance of extent wastage and with out extent trimming that space will be unusable.
Can someone please explain in which cases we use uniform extent allocation?
for suppose we use uniform extent allocation and we have lot of unused space from the extent allocation, can that space be reclaimed using shrink space command for tables and indexes?
Thank You

Extent trimming, to the best of my knowledge, is something that only happens when you are using parallel query to do large loads, not something that happens during normal OLTP type operations. As with anything called "automatic" in Oracle, though, the internals are subject to change across versions (and patchsets) and are not necessarily documented, so it is entirely possible for behaviors to change over time. Relying on specific internal behaviors is generally not a good idea.
The example I gave (assuming you reverse the truncating of A and the loading of C, as Hemant pointed out) produces "fragentation" when you're using automatic extent management. It's not a particularly realistic scenario, but it is possible. If you never delete data, never truncate tables, (and, presumably, never shrink tables), extents would never be deallocated and there would, therefore, never be holes. That is just as true of ancient dictionary managed tablespaces as well as locally managed tablespaes whether you're using uniform or autoallocated extents.
Shrinking a table has nothing to do with defragmenting a tablespace. It is simply compacting the data in the table and then potentially deallocating extents. You can do that with any locally managed tablespace. There is still the possibility, of course, that you have just enough data in the table that you need to allocate 1 extra extent when you only need space for 1 row in 1 block. So there may be some number of MB of "wasted" space per segment (though, again, this is generally not something that is a practical concern since the data in tables generally changes over time and it's generally not worth the effort of worrying about a few MB).
Justin
For your third question, assuming both extents are part of the same segment, assuming that the space is actually usable based on things like the PCTUSED setting of the table, and assuming a nice, simple conventional path insert in a single-user, Oracle would use the free space in the extent for new inserts before allocating a new extent. Oracle generally doesn't allocate new extents unless it needs to (there are caveats to this-- if the only blocks with free space have a relatively large fraction of their space used such that a particular new insert only fits in 1 of the 1 million blocks in the currently allocated extents, Oracle will potentially give up before finding the 1 in a million block that it would need an may allocate a new extent).
Message was edited by: JustinCave

Large Uniform Extent Size = Slow TRUNCATE?

Here's the scenario...
We have a a tablespace with the following storage parameter:
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 32M
Users were complaining about slow TRUNCATE performance. I saw the same when I created a table with 30,000 rows - same as the user was complaining about - in the same tablespace.
I proceeded to move the objects from the schema the user was referencing to a tablespace with:
EXTENT MANAGEMENT LOCAL AUTOALLOCATE
... and the TRUNCATE executed in the expected time (less than a second) for the same amount of rows in the same table structure.
Why does a large UNIFORM extent size (such as 32M in this case) cause for slow TRUNCATE performance? I wasn't able to find an exact cause of this in the forums or on Metalink thus far.
Version: Oracle DB 10.2.0.3
System Info:
Linux ilqaos01c 2.6.9-55.0.12.ELsmp #1 SMP Wed Oct 17 08:15:59 EDT 2007 x86_64
Thanks.

Robert Sislow wrote:
The Metalink article was helpful, however, the database we're on is version 10.2.0.3, and the article is referencing 9.2.0.4.
Additionally, the last few responses in this thread are referring to concurrent TRUNCATE operations. The TRUNCATE that we're running is a single-thread TRUNCATE on a very small table - about 8000 rows.
After executing a 10046 level 12 trace, and using the Trace Analyzer tool, we've found that the "local write wait" event is taking up ~90% of the statement's activity for each run. Once again, all we can find that's causing this is the fact the the extent size in the tablespace with the table where we're seeing the slowness is set to UNIFORM size of 32M.
You're using ASSM (automatic segment space management), which means you have a number of bitmap space management blocks scattered through the object.
If you're running with 32MB uniform extents, the first extent will be 4096 blocks, and there will be one level 2 bitmap, 64 level 1 bitmaps, and the segment header block at the start of the extent. With autoallocate, the first extent will start with one level 2 bitmap, one (or possibly 2) level 1 bitmap(s) and the segment header block.
When you truncate an object, all the space managment blocks in the first extent (and any extents you keep) have to be reset to show 100% free space - this means they may all have to be read into the buffer cache before being updated and written back with local writes (i.e. writes by the process, not by dbwr).
So you have to wait for 66 reads and writes in one case and 3 (or 4) reads and writes in the other case. This helps to explain part of the difference. However, a local write wait should NOT take the best part of a second - so there must be a configuration problem somewhere in your setup. (e.g. issues with async I/O, or RAID configuration).
Regards
Jonathan Lewis

Will a converted LMT have UNIFORM EXTENT MANAGEMENT?

if we convert a DMT to an LMT, can we then set this LMT to have UNIFORM EXTENT MANAGEMENT?
thanks

Don't convert. Yes, Oracle provides a procedure to do the conversion, but it ends up creating a horrible 'hybrid' sort of tablespace, certainly unable to use a uniform extent management technique, but not really using a proper autoallocate method either.
Better to create a new tablespace and move segments across from one to the other. Then drop the original.

AUTOALLOCATE or UNIFORM extents for LMTs?

Hi,
I checked metalink and other resources, but couldn't find a conclusive statement indicating as to which one of the following is the best and recommended option:
1) LMTs with AUTOALLOCATE or
2) LMTs with UNIFORM EXTENT sizes
Any pros and cons would be appreciated.
Thanks
SS

A classic example where AUTOALLOCATE is very good is the 3rd party application where you don't know which tables are going to be big, which ones small, and which one won't be used at all If you put everything into AUTOALLOCATE it avoids wasting space, but lets the big tables grow without producing a vast number of extents.
If you are in control of the application and have good information about sizing of a few critical objects, you might choose to use UNIFORM sizing for adminstrative and monitoring reasons - it gives you the option for watching objects grow at a predictable rate.
If you are doing a lot of parallel work with scratch tables (CTAS, insert /*+ append */ then you might want to read up about the possible conflict between PX and AUTOALLOCATE at the following URL:
http://jonathanlewis.wordpress.com/2007/05/29/autoallocate-and-px/
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk

OATM conversion - should I use unform or auto allocated extents

Hi, as part of an 11i to R12 E-Biz upgrade, I am migrating to the OATM model of tablespaces. One issue I am not sure about is whether to create the new OATM tablespaces so that they use Uniform Extents or whether I should set them to use Auto Allocate. I appreciate that some folk believe Auto Allocate can in the long run lead to freespace fragmentation. However I have not seen any recommendation from Oracle in any of the upgrade documentation as to which method of extent allocation to use.
Q1. Any ideas on which is the recommended / better / wiser extent allocation method to use ?
Q2. Are the concerns around free space fragmentation with the Auto Allocate method really likely ?
Also when I ran the Sizing Report in the OATM migration utility against my existing non OATM 11i tablespaces to predict the space I required for the migration, I got very different results / predictions !
For Uniform Extent Allocation I got the following prediction
Required 20% buffer Current
======= ======= =====
Total(in KB): 83,552,256 100,261,687 31,653,400
For Auto Allocate I got the following prediction
Required 20% buffer Current
======= ======= =====
Total(in KB): 29,842,048 35,809,437 31,653,400
Q3. Any idea why there is such a large variation between the predicted figures for both methods ?
any insight or shared thoughts greatly appreciated,
Jim

Thanks Hussein,
The notes indicate that the recommendation for OATM is Uniform Extnts of 128 Kb. However it caveats that with the statement "if that suits your database". How are you meant to pre-determine what extent size suits your current data / database ?
Also when I ran the pre-sizing report in the OATM migration utility I got vastly different space predictions ( see below ) when proposing to use Uniform Extent Allocation ( of 128 Kb ) and Auto Allocate. Do you know why there should be such a large difference in the figures ( especially as the recommended Unform Extent allocation is so much larger ! )
For Uniform Extent Allocation
==================
Required 20% buffer Current
Total(in KB): 83,552,256 100,261,687 31,653,400
For Auto Allocation
============
Required 20% buffer Current
Total(in KB): 29,842,048 35,809,437 31,663,600

OATM after upgrading to Release 12

Hi,
Wanted to find out if anyone has done OATM after the e-business suite got upgraded to Release 12.0.4.
All the new objects were created under new OATM model since the new tablespaces were created as part of Rapid Install.
We need to move rest of the objects (old ones created at 11i) to the new tablespace model.
Has anyone done this and if so, any issues faced, any specific step that is critical to success of OATM migration.
If you can share any documentation please post or I can provide my email address to share.
Initial/next extent for new tablespaces created by Rapid Install has default of 128K. I am thinking
of using either 1MB or 10MB of uniform extents. What storage parameters did you choose and why?
Are you happy with that parameter or do you wish you have changed to different one?
Thanks in advance for sharing.
-RJ

Hi Sawwan,
Thanks for your response.
I agree but the client already upgraded to Release 12.0.4 and didn't migrate all the objects (old R11i objects, for example: gl_je_batches, gl_je_headers, gl_je_lines still uses GLD tablespace instead of APPS_TS_TX_DATA) to new tablespace model (OATM).
My question is that have any one of you faced this situation and how did you go about using the OATM migration utility for migration and any specific steps that are critical to the success of OATM migration.
Thanks,
RJ.

Migrating to OATM in a ASM database

Hi All,
We are on 11.5.10.2. and Db with 10.2.0.4
Can you please advice on the possibilities and any changes in the steps for OATM migration for a Database in ASM.
Oracle standard documents have steps for Non ASM database.
We are yet to migrate to ASM, we are working on the possibilities of which one can be done first.
Migration from Non ASM to ASM and then Migration to OATM ( or ) Migration to OATM and then Migration from Non ASM to ASM
Please advice on the best possible approach
Thanks & Regards,
Rakesh

Hi Hussein,
Have raised an SR to get the oracle support responce on having OATM migration in a ASM database.
Have another query....
Current tablespaces have the segment_space_management as Manual, we are planning to change this to Auto during the OATM migration except for some 4 to 5 Modules where the segments are huge and lots of transaction will be going on for those ( Heavily used modules ).
Those schemas alone we are planning to have uniform extent in seperate tablespaces.
Verified the oracle system administrator guide for this and it has mentioned about changing the complete APPS_TS_TX_DATA to APPS_TS_TX_DATA_1MB. But we want to have the 200+ oracle registered schema in APPS_TS_TX_DATA ( segment management auto ) and 5 oracle registered schema in a another set of tablespaces ( Segment management uniform )
I guess recommended segment space management is Uniform, as i have mentioned earlier there are many tables/indexes which are huge 100G plus, currently the next extent of these objects are 10M plus. So while migrating to OATM we should have these in 10M+ uniform extent to avoid performance issue or we can have in 1 M uniform extent.
Can you please advice on how can we achieve this and is there any draw back in this.
Thanks & Regards,
Rakesh

MAX EXTENTS for a table

Hello Guru's
I am working on oracle express 10 G on windows , This is my test machine. I am a beginner to oracle Dba activities,
Problem:
I want to restrict the size of a table (say max upto 400k)
My Approach:
1. I create a Tablepsace with uniform extent size (40K each)
2. I created a table in this tablespace with max extents 10 ( so that 40K * 10 = 400K)
SCOTT@xe>CREATE TABLESPACE TB
2   DATAFILE 'F:\Oracle\oradata\XE\TB.DBF' SIZE 100M
3   EXTENT MANAGEMENT LOCAL
4   UNIFORM SIZE 40K
5   ONLINE ;
Tablespace created.
SCOTT@xe>
SCOTT@xe>DROP USER G CASCADE ;
User dropped.
SCOTT@xe>CREATE USER G IDENTIFIED BY G DEFAULT TABLESPACE TB ;
User created.
SCOTT@xe>ALTER USER G QUOTA UNLIMITED ON TB;
User altered.
SCOTT@xe>GRANT CREATE SESSION , CREATE TABLE TO G;
Grant succeeded.
SCOTT@xe>CONNECT G/G@xe
Connected.
G@xe>CREATE TABLE t ( A number) TABLESPACE TB storage (minextents 1 maxextents 10);
Table created.
G@xe>SELECT SEGMENT_NAME, MIN_EXTENTS, MAX_EXTENTS , SEGMENT_TYPE, TABLESPACE_NAME, BLOCKS
2 FROM USER_SEGMENTS ;
SEGMENT_NAME                                                                      MIN_EXTENTS MAX_EXTENTS SEGMENT_TYPE       TABLESPACE_NAME                    BLOCKS
T                                                                                           1 2147483645 TABLE              TB                                      5
G@xe>Issue is:
I want the maximun extents that could be llocated to this table must be 10 , BUT from user_segments I could see MAX_EXTENTS = 2147483645 (default value).
When i pump data into this table MAX_EXTENTS exceeds 10 (i.e user Defined value)
I have no idea why this is the case;
Regards,

When creating a segment (Table/Index) in a Locally Managed Tablespace (created with "EXTENT MANAGEMENT LOCAL" and visible in DBA_TABLESPACES under EXTENT_MANAGEMENT), Oracle ignores the specification of MAXEXTENTS.
All segments in an LMT would default to MAXEXTENTS UNLIMITED (which really means 2 billion).
(DEFAULT STORAGE at the Tablespace level cannot be set if it is LOCAL AUTOALLOCATE or LOCAL UNIFORM)
See [The 10gR2 documentation on the STORAGE clause|http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/clauses009.htm#i997450]
In your 10gXE install you will not be able to create a DICTIONARY MANAGED Tablespace as the SYSTEM Tablespace itself is LOCALLY MANAGED.
If you want to limit the size of a table you could
a. Create a Tablespace with a set size for datafiles (ie, set AUTOEXTEND OFF for the datafiles)
b. Create the Table in that Tablespace
Edited by: Hemant K Chitale on Aug 18, 2009 3:31 PM

ORA-25150 Altering of extent parameters not allowed

I had created an index as below
SQL> create index sys.emp_name_idx
2> on sys.emp(emp_name)
3> pctfree 30
4> storage( initial 200k next 200k pctincrease 0 maxextents 50)
5> tablespace indx;
Index Created.
Now i am trying to alter storage parameters of the index as below:-
SQL> Alter index emp_name_idx
2> storage( next 400k maxextents 100);
ERROR AT LINE 1
ora 25150 - aLTERING OF EXTENT PARAMETERS NOT PERMITTED
PLZ HELP!!!
Edited by: UNMESH on Jun 20, 2011 1:45 AM

Error:     ORA-25150
Text:     ALTERING of extent parameters not permitted
Cause:     An attempt was made to alter the extent parameters for a segment in a
     tablespace with autoallocate or uniform extent allocation policy.
Action:     Remove the appropriate extent parameters from the command.

Any guidelines on uniform ext size?

Hi,
Are there any guidelines, to be followed for optimal performance of tablespaces, in setting the uniform extent size of locally managed tablespaces? I am particularly interested in the percentage of the total tablespace size, to be used as the extent size. Even any other guideline will be helpful.
Thanks
Yash

I dont think there's is a "RULE" about that, just good sense i think.
If your biggest table is 2GB, make one tablespace (or more if you make partitionning on it) for this table with something like 500MB extent. Make a specific tablespace for the index too with extent like 200MB.
You should also have littles tables such as parameters tables with little size like few KB to 100KB => make a tablespace for theses littles tables with a 32KB extent for example and a tablespace for the indexes with a 16KB extent size.
Fred

EXTENT MANAGEMENT

Hi,
on 11g R2 on Win 2008
Would it be better to change to UNIFORM SIZE 128K for performance ?
What are the advantage of AUTOALLOCATE ?
Can we alter from AUTOALOCATE to UNIFORME or vice versa?
Thank you.

user522961 wrote:
Hi,
on 11g R2 on Win 2008
Would it be better to change to UNIFORM SIZE 128K for performance ?
What are the advantage of AUTOALLOCATE ?
Can we alter from AUTOALOCATE to UNIFORME or vice versa?
Thank you. What made you think so to change to UNIFORM size?
There is lots of debates around the AUTOALOCATE vs UNIFORME extents size performance, because its not like one size fits all. So you have to carefully read your current setup/configuration of database first then plan to change to UNIFORM.
UNIFORM extents are choosen for Large segments when you know its size in advance and you are inserting large amount of data.
However if you are not sure about size of segments and you are unaware of data that will be manipulated then i would suggest you to go with AUTO, this is usually used in case where future growth is not known and data set or segments are small in size typically in OLTP systems.
See nice blog here https://blogs.oracle.com/datawarehousing/entry/parallel_load_uniform_or_autoallocate
And - http://www.oracle.com/technetwork/issue-archive/2007/07-may/o37asktom-101781.html

Determining Extent Allocation Type

Does anyone know how you tell if a tablespace has been configured to use UNIFORM extent allocation or AUTO ALLOCATE . I can see in dba_tablespaces if the extent is dictionary or locally managed. I can also see if it is using ASSM or not but I am struggling to see where the actual method of extent allocation is recorded
thanks,
Jim

http://docs.oracle.com/cd/B19306_01/server.102/b14237/statviews_4157.htm
ALLOCATION_TYPE

Change extent allocation in tablespace

Hi All,
Database Version : 11.1.0.6
I have a LMT tablespace with uniform extent of 192 K. It has been in use since long .
Is it possible to change the extent allocation to AUTOALLOCATE now ?
If not , is there any workaround ..
Thanks

hi..
there is no "alter table space" syntax for changing extent management from uniform to auto allocate. Hence, you must re-define the table space to change the extent management:
* Backup the table space
* Export the table space data
* Drop and re-allocate the table space
* Import the table space

ORA-01631: max # extents (4096)

Hi
I received below ORA error for one of my prod table, would like to in which scenario we get the below error and how to investigate why it has occured.
ORA-01631: max # extents (4096) reached in table DWHSE.F_APS_ORDERS
Regards

To hit a maximum extents error on a table you pretty much have to be using dictionary tablespace management. The maximum number of extents defaults based on the block size. If your Oracle version is 8.1 and up all your tablespaces should have been rebuilt as locally managed tablespaces using either auto-allocate or uniform extents. In the case where you have a newer version you should consider creating new tablespaces and moving the objects into them so you can take advantage of modern extent management features.
If you are running an older release then just take some time to review your object allocation layout to see if for space managment purposes you need to do any re-arranging or storage parameter modification. We used our own version of auto-allocate under 7.x where we had 4 different extent sizes for smaller objects where each size was an even multiple of the smaller sizes. For moderate size and large tables we had uniform extent sizes.
Good luck.
HTH -- Mark D Powell --

OATM uniform extent strategy

Similar Messages

Maybe you are looking for