SQL Server - Arrêt et redémarrage d’instance SQL Server… Bonne pratique ou pas ? Par SQLpro

Version imprimable

30/05/2022, 03h52
SQLpro

SQL Server - Arrêt et redémarrage d’instance SQL Server… Bonne pratique ou pas ? Par SQLpro

Chers membres du club,

J'ai le plaisir de vous présenter cet article :

SQL Server - Arrêt et redémarrage d’instance SQL Server… Bonne pratique ou pas ?

Citation:

Parmi les pires pratiques que l’on rencontre encore couramment au sujet de Microsoft SQL Server, il y a le fait que redémarrer une instance régulièrement serait bénéfique pour les bases de données d’une instance SQL Server. Ceci est faux et c’est bien tout le contraire qui se produit. Explications…

Bonne lecture ;)

:fleche: Les meilleurs cours et tutoriels pour apprendre Microsoft SQL Server.

:fleche: Retrouvez les meilleurs cours et tutoriels pour apprendre les SGBD et SQL.
01/06/2022, 18h19
chrtophe

Article intéressant, bien que pour moi, hors de mon domaine de compétence.

si elles ont un intérêt pertinent comme expliqué, je trouve étonnant que les stats ne soient pas conservées en cas d'arrêt propre, ou au moins qu'il y est une option.
Après je suppose qu'il est possible de les récupérer via une requête.
03/06/2022, 18h09
cd090580

Article très intéressant mais comment éviter et/ou gérer les redémarrages fréquents du serveur quand Microsoft impose de redémarrer l'OS suite aux correctifs installés mensuellement ????????

Dans ce cas on perd tous les bénéfices des stats et autres caches gérés par SQL Server sur la durée
09/06/2022, 14h44
SQLpro

C'est effectivement un problème. Mais il n'est pas absolument nécessaire de passer tous les correctifs immédiatement (en particulier les correctifs Windows sont de peu d'intérêt au regard de SQL Server). En effet, la plupart ne concernent pas des problématique de sécurité. On peut donc les retarder et les appliquer dans des plages définies à l'avance. De plus l'utilisation de réplicas de type AlwaysOn minimise ce problème dans le sens ou les caches des réplicas contiennent au moins les données mises à jour, voir si les réplicas sont lisible, une partie des données lues. Dans ce cas, il faut alterner l'application des correctifs et resté sur l'instance basculée.

A +
09/06/2022, 19h12
chrtophe

Citation:

De plus l'utilisation de réplicas de type AlwaysOn minimise ce problème

Il te faut donc 2 nœuds. Dans le cas d'un seul serveur on fait comment ?
10/06/2022, 18h16
mikedavem

Citation:

Envoyé par chrtophe

Il te faut donc 2 nœuds. Dans le cas d'un seul serveur on fait comment ?

Si pas de mécanisme de HA comme AlwaysOn et les groupes de disponibilité, en fonction de l'impact on peut avoir un calendrier des mise à jours Windows moins fréquent pour minimiser l'indisponibilité de service. Pas trop le choix je dirai ...
Si la disponibilité du service est quelque chose d'important alors s'orienter vers des architectures comme les AGs est quelque chose à considérer.

++
11/06/2022, 17h15
Pomalaix

Pour faire mon SQLPro, il y a une solution très simple à la problématique :mouarf: : passer à Oracle où le mécanisme AWR, présent depuis près de 20 ans, permet d'historiser de manière persistante une multitude de métriques de performances.
Il est surprenant que Microsoft n'ait pas été capable de fournir d'équivalent.
11/06/2022, 18h42
chrtophe

Comme je le disais, je pense qu'il est possible de récupérer les données avant reboot.
13/06/2022, 07h24
mikedavem

Citation:

Envoyé par Pomalaix

Pour faire mon SQLPro, il y a une solution très simple à la problématique :mouarf: : passer à Oracle où le mécanisme AWR, présent depuis près de 20 ans, permet d'historiser de manière persistante une multitude de métriques de performances.
Il est surprenant que Microsoft n'ait pas été capable de fournir d'équivalent.

Il y a aussi des outils qui permettent de faire cela avec SQL Server avec Data Collector ou Query Store (pas aussi abouti que AWR cependant). Bon si je devais faire mon SQLPro aussi :mouarf: je dirai qu'il te faudrait en plus payer pour avoir les options qui vont bien avec AWR. Ceci étant dit il existe une multitude d'outils externes à Microsoft qui permettent de faire ce que AWR fait sur Oracle auj.

De notre côté nous utilisons une stack open source Telegraf + Prometheus + Grafana qui répond très bien au besoin.

++
13/06/2022, 15h41
SQLpro

Citation:

Envoyé par chrtophe

Comme je le disais, je pense qu'il est possible de récupérer les données avant reboot.

Oui, mais pas de les réinjecter...

A +
13/06/2022, 15h43
SQLpro

Citation:

Envoyé par mikedavem

Il y a aussi des outils qui permettent de faire cela avec SQL Server avec Data Collector ou Query Store (pas aussi abouti que AWR cependant). Bon si je devais faire mon SQLPro aussi :mouarf: je dirai qu'il te faudrait en plus payer pour avoir les options qui vont bien avec AWR. Ceci étant dit il existe une multitude d'outils externes à Microsoft qui permettent de faire ce que AWR fait sur Oracle auj.

De notre côté nous utilisons une stack open source Telegraf + Prometheus + Grafana qui répond très bien au besoin.

++

Tu as oublié les "report" de SSMS qui sont assez nombreux et que d'autres ont complétés comme notre ami Arian Papillon de DataFly :
https://github.com/datafly/SSMSInfoReports

A +
13/06/2022, 19h28
chrtophe

Citation:

Oui, mais pas de les réinjecter...

ca je m'en doutais, mais ça permet d'avoir un historique en cas de reboot le temps que les métadonnées se reconstituent
14/06/2022, 14h02
mikedavem

Citation:

Envoyé par SQLpro

Tu as oublié les "report" de SSMS qui sont assez nombreux et que d'autres ont complétés comme notre ami Arian Papillon de DataFly :
https://github.com/datafly/SSMSInfoReports
A +

Pas oublié non mais les rapports SSMS se basent souvent sur des données live non historisées par défaut mais cela n'enlève rien à leur intérêt et ainsi que ceux proposés Arian également :)