Quand utiliser sort_in_tempdb lors de la reconstruction des index?

Nous discutons de l'opportunité d'utiliser l'option SORT_IN_TEMPDB pour nos tables DW. Ma compréhension est qu'il y a plus d'écritures lors de l'utilisation de cette option, bien qu'elles soient plus séquentielles. Nous avons un SAN (qui a parfois été notoirement lent), dans notre cas, nous voulons limiter le nombre d'écritures autant que possible. Je crois que tempdb est sur un LUN (ensemble de disques) distinct.

Nous avons beaucoup d'espace disque dans notre fichier de données et sur notre fichier tempdb. Dans ce cas, serait-il avantageux d'utiliser SORT_IN_TEMPDB?

Une chose qui m'a frappé était ce commentaire sur cette réponse

Lors de la reconstruction d'un index, vous auriez besoin du double de l'espace de l'index + 20% pour le tri. Donc, en général, pour reconstruire chaque index de votre base de données, vous n'avez besoin que de 120% de votre plus grand index dans votre base de données. Si vous utilisez SORT_IN_TEMPDB, vous ne gagnez que 20%, vous avez encore besoin d'un 100% supplémentaire dans votre fichier de données. De plus, l'utilisation de sort dans tempdb augmente considérablement votre charge d'E / S, car au lieu d'écrire une fois l'index dans le fichier de données, vous l'écrivez maintenant une fois dans la tempdb, puis l'écrivez dans le fichier de données. Ce n'est donc pas toujours idéal.

Nous ne voulons certainement pas augmenter notre charge d'E / S avec notre SAN lent / éventuellement mal configuré.

Quelle serait la meilleure façon de tester cela? En reconstruisant simplement la table avec et sans l'option et en enregistrant les heures?

Edit : Nous avons 8 fichiers tempdb, chacun de 15 Go. Nous avons des drapeaux TF 1117/1118 et IFI est activé. Nous faisons actuellement un mélange de reconstruction avec l'option sort_in_tempdb et sans elle.

Merci!

SQL Server 2012 Enterprise

SORT_IN_TEMPDBsignifie que SQL Server utilisera tempdbpour allouer l'espace temporaire au lieu d'allouer de l'espace dans la base de données utilisateur dont l'index est en cours de reconstruction. Cela signifie que vous aurez besoin de moins d'espace libre dans votre base de données utilisateur lors d'une opération de reconstruction d'index et de plus d'espace libre dans tempdb.

Il vous offre un meilleur avantage lorsque tempdb se trouve sur un ensemble de disques (LUN) différent de la base de données utilisateur.

De l' option SORT_IN_TEMPDB - BOL :

Si l' option SORT_IN_TEMPDB est définie sur ON et que tempdb se trouve sur un ensemble de disques distinct du groupe de fichiers de destination, pendant la première phase, les lectures des pages de données se produisent sur un disque différent des écritures dans la zone de travail de tri dans tempdb. Cela signifie que les lectures sur disque des clés de données se poursuivent généralement plus en série sur le disque, et les écritures sur le disque tempdb sont également généralement en série, tout comme les écritures pour construire l'index final. Même si d'autres utilisateurs utilisent la base de données et accèdent à des adresses de disque distinctes, le modèle global de lectures et d'écritures est plus efficace lorsque SORT_IN_TEMPDB est spécifié que lorsqu'il ne l'est pas.

Assurez-vous de lire l' espace disque requis lorsque SORT_IN_TEMPDB est activé .

SAN lent / éventuellement mal configuré

Vous connaissez le point douloureux. Pourquoi ne travaillez-vous pas avec votre administrateur SAN pour le réparer? Un SAN mal configuré et / ou lent entraînera toutes sortes de problèmes comme la lenteur .

Quelques points importants à noter:

• Utilisez MAXDOP = 1 lorsque vous effectuez une reconstruction d'index en ligne , sinon cela entraînera une fragmentation accrue.
• Réorganisez / reconstruisez intelligemment vos index en fonction du niveau de fragmentation ainsi que des fragments de page.
• Lisez l'expérience de SQLFool avec la création d'un index de 60 Go
• Assurez-vous que vous avez correctement configuré tempdb - TF 1117 (GROW TO ALL FILES IN A FILEGROUP EGALY) and 1118 (FULL EXTENTS ONLY) and have more tempdb datafiles .

Quelle serait la meilleure façon de tester cela?

Oui, vous devez le tester en analysant les waitstats lorsque vous reconstruisez l'index avec et sans SORT_IN_TEMPDB. Mesurez également le temps d'exécution et lorsque vous le faites dans PROD, assurez-vous de le faire pendant une fenêtre de maintenance ou moins d'activité du serveur. Vérifiez également vos données en lecture / écriture et la latence du journal .

Je ne suis pas sûr que vous ayez une initialisation de fichier instantanée , mais cela bénéficiera lors de la restauration, lors de la croissance automatique des fichiers de données et lors de la création d'une nouvelle base de données (en mentionnant simplement l'exhaustivité).