> Tech > Vues partitionnées distribuées (partie I)

Vues partitionnées distribuées (partie I)

Tech - Par iTPro.fr - Publié le 24 juin 2010
email

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.

Vues partitionnées distribuées (partie I)

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

Microsoft 365 : HP Subscription Management Services en détail

Microsoft 365 : HP Subscription Management Services en détail

Collaboration à distance, environnements de travail et productivité optimisés, gestion évolutive des licences, accélérez la transformation de votre business pour le faire entrer dans l’ère de la collaboration hybride. Découvrez comment le service de gestion des abonnements HP peut vous aider à optimiser vos investissements et votre stratégie de gestion de vos abonnements Microsoft 365.

Tech - Par iTPro.fr - Publié le 24 juin 2010

A lire aussi sur le site

Revue Smart DSI

La Revue du Décideur IT