Bonjour,
j'ai un souci sous SQL 2005 Enterprise SP2.
J'ai créé une vue (avec Schemabinding et tout ce qui va bien), puis j'ai
créé un Index Unique Clustered sur cette vue.
Tout s'est jusque là bien passé.
le problème, c'est que lorsque je fais un select top 10 * from ma_vue, le
plan d'exécution montre que le moteur de données refait les jointures avec
les tables sous-jacentes, au lieu d'utiliser l'index créé.
Quelqu'un aurait-il une piste?
Merci.
JN
Bonjour,
j'ai un souci sous SQL 2005 Enterprise SP2.
J'ai créé une vue (avec Schemabinding et tout ce qui va bien), puis j'ai
créé un Index Unique Clustered sur cette vue.
Tout s'est jusque là bien passé.
le problème, c'est que lorsque je fais un select top 10 * from ma_vue, le
plan d'exécution montre que le moteur de données refait les jointures avec
les tables sous-jacentes, au lieu d'utiliser l'index créé.
Quelqu'un aurait-il une piste?
Merci.
JN
Bonjour,
j'ai un souci sous SQL 2005 Enterprise SP2.
J'ai créé une vue (avec Schemabinding et tout ce qui va bien), puis j'ai
créé un Index Unique Clustered sur cette vue.
Tout s'est jusque là bien passé.
le problème, c'est que lorsque je fais un select top 10 * from ma_vue, le
plan d'exécution montre que le moteur de données refait les jointures avec
les tables sous-jacentes, au lieu d'utiliser l'index créé.
Quelqu'un aurait-il une piste?
Merci.
JN
Bonjour,
Avez vous fait une mise à jour des stats (UPDATE STATISTICS), vidé le cache
(DBCC FREEPROCACHE), ...
Cordialement
_______________________________
Philippe TROTIN
Microsoft Services France
_______________________________
"Jean-Nicolas BERGER" a écrit
dans le message de groupe de discussion :
> Bonjour,
> j'ai un souci sous SQL 2005 Enterprise SP2.
> J'ai créé une vue (avec Schemabinding et tout ce qui va bien), puis j'ai
> créé un Index Unique Clustered sur cette vue.
> Tout s'est jusque là bien passé.
> le problème, c'est que lorsque je fais un select top 10 * from ma_vue, le
> plan d'exécution montre que le moteur de données refait les jointures avec
> les tables sous-jacentes, au lieu d'utiliser l'index créé.
> Quelqu'un aurait-il une piste?
> Merci.
> JN
Bonjour,
Avez vous fait une mise à jour des stats (UPDATE STATISTICS), vidé le cache
(DBCC FREEPROCACHE), ...
Cordialement
_______________________________
Philippe TROTIN
Microsoft Services France
_______________________________
"Jean-Nicolas BERGER" <JeanNicolasBERGER@discussions.microsoft.com> a écrit
dans le message de groupe de discussion :
7AF8B005-CB2A-4C03-BBE4-ACF4987A5939@microsoft.com...
> Bonjour,
> j'ai un souci sous SQL 2005 Enterprise SP2.
> J'ai créé une vue (avec Schemabinding et tout ce qui va bien), puis j'ai
> créé un Index Unique Clustered sur cette vue.
> Tout s'est jusque là bien passé.
> le problème, c'est que lorsque je fais un select top 10 * from ma_vue, le
> plan d'exécution montre que le moteur de données refait les jointures avec
> les tables sous-jacentes, au lieu d'utiliser l'index créé.
> Quelqu'un aurait-il une piste?
> Merci.
> JN
Bonjour,
Avez vous fait une mise à jour des stats (UPDATE STATISTICS), vidé le cache
(DBCC FREEPROCACHE), ...
Cordialement
_______________________________
Philippe TROTIN
Microsoft Services France
_______________________________
"Jean-Nicolas BERGER" a écrit
dans le message de groupe de discussion :
> Bonjour,
> j'ai un souci sous SQL 2005 Enterprise SP2.
> J'ai créé une vue (avec Schemabinding et tout ce qui va bien), puis j'ai
> créé un Index Unique Clustered sur cette vue.
> Tout s'est jusque là bien passé.
> le problème, c'est que lorsque je fais un select top 10 * from ma_vue, le
> plan d'exécution montre que le moteur de données refait les jointures avec
> les tables sous-jacentes, au lieu d'utiliser l'index créé.
> Quelqu'un aurait-il une piste?
> Merci.
> JN
Bonjour,
Le comportement est inchangé lorsque je met à jour les statistiques ou
encore lorsque je vide le cache;
Pour info, si je lance le SELECT avec WITH (NOEXPAND), il y a bien
utilisation de l'index.
Et en lancant dans un même lot un SELECT avec WITH (NOEXPAND) et un SELECT
avec OPTION (EXPAND VIEWS), j'obtiens une répartition du temps d'exécution
de
la forme 5% / 95%.
Et sans option, l'optimiseur choisi la version la plus lente... :-(
Merci d'avance pour votre aide.
Cordialement.
JN BERGER
"Philippe TROTIN [MS]" wrote:Bonjour,
Avez vous fait une mise à jour des stats (UPDATE STATISTICS), vidé le
cache
(DBCC FREEPROCACHE), ...
Cordialement
_______________________________
Philippe TROTIN
Microsoft Services France
_______________________________
"Jean-Nicolas BERGER" a
écrit
dans le message de groupe de discussion :
> Bonjour,
> j'ai un souci sous SQL 2005 Enterprise SP2.
> J'ai créé une vue (avec Schemabinding et tout ce qui va bien), puis
> j'ai
> créé un Index Unique Clustered sur cette vue.
> Tout s'est jusque là bien passé.
> le problème, c'est que lorsque je fais un select top 10 * from ma_vue,
> le
> plan d'exécution montre que le moteur de données refait les jointures
> avec
> les tables sous-jacentes, au lieu d'utiliser l'index créé.
> Quelqu'un aurait-il une piste?
> Merci.
> JN
Bonjour,
Le comportement est inchangé lorsque je met à jour les statistiques ou
encore lorsque je vide le cache;
Pour info, si je lance le SELECT avec WITH (NOEXPAND), il y a bien
utilisation de l'index.
Et en lancant dans un même lot un SELECT avec WITH (NOEXPAND) et un SELECT
avec OPTION (EXPAND VIEWS), j'obtiens une répartition du temps d'exécution
de
la forme 5% / 95%.
Et sans option, l'optimiseur choisi la version la plus lente... :-(
Merci d'avance pour votre aide.
Cordialement.
JN BERGER
"Philippe TROTIN [MS]" wrote:
Bonjour,
Avez vous fait une mise à jour des stats (UPDATE STATISTICS), vidé le
cache
(DBCC FREEPROCACHE), ...
Cordialement
_______________________________
Philippe TROTIN
Microsoft Services France
_______________________________
"Jean-Nicolas BERGER" <JeanNicolasBERGER@discussions.microsoft.com> a
écrit
dans le message de groupe de discussion :
7AF8B005-CB2A-4C03-BBE4-ACF4987A5939@microsoft.com...
> Bonjour,
> j'ai un souci sous SQL 2005 Enterprise SP2.
> J'ai créé une vue (avec Schemabinding et tout ce qui va bien), puis
> j'ai
> créé un Index Unique Clustered sur cette vue.
> Tout s'est jusque là bien passé.
> le problème, c'est que lorsque je fais un select top 10 * from ma_vue,
> le
> plan d'exécution montre que le moteur de données refait les jointures
> avec
> les tables sous-jacentes, au lieu d'utiliser l'index créé.
> Quelqu'un aurait-il une piste?
> Merci.
> JN
Bonjour,
Le comportement est inchangé lorsque je met à jour les statistiques ou
encore lorsque je vide le cache;
Pour info, si je lance le SELECT avec WITH (NOEXPAND), il y a bien
utilisation de l'index.
Et en lancant dans un même lot un SELECT avec WITH (NOEXPAND) et un SELECT
avec OPTION (EXPAND VIEWS), j'obtiens une répartition du temps d'exécution
de
la forme 5% / 95%.
Et sans option, l'optimiseur choisi la version la plus lente... :-(
Merci d'avance pour votre aide.
Cordialement.
JN BERGER
"Philippe TROTIN [MS]" wrote:Bonjour,
Avez vous fait une mise à jour des stats (UPDATE STATISTICS), vidé le
cache
(DBCC FREEPROCACHE), ...
Cordialement
_______________________________
Philippe TROTIN
Microsoft Services France
_______________________________
"Jean-Nicolas BERGER" a
écrit
dans le message de groupe de discussion :
> Bonjour,
> j'ai un souci sous SQL 2005 Enterprise SP2.
> J'ai créé une vue (avec Schemabinding et tout ce qui va bien), puis
> j'ai
> créé un Index Unique Clustered sur cette vue.
> Tout s'est jusque là bien passé.
> le problème, c'est que lorsque je fais un select top 10 * from ma_vue,
> le
> plan d'exécution montre que le moteur de données refait les jointures
> avec
> les tables sous-jacentes, au lieu d'utiliser l'index créé.
> Quelqu'un aurait-il une piste?
> Merci.
> JN
Bonjour,
Et si vous faites un SELECT TOP 10 * FROM ma_vue ORDER BY Mon_Index ?
Cordialement
_______________________________
Philippe TROTIN
Microsoft Services France
_______________________________
"Jean-Nicolas BERGER" a écrit
dans le message de groupe de discussion :
> Bonjour,
> Le comportement est inchangé lorsque je met à jour les statistiques ou
> encore lorsque je vide le cache;
> Pour info, si je lance le SELECT avec WITH (NOEXPAND), il y a bien
> utilisation de l'index.
> Et en lancant dans un même lot un SELECT avec WITH (NOEXPAND) et un SELECT
> avec OPTION (EXPAND VIEWS), j'obtiens une répartition du temps d'exécution
> de
> la forme 5% / 95%.
> Et sans option, l'optimiseur choisi la version la plus lente... :-(
> Merci d'avance pour votre aide.
> Cordialement.
> JN BERGER
>
> "Philippe TROTIN [MS]" wrote:
>
>> Bonjour,
>>
>> Avez vous fait une mise à jour des stats (UPDATE STATISTICS), vidé le
>> cache
>> (DBCC FREEPROCACHE), ...
>>
>> Cordialement
>> _______________________________
>>
>> Philippe TROTIN
>> Microsoft Services France
>> _______________________________
>>
>> "Jean-Nicolas BERGER" a
>> écrit
>> dans le message de groupe de discussion :
>>
>> > Bonjour,
>> > j'ai un souci sous SQL 2005 Enterprise SP2.
>> > J'ai créé une vue (avec Schemabinding et tout ce qui va bien), puis
>> > j'ai
>> > créé un Index Unique Clustered sur cette vue.
>> > Tout s'est jusque là bien passé.
>> > le problème, c'est que lorsque je fais un select top 10 * from ma_vue,
>> > le
>> > plan d'exécution montre que le moteur de données refait les jointures
>> > avec
>> > les tables sous-jacentes, au lieu d'utiliser l'index créé.
>> > Quelqu'un aurait-il une piste?
>> > Merci.
>> > JN
>>
>>
Bonjour,
Et si vous faites un SELECT TOP 10 * FROM ma_vue ORDER BY Mon_Index ?
Cordialement
_______________________________
Philippe TROTIN
Microsoft Services France
_______________________________
"Jean-Nicolas BERGER" <JeanNicolasBERGER@discussions.microsoft.com> a écrit
dans le message de groupe de discussion :
7E432C9D-2820-4BCD-9C11-1B86B3030000@microsoft.com...
> Bonjour,
> Le comportement est inchangé lorsque je met à jour les statistiques ou
> encore lorsque je vide le cache;
> Pour info, si je lance le SELECT avec WITH (NOEXPAND), il y a bien
> utilisation de l'index.
> Et en lancant dans un même lot un SELECT avec WITH (NOEXPAND) et un SELECT
> avec OPTION (EXPAND VIEWS), j'obtiens une répartition du temps d'exécution
> de
> la forme 5% / 95%.
> Et sans option, l'optimiseur choisi la version la plus lente... :-(
> Merci d'avance pour votre aide.
> Cordialement.
> JN BERGER
>
> "Philippe TROTIN [MS]" wrote:
>
>> Bonjour,
>>
>> Avez vous fait une mise à jour des stats (UPDATE STATISTICS), vidé le
>> cache
>> (DBCC FREEPROCACHE), ...
>>
>> Cordialement
>> _______________________________
>>
>> Philippe TROTIN
>> Microsoft Services France
>> _______________________________
>>
>> "Jean-Nicolas BERGER" <JeanNicolasBERGER@discussions.microsoft.com> a
>> écrit
>> dans le message de groupe de discussion :
>> 7AF8B005-CB2A-4C03-BBE4-ACF4987A5939@microsoft.com...
>> > Bonjour,
>> > j'ai un souci sous SQL 2005 Enterprise SP2.
>> > J'ai créé une vue (avec Schemabinding et tout ce qui va bien), puis
>> > j'ai
>> > créé un Index Unique Clustered sur cette vue.
>> > Tout s'est jusque là bien passé.
>> > le problème, c'est que lorsque je fais un select top 10 * from ma_vue,
>> > le
>> > plan d'exécution montre que le moteur de données refait les jointures
>> > avec
>> > les tables sous-jacentes, au lieu d'utiliser l'index créé.
>> > Quelqu'un aurait-il une piste?
>> > Merci.
>> > JN
>>
>>
Bonjour,
Et si vous faites un SELECT TOP 10 * FROM ma_vue ORDER BY Mon_Index ?
Cordialement
_______________________________
Philippe TROTIN
Microsoft Services France
_______________________________
"Jean-Nicolas BERGER" a écrit
dans le message de groupe de discussion :
> Bonjour,
> Le comportement est inchangé lorsque je met à jour les statistiques ou
> encore lorsque je vide le cache;
> Pour info, si je lance le SELECT avec WITH (NOEXPAND), il y a bien
> utilisation de l'index.
> Et en lancant dans un même lot un SELECT avec WITH (NOEXPAND) et un SELECT
> avec OPTION (EXPAND VIEWS), j'obtiens une répartition du temps d'exécution
> de
> la forme 5% / 95%.
> Et sans option, l'optimiseur choisi la version la plus lente... :-(
> Merci d'avance pour votre aide.
> Cordialement.
> JN BERGER
>
> "Philippe TROTIN [MS]" wrote:
>
>> Bonjour,
>>
>> Avez vous fait une mise à jour des stats (UPDATE STATISTICS), vidé le
>> cache
>> (DBCC FREEPROCACHE), ...
>>
>> Cordialement
>> _______________________________
>>
>> Philippe TROTIN
>> Microsoft Services France
>> _______________________________
>>
>> "Jean-Nicolas BERGER" a
>> écrit
>> dans le message de groupe de discussion :
>>
>> > Bonjour,
>> > j'ai un souci sous SQL 2005 Enterprise SP2.
>> > J'ai créé une vue (avec Schemabinding et tout ce qui va bien), puis
>> > j'ai
>> > créé un Index Unique Clustered sur cette vue.
>> > Tout s'est jusque là bien passé.
>> > le problème, c'est que lorsque je fais un select top 10 * from ma_vue,
>> > le
>> > plan d'exécution montre que le moteur de données refait les jointures
>> > avec
>> > les tables sous-jacentes, au lieu d'utiliser l'index créé.
>> > Quelqu'un aurait-il une piste?
>> > Merci.
>> > JN
>>
>>
Je ne peux bien évidemment pas faire un 'ORDER BY Mon_Index', mais un
'ORDER
BY LesChampsDeMonIndex' n'arrange pas le problème, le plan d'exécution
montre
toujours un passage par les tables sous-jacentes.
Mytère, quand tu nous tiens...
JN.
"Philippe TROTIN [MS]" wrote:Bonjour,
Et si vous faites un SELECT TOP 10 * FROM ma_vue ORDER BY Mon_Index ?
Cordialement
_______________________________
Philippe TROTIN
Microsoft Services France
_______________________________
"Jean-Nicolas BERGER" a
écrit
dans le message de groupe de discussion :
> Bonjour,
> Le comportement est inchangé lorsque je met à jour les statistiques ou
> encore lorsque je vide le cache;
> Pour info, si je lance le SELECT avec WITH (NOEXPAND), il y a bien
> utilisation de l'index.
> Et en lancant dans un même lot un SELECT avec WITH (NOEXPAND) et un
> SELECT
> avec OPTION (EXPAND VIEWS), j'obtiens une répartition du temps
> d'exécution
> de
> la forme 5% / 95%.
> Et sans option, l'optimiseur choisi la version la plus lente... :-(
> Merci d'avance pour votre aide.
> Cordialement.
> JN BERGER
>
> "Philippe TROTIN [MS]" wrote:
>
>> Bonjour,
>>
>> Avez vous fait une mise à jour des stats (UPDATE STATISTICS), vidé le
>> cache
>> (DBCC FREEPROCACHE), ...
>>
>> Cordialement
>> _______________________________
>>
>> Philippe TROTIN
>> Microsoft Services France
>> _______________________________
>>
>> "Jean-Nicolas BERGER" a
>> écrit
>> dans le message de groupe de discussion :
>>
>> > Bonjour,
>> > j'ai un souci sous SQL 2005 Enterprise SP2.
>> > J'ai créé une vue (avec Schemabinding et tout ce qui va bien), puis
>> > j'ai
>> > créé un Index Unique Clustered sur cette vue.
>> > Tout s'est jusque là bien passé.
>> > le problème, c'est que lorsque je fais un select top 10 * from
>> > ma_vue,
>> > le
>> > plan d'exécution montre que le moteur de données refait les
>> > jointures
>> > avec
>> > les tables sous-jacentes, au lieu d'utiliser l'index créé.
>> > Quelqu'un aurait-il une piste?
>> > Merci.
>> > JN
>>
>>
Je ne peux bien évidemment pas faire un 'ORDER BY Mon_Index', mais un
'ORDER
BY LesChampsDeMonIndex' n'arrange pas le problème, le plan d'exécution
montre
toujours un passage par les tables sous-jacentes.
Mytère, quand tu nous tiens...
JN.
"Philippe TROTIN [MS]" wrote:
Bonjour,
Et si vous faites un SELECT TOP 10 * FROM ma_vue ORDER BY Mon_Index ?
Cordialement
_______________________________
Philippe TROTIN
Microsoft Services France
_______________________________
"Jean-Nicolas BERGER" <JeanNicolasBERGER@discussions.microsoft.com> a
écrit
dans le message de groupe de discussion :
7E432C9D-2820-4BCD-9C11-1B86B3030000@microsoft.com...
> Bonjour,
> Le comportement est inchangé lorsque je met à jour les statistiques ou
> encore lorsque je vide le cache;
> Pour info, si je lance le SELECT avec WITH (NOEXPAND), il y a bien
> utilisation de l'index.
> Et en lancant dans un même lot un SELECT avec WITH (NOEXPAND) et un
> SELECT
> avec OPTION (EXPAND VIEWS), j'obtiens une répartition du temps
> d'exécution
> de
> la forme 5% / 95%.
> Et sans option, l'optimiseur choisi la version la plus lente... :-(
> Merci d'avance pour votre aide.
> Cordialement.
> JN BERGER
>
> "Philippe TROTIN [MS]" wrote:
>
>> Bonjour,
>>
>> Avez vous fait une mise à jour des stats (UPDATE STATISTICS), vidé le
>> cache
>> (DBCC FREEPROCACHE), ...
>>
>> Cordialement
>> _______________________________
>>
>> Philippe TROTIN
>> Microsoft Services France
>> _______________________________
>>
>> "Jean-Nicolas BERGER" <JeanNicolasBERGER@discussions.microsoft.com> a
>> écrit
>> dans le message de groupe de discussion :
>> 7AF8B005-CB2A-4C03-BBE4-ACF4987A5939@microsoft.com...
>> > Bonjour,
>> > j'ai un souci sous SQL 2005 Enterprise SP2.
>> > J'ai créé une vue (avec Schemabinding et tout ce qui va bien), puis
>> > j'ai
>> > créé un Index Unique Clustered sur cette vue.
>> > Tout s'est jusque là bien passé.
>> > le problème, c'est que lorsque je fais un select top 10 * from
>> > ma_vue,
>> > le
>> > plan d'exécution montre que le moteur de données refait les
>> > jointures
>> > avec
>> > les tables sous-jacentes, au lieu d'utiliser l'index créé.
>> > Quelqu'un aurait-il une piste?
>> > Merci.
>> > JN
>>
>>
Je ne peux bien évidemment pas faire un 'ORDER BY Mon_Index', mais un
'ORDER
BY LesChampsDeMonIndex' n'arrange pas le problème, le plan d'exécution
montre
toujours un passage par les tables sous-jacentes.
Mytère, quand tu nous tiens...
JN.
"Philippe TROTIN [MS]" wrote:Bonjour,
Et si vous faites un SELECT TOP 10 * FROM ma_vue ORDER BY Mon_Index ?
Cordialement
_______________________________
Philippe TROTIN
Microsoft Services France
_______________________________
"Jean-Nicolas BERGER" a
écrit
dans le message de groupe de discussion :
> Bonjour,
> Le comportement est inchangé lorsque je met à jour les statistiques ou
> encore lorsque je vide le cache;
> Pour info, si je lance le SELECT avec WITH (NOEXPAND), il y a bien
> utilisation de l'index.
> Et en lancant dans un même lot un SELECT avec WITH (NOEXPAND) et un
> SELECT
> avec OPTION (EXPAND VIEWS), j'obtiens une répartition du temps
> d'exécution
> de
> la forme 5% / 95%.
> Et sans option, l'optimiseur choisi la version la plus lente... :-(
> Merci d'avance pour votre aide.
> Cordialement.
> JN BERGER
>
> "Philippe TROTIN [MS]" wrote:
>
>> Bonjour,
>>
>> Avez vous fait une mise à jour des stats (UPDATE STATISTICS), vidé le
>> cache
>> (DBCC FREEPROCACHE), ...
>>
>> Cordialement
>> _______________________________
>>
>> Philippe TROTIN
>> Microsoft Services France
>> _______________________________
>>
>> "Jean-Nicolas BERGER" a
>> écrit
>> dans le message de groupe de discussion :
>>
>> > Bonjour,
>> > j'ai un souci sous SQL 2005 Enterprise SP2.
>> > J'ai créé une vue (avec Schemabinding et tout ce qui va bien), puis
>> > j'ai
>> > créé un Index Unique Clustered sur cette vue.
>> > Tout s'est jusque là bien passé.
>> > le problème, c'est que lorsque je fais un select top 10 * from
>> > ma_vue,
>> > le
>> > plan d'exécution montre que le moteur de données refait les
>> > jointures
>> > avec
>> > les tables sous-jacentes, au lieu d'utiliser l'index créé.
>> > Quelqu'un aurait-il une piste?
>> > Merci.
>> > JN
>>
>>
En fait le comportement est celui d'une edition Standard alors qu'il s'agit
d'une edition Enterprise
Je lancerais a toutes fins utiles
SELECT SERVERPROPERTY ('Edition')
Med Bouchenafa
"Jean-Nicolas BERGER" wrote in
message news:
> Je ne peux bien évidemment pas faire un 'ORDER BY Mon_Index', mais un
> 'ORDER
> BY LesChampsDeMonIndex' n'arrange pas le problème, le plan d'exécution
> montre
> toujours un passage par les tables sous-jacentes.
>
> Mytère, quand tu nous tiens...
> JN.
>
> "Philippe TROTIN [MS]" wrote:
>
>> Bonjour,
>>
>> Et si vous faites un SELECT TOP 10 * FROM ma_vue ORDER BY Mon_Index ?
>>
>> Cordialement
>> _______________________________
>>
>> Philippe TROTIN
>> Microsoft Services France
>> _______________________________
>>
>> "Jean-Nicolas BERGER" a
>> écrit
>> dans le message de groupe de discussion :
>>
>> > Bonjour,
>> > Le comportement est inchangé lorsque je met à jour les statistiques ou
>> > encore lorsque je vide le cache;
>> > Pour info, si je lance le SELECT avec WITH (NOEXPAND), il y a bien
>> > utilisation de l'index.
>> > Et en lancant dans un même lot un SELECT avec WITH (NOEXPAND) et un
>> > SELECT
>> > avec OPTION (EXPAND VIEWS), j'obtiens une répartition du temps
>> > d'exécution
>> > de
>> > la forme 5% / 95%.
>> > Et sans option, l'optimiseur choisi la version la plus lente... :-(
>> > Merci d'avance pour votre aide.
>> > Cordialement.
>> > JN BERGER
>> >
>> > "Philippe TROTIN [MS]" wrote:
>> >
>> >> Bonjour,
>> >>
>> >> Avez vous fait une mise à jour des stats (UPDATE STATISTICS), vidé le
>> >> cache
>> >> (DBCC FREEPROCACHE), ...
>> >>
>> >> Cordialement
>> >> _______________________________
>> >>
>> >> Philippe TROTIN
>> >> Microsoft Services France
>> >> _______________________________
>> >>
>> >> "Jean-Nicolas BERGER" a
>> >> écrit
>> >> dans le message de groupe de discussion :
>> >>
>> >> > Bonjour,
>> >> > j'ai un souci sous SQL 2005 Enterprise SP2.
>> >> > J'ai créé une vue (avec Schemabinding et tout ce qui va bien), puis
>> >> > j'ai
>> >> > créé un Index Unique Clustered sur cette vue.
>> >> > Tout s'est jusque là bien passé.
>> >> > le problème, c'est que lorsque je fais un select top 10 * from
>> >> > ma_vue,
>> >> > le
>> >> > plan d'exécution montre que le moteur de données refait les
>> >> > jointures
>> >> > avec
>> >> > les tables sous-jacentes, au lieu d'utiliser l'index créé.
>> >> > Quelqu'un aurait-il une piste?
>> >> > Merci.
>> >> > JN
>> >>
>> >>
>>
En fait le comportement est celui d'une edition Standard alors qu'il s'agit
d'une edition Enterprise
Je lancerais a toutes fins utiles
SELECT SERVERPROPERTY ('Edition')
Med Bouchenafa
"Jean-Nicolas BERGER" <JeanNicolasBERGER@discussions.microsoft.com> wrote in
message news:96755660-2731-420F-AAA1-92F71670BA28@microsoft.com...
> Je ne peux bien évidemment pas faire un 'ORDER BY Mon_Index', mais un
> 'ORDER
> BY LesChampsDeMonIndex' n'arrange pas le problème, le plan d'exécution
> montre
> toujours un passage par les tables sous-jacentes.
>
> Mytère, quand tu nous tiens...
> JN.
>
> "Philippe TROTIN [MS]" wrote:
>
>> Bonjour,
>>
>> Et si vous faites un SELECT TOP 10 * FROM ma_vue ORDER BY Mon_Index ?
>>
>> Cordialement
>> _______________________________
>>
>> Philippe TROTIN
>> Microsoft Services France
>> _______________________________
>>
>> "Jean-Nicolas BERGER" <JeanNicolasBERGER@discussions.microsoft.com> a
>> écrit
>> dans le message de groupe de discussion :
>> 7E432C9D-2820-4BCD-9C11-1B86B3030000@microsoft.com...
>> > Bonjour,
>> > Le comportement est inchangé lorsque je met à jour les statistiques ou
>> > encore lorsque je vide le cache;
>> > Pour info, si je lance le SELECT avec WITH (NOEXPAND), il y a bien
>> > utilisation de l'index.
>> > Et en lancant dans un même lot un SELECT avec WITH (NOEXPAND) et un
>> > SELECT
>> > avec OPTION (EXPAND VIEWS), j'obtiens une répartition du temps
>> > d'exécution
>> > de
>> > la forme 5% / 95%.
>> > Et sans option, l'optimiseur choisi la version la plus lente... :-(
>> > Merci d'avance pour votre aide.
>> > Cordialement.
>> > JN BERGER
>> >
>> > "Philippe TROTIN [MS]" wrote:
>> >
>> >> Bonjour,
>> >>
>> >> Avez vous fait une mise à jour des stats (UPDATE STATISTICS), vidé le
>> >> cache
>> >> (DBCC FREEPROCACHE), ...
>> >>
>> >> Cordialement
>> >> _______________________________
>> >>
>> >> Philippe TROTIN
>> >> Microsoft Services France
>> >> _______________________________
>> >>
>> >> "Jean-Nicolas BERGER" <JeanNicolasBERGER@discussions.microsoft.com> a
>> >> écrit
>> >> dans le message de groupe de discussion :
>> >> 7AF8B005-CB2A-4C03-BBE4-ACF4987A5939@microsoft.com...
>> >> > Bonjour,
>> >> > j'ai un souci sous SQL 2005 Enterprise SP2.
>> >> > J'ai créé une vue (avec Schemabinding et tout ce qui va bien), puis
>> >> > j'ai
>> >> > créé un Index Unique Clustered sur cette vue.
>> >> > Tout s'est jusque là bien passé.
>> >> > le problème, c'est que lorsque je fais un select top 10 * from
>> >> > ma_vue,
>> >> > le
>> >> > plan d'exécution montre que le moteur de données refait les
>> >> > jointures
>> >> > avec
>> >> > les tables sous-jacentes, au lieu d'utiliser l'index créé.
>> >> > Quelqu'un aurait-il une piste?
>> >> > Merci.
>> >> > JN
>> >>
>> >>
>>
En fait le comportement est celui d'une edition Standard alors qu'il s'agit
d'une edition Enterprise
Je lancerais a toutes fins utiles
SELECT SERVERPROPERTY ('Edition')
Med Bouchenafa
"Jean-Nicolas BERGER" wrote in
message news:
> Je ne peux bien évidemment pas faire un 'ORDER BY Mon_Index', mais un
> 'ORDER
> BY LesChampsDeMonIndex' n'arrange pas le problème, le plan d'exécution
> montre
> toujours un passage par les tables sous-jacentes.
>
> Mytère, quand tu nous tiens...
> JN.
>
> "Philippe TROTIN [MS]" wrote:
>
>> Bonjour,
>>
>> Et si vous faites un SELECT TOP 10 * FROM ma_vue ORDER BY Mon_Index ?
>>
>> Cordialement
>> _______________________________
>>
>> Philippe TROTIN
>> Microsoft Services France
>> _______________________________
>>
>> "Jean-Nicolas BERGER" a
>> écrit
>> dans le message de groupe de discussion :
>>
>> > Bonjour,
>> > Le comportement est inchangé lorsque je met à jour les statistiques ou
>> > encore lorsque je vide le cache;
>> > Pour info, si je lance le SELECT avec WITH (NOEXPAND), il y a bien
>> > utilisation de l'index.
>> > Et en lancant dans un même lot un SELECT avec WITH (NOEXPAND) et un
>> > SELECT
>> > avec OPTION (EXPAND VIEWS), j'obtiens une répartition du temps
>> > d'exécution
>> > de
>> > la forme 5% / 95%.
>> > Et sans option, l'optimiseur choisi la version la plus lente... :-(
>> > Merci d'avance pour votre aide.
>> > Cordialement.
>> > JN BERGER
>> >
>> > "Philippe TROTIN [MS]" wrote:
>> >
>> >> Bonjour,
>> >>
>> >> Avez vous fait une mise à jour des stats (UPDATE STATISTICS), vidé le
>> >> cache
>> >> (DBCC FREEPROCACHE), ...
>> >>
>> >> Cordialement
>> >> _______________________________
>> >>
>> >> Philippe TROTIN
>> >> Microsoft Services France
>> >> _______________________________
>> >>
>> >> "Jean-Nicolas BERGER" a
>> >> écrit
>> >> dans le message de groupe de discussion :
>> >>
>> >> > Bonjour,
>> >> > j'ai un souci sous SQL 2005 Enterprise SP2.
>> >> > J'ai créé une vue (avec Schemabinding et tout ce qui va bien), puis
>> >> > j'ai
>> >> > créé un Index Unique Clustered sur cette vue.
>> >> > Tout s'est jusque là bien passé.
>> >> > le problème, c'est que lorsque je fais un select top 10 * from
>> >> > ma_vue,
>> >> > le
>> >> > plan d'exécution montre que le moteur de données refait les
>> >> > jointures
>> >> > avec
>> >> > les tables sous-jacentes, au lieu d'utiliser l'index créé.
>> >> > Quelqu'un aurait-il une piste?
>> >> > Merci.
>> >> > JN
>> >>
>> >>
>>
Je ne peux bien évidemment pas faire un 'ORDER BY Mon_Index', mais un
'ORDER
BY LesChampsDeMonIndex' n'arrange pas le problème, le plan d'exécution
montre
toujours un passage par les tables sous-jacentes.
Mytère, quand tu nous tiens...
JN.
"Philippe TROTIN [MS]" wrote:Bonjour,
Et si vous faites un SELECT TOP 10 * FROM ma_vue ORDER BY Mon_Index ?
Cordialement
_______________________________
Philippe TROTIN
Microsoft Services France
_______________________________
"Jean-Nicolas BERGER" a
écrit
dans le message de groupe de discussion :
> Bonjour,
> Le comportement est inchangé lorsque je met à jour les statistiques ou
> encore lorsque je vide le cache;
> Pour info, si je lance le SELECT avec WITH (NOEXPAND), il y a bien
> utilisation de l'index.
> Et en lancant dans un même lot un SELECT avec WITH (NOEXPAND) et un
> SELECT
> avec OPTION (EXPAND VIEWS), j'obtiens une répartition du temps
> d'exécution
> de
> la forme 5% / 95%.
> Et sans option, l'optimiseur choisi la version la plus lente... :-(
> Merci d'avance pour votre aide.
> Cordialement.
> JN BERGER
>
> "Philippe TROTIN [MS]" wrote:
>
>> Bonjour,
>>
>> Avez vous fait une mise à jour des stats (UPDATE STATISTICS), vidé le
>> cache
>> (DBCC FREEPROCACHE), ...
>>
>> Cordialement
>> _______________________________
>>
>> Philippe TROTIN
>> Microsoft Services France
>> _______________________________
>>
>> "Jean-Nicolas BERGER" a
>> écrit
>> dans le message de groupe de discussion :
>>
>> > Bonjour,
>> > j'ai un souci sous SQL 2005 Enterprise SP2.
>> > J'ai créé une vue (avec Schemabinding et tout ce qui va bien), puis
>> > j'ai
>> > créé un Index Unique Clustered sur cette vue.
>> > Tout s'est jusque là bien passé.
>> > le problème, c'est que lorsque je fais un select top 10 * from
>> > ma_vue,
>> > le
>> > plan d'exécution montre que le moteur de données refait les
>> > jointures
>> > avec
>> > les tables sous-jacentes, au lieu d'utiliser l'index créé.
>> > Quelqu'un aurait-il une piste?
>> > Merci.
>> > JN
>>
>>
Je ne peux bien évidemment pas faire un 'ORDER BY Mon_Index', mais un
'ORDER
BY LesChampsDeMonIndex' n'arrange pas le problème, le plan d'exécution
montre
toujours un passage par les tables sous-jacentes.
Mytère, quand tu nous tiens...
JN.
"Philippe TROTIN [MS]" wrote:
Bonjour,
Et si vous faites un SELECT TOP 10 * FROM ma_vue ORDER BY Mon_Index ?
Cordialement
_______________________________
Philippe TROTIN
Microsoft Services France
_______________________________
"Jean-Nicolas BERGER" <JeanNicolasBERGER@discussions.microsoft.com> a
écrit
dans le message de groupe de discussion :
7E432C9D-2820-4BCD-9C11-1B86B3030000@microsoft.com...
> Bonjour,
> Le comportement est inchangé lorsque je met à jour les statistiques ou
> encore lorsque je vide le cache;
> Pour info, si je lance le SELECT avec WITH (NOEXPAND), il y a bien
> utilisation de l'index.
> Et en lancant dans un même lot un SELECT avec WITH (NOEXPAND) et un
> SELECT
> avec OPTION (EXPAND VIEWS), j'obtiens une répartition du temps
> d'exécution
> de
> la forme 5% / 95%.
> Et sans option, l'optimiseur choisi la version la plus lente... :-(
> Merci d'avance pour votre aide.
> Cordialement.
> JN BERGER
>
> "Philippe TROTIN [MS]" wrote:
>
>> Bonjour,
>>
>> Avez vous fait une mise à jour des stats (UPDATE STATISTICS), vidé le
>> cache
>> (DBCC FREEPROCACHE), ...
>>
>> Cordialement
>> _______________________________
>>
>> Philippe TROTIN
>> Microsoft Services France
>> _______________________________
>>
>> "Jean-Nicolas BERGER" <JeanNicolasBERGER@discussions.microsoft.com> a
>> écrit
>> dans le message de groupe de discussion :
>> 7AF8B005-CB2A-4C03-BBE4-ACF4987A5939@microsoft.com...
>> > Bonjour,
>> > j'ai un souci sous SQL 2005 Enterprise SP2.
>> > J'ai créé une vue (avec Schemabinding et tout ce qui va bien), puis
>> > j'ai
>> > créé un Index Unique Clustered sur cette vue.
>> > Tout s'est jusque là bien passé.
>> > le problème, c'est que lorsque je fais un select top 10 * from
>> > ma_vue,
>> > le
>> > plan d'exécution montre que le moteur de données refait les
>> > jointures
>> > avec
>> > les tables sous-jacentes, au lieu d'utiliser l'index créé.
>> > Quelqu'un aurait-il une piste?
>> > Merci.
>> > JN
>>
>>
Je ne peux bien évidemment pas faire un 'ORDER BY Mon_Index', mais un
'ORDER
BY LesChampsDeMonIndex' n'arrange pas le problème, le plan d'exécution
montre
toujours un passage par les tables sous-jacentes.
Mytère, quand tu nous tiens...
JN.
"Philippe TROTIN [MS]" wrote:Bonjour,
Et si vous faites un SELECT TOP 10 * FROM ma_vue ORDER BY Mon_Index ?
Cordialement
_______________________________
Philippe TROTIN
Microsoft Services France
_______________________________
"Jean-Nicolas BERGER" a
écrit
dans le message de groupe de discussion :
> Bonjour,
> Le comportement est inchangé lorsque je met à jour les statistiques ou
> encore lorsque je vide le cache;
> Pour info, si je lance le SELECT avec WITH (NOEXPAND), il y a bien
> utilisation de l'index.
> Et en lancant dans un même lot un SELECT avec WITH (NOEXPAND) et un
> SELECT
> avec OPTION (EXPAND VIEWS), j'obtiens une répartition du temps
> d'exécution
> de
> la forme 5% / 95%.
> Et sans option, l'optimiseur choisi la version la plus lente... :-(
> Merci d'avance pour votre aide.
> Cordialement.
> JN BERGER
>
> "Philippe TROTIN [MS]" wrote:
>
>> Bonjour,
>>
>> Avez vous fait une mise à jour des stats (UPDATE STATISTICS), vidé le
>> cache
>> (DBCC FREEPROCACHE), ...
>>
>> Cordialement
>> _______________________________
>>
>> Philippe TROTIN
>> Microsoft Services France
>> _______________________________
>>
>> "Jean-Nicolas BERGER" a
>> écrit
>> dans le message de groupe de discussion :
>>
>> > Bonjour,
>> > j'ai un souci sous SQL 2005 Enterprise SP2.
>> > J'ai créé une vue (avec Schemabinding et tout ce qui va bien), puis
>> > j'ai
>> > créé un Index Unique Clustered sur cette vue.
>> > Tout s'est jusque là bien passé.
>> > le problème, c'est que lorsque je fais un select top 10 * from
>> > ma_vue,
>> > le
>> > plan d'exécution montre que le moteur de données refait les
>> > jointures
>> > avec
>> > les tables sous-jacentes, au lieu d'utiliser l'index créé.
>> > Quelqu'un aurait-il une piste?
>> > Merci.
>> > JN
>>
>>