Forum aux questions sur SQLÉviter les redémarrages, installer plusieurs mises à jour et plus encore

Par Nancy Michell

Éviter les redémarrages

Q Comment puis-je limiter le nombre de redémarrages pendant l'application de correctifs de sécurité ou autres sur le SQL Server et même sur le système d'exploitation en général ?

R Tout d'abord, cela vous intéressera certainement de savoir que la plupart des redémarrages post-installation ne sont pas codés en dur dans l'installateur. Ils sont généralement le résultat de fichiers verrouillés. Cela signifie que l'installateur essaie de mettre à jour les fichiers qui sont en cours d'utilisation (verrouillés) par d'autres applications ou par le système d'exploitation. Il existe une approche simple pour éliminer ces redémarrages, qui consiste à s'assurer qu'aucun processus n'utilise les fichiers en question. Comment est-ce que l'on fait ça ?

La première étape consiste à déterminer les fichiers spécifiques qui étaient utilisés et ont été verrouillés pendant l'installation. La manière la plus simple est de les rechercher dans le registre à HKLM\system\currentcontrolset\control\sessionmanager\pendingfilerenameoperations. Vérifier cette clé de registre est utile pour deux raisons : cela confirme que la demande de redémarrage a bien été causée par des fichiers verrouillés et cela vous indique quels fichiers étaient verrouillés. Si vous les recherchez après l'installation, mais avant le redémarrage, vous serez peut-être en mesure de découvrir ce qui a causé la demande de redémarrage puis de prendre des mesures pour l'éliminer lors d'installations futures.

Vous pouvez rencontrer deux types d'entrées. Si un fichier a été verrouillé en lecture, vous verrez une entrée du type une- ligne-par-fichier qui signifie que le fichier mis à jour est déjà présent sur le disque mais que vous devez nettoyer la copie temporaire qui est encore en cours d'utilisation. Si un fichier a été verrouillé en écriture, vous verrez une entrée du type deux- lignes-par-fichier qui signifie que la mise à jour n'a pas encore été effectuée, que l'application est dans un état inconnu et ne doit pas être utilisée. Tout ça revient pratiquement à s'arrêter au beau milieu de l'installation Dans ce cas, une ligne indique le fichier réel et l'autre pointe vers un fichier temporaire (qui deviendra le fichier réel au redémarrage).

L'étape suivante dépend de plusieurs facteurs, mais le principe est d'identifier quel logiciel utilise les fichiers verrouillés. Utilisez des vérificateurs de dépendance si vous le pouvez ou la base de données DLL HELP sur MSDN® (consultez support.microsoft.com/kb/815065).

Si le logiciel que vous identifiez a un service, arrêtez ce service manuellement puis faites le test à nouveau. Si c'est une application, fermez-la et réessayez. Parfois, plusieurs applications utilisent un fichier unique et vous devez toutes les arrêter.

Le résultat de ces tests (dans votre environnement de test) est une liste d'applications et de services à arrêter dans l'environnement de production avant l'installation. Ainsi, l'environnement de production ne nécessitera pas de redémarrage car aucun logiciel ne continuera à verrouiller les fichiers que l'installateur est en train d'installer. Évidemment, n'oubliez pas de redémarrer chacun d'entre eux une fois l'installation terminée.

La bonne nouvelle à ce sujet est que, généralement, les verrous ne changent pas tant que ça. Donc, une fois que vous aurez compris ce modèle pour vos systèmes, cela vous évitera de nombreux redémarrages pendant toute la durée de vie de votre système.

Une autre astuce mérite d'être citée. Vous pouvez avoir plusieurs versions de SQL Server™ ou un autre produit installés côte à côte et ils peuvent se trouver à différents niveaux de version. Vous devez toujours mettre à jour la version la plus récente en premier. Il y a de bonnes chances que la mise à jour remplace tout par les versions les plus récentes et toutes les autres instances ne s'intéresseront pas du tout au verrouillage. Par exemple, si vous avez trois instances de SQL Server 2000 SP3, la première que vous mettez à niveau vers SP4 mettra à niveau le fichier MSXML3.dll et nécessitera un redémarrage. Supposons que vous effectuiez ce redémarrage maintenant. Vous pouvez alors mettre à niveau les deux instances suivantes vers SP4 sans avoir à redémarrer, car le fichier MSXML3.dll mis à jour est déjà présent. Il en va de même pour la mise à niveau de toutes les instances SQL Server 2005 avant les instances SQL Server 2000 et les instances SQL Server 2000 avant les instances SQL Server 7.0. Il s'agit d'une stratégie de minimisation des redémarrages qui fonctionne véritablement.

En étudiant le sujet, les équipes de développement Microsoft ont beaucoup œuvré pour stopper les redémarrages ou en limiter le nombre dans de nombreux scénarios. Dans la mesure où il s'agit de la rubrique Q&R SQL, prenons SQL Server comme exemple.

Dans SQL Server 2005, l'équipe SQL Server a fractionné le code Microsoft® Data Access Components (MDAC) nécessaire à SQL Server dans SQLNCLI (nouveaux fichiers) au lieu de mettre à jour le MDAC lui-même, puis a déplacé le MDAC en intrabande avec le système d'exploitation. En quoi cela aide-t-il ? Le système d'exploitation Windows® utilise le MDAC et maintient ces fichiers verrouillés. C'est pourquoi la plupart des service packs SQL Server ainsi que d'autres packages vous obligeaient à redémarrer. Désormais, SQL Server peut mettre à jour sa version du MDAC sans toucher aux fichiers MDAC du système d'exploitation en cours d'utilisation, donc vous n'avez pas à redémarrer.

En outre, il existe désormais un vérificateur de dépendance et une pause intégrés à l'installation de SQL Server 2005 SP1. Ceci vous montre ce qui est verrouillé et la cause du verrouillage et vous permet ensuite d'arrêter sur le champ tout ce qui est responsable du verrouillage et de continuer l'installation sans redémarrer. Cela signifie que vous pouvez faire ça en temps réel sans avoir besoin d'un laboratoire d'essai. Évidemment, vous pouvez toujours décider de continuer et effectuer le redémarrage si vous le souhaitez ou si vous en êtes en mode sans assistance. Remarquez combien il devient facile de découvrir ce qui bloque vos fichiers !

De plus, la technologie Microsoft Installer gère aussi beaucoup mieux les PendingFileRenameOperations (PFR) existantes. Vous vous rappelez peut-être que l'installation de SQL Server 2000 bloquait si des fichiers apparaissaient sur la clé de registre que nous avons évoquée plus tôt. L'installation de SQL Server 2005 est assez intelligente pour ne bloquer que si les fichiers appartiennent à SQL Server (ce qui signifie qu'il pourrait y avoir un conflit) et même dans ces cas-là, elle peut souvent explorer en profondeur la clé PFR et la mettre directement à jour sans redémarrer. Cette technologie est incluse à un certain niveau à la fois dans MSI et dans update.exe, qui sont les installateurs Microsoft standard actuels utilisés pour effectuer toutes les mises à jour.

Quelles sont certaines des erreurs connues qui provoquent les redémarrages ? MSXML3.dll est l'une des plus importantes. Ce fichier est toujours verrouillé par le service Windows SVCHost, donc tout ce qui inclut ce service devra redémarrer. Il est aussi présent dans la plupart des piles MDAC (mdac_typ.exe). Heureusement, MDAC est "intrabande" sur Windows Server® 2003 et Windows XP SP2 ou version ultérieure. L'équipe de développement SQL Server a beaucoup œuvré pour dissocier msxmlsql.dll de sorte que les mises à jour de SQL Server n'entraînent pas de redémarrage. Vous pouvez cependant vous attendre à ce que cela arrive de temps à autre. Il n'y a rien que vous puissiez faire dans ce cas - vous pouvez arrêter SVCHost et continuer à exécuter les mises à jour cependant..

De même, les packages update.exe présentent une légère anomalie au niveau du processus de désinstallation. Si vous en désinstallez un, il pose un verrou (en dehors des clés PFR, bien entendu) sur les fichiers en place de l'installateur. Cela évite que d'autres packages update.exe puissent s'exécuter jusqu'à ce que vous redémarriez et enleviez le verrou. La seule chose que vous pouvez faire est d'en être conscient et d'envisager de redémarrer après toute désinstallation de correctif que vous pouvez effectuer..

L'intermittence aussi est un problème Tous les programmes ne sont pas présents à 100 % au niveau d'un fichier. En fait, l'utilisation des DLL partagés est dans la plupart des cas ponctuelle, ce qui signifie que d'autres programmes y accèdent seulement si nécessaire, selon leur propre charge de travail et leurs chemins de code. Cela veut dire que vous pouvez faire le test 10 fois et ne voir aucun fichier verrouillé, puis rencontrer un fichier verrouillé lors du déploiement de production. Il n'existe pas de formule magique, malheureusement. Construisez simplement votre environnement de test un peu comme votre environnement de production, comme vous pouvez, en incluant le chargement (ce qui est un objectif honorable en soi) et exécutez suffisamment de tests pour dépiler ces permutations.

Les service packs SE et les mises à jour vont redémarrer. Remarquez que dans les versions anciennes (Windows 2000, Windows XP et toute version antérieure), l'installation n'est pas finie avant la fin du redémarrage - même si la clé de registre pendingfilerenameoperations est vide. Il existe des opérations d'inscription de package d'exception qui peuvent s'exécuter pour installer du code lors de ce redémarrage. Celles-ci ne font pas même pas partie de la définition du service pack mais sont des commandes intégrées à votre système d'exploitation courant déclenchées par des scénarios de mise à niveau pour permettre à certains morceaux de code que vous utilisez de leur survivre.

Au final, la clé PFR n'effectue pas de vérifications de version de fichier et ne fait pas appliquer un ordre via la sérialisation non plus. Cela signifie qu'elle lance le remplacement de fichiers dans l'ordre dans lequel ils sont répertoriés. Mais le moment où ils sont appliqués sur le disque dur s'est avéré être le moment où le dernier a terminé (non pas le moment où le premier a commencé). C'est logique mais cela signifie que le fait d'avoir deux copies du même fichier sur le même chemin, chacune pointant vers des versions différentes, produira un résultat aléatoire après le redémarrage. Si vous rencontrez cette situation, vous devez vous assurer que le problème est résolu. Si vous n'en êtes pas certain, exécutez simplement les deux installateurs une nouvelle fois après avoir redémarré. Si vous avez les bons fichiers, aucun des deux ne fera quoi que ce soit. Si vous avez les mauvais fichiers, alors le package possédant le fichier correct règlera alors le problème. Honnêtement, c'est une technique à la fois plus rapide et plus sûre que d'essayer de déterminer quel est le résultat voulu.

Installations de plusieurs Service Packs

Q Je possède huit instances en grappes SQL Server 2000 sur un cluster à 4 nœuds et je voudrais installer un SP4 avec un minimum de redémarrages. Puis-je installer SP4 sur les 8 instances successivement et redémarrer tous les nœuds à la fin ?

R Une fois que vous avez fini d'installer une seule instance de SQL Server SP4 - ce qui peut nécessiter un redémarrage - sur un serveur Windows donné (en grappes ou non), vous ne devriez pas avoir à effectuer de redémarrages supplémentaires lors de l'installation de SQL Server SP4 sur toute autre instance SQL Server de cette boîte. Ceci s'explique par le fait que tous les fichiers partagés - outils, MDAC, MSXML, ainsi de suite - sont déjà à la bonne version et, verrouillés ou non, qu'ils ne nécessitent pas une nouvelle mise à jour. Tous les fichiers non partagés sont uniquement utilisés par la première instance et elle sera fermée par l'installation. Il est important de remarquer que l'instance la plus récente de SQL Server doit être mise à jour en premier dans le cas où vous avez des instances multiples de versions multiples.

Exécuter en tant que Service réseau

Q Qu'est-ce que le compte NT AUTHORITY\NETWORK SERVICE exactement et quel est son principal objectif ? De même, quelles sont les implications au niveau sécurité de ce compte, particulièrement s'il est doté de droits sysadmin (sa) ?

R Le compte Service réseau a la même identité (identité machine) que Système sur le réseau mais ses privilèges sont réduits au niveau de la boîte locale. Donc, si un service demande l'accès aux ressources réseau, peut-être pour résoudre des noms de compte avec le contrôleur de domaine, il doit s'exécuter en tant que Système, compte de domaine ou Service réseau. Ce dernier est généralement le choix le plus sûr car il est configuré uniquement pour une boîte locale et même là, ses privilèges sont réduits.

Faire du Service réseau un sysadmin dans SQL Server signifie que tout autre service s'exécutant en tant que Service réseau sur une boîte locale contrôle totalement le serveur. Ceci se produit, par exemple, lorsque le compte de service SQL Server est configuré pour s'exécuter en tant que Service réseau. Faire d'un compte de service SQL Server un membre de sysadmin est nécessaire pour la fonctionnalité du serveur (par exemple, pour permettre des connexions de bouclage). Alors que le fait d'avoir le Service réseau exécuté comme admin sur SQL Server n'est pas une méthode très fiable du point de vue de la sécurité, cela peut (ou non) s'avérer être une meilleure solution que d'utiliser un compte de domaine dans ce but et c'est beaucoup plus fiable que d'avoir SQL Server exécuté en tant que LocalSystem.

Si vous ne voulez pas que le Service réseau ait des privilèges sysadmin, une autre possibilité à envisager est d'utiliser un compte de domaine spécialement dédié pour exécuter SQL Server sur une ou plusieurs installations de Windows NT®.

Les articles suivants peuvent apporter de l'aide : msdn.microsoft.com/library/en-us/dnpag2/html/paght000009.asp et microsoft.com/technet/security/topics/serversecurity/serviceaccount.

Créer plusieurs bases de données

Q Je prévois de partitionner des données dans des bases de données individuelles, peut-être jusqu'à 250 bases de données en ligne à la fois. J'estime que seulement 20 pour cent ne seront utilisés pour des requêtes actives à n'importe quel moment donné. Est-ce mieux d'avoir un plus grand nombre de bases de données ?

R Le nombre de bases de données dans une instance de serveur de base de données doit être motivé par des considérations de fonctionnement et des facteurs administratifs. Il y a très peu de surcharge lors de la création de plusieurs bases de données dans une seule instance de serveur, mais un plus grand nombre de bases de données signifie une surcharge administrative pour les tâches de maintenance comme les sauvegardes et les restaurations, la mise en miroir, les comptes utilisateur et les rôles utilisateur. Les complexités administratives supplémentaires peuvent l'emporter sur les avantages que constituent des bases de données supplémentaires.

En règle générale, toutes les données liées à une application doivent être conservées dans une seule base de données, ce qui rend la récupération après une panne plus facile. Si les données d'une application sont réparties sur plusieurs bases de données, toutes les bases de données doivent être récupérées lors d'un basculement. Cela peut retarder la récupération ou même empêcher une récupération si l'une des bases de données ne peut être récupérée.

Ceci dit, répartir des données sur plusieurs bases de données ne se fait pas sans raisons :

• Un sous-ensemble de données a des exigences de backup différentes par rapport à d'autres données.
• Certaines données ont besoin d'un contexte de sécurité à part, c'est-à-dire un d'un propriétaire de base de données différent.
• Parfois les données existent pour des raisons historiques et doivent être conservées en mode lecture seule.

Merci aux informaticiens Microsoft ci-dessous pour l'apport de leur expertise technique : Ramon Arjona, Frank De Waelle, Robert Djabarov, Herman Learmond-Criqui, Maxwell Myrick, Ruslan Ovechkin, Uttam Parui, Shashi Ramaka, Gary Roos, Gavin Sharpe, Vijay Sirohi, Jimmie Thompson et Madhusudhanan Vadlamaani.

Par Nancy Michell

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.