Avez-vous déjà été amené à mettre à jour votre environnement SQL Server et avez-vous eu besoin de le tester ? Cela peut être un processus difficile, surtout lorsqu’il y a des délais serrés et la nécessité de maintenir les technologies actuelles. Dans cet article, nous discuterons d’une solution rapide pour préparer votre environnement de test sans avoir à manipuler chaque package.

Lors de la création de nouveaux serveurs de test, il peut être nécessaire de modifier les emplacements des journaux, les chaînes de connexion et les requêtes à l’intérieur des packages pour les faire fonctionner dans l’environnement de test. Une solution consiste à créer une entrée CNAME dans DNS avec le nom de l’ancien serveur et à le pointer vers l’adresse IP des nouveaux serveurs. Cependant, cette approche peut ne pas fonctionner lorsque vous avez besoin de tester alors que le serveur de production existe toujours.

Une autre option consiste à créer un nouveau réseau de test, mais cela peut ne pas être réalisable en raison des contraintes de temps et d’équipement. Alors, que pouvez-vous faire ?

La première approche qui vient à l’esprit est de modifier le fichier Hosts sur les serveurs. Cependant, dans Server 2008 R2, ce processus est un peu différent en raison de la nécessité de lancer Notepad en mode administrateur. Même après avoir modifié le fichier Hosts, vous pouvez rencontrer des erreurs lors de la tentative de création d’une connexion dans SSMS, telles qu’une erreur liée à un domaine non approuvé.

Une autre solution consiste à créer un alias sur chacun des serveurs. En configurant la version 32 bits de la configuration du client, vous pouvez créer un alias à utiliser par SSMS. Cela vous permet de faire référence au nom d’alias dans SSMS et d’être redirigé vers les bases de données locales. SQL Agent utilisera également l’alias lorsqu’il tentera de se connecter à un nom de serveur rencontré dans une chaîne de connexion dans un package DTS.

Cependant, il est important de noter que l’alias et la reconfiguration du fichier Hosts ne fonctionnent pas conjointement. Si vous avez des journaux qui sont écrits sur le système de fichiers, ils seront écrits sur le serveur réel et non sur le serveur aliasé. Cela est vrai pour les journaux attachés aux étapes des tâches et les journaux à l’intérieur du package DTS. Pour surmonter cela, il est recommandé d’écrire les journaux dans une table au lieu du système de fichiers. L’écriture des journaux dans une table réduit les modifications requises dans les packages et leurs tâches de l’Agent, ce qui permet des tests plus rapides.

Il convient de mentionner que le changement de l’alias dans la section de configuration du client SQL Native 10.0 peut ne pas donner les résultats souhaités. Par conséquent, il est important de faire preuve de prudence lors de tels changements.

En conclusion, lors des tests des environnements SQL Server, il est crucial de reproduire le plus fidèlement possible l’environnement de production. En utilisant des alias et en écrivant les journaux dans des tables au lieu du système de fichiers, vous pouvez vous assurer que votre environnement de test fonctionne correctement et produit des résultats souhaitables. Cette solution rapide permet de gagner du temps et des efforts, vous permettant de vous concentrer sur les tests et la validation de votre environnement SQL Server.