j'ai un gros soucis sur ma base de production principale , j'ai une vue
compos=E9e de 5 autres vues jointes entres elle en LEFT OUTER JOIN.
cette vue me retourne habituellement les 7.000 articles de ma base de
production en 1 secondes, hors depuis 5/6 jours elle met plus de 60
secondes !
Or, la base article =E9tant l'ossature de notre reporting/etat, ce
probl=E8me devient critique.
j'ai effectu=E9 des DBCC CHECKDB / CHECKTABLE /REINDEX / INDEXDEFRAG
.=2Ej'ai d=E9fragment=E9 les index, pas d'am=E9lioration, j'ai donc recr=E9=
=E9
les index..pas mieux !
Lorsque j'enleve n'importe laquelle d'une des 5 sous vues composant ma
vue principale les performances sont de nouveaux au rendez vous...mais
bin sur cette solution est tr=E8s insatisfesante.
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
Arnaud CLERET
Cela ressemble beaucoup à des statistiques pas à jour. L'option "mise à jour automatique des statistiques" est-elle bien activée ?
Sinon que vous donne le plan d'exécution de votre requête ?
-- arno - http://www.dotnetguru2.org/acleret/
"Thomas larcher" a écrit dans le message de news:
Bonjour à tous,
j'ai un gros soucis sur ma base de production principale , j'ai une vue composée de 5 autres vues jointes entres elle en LEFT OUTER JOIN.
cette vue me retourne habituellement les 7.000 articles de ma base de production en 1 secondes, hors depuis 5/6 jours elle met plus de 60 secondes ! Or, la base article étant l'ossature de notre reporting/etat, ce problème devient critique.
j'ai effectué des DBCC CHECKDB / CHECKTABLE /REINDEX / INDEXDEFRAG ..j'ai défragmenté les index, pas d'amélioration, j'ai donc recréé les index..pas mieux !
Lorsque j'enleve n'importe laquelle d'une des 5 sous vues composant ma vue principale les performances sont de nouveaux au rendez vous...mais bin sur cette solution est très insatisfesante.
Quelqu'un pourrait m'aider sur ce probleme ?
merci,
Cordialement,
Thomas Larcher
Cela ressemble beaucoup à des statistiques pas à jour. L'option "mise à jour
automatique des statistiques" est-elle bien activée ?
Sinon que vous donne le plan d'exécution de votre requête ?
--
arno - http://www.dotnetguru2.org/acleret/
"Thomas larcher" <larchert@hotmail.com> a écrit dans le message de news:
1144224201.480270.17690@t31g2000cwb.googlegroups.com...
Bonjour à tous,
j'ai un gros soucis sur ma base de production principale , j'ai une vue
composée de 5 autres vues jointes entres elle en LEFT OUTER JOIN.
cette vue me retourne habituellement les 7.000 articles de ma base de
production en 1 secondes, hors depuis 5/6 jours elle met plus de 60
secondes !
Or, la base article étant l'ossature de notre reporting/etat, ce
problème devient critique.
j'ai effectué des DBCC CHECKDB / CHECKTABLE /REINDEX / INDEXDEFRAG
..j'ai défragmenté les index, pas d'amélioration, j'ai donc recréé
les index..pas mieux !
Lorsque j'enleve n'importe laquelle d'une des 5 sous vues composant ma
vue principale les performances sont de nouveaux au rendez vous...mais
bin sur cette solution est très insatisfesante.
Cela ressemble beaucoup à des statistiques pas à jour. L'option "mise à jour automatique des statistiques" est-elle bien activée ?
Sinon que vous donne le plan d'exécution de votre requête ?
-- arno - http://www.dotnetguru2.org/acleret/
"Thomas larcher" a écrit dans le message de news:
Bonjour à tous,
j'ai un gros soucis sur ma base de production principale , j'ai une vue composée de 5 autres vues jointes entres elle en LEFT OUTER JOIN.
cette vue me retourne habituellement les 7.000 articles de ma base de production en 1 secondes, hors depuis 5/6 jours elle met plus de 60 secondes ! Or, la base article étant l'ossature de notre reporting/etat, ce problème devient critique.
j'ai effectué des DBCC CHECKDB / CHECKTABLE /REINDEX / INDEXDEFRAG ..j'ai défragmenté les index, pas d'amélioration, j'ai donc recréé les index..pas mieux !
Lorsque j'enleve n'importe laquelle d'une des 5 sous vues composant ma vue principale les performances sont de nouveaux au rendez vous...mais bin sur cette solution est très insatisfesante.
Quelqu'un pourrait m'aider sur ce probleme ?
merci,
Cordialement,
Thomas Larcher
Thomas larcher
Bonjour, les statistiques sont bien activées. j'ai un peu avancé, j'ai localisé l'INDEX qui me causait probleme : c'est l'INDEX CLUSTERED de la table (sur le champs CODE ARTICLE)
Dès que je le passe en NON-CLUSTERED, les performances sont de retour.. Mais je ne comprend pas pourquoi, et j'ai souhaiterai le maintenir en clustered
Une idée ?
merci
Bonjour,
les statistiques sont bien activées.
j'ai un peu avancé, j'ai localisé l'INDEX qui me causait probleme :
c'est l'INDEX CLUSTERED de la table (sur le champs CODE ARTICLE)
Dès que je le passe en NON-CLUSTERED, les performances sont de
retour..
Mais je ne comprend pas pourquoi, et j'ai souhaiterai le maintenir en
clustered
Bonjour, les statistiques sont bien activées. j'ai un peu avancé, j'ai localisé l'INDEX qui me causait probleme : c'est l'INDEX CLUSTERED de la table (sur le champs CODE ARTICLE)
Dès que je le passe en NON-CLUSTERED, les performances sont de retour.. Mais je ne comprend pas pourquoi, et j'ai souhaiterai le maintenir en clustered
Une idée ?
merci
bruno reiter
c'est sans doute un problème avec les non-clustered, ceux-ci doivent utiliser le clustered (quand il existe) pour accéder aux données. La clé du clustered n'est elle pas trop longue?
br
"Thomas larcher" a écrit dans le message de news:
Bonjour, les statistiques sont bien activées. j'ai un peu avancé, j'ai localisé l'INDEX qui me causait probleme : c'est l'INDEX CLUSTERED de la table (sur le champs CODE ARTICLE)
Dès que je le passe en NON-CLUSTERED, les performances sont de retour.. Mais je ne comprend pas pourquoi, et j'ai souhaiterai le maintenir en clustered
Une idée ?
merci
c'est sans doute un problème avec les non-clustered, ceux-ci doivent
utiliser le clustered (quand il existe) pour accéder aux données. La clé du
clustered n'est elle pas trop longue?
br
"Thomas larcher" <larchert@hotmail.com> a écrit dans le message de news:
1144394288.911508.79860@j33g2000cwa.googlegroups.com...
Bonjour,
les statistiques sont bien activées.
j'ai un peu avancé, j'ai localisé l'INDEX qui me causait probleme :
c'est l'INDEX CLUSTERED de la table (sur le champs CODE ARTICLE)
Dès que je le passe en NON-CLUSTERED, les performances sont de
retour..
Mais je ne comprend pas pourquoi, et j'ai souhaiterai le maintenir en
clustered
c'est sans doute un problème avec les non-clustered, ceux-ci doivent utiliser le clustered (quand il existe) pour accéder aux données. La clé du clustered n'est elle pas trop longue?
br
"Thomas larcher" a écrit dans le message de news:
Bonjour, les statistiques sont bien activées. j'ai un peu avancé, j'ai localisé l'INDEX qui me causait probleme : c'est l'INDEX CLUSTERED de la table (sur le champs CODE ARTICLE)
Dès que je le passe en NON-CLUSTERED, les performances sont de retour.. Mais je ne comprend pas pourquoi, et j'ai souhaiterai le maintenir en clustered
Une idée ?
merci
Arnaud CLERET
Avez vous essayé de défragmenter vos indexes afin d'accéler les recherches ? Si ne n'est pas le cas vous pouvez utiliser la commande : DBCC INDEXDEFRAG
-- arno - http://www.dotnetguru2.org/acleret/
"Thomas larcher" a écrit dans le message de news:
Bonjour, les statistiques sont bien activées. j'ai un peu avancé, j'ai localisé l'INDEX qui me causait probleme : c'est l'INDEX CLUSTERED de la table (sur le champs CODE ARTICLE)
Dès que je le passe en NON-CLUSTERED, les performances sont de retour.. Mais je ne comprend pas pourquoi, et j'ai souhaiterai le maintenir en clustered
Une idée ?
merci
Avez vous essayé de défragmenter vos indexes afin d'accéler les recherches ?
Si ne n'est pas le cas vous pouvez utiliser la commande : DBCC INDEXDEFRAG
--
arno - http://www.dotnetguru2.org/acleret/
"Thomas larcher" <larchert@hotmail.com> a écrit dans le message de news:
1144394288.911508.79860@j33g2000cwa.googlegroups.com...
Bonjour,
les statistiques sont bien activées.
j'ai un peu avancé, j'ai localisé l'INDEX qui me causait probleme :
c'est l'INDEX CLUSTERED de la table (sur le champs CODE ARTICLE)
Dès que je le passe en NON-CLUSTERED, les performances sont de
retour..
Mais je ne comprend pas pourquoi, et j'ai souhaiterai le maintenir en
clustered
Avez vous essayé de défragmenter vos indexes afin d'accéler les recherches ? Si ne n'est pas le cas vous pouvez utiliser la commande : DBCC INDEXDEFRAG
-- arno - http://www.dotnetguru2.org/acleret/
"Thomas larcher" a écrit dans le message de news:
Bonjour, les statistiques sont bien activées. j'ai un peu avancé, j'ai localisé l'INDEX qui me causait probleme : c'est l'INDEX CLUSTERED de la table (sur le champs CODE ARTICLE)
Dès que je le passe en NON-CLUSTERED, les performances sont de retour.. Mais je ne comprend pas pourquoi, et j'ai souhaiterai le maintenir en clustered
Une idée ?
merci
SQLpro [MVP]
Thomas larcher a écrit :
Bonjour, les statistiques sont bien activées. j'ai un peu avancé, j'ai localisé l'INDEX qui me causait probleme : c'est l'INDEX CLUSTERED de la table (sur le champs CODE ARTICLE)
Dès que je le passe en NON-CLUSTERED, les performances sont de retour.. Mais je ne comprend pas pourquoi, et j'ai souhaiterai le maintenir en clustered
L'index CLUSTERED ne donne toute satisfaction que si : 1) l'index est composé d'une seule colonne 2) les données de l'index sont monotone à l'insertion (croissance) 3) les données de l'index ne changent jamais 4) les données des colonnes de taille variable ne changent JAMAIS (pas d'update)
En d'autre terme le cluster est parfait pour une clef de type auto incrément et des données qui ne sont jamais mise à jour pour les colonnes de taille variable.
En dehors de cela et particulièrement si la clef est alphanumérique, le cluster peut s'avérer particulièrement contre performant.
A +
Une idée ?
merci
-- 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 ***********************
Thomas larcher a écrit :
Bonjour,
les statistiques sont bien activées.
j'ai un peu avancé, j'ai localisé l'INDEX qui me causait probleme :
c'est l'INDEX CLUSTERED de la table (sur le champs CODE ARTICLE)
Dès que je le passe en NON-CLUSTERED, les performances sont de
retour..
Mais je ne comprend pas pourquoi, et j'ai souhaiterai le maintenir en
clustered
L'index CLUSTERED ne donne toute satisfaction que si :
1) l'index est composé d'une seule colonne
2) les données de l'index sont monotone à l'insertion (croissance)
3) les données de l'index ne changent jamais
4) les données des colonnes de taille variable ne changent JAMAIS (pas
d'update)
En d'autre terme le cluster est parfait pour une clef de type auto
incrément et des données qui ne sont jamais mise à jour pour les
colonnes de taille variable.
En dehors de cela et particulièrement si la clef est alphanumérique, le
cluster peut s'avérer particulièrement contre performant.
A +
Une idée ?
merci
--
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, les statistiques sont bien activées. j'ai un peu avancé, j'ai localisé l'INDEX qui me causait probleme : c'est l'INDEX CLUSTERED de la table (sur le champs CODE ARTICLE)
Dès que je le passe en NON-CLUSTERED, les performances sont de retour.. Mais je ne comprend pas pourquoi, et j'ai souhaiterai le maintenir en clustered
L'index CLUSTERED ne donne toute satisfaction que si : 1) l'index est composé d'une seule colonne 2) les données de l'index sont monotone à l'insertion (croissance) 3) les données de l'index ne changent jamais 4) les données des colonnes de taille variable ne changent JAMAIS (pas d'update)
En d'autre terme le cluster est parfait pour une clef de type auto incrément et des données qui ne sont jamais mise à jour pour les colonnes de taille variable.
En dehors de cela et particulièrement si la clef est alphanumérique, le cluster peut s'avérer particulièrement contre performant.
A +
Une idée ?
merci
-- 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 ***********************
Thomas larcher
Merci pour vos informations
mon index est clustered sur un varchar de 15, qui ne change jamais (insertion/suppression uniquement pas d'update sur ce champs)
mes performances deviennent exécrables - c'est peu dire - : 1 minute spour ramener quelques centaines de ligne dès que je fais une requete sur cette table via des vues, si j'attaque la table en direct aucun probleme, dès que je rajoute 2/3 autres tabels ca part en cacahouete (alors qu'avant AUCUN probleme)
et je n'ai plus d'index clustered , je ne comprend absolument pas, je suis très inquiet
J'ai copié mes tables d'exmeple dans une autre base : le probleme se reproduit (donc ce n'est pas un probleme hardware) (j'ai déjà régénéré mes index, defragmenter, recalculer les statistiques, vérifier la cohérence de la base ...)
j'ai quelque chose dans cette table qui me pourrit tout et je ne comprend tjs pas
Merci pour vos informations
mon index est clustered sur un varchar de 15, qui ne change jamais
(insertion/suppression uniquement pas d'update sur ce champs)
mes performances deviennent exécrables - c'est peu dire - : 1 minute
spour ramener quelques centaines de ligne dès que je fais une requete
sur cette table via des vues, si j'attaque la table en direct aucun
probleme, dès que je rajoute 2/3 autres tabels ca part en cacahouete
(alors qu'avant AUCUN probleme)
et je n'ai plus d'index clustered , je ne comprend absolument pas, je
suis très inquiet
J'ai copié mes tables d'exmeple dans une autre base : le probleme se
reproduit (donc ce n'est pas un probleme hardware)
(j'ai déjà régénéré mes index, defragmenter, recalculer les
statistiques, vérifier la cohérence de la base ...)
j'ai quelque chose dans cette table qui me pourrit tout et je ne
comprend tjs pas
mon index est clustered sur un varchar de 15, qui ne change jamais (insertion/suppression uniquement pas d'update sur ce champs)
mes performances deviennent exécrables - c'est peu dire - : 1 minute spour ramener quelques centaines de ligne dès que je fais une requete sur cette table via des vues, si j'attaque la table en direct aucun probleme, dès que je rajoute 2/3 autres tabels ca part en cacahouete (alors qu'avant AUCUN probleme)
et je n'ai plus d'index clustered , je ne comprend absolument pas, je suis très inquiet
J'ai copié mes tables d'exmeple dans une autre base : le probleme se reproduit (donc ce n'est pas un probleme hardware) (j'ai déjà régénéré mes index, defragmenter, recalculer les statistiques, vérifier la cohérence de la base ...)
j'ai quelque chose dans cette table qui me pourrit tout et je ne comprend tjs pas
