Internal components of the online index rebuild.

Hi all

What happens in the index rebuild online compared to the simple index rebuild?

Why this task consumes temporary space in the tablespace where index?

How to get access index is accepted when online index rebuilding... What happens internally?

-Yasser

Tags: Database

Similar Questions

For the loop index rebuild

DB version 10.2

 BEGIN
      FOR vIdxList IN (select INDEX_NAME from user_indexes where table_name in('PORT') and index_type='NORMAL')
      LOOP
   EXECUTE IMMEDIATE 'ALTER INDEX ' || vIdxList.INDEX_NAME || ' REBUILD nologging parallel 4 ';
      5      dbms_output.put_line('-----------------');
         --EXECUTE IMMEDIATE 'ALTER INDEX ' || vIdxList.INDEX_NAME || 'NOPARALLEL';
      END LOOP;
      begin
     FOR vIdxList IN (select INDEX_NAME from user_indexes where table_name in('PORT') and index_type='NORMAL')
     LOOP
     EXECUTE IMMEDIATE 'ALTER INDEX ' || vIdxList.INDEX_NAME || 'NOPARALLEL';
     end loop;
     end;
   END;
   /

When I try to do more high I am hit with ORA-02242 after reconstitution with nologging parallel 4. But when I run manually

 ALTER INDEX'  <index_name> NOPARALLEL

then ok.

Some can help me please

ERROR on line 1:
ORA-02242: no option specified for the ALTER INDEX statement
ORA-06512: at line 11 level

BEGIN
      FOR vIdxList IN (select INDEX_NAME from user_indexes where table_name in('EMPLOYEES') and index_type='NORMAL')
      LOOP
          EXECUTE IMMEDIATE 'ALTER INDEX ' || vIdxList.INDEX_NAME || ' REBUILD nologging parallel 4 ';
          EXECUTE IMMEDIATE 'ALTER INDEX ' || vIdxList.INDEX_NAME || ' NOPARALLEL ';
       END LOOP;
END;
/

After the import index rebuild...
My colleague and I are discussing is necessary or advisable, to rebuild the index after a schema import.

My thought is that the index data are implemented cost blocks thus creating a tree of very flat index without any fragmentation.
But my colleague suspect that perhaps the blocks are built exactly as they existed in the source database.

I could perhaps understand if the update was performed using RMAN that copies the block by block, but even in this case, I'm not sure.

You can help us understand this please?

Thank you.

Ed
In my view, all indexes of normal type are created 'new' as part of the import process.
This would include the B-tree, bitmap, based on a function, etc.

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.

Error creating the Spatial Index for SRID 8307 on newly hardened database
Oracle 11g Rel2, Windows 2003 platform

Help, please...

Meeting with error message:
ERROR on line 1:
ORA-29855: an error has occurred in the execution of routine ODCIINDEXCREATE
ORA-13249: internal error in the Spatial index: [mdidxrbd]
ORA-13249: geodetic initialization error turn
ORA-13249: SRID 8307 does not exist in the table MDSYS.CS_SRS
ORA-29400: data cartridge error
ORA-04063: package body 'MDSYS. SDO_CS"contains errors
ORA-06512: at the 'MDSYS. SDO_INDEX_METHOD_10I', line 10

After running the command

INSERT INTO USER_SDO_GEOM_METADATA VALUES
("PointGeometry",
"pointGeom,"
MDSYS.sdo_dim_array (mdsys.sdo_dim_element ('Longitude',-180, 180, 1),
mdsys.sdo_dim_element('Latitude',-90,90,1)),
8307
);

CREATE the INDEX IDX_POINTGEOMETRY on PointGeometry (pointGeom) indextype is mdsys.spatial_index parameters('LAYER_GTYPE=POINT');

When I ask mdsys.sdo_cs I see that there are actually SRID 8307. This index was created in this schema without problem. The problem only arises once the hardened customer database and we tried to recreate the schema (and index).

Probably not coincidentally, I also get error:
ORA-29855: an error has occurred in the execution of routine ODCIINDEXCREATE
ORA-04063: package body "CTXSYS. DRIXMD' has errors
ORA-06508: PL/SQL: called program unit is not found: 'CTXSYS. DRIXMD ".
ORA-06512: at "CTXSYS. DRUE", line 145
ORA-06512: at "CTXSYS. TEXTINDEXMETHODS', line 366
ORA-04063: package body "CTXSYS. DRIXMD' has errors
ORA-06508: PL/SQL: called program unit is not found: 'CTXSYS. DRIXMD ".

When attempting to create and index Oracle Text context.

Your help is greatly appreciated.
Then, that's the problem.

MDSYS user now has not run, and select privileges on the dbms_lob package.

You must grant privileges on this package in MDSYS.

Note that you can run into other issues of privilege package like this, so you must correct all by the granting of the
required privileges for MDSYS.

Siva

schedule the index rebuild online
Hello

I need to schedule a task at the level of the database to rebuild the index online each month. all script exist? as the procedure to call on every month to rebuild indexes for the 5 tables identified in our project?

It is in production

We run in oracle 10g in the solaris platform.
Dear Raman,

I have no why yon need this.

Try this, you can change next_date and interval you condition
```
declare
  VJOBNUMBER BINARY_INTEGER;
begin
  DBMS_JOB.SUBMIT( job => VJOBNUMBER, NEXT_DATE => sysdate, interval => 'SYSDATE + 30', WHAT => 'BEGIN
FOR S IN (SELECT ''alter index'' || INDEX_NAME || '' rebuild;'' A FROM ALL_INDEXES)
LOOP
EXECUTE IMMEDIATE S.A;
END LOOP;
END;');
  DBMS_OUTPUT.PUT_LINE('Job number assigned: ' || TO_CHAR(VJOBNUMBER));
end;
```

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.

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.

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

Reduced index rebuild the size of
Hi all

I think that this topic was raised by several times up to now... But I would like to know as I'm very curious.

An array of size 6 GB with index btree of 300 MB, the size very high CPU load in that server (I think because of I/O), after the reconstruction of this size of the index came up to 250 MB.

Now all my seniors ordered me to rebuild all indexes in the database that are huge in size, so that the i/o and CPU will be back to normal.

I had the argument with my elder for the reason why we need to rebuild the index?
Answer: As Oracle has access to this index it a lot of scan crashes a lot because of fragmentation. Oracle also has to scan all the blocks below the high water mark, where some blocks have fewer lines.

My doubt is: when index is fragmented (candidate means that after reconstruction, reduced its size) made Oracle scans unwanted blocks below let high water is wrong, because the INDEX and TABLE are two different concepts, INDEX maintains information on which all blocks, it would seek the required values. So Oracle will not scan the blocks unwanted in the INDEX.

Do may doubt is good or bad?

A few details:
The indicator is in DMT tablespace.
Oracle 8i version.
Sun solaris with 5.8 version, with 8 CPUS and 6 GB of RAM
None of the indices have a height more than two.

Plz HELP me in this concept... I want to prove my elders.

-Yasser
Yasserracdba,

People learn their theory IT more. The normal index is implemented as a B *-tree structure.
This means
```
                                                                  1 

                                             2        3                              5            6

                                      7       8    9   10                    11     12    13     14
                                                   
```
This means: block 1 contains information on block 2, 3, 5, 6 (I forgot 4, does not renumber)
Block 2 about 7 and 8
Block 7, etc are the leaves blocks and contain the actual keys.
The key consists of key values and a rowid.

The index is balanced. For a single scan will always tell you the same number of blocks, in this case 4
(3 blocks + block index 1 data).

IF YOU DON'T HAVE A CLUE, YOU WILL BE FORCED TO READ THE ENTIRE TABLE, THE TABLE SCAN COMPLETE THIS CALLED (YOU CAN SHOUT, I CAN SHOUT TOO)

TO ACCESS THE INDEX MEANS SELF-CONTAINED BED, FULL TABLE SCAN MEANS SCATTERED MULTI BLOCK READING (BLOCKS END UP NOT CONTIGUOUS CACHE)

FOR RANGE SCANS IO CAN BE REDUCED. TO LOOK UP A KEY INDIVIDUAL IO WILL NOT, I REPEAT N O T, REDUCE.

-----------------
Sybrand Bakker
Senior Oracle DBA

Experts: those who don't read the documentation

Published by: sybrand_b on May 28, 2009 11:04

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.

Locking during the generation and the online option to avoid problems

Hi Experts,

In our suite of applications, schemas are shared among several applications, and even when there is a deployment of an application, the other application remains upward. In this process, we are facing problems of locking. For example, when creating indexes, I get the error "resource busy and acquired with no expectations. This post is specific to this point on error when creating index (change the design of the app etc is out of reach for me currently).

I was checking the "online" option of create index and I was wondering if that helps. It looks promising for me. When we have large tables (50 million more and creating indexes on them takes about 5 minutes and at the same time we have another app doing short transactions - who commit in 5 seconds, then creating index 'with the option' can help - is what I was asking.)

Here is an example of what I've tried:
```
-- first create a table with a few million rows:

SET SERVEROUTPUT ON

DECLARE
  v_sql VARCHAR2 (200);
BEGIN
  v_sql := 'create table test as select * from dba_objects';

  EXECUTE IMMEDIATE v_sql;

  FOR i IN 1 .. 5
  LOOP
  v_sql := 'insert into test select * from test';

  EXECUTE IMMEDIATE v_sql;

  COMMIT;
  END LOOP;
END;
/

--Now in session 1:
---------


create index ti1 on test(OWNER,OBJECT_NAME,SUBOBJECT_NAME,OBJECT_ID,DATA_OBJECT_ID,OBJECT_TYPE,CREATED,LAST_DDL_TIME,TIMESTAMP,STATUS,TEMPORARY,GENERATED,SECONDARY,NAMESPACE)
online;

session 2:
------------
DELETE FROM TEST WHERE ROWNUM<1000;

commit;

DELETE FROM TEST WHERE ROWNUM<40200;
rollback;

--etc.
```
I find that deletions, etc. in the second session is done (they follow by commit and they take a few seconds) with this option 'create an index online '. The option 'create index' is also no error with the error ORA-«resource busy...» ». So what a better way to create indexes to avoid locking issues? Note that is is very good for us to have the creation of index take more time for what's important is that they are not lacking in critical production deployments.

Are there other possible implications (-except that it takes more time to create the index with the option 'online'), that one should be aware of? Any known issues or is there any other glitches with the creation of online index?

I will be grateful for any views on that.

What is your version of DB full?

In our suite of applications, schemas are shared among several applications, and even when there is a deployment of an application, the other application remains upward. In this process, we are facing problems of locking. For example, when creating indexes, I get the error "resource busy and acquired with no expectations.

OK-, this exception is not surprising. To create or rebuild an index, Oracle has a lock on the base table. He can't do that if other users perform DML on the table - it must wait.

And before 11 g ANY other session that then tries to perform DML on the base table that oracle wait will also block.

I was checking the "online" option of create index and I was wondering if that helps.

Well, if you do not use the clause of 'ONLINE' you must do that maintenance CONNECTION or you now cause other sessions cling while creating/reconstruction is made;

It looks promising for me. When we have large tables (50 million more and creating indexes on them takes about 5 minutes and at the same time we have another app doing short transactions - who commit in 5 seconds, then creating index 'with the option' can help - is what I was asking.)

Yes - it should help. But he cannot eliminate the problem entirely.

See this article by the Index indicated Richard expert Foote (there are many other related articles index also):

https://richardfoote.WordPress.com/2008/02/11/index-create-and-rebuild-locking-improvements-in-11g-ch-ch-ch-changes/

One of the secondary index is not complete

Hello
I had an entity having 18847 record. It contains a primary key and secondary keys several. Since the next release to check, we see it, all indexes are complete except ProductId. What should I do to fix this error?
Verification of data persist #gdlogs #test. TableWhProductStorageCard
Tree control to persist #gdlogs #test. TableWhProductStorageCard
BTree: Composition of the btree, types and number of nodes.
binCount = 149
binEntriesHistogram = [40-49%: 1; 80 to 89%: 1, 90-99%: 147]
binsByLevel = [level 1: count = 149]
deletedLNCount = 0
inCount = 3
insByLevel = [level 2: number = 2; level 3: count = 1]
lnCount = 18, 847
mainTreeMaxDepth = 3
BTree: Composition of the btree, types and number of nodes.
Verification of data persist #gdlogs #test. TableWhProductStorageCard #BatchNo
Tree control to persist #gdlogs #test. TableWhProductStorageCard #BatchNo
BTree: Composition of the btree, types and number of nodes.
binCount = 243
binEntriesHistogram = [% 40-49: 43; 50 to 59%: 121, 60-69%: 30; 70-79%: 23; 80 to 89%: 17; 90-99%: 9]
binsByLevel = [level 1: count = 243]
deletedLNCount = 0
inCount = 4
insByLevel = [level 2: number = 3; level 3: count = 1]
lnCount = 18, 847
mainTreeMaxDepth = 3
BTree: Composition of the btree, types and number of nodes.
This secondary index is correct. (the lnCount is the same as the primary index)

Verification of data persist #gdlogs #test. TableWhProductStorageCard #ProductId
Tree control to persist #gdlogs #test. TableWhProductStorageCard #ProductId
BTree: Composition of the btree, types and number of nodes.
binCount = 168
binEntriesHistogram = [% 40-49: 16; 50 to 59%: 47; 60 to 69%: 39; 70-79%: 26; 80 to 89%: 26; 90-99%: 14]
binsByLevel = [level 1: count = 168]
deletedLNCount = 0
inCount = 3
insByLevel = [level 2: number = 2; level 3: count = 1]
lnCount = 14: 731
mainTreeMaxDepth = 3
BTree: Composition of the btree, types and number of nodes.
This index is not complete. (lnCount is less than the primary index) Then when use this index to iterate through the lines, only the first record 14731 is returned.

Apparently, somehow your secondary index DB became not synchronized with your primary. Normally, this is caused by not using is not a transactional store (EntityStore.setTransactional). But whatever the cause, I will describe how to correct the situation by rebuilding the index.

(1) take your application offline so that no other operations occur.

(2) make a backup in case a problem occurs during this procedure.

(3) do not open the EntityStore yet.

(4) delete the database index that is out of sync (persist #gdlogs #test. TableWhProductStorageCard #ProductId) by calling the Environment.removeDatabase with this name.

(5) rebuild the index database simply by opening the EntityStore. It will take more time than usual, since the index will be rebuilt before the return of the EntityStore constructor.

(6) confirm that the index is rebuilt correctly.

(7) bring your online return request.

-mark

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.

ORA-00439: feature not enabled: Online Index build
Hello

OS: LINUX
Oracle: 10.2.0.3

I get the below error while I m attemptig to rebuild the index. He runs in another db in the same version.

SQL > alter index ANALYTIC2.MS_QF_RATING rebuild online;
change the ANALYTIC2.MS_QF_RATING index rebuild online
*
ERROR on line 1:
ORA-00439: feature not enabled: Online Index build

Some may suggest what is the root cause and what might e the best solution for this problem.

Thank you.
Marie rosine
Enterprise Edition has the word "Business" in the banner.
```
SQL> select * from v$version;

BANNER
----------------------------------------------------------------
Oracle Database 10g *Enterprise Edition* Release 10.2.0.4.0 - Prod
PL/SQL Release 10.2.0.4.0 - Production
CORE    10.2.0.4.0      Production
TNS for Linux: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production
```
In the absence of the above, it is the standard edition.

Internal components of the online index rebuild.

Similar Questions

Maybe you are looking for