Préparez-vous

vous permettra
d’utiliser les deux versions de la
base de données en parallèle pendant
quelques jours pour adoucir la transition.
Vous pouvez exécuter SQL Server
2000 et 6.5 sur le même ordinateur,
mais pas en même temps, à  moins
d’installer une instance nommée de
SQL Server 2000. Toutefois cela complique
l’opération de mise à  niveau
parce que l’Upgrade Wizard a besoin
d’une instance par défaut, pas d’une
instance nommée, de SQL Server 2000.

D’un point de vue réaliste, si vous utilisez
SQL Server 6.5, il vous faudra peutêtre
mettre à  niveau l’ancien matériel
serveur juste pour SQL Server 2000. Si
vous avez deux serveurs, vous pouvez
également déplacer les bases de données
une à  la fois, plutôt que de les
mettre toutes à  niveau en même
temps. Et, si cela ne suffit pas pour
convaincre votre patron de l’intérêt
d’ajouter un serveur, nous verrons
plus loin dans cet article une idée
d’utilisation intéressante pour l’ancien
ordinateur.

Avant de démarrer la mise à  niveau,
sauvegardez les bases de données.
Exécutez aussi quelques utilitaires de
vérification de cohérence de la base de données (commandes DBCC) comme
DBCC CHECKDB, pour être certain
que vous n’allez pas mettre à  niveau
une base de données endommagée ou
corrompue. Si vous ne l’avez pas déjà 
fait, nous vous recommandons aussi
d’utiliser le General SQL Script Wizard
pour générer des scripts SQL contenant
tous les objets pour chaque base
de données. Dans Enterprise Manager,
sélectionnez la base de données puis
cliquez sur Options, Generate SQL
Scripts dans la barre de menus.
Contrairement à  SQL Server 2000, le
générateur de scripts dans SQL Server
6.5 ne génère que des objets dans la
base de données. Il ne peut pas générer
le code SQL requis pour créer la
base de données, mais vous pouvez
toujours ajouter cela manuellement.
N’oubliez pas de générer les
paramètres d’utilisateur et de sécurité.

SQL Server 2000 et 7.0 utilisent
une approche différente de celle de
SQL Server 6.5 pour indexer des données.
C’est ainsi que certains DBA
(Database Administrators) peu méfiants
ont vu leurs bases de données
gonfler démesurément après une mise
à  niveau. Dans SQL Server 6.5 et versions
antérieures, les index non clustered
classiques utilisent des pointeurs
de lignes physiques pour pointer sur
l’enregistrement de données réel.
Dans SQL Server 2000 et 7.0, les index
non clustered utilisent la clé d’index
clustered pour pointer sur l’enregistrement
de données si la table est en cluster,
comme le montre la figure 1.
Microsoft a inclus ce changement d’architecture
majeur pour améliorer la
performance pendant les modifications
de données. Mais, comme cela
risque de ralentir l’extraction des données,
vous devrez examiner quelles colonnes
vous utilisez pour les index en
cluster. Si les valeurs de clé sont
courtes, comme pour un numéro de
facture ou un numéro de client, la
croissance de la base de données devrait
rester dans des limites raisonnables.
En revanche, si l’index en cluster est sur une colonne ou une
combinaison de colonnes occupant 20
octets ou plus, il vaut mieux repenser
dès maintenant votre stratégie d’indexation.
Même si les valeurs clé d’index
non clustered sont courtes et n’occupent
pas beaucoup d’espace, la
valeur d’index de chaque SQL Server
2000 est associée à  une clé d’index en
cluster qui pointe sur les données. De
ce fait, la taille totale de l’index sera désormais
bien plus grande que dans les
releases précédentes.

Comme les index sont construits
très différemment dans SQL Server
2000 et 6.5, même si vous ne reconcevez
pas votre indexation, nous vous
conseillons de laisser tomber tous les
index avant la mise à  niveau, puis de les
reconstruire après avoir transféré les
données sur SQL Server 2000. Cette
technique permettra à  la mise à  niveau
de s’exécuter plus facilement. Cette
tâche est plus facile si vous disposez
des scripts SQL provenant du Generate
SQL Script Wizard pour vous guider à 
propos de ce qu’il faut reconstruire.

Si la réplication est installée dans votre environnement SQL Server 6.5,
l’opération de mise à  niveau peut tout
transférer – y compris la réplication –
sur SQL Server 2000, pourvu que la
mise à  niveau se fasse en place sur le
même ordinateur. En revanche, si vous
transférez les bases de données sur un
nouvel ordinateur, vous devrez casser
la réplication sur SQL Server 6.5 et la
rétablir sur SQL Server 2000. Ce n’est
pas une si mauvaise nouvelle car ce
dernier jouit de quelques changements
notables concernant la réplication.
Ainsi, dans une souscription pull
SQL Server 2000, la charge de travail
est supérieure pour l’abonné parce
que c’est là  que le Distribution Agent
fonctionne désormais. S’il y a de multiples
abonnements dans SQL Server
6.5, le Distribution Server doit les gérer
tous. C’est encore vrai dans SQL Server
2000 pour les abonnements push mais,
pour les abonnements pull, l’abonné
doit accomplir le travail. Parmi les autres options de la réplication, on
trouve merge replication, qui offre une
possibilité de mise à  jour bidirectionnelle.
Dans SQL Server 2000, il est déconseillé
de s’abonner à  des articles individuels
pour des raisons d’intégrité
des données ; il faut s’abonner à  toute
la publication. En raison des nombreuses
nouvelles fonctions de réplication
de SQL Server 2000, le moment
est venu d’abandonner vos scénarios
de réplication existants et de reconstruire
la réplication pour tirer entièrement
parti des possibilités de SQL
Server 2000. Donc, avant de commencer
l’opération de mise à  niveau, annulez
les abonnés, les publications et les
publieurs, et ôtez les jobs de réplication
de la base de données SQL Server
6.5.

Le SQL Server 2000 Upgrade
Wizard, qui vous guide dans l’opération
de mise à  niveau, demande que
vous ayez un pagefile ou au moins la
quantité de RAM dans votre ordinateur
plus 16 Mo. Cette limitation semble superflue
si vous avez acheté un système
bourré de RAM en pensant vous dispenser
ainsi d’un grand pagefile. Mais
l’Upgrade Wizard ne fonctionnera que
quand vous aurez rendu le pagefile
aussi grand qu’il l’exige. Vous pourrez
toujours redéfinir le pagefile après la
mise à  niveau.

Un pack de service doit être appliqué
à  votre installation de SQL Server
6.5. Si vous effectuez la mise à  niveau
sur place sur le même ordinateur, il
faut que Service Pack 5 (SP5) soit appliqué
à  SQL Server 6.5. Si vous envisagez
la mise à  niveau en déplaçant les
bases de données sur une installation
SQL Server 2000 sur un nouvel ordinateur,
l’installation 6.5 a besoin d’au moins SP3. Faute d’avoir le pack de
service correct, vous obtiendrez un
message d’erreur et la mise à  niveau se
terminera. La meilleure façon de savoir
si le bon pack de service est appliqué
consiste à  ouvrir le Query Analyzer
(ISQL/w dans SQL Server 6.5) et à 
exécuter

SELECT @@version

La release originale de SQL Server
6.5 était la version 6.50.201. SP3 l’a hissée
au niveau 6.50.258. SP5 amène la
version à  6.50.415 et SP5A à  6.50.416.