par Kalen Delaney et Itzik Ben-Gan
NDLR : cet article est le premier d'une série de trois sur les Vues partitionnées distribuées de SQL Server 2000.
Les environnements OLTP (OnLine Transaction Processing) et
les bases de données des grands sites Web sont en général constitués de
nombreuses requêtes individuelles, interrogeant ou manipulant une quantité de
données relativement petite. Quand la taille du système augmente, et que les
utilisateurs font de plus en plus de requêtes base de données, les
administrateurs essaient habituellement d'améliorer les temps de réponse en
augmentant la puissance des serveurs. On peut alors ajouter des CPU, remplacer
ses CPU par des CPU plus rapides, ajouter de la mémoire, renforcer le réseau
ou ajouter des disques durs plus rapides, avec de meilleurs contrôleurs. Mais
à un certain moment, on va épuiser les ressources disponibles car les limites
de la machine seront atteintes; à moins que ce ne soit votre budget. SQL Server
2000 apporte une solution à la demande sans cesse grandissante en puissance de
traitement : l'expansion horizontale.
Cette solution consiste à fractionner de gigantesques tables
en tables plus petites (chacune étant un sous ensemble, ou partition, de la
table d'origine) et à les faire coexister sur des serveurs distincts. Chaque
serveur peut être géré indépendamment, mais ensemble, ces serveurs forment
une fédération. Pour accéder à une donnée sur n'importe laquelle des
partitions, on définit une vue du même nom sur tous les serveurs, ce qui rend
transparent le fait que les données sont distribuées sur plusieurs noeuds. Un
utilisateur ou une application connectés aux serveurs peut passer des
instructions DML (Data Manipulation Language : langage de manipulation de
données) comme SELECT, INSERT, UPDATE et DELETE sur cette vue comme s'il
interrogeait la table d'origine. SQL Server 2000 intercepte les instructions
et les reroute vers les serveurs appropriés. Cette configuration distribue la
charge de traitement entre tous les membres de la fédération.
Apprenez à utiliser
les techniques liées à la stratégie d'expansion horizontale de Microsoft
SQL Server 7.0 permet de créer des vues partitionnées
locales. Avec SQL Server 7.0, on peut également créer des vues partitionnées
sur de multiples serveurs, mais on ne peut pas les modifier, ce qui limite
beaucoup leur utilité. De plus, avec SQL Server 7.0 ainsi que les versions
précédentes, toute vue basée sur une opération UNION ne peut être mise à
jour, qu'elle se trouve sur un serveur unique ou soit distribuée sur de
multiples serveurs. SQL Server 2000 remédie à cette restriction en permettant
aux utilisateurs de mettre à jour certains types de vues basée sur la commande
UNION, et introduit de nouvelles techniques d'optimisation pour la mise en
place des vues partitionnées. Nous allons présenter ces nouvelles techniques d'optimisation
dans cet article, et vous montrer comment mettre en place et modifier des vues
partitionnées distribuées.
Cette action implique trois étapes : la définition des
serveurs liés, la création des tables partitionnées, et la création des vues
partitionnées.
Définition des serveurs liés
Cette étape préliminaire n’est pas nécessaire quand on
travaille en local. Comme les tables partitionnées sont distribuées sur de
multiples serveurs, chaque serveur doit avoir accès à tous les autres. Il faut
donc configurer tous les serveurs comme des serveurs liés. Supposons que l’on
souhaite partitionner les tables "Clients" et "Orders" sur
trois serveurs appelés Shire, Hobbiton, et Rivendell. Shire doit pointer vers
Hobbiton et Rivendell ; Hobitton vers Shire et Rivendell, et Rivendell vers
Shire et Hobitton. La figure 1 représente la disposition des serveurs liés,
chaque flèche correspondant à un lien logique. Le listing 1 contient le script
de configuration des serveurs liés à Shire, ou noeud 1.
Dans la procédure cataloguée sp_addlinkedserver, la
variable @server contient le nom logique du serveur lié, et la variable @datasrc
le nom du serveur que nous voulons atteindre. Remarquez que dans ce script, le
nom du serveur distant est constitué de deux parties séparées par un
backslash, comme dans server\instance. SQL Server 2000 permet l’implémentation
de multiples instances sur un même serveur. Donc, si on souhaite exécuter ces
exemples de code sur une seule machine, on peut installer les trois instances de
SQL Server 2000 sur sa machine, et tout simplement remplacer le nom des serveurs
dans le script par des noms de type server\instances. Si on utilise par exemple
un serveur appelé Serveur1, on peut implanter trois instances de SQL Server
2000 Instance1, Instance2, et Instance3, et se référer à elles en tant que,
respectivement, Serveur1\Instance1, Serveur1\Instance2, et Serveur1\Instance3.
Après avoir défini la connexion avec chacun des deux autres
serveurs, on utilise la procédure sp_serveroption, qui permet la validation
automatique des schémas sur chacun des serveurs liés. Microsoft a introduit
cette routine dans SQL Server 2000 pour optimiser les performances en assurant
que le traitement des requêtes ne fera pas appel à des Métadonnées sur les
tables liées tant que les utilisateurs requerront des données de la table
membre distante. Quand un utilisateur exécute une requête distribuée sur un
serveur lié, la connexion se fait sous le nom de l’utilisateur en cours. La
configuration des sécurités du serveur lié n’ont pas à être modifiées si
les conditions suivantes sont remplies :
- les utilisateurs se connectent à SQL Server en utilisant l’authentification
de Windows.
- La délégation de sécurité existe sur la machine cliente (sur laquelle
tourne l’interface utilisateur) ainsi que sur le serveur local. La
délégation de sécurité est disponible avec Windows 2000
Dans l’exemple que nous utilisons, la configuration n’est
pas nécessaire car les deux exigences sont satisfaites. Les trois serveurs sont
des serveurs membres d’un domaine Windows 2000 appelé " MIDDLE_EARTH
" et les utilisateurs se connectant aux serveurs utilisent
l’authentification de Windows.
Si votre configuration ne répond pas à ces exigences de
sécurité, il faut configurer les sécurités du serveur lié en utilisant la
procédure cataloguée "sp_addlinkedsrvlogin".
Ensuite, et comme pour le noeud 1, exécutez le script du
listing 2 pour mettre en place les serveurs liés à Hobbiton, ou noeud 2.
Enfin, exécutez le script décrit dans le listing 3 pour mettre en place les
serveurs liés à Rivendell, ou noeud 3.
Téléchargez cette ressource
Préparer l’entreprise aux technologies interconnectées
Avec la « quatrième révolution industrielle », les environnements hyperconnectés entraînent de nouveaux risques en matière de sécurité. Découvrez, dans ce guide Kaspersky, comment faire face à cette nouvelle ère de vulnérabilité.
