Re-organizing table to reclaim space

Hi All,
Recently we have purged data from some tables in the database.
Is it necessary to reorganize the table to reclaim space after we remove the data from the tables? How can we find out that the table can be reorganized?
Database version:11.2.0.2
OS version:AIX

how did you purge the data?
have you used delete or truncate.
please check space under dba_segments for particular object which was purged.
from 10g onwards we have segment advisor.
The segment advisor performs analysis on the fragmentation of specified tablespaces, segments or objects and makes recommendations on how space can be reclaimed. The advisor is accessible from Enterprise Manager (Home > Advisor Central > Segment Advisor) or from PL/SQL by using the DBMS_ADVISOR package.
https://forums.oracle.com/forums/ann.jspa?annID=718
Please close the thread after marking it helpful or correct if you get the answer.
Thanks
Kuljeet Pal Singh

Similar Messages

Need to reclaim space from dwh tables.

We have couple of large tables (> 200G) in one of the DWH schema. I need to reclaim space on the mountpoint.
I have used ALTER TABLE <> MOVE COMPRESS; command to compress these tables.
Now in dba_segments it is showing the improvement. 200g table came down to 60G. However I am not able to see any change in datafile and in mountpoint, I beleive due to the HWM.
I tried shrink for the tables, it did not help.
Could you please suggest any other approach.

refer to
http://jonathanlewis.wordpress.com/2010/01/30/free-space/
http://jonathanlewis.wordpress.com/2010/02/06/shrink-tablespace/
Anand

Index Organized Tables

what is logical rowid in IOT?are they stored somwhere physically just like physical rowId's
what are secondary indexes?
what it means by leaf block splits?when and how it happens?
and the primary key constraint for an index-organized table cannot be dropped, deferred, or disabled,,,,,Is it true,,,,,if Yes Then Y
how does overflow works?how the two clauses are implemented PCTTHRESHOLD and INCLUDING.how they work?
Edited by: Juhi on Oct 22, 2008 1:09 PM

I'm sort-of tempted to just point you in the direction of the official documentation (the concepts guide would be a start. See http://download.oracle.com/docs/cd/B28359_01/server.111/b28318/schema.htm#sthref759)
But I would say one or two other things.
First, physical rowids are not stored physically. I don't know why you'd think they were. The ROWID data type can certainly be used to store a rowid if you choose to do so, but if you do something like 'select rowid from scott.emp', for example, you'll see rowids that are generated on-the-fly. ROWID is a pseudo-column, not physically stored anywhere, but computed whenever needed.
The difference between a physical rowid and a logical one used with IOTs comes down to a bit of relational database theory. It is a cast-iron rule of relational databases that a row, once inserted into a table, must never move. That is, the rowid it is assigned at the moment of its first insertion, must be the rowid it 'holds onto' for ever and ever. If you ever want to change the rowids assigned to rows in an ordinary table, you have to export them, truncate the table and then re-insert them: fresh insert, fresh rowid. (Oracle bends this rule for various maintenance and management purposes, whereby 'enable row movement' permits rows to move within a table, but the general case still applies mostly).
That rule is obviously hopeless for index structures. Were it true, an index entry for 'Bob' who gets updated to 'Robert' would find itself next to entries for 'Adam' and 'Charlie', even though it now has an 'R' value. Effectively, a 'b' "row" in an index must be allowed to "move" to an 'r' sort of block if that's the sort of update that takes place. (In practice, an update to an index entry consists of performing a delete followed by a re-insert, but the physicalities don't change the principle: "rows" in an index must be allowed to move if their value changes; rows in a table don't move, whatever happens to their values)
An IOT is, at the end of the day, simply an index with a lot more columns in it than a "normal" index would have -so it, too, has to allow its entires (its 'rows', if you like) to move. Therefore, an IOT cannot use a standard ROWID, which is assigned once and forever. Instead, it has to use something which takes account of the fact that its rows might wander. That is the logical rowid. It's no more "physical" than a physical rowid -neither are physically stored anywhere. But a 'physical' rowid is invariant; a logical one is not. The logical one is actually constructed in part from the primary key of the IOT -and that's the main reason why you cannot ever get rid of the primary key constraint on the IOT. Being allowed to do so would equate to allowing you to destroy the one organising principle for its contents that an IOT possesses.
(See the section entitled "The ROWID Pseudocolumn" and following on this page: http://download.oracle.com/docs/cd/B28359_01/server.111/b28318/datatype.htm#CNCPT1845
So IOTs have their data stored in them in primary key order. But they don't just contain the primary key, but every other column in the 'table definition' too. Therefore, just like with an ordinary table, you might want sometimes to search for data on columns which are NOT part of the primary key -and in that case, you might well want these non-primary key columns to be indexed. Therefore, you will create ordinary indexes on these columns -at this point, you're creating an index on an index, really, but that's a side issue, too! These extra indexes are called 'secondary indexes', simply because they are 'subsidiary indexes' to the main one, which is the "table" itself arranged in primary key order.
Finally, a leaf block split is simply what happens when you have to make room for new data in an index block which is already packed to the rafters with existing data. Imagine an index block can only contain four entries, for example. You fill it with entries for Adam, Bob, Charlie, David. You now insert a new record for 'Brian'. If this was a table, you could throw Brian into any new block you like: data in a table has no positional significance. But entries in an index MUST have positional significance: you can't just throw Brian in amongst the middle of a lot of Roberts, Susans and Tanyas. Brian HAS to go in between the existing entires for Bob and Charlie. Yet you can't just put him in the middle of those two, because then you'd have five entries in a block, not four, which we imagined for the moment to be the maximum allowed. So what to do? What you do is: obtain a new, empty block. Move Charlie and David's entries into the new block. Now you have two blocks: Adam-Bob and Charlie-David. Each only has two entries, so each has two 'spaces' to accept new entries. Now you have room to add in the entry for Brian... and so you end up with Adam-Bob-Brian and Charlie-David.
The process of moving some index entries out of one block into a new one so that there's room to allow new entries to be inserted in the middle of existing ones is called a block split. They happen for other reasons, too, so this is just a gloss treatment of them, but they give you the basic idea. It's because of block splits that indexes (and hence IOTs) see their "rows" move: Charlie and David started in one block and ended up in a completely different block because of a new (and completely unrelated to them) insert.
Very finally, overflow is simply a way of splitting off data into a separate table segment that wouldn't sensibly be stored in the main IOT segment itself. Suppose you create an IOT containing four columns: one, a numeric sequence number; two, a varchar2(10); three, a varchar2(15); and four, a blob. Column 1 is the primary key.
The first three columns are small and relatively compact. The fourth column is a blob data type -so it could be storing entire DVD movies, multi-gigabyte-sized monsters. Do you really want your index segment (for that is what an IOT really is) to balloon to huge sizes every time you add a new row? Probably not. You probably want columns 1 to 3 stored in the IOT, but column 4 can be bumped off over to some segment on its own (the overflow segment, in fact), and a link (actually, a physical rowid pointer) can link from the one to the other. Left to its own devices, an IOT will chop off every column after the primary key one when a record which threatens to consume more than 50% of a block gets inserted. However, to keep the main IOT small and compact and yet still contain non-primary key data, you can alter these default settings. INCLUDE, for example, allows you to specify which last non-primary key column should be the point at which a record is divided between 'keep in IOT' and 'move out to overflow segment'. You might say 'INCLUDE COL3' in the earlier example, so that COL1, COL2 and COL3 stay in the IOT and only COL4 overflows. And PCTTHRESHOLD can be set to, say, 5 or 10 so that you try to ensure an IOT block always contains 10 to 20 records -instead of the 2 you'd end up with if the default 50% kicked in.

Reclaim space at OS level.

Dear all
I have performed following activities to reclaim space at database level on development system but I am quite suspicious about to reclaim at OS level.
1) Choose baldat table for REORG candidate
2) Size of table before deleting record was 11GB
3) Delete record from it using slg2
4) Offline REORG done
5) Table size is now around 2.5GB
6) Since database is DB9.7 and tablespace is in DMS type, I need to issue two command as following to reclaim space at DB and OS level.
     alter tablespace TCD#BTABD lower high water mark
     ALTER TABLESPACE TCD#BTABD REDUCE (ALL CONTAINERS G/K/M)
7) I have issued only first command to lower HWM which freed up space at Database level.
     Checked from DBACOKPIT to see tablespace status as following
     Tablespace Name     KB Total     Percent Used     KB Free     Page Size (KB)     High-Water Mark (KB)
     TCD#BTABD            16121856        33.25           10762016       16                         5359712
Now my query is I want to reduce it down by 9GB at OS level so which figure I have to put (??) on the following. Is there any harm to execute this command on the fly which causes database issue???
      ALTER TABLESPACE TCD#BTABD REDUCE (ALL CONTAINERS ??? G/K/M)
Thanks
Mehul

Hi,
I have a following output from abovemention query
TBSP_NAME                      TBSP_TYPE RECLAIMABLE_SPACE_ENABLED
SYSCATSPACE                    DMS                                1
SAPTOOLS                       DMS                                1
SAPEVENTMON                    DMS                                1
PSAPTEMP16                     SMS                                0
SYSTOOLSTMPSPACE               SMS                                0
SYSTOOLSPACE                   DMS                                1
TCD#STABD                      DMS                                1
TCD#STABI                      DMS                                1
TCD#BTABD                      DMS                                1
TCD#BTABI                      DMS                                1
TCD#CLUD                       DMS                                1
TCD#CLUI                       DMS                                1
TCD#POOLD                      DMS                                1
TCD#POOLI                      DMS                                1
TCD#DDICD                      DMS                                1
TCD#DDICI                      DMS                                1
TCD#DOCUD                      DMS                                1
TCD#DOCUI                      DMS                                1
TCD#EL702D                     DMS                                1
TCD#EL702I                     DMS                                1
TCD#LOADD                      DMS                                1
TCD#LOADI                      DMS                                1
TCD#PROTD                      DMS                                1
TCD#PROTI                      DMS                                1
TCD#ES702D                     DMS                                1
TCD#ES702I                     DMS                                1
TCD#SOURCED                    DMS                                1
TCD#SOURCEI                    DMS                                1
TCD#USER1D                     DMS                                1
TCD#USER1I                     DMS                                1
TCD#DIMD                       DMS                                1
TCD#DIMI                       DMS                                1
TCD#FACTD                      DMS                                1
TCD#FACTI                      DMS                                1
TCD#ODSD                       DMS                                1
TCD#ODSI                       DMS                                1
36 record(s) selected.
Thanks
Mehul

Can't reclaim space in tablespace after deleting records

Oracle 11gR1 RHEL5 64bit
Hi.
I am having trouble reclaiming space from a tablespace after having deleted all (thousands) of the records from a table (which resides in that tablespace). I have tried the following options to no avail:
- Alter table <table_name> shrink
- purge tablespace
- purge recyclebin
This table has several LOB columns and is using securefiles. I don't know if that has something to do with it or not. The tablespace is locally Managed and Segment space management is set to AUTO. Below is the create table command:
CREATE TABLE IIQ.DICOM_OBJECT
DICOM_OBJECT_RID NUMBER CONSTRAINT NN_DICOM_OBJECT_DICOM_OBJ_RID NOT NULL,
SUBMISSION_RID NUMBER,
SUBMISSION_ITEM_RID NUMBER,
DICOM ORDSYS.ORDDICOM,
IMAGETHUMB ORDSYS.ORDIMAGE,
ANONDICOM ORDSYS.ORDDICOM,
ACTIVE_FLAG VARCHAR2(1 CHAR) DEFAULT 'Y' CONSTRAINT NN_DICOM_OBJECT_ACTIVE_FLAG NOT NULL,
CREATED_TIMESTAMP TIMESTAMP(6) WITH LOCAL TIME ZONE DEFAULT SYSTIMESTAMP CONSTRAINT NN_DICOM_OBJECT_TIMESTAMP NOT NULL,
SOURCE_DESCRIPTION VARCHAR2(100 CHAR) CONSTRAINT NN_DICOM_OBJECT_SOURCE NOT NULL,
OP_CONFORMANCE_FLAG VARCHAR2(1 CHAR)
COLUMN IMAGETHUMB NOT SUBSTITUTABLE AT ALL LEVELS
TABLESPACE IIQDCMDAT01
PCTUSED 0
PCTFREE 10
INITRANS 1
MAXTRANS 255
STORAGE (
INITIAL 80K
NEXT 1M
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
LOGGING
NOCOMPRESS
LOB ("DICOM"."EXTENSION") STORE AS SECUREFILE
( TABLESPACE IIQDCMLOB01
DISABLE STORAGE IN ROW
CHUNK 16384
RETENTION
NOCACHE
INDEX (
TABLESPACE IIQDCMLOB01
STORAGE (
INITIAL 80K
NEXT 1
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
STORAGE (
INITIAL 208K
NEXT 1M
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
LOB (SYS_NC00050$) STORE AS
( TABLESPACE IIQDCMDAT01
ENABLE STORAGE IN ROW
CHUNK 16384
PCTVERSION 10
NOCACHE
INDEX (
TABLESPACE IIQDCMDAT01
STORAGE (
INITIAL 80K
NEXT 1
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
STORAGE (
INITIAL 80K
NEXT 1M
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
LOB ("DICOM"."SOURCE"."LOCALDATA") STORE AS SECUREFILE
( TABLESPACE IIQDCMLOB01
DISABLE STORAGE IN ROW
CHUNK 16384
RETENTION
NOCACHE
INDEX (
TABLESPACE IIQDCMLOB01
STORAGE (
INITIAL 80K
NEXT 1
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
STORAGE (
INITIAL 208K
NEXT 1M
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
LOB ("ANONDICOM"."SOURCE"."LOCALDATA") STORE AS SECUREFILE
( TABLESPACE IIQDCMLOB01
DISABLE STORAGE IN ROW
CHUNK 16384
RETENTION
NOCACHE
INDEX (
TABLESPACE IIQDCMLOB01
STORAGE (
INITIAL 80K
NEXT 1
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
STORAGE (
INITIAL 208K
NEXT 1M
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
XMLTYPE SYS_NC00017$ STORE AS CLOB
( TABLESPACE IIQDCMLOB01
DISABLE STORAGE IN ROW
CHUNK 16384
RETENTION
CACHE READS
INDEX (
TABLESPACE IIQDCMLOB01
STORAGE (
INITIAL 80K
NEXT 1
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
STORAGE (
INITIAL 208K
NEXT 1M
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
LOB ("IMAGETHUMB"."SOURCE"."LOCALDATA") STORE AS SECUREFILE
( TABLESPACE IIQDCMLOB01
DISABLE STORAGE IN ROW
CHUNK 16384
RETENTION
NOCACHE
INDEX (
TABLESPACE IIQDCMLOB01
STORAGE (
INITIAL 80K
NEXT 1
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
STORAGE (
INITIAL 208K
NEXT 1M
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
LOB ("ANONDICOM"."EXTENSION") STORE AS SECUREFILE
( TABLESPACE IIQDCMLOB01
DISABLE STORAGE IN ROW
CHUNK 16384
RETENTION
NOCACHE
INDEX (
TABLESPACE IIQDCMLOB01
STORAGE (
INITIAL 80K
NEXT 1
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
STORAGE (
INITIAL 208K
NEXT 1M
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOCACHE
NOPARALLEL
MONITORING
ENABLE ROW MOVEMENT;
Thank you all.

Justin Cave wrote:
OK, so you did a SHRINK SPACE CASCADE? Not just a SHRINK SPACE?That is correct.
What makes you believe that there is more space that can be reclaimed? Well, what I don't understand is that when a table (and only that table) was assigned to a specific tablespace whose data was completely removed is showing as if the data is still there...at least when you look at the tablespace. If all the rows of a table are removed, then shouldn't the tablespace size go down? There was 95 GB of data in that tablespace and all from that one table, which was completely emptied. However, it still shows the tablespace as being 95GB full.
Can you post the size of the table segment and the LOB segments as well as the size of the actual data in the table and the LOBs?Can you tell me which views you would like to the see the data from ? dba_lobs, dba_segments, etc... I want to make sure i have the right query for you.
Here is some info...not sure if this is what you want (formatiing is off):
select owner, segment_name, segment_type, tablespace_name, bytes
from dba_segments
where owner = 'IIQ'
and tablespace_name = 'IIQDCMLOB01'
and segment_type = 'LOBSEGMENT';
OWNER SEGMENT_NAME SEGMENT_TYPE TABLESPACE_NAME BYTES
IIQ SYS_LOB0000651630C00012$$ LOBSEGMENT IIQDCMLOB01 9.8416E+10
IIQ SYS_LOB0000651630C00018$$ LOBSEGMENT IIQDCMLOB01 755236864
IIQ SYS_LOB0000651630C00021$$ LOBSEGMENT IIQDCMLOB01 755236864
IIQ SYS_LOB0000651630C00023$$ LOBSEGMENT IIQDCMLOB01 262144
IIQ SYS_LOB0000651630C00044$$ LOBSEGMENT IIQDCMLOB01 262144
IIQ SYS_LOB0000651630C00053$$ LOBSEGMENT IIQDCMLOB01 262144
OWNER TABLE_NAME
COLUMN_NAME
----------------------------------- SEGMENT_NAME TABLESPACE_NAME INDEX_NAME CHUNK PCTVERSION RETENTION FREEPOOLS CACHE LOGGING ENCR COMPRE DEDUPLICATION IN_ FORMAT PAR SEC
IIQ DICOM_OBJECT
"DICOM"."SOURCE"."LOCALDATA"
SYS_LOB0000651630C00012$$ IIQDCMLOB01 SYS_IL0000651630C00012$$ 16384 10800 NO YES NO NO NO NO NOT APPLICABLE NO YES
IIQ DICOM_OBJECT
SYS_NC00018$
SYS_LOB0000651630C00018$$ IIQDCMLOB01 SYS_IL0000651630C00018$$ 16384 10800 CACHEREADS YES NO NO NO NO ENDIAN NEUTRAL NO YES
IIQ DICOM_OBJECT
"DICOM"."EXTENSION"
SYS_LOB0000651630C00021$$ IIQDCMLOB01 SYS_IL0000651630C00021$$ 16384 10800 NO YES NO NO NO NO NOT APPLICABLE NO YES
IIQ DICOM_OBJECT
"IMAGETHUMB"."SOURCE"."LOCALDATA"
SYS_LOB0000651630C00023$$ IIQDCMLOB01 SYS_IL0000651630C00023$$ 16384 10800 NO YES NO NO NO NO NOT APPLICABLE NO YES
IIQ DICOM_OBJECT
"ANONDICOM"."SOURCE"."LOCALDATA"
SYS_LOB0000651630C00044$$ IIQDCMLOB01 SYS_IL0000651630C00044$$ 16384 10800 NO YES NO NO NO NO NOT APPLICABLE NO YES
IIQ DICOM_OBJECT
"ANONDICOM"."EXTENSION"
SYS_LOB0000651630C00053$$ IIQDCMLOB01 SYS_IL0000651630C00053$$ 16384 10800 NO YES NO NO NO NO NOT APPLICABLE NO YES
Thanks.

Reclaim space from DBFs

Hi All,
I have one query regarding tablespace reclaim space. I have users tablespace which is having 5 dbfs. Some of the DBFs of USERS tablespace having autoextend on with max size 32G and some of the DBFs not having autoextend on and maxsize 4G.
Now when I checked the USERS TBS through EM , I come to know only few MBs out of 20G are in used in 3 DBFs of USERS tablespace and rest of 2 dbfs are in good in use. Now I want to reclaim the space from 3 dbfs say users03,users04 and users05. users01 and users02 are properly in used. I want to reclaim the space from 03,04 and 05.
can I have any idea how to reclaim space from dbfs? I try with alter database datafile ...resize but giving error "ORA-03297: file contains used data beyond requested RESIZE value".
please suggest me,
Thanks...

Yes, I think you are understanding how it works. For a visual example, if this is your data file:
XXXX--XX-XXXX-XXXX-XXXX-XXXXXXX-----------------
and you delete some data
XX----X--------X------------------X-----------------
The datafile can be resized only down to
XX----X--------X------------------X
Which tools are available to do this efficiently vary by database version, for example in my 9.2.0.6 database I can use exp/imp, CREATE TABLE AS SELECT, rebuild indexes (mostly) online, exp/imp, move LOBs around with ALTER TABLE ... MOVE LOB, or other strategies - some of these are more work than others, and all will take some amount of time. In 8i There are fewer options; beginning with 10g data pump and DBMS_REDEFINITION are available; in 11g the index rebuilds don't lock the data, so the time may be less of a concern.
Before you even spend the time to shrink these data files, consider the space needs for USERS. If the extended size was a one-time thing, then shrinking datafiles may be justified. If USERS may grow that large again then a data file shrink is a lot of work for little gain.

Benefits of Reorg to reclaim space in Oracle

Hi All,
I have archived and deleted records from few big tables from my database, now how want to reclaim space by doing reorg.
Can anyone please guide me how to find out If I can reclaim some space by doing reorg.
What are the queries which can help me find out space used before and after reorg.
Thanks & Regards,
Deepak

You cannot do much with a long raw short of export/import it - so you would export it, drop the old table, create a new one in the new tablespace and import with ignore=y. Other objects can be online redefined into this tablespace - or indexes if they are in there can be rebuilt online into this new tablespace, but moving the long raw is going to be offline.
Source:Ask Tom &quot;Reclaim space&quot;
Shrink, Move, CTAS (Reclaiming space) do not works for LONG datatype. For LONG dataype export/import is the best and feasible solution.
Regards
Girish Sharma

Query needed to find reclaimable space in db

10.2.0.4
Linux 4.
Hi.
On a test database I suspect there are a lot of objects that are not needed that are taking up valuable disk space. These may include tables that are backups of tables etc.
Does anyone have a tested query to seek out these objects? They will have probably been named test, or backup, etc.
Thanks in advance.

Apparently you want to find candidate junk objects to discard. This is a quite specific subset of the overall issue of finding reclaimable space. In the overall issue a lot of attention should be paid to whether temporarily supressing some free space (due to massive deletions, for example) is worthwhile. In the subset you inquire about, if you can identify the junk it is almost certainly a win to discard it. Some shops have naming standards for objects not officially sanctioned in the production schema. My favorite is the prefix JUNK_<initials>_, so that all the objects can be found quickly with the wildcard on the efficient end of the query, as in:
select owner,object_name,object_type
   from dba_objects
   where object_name like 'JUNK%'
   order by object_name;
or
select owner,object_name,object_type
   from dba_objects
   where object_name like 'JUNK_MWF%'
   order by object_name;Even just the naming convention makes it easy to identify candidate objects, and if you have rules about creating "JUNK" objects such as maintaining a log with expiration dates and purposes, then further inquiry is easy. Having the object's sponsor's initials at hand makes a personal interview possible if the log entries are not useful, and if an expiration date is provided you can simply use the log table as a list to control deleting discardable objects.
In your case you are dealing with catching the horses after the stalls and barn door were left open. Up to now I've written more about closing the barn door for future efforts.
For the cleanup, the similar query with the like predicate '%TEST' and other candidate name templates should suffice. Depending on how creative folks have been spelling TST and BCKUP, you may want to play with the regex functions. Just be sure to treat the generated list as a list of candidates. Depending on the length of the list you can then either generate the appropriate drop statement by type or simply type them into a file for review and execution. Sending out the list of objects to be deleted with a reasonable warning period is highly recommended, since having the ability to create unknown objects often implies sufficient rank to ignore organizational rules. Whether creating an individual object export prior to the drop will vary from site to site and by the size of the object to be dropped.
Good luck,
mwf (aka pudge)

Why Index-organized Table (IOT) is so slow during bulk/initial insert?

Tested in 11.1.0.7.0 RAC on RHEL 5 with ASM and 16KB block size.
Table is not wide: PK contains 4 columns and the leading 2 are compressed because they have relatively low cardinality; 2 other columns are included; the table contains another 4 audit columns; overflow table space defined.
Created 2 tables, one is IOT, the other is a normal heap-organized table with "COMPRESS FOR ALL OPERATIONS". Both tables have been range partitioned by the first column into 8 partitions, and DOP is set to 8.
Initial load volume is about 160M rows. Direct Path insert is used with parallel degree 8.
After initial load, create PK for the 4 columns with the leading 2 compressed on the normal table. The IOT occupied about 7GB storage; the normal table occupied 9GB storage (avg_row_len = 80 bytes) and the PK occupied 5.8GB storage.
The storage saving of IOT is significant, but it took about 60 minutes to load the IOT, while it only took 10 minutes to load the heap-organized table and then 6 minutes to create the PK. Overall, the bulk insert for IOT is about 4 times slower than the equivalent heap-organized table.
I have ordered the 4 columns in PK for the best compression ratio (lower cardinality comes first) and only compress the most repetitive leading columns (this matches ORACLE's recommendation in index_stats after validate structure), partition is used to reduce contention, parallel degree is amble, /*+ append */ is used for insert, the ASM system is backed with high-end SAN with a lot of I/O bandwidth.
So it seems that such table is good candidate for IOT and I've tried a few tricks to get the best out of IOT, but the insert performance is quite disappointing. Please advise me if I missed anything, or you have some tips to share.
Thanks a lot.
CREATE TABLE IOT_IS_SLOW
GROUP_ID      NUMBER(2)                   NOT NULL,
BATCH_ID      NUMBER(4)                  NOT NULL,
KEY1              NUMBER(10)                    NOT NULL,
KEY2              NUMBER(10)                NOT NULL,
STATUS_ID         NUMBER(2)                   NOT NULL,
VERSION           NUMBER(10),
SRC_LAST_UPDATED      DATE,
SRC_CREATION_DATE     DATE,
DW_LAST_UPDATED   DATE,
DW_CREATION_DATE DATE,
CONSTRAINT PK_IOT_IS_SLOW
PRIMARY KEY (GROUP_ID, BATCH_ID, KEY1, KEY2)
ORGANIZATION INDEX COMPRESS 2
INCLUDING VERSION
NOLOGGING
PCTFREE 20
OVERFLOW
PARALLEL ( DEGREE 8 )
PARTITION BY RANGE(GROUP_ID)
     PARTITION P01 VALUES LESS THAN (2),
     PARTITION P02 VALUES LESS THAN (3),
     PARTITION P03 VALUES LESS THAN (4),
     PARTITION P04 VALUES LESS THAN (5),
     PARTITION P05 VALUES LESS THAN (6),
     PARTITION P06 VALUES LESS THAN (7),
     PARTITION P07 VALUES LESS THAN (8),
     PARTITION P08 VALUES LESS THAN (MAXVALUE)
);Even if /*+ APPEND */ is ignored for IOT, it is too slow, isn't it?

David_Aldridge wrote:
oftengo wrote:
>
Direct-path INSERT into a single partition of an index-organized table (IOT), or into a partitioned IOT with only one partition, will be done serially, even if the IOT was created in parallel mode or you specify the APPEND or APPEND_VALUES hint. However, direct-path INSERT operations into a partitioned IOT will honor parallel mode as long as the partition-extended name is not used and the IOT has more than one partition.
>
http://download.oracle.com/docs/cd/E11882_01/server.112/e17118/statements_9014.htm
Hmmm, that's very interesting. I'm still a bit cynical though -- in order for direct path to work on an index organized table by appending blocks I would think that some extra conditions would have to be satisfied:
* the table would have to be empty, or the lowest-sorting row of the new data would have to be higher than the highest-sorting row of the existing data
* the data would have to be sorted
... that sort of thing. Maybe I'm suffering a failure of imagination though.Could be. From a Tanel Poder post:
>
The “direct path loader” (KCBL) module is used for performing direct path IO in Oracle, such as direct path segment scans and reading/writing spilled over workareas in temporary tablespace. Direct path IO is used whenever you see “direct path read/write*” wait events reported in your session. This means that IOs aren’t done from/to buffer cache, but from/to PGA directly, bypassing the buffer cache.
This KCBL module tries to dynamically scale up the number of asynch IO descriptors (AIO descriptors are the OS kernel structures, which keep track of asynch IO requests) to match the number of direct path IO slots a process uses. In other words, if the PGA workarea and/or spilled-over hash area in temp tablespace gets larger, Oracle also scales up the number of direct IO slots. Direct IO slots are PGA memory structures helping to do direct IO between files and PGA.
>
So I'm reading into this that somehow these temp segments handle it, perhaps because with parallelism you have to be able to deal anyway. I speculate the data is inserted past the high water mark, then any ordering issues left can be resolved before moving the high water mark(s). Maybe examining where segments wind up in the data files can show how this works.
>
I can't find anything in the documentation that speaks to this, so I wonder whether the docs are really talking about a form of conventional path parallel insert into an IOT and not true direct path inserts.
One way to check, I think, would be to get the wait events for the insert and see whether the writes are direct.

Shrink / reclaim space

what is the best proceedure to reclaim or shrink a 109GB of reclaimable space? w/o using alot of disk space.
tyia

1. ALTER TABLE tablename SHRINK SPACE COMPACT;
-> DML operations and queries can be issued during compaction.
2. ALTER TABLE tablename SHRINK SPACE;
-> DML operations are blocked when the HWM is adjusted.
When you specify the SHRINK SPACE COMPACT clause, the progress of the shrink operation is saved in the bitmap blocks of the corresponding segment. This means that the next time a shrink operation is executed on the same segment, the Oracle database server remembers what has been done already. You can then reissue the SHRINK SPACE clause without the COMPACT clause during off-peak hours to complete the second phase.

Clear FND_LOBS to reclaim space in applsysd

we have on LOB in applsysd tablespace which is taking 20% space in tablespace. I do not need this, please advise how to move to reclaim space on it.
I have LOB segment details and we can findout LOB files location in FND_LOBS, but wondering how to match both of these.

Review the following notes:
Note: 303709.1 - Reclaiming unused space in APPLSYSD tablespace
https://metalink2.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=303709.1
Note: 298698.1 - Avoiding abnormal growth of FND_LOBS table in Applications 11i
https://metalink2.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=298698.1
Note: 555463.1 - How to Purge Generic or Purchasing Attachments from the FND_LOBS Table
https://metalink2.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=555463.1

Creation of context index on index-organized table

I encountered a problem when creating a domain index(intermediate text context index) on a index-organised table in oracle 8i.
The description of the error is stated below:
"ORA-29866: cannot create domain index on a column of index-organized table "
I have configured intermediate text properly and even it worked for those tables which are not index-organised(ordinary tables).
This problem has occured only when i made the tables as index organised.
Please provide us a solution to this problem as early as possible.
In case if you require any more details i shall provide them.

Please ask questions about Oracle Text (formerly interMedia text) in the Oracle Text forum. You will get a quicker, more expert answer there.

Creation of context index on index-organized tables

I encountered a problem when creating a domain index(intermediate text context index) on a index-organised table in oracle 8i.
The description of the error is stated below:
"ORA-29866: cannot create domain index on a column of index-organized table "
I have configured intermediate text properly and even it worked for those tables which are not index-organised(ordinary tables).
This problem has occured only when i made the tables as index organised.
Please provide us a solution to this problem as early as possible.
In case if you require any more details i shall provide them.

creation of domain indexes (such as context) on iot's
is not currently supported in oracle.

Finding Parent Table of Index Organized Table

I am using Oracle 10g Rel 2 and faced error message while granting select priviliges ORA-25191: cannot reference overflow table of an index-organized table
I searched solution and found: Issue the statement against the parent index-organized table containing the specified overflow table.
Question is how can i find parent index-organized table containing the specified overflow table.
Further i faced an other error while granting select priviliges : ORA-22812: cannot reference nested table column's storage table
Solution is same and i found parent table and first granted select priviliges on that parent table and then tried then tried to grant select priviliges on required table to public and did not worked.
if some body could help me!!!!!!!!!!!!!!!!!!!!!

And just what does this problem have to do with either the SQL and/or PL/SQL languages?
Try the [url http://forums.oracle.com/forums/forum.jspa?forumID=61&start=0]Community Discussion Forums » Database » Database - General forum.
Also suggest that you read up on just what an IOT is, and where and when overflows apply. See the [url http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/schema.htm#sthref1060]Oracle® Database Concepts guide.

Problem with a 2 columns Range Partitioning for a indexed organized table

have an indexed organized table with a 2 column PK. the first field (datum) is a date field the second field (installatieid) is a number(2) field.
Every minute a 7 records are inserted (installatieid 0-6).
I like to partition this table with one partition per year per installatieid.
I tried to do it with:
partition by range(datum,installatieid)
(partition P_2004_0 values less than (to_date('2004-01,'yyyy-mm'),1)
,partition P_2004_6 values less than (to_date('2004-01','yyyy-mm'),7)
partition P_2005_0 values less than (to_date('2005-01','yyyy-mm'),1)
,partition P_2005_6 values less than (to_date('2005-01','yyyy-mm'),7)
but now only the P_2004_0 and P_2005_0 are filled.
I thought about to combine a range partition on datum with a list subpartition on installatieid, but I read this is not allowed with an index organized table.
How can I solve this problem.

partition by range(datum,installatieid)
(partition P_2004_0 values less than
(to_date('2004-01,'yyyy-mm'))
,partition P_2004_6 values less than
(to_date('2004-07','yyyy-mm'))
partition P_2005_0 values less than
(to_date('2005-01','yyyy-mm'))
,partition P_2005_6 values less than
(to_date('2005-07','yyyy-mm'))
? Sorry haven't got time to test it this morning ;0)

Re-organizing table to reclaim space

Similar Messages

Maybe you are looking for