Changements de comportement des fonctionnalités du moteur de base de données de SQL Server 2008

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.

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 ».

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.

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 :

1. Supprimez l'indicateur USE PLAN de la requête.

2. Testez la requête.

3. 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 :

1. 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.

2. 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.

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.

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.

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.

1. 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 :

   1. Tous les index XML de la colonne sont désactivés.

   2. 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.

   3. 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.

2. 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é.

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.