Discussion :

[Kloun]

Bonjour,

Il me semble avoir lu (sans doute à partir d'un lien de Développez.com) un document indiquant qu'un redémarrage régulier (dans mon cas, toutes les semaines) de SQL Server n'était pas une bonne idée.
Je ne retrouve malheureusement pas le dit document.
Quelqu'un aurait-il un lien à me proposer ?
Merci.

[bvesan]

Bonjour,
Sans connaître l'article que vous avez pu avoir lu sur le sujet, voici quelques conséquences d'un redémarrage d'une instance SQL Server

En quelques mots: SQL Server utilise la mémoire pour accélérer les traitements, principalement en y plaçant une copie des pages de données (tables et indexes) récemment utilisées (Cache de Données), et en stockant les plans d'exécution des requêtes récemment exécutées (Cache de Procédures). Lire une page en mémoire est bien plus rapide (de l'ordre de 1000 à 100 000 fois plus rapide) que la lire sur disque, et exécuter une requête déjà exécutée récemment évite la phase de compilation qui peut prendre plusieurs dizaines de millisecondes.
Redémarrer une instance, c'est (entre autres choses) purger les zones mémoires allouées à l'instance. Donc, tant que les pages fréquemment utilisées n'ont pas été remontées dans le Cache de Données et que les plans d'exécution des principales requêtes n'ont pas été montés dans le Cache de Procédures, les traitements risquent d'être bien plus lents.

A noter que redémarrer une instance, c'est aussi:
rendre l'instance indisponible le temps du redémarrage (...)
Réinitialiser certains compteurs de performances internes à l'instance
Recréer la base TempDB
Interrompre toutes les traces qui ont pu être démarrés manuellement
...

[Kloun]

Merci pour la réponse.
C'est ce que j'avais retenu de cet article "officiel" de Microsoft (il me semble).
J'aimerais bien mettre la main dessus pour le montrer à l'administrateur système qui ne veut pas démordre de l'idée qu'un redémarrage hebdomadaire du serveur est une bonne chose.

[aieeeuuuuu]

Bonjour,

l'administrateur système qui ne veut pas démordre de l'idée qu'un redémarrage hebdomadaire du serveur est une bonne chose.

Quels sont ses arguments ?

(je sent venir un argument shadokien : "mieux vaut redémarrer et qu'il ne se passe rien, que ne pas redémarrer et risquer qu'il se passe quelque chose de pire")

[Kloun]

C'est à peu près ça : "dans le doute reboot, si ça rate, formate."
Heureusement, on en n'est pas à la 2ème partie.
Je voudrais contrer avec quelque chose de factuel, parce que là, on est plus dans les croyances ("il faut rebooter régulièrement un serveur Windows") qu'autre chose.

[mikedavem]

Je crois que l'on ne va pas recopier les arguments que Benjamin donne déjà :-)
Je rajouterais que beaucoup de mes clients mais je n'ai aucun doute sur ceux des autres consultants ou DBA ne redémarrent leurs instances que pour les campagnes de patching.

As-tu confronté les arguments de Benjamin à ton administrateur système ? Qu'en pense-t-il ?

++

[Zabriskir]

Voici un billet de SQLPro sur la sauvegarde avec SQL Server qui évoque le mythe de l'arrêt des serveurs Windows et le redémarrage d'une instance.
http://blog.developpez.com/sqlpro/p7...vec_sql_server

@+

[SQLpro]

Bonjour,

Il me semble avoir lu (sans doute à partir d'un lien de Développez.com) un document indiquant qu'un redémarrage régulier (dans mon cas, toutes les semaines) de SQL Server n'était pas une bonne idée.
Je ne retrouve malheureusement pas le dit document.
Quelqu'un aurait-il un lien à me proposer ?
Merci.

Pour en rajouter une couche, voici ce que je dis dans mon livre à paraître sur SQL Server 2014 :
"

13.2.12 - Arrêt du serveur

Il ne faut jamais arrêter un serveur SQL en production. Outre de vider le cache, ceci fait perdre toutes les statistiques d’exécution accumulées depuis le démarrage du serveur. C’est pourquoi il faut toujours chercher une solution « on line ». C’est la raison même d’exister de la version Datacenter qui permet l’ajout ou le retrait à chaud de CPU et de RAM.
De la même manière arrêter le service SQL Server est déraisonnable. Cherchez les causes de votre problème à coup de requête ceci aura le double avantage de permettre à la fois le diagnostic et la résolution...

PERFORMANCES : tout arrêt de SQL Server ou de la machine pose des problèmes de performance. Dans SQL Server, toutes les opérations peuvent se faire à chaud. Avec la bonne version de Windows, même certaines opérations hardware peuvent s’effectuer alors que la machine fonctionne. N’arrêtez donc jamais ni la machine ni le service SQL Server.

De plus en plus de « Service Pack » ne nécessite pas le redémarrage de la machine (SP pour Windows) ou de l’instance (SP Pour SQL Server). Les SP pour SQL Server devant être passés le plus rapidement possible, profitez de ce moment pour passer les SP de Windows, dont l’urgence est peu importante en général au regard de SQL Server.


"

A +

[escartefigue]

Bonjour,

Ce sujet est récurrent et je suis surpris de ne rien trouver dans la documentation miscrosoft pour alerter sur les dangers d'un arrêt du serveur.

L'éditeur serait muet sur ce chapitre ?

[StringBuilder]

Bonjour,

Ce sujet est récurrent et je suis surpris de ne rien trouver dans la documentation Miscrosoft pour alerter sur les dangers d'un arrêt du serveur.

L'éditeur serait muet sur ce chapitre ?

Une raison courante de ces coupures hebdomadaires (qui mensuelles, quotidiennes, touslesjesaispasquand) est purement liée à Microsoft qui est l'unique responsable : les mises à jour.

Même si depuis quelques temps les mises à jour ne nécessitent plus systématiquement un reboot complet de la machine, il n'en reste pas moins que :
- un nombre important de mises à jour nécessite toujours un redémarrage complet du serveur
- un nombre tout aussi important de mises à jour a pour conséquences le redémarrage de certains services (y compris SQL Server par exemple)
- et toujours un grand nombre de mises à jour a un très gros impact négatif sur les performances du serveur pendant plusieurs minutes (genre le scan anti-virus qui démarre à à la réception de chaque nouvelle définition de virus, mais pas que, la simple installation de certaines mises à jour relance les routines d'optimisation .NET qui plombent les perfs)

Donc pour toutes ces raisons, les sysadmin ont pour habitude de préconiser une coupure régulière du serveur afin de passer les mises à jour (qu'est-ce qui est pire entre avoir un serveur coupé quelques minutes puis lent quelques minutes et un serveur vulnérable ?) et profitent de ce reboot pour "verrouiller" dans les planning fonctionnels une plage de temps pendant laquelle personne ne doit faire de traitement sur le serveur (ni s'offusquer s'il reboote en plein milieu d'un traitement).

Pour administrer en // quelques VM Linux, je suis quand même assez attristé de voir que Microsoft nécessite toujours un reboot aussi souvent.
D'ailleurs, SQL Server sous Linux ne résous rien, car la moindre KB qui passe sur SQL Server va redémarrer l'instance d'après mon expérience !

Bref : si on ne veut pas s'emmerder à suivre au jour le jour le serveur, ni chercher avec le client des créneaux pour rebooter suite à une mise à jour, la plupart des sysadmin imposent dès le départ un créneau régulier, même s'il ne sert à rien 90% du temps.

Reste aussi d'autres arguments plus douteux, hérités de Windows 95 qui de toute façon ne pouvait pas rester allumé plus de 90 jours sans planter (bug dans le noyau, qui n'a jamais été corrigé). On a tours connus Windows pré-2000 avec des serveurs d'une stabilité parfaitement discutable. Les habitudes ont la vie dure chez les sysadmin qui n'ont généralement pas envie d'engager leur responsabilité quand il peuvent suivre quelques proverbes Shadocks.

[vanagreg]

Question d'habitude, à chaque fois qu'on a des merdes avec Windows on est obligé de redémarrer C'est un peu comme tirer la chasse. D'ailleurs ça me fait toujours marrer quand des soit disant DBA Oracle veulent redémarrer l'instance dès qu'ils ne trouvent pas ce qui cloche

[mikedavem]

Une raison courante de ces coupures hebdomadaires (qui mensuelles, quotidiennes, touslesjesaispasquand) est purement liée à Microsoft qui est l'unique responsable : les mises à jour.

Très juste mais en contrepartie contrairement aux mythes / rumeurs les produits qui présentent le plus de vulnérabilités ne fonctionnent pas sur Windows (https://thebestvpn.com/vulnerability-alerts/)

Même si depuis quelques temps les mises à jour ne nécessitent plus systématiquement un reboot complet de la machine, il n'en reste pas moins que :
- un nombre important de mises à jour nécessite toujours un redémarrage complet du serveur
- un nombre tout aussi important de mises à jour a pour conséquences le redémarrage de certains services (y compris SQL Server par exemple)
- et toujours un grand nombre de mises à jour a un très gros impact négatif sur les performances du serveur pendant plusieurs minutes (genre le scan anti-virus qui démarre à à la réception de chaque nouvelle définition de virus, mais pas que, la simple installation de certaines mises à jour relance les routines d'optimisation .NET qui plombent les perfs)

D'où l'intérêt d'avoir du Windows Core ici qui réduit drastiquement le nb de mises à jour Windows où d'avoir des campagnes de mises à jour raisonnables.
La réduction de l'impact de maintenance peut aussi se faire au travers d'architecture de HA si cela s'avère nécessaire. Certainement plus cher mais quid de l'impact d'une maintenance pour le client ?

Pour administrer en // quelques VM Linux, je suis quand même assez attristé de voir que Microsoft nécessite toujours un reboot aussi souvent.
D'ailleurs, SQL Server sous Linux ne résous rien, car la moindre KB qui passe sur SQL Server va redémarrer l'instance d'après mon expérience !

Juste mais comme bcp de produits de bases de données. La grosse différence c'est qu'avec Linux, les mises à jour de l'OS sont moins fréquentes car souvent plus périlleuses

Bref : si on ne veut pas s'emmerder à suivre au jour le jour le serveur, ni chercher avec le client des créneaux pour rebooter suite à une mise à jour, la plupart des sysadmin imposent dès le départ un créneau régulier, même s'il ne sert à rien 90% du temps.

Tout dépend le contexte mais je dirai oui dns 90% des cas que j'ai pu voir.