LOB index segment

Similar Questions

• Lob Index DDL

  Hello

  I have developed 1 application where in i Ran SQL advisor tunning to grant some queries and it created many clues.

  So now I have to rename these indexes (LOB) to something like table_name_column name so I need to get the metadata in order to check the columns these lob indexes are cerated

  But when I ran get ddl statement I do not get the names of columns on which these lob indexes are created.

  Example:

  SQL > select dbms_metadata.get_ddl('INDEX','SYS_IL0000113826C00055$$','XXI') from double;

  DBMS_METADATA. GET_DDL('INDEX','SYS_IL0000113826C00055$$','XXCEMLI')

  --------------------------------------------------------------------------------

  CREATE A UNIQUE INDEX "XXI". "" SYS_IL0000113826C00055$ $' TO 'XX '. "" (tbs1_MV).

  PCTFREE, INITRANS 10 2 MAXTRANS 255

  STORAGE (INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645)

  PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1

  USER_TABLES FLASH_CACHE, CELL_FLASH_CACHE DEFAULT DEFAULT)

  TABLESPACE "XXI_D".

  PARALLEL (INSTANCES OF DEGREE 0 0)

  DBMS_METADATA. GET_DDL('INDEX','SYS_IL0000113826C00012$$','XXCEMLI')

  --------------------------------------------------------------------------------

  CREATE A UNIQUE INDEX "XXI". "" SYS_IL0000113826C00012$ $' ON 'XXCEMLI '. "" (tbs1_MV).

  PCTFREE, INITRANS 10 2 MAXTRANS 255

  STORAGE (INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645)

  PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1

  USER_TABLES FLASH_CACHE, CELL_FLASH_CACHE DEFAULT DEFAULT)

  TABLESPACE "XXI_D".

  PARALLEL (INSTANCES OF DEGREE 0 0)

  These indices are those that Oracle uses to find the content of the LOB column in the LOB segment when they are stored offline.  They are created and managed automatically by Oracle when you create a LOB column.  There is no need to change the names for those since you'll never use them, only Oracle internally.  In fact, I'm not entirely sure if you can change the name without breaking your BUSINESS.

  John

• LOB index are not deleted when delete a table

  Hello
  
  I dropped a table with a blob column by running 'drop table table_name ". When I try to recreate, Oracle complained that this object already exists.
  
  I checked dba_tables, the table disappeared. Then I checked dba_lobs, the lob index is still there with the name of the table and the name of the renamed lob segment in "BIN$ XIlKa53KaoDgRAAUTw8jtg == $0". I have to purge recyclebin. Now, I don't see any line in recyclebin, but business index is still in dba_lobs. As a result, I still can't recreate the table.
  
  How can I remove the index of business so that I can recreate the table? How am I supposed to drop a table with lob columns so that I no longer experience this problem?
  
  Thank you.

  user632535 wrote:
  It's the Oracle 10 g.

  I just found the solution. I have flashback the table before the fall, and then performed "drop table t purge. I am able to recreate the table now.

  I tried to imitate this problem, with some variations, 10.2.0.3 and couldn't get the anomaly appears - what is your exact version?

  I think you did your oil change and recreate your in the scheme of the difference, like the purge should make it impossible to do a "flashback table from before the fall." If this isn't the case, then something went wrong with the purge if he hid the table since the return of flame, but not did not fall out of the database.

  Concerning
  Jonathan Lewis
  http://jonathanlewis.WordPress.com
  http://www.jlcomp.demon.co.UK

  "The premature temptation to theories of shape on the lack of data is the scourge of our profession."
  Sherlock Holmes (Sir Arthur Conan Doyle) in "the Valley of fear."

• Index segment vs data segment

  When I create a storage space for data or index, do I need to do something special for index?
  
  What is a segment of the Index?
  
  Thank you.

  You don't need to do something special for index segments - tablespaces can contain.

  Have a read wrong on separating the index/tables (i.e. There is no requirement of practice):

  http://asktom.Oracle.com/pls/Apex/f?p=100:11:0:P11_QUESTION_ID:901906930328

  The following documentation explains the types of segments:

  http://download.Oracle.com/docs/CD/B19306_01/server.102/b14220/logical.htm#CNCPT301

  Hope that helps.
  Paul

• Limit of Maxextent reaching index Segment

  Oracle Version 9.2.0.8.0 - 64 bit Production
  
  IBM AIX operating system version
  
  
  Hello
  
  
  I am facing a problem with Index segment limit maxextents.
  
  The EXTENSIONS MAX_EXTENTS columns and in the DBA_SEGMENTS for this Segment of the Index is 1.
  
  I tried to increase this size maxextents for this segment, but I get this error message.
  
  ALTER index... storage (maxextents 5)
  *
  ERROR on line 1:
  ORA-25176: specification of storage not allowed for the primary key
  
  
  I found that the Tablespace containing this segment is managed dictionary.
  
  Is this problem because of the storage space managed dictionary?
  
  How to solve this problem?

  What is an index organized table?
  If so you can't change the definition of the storage of the index - you need to do this on the table associated with the altar storage (...) syntax table.

• What LOB index is really

  Hi friends!
  
  I have a very simple question. I was a little confused, read the docs on oracle 11g. I don't remember the exact number of topic, but it was working with LOB data types. So in the first statement, they say that when the null value is assigned to a LOB field this field is no clue, is not possible to extract it and use in some plsql block to associate the field with lob data. In the same paragraph, they say that if using empty_blob rather for purposes of initialization, we can get later inside the plsql block and bind it to some data.
  
  On this subject a bit down the text it is said that there is always a hint of any value has been assigned to the field: null, empty_blob or other. How can it be? If a Web address must be thinking as a pointer, then what region it references after you have created with the emp_LOB method?
  
  Thank you.

  Timin wrote:
  Please look at the first paragraph and find the note that includes the following:

  A LOB Locator still exists for any instance LOB regardless of the properties of LOB storage or LOB - NULL, empty, or another value.

  I think the confusion is where he uses the word "instance". If you have stored a NULL value in the column, then it isn't actually an instance of a LOB it. Instance exist that once there is an empty lob or a lob with data in it, in which case it will be the lob Locator.

• ORA-01691: impossible to extend lob segment

  Hi, Iam facing mentoned question below
  2010-08-02 17:56:56: DB error!
  
  java.sql.SQLException: ORA-01691: impossible to extend lob XXX_XXX segment. SYS_LOB0000175123C00008$ $ by 1024 in the XXX_XXX_TBL tablespace
  
  at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:125)
  at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:305)
  at oracle
  This is when inserting records into a table, Oracle needed to extend a segment, but as there is not sufficient space to allow him to do so, i.e. the storage space is full Sunrise error.
  
  I would like to know is possible to fix it without adding a new data file...
  
  Oracle9i Enterprise Edition Release 9.2.0.8.0 - 64 bit Production
  PL/SQL Release 9.2.0.8.0 - Production
  CORE Production 9.2.0.8.0
  AMT for Solaris: 9.2.0.8.0 - Production Version
  NLSRTL Version 9.2.0.8.0 - Production

  Try,

  ALTER database datafile '' autoextend on maxsize unlimited;

  and you can also do the same thing with the temp tablespace.

  concerning

  Published by: Fahd Mirza on August 2, 2010 15:38

• Moving the huge LOBs

  Hello

  We have a table with LOB which must be reorg with in the tablespace. These tables have the LOB index.

  These segments are up to 500 GB in size.

  We tried to eat with 15 parallel with nologging option but it takes ages (more than one day) to finish which is not acceptable by our customers.

  Let me know the fast and effective way to do this?

  Thank you

  Yes, you can migrate to a new tablespace using the DBMS_REDEFINITION.

  When you create the temp table, you can specify the new name of the tablespace for the LOB.

  Redef finish makes the exchange table original black and white data dictionary and the interim. The interim table will be your actual table after finishing redef procedure ends successfully

• Strange behavior of index sous-partitionnée

  Hi all!

  I am facing a strange problem on my database.

  I have a huge table that is partitioned by year and sous-partitionnée per month and per day. For this table, we have 13 indices that is partitioned and sous-partitionnée.

  For a given day, the July 13 subpartition index segment is missing, but when I ask DBA_IND_SUBPARTITIONS date index is here:

  1. Select index_name, subpartition_name, status

  dba_ind_subpartitions 2 c

  3 where subpartition_name = 'P_ANO_04_JUL_13. '

  4 * and index_name like '% FATINDFIXOL % '.

  SQL > /.

  
  

  INDEX_NAME SUBPARTITION_NAME STATUS

  -------------------------------------------------- ------------------------------ --------

  IDX_FATINDFIXOL_ID_TERMINAL_C USABLE P_ANO_04_JUL_13

  IDX_FATINDFIXOL_PARTE_TARIFAD USABLE P_ANO_04_JUL_13

  IDX_FATINDFIXOL_CSP USABLE P_ANO_04_JUL_13

  IDX_FATINDFIXOL_FDS USABLE P_ANO_04_JUL_13

  IDX_FATINDFIXOL_CATEGORIA USABLE P_ANO_04_JUL_13

  IDX_FATINDFIXOL_FLAG_PORTAB USABLE P_ANO_04_JUL_13

  IDX_FATINDFIXOLIDTERMORIGPORT USABLE P_ANO_04_JUL_13

  IDX_FATINDFIXOLIDTERMDESTPORT USABLE P_ANO_04_JUL_13

  IDX_FATINDFIXOL_ORIGEM USABLE P_ANO_04_JUL_13

  IDX_FATINDFIXOL_DESTINO USABLE P_ANO_04_JUL_13

  IDX_FATINDFIXOL_ID_CARACT_FIX USABLE P_ANO_04_JUL_13

  IDX_FATINDFIXOL_ROTA_ENTRADA USABLE P_ANO_04_JUL_13

  IDX_FATINDFIXOL_ROTA_SAIDA USABLE P_ANO_04_JUL_13

  SQL > select nom_segment, nom_partition, bytes/1024/1024 MB

  2 from dba_segments

  3 where nom_partition = 'P_ANO_04_JUL_13. '

  4 and nom_segment like '% FATINDFIXOL % '.

  5.

  no selected line

  Showing another day, July 14:

  SQL > select index_name, subpartition_name, status

  user_ind_subpartitions 2 c

  3. inner join WHERE USER_SEGMENTS one ON (A.PARTITION_NAME = C.SUBPARTITION_NAME AND nom_segment = C.INDEX_NAME)

  4 where subpartition_name = 'P_ANO_04_JUL_14. '

  5 and index_name like '% FATINDFIXOL % '.

  6.

  INDEX_NAME SUBPARTITION_NAME STATUS

  -------------------------------------------------- ------------------------------ --------

  IDX_FATINDFIXOLIDTERMDESTPORT UNUSABLE P_ANO_04_JUL_14

  IDX_FATINDFIXOLIDTERMORIGPORT UNUSABLE P_ANO_04_JUL_14

  IDX_FATINDFIXOL_CATEGORIA UNUSABLE P_ANO_04_JUL_14

  IDX_FATINDFIXOL_CSP USABLE P_ANO_04_JUL_14

  IDX_FATINDFIXOL_DESTINO UNUSABLE P_ANO_04_JUL_14

  IDX_FATINDFIXOL_FDS UNUSABLE P_ANO_04_JUL_14

  IDX_FATINDFIXOL_FLAG_PORTAB UNUSABLE P_ANO_04_JUL_14

  IDX_FATINDFIXOL_ID_CARACT_FIX UNUSABLE P_ANO_04_JUL_14

  IDX_FATINDFIXOL_ID_TERMINAL_C UNUSABLE P_ANO_04_JUL_14

  IDX_FATINDFIXOL_ORIGEM UNUSABLE P_ANO_04_JUL_14

  IDX_FATINDFIXOL_PARTE_TARIFAD UNUSABLE P_ANO_04_JUL_14

  IDX_FATINDFIXOL_ROTA_ENTRADA UNUSABLE P_ANO_04_JUL_14

  IDX_FATINDFIXOL_ROTA_SAIDA UNUSABLE P_ANO_04_JUL_14

  1 Select nom_segment, nom_partition, bytes/1024/1024 MB

  2 from dba_segments

  3 where nom_partition = 'P_ANO_04_JUL_14. '

  4 * and nom_segment like '% FATINDFIXOL % '.

  SQL > /.

  NOM_SEGMENT NOM_PARTITION MB

  ------------------------------ ------------------------------ ----------

  IDX_FATINDFIXOL_ROTA_ENTRADA P_ANO_04_JUL_14, 0625

  IDX_FATINDFIXOL_ROTA_SAIDA P_ANO_04_JUL_14, 0625

  IDX_FATINDFIXOL_CATEGORIA P_ANO_04_JUL_14, 0625

  IDX_FATINDFIXOL_FLAG_PORTAB P_ANO_04_JUL_14, 0625

  IDX_FATINDFIXOL_ORIGEM P_ANO_04_JUL_14, 0625

  IDX_FATINDFIXOL_DESTINO P_ANO_04_JUL_14, 0625

  IDX_FATINDFIXOL_ID_CARACT_FIX P_ANO_04_JUL_14, 0625

  IDX_FATINDFIXOL_ID_TERMINAL_C P_ANO_04_JUL_14, 0625

  IDX_FATINDFIXOL_PARTE_TARIFAD P_ANO_04_JUL_14, 0625

  IDX_FATINDFIXOL_CSP P_ANO_04_JUL_14, 0625

  IDX_FATINDFIXOL_FDS P_ANO_04_JUL_14, 0625

  IDX_FATINDFIXOLIDTERMORIGPORT P_ANO_04_JUL_14, 0625

  IDX_FATINDFIXOLIDTERMDESTPORT P_ANO_04_JUL_14, 0625

  Also, if I run a query using any index and generate a plan to explain it, it shows that the index is used:

  13 July:

  SQL > select the CATEGORY of USRCARGADB.fato_indice_fixa_online (p_ano_04_jul_13) subpartition where category = 'ASDF ';

  no selected line

  Elapsed time: 00:00:00.01

  Execution plan

  ----------------------------------------------------------

  Hash value of plan: 690609349

  -------------------------------------------------------------------------------------------------------------------------

  | ID | Operation | Name                      | Lines | Bytes | Cost (% CPU). Time | Pstart. Pstop |

  -------------------------------------------------------------------------------------------------------------------------

  |   0 | SELECT STATEMENT |                           |     1.     3.     1 (0) | 00:00:01 |       |       |

  |   1.  COMBINATION ITERATOR PARTITION |                           |     1.     3.     1 (0) | 00:00:01 |   KEY |   KEY |

  |*  2 |   INDEX RANGE SCAN | IDX_FATINDFIXOL_CATEGORIA |     1.     3.     1 (0) | 00:00:01 |  1315 |  1315 |

  -------------------------------------------------------------------------------------------------------------------------

  Information of predicates (identified by the operation identity card):

  ---------------------------------------------------

  2 - access ("CATEGORIA" = 'ASDF')

  11 July:

  SQL > select the CATEGORY of USRCARGADB.fato_indice_fixa_online (p_ano_04_jul_11) subpartition where category = 'ASDF ';

  no selected line

  Elapsed time: 00:00:00.03

  Execution plan

  ----------------------------------------------------------

  Hash value of plan: 690609349

  -------------------------------------------------------------------------------------------------------------------------

  | ID | Operation | Name                      | Lines | Bytes | Cost (% CPU). Time | Pstart. Pstop |

  -------------------------------------------------------------------------------------------------------------------------

  |   0 | SELECT STATEMENT |                           |     1.     3.     3 (0) | 00:00:01 |       |       |

  |   1.  COMBINATION ITERATOR PARTITION |                           |     1.     3.     3 (0) | 00:00:01 |   KEY |   KEY |

  |*  2 |   INDEX RANGE SCAN | IDX_FATINDFIXOL_CATEGORIA |     1.     3.     3 (0) | 00:00:01 |  1313 |  1313 |

  -------------------------------------------------------------------------------------------------------------------------

  Information of predicates (identified by the operation identity card):

  ---------------------------------------------------

  2 - access ("CATEGORIA" = 'ASDF')

  Anyone know what might happened to this segment of the specific index for July 13? If I try to rebuild this subpartition or make it UNUSABLE, it works, but still does not show a thing on the DBA_SEGMENTS or DBA_EXTENTS. The version is 11.2.0.3

  Thank you

  Post edited by: rafa.aborges

  You have not yet provided your Oracle version 4-digit or the TABLE and the INDEX of DDL.

  Your 'problem' might be that creating DEFERRED SEGMENT where Oracle is not allocate space until the first data are added to this segment.

  See 'Understanding delayed Segment creation' in the DBA Guide

  http://docs.Oracle.com/CD/E11882_01/server.112/e25494/tables002.htm#CHDGJAGB

  >

  Understand the creation of Segment delayed

  Starting with the Oracle 11 g Release 2 database, when you create tables of heap-organized in a locally managed tablespace data base differs from creating segment table until the first row is inserted.

  In addition, the creation of segment is deferred for all columns of the table LOB, all indexes created implicitly as part of the creation of the table and all indexes created later explicitly on the table.

  Note:

  In the 11.2.0.1 release, delayed segment creation is not supported for partitioned tables. This restriction is removed in the 11.2.0.2 version and later.

  >

  It is MANDATORY that posters provide their versions of Oracle 4-digit. There are too many features that depend on the version used.

• regarding type LOB data...

  I'm not so familiar with LOB and was hoping someone could shed some light for me.
  
  I am under Oracle 11.2.0.2 EE and made an interesting discovery of this new database I load.
  
  First of all, I discovered that I have a table which is about 7.4 G, but there two columns LOB that when I have a dba_lobs query, I found that they contains 365 G of lobs and the table itself has 22 G of LOB - don't know what the difference is.
  

  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 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, in the light of the foregoing, I noticed in the first query that contains the table T2192 21.8 G of LOBS and that C456 and C459 of same table columns (181,7 + 183.9) total = 365.6 G.
  
  First question is how can the table be only 21.8 G, and business segments the columns of the table of 365,6 G of the Lobs?
  It seems that some type LOB data should be external, while others are part of the table.
  
  Then, I wonder if a line is removed from the table, would be the LOB associated with this line that is referenced by columns C456 and C459 also deleted.
  Discuss with our senior developer, he said, the table is purged of lines longer than 6 months, but my question is if the LOB is actually purged with the lines.
  
  Any ideas?
  
  Published by: 974632 on December 27, 2012 08:05

  The space occupied by business segments is not reported as part of space for table segment, welll, don't not all still. What is reported as part of the size of the table is the size of the lob index (a pointer to the segment of the 'real' job, 16 bytes if I remember correctly) and the LOB that are stored online in the table (those under 4 k). To get the "full" size of the table, you must add the space occupied by the ant lob columns.

  If you delete a line, then the space occupied in the business segments will be defined as free space inside the existing segment. He will thereafter (there are a number of round redo and undo that are managed differently from the lobs), be used by the data for the other lines, but it might take some time.

  There are a number of documents on My Oracle support in this regard, many are related to:

  Troubleshooting Guide (TSG) - large objects (LOBs) [ID 846562.1]

  John

• Move the LOB to a new tablespace

  I want the users tablespace LOB to some other tablespace. But when I tried I got the error set-aside. I moved all the objects corresponding to the particular schema, but not the LOB. Can you please explain why Cant I move the LOB. And if you can explain that I want to know the importance of the lob indexex. Thank you in advance.
  
  SQL > select TABLE_NAME, INDEX_NAME, TABLESPACE_NAME from dba_lobs where owner = 'PC_DOM ';
  
  TABLESPACE_NAME INDEX_NAME TABLE_NAME
  ------------------------------ ------------------------------ ------------------------------
  PCSF_DOMAIN SYS_IL0000077924C00002$ $ USERS
  PCSF_CPU_USAGE_SUMMARY SYS_IL0000077933C00006$ $ USERS
  PCSF_REPO_USAGE_SUMMARY SYS_IL0000077936C00005$ $ USERS
  PCSF_USER SYS_IL0000077940C00002$ $ USERS
  PCSF_GROUP SYS_IL0000077944C00002$ $ USERS
  PCSF_ROLE SYS_IL0000077948C00002$ $ USERS
  PCSF_DOMAIN_USER_PRIVILEGE SYS_IL0000077952C00002$ $ USERS
  PCSF_DOMAIN_GROUP_PRIVILEGE SYS_IL0000077956C00002$ $ USERS
  
  8 selected lines.
  
  SQL > alter table PCSF_DOMAIN move lob (SYS_IL0000077924C00002$) store as (tablespace TS_PC_DOM);
  ALTER table PCSF_DOMAIN move lob (SYS_IL0000077924C00002$) store as (tablespace TS_PC_DOM)
  *
  ERROR on line 1:
  ORA-00942: table or view does not exist

  Do not use segment name of LOB but about the name of the column in the table and qualify the name of the table with the owner of the table if you are not logged in as owner of the table:

  Try:

  alter table PC_DOM.PCSF_DOMAIN move lob () store as ( tablespace TS_PC_DOM );
  

  Each LOB column is materialized with 2 segments:
  -a LOB segment containing LOB data
  -a LOB index that is a structure designed to facilitate access to the LOB data in the LOB segment.

  Edited by: P. Forstmann on 22 July. 2011 20:48

  Edited by: P. Forstmann on 22 July. 2011 20:52

• Size LOB in Oracle

  Hello
  
  How to find the size of a table containing a LOB in oracle 9i.
  
  Thank you
  Mariangela

  For each TRADE is created is a LOB segment created and also a type LOB index created: you also have to add this to your query.
  Check with

  select index_name from user_indexes where index_type='LOB';
  

• index rebuild

  During the rebuilding of the index on the production of databases what precautions because a DBA will take? If dba disable the application or not?
  When online index rebuilding, what performance question will come on the production database?
  
  
  Thanks in advance

  Reconstruction on-line during the index of what will be the impact on the database?

  1 space of index segments can be roughly doubled as Oracle retains the original index segment during the reconstruction. It creates a new index segment, he switches rapidly, then deletes the old.
  2 CPU will be consumed
  3 oracle perhaps fully analyze the old index, other index or table.

  If a user makes a request at the time of the index to rebuild which will have an impact on this user?

  a shared lock on the table will be held
  brief exclusive lock tables and indexes metadata will be held during the switch.

• Pass correctly index partition to a different tablespace

  Oracle Version: 10.2.0.3.0
  
  Hello
  
  I have a clue of sous-partitionnee - & gt; partitioned by range and sous-partitionnée of the list. I have to move the index to a different tablespace. I moved all the subparts successfully, but views of the index always show me references to former storage space.
  
  I moved all of the following subparts: ALTER INDEX MYINDEX REBUILD SUBPARTITION MYSUBPARTITION TABLESPACE NEWTABLESPACE;
  Now when I look at 'dba_segments' view corresponding index segments, they are correctly moved to the new tablespace.
  
  But,
  
  in the column 'def_tablespace_name' in view 'dba_part_indexes' value is always the old name of the tablespace.
  in the column 'nom_tablespace' in view 'dba_ind_partitions' value is always the old name of the tablespace.
  
  in the column 'nom_tablespace' in view 'dba_ind_subpartitions' value is correct, making reference to the new tablespace.
  
  What should I do to have these set correctly values (see dba_part_indexes and dba_ind_partitions)?
  
  I tried
  ALTER index rebuild partition mypartition tablespace newtablespace myindex;
  but I got the error:
  
  Error: ORA-14287
  Text: cannot REBUILD a partition of a Composite range partitioned index-
  Cause: The user attempted to rebuild a partition of a partitioned set of Composite
  index which is illegal
  Action: REBUILD the index partition, a subpartition at a time
  
  Thank you to
  
  
  
  Type of account
  
  St & eacute; phane
  
  Published by: user9928511 on March 13, 2009 11:29

  user9928511 wrote:
  Oracle Version: 10.2.0.3.0

  Hello

  I have an index-> partitioned by range and sous-partitionnée of the list subpartitioned. I have to move the index to a different tablespace. I moved all the subparts successfully, but views of the index always show me references to former storage space.

  I moved all of the following subparts: ALTER INDEX MYINDEX REBUILD SUBPARTITION MYSUBPARTITION TABLESPACE NEWTABLESPACE;
  Now when I look at 'dba_segments' view corresponding index segments, they are correctly moved to the new tablespace.

  But,

  in the column 'def_tablespace_name' in view 'dba_part_indexes' value is always the old name of the tablespace.
  in the column 'nom_tablespace' in view 'dba_ind_partitions' value is always the old name of the tablespace.

  Sub-parts are "segments" in your partitioned table. The scores are just a logical grouping of physical subpartitions. then of course, you can not rebuild and it will show the old man a tablespace name.

  def_tablespace_name can be changed with alter index:
  ALTER INDEX index-name DEFAULT ATTRIBUTES ALTER TABLESPACE nom_tablespace;

• Index organized Tables

  What is logical rowid in IOT? are they kept physically somwhere like physical rowId
  
  What are secondary indexes?
  
  what he meant by leaves block splits? When and how it happens?
  
  and the primary key for a table in index constraint cannot be abandoned, delayed or off, is this true, if yes then Y
  
  How overflow works? how the two clauses are implemented PCTTHRESHOLD and INCLUDING.how they work?
  
  Published by: Juhi on October 22, 2008 13:09

  I'm sort of tempted to simply point you in the direction of the official documentation (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 ROWID not is not physically stored. I don't know why you would think they were. Certainly the ROWID data type can store a rowid if you choose to do, but if you do something like "select rowid from scott.emp", for example, you will see the ROWID that are generated on the fly. ROWID is a pseudo-column, not physically stored anywhere, but calculated each time as needed.

  The difference between a physical rowid and logic used with IOT boils down to a bit of relational database theory. It is a rule in melting of relational databases that a line, once inserted into a table, must never move. In other words, the identifier that is assigned at the time of his first insertion, must be the rowid he "keeps" for ever and ever. If you ever want to change the assigned lines in an ordinary table ROWID, you must export them, truncate the table, and then reinsert them: Insert charges, fees rowid. (Oracle bend this rule for various purposes of maintenance and management, according to which 'allow the movement of line"allows lines without a table, but the general case is still valid for most).

  This rule is obviously hopeless for the index structures. It was true, an index entry for "Bob" which is updated to "Robert" would find next to the entries for 'Adam' and 'Charlie', even though she now has a value of 'R '. Effectively, 'line' a 'b' in an index must be allowed to "move" a sort of 'r' of the block if it's the kind 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 do not change the principle: 'lines' in an index must be allowed to move if their value is changed; rows of a table do not move, no matter what happens to their values)

  An IOT is, at the end of the day, simply an index with columns much more in it that a 'normal' index would - he, too, has thus allow its entires (his 'rows', if you like) to move. Therefore, an IOT cannot use a standard ROWID, which is assigned only once and forever. Instead, one must use something that takes into account that its lines may wander. It's the logical rowid. It is not more 'physical' as a physical rowid - or are physically stored anywhere. But a 'physical' rowid is invariable; a logic is not. Logic, it is actually built in part of the primary key of the ITO - and this is the main reason why you can never get rid of the primary key on the IOT constraint. Be allowed to do would be to you to destroy an organizing principle for its content which has an IOT.

  (See the section called "The virtual ROWID" and continued on this page: http://download.oracle.com/docs/cd/B28359_01/server.111/b28318/datatype.htm#CNCPT1845)

  IOT so their data stored inside in the primary key order. But they only contain the primary key, but all the other columns in the definition of 'table' too. Therefore, just as with an ordinary table, you might sometimes find data on columns that are NOT part of the first key - and in this case, you might well these columns non-primary keys are indexed. Therefore, you create ordinary index on those columns - at this point, you create an index in an index, really, but it's a secondary question, too! These additional indices are called 'secondary index', simply because they are "subsidiary clues" in the main proceedings, which is the 'picture' himself laid out in the primary key order.

  Finally, a split block of sheets is simply what happens when you have to make room for the new data in an index block which is already filled to overflowing with the existing data. Imagine an index block may not contain four entries, for example. Fill you with entries for Adam, Bob, Charlie, David. Now, you insert a new record of 'Brian '. If it's a table, you can take Brian to a new block you like: data from a table have no positional sense. But the entries of an index MUST have positional significance: you can't just throw MC Bean and Brian in the middle of a lot of Roberts, bristling. Brian DOIT pass between the existing entries for Bob and Charlie. Still you can not just put him in the middle of these two, because then you'd have five entries in a block, not four, which we imagined for the moment to be maximally allowed. So what to do? What you do is: get an empty block. Move Charlie and David entries in the new block. Now you have two blocks: Adam-Bob and Charlie David. Each has only two entries, so each has two 'spaces' to accept new entries. Now you have room to add in the entry for Brian... and if you end up with Adam-Bob-Brian and Charlie David.

  The process of moving the index entries in a single block in a new one so that there is room to allow new entries to be inserted in the middle of existing ones is called a split of block. They occur for other reasons too, so it's just a brilliant of them treatment, but they give you the basic idea. It's because of splits of block that indexes (and thus IOT) see their 'lines' move: Charlie and David started in a single block and ended up in a completely different block due to a new (and completely foreign to them) Insert.

  Very well, infinity is simply a means of segregation of data in a separate table segment that would not reasonably be stored in the main segment of the ITO himself. Suppose that you are creating an IOT containing four columns: one, a digital 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 of data type - so it could be stored whole, multi-gigabyte-size monsters DVD movies. Do you really want your index segment (because that's what an IOT really is) to ball to the huge dimensions, every time that you add a new line? Probably not. You probably want 1 to 3 columns, stored in the IOT, but column 4 can be struck off the coast to a segment on its own (the overflow segment, actually) and a link (in fact, a physical rowid pointer) can bind to the other. Left to himself, an IOT will cut each column after the a primary key when a record that threatens to consume more than 50% of a block is inserted. However, to keep the main IOT small and compact and yet still contain data of non-primary key, you can change these default settings. INCLUDE, for example, to specify what last non-primary key column should be the point where a record is split between "keep in IOT" and "out to overflow segment." You could say "INCLUDE COL3" in the previous example, so that COL1, COL2 and COL3 remain in the IOT and only COL4 overflows. And PCTTHRESHOLD can be set at, say, 5 or 10 so that you try to assure an IOT block always contains 10 to 20 saves - instead of the 2 you would end up with default if 50% of kicks.