Regarding LOB index

Hi,
I am having a SQL loader mapping where in I am loading data from a CSV file to Oracle target table.
My target table is having a CLOB column. Now, due to this a LOB index has also been created for this column.
My CSV is having 1 million records and when I execute the mapping it gets hang and doesnot load anything.
I think that due to that LOB index the execution is taking so long. Is there any way that I can disable this index during run-time. I tried but it gave me error: ORA-22864: cannot ALTER or DROP LOB indexes.
Can anyone of you suggest any alternate to this.
Thanks!!!!

Hey Fren,
We have Secondary index to shorten the search time and thus to increase the proficiency in selecting the accurate records from numerous fields available for the option...
That means, we can say that Secondary Index can act as an Extension to the Primary Key fields available to Shorten the Search time.....
But if you use 'OR' condition and give a SELECT Query in your report it will act as the reverse effect of Secondary index......
Instead you can create the Secondary Index including the key fields with some extension to the same...
Means For example,
Table 1:
Field1 [x] CHAR 10
Field2 [x] CHAR 10
Field3 [ ] NUMC 10
Field4 [ ] CHAR 10
Field5 [ ] CHAR 10
Field6 [ ] NUMC 10
Field7 [ ] CHAR 10
Field8 [ ] CHAR 10
Field9 [ ] NUMC 10
Field10 [ ] CHAR 10
Field11 [ ] CHAR 10
Field12 [ ] NUMC 10
Field13 [ ] CHAR 10
Field14 [ ] CHAR 10
Field15 [ ] NUMC 10
Field16 [ ] CHAR 10
Field17 [ ] CHAR 10
Field18 [ ] NUMC 10
Field19 [ ] CHAR 10
Field20 [ ] CHAR 10
Field21 [ ] NUMC 10
Field22 [ ] CHAR 10
Field23 [ ] CHAR 10
Field24 [ ] NUMC 10
So you can have Field 3 Field4 Field5 Field6 as your secondary index.....
Thats it,
Thank you,
Inspire If Needful,
Warm Regards,
Abhi

Similar Messages

Regarding sy-index and sy-tabix

Hi,
What is the major difference between sy-index and sy-tabix ,
can you give me one good example with code..
Regards,
Reddy.

Hi,
SY-TABIX - Current line of an internal table. SY-TABIX is set by the statements below, but only for index tables. The field is either not set or is set to 0 for hashed tables.
APPEND sets SY-TABIX to the index of the last line of the table, that is, it contains the overall number of entries in the table.
COLLECT sets SY-TABIX to the index of the existing or inserted line in the table. If the table has the type HASHED TABLE, SY-TABIX is set to 0.
LOOP AT sets SY-TABIX to the index of the current line at the beginning of each loop lass. At the end of the loop, SY-TABIX is reset to the value that it had before entering the loop. It is set to 0 if the table has the type HASHED TABLE.
READ TABLE sets SY-TABIX to the index of the table line read. If you use a binary search, and the system does not find a line, SY-TABIX contains the total number of lines, or one more than the total number of lines. SY-INDEX is undefined if a linear search fails to return an entry.
SEARCH FOR sets SY-TABIX to the index of the table line in which the search string is found.
SY_INDEX - In a DO or WHILE loop, SY-INDEX contains the number of loop passes including the current pass.
sy-tabix is the tab index - the index of the record in the internal table you are accessing,
sy-index is the loop counter.
If you use a condition in LOOP the sy-index will go from 1 to n, but sy-tabix will refer to the line in the internal table.
Hope this helps u.
Thanks,
Ruthra

Regarding Renaming INDEX Partitions

Hi All,
I have the following syntax for renaming table partitions/subpartitions :
ALTER TABLE SMTP_MSG_TRAFFIC_FCT RENAME PARTITION FOR (20100310) TO BASE_FACT_20100310;
ALTER TABLE SMTP_MSG_TRAFFIC_FCT RENAME SUBPARTITION FOR (20100310,19) TO BASE_FACT_20100310_MAILBOX;
I want to do the same thing for renaming the index partitions/subpartitions :
ALTER INDEX SMTP_MSG_TF_FX02_ARR_TM_DIM_ID RENAME PARTITION FOR (20100310) TO BASE_FACT_20100310;
ALTER TABLE SMTP_MSG_TF_FX02_ARR_TM_DIM_ID RENAME SUBPARTITION FOR (20100310,19) TO BASE_FACT_20100310_MAILBOX;
But I get the following error:
SQL> ALTER INDEX SMTP_MSG_TF_FX02_ARR_TM_DIM_ID RENAME PARTITION FOR (20100310) TO BASE_FACT_20100310;
ALTER INDEX SMTP_MSG_TF_FX02_ARR_TM_DIM_ID RENAME PARTITION FOR (20100310) TO BASE_FACT_20100310
ERROR at line 1:
ORA-14006: invalid partition name
Is it possible to rename the partition in this way? Or can I set any parameter that will ensure that when the base table partition name changes, it will also change the index partition name?
Thanks & Regards,
Aniket

yes its possible:
SQL>ALTER INDEX index_name RENAME PARTITION index_partiton_name TO new_index_partition;
You are getting error because :
a partition name is expected but not present as you typed,
enter an appropriate partition name, will solve the problem.
Edited by: adnanKaysar on Mar 18, 2010 12:32 PM

Regarding "Delete Index" process in the process chain.

Hi Gurus
In the process chain, I have Delete Index -> Load Info pacakge -> Create Index process in the above order.
I am loading few records, so no need to delete indexes everytime. Can i remove the "Delete Index" process from the Chain without deleting the Create Index process. Or do I have to delete both.
Could you please clarify my doubt if possible in detail.
Thanks,
Regards,
aarthi

With the numbers you provided, you probably don't need to have the steps. With Oracle (not sure about all the other DB flavors) there are some other considerations:
Not having the indexes when loading the data can improve the load time since the bitmap indexes are not very efficient with respect to inserts/updates. The more dimensions you have, the more indexes there will be and the more noticable the impact of having the indexes present when loading.
The drop index process only drops the F fact table indexes. If you compress your cubes regularly so that you don't have many uncompressed requests, the index rebuild time will remain small, but if you have many uncompressed requests in your cube, the index rebuild time can begin to exceed whatever time you might save on the load with indexes deleted.
With bitmap indexes present, you can also occasionally receive a ORA-0600 deadlock error during the load process, and that can be prevented by dropping the indexes before loading or chose the load option packet by packet so that two packets are not trying to update the same index block at the same time.
Another concern in shops where reporting on the cube might occur during the load process - if you drop indexes prior to a load, any one trying to run a query on teh cube could have poor query performance since all the indexes will be missing onthe F fact table, this agina becomes more apparent the more data you have in the uncompressed fact table.
So it really comes down to your environment, but certainly drop the indexes any time you have large loads.

Regarding Secondary Index in a Table

hi
if i create a secondary index in a table is it obligatory or optional to have first field as MANDT (Client field) if the table is client dependent & how many secondary indexes(MAXIMUM) can be created for a table.
Regards

Hi,
Check the below Link
How to transport a secondary index on P master data table?
Hope this helps you.
Regards,
Anki Reddy

Regarding deleting index

Hi Friends,
If I delete the whole content of an Infocube and then do the reload,is it require to delete the index seperately.
If I don't delete the index how is it going to impact the load?
Regards,
Debjani...

It doesn't mean that Indexes will delete permanently .. Structure will remain same!
When you delete data from cube it also deletes the generated indexes which are existed .. there is no point of having indexes on deleted records .. it's logical
even it doesn't hold any data it allows you to create index and generate stats(ex. create a dummy cube and try to generate)
For the moment I don't have any document for it.. I will let know
For your 2nd ques.
Only for huge loads droping index will be usefull which will improve the loading performance!
For daily delta load with less volume of data you need not to drop Indexes .. if you do so it will take lot of time to rebuild the indexes(on whole data)

Regarding Condition Index

Hi All,
With regards to condition index I have made the required tick in the condition type now when I am going into the master data with regards to creating condition records selecting the condition index tab by giving the input as the condition type, the system says that there are no records found, eventhough I have created the sales order in the system, the access sequence consists of line item and sales order please advise if any other configuration needs to be done for condition index and how do I check if the configuration is complete.
Kind Regards
Atul

Hi Condition indes only Specifies whether the system updates one or more condition indices when maintaining condition records. It depends whether you had created the combination of condition recored to determin if you can find the existing one, please be sure you had created the condition record via vk11.

Regarding sy-index

Hi all,
I am trying to get loop count by using sy-index.
But I am not able get exact expected out put.
I am gettig all zeros instead of loop number.
I am sending my code here.
DATA: lv_diff(10) TYPE c,
        lv_erdat1 LIKE sy-datum,
        lv_erdat2 LIKE sy-datum,
        i(15) TYPE c VALUE '1'.
SORT t_ordno BY aufnr.
LOOP AT t_ordno INTO st_ordno.
    READ TABLE t_ordno INTO st_ordno INDEX i.
    lv_erdat1 = st_ordno-erdat.
    i = i + 1.
    READ TABLE t_ordno INTO st_ordno INDEX i.
    lv_erdat2 = st_ordno-erdat.
    i = i + 1.
    CALL FUNCTION 'DAYS_BETWEEN_TWO_DATES'
         EXPORTING
              i_datum_bis = lv_erdat2
              i_datum_von = lv_erdat1
         IMPORTING
              e_tage      = lv_diff.
    WRITE:/ lv_diff,
          50 <u><b>sy-index.</b></u>
    CLEAR: lv_erdat1,lv_erdat2,lv_diff.

use this code
DATA: lv_diff(10) TYPE c      ,
      lv_erdat1 LIKE sy-datum ,
      lv_erdat2 LIKE sy-datum ,
      i(15) TYPE c VALUE '1' ,
      l_tabix type syst-tabix .
SORT t_ordno BY aufnr.
LOOP AT t_ordno INTO st_ordno.
l_tabix = sy-tabix .
READ TABLE t_ordno INTO st_ordno INDEX i.
lv_erdat1 = st_ordno-erdat.
i = i + 1.
READ TABLE t_ordno INTO st_ordno INDEX i.
lv_erdat2 = st_ordno-erdat.
i = i + 1.
CALL FUNCTION 'DAYS_BETWEEN_TWO_DATES'
       EXPORTING
            i_datum_bis = lv_erdat2
            i_datum_von = lv_erdat1
       IMPORTING
            e_tage      = lv_diff.
WRITE:/ lv_diff,
       50 l_tabix.
CLEAR: lv_erdat1,lv_erdat2,lv_diff.

Regarding secondary index

how and when we create secondary indexes and what are the advantages and disadvantages of secondary indexes?

Hi
Index: Technical key of a database table.
Primary index: The primary index contains the key fields of the table and a pointer to the non-key fields of the table. The primary index is created automatically when the table is created in the database.
Secondary index: Additional indexes could be created considering the most frequently accessed dimensions of the table.
Structure of an Index
An index can be used to speed up the selection of data records from a table.
An index can be considered to be a copy of a database table reduced to certain fields. The data is stored in sorted form in this copy. This sorting permits fast access to the records of the table (for example using a binary search). Not all of the fields of the table are contained in the index. The index also contains a pointer from the index entry to the corresponding table entry to permit all the field contents to be read.
When creating indexes, please note that:
An index can only be used up to the last specified field in the selection! The fields which are specified in the WHERE clause for a large number of selections should be in the first position.
Only those fields whose values significantly restrict the amount of data are meaningful in an index.
When you change a data record of a table, you must adjust the index sorting. Tables whose contents are frequently changed therefore should not have too many indexes.
Make sure that the indexes on a table are as disjunctive as possible.
(That is they should contain as few fields in common as possible. If two indexes on a table have a large number of common fields, this could make it more difficult for the optimizer to choose the most selective index.)
Accessing tables using Indexes
The database optimizer decides which index on the table should be used by the database to access data records.
You must distinguish between the primary index and secondary indexes of a table. The primary index contains the key fields of the table. The primary index is automatically created in the database when the table is activated. If a large table is frequently accessed such that it is not possible to apply primary index sorting, you should create secondary indexes for the table.
The indexes on a table have a three-character index ID. '0' is reserved for the primary index. Customers can create their own indexes on SAP tables; their IDs must begin with Y or Z.
If the index fields have key function, i.e. they already uniquely identify each record of the table, an index can be called a unique index. This ensures that there are no duplicate index fields in the database.
When you define a secondary index in the ABAP Dictionary, you can specify whether it should be created on the database when it is activated. Some indexes only result in a gain in performance for certain database systems. You can therefore specify a list of database systems when you define an index. The index is then only created on the specified database systems when activated
Regards

Regarding Timeline Index

How do i update the timeline index in fcpx?? I kind of deleted a keyword collection and added a new one in the Event library, but it is not showing in the timeline index...Could someone tell me how to do that???

The Time Line Index doesn't update when you change a keyworded clip (or clips) in the event.
You would need to replace the clips in the Timeline whose keywords were changed in order to see that reflected in the TL Index.
Russ

Regarding lobs...

I am not that familiar with LOBs, and was hoping someone could shed some light for me.
I am running Oracle 11.2.0.2 EE, and have made an interesting discovery of this new database that i am responsible.
First, I found out that I have a table that is about 7.4G, but it has two LOB columns that when I query dba_lobs, I found that they contains 365G of lobs and the table itself has 22G of LOBS - not sure what is the difference.
SQL> 1 select segment_name, round(sum(bytes)/1024/1024/1024,1) as "SIZE" , segment_type
2 from dba_segments where owner = 'ARADMIN'
3 group by segment_name, segment_type
4 having round(sum(bytes)/1024/1024/1024,1) > 1
5* order by 2
SEGMENT_NAME                                SIZE SEGMENT_TYPE
SYS_LOB0000077517C00027$$                    4.2 LOBSEGMENT
SYS_LOB0000210343C00029$$                    4.4 LOBSEGMENT
SYS_LOB0000077480C00002$$                    4.6 LOBSEGMENT
T465                                           5 TABLE
T2052                                        8.3 TABLE
T2115                                       12.4 TABLE
T2444                                       13.4 TABLE
T2179                                       14.8 TABLE
T2192                                       21.8 TABLE
SYS_LOB0000077549C00015$$                    182 LOBSEGMENT   <=== (related to table T2192)
SYS_LOB0000077549C00016$$                  184.4 LOBSEGMENT <=== (related to table T2192)
30 rows selected.Now, let's look at the which table these LOBS belong...
SQL> select table_name, column_name, segment_name
2 from dba_lobs
3 where segment_name in (
4 select segment_name from dba_segments where owner = 'ARADMIN'
5   having round(sum(bytes)/1024/1024/1024,1) > 1
6 group by segment_name
7 )
8 /
TABLE_NAME                       COLUMN_NAME                      SEGMENT_NAME
B1947C536880923                  C536880923                       SYS_LOB0000077310C00002$$
T2051                            C536870998                       SYS_LOB0000077426C00041$$
T2052                            C536870987                       SYS_LOB0000077440C00063$$
T2115                            C536870913                       SYS_LOB0000077463C00009$$
B2125C536880912                  C536880912                       SYS_LOB0000077480C00002$$
B2125C536880913                  C536880913                       SYS_LOB0000077483C00002$$
T2179                            C536870936                       SYS_LOB0000077517C00027$$
T2192                            C456                             SYS_LOB0000077549C00015$$   <====
T2192                            C459                             SYS_LOB0000077549C00016$$   <====
T2444                            C536870936                       SYS_LOB0000210343C00029$$
T1990                            C536870937                       SYS_LOB0000250271C00026$$
11 rows selected.So, from the above, I noticed in the first query that the table T2192 itself contains 21.8G of LOBS, and, that the columns C456 and C459 of same table contain a total of (181.7+183.9) = 365.6G.
First question is how can the table be only 21.8G, and the lob segments of the table columns be 365.6G of Lobs?
It seems some lobs must be external, while others are part of the actual table.
Next, I am wondering if a row is deleted from the table, would the lobs associated with that row that are referenced by columns C456 and C459 also be deleted.
Discussing this with our Sr. Developer, he says the table is purged of rows older than 6 months, but my question is whether the Lobs are actually purged with the rows.
Any ideas?
Edited by: 974632 on Dec 27, 2012 8:05 AM

Hi John,
Reading note 386341.1, this is pretty messed up about lobs.
First, the UNDO data for a LOB segment is kept within the LOB segment space, e.g., when lobs are deleted, etc. Yuck!
So, you are right about the space eventually being returned to the database, but surely we can do better than that!
Then, when we check for the size of the lobs using dbms_lob.getlength, (since we are using AL32UTF8), it returns it in the number of characters instead of bytes.
So, then we have to convert - ref. note 790886.1. An enhancement request via Bug 7156454 has been filed to get this functionality and is under consideration by development.
So, how does one (safely) clean up lobs that have been deleted in the database?
It seems that doing an alter table... 'move lob' might work, and also an alter table ... modify lob (...) (shrink space [cascade]);
But with this being production, I'm very concerned about all the related bugs, even though I am on 11.2.0.2.
WARNING : shrinking / reorganizing BASICFILE lobs can cause performance problems due to "enq: HW contention" waits
Serious LOB corruption can occur after an
ALTER TABLE <table> MODIFY LOB ("<lob_column>") (STORAGE (freelists <n>));
has been issued on a LOB column which resides in a manual space managed tablespace. Subsequent use of the LOB can fail with various internal errors such as:
ORA-600 [ktsbvmap1]
ORA-600 [25012]
For more information, please refer to bug 4450606.
#2. Be aware of the following bug before using the SHRINK option in releases which are <=10.2.0.3:
Bug: 5636728 LOB corruption / ORA-1555 when reading LOBs after a SHRINK operation
Please check:
Note.5636728.8 Ext/Pub Bug 5636728 - LOB corruption / ORA-1555 when reading LOBs after a SHRINK operation
for details on it.
#3. Be aware that, sometimes, it could be needed to perform the shrink operation twice, in order to avoid the:
Bug:5565887 SHRINK SPACE IS REQUIRED TWICE FOR RELEASING SPACE.
is fixed in 10.2.From looking at note: 1451124.1, it seems the best options are:
1) alter table move (locks the table, and requires additional space of at least double the size of the table).
2) do an export / drop the table / and reimport - again downtime required.
Neither option are possible in our environment.

Dealing with orphan lob

Oracle 10.2.0.4 EE on HP-UX 11.23
I seem to have "acquired" an orphaned lob:
SQL> select object_type, object_name
2 from dba_objects
3 where owner='OPS$STEVENSE';
OBJECT_TYPE         OBJECT_NAME
LOB                 SYS_LOB0000120564C00036$$
1 select segment_name, segment_type from dba_segments
2* where owner='OPS$STEVENSE'
SQL> /
SEGMENT_NAME                   SEGMENT_TYPE
BIN$UH6CiZpAVujgRAAaSwaUUg==$0 TABLE
BIN$hDEyxtzAG7vgRAAaSwaUUg==$0 TABLE
SYS_IL0000120564C00036$$       LOBINDEX
SYS_LOB0000120564C00036$$      LOBSEGMENTTwo tables in the recyclebin? Could the lobs be orphaned from a DROP TABLE?
The segments listed in my query on dba_segments don't show up in the recyclebin:
SQL> select object_name, original_name, type from recyclebin;
SQL> /
OBJECT_NAME                    ORIGINAL_N TYPE
BIN$crNFpQ4GNb3gRAAaSwaUUg==$0 DBSRROWN   TABLE
BIN$crNFpQ4FNb3gRAAaSwaUUg==$0 MR_TBL     TABLE
BIN$crNFpQ4ENb3gRAAaSwaUUg==$0 DEFROLES   TABLE
BIN$crNFpQ4DNb3gRAAaSwaUUg==$0 DEFUSERS   TABLE
BIN$crNFpQ4CNb3gRAAaSwaUUg==$0 DBSRRRPT   TABLE
BIN$crNFpQ4BNb3gRAAaSwaUUg==$0 DBSRREXP   TABLE
BIN$crNFpQ4ANb3gRAAaSwaUUg==$0 DBSRRIN    TABLE
7 rows selected.What about dba_lobs?
SQL> select table_name, segment_name
2 from dba_lobs where owner='OPS$STEVENSE';
TABLE_NAME                     SEGMENT_NAME
BIN$hDEyxtzAG7vgRAAaSwaUUg==$0 SYS_LOB0000120564C00036$$Looks like my lob belongs to a table that has been dropped, but is no longer in the recyle bin.
Any suggestions on how to clean this up?

Girish Sharma wrote:
I do'nt know whether it is relevant or not:
"I think you may have done your purge and your recreate in difference schema, as the purge should have made it impossible to do a 'flashback table to before drop'. If that's not the case, then something went wrong with the purge if it hid the table from the flashback, but didn't actually drop it from the database."
LOB indexes are not dropped when drop a table
Reply by Sir Jonathan.
Regards
Girish SharmaThat discussion looked almost identical to my situation. I had dropped a table, but when I tried to flashback to before drop, it told me the table wasn't in the recyclebin. I had not purged the recycle bin, and the DROP had occurred only a few minutes before. All very strange. Looks like I'll have to open an SR. Fortunately, this is just housekeeping and not a pressing matter.

Performance of LOB Segments for Blob Columns

Hi,
I am migrating 11,000 rows of tiff images from Informix to Oracle.In Informix the datatype for the image storage is Byte and Oracle we chose it to Blob.
The Blob column is creating lob segment and lob index.
When I do the migration I observe that the size of the lob segment object is increasing rather than the table object.
So due to creation of this lob segment for the Blob column,will there be any performance issues while retrieval of images from the database and Inserting images into into the database.
Can I get all the issues that can be encountered by storing data in blob column in terms of lob segment.
This is very important information for us as the application has lot of SQL queries for retrieving and injecting images in the database.
It will be really apprecialbe if you can provide Information about this.
Thanks & Regards
Ramanathan KrishnaMurthy

I agree with D.Morgan that object type with 250 attributes is doubtful.
I don't like object tables (tables with "row objects") too.
But, your table is a relational table with object column ("column object").
C.J.Date in An introduction to Database Systems (2004, page 885) says:
"... object/relational systems ... are, or should be, basically just relational systems
that support the relational domain concept (i.e., types) properly - in other words, true relational systems,
meaning in particular systems that allow users to define their own types."
1. How will Oracle store the data in the ADT column?...
For some answers see:
“OR(DBMS) or R(DBMS), That is the Question”
http://www.quest-pipelines.com/pipelines/plsql/tips.htm#OCTOBER
and (of course):
"Oracle® Database Application Developer's Guide - Object-Relational Features" 10g Release 2 (10.2)
http://download-uk.oracle.com/docs/cd/B19306_01/appdev.102/b14260/adobjadv.htm#i1006903
Regards,
Zlatko

Separate LOB tablespace

Hello members,
I am currently doing maintenance work on a 10.2 application. This has quite a few xmltype columns, and I've noticed one thing;
all of these are created with no considerations given to physical properties. Meaning - among other things - that all are enable storage in row.
I am planning to do something about this, but first I was reading through the lob developers guide (Both 11.2 and 10.2 since we are in our final year of 10g)
Doing this, I came across this little sentence:
TABLESPACE and LOB Index
Best performance for LOBs can be achieved by specifying storage for LOBs in a tablespace different from the one used for the table that contains the LOB. If many different LOBs are accessed frequently, then it may also be useful to specify a separate tablespace for each LOB column or attribute in order to reduce device contention.
Which strikes me as kind of odd, playing the performance card here. It makes me wonder if this is the "Separate Index Table Space" revived?
Or is there more to it? - Is there any reason for separate lob tablespace, and if no performance reason, what then?
Any comments?
Regards
Peter
P.S: I may decide to enjoy my week-end, so I may not follow up right away ;)

Hi Peter,
I am reading this link :
http://asktom.oracle.com/pls/asktom/f?p=100:11:3400094338666934::::P11_QUESTION_ID:378418239571
And Sir Thomas's replies :
1.
lobs make sense in their own tablespace since they use a "versioning" scheme that is a little different from table data (they use space very differently)
2.
not just "another tablespace", for a tablespace is for ease of administration, not performance. You could have 100 tablespaces -- all on the same disk (leaving 50 other disks idle) for example.
It is about even IO distribution, not tablespaces.
3.
In general, tablespaces are NOT a performance thing, they are a "make my life as an admin easier" thing. They are a tool you can use to organize data.
A separate tablespace doesn't mean "separate IO system".
by default LOBS are not cached, depending on the size of your lobs - you might look at that detail. By default, when you insert a lob, you wait for the direct IO to the lob segment to complete. By default, when you read a lob, you wait for the direct IO to complete.
4.
A tablespace is a collection of one or more files in general. A tablespace is not a "tuning device" really (just because byte A and byte B are in different tablespaces does NOT mean that bytes A and B are on different devices at all)
So, i think here we get conflict of doc writing with Expert's (not only expert, but Oracle Legend) view.
Regards
Girish Sharma

Exact space occupied by a table with LOB column

Hi Gurus,
I need to check the exact amount of space used (in bytes or MB) by a table which is having a BLOB column.
I tried the following query but it is not giving the proper usage.
select segment_name , sum(bytes)
from dba_extents
where segment_type='TABLE'
and segment_name in ('TEST_CLOB','TEST_BLOB','TEST_CLOB_ADV','TEST_BLOB_ADV')
group by segment_name;
I even tried the following stored procedure
create or replace procedure sp_get_table_size (p_table_name varchar2)
as
    l_segment_name          varchar2(30);
    l_segment_size_blocks   number;
    l_segment_size_bytes    number;
    l_used_blocks           number;
    l_used_bytes            number;
    l_expired_blocks        number;
    l_expired_bytes         number;
    l_unexpired_blocks      number;
    l_unexpired_bytes       number;
begin
    select segment_name
    into l_segment_name
    from dba_lobs
    where table_name = p_table_name;
    dbms_output.put_line('Segment Name=' || l_segment_name);
    dbms_space.space_usage(
        segment_owner           => 'dldbo',
        segment_name            => l_segment_name,
        segment_type            => 'LOB',
        partition_name          => NULL,
        segment_size_blocks     => l_segment_size_blocks,
        segment_size_bytes      => l_segment_size_bytes,
        used_blocks             => l_used_blocks,
        used_bytes              => l_used_bytes,
        expired_blocks          => l_expired_blocks,
        expired_bytes           => l_expired_bytes,
        unexpired_blocks        => l_unexpired_blocks,
        unexpired_bytes         => l_unexpired_bytes
    dbms_output.put_line('segment_size_blocks       => '|| l_segment_size_blocks);
    dbms_output.put_line('segment_size_bytes        => '|| l_segment_size_bytes);
    dbms_output.put_line('used_blocks               => '|| l_used_blocks);
    dbms_output.put_line('used_bytes                => '|| l_used_bytes);
    dbms_output.put_line('expired_blocks            => '|| l_expired_blocks);
    dbms_output.put_line('expired_bytes             => '|| l_expired_bytes);
    dbms_output.put_line('unexpired_blocks          => '|| l_unexpired_blocks);
    dbms_output.put_line('unexpired_bytes           => '|| l_unexpired_bytes);
end sp_get_table_size;
But it is giving the error
Error starting at line 298 in command:
exec sp_get_table_size ('TEST_CLOB_ADV')
Error report:
ORA-03213: Invalid Lob Segment Name for DBMS_SPACE package
ORA-06512: at "SYS.DBMS_SPACE", line 210
ORA-06512: at "SYS.SP_GET_TABLE_SIZE", line 20
ORA-06512: at line 1
03213. 00000 - "Invalid Lob Segment Name for DBMS_SPACE package"
*Cause:    The Lob Segment specified in the DBMS_SPACE operation does not
           exist.
*Action:   Fix the Segment Specification
Although the LOB section is specified in create table syntax.
Please help.
Thanks
Amitava.

Here is a query that I use, to associate space from all segments under s schema (LOBs, indexes, etc.) back to the tables they support:
with schema as (select '&your_schema' as name from dual),
segs_by_table as(
select 'TABLE' seg_supertype, seg.segment_name as related_table, seg.* from dba_segments seg, schema where seg.owner = schema.name and seg.segment_type in ('TABLE','TABLE PARTITION','TABLE SUBPARTITION')
union all
select 'INDEX' seg_supertype, i.table_name as related_table, seg.* from dba_segments seg, dba_indexes i, schema where seg.owner = schema.name and seg.segment_type in ('INDEX','INDEX PARTITION','INDEX SUBPARTITION')
and Seg.OWNER = i.owner and seg.segment_name = i.index_name
union all
select 'LOB' seg_supertype, lob.table_name as related_table, seg.* from dba_segments seg, dba_lobs lob, schema where seg.owner = schema.name and seg.segment_type in ('LOBSEGMENT','LOB PARTITION')
and seg.OWNER = lob.owner and seg.segment_name = lob.segment_name
union all
select 'LOB' seg_supertype, lob.table_name as related_table, seg.* from dba_segments seg, dba_lobs lob, schema where seg.owner = schema.name and seg.segment_type in ('LOBINDEX')
and seg.OWNER = lob.owner and seg.segment_name = lob.index_name
select owner,related_table,
segment_type,   segment_name , partition_name, blocks
from segs_by_table, schema
where owner = schema.name
--and related_table like 'BLOB_TEST%'
order by owner,related_table, segment_type, segment_name;
You can revise as needed to limit to a single table, to summarize, etc.
Mike

Regarding LOB index

Similar Messages

Maybe you are looking for