[IQUG] [iqug] 16.0 index rebuilds
markdmumy at gmail.com
Mon Oct 7 06:37:22 MST 2019
Just to plant the seed.... if you don’t go to 16.1 sp03 or later you will need to do another rebuild then too.
Why are you going to tiered HG? First, that operation takes seconds. More importantly are you sure that you need them? I know that the benefit is hit or miss. I’ve not seen much help with them but some have.
Other than that, the process looks fine.
Sent from my mobile device
> On Oct 7, 2019, at 08:09, Louie, David <David.Louie at blackrock.com> wrote:
> Hello All,
> Another 16.0 migration set of questions.
> Our 15.4 db is 50+ TB and contains a large 30 TB table. We know we need to rebuild FP indices post upgrade and then rebuild HG as tiered, (sp_iqrebuildindex(<table>, HG, retier). We know we will need to do a phased approach as it is impossible to do this much work over 1 weekend.
> Weekend 1 upgrade in place to 16.0, rebuild all critical tables FP indices
> Weekend 2 rebuild all large tables FP indices (30TB table included) Not all of the FP indices on the 30 TB table will be done and will need to be phased
> Weekend 3 and beyond continue to rebuild the 30 TB FP indices and misc HG indices as tiered.
> First is the approach correct and is what most shops are doing?
> Second would there be a performance hit as we cannot get all HG indices Tiered and partial FP rebuilds on various table ( like the 30 TB table)
> We have a problem creating HG indices on the 30 TB table. ( dropping LF indices to make them HG). Ran out of temp space and our server stack traced and needed to be rebooted.
> Is there a way to determine how much temp space is required to recreate an HG index on a table?
> Are LF indices completely deprecated in 16.0 and will we need to recreate them as HG’s day 1?
> For a list of BlackRock's office addresses worldwide, see http://www.blackrock.com/corporate/about-us/contacts-locations.
> © 2019 BlackRock, Inc. All rights reserved.
> IQUG mailing list
> IQUG at iqug.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the IQUG