June 3, 2022 at 9:15 am
Why are using this setting: SORT_IN_TEMPDB = OFF?
That's generally a very bad idea overall, esp. for larger indexes.
Not sure, im just using the following which was suggested earlier unless i made a mistake, which resulted in this execution:
EXECUTE [MASTER].dbo.IndexOptimize
@Databases = 'prodmd01', -- or just 1 db
@Indexes = @CURRENT_DB_SCHEMA_Table,
@FragmentationLow = NULL,
@FragmentationMedium = 'INDEX_REBUILD_OFFLINE',
@FragmentationHigh = 'INDEX_REBUILD_OFFLINE',
@FragmentationLevel1 = 30, -- change to a better value
@FragmentationLevel2 = 50, -- change to a better value
@UpdateStatistics = 'ALL',
@OnlyModifiedStatistics = 'Y',
@LogToTable = 'Y'
I want to be the very best
Like no one ever was
June 3, 2022 at 9:23 am
Duplicate Post i made because i couldnt see my own post/page 2 option.
Please ignore
I want to be the very best
Like no one ever was
June 3, 2022 at 10:15 am
forgot to add that option to the list.
to sort it out add
@SortInTempdb = 'Y'
to that list of options
with regards to that long run - get a copy of sp_whoisactive and if it happens again use it to see what is locking it.
June 5, 2022 at 5:30 am
Or how does the REBUILD over there interact with action thats happening on the server? from what ive been told its a very active table even at night when the job is running (select, delete, update, insert), could it have been deadlocked somehow?
Rebuild an index offline will lock the table. If the table is very high usage and is large, it would be better to let it fragment and rebuild it after you've done a couple of things...
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 4 posts - 16 through 18 (of 18 total)
You must be logged in to reply to this topic. Login to reply