Changements de comportement des fonctionnalités du moteur de base de données de SQL Server 2008
Cette rubrique décrit les changements de comportement dans le moteur de base de données. Les changements de comportement affectent la façon dont certaines fonctionnalités fonctionnent ou interagissent dans SQL Server 2008 par rapport aux versions précédentes de SQL Server.
Agent SQL Server
Changements de comportement dans le script d'une tâche de l'Agent SQL Server.
Dans SQL Server 2008, si vous créez un travail en copiant le script à partir d'un travail existant, le nouveau travail peut affecter le travail existant par inadvertance. Pour créer un travail à l'aide du script d'un travail existant, supprimez manuellement le paramètre @schedule\_uid qui est habituellement le dernier paramètre de la section qui crée la planification du travail dans le travail existant. Vous créez ainsi une planification indépendante pour le nouveau travail sans affecter les travaux existants.
Options access check cache
Dans SQL Server 2005, la structure interne access check result cache ne peut pas être configurée sauf à l'aide d'indicateurs de trace. Dans SQL Server 2008, vous pouvez utiliser les options access check cache pour modifier cette structure. Pour plus d'informations, consultez Options access check cache.
Recherche en texte intégral
SQL Server 2008 introduit une nouvelle architecture de recherche en texte intégral. Le moteur de recherche en texte intégral est désormais complètement intégré au moteur de base de données SQL Server, au lieu d'un service distinct. En matière de recherche en texte intégral, cette intégration offre une simplicité de gestion, une évolutivité, une sécurité et des performances supérieures à celles des versions précédentes de SQL Server. Pour plus d'informations sur les différences principales entre la recherche en texte intégral dans SQL Server 2005 et SQL Server 2008, ainsi que sur les recommandations associées à ce nouveau moteur de recherche en texte intégral intégré, consultez l'article technique « SQL Server 2008 Full-Text Search: Internals and Enhancements » (en anglais) sur MSDN.
Serveurs liés
SQL Server 2008 modifie la sémantique de transaction des instructions INSERT...EXECUTE qui s'exécutent sur un serveur lié en boucle. Dans SQL Server 2005, ce scénario n'est pas pris en charge et provoque une erreur. Dans SQL Server 2008, une instruction INSERT...EXECUTE peut s'exécuter sur un serveur lié en boucle lorsque MARS (Multiple Active Result Set) n'est pas activé sur la connexion. Lorsque MARS est activé sur la connexion, le comportement est le même que dans SQL Server 2005.
Parallélisme
Traitement des requêtes sur les tables partitionnées et parallélisme
Dans SQL Server 2008, les améliorations apportées à la conception des tables partitionnées permettent d'optimiser le parallélisme par rapport à SQL Server 2005, lors du traitement des requêtes sur des tables partitionnées. En raison de cette nouvelle conception, seules des jointures bidirectionnelles peuvent être colocalisées. Les plans de requêtes pour les jointures colocalisées bidirectionnelles dans SQL Server 2008 sont semblables à ceux de SQL Server 2005 et ont des performances comparables à celles de SQL Server 2005. Si des tables supplémentaires avec partitionnement aligné sont incluses dans la jointure, un autre plan est sélectionné ; par exemple, une jointure colocalisée bidirectionnelle peut être suivie d'une jointure de hachage avec la troisième table. Les jointures colocalisées entre plusieurs tables sont rares ; en outre, les jointures colocalisées ne tirent pas parti des améliorations du parallélisme dans SQL Server 2008. Toutefois, si vous disposez d'une requête pour laquelle SQL Server 2005 effectue une jointure colocalisée à trois directions ou plus, il se peut que la requête s'exécute plus lentement dans SQL Server 2008 si la quantité de mémoire est faible par rapport à la taille des tables. Dans ce type de cas, vous pouvez améliorer les performances en augmentant la quantité de mémoire disponible et en réécrivant la requête de sorte que les partitions individuelles soient jointes séparément avant la combinaison des résultats. Pour plus d'informations sur les jointures colocalisées, consultez Améliorations du traitement des requêtes sur les tables et les index partitionnés.
Jointure en étoile et parallélisme
SQL Server offre une nouvelle fonction d'optimisation pour le traitement des requêtes avec jointures en étoile, qui utilise des jointures de hachage et des filtres Bitmap. Lorsqu'une requête traite de grandes quantités de données provenant de la jonction de tables de faits à des tables de dimension dans un schéma en étoile, tout plan de requête qui utilise la nouvelle fonction d'optimisation peut s'exécuter beaucoup plus rapidement.
Par conséquent, vous pouvez voir un nouveau plan de requête pour vos requêtes existantes si elles correspondent au modèle de jointure en étoile. L'optimiseur de requête choisit ce plan lorsque ses estimations indiquent une augmentation des performances des requêtes. Toutefois, si les statistiques utilisées dans l'estimation de coût sont inexactes, l'optimiseur de requête peut choisir l'optimisation de jointure en étoile alors qu'un autre plan se révèle plus rapide.
Si l'option de configuration max degree of parallelism ou l'option d'index MAXDOP a la valeur 1, l'optimiseur de requête n'utilise pas l'optimisation de jointure en étoile ; en outre, vous ne pouvez pas tirer parti des avantages résultant de la nouvelle fonction d'optimisation de jointure en étoile. Si le système d'exécution de requêtes distribue une requête optimisée à l'aide d'un plan parallèle avec un seul thread, certains filtres Bitmap peuvent être supprimés d'un plan de jointure en étoile comportant plusieurs filtres Bitmap. Cette modification peut ralentir l'exécution de manière plus importante que prévu lorsque vous passez de 2 threads à un 1 thread, par exemple.
L'optimisation de jointure en étoile est uniquement disponible dans les éditions Enterprise, Developer et Evaluation de SQL Server. Pour plus d'informations sur le filtrage Bitmap, consultez Optimisation des performances des requêtes d'entrepôt de données grâce au filtrage Bitmap. Pour plus d'informations sur l'interprétation des plans de requêtes qui contiennent des filtres Bitmap, consultez Interprétation des plans d'exécution contenant des filtres Bitmap. Pour plus d'informations sur l'optimisation de jointure en étoile, consultez l'article de TechNet Magazine « Performances des requêtes d'entrepôts de données ».
Parallélisme d'un petit nombre de lignes externes
SQL Server 2008 facilite le parallélisme des jointures de boucles imbriquées lorsque le côté extérieur de la jointure n'a que quelques lignes. Dans SQL Server 2005, si plusieurs threads sont disponibles, chaque thread se voit allouer une page de lignes provenant du côté extérieur de la jointure. S'il n'existe que quelques lignes, elles sont probablement sur la même page. Dans ce cas, un seul thread est employé et les avantages potentiels du parallélisme sont perdus. SQL Server 2008 reconnaît ce type de cas et introduit un opérateur d'échange qui alloue une ligne par thread de sorte que tous les processeurs disponibles soient employés. L'augmentation du parallélisme signifie que la consommation processeur est temporairement plus élevée que dans SQL Server 2005 ; toutefois, l'exécution des requêtes est plus rapide. Ce nouveau comportement est visible uniquement si le nombre de lignes externes est faible et si le coût estimé de la requête est suffisamment important pour tirer parti du parallélisme supplémentaire. Si l'estimation de coût de la requête est faible ou si l'estimation de cardinalité du côté extérieur est supérieure à 1 000, SQL Server alloue une page par thread, comme dans SQL Server 2005. Pour plus d'informations sur les opérateurs d'échange et sur le traitement de requêtes en parallèle, consultez Traitement de requêtes en parallèle.
Requêtes de tables partitionnées utilisant l'indicateur USE PLAN
SQL Server 2008 modifie la manière dont sont traitées les requêtes sur les tables et index partitionnés. Les requêtes sur des objets partitionnés qui utilisent l'indicateur USE PLAN peuvent contenir un plan non valide. Nous recommandons les procédures suivantes après la mise à niveau vers SQL Server 2008.
Lorsque l'indicateur USE PLAN est spécifié directement dans une requête :
Supprimez l'indicateur USE PLAN de la requête.
Testez la requête.
Si l'optimiseur ne sélectionne pas un plan approprié, réglez la requête, puis spécifiez l'indicateur USE PLAN avec le plan de requête voulu.
Lorsque l'indicateur USE PLAN est spécifié dans un repère de plan :
Utilisez la fonction sys.fn_validate_plan_guide pour vérifier la validité du repère de plan. Vous pouvez aussi surveiller les repères de plan non valides en utilisant l'événement Plan Guide Unsuccessful dans SQL Server Profiler.
Si le repère de plan n'est pas valide, supprimez-le. Si l'optimiseur ne sélectionne pas un plan approprié, réglez la requête, puis spécifiez l'indicateur USE PLAN avec le plan de requête désiré.
Pour plus d'informations sur le traitement des requêtes sur les objets partitionnés, consultez Améliorations du traitement des requêtes sur les tables et les index partitionnés.
Repères de plan
Dans SQL Server 2008, si un repère de plan ne peut pas être honoré, la requête est compilée à l'aide d'un plan différent et aucune erreur n'est retournée. Dans SQL Server 2005, une erreur est levée et la requête échoue.
Les repères de plan créés dans SQL Server 2005 peuvent ne pas être valides après une mise à niveau vers SQL Server 2008. Les repères de plan non valides n'entraînent pas l'échec de l'application, mais le repère de plan n'est pas utilisé. Il est recommandé de réévaluer et de tester les définitions des repères de plan lorsque vous mettez à niveau votre application vers une nouvelle version de SQL Server. Les contraintes liées au paramétrage des performances et le comportement de la mise en correspondance des repères de plan peuvent changer. Après avoir mis à niveau une base de données vers SQL Server 2008, effectuez les tâches suivantes pour valider des repères de plan existants à l'aide de la fonction sys.fn_validate_plan_guide. Vous pouvez aussi surveiller les repères de plan non valides en utilisant l'événement Plan Guide Unsuccessful dans SQL Server Profiler.
Architecture du processeur de requêtes
SQL Server 2008 modifie la manière dont sont traitées les requêtes sur les tables et index partitionnés. Les requêtes sur des objets partitionnés qui utilisent l'indicateur USE PLAN pour un plan généré par SQL Server 2005 peuvent contenir un plan non valide. Pour plus d'informations, consultez Considérations sur la mise à niveau du moteur de base de données. Pour plus d'informations sur le traitement des requêtes sur les objets partitionnés, consultez Améliorations du traitement des requêtes sur les tables et les index partitionnés.
Fonction REPLACE
Dans SQL Server 2005, les espaces de fin spécifiés dans le premier paramètre d'entrée de la fonction REPLACE sont supprimés lorsque le paramètre est de type char. Par exemple, dans l'instruction SELECT '<' + REPLACE(CONVERT(char(6), 'ABC '), ' ', 'L') + '>', la valeur 'ABC ' est considérée à tort comme étant 'ABC'.
Dans SQL Server 2008, les espaces de fin sont toujours conservés. Pour les applications basées sur le comportement antérieur de la fonction, utilisez la fonction RTRIM lors de la spécification du premier paramètre d'entrée de la fonction. Par exemple, la syntaxe suivante reproduit le comportement de SQL Server 2005 : SELECT '<' + REPLACE(RTRIM(CONVERT(char(6), 'ABC ')), ' ', 'L') + '>'.
Bases de données système
Base de données Resource
Dans SQL Server 2005, les fichiers de données et les fichiers journaux de la base de données Resource dépendent de l'emplacement du fichier de données de la base de données master. Par conséquent, le déplacement de la base de données master implique également le déplacement de la base de données Resource au même emplacement. Dans SQL Server 2008, cette dépendance n'existe pas. Les fichiers de la base de données master peuvent être déplacés sans déplacer la base de données Resource.
Dans SQL Server 2008, l'emplacement par défaut de la base de données Resource est <lecteur>:\Program Files\Microsoft SQL Server\MSSQL10.<nom_instance>\Binn\. La base de données Resource ne peut pas être déplacée.
Base de données tempdb
Dans les versions antérieures de SQL Server, l'option de base de données PAGE_VERIFY est définie par la valeur NONE pour la base de données tempdb et ne peut pas être modifiée. Dans SQL Server 2008, la valeur par défaut pour la base de données tempdb est CHECKSUM pour les nouvelles installations de SQL Server. Lorsque vous mettez à niveau une installation SQL Server, la valeur par défaut reste NONE. Impossible de modifier l'option. Nous vous recommandons d'utiliser CHECKSUM pour la base de données tempdb.
Utilisation de INSERT…SELECT pour les données de chargement en masse avec une journalisation minimale
Dans les versions antérieures de SQL Server, le chargement en masse de lignes dans une table cible à l'aide de l'instruction INSERT INTO <table_cible> SELECT <colonnes> FROM <table_source> est toujours une opération entièrement journalisée. Dans SQL Server 2008, cette opération peut être effectuée avec une journalisation minimale lorsque la table cible est un segment de mémoire, que le mode de récupération défini de la base de données est le mode simple ou le mode utilisant les journaux de transactions et que l'indicateur TABLOCK est spécifié sur la table cible. La journalisation minimale peut améliorer les performances de l'instruction et réduire le risque de voir l'opération remplir l'espace disponible du journal des transactions au cours de la transaction. Pour plus d'informations, consultez INSERT (Transact-SQL).
XML
Mise à niveau de XML typé de SQL Server 2005 vers SQL Server 2008
SQL Server 2008 contient plusieurs extensions de prise en charge du schéma XML, notamment la prise en charge de la validation du type lax, une gestion améliorée des données d'instance xs:date, xs:time et xs:dateTime, ainsi qu'une prise en charge supplémentaire des types list et union. Dans la plupart des cas, les modifications n'affectent pas l'expérience de mise à niveau. Toutefois, si vous utilisez une collection de schémas XML dans SQL Server 2005 qui autorise les valeurs de type xs:date, xs:time ou xs:dateTime (ou tout sous-type), les étapes de mise à niveau suivantes ont lieu lorsque vous mettez à niveau votre base de données SQL Server 2005 vers SQL Server 2008.
Pour chaque colonne xml typée avec une collection de schémas XML qui contient des éléments ou attributs typés en tant que xs:anyType, xs:anySimpleType, xs:date ou l'un de ses sous-types, xs:time ou l'un de ses sous-types, ou xs:dateTime et l'un de ses sous-types, ou qui constituent des types union ou list contenant l'un de ces types, les événements suivants se produisent :
Tous les index XML de la colonne sont désactivés.
Toutes les valeurs SQL Server 2005 continuent d'être représentées dans le fuseau horaire Z, car elles ont été normalisées selon le fuseau horaire Z.
Toute valeur xs:date ou xs:dateTime inférieure au 1er janvier de l'année 1 provoque une erreur d'exécution lorsque l'index est reconstruit, ou lorsque des instructions XQuery ou XML-DML sont exécutées par rapport au type de données xml contenant cette valeur.
Les années négatives dans des facettes xs:date ou xs:dateTime ou les valeurs par défaut dans une collection de schémas XML sont automatiquement mises à jour en fonction de la plus petite valeur autorisée par le type xs:date ou xs:dateTime de base. Par exemple, 0001-01-01T00:00:00.0000000Z pour xs:dateTime.
Notez que vous pouvez toujours utiliser une simple instruction SQL SELECT pour récupérer l'intégralité du type de données xml, même s'il contient des années négatives. Il est recommandé de remplacer les années négatives par une année comprise dans la plage nouvellement prise en charge, ou de modifier le type de l'élément ou attribut en xs:string. Pour plus d'informations, consultez Comparaison du XML typé et du XML non typé.
Validation de type lax et éléments xs:anyType
Dans SQL Server 2005, la validation du type lax n'est pas prise en charge ; en outre, une validation stricte est appliquée pour les éléments de type anyType. Dans SQL Server 2008, le contenu des éléments de type anyType est validé via la validation du type lax. Pour plus d'informations, consultez Composants génériques et validation de contenu.
Voir aussi
Référence
Autres ressources
Historique des modifications
Mise à jour du contenu |
|---|
Ajout des sections « Options access check cache », « Recherche en texte intégral », « Parallélisme » et « XML ». |
Ajout de la section « Utilisation de INSERT…SELECT pour les données de chargement en masse avec une journalisation minimale ». |
Ajout de la section « Changements de comportement dans le script d'une tâche de l'Agent SQL Server ». |