Attention aux conséquences d’un manque d’informations

ne disent pas tout. Commencez par compiler une liste complète des serveurs connus ou d’autres machines de votre réseau sur lesquelles SQL Server est installé. Bien que la majorité des clients pensent connaître tout leur parc SQL Server, ce n’est en fait pas le cas. Après avoir établi cette liste, utilisez un outil tiers (par ex., Reporter de Quest Software) ou un utilitaire maison (qui exploite WMI) pour interroger toutes les machines du réseau qui ont de près ou de loin une ressource SQL Server (y compris les produits tels que MSDE).

Ensuite, comparez les listes afin de détecter d’éventuelles nouvelles installations de SQL Server. Si les listes ne concordent pas, déterminez les propriétaires des nouvelles instances identifiées, l’utilisation qu’ils en font et la raison pour laquelle vous n’avez pas connaissance de leur existence. Ensuite, enregistrez tous les aspects relatifs à SQL Server (par ex. les informations sur l’ordinateur physique telles que le type et la vitesse du processeur, la marque, le modèle ; tous les paramètres du système d’exploitation, y compris les versions des pilotes, les Services Packs et les correctifs ; la configuration des instances, notamment les options et paramètres de niveau serveur, la page de codes, la sécurité, les tâches et les lots DTS ou packages SSIS ; la configuration des bases de données, y compris les options et la taille des bases de données, l’espace disponible et la taille de chaque fichier).

Consignez ces informations pour chaque ordinateur et instance SQL Server identifiés. Au final, ces informations détaillées vous aideront à déterminer les bases de données combinables avec d’autres sur une instance spécifique de SQL Server, ainsi que les bases de données capables de travailler ensemble. Les informations documentées influeront sur de nombreux aspects de votre évaluation de la consolidation et de votre plan correspondant, y compris sur votre décision concernant le standard d’instance final (par ex., la version de SQL Server et les formes de haute disponibilité que vous pourriez déployer).

La documentation servira également de référence si vous déplacez une base de données et qu’une personne doit savoir d’où elle provient et si vous avez déplacé, reconfiguré ou recréé des objets tels que les tâches, les lots DTS ou les packages SSIS et la réplication. Cela constituera peut-être votre unique chance d’obtenir un instantané exhaustif de votre environnement SQL Server. Bien que la majorité des DBA n’effectuent pas un suivi des informations d’historique concernant chaque base de données, vous avez besoin de ces informations (par ex., utilisation de la base de données, modèles de croissance, y compris la taille des sauvegardes de base de données).

Ainsi, si une base de données est en production depuis deux ans, le fait de connaître son modèle de croissance peut vous aider à déterminer l’espace de stockage éventuellement nécessaire dans l’avenir. Se contenter de la meilleure estimation possible ne constitue pas une méthode efficace pour dimensionner un environnement. En l’absence d’informations précises, votre proposition peut aboutir à un environnement sous-dimensionné ou largement surdimensionné.