> Tech > Adresser des requêtes à  l’Oracle Linked Server

Adresser des requêtes à  l’Oracle Linked Server

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

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 gratuitement cette ressource

Cybersécurité sous contrôle à 360°

Cybersécurité sous contrôle à 360°

Avec Cloud in One, les entreprises ne gagnent pas uniquement en agilité, en modernisation et en flexibilité. Elles gagnent également en sécurité et en résilience pour lutter efficacement contre l’accroissement en nombre et en intensité des cyberattaques. Découvrez l'axe Cybersécurité de la solution Cloud In One.

Tech - Par iTPro - Publié le 24 juin 2010