'alter index rebuild' paralellism problem

Hi,
I have this problem described in example. I am using interMedia Text version 8.1.7 on Win32 platform ,
Imagine two tables with the same structure, but in first there are big pdf files(size more than 1MB, lot of files) and in the second there are small files(less than 10KB, imagine few files).
There are same preferences used for indexing( file_datastore, inso_filter..).
If I run the alter index for first table, it usually takes long time. Than if I run the alter index for the second table, it always begin after the first will finish.
Other combination work correctly :
Running create index for first table and create index for second is done paralelly, runnig combination of create index and alter index (no matter for which table) is done paralelly too.
The only problem is with runnig two alter indexes at the same time.
The problem is about to index around 100 GB of documents by small steps - documents are added and indexed using alter index. Using create index is not possible, because whole system is backed up and switched off during night.
So indexing process is interrupted.
Thanks for every reply..
Milan

Please put your question in the Oracel text forumn for a quicker, more expert answer.

Similar Messages

Alter index rebuild

Hello, I want to rebuild an index :
SQL> alter index APPLSYS.WF_LOCAL_ROLES_N1 REBUILD ;
alter index APPLSYS.WF_LOCAL_ROLES_N1 REBUILD
ERROR at line 1:
ORA-14086: a partitioned index may not be rebuilt as a whole
What is wrong with my sql instruction ? Should I give partition name may be ? Where can I find partition name for that index ? Many thanks before.

[linuxas oracle test10]$ oerr ora 14086
14086, 00000, "a partitioned index may not be rebuilt as a whole"
// *Cause: User attempted to rebuild a partitioned index using
//          ALTER INDEX REBUILD statement, which is illegal
// *Action: Rebuild the index a partition at a time (using
//          ALTER INDEX REBUILD PARTITION) or drop and recreate the
//          entire index
[linuxas oracle test10]$To see partition names for an index :
SQL> select partition_name from USER_IND_PARTITIONS
2* where index_name = '<YOUR INDEX>';Paul

Alter index rebuild calculates statistics?

Hi
Does anyone know if ALTER INDEX REBUILD gathers statistics on the index automatically? Does it do it at a 100% by default?
Thanks for your help!!!

On 10g+ the alter index command defaults to compute statistics which to the best o my knowledge is a 100% sample. With lower versions you need to specify that you want statistics: alter index owner.index_name rebuild compute statistics;
HTH -- Mark D Powell --

Alter index rebuild reverse duration

Hi,
I'm working on an Oracle Database 11g Release 11.1.0.6.0 - 64bit Production With the Real Application Clusters option.
I would need to rebuild reverse 2 indexes, 60gb each.
Is it possibile to forecast somehow the opreation duration?
The alter index rebuild is locking (insert on those tables are locked), doesn't it?
Thanks in advance,
Samuel

You can rebuild it online, but it will demand extra temporary space, and can take more time.
ALTER INDEX INDX REBUILD ONLINE

Question on fragmentation and ALTER INDEX REBUILD/REORGANIZE not effecting it

The problem I ran into was troubleshooting a sporadically slow singleton lookup on a Clustered Index in a table with about 8 million rows, which is a separate issue I may need to submit for help. That aside, during that troubleshooting I noticed fragmentation
on the Unique Clustered Index (it's a VARCHAR(20)), and then noticed the fragmentation in other indexes on this table. See sys.dm_db_index_physical_stats and DBCC SHOWCONTIG results below.
SELECT
substring(OBJECT_NAME(i.object_id),1,30) AS TableName,
substring(i.name,1,40) AS TableIndexName,
i.index_id, phystat.index_level,
phystat.avg_fragmentation_in_percent
FROM
sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'DETAILED') phystat inner JOIN sys.indexes i
ON i.object_id = phystat.object_id
AND i.index_id = phystat.index_id WHERE
OBJECT_NAME(i.object_id) = 'CONSUMERS'
TableName TableIndexName index_id index_level avg_fragmentation_in_percent
CONSUMERS UNI2K_CONSUMERS 1 0
0.154827346202469
CONSUMERS UNI2K_CONSUMERS 1 1
35.2941176470588
CONSUMERS UNI2K_CONSUMERS 1 2
0
CONSUMERS PK__CONSUMER__7F6B0B8B286302EC 2 0 0.336078590685822
CONSUMERS PK__CONSUMER__7F6B0B8B286302EC 2 1 100
CONSUMERS PK__CONSUMER__7F6B0B8B286302EC 2 2 0
CONSUMERS UNI1K_CONSUMERS 3 0
0.156451316031658
CONSUMERS UNI1K_CONSUMERS 3 1
61.1510791366906
CONSUMERS UNI1K_CONSUMERS 3 2
0
CONSUMERS IDX1_CONSUMERS 4 0
0.215271389144434
CONSUMERS IDX1_CONSUMERS 4 1
40
CONSUMERS IDX1_CONSUMERS 4 2
100
CONSUMERS IDX1_CONSUMERS 4 3
0
CONSUMERS IDX2_CONSUMERS 5 0
0.222614710968834
CONSUMERS IDX2_CONSUMERS 5 1
38.6281588447653
CONSUMERS IDX2_CONSUMERS 5 2
75
CONSUMERS IDX2_CONSUMERS 5 3
0
(17 row(s) affected)
DBCC SHOWCONTIG('CONSUMERS') WITH ALL_INDEXES
DBCC SHOWCONTIG scanning 'CONSUMERS' table...
Table: 'CONSUMERS' (645577338); index ID: 1, database ID: 5
TABLE level scan performed.
- Pages Scanned................................: 70401
- Extents Scanned..............................: 8827
- Extent Switches..............................: 8843
- Avg. Pages per Extent........................: 8.0
- Scan Density [Best Count:Actual Count].......: 99.51% [8801:8844]
- Logical Scan Fragmentation ..................: 0.15%
- Extent Scan Fragmentation ...................: 23.76%
- Avg. Bytes Free per Page.....................: 47.2
- Avg. Page Density (full).....................: 99.42%
DBCC SHOWCONTIG scanning 'CONSUMERS' table...
Table: 'CONSUMERS' (645577338); index ID: 2, database ID: 5
LEAF level scan performed.
- Pages Scanned................................: 27077
- Extents Scanned..............................: 3402
- Extent Switches..............................: 3402
- Avg. Pages per Extent........................: 8.0
- Scan Density [Best Count:Actual Count].......: 99.47% [3385:3403]
- Logical Scan Fragmentation ..................: 0.34%
- Extent Scan Fragmentation ...................: 11.88%
- Avg. Bytes Free per Page.....................: 24.1
- Avg. Page Density (full).....................: 99.70%
DBCC SHOWCONTIG scanning 'CONSUMERS' table...
Table: 'CONSUMERS' (645577338); index ID: 3, database ID: 5
LEAF level scan performed.
- Pages Scanned................................: 54330
- Extents Scanned..............................: 6803
- Extent Switches..............................: 6805
- Avg. Pages per Extent........................: 8.0
- Scan Density [Best Count:Actual Count].......: 99.79% [6792:6806]
- Logical Scan Fragmentation ..................: 0.16%
- Extent Scan Fragmentation ...................: 7.03%
- Avg. Bytes Free per Page.....................: 50.3
- Avg. Page Density (full).....................: 99.38%
DBCC SHOWCONTIG scanning 'CONSUMERS' table...
Table: 'CONSUMERS' (645577338); index ID: 4, database ID: 5
LEAF level scan performed.
- Pages Scanned................................: 54350
- Extents Scanned..............................: 6808
- Extent Switches..............................: 6837
- Avg. Pages per Extent........................: 8.0
- Scan Density [Best Count:Actual Count].......: 99.36% [6794:6838]
- Logical Scan Fragmentation ..................: 0.22%
- Extent Scan Fragmentation ...................: 7.17%
- Avg. Bytes Free per Page.....................: 53.2
- Avg. Page Density (full).....................: 99.34%
DBCC SHOWCONTIG scanning 'CONSUMERS' table...
Table: 'CONSUMERS' (645577338); index ID: 5, database ID: 5
LEAF level scan performed.
- Pages Scanned................................: 54354
- Extents Scanned..............................: 6804
- Extent Switches..............................: 6846
- Avg. Pages per Extent........................: 8.0
- Scan Density [Best Count:Actual Count].......: 99.24% [6795:6847]
- Logical Scan Fragmentation ..................: 0.22%
- Extent Scan Fragmentation ...................: 7.13%
- Avg. Bytes Free per Page.....................: 53.8
- Avg. Page Density (full).....................: 99.33%
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
This fragmentation I found shocking because I reorg nightly and have a weekly rebuild task running that I set up through the Maintenance Plan wizard (which I've verified has been running). So I attempted to reorg these manually (especially index ID: 1)
and to my shock the fragmentation % did not change at all. I then took the SQL provided by the Maintenance Plan for rebuilding the indexes and found that after running that it didn't change the fragementation % at all either (commands run shown below).
ALTER INDEX [IDX1_CONSUMERS] ON [dbo].[CONSUMERS] REBUILD PARTITION = ALL WITH ( PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, ONLINE = ON, SORT_IN_TEMPDB = ON )
GO
ALTER INDEX [IDX2_CONSUMERS] ON [dbo].[CONSUMERS] REBUILD PARTITION = ALL WITH ( PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, ONLINE = ON, SORT_IN_TEMPDB = ON )
GO
ALTER INDEX [UNI1K_CONSUMERS] ON [dbo].[CONSUMERS] REBUILD PARTITION = ALL WITH ( PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, IGNORE_DUP_KEY = OFF, ONLINE = ON, SORT_IN_TEMPDB
= ON )
GO
ALTER INDEX [UNI2K_CONSUMERS] ON [dbo].[CONSUMERS] REBUILD PARTITION = ALL WITH ( PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, IGNORE_DUP_KEY = OFF, ONLINE = ON, SORT_IN_TEMPDB
= ON )
GO
Fragmentation did not change until I performed a "CREATE ... DROP_EXISTING = ON" on the 4 non PK indexes and a manual rebuild of Primary Key offline not specifying any other parameters, which all seemed completely overkill to ensure the defragmentation
actually got done. Final sys.dm_db_index_physical_stats and DBCC SHOWCONTIG results below.
SELECT
substring(OBJECT_NAME(i.object_id),1,30) AS TableName,
substring(i.name,1,40) AS TableIndexName,
i.index_id, phystat.index_level,
phystat.avg_fragmentation_in_percent
FROM
sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'DETAILED') phystat inner JOIN sys.indexes i
ON i.object_id = phystat.object_id
AND i.index_id = phystat.index_id WHERE
OBJECT_NAME(i.object_id) = 'CONSUMERS'
TableName TableIndexName index_id index_level avg_fragmentation_in_percent
CONSUMERS UNI2K_CONSUMERS 1 0
0.0213458562356583
CONSUMERS UNI2K_CONSUMERS 1 1
11.2426035502959
CONSUMERS UNI2K_CONSUMERS 1 2
0
CONSUMERS PK__CONSUMER__7F6B0B8B286302EC 2 0 0.0460971112476951
CONSUMERS PK__CONSUMER__7F6B0B8B286302EC 2 1 14.2857142857143
CONSUMERS PK__CONSUMER__7F6B0B8B286302EC 2 2 0
CONSUMERS UNI1K_CONSUMERS 3 0
0.0225314031431307
CONSUMERS UNI1K_CONSUMERS 3 1
10.6194690265487
CONSUMERS UNI1K_CONSUMERS 3 2
0
CONSUMERS IDX1_CONSUMERS 4 0
0.0225318262045139
CONSUMERS IDX1_CONSUMERS 4 1
10.7296137339056
CONSUMERS IDX1_CONSUMERS 4 2
0
CONSUMERS IDX1_CONSUMERS 4 3
0
CONSUMERS IDX2_CONSUMERS 5 0
0.0225314031431307
CONSUMERS IDX2_CONSUMERS 5 1
12.0171673819742
CONSUMERS IDX2_CONSUMERS 5 2
0
CONSUMERS IDX2_CONSUMERS 5 3
0
(17 row(s) affected)
DBCC SHOWCONTIG('CONSUMERS') WITH ALL_INDEXES
DBCC SHOWCONTIG scanning 'CONSUMERS' table...
Table: 'CONSUMERS' (645577338); index ID: 1, database ID: 5
TABLE level scan performed.
- Pages Scanned................................: 56217
- Extents Scanned..............................: 7029
- Extent Switches..............................: 7028
- Avg. Pages per Extent........................: 8.0
- Scan Density [Best Count:Actual Count].......: 99.99% [7028:7029]
- Logical Scan Fragmentation ..................: 0.02%
- Extent Scan Fragmentation ...................: 0.44%
- Avg. Bytes Free per Page.....................: 32.4
- Avg. Page Density (full).....................: 99.60%
DBCC SHOWCONTIG scanning 'CONSUMERS' table...
Table: 'CONSUMERS' (645577338); index ID: 2, database ID: 5
LEAF level scan performed.
- Pages Scanned................................: 26032
- Extents Scanned..............................: 3256
- Extent Switches..............................: 3255
- Avg. Pages per Extent........................: 8.0
- Scan Density [Best Count:Actual Count].......: 99.94% [3254:3256]
- Logical Scan Fragmentation ..................: 0.05%
- Extent Scan Fragmentation ...................: 0.31%
- Avg. Bytes Free per Page.....................: 11.1
- Avg. Page Density (full).....................: 99.86%
DBCC SHOWCONTIG scanning 'CONSUMERS' table...
Table: 'CONSUMERS' (645577338); index ID: 3, database ID: 5
LEAF level scan performed.
- Pages Scanned................................: 53259
- Extents Scanned..............................: 6659
- Extent Switches..............................: 6658
- Avg. Pages per Extent........................: 8.0
- Scan Density [Best Count:Actual Count].......: 99.98% [6658:6659]
- Logical Scan Fragmentation ..................: 0.02%
- Extent Scan Fragmentation ...................: 0.35%
- Avg. Bytes Free per Page.....................: 40.5
- Avg. Page Density (full).....................: 99.50%
DBCC SHOWCONTIG scanning 'CONSUMERS' table...
Table: 'CONSUMERS' (645577338); index ID: 4, database ID: 5
LEAF level scan performed.
- Pages Scanned................................: 53258
- Extents Scanned..............................: 6659
- Extent Switches..............................: 6658
- Avg. Pages per Extent........................: 8.0
- Scan Density [Best Count:Actual Count].......: 99.98% [6658:6659]
- Logical Scan Fragmentation ..................: 0.02%
- Extent Scan Fragmentation ...................: 0.53%
- Avg. Bytes Free per Page.....................: 40.3
- Avg. Page Density (full).....................: 99.50%
DBCC SHOWCONTIG scanning 'CONSUMERS' table...
Table: 'CONSUMERS' (645577338); index ID: 5, database ID: 5
LEAF level scan performed.
- Pages Scanned................................: 53259
- Extents Scanned..............................: 6659
- Extent Switches..............................: 6658
- Avg. Pages per Extent........................: 8.0
- Scan Density [Best Count:Actual Count].......: 99.98% [6658:6659]
- Logical Scan Fragmentation ..................: 0.02%
- Extent Scan Fragmentation ...................: 0.59%
- Avg. Bytes Free per Page.....................: 40.5
- Avg. Page Density (full).....................: 99.50%
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
For the record, here's the version I'm running:
select @@VERSION
Microsoft SQL Server 2008 R2 (SP1) - 10.50.2500.0 (X64)
Jun 17 2011 00:54:03
Copyright (c) Microsoft Corporation
Enterprise Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1)
In summary my question is - why didn't ALTER INDEX ... REBUILD/REORGANIZE modify the index_level 1 fragmentation as reported by sys.dm_db_index_physical_stats, nor would it correct the Extent Scan Fragmentation as reported by DBCC SHOWCONTIG?

Hi Brian.cs ,
SQL Server will not rebuild indexes that are not large enough. Could you please have a look a the
fragment_count which is one of the fields in the
sys.dm_db_index_physical_stats view to check whether it is low or not ?
Best Regards,
Peja
Please remember to click "Mark as Answer" on the post that helps you, and to click "Unmark as Answer" if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
Peja, here's the information you requested, and of course this was after I dropped/recreated because rebuild didn't seem to actually address the fragmentation - the index I was most concerned about at index_level = 0 showed a fragment_count = 8922. FYI this
table has over 8 million rows. And apologies for the delayed response, was on vacation over the near year.
SELECT
substring(OBJECT_NAME(i.object_id),1,30) AS TableName,
substring(i.name,1,40) AS TableIndexName,
i.index_id, phystat.index_level,
phystat.avg_fragmentation_in_percent, fragment_count
FROM
sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'DETAILED') phystat inner JOIN sys.indexes i
ON i.object_id = phystat.object_id
AND i.index_id = phystat.index_id WHERE
OBJECT_NAME(i.object_id) = 'CONSUMERS'
TableName TableIndexName index_id index_level avg_fragmentation_in_percent
fragment_count
CONSUMERS UNI2K_CONSUMERS 1 0
0.259780818806428 8922
CONSUMERS UNI2K_CONSUMERS 1 1
39.4190871369295 86
CONSUMERS UNI2K_CONSUMERS 1 2
0 1
CONSUMERS PK__CONSUMER__7F6B0B8B286302EC 2 0 0.240887634434766
5182
CONSUMERS PK__CONSUMER__7F6B0B8B286302EC 2 1 80.3738317757009
84
CONSUMERS PK__CONSUMER__7F6B0B8B286302EC 2 2 0
1
CONSUMERS UNI1K_CONSUMERS 3 0
0.0661472879611936 8532
CONSUMERS UNI1K_CONSUMERS 3 1
53.4883720930233 86
CONSUMERS UNI1K_CONSUMERS 3 2
0 1
CONSUMERS IDX1_CONSUMERS 4 0
0.192426334498663 8598
CONSUMERS IDX1_CONSUMERS 4 1
31.5315315315315 95
CONSUMERS IDX1_CONSUMERS 4 2
85.7142857142857 7
CONSUMERS IDX1_CONSUMERS 4 3
0 1
CONSUMERS IDX2_CONSUMERS 5 0
0.189494094835184 8613
CONSUMERS IDX2_CONSUMERS 5 1
31.8840579710145 97
CONSUMERS IDX2_CONSUMERS 5 2
85.7142857142857 7
CONSUMERS IDX2_CONSUMERS 5 3
0 1

Alter index rebuild with online option

I created a spatial index with the following statement:
SQL> create index A3_IX1_A on A67(GEOMETRIE) indextype is mdsys.spatial_index parameters ('sdo_non_leaf_tbl=TRUE; sdo_dml_batch_size =
2 1000');
I want to rebuild the index with the next statement:
SQL> alter index ttnl.A3_IX1_A rebuild online parameters ('index_status=cleanup;sdo_dml_batch_size=1000');
the result is the next error message:
alter index ttnl.A3_IX1_A rebuild online parameters ('index_status=cleanup;sdo_dml_batch_size=1000')
ERROR at line 1:
ORA-29871: invalid alter option for a domain index
Can some one help me?

Hi,
This is only supported in the next release (11.x).
In the release upto 10.2, this functionality is not supported for Spatial indexes.
siva
Message was edited by:
sravada

Alter index rebuild question

Hello experts,
I have a simple question regarding rebuilding indexes...
First, I am running 11.2.0.2 on Solaris 10.
My reason for rebuilding is to relocate the indexes to their own tablespace, and while I recognize this is a subjective reason as far as performance is concerned, it makes administration easier.
That being said, my question is in regards to use of "compute statistics" and also "online", and "nologging".
Since I do want to minimize he impact to our users, and this table is one of the most used tables in the database, my syntax was going to be as follows:
alter index <schema>.<index> rebuild online nologging tablespace <ts_idx> compute statistics;
Questions:
1.   does doing the rebuild online preclude queries against the table during the duration of the rebuild?
2.   does use of nologging improve speed of rebuilding
3.   is it advisable to include the "compute statistics". I believe I read on Jonathan Lewis' page that statistics are gathered automatically and to include "compute statistics" was not necessary when rebuilding an index.
And I guess one final question is whether I can include all the options in the same rebuild statement as I have shown above?
I've tested the above in our test database, but it seems to hang when using the online option (with all the other options).
Thanks in advance.

Excellent resource. Thanks for the link. While I've read most of those discussions on either Jonathan's or Richard's web sites already, it is a good presentation and reference.
Unfortunately, it does not answer either of the questions that I asked. The reason I asked those questions is because the answers you gave contradict what i read in Oracle documentation (although it might be version specific).
Also, it does seem to be slightly faster to rebuild using nologging (in my test environment).
I've tested this with multiple indexes and the timing is slightly improved consistently.
{quote}
SQL> ALTER INDEX ARADMIN."T2179_C1_0944_1037" REBUILD LOGGING TABLESPACE REMEDY_IDX;
Index altered.
Elapsed: 00:00:10.68
SQL> ALTER INDEX ARADMIN."T2179_C1_0944_1037" REBUILD nologging TABLESPACE REMEDY_IDX;
Index altered.
Elapsed: 00:00:08.50
{quote}
The use of online, however, seems to "hang" for some reason, even in my test database while no one else is logged into the database except me.
Referencing Oracle's documentation, it says that rebuilding an index online does not allow queries against the base table. This is why I asked this question, but your answer is different than Oracle's. In this case, however, it is for Oracle 10.2, so not sure if this is still true for 11.2.
Ref. Oracle Text SQL Statements and Operators
[ONLINE]
ONLINE enables you to continue to perform updates, inserts, and deletes on a base table; it does not enable you to query the base table.
You cannot use PARALLEL with ONLINE. ONLINE is only supported for CONTEXT indexes.
Now, regarding the use of "compute statistics", I am pretty sure I recall reading either in Jonathan's papers, or in Richard's papers, that this is not necessary and/or is redundant. But then why would Oracle include this as an option. This is counter intuitive, which again is why I'm asking. Do you know if any reference that can clear this up?

Alter index ... rebuild was failing - getting corrupt blocks

Database: 9.2.0.5
OS: HPUX-ia64
Hello,
i rebuilded a index, announced from UpdatStats in DB13, and get a ORA-01114: IO error writing block to file 2045 (block # 319154) and
ORA-27072: skgfdisp: I/O error in my sqlplus session.
-> i do a alter index SAPR3."xxx~0" rebuild online parallel 4 nologging;
-> System was up and running
After that, the DBVerify marked some blocks corrupt, here one example:
BR0398E DBVERIFY detected corrupted blocks in /oracle/XXX/sapdata22/btabi_95/btabi.data95
We checked all corrupted blocks - all in free space.
So we fixed that with creating a table with next extend size from the corrupted blocksize.
I think we had not enough space in the tablespace where the index is, okay ... and what we also found, the PSAPTEMP datafiles was created as SPARSE files ...!!
-> PSAPTEMP-Datafile: 10GB in the System - 2,5GB maximum on OS-Level, no more space.
But my question is why i am getting corrupt blocks when a "alter index ... rebuild ..." is failing ?!?!
Thank you for your support.
Regards,
Markus
Edited by: Markus Dinkel on Oct 9, 2008 12:56 PM
Edited by: Markus Dinkel on Oct 9, 2008 12:56 PM
Edited by: Markus Dinkel on Oct 9, 2008 12:59 PM

Thany you for the answer.
I cant find any "cor" entries in the last DBVeriy log.
I think (hope) we dont' have anymore corrupted blocks in the system.
We get a response from SAP to update to 9.2.0.8.
My customer wanna do a update to oracle 10 in march/april 2009, so he send me the question if we need a update to 9.2.0.8 ASAP or can we wait for the update to oralce10.
But the important question from my customer and me is, why we get corrupt blocks after failing the alter index rebuild?
Regards,
Markus

ALTER INDEX .. REORGANIZE vs.REBUILD

What is the difference between ALTER INDEX .. REORGANIZE and ALTER INDEX .. REBUILD ?
Thanks, Christine & Danny

Are you talking about Oracle here?
There is no REORGANIZE with ALTER INDEX. Its valid command for SQLServer.
If you are talking about SqlServer here, then, read the article from the below link:
http://msdn2.microsoft.com/en-us/library/ms189858.aspx
If you are concerned about Oracle's ALTER INDEX REBUILD, read my blog about functionality/machanism of rebuilding index online and normally, Part 1 and Part 2.
http://jaffardba.blogspot.com/search/label/Indexes

Index rebuild

Hi Team,
Please tell me any difference b/w alter index <index> rebuild or alter index <index> rebuild move.
Is there any difference that more space will be released if I move index to diffrenet tablespace and move move back to orginal tablespace.
I know that if we use move option we can move index to different tablespace,
Regards,
jit

Even if you would do lots of dml's, that's not certainly means that you need the rebuilding of the index. If your assertion is based on this that there would be some "holes" within the leaf blocks which wont be reused and would require a rebuild, it's wrong then since Oracle would take care of these things on its own. So again, what criteria, other than an OLTP db you used to conclude that you need rebuilding of indexes?
But I just wanted to know If I go for alter index rebuild or alter index rebuild move and move back the indexes, which option will be best for me mean by which option I can reclaim more space.Well, I am sorry to say but I think you really don't know very well both the commands. The commands don't differ in the space reclaim given by them but in the way they do the rebuild. Please read the documentation to know what both commands do and how? BTW, from where you picked the command alter index rebuild move since I am not sure that such command exists?
Aman....

Index rebuild - temporary segment

Hi,
I am getting an error while rebuilding the indexes, like unable to allocate extents in temporary segment. Kindly help me to solve this.
Regards,
Mathew Collins

You should never drop an index with the intention of recreating it without first checking the size of the index against the size of the available temp tablespace sort area.
If you are using an alter index rebuild to reorganize the index then unless you specify a new tablespace in the command the existing tablespace must have enough free space to hold the entire original index and the rebuilt index. An alter index rebuild also uses temporary (sort) tablespace so you still need to ensure that your index has not outgrown your temp tablespace.
HTH -- Mark D Powell --

Problems creating/altering index with certain Word docs

Hello,
I am having an odd problem when attempting to drop/create or alter my index after entering certain MS Word docs in my table.
Has anyone run into this? Does anyone have any insight as to which features in Word docs (e.g. macros, etc.) might cause this problem?
The errors are listed below (they also cause GPFs when extproc.exe runs). Thanks for your help.
Mike
alter index blobdoc_idx rebuild online parameters ( 'sync' )
ERROR at line 1:
ORA-29863: warning in the execution of ODCIINDEXCREATE routine
SQL> CREATE INDEX BLOBDOC_IDX
2 ON BLOBS(DOC_BLOB) INDEXTYPE IS CTXSYS.CONTEXT PARAMETERS('FILTER ctxsys.INSO_FILTER STORAGE
INTERMEDIASTORE LEXER INTERMEDIALEXER');
CREATE INDEX BLOBDOC_IDX
ERROR at line 1:
ORA-29855: error occurred in the execution of ODCIINDEXCREATE routine
ORA-20000: interMedia Text error:
ORA-28579: network error during callback from external procedure agent
ORA-06512: at "CTXSYS.DRUE", line 126
ORA-06512: at "CTXSYS.TEXTINDEXMETHODS", line 54
ORA-06512: at line 1

Additional information: error message found in CTXSYS.DR$INDEX_ERROR TABLE:
DRG-10595: ALTER INDEX BLOBDOC_IDX failed
ORA-28579: network error during callback from external procedure agent
Mike
<BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>Originally posted by Michael Hoekstra ([email protected]):
Hello,
I am having an odd problem when attempting to drop/create or alter my index after entering certain MS Word docs in my table.
Has anyone run into this? Does anyone have any insight as to which features in Word docs (e.g. macros, etc.) might cause this problem?
The errors are listed below (they also cause GPFs when extproc.exe runs). Thanks for your help.
Mike
alter index blobdoc_idx rebuild online parameters ( 'sync' )
ERROR at line 1:
ORA-29863: warning in the execution of ODCIINDEXCREATE routine
SQL> CREATE INDEX BLOBDOC_IDX
2 ON BLOBS(DOC_BLOB) INDEXTYPE IS CTXSYS.CONTEXT PARAMETERS('FILTER ctxsys.INSO_FILTER STORAGE
INTERMEDIASTORE LEXER INTERMEDIALEXER');
CREATE INDEX BLOBDOC_IDX
ERROR at line 1:
ORA-29855: error occurred in the execution of ODCIINDEXCREATE routine
ORA-20000: interMedia Text error:
ORA-28579: network error during callback from external procedure agent
ORA-06512: at "CTXSYS.DRUE", line 126
ORA-06512: at "CTXSYS.TEXTINDEXMETHODS", line 54
ORA-06512: at line 1
<HR></BLOCKQUOTE>
null

Do index rebuild in bussiness hours creates any problem?

hi friends
two node rac
version 10.2.0.4
windows-o/s
do index rebuild in bussiness hours creates any problem.i had still half an hour time for business hours.
out of 10 indexes still 2 indexes are left.please let me know your suggestions thanks.
thanks in advance
cheers :-)

Respond to what, exactly?
Oracle indexes do not need to be rebuilt as a general rule. There are some exceedingly rare cases where an occasional index may need to be rebuilt. But to have 10 indexes in a database that all need to be rebuilt would be exceptional. And your description doesn't seem to indicate any logical reason that any of your indexes need to be rebuilt. That leads me to strongly suspect that you are pointlessly rebuilding the indexes in the first place.
If you are going to pointlessly rebuild indexes (which I don't recommend), you should do it during system downtime windows when no one else is using the system. It would be better not to do them in the first place, but if you're going to waste cycles, at least waste nonproductive cycles.
Justin

Difference between "REBUILD ONLINE" and "REBUILD" while altering index

Hi Everyone,
Please go through this link.
[http://docs.oracle.com/cd/B28359_01/server.111/b28310/indexes004.htm#i1006864]
Now if Rebuilding online enables you to update base tables at the same time that you are rebuilding, then when the base table is getting updated while Rebuilding without online option?
Regards,
BS2012

Hi,
I believe it work like this way
rebuild without online option => table and index is locked in exclusive mode preventing any translations on the table.
With online index rebuild, transactions can still access the table and index.

Index Rebuild in Oracle 7

Hi DBA's,
DB Details: ORACLE 7 , Machine : P-III : VMWARE..
I am getting an error in prod like follows,
24-may-2011 04:24:33 am: start rebuilding the index on the table ...
alter index
ERROR at line 1:
ORA-01652: unable to extend temp segment by 168168 in tablespace SFX_INDEX
doubt:
why does the error say "extend temp segment" for the permanent index tablespace.
We have 3000MB Free space in Same tablespace & we have 2000MB free space in Temp also.But Still it is Giving error in "ORACLE 7 "
Any Idea...
Help me soon .

user11919409 wrote:
DB Details: ORACLE 7 , Machine : P-III : VMWARE..
I am getting an error in prod like follows,
24-may-2011 04:24:33 am: start rebuilding the index on the table ...
alter index
ERROR at line 1:
ORA-01652: unable to extend temp segment by 168168 in tablespace SFX_INDEX
doubt:
why does the error say "extend temp segment" for the permanent index tablespace. Because when you rebuild an index, the new index structure starts life as a temp segment (and so can be easily dropped in case of failure) and gets renamed and reassigned as the index segment once the index rebuild process is complete.
>
We have 3000MB Free space in Same tablespace & we have 2000MB free space in Temp also.But ; Still it is Giving error in "ORACLE 7 "
It's the free space in the SFX_INDEX tablespace that's the problem, you don't have 168168 free contiguous blocks within the tablespace necessary for the index (the actual amount of space this corresponds to is of course is dependent on your block size).
Cheers
Richard Foote
http://richardfoote.wordpress.com/

'alter index rebuild' paralellism problem

Similar Messages

Maybe you are looking for