La RECONSTRUCTION d'un HEAP provoque-t-elle des temps d'arrêt?

C'est une question un peu embarrassante, et je ne peux pas croire que je l'ai manqué depuis tant d'années.

J'ai une base de données tierce fournisseur qui a 401 tables de tas. J'ai récemment utilisé les scripts et la configuration sp_BlitzFirstde Brent Ozar pour s'exécuter toutes les 15 minutes afin de recueillir des statistiques d'attente, etc.

Ce qu'il a découvert était chaque fois qu'il fonctionnait sur une période de 24 heures, il me disait de corriger les enregistrements transférés . Ce qui va probablement choquer certains lecteurs que j'ai exécuté une requête sur les DMV et récupéré quelques tables avec plus de 150 000 valeurs d'enregistrement transmises.

Je comprends que résoudre ce problème est d'avoir un index clusterisé sur la table, ou comme solution de rechange temporaire à exécuter ALTER TABLE [tablename] REBUILD.

Ce que je n'ai pas pu trouver cependant, c'est si cela met la table hors ligne et s'il y a d'autres problèmes que je devrais être au courant avant d'exécuter cette commande.

J'utilise l'édition Enterprise Edition de 2008 R2, et je me demande si son exécution de cette façon supprimera la nécessité d'une panne?

ALTER TABLE [tablename] REBUILD WITH (ONLINE = ON);  

Est-ce que quelqu'un a de l'expérience avec ça?

Bonne nouvelle: 150 000 enregistrements transférés ne sont pas vraiment mauvais, selon le type de période dont nous parlons. Les enregistrements transférés sont suivis tant que le serveur est en place (avec quelques pièges autour d'un bogue dans des versions spécifiques de 2012/2014 .)

Même lorsqu'il fonctionne en ligne, vos utilisateurs peuvent le remarquer en fonction de votre débit d'E / S, de la taille de la table, du nombre d'index non clusterisés et de vos charges de travail.

Voici comment je m'y attaque:

• Répertorier les tables avec les avertissements des enregistrements transférés de la plus petite à la plus grande taille de table (pas le nombre d'enregistrements transférés)
• Reconstruisez ces tables dans l'ordre, manuellement, quelques-unes à la fois. N'automatisez pas cela - vous voulez avoir une idée de la façon dont votre système réagit à la reconstruction de petites tables. Vous apprendrez assez rapidement si votre serveur peut suivre.
• Gardez un œil sur votre utilisation du journal des transactions. Si votre fichier journal fait 10 Go et que vous essayez de reconstruire un tas de 50 Go, vous pouvez rencontrer des problèmes. Vous pouvez atténuer ces problèmes en augmentant la déconnexion à l'avance pendant les fenêtres de maintenance et en effectuant des sauvegardes de journaux fréquentes pendant que vous effectuez cette opération - mais je vais être honnête, à 150 000 enregistrements transmis sur une période de quelques jours, je ne voudrais pas pas la peine de passer par autant de travail.
• À l'avenir, travaillez avec le fournisseur pour mettre une clé en cluster sur ces tables. Oui, il y a des moments où des tas sont appropriés, mais si vous rencontrez le problème d'enregistrement transféré, vous n'êtes probablement pas dans l'une de ces situations conviviales.