Dans votre premier exemple utilisant la notation "point", le moteur de curseur client est utilisé et la plupart des éléments sont évalués localement. Si vous sélectionnez dans une grande table et utilisez une clause WHERE, les enregistrements seront extraits localement à partir de la base de données distante. Une fois que les données ont été extraites sur le serveur lié, la clause WHERE est alors appliquée localement. Souvent, cette séquence est un succès de performance. Les index sur la base de données distante sont pratiquement rendus inutiles.
Alternativement, lorsque vous utilisez OPENQUERY, SQL Server envoie l'instruction sql à la base de données cible pour traitement. Pendant le traitement, tous les index des tables sont exploités. De plus, la clause where est appliquée côté Oracle avant de renvoyer le jeu de résultats à SQL Server.
D'après mon expérience, à l'exception des requêtes les plus simples, OPENQUERY vous offrira de meilleures performances.
Je recommanderais d'utiliser OpenQuery pour tout pour les raisons ci-dessus.
L'un des points faibles lors de l'utilisation d'OpenQuery que vous avez peut-être déjà rencontré est les guillemets simples. Si la chaîne sql envoyée à la base de données distante nécessite des guillemets simples autour d'une chaîne ou d'une date, ils doivent être échappés. Sinon, ils terminent par inadvertance la chaîne sql.
Voici un modèle que j'utilise chaque fois que je traite des variables dans une instruction openquery vers un serveur lié pour résoudre le problème des guillemets simples :
DECLARE @UniqueId int
, @sql varchar(500)
, @linkedserver varchar(30)
, @statement varchar(600)
SET @UniqueId = 2
SET @linkedserver = 'LINKSERV'
SET @sql = 'SELECT DummyFunction(''''' + CAST(@UniqueId AS VARCHAR(10))+ ''''') FROM DUAL'
SET @statement = 'SELECT * FROM OPENQUERY(' + @linkedserver + ', '
SET @Statement = @Statement + '''' + @SQL + ''')'
EXEC(@Statement)
