Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Windows Windows Serveur SQL Serveur SQL2000 --> Oracle : lenteur si vue

SQL2000 --> Oracle : lenteur si vue

5 réponses
Avatar
Vuillermet Jacques
Bonjour,

Contexte :
- SQL2000 SP4 et Oracle 9.2 relié par une liaison réseau TRES TRES lente.
- une table Produit d'environ 1 million de lignes.

J'effectue directement la requête suivante vers le serveur lié Oracle sans
difficulté :

SELECT *
FROM OPENQUERY(SrvLnk, '
SELECT Id_Produit
FROM Produit
WHERE Id_Produit = 1')

La réponse est rapide.

Je crée la vue suivante :

CREATE VIEW VueProduit AS
SELECT *
FROM OPENQUERY(SrvLnk, 'SELECT * FROM Produit')

La requête initiale devient alors :

SELECT Id_Produit
FROM VueProduit
WHERE Id_Produit = 1

Mais là, le temps de réponse est très long (>30 minutes).

Le plan d'exécution est le suivant :

StmtText
----------------------------------------------------------------------------
------------------
|--Filter(WHERE:([MSDAORA].[ID_PRODUIT]=Convert([@1])))
|--Remote Scan(SOURCE:(LeServeurOracle), OBJECT:(SELECT * FROM
PRODUIT))

J'en déduis que SQL Server n'envoie pas le WHERE à Oracle.
Autrement dit : SQL Server rapatrie d'abord le million de lignes PUIS il
applique le filtre !

Comment faire pour forcer SQL Server à envoyer la clause WHERE à Oracle en
utilisant une vue ?

Merci,

Jacques.
Signaler un problème avec ce contenu

5 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
Romelard Fabrice [MVP]
Bonjour,

Cela me semble normal selon ce que vous expliquez.
Vous avez créé une vue sur le serveur SQL Server qui fait une requête
(SELECT *) sur votre serveur lié ORACLE sans filtre.
Ensuite vous envoyez une condition sur cette vue.

De ce fait, à mon sens l'ordre sera le suivant :
- SELECT * sur la table ORACLE
- Récupération de tous les éléments de la table ORACLE par le moteur SQL
Server
- Application du filtre transmis à la vue par SQL Server
- Restitution des données

Donc le plan d'exécution est correct, c'est votre méthode qui me semble
discutable, d'ailleurs, je ne comprends pas bien le concept de la vue dans
ce cas.

--
Cordialement.

Romelard Fabrice [MVP]

"Vuillermet Jacques" a écrit dans le message de news:

Bonjour,

Contexte :
- SQL2000 SP4 et Oracle 9.2 relié par une liaison réseau TRES TRES lente.
- une table Produit d'environ 1 million de lignes.

J'effectue directement la requête suivante vers le serveur lié Oracle sans
difficulté :

SELECT *
FROM OPENQUERY(SrvLnk, '
SELECT Id_Produit
FROM Produit
WHERE Id_Produit = 1')

La réponse est rapide.

Je crée la vue suivante :

CREATE VIEW VueProduit AS
SELECT *
FROM OPENQUERY(SrvLnk, 'SELECT * FROM Produit')

La requête initiale devient alors :

SELECT Id_Produit
FROM VueProduit
WHERE Id_Produit = 1

Mais là, le temps de réponse est très long (>30 minutes).

Le plan d'exécution est le suivant :

StmtText
----------------------------------------------------------------------------
------------------
|--Filter(WHERE:([MSDAORA].[ID_PRODUIT]=Convert([@1])))
|--Remote Scan(SOURCE:(LeServeurOracle), OBJECT:(SELECT * FROM
PRODUIT))

J'en déduis que SQL Server n'envoie pas le WHERE à Oracle.
Autrement dit : SQL Server rapatrie d'abord le million de lignes PUIS il
applique le filtre !

Comment faire pour forcer SQL Server à envoyer la clause WHERE à Oracle en
utilisant une vue ?

Merci,

Jacques.




Avatar
Vuillermet Jacques
Merci de m'avoir confirmer ce que je pensais.

Je pensais qu'il y aurait un moyen (que j'ignore) de faire comme de SQL
Server à SQL Server : même si une vue est définie sans WHERE, si l'on
requête sur la vue avec un WHERE alors le WHERE est transmis à la table
source (mal dit mais l'état d'esprit y est).

Mais alors comment faire : ne plus utiliser de vue et utiliser
OpenQuery(lnk, ...) dans chaque requête ?
Je trouve cela dommage.

L'objectif des vues est le suivant : je définis mes vues une seule fois dans
mon serveur SQL Server.
Ensuite, toutes les applications tournant sur SQL Server utilisent ces vues.
Cela me permet de définir le serveur lié comme je l'entend (comme DBA SQL
Server) et même de pouvoir changer son nom si je le souhaite : il me suffira
de reconstruire les vues sans avoir à toucher les applications.
Le développeur d'application, lui, ne voit que les vues.
Les vues forment donc une couche intermédiaire logique entre l'application
et le serveur Oracle.
Demain, si les données actuellement gérées par Oracle passent sous SQL
Server alors je n'ai rien à faire au niveau application mais seulement au
niveau des vues : ce qui serait très loin d'être le cas avec OpenQuery !
Les vues pourraient même permettre d'absorber, dans une certaine mesure, les
variations de structure des bases Oracle.

Mais vu que SQL Server ne "transmet" pas la clause WHERE à Oracle je vais,
hélas, ne plus pouvoir me baser sur cette couche d'abstraction.
Je continuerai à utiliser cette couche que pour les applications qui
n'utilisent pas le WHERE (rapatriement en masse de données depuis Oracle).

Merci encore.

Jacques.


"Romelard Fabrice [MVP]" a écrit dans le message de
news:
Bonjour,

Cela me semble normal selon ce que vous expliquez.
Vous avez créé une vue sur le serveur SQL Server qui fait une requête
(SELECT *) sur votre serveur lié ORACLE sans filtre.
Ensuite vous envoyez une condition sur cette vue.

De ce fait, à mon sens l'ordre sera le suivant :
- SELECT * sur la table ORACLE
- Récupération de tous les éléments de la table ORACLE par le moteur


SQL
Server
- Application du filtre transmis à la vue par SQL Server
- Restitution des données

Donc le plan d'exécution est correct, c'est votre méthode qui me semble
discutable, d'ailleurs, je ne comprends pas bien le concept de la vue dans
ce cas.

--
Cordialement.

Romelard Fabrice [MVP]

"Vuillermet Jacques" a écrit dans le message de news:

> Bonjour,
>
> Contexte :
> - SQL2000 SP4 et Oracle 9.2 relié par une liaison réseau TRES TRES


lente.
> - une table Produit d'environ 1 million de lignes.
>
> J'effectue directement la requête suivante vers le serveur lié Oracle


sans
> difficulté :
>
> SELECT *
> FROM OPENQUERY(SrvLnk, '
> SELECT Id_Produit
> FROM Produit
> WHERE Id_Produit = 1')
>
> La réponse est rapide.
>
> Je crée la vue suivante :
>
> CREATE VIEW VueProduit AS
> SELECT *
> FROM OPENQUERY(SrvLnk, 'SELECT * FROM Produit')
>
> La requête initiale devient alors :
>
> SELECT Id_Produit
> FROM VueProduit
> WHERE Id_Produit = 1
>
> Mais là, le temps de réponse est très long (>30 minutes).
>
> Le plan d'exécution est le suivant :
>
> StmtText

--------------------------------------------------------------------------


--
> ------------------
> |--Filter(WHERE:([MSDAORA].[ID_PRODUIT]=Convert([@1])))
> |--Remote Scan(SOURCE:(LeServeurOracle), OBJECT:(SELECT * FROM
> PRODUIT))
>
> J'en déduis que SQL Server n'envoie pas le WHERE à Oracle.
> Autrement dit : SQL Server rapatrie d'abord le million de lignes PUIS il
> applique le filtre !
>
> Comment faire pour forcer SQL Server à envoyer la clause WHERE à Oracle


en
> utilisant une vue ?
>
> Merci,
>
> Jacques.
>
>




Avatar
Arnaud CLERET
Et pourquoi ne pas créer une procédure stockée comme ci-dessous et
l'utiliser de façon mutualisée comme vous souhaitez le faire :

CREATE PROCEDURE dbo.GetData
(
@IdProduit AS INT
)
AS
BEGIN

SET NOCOUNT ON

SELECT
*
FROM
OPENQUERY(SrvLnk,
'SELECT
Id_Produit
FROM
Produit
WHERE
Id_Produit = ' + @IdProduit)


END
GO

--
arno - http://www.dotnetguru2.org/acleret/

"Vuillermet Jacques" a écrit dans le message de news:

Merci de m'avoir confirmer ce que je pensais.

Je pensais qu'il y aurait un moyen (que j'ignore) de faire comme de SQL
Server à SQL Server : même si une vue est définie sans WHERE, si l'on
requête sur la vue avec un WHERE alors le WHERE est transmis à la table
source (mal dit mais l'état d'esprit y est).

Mais alors comment faire : ne plus utiliser de vue et utiliser
OpenQuery(lnk, ...) dans chaque requête ?
Je trouve cela dommage.

L'objectif des vues est le suivant : je définis mes vues une seule fois
dans
mon serveur SQL Server.
Ensuite, toutes les applications tournant sur SQL Server utilisent ces
vues.
Cela me permet de définir le serveur lié comme je l'entend (comme DBA SQL
Server) et même de pouvoir changer son nom si je le souhaite : il me
suffira
de reconstruire les vues sans avoir à toucher les applications.
Le développeur d'application, lui, ne voit que les vues.
Les vues forment donc une couche intermédiaire logique entre l'application
et le serveur Oracle.
Demain, si les données actuellement gérées par Oracle passent sous SQL
Server alors je n'ai rien à faire au niveau application mais seulement au
niveau des vues : ce qui serait très loin d'être le cas avec OpenQuery !
Les vues pourraient même permettre d'absorber, dans une certaine mesure,
les
variations de structure des bases Oracle.

Mais vu que SQL Server ne "transmet" pas la clause WHERE à Oracle je vais,
hélas, ne plus pouvoir me baser sur cette couche d'abstraction.
Je continuerai à utiliser cette couche que pour les applications qui
n'utilisent pas le WHERE (rapatriement en masse de données depuis Oracle).

Merci encore.

Jacques.


"Romelard Fabrice [MVP]" a écrit dans le message
de
news:
Bonjour,

Cela me semble normal selon ce que vous expliquez.
Vous avez créé une vue sur le serveur SQL Server qui fait une requête
(SELECT *) sur votre serveur lié ORACLE sans filtre.
Ensuite vous envoyez une condition sur cette vue.

De ce fait, à mon sens l'ordre sera le suivant :
- SELECT * sur la table ORACLE
- Récupération de tous les éléments de la table ORACLE par le moteur


SQL
Server
- Application du filtre transmis à la vue par SQL Server
- Restitution des données

Donc le plan d'exécution est correct, c'est votre méthode qui me semble
discutable, d'ailleurs, je ne comprends pas bien le concept de la vue
dans
ce cas.

--
Cordialement.

Romelard Fabrice [MVP]

"Vuillermet Jacques" a écrit dans le message de news:

> Bonjour,
>
> Contexte :
> - SQL2000 SP4 et Oracle 9.2 relié par une liaison réseau TRES TRES


lente.
> - une table Produit d'environ 1 million de lignes.
>
> J'effectue directement la requête suivante vers le serveur lié Oracle


sans
> difficulté :
>
> SELECT *
> FROM OPENQUERY(SrvLnk, '
> SELECT Id_Produit
> FROM Produit
> WHERE Id_Produit = 1')
>
> La réponse est rapide.
>
> Je crée la vue suivante :
>
> CREATE VIEW VueProduit AS
> SELECT *
> FROM OPENQUERY(SrvLnk, 'SELECT * FROM Produit')
>
> La requête initiale devient alors :
>
> SELECT Id_Produit
> FROM VueProduit
> WHERE Id_Produit = 1
>
> Mais là, le temps de réponse est très long (>30 minutes).
>
> Le plan d'exécution est le suivant :
>
> StmtText

--------------------------------------------------------------------------


--
> ------------------
> |--Filter(WHERE:([MSDAORA].[ID_PRODUIT]=Convert([@1])))
> |--Remote Scan(SOURCE:(LeServeurOracle), OBJECT:(SELECT * FROM
> PRODUIT))
>
> J'en déduis que SQL Server n'envoie pas le WHERE à Oracle.
> Autrement dit : SQL Server rapatrie d'abord le million de lignes PUIS
> il
> applique le filtre !
>
> Comment faire pour forcer SQL Server à envoyer la clause WHERE à Oracle


en
> utilisant une vue ?
>
> Merci,
>
> Jacques.
>
>








Avatar
Vuillermet Jacques
[Tu peux me tutoyer Arnaud... on est de la même société !]

L'objectif est (...était) de fournir aux développeurs une couche
d'abstraction qui leur laisse une entière liberté ; ils peuvent requêter sur
les vues comme sur une table :
- dans la clause SELECT : ils précisent les champs à remonter ;
- dans la clause FROM ils effectuent les jointures qu'ils veulent (même si
pas très glop côté perf) ;
- dans la clause WHERE ils précisent librement les conditions ("WHERE
Id_Produit=" était un simple exemple).

Ta solution de procédure stockée ne pourrait malheureusement pas fournir
cette souplesse, à moins de passer en argument la chaîne SQL complète à
exécuter.
... ce qui peut être une voie.

A+
Jacques.



"Arnaud CLERET" a écrit dans le message
de news:
Et pourquoi ne pas créer une procédure stockée comme ci-dessous et
l'utiliser de façon mutualisée comme vous souhaitez le faire :

CREATE PROCEDURE dbo.GetData
(
@IdProduit AS INT
)
AS
BEGIN

SET NOCOUNT ON

SELECT
*
FROM
OPENQUERY(SrvLnk,
'SELECT
Id_Produit
FROM
Produit
WHERE
Id_Produit = ' + @IdProduit)


END
GO

--
arno - http://www.dotnetguru2.org/acleret/

"Vuillermet Jacques" a écrit dans le message de news:

> Merci de m'avoir confirmer ce que je pensais.
>
> Je pensais qu'il y aurait un moyen (que j'ignore) de faire comme de SQL
> Server à SQL Server : même si une vue est définie sans WHERE, si l'on
> requête sur la vue avec un WHERE alors le WHERE est transmis à la table
> source (mal dit mais l'état d'esprit y est).
>
> Mais alors comment faire : ne plus utiliser de vue et utiliser
> OpenQuery(lnk, ...) dans chaque requête ?
> Je trouve cela dommage.
>
> L'objectif des vues est le suivant : je définis mes vues une seule fois
> dans
> mon serveur SQL Server.
> Ensuite, toutes les applications tournant sur SQL Server utilisent ces
> vues.
> Cela me permet de définir le serveur lié comme je l'entend (comme DBA


SQL
> Server) et même de pouvoir changer son nom si je le souhaite : il me
> suffira
> de reconstruire les vues sans avoir à toucher les applications.
> Le développeur d'application, lui, ne voit que les vues.
> Les vues forment donc une couche intermédiaire logique entre


l'application
> et le serveur Oracle.
> Demain, si les données actuellement gérées par Oracle passent sous SQL
> Server alors je n'ai rien à faire au niveau application mais seulement


au
> niveau des vues : ce qui serait très loin d'être le cas avec OpenQuery !
> Les vues pourraient même permettre d'absorber, dans une certaine mesure,
> les
> variations de structure des bases Oracle.
>
> Mais vu que SQL Server ne "transmet" pas la clause WHERE à Oracle je


vais,
> hélas, ne plus pouvoir me baser sur cette couche d'abstraction.
> Je continuerai à utiliser cette couche que pour les applications qui
> n'utilisent pas le WHERE (rapatriement en masse de données depuis


Oracle).
>
> Merci encore.
>
> Jacques.
>
>
> "Romelard Fabrice [MVP]" a écrit dans le message
> de
> news:
>> Bonjour,
>>
>> Cela me semble normal selon ce que vous expliquez.
>> Vous avez créé une vue sur le serveur SQL Server qui fait une requête
>> (SELECT *) sur votre serveur lié ORACLE sans filtre.
>> Ensuite vous envoyez une condition sur cette vue.
>>
>> De ce fait, à mon sens l'ordre sera le suivant :
>> - SELECT * sur la table ORACLE
>> - Récupération de tous les éléments de la table ORACLE par le


moteur
> SQL
>> Server
>> - Application du filtre transmis à la vue par SQL Server
>> - Restitution des données
>>
>> Donc le plan d'exécution est correct, c'est votre méthode qui me semble
>> discutable, d'ailleurs, je ne comprends pas bien le concept de la vue
>> dans
>> ce cas.
>>
>> --
>> Cordialement.
>>
>> Romelard Fabrice [MVP]
>>
>> "Vuillermet Jacques" a écrit dans le message de


news:
>>
>> > Bonjour,
>> >
>> > Contexte :
>> > - SQL2000 SP4 et Oracle 9.2 relié par une liaison réseau TRES TRES
> lente.
>> > - une table Produit d'environ 1 million de lignes.
>> >
>> > J'effectue directement la requête suivante vers le serveur lié Oracle
> sans
>> > difficulté :
>> >
>> > SELECT *
>> > FROM OPENQUERY(SrvLnk, '
>> > SELECT Id_Produit
>> > FROM Produit
>> > WHERE Id_Produit = 1')
>> >
>> > La réponse est rapide.
>> >
>> > Je crée la vue suivante :
>> >
>> > CREATE VIEW VueProduit AS
>> > SELECT *
>> > FROM OPENQUERY(SrvLnk, 'SELECT * FROM Produit')
>> >
>> > La requête initiale devient alors :
>> >
>> > SELECT Id_Produit
>> > FROM VueProduit
>> > WHERE Id_Produit = 1
>> >
>> > Mais là, le temps de réponse est très long (>30 minutes).
>> >
>> > Le plan d'exécution est le suivant :
>> >
>> > StmtText
>>

-------------------------------------------------------------------------




-
> --
>> > ------------------
>> > |--Filter(WHERE:([MSDAORA].[ID_PRODUIT]=Convert([@1])))
>> > |--Remote Scan(SOURCE:(LeServeurOracle), OBJECT:(SELECT * FROM
>> > PRODUIT))
>> >
>> > J'en déduis que SQL Server n'envoie pas le WHERE à Oracle.
>> > Autrement dit : SQL Server rapatrie d'abord le million de lignes PUIS
>> > il
>> > applique le filtre !
>> >
>> > Comment faire pour forcer SQL Server à envoyer la clause WHERE à


Oracle
> en
>> > utilisant une vue ?
>> >
>> > Merci,
>> >
>> > Jacques.
>> >
>> >
>>
>>
>
>




Avatar
Arnaud CLERET
Oups, je n'avais pas ragardé qui était l'émetteur de ce mail :)

Je comprend en effet ta problématique mais il va falloir faire un compromis
entre sécurité des données, performance et totale liberté des développeur
sur ce jeu de données.

Pour ma part, je préfèrerai implémenter une procédure stockée qui me
garantirait la sécurité d'accès à mes données et surtout les plan
d'exécution qui en découle. En effet, le fait de laisser un développeur
s'abstraire des données qu'il requête risque d'amener à des exécution ne
profitant pas des indexes que tu aurais pu définir.

Si tu souhaites réellement avoir toute la liberté dans l'exécution des
requêtes, tu peux regarder du coté de la gestion du XML dans SQL Server qui
permet de passer un flux XML à une procédure stockée, de parser ce flux pour
construire la requête puis d'exécuter la requête comme tu le souhaites. Ce
procédé te garantira un peu plus de sécurité et de performance sur tes
requêtes.

Gestion de l'XML => regarde du coté de OPENXML
Exécution de requête dynamique => regarde du coté de sp_executeSql

--
arno - http://www.dotnetguru2.org/acleret/

"Vuillermet Jacques" a écrit dans le message de news:
%
[Tu peux me tutoyer Arnaud... on est de la même société !]

L'objectif est (...était) de fournir aux développeurs une couche
d'abstraction qui leur laisse une entière liberté ; ils peuvent requêter
sur
les vues comme sur une table :
- dans la clause SELECT : ils précisent les champs à remonter ;
- dans la clause FROM ils effectuent les jointures qu'ils veulent (même si
pas très glop côté perf) ;
- dans la clause WHERE ils précisent librement les conditions ("WHERE
Id_Produit=" était un simple exemple).

Ta solution de procédure stockée ne pourrait malheureusement pas fournir
cette souplesse, à moins de passer en argument la chaîne SQL complète à
exécuter.
... ce qui peut être une voie.

A+
Jacques.



"Arnaud CLERET" a écrit dans le message
de news:
Et pourquoi ne pas créer une procédure stockée comme ci-dessous et
l'utiliser de façon mutualisée comme vous souhaitez le faire :

CREATE PROCEDURE dbo.GetData
(
@IdProduit AS INT
)
AS
BEGIN

SET NOCOUNT ON

SELECT
*
FROM
OPENQUERY(SrvLnk,
'SELECT
Id_Produit
FROM
Produit
WHERE
Id_Produit = ' + @IdProduit)


END
GO

--
arno - http://www.dotnetguru2.org/acleret/

"Vuillermet Jacques" a écrit dans le message de news:

> Merci de m'avoir confirmer ce que je pensais.
>
> Je pensais qu'il y aurait un moyen (que j'ignore) de faire comme de SQL
> Server à SQL Server : même si une vue est définie sans WHERE, si l'on
> requête sur la vue avec un WHERE alors le WHERE est transmis à la table
> source (mal dit mais l'état d'esprit y est).
>
> Mais alors comment faire : ne plus utiliser de vue et utiliser
> OpenQuery(lnk, ...) dans chaque requête ?
> Je trouve cela dommage.
>
> L'objectif des vues est le suivant : je définis mes vues une seule fois
> dans
> mon serveur SQL Server.
> Ensuite, toutes les applications tournant sur SQL Server utilisent ces
> vues.
> Cela me permet de définir le serveur lié comme je l'entend (comme DBA


SQL
> Server) et même de pouvoir changer son nom si je le souhaite : il me
> suffira
> de reconstruire les vues sans avoir à toucher les applications.
> Le développeur d'application, lui, ne voit que les vues.
> Les vues forment donc une couche intermédiaire logique entre


l'application
> et le serveur Oracle.
> Demain, si les données actuellement gérées par Oracle passent sous SQL
> Server alors je n'ai rien à faire au niveau application mais seulement


au
> niveau des vues : ce qui serait très loin d'être le cas avec OpenQuery
> !
> Les vues pourraient même permettre d'absorber, dans une certaine
> mesure,
> les
> variations de structure des bases Oracle.
>
> Mais vu que SQL Server ne "transmet" pas la clause WHERE à Oracle je


vais,
> hélas, ne plus pouvoir me baser sur cette couche d'abstraction.
> Je continuerai à utiliser cette couche que pour les applications qui
> n'utilisent pas le WHERE (rapatriement en masse de données depuis


Oracle).
>
> Merci encore.
>
> Jacques.
>
>
> "Romelard Fabrice [MVP]" a écrit dans le
> message
> de
> news:
>> Bonjour,
>>
>> Cela me semble normal selon ce que vous expliquez.
>> Vous avez créé une vue sur le serveur SQL Server qui fait une requête
>> (SELECT *) sur votre serveur lié ORACLE sans filtre.
>> Ensuite vous envoyez une condition sur cette vue.
>>
>> De ce fait, à mon sens l'ordre sera le suivant :
>> - SELECT * sur la table ORACLE
>> - Récupération de tous les éléments de la table ORACLE par le


moteur
> SQL
>> Server
>> - Application du filtre transmis à la vue par SQL Server
>> - Restitution des données
>>
>> Donc le plan d'exécution est correct, c'est votre méthode qui me
>> semble
>> discutable, d'ailleurs, je ne comprends pas bien le concept de la vue
>> dans
>> ce cas.
>>
>> --
>> Cordialement.
>>
>> Romelard Fabrice [MVP]
>>
>> "Vuillermet Jacques" a écrit dans le message de


news:
>>
>> > Bonjour,
>> >
>> > Contexte :
>> > - SQL2000 SP4 et Oracle 9.2 relié par une liaison réseau TRES TRES
> lente.
>> > - une table Produit d'environ 1 million de lignes.
>> >
>> > J'effectue directement la requête suivante vers le serveur lié
>> > Oracle
> sans
>> > difficulté :
>> >
>> > SELECT *
>> > FROM OPENQUERY(SrvLnk, '
>> > SELECT Id_Produit
>> > FROM Produit
>> > WHERE Id_Produit = 1')
>> >
>> > La réponse est rapide.
>> >
>> > Je crée la vue suivante :
>> >
>> > CREATE VIEW VueProduit AS
>> > SELECT *
>> > FROM OPENQUERY(SrvLnk, 'SELECT * FROM Produit')
>> >
>> > La requête initiale devient alors :
>> >
>> > SELECT Id_Produit
>> > FROM VueProduit
>> > WHERE Id_Produit = 1
>> >
>> > Mais là, le temps de réponse est très long (>30 minutes).
>> >
>> > Le plan d'exécution est le suivant :
>> >
>> > StmtText
>>

-------------------------------------------------------------------------




-
> --
>> > ------------------
>> > |--Filter(WHERE:([MSDAORA].[ID_PRODUIT]=Convert([@1])))
>> > |--Remote Scan(SOURCE:(LeServeurOracle), OBJECT:(SELECT * FROM
>> > PRODUIT))
>> >
>> > J'en déduis que SQL Server n'envoie pas le WHERE à Oracle.
>> > Autrement dit : SQL Server rapatrie d'abord le million de lignes
>> > PUIS
>> > il
>> > applique le filtre !
>> >
>> > Comment faire pour forcer SQL Server à envoyer la clause WHERE à


Oracle
> en
>> > utilisant une vue ?
>> >
>> > Merci,
>> >
>> > Jacques.
>> >
>> >
>>
>>
>
>