Recommeded way to rebuild Indexes in EBS 11.5.10.2

What is the recommended way to rebuild all the possible indexes for better performance in EBS 11.5.10.2?
Is there any seeded script / concurrent program, that which could be made use of?

I have been using bde_rebuild.sql (available from Metalink) with pretty good success. It seems to work better doing it schema by schema rather than supplying % for schema name (gets hung up and never completes).
bde_rebuild.sql - Validates and rebuilds indexes occupying more space than needed
http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=182699.1
How to Rebuild All Indexes in a Database
http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=300327.1

Similar Messages

Easy way to "Rebuild indexes" ?

is there some command which can rebuild all indexes on the fly ?
or do i have delete each index, then recreate it using the same indexing options ?
the problem is : our mailserver (iplanet messaging) has quite often a fragmented index of the attributes mail in the PAB database. I'd now like to periodically rebuild this index, without manual user intervention

There is a db2index command, but it may be broken in iDS 5.1. I'm not sure if iDS has the db2index.pl command, but it may be broken as well.
There is an interface into the indexing subsystem via LDAP - cn=index,cn=tasks,cn=config - you basically create an entry under this entry (e.g. cn=indextask2309842) and specify the correct parameters as attributes and values of this entry. I think the attributes and values are documented in the docs. I think there may be a bug in this code but I'm not sure if Sun fixed it.

Rebuild indexes of all schema in EBS r12.

HI,
Is it possible to rebuilt all schema indexes in EBS r12?
If yes , then please tell us how?
I want ro rebuilt indexes due to very bad EBS performance?
thx

Rebuilding indexes is technically possible, but it typically does not help in fixing EBS (or database) performance issues. Pl post details of your OS, database and EBS versions, along with details of your architecture and what performance issues you are experiencing. There are many threads that have discussed performance issues and ways to troubleshoot. See Re: Disk and memory utilization is 100% on Oracle E-business Suite Application. as an example.
Knowing more details about your environment and its issues will help provide better answers.
HTH
Srini

"analyze index" vs "rebuild index"

Hi,
I don't undestand the difference between "analyze index" and "rebuild index".
I have a table where I do a lot of "insert" and "update" and "query", What is the best thing to do ??
thanks
Giordano

When you use dbms_stats.gather_schema_stats package with cascade=>true option, you are also collecting stats for the indexes, no need to collects stats separately using dbms_stats.gather_index_stats.Of course, but I refered to the rebuild index question. Therefore I only mentioned the GATHER_INDEX_STATS.
Auto_sample_size has many problems/bugs in 9iOk didn't know that - I'm using 10gR2.
But this discussion made me curious. So I tried something (10gR2):
CREATE TABLE BIG NOLOGGING AS
WITH GEN AS (
SELECT ROWNUM ID FROM ALL_OBJECTS WHERE ROWNUM <=10000)
SELECT V1.ID,RPAD('A',10) C FROM GEN V1,GEN V2
WHERE ROWNUM <=10000000;
SELECT COUNT(*) FROM BIG;
COUNT(*)
10000000
So I had a Table containing 10 Million rows. Now I indexed ID:
CREATE INDEX BIG_IDX ON BIG(ID)
I tested two different methods:
1.) GATHER_TABLE_STATS with estimate 10%
EXEC DBMS_STATS.GATHER_TABLE_STATS(TABNAME=>'BIG',OWNNAME=>'DIMITRI',CASCADE=>TRUE,ESTIMATE_PERCENT=>10);
It took about 6 seconds (I only set timing on in sqlplus, no 10046 trace) Now I checked the estimated values:
SELECT NUM_ROWS,SAMPLE_SIZE,ABS(10000000-NUM_ROWS)/100000 VARIANCE,'TABLE' OBJECT FROM USER_TABLES WHERE TABLE_NAME='BIG'
UNION ALL
SELECT NUM_ROWS,SAMPLE_SIZE,ABS(10000000-NUM_ROWS)/100000 VARIANCE,'INDEX' OBJECT FROM USER_INDEXES WHERE INDEX_NAME='BIG_IDX';
NUM_ROWS SAMPLE_SIZE VARIANCE OBJEC
9985220 998522 ,1478 TABLE
9996210 999621 ,0379 INDEX
2.) GATHER_TABLE_STATS with DBMS_STATS.AUTO_SAMPLE_SIZE
EXEC DBMS_STATS.DELETE_TABLE_STATS(OWNNAME=>'DIMITRI',TABNAME=>'BIG');
EXEC DBMS_STATS.GATHER_TABLE_STATS(TABNAME=>'BIG',OWNNAME=>'DIMITRI',CASCADE=>TRUE,ESTIMATE_PERCENT=>DBMS_STATS.AUTO_SAMPLE_SIZE);
It took about 1,5 seconds. Now the results:
NUM_ROWS SAMPLE_SIZE VARIANCE OBJEC
9826851 4715 1,73149 TABLE
10262432 561326 2,62432 INDEX
The estimate 10% was more exact - also a 1,7 and 2,6 percent variance is still ok. It's also very interesting, that using AUTO_SAMPLE_SIZE
causes oracle to execute a estimate 5% for the index and a estimate 0.5 for the table.
I tried again with a table containing only 1 Million records and oracle did an estimate with 100% for the index.
So for me I will continue using AUTO_SAMPLE_SIZE. Its very flexible, fast and accurate.
Dim
PS: Is there a way to format code like one can do in HTML using <code> or <pre>?

Q/s on rebuilding index

Hi All
in one of our applications we want to rebuild index which his craete as below, this is on 11G 11.2.0.3.0 Solaris 64bit
CREATE INDEX idx_id ON scott.branch(bank_id)
INDEXTYPE IS CTXSYS.CONTEXT PARAMETERS
('FILTER CTXSYS.NULL_FILTER SECTION GROUP CTXSYS.HTML_SECTION_GROUP');
Is rebuilding the index a reasonable option or will that be much slower than a sync ?
secondly is ctx_ddl package installed by default
thanks

hi,
you should ask this question to: Text for get answers faster.
by the way, if you installed Oracle Text (which is default on installation) ctx_ddl package is also comming too.

Multiple objects with same name when rebuilding index online

I am looking for advice on how to handle a race-condition in sql server, related to reading metadata while an online index rebuild is being performed.
The problem is as follows:
At some point we execute the following statement:
SELECT
obj.object_id AS id,
scm.name AS scm,
obj.name AS name,
obj.type AS type,
ds.name AS dataspace_name,
prop.value AS description,
part.data_compression_desc as compression_desc
FROM sys.objects AS obj
INNER JOIN sys.schemas AS scm ON obj.schema_id = scm.schema_id
INNER JOIN sys.indexes AS idx ON obj.object_id = idx.object_id AND idx.type IN (0,1)
INNER JOIN sys.data_spaces AS ds ON idx.data_space_id = ds.data_space_id
INNER JOIN (SELECT object_id, data_compression_desc FROM sys.partitions WHERE index_id IN (0,1) /*Heap, Clustered*/) AS part ON part.object_id = obj.object_id
LEFT OUTER JOIN sys.extended_properties AS prop ON obj.object_id = prop.major_id AND prop.minor_id = 0 AND prop.class = 1 AND prop.name = 'Description'
WHERE obj.type = 'U' OR obj.type = 'S'";
The statement returns some metadata for indexes (indices?), the purpose of wich is not the subject.
When executed while an online index rebuild is running, a race condition occurs: When the rebuilding enters the final phase, the new index, which have the same name, becomes visible and thus results in two rows with the same name (from sys.object). I am unaware
if this only occurs for clustered index (which is what we have observed).
We became aware of this behaviour, as we added the metadata to a .Net Dictionary using name as key, and received a duplicate key exception. We have, hoewever, not been able to reproduce the situation, due to the nature of the race condition, and we found very
little documentation on the subject.
What we would like to do now, is to differentiate between the two. We see two options:
1) We could just use the first of the rows and ignore the second. This solution would require that the metadata for both rows are identical.
2) We could discern the "real" index from the "rebuilding" index. This requires some kind of extension of the Where-part.
We have not been able to determine if the requirements for either option is present, as we havent found any documentation, nor have we been able to test for differences, as we cannot reproduce the situation.
We would also like some way of reproducing the situation, so ideas as to how to do that is welcome.
Can anyone direct me to relevant documentation, or alternate solutions.
HRP

1. Use the index with the lower fragmentation to identify the newly rebuilt index (as it almost always will have lower fragmentation)
2. To reproduce, block the online index rebuild process by trying to alter the table's definition in a transaction (and don't commit, which will place schema lock on the table)
Satish Kartan http://www.sqlfood.com/

REBUILD INDEXES IN OFFLINE MODE

hi all
we got SQL 2012 enterprise edition on our production server, As our frag levels are more we are planning to do defragmentation but when we scheduled rebuild indexs last time this ran for 7-8hrs and drive spaces decreased rapidly so we have killed
the process in the middle. I heard that offline indexes will be the better solution as it will be done quickly and keeping in simple recovery prevents the log file increase. could some one tell me how to schedule maintenance plan for rebuild with
offline mode in sql 2012 enterprise edtion or some other efficient way.
proposed plan for rebuilding->take full backup for DB
change recovery model to simple
configure m plan with offline mode
change to full after the plan finished
run dbcc update usage
take full backup after all done
could you please help me in this by letting me know is this correct way to do and how to configure plan which rebuils in offline mode
with regards,
ram.

->setting recovery model from full to simple is to save the disk space, as log will not increase
->As of now we are not taking any T-log backup due to some internal issues so there will be no issue with log chain break
Frankly, I get scared. OK, I don't know what your system is doing, and what your SLA is saying, but someone is paying a lot of money to use Enterprise Edition. But you are not taking log backups? I can only hope that your system does not have a disaster,
because if you have and you are not able to restart the business, you need to be in a country with very high labour security to not lose your job.
->won't the DB files size increase wen we do this bulk logged
Obviously, if you are not taking log backups, the log file file will keep growing, but it will grow less in bulk-logged recovery. On the other hand, the log backups - had you taken any - will be larger.
Please correct me If iam wrong, could you please tell me the procedure for REBUILD IN OFFLINE MODE through maintenance plan.
If you are talking about the maintenance plans you see in SSMS, I only have one advice: don't use them. Instead go to
http://ola.hallengren.com
for an enterprise solution.
Erland Sommarskog, SQL Server MVP, [email protected]

Run Rebuild Index Task daily on database but about 77 tables still highly fragmented over 80% !!!

Hello everyone
On our particular database server, we run the Rebuild Index Task (Using classic Maintenance Plan Designer) every night. Running the script below, I saw that about 77 tables had an avg_fragmentation_in_percentage between 80% and 99% !!
SELECT OBJECT_NAME(ind.OBJECT_ID) AS TableName,
ind.name AS IndexName, indexstats.index_type_desc AS IndexType,
indexstats.avg_fragmentation_in_percent
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, NULL) indexstats
INNER JOIN sys.indexes ind
ON ind.object_id = indexstats.object_id
AND ind.index_id = indexstats.index_id
WHERE indexstats.avg_fragmentation_in_percent > 30--You can specify the percent as you want
ORDER BY indexstats.avg_fragmentation_in_percent DESC
I dont understand why these tables are highly fragmented after a daily index rebuild! Unless the users are doing heavy inserts/updates/deletes during the day.
Anyone has an idea of the possible causes of these results??
Thank you all in advance

Hallo Efyuzegeekgurl,
this is a normal behaviour when your table is only a small one. The reason for that behaviour is the following:
The dmv sys.dm_db_index_physical_stats counts each page which is not located at the very next one of the same table as a "fragment". If the first data page is 1700 and the second one is located on 1705 SQL server will count it as a fragment.
The basic allocation algorithm of Microsoft SQL Server is that new data pages will be created in "mixed extents". An extent is a contigious line of 8 consecutive data pages. This is for historical reasons when storage was expensive and data should
use as much as possible of allocated storage.
If a new table will be created the very first 8 pages are not located one after the other but "could" be located on different extents. If your table has only 9 data pages than 8 pages will count as "fragmented" because of their non consecutive
allocation. After 8 pages have been allocated Microsoft SQL Server will ALWAYS use a full extent for the next 8 pages (and so on!).
To understand this behaviour use the following example which creates a table with a record length of 8K. The next command will create 10 records (which means 10 data pages).
CREATE TABLE dbo.foo
Id INT NOT NULL IDENTITY (1, 1),
c1 CHAR(8000) NOT NULL DEFAULT ('filler')
GO
SET NOCOUNT ON;
GO
INSERT INTO dbo.foo DEFAULT VALUES
GO 10
When you check the page allocation you'll find the first 8 data pages not in a consecutive row but "scrambled" into different pages:
SELECT database_id,
index_id,
partition_id,
allocation_unit_type_desc,
extent_page_id,
allocated_page_page_id,
is_mixed_page_allocation,
page_type_desc
FROM sys.dm_db_database_page_allocations
DB_ID(),
OBJECT_ID('dbo.foo', 'U'),
0,
NULL,
'DETAILED'
) AS DDDPA
WHERE
DDDPA.is_allocated = 1
ORDER BY
DDDPA.is_iam_page DESC,
DDDPA.page_level DESC;
GO
You will see that the first 8 pages are located in a MIXED extent. Although the pages are in a consecutive order in the extent 221112 it is not guaranteed!
You can see from the very first three records that they are not in a consecutive row stored.
Now the fragmentation of the data seems to be quite high because we have 4 breaks in the rows. If we compare this value to the "fragmentation in sys.dm_db_index_physical_stats we will see at least the same result:
SELECT index_type_desc,
alloc_unit_type_desc,
DDIPS.avg_fragmentation_in_percent,
DDIPS.fragment_count,
DDIPS.page_count,
avg_page_space_used_in_percent
FROM sys.dm_db_index_physical_stats
DB_ID(),
OBJECT_ID('dbo.foo', 'U'),
NULL,
NULL,
'DETAILED'
) AS DDIPS;
So - just from my point of view - don't count only to the fragmentation in percent because if the table is to small it will ALWAYS be over 30%. Take more into account the density of the pages and - as all others have mentioned - the number of pages of the
index.
I would consider indexes with more or equal to 1.000 pages.
Another tip: Forget about the f... maintenance plans. These "plans" are not worth the time and money because you cannot control it in a more precise way. Have a look to the solution of Ola Hallengren and implement his solution - a great master
piece of index maintenance:
http://ola.hallengren.com
All the best to the community :)
MCM - SQL Server 2008
MCSE - SQL Server 2012
db Berater GmbH
SQL Server Blog (german only)

Rebuilding indexes after importing...

My coworker and I are discussing whether it is necessary, or advised, to rebuild indexes after an import of the schema.
My thinking is that the index data is put into fresh blocks thereby creating a very flat index tree without any fragmentation.
But my coworker suspects that perhaps the blocks are built exactly as they existed in the source database.
I could understand, perhaps, if the refresh were done by using RMAN which copies block by block, but even then I'm not sure.
Can you help us understand this please?
Thanks.
Ed

Hi,
Normally, the indexes are build and statistics upfated after the import automatically. You do not ned to generate the statistics after the import until unless you are running very old version of database.
Regards
[sfa-dev1:oracle:10.2.0] $ imp help=Y
Import: Release 10.2.0.4.0 - Production on Fri Nov 13 11:49:56 2009
Copyright (c) 1982, 2007, Oracle. All rights reserved.
You can let Import prompt you for parameters by entering the IMP
command followed by your username/password:
Example: IMP SCOTT/TIGER
Or, you can control how Import runs by entering the IMP command followed
by various arguments. To specify parameters, you use keywords:
Format: IMP KEYWORD=value or KEYWORD=(value1,value2,...,valueN)
Example: IMP SCOTT/TIGER IGNORE=Y TABLES=(EMP,DEPT) FULL=N
or TABLES=(T1:P1,T1:P2), if T1 is partitioned table
USERID must be the first parameter on the command line.
Keyword Description (Default) Keyword Description (Default)
USERID username/password FULL import entire file (N)
BUFFER size of data buffer FROMUSER list of owner usernames
FILE input files (EXPDAT.DMP) TOUSER list of usernames
SHOW just list file contents (N) TABLES list of table names
IGNORE ignore create errors (N) RECORDLENGTH length of IO record
GRANTS import grants (Y) INCTYPE incremental import type
INDEXES import indexes (Y) COMMIT commit array insert (N)
ROWS import data rows (Y) PARFILE parameter filename
LOG log file of screen output CONSTRAINTS import constraints (Y)
DESTROY overwrite tablespace data file (N)
INDEXFILE write table/index info to specified file
SKIP_UNUSABLE_INDEXES skip maintenance of unusable indexes (N)
FEEDBACK display progress every x rows(0)
TOID_NOVALIDATE skip validation of specified type ids
FILESIZE maximum size of each dump file
STATISTICS import precomputed statistics (always) On 10gR2
Edited by: skvaish1 on Nov 13, 2009 11:50 AM

What is the difference between the drop and create the index and rebuild index ?

Hi All,
what is the difference between drop and create index & rebuild index ? i think both are same...Please clarify if both are same or any difference...
Thanks in Advance,
rup

Both are same. Rebuilding an index drops and re-creates the index.
Ref:
SSMS - https://technet.microsoft.com/en-us/library/ms187874(v=sql.105).aspx
TSQL - https://msdn.microsoft.com/en-us/library/ms188388.aspx
I would suggest you to also refer one of the best index maintenance script as below:
https://ola.hallengren.com/sql-server-index-and-statistics-maintenance.html

REBUILD INDEX vs DROP/CREATE INDEX

Hi there,
Does anyone has already got some performance degradation after REBUILD INDEXes ? Would it be better to perform DROP/CREATE INDEX instead ?
Thank you very much for anu reply.
Best regards,
Helena

Hi,
>>so is it then better to DROP/CREATE them ?
Well, In fact I learned that when you rebuild an index, Oracle creates a new index from the old index and does not perform sorting while building the new index, which results in performance enhancement. In this case, depending of the size of your data it's necessary sufficient space on a tablespace for storing the old as well as the new index (while creating the new index). Other advantage, is that Oracle can use the old index for answering queries while it builds the new index too using [alter index <index_name> rebuild online].
Cheers

Rebuild Index VS Drop and Rebuild?

Hey all,
I am currently redesigning a weekly process (weekly coz we pre determined the rate of index fragmentation) for specific indexes that get massive updates. The old process has proved to be able to fix and maintain reports performance.
In this process we rebuild specific indexes using the below command:
Alter index index_name rebuild online;
This command takes around 10 min for selected indexes.
Testing the below took 2 min for 6 or 7 indexes.
Drop Index Index_Name;
Create Index Index_Name on Table_name (Col1, col, ..);
I know that indexes might not be used, and the application performance would be degraded with stale or non-existent stats. But our production and all our test DBs have procedures that daily gather stats on them.
I tested the below script to make sure that execution plan does not change:
SELECT ProductID, ProductName, MfrID FROM PRODUCT WHERE MFRID = 'Mfr1';
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
| 0 | SELECT STATEMENT | | 37 | 3737 | 13 (0)|
| 1 | TABLE ACCESS BY INDEX ROWID| PRODUCT | 37 | 3737 | 13 (0)|
| 2 | INDEX RANGE SCAN | PRODUCT_X1 | 37 | | 3 (0)|
dropping PRODUCT_X1 and recreating it only changed the cost to 12.
Gathering the stats again took the cost to 14.
No performance issues were faced and index was still used.
My question is: Is there any oracle recommendation that requires rebuilding the index instead of dropping and recreating it?
Is there any side effect to my approach that I did not consider?
Thank you

Charlov wrote:
I am currently redesigning a weekly process (weekly coz we pre determined the rate of index fragmentation)Nice. Not only have you defined and located index fragmentation but have also measured the rate at which it occurs.
Could you please share your definition of index fragmentation, how you detect it, and how you measure the rate of change of this fragmentation.
I am curious about all this since it can be repeatedly shown that Oracle btree indexes are never fragmented.
http://richardfoote.files.wordpress.com/2007/12/index-internals-rebuilding-the-truth-ii.pdf
The old process has proved to be able to fix and maintain reports performance.Great so you have traces and run time statistics from before and after the rebuild that highlight this mysterious fragmentation and show how the fragmentation caused the report to be slow, details what effects the rebuild had that caused the reports to perform better.
Please share them as these would be an interesting discussion point since no one has been able to show previously how an index rebuild caused a report to run faster or even show the fragmentation that caused it to be slow in the first place.
I mean it would be a pity if the report was just slow because of an inefficient plan and compressing an index or two that probably shouldn't be used in teh first place appears to temporarily speed it up. Could you imagine rebuilding indexes every week, because some developer put the wrong hint in a query? That would be pretty funny.

Rebuild index vs Analyze index

Hi All,
I am realy confused about rebuilding index versus Analyzing index.
Could anyone plz help me out what is the diffrence between them.
How to Perform analyze of indexes and Rebuld of Indexes for both Oracle 9i and 10g databases.
Thanks a lot

CKPT wrote:
You can see the posts of experts by jonathan
I am realy confused about rebuilding index versus Analyzing index. tell us you are getting confused why we need to ananlyze before reubild index? if so
if index analyzed the whole statistics of index will be gathered.... then you can check what is the hieght of the index.. according to the height of the index you need to take step is index need to be really rebuild or not...
lets see furhter posts from experts if not clear..Thanks OK, so you determine the height of an index is (say) 4. What then ? If you decide to rebuild the index and the index remains at a height of 4, what now ? Was it really worth doing and do you rebuild it again as the index height is still 4 and still within your index rebuild criteria ? At what point do you decide that rebuilding the index just because it has a height of 4 is a total waste of time in this case ?
OK, so you determine the index only has a height of (say) 3, does that mean you don't rebuild the index ? But what if by rebuilding the index, the index now reduces to a height of just 1 ? Perhaps not rebuilding the index even though it has just a height of 3 and doesn't currently meet your index rebuild criteria is totally the wrong thing to do and a rebuild would result in a significantly leaner and more efficient index structure ?
So what if it's pointless rebuilding an index with a height of 4 but another index with a height of 3 is a perfect candidate to be rebuilt ?
Perhaps knowing just the height of an index leaves one totally clueless after all as to whether the index might benefit from an index rebuild ...
Cheers
Richard Foote
http://richardfoote.wordpress.com/

I am trying to rebuild my iPhoto library and noticed my backup contains aliases (pointers?) and not the actual file. What's the best way to rebuild my library?

I am trying to rebuild my iPhoto library and noticed my backup contains aliases (pointers?) and not the actual file. What's the best way to rebuild my library?
Facts:
In moving to a new iMac, I copied the iPhoto library to an external HDD assuming that I would point the new iMac to the backed up iPhoto Library
All worked fine when I pointed the new library but noticed that some folders contained aliases and not the original file. So when I attempt to open that photo it can't find it because the alias is pointing to another drive.
I do have all original photos from a couple of external HDDs. In the folders titled, "Originals" (from older versions of iPhoto) and "Masters" (from current iPhoto)
I'm thinking I can create a new folder and drop the original files and make that my new iPhoto library. Is there a better way to rebuild my library? I do not want to create any future aliases.
Thanks in advance for any help!

do you have a strongly recommended default "managed" library (the iPhoto preference to "copy imported items to the iPhoto library is in its checked state) or a referenced library - you have unchecked that option?
It sounds like you have a referenced library and are now experiancing one of the very siginificant drawbacks of a referenced library and one of the many reasons they are strongly not recommended
Also note that iPhoto '11 may use alises in the originals folder as part of the upgrade
It is important that we understand exactly what you have and what is not sorking - what error messages you are getting
You must NEVER make any changes of any sort to the structure of content of the iPhoto library - there are no user servicable parts in it -- and you can not rebuild yoru librtary - only iPhoto ir iPhoto Library Manager - http://www.fatcatsoftware.com/iplm/ - can rebuild a library unless you are a SQL programmer and understand the structure that iPhoto uses
LN

If meta data LUN is totaly destroied , is there any way to rebuild the data from the video LUN

If meta data LUN is totaly destroied , is there any way to rebuild the data from the video LUN ????

What happened to your metadata? Are you sure the metadata is gone?
In theory, file carving could be attempted on the data LUNs, but you would need a tool that understands how Xsan lays out data across LUNs in a stripe group and hope your fragmentation isn't too bad. I doubt such a tool exists, but if one does it almost certainly is not publicly available. You should probably contact a data recovery service with experience recovering data from Xsan. Do that before you do anything else if this data is really important.

Recommeded way to rebuild Indexes in EBS 11.5.10.2

Similar Messages

Maybe you are looking for