Rebuilding indexes on a scheduled basis:

can you please help mefor this :
1)can you give me a sample schedualr program that rebuilds the indexes on the particular tables for every weekends.

909551 wrote:
I am having particualr tables where dml operations are performed in a very frequent manner and in with the huge no of rows i want to rebuid the indexes for these tables every once per week so that i want schedular program for rebuilding the indexes for this one i want sample schedular programSo what is the problem? Why do the indexes need to be rebuild?
Are the indexes dropped before the DML? And then rebuild? Does not sound like it.
Instead is sounds like you expect there is something wrong with the indexes after DML and then this needs to be corrected using an index rebuild. So what is wrong with the indexes after the DML?
How about reading this asktom thread on the topic?

Similar Messages

When to rebuild indexes

How can iddentify indexes that need to be rebuild?
Thanks

This is a question that comes up frequently and generally devolves into a flame war. I'm sure you can do a search and have threads to read for the next couple years.
The best presentation on the topic is Richard Foote's [Oracle Index Internals|http://richardfoote.files.wordpress.com/2007/12/index-internals-rebuilding-the-truth.pdf].
The summary though, is that most indexes never have to be rebuilt.
Occasionally, you may need to do a 1-time rebuild on an index if
- the index is on a monotonically increasing (or decreasing) column (i.e. a sequence or a date), AND
- you delete a substantial fraction but not all of the data below a particular value (i.e. you delete 90% of the rows inserted more than a year ago)
Extremely rarely, it may be beneficial to rebuild indexes on a schedule. Programmatically identifying the particular indexes that need to be rebuilt is probably not possible (there are various formulas floating around that are, to be kind, not particularly valid) if only because it requires information about the data that will be inserted in the future. If you have a window where no one is using the system (i.e. it is absolutely, totally inactive) and you have a well-tested rebuild script and you don't believe there is a risk that your rebuild script will fail to rebuild an index and cause problems, it generally doesn't hurt to rebuild an index (other than wasting a lot of CPU and IO to do so). If you reclaim space by rebuilding the index, though, it's not uncommon that you would cause some (generally small) performance decrease as your OLTP operations have to re-expand an index to its steady state size.
So generally, if you're asking the question, I'd argue that the answer is "functionally never". But read Richard's presentation for more information.
Justin

Scheduled job to rebuild indexes

Hi Gurus,
I need to create a DBMS job that will rebuild indexes of a DB schema and Re-compute statistics.
The job will run once a month, say First Sunday of the month.
Any ideas are welcome.
Thanks
Amitava.

Hello d96a...
Because I do not know the background I can only ask you whether you are really sure that you want to rebuild the indexes?
There are a lot of documents about the topic "Rebuilding Indexes"
An example : https://communities.bmc.com/docs/DOC-10072
An excerpt from this document:
Conclusion
There is only one sound argument for rebuilding an index:
Will the total cost of rebuilding the index be a reasonable price to pay for the resulting benefit to the system?
The answer to this question is frequently a resounding NO. In fact, sometimes the overall impact of rebuilding an active index will be detrimental to the system. However, there are still plenty of misconceptions about indexes that result in DBAs the world over wasting valuable time and effort rebuilding indexes unnecessarily.
I hope it helps you!

SCCM database Modified date doesn't change / rebuild indexes

Hi all,
I have 2 questions
1)
We have a month ago upgraded our SCCM environment from SCCM 2012 RTM -> SCCM 2012 SP1 (no CU), and we have upgraded SQL 2008 R2 (CU6) to SQL 2008 R2 SP2.
We have a SCCM 2012 primary site and an SCCM 2012 CAS site from both these sites its database file has not changed its modified date since the data of upgrade (SQL is installed on the same server so the database is local). However the WSUS database and the
reporting DB that exist on the same server updates its modified date.
SCCM is running and all status messages are OK. All component status's are updating and have correct dates based on when e.g. the last backup ran (that is at 6 pm every night) with no errors. To make a long story short, everything works
as it should. Deployments and advertisements and OSD arrive, collections get updated, no errors appear in the log files or in the component or site status, but the database on these servers (CAS and Primary) does not modify its date. SCCM backup of these servers
is running and the database file in that backup also contains the same modified date.
Anyone knows why this happens , or do we have an issue ?
2)
Maintenance task rebuild indexes
Is there a best practice according to the maintenance task rebuild indexes?
In our environment we have not enabled this maintenance task, both sites run for over one year.
Can we enable this task without disturbing or is it a better idea to enable this task in the weekend when there is less workload , and afterwards schedule this task once a week
regards and thx in advance
Johan

As stated “The time stamp will also change if the database files size are expanded as well when the database grow”
does that mean that after our upgrade a month ago the database has not grown with new data??
It depends. Data might have been added to the database (which it was fur sure with ConfigMgr), but the timestamp will only change if the file size was increased too. That has something to do with the initial and max file size settings in SQL and the autogrowth
settings.
Torsten Meringer | http://www.mssccmfaq.de

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]

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.

"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>?

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/

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/

Problem with replacement of index series, change of base year

Hi Experts!
I try to explain my problem in Real Estate.
In Italy from January 2011 the baseline (base year) national index of consumer prices for the entire community (NIC) and national consumer price index for families of workers and employees (CPI) moved from 1995 to 2010.
So, I have to change the base year of index in Rent Adjustment.
I think I have changed the base year from 1995 to 2010.
(Path: Real Estate>Rent Adjustment>Index>Replacement of index series, change of base year)
In table TIVAJINDXCON (previous was empty) now there is this record:
SERIESTO: 08000
BASEYEARTO: 1995
SERIESFROM: 08000
BASEYEARFROM: 2010
CHAINDATE: 31.12.2010
INDEXBASETO: 1,373
But with transaction FOA0 it seems that the rent adjustment still consider 1995 as base year instead of 2010.
I have to set the SAP application as to use 2010 as new base year instead of 1995.
Would you please forward me with any support.
Best regards,
Thank you.
Tania

My question has been answered by SAP.

How to rebuild index from different schema

Hi All,
I want to rebuild an Index of schema A from Schema B.
Is there any grant needs to be give to Schema B in order to rebuild index of Schema A?
Thanks,
Tarak

It is true what P. Forstmann said. However if you don't want to give the second user the ANY priviledge, then you can do a little workaround. Create a small procedure in Schema A that does the rebuild (maybe dynamically). Then grant execute rights on the procedure to Schema B.

Rebuilding indexes on a scheduled basis:

Similar Messages

Maybe you are looking for