La connexion étant configurée, vous
pouvez commencer à exécuter des instructions
SQL Server visant le serveur
Oracle linked. Les requêtes adressées
aux linked servers utilisent la syntaxe
de nommage suivante en quatre parties
: linked_server_name.catalog_name.
schema_name.table_name.
Comme le montre la figure 8, le schéma
Oracle SCOTT a cinq tables utilisateur.
Adresser des requêtes à l’Oracle Linked Server

Pour sélectionner toutes les
lignes de la table EMP, vous entreriez
l’instruction SQL suivante :
SELECT * FROM
TecaOracle.SCOTT.EMP
La valeur TecaOracle identifie le
serveur linked. La valeur Catalog est
toujours vierge parce que la base de
données Oracle ne prend en charge
qu’un catalogue. SCOTT est le nom du
schéma Oracle associé au nom d’utilisateur
Scott que nous avons mappé
précédemment à l’aide de la procédure
stockée sp_addlinkedsrvlogin. Et,
finalement, EMP est le nom de la table
dans le schéma à laquelle vous voulez
accéder. Le panneau de droite de la figure
8 montre les valeurs que vos requêtes
linked server doivent utiliser
dans chacune de ces parties de nom.
Dès que vous avez mis en place le
linked server, SQL Server commence à
journaliser des statistiques pour la
table sur le linked server, en essayant
d’optimiser le type de requêtes qui seront
envoyées à celui-ci. Un point important
à propos de linked server est
que le processeur de requêtes distribuées
SQL Server – pas le linked server
– est chargé d’optimiser les requêtes
que SQL Server envoie au linked server
pour extraire des données.
SQL Server interroge d’abord le
linked server pour déterminer le niveau
de dialecte SQL qu’il reconnaît,
comme le dialecte SQL Server complet,
le dialecte SQL-92, le dialecte core
ODBC ou le dialecte Jet, puis il tente
de pousser des opérations du genre
jointures, unions, tris et GROUP BYs
vers le serveur distant. Cependant, le
processeur de requêtes distribuées ne
possède pas le même type d’information
sur les tables distantes que sur les
tables locales, et donc la démarche
qu’il suit pour extraire les données
n’est pas toujours la meilleure.
SQL Server Query Analyzer a la
possibilité d’afficher le plan d’exécution.
C’est un bon moyen d’avoir un
aperçu de la manière dont le processeur
de requêtes distribuées de SQL
Server traitera la requête distante. Un
contournement possible pour les requêtes
qui ne se comportent pas
comme prévu, passe par la fonction
OPENQUERY(). OPENQUERY() contourne
le processeur de requêtes
distribuées et envoie la requête directement
au serveur distant pour traitement.
Téléchargez cette ressource

État des lieux de la sécurité cloud-native
L’État des lieux de la sécurité cloud-native vous offre une analyse complète des problématiques, des tendances et des priorités qui sous-tendent les pratiques de sécurité cloud-native dans le monde entier. Une lecture indispensable pour renforcer votre stratégie de sécurité dans le cloud. Une mine d’infos exclusives pour élaborer votre stratégie de sécurité cloud-native.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Les risques liés à l’essor fulgurant de l’IA générative
- Pourquoi est-il temps de repenser la gestion des vulnérabilités ?
- Reporting RSE : un levier d’innovation !
- De la 5G à la 6G : la France se positionne pour dominer les réseaux du futur
- Datanexions, acteur clé de la transformation numérique data-centric
