DBMS_SPACE_ADMIN ASSM

Hi,
Does anyone know to simulate the type of corruption or inconsistency in an ASSM tablespace or segment that would be highlighted by the following procedures?
DBMS_SPACE_ADMIN.ASSM_TABLEPSACE_VERIFY
DBMS_SPACE_ADMIN.ASSM_SEGMENT_VERIFY
I'd like to try and see how the errors are reported in the trc file so that I can perhaps script up something to check for them when we run these commands. At the moment I don't have an inconsistent tablespace or segment so would like to try and introduce an error.
Any thoughts appreciated,
Thanks
ma365

Always used a number instead on constant name, it always work for me
Try
exec DBMS_SPACE_ADMIN.ASSM_TABLESPACE_VERIFY ('USERS',20,10);
After running above come out from sql session.
Virag

Similar Messages

ASSM (Automatic Segment Space Management)

Hi Folks.
I have a severe problem regarding Buffer Busy Waits.
I have deceided to implement ASSM (Automatic Segment Space Management).
Please assist....is the approch OK & how should i apply this in a existing tablespace (pls also specify the syntax & other constraints that should be taken care of)....
Waiting for reply ... & thanks a lot in advance....

ASSM is a good feature to use, but, you need to kill the culprit instaed of simply MOVING ON.
If creating a new tablespace with ASSM, moving objects from Non-ASSM to the new tablespace is a problem, then, think of the following:
First of all, findout which object type is causing BBW, is it rollback/undo header, undo/rollback block, segment headere or what?
You need to review the P3 value(reason code) of BBW wait event.
Try to review the following dynamic views, before you decide to MOVE on.
v$waitstat (segment header)
v$segment_statistics(read the oracle docs. how to use this view and which parameter need to set in order to enable this feature).
Jaffar

Buffer Busy Waits on ASSM

Oracle 11.1.0.7
Windows 2003
We have huge Buffer Busy Waits , Tablespace is in ASSM. How can we avoid this ?
Thank You

Buffer busy waits are reported when multiple sessions try to read the same block in the cache.
Wait events:
Buffer busy wait:
This event is commonly caused when multiple session are trying to read the same block or multiple session waiting for a change to complete in the same block. Block contention corrective actions depends on the type of block involved. Query on V$WAITSTAT and X$KCBFWAIT to detect the hottest blocks breaking down by the type of block. To reduce buffer busy waits on:
data blocks:
Reduce number of rows per block whether changing pctfree/pctused or reducing the DB_BLOCK_SIZE.
Check for 'right-hand-indexes' (indexes that get inserted into at the same point by many processes). You can use reverse key indexes to distribute the different information.
See Note:155971.1 for a detailed case-study on how to diagnose and resolve intensive random access performance problems.
segment header:
Use freelists or increase of number of freelists.
Extent size too small can cause contention on the header when the table grows regularly. Consider increasing the extent size for the table.
undo header:
Add more rollback segments to reduce the number of transaction per rollback segment.
Reduce the value of the parameter TRANSACTION_PER_ROLLBACK_SEGMENT
undo block:
Consider making rollback segments larger in exclusive mode
Refer to metalink DOC 62172.1

Reuse of freed space after DELETE statement (ASSM)

Dear Members,
After DELETE of records in tables, the USED SPACE in tablespace still grows when new records are inserted. So the freed space is apparently not reused!
DB is Oracle 9.2. and ASSM is used.
Does anyone knows how to solve this problem?

1) Table (heap) space will continue to grow after deletes if the new rows are appended (APPEND HINT). Appending rows does not reuse free space in existing blocks.
2) Index space will continue to grow after deletes if the leaf blocks could not be reused. Index leaf blocks will be reused only if a) new data index keys will fit in on of the existing leaf blocks that still has entries after the delete completes; b) all of the entries in the leaf block were deleted and a new leaf block needs to be added to the index. It is possible to shrink/coalesce or rebuild an index to cure this phenomenon.

ASSM in Oracle 10g

Does anyone know if a tablespace can be altered to allow for automatic segment space management? For example, the "segment space management auto" feature? This is created by default in 10g, but I have converted an 8i DB to 10g, and they are all set to manual.
Thanks,
Mike

You have to create a new tablespace with ASSM and move tables from old one to new one.
The segment space management that you specify at tablespace creation time applies to all segments subsequently created in the tablespace. You cannot change the segment space management mode of a tablespace.
http://download-west.oracle.com/docs/cd/B19306_01/server.102/b14231/tspaces.htm#sthref1214

ASSM and FREELIST

Hi guys,
Anyone knows if is possible to check how many Freelists are set in a Table which is in a ASSM tablespace?
I know that Oracle automatically set the Freelist for ASSM tablespaces and I just want to check how many freelists oracle is setting to a particular table.
Thanks,
Paulo.

Freelists and ASSM are mutually exclusive. Either the table is in a non-ASSM tablespace, in which case the table has freelists, and how many can be observed with:
select freelists from dba_tables where owner='&owner' and table_name = '&table_name';
Or the table is in an ASSM tablespace, in which case there are no free list data structures, and free space is managed via bitmap blocks. More information on the differences can be found here:
http://download.oracle.com/docs/cd/B19306_01/server.102/b14231/tspaces.htm#ADMIN10065
Hope that helps,
-Mark

Too many extents for table on locally managed uniform ASSM tablespace

Running Oracle 9.2.0.8 on solaris 10, Enterprise edition.
Tablespace configuration:
select extent_management, allocation_type, segment_space_management, block_size, initial_extent, next_extent
from dba_tablespaces
where tablespace_name = 'PCLARGE';
LOCAL UNIFORM AUTO 8192 2097152 2097152
A nightly peoplesoft SQR job inserts and updates the problem table. The job has been in place without change for four years. During that time, the database moved from 8i to 9i, and the tablespace parameters moved to uniform local ASSM. The job selects from a 70 million row table and then updates the target summary table.
Can somebody help me understand why the number of extents would grow way out of proportion to the number of rows?
When the row count was 9807427, this table had 233 extents.
Row count 10759033, table had 501 extents.
Row count 10764665, table has 1967 extents.
The table is not analyzed since the system is using RULE. DBMS_SPACE.SPACE_USAGE indicates no extents above the high water mark. Running SELECT name,value FROM v$sysstat WHERE name like '%table%' seems to indicate that chained rows are not a factor, since the row with name "table fetch continued row" returns a small amount of rows.
Any ideas? Is it possible there is a bug with ASSM that is causing this?
Unfortunately I don't have detailed extent history information after each nightly run. I just have the 3 data points above.

Hi Hemant,
Thanks for your reply! No parallelism was involved in the SQR script.
Oracle support has pointed me to Metalink Note:469985.1: Sudden Increase in Unformatted Blocks. This behavior matches our symptoms. My company is going to pursue a backport, but in the meantime we may need to move data into tablespaces without ASSM.
Best regards,
Ben

Query on Oracle Concepts: Advantages of ASSM

Hi,
A query on Oracle Concepts, specifically on Advantages of ASSM.
While I am able to understand 'Simplified administration' & 'Increased concurrency', can anyone mention this in simple terms:
• Dynamic affinity of space to instances in an Oracle Real Application Clusters (Oracle RAC) environment.I guess I know whats Oracle RAC but what it meant by 'Dynamic affinity of space to instances'?
Regards,
Ankit Rathi

Hi Aman,
I was going through Oracle® Database Concepts 11g Release 2, Chapter 12 Logical Storage Structures (link below):
http://docs.oracle.com/cd/E11882_01/server.112/e25789/logical.htm#i19599
*Automatic Segment Space Management*
The ASSM method uses bitmaps to manage space. Bitmaps provide the following advantages:
•Simplified administration
ASSM avoids the need to manually determine correct settings for many storage parameters. Only one crucial SQL parameter controls space allocation: PCTFREE. This parameter specifies the percentage of space to be reserved in a block for future updates (see "Percentage of Free Space in Data Blocks").
•Increased concurrency
Multiple transactions can search separate lists of free data blocks, thereby reducing contention and waits. For many standard workloads, application performance with ASSM is better than the performance of a well-tuned application that uses MSSM.
•Dynamic affinity of space to instances in an Oracle Real Application Clusters (Oracle RAC) environment
ASSM is more efficient and is the default for permanent, locally managed tablespaces.Regards,
Ankit Rathi

Output of dbms_space_admin.segment_verify

Hi,
I'm using dbms_space_admin.segment_verify to check the consistency of the segment extent map with the tablespace file bitmaps. The procedure executes successfully.
My question is: if the procedure finds any problem, where or how does it report it?
Thanks in advance.

I knew that I have to check sid_ora_process_ID.trc file in USER_DUMP_DEST after the execution.

Using ASSM in 10g RAC with SAP

Hi,
It is recommended to use ASSM (Automatic Segment Space Management) with using 10g RAC with SAP. Our deployment is currently a single instance database that is not using ASSM. We plan to convert this single instance database to a 10g RAC database. I wanted to know what the supported method is to convert to ASSM, during this process.
Will it require an export and import of the database?
Thanks

Hi Badar,
of course you can move tables (w/o longs) via ALTER TABLE MOVE... but why do you may want to do that?
ALTER TABLE MOVE is an OFFLINE action - nobody can access the table during the move.
DBMS_REDEFINITION (used by the BRTOOLS) is ONLINE. Normal work can proceed while the data is copied.
With ALTER TABLE MOVE you've to touch every single table (ca 50.000-80.000 in a SAP installation) by hand. PLUS you've to rebuild each index on each table by hand.
The BRTOOLS do all that for you. In parallel if you want to.
Moreover the BRTOOLS provide extensive logging in case any error should occur. ALTER TABLE MOVE does not.
So better forget about ALTER TABLE MOVE... use the BRTOOLS - they are not that bad
best regards,
Lars

Working of LMT datafile and ASSM bitmaps + data-dictionary

Hi,
I was looking to have some clarification on effective changes that take place within the database during a datafile addition/resize in a LMT. Hence what are the scenarios where a datafile resize would be better than a datafile addition and vice-versa?
I have not been able to find clear guidelines to the above.

From the perspective of bitmap in datafile header is it not true that multiple datafiles with separate bitmaps in their headers can reduce the contention for multiple hot blocks in a single datafile?
To phrase my question differently, when does the additional calculations for LMT,ASSM and data-dictionary maintainance rule in favor of resizing a single datafile(ending in a sort of big file tablespace) rather than adding datafiles?

A Question for ASSM Experts

Hello,
Oracle version 10.2.0.4
Block size 16k
I have a locally managed tablespace, with uniform extent size of 128k and SSM set to AUTO. My tablespace is called rj_test_X128K in the following test:
dba@TEST> create table dba.rj_del_ins_test
2 tablespace rj_test_X128K
3 as
4 select *
5 from table
6 where PK_COL > 1135268669
7 and PK_COL is not null;
Table created.
dba@TEST> exec dbms_stats.gather_table_stats('dba', tabname=>'RJ_DEL_INS_TEST',estimate_percent => 100, method_opt => 'FOR ALL COLUMNS SIZE 1', cascade=>TRUE);
PL/SQL procedure successfully completed.
dba@TEST> select TABLE_NAME, FREELISTS, NUM_ROWS, BLOCKS, EMPTY_BLOCKS, AVG_SPACE, AVG_ROW_LEN, NUM_FREELIST_BLOCKS
2 from dba_tables
3 where table_name = 'RJ_DEL_INS_TEST';
TABLE_NAME                      FREELISTS   NUM_ROWS     BLOCKS EMPTY_BLOCKS AVG_SPACE AVG_ROW_LEN NUM_FREELIST_BLOCKS
RJ_DEL_INS_TEST                                84217        868            0          0         141           0
dba@TEST> delete from dba.rj_del_ins_test
2 where PK_COL > 1135268669
3 and mod(PK_COL,20) = 10;
4143 rows deleted.
dba@TEST> commit;
Commit complete.
dba@TEST> exec dbms_stats.gather_table_stats('dba', tabname=>'RJ_DEL_INS_TEST',estimate_percent => 100, method_opt => 'FOR ALL COLUMNS SIZE 1', cascade=>TRUE);
PL/SQL procedure successfully completed.
dba@TEST> select TABLE_NAME, FREELISTS, NUM_ROWS, BLOCKS, EMPTY_BLOCKS, AVG_SPACE, AVG_ROW_LEN, NUM_FREELIST_BLOCKS
2 from dba_tables
3 where table_name = 'RJ_DEL_INS_TEST';
TABLE_NAME                      FREELISTS   NUM_ROWS     BLOCKS EMPTY_BLOCKS AVG_SPACE AVG_ROW_LEN NUM_FREELIST_BLOCKS
RJ_DEL_INS_TEST                                80074        868            0          0         141           0
dba@TEST> insert into dba.rj_del_ins_test
2 select *
3 from table
4 where PK_COL > 1135268669
5 and PK_COL is not null
6 and mod(PK_COL,20) = 6;
4277 rows created.
dba@TEST> commit;
Commit complete.
dba@TEST>
dba@TEST> exec dbms_stats.gather_table_stats('dba', tabname=>'RJ_DEL_INS_TEST',estimate_percent => 100, method_opt => 'FOR ALL COLUMNS SIZE 1', cascade=>TRUE);
PL/SQL procedure successfully completed.
dba@TEST> select TABLE_NAME, FREELISTS, NUM_ROWS, BLOCKS, EMPTY_BLOCKS, AVG_SPACE, AVG_ROW_LEN, NUM_FREELIST_BLOCKS
2 from dba_tables
3 where table_name = 'RJ_DEL_INS_TEST';
TABLE_NAME                      FREELISTS   NUM_ROWS     BLOCKS EMPTY_BLOCKS AVG_SPACE AVG_ROW_LEN NUM_FREELIST_BLOCKS
RJ_DEL_INS_TEST                                84351        911            0          0         141           0I notice that the number of blocks increases even though I am only inserting very few additional rows - 134 to be exact. Using the avg. row length of 141, that takes me to 134*141 = 18894bytes; just over 1 block. I get an increase of 43 blocks. Any ideas why?
I understand that there is a management overhead in terms of space usage when using ASSM, but I don't understand why there is such an increase in the number of blocks when I would have thought that the blocks were already allocated in the inital table creation stage. If I had inserted thousands more rows, I would understand the jump in block usage, but not with 134.
Here are the results of the DBMS_SPACE.SPACE_USAGE procedure
UNF         0
      UNFB         0
       FS4         0
      FS4B         0
       FS3         0
      FS3B         0
       FS2         0
      FS2B         0
       FS1         2
      FS1B     32768
      FULL       891
     FULLB 14598144
FS1
Number of blocks that has at least 0 to 25% free space
FS1B
Number of bytes that has at least 0 to 25% free space
FULL
Total number of blocks that are full in the segment
FULLB
Total number of bytes that are full in the segmentI used the DBMS_SPACE.UNUSED_SPACE procedure and got these results:
TOTAL_BLOCKS    912
TOTAL_BYTES        14942208
UNUSED_BLOCKS   0
UNUSED_BYTES    0
LASTEXTF      251
LAST_EXTB      909
LASTUSEDBLOCK   8
Definitions taken from the docs:
total_blocks
Returns total number of blocks in the segment.
total_bytes
Returns total number of blocks in the segment, in bytes.
unused_blocks
Returns number of blocks which are not used.
unused_bytes
Returns, in bytes, number of blocks which are not used.
last_used_extent_ file_id
Returns the file ID of the last extent which contains data.
last_used_extent_ block_id
Returns the starting block ID of the last extent which contains data.
last_used_block
Returns the last block within this extent which contains data.Further to this, here are how the stats look after the deletion and insert, shown in two stage:
# After deletion
FULL      850
FULLB     13926400
TOTAL_BLOCKS              872
TOTAL_BYTES             14286848
UNUSED_BLOCKS           4
UNUSED_BYTES            65536
LASTEXTF                 251
LAST_EXTB            869
LASTUSEDBLOCK            4
109 extents
NUM_ROWS     BLOCKS
     80074        868
# After Insert
FS1              1
FS1B          16384
FULL            892
FULLB           14614528
TOTAL_BLOCKS              912
TOTAL_BYTES             14942208
UNUSED_BLOCKS           0
UNUSED_BYTES                0
LASTEXTF                 251
LAST_EXTB            909
LASTUSEDBLOCK           8
114 extents
NUM_ROWS     BLOCKS
    84351        911So, can anyone come up with an explanation as to why this is happening?
Or perhaps some further testing that I can do to see what the blocks are being used for?
Thanks
Rob

Hi Randolf,
I used the values 0 and 99 for PCTFREE and PCTUSED, respectively. Hmmm, perhaps my use of the word appropriate wasn't so appropriate after all...
I wasn't aware of how Oracle decided a block's "freeness" before, so that is something new to me. Here is the information that you asked for.
TEST 1
ASSM tablespace, using default params for table, i.e. PCTFREE 10%
# After creating the table
-- output from dba_tables
NUM_ROWS     BLOCKS
     84217        868
-- Output from DBMS_SPACE.SPACE_USED
       UNF         0
      UNFB         0
       FS1         0
      FS1B         0
       FS2         0
      FS2B         0
       FS3         0
      FS3B         0
       FS4         0
      FS4B         0
      FULL       850
     FULLB 13926400
-- Output from DBMS_SPACE.UNUSED_SPACE
TOTAL_BLOCKS    872
TOTAL_BYTES        14286848
UNUSED_BLOCKS   4
UNUSED_BYTES    65536
LASTEXTF      251
LAST_EXTB      869
LASTUSEDBLOCK     4
# After the deletion
-- output from dba_tables
NUM_ROWS     BLOCKS
     80074        868
-- Output from DBMS_SPACE.SPACE_USED
       UNF         0
      UNFB         0
       FS1         0
      FS1B         0
       FS2         0
      FS2B         0
       FS3         0
      FS3B         0
       FS4         0
      FS4B         0
      FULL       850
     FULLB 13926400
-- Output from DBMS_SPACE.UNUSED_SPACE
TOTAL_BLOCKS    872
TOTAL_BYTES        14286848
UNUSED_BLOCKS   4
UNUSED_BYTES    65536
LASTEXTF      251
LAST_EXTB      869
LASTUSEDBLOCK     4Randolf, you are right; the blocks are still showing as FULL and therefore new blocks will be used for the subsequent insert. This, I presume, is a result of the "freeness" factor which you mentioned before.
TEST 2
MSSM tablespace using PCTFREE 10 and PCTUSED 75
dba@TEST> create table dba.rj_del_ins_test PCTFREE 10 PCTUSED 75
2 tablespace tbs_tables_X128K
3 as
4 select *
5 from table
6 where PK_COL > 1135268669
7 and PK_COL is not null;
Table created.
dba@TEST> exec dbms_stats.gather_table_stats('dba', tabname=>'RJ_DEL_INS_TEST',estimate_percent => 100, method_opt => 'FOR ALL COLUMNS SIZE 1', cascade=>TRUE);
PL/SQL procedure successfully completed.
dba@TEST> select TABLE_NAME, FREELISTS, NUM_ROWS, BLOCKS, EMPTY_BLOCKS, AVG_SPACE, AVG_ROW_LEN, NUM_FREELIST_BLOCKS
2 from dba_tables
3 where table_name = 'RJ_DEL_INS_TEST';
TABLE_NAME                      FREELISTS   NUM_ROWS     BLOCKS EMPTY_BLOCKS AVG_SPACE AVG_ROW_LEN NUM_FREELIST_BLOCKS
RJ_DEL_INS_TEST                         1      84217        849            0          0         141           0
dba@TEST> delete from dba.rj_del_ins_test
2 where PK_COL > 1135268669
3 and mod(PK_COL,20) = 10;
4143 rows deleted.
dba@TEST> commit;
Commit complete.
dba@TEST> exec dbms_stats.gather_table_stats('dba', tabname=>'RJ_DEL_INS_TEST',estimate_percent => 100, method_opt => 'FOR ALL COLUMNS SIZE 1', cascade=>TRUE);
PL/SQL procedure successfully completed.
dba@TEST> select TABLE_NAME, FREELISTS, NUM_ROWS, BLOCKS, EMPTY_BLOCKS, AVG_SPACE, AVG_ROW_LEN, NUM_FREELIST_BLOCKS
2 from dba_tables
3 where table_name = 'RJ_DEL_INS_TEST';
TABLE_NAME                      FREELISTS   NUM_ROWS     BLOCKS EMPTY_BLOCKS AVG_SPACE AVG_ROW_LEN NUM_FREELIST_BLOCKS
RJ_DEL_INS_TEST                         1      80074        849            0          0         141           0
dba@TEST> insert into dba.rj_del_ins_test
2 select *
3 from table
4 where PK_COL > 1135268669
5 and PK_COL is not null
6 and mod(PK_COL,20) = 6;
4277 rows created.
dba@TEST> commit;
Commit complete.
dba@TEST> exec dbms_stats.gather_table_stats('dba', tabname=>'RJ_DEL_INS_TEST',estimate_percent => 100, method_opt => 'FOR ALL COLUMNS SIZE 1', cascade=>TRUE);
PL/SQL procedure successfully completed.
dba@TEST> select TABLE_NAME, FREELISTS, NUM_ROWS, BLOCKS, EMPTY_BLOCKS, AVG_SPACE, AVG_ROW_LEN, NUM_FREELIST_BLOCKS
2 from dba_tables
3 where table_name = 'RJ_DEL_INS_TEST';
TABLE_NAME                      FREELISTS   NUM_ROWS     BLOCKS EMPTY_BLOCKS AVG_SPACE AVG_ROW_LEN NUM_FREELIST_BLOCKS
RJ_DEL_INS_TEST                         1      84351        892            0          0         141           0As you can see, TEST 2 shows that when using the representative parameters for PCTFREE and PCTUSED in MSSM to those of ASSM we get a comparable outcome to using ASSM.
So, regardless of what I set PCTFREE to in ASSM tablespace a block still has to have more than 25% free space to be a candidate for new inserts? Is there a way of changing this behaviour; is it just a hit you have to take for using ASSM or is there a logical reason behind it that I've missed?

ASSM vs. non-ASSM

I am engaged in a discussion about moving from 10g --> 11g. The tablespaces in this particular 10G are all created with the manual segment space management. I am reading the blogs and am aware of all the troubles that ASSM can cause, ranging from wasting space to problems with the free lists and even some spurious corruption issues.
However, Oracle made ASSM default in version 10g, and this project is about upgrading a large production DB. What are the opinions here? Does it make sense to go with manual SSM or should I go with ASSM?

My preference is encapsulated here:
CREATE TABLESPACE uwdata
DATAFILE 'C:\ORACLE\ORADATA\ORABASE\UWDATA01.DBF' SIZE 250M
LOGGING FORCE LOGGING ONLINE PERMANENT BLOCKSIZE 8K
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 256K
SEGMENT SPACE MANAGEMENT AUTO;I prefer ASSM with uniform extent sizes.

Storing LOBs in ASSM tablespace

Hello,
I'd like to know if a lob (clob, nlob, etc). can be stored in an ASSM (automatic segment space management) tablespace in Oracle 10g R1.
Thanks!
Gabriel.

Yes ... [Just try it?!?!]
flip@FLOP> select default_tablespace from user_users;
DEFAULT_TABLESPACE
USERS
flip@FLOP> select SEGMENT_SPACE_MANAGEMENT from user_tablespaces where tablespace_name='USERS';
SEGMEN
AUTO
flip@FLOP> create table yes ( c clob );
Table created.
flip@FLOP> select dbms_metadata.get_ddl('TABLE','YES') from dual;
DBMS_METADATA.GET_DDL('TABLE','YES')
CREATE TABLE "FLIP"."YES"
( "C" CLOB
) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "USERS"
LOB ("C") STORE AS (
TABLESPACE "USERS" ENABLE STORAGE IN ROW CHUNK 8192 PCTVERSION 10
NOCACHE
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT))

Questio about ASSM managed tablespaces?

Hi, we have a 2 node RAC cluster running 10.2.0.3 on linux itanium and we have some tablespaces that we have configiured using ASSM with automatic allocation set for extent mgmt and also automagic for segment space mgmt.
We are an online E-tail site and we have periods of high trafffic and have alot of updates happening in the database with objects that are in the new table spaces and ny question is...Would it be wiser to not let oracle handle to extent mgmt and instead set the uniform allocation for extents?
My other question is, can you preallocate extents so that the application would never have to wait when the next extent has to be initialized into the segment?
Thanks.

I personally prefer uniform extents and, in cases like yours, pre-allocation.
It also makes sense in environments where traffic is predictable to set up large extents so that fewer allocations/time are required.
At least that is what I have seen in my testing. Your mileage may vary so test it on your hardware and version.

DBMS_SPACE_ADMIN ASSM

Similar Messages

Maybe you are looking for