Le redémarrage de SQL Server accélère-t-il?
J'ai remarqué que certains administrateurs de base de données redémarrent SQL Server très fréquemment, parfois même la nuit. Je pense qu'ils le font pour libérer de la mémoire, ou peut-être aussi pour accélérer les requêtes. Je sais qu'après un redémarrage, les plans de requête doivent être recompilés, mais même en incluant cela, je me demande s'il y a un avantage net à cette pratique.
Est-il vrai que le redémarrage quotidien de SQL Server accélère son exécution?
Le redémarrage du serveur est probablement l'une des choses les plus dommageables pour les performances. Cela signifie que vous forcez un cache froid pour les données, un cache froid pour les plans de requête et tous les caches internes SQL Server sont également supprimés dans le processus. Sans oublier qu'en jetant toutes les statistiques collectées dans les statistiques de fonctionnement DMV, vous diminuez vos chances de réussir à enquêter sur quelque chose.
Il n'y a aucune orientation officielle soutenant cette pratique, je ne l'ai jamais vue mentionnée dans aucun travail de bonne pratique réputé, je n'ai jamais entendu parler d'un expert réputé mentionnant cela comme une pratique. Ne le fais pas.
Bien que les autres réponses soient bonnes, il leur manque un élément important: le cache de fichiers de Windows.
Sur Windows 64 bits, il n'y a pas de limite à la quantité de mémoire que Windows utilisera pour mettre en cache les fichiers. Windows peut vider complètement votre système de mémoire, et à ce stade, vous commencerez à échanger sur le disque. Cela a été documenté à quelques endroits:
- https://blogs.msdn.Microsoft.com/ntdebugging/2007/11/27/too-much-cache/
- https://blogs.msdn.Microsoft.com/ntdebugging/2009/02/06/Microsoft-windows-dynamic-cache-service/
- https://blogs.msdn.Microsoft.com/ntdebugging/2007/10/10/the-memory-Shell-game/
En redémarrant SQL Server, vous forcez SQL à abandonner la mémoire, laissant ainsi Windows obtenir plus, et la pagination s'arrête temporairement. SQL redémarrera à une utilisation de la mémoire proche de zéro et augmentera progressivement, et lorsque la boîte manquera de mémoire, le redémarrage aidera temporairement. En redémarrant l'intégralité du système d'exploitation, vous forcerez également l'utilisation du cache de fichiers de Windows.
La vraie solution: arrêtez de copier des fichiers à partir du serveur Windows ou limitez la quantité de cache de fichiers utilisée avec le service de cache de fichiers dynamiques, comme indiqué dans les articles de blog ci-dessus.
Si cela accélère les requêtes, reniflement des paramètres pourrait être impliqué. Si un plan de merde est mis en cache et appliqué à des appels ultérieurs inappropriés, le miracle du redémarrage permet au plan commun/correct d'être mis en cache. Si tel est le cas, il existe des moyens infiniment meilleurs de corriger le comportement, comme d'autres l'ont indiqué. Mais jusqu'à ce qu'ils arrêtent de redémarrer la boîte, il n'y a aucun moyen d'effectuer une analyse des causes profondes.
Vous ne devez pas redémarrer SQL Server sauf si vous avez modifié les propriétés du service ou défini des traces de démarrage que vous souhaitez appliquer immédiatement.
Comme @RemusRusanu a déclaré de nombreux points, il efface beaucoup de caches et oblige SQL Server à faire beaucoup de travail de démarrage inutile.
Il semble que ce serveur ne soit pas un serveur SQL Server/base de données dédié. Il est préférable qu'un serveur de base de données de production n'ait qu'un seul but ... être un serveur de base de données. Dans ce cas, vous devez mettre de côté suffisamment de mémoire et de ressources pour le système d'exploitation et donner tout le reste à SQL Server. Cela vous amènerait à ne pas affamer d'autres applications ou rôles de serveur.
Je suis d'accord avec le sentiment que si vous faites tout correctement, vous n'aurez peut-être pas besoin de redémarrer/redémarrer votre serveur MSSQL.
Pour moi, cela s'applique au scénario où tout le monde est compétent et où vous pouvez tout réparer.
Je ne suis pas DBA. Je suis architecte logiciel et une partie de cela implique de construire des schémas de base de données entiers à partir de zéro et, malheureusement , de travailler avec des bases de données tierces que j'ai absolument NON contrôle.
Les personnes, qui ont créé et entretiennent l'une de nos principales bases de données tierces, l'ont à peine rendue fonctionnelle.
Ai-je mentionné que je ne suis pas non plus un expert en sécurité ou un ingénieur réseau?
- Au moins une mise à jour du système d'exploitation Windows majeure, une mise à jour de sécurité, une mise à jour du BIOS, un Service Pack OS/MSSQL ou une mise à jour cumulative MSSQL sont censées sortir tous les mois ou tous les deux mois.
- Les appliquer en temps opportun signifie redémarrer/redémarrer votre serveur tous les trimestres.
- Même lorsque vous travaillez à l'intérieur d'un intranet, pourquoi n'appliqueriez-vous pas les mises à jour de sécurité?
- Si j'étais autorisé à avoir SSL sur nos sites intranet PHI, je le ferais car aucun réseau n'est infaillible. Je suis paranoïaque je suppose.
Pour moi, la question devient alors: Dois-je redémarrer SQL Server plus souvent que tous les 3 mois?
Planifier des redémarrages pour la promesse d'un pouce supplémentaire de performance, c'est comme danser pour la pluie.
Peut-être que ça viendra, peut-être que ça n'arrivera pas, mais vous ne saurez pas avec certitude ce qui a causé la pluie.
- Si vous constatez une augmentation significative des performances après le redémarrage du serveur en raison d'une maintenance régulière, vous devez rechercher pourquoi cela se produit.
- Si vous rencontrez des problèmes et n'êtes pas sûr de la cause de ces problèmes, alors que vous réduisez vos variables en arrêtant les services et les travaux pour trouver quelque chose comme une fuite de mémoire (dans des cas extrêmes comme celui-ci), vous pouvez redémarrer/redémarrer votre serveur avec certains services activés off (ou traces activées) vous aidera à exclure ces autres services comme cause.
Je n'aime pas vous dire [~ # ~] jamais [~ # ~] devez le redémarrer pour dépanner un émettre ou vérifier le basculement, mais j'ai a un problème avec la planification des redémarrages pour empêcher un problème de performances inconnu de se produire de manière aléatoire.
L'exception niquement à cela est si vous gérez une base de données tierce non fiable où le redémarrer toutes les semaines ou deux semble être le seul moyen de le faire fonctionner et vous n'êtes pas autorisé à le réparer ou même à le toucher.
Même dans ce cas, vous devez rechercher des correctifs, les partager avec le propriétaire et déclencher l'enfer jusqu'à ce qu'il soit résolu.