Index Maintenance

Hi,
I am having a table with 47 Columns. The total no of records in the tables is around 10,00,000 and the avagrage growth of the table is 10,000 transactions per day. I need around 10 indexes on this table for various purposes including primary key.
What is your suggestion. Whether it will affect the performance?
Clarify.
Regards
Sugirtha

Our CRM database has very wide tables and needs a similar number of indexes but we drop the indexes load the data and then rebuild the indexes. Only doing this once every few weeks with fresh customer data e.t.c. Without knowing any detail about the app 10 may be fine. You can use the monitor facility in 10G to find out if some indexes are "unused".
Kind regards Bill
Re: Finding Unused Indexes Edited by: triggb on Sep 16, 2008 9:01 AM

Similar Messages

Recommended frequency for running Rebuild Indexes Maintenance task on CAS

How frequently shall we run "Rebuild Index" maintenance task on CAS?

You should also consider using an actual SQL index rebuild script instead of the built-in maintenance task as described at http://stevethompsonmvp.wordpress.com/2013/05/07/optimizing-configmgr-databases/
Jason | http://blog.configmgrftw.com

Enable Re-Indexing Maintenance Task for SCCM 2012 R2 Database?

If I use the
MaintenanceSolution.sql script provided by Ola Hallengren here:
http://ola.hallengren.com/sql-server-index-and-statistics-maintenance.html
and then use this SQL script weekly to rebuild the SCCM 2012 R2 indexes:
EXECUTE dbo.IndexOptimize
@Databases = 'USER_DATABASES',
@FragmentationLow = NULL,
@FragmentationMedium = 'INDEX_REORGANIZE,INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
@FragmentationHigh = 'INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
@FragmentationLevel1 = 5,
@FragmentationLevel2 = 30,
@UpdateStatistics = 'ALL',
@OnlyModifiedStatistics = 'Y'
Then do I still need to enable the built-in database re-indexing maintenance task in the SCCM 2012 R2 console?
Thanks

In the Channel9 video, the statement is made that the built in Rebuild Indexes "maintenance task does not always work and that it is kind of broken, but it works sometimes and not always." Can anyone provide further
details regarding the state of the Rebuild Indexes
maintenance task? Why does it only sometimes work? Should it be used at all? Has it been fixed with a CU since the video came out? Are there plans to fix it?
I need to defrag my database, and I am trying to determine the best approach.
Thanks!
-Tony

11g interval partitioning and global index maintenance

hi gurus,
in 11g interval partitioning system can automatically manage the creation of new partitions based on data.
in this case do we need to manage global indexes?
in earlier versions, we have to update global indexes whenever there is a partition maintenance operation.
please suggest.
thanks,
charles

user570138 wrote:
in earlier versions, we have to update global indexes whenever there is a partition maintenance operation.In 10gR2 you don't need to update/rebuild a global index after adding a partition to the base table.
So it should be the same when using interval partitioning.
Regards
Maurice

SQL*Loader Index Maintenance

Hi all,
we are loading data from SQL*Loader 9.2.0.3 into Database 11.2.0.3 with direct path load. During Load some Indexes are in state unusable. Acctually I thought that SQL*Loader would also maintain indexes when loading with direct path. But state in dba_indexes is UNUSABLE. Is that the expected behaivior? I couldnt find anything like that in the documentation. Just that it could happen after a successfully/failed load (unique constraint violated etc)...
Thanks in advance

No, no referential constraints on that table... but it's not the expected behavior that Oracle sets the index to unusable and "rebuilds" it at the end of a load, isn't it?
Thanks

Index maintenance at target

When data replication happens at the target database (both source & target databases are Oracle) via GoldenGate for a specific table, will the corresponding Index table at the target also get updated ?
Is there a requirement that a similar index should also exist in the source table to achieve this ?

GoldenGate uses standard DML operations to apply the data on the target system. Since it uses standard DML (via OCI) any indexes that exist on the target system are automatically updated by Oracle.
You can have a totally different indexing scheme on the target than you do on the source. While creating a live reporting environment many customers add additional indexes on the target to help reports run faster, since OLTP performance is no longer a consideration.
You can even have different keys on the source and target. In this case, there is some manual work, and you'll need to specify those keys in the parameter files using the KEYCOLS parameter.

TFS 2013 Index Maintenance

What job *exactly* controls reindexing on the TFS_DefaultCollection DB? I want to verify that this job is functioning correctly. In the past week I found a table with 1.1M rows that was 40% fragmented and want to verify that it's running properly. I
have read that in the past this was controled via a SQL job and also executed via the Visual Studio Team Foundation Background Job Agent.

Thx John,
I will contact MS for more information on forcing execution of this jobs. Looks like it's not running in our ENV. I confirmed by looking in the Job Definition table that other jobs show up as executing, but not this one.
SELECT *
FROM [Tfs_Configuration].[dbo].[tbl_JobDefinition] AS JobDefn with (nolock)
LEFT JOIN [Tfs_Configuration].[dbo].[tbl_JobHistory] AS JobHist
ON JobDefn.[JobID] = JobHist.[JobId]
WHERE JobDefn.[JobID] = '5C562C02-C8DB-464B-A1B5-54CE96FEC5E1'
PartitionId JobId
JobName ExtensionName
Data EnabledState
Flags LastExecutionTime
PriorityClass HistoryId
JobSource JobId
QueueTime StartTime
EndTime AgentId
Result ResultMessage
QueuedReasons QueueFlags
Priority
1 5C562C02-C8DB-464B-A1B5-54CE96FEC5E1
Optimize Databases Microsoft.TeamFoundation.Warehouse.OptimizeDatabases
<Data>JobType=b6daf560-532d-416f-ba0a-402bef515832;JobCategories=WarehouseMaintenance;</Data>
0 0
NULL 3
NULL NULL
NULL NULL
NULL NULL
NULL NULL
NULL NULL
NULL NULL

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

Transactional replication very slow with indexes on Subscriber table

I have setup Transactional Replication for one of our databases where one table with about 5mln records is replicated to a Subsriber database. With every replication about 500-600.000 changed records are send to the Subscriber.
Since one month I see very strange behaviour when I add about 10 indexes to the Subscriber table. As soon as I have added the indexes replication speed becomes extremely slow (almost 3 hours for 600k records). As soon as I remove the indexes the replication
is again very fast, about 3 minutes for the same amount of records.
I've searched a lot on the internet to solve this issue but can't find any explaination for this strange behaviour after adding the indexes. As far as I know it doesn't have to be a problem to add indexes to a Subscriber table, and it hasn't been before on
another replication configuration we use.
Some information from the Replication Log:
With indexes on the Subscriber table
Total Run Time (ms) : 9589938 Total Work Time : 9586782
Total Num Trans : 3 Num Trans/Sec : 0.00
Total Num Cmds : 616245 Num Cmds/Sec : 64.28
Total Idle Time : 0
Writer Thread Stats
Total Number of Retries : 0
Time Spent on Exec : 9580752
Time Spent on Commits (ms): 2687 Commits/Sec : 0.00
Time to Apply Cmds (ms) : 9586782 Cmds/Sec : 64.28
Time Cmd Queue Empty (ms) : 5499 Empty Q Waits > 10ms: 172
Total Time Request Blk(ms): 5499
P2P Work Time (ms) : 0 P2P Cmds Skipped : 0
Reader Thread Stats
Calls to Retrieve Cmds : 2
Time to Retrieve Cmds (ms): 10378 Cmds/Sec : 59379.94
Time Cmd Queue Full (ms) : 9577919 Full Q Waits > 10ms : 6072
Without indexes on the Subscriber table
Total Run Time (ms) : 89282 Total Work Time : 88891
Total Num Trans : 3 Num Trans/Sec : 0.03
Total Num Cmds : 437324 Num Cmds/Sec : 4919.78
Total Idle Time : 0
Writer Thread Stats
Total Number of Retries : 0
Time Spent on Exec : 86298
Time Spent on Commits (ms): 282 Commits/Sec : 0.03
Time to Apply Cmds (ms) : 88891 Cmds/Sec : 4919.78
Time Cmd Queue Empty (ms) : 1827 Empty Q Waits > 10ms: 113
Total Time Request Blk(ms): 1827
P2P Work Time (ms) : 0 P2P Cmds Skipped : 0
Reader Thread Stats
Calls to Retrieve Cmds : 2
Time to Retrieve Cmds (ms): 2812 Cmds/Sec : 155520.63
Time Cmd Queue Full (ms) : 86032 Full Q Waits > 10ms : 4026
Can someone please help me with this issue? Any ideas?
Pim

Hi Megens:
Insert statement might be slow with not only indexes and few others things too
0) SQL DB Blocking during inserts
1) If any insert triggers are existed
2) Constraints - if any
3) Index fragmentation
4) Page splits / fill factor
Without indexes inserts will be fast because, each time when new row going to insert to the table, SQL Server will do
1) it will check for the room, if no room page splits will happen and record will placed at right place
2) Once the record updated all the index should be update
3) all these extra update work will cause can make insert statement bit slow
Its better to have index maintenance jobs frequently to avoid fragmentation.
If every thing is clear on SQL Server Side, you need look up on DISK IO, N/W Latency between the servers and so on
Thanks,
Thanks, Satish Kumar. Please mark as this post as answered if my anser helps you to resolves your issue :)

Using UNUSABLE on Unique Index gives "initially in unusable state" error

I am doing the following:
1. Truncate table
2 Alter PK Index Disable
2. Alter Unique Index Unusable
3. Insert /*+ APPEND NOLOGGING*/ into my table
My problem is, I get an "ORA-26026: unique index ... initially in unusable state" error when I try to do the Insert. If I make the Unique index non-unique it isn't a problem. If I drop the index and recreate it its not a problem - so uniqueness doesn't appear to be the issue. Can you not use UNUSABLE with a Unique index, I couldn't find any reference to this in the 10g docs.
I am using 10.1.0.4.
Thanks
Richard

26026, 0000, "unique index %s.%s initially in unusable state"
//* Cause: A unique index is in IU state (a unique index cannot have
//* index maintenance skipped via SKIP_UNUSABLE_INDEXES).
//* Action: Either rebuild the index or index partition, or use
//* SKIP_INDEX_MAINTENANCE if the client is SQL*Loader.

Oracle Table Indexes

Hello.
I'm in the process of putting some indexes on tables for performance improvement of queries run.
eg the foll query -
SELECT MPH_ENTITY_ID, MPH_PRICE_DT, MPH_STCK_EXCHNG_ID, BPT_BP_SHRT_NM, MPH_SEC_ID, SEC_SEC_NM, NMS_SEC_NUM, MPH_PRICE_TYP, MPH_MKT_PRC, MPH_VENDOR, MPH_PRICE_TIME, MPH_EXCHNG_RATE, MPH_DENOM_UNIT, MPH_LOCL_CNC_EQVU, MPH_INDCTV_PRC_IND, MPH_VLM_TRDD, MPH_MRKT_CPTL, MPH_MKT_PRICE_HSTRY_VER, BPT_BSNS_PRTNR_VER, SEC_SEC_MASTER_VER FROM MPH_MKT_PRICE_HSTRY left outer join NMS_NUM_SCHEME on NMS_SEC_ID=MPH_SEC_ID AND NMS_NUM_SCHM='CUSIP',BPT_BSNS_PRTNR,SEC_SEC_MASTER WHERE MPH_ENTITY_ID=BPT_ENTITY_ID AND MPH_STCK_EXCHNG_ID=BPT_BP_ID AND MPH_SEC_ID=SEC_SEC_ID ORDER BY MPH_SEC_ID DESC
The Explain plan in PL/SQL developer shows "Table Access Full" scan for 2 tables - BPT_BSNS_PRTNR AND MPH_MKT_PRICE_HSTRY.
I created the foll 2 indexes and now the explain plan shows "index fast full" scan on these tables -
1) create index mph_3 on mph_mkt_price_hstry(MPH_ENTITY_ID, MPH_PRICE_DT, MPH_STCK_EXCHNG_ID, MPH_SEC_ID, MPH_PRICE_TYP, MPH_MKT_PRC, MPH_VENDOR, MPH_PRICE_TIME, MPH_EXCHNG_RATE, MPH_DENOM_UNIT, MPH_LOCL_CNC_EQVU, MPH_INDCTV_PRC_IND, MPH_VLM_TRDD, MPH_MRKT_CPTL, MPH_MKT_PRICE_HSTRY_VER);
2) create index BPT_8 on bpt_bsns_prtnr(BPT_BP_SHRT_NM,BPT_BSNS_PRTNR_VER,BPT_ENTITY_ID,BPT_BP_ID);
My question here is that I have included columns in the select clause also in the indexes and the scan type has improved from table access full to index fast full scan. Is this correct ? Should select columns be also a part of indexes ? My take was that indexes contain columns in "where" clause or columns where joins are implemented and not select columns.
Please suggest.

An Index that includes all the columns of the SELECT clause with those of the WHERE clause is a "skinny table".
Using such an Index avoids accesses to the table entirely.
There are situations where the DBA or Designer may choose to create such an Index.
Downsides ?*
If there are too many columns in the Index, the Index itself may become too large. When the index is too large for Oracle to be able to cache blocks, Oracle may have to undertake multiple single block read calls to the OS if accessing many rows. This can make the index counter-productive.
Index maintenance overheads increase -- the probability that the index also has to be updated with every UPDATE statement on the table increases. Also, every INSERT and DELETE makes that much more effort updating the Index Leaf Blocks (ie the size of the update to the Index is larger, the Index Key being larger).
Some queries might be executed using Skip Scan Search of the index when, properly, it might have made more sense to put those query columns in a seperate index.

In what way can an index go in invalid state????????

I did a lot of activity in my database and i found one of my index is in invalid state...i got an error
......Error occured is ORA-01502: index 'MUMBAI.SYS_C0013323' or partition of such index is in unusable state......
Can anybody tell me what activity (or set of activies) can lead to invalid state of Index????/
How to check if any other index is is Invalid state????????
Thanx in Advance
Gagan

Hello,
Following are some reason for index to be marked UNUSED;
Operations like Import Partition or conventional path SQL*Loader
that offer an option to bypass local index maintenance. When the
Import is complete, the affected local index partitions are marked
IU.
Partition maintenance operations like ALTER TABLE MOVE PARTITION
that change rowids. These operations mark the affected local index
partition and all global index partitions IU.
Partition maintenance operations like ALTER TABLE SPLIT PARTITION
that modify the partition definition of local indexes but do not
automatically rebuild the index data to match the new definitions.
These operations mark the affected local index partitions IU. ALTER
TABLE SPLIT PARTITION also marks all global index partitions IU
because it results in changes to rowids.
Index maintenance operations like ALTER INDEX SPLIT PARTITION that
modify the partitioning definition of the index but do not
automatically rebuild the affected partitions. These operations
mark the affected index partitions IU. However, if you split a
USABLE partition of a global index, resulting partitions are created
USABLE. If the partition that was split was marked IU, then so are
the partitions resulting from the split. Note that dropping a
partition of a global index that is either IU or is not empty causes
the next partition of the index to become IU.
Above points are mentioned at Metalink.
Hope that this will help you.....

Local Bitmap Index Confusions

Hi,
I am using Oracle 10.2.0.3.0 on Solaris 5.10.
I have a range based partition table with 60 partitions. This is a fact table. I have to load 60 days data in this table. I have created a partition for each day and the partition key is the date column. I created the table with partition, but didn't create the local bitmap index on the partition key vdate, because as far as I know oracle makes the local bitmap index unusable before the insert and then we have to rebuild it after the load. Is that right?
So the better strategy is to first load the data in the partition and then create a local bitmap index on that partition, is that right?
For instance, in future, some rows get inserted in an existing partition where the local bitmap index is present, so then I should once again rebuild the index on that partition, because in case of insert Oracle would have disabled it?
In this table there is another column vactivity, which is a foreign key from a dimension. Many queries use this column in there where clause. I would also like to create a bitmap index on this column? On this non partitioned key column, the local bitmap index should be created. Is that right?
Please also suggest as which is more faster, rebuilding a local bitmap index after rendering it unusable, or dropping and recreating it?
Thanks and best regards

The more I know, the more I know that how little I know. Thanks Jonathan for a very insightful answer. Please clarify some points and thanks for your valuable feedback.
Jonathan Lewis wrote:
Fahd Mirza wrote:
Hi,
I am using Oracle 10.2.0.3.0 on Solaris 5.10.
I have a range based partition table with 60 partitions. This is a fact table. I have to load 60 days data in this table. I have created a partition for each day and the partition key is the date column. I created the table with partition, but didn't create the local bitmap index on the partition key vdate, because as far as I know oracle makes the local bitmap index unusable before the insert and then we have to rebuild it after the load. Is that right?
That may depend on the software you use to load the data, it's not a necessity from the perspective of the database.I am using Oracle Warehouse Builder to load the data into the database.
>
So the better strategy is to first load the data in the partition and then create a local bitmap index on that partition, is that right?
Depends on the tools, and whether there is data in the table already - but Oracle will optimise index maintenance for bulk inserts in a way which means that it isn't necessary to worry about dropping/recreating if the index already exists and the table is empty.There is no data in the partitions prior to loading.
You may find that with one index it's more efficient to create the index with a lot of free space (51%, say) and leave it at that while another index works better if you mark unusable and rebuild.
Would you please elaborate on this point?
>
>>
In this table there is another column vactivity, which is a foreign key from a dimension. Many queries use this column in there where clause. I would also like to create a bitmap index on this column? On this non partitioned key column, the local bitmap index should be created. Is that right?
Your question raise more questions:
a) Does this mean you are only going to have a maximum of two bitmap indexes on this fact table with 60 million rows ? That doesn't sound like it's enough indexes.No, I will create local bitmap indexes on other columns too, which are likely to be used in the adhoc queries.
b) Are you hoping that the vactivity bitmap index will protect you against foreign key locking ? It won't. This (in part) is why people tend to set FK's to disable, novalidate, rely in data warehouses, they want bitmap indexes not btree indexesActually I haven't created the FK constraint.
d) Going back to the bitmap index on the date - is this column storing values that are date-only, or is it storing "date with time". If it's date-only then you've only got one date per partition and the index is a waste of space and processing overhead.The datatype of the column vdate is number. Actually it is refering to the pk of time dimension, in which we have preloaded the dates for the next ten years. Would the index be a total waste on this column?
>
>
Please also suggest as which is more faster, rebuilding a local bitmap index after rendering it unusable, or dropping and recreating it?
Here is the table. I have omitted many partitions for the sake of brevity:
CREATE TABLE CDR
CLNG_NMBR          NUMBER,
   CL_RFRNC_NMBR      VARCHAR2(100 BYTE),
DT_KY              NUMBER,
TM_KY              NUMBER,
HRLY_KY            NUMBER,
ACTVTY_KY          NUMBER,
INS_DT             DATE,
SRVC_ID            VARCHAR2(100 BYTE),
MSC_ADRS           VARCHAR2(100 BYTE),
TRF_ID             NUMBER,
CL_TYP             NUMBER,
LCTN_INFRMTN       VARCHAR2(100 BYTE),
LCTN_KY            NUMBER,
SRC_CLNG_NMBR      VARCHAR2(50 BYTE),
ACTVTY_CL_TP       VARCHAR2(100 CHAR)
PARTITION BY RANGE(DT_KY)
PARTITION DAY_20DEC2009 VALUES LESS THAN (4153),
PARTITION DAY_21DEC2009 VALUES LESS THAN (4154),
PARTITION DAY_22DEC2009 VALUES LESS THAN (4155),
PARTITION DAY_23DEC2009 VALUES LESS THAN (4156),
PARTITION DAY_24DEC2009 VALUES LESS THAN (4157),
PARTITION DAY_25DEC2009 VALUES LESS THAN (4158),
PARTITION DAY_26DEC2009 VALUES LESS THAN (4159),
PARTITION DAY_27DEC2009 VALUES LESS THAN (4160),
PARTITION DAY_28DEC2009 VALUES LESS THAN (4161),
PARTITION DAY_31DEC2011 VALUES LESS THAN (4894),
PARTITION DAY_END_PART VALUES LESS THAN (MAXVALUE)
TABLESPACE cdr
PCTUSED    0
PCTFREE    10
INITRANS   1
MAXTRANS   255
STORAGE    (
            INITIAL          80K
            MINEXTENTS       1
            MAXEXTENTS       UNLIMITED
            PCTINCREASE      0
            BUFFER_POOL      DEFAULT
NOLOGGING
NOCOMPRESS
NOCACHE
NOPARALLEL
MONITORING;Many many thanks and best regards
Fahd
Edited by: Fahd Mirza on Jun 3, 2010 2:00 PM
Edited by: Fahd Mirza on Jun 3, 2010 2:03 PM

Can we create secondary index for a cluster table

hi
can we create secondary index for a cluster table

Jyothsna,
There seems to be some kind of misunderstanding here. You <i>cannot</i> create a secondary index on a cluster table. A cluster table does not exist as a separate physical table in the database; it is part of a "physical cluster". In the case of BSEG for instance, the physical cluster is RFBLG. The only fields of the cluster table that also exist as fields of the physical cluster are the leading fields of the primary key. Taking again BSEG as the example, the primary key includes the fields MANDT, BUKRS, BELNR, GJAHR, BUZEI. If you look at the structure of the RFBLG table, you will see that it has primary key fields MANDT, BUKRS, BELNR, GJAHR, PAGENO. The first four fields are those that all cluster tables inside BSEG have in common. The fifth field, PAGENO, is a "technical" field giving the sequence number of the current record in the series of cluster records sharing the same primary key.
All the "functional" fields of the cluster table (for BSEG this is field BUZEI and everything beyond that) exist only inside a raw binary object. The database does not know about these fields, it only sees the raw object (the field VARDATA of the physical cluster). Since the field does not exist in the database, it is impossible to create a secondary index on it. If you try to create a secondary index on a cluster table in transaction SE11, you will therefore rightly get the error "Index maintenance only possible for transparent tables".
Theoretically you could get around this by converting the cluster table to a transparent table. You can do this in the SAP dictionary. However, in practice this is almost never a good solution. The table becomes much larger (clusters are compressed) and you lose the advantage that related records are stored close to each other (the main reason for having cluster tables in the first place). Apart from the performance and disk space hit, converting a big cluster table like BSEG to transparent would take extremely long.
In cases where "indexing" of fields of a cluster table is worthwhile, SAP has constructed "indexing tables" around the cluster. For example, around BSEG there are transparent tables like BSIS, BSAS, etc. Other clusters normally do not have this, but that simply means there is no reason for having it. I have worked with the SAP dictionary for over 12 years and I have never met a single case where it was necessary to convert a cluster to transparent.
If you try to select on specific values of a non-transparent field in a cluster without also specifying selections for the primary key, then the database will have to do a serial read of the whole physical cluster (and the ABAP DB interface will have to decompress every single record to extract the fields). The performance of that is monstrous -- maybe that was the reason of your question. However, the solution then is (in the case of BSEG) to query via one of the index tables (where you are free to create secondary indexes since those tables are transparent).
Hope this clarifies things,
Mark

Datapump import of tables will automatically rebuild indexes ?

dear all,
do datapump import of tables will automatically rebuild the indexes againts the associated tables?
urgent response please

Yes indexes are rebulit.
From dba-oracle
Set indexes=n – Index creation can be postponed until after import completes, by specifying indexes=n. If indexes for the target table already exist at the time of execution, import performs index maintenance when data is inserted into the table. Setting indexes=n eliminates this maintenance overhead. You can also use the indexfile=filename parm to rebuild all the indexes once, after the data is loaded. When editing the indexfile, add the nologging and parallel keywords (where parallel degree = cpu_count-1).

Index Maintenance

Similar Messages

Maybe you are looking for