I've come across a situation where my database operations on many of my SQL Server database's tables have become very slow as more records have been added (5s for single insert to a table with 1 million records).
I've estimated that this may be due to fragmented indexes on tables in my database, because I have many tables that use (and need to use) a uniqueidentifier type for Primary Key clustered indexes.
How can I evaluate whether this is the case or not, and how can I resolve the fragmentation issues (perhaps once per deployment) if there are any fragmentation issues?
I would like a solution that works in SQL Server 2005 and higher (I am specifically working with SQL Server in an Azure database (12.0.2000.8)).
4条答案
按热度按时间8e2ybdfx1#
To check the fragmentation percentage on a table
To fix the fragmentation either rebuild or reorganize the index on the table
OR
-- REORGANIZE
OR
OR
https://learn.microsoft.com/en-us/sql/relational-databases/indexes/reorganize-and-rebuild-indexes
ar7v8xwq2#
Since you already know the table in which fragmentation is suspected, you can use the below T-SQL statements to identify Fragmentation.
To get the Database ID of a DB:
Run these queries under the database in which the table belongs to.
To get the object ID of a table:
To find the fragmentation percentage in a table:
If the fragmentation of an index is more than 20% then we can try rebuilding that index:
OR - to rebuild all the indexes in the table
OR - by using DBCC DBREINDEX
If Fragmentation count is below 20%, you could do away with an Index rebuild or ReOrg.. instead just update statistics for that Index/Table.
To run update statistics on a table with FULLSCAN:
To Update Stats of an Index
I have given each of these as separate queries for you to get a better understanding of what is being done. Hope this helps
qlzsbp2j3#
Here is a SQL query solution that works in SQL Server 2005 and up, that will let you
first find all the indexes that need to be rebuilt or reorganized to reduce fragmentation, and then
with a single copy-paste of the first five columns of the results to a new query window (removing the column header line), execute all the statements (rebuild/reorganize of indexes) that will resolve the majority of the current fragmentation issues in all tables in your database.
Note: If you run into permission errors, you may need to make sure you are positioned in the master schema and that your user has appropriate permissions for the database.
I named this query: GetFragmentationOfIndexesAndFirst5ColumnsExecutedResolveFragmentation.sql
I have to credit two places I used in understanding and ultimately coming to this solution:
Initial way to find fragmentation within a database: https://myadventuresincoding.wordpress.com/2013/05/27/sql-server-check-index-fragmentation-on-all-indexes-in-a-database/
How to resolve fragmentation within a database (and guideline of 5%-30% fragmentation should be resolved with reorganize of index, and 30%+ fragmentation should be resolved with rebuild of index): http://www.passionforsql.com/how-to-check-index-fragmentation-in-sql-server/
EDIT: I've included the
with (FILLFACTOR = 80)
part in the query above because in my case, the majority of the fragmented indexes were on uniqueidentifier columns, which should not be indexed with the default FILLFACTOR of 0 (100%) because having them that way will inevitably cause fragmentation quickly again because inserts will always need to be put between other rows due to the non-ordered creation of uniqueidentifiers. You can certainly change your pasted values to remove or change the parameters as is appropriate for your tables/indexes.I've also found that you'll want to execute
EXEC sp_updatestats
after rebuilding and reorganizing indexes so that the statistics can catch up with the index changes rather than having to do so incrementally during future queries.wljmcqd84#
Fully agree with the accepted answer. Just thought I would add this for posterity; it uses that same guidance and handles everything for you. Just run the script and defragment all indexes, or drop into a stored procedure and run nightly. You can restrict to a schema and skip sparse tables that will always appear fragmented. Enjoy!
Note that it does not alter the default FILLFACTOR (which is a great idea on uniqueidentifier columns) or rebuild the statistics, as that is often automated anyway, and adds a fair bit of time to this script.