0% ont trouvé ce document utile (0 vote)
27 vues64 pages

SQL Server

SQL Server est un système de gestion de bases de données relationnelles client-serveur qui utilise Transact-SQL pour communiquer entre un client et le serveur. Il gère les bases de données et les ressources du serveur. Transact-SQL est utilisé pour interroger, mettre à jour et gérer les bases de données relationnelles.

Transféré par

bouchakyahya0
Copyright
© © All Rights Reserved
Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.
Formats disponibles
Téléchargez aux formats PPT, PDF, TXT ou lisez en ligne sur Scribd
0% ont trouvé ce document utile (0 vote)
27 vues64 pages

SQL Server

SQL Server est un système de gestion de bases de données relationnelles client-serveur qui utilise Transact-SQL pour communiquer entre un client et le serveur. Il gère les bases de données et les ressources du serveur. Transact-SQL est utilisé pour interroger, mettre à jour et gérer les bases de données relationnelles.

Transféré par

bouchakyahya0
Copyright
© © All Rights Reserved
Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.
Formats disponibles
Téléchargez aux formats PPT, PDF, TXT ou lisez en ligne sur Scribd

Définition SQL Server

SQL Server est un système de gestion de bases de données relationnelles


client-serveur (SGBDR) qui utilise Transact-SQL pour transmettre des requêtes
entre un client et SQL Server.

Architecture Client/Server :
SQL Server utilise une architecture client-serveur pour répartir la charge de
travail en différentes tâches exécutées sur les ordinateurs serveurs et les
ordinateurs clients.

• Le client est chargé de la logique d'entreprise et de la présentation des


données à l'utilisateur. Il est généralement exécuté sur un ou plusieurs
ordinateurs clients, mais peut également être exécuté sur l'ordinateur serveur
avec SQL Server.

• SQL Server gère les bases de données et répartit les ressources disponibles
du serveur (telles que la mémoire, la bande passante du réseau et les
opérations de disque) entre plusieurs requêtes.
L'architecture client-serveur permet de concevoir et de déployer des
applications de manière optimale pour divers environnements. Les interfaces de
programmation clientes permettent d'exécuter des applications sur des
ordinateurs clients distincts et de communiquer avec le serveur par le biais d'un
réseau.
Système de gestion de bases de données relationnelles :
Le SGBDR est chargé des tâches suivantes :
. gérer les relations entre les données dans la base de données ;
. assurer le stockage correct des données (les règles définissant les relations
entre les données ne doivent pas être enfreintes) ;
. ramener toutes les données à un état de cohérence antérieur en cas de panne
du système.
Transact-SQL :
SQL Server utilise Transact-SQL, une version du SQL (Structured Query
Language), en tant que langage de requêtes de base de données et de
programmation. SQL est un ensemble de commandes qui permet de spécifier
les informations à extraire ou modifier. Transact-SQL permet d'accéder aux
données et d'interroger, mettre à jour et gérer les systèmes de bases de données
relationnelles.
TSQL :
Transact-SQL possède trois langage :
Le langage de définition de données : LDD (ou DDL en anglais) : permet de créer,
de modifier et de supprimer des objets de bases de données (tables, vues, ..), il utilise
principalement les instructions CREATE, ALTER, DROP.

Le langage de manipulation de données : LMD (ou DML en anglais) : permet de


selectionner, d’ajouter, de modifier, et de supprimer des données dans les objets de
bases de données (tables, vues, …), il utilise les instructions SELECT, INSERT,
UPDATE et DELETE.

Le langage de contrôle de données : LCD (ou DCL en anglais) : permet de gérer des
protections d’accès aux données, il utilise principalement les instructions GRANT,
DENY et REVOKE.
Les directives
Les directives indiquent comment traiter les instructions TSQL, les principales directives
sont :
USE bases de données : permet de préciser sur quelle base de données vont porter les
instructions qui suivent.
GO : SQL Server interprète l’instruction GO comme un signale pour exécuter les
instructions qui précèdent.
PRINT : permet de générer une ligne en sortie de procédure.
EXEC : utilisé pour exécuter une fonction ou une procédure stockée

Types de données :
Ils déterminent la nature du contenu des objets tels que les colonnes, les variables, les
paramètres, etc …
Numériques : ce type représente des valeurs entiers ou décimales
Séquences (CREATE SEQUENCE)

Création d’une séquence

Une séquence est en fait une table spéciale contenant une seule ligne. Cet
objet est utilisé pour créer une suite de nombres entiers dont l’évolution,
généralement croissante, est régie par un certain nombre de paramètres.
Voici la syntaxe de création d’une séquence :
CREATE SEQUENCE nom [ INCREMENT [ BY ] incrément ]
[ MINVALUE valeurmin ]
[ MAXVALUE valeurmax ]
[ START [ WITH ] début ]
[ [ NO ] CYCLE ]
La commande CREATE SEQUENCE crée un nouveau générateur de
nombre. Ceci implique la création et l’initialisation d’une nouvelle table portant
le nom nom.
INCREMENT BY : La clause optionnelle INCREMENT BY incrément
spécifie la valeur ajoutée à la valeur de la séquence courante pour créer
une nouvelle valeur. Une valeur positive créera une séquence ascendante,
une négative en créera une descendante. La valeur par défaut est 1.

MINVALUE : La clause optionnelle MINVALUE valeurmin précise la valeur


minimale qu’une séquence peut générer. Si cette clause n’est pas fournie,
alors les valeurs par défaut seront utilisées. Les valeurs par défaut sont 1 et
−263 − 1 pour les séquences respectivement ascendantes et descendantes.

MAXVALUE : La clause optionnelle MAXVALUE valeurmax précise la


valeur maximale pour la séquence. Si cette clause n’est pas fournie, alors
les valeurs par défaut seront utilisées. Les valeurs par défaut sont 2 63 − 1 et
−1 pour les séquences respectivement ascendantes et descendantes.
START WITH : La clause optionnelle START WITH début précise la
valeur d’initialisation de la séquence. La valeur de début par défaut est
valeurmin pour les séquences ascendantes et valeurmax pour les
séquences descendantes.

[ NO ] CYCLE : L’option CYCLE autorise la séquence à recommencer au


début lorsque valeurmax ou valeurmin a été atteinte par une séquence
respectivement ascendante ou descendante. Si la limite est atteinte, le
prochain nombre généré sera respectivement valeurmin ou valeurmax. Si
NO CYCLE est spécifié, tout appel à nextval après que la séquence a
atteint la valeur minimale renverra une erreur. NO CYCLE est le
comportement par défaut.

Utilisation d’une séquence


Bien que vous ne pouvez pas mettre à jour directement une séquence,
vous pouvez toujours utiliser une requête comme :
SELECT * FROM nom_sequence;
TD : séquence

1. Créez une séquence test_sequence cyclique commençant à 10 de


pas d’incrément 2 et de valeur maximum 20.

2. Testez cette séquence (avec la fonction nextval) et observez son


comportement. Le cycle recommence t-il à 10 ? Pourquoi ?

3. Testez également les fonctions currval et setval. Effacez la séquence


de la table.
Après la création d’une séquence, il faut utiliser les fonctions nextval(),
currval() et setval() pour la manipuler.

nextval(’nom_sequence’) : incrémente la valeur courante de la séquence


nom_sequence (excepté la première fois) et retourne cette valeur.

currval(’nom_sequence’) : retourne la valeur courante de la séquence


nom_sequence ; cette fonction ne peut être appelée que si nextval() l’a été
au moins une fois.

setval(’nom_sequence’, nombre) : Initialise la valeur courante de la séquence


nom_sequence à nombre.

Vous pouvez appeler ces différentes fonctions de la manière suivante :


SELECT nextval(’nom_sequence’);
SELECT currval(’nom_sequence’);
SELECT setval(’nom_sequence’, nombre);
Utilisez DROP SEQUENCE pour supprimer une séquence.
Administration SQl server :

SQL Server fournit plusieurs outils de gestion qui permettent de réduire


et d'automatiser les tâches administratives de routine. Les instructions
Transact-SQL constituent le mécanisme sous-jacent utilisé pour
administrer SQL Server.

Nous venons de voir que le ticket d’entrée à la base de donnée consiste


en un nom de connexion et un nom d’utilisateur.

Création des noms :


Les noms de connexion ou d’utilisateurs sont créer via SQL server
management ou via transat-SQL.
Les noms de connexion sont stockés dans la table sysxlogins, rend
compte implicitement des éléments nécessaires à la création d’un nom
de connexion.
Création d’un compte de connexion avec Transact-SQL :
Avec Transact-SQL, la création d’un compte de connexion n’entraîne pas
la création du ou des noms d’utilisateurs associés. Il existe deux
procédures pour ajouter un compte de connexion selon qu’il s’agit d’un
compte SQL server pour une authentification SQL server ( sp_addlogin)
ou d’un compte windows pour authentification windows (sp_grantlogin).

Code Transact-SQL
Sp_addlogin[@loginname=]’nom_de_connexion’
[,[@passwd=]’mot_de_passe’]
[,[@defdb=]’base_de_donnée’]
[,[@deflanguage=]’langue’]
[,[@sid=]’sid’]
[,[@encryptopt=]’option_de_cryptage’]
Sp_grantlogin [@loginame=]’nom de connexion’

Exemple :
Sp_addlogin[@loginname=]’EST’
[,[@passwd=]’GI’]
[,[@defdb=]’gestion’]

Ou : Sp_addlogin ‘EST’ , ‘GI’ , ‘gestion’ , null

Crée un compte de connexion appelé BTS ayant comme mot de passe


DSI et comme base de données par défaut gestion, il utilisera la langue
par défaut du serveur

Sp_grantlogin ‘siege/ahmed’
Accord d’un accès à l’utilisateur windows appelé ahmed du domaine
siege
Pour connaître les noms de connexion disponibles sur un serveur, utiliser
la procédure sp_helplogin.
Une fois les utilisateurs authentifiés et autorisés à se connecter à SQL Server,
ils doivent disposer d'un compte dans une base de données. Les rôles et les
comptes d'utilisateur identifient un utilisateur au sein d'une base de données
et contrôlent la propriété des objets et les autorisations d'exécution
d'instructions.

comptes d'utilisateur de base de données


Les comptes d'utilisateur employés pour attribuer des autorisations de
sécurité sont des utilisateurs, des groupes Windows NT ou des comptes de
connexion SQL Server. Les comptes d'utilisateur sont spécifiques à une base
de données.

Création des noms d’utilisateurs avec Transact-SQL


Une fois les procédures sp_addlogin et sp_grantlogin exécutées, il ne reste
qu’à créer les noms utilisateurs avec sp_grantdbaccess.

Syntaxe :
Sp_grantdbaccess [@loginame=]’connexion[,[@name_in_db
=]’nom_dans_la_base’[output]]

Exemple : sp_grantdbaccess connexion,utilisateur


Supprimer un nom de connexion :
Pour ce faire, on utilise la procédure sp_droplogin
Syntaxe :
Sp_droplogin [@loginame=]’nom_de_la_connexion’
Exemple :
Sp_droplogin EST
Supprime le compte de connexion EST

Supprimer un nom d’utilisateur :


L’instruction sp_revokdbaccess supprime de maniére définitive un nom
d’utilisateur en effaçant l’enregistrement correspondant de la table
sysusers.
Syntaxe :
sp_revokdbaccess [@name_in_db=]’nom_utilisateur’
Les rôles :

Les rôles permettent de grouper des utilisateurs en une entité unique à


laquelle vous pouvez attribuer des autorisations. SQL Server propose des
rôles de serveur et de base de données prédéfinis pour des fonctions
administratives courantes afin que vous puissiez accorder un ensemble
d'autorisations administratives à un utilisateur spécifique. Vous pouvez
également créer vos propres rôles de base de données. Dans SQL Server, les
utilisateurs peuvent appartenir à plusieurs rôles.

Rôles de serveur :
Les rôles fixes de serveur permettent de regrouper des privilèges
administratifs au niveau du serveur. Ils sont gérés au niveau du serveur,
indépendamment des bases de données utilisateur.

Le tableau suivant décrit les rôles fixes de serveur les plus courants :
Rôle Autorisation
dbcreator Création et modification des bases de
données
Diskadmin Gestion des fichiers sur disque
Rôle Autorisation
Processadmin Gestion des processus SQL Server
Securityadmin Gestion et audit des noms de
connexion serveur
Serveradmin Configuration des paramètres de
serveur
Setupadmin Installation de la réplication
Sysadmin Exécution de toutes les activités
Remplir un rôle de serveur :
En utilisant transact-SQL
Sp_addsrvrolemember [@loginame =]’nom_de_connexion’ ,
[@rolename=]’nom_de_role’
Pour supprimer un rôle :
Sp_dropsrvrolemember [@loginame =]’nom_de_connexion’ ,
[@rolename=]’nom_de_role’
Les rôles de base de données :
Les rôles fixes de base de données permettent de regrouper des privilèges
administratifs au niveau de la base de données. Le tableau suivant décrit les
rôles fixes de base de données les plus courants :
Rôle Autorisation
Public Conservation de toutes les autorisations par défaut pour
les utilisateurs d'une base de données
db_owner Exécution de toutes les activités de rôle de base de
données
db_accessadmin Ajout ou suppression d'utilisateurs, de groupes et de rôles de
base de données
db_ddladmin Ajout, modification ou suppression d'objets de base de données
db_securityadmin Affectation d'autorisations d'instructions et d'objets
db_backupoperator Sauvegarde et restauration de bases de données
db_datareader Lecture de données dans toutes les tables
db_datawriter Ajout, modification ou suppression de données dans toutes les
tables
db_denydatareader Interdiction de lecture des données dans toutes les tables
db_denydatawriter Interdiction de modification des données dans toutes les tables
Exemple :
Sp_addrole rolebts,db_ddladmin
Sp_addrolemember rolebts,etudiant1

Pour supprimer un rôle de base de données :


Sp_droprolemember [@rolename =]’nom_de_role’ ,
[@membername=]’nom_de_utilisateur’

Rôles d’application
Un rôle d’application est une forme particulier de rôle de base de
données. Il est créé dans une base de données, mais n’est pas liè à une
connexion, ne contient pas d’utilisateurs et n’est utilisé que par une
application.
Pour se servir d’un rôle d’application, il faut d’abord ouvrir une session
sous SQL server et entrer dans la base de données ; ensuite l’application
peut l’utiliser. L’utilisateur de l’application est alors placé dans
l’environnement de sécurité spécifier de ce role.
Créer et gérer un rôle d’application :
Sp_addapprole[@rolename=]’nom_du_rôle’,
[@password=]’mot_de_passe’
Pour modifier le mot de passe
Sp_approlepassword [@rolename=]’rôle’,
[@newpwd=]’mot_de_passe’

Pour utiliser un rôle d’application :


Sp_setapprole [@rolename=] ‘rôle’,
[@password=] ‘{ Encrypt N’mot_de_passe’} ‘mot_de_passe’,
[,[@encrypt=]’style_de cryptage’

Exemple :
Sp_setapprole ‘roleapplication1’, {Encrypt N ‘12345’}, ‘odbc’
Ce cryptage n’est possible qu’avec la bibliothéque cliente ODBC
Autorisations
1 Sur les instructions
Exemple : pour autoriser les utilisateurs Paul et Henri `a créer des tables et
des déclencheurs

GRANT CREATE TABLE, CREATE TRIGGER


TO Paul, Henri

Remarque : Paul et Henri doivent déjà posséder un compte utilisateur sur


SQL Server.

Autre exemple : pour empêcher Paul de créer des bases


DENY CREATE DATABASE
TO Paul
Dernier exemple : pour lever les autorisations et les empêchements de Paul
REVOKE CREATE DATABASE, CREATE TABLE
TO Paul
Remarques :
– après un REVOKE SQL Server s’en remet aux autorisations par défaut du
rôle dont Paul est membre ;
– on peut utiliser le mot-clé ALL pour désigner toutes les instructions.

2 - Sur les objets

Dans une base de données, pour chaque table, chaque colonne et chaque
instruction on peut préciser les autorisations.
Exemple : pour autoriser la sélection sur la table member
GRANT SELECT ON member
TO Paul
Autre exemple : pour empêcher les autres instructions
DENY INSERT, UPDATE, DELETE ON member
TO Paul
Dernier exemple : pour autoriser la modification mais seulement du prénom
GRANT UPDATE(firstname) ON MEMBER
TO Paul
Distribution des données :

Serveurs distances
Deux serveurs sont dits distants quand il est possible depuis l’un d’eux
d’exécuter une procédure sur l’autre. Il n’est pas nécessaire que cette
possibilité soit bidirectionnelle.

Imaginons deux serveurs : serveurA et serveurB; pour déclarer serveurB


comme serveur distant de serveurA. Il faut aussi déclarer serveurA comme
serveur distant de sevreurB. D’où la démarche suivant :
•Sur serveurA : sp_addserver serveurB
•Sur serveurB : sp_addserver serveurA

Syntaxe pour ajouter un serveur distant :


Sp_addserver [@server =]’serveur’
[,[@local =]’local’]
[,[@duplicate_ok =]’duplicate_ok’I null ]

Pour supprimer un seveur distant :


Sp_dropserver [@server =]’serveur’
[,[@droplogin =]{droplogins’ I null}]
Utilisateurs distants :
Dans la mesure où l’un des serveurs (serveurA) va tenir exécuter une
procédure sur un autre serveur (serveurB), il est clair que serveurA a
besoin d’une connexion serveurB. Il s’agit une connexion d’accès distant.
En fait, un utilisateur de serveurA va exécuter une procédure sur le
serveurB, il faut donc à cet utilisateur un compte sur le serveurB.
L’opération se fait de manière transparente pour l’utilisateur : il faut
uniquement mettre en correspondance un nom de connexion sur le
serveurA avec un nom de connexion sur le serveurB.
Il existe deux méthodes de mise en correspondance des noms de
connexion :
Un nom de connexion sur serveurA est mis en correspondance avec un
nom de connexion sur serveurB.
Tous les noms de connexion sur serveurA est mis en correspondance
avec un seul nom de connexion sur serveurB
Pour ajouter un nom de connexion distant :
Sp_addremotelogin [@remoteserver=] ‘serveur_distant’]
[,[@loginname =] ‘nom_de_connexion’]
[,[@remotename =] ‘nom_distance’]
Pour supprimer un nom de connexion distant :
Sp_dropremotelogin [@remoteserver=] ‘serveur_distant’]
[,[@loginname =] ‘nom_de_connexion’]
[,[@remotename =] ‘nom_distance’]
.
Options distantes :
Il existe trois options importantes pour les connexions distants, qui ne sont
visibles et modifiables qu’avec la procédure stockée sp_configure
Remote access : active ou non l’accès distant, il faut que cette option soit à 1.
Remote login timeout : délai d’attente maximum pour l’ouverture d’une
connexion.
Remote query timeout : délai d’attente maximum pour l’exécution d’une
requette.

Voila la syntaxe d’exécution d’une procédure stockée distante :


Exec nom_serveur, nom_base_propriétaire, nom_procédure
serveur lié :
Un serveur lié autorise l'accès à des sources de données OLE DB par
l'intermédiaire de requêtes distribuées et hétérogènes. Une fois qu'un
serveur lié a été créé, il est possible d'exécuter des requêtes distribuées sur
ce serveur, et les requêtes peuvent joindre des tables de plusieurs sources
de données. Si le serveur lié est défini comme une instance de SQL Server,
des procédures stockées distantes peuvent être exécutées.

Syntaxe :
Sp_addlinkedserver [@server =] ‘serveur’
[,[@srvproduct =] ‘nom_du_produit’]
[,[@provider =] ‘nom_du_fournisseur’]
[,[@datasrc =] ‘source_de_données’]
[,[@location =] ‘emplacement’]
[,[@provstr =] ‘chaine_fournisseur’]
[,[@catalog =] ‘catalogue’]
Fournisseur : Sélectionnez une source de données OLE DB dans la
zone de liste. Le fournisseur OLE DB est inscrit avec le PROGID donné
dans le Registre.
Nom de produit : Tapez le nom de produit de la source de données
OLE DB à ajouter en tant que serveur lié.
Source de données : Tapez le nom de la source de données tel qu'il
est interprété par le fournisseur OLE DB. Si vous vous connectez à une
instance de SQL Server, spécifiez le nom d'instance.
Chaîne du fournisseur : Tapez l'identificateur de programme unique
(PROGID) du fournisseur OLE DB qui correspond à la source de
données. Pour obtenir des exemples de chaînes de fournisseur valides,
Emplacement : Tapez l'emplacement de la base de données tel qu'il est
interprété par le fournisseur OLE DB.
Catalogue : Tapez le nom du catalogue à utiliser lors de la connexion au
fournisseur OLE DB.
Lire des données :
SELECT num_clt, nom_clt, prenom_clt, adr_clt FROM
nom_serveur_lié.client where ville=‘guelmim’
Mettre à jour :
update nom_serveur_lié.client
SET adr_clt = ‘23 rue hassan II’
where num_clt= ‘5’
Transaction :
Une transaction est un ensemble d’instructions regroupées pour former un
ensemble atomique, cohérent, isolé et durable.
Exemple : BEGIN TRAN
Update clientSQL
SET code_postale = ‘435464’
WHERE ville = ‘guelmim’
COMMIT TRAN
Gestion des accès concurrents
Les problèmes liés aux accès concurrents aux données sont présentés
dans leur généralité. Les solutions apportées par les différents SGBDs.

Problèmes liés aux accès concurrents


Il peut arriver que plusieurs transactions veuillent modifier en même temps
les mêmes données. Dans ce cas, il peut se produire des pertes de
données si l'on ne prend pas certaines précautions.

Mises à jour perdues


Si deux processus mettent à jour en même temps la somme S contenue
dans un compte client d'une banque en enregistrant deux versements de
1000 et de 2000 francs, on peut avoir
Finalement, la valeur du compte sera augmentée de 2000 francs au lieu
de 3000 francs.

Pour éviter ce genre de situation, les SGBD bloquent l'accès aux tables
(ou parties de tables : blocs mémoire ou lignes par exemple) lorsque de
nouveaux accès pourraient occasionner des problèmes. Les processus qui
veulent accéder aux tables bloquées sont mis en attente jusqu'à ce que les
tables soient débloquées.

Cependant ceci peut aussi amener à l'interblocage de processus (deadlock


en anglais) comme dans l'exemple suivant :

On remarquera que ce type d'interblocage ne peut arriver si tous les


utilisateurs bloquent les tables dans le même ordre.
Lecture inconsistante ou lecture impropre
Une transaction T2 lit une valeur V donnée par une autre transaction T1.
Ensuite la transaction T1 annule son affectation de V et la valeur lue par
T2 est donc fausse.

Ce cas ne peut arriver si les modifications effectuées par une transaction


ne sont visibles par les autres qu'après validation (Commit) de la
transaction. C'est le plus souvent le cas.
Lecture non répétitive, ou non reproductible, ou incohérente
Une transaction lit deux fois une même valeur et ne trouve pas la même
valeur les deux fois.

Pour éviter ceci, T1 devra bloquer les données qu'elle veut modifier entre
les temps t1 et t3, pour empêcher les autres transactions de les modifier
Lignes fantômes
Le phénomène des lignes fantômes peut arriver si une transaction ajoute
des données sans qu'une autre transaction ne s'en aperçoive. Cette
dernière transaction peut posséder des informations contradictoires sur la
base.
Par exemple, une transaction récupère tous les t-uplets qui vérifient un
certain critère. Une autre transaction ajoute des lignes qui vérifient ce
critère. La même requête relancée une deuxième fois ne retrouve plus le
même nombre de lignes.
Une variante que l'on peut rencontrer si on veut accéder aux données
depuis un langage de programmation tel que Java : on commence par lire
le nombre de lignes qui vérifient un critère pour dimensionner un tableau
Java qui les contiendra ; on relance ensuite la même sélection pour ranger
les lignes dans le tableau ; si entre temps un autre utilisateur a rajouté des
lignes qui vérifient ce critère, on provoque une erreur (le tableau n'est plus
assez grand pour contenir toutes les lignes).
Un blocage de ligne n'est plus la solution ici car ces lignes n'existent pas
à la première lecture. On sera souvent amené à effectuer un blocage
explicite de table, ou à choisir le degré d'isolation serializable (décrit dans
la section suivante).
Distribution des données :

Serveurs distances
Deux serveurs sont dits distants quand il est possible depuis l’un d’eux
d’exécuter une procédure sur l’autre. Il n’est pas nécessaire que cette
possibilité soit bidirectionnelle.

Imaginons deux serveurs : serveurA et serveurB; pour déclarer serveurB


comme serveur distant de serveurA. Il faut aussi déclarer serveurA comme
serveur distant de sevreurB. D’où la démarche suivant :
•Sur serveurA : sp_addserver serveurB
•Sur serveurB : sp_addserver serveurA

Syntaxe pour ajouter un serveur distant :


Sp_addserver [@server =]’serveur’
[,[@local =]’local’]
[,[@duplicate_ok =]’duplicate_ok’I null ]

Pour supprimer un seveur distant :


Sp_dropserver [@server =]’serveur’
[,[@droplogin =]{droplogins’ I null}]
Utilisateurs distants :

Dans la mesure où l’un des serveurs (serveurA) va tenir exécuter une


procédure sur un autre serveur (serveurB), il est clair que serveurA a
besoin d’une connexion serveurB. Il s’agit une connexion d’accès distant.
En fait, un utilisateur de serveurA va exécuter une procédure sur le
serveurB, il faut donc à cet utilisateur un compte sur le serveurB.
L’opération se fait de manière transparente pour l’utilisateur : il faut
uniquement mettre en correspondance un nom de connexion sur le
serveurA avec un nom de connexion sur le serveurB.
Il existe deux méthodes de mise en correspondance des noms de
connexion :
Un nom de connexion sur serveurA est mis en correspondance avec un
nom de connexion sur serveurB.
Tous les noms de connexion sur serveurA est mis en correspondance
avec un seul nom de connexion sur serveurB
Pour ajouter un nom de connexion distant :
Sp_addremotelogin [@remoteserver=] ‘serveur_distant’]
[,[@loginname =] ‘nom_de_connexion’]
[,[@remotename =] ‘nom_distance’]
Pour supprimer un nom de connexion distant :
Sp_dropremotelogin [@remoteserver=] ‘serveur_distant’]
[,[@loginname =] ‘nom_de_connexion’]
[,[@remotename =] ‘nom_distance’]
.
Options distantes :
Il existe trois options importantes pour les connexions distants, qui ne sont
visibles et modifiables qu’avec la procédure stockée sp_configure
Remote access : active ou non l’accès distant, il faut que cette option soit à 1.
Remote login timeout : délai d’attente maximum pour l’ouverture d’une
connexion.
Remote query timeout : délai d’attente maximum pour l’exécution d’une
requette.

Voila la syntaxe d’exécution d’une procédure stockée distante :


Exec nom_serveur, nom_base_propriétaire, nom_procédure
serveur lié :
Un serveur lié autorise l'accès à des sources de données OLE DB par
l'intermédiaire de requêtes distribuées et hétérogènes. Une fois qu'un
serveur lié a été créé, il est possible d'exécuter des requêtes distribuées sur
ce serveur, et les requêtes peuvent joindre des tables de plusieurs sources
de données. Si le serveur lié est défini comme une instance de SQL Server,
des procédures stockées distantes peuvent être exécutées.

Syntaxe :
Sp_addlinkedserver [@server =] ‘serveur’
[,[@srvproduct =] ‘nom_du_produit’]
[,[@provider =] ‘nom_du_fournisseur’]
[,[@datasrc =] ‘source_de_données’]
[,[@location =] ‘emplacement’]
[,[@provstr =] ‘chaine_fournisseur’]
[,[@catalog =] ‘catalogue’]
Fournisseur : Sélectionnez une source de données OLE DB dans la
zone de liste. Le fournisseur OLE DB est inscrit avec le PROGID donné
dans le Registre.
Nom de produit : Tapez le nom de produit de la source de données
OLE DB à ajouter en tant que serveur lié.
Source de données : Tapez le nom de la source de données tel qu'il
est interprété par le fournisseur OLE DB. Si vous vous connectez à une
instance de SQL Server, spécifiez le nom d'instance.
Chaîne du fournisseur : Tapez l'identificateur de programme unique
(PROGID) du fournisseur OLE DB qui correspond à la source de
données. Pour obtenir des exemples de chaînes de fournisseur valides,
Emplacement : Tapez l'emplacement de la base de données tel qu'il est
interprété par le fournisseur OLE DB.
Catalogue : Tapez le nom du catalogue à utiliser lors de la connexion au
fournisseur OLE DB.
Lire des données :
SELECT num_clt, nom_clt, prenom_clt, adr_clt FROM
nom_serveur_lié.client where ville=‘guelmim’
Mettre à jour :
update nom_serveur_lié.client
SET adr_clt = ‘23 rue hassan II’
where num_clt= ‘5’
Transaction :
Une transaction est un ensemble d’instructions regroupées pour former un
ensemble atomique, cohérent, isolé et durable.
Exemple : BEGIN TRAN
Update clientSQL
SET code_postale = ‘435464’
WHERE ville = ‘guelmim’
COMMIT TRAN

Vous aimerez peut-être aussi