Comment configurer Azure SQL pour reconstruire les index automatiquement?
Dans les bases de données SQL sur site, il est normal de disposer d'un plan de maintenance permettant de reconstruire les index de temps en temps, lorsqu'ils ne sont pas trop utilisés.
Comment puis-je l'installer dans Azure SQL DB?
P.S: J'ai déjà essayé, mais comme je ne trouvais aucune option pour cela, je pensais qu'ils le faisaient automatiquement jusqu'à ce que je lise ce post et que j'essaye:
SELECT
DB_NAME() AS DBName
,OBJECT_NAME(ps.object_id) AS TableName
,i.name AS IndexName
,ips.index_type_desc
,ips.avg_fragmentation_in_percent
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.indexes i
ON ps.object_id = i.object_id
AND ps.index_id = i.index_id
CROSS APPLY sys.dm_db_index_physical_stats(DB_ID(), ps.object_id, ps.index_id, null, 'LIMITED') ips
ORDER BY ps.object_id, ps.index_id
Et découvert que j'ai des index qui ont besoin de maintenir 
Je ferai remarquer que la plupart des gens n'ont pas du tout besoin de reconstruire les index dans SQL Azure. Oui, les index de l'arborescence B + peuvent devenir fragmentés, ce qui peut entraîner une surcharge d'espace et une surcharge de processeur par rapport aux index parfaitement ajustés. Ainsi, dans certains cas, nous travaillons avec les clients pour reconstruire les index. (Le scénario principal est le moment où le client peut manquer d'espace, car l'espace disque est quelque peu limité dans SQL Azure en raison de l'architecture actuelle). Je vous encourage donc à prendre du recul et à considérer que l’utilisation du modèle SQL Server pour la gestion des bases de données n’est pas «fausse», mais que vos efforts en valent peut-être la peine.
(Si vous devez reconstruire un index, vous pouvez utiliser les modèles postés ici par les autres affiches. Il s'agit généralement de modèles parfaits pour les tâches de script. Notez que SQL Azure Managed Instance prend également en charge SQL Agent, que vous pouvez également utiliser. créer des tâches pour les opérations de maintenance de script si vous le souhaitez).
Voici quelques détails qui peuvent vous aider à décider si vous pouvez être candidat à la reconstruction d'index:
- Le lien que vous avez référencé provient d'un article de 2013. L'architecture de SQL Azure a été complètement refaite après cet article. Plus précisément, l'architecture matérielle est passée d'un modèle basé sur des disques en rotation locaux à un modèle basé sur des disques SSD locaux (dans la plupart des cas). Les indications du message original sont donc obsolètes.
- Vous pouvez avoir des cas dans l'architecture actuelle où vous pouvez manquer d'espace avec un index fragmenté. Vous avez le choix entre reconstruire l’index ou passer à une taille de réservation plus grande pendant un certain temps (ce qui coûtera plus cher) qui prend en charge une allocation d’espace disque plus grande. [L'espace SSD local sur les machines étant limité, les tailles de réservation sont grossièrement liées aux proportions de la machine. Au fur et à mesure que nous obtenons du matériel plus récent avec des disques plus gros/plus nombreux, vous disposez de plus d’options d’agrandissement].
- L'impact de la fragmentation des disques SSD est relativement faible par rapport à la rotation des disques car le coût d'un IO aléatoire n'est pas vraiment supérieur à celui d'un disque séquentiel. Le temps de calcul de la marche de quelques pages intermédiaires B + Tree supplémentaires est modeste. J'ai généralement constaté des frais généraux de 5 à 20% maximum dans le cas moyen (ce qui peut justifier ou non des reconstructions régulières qui ont un impact beaucoup plus important sur la charge de travail lors de la reconstruction).
- Si vous utilisez un magasin de requêtes (qui est activé par défaut dans SQL Azure), vous pouvez évaluer si une reconstruction d'index spécifique améliore vos performances, de manière visible ou non. Vous pouvez le faire à titre de test pour voir si votre charge de travail s'améliore avant de prendre le temps de créer et de gérer vous-même les opérations de reconstruction d'index.
- Notez qu'il n'existe actuellement aucune gouvernance de ressources intra-base de données dans SQL Azure pour les charges de travail des utilisateurs. Ainsi, si vous démarrez une reconstruction d'index, vous risquez de consommer beaucoup de ressources et d'avoir un impact sur votre charge de travail principale. Vous pouvez bien sûr essayer de faire en sorte que les tâches soient effectuées en dehors des heures de travail, mais cela n’est peut-être pas possible pour les applications ayant de nombreux clients à travers le monde.
- De plus, je noterai que de nombreux clients ont des travaux de reconstruction d'index "parce qu'ils veulent que les statistiques soient mises à jour". Il n'est pas nécessaire de reconstruire un index pour reconstruire les statistiques. Dans les versions récentes de SQL Server et de SQL Azure, l'algorithme de mise à jour des statistiques est devenu plus agressif pour les tables plus volumineuses et le modèle d'estimation de la cardinalité dans le cas où les clients interrogent des données récemment insérées (depuis la dernière mise à jour des statistiques) a été modifié ultérieurement. niveaux. Ainsi, il arrive souvent que le client n’ait même pas besoin de mettre à jour ses statistiques manuellement.
- Enfin, je noterai que par le passé, l’impact des statistiques sur les statistiques était que vous obteniez des régressions de choix de régimes. Pour les requêtes répétées, l'impact de cette modification a été largement atténué par l'introduction de la fonctionnalité de réglage automatique du magasin de requêtes (qui force les plans précédents si elle constate une régression importante des performances de la requête par rapport au plan précédent).
La recommandation officielle que je recommande aux clients est de ne pas se préoccuper de la reconstruction d'index, sauf s'ils disposent d'une application de niveau 1 pour laquelle ils ont démontré un besoin réel (les avantages l'emportent sur les coûts), ou lorsqu'ils sont SaaS ISV où ils tentent d'adapter une charge de travail à de nombreuses bases de données/clients dans des pools élastiques ou dans une conception de base de données à locataires multiples afin de réduire leur COGS ou d'éviter de manquer d'espace disque (comme mentionné précédemment) sur une très grande base de données. Dans les plus gros clients que nous avons sur la plate-forme, nous parfois voyons l'intérêt de faire des opérations d'index manuellement avec le client, mais nous n'avons souvent pas besoin d'un travail régulier où nous effectuons ce type d'opération "juste en Cas". L’intention de l’équipe SQL est que vous n’ayez pas besoin de vous préoccuper de cela, vous pouvez simplement vous concentrer sur votre application. Il y a toujours des choses que nous pouvons ajouter ou améliorer dans nos mécanismes automatiques, bien sûr, donc je permets complètement la possibilité qu'une base de données client individuelle puisse avoir besoin de telles actions. Je n'en ai pas moi-même vu d'autres que celles que j'ai mentionnées, et même celles-ci posent rarement problème.
J'espère que cela vous donne un certain contexte pour comprendre pourquoi cela n'a pas encore été fait sur la plate-forme - cela n'a tout simplement pas été un problème pour la grande majorité des bases de données clients que nous avons aujourd'hui dans notre service par rapport à d'autres besoins urgents. Nous revoyons bien sûr la liste des éléments dont nous avons besoin pour construire chaque cycle de planification et nous examinons régulièrement les opportunités de ce type.
Bonne chance - quel que soit votre résultat ici, j'espère que cela vous aidera à faire le bon choix.
Cordialement, Conor Cunningham Architecte, SQL
Vous pouvez utiliser Azure Automation pour planifier des tâches de maintenance des index, comme expliqué ci-après: Reconstruction des index de base de données SQL à l'aide d'Azure Automation
Voici les étapes:
1) Mettez en place un compte d’automatisation si vous n’en possédez pas en vous rendant sur https://portal.Azure.com et en sélectionnant Nouveau> Gestion> Compte d’automatisation.
2) Après avoir créé le compte d'automatisation, ouvrez les détails et cliquez maintenant sur Runbooks> Parcourir la galerie.
Tapez dans le champ de recherche le mot "indexes" et le runbook "Indexer les tables dans une base de données Azure si leur niveau de fragmentation est élevé":
4) Notez que l'auteur du runbook est le SC Automation Product Team de Microsoft. Cliquez sur Importer:
5) Après avoir importé le runbook, ajoutons maintenant les informations d’identification de la base de données aux ressources. Cliquez sur Actifs> Informations d'identification, puis sur le bouton «Ajouter une information d'identification…». 
6) Définissez un nom d'identification (qui sera utilisé ultérieurement dans le runbook), le nom d'utilisateur et le mot de passe de la base de données:
7) Cliquez à nouveau sur Runbooks, puis sélectionnez «Update-SQLIndexRunbook» dans la liste, puis cliquez sur le bouton «Modifier…». Vous pourrez voir le script PowerShell qui sera exécuté:
8) Si vous souhaitez tester le script, cliquez simplement sur le bouton «Volet de test». La fenêtre de test s'ouvre. Introduisez les paramètres requis et cliquez sur Démarrer pour exécuter la reconstruction d'index. Si une erreur se produit, l'erreur est enregistrée dans la fenêtre de résultats. Notez que, selon la base de données et les autres paramètres, la procédure peut être longue:
9) Maintenant, retournez dans l'éditeur et cliquez sur le bouton “Publier” pour activer le runbook. Si nous cliquons sur «Démarrer», une fenêtre apparaît pour vous demander les paramètres. Mais comme nous voulons planifier cette tâche, nous allons plutôt cliquer sur le bouton "Planifier":
10) Cliquez sur le lien Planning pour créer un nouveau planning pour le runbook. J'ai précisé une fois par semaine, mais cela dépend de votre charge de travail et de la manière dont vos index augmentent leur fragmentation au fil du temps. Vous devrez modifier le calendrier en fonction de vos besoins et en exécutant les requêtes initiales entre les exécutions:
11) Introduisez maintenant les paramètres et les paramètres d'exécution:
NOTE: vous pouvez jouer avec différentes planifications avec différents paramètres, c’est-à-dire avec une planification spécifique pour une table spécifique.
Avec ça, vous avez fini. N'oubliez pas de modifier les paramètres de journalisation comme vous le souhaitez:
Azure Automation est bon et le prix est également négligeable.
Certaines autres options que vous avez sont
1.Créez une tâche d'exécution SQL et planifiez-la via l'agent SQL. La tâche d'exécution SQL doit contenir le code de reconstruction d'index ainsi que la commande stats reconstruite.
2.Vous pouvez également créer un serveur lié à SQLAZURE et un travail d'agent SQL. Pour créer un serveur lié à Azure, vous pouvez voir ce lien SO: Je dois ajouter un serveur lié à un MS Azure SQL Server