Applications

compiler une liste de toutes vos applications, de leurs propriétaires, de leurs contrats de niveau de service (SLA) et de leur utilisation dans l’environnement. Il existe deux types d’applications : celles que vous achetez et celles développées en interne.

Bien que certaines des informations dont vous avez besoin sur chacun des deux types diffèrent, ces applications ont de nombreux aspects en commun. Ainsi, vous avez besoin de connaître le modèle de sécurité de l’application (authentification Windows ou SQL Server) et si l’association des bases de données de l’application avec des bases de données d’autres applications envisagées pourra fonctionner. Par exemple, supposons que deux de vos applications utilisent l’authentification SQL Server et ont un login nommé Sally.

Dans une application, Sally a besoin des privilèges d’administrateur système (sa) sur SQL Server, alors qu’elle dispose uniquement d’un accès en lecture seule à la base de données de l’autre application. Comme les droits de Sally incluent déjà l’accès sa, vous allez très probablement relever inutilement les droits de Sally dans la deuxième application. Par conséquent, ces applications se prêtent peu à une consolidation sur la même instance SQL Server. Vous devez également connaître la version de SQL Server sur laquelle une application a été testée.

Cet aspect est particulièrement important car nombre de DBA souhaiteront profiter de la consolidation pour passer à SQL Server 2005. Les éditeurs tiers n’ont pas tous certifié leurs applications sur cette nouvelle mouture de SQL Server, et même s’ils l’ont fait, leurs applications ne sont peut-être pas certifiées vis-à-vis du Service Pack 1 (SP1) ou du SP2 du produit. Par conséquent, si vous décidez de normaliser l’environnement sur SQL Server 2005 Service Pack 2 et si une application ne prend en charge que la RTM, vous devez soit laisser l’application telle quelle, soit la déployer de manière consolidée au moyen de la RTM car SQL Server gère les niveaux d’instance mixtes.

Si vous n’identifiez pas ces types de besoins pendant l’évaluation, vous aboutirez à une incompatibilité entre l’instance SQL Server et l’application au moment de planifier et de déployer votre environnement consolidé. De même, vous n’avez probablement pas encore testé vos applications maison sur SQL Server 2005. S’il s’agit de la version que vous allez employer, vous prenez un gros risque en supposant que vos applications fonctionneront. Même si, au final, vous utilisez SQL Server 2000 (par ex., SQL Server 2000 SP4), les mêmes règles s’appliquent. Vous devez collaborer avec les équipes internes compétentes pour vous assurer que tout fonctionnera correctement après la consolidation. Pour terminer, vous devez connaître les dépendances de chaque application et vous assurer qu’elles sont documentées.

Une dépendance peut prendre n’importe quelle forme, y compris des chaînes de connexion à d’autres serveurs (en incluant tous les aspects dans la chaîne jusqu’à votre serveur Active Directory). En particulier, vous devez prendre en compte le mode de connexion de chaque serveur d’applications au serveur de base de données, afin que vous puissiez reconfigurer correctement chaque application après la consolidation. Ne partez jamais du principe que le déplacement d’une base de données vers un autre ordinateur SQL Server constitue un processus transparent. Cela peut affecter la disponibilité d’autres applications et serveurs. Vous devez identifier ces risques pendant l’évaluation, afin de prévoir soigneusement le déplacement de la base de données lors de la planification de la consolidation.