Restart the Database Engine service

Version imprimable

27/08/2010, 15h24
zinzineti

Restart the Database Engine service

Bonjour,

Contexte
---------------------
Sous SQL Server 2005 lorsqu'on modifie les paramètres de configuration (par exemple le "remote connections") via l'IHM " SQL Server Surface Area Configuration" il y a souvent un message qui demande de redémarrer le service du moteur SQL pour la modification soit effective

Citation:

Changes to Connection Settings will not take effect until you restart the Database Engine service.

Question
---------------------
Existe-t-il une solution pour éviter celà ?

Inquiétudes
---------------------
Pourquoi je souhaite éviter de redémarrer le service du moteur de base ?

Parce qu'il me semble que redémarrer le service peut entrainer pour une instance en production :

- des défauts d'intégrité des bases de données de l'instance concernée

- la perte des caches

- ré-initialisation des valeurs des indicateurs de performances

- ...

Merci de m'éclairer

A+
27/08/2010, 15h41
kagemaru

salut

Tu peux trouver ici la liste des paramètres de configuration. Certains sont statiques et nécessitent le redémarrage de ton instance, d'autres sont dynamiques et pris en compte immédiatement. Il n'y a pas grand chose à faire pour éviter cela.

http://msdn.microsoft.com/en-us/libr...SQL.90%29.aspx.

Citation:

- des défauts d'intégrité des bases de données de l'instance concernée

Pourquoi l'arrêt d'une instance génèrait des défauts d'intégrité ?
27/08/2010, 16h15
mikedavem

Citation:

des défauts d'intégrité des bases de données de l'instance concernée

Si l'instance est redémarrée correctement il n'y aura en principe aucun défaut d'intégrité.

Avec la vue sys.configurations tu peux avoir un apercçu des options qui vont nécessité un redémarre ou pas (colonne is_dynamic)

++
27/08/2010, 16h15
zinzineti

Citation:

Envoyé par kagemaru

salut

Tu peux trouver ici la liste des paramètres de configuration. Certains sont statiques et nécessitent le redémarrage de ton instance, d'autres sont dynamiques et pris en compte immédiatement. Il n'y a pas grand chose à faire pour éviter cela.

http://msdn.microsoft.com/en-us/libr...SQL.90%29.aspx.

Pourquoi l'arrêt d'une instance génèrait des défauts d'intégrité ?

Merci kagemaru pour le lien.

Pourquoi l'arrêt d'une instance peut entrainer des défauts d'intégrité ?

Si l'arrêt du service est brutal (par exemple via services.msc) il peut y avoir des problèmes d'intégrités. c'est d'ailleurs pourquoi il est conseillé d'arrêter/redémarrer les services SQL via SQL Configuration manager.

A+
27/08/2010, 16h23
zinzineti

Ok, donc pour les paramètres de configuration qui nécessite le redémarrage de l'instance, il y a aucun moyen pour éviter de :

- perdre des caches

- ré-initialiser les valeurs des indicateurs de performances ?

C'est quand même embêtant !?
27/08/2010, 16h32
Invité

Citation:

Envoyé par zinzineti

C'est quand même embêtant !?

Non, parce que ce sont des paramètres que tu ne changes pas tous les jours.
27/08/2010, 16h40
mikedavem

Citation:

Pourquoi l'arrêt d'une instance peut entrainer des défauts d'intégrité ?

Si l'arrêt du service est brutal (par exemple via services.msc) il peut y avoir des problèmes d'intégrités. c'est d'ailleurs pourquoi il est conseillé d'arrêter/redémarrer les services SQL via SQL Configuration manager.

Les seuls cas où il est plus que conseillé (ou intéressant) d'utiliser le configuration manager de SQL Server plutôt que la console d'administration des services Windows est le changement de compte d'un des services SQL Server. Le configuration manager exécute des opérations en plus tel que le paramétrage de sécurité de la registry pour le nouveau compte ...

De plus le changement de mot passe par le configuration manager ne nécessitera pas de redémarrage du service SQL Server concerné.

Il n'y aura aucune perte d'intégrité si le serveur de bases de données est arrêté par la console de gestion des services Windows ou par une simple commande net stop mssqlserver ...

Citation:

Ok, donc pour les paramètres de configuration qui nécessite le redémarrage de l'instance, il y a aucun moyen pour éviter de ...

Non effectivement ...

++
27/08/2010, 16h48
zinzineti

Citation:

Envoyé par Jerome_Mtl

Non, parce que ce sont des paramètres que tu ne changes pas tous les jours.

Dans tous les cas du moment où on perd les caches, celà veut dire qu'il y aura d'impact sur la performance du serveur ? Non ?
Et la question c'est : au bout de combien temps le moteur SQL va retrouver son fonctionnement optimal à la suite de cette perte de cache ?
27/08/2010, 16h54
Ptit_Dje

Citation:

Envoyé par zinzineti

Dans tous les cas du moment où on perd les caches, celà veut dire qu'il y aura d'impact sur la performance du serveur ? Non ?
Et la question c'est : au bout de combien temps le moteur SQL va retrouver son fonctionnement optimal à la suite de cette perte de cache ?

Ca depend de la taille de ta RAM et de l'activite de ton serveur.
Lorsqu'il est vraiment utiliser, compte 5-10 minutes... Et encore...
27/08/2010, 16h55
Invité

Citation:

Envoyé par zinzineti

au bout de combien temps le moteur SQL va retrouver son fonctionnement optimal à la suite de cette perte de cache ?

Réponse de Normand (mais pas Normand Lamour...) : ça dépend de l'activité sur ta bd...
27/08/2010, 17h00
kagemaru

Citation:

Et la question c'est : au bout de combien temps le moteur SQL va retrouver son fonctionnement optimal à la suite de cette perte de cache ?

Je crois que cela dépend vraiment du type d'application et du nb d'utilisateurs présents après le redémarrage de l'instance.

Une technique de "préchauffage" de cache est de faire des SELECT de certains tables très utilisées juste après le redémarrage.

Une autre technique (un peu extrême) est de basculer ton appli sur ta base miroir (les pages de données modifiées sont alors en cache), de redémarrer ton instance primaire. Mais le cache est disons ..... tiède. Donc ce n'est pas non plus la panacée.
27/08/2010, 17h00
zinzineti

Citation:

Envoyé par Jerome_Mtl

Réponse de Normand (mais pas Normand Lamour...) : ça dépend de l'activité sur ta bd...

Excellent :)

Donc plus il y a d'activités sur l'instance, plus vite les choses rentreront dans l'ordre.

Bon il y a pas vraiment d'inquiétude à avoir à ce niveau là ?

A+
27/08/2010, 17h01
dbaffaleuf

Citation:

Envoyé par zinzineti

Inquiétudes
---------------------
Pourquoi je souhaite éviter de redémarrer le service du moteur de base ?

Parce qu'il me semble que redémarrer le service peut entrainer pour une instance en production :
- des défauts d'intégrité des bases de données de l'instance concernée
- la perte des caches
- ré-initialisation des valeurs des indicateurs de performances
- ...

Des défauts d'intégrité, heureusement que non. Un arrêt par le gestionnaire de services exécute un checkpoint dans chaque base avant de fermer, et de toutes façons, le recovery est éxecuté dans chaque base au démarrage suivant.
27/08/2010, 17h05
zinzineti

Citation:

Envoyé par kagemaru

Une technique de "préchauffage" de cache est de faire des SELECT de certains tables très utilisées juste après le redémarrage.

Des SELECT du genre :

Code:

WHILE (1 = 1 ) SELECT ...

?
27/08/2010, 17h09
zinzineti

Citation:

Envoyé par dbaffaleuf

Des défauts d'intégrité, heureusement que non. Un arrêt par le gestionnaire de services exécute un checkpoint dans chaque base avant de fermer, et de toutes façons, le recovery est éxecuté dans chaque base au démarrage suivant.

Ok, donc j'ai rien dit concernant les défauts d'intégrité ;)

Merci David :ccool:
27/08/2010, 17h10
mikedavem

Un peu de lecture si ça te dit au passage ;)

++
27/08/2010, 22h45
kagemaru

Code:

WHILE (1 = 1 ) SELECT ...

Il suffit de lire une première fois la donnée pour que le deuxième lecture soit une lecture logique (sauf si le buffer cache est trop petit). Donc un simple SELECT * (ou des colonnes nécessaires si on les connait bien) des tables importantes.

Citation:

Réponse de Normand (mais pas Normand Lamour...) : ça dépend de l'activité sur ta bd...

hé c'est de la dynamite :yaisse3:, en plus le gars a débuté sa carrière à 68 ans, repect !! :P
01/09/2010, 11h59
Bluedeep

Citation:

Envoyé par zinzineti

Excellent :)

Donc plus il y a d'activités sur l'instance, plus vite les choses rentreront dans l'ordre.

Bon il y a pas vraiment d'inquiétude à avoir à ce niveau là ?

A+

Absolument aucune : il faur savoir que l'arrêt d'un service sous windows se fait par un dialogue. Le SCM (Service Control Manager) notifie le service qu'il va être stoppé, et l'arrêt effectif n'intervient qu'au retour de la méthode de notification. Si le service ne retourne pas sur sa notification d'arrêt, un message d'erreur est envoyé par le SCM et le service n'est pas arrêté.

Tous les services (a fortiori Sql Server) ont une méthode de terminaison "propre".
01/09/2010, 12h47
zinzineti

Citation:

Envoyé par Bluedeep

Absolument aucune : il faur savoir que l'arrêt d'un service sous windows se fait par un dialogue. Le SCM (Service Control Manager) notifie le service qu'il va être stoppé, et l'arrêt effectif n'intervient qu'au retour de la méthode de notification. Si le service ne retourne pas sur sa notification d'arrêt, un message d'erreur est envoyé par le SCM et le service n'est pas arrêté.

Tous les services (a fortiori Sql Server) ont une méthode de terminaison "propre".

Merci pour toutes informations :ccool:
01/09/2010, 12h53
Ptit_Dje

Un petit NB au passage:
Dans un environnement clusteriser, il est preferable de terminer le service au moyen de l'outil de gestion du cluster.
Sinon le service bascule sur un autre noeud.

Citation:

Envoyé par Bluedeep

Tous les services (a fortiori Sql Server) ont une méthode de terminaison "propre".

Je ne suis pas convaincu. Lorsqu'il reçoit un SERVICE_CONTROL_STOP, SQL Server effectue un checkpoint dans chaque base et termine les connexions en cours. Au redémarrage, un recovery sera effectué. S'il y avait une grosse transaction en cours, la mise en ligne de la base sera d'autant rallongée (sauf fast recovery en édition Enterprise, encore que... de toutes façons les pages impliquées dans le rollback seront verrouillées donc pas accessibles à la fin du REDO):
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 (...) Analysis of database 'CAPDATA' (5) is 75% complete (approximately 0 seconds remain). This is an informational message only. No user action is required. Analysis of database 'CAPDATA' (5) is 100% complete (approximately 0 seconds remain). This is an informational message only. No user action is required. Recovery of database 'CAPDATA' (5) is 0% complete (approximately 83 seconds remain). Phase 2 of 3. This is an informational message only. No user action is required. Using 'xpstar90.dll' version '2005.90.4035' to execute extended stored procedure 'xp_readerrorlog'. This is an informational message only; no user action is required. Recovery of database 'CAPDATA' (5) is 2% complete (approximately 44 seconds remain). Phase 2 of 3. This is an informational message only. No user action is required. Recovery of database 'CAPDATA' (5) is 2% complete (approximately 44 seconds remain). Phase 3 of 3. This is an informational message only. No user action is required. (...) Recovery of database 'CAPDATA' (5) is 100% complete (approximately 0 seconds remain). Phase 3 of 3. This is an informational message only. No user action is required. 1 transactions rolled back in database 'CAPDATA' (5). This is an informational message only. No user action is required. Recovery is writing a checkpoint in database 'CAPDATA' (5). This is an informational message only. No user action is required. Recovery is complete. This is an informational message only. No user action is required. (...)
Si ça fait suite à un arrêt électrique par exemple, et qu'au redémarrage un des disques du journal de transaction grille, le recovery ne pourra pas se faire sur la base et elle passera en suspect. C'est pour ça que je ne mettrai pas 10/10 à la méthode d'arrêt de SQL Server.

Sachant que contrairement à Sybase ASE qui attend la fermeture des connexions sur un 'shutdown' classique, le 'shudown' SQL Server termine lui aussi les transactions en cours comme un gros sagouin. :(