Pour télécharger et installer SQL Server 2005 SP2, votre ordinateur doit posséder au moins 1,9 Go d'espace disque disponible. Le tableau suivant présente l'espace disque requis par les composants du programme d'installation :

Après l'installation, vous pouvez supprimer le package de téléchargement de 250 Mo de votre ordinateur. L'utilisation permanente de l'espace disque de SQL Server 2005 SP2 après l'installation est d'environ 1 Go.

[Haut de la page]

Tous les bulletins de sécurité relatifs à SQL Server 2005, accessibles au public et publiés avant le 15 janvier 2007 ont été intégrés au SP2. Si vous avez reçu un correctif logiciel relatif à SQL Server 2005 après le 15 janvier 2007, il n'est peut-être pas inclus dans cette version du SP2. Contactez votre support technique principal afin d'obtenir ce même correctif logiciel pour SQL Server 2005 SP2.

SQL Server 2005 SP2 comprend la prise en charge pour Microsoft SQL Server 2005 Compact Edition (SQL Server Compact Edition), précédemment appelée Microsoft SQL Server 2005 Mobile Edition (SQL Server Mobile). Pour plus d'informations sur SQL Server Compact Edition, consultez SQL Server .

Chaque produit SQL Server (y compris les Service Packs) dispose de son propre numéro de version. Le numéro de version d'une instance de SQL Server 2005 peut être affiché de deux façons :

• Dans l'Explorateur d'objets de SQL Server Management Studio, lorsque vous êtes connecté à l'instance.
  
  
• En exécutant la requête SELECT SERVERPROPERTY('ProductVersion') sur une instance de moteur de base de données.
  
  

Le tableau suivant présente les numéros de versions qui correspondent aux versions de SQL Server 2005 :

[Haut de la page]

Lors de la mise à niveau d'instances SQL Server 2005 dans une topologie de réplication de fusion ou dans une topologie de réplication transactionnelle à l'aide d'Abonnés de mise à jour, vous devez mettre à niveau les instances dans l'ordre suivant :

1. Serveur de distribution
   
   
2. Serveur de publication
   
   
3. Abonnés
   
   

[Haut de la page]

Si vous mettez à niveau une installation de Reporting Services qui inclut une base de données du serveur de rapports distante, vous rencontrerez peut-être des problèmes lors de la mise à niveau du schéma de la base de données. Par défaut, le programme d'installation utilise le jeton de sécurité de l'utilisateur qui exécute le programme d'installation pour se connecter à l'instance SQL Server distante et mettre à jour le schéma. Si vous disposez des autorisations d'administrateur à la fois sur l'ordinateur local et sur l'ordinateur distant, la mise à niveau de la base de données s'effectuera correctement. Si vous exécutez le programme d'installation à partir de l'invite de commandes et que vous spécifiez les commutateurs /rsupgradedatabaseaccount et /rsupgradepassword pour un compte qui a l'autorisation de modifier le schéma sur l'ordinateur distant, la mise à niveau de la base de données s'effectuera également correctement.

Si vous n'avez pas l'autorisation de mettre à jour le schéma sur l'ordinateur distant, la connexion sera refusée avec l'erreur suivante :

« Le programme d'installation n'a pas pu mettre à niveau le schéma de base de données de serveur de rapports. Exécutez l'outil de configuration de Reporting Services, puis dans l'onglet Installation de la base de données, mettez à niveau la base de données du serveur de rapports vers la version actuelle du schéma de base de données. »

Les fichiers programme du serveur de rapports seront mis à niveau vers SP2, mais la base de données du serveur de rapports sera dans le format de la version précédente. Le serveur de rapports restera inaccessible tant que la base de données du serveur de rapports sera dans l'ancien format.

Pour mettre à niveau la base de données manuellement, exécutez l'outil de configuration de Reporting Services une fois la mise à niveau terminée. Connectez-vous au serveur de rapports mis à niveau et utilisez l'option Mettre à niveau de la page Installation de la base de données pour mettre à jour le schéma de la base de données. Après l'exécution de ces étapes, le serveur de rapports sera accessible.

[Haut de la page]

Si vous utilisez la fonction Ajout/Suppression de programmes pour réparer ou modifier des composants SQL Server après l'installation du SP2, le message d'erreur suivant peut apparaître :

« Le composant que vous essayez d'utiliser se trouve sur une ressource réseau non disponible. »

Les composants SQL Server suivants sont affectés :

• MSXML (msxml6.msi)
  
  
• SQLXML (sqlxml4.msi)
  
  
• SQL Server Native Client (sqlncli.msi)
  
  
• Compatibilité descendante (SqlServer2005_BC.msi)
  
  
• SQL Server VSS Writer (SqlWriter.msi)
  
  

[Haut de la page]

Lorsque vous appliquez le SP2, le programme d'installation met à niveau les bases de données système. Si vous avez implémenté des restrictions à la syntaxe ALTER DATABASE, cette mise à niveau peut échouer. Les restrictions apportées à la syntaxe ALTER DATABASE sont par exemple :

• Le refus explicite de l'instruction ALTER DATABASE.
  
  
• Un déclencheur de langage de définition de données (DDL) sur ALTER DATABASE qui restaure la transaction contenant l'instruction ALTER DATABASE.
  
  

Si vous avez apporté des restrictions à la syntaxe ALTER DATABASE et que le programme d'installation ne peut pas mettre à niveau les bases de données système vers SP2, vous devez désactiver ces restrictions et réexécuter le programme d'installation.

[Haut de la page]

Prenez note des informations suivantes avant d'installer SP2 sur une instance de cluster avec basculement :

• N'arrêtez pas le service de cluster avant d'exécuter le programme d'installation du SP2, ou pendant l'exécution du programme d'installation.
  
  
• N'interrompez aucun processus en cours d'exécution avant d'exécuter le programme d'installation du SP2.
  
  
• Ne mettez pas le service SQL Server hors connexion avant d'exécuter le programme d'installation du SP2. Le programme d'installation du SP2 arrêtera et redémarrera le service SQL Server.
  
  
• Exécutez le programme d'installation d'origine du SP2 sur le nœud principal de l'instance de cluster avec basculement.
  
  
• Vous devez redémarrer tous les nœuds de cluster avec basculement une fois l'installation du SP2 terminée.
  
  
• La mise à niveau propagée n'est pas prise en charge pour SP2.
  
  

[Haut de la page]

Prenez note des modifications suivantes apportées au type de démarrage et à l'état par défaut du service SQL Writer :

• Le type de démarrage du service SQL Writer est passé de Manuel à Automatique.
  
  
• L'état par défaut du service SQL Writer est passé de Arrêté à Démarré.
  
  

[Haut de la page]

Présent à partir de SQL Server 2005 Service Pack 1 (SP1).

Les index non cluster uniques peuvent dorénavant être créés en ligne. Les instructions suivantes sont affectées :

• CREATE UNIQUE NONCLUSTERED INDEX
  
  
• CREATE UNIQUE NONCLUSTERED INDEX WITH DROP_EXISTING
  
  
• ALTER TABLE ADD CONSTRAINT PRIMARY KEY NONCLUSTERED
  
  
• ALTER TABLE ADD CONSTRAINT UNIQUE NONCLUSTERED
  
  

Pour plus d'informations, consultez la section Mises à jour de la documentation en ligne de SQL Server 2005.

[Haut de la page]

Présent à partir de SQL Server 2005 SP1.

Un mini fichier de vidage (SQLDUMPnnnn.txt) est créé dans le répertoire LOG de SQL Server lorsqu'une commande DBCC CHECKDB, DBCC CHECKALLOC, DBCC CHECKFILEGROUP ou DBCC CHECKTABLE détecte une erreur d'altération. Lorsque les fonctionnalités de collecte de données Utilisation de fonctionnalités et de rapports d'erreurs sont activées pour l'instance SQL Server, le fichier est automatiquement transféré à Microsoft. Les données collectées sont utilisées pour améliorer les fonctionnalités de SQL Server. Pour plus d'informations, consultez la section « Paramètres de rapports d'erreurs et d'utilisation » dans la documentation en ligne de SQL Server 2005.

Le fichier de vidage contient les résultats de la commande DBCC ainsi que des éléments supplémentaires de diagnostic. Ce fichier contient des listes de contrôle d'accès discrétionnaires de service (DACL). L'accès au fichier de vidage est limité au compte de service SQL Server et aux membres du rôle sysadmin. Par défaut, le rôle sysadmin contient tous les membres du groupe Windows BUILTIN\Administrators et du groupe de l'administrateur local. La commande DBCC n'échoue pas si le processus de collecte des données échoue.

[Haut de la page]

Présent à partir de SQL Server 2005 SP1.

Lorsqu'un lot est terminé, le moteur de base de données restaure automatiquement toutes les transactions non validables actives. Dans les versions antérieures à SP2, les transactions non validables devaient être restaurées manuellement.

[Haut de la page]

Présent à partir de SQL Server 2005 SP1.

La syntaxe de jeton des étapes de travail de l'Agent SQL Server 2005 n'est plus la même. En conséquence, vous devez insérer une macro d'échappement de tous les jetons utilisés dans les étapes de travail, sinon ces étapes échoueront avec le message d'erreur suivant :

« Le travail contient un ou plusieurs jetons. Pour SQL Server 2005 SP1 ou ultérieur, toutes les étapes de travail comportant des jetons doivent être mises à jour à l'aide d'une macro avant d'exécuter le travail. »

Il s'agit là d'une différence par rapport aux versions précédentes de SQL Server 2005, qui ne nécessitaient pas de macros d'échappement des jetons. Pour plus d'informations sur la mise à jour de vos travaux en vue d'utiliser la nouvelle syntaxe et sur l'utilisation de macros d'échappement, consultez « Utilisation de jetons dans les étapes de travail » dans la documentation en ligne de SQL Server 2005 (avril 2006) ou version ultérieure. Pour plus d'informations sur les mises à jour de la documentation en ligne, consultez la section Mises à jour de la documentation en ligne de SQL Server 2005.

[Haut de la page]

Présent à partir de SQL Server 2005 SP2.

Le message d'erreur suivant apparaît si vous utilisez un outil d'une version précédente pour ouvrir un plan de maintenance SP2 créé avec le concepteur de plan de maintenance :

« Ce plan de maintenance a été modifié à l'aide d'un autre outil que le concepteur de plan de maintenance. Vous devez désormais utiliser SQL Server Integration Services pour le modifier. »

Pour résoudre ce problème, il est recommandé de mettre vos outils à niveau vers SQL Server 2005 SP2. Il est également recommandé d'utiliser le concepteur de plan de maintenance pour modifier le plan, plutôt que les services Integration Services mentionnés dans le message d'erreur.

[Haut de la page]

Présent à partir de SQL Server 2005 SP1.

L'installation de ce Service Pack réinitialise les autorisations DCOM pour le lancement du service Integration Services et l'accès à ce service. Les autorisations sont réinitialisées aux autorisations par défaut. Si vous avez des autorisations DCOM personnalisées, vous devez réappliquer la personnalisation.

[Haut de la page]

Présent à partir de SQL Server 2005 SP1.

SQL Server SP2 réinitialise la valeur de la clé de Registre HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDTS\ServiceConfigFile à sa valeur par défaut. Cette clé de Registre spécifie l'emplacement du fichier de configuration du service Integration Services (MsDtsSrvr.ini.xml). Si vous avez changé la valeur de cette clé de Registre par rapport à l'emplacement par défaut, vous devez le mettre à nouveau à jour après avoir appliqué le Service Pack.

[Haut de la page]

Présent à partir de SQL Server 2005 SP1.

Après l'installation de SQL Server SP2, les conversions de colonnes peuvent échouer dans les cas suivants :

Présent à partir de SQL Server 2005 SP1.

Les composants de flux de données Integration Services ne sont plus initialisés de la même façon. Dans les versions précédentes, les composants de flux de données étaient initialisés tout d'abord en appelant la méthode AcquireConnections, puis en appelant la méthode PreExecute pour chaque connexion associée. Dans cette version, la méthode AquireConnections est appelée pour toutes les connexions associées avant d'appeler la méthode PreExecute. Le nouveau processus d'initialisation permet un enregistrement plus fiable des transactions et une meilleure intégration des données.

Dans certains cas, le nouveau processus d'initialisation entraîne une erreur de temporisation. Par exemple, les tâches de flux de données complexes peuvent contenir de nombreux composants qui utilisent des connexions, telles que sources, destinations et recherches multiples. Les composants se trouvant au bas de la liste ne peuvent pas utiliser les connexions qui leur sont associées jusqu'a ce que tous les appels PreExecute des composants précédents soient terminés. En conséquence, sous certaines conditions, le délai entre l'acquisition et la première utilisation d'une connexion peut être plus long que prévu, ce délai allongé peut entraîner l'expiration de certaines connexions, entraînant l'échec de packages.

Pour résoudre ce problème, augmentez simplement la valeur de la propriété Timeout pour les connexions qui échouent. Les performances du package après l'initialisation ne sont pas affectées.

[Haut de la page]

Présent à partir de SQL Server 2005 SP2.

Les packages Integration Services utilisent les fonctionnalités de Microsoft Visual Studio for Applications (VSA) pour exécuter le code personnalisé contenu dans les composants Script et les tâches Script. Les mises à jour de sécurité critiques publiées pour .NET Framework 2.0 provoquent une incompatibilité binaire entre les packages qui contiennent des scripts et l'environnement d'exécution VSA. Pour plus d'informations, voir l'article 928365 de la Base de connaissances Microsoft.

Si cette incompatibilité se manifeste à l'exécution, Integration Services tente d'identifier toutes les instances de ce problème et de les éviter afin que les scripts puissent s'exécuter normalement. Cependant, dans quelques cas, les scripts peuvent ne pas s'exécuter et vous devrez peut-être recompiler manuellement les scripts. Pour plus d'informations, voir l'article 931846 de la Base de connaissances Microsoft. Si votre ordinateur exécute Windows Vista, vous devrez peut-être installer un correctif, comme décrit dans l'article 928208 de la Base de connaissances Microsoft.

[Haut de la page]

Présent à partir de SQL Server 2005 SP2.

Pour prendre en charge toutes les fonctionnalités de décisionnel dans Microsoft Office 2007 lors de la connexion à une instance Analysis Services, vous devez avoir installé SP2. Si le SP2 n'est pas installé, les fonctionnalités d'Office 2007 qui nécessitent le SP2 sont désactivées lors de l'exécution sur une instance Analysis Services.

[Haut de la page]

Présent à partir de SQL Server 2005 SP2.

Analysis Services requiert désormais que toutes les dimensions contenues dans un groupe de mesures lié présentent la même granularité que la dimension dans le groupe de mesures source. Par exemple, si l'attribut jour est défini comme attribut de granularité dans une dimension de temps du groupe de mesures source, le groupe de mesures lié doit également utiliser l'attribut jour comme attribut de granularité. Le scénario le plus courant d'une base de données Analysis Services qui enfreint cette règle est une base de données SQL Server 2000 Analysis Services qui a été migrée en utilisant une version précommerciale de SQL Server 2005.

Si vous disposez d'une base de données qui enfreint cette règle de granularité, vous devez modifier la base de données contenant le groupe de mesures lié avant d'appliquer le SP2. Dans le cas contraire, les bases de données ne seront pas valides une fois le SP2 appliqué. Ces bases de données non valides doivent être supprimées.

[Haut de la page]

Présent à partir de SQL Server 2005 SP2.

Le SP2 entraîne des modifications du comportement des requêtes Multidimensional Expressions (MDX) :

• Les coordonnées des cellules sur les axes des colonnes et des lignes sont désormais fusionnées avec les coordonnées des membres de dimension tuple unique contenus dans une clause WHERE. Par exemple, SELECT [USA] FROM [Cube] WHERE [Seattle] renvoie désormais la valeur de la cellule pour Seattle et non pour les États-Unis d'Amérique (USA). Les requêtes contenant des membres de plusieurs dimensions d'un attribut ou d'une hiérarchie spécifique dans la clause WHERE et sur un axe de colonne ou de ligne ne sont pas affectées par le SP2 et peuvent renvoyer des résultats non attendus. Ce comportement est susceptible de changer à nouveau.
  
  
• Les requêtes qui contiennent des calculs remplaçant les coordonnées qui sont définies dans une sous-sélection ne conservent plus les valeurs visibles. Par exemple, WITH MEMBER Measures.ParentContribution AS (Measures.Sales, Geography.Currentmember.Parent) / Measures.Sales SELECT Measures.ParentValue ON COLUMNS, Geography.Members ON ROWS FROM (Select Geography.USA on 0 from Sales) renvoie désormais la contribution au parent sans valeurs visibles.
  
  

[Haut de la page]

Présent à partir de SQL Server 2005 SP2.

En raison de modifications de compatibilité descendante et ascendante dans le protocole Analysis Services et dans le format de fichier dans le SP2, les dossiers de données et les sauvegardes Analysis Services SP2 ne peuvent pas être chargés par les serveurs Analysis Services SP1, et la synchronisation de serveur ne peut pas être effectuée entre les serveurs Analysis Services SP2 et les serveurs Analysis Services SP1. Cette modification est en vigueur depuis SQL Server 2005 SP1 QFE 251.

[Haut de la page]

Présent à partir de SQL Server 2005 SP2.

Lors de l'affichage de rapports avec du contenu pouvant être développé dans Internet Explorer 7.0, le bouton Précédent ne charge pas les pages précédemment affichées.

[Haut de la page]

Sur un serveur de rapports qui s'exécute en mode SharePoint intégré, vous pouvez obtenir une erreur de temporisation ASP.NET pour les rapports longs qui nécessitent un temps de traitement supérieur à celui spécifié dans la temporisation par défaut. Par défaut, la temporisation ASP.NET est définie à 2 minutes. Les rapports qui nécessitent plus de deux minutes de traitement se ferment de façon inattendue et la page d'erreur Windows SharePoint Services s'affiche avec l'erreur suivante : « Une erreur inattendue s'est produite. »

Si vous pensez que cette erreur est liée à la temporisation, vous pouvez remédier à ce problème en ajoutant un attribut httpRuntime executionTimeout au fichier Web.config de l'application Web SharePoint.

Assurez-vous de fournir une valeur suffisante pour le traitement des rapports longs. Pour un serveur de rapports en mode natif, la valeur par défaut est de 9000 secondes pour un serveur de rapports et le Gestionnaire de rapports. Choisissez une valeur similaire lorsque vous spécifiez executionTimeout pour l'application Web SharePoint.

Si vous avez déployé plusieurs applications dans une batterie de serveurs SharePoint, répétez les étapes précédentes pour chaque fichier Web.config de la batterie. Ceci s'applique à tous les fichiers Web.config de l'application Web SharePoint dans les sous-répertoires de <lecteur>:\inetpub\wwwroot\wss\VirtualDirectories. Cela s'applique aussi aux fichiers Web.config des applications de la batterie installées sur différents ordinateurs.

[Haut de la page]

SQL Server 2005 SP2 comprend une nouvelle version de l'outil de configuration de Reporting Services. Si vous installez le SP2, vous devez utiliser la version SP2 de l'outil de configuration de Reporting Services pour configurer le serveur de rapports. Par ailleurs, vous ne pouvez pas utiliser la version SP2 de l'outil de configuration de Reporting Services pour configurer un serveur de rapports antérieur à la version SP2. Cette incompatibilité est due au fait que l'outil de configuration de Reporting Services utilise une nouvelle version du fournisseur WMI, qui ne prend pas en charge la compatibilité descendante. Si vous utilisez l'outil de configuration de Reporting Services avec une version non prise en charge, une erreur survient indiquant que le fournisseur WMI a renvoyé un statut non spécifié à ReportServicesConfigUI.WMIProvider.ConfigurationItem.CreateConfigurationItem.

[Haut de la page]

Si vous configurez le répertoire virtuel du serveur de rapports et que le Gestionnaire de rapports n'est pas installé, l'outil de configuration de Reporting Services se ferme de façon inattendue et une erreur survient indiquant que l'outil de configuration de SQL Server 2005 Reporting Services a rencontré un problème et doit fermer. En fait, en dépit du message d'erreur, le répertoire virtuel est créé. L'erreur ne survient qu'une seule fois. Lorsque vous ouvrez à nouveau l'outil, vous pouvez terminer la configuration du serveur sans que l'erreur survienne à nouveau.

[Haut de la page]

Si vous déployez et intégrez un serveur de rapports avec une batterie de serveurs SharePoint, vous devez utiliser les mêmes versions des produits et technologies SharePoint sur tous les serveurs, y compris sur le serveur qui héberge le serveur de rapports. Vous ne pouvez pas combiner Windows SharePoint Services 3.0 et Office SharePoint Server 2007 dans la même batterie de serveurs.

[Haut de la page]

Le type des informations d'identification spécifiées dans la connexion à la base de données du serveur de rapports détermine si le programme d'installation peut mettre à niveau une base de données de serveur de rapports de la version SP1 ou SP2 CTP vers la version SP2 finale.

Si le serveur de rapports se connecte à la base de données du serveur de rapports à l'aide d'informations d'identification de base de données ou d'un compte utilisateur différents des informations utilisées pour exécuter le service Windows Report Server, la base de données ne sera pas mise à jour lorsque le reste des logiciels est mis à niveau. Si ceci se produit, utilisez l'outil de configuration de Reporting Services pour mettre à niveau manuellement la base de données du serveur de rapports. Dans la page Installation de la base de données, cliquez sur Mettre à niveau pour appliquer le format SP2 à la base de données du serveur de rapports.

[Haut de la page]

Vous ne pouvez pas intégrer plusieurs instances de serveur de rapports qui partagent la même base de données de serveur de rapports dans des déploiements serveurs autonomes de Windows SharePoint Services 3.0 ou Microsoft Office SharePoint Server 2007. Cela pourrait endommager les données dans la base de données principale du serveur de rapports. Le scénario suivant n'est pas pris en charge : deux installations indépendantes de Windows SharePoint Services 3.0, chacune étant intégrée à une instance locale du serveur de rapports et où les deux instances de serveur de rapports partagent la même base de données du serveur de rapports.

[Haut de la page]

Dans cette version, Microsoft Visual Studio for Applications (VSA), environnement de développement de scripts et moteur d'exécution utilisés par la tâche Script et le composant Script d'Integration Services, est incompatible avec la version finale de Windows Vista. Si un ordinateur exécute la version finale de Windows Vista, vous ne pouvez pas utiliser cet ordinateur pour modifier ou déboguer les scripts dans Integration Services, ni exécuter les packages Integration Services qui contiennent des scripts.

[Haut de la page]

Windows Vista comprend une nouvelle fonctionnalité, le Contrôle de compte d'utilisateur, qui aide les administrateurs à gérer l'utilisation des privilèges élevés. Sous Windows Vista, les administrateurs n'utilisent pas leurs privilèges d'administration par défaut. Ils effectuent la plupart des actions en tant qu'utilisateurs standard (non-administrateurs), et n'utilisent leurs privilèges d'administration que temporairement lorsque cela est nécessaire.

Le Contrôle de compte d'utilisateur entraîne certains problèmes connus. Pour plus d'informations, consultez les pages Web suivantes sur TechNet :

• Windows Vista : Contrôle de compte d'utilisateur
  
  
• Guide pas à pas du contrôle de compte d'utilisateur Windows Vista