December 29, 2020 at 12:34 am
I have 3 large tables with 133 million rows in 2 of the tables and over 570 million in the other. I have a 12 hour window of downtime
and would like to rebuild the Indexes on these tables, but concerned on the length of time it may consume. Are there any diagnostics
I could run to maybe give me an idea of the time the rebuilds may consume. The server has 32gig of memory and 4 processors and would
be solely dedicated to the Index rebuild during this time period.
Thanks, any suggestions would be appreciated.
December 29, 2020 at 12:34 am
sql2012 - sp4
December 29, 2020 at 1:32 am
It shouldn't take anything remotely close to 12 hours to rebuild indexes on tables that size with that much RAM available.
Unless maybe the table's incredibly wide. What is the average row length for each table?
SQL DBA,SQL Server MVP(07, 08, 09) "It's a dog-eat-dog world, and I'm wearing Milk-Bone underwear." "Norm", on "Cheers". Also from "Cheers", from "Carla": "You need to know 3 things about Tortelli men: Tortelli men draw women like flies; Tortelli men treat women like flies; Tortelli men's brains are in their flies".
December 29, 2020 at 3:42 pm
nbr-of-columns avg-row-length records
15 905 133 million
4 412 570 million
4 6 133 million
The DB is in "SIMPLE" mode, and other things -- space - ?
Who can you monitor progress ?
Thanks.
December 29, 2020 at 5:23 pm
I don't know of a way to predict index REBUILD times. I can only tell you that I have a similar table that has a similar row count and slightly larger average row size that weighs out at 147GB and it took 12 minutes on one of my DEV boxes in the Simple Recovery Model for the Clustered Index. YMMV depending on your I/O system performance.
As a bit of a sidebar, if the indexes are page-compressed, multiply that duration by 4. I don't know what the multiplication factor will be for row compression because I've not tried that yet.
Also be aware that for any index over 128 extents (that's just 8MB in size), that you'll need room for the largest index to temporarily double in size because, for such indexes, a totally new index is created with all the data in place before dropping the old index (data).
And, to ask the question, you're actually planning on using REBUILD and not REORGANIZE, correct? I ask because REORGANIZE is not the tame little kitty that everyone claims it is. With just 12% fragmentation on the table I spoke of, it took almost two hours and it caused the log file to blow out at 227GB even in the Simple Recovery Model. The log file for the rebuild never got over 20GB on a standalone machine nor over 37GB on an active machine during the REBUILD.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 29, 2020 at 6:17 pm
I'm going to do a REBUILD. If I have 3+ indexes along with PK, is there any rule on thumb to rebuild each individually or
REBUILD ALL on the table?
Any trade-offs for doing individually or ALL. Do you just run a script or thru SSMS?
Thanks.
December 29, 2020 at 8:05 pm
If you need rebuilding indexes it’s probably a good time to rethink the indexing strategy.
you need to figure out what causes fragmentation and redefine the indexes in such a way which will minimise the fragmentation as tables get populated.
_____________
Code for TallyGenerator
December 29, 2020 at 8:10 pm
If you need rebuilding indexes it’s probably a good time to rethink the indexing strategy. you need to figure out what causes fragmentation and redefine the indexes in such a way which will minimise the fragmentation as tables get populated.
Amen to that!
--Jeff Moden
Change is inevitable... Change for the better is not.
December 29, 2020 at 8:13 pm
Use REBUILD ALL, it will (should) be more efficient.
But pre-grow the log first to the total size you will need for the REBUILD. It's a very slow process when the log has to grow dynamically. If you're unsure of what the total size will be, and can afford the space, just pre-grow the log so its available space is the size of the table plus all its nonclustered indexes.
During the REBUILD you can look to see how much of the log is used via DBCC LOGINFO. On SQL 2016+, we can use sys.dm_db_log_info ( database_id ) for complete info, even after the REBUILD completes. But before 2016, sadly not available.
SQL DBA,SQL Server MVP(07, 08, 09) "It's a dog-eat-dog world, and I'm wearing Milk-Bone underwear." "Norm", on "Cheers". Also from "Cheers", from "Carla": "You need to know 3 things about Tortelli men: Tortelli men draw women like flies; Tortelli men treat women like flies; Tortelli men's brains are in their flies".
December 29, 2020 at 8:24 pm
I'm going to do a REBUILD. If I have 3+ indexes along with PK, is there any rule on thumb to rebuild each individually or REBUILD ALL on the table?
Any trade-offs for doing individually or ALL. Do you just run a script or thru SSMS?
Thanks.
I never use the ALL option because, a lot of times, there will be one or more indexes that don't need to be rebuilt and so doing unnecessary rebuilds is a total waste of time, CPU, I/O, and disk space (log file).
As for how to run it, a stored procedure is best. I'm changing all of my stuff to do some magic with determining the proper Fill Factor and minimize disk usage (including a thing that a fellow DBA and I call "external REBUILDs") and it's not yet ready for prime time or I'd share it with you.
So, my rule of thumb is that, since each index has it's own personality, I rebuild them one at a time. There's also the issue of having disabled indexes for one reason or another. ALL will have some consequences there. I've not researched them all because I simply don't use ALL.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 29, 2020 at 8:40 pm
With a table that large, say you have a total of 6 indexes, 1 clus and 5 nonclus.
I'd expect it to be faster to do a REBUILD ALL than to REBUILD the clus index and then 2 nonclus indexes each separately. At least as I understand SQL's processing, the REBUILD ALL can rebuild all indexes with only a single scan of the table.
SQL DBA,SQL Server MVP(07, 08, 09) "It's a dog-eat-dog world, and I'm wearing Milk-Bone underwear." "Norm", on "Cheers". Also from "Cheers", from "Carla": "You need to know 3 things about Tortelli men: Tortelli men draw women like flies; Tortelli men treat women like flies; Tortelli men's brains are in their flies".
December 30, 2020 at 1:12 am
does anyone have there SP they run and like to share ?
Thx.
December 30, 2020 at 2:44 am
With a table that large, say you have a total of 6 indexes, 1 clus and 5 nonclus.
I'd expect it to be faster to do a REBUILD ALL than to REBUILD the clus index and then 2 nonclus indexes each separately. At least as I understand SQL's processing, the REBUILD ALL can rebuild all indexes with only a single scan of the table.
Do you have a link that explains that, Scott?
--Jeff Moden
Change is inevitable... Change for the better is not.
December 30, 2020 at 1:17 pm
I was thinking of using this script on my fragmented index rebuilds.
USE [xxxx]
GO
ALTER INDEX [PK_EmployeeJobHistory_1] ON [dbo].[EmployeeJobHistory]
REBUILD PARTITION = ALL WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF,
SORT_IN_TEMPDB = OFF,ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 90)
GO
December 30, 2020 at 4:31 pm
Even if the db is not normally in SIMPLE mode, you would certainly want it to be in SIMPLE for these rebuilds, to drastically reduce logging requirements.
If the db is normally in FULL mode, then the index rebuild sequence should be:
SQL DBA,SQL Server MVP(07, 08, 09) "It's a dog-eat-dog world, and I'm wearing Milk-Bone underwear." "Norm", on "Cheers". Also from "Cheers", from "Carla": "You need to know 3 things about Tortelli men: Tortelli men draw women like flies; Tortelli men treat women like flies; Tortelli men's brains are in their flies".
Viewing 15 posts - 1 through 15 (of 47 total)
You must be logged in to reply to this topic. Login to reply