SQL Server 2008 :: Logic To Rebuild Only Clustered Indexes / Skipping To Rebuild Non Clustered Indexes In Same Table
Jun 25, 2015
I have a requirement to only rebuild the Clustered Indexes in the table ignoring the non clustered indexes as those are taken care of by the Clustered indexes.
In order to do that, I have taken the records based on the fragmentation %.
But unable to come up with a logic to only consider rebuilding the clustered indexes in the table.
So I'm reading http://www.sql-server-performance.com/tips/clustered_indexes_p2.aspx and I come across this: When selecting a column to base your clustered index on, try to avoid columns that are frequently updated. Every time that a column used for a clustered index is modified, all of the non-clustered indexes must also be updated, creating additional overhead. [6.5, 7.0, 2000, 2005] Updated 3-5-2004 Does this mean if I have say a table called Item with a clustered index on a column in it called itemaddeddate, and several non-clustered indexes associated with that table, that if a record gets modified and it's itemaddeddate value changes, that ALL my indexes on that table will get rebuilt? Or is it referring to the table structure changing? If so does this "pseudocode" example also cause this to occur: sqlstring="select * from item where itemid=12345" rs.open sqlstring, etc, etc, etc rs.Fields("ItemName")="My New Item Name" rs.Fields("ItemPrice")=1.00 rs.Update Note I didn't explicitly change the value of rs.fields("ItemAddedDate")...does rs.Fields("ItemAddedDate")=rs.Fields("ItemAddedDate") occur implicitly, which would force the rebuild of all the non-clustered indexes?
My environment is SQL 2000. I have a table with 500 million rows. The table is consistently getting updated and inserted. I can not take the table offline. My clustered index needs to be rebuilt due to decreased performance. How do I accomplish this?
Our inhouse app used to run on a SQL2000, but we've recently moved it to 2005. The move was done by way of backup and restore (it was on a whole new server).
After the move, an odd problem showed up: once in a while, the server seems incapable of finding/using its indexes: everything starts working slowly, until I run a maintenance plan that rebuilds its indexes etc. In the database/server all relevant options seem to be ok (auto update statictiscs etc.), and my conclusion that it doesn't use its indexes comes from the fact that: * it gives the results from certain select statements in a totally different order (although the set of rows is the same), * performance is (all of a sudden) very slow (seconds turning to minutes!!)
This happens: * at least after a reboot of the server * sometimes just in the middle of the day
The only way I've found to solve the matter, is by running the maintenance plan to rebuild the indexes, but sometimes this only seems to work the second time.
Does anybody share this experience, or know what to do about it?
I would like to find information on Clustered and Non-clustered indexes and how B-trees are used. I know a clustered index is placed into a b-tree which makes sense for fast ordered searching. What data structure does a non-clustered index use and how? I tried to find info. on the web but couldn't get much detail...
Hi All, SQL 7 REQUIRES THE DBA TO MANAGE THE INDEXES AND IN PARTICULAR THE FILL FACTOR AVAILABILITY. DOES SQL SERVER 2000 AUTOMATICALLY ADDRESS THIS OR DO WE STILL HAVE TO PERIODICALLY RUN,
In the maintance plans there is a Rebuild Index choice. If u choose tables and views the plan executes ALTER INDEX <index> ON <table> ;REBUILD for all indexes in the datebase. I am currently using this plan on our production DB, scheduled for every Saturday night. I wonder if there is a downside of using maintance plans. Because it seems to be doing the job. Any comments?
I am upgrading from SQL2000 to SQL2005. I have restored my 2000 db to 2005. I have changed the Compatiblilty level to 90. Now I need to reindex. How do I reindex all the tables at once? Thanks for ALL your help r/p
We have a script running everyday for rebuild and re-organisation of indexes. But, somehow its getting failed. Attached script for your consideration. There is no database name with amoperations. There is table called DatabaseObjectAudit but it exist on master db.
Message:
-->Start Index Maint -> Gathering fragmentation information (can take a while!) -> Gathering COMPLETE : Total of 43 databases were found. -> Gathering COMPLETE : Total of 1622 indexes were found.
I have a number of databases that are being transactionally replicated from SQL 2000 Enterprise edition publisher to SQL 2005 Enterprise edition subscriber. I have included indexes in the replication. The subscriber database is then accessed and the data de-normalised and aggregated for reporting purposes.
My question is this: I want to periodically re-build the indexes on the publisher and subscriber via an automated task. If I rebuild the indexes on the publisher, will that automatically replicate to the subscriber? Will there be a problem with the "snapshot being out of date", and therefore replication stopping? I run a new snapshot once a day in the small hours of the morning. If there is likely to be a problem with the rebuild throwing the replication out, would it be wise to have the rebuild job running just before the new snapshot is taken?
We are planning to standardize our newly deployed sql server, As a part of it we have configured 2 maintenance plans 1) Update Statistics which runs daily and 2) Index Reorganize which runs on weekly.
Apart from above, any other things to be in place for better maintenance of the sql server.
Also, how to Index Rebuild activity for clustered indexes requires any downtime.
Hi, I have a script to rebuild and reorganize indexes for sybase i.e reorg rebuild index... like command i have. Now i want similar command for MSSQLSqlserver.plz help me.
I am using SQL Server 2008 (RTM) Standard Edition.
In my environment, one of my Database size is 75 gb and I have to create a plan for index rebuild using maintenance plan.But when we rebuild indexes, it requires some space on data and log files of database.how can we calculate disk space requirement for index rebuild process ?
We have a maintenance plan running everyday for rebuild and re-organisation of indexes. But, somehow its getting failed. Here is the script that we are running for rebuild or re-org.
/* Script to handle index maintenance Tuning constants are set in-line current values are; SET @MinFragmentation SET @MaxFragmentation SET @TrivialPageCount
If you have a clustered index on an identity field are appends then forced onto the last page anyway because of the identity field order. So is there any advanbtage of having a clustered identity field ?
I need to convert several tables that currently have nonclustered indexes (primary keys) to clustered. Could anyone suggest what the easiest way of doing this would be.
Hi,The more I read, the more confused I'm getting ! (no wonder they sayignorance is bliss)I just got back from the bookstore and was flipping through some SQL ServerAdministration books.One says, that to get the best query performance, youi do two things:1. Cover all the columns used in each SELECT (including the WHERE, ORDERBY , etc.) with an index2. Make sure it's a NON-CLUSTERED index.In this way, the author says, you avoid ever going directly to the basetables for data to resolve the query - i.e. it's resolved in the index.So, for example, he argues if you have:SELECT Lname,Fname, CompanyNamefrom Contactsinner join Customerson (contacts.custid = customers.custid)that you use two non-clustered indexes:1. Lname,Fname and custid from the Contacts table2. CompanyName and custid from Customers(as opposed to the standard approach of a clustered index on the PK's ofeach table)He says that clustered indexes don't speed up performance because they'rethe same as a full table scan. Should I drop clustered indexes from mylarge tables, given that there are multiple non-clustered indexes on them?Is it better to just use multiple non-clustered indexes on a heap table?Steve
Normally we use rebuild, reorganize indexes when it is required, I used a SQL job using maintenance plan to run daily and rebuild, reorganize indexes and update statistics but I do not know if it runs either they are required or not. Should this plan automatically execute the build upon required indexes to be rebuild or it fires either they are required to be executed or not.
SQL 7 created by default a clustered index on my primary key field. I would like to drop this index and recreate it on another field, but it is not allowing me. Error message states: "An explicit DROP INDEX is not allowed... It is being used for PRIMARY KEY CONSTRAINT enforcement." Can anybody advise how I can solve this? TIA
Is any one know of a way of changing the clustered index without creating in the middle the default clustered index
we have a big table that we use to switch the clustered index whenever we change the clustered index we cannot change it directly we have to drop the existing than the default clustered is built and than we can built the new one - since it is a big table the process takes a lot of time and I wonder if we can do it directly from one cluster index to another
What we do not is running the following SQL: -- remove the old index drop index Tbl.I_oldId GO -- now create the newId as clustered CREATE CLUSTERED INDEX [I_newId] ON Tbl ([newId]) ON [PRIMARY] GO
Using SQL Server 2000 ... hopefully not too dumb a question.
Is there a performance hit using Clustered Index on a table that gets a lot of deletes?
I'm creating a Transaction Log table that will get about 4,000 inserts per day. The value of some of this historical data is worthless after a while, so I delete it.
It occurs to me that this may create a lot of fragmentation. If so, is this cleaned up during weekly "Reorganize data and index pages" in the Maintenance Plan? Do I also need to select "Remove unused space from database files"?
Additional question: I though that care needed to be taken that a clustered key be a value that always increments (datestamp, identity key, etc), yet in this write-up, it shows using randomly generated key values. I'm confused. Wouldn't it have to reorganize everything with greater values to insert the new row into the appropriate spot? http://www.sql-server-performance.com/gv_clustered_indexes.asp
What's best practice for creating clustered indexes?! Should they be added to a table AFTER it has been populated or should the clustered index be created BEFORE?
When you Upsize from Access using the wizard, unsurprisingly, a Unique index is created on the PK field, but these are all non-clustered. I presume there isn't one definitive answer to whether a index should be clustered or not, (which I understand means the table's records are held on disk contiguously), but generally, is it worth altering these all to become clustered? Would you selectively cluster only those tables which you think would benefit most? Leave them all unclustered and look for bottle-necks?
