Tout ce que j'ai lu, c'est à quel point il est potentiellement dommageable d'arrêter SQL Server car il crée un cache froid et aspire la mémoire. Alors , pourquoi quelqu'un besoin d'arrêter le SQL Server? Si vous pouvez fournir des liens vers des articles afin que je puisse en savoir plus, j'apprécierais vraiment!
Cette question a été posée par mon professeur. À moins que ce ne soit une question piège, cela me rend absolument perplexe. Sa question exacte était:
Faites des recherches sur Internet et découvrez pourquoi quelqu'un voudrait arrêter SQL Server. Expliquez votre réponse.
C'était dans le cadre de notre exploration de l'utilisation de SQL Server 2008 R2. Je ne sais pas s'il demande la réponse évidente ou s'il manque quelque chose.
sql-server
sql-server-2008-r2
shutdown
Amerilys
la source
la source
Réponses:
Brent a énuméré des raisons non valides d'arrêter le service, mais il existe également des raisons valables:
la source
Parce qu'ils pensent qu'il y a un problème de mémoire - SQL Server utilise toute la mémoire disponible, jusqu'à son paramètre de mémoire maximale (et même au-delà). "Il doit y avoir une fuite de mémoire - je vais arrêter et redémarrer SQL Server, et voir ce qui se passe." Effectivement, cela libère beaucoup de mémoire (parce que SQL Server ne l'alloue pas tout de suite par défaut), alors ils pensent avoir corrigé le bogue. La prochaine chose que vous savez, c'est qu'ils redémarrent SQL Server chaque semaine.
Parce qu'ils pensent qu'il y a un problème de CPU - les requêtes utiliseront une tonne de ressources CPU, en particulier dans le cas de problèmes de reniflage de paramètres. Les inconnus essaient de se connecter à SQL Server sans connaître la connexion Dedicated Admin Connection (DAC), ne peuvent pas se connecter et manquent d'options. Ils redémarrent parce que les cadres se tiennent derrière eux, voulant une solution rapide.
Parce qu'ils ont entendu dire que cela corrige la corruption - lorsque les gens rencontrent un problème de corruption, ils sont souvent prêts à tout essayer pour y remédier.
Parce qu'ils veulent que la restauration se termine - ils tuent une requête, et elle reste en place pendant un certain temps parce qu'ils ne savaient pas que la restauration d'une requête est à thread unique. Après quelques minutes (ou heures) d'attente, ils redémarrent SQL Server, pensant que la restauration ne sera pas nécessaire lors du redémarrage. Malheureusement, ils ont tort, et SQL Server continue de faire le retour au démarrage.
la source
Une des raisons pourrait être que vous avez acheté du nouveau matériel et migré les bases de données vers ce nouveau serveur. Vous arrêtez maintenant cette instance de serveur sql sur l'ancienne boîte (avec la boîte elle-même) car vous voulez vous assurer que personne ne s'y connecte plus
Vous avez déménagé dans le cloud, la boîte on prem n'est plus nécessaire, elle est fermée, reformatée et réutilisée (si elle n'est pas trop ancienne)
la source
Une raison valable est qu'il existe d'autres logiciels exécutés sur le même serveur qui ont besoin d'une partie de la mémoire du serveur SQL, mais qui ne s'exécutent que quelques fois par mois.
Par exemple, ma femme (un comptable qui souhaite en savoir aussi peu (et pas moins) sur le serveur SQL qui est nécessaire pour faire son travail) a un système basé sur le serveur SQL utilisé par 3 personnes, dont elle pour traiter un très grand ensemble de données, ils le font beaucoup de requêtes ad-hock, mais quelques fois par mois, ils doivent exécuter un moteur de calcul qui se trouve sur le même serveur et accède à la base de données. Le moteur de calcul a besoin de mémoire. Ils n'ont pas de DBA, ils ne peuvent pas obtenir de financement pour plus de matériel, même s'ils le pouvaient, le service informatique (qui en sait moins sur SQL que les comptables) prendrait des mois pour configurer un nouveau matériel et une réinitialisation de SQL serveur leur permet de faire leur travail en tant que comptables. (Le système transactionnel est distinct.)
la source