J'ai récemment repris un projet et ils ont une configuration de travail SQL pour fonctionner toutes les trois heures qui reconstruisent les index trouvés dans les tables de base de données ASP.NET.
Cela semble assez élevé, de reconstruire des index 8 fois par jour. Je reçois environ 2000 nouveaux utilisateurs tous les jours et un total d'environ 2 millions d'utilisateurs enregistrés.
Que recommanderiez-vous pour un calendrier de reconstruction d'index approprié?
4 Réponses :
La reconstruction a-t-elle blessé la stabilité du système ou prend trop de temps système?
Si vous répondez non - ne le touchez pas :)
Cela ne semble pas, mais je reçois quelques problèmes d'impasse tout au long de la journée liés à la nouvelle inscription à l'utilisateur. Je me demandais si cela se produisait à cause de la reconstruction de l'index.
Dépend si vous faites une reconstruction en ligne ou hors ligne. Si son déconnecté, alors oui, il peut provoquer des blocages car il place un verrou de lecture sur l'index. Si c'est en ligne, cela ne place que un serrure de schéma sur l'index.
Vos blocages peuvent certainement être liés à la reconstruction des index. Il ne fait aucun doute que ces index n'ont pas besoin d'être reconstruits fréquemment. Au minimum, vous devriez envisager d'utiliser l'option en ligne si vous le permettez de conserver l'index d'être déposé avant sa reconstruction.
Voici une ligne directrice que nous utilisons:
Index doit être reconstruit lors de l'index La fragmentation est supérieure à 40%. Indice devrait être réorganisé lorsque l'index La fragmentation est comprise entre 10% et 40%. Le processus de reconstruction d'index utilise plus de CPU et il verrouille les ressources de la base de données. Version de développement SQL Server et Enterprise version a option en ligne, qui peut être allumé lorsque l'index est reconstruit. L'option en ligne conservera l'index disponible pendant la reconstruction.
Capturez le graphique de l'impasse et vous avez une réponse réelle de ce qui est une mauvaise manipulation, par opposition à un devinez . Étant donné que cette impasse est (ou au moins devrait être) une occurrence assez rare (moins de 10 / seconde), vous pouvez joindre en toute sécurité le profileur sur une longue période et capturer seul le
Une bonne règle de base est de reconstruire lorsque plus de 30% fragmentés, réorganisent de 10% et 30%.
Ne vous inquiétez pas avec les tables inférieures à 1000 pages, vous ne remarquerez pas, et même après avoir exécuté une reconstruction pour une plus de 30%, il restera souvent à 30%.
Vous devriez probablement viser à reconstruire / réorganiser assez rarement, chaque semaine au plus pour une base de données moyenne. Si vous devez défragmenter les index plus souvent que cela, vous devez probablement retenir vos facteurs de remplissage et votre rembourrage.
Une exception est après le chargement des données en vrac, où il pourrait être courant d'avoir fragmenté les index (parfois mieux de désactiver l'index ou de déposer les index et de reconstruire ou de les reconstruire en fonction des données chargées).
Donc, en résumé, 8 fois par jour semble excessive.
Références:
http://technet.microsoft.com/en-us/library/ms189858.aspx
http: //www.sqllusings. COM / 2009/03/15 / A-plus-véritable-index sélectif-index-reconstituer-stratégie /
http://realworlddba.wordpress.com/2008/ 01/27 / index à la reconstruction-ou-réorganisation /
http://realworlddba.wordpress.com/2008/ 01/27 / index à la reconstruction-ou-réorganisation /