Observations relatives à l'utilisation de serveurs de test

L’utilisation d’un serveur de test pour paramétrer une base de données sur un serveur de production est un avantage important de l’Assistant Paramétrage du moteur de base de données. À l’aide de cette fonctionnalité, vous pouvez décharger la surcharge de paramétrage sur un serveur de test sans copier les données réelles sur le serveur de test à partir du serveur de production.

Pour utiliser cette fonctionnalité, passez en revue les considérations répertoriées dans les sections suivantes.

Configuration de l’environnement serveur de test/serveur de production

• L’utilisateur qui souhaite utiliser un serveur de test pour régler une base de données sur un serveur de production doit exister sur les deux serveurs, ou ce scénario ne fonctionnera pas.

• La procédure stockée étendue, xp_msver, doit être activée pour utiliser le scénario de serveur de test/serveur de production. L’Assistant Paramétrage du moteur de base de données utilise cette procédure stockée étendue pour extraire le nombre de processeurs et la mémoire disponible du serveur de production à utiliser lors du paramétrage du serveur de test. Si xp_msver n’est pas activé, l’Assistant Paramétrage du moteur de base de données suppose les caractéristiques matérielles de l’ordinateur sur lequel l’Assistant Paramétrage du moteur de base de données est en cours d’exécution. Si les caractéristiques matérielles de l’ordinateur sur lequel l’Assistant Paramétrage du moteur de base de données s’exécute ne sont pas disponibles, un processeur et 1024 mégaoctets (MB) de mémoire sont supposés. Cette procédure stockée étendue est activée par défaut lorsque vous installez SQL Server. Pour plus d’informations, consultez Configuration de surface d’exposition et xp_msver (Transact-SQL).

• L’Assistant Paramétrage du moteur de base de données s’attend à ce que les éditions de SQL Server soient identiques sur le serveur de test et le serveur de production. S’il existe deux éditions différentes, l’édition sur le serveur de test est prioritaire. Par exemple, si le serveur de test exécute SQL Server Standard, l’Assistant Paramétrage du moteur de base de données n’inclut pas les vues indexées, le partitionnement et les opérations en ligne dans ses recommandations, même si le serveur de production exécute SQL Server Enterprise.

À propos du comportement du serveur de test/serveur de production

• L’Assistant Paramétrage du moteur de base de données prend en compte les différences matérielles entre la production et le serveur de test lors de la création de recommandations. La recommandation est la même que si le réglage a été effectué sur le serveur de production seul.

• L’Assistant Paramétrage du moteur de base de données peut imposer une charge sur le serveur de production pour collecter les métadonnées, ainsi que la création de statistiques nécessaires au réglage.

• L’Assistant Paramétrage du moteur de base de données ne copie pas de données réelles du serveur de production sur le serveur de test. Il copie uniquement les métadonnées des bases de données et les statistiques nécessaires.

• Toutes les informations de session sont stockées dans msdb sur le serveur de production. Cela vous permet d’exploiter n’importe quel serveur de test disponible pour le réglage, et des informations sur toutes les sessions sont disponibles à un seul endroit (le serveur de production).

Problèmes liés à la base de données Shell

• Après le réglage, l’Assistant Paramétrage du moteur de base de données doit supprimer les métadonnées qu’il a créées sur le serveur de test pendant le processus de paramétrage. Cela inclut la base de données shell. Si vous effectuez une série de sessions de réglage avec les mêmes serveurs de production et de test, vous pouvez conserver cette base de données shell pour gagner du temps. Dans le fichier d’entrée XML, spécifiez le sous-élément RetainShellDB avec les autres sous-éléments sous l’élément parent TuningOptions . L’utilisation de ces options permet à l’Assistant Paramétrage du moteur de base de données de conserver la base de données shell. Pour plus d’informations, voir les Informations de référence sur le fichier d’entrée XML (Assistant Paramétrage du moteur de base de données).

• Les bases de données Shell peuvent être laissées derrière elles sur le serveur de test après une session de paramétrage de serveur de test/de production réussie, même si vous n’avez pas spécifié le sous-élément RetainShellDB . Ces bases de données shell indésirables peuvent interférer avec les sessions de réglage suivantes et doivent être supprimées avant d’effectuer une autre session de paramétrage de serveur de test/serveur de production. En outre, si une session de paramétrage se ferme de façon inattendue, les bases de données shell sur le serveur de test et les objets de ces bases de données peuvent être laissés derrière elles sur le serveur de test. Vous devez également supprimer ces bases de données et objets avant de commencer une nouvelle session de paramétrage de serveur de test/serveur de production.

Problèmes liés au processus de paramétrage

• L’utilisateur doit vérifier le journal de réglage des erreurs qui résultent des différences entre les serveurs de production et de test, ainsi que les erreurs résultant de la copie des métadonnées de la production vers le serveur de test. Par exemple, une connexion utilisateur peut ne pas exister sur le serveur de test. Si une connexion utilisateur n’existe pas sur le serveur de test, ces événements dans la charge de travail émises par cette connexion utilisateur peuvent ne pas être paramétrables. Utilisez l'interface graphique utilisateur de l’Assistant Tuning du moteur de base de données pour afficher le journal de tuning. Pour plus d’informations, consultez Afficher et utiliser la sortie de l’Assistant Paramétrage du moteur de base de données

• Si l’Assistant Paramétrage du moteur de base de données ne peut pas régler de nombreux événements, car les objets sont manquants dans la base de données shell créée par l’Assistant Paramétrage du moteur de base de données sur le serveur de test, l’utilisateur doit vérifier le journal de paramétrage. Les événements qui ne peuvent pas être paramétrés sont répertoriés dans le journal. Pour régler correctement la base de données sur le serveur de test, l’utilisateur doit créer les objets manquants dans la base de données shell, puis démarrer une nouvelle session de paramétrage.

• Si une base de données portant le même nom existe déjà sur le serveur de test, l’Assistant Paramétrage du moteur de base de données ne copie pas les métadonnées, mais continue le réglage et collecte les statistiques si nécessaire. Cela est utile si l’utilisateur a déjà créé une base de données sur le serveur de test et a copié les métadonnées appropriées avant d’appeler l’Assistant Paramétrage du moteur de base de données.

• Si l’option DATE_CORRELATION_OPTIMIZATION est activée pour une base de données sur le serveur de production, les métadonnées et les données associées à cette option ne sont pas entièrement scriptées lors du paramétrage du serveur de test. Lorsque le réglage est effectué pour un scénario de serveur de test/serveur de production, les problèmes suivants peuvent s’appliquer :

  • Les utilisateurs peuvent avoir différents plans de requête sur les serveurs pour les requêtes qui utilisent l’option DATE_CORRELATION_OPTIMIZATION.

  • L’Assistant de réglage du moteur de base de données peut suggérer de supprimer des vues indexées qui prennent en charge l’option DATE_CORRELATION_OPTIMIZATION dans le script de recommandation.

  Par conséquent, vous pouvez ignorer les recommandations que l’Assistant Paramétrage du moteur de base de données effectue sur les vues indexées qui contiennent des statistiques de corrélation, car l’Assistant Paramétrage du moteur de base de données connaît leurs coûts, mais pas leurs avantages. L’Assistant Paramétrage du moteur de base de données peut ne pas recommander la sélection de certains index tels que les index en cluster sur les colonnes datetime , ce qui peut être bénéfique lorsque DATE_CORRELATION_OPTIMIZATION est activé.

  Pour déterminer si une vue est basée sur des statistiques de corrélation, sélectionnez la colonne is_date_correlation_view de l’affichage catalogue sys.views .