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
Guide de Sécurité IA et IoT
Compte tenu de l'ampleur des changements que l'IA est susceptible d'entraîner, les organisations doivent élaborer une stratégie pour se préparer à adopter et à sécuriser l'IA. Découvrez dans ce Livre blanc Kaspersky quatre stratégies efficaces pour sécuriser l'IA et l'IoT.