Je rencontre de gros problèmes de perf sur ma base sql 2000.
Ces pb viennent surement de tables mal indexés !
Existe t il une liste de synthétique ( en français de préférence )
de choses à savoir en matière d'index afin que je puisse rapidement
faire un état des lieux et modifier ou supprimer des indexes !
Même chose pour l'optimisation de mes requêtes, y a t il une liste
de trucs à savoir au niveau plan d'éxécution pour rapidement se rendre compte
des pb de lenteurs et y remédier. Parceque sorti des table scan et des index
seek
ca me parle pas trop le plan d'éxécution !
Donc en résumer y aurait il un petit site, ou petit doc pour me dépanner !!
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
Med Bouchenafa
C'est comme toute chose, cela parait compliqué lorsque on ne sait pas Dans SQL Server 2000, tu as un outil qui peut t'aider à indexer tes tables en fonction de tes requetes Tu ouvres l'Analyseur de requêtes, Tu tapes ta requête et tu la selectionnes tu tapes CTRL+I Cela lance l'assistant Index tuning qui va te suggerer l'indexage correspondant à ta requête
Il ya aussi pas mal de ressources sur le web pour t'aider dans ta démarche
-- Bien cordialement Med Bouchenafa
"JO" a écrit dans le message de news:
Bonjour à tous,
Je rencontre de gros problèmes de perf sur ma base sql 2000. Ces pb viennent surement de tables mal indexés !
Existe t il une liste de synthétique ( en français de préférence ) de choses à savoir en matière d'index afin que je puisse rapidement faire un état des lieux et modifier ou supprimer des indexes !
Même chose pour l'optimisation de mes requêtes, y a t il une liste de trucs à savoir au niveau plan d'éxécution pour rapidement se rendre compte des pb de lenteurs et y remédier. Parceque sorti des table scan et des index seek ca me parle pas trop le plan d'éxécution !
Donc en résumer y aurait il un petit site, ou petit doc pour me dépanner !!
Merci par avance pour vos réponses
jonathan
C'est comme toute chose, cela parait compliqué lorsque on ne sait pas
Dans SQL Server 2000, tu as un outil qui peut t'aider à indexer tes tables
en fonction de tes requetes
Tu ouvres l'Analyseur de requêtes,
Tu tapes ta requête et tu la selectionnes
tu tapes CTRL+I
Cela lance l'assistant Index tuning qui va te suggerer l'indexage
correspondant à ta requête
Il ya aussi pas mal de ressources sur le web pour t'aider dans ta démarche
--
Bien cordialement
Med Bouchenafa
"JO" <JO@discussions.microsoft.com> a écrit dans le message de news:
999D9C19-AE95-4741-ACD7-D96676B0B2D3@microsoft.com...
Bonjour à tous,
Je rencontre de gros problèmes de perf sur ma base sql 2000.
Ces pb viennent surement de tables mal indexés !
Existe t il une liste de synthétique ( en français de préférence )
de choses à savoir en matière d'index afin que je puisse rapidement
faire un état des lieux et modifier ou supprimer des indexes !
Même chose pour l'optimisation de mes requêtes, y a t il une liste
de trucs à savoir au niveau plan d'éxécution pour rapidement se rendre
compte
des pb de lenteurs et y remédier. Parceque sorti des table scan et des
index
seek
ca me parle pas trop le plan d'éxécution !
Donc en résumer y aurait il un petit site, ou petit doc pour me dépanner
!!
C'est comme toute chose, cela parait compliqué lorsque on ne sait pas Dans SQL Server 2000, tu as un outil qui peut t'aider à indexer tes tables en fonction de tes requetes Tu ouvres l'Analyseur de requêtes, Tu tapes ta requête et tu la selectionnes tu tapes CTRL+I Cela lance l'assistant Index tuning qui va te suggerer l'indexage correspondant à ta requête
Il ya aussi pas mal de ressources sur le web pour t'aider dans ta démarche
-- Bien cordialement Med Bouchenafa
"JO" a écrit dans le message de news:
Bonjour à tous,
Je rencontre de gros problèmes de perf sur ma base sql 2000. Ces pb viennent surement de tables mal indexés !
Existe t il une liste de synthétique ( en français de préférence ) de choses à savoir en matière d'index afin que je puisse rapidement faire un état des lieux et modifier ou supprimer des indexes !
Même chose pour l'optimisation de mes requêtes, y a t il une liste de trucs à savoir au niveau plan d'éxécution pour rapidement se rendre compte des pb de lenteurs et y remédier. Parceque sorti des table scan et des index seek ca me parle pas trop le plan d'éxécution !
Donc en résumer y aurait il un petit site, ou petit doc pour me dépanner !!
Merci par avance pour vos réponses
jonathan
Fred BROUARD
Bonjour,
l'optimisation n'est pas quelque chose de simple et fait appel à de multiples problématique : - architecture de la base - OS et réseau - serveur - configuration du SGBDR - écriture du code (requêtes, procédures, fonctions, code client) - indexation ...
Pour une première vision globale de la chose, lisez l'article que j'ai écrit à ce sujet : http://sqlpro.developpez.com/cours/optimiser/
Dans SQL Server, vous disposez en outre des outils suivants : - SQL Profiler : pour monitorer le code qui est envoyé au serveur - plan de requête : pour comprendre et tester différentes solution - statistiques (IO notamment) pour mesurer l'impact.
Je ne suis pas un fan da l'assitant d'indexation car il a tendance a proposer de TOUT indexer. En effet trop d'index tue l'index.
Dans les audits que je pratique, les plus gros gains de performances sont les suivants : 1) modèle de données 60% 2) style d'écriture de l'application 20% 3) indexation 10% ...
A +
JO a écrit:
Bonjour à tous,
Je rencontre de gros problèmes de perf sur ma base sql 2000. Ces pb viennent surement de tables mal indexés !
Existe t il une liste de synthétique ( en français de préférence ) de choses à savoir en matière d'index afin que je puisse rapidement faire un état des lieux et modifier ou supprimer des indexes !
Même chose pour l'optimisation de mes requêtes, y a t il une liste de trucs à savoir au niveau plan d'éxécution pour rapidement se rendre compte des pb de lenteurs et y remédier. Parceque sorti des table scan et des index seek ca me parle pas trop le plan d'éxécution !
Donc en résumer y aurait il un petit site, ou petit doc pour me dépanner !!
Merci par avance pour vos réponses
jonathan
-- 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 ***********************
Bonjour,
l'optimisation n'est pas quelque chose de simple et fait appel à de multiples
problématique :
- architecture de la base
- OS et réseau
- serveur
- configuration du SGBDR
- écriture du code (requêtes, procédures, fonctions, code client)
- indexation
...
Pour une première vision globale de la chose, lisez l'article que j'ai écrit à
ce sujet :
http://sqlpro.developpez.com/cours/optimiser/
Dans SQL Server, vous disposez en outre des outils suivants :
- SQL Profiler : pour monitorer le code qui est envoyé au serveur
- plan de requête : pour comprendre et tester différentes solution
- statistiques (IO notamment) pour mesurer l'impact.
Je ne suis pas un fan da l'assitant d'indexation car il a tendance a proposer de
TOUT indexer.
En effet trop d'index tue l'index.
Dans les audits que je pratique, les plus gros gains de performances sont les
suivants :
1) modèle de données 60%
2) style d'écriture de l'application 20%
3) indexation 10%
...
A +
JO a écrit:
Bonjour à tous,
Je rencontre de gros problèmes de perf sur ma base sql 2000.
Ces pb viennent surement de tables mal indexés !
Existe t il une liste de synthétique ( en français de préférence )
de choses à savoir en matière d'index afin que je puisse rapidement
faire un état des lieux et modifier ou supprimer des indexes !
Même chose pour l'optimisation de mes requêtes, y a t il une liste
de trucs à savoir au niveau plan d'éxécution pour rapidement se rendre compte
des pb de lenteurs et y remédier. Parceque sorti des table scan et des index
seek
ca me parle pas trop le plan d'éxécution !
Donc en résumer y aurait il un petit site, ou petit doc pour me dépanner !!
Merci par avance pour vos réponses
jonathan
--
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 ***********************
l'optimisation n'est pas quelque chose de simple et fait appel à de multiples problématique : - architecture de la base - OS et réseau - serveur - configuration du SGBDR - écriture du code (requêtes, procédures, fonctions, code client) - indexation ...
Pour une première vision globale de la chose, lisez l'article que j'ai écrit à ce sujet : http://sqlpro.developpez.com/cours/optimiser/
Dans SQL Server, vous disposez en outre des outils suivants : - SQL Profiler : pour monitorer le code qui est envoyé au serveur - plan de requête : pour comprendre et tester différentes solution - statistiques (IO notamment) pour mesurer l'impact.
Je ne suis pas un fan da l'assitant d'indexation car il a tendance a proposer de TOUT indexer. En effet trop d'index tue l'index.
Dans les audits que je pratique, les plus gros gains de performances sont les suivants : 1) modèle de données 60% 2) style d'écriture de l'application 20% 3) indexation 10% ...
A +
JO a écrit:
Bonjour à tous,
Je rencontre de gros problèmes de perf sur ma base sql 2000. Ces pb viennent surement de tables mal indexés !
Existe t il une liste de synthétique ( en français de préférence ) de choses à savoir en matière d'index afin que je puisse rapidement faire un état des lieux et modifier ou supprimer des indexes !
Même chose pour l'optimisation de mes requêtes, y a t il une liste de trucs à savoir au niveau plan d'éxécution pour rapidement se rendre compte des pb de lenteurs et y remédier. Parceque sorti des table scan et des index seek ca me parle pas trop le plan d'éxécution !
Donc en résumer y aurait il un petit site, ou petit doc pour me dépanner !!
Merci par avance pour vos réponses
jonathan
-- 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 ***********************
GNocent
Je ne suis pas d'accord avec l'expression "trop d'index tue l'index", qui pour moi, n'est pas une généralité (même si évidemment "trop d'index" peut avoir des conséquences désastreuses si l'on ne sait pas ce que l'on fait). Tout dépend en effet du type d'activité sur la table en question ... une table très peu modifiée et/ou où les temps d'insert/delete/update ne sont pas du tout critiques, alors que les select sont mutlicritères avec de la volumétrie et des temps d'exécution sensibles aura forcément tendance a être fortement indexée. Come toujours l'indexation est affaire de cas par cas ...
D'ailleurs sous SQLServer 2005 il est possible de savoir quels indexes ne sont pas utilisés si l'on souhaite faire de ménage suite à une indexation sauvage à la mode "j'en mets partout au cas où" : http://blogs.msdn.com/sqlcat/archive/2005/12/12/502735.aspx
Quant aux statistiques sur les axes d'optimisation possibles, même s'il est évident qu'un remaniement du modèle de données est forcément l'option la plus efficace et la plus intelligente, il n'en reste pas moins qu'elle est souvent peu réaliste sur un projet sensible et/ou qui a déjà un peu vécu : cela est très couteux (en temps) car cela peut remettre en cause en profondeur le fonctionnement d'une application. Bref, la réalité applicative, même si c'est intellectuellement moins élégant, nous mène souvent à un mix de petites retouches du modèle associé surtout à une revue de l'indexation et/ou de l'écriture de certaines requêtes. Si une application a été un minimum bien pensée en terme de modèle, les problèmes de performances seront souvent localisés à quelques requêtes ou quelques indexations de tables (souvent on a la règle du 80% des lenteurs proviennent de 20% du code, si ça n'est pas du 95/5), et une indexatino plus adaptée ou une réécriture de quelques requêtes peut souvent mener à des gains de perfs assez conséquents voire à une diminution très sensible de la charge de la machine.
C'est en tout cas ce que j'ai pu observer sur les projets sur lesquels j'ai pu travailler, l'avis d'autres DBA est le bienvenu !
Guillaume.
============================ "Fred BROUARD" a écrit :
Bonjour,
l'optimisation n'est pas quelque chose de simple et fait appel à de multiples problématique : - architecture de la base - OS et réseau - serveur - configuration du SGBDR - écriture du code (requêtes, procédures, fonctions, code client) - indexation ....
Pour une première vision globale de la chose, lisez l'article que j'ai écrit à ce sujet : http://sqlpro.developpez.com/cours/optimiser/
Dans SQL Server, vous disposez en outre des outils suivants : - SQL Profiler : pour monitorer le code qui est envoyé au serveur - plan de requête : pour comprendre et tester différentes solution - statistiques (IO notamment) pour mesurer l'impact.
Je ne suis pas un fan da l'assitant d'indexation car il a tendance a proposer de TOUT indexer. En effet trop d'index tue l'index.
Dans les audits que je pratique, les plus gros gains de performances sont les suivants : 1) modèle de données 60% 2) style d'écriture de l'application 20% 3) indexation 10% ....
A +
JO a écrit: > Bonjour à tous, > > Je rencontre de gros problèmes de perf sur ma base sql 2000. > Ces pb viennent surement de tables mal indexés ! > > Existe t il une liste de synthétique ( en français de préférence ) > de choses à savoir en matière d'index afin que je puisse rapidement > faire un état des lieux et modifier ou supprimer des indexes ! > > Même chose pour l'optimisation de mes requêtes, y a t il une liste > de trucs à savoir au niveau plan d'éxécution pour rapidement se rendre compte > des pb de lenteurs et y remédier. Parceque sorti des table scan et des index > seek > ca me parle pas trop le plan d'éxécution ! > > Donc en résumer y aurait il un petit site, ou petit doc pour me dépanner !! > > Merci par avance pour vos réponses > > jonathan > >
-- 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 ***********************
Je ne suis pas d'accord avec l'expression "trop d'index tue l'index", qui
pour moi, n'est pas une généralité (même si évidemment "trop d'index" peut
avoir des conséquences désastreuses si l'on ne sait pas ce que l'on fait).
Tout dépend en effet du type d'activité sur la table en question ... une
table très peu modifiée et/ou où les temps d'insert/delete/update ne sont pas
du tout critiques, alors que les select sont mutlicritères avec de la
volumétrie et des temps d'exécution sensibles aura forcément tendance a être
fortement indexée.
Come toujours l'indexation est affaire de cas par cas ...
D'ailleurs sous SQLServer 2005 il est possible de savoir quels indexes ne
sont pas utilisés si l'on souhaite faire de ménage suite à une indexation
sauvage à la mode "j'en mets partout au cas où" :
http://blogs.msdn.com/sqlcat/archive/2005/12/12/502735.aspx
Quant aux statistiques sur les axes d'optimisation possibles, même s'il est
évident qu'un remaniement du modèle de données est forcément l'option la plus
efficace et la plus intelligente, il n'en reste pas moins qu'elle est souvent
peu réaliste sur un projet sensible et/ou qui a déjà un peu vécu : cela est
très couteux (en temps) car cela peut remettre en cause en profondeur le
fonctionnement d'une application.
Bref, la réalité applicative, même si c'est intellectuellement moins
élégant, nous mène souvent à un mix de petites retouches du modèle associé
surtout à une revue de l'indexation et/ou de l'écriture de certaines
requêtes. Si une application a été un minimum bien pensée en terme de modèle,
les problèmes de performances seront souvent localisés à quelques requêtes ou
quelques indexations de tables (souvent on a la règle du 80% des lenteurs
proviennent de 20% du code, si ça n'est pas du 95/5), et une indexatino plus
adaptée ou une réécriture de quelques requêtes peut souvent mener à des gains
de perfs assez conséquents voire à une diminution très sensible de la charge
de la machine.
C'est en tout cas ce que j'ai pu observer sur les projets sur lesquels j'ai
pu travailler, l'avis d'autres DBA est le bienvenu !
Guillaume.
============================
"Fred BROUARD" a écrit :
Bonjour,
l'optimisation n'est pas quelque chose de simple et fait appel à de multiples
problématique :
- architecture de la base
- OS et réseau
- serveur
- configuration du SGBDR
- écriture du code (requêtes, procédures, fonctions, code client)
- indexation
....
Pour une première vision globale de la chose, lisez l'article que j'ai écrit à
ce sujet :
http://sqlpro.developpez.com/cours/optimiser/
Dans SQL Server, vous disposez en outre des outils suivants :
- SQL Profiler : pour monitorer le code qui est envoyé au serveur
- plan de requête : pour comprendre et tester différentes solution
- statistiques (IO notamment) pour mesurer l'impact.
Je ne suis pas un fan da l'assitant d'indexation car il a tendance a proposer de
TOUT indexer.
En effet trop d'index tue l'index.
Dans les audits que je pratique, les plus gros gains de performances sont les
suivants :
1) modèle de données 60%
2) style d'écriture de l'application 20%
3) indexation 10%
....
A +
JO a écrit:
> Bonjour à tous,
>
> Je rencontre de gros problèmes de perf sur ma base sql 2000.
> Ces pb viennent surement de tables mal indexés !
>
> Existe t il une liste de synthétique ( en français de préférence )
> de choses à savoir en matière d'index afin que je puisse rapidement
> faire un état des lieux et modifier ou supprimer des indexes !
>
> Même chose pour l'optimisation de mes requêtes, y a t il une liste
> de trucs à savoir au niveau plan d'éxécution pour rapidement se rendre compte
> des pb de lenteurs et y remédier. Parceque sorti des table scan et des index
> seek
> ca me parle pas trop le plan d'éxécution !
>
> Donc en résumer y aurait il un petit site, ou petit doc pour me dépanner !!
>
> Merci par avance pour vos réponses
>
> jonathan
>
>
--
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 ***********************
Je ne suis pas d'accord avec l'expression "trop d'index tue l'index", qui pour moi, n'est pas une généralité (même si évidemment "trop d'index" peut avoir des conséquences désastreuses si l'on ne sait pas ce que l'on fait). Tout dépend en effet du type d'activité sur la table en question ... une table très peu modifiée et/ou où les temps d'insert/delete/update ne sont pas du tout critiques, alors que les select sont mutlicritères avec de la volumétrie et des temps d'exécution sensibles aura forcément tendance a être fortement indexée. Come toujours l'indexation est affaire de cas par cas ...
D'ailleurs sous SQLServer 2005 il est possible de savoir quels indexes ne sont pas utilisés si l'on souhaite faire de ménage suite à une indexation sauvage à la mode "j'en mets partout au cas où" : http://blogs.msdn.com/sqlcat/archive/2005/12/12/502735.aspx
Quant aux statistiques sur les axes d'optimisation possibles, même s'il est évident qu'un remaniement du modèle de données est forcément l'option la plus efficace et la plus intelligente, il n'en reste pas moins qu'elle est souvent peu réaliste sur un projet sensible et/ou qui a déjà un peu vécu : cela est très couteux (en temps) car cela peut remettre en cause en profondeur le fonctionnement d'une application. Bref, la réalité applicative, même si c'est intellectuellement moins élégant, nous mène souvent à un mix de petites retouches du modèle associé surtout à une revue de l'indexation et/ou de l'écriture de certaines requêtes. Si une application a été un minimum bien pensée en terme de modèle, les problèmes de performances seront souvent localisés à quelques requêtes ou quelques indexations de tables (souvent on a la règle du 80% des lenteurs proviennent de 20% du code, si ça n'est pas du 95/5), et une indexatino plus adaptée ou une réécriture de quelques requêtes peut souvent mener à des gains de perfs assez conséquents voire à une diminution très sensible de la charge de la machine.
C'est en tout cas ce que j'ai pu observer sur les projets sur lesquels j'ai pu travailler, l'avis d'autres DBA est le bienvenu !
Guillaume.
============================ "Fred BROUARD" a écrit :
Bonjour,
l'optimisation n'est pas quelque chose de simple et fait appel à de multiples problématique : - architecture de la base - OS et réseau - serveur - configuration du SGBDR - écriture du code (requêtes, procédures, fonctions, code client) - indexation ....
Pour une première vision globale de la chose, lisez l'article que j'ai écrit à ce sujet : http://sqlpro.developpez.com/cours/optimiser/
Dans SQL Server, vous disposez en outre des outils suivants : - SQL Profiler : pour monitorer le code qui est envoyé au serveur - plan de requête : pour comprendre et tester différentes solution - statistiques (IO notamment) pour mesurer l'impact.
Je ne suis pas un fan da l'assitant d'indexation car il a tendance a proposer de TOUT indexer. En effet trop d'index tue l'index.
Dans les audits que je pratique, les plus gros gains de performances sont les suivants : 1) modèle de données 60% 2) style d'écriture de l'application 20% 3) indexation 10% ....
A +
JO a écrit: > Bonjour à tous, > > Je rencontre de gros problèmes de perf sur ma base sql 2000. > Ces pb viennent surement de tables mal indexés ! > > Existe t il une liste de synthétique ( en français de préférence ) > de choses à savoir en matière d'index afin que je puisse rapidement > faire un état des lieux et modifier ou supprimer des indexes ! > > Même chose pour l'optimisation de mes requêtes, y a t il une liste > de trucs à savoir au niveau plan d'éxécution pour rapidement se rendre compte > des pb de lenteurs et y remédier. Parceque sorti des table scan et des index > seek > ca me parle pas trop le plan d'éxécution ! > > Donc en résumer y aurait il un petit site, ou petit doc pour me dépanner !! > > Merci par avance pour vos réponses > > jonathan > >
-- 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 ***********************
