How to make DBReindex use multiple cores?
The related question was mine also.
A large table took almost 15 hours to complete a rebuild of the indexes. While it was running, I noticed that it was only using one core out of 8. Is there a way to cause the REINDEX to use multiple cores or will it only run on one core since it is one process (query)?
A large table took almost 15 hours to complete a rebuild of the indexes. While it was running, I noticed that it was only using one core out of 8. Is there a way to cause the REINDEX to use multiple cores or will it only run on one core since it is one process (query)?
ASKER
It did not appear to be using more than one core. 7 cores were at about 5-10% of usage while one core was at about 100%. I checked the max degree of Parallelism and it is showing config and run values of 4.
That article certainly confirmed what I already new about several of my larger tables. They definately need to be reindexed. Here's the results of ShowContig for two of the tables. The table I reindex in the other areticle had a scan density of about 25% also before the reindex and 99.09% after.
DBCC SHOWCONTIG scanning 'TicketImage' table...
Table: 'TicketImage' (1537856991); index ID: 1, database ID: 7
TABLE level scan performed.
- Pages Scanned...................
- Extents Scanned...................
- Extent Switches..................
- Avg. Pages per Extent....................
- Scan Density [Best Count:Actual Count].......: 25.37% [347158:1368528]
- Logical Scan Fragmentation ..................: 39.49%
- Extent Scan Fragmentation ...................: 40.52%
- Avg. Bytes Free per Page.....................:
- Avg. Page Density (full)....................
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
DBCC SHOWCONTIG scanning 'TicketHeader' table...
Table: 'TicketHeader' (1137855566); index ID: 1, database ID: 7
TABLE level scan performed.
- Pages Scanned...................
- Extents Scanned...................
- Extent Switches..................
- Avg. Pages per Extent....................
- Scan Density [Best Count:Actual Count].......: 24.98% [18165:72729]
- Logical Scan Fragmentation ..................: 28.14%
- Extent Scan Fragmentation ...................: 48.43%
- Avg. Bytes Free per Page.....................:
- Avg. Page Density (full)....................
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
That article certainly confirmed what I already new about several of my larger tables. They definately need to be reindexed. Here's the results of ShowContig for two of the tables. The table I reindex in the other areticle had a scan density of about 25% also before the reindex and 99.09% after.
DBCC SHOWCONTIG scanning 'TicketImage' table...
Table: 'TicketImage' (1537856991); index ID: 1, database ID: 7
TABLE level scan performed.
- Pages Scanned...................
- Extents Scanned...................
- Extent Switches..................
- Avg. Pages per Extent....................
- Scan Density [Best Count:Actual Count].......: 25.37% [347158:1368528]
- Logical Scan Fragmentation ..................: 39.49%
- Extent Scan Fragmentation ...................: 40.52%
- Avg. Bytes Free per Page.....................:
- Avg. Page Density (full)....................
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
DBCC SHOWCONTIG scanning 'TicketHeader' table...
Table: 'TicketHeader' (1137855566); index ID: 1, database ID: 7
TABLE level scan performed.
- Pages Scanned...................
- Extents Scanned...................
- Extent Switches..................
- Avg. Pages per Extent....................
- Scan Density [Best Count:Actual Count].......: 24.98% [18165:72729]
- Logical Scan Fragmentation ..................: 28.14%
- Extent Scan Fragmentation ...................: 48.43%
- Avg. Bytes Free per Page.....................:
- Avg. Page Density (full)....................
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
After seeing what is below you may want to watch some performance counters while this reIndex is going on and see if it is disk IO that is the bottleneck (quick and easy way is to watch the Current Disk Queue Length on the drives containing the DB) since that dbReindex will attempt to actually resort by your primary key that may be the major slowdown.
Just for kicks also give running dbIndexDefrag and Update Statistics and see if that takes a comparable amount of time or not.
Is this database really fragmented too? What is the output of ShowContig?
http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/ss2kidbp.mspx
There are two distinct advantages of running DBCC DBREINDEX over DBCC INDEXDEFRAG:
"
DBCC DBREINDEX rebuilds statistics automatically during the rebuild of the indexes; this can have dramatic improvements on workload performance.
"
DBCC DBREINDEX can take advantage of multiple-processor computers and can be significantly faster when rebuilding large or heavily fragmented indexes.