fts - contains - premiere recherche lente - les autres rapides
3 réponses
OLAPFOREVER
fulltext search
-----------------
J'ai une table avec 1,500,000 nom et prenom
J'utilise un énoncé contains sur le nom
select ... from table1 where contains( nom,'abc')
la premiere recherche prends 45 secs
toutes les suivantes prennent en dessous de 1 secs (sur le meme ou
d'autres noms )
une heure plus tard le probleme reviens ( 1er 45 secs ... les autres 1 sec)
je test 1,000,000 recherche avec des noms différents ( pour valider si le
probleme en est un de caching) .. la premiere recherche prend 45 secs et le
999,999 autres 1 sec
sur mon poste local ... tout roule en dessous de 1 sec
Peter Yang de microsoft pense que cest un probleme lié a la memoire et au
caching .. mais il ne m'a pas convaincu ... 45 secs cest un peu trop long
pour du caching ...
j'ose espérer que l'engin SQL charge en cache les pages de la premiere
recherche en non l'index au complet ... dans ce cas ce serait une erreur
majeure pour la performance ...
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
Julien Bonnier
Ton poste en local... c'est le poste ou SQL Server est installé ?
Si oui, le probleme surviens a partir de n'importe quel autre poste ? Et si tel est le cas, est-ce que c'est 45 sec pour la premiere requete partant de chaque poste ou 45 sec pour la premiere requete tout court.
Je m'explique, si un poste 1 fait une requete (45 sec) et que un poste 2 fait une autre requete, cette requete sera efectuer en 1 ou 45 sec(s)?
Si c'est 45 secs pour la premiere de chaque postes et que le serveur est sur ton poste en local, peut-etre est-ce le temps que met l'ordinateur client à trouver le serveur sur le réseau... ?
Pense à ca.
Cordialement, Julien
"OLAPFOREVER" wrote in message news:
fulltext search ----------------- J'ai une table avec 1,500,000 nom et prenom J'utilise un énoncé contains sur le nom select ... from table1 where contains( nom,'abc')
la premiere recherche prends 45 secs
toutes les suivantes prennent en dessous de 1 secs (sur le meme ou d'autres noms )
une heure plus tard le probleme reviens ( 1er 45 secs ... les autres 1 sec)
je test 1,000,000 recherche avec des noms différents ( pour valider si le probleme en est un de caching) .. la premiere recherche prend 45 secs et le 999,999 autres 1 sec
sur mon poste local ... tout roule en dessous de 1 sec
Peter Yang de microsoft pense que cest un probleme lié a la memoire et au caching .. mais il ne m'a pas convaincu ... 45 secs cest un peu trop long pour du caching ...
j'ose espérer que l'engin SQL charge en cache les pages de la premiere recherche en non l'index au complet ... dans ce cas ce serait une erreur majeure pour la performance ...
pouvez-vous m'aider
Ton poste en local... c'est le poste ou SQL Server est installé ?
Si oui, le probleme surviens a partir de n'importe quel autre poste ?
Et si tel est le cas, est-ce que c'est 45 sec pour la premiere requete
partant de chaque poste ou 45 sec pour la premiere requete tout court.
Je m'explique, si un poste 1 fait une requete (45 sec) et que un poste 2
fait une autre requete, cette requete sera efectuer en 1 ou 45 sec(s)?
Si c'est 45 secs pour la premiere de chaque postes et que le serveur est sur
ton poste en local, peut-etre est-ce le temps que met l'ordinateur client à
trouver le serveur sur le réseau... ?
Pense à ca.
Cordialement,
Julien
"OLAPFOREVER" <OLAPFOREVER@discussions.microsoft.com> wrote in message
news:62147F69-56A6-4241-995E-4DE6EBCEC804@microsoft.com...
fulltext search
-----------------
J'ai une table avec 1,500,000 nom et prenom
J'utilise un énoncé contains sur le nom
select ... from table1 where contains( nom,'abc')
la premiere recherche prends 45 secs
toutes les suivantes prennent en dessous de 1 secs (sur le meme ou
d'autres noms )
une heure plus tard le probleme reviens ( 1er 45 secs ... les autres 1
sec)
je test 1,000,000 recherche avec des noms différents ( pour valider si le
probleme en est un de caching) .. la premiere recherche prend 45 secs et
le
999,999 autres 1 sec
sur mon poste local ... tout roule en dessous de 1 sec
Peter Yang de microsoft pense que cest un probleme lié a la memoire et au
caching .. mais il ne m'a pas convaincu ... 45 secs cest un peu trop long
pour du caching ...
j'ose espérer que l'engin SQL charge en cache les pages de la premiere
recherche en non l'index au complet ... dans ce cas ce serait une erreur
majeure pour la performance ...
Ton poste en local... c'est le poste ou SQL Server est installé ?
Si oui, le probleme surviens a partir de n'importe quel autre poste ? Et si tel est le cas, est-ce que c'est 45 sec pour la premiere requete partant de chaque poste ou 45 sec pour la premiere requete tout court.
Je m'explique, si un poste 1 fait une requete (45 sec) et que un poste 2 fait une autre requete, cette requete sera efectuer en 1 ou 45 sec(s)?
Si c'est 45 secs pour la premiere de chaque postes et que le serveur est sur ton poste en local, peut-etre est-ce le temps que met l'ordinateur client à trouver le serveur sur le réseau... ?
Pense à ca.
Cordialement, Julien
"OLAPFOREVER" wrote in message news:
fulltext search ----------------- J'ai une table avec 1,500,000 nom et prenom J'utilise un énoncé contains sur le nom select ... from table1 where contains( nom,'abc')
la premiere recherche prends 45 secs
toutes les suivantes prennent en dessous de 1 secs (sur le meme ou d'autres noms )
une heure plus tard le probleme reviens ( 1er 45 secs ... les autres 1 sec)
je test 1,000,000 recherche avec des noms différents ( pour valider si le probleme en est un de caching) .. la premiere recherche prend 45 secs et le 999,999 autres 1 sec
sur mon poste local ... tout roule en dessous de 1 sec
Peter Yang de microsoft pense que cest un probleme lié a la memoire et au caching .. mais il ne m'a pas convaincu ... 45 secs cest un peu trop long pour du caching ...
j'ose espérer que l'engin SQL charge en cache les pages de la premiere recherche en non l'index au complet ... dans ce cas ce serait une erreur majeure pour la performance ...
pouvez-vous m'aider
OLAPFOREVER
aucun autre poste n'accede a mon poste local .....
les tests se font sur le serveur SQL corporatif
j'ai testé en local car j'ai une copie conforme sur mon poste de la bd corpo
en local j'ai SQL devl edition et sur le serveur j'ai sql standard edition
les tests se font dans Management studio de sql 2005 dans tous les cas ... donc le DNS n'intervient plus à ce moment
"Julien Bonnier" wrote:
Ton poste en local... c'est le poste ou SQL Server est installé ?
Si oui, le probleme surviens a partir de n'importe quel autre poste ? Et si tel est le cas, est-ce que c'est 45 sec pour la premiere requete partant de chaque poste ou 45 sec pour la premiere requete tout court.
Je m'explique, si un poste 1 fait une requete (45 sec) et que un poste 2 fait une autre requete, cette requete sera efectuer en 1 ou 45 sec(s)?
Si c'est 45 secs pour la premiere de chaque postes et que le serveur est sur ton poste en local, peut-etre est-ce le temps que met l'ordinateur client à trouver le serveur sur le réseau... ?
Pense à ca.
Cordialement, Julien
"OLAPFOREVER" wrote in message news: > fulltext search > ----------------- > J'ai une table avec 1,500,000 nom et prenom > J'utilise un énoncé contains sur le nom > select ... from table1 where contains( nom,'abc') > > la premiere recherche prends 45 secs > > toutes les suivantes prennent en dessous de 1 secs (sur le meme ou > d'autres noms ) > > une heure plus tard le probleme reviens ( 1er 45 secs ... les autres 1 > sec) > > je test 1,000,000 recherche avec des noms différents ( pour valider si le > probleme en est un de caching) .. la premiere recherche prend 45 secs et > le > 999,999 autres 1 sec > > > sur mon poste local ... tout roule en dessous de 1 sec > > Peter Yang de microsoft pense que cest un probleme lié a la memoire et au > caching .. mais il ne m'a pas convaincu ... 45 secs cest un peu trop long > pour du caching ... > > j'ose espérer que l'engin SQL charge en cache les pages de la premiere > recherche en non l'index au complet ... dans ce cas ce serait une erreur > majeure pour la performance ... > > pouvez-vous m'aider
aucun autre poste n'accede a mon poste local .....
les tests se font sur le serveur SQL corporatif
j'ai testé en local car j'ai une copie conforme sur mon poste de la bd corpo
en local j'ai SQL devl edition et sur le serveur j'ai sql standard edition
les tests se font dans Management studio de sql 2005 dans tous les cas ...
donc le DNS n'intervient plus à ce moment
"Julien Bonnier" wrote:
Ton poste en local... c'est le poste ou SQL Server est installé ?
Si oui, le probleme surviens a partir de n'importe quel autre poste ?
Et si tel est le cas, est-ce que c'est 45 sec pour la premiere requete
partant de chaque poste ou 45 sec pour la premiere requete tout court.
Je m'explique, si un poste 1 fait une requete (45 sec) et que un poste 2
fait une autre requete, cette requete sera efectuer en 1 ou 45 sec(s)?
Si c'est 45 secs pour la premiere de chaque postes et que le serveur est sur
ton poste en local, peut-etre est-ce le temps que met l'ordinateur client à
trouver le serveur sur le réseau... ?
Pense à ca.
Cordialement,
Julien
"OLAPFOREVER" <OLAPFOREVER@discussions.microsoft.com> wrote in message
news:62147F69-56A6-4241-995E-4DE6EBCEC804@microsoft.com...
> fulltext search
> -----------------
> J'ai une table avec 1,500,000 nom et prenom
> J'utilise un énoncé contains sur le nom
> select ... from table1 where contains( nom,'abc')
>
> la premiere recherche prends 45 secs
>
> toutes les suivantes prennent en dessous de 1 secs (sur le meme ou
> d'autres noms )
>
> une heure plus tard le probleme reviens ( 1er 45 secs ... les autres 1
> sec)
>
> je test 1,000,000 recherche avec des noms différents ( pour valider si le
> probleme en est un de caching) .. la premiere recherche prend 45 secs et
> le
> 999,999 autres 1 sec
>
>
> sur mon poste local ... tout roule en dessous de 1 sec
>
> Peter Yang de microsoft pense que cest un probleme lié a la memoire et au
> caching .. mais il ne m'a pas convaincu ... 45 secs cest un peu trop long
> pour du caching ...
>
> j'ose espérer que l'engin SQL charge en cache les pages de la premiere
> recherche en non l'index au complet ... dans ce cas ce serait une erreur
> majeure pour la performance ...
>
> pouvez-vous m'aider
aucun autre poste n'accede a mon poste local .....
les tests se font sur le serveur SQL corporatif
j'ai testé en local car j'ai une copie conforme sur mon poste de la bd corpo
en local j'ai SQL devl edition et sur le serveur j'ai sql standard edition
les tests se font dans Management studio de sql 2005 dans tous les cas ... donc le DNS n'intervient plus à ce moment
"Julien Bonnier" wrote:
Ton poste en local... c'est le poste ou SQL Server est installé ?
Si oui, le probleme surviens a partir de n'importe quel autre poste ? Et si tel est le cas, est-ce que c'est 45 sec pour la premiere requete partant de chaque poste ou 45 sec pour la premiere requete tout court.
Je m'explique, si un poste 1 fait une requete (45 sec) et que un poste 2 fait une autre requete, cette requete sera efectuer en 1 ou 45 sec(s)?
Si c'est 45 secs pour la premiere de chaque postes et que le serveur est sur ton poste en local, peut-etre est-ce le temps que met l'ordinateur client à trouver le serveur sur le réseau... ?
Pense à ca.
Cordialement, Julien
"OLAPFOREVER" wrote in message news: > fulltext search > ----------------- > J'ai une table avec 1,500,000 nom et prenom > J'utilise un énoncé contains sur le nom > select ... from table1 where contains( nom,'abc') > > la premiere recherche prends 45 secs > > toutes les suivantes prennent en dessous de 1 secs (sur le meme ou > d'autres noms ) > > une heure plus tard le probleme reviens ( 1er 45 secs ... les autres 1 > sec) > > je test 1,000,000 recherche avec des noms différents ( pour valider si le > probleme en est un de caching) .. la premiere recherche prend 45 secs et > le > 999,999 autres 1 sec > > > sur mon poste local ... tout roule en dessous de 1 sec > > Peter Yang de microsoft pense que cest un probleme lié a la memoire et au > caching .. mais il ne m'a pas convaincu ... 45 secs cest un peu trop long > pour du caching ... > > j'ose espérer que l'engin SQL charge en cache les pages de la premiere > recherche en non l'index au complet ... dans ce cas ce serait une erreur > majeure pour la performance ... > > pouvez-vous m'aider
Fred BROUARD
OLAPFOREVER a écrit :
fulltext search ----------------- J'ai une table avec 1,500,000 nom et prenom J'utilise un énoncé contains sur le nom select ... from table1 where contains( nom,'abc')
la premiere recherche prends 45 secs
toutes les suivantes prennent en dessous de 1 secs (sur le meme ou d'autres noms )
une heure plus tard le probleme reviens ( 1er 45 secs ... les autres 1 sec)
je test 1,000,000 recherche avec des noms différents ( pour valider si le probleme en est un de caching) .. la premiere recherche prend 45 secs et le 999,999 autres 1 sec
sur mon poste local ... tout roule en dessous de 1 sec
Peter Yang de microsoft pense que cest un probleme lié a la memoire et au caching .. mais il ne m'a pas convaincu ... 45 secs cest un peu trop long pour du caching ...
A l'évidence problème de cache. En effet l'algorithme LRU va décharger le catalogue d'indexation s'il a besoin de cache pour d'autres données. Or lorsque vous ne faites plus de requêtes CONTAINS, le cache contenant le catalogue FT vieillit et se trouve donc fortement candidat à dégager du cache.
Auditez les compteurs cache hit ration et target server memory.
j'ose espérer que l'engin SQL charge en cache les pages de la premiere recherche en non l'index au complet ... dans ce cas ce serait une erreur majeure pour la performance ...
pouvez-vous m'aider
A +
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
OLAPFOREVER a écrit :
fulltext search
-----------------
J'ai une table avec 1,500,000 nom et prenom
J'utilise un énoncé contains sur le nom
select ... from table1 where contains( nom,'abc')
la premiere recherche prends 45 secs
toutes les suivantes prennent en dessous de 1 secs (sur le meme ou
d'autres noms )
une heure plus tard le probleme reviens ( 1er 45 secs ... les autres 1 sec)
je test 1,000,000 recherche avec des noms différents ( pour valider si le
probleme en est un de caching) .. la premiere recherche prend 45 secs et le
999,999 autres 1 sec
sur mon poste local ... tout roule en dessous de 1 sec
Peter Yang de microsoft pense que cest un probleme lié a la memoire et au
caching .. mais il ne m'a pas convaincu ... 45 secs cest un peu trop long
pour du caching ...
A l'évidence problème de cache. En effet l'algorithme LRU va décharger
le catalogue d'indexation s'il a besoin de cache pour d'autres données.
Or lorsque vous ne faites plus de requêtes CONTAINS, le cache contenant
le catalogue FT vieillit et se trouve donc fortement candidat à dégager
du cache.
Auditez les compteurs cache hit ration et target server memory.
j'ose espérer que l'engin SQL charge en cache les pages de la premiere
recherche en non l'index au complet ... dans ce cas ce serait une erreur
majeure pour la performance ...
pouvez-vous m'aider
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
fulltext search ----------------- J'ai une table avec 1,500,000 nom et prenom J'utilise un énoncé contains sur le nom select ... from table1 where contains( nom,'abc')
la premiere recherche prends 45 secs
toutes les suivantes prennent en dessous de 1 secs (sur le meme ou d'autres noms )
une heure plus tard le probleme reviens ( 1er 45 secs ... les autres 1 sec)
je test 1,000,000 recherche avec des noms différents ( pour valider si le probleme en est un de caching) .. la premiere recherche prend 45 secs et le 999,999 autres 1 sec
sur mon poste local ... tout roule en dessous de 1 sec
Peter Yang de microsoft pense que cest un probleme lié a la memoire et au caching .. mais il ne m'a pas convaincu ... 45 secs cest un peu trop long pour du caching ...
A l'évidence problème de cache. En effet l'algorithme LRU va décharger le catalogue d'indexation s'il a besoin de cache pour d'autres données. Or lorsque vous ne faites plus de requêtes CONTAINS, le cache contenant le catalogue FT vieillit et se trouve donc fortement candidat à dégager du cache.
Auditez les compteurs cache hit ration et target server memory.
j'ose espérer que l'engin SQL charge en cache les pages de la premiere recherche en non l'index au complet ... dans ce cas ce serait une erreur majeure pour la performance ...
pouvez-vous m'aider
A +
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
