0Migrer vers SQL Server 2000 en un clin d’œil
Pourquoi passer à SQL Server 2000, comment mettre à jour des applications, quelles sont les innovations apportées par SQL Server 2000 ?
Ce chapitre se propose de répondre à ces questions et d’éclairer le meilleur choix en la matière, en fait l’unique : migrer vers SQL Server 2000 !
Si vous êtes utilisateur de SQL Server version 6.x ou 7, n’hésitez pas à vous attarder quelque peu à ce chapitre, afin d’avoir une vue globale des principa- les différences entre ces versions et SQL Server 2000, et surtout de la procé- dure de migration d’une base en version 6.x ou 7.0 à une base en version 2000. Si vous abordez directement le monde SQL Server en version 2000, passez directement à la première partie.
Ce chapitre, par contre, vous concerne si vous connaissez déjà SQL Server 6 ou 7 et souhaitez migrer vers la version 2000. Vous y trouverez les indications majeures permettant de connaître les modifications qui en font un produit nouveau, et cependant fidèle à ses précédentes versions.
Vous allez découvrir comment installer et migrer un système d’une version 6.x ou 7 à la version 2000, et comment faire cohabiter des versions différentes de Enterprise Manager. Vous parcourrez rapidement les évolutions majeures des structures de stockage et de verrouillage, ainsi que celles du langage.
Enfin, nous reprenons les raisons d’adopter SQL Server 2000.
SQL Server 2000 est proposé en six éditions :
• Desktop Engine : anciennement appelée Microsoft Data Engine (MSDE), il s’agit de la version runtime du moteur. Cette édition permet de dévelop- per des applications monopostes tirant parti du stockage de SQL Server ;
• Personal : la version monoposte de SQL Server. À ne pas confondre avec le Desktop Engine, car cette version dispose des outils d’administration ;
• Standard : la version serveur « classique » ;
• Entreprise : la version serveur fonctionnant sur Windows 2000 Advanced Server et Datacenter Server, et Windows NT, Édition Entreprise, pour la gestion des clusters, de la mémoire au-delà de 4 Go, et le support de plus de 4 processeurs ;
• Developer : c’est une version entreprise, mais limité à une seule licence.
Elle permet à un développeur d’utiliser toutes les fonctionnalités de la version Enterprise ;
• Windows CE : la version pour PC de poche. Utiliser SQL Server sur son PC de poche offre la possibilité de créer des applications utilisant le même format de données quelle que soit la plate-forme, et donc de synchroniser les données simplement.
Il en existe aussi une version particulière, intégrée à Microsoft Small Business Server. Le choix dépend donc du système d’exploitation en service. Voici un tableau récapitulatif simple :
Tableau 1
Système d’exploitation et édition de SQL Servera
Système d’exploitation Éditions de SQL Server supportées
Windows 3.x Non supporté
Windows 95 Non supporté
Windows 98 Personal, Developer, Desktop
Windows Me Personal, Developer, Desktop
Windows NT Workstationb Personal, Developer, Desktop
Windows NT Server Standard, Personal, Developer, Desktop
Windows NT, Édition Entreprise Entreprise, Standard, Personal, Developer, Desktop Windows 2000, Professional Personal, Developer, Desktop
Windows 2000, Server Standard, Personal, Developer, Desktop
Windows 2000, Advanced Server Entreprise, Standard, Personal, Developer, Desktop
Pour en savoir plus
Ces différentes éditions sont décrites en détail au chapitre 2, « Installation de SQL Server », dans la section « éditions de SQL Server ».
De SQL Server 6.5 à SQL Server 2000
Pour utiliser SQL Server, il faut, comme tout logiciel, l’installer. Son installa- tion est simple et rapide, puisqu’une fois le CD-ROM inséré, les seuls choix à effectuer concernent l’édition de SQL Server 2000 et les options d’installa- tion. Il faut, avant de lancer l’installation de SQL Server 2000, installer le Service Pack 5a pour SQL Server 6.5 et Internet Explorer 5.0.
Après vous avoir demandé de choisir la méthode d’installation (locale ou distante), votre nom, celui de votre organisation et le numéro de série de votre logiciel, le programme d’installation demande le type d’installation souhaité : typique, minimum ou personnalisée.
• Par défaut: indiquer les comptes des services et le mode de licence utilisé ; le système installe alors un serveur satisfaisant la plupart des utilisateurs ;
• Minimum: indiquer les comptes des services et le mode de licence utilisé ; le système installe alors un serveur minimal capable de faire tourner SQL Server, mais économise au maximum l’espace consommé ;
• Personnalisée: à vous de choisir les options à installer.
L’installation personnalisée propose plusieurs options qui concernent :
• les composants à installer ;
• le classement et l’ordre de tri ;
Windows 2000, Datacenter Server Enterprise, Standard, Personal, Developer, Desktop
Windows CE Windows CE
a. La première édition listée dans chaque ligne est l’édition privilégiée pour la plate-forme concernée.
b. Quand, dans cet ouvrage, on mentionne Windows NT, il s’agit toujours de la version 4.0, car SQL Server ne fonctionne pas sur Windows NT 3.51.
Tableau 1
Système d’exploitation et édition de SQL Servera Système d’exploitation Éditions de SQL Server supportées
• les bibliothèques réseau (mécanisme d’IPC) supportées ;
• les comptes de connexion des services de SQL Server ;
• le mode de licence.
Pour en savoir plus
Ces différentes options sont décrites en détail au chapitre 2, « Installation de SQL Server », dans la section « Les options d’installation ».
La mise à niveau vers SQL Server 2000 n’est possible qu’à partir d’une version 6.5 ou 7 : on ne peut, par exemple, mettre à niveau une version 6.0 (sans parler d’une 4.2 ou d’une 1.x) sans, au préalable, l’avoir mise à niveau en version 6.5.
La mise à niveau de SQL Server est différente selon qu’il s’agit d’une version 6.5 ou 7. La mise à niveau d’un système 6.5 s’opère en deux temps. Il convient d’abord d’installer SQL Server 2000, puis de lancer l’Assistant Mise à niveau de SQL Server à partir de la machine obtenue. En version 7, la mise à jour est directe si vous installez SQL Server 2000 par-dessus SQL Server 7, ou peut être réalisée avec l’Assistant Copie de Base de données.
Important
Si vous souhaitez mettre à niveau une version 6.0 en version 2000, vous disposez de deux moyens, au choix :
• convertir votre système en SQL Server 6.5, puis procéder à la mise à niveau en version 2000 ;
• convertir votre système en SQL Server 7, avec l’Assistant Mise à Niveau livré avec SQL Server 7, puis procéder à la mise à niveau en version 2000.
À mon avis, le premier, à savoir passer par SQL Server 6.5, est préférable, car l’Assistant Mise à Niveau de SQL Server 2000 est plus performant que celui de SQL Server 7.
Éléments nécessaires à la mise à niveau
Lors d’une mise à niveau des bases de données, il importe que le serveur à migrer respecte les critères suivants :
• SQL Server 6.5, Service Pack 5a ;
• tempdb d’au moins 10 Mo, 25 Mo étant recommandés ;
• la base de données master doit disposer d’au moins 3 Mo d’espace libre.
La machine qui accueille SQL Server 2000 doit être installée conformément aux indications données au chapitre 2, « Installation de SQL Server » et fonc- tionner en authentification SQL.
Si l’on installe SQL Server 2000 sur une machine équipée de SQL Server 6.5, il ne faut surtout pas l’installer dans le même répertoire, car on perdrait toute possibilité de mise à jour des bases 6.5.
Il faut disposer de l’espace nécessaire à la création des nouvelles bases de données sur le serveur SQL Server 2000. On pourrait réutiliser l’espace des bases SQL Server 6.x en procédant à une mise à jour par bande, mais c’est déconseillé. Microsoft recommande de disposer d’au moins 1,5 fois la taille des bases 6.x.
Important
L’Assistant Mise à niveau de SQL Server s’appuie sur les canaux nommés pour piloter le transfert : les deux SQL Server doivent utiliser les canaux nommés par défaut : \\.\pipe\sql\query.
Le processus de mise à niveau
Le processus de mise à niveau peut se dérouler avec une ou deux machines, via un canal de communication direct ou par bande. La figure 1 présente les trois scénarios possibles.
Dans tous les cas de figure, l’Assistant Mise à niveau de SQL Server crée les nouvelles bases de données à une taille estimée correcte avant de se lancer dans le transfert des objets. Si la place vient à manquer sur le disque, le processus de mise à niveau échoue.
Lors d’une mise à jour, le système pose plusieurs questions :
• La mise à niveau se fait-elle par canal de communication direct (canaux nommés) ou par bande ?
• Faut-il vérifier le transfert ?
• Quels objets et bases de données faut-il transférer ?
• Faut-il modifier les options par défaut de création des bases de données ? Voyons les différentes options offertes au cours du transfert en vue de la trans- formation des données.
Mise à niveau par canal de communication direct
La mise à niveau par canal de communication direct est la plus sûre, puisqu’elle ne touche absolument pas aux données source, et qu’elle se contente de les transférer vers un nouveau format. Il faut bien évidemment disposer de suffisamment d’espace disque pour héberger les nouvelles bases (environ 1,5 fois la taille des bases source).
Précision : si l’on utilise cette méthode — et uniquement dans ce cas — il n’est pas nécessaire de migrer toutes les bases de données en même temps.
Mise à niveau par bande
La mise à niveau par bande utilise un lecteur de bande pour entreposer de manière temporaire les données à transférer. On optera pour la migration par bande si l’on n’a pas assez d’espace disque. Si, par contre, on a un certain confort de ce côté, il est préférable d’employer le processus par canal de communication direct.
Important
Le système ne fait pas de sauvegarde des bases de données ; il utilise un format propre au transfert et, de plus, formate la bande avant de commencer le transfert.
Figure 1
Différents types de mise à niveau
L’assistant peut, une fois les données copiées sur la bande, et avant de les remonter dans SQL Server 2000, supprimer les unités des bases de données SQL Server 6.5. Il faut garder à l’esprit que toutes les unités seront alors supprimées : il est donc impératif de faire migrer toutes les bases en une seule opération.
Au lancement, l’assistant propose soit de s’interrompre pour vous permettre de sauvegarder vos bases avant de les faire migrer, soit de faire une copie des fichiers d’unités vers un répertoire partagé sur le réseau. Si jamais il se produisait une erreur lors de la migration, après suppression des bases 6.5, il vous serait possible de revenir à vos bases 6.5 rapidement en réinstallant une version 6.5 et en remontant vos sauvegardes ou les copies des unités.
Les vérifications
L’assistant peut vérifier, après une migration :
• La réussite du transfert (par défaut) : le système compare les noms des objets et le nombre de lignes dans les tables avant et après la migration.
Dans la plupart des cas, cette vérification est suffisante.
• L’exhaustivité des données : l’assistant calcule une somme de contrôle colonne par colonne et en compare les valeurs avant et après la migration.
Dans tous les cas, l’assistant génère des journaux (upgrade.log et differences report.log, tous deux situés dans le répertoire \PROGRAM FILES\MICROSOFT SQL SERVER\MSSQL\UPGRADE\nomserveur_date_heure), qui permettent de connaître les transformations opérées sur les données pendant la migration et les différences éventuelles d’état avant et après mise à niveau.
Les bases à transférer
L’assistant propose de choisir, parmi les bases, celles que l’on veut mettre à jour, hormis les bases système (master, msdb, tempdb) et la base exemple pubs, qui n’apparaissent pas dans la liste de sélection des bases de données.
Seules les bases sélectionnées seront migrées :
• en ce qui concerne tempdb, inutile de la faire migrer, c’est une base temporaire… Quant à pubs, elle se trouve déjà dans SQL Server 2000, de plus ce n’est qu’une base exemple.
• master sera migrée si l’on opte pour la migration de la configuration du serveur. L’assistant importera alors les noms d’accès et les options de configuration du système.
• msdb sera migrée si l’on demande la migration des Paramètres de SQL Executive.
• distribution sera migrée si l’on demande la migration des Paramètres de réplication.
Pour refaire la migration d’une base de données, il faudra la supprimer dans SQL Server 2000, puis redemander sa migration.
Important
Si l’on veut mettre à niveau un système sur lequel la réplication a été installée, il faut commencer par le distributeur, puis faire migrer les éditeurs et les abonnés.
En effet, un distributeur en version 2000 peut gérer éditeurs et abonnés de la version 6.5, alors qu’en version 6.5, il ne peut gérer ni éditeurs ni abonnés de la version 2000.
Modification du schéma des bases à transférer
L’assistant estime automatiquement l’espace nécessaire aux bases de données migrées. Il crée automatiquement les fichiers, en partant des emplacements et des noms des unités initiales, conformément aux règles suivantes :
Figure 2
Écran de visualisation des bases de données et fichiers créés
Tableau 2 Unités 6.5 et fichiers 2000
Unités SQL Server 6.5 Fichiers SQL Server 2000 Données : CHEMIN\FICHIER.DAT CHEMIN\FICHIER.MDFOU .NDF
Tous les fichiers sont placés au même endroit que leurs unités source. Le fichier .MDF est taillé pour recevoir la totalité des données, les autres fichiers (.NDF) l’étant au minimum.
Journal : CHEMIN\FICHIERLOG.DAT CHEMIN\FICHIER.LDF
Si la base SQL Server 6.5 comprend plusieurs fichiers de journaux, la base SQL Server 2000 n’en aura qu’un, à l’emplacement de la première unité de journal SQL Server 6.5.
Il est possible de modifier les paramètres de ces fichiers avant d’effectuer la migration. On peut :
• modifier la taille, le nom et l’emplacement de chaque fichier ;
• supprimer un ou plusieurs fichiers .NDF;
• modifier la valeur de l’auto-incrément.
Il est possible d’affiner la personnalisation en créant la base de destination dans SQL Enterprise Manager, ou avec Transact-SQL, avant de lancer la migration.
Les options
Il existe enfin deux options essentielles lors de la migration, concernant :
• le comportement du moteur face à la valeur NULL;
• le comportement du moteur face aux identificateurs entre guillemets.
Figure 3 Modification de la taille, de l’emplacement et de l’incrément d’un fichier
Figure 4 Options de la mise à niveau
ANSI_NULLS
Cette option correspond à l’instruction SET ANSI_NULLS. Elle modifie le comportement du moteur face aux valeurs NULL et surtout face à la norme ANSI-92. Elle détermine :
• l’identification des colonnes des tables comme autorisant ou non la valeur
NULL;
• le résultat des comparaisons = et <> par rapport à la valeur NULL: elles sont toujours fausses, même si la colonne comparée contient des valeurs
NULL, car l’opérateur autorisé est ISNULL.
Si vous avez une base SQL Server 6.5 ANSI ou si vous avez des doutes quant à la compatibilité de vos bases, activez cette option.
Identificateurs entre guillemets
Cette option correspond à l’instruction SET QUOTED_IDENTIFIER. Elle définit le comportement de SQL Server face aux doubles guillemets ("). L’assistant propose trois possibilités :
• ON: les guillemets jouent le rôle de délimiteurs d’identificateurs. Par exemple, dans la requête select "test" from matable, test est le nom d’une colonne.
• OFF: les guillemets délimitent des chaînes de caractères. Par exemple, dans la requête select "test" from matable, test est une chaîne de caractères à renvoyer telle quelle.
• Mixte : l’assistant fait migrer tous les objets avec ON, puis fait migrer ceux qui ont généré des erreurs avec la valeur OFF.
Si vous avez des doutes sur l’utilisation des guillemets dans les procédures stockées, utilisez le choix mixte.
Important
Une procédure stockée conserve après création le comportement des guillemets.
Si elle a été créée avec SETQUOTED_IDENTIFIERON, elle considérera les guille- mets comme des délimiteurs d’identificateur, même si SET QUOTED_IDENTIFIER
est à OFF lors de son exécution.
Une fois tous les choix effectués, l’assistant fait ses dernières vérifications et lance la migration. Ce processus est sans risque, puisque les bases source SQL Server 6.5 ne sont pas du tout touchées. S’il y a un quelconque échec, il suffit de repasser à SQL Server 6.5 depuis le menu Commutation, le temps de résoudre le problème, puis de relancer le processus. L’assistant dispose en effet d’un ensemble de marqueurs qui lui permettent de savoir si le processus s’est déroulé correctement ou non. Si vous relancez la mise à niveau après un
problème, vous obtiendrez la boîte de dialogue de la figure 5, qui permet de reprendre le processus où il s’est arrêté ou de le recommencer.
À la fin d’une mise à niveau, l’assistant propose la liste des tâches effectuées avec leur durée, telles qu’elles sont enregistrées dans le fichier UPGRADE.LOG.
Tous les fichiers de scripts utilisés pendant la migration, ainsi que les fichiers journaux, peuvent être consultés dans le répertoire \PROGRAM FILES\
MICROSOFT SQL SERVER\MSSQL\UPGRADE\nomserveur_date_heure. Si on lance la mise à niveau plusieurs fois, on obtient autant de répertoires nomserveur_date_heure que de tentatives.
En résumé, la mise à niveau des données SQL Server 6.5 en SQL Server 2000 est un processus sans problème et sans risque. Les problèmes peuvent surve- nir par la suite quand vous essayez de connecter vos applications à SQL Server 2000, surtout si elles utilisent des fonctionnalités propres à SQL Server 6.5 qui ne sont plus supportés dans SQL Server 2000 (rare, mais non impossible).
Figure 5 Avertissement de l’assistant mise à niveau
Figure 6 Liste des tâches effectuées par l’assistant de mise à niveau.
Sept bonnes raisons de passer de SQL Server 6.5 à SQL Server 2000
Voici, pêle-mêle, sept bonnes raisons de passer de SQL Server 6.5 à SQL Server 2000 ; ce sont, à mon sens, les innovations les plus utiles aux sites en production, sachant qu’à ce jour, il ne saurait être question d’exhaustivité. La lecture des chapitres cités en référence permettra d’approfondir le sujet.
Les nouvelles structures de stockage
La taille des pages de données passe de 2 kilo-octets à 8 kilo-octets, et les entrées-sorties s’améliorent. C’est avant tout la solidité de ces structures qui apportent le plus de satisfaction : le fait, par exemple, que les pages ne soient plus doublement chaînées, mais accessibles par des index bitmaps, rendent inutiles certaines opérations DBCC et limitent les éventuelles corruptions d’allocation ; l’évolution des structures de stockage a aussi transformé les mécanismes de sauvegarde, plus rapides et plus fiables.
Pour en savoir plus
Les structures de stockage sont décrites en détail aux chapitres 3, « Architecture de SQL Server » et 4, « Architecture d’une base de données SQL Server ».
Le verrouillage de ligne
Enfin, même si le verrouillage de ligne ne résout pas tous les problèmes, il permet d’éviter l’apparition de nombreux blocages, et il est totalement dynamique !
Dans la version 6.x, tous les verrous étaient des verrous de page, mais pouvaient être « escaladés » en verrous de table, sur la base d’un seuil pour le nombre de verrous de page placés. Depuis la version 7, la granularité du verrou (ligne, page, table) est choisie par le système en fonction de paramè- tres variés : le nombre estimé d’enregistrements récupérés, l’activité du système, le type d’instruction exécutée… En somme, le verrouillage ligne, c’est bien ; le verrouillage dynamique, c’est encore mieux !
Pour en savoir plus
Les mécanismes de verrouillage sont décrits en détail aux chapitres 10,
« Développement d’applications client-serveur traditionnelles », et 12,
« Optimisation des performances ».
La croissance automatique des bases de données
Finis les bases de données et les journaux de transactions saturés ! Par défaut, vos bases de données vont croître sans autre limite que la taille du disque dur.
Cette possibilité est utile, en particulier pour les petites et moyennes bases, mais il est préférable de fonctionner en préallocation statique d’espace pour des bases de données d’une taille supérieure au giga-octet.
Pour en savoir plus
Les bases de données sont décrites en détail au chapitre 4, « Architecture d’une base de données SQL Server ».
L’administration simplifiée
Plus d’assistant et un paramétrage quasi nul ! Presque tous les paramètres sont calculés de manière automatique et dynamique : l’espace mémoire utilisé, le nombre de connexions, etc. En bref, le rêve d’un administrateur ! Cependant, pour les passionnés, tout est débrayable et paramétrable à la main.
Pour en savoir plus
L’administration des bases et des opérations connexes est décrite dans tous les chapitres. Vous découvrirez de nombreuses astuces au fil de votre lecture.
Le nouveau processeur de requêtes
Un régal ! À côté, celui de SQL Server 6.x fait figure d’un « jambon-beurre » comparé à un repas chez un « trois étoiles Michelin » ! En voici quelques caractéristiques :
• utilisation de plusieurs index par table dans une requête ;
• choix de plusieurs stratégies de jointures : itération imbriquée, fusion ou hachage (hash-coding) ;
• choix de plusieurs stratégies de regroupement ;
• exécution des requêtes sur tous les processeurs disponibles, en parallèle ;
• statistiques de distribution des données fondées sur des algorithmes d’échantillonnage et mises à jour automatiquement.
Associé à l’analyseur de requêtes et à son plan d’exécution graphique, il s’agit de l’un des meilleurs processeurs heuristiques du marché.
Pour en savoir plus
L’optimiseur de requêtes est décrit en détail au chapitre 12, « Optimisation des performances ».
Les services de transformation de données
C’est la fonction — ou le produit ? — qui me séduit le plus. Grâce aux DTS (Data Transformation Services), les possibilités de manipulation de données sont infinies :
• importation et exportation de données d’une source OLE-DB depuis/vers une autre source OLE-DB ;
• planification de ces importations/exportations ;
• transformation, filtrage, normalisation des données au moment de l’impor- tation/exportation via un langage de programmation simple et puissant comme Visual Basic ou Java ;
• mise en place aisée des mises à jour incrémentales ;
• conception graphique de scripts complexes avec le concepteur de lots DTS ;
• utilisation simple des lots DTS puisqu’il s’agit d’objets COM…
Bref, ne serait-ce que pour DTS, le passage à SQL Server 2000 est un
« must ».
Pour en savoir plus
DTS est décrit en détail au chapitre 9, « Exporter et importer des données ».
Les serveurs liés
Les serveurs liés — ou comment écrire des requêtes hétérogènes sans jamais se préoccuper du format des données — permettent de déclarer des bases de données de n’importe quel type (Oracle, Access, DB2…), et d’y faire réfé- rence comme s’il s’agissait de bases SQL Server. Il est donc possible d’inter- roger et de mettre à jour les données, mais aussi de créer des jointures entre tables hétérogènes ou de transférer des données d’une base à l’autre en n’utili- sant que des instructions SQL.
Pour en savoir plus
Les serveurs liés sont décrits en détail au chapitre 7, « Récupérer et mettre à jour des données distribuées ».
Vous trouverez d’autres bonnes raisons de passer à SQL Server 2000 dans la section suivante.
De SQL Server 7 à SQL Server 2000
Un peu moins de 2 ans se sont écoulés entre la sortie de SQL Server 7 et de SQL Server 2000. Avant sa sortie et son baptême, cette nouvelle version était numérotée 7.5. Les différences entre SQL Server 7 et SQL Server 2000 sont en effet d’un ordre comparable à celles qui existent entre SQL Server 6.0 et SQL Server 6.5. Ceci dit, si les quelques nouveautés de l’interface graphique peuvent laisser de glace, un ensemble de détails montre que l’équipe de déve- loppement de Microsoft a fait de gros efforts pour intégrer un ensemble de nouveautés que nous aurions aimé voir dans SQL Server 7, et qui font de SQL Server 2000 une vraie nouvelle version, qui n’a pas à rougir de son numéro.
Éléments nécessaires à la mise à niveau
La mise à niveau de SQL Server 7 vers SQL 2000 est un processus beaucoup plus simple que celle de SQL Server 6.5. En effet, les structures de données n’ont que très peu évolué, et la mise à niveau s’assimile plus à un transfert de base de données qu’à une réelle mise à niveau.
Comme pour une mise à niveau depuis SQL Server 6.5, celle d’un serveur SQL Server 7 peut se faire sur une seule machine ou en impliquer deux. La grosse différence avec SQL Server 6.5 est que, compte tenu de la nouveauté des instances multiples d’un moteur SQL Server 2000, il est tout à fait possi- ble de faire tourner simultanément sur le même serveur SQL Server 7 et SQL Server 2000.
Le processus de mise à niveau
Sur une seule machine, le processus de mise à niveau d’une installation de SQL Server 7 peut avoir lieu pendant l’installation de SQL Server 2000 ou après cette opération :
• si vous mettez à niveau SQL Server 7 pendant l’installation de SQL Server 2000, ce dernier prend la place de SQL Server 7. Il est fortement conseillé de sauvegarder vos bases de données SQL Server 7 avant de procéder à une telle mise à niveau ;
• vous pouvez aussi installer une instance nommée de SQL Server 2000 qui va fonctionner en parallèle de SQL Server 7. Les deux moteurs fonction- nent alors en même temps sur le serveur, ce qui vous permet de mettre à niveau vos bases de données sans risque. L’unique contrainte de cette méthode est l’espace nécessaire. Il faut en effet assez d’espace sur disque pour copier les bases de données, celles de l’instance de SQL Server 7 n’étant pas impactées.
Mise à niveau avec remplacement de SQL Server 7
Si vous lancez l’installation de SQL Server 2000 sur un serveur contenant SQL Server 7, le programme d’installation active l’option de mise à niveau.
Le processus d’installation va alors se poursuivre en vous demandant de confirmer la mise à niveau.
Si vous poursuivez dans cette voie, toutes les bases de données SQL Server 7 vont être mises à niveau, ainsi que tous les paramètres de votre serveur, tels les noms d’accès, les travaux de l’agent, les messages d’erreurs personnali- sés… En fait vous allez retrouver votre configuration SQL Server 7 sous SQL Server 2000, sans retour en arrière possible, à moins de réinstaller SQL Server 7 et de restaurer vos bases de données. Pour s’assurer que vous savez
Figure 7
Mise à niveau de SQL Server 7 pendant l’installation de SQL Server 2000
Figure 8
Mise à niveau de SQL Server 7 pendant l’installation de SQL Server 2000
ce que vous faites, le programme d’installation va vous demandez de confir- mer une troisième fois votre choix !
Le processus se poursuit alors automatiquement. Il ne vous reste plus qu’à croiser les doigts pour que tout se passe bien.
Mise à niveau avec une instance nommée de SQL Server 2000
L’autre solution de mise à niveau consiste à installer une nouvelle instance nommée de SQL Server 2000 en parallèle de SQL Server 7 (voir Chapitre 2).
Une fois l’instance nommée de SQL Server 2000 installée, on dispose de deux moteurs SQL Server, l’un en version 7, l’autre en version 2000, pouvant tourner conjointement et permettant la mise à niveau des bases de données SQL Server 7 en toute sécurité. Lorsque l’installation est terminée, on accède aux deux instances depuis SQL Enterprise Manager1 (figure 10).
Le processus de mise à niveau est alors pris en charge par l’Assistant Copie de bases de données. Placez-vous sur l’instance de SQL Server 7 et démarrez l’Assistant Copie de bases de données depuis la liste des assistants (menu Outils, Assistants). Dans l’assistant, choisissez votre instance de SQL Server 7 comme source de données et votre instance nommée de SQL Server 2000 comme destination. L’assistant va alors vous proposer la liste des bases de données à migrer.
Dans la copie d’écran de la figure 11, on constate que les bases systèmes ne sont pas à migrer ; d’autre part que, comme les bases exemples existent déjà, elles ne sont pas migrées et que la base Gestion peut être copiée ou déplacée.
Figure 9 Confirmation de la mise à niveau de SQL Server 7
1. Une grande partie des copies d’écran du livre ont été réalisées depuis un client installé sous Windows XP Professionel, alors que les serveurs étaient sous Windows 2000 Advanced Server.
Si vous envisagez le déplacement, à faire en cas de manque d’espace sur le serveur, faites une sauvegarde de la base avant de lancer son déplacement.
L’assistant va ensuite vous proposer l’emplacement et la taille des fichiers de données et de journaux de transaction, avec possibilité de les modifier.
Figure 10
Administration des instances de SQL Server 7 et de SQL Server 2000
Figure 11
Choix des bases de données à mettre à niveau
Vient ensuite le choix des éléments système à migrer. Car, si les bases système ne sont pas à mettre à niveau, du fait qu’elles existent déjà dans votre instance de SQL Server 2000, elles contiennent des éléments à copier.
On peut ainsi copier les noms de connexion, les procédures utilisateur stoc- kées, enregistrées dans la base de données master, les travaux et les messages d’erreurs personnalisés. Noter que ces quatre types d’objets sont copiés grâce à de nouvelles tâches des Data Transformation Services (voir chapitre 13,
« Automatisation des tâches »). L’assistant va alors créer un lot DTS pour prendre en charge la copie, que l’on peut exécuter immédiatement ou planifier pour une exécution ultérieure.
Figure 12 Choix des éléments système à copier
Figure 13 Création du lot DTS
Le processus peut maintenant être lancé. Pendant son exécution, une fenêtre d’avancement vous donne des informations sur ce que fait SQL Server et sur les erreurs éventuelles.
À partir de cette étape, vous pouvez tester vos applications avec cette nouvelle instance de SQL Server 2000 et finalement décider de mettre SQL Server 7 au fond d’un placard.
Sept bonnes raisons de passer de SQL Server 7 à SQL Server 2000
Les raisons qui font pencher la balance en faveur de la mise à niveau de SQL Server 7 vers SQL Server 2000 sont nombreuses. Vous en découvrirez dans les sections suivantes. En voici cependant sept qui me semblent suffisantes, tant elles améliorent la vie quotidienne des développeurs, des administrateurs et des utilisateurs.
Figure 14
Journal d’avancement de la mise à niveau des bases de données SQL Server 7
Support de XML
XML (Xtended Markup Language) est au cœur des échange de données sur Internet et totalement intégré dans Windows XP, Windows .Net, Visual Studio .Net et tous les produits .Net de Microsoft. Tôt ou tard vous y viendrez. XML est intégré dans SQL Server 2000. Il est donc possible d’interroger des données SQL Server en XML, de mettre à jour ces mêmes données à partir de document XML, etc.
Pour en savoir plus
Les fonctionnalités XML sont décrites en détail au chapitre 11, « Développement d’applications clientes Internet et intranet ».
Indexation des vues
Jusqu’à SQL Server 7, une vue était simplement une requête nommée. Quand une vue était interrogée, le système accédait aux tables sous-jacentes. Dans le cadre de l’informatique décisionnelle, où certaines vues peuvent interroger plusieurs dizaines de tables simultanément, la capacité d’indexer une vue permet de rapprocher et stocker les données ce qui accélère considérablement leur restitution.
Pour en savoir plus
Les vues indexées sont décrites en détail au chapitre 4, « Architecture d’une base de données SQL Server ».
L’analyseur de requêtes
L’analyseur de requêtes a subi un sérieux « lifting » (voir figure 15). Il contient un explorateur d’objet, un débogueur de procédure stockée, des fonc- tions améliorées de mise en forme du code, des informations étendues d’analyse des performances, etc. Une fois utilisé, adopté pour toujours (enfin, jusqu’à la prochaine version…) !
L’intégrité référentielle en cascade
Voici une fonctionnalité que l’on attendait avec impatience. Fini les déclen- cheurs, fini le code client, l’intégrité référentielle en cascade permet de mettre en œuvre suppression et mise à jour en cascade, y compris à plusieurs niveaux, avec un simple clic de souris pour la définition des relations.
Pour en savoir plus
L’intégrité référentielle en cascade est décrite en détail au chapitre 4,
« Architecture d’une base de données SQL Server ».
Les classements définis par base de données
Dans un environnement international, tous les serveurs ne sont pas forcément installés avec le même jeu de caractères et le même ordre de tri. Il en est de même des classements de SQL Server 2000. Ceci étant, chaque base de données (voire chaque colonne d’une table) peut utiliser un classement diffé- rent (jeu de caractères, ordre de tri), sur un même serveur. Au revoir le casse- tête des classements, bonjour la simplification.
Pour en savoir plus
L’intégrité référentielle en cascade est décrite en détail au chapitre 4,
« Architecture d’une base de données SQL Server ».
Les fonctions définies par l’utilisateur
Encore une fonctionnalité annoncée pour SQL Server 7, arrivée avec SQL Server 2000. Entre les vues et les procédures stockées, les fonctions définies par l’utilisateur (UDF, User Defined Function) permettent de créer des fonc- tions renvoyant des valeurs scalaires ou des tables, pouvant être utilisées en lieu et place des fonctions système ou des noms de table ou de vue. Elles éten- dent la fonctionnalité des vues en admettant des paramètres.
Pour en savoir plus
Les fonctions définies par l’utilisateur sont décrites en détail au chapitre 4,
« Architecture d’une base de données SQL Server ».
Les déclencheurs
INSTEADOFNous avions les déclencheurs after jusqu’à la version 7, c’est-à-dire qu’ils se déclenchaient après exécution de l’instruction — pour l’annuler le cas échéant. SQL Server 2000 introduit les déclencheurs INSTEADOF qui s’exécu- tent à la place des instructions qui les ont déclenchées. De plus, ils peuvent être créés sur des vues, ce qui étend leur capacité de mise à jour.
Pour en savoir plus
Les déclencheurs INSTEADOF sont décrits en détail au chapitre 4, « Architecture d’une base de données SQL Server ».
Outils de gestion
Au passage de la version 6.x à la version 7, tous les outils avaient été revus (tout le logiciel, en fait…). SQL Server 2000 est allé encore un peu plus loin.
Le tableau 3 donne un bref aperçu des équivalences entre les outils des versions 6.x et ceux de la version 2000.
Passons en revue ces outils afin d’en détailler les améliorations.
Analyseur de requêtes
Cette version n’a plus grand rapport avec ISQL_w. Parmi ses fonctionnalités majeures, citons :
• la visualisation simultanée de la requête et du résultat ;
• l’affichage de la durée d’exécution ;
• l’édition du code en couleur ;
• le plan d’exécution graphique, estimé et réel (figure 15).
Tableau 3
Outils de gestion SQL Server
Outil SQL Server 2000 Equivalent SQL Server 6.x
Analyseur de requêtes ISQL_w
Services de composants de Windows Objet DTC dans SQL Enterprise Manager Documentation en ligne Titres en ligne
Enterprise Manager SQL Enterprise Manager
Générateur de profils SQL Trace
Gestionnaire de services SQL Server Gestionnaire de services SQL Server Importation et exportation de données Bcp (pas d’équivalent en mode graphique)
Utilitaire Réseau Client Configuration réseau client, dans le Panneau de configuration Utilitaire Réseau Serveur Dans le programme d’installation de SQL Server 6.x
Services de composants
MSDTC (Microsoft Distributed Transaction Coordinator) gère toujours les transactions distribuées, appelées couramment Commit à deux phases. Intégré à SQL Enterprise Manager dans la version 6.x, il a maintenant gagné ses galons d’indépendant.
DTC est un composant standard de Windows 2000, de Windows NT 4 avec l’option Pack 4 et de Windows XP/.Net (figure 16). Il fait partie des services de composants.
Documentation en ligne
Fini les « Titres en ligne », voici la documentation en ligne ! Deux évolutions importantes : un nouvel outil de visualisation et le tout HTML… En règle générale, la documentation est fort bien faite. Elle n’est pas traduite en tota-
Figure 15
Analyse graphique du plan d’exécution d’une requête
lité, mais seuls les développeurs s’en plaindront, puisque tous les livres d’administration sont en français.
Enterprise Manager
L’évolution la plus importante de SQL Server se trouve incontestablement dans SQL Enterprise Manager. La nouvelle version est livrée comme compo- sant enfichable de Microsoft Management Console (MMC). MMC constitue l’outil de visualisation de base de Windows 2000. Il est livré aussi avec l’Option Pack de Windows NT 4.
Mais là n’est pas la seule évolution. SQL Enterprise Manager (figure 17) a été entièrement repensé selon deux axes : tirer parti des nouvelles fonctionnalités de SQL Server 2000 et simplifier au maximum le travail des administrateurs et des développeurs.
Parmi les nouveautés, citons notamment :
• la création et la modification en mode graphique des tables, des vues, des procédures stockées et des fonctions définies par l’utilisateur ;
• de nombreux assistants, tels ceux d’importation et d’exportation de données, de mise en place de la réplication…
• le suivi de l’activité du serveur, connexion par connexion ;
• l’intégration des compteurs de l’analyseur de performances dans les aler- tes de SQL Server ;
Figure 16 Administration de DTC
• des plans de gestion revus ;
• la création et la gestion des serveurs liés, particulièrement des serveurs Oracle et des bases Access ;
• l’intégration de l’Assistant Web.
Cette liste n’est pas exhaustive, mais donne un rapide aperçu du travail réalisé par les développeurs de Redmond…
SQL Enterprise Manager est un outil incontournable, mais pas toujours très
« logique ». Nous reparlerons de ses incohérences au fil de ce livre.
Générateur de profils
Le Générateur de profils (figure 18) et SQL Trace ne se rejoignent qu’en un point : leur but. Ils interceptent tous deux les instructions entre les clients et un serveur. Le Générateur de profils va beaucoup plus loin dans :
• la création et l’utilisation de nombreux filtres ;
• le regroupement multicritères ;
Figure 17
SQL Enterprise Manager
• la sauvegarde, dans une table ou un fichier, des traces ou des seules instructions reçues ;
• l’analyse des instructions contenues dans une procédure stockée.
Vous vous servirez du Générateur de profils comme source de l’optimiseur d’index, pour repérer les requêtes les plus lentes, identifier les processus bloquants ou encore enregistrer la charge de travail d’un serveur.
Nous retrouverons le Générateur de profils dans les chapitres de la cinquième partie, « Optimisation et automatisation ».
Gestionnaire de services SQL Server
Rien de bien neuf dans l’interface du Gestionnaire de services (figure 19) ; il sert toujours à arrêter, mettre en pause ou démarrer les services MSDTC, MSSQLServer et SQL Server Agent.
Figure 18 Console du Générateur de profils
Il existe deux autres moyens de le lancer : le menu Démarrer et le raccourci dans la barre des tâches.
Grâce à l’icône de la barre des tâches et à son menu contextuel, on accède aux mêmes services qu’au travers de l’interface du Gestionnaire de services et on peut connaître l’état du service sélectionné.
Importation et exportation de données
Voilà enfin comblée l’attente de tous les utilisateurs du BCP (Bulk Copy Program). Bien que le BCP existe toujours, les services de distribution de données (DTS, Data Transformation Services) le remplacent allègrement.
L’Assistant DTS (figure 21) se lance depuis le menu Démarrer. Ce n’est que la partie visible de l’iceberg DTS. Cet assistant ne sert qu’à importer ou exporter une ou plusieurs tables depuis ou vers une base de données SQL Server ou autre, mais DTS va beaucoup plus loin… En fait, DTS n’est pas spécifique de SQL Server (figure 22).
Ces services permettent de « pomper » des données d’une source dotée d’un fournisseur OLE-DB ou d’un pilote ODBC, pour les envoyer vers une autre, dotée elle aussi d’un fournisseur OLE-DB ou d’un pilote ODBC, après trans- formation éventuelle grâce à des scripts Visual Basic ou Java.
Pour en savoir plus
Les services DTS sont décrits en détail au chapitre 9, « Exporter et importer des données ».
Figure 19
Gestionnaire de services SQL Server
Figure 20
Gestionnaire de services dans la barre des tâches
Utilitaire Réseau du client SQL Server
Cet utilitaire permet de définir et de paramétrer les bibliothèques de réseau à partir desquelles le client SQL émet. Quelque peu revu, il ne fait plus partie du Panneau de configuration.
Figure 21 Assistant importation/exportation DTS
Figure 22 Services de transformation de données
Utilitaire Réseau SQL Server
Cet utilitaire définit et paramètre les bibliothèques de réseau à partir desquel- les le serveur SQL émet et écoute. Initialement situé dans la procédure d’installation de SQL Server, il constitue maintenant un outil à part, sans grosse innovation (figure 24). Il reste primordial de paramétrer correctement ces bibliothèques en fonction des différents types de clients, et client et serveur doivent utiliser les mêmes bibliothèques pour pouvoir communiquer.
Figure 23
Utilitaires réseau du client SQL Server
Figure 24
Utilitaires réseau SQL Server
Structure des données
L’une des évolutions majeures de SQL Server concerne les formats de fichiers (et donc de données), et la version 6.x et la version 2000 ne sont pas compatibles sur ce point. En fait, depuis la version 1.0, ils n’avaient guère changé et souffraient de leur âge (une bonne dizaine d’années !). Depuis les années 80, le matériel et les logiciels ont considérablement évolué ; il deve- nait donc primordial de faire évoluer aussi les structures de données pour répondre aux nouveaux besoins en termes de stockage, mais aussi de gestion des volumes, de performances, d’administration, etc.
Les unités SQL Server 6.x ne sont pas directement compatibles avec les fichiers de SQL Server 2000. Il faut passer par l’intermédiaire de l’Assistant Mise à niveau SQL Server, présenté dans la section précédente.
Voici quelques nouvelles caractéristiques qui justifient l’intérêt de ce changement :
• le journal des transactions est obligatoirement séparé des données ;
• la taille maximale d’une base de données est désormais de 1 048 516 téra- octets, dont 4 téra-octets au maximum pour le journal des transactions ;
• 1 024 colonnes au maximum par table ;
• 8 060 octets au maximum par enregistrement (hors type image et text) ;
• les caractères Unicode font l’objet de trois nouveaux types de données, nchar, nvarchar et ntext;
• les noms d’objets sont désormais limités à 128 caractères et peuvent contenir tout type de caractère, espace compris ;
• les pages de données occupent désormais 8 kilo-octets ;
• une extension, composée de 8 pages (ayant donc une taille de 64 kilo- octets), peut contenir plusieurs tables et/ou index ; il existe des extensions mixtes (contenant plusieurs tables et/ou index) et des extensions unifor- mes (ne contenant qu’une table ou un index).
Cette liste n’est bien sûr pas exhaustive, mais elle contient les points les plus importants. Le but avoué de cette restructuration est de :
1. optimiser les entrées/sorties pour tirer parti des capacités des sous-systè- mes de disques les plus récents ;
2. repousser les limites théoriques du produit pour répondre à la concurrence.
En règle générale, ces nouvelles fonctionnalités ou caractéristiques nous simplifient beaucoup la vie et améliorent les performances d’une application.
Tous ces points sont détaillés dans la première partie de ce livre.
Verrouillage
À l’instar des structures de données, le système de verrouillage et les verrous ont été modifiés. Tout d’abord, la granularité des verrous (figure 25) est, par défaut, réduite à la ligne de données, pour toute opération de lecture, de mise à jour, d’insertion et de suppression sur les tables et les index. Ensuite, l’opti- miseur de requêtes choisit le type de verrou en fonction du nombre de lignes à lire (ou à modifier) et de l’activité sur le système.
Le système choisit le type de verrou de manière à :
• minimiser le nombre de verrous, ce qui favorise l’emploi des verrous de page (voire de table) face aux verrous de ligne ;
• minimiser la contention du système en multiutilisation, ce qui favorise l’utilisation des verrous de ligne face aux verrous de page (voire de table).
Il cherche donc à équilibrer le nombre de verrous posés et le nombre maxi- mum d’utilisateurs actifs simultanément. L’avantage du verrouillage de ligne est évident dans les applications transactionnelles, puisqu’il permet le support d’un plus grand nombre d’utilisateurs tout en diminuant la contention du système. Parmi les améliorations, notons dès maintenant l’existence d’un timeout sur les verrous. Il permet d’annuler, au-delà d’un certain délai, une requête bloquée en attente de verrouillage.
Figure 25
Granularité des verrous
Transact-SQL
On pourrait consacrer un chapitre entier aux innovations de Transact-SQL. En voici les principales améliorations :
• les types Unicode : nchar, nvarchar et ntext;
• les types de données : bigint, sql_variant et table;
• la taille maximale des colonnes char et varchar, de 8 000 caractères ;
• la possibilité de modifier le type d’une colonne d’une table contenant déjà des données ;
• la possibilité d’ajouter et de supprimer des colonnes à une table contenant des données ;
• le remplissage d’une nouvelle colonne avec une valeur par défaut ;
• la création d’index croissants ou décroissants ;
• l’indexation des colonnes calculées ;
• le nombre illimité de déclencheurs sur une table ;
• les déclencheurs INSTEADOF;
• l’instruction ALTER qui permet de modifier un déclencheur, une procédure stockée ou une vue ;
• les vues indexées ;
• les fonctions définies par l’utilisateur ;
• le processeur de requêtes permettant de tirer parti des nouveaux algorith- mes de jointures et de verrouillage ;
• la clause TOP n du SELECT, qui sert à récupérer les n premiers enregistre- ments sélectionnés ;
• l’instruction DENY, pour supprimer les droits d’un utilisateur ou d’un rôle sur un objet ;
• le type uniqueidentifier, pour ajouter une colonne GUID (Globally Unique Identifier) à une table, ce qui garantit l’unicité des valeurs sur plusieurs serveurs ;
• le type rowversion remplaçant timestamp;
• le type cursor, pour passer des curseurs en tant que paramètres de procé- dures stockées.
Pour en savoir plus
Rechercher « Améliorations en matière de bases de données relationnelles » dans la documentation en ligne pour en avoir une liste exhaustive. La liste est longue...
Points clés
• La mise à niveau d’une base de données 6.x vers 2000 peut se faire sur une ou sur deux machines, par canal de communication direct ou par bande.
• Si l’on opte pour une mise à niveau par bande, il faut sauvegarder les bases 6.x avant de lancer la mise à niveau.
• Toute l’administration des bases SQL Server 2000 se fait au travers de Micro- soft Management Console et de SQL Enterprise Manager.
• Les pages de données occupent désormais 8 kilo-octets.
• Les blocs de huit pages de données, appelés extensions, peuvent contenir des tables et/ou des index différents.
• Les verrous se posent sur un enregistrement, une page, une table ou un index.
• Par défaut, les bases de données augmentent automatiquement en fonction des besoins en stockage.
• Les services de transformation de données (DTS) permettent d’importer, exporter, transformer, filtrer, etc. des données d’une source OLE-DB.
• SQL Server 2000 offre de nombreuses nouveautés aux utilisateurs de SQL Server 7, bien qu’en majorité elles soient plutôt des fonctionnalités en arrière- plan.
