For asm index rebuild

Similar Questions

• Index rebuild VS analysis static calculation index VS DBMS_STATS. GATHER_INDEX_S

  Hello
  
  I have little doubt below the topics listed. Please explain each topics and where we need to use for the same thing. Can I use any of that? What are the subjects of these advantages and disadvantages?
  
  (1) index rebuild and index rebuild online
  (2) analyze index-static calculation and validate the strcture
  (3) DBMS_STATS. GATHER_INDEX_STATS

  In order to make good use of the cost based optimizer, you create statistics for data in the database.

• Index rebuild required after truncate the table and load data

  Hello
  
  
  I have a situation that we truncate tables bit and then we loaded data [only content] on these tables. What you need to rebuild the index online is necessary or not?
  
  
  And another question is if we drop a few clues is the total amount of space is released or not. And re-create indexes will use the same amount of space. As I don't have disk space more? In this situation, rebuild the index online will be a better idea...
  
  Can you please on this...
  
  
  truncate the table some the few loading tables + reconstruction markings online is the best (or) droping little tables, a few tables loading + re-create the index is better
  
  Can you suggest the best way... We have a time that it currently we don't have enough space on the disk... [Option should not effect the space]

  user13095767 wrote:
  Ok. I have it...

  u want to say if we disbale the index while loading... Next, we need to spend the time to build.

  If the indexes are enabled, then rebuild again is not necessary after loading tables...

  Please answer if my understanding is correct...

  above is correct

  >

  If so, how abt the differences in the space occupied by the spaces of storage during the index rebuild and re-create... T he acquires more space if recreate us [deletion and creation] or rebuild online is preferable to an index...?

  space used is the same for all options.

• At the same time index rebuild...

  OK, so I have a question that has puzzled me a bit. I think I understand the theory, but I am not convinced, so looking for 3xp3rt thoughts.
  
  I have the following table with the indexes following:
  
  Departments of instance name table Name Index
  AWESOME_DETAIL 20 1 AWESOME_DETAIL_B8
  
  The table itself has a DEGREE of 2 BODIES 1 value.
  
  What is happening is when the following is executed:
  
  ALTER INDEX REBUILD AWESOME_DETAIL_B8.
  
  the table is read in series, despite the index with a DOP of 20. However, when we do the following:
  
  ALTER INDEX REBUILD PARALLEL OF 20 AWESOME_DETAIL_B8
  
  The table is read with the parallelism and the treatment is faster (no surprise on the second part).
  
  When the index is rebuilt with the first statement, the degree of parallel remained unchanged at 20. If we run the second statement, and the index have had a degree of parallelism of the 2, then I expect the degree of parallelism of the index itself will be replaced by 20 (because I've seen this before).
  
  Is this expected behavior? Is the first statement saying Oracle "Hey, this rebuild operation does not have parallel" and the second statement saying: 'Hey, I'm specifying options of storage here, my friend, do in parallel of 20'.
  
  Essentially, the first statement is a pure DDL operation and the second statement is a DDL operation with storage options, where the change? And DDL operations ignore the declaration of principles on the subject, unlike, for example, a SELECT statement.
  
  I tried with a DISPLACEMENT of ALTER TABLE and saw the same behavior: without specifying PARALLEL in my statement, it read the table in series. When I specified PARALLEL, it read the table in parallel.
  
  Mark

  When you specify PARALLEL creating / REBUILD / MOVE, the degree is used for the C/R/M. it is always "in place" for all the readings (and will be used in DML If ALTER SESSION ACTIVATE PARALLEL_DML has been paid).
  However, the degree of PARALLEL set of the GET on the table / index is not automatically reused for the next RECONSTRUCTION/MOVE (although the degree that has been set remains!)

  Is the first statement saying Oracle "Hey, this rebuild operation does not have parallel" and the second statement saying: 'Hey, I'm specifying options of storage here, my friend, do in parallel of 20'.

  Yes, precisely.

  See http://download.oracle.com/docs/cd/E11882_01/server.112/e17118/clauses006.htm#g1058315

  NOPARALLEL
  Specify NOPARALLEL for serial execution. It is the default value.

  Hemant K Collette

• Reclaim the storage space for the Index tablespace. The fastest approach

  Hello world
  My version of the database is 10.2.0.4
  I have a partitioned table that has divided the indexes that are found on a tablespace called INDEX01.
  the space allocated to the tablespace INDEX01 is about 10 terabytes, however the space used is about 1.5 tera-bytes.
  I need to recover to the level of the storage space. I decided to recreate the tablespace INDEX01.
  I did not create index scripts so I came with two approaches
  1. to move the index partitions in a different tablespace, drop the tablespace INDEX01, recreate the tablespace INDEX01 and then replace the index partitions.
  2. intentionally mark the unusable index partitions, drop the tablespace INDEX01, recreate the tablespace INDEX01 and then rebuild the index partitions.
  
  step 2 seems faster but I need to know if it would work and impact? (the tablespace would pass with the marked index unsable partitions) and I hope that the original table is not affected?
  
  concerning
  Samuel

  Samuel K wrote:
  Hello world
  My version of the database is 10.2.0.4
  I have a partitioned table that has divided the indexes that are found on a tablespace called INDEX01.
  the space allocated to the tablespace INDEX01 is about 10 terabytes, however the space used is about 1.5 tera-bytes.
  I need to recover to the level of the storage space. I decided to recreate the tablespace INDEX01.
  I did not create index scripts so I came with two approaches
  1. to move the index partitions in a different tablespace, drop the tablespace INDEX01, recreate the tablespace INDEX01 and then replace the index partitions.
  2. intentionally mark the unusable index partitions, drop the tablespace INDEX01, recreate the tablespace INDEX01 and then rebuild the index partitions.

  Since you're talking about the abolition of the index, I guess that you have application downtime. Since this is the case, you may want to consider the fact that an index rebuild can analyze the existing index in order to collect relevant data - provides the index is not unusable, and you do not have a reconstruction in line.

  The fastest option - if INDEX01 is a locally managed tablespace - would probably be:
  

  
  Find partitions of index holding at the beginning of the file and rebuild (nologging, parallel, perhaps for speed) in a different tablespace.
  Find the clues that are 'next' in the repository and rebuild in the same tablespace. If the tablespace is locally managed, then the index will fill the empty space at the beginning of the files.
  Work on the files gradually moving toward the front of the space of tables, indexes, and leaving the 'next' bit of the empty file.
  Finish by copying back the small number of partitions of index you rebuilt in the tablespace to spare (and drop this tablespace).
  Shrink the large tablespace.
  

  Concerning
  Jonathan Lewis

  p.s. I wrote a small script some time ago to report the measure ordering in a tablespace - it can help you to choose the order of rebuild.
  http://jonathanlewis.WordPress.com/2010/02/06/shrink-tablespace/

• ALTER Index Rebuild online

  My database is out 10 gr 2. Sometimes, I pass command ALTER INDEX < index name > REBUILD online on the indexes that are 500 MB in size. It takes about ten minutes to run the command. The database alert log shows no activity for the first six minutes, and DML is allowed on the associated table. At about minute seven journal alerts shows the first of a series of five online redo logs switches. They are each 100 MB.
  
  During the time that online redo logs, DML execution sessions cannot fill. When the new version of the index was created again online records switching station, the original copy of the index disappears, the ALTER INDEX command ends, and blocking for DML ceases.
  
  I read that the DML statements are not affected by executing ALTER INDEX REBUILD online, but experience shows that the blocking of the above sessions. Can someone explain to me what is happening in the different stages of the index rebuild? Is there something I can do to eliminate the blocking of the DML statements during the period when redo online record switch?
  
  Thank you
  Bill

  Bill,

  A useful reference for you:
  http://jonathanlewis.WordPress.com/2009/06/05/online-rebuild/

  Another very useful reference - of many articles:
  http://richardfoote.WordPress.com/category/index-rebuild/

  For what reason you rebuild the index?

  Charles Hooper
  Co-author of "Expert Oracle practices: Oracle Database Administration of the Oak Table.
  http://hoopercharles.WordPress.com/
  IT Manager/Oracle DBA
  K & M-making Machine, Inc.

• An index rebuild

  Hello
  I must set my DB and move some tables from one tablaspace to another.
  For example, a PRODUCT stored on tablespace TBL_1 table I wrote a script like this:
  
  ALTER table PRODUCT move tablespace TBL_2
  storage
  *(*
  initial 1 M
  According to 1 M
  PCTINCREASE 0
  *);*
  
  Its index to perform a script like this?
  
  ALTER index rebuild of IDX_PRODUCT;
  
  I just want to rebuid the index because I guess that after having pass the array to another tablaspace, the index is no longer gets its records, but I don't need to move the index to a different tablespace.
  My alter index statement above is fair?
  My version is Oracle 8.1.7.
  Thank you

  Yes.
  ALTER index rebuild of tablespace ;

• the index rebuild process

  Hi master,
  
  It is 'NO' yet another thread on the rebuilding of the index.
  
  I have read all the threads on index rebuild on oracle forums. each thread is full load with arguments and significantly useful discussion.
  
  but hardly a thread to discuss the process of rebuilding the index!
  
  I would like to know what exactly the do oracle, to rebuild the index? It uses the existing as a source index and therefore require more space?
  
  or it generates repeat therefore requires more space?
  
  What oracle will do with the old index? It frees the space occupied by the old index?
  
  If someone has a link or a suggestion, I will be grateful. and the deep knowledge sharing is more appreciated.
  
  
  Thanks and greetings
  VD
  
  Published by: vikrant dixit on January 21, 2009 03:40

  Vikrant dixit says:
  Thanks Charles

  for your kind support. and yet I doubt how much performance gain should be expected by rebuilding the index. I think I have to read all this thread once more and find the cream of the subject.

  and all that said by experts is it not true that the performance gain is dependent on scenario?

  in any case thank you

  Thanks and greetings
  VD

  Vikrant,

  From what I've seen and read, what said you above is correct.

  I like your the thread topic to try to understand what is happening during an index rebuild and after an index rebuild. The subject of rebuild indexes or not has been discussed many, many times on this forum, in messages Usenet dating back to 1999, various threads on asktom.oracle.com, various Web sites and in various books. But, your topic of what happens during an index rebuild, and after an index rebuild is not discussed as often, then I hope the links I provided will help you.

  Charles Hooper
  IT Manager/Oracle DBA
  K & M-making Machine, Inc.

• ALTER INDEX REBUILD and large waste area

  Hello world.
  
  Concerns the RDBMS EE 10.2.0.2 on a box with 16CPUs. Non-standard initialization parameters:
  
  db_16k_cache_size = 3G
  pga_aggregate_target = 3G
  SGA_MAX_SIZE = 12G
  SGA_TARGET = 5G
  workarea_size_policy = AUTO
  
  I have a large table partitioned on a monthly basis with a local couple of bitmap index on this subject. Table and index are stored in different areas of storage. The index tablespace is
  
  EXTENT MANAGEMENT UNIFORM LOCAL 1 M SIZE
  16K BLOCKSIZE
  SEGMENT SPACE MANAGEMENT AUTO
  
  Nightly batch processing allows a few partitions index unusable then inserts/adds one part of the data and rebuilds the index with
  
  ALTER INDEX... REBUILD PARTITION... NOLOGGING PARALLEL
  
  When you are finished, query on DBA_IND_PARTITIONS shows that, for all the index, partition value SCOPES is much greater than the value of used BYTES, for example one of the partitions has 106 DEGREES (1 MB each so he made 106 MB space) while only 15 MB for the BYTES.
  
  I understand that during the reconstruction of the parallel process slave create segments in the tablespace of the index of destination so that spend a lot more space than this segment takes finally. But it also means that the space is not released. (Deallocation/shrinkage will not help). Same thing can be demonstrated by the queries on DBA_SEGMENTS and DBA_FREE_SPACE. Because of this behavior, I have huge waste of space in the tablespace to index.
  
  Can someone help, please?
  Przemek
  
  Allocate space for parallel process slave is documented in the book 'Data warehousing database Oracle 10 g 2', chapter 25 "run in parallel to assistance.

  user2038804 wrote:
  Concerns the RDBMS EE 10.2.0.2 on a box with 16CPUs. Non-standard initialization parameters:

  When you are finished, query on DBA_IND_PARTITIONS shows that, for all the index, partition value SCOPES is much greater than the value of used BYTES, for example one of the partitions has 106 DEGREES (1 MB each so he made 106 MB space) while only 15 MB for the BYTES.

  Przemek,

  I can confirm that there is a bug in 10.2.0.2 leading to inconsistent information related to size in DBA_SEGMENTS / DBA_EXTENTS after an index rebuild in parallel to a big clue, maybe a bug 4771672 in 10.2.0.3. If I remember correctly the information of MEASUREMENT is correct and the information provided in DBA_SEGMENTS is misleading.

  The Metalink note suggests to use DBMS_SPACE_ADMIN Procedure TABLESPACE_FIX_SEGMENT_EXTBLKS to correct erroneous information in the dictionary, but I don't know if it was the one we used when encountering the problem.

  Kind regards
  Randolf

  Oracle related blog stuff:
  http://Oracle-Randolf.blogspot.com/

  SQLTools ++ for Oracle (Open source Oracle GUI for Windows):
  http://www.sqltools-plusplus.org:7676 /.
  http://sourceforge.NET/projects/SQLT-pp/

• I know how to force the Spotlight for re - index a drive or a folder. But how then do I mail?

  I know how to force the Spotlight for re - index a drive or a folder.

  But how then do I mail? I drag this file to the window?

  Thank you.

  Try re-indexing of mailboxes mailbox. This can take some time if you have a lot of mail.

  Reindex messages           For El Capitan, try looking in V3.

  Reindex messages (2)        See post by Linc Davis

• file system support for ASM with NAS?

  Can someone tell me the management system of files for ASM with NAS?

  Thank you

  How To Create ASM starts using NFS/NAS files? (Doc ID 731775.1)

  http://docs.Oracle.com/CD/E11882_01/install.112/e17212/storage.htm#CWLIN291

• Is it possible for an index that includes the condition 'GOLD '?

  Hello, I have a few questions.

  The test was conducted in the following procedure.

  ################################
  create table test
  (
  VARCHAR2 (10) C1.
  C2 varchar2 (10),
  key (c1) elementary school

  );

  create index test_idx1 on test (c2);

  Command > explain select * test where c1 = 'JOHN' or c2 = "JOHN";

  Query optimizer plan:

  STEP: 1
  LEVEL: 1
  OPERATION: RowLkRangeScan
  TABLENAME: TEST
  IXNAME: TEST
  CONDITION INDEX: < NULL >
  NOT INDEXED: TEST. C2 = 'JOHN' OR TEST. C1 = 'LUCY '.

  Command >

  
  Command > explain select * test where c1 = 'LUCY' and c2 = "ABDELLAH.

  Query optimizer plan:

  STEP: 1
  LEVEL: 1
  OPERATION: RowLkRangeScan
  TABLENAME: TEST
  IXNAME: TEST
  INDEXED CONDITION: TEST. C1 = 'ABDELLAH.
  NOT INDEXED: TEST. C2 = "ABDELLAH.

  Command >
  ################################

  By adding the status of "GOLD" in this test does not use the index.

  Is it possible for an index that includes the condition 'GOLD '?

  Thank you.

  GooGyum.

  A database can generally use indexes in this way for one 'or' with two different columns. However, for this example specific can easily rewrite the query using 'UNION' to use the relevant hints while still giving the same result (correct):

  Command > explain select * from t1 test where t1.c1 = 'LUCY' union select * test t2 where t2.c2 = "JOHN";

  Query optimizer plan:

  STEP: 1

  LEVEL: 1

  OPERATION: RowLkRangeScan

  TABLENAME: TEST

  IXNAME: TEST

  INDEXED CONDITION: T1. C1 = 'ABDELLAH.

  NOT INDEXED:

  STEP: 2

  LEVEL: 2

  OPERATION: RowLkRangeScan

  TABLENAME: TEST

  IXNAME: TEST_IDX2

  INDEXED CONDITION: T2. C2 = "ABDELLAH.

  NOT INDEXED:

  STEP: 3

  LEVEL: 1

  OPERATION: OrderBy

  TABLE_NAME:

  IXNAME:

  INDEXED CONDITION:

  NOT INDEXED:

  STEP: 4

  LEVEL: 2

  OPERATION: UnionMergeSort

  TABLE_NAME:

  IXNAME:

  INDEXED CONDITION:

  NOT INDEXED:

  Maybe you can apply something similar? If you know that there is no possibility of duplicate lines then you can optimize it (in terms of performance) by using UNION all.

  Chris

• Models to define templates for keys, indexes and constraints in Version 4

  Oracle SQL Developer Data Model Version 4.0.0.833

  Someone tell me where to find templates to define templates for keys, indexes and constraints?

  In version 3, it has been in tools > General Options > naming standards > models

  Hello

  In the 4.0.0.833 version, you must open the Properties dialog box for the design (by doing a right click on the entry for the relevant design in the browser tree, and select properties).

  Then in the design properties dialog box, select settings > naming Standard > models

  David

• Clustering factor vary for each index?

  Dear experts,

  Today when I was reading an article on bitmap indexes and index b-tree, I learned something new called consolidation factor. I read more about this and I was wondering which makes him change for each index?

  For example, lets say that I had the table as follows

  create table emp)

  emp_no number primary key,

  name varchar2 (50).

  name varchar2 (50)

  );

  create index emp_name_indx on emp (name);

  We got two indexed columns, one is emp_no and the other's name. My question is, suppose that we have inserted some 100 million lines with a sequential order by emp_no. However, the names may be different. for example;

  1 michael jackson

  2 toni blair

  Zack 3-wire

  ......

  mike tyson 1000000

  I mean, the names are scattered. And I think it's quite normal because you can only insert a command. So anyway, the factor of grouping of emp_no perhaps is low. However, for the name, it could be so high.

  If this is true, then it does not depend on us? We cannot do something to this factor, right? Because we can only insert rows based on the order of a column, isn't?

  My last question is also very important, lets say that we got 20 tables and these tables are filled with ascending order with hundreds of millions of rows. The factor of clustering for each index in these tables are also very high. Because the tables are filled with a sequential order and if the lines are added sequentially in the same blocks of data, i.e. the tables become widely dispersed in the data files. It's very bad for clustering factor?

  Thanks in advance.

  NightWing wrote:

  My last question is also very important, lets say that we got 20 tables and these tables are filled with ascending order with hundreds of millions of rows. The factor of clustering for each index in these tables are also very high. Because the tables are filled with a sequential order and if the lines are added sequentially in the same blocks of data, i.e. the tables become widely dispersed in the data files. It's very bad for clustering factor?

  See link below:

  Ask Tom & quot; Dba_indexes & quot;

  i.e. If you want CF to close the index of number of blocks, you must insert the data in the indexed column command; before the block insertion, you must inform this column order that is most important to you / indexed column.

  In the link above, Tom gave two examples:

  1 insert in... created id column order of indexes on columns id and name, so SEE the index for the id column is about the number of blocks. Because the order of column is the main factor for CF.

  2. Insert in... created name column order of indexes on columns id and name, so SEE the index for the column name is close to the number of blocks.  Because the order of column is the main factor for CF.

  Concerning

  Girish Sharma

• Index rebuild after moving table to a different tablespace?

  Index rebuild after moving table to a different tablespace?

  Oracle-Meng wrote:

  Index rebuild after moving table to a different tablespace?

  Only if you want to reuse.

  See DBA guide

  http://docs.Oracle.com/CD/B28359_01/server.111/b28310/tables006.htm#i1106606

  Pass an array to a new Segment or a Tablespace

  Move a table changes the ROWID of the rows in the table. This causes the indexes on the table to be marked UNUSABLE , and DML, access the table using these clues you will receive an ORA-01502 error. The indexes on the table must be deleted or rebuilt. Similarly, all the statistics in the table become invalid and new statistics should be collected after the removal of the table.