Bonjour,
J'ai un GROS souci sur un lot de procédures stockées, dont les
performances
fluctuent énormément dans le temps et provoquent des timeouts bloquants
pour
les utilisateurs. A l'analyse du code, il sembleraient qu'elles accèdent à
des tables assez volumineuses (certaines ont des dizaines de millions de
lignes) par le biais d'index dont les clés ne sont pas en cause.
Jusqu'il y a très peu, je recréais nocturnement tous les index de ma base
(300 tables de tailles diverses, index clustered pour les clés primaires),
afin de bénéficier de pointeurs frais et de chemins de parcours d'index
les
plus courts. Dans la foulée, histoire que tout le monde profite de cette
fraîcheur, je marquais à recompilation toutes les procédures dépendantes
de
toutes les tables de ma base.
Constatant que le premier utilisateur matinal de certaines de ces 20 p.s
se
prenait timeout sur timeout (le code a été vérifié et même réécrit pour
limiter les gabegies de ressources) avant de décrocher son téléphone pour
m'incendier, en dépit de ce que je pensais être un modèle d'optimisation.
J'ai donc fait appel à un consultant qui m'a conseillé de laisser faire
SQL2000 autant que possible, de désactiver la recréation automatique des
index (via mon plan de maintenance) et de coder un script qui le ferait en
utilisant DBCC et que je ferais tourner en hebdo, voir en bimensuel. Ceci
aurait pour effet d'éviter les recompilations en cascade de chaque
procédure
référencée, même si elle ne change pas. Dont acte, ça me paraissaît
logique,
sauf qu'une semaine plus tard, c'était toujours (au moins) pareil.
J'ai du mal à comprendre ce qui peut produire ces ralentissements ni le
côté
cyclique irrégulier du phénomène. La seule chose que je comprends, c'est
que
la base respecte les formes normales, les index ne sont pas faits en dépit
du
bon sens, que la machine est une bombe, que l'OS est censé la booster
encore
plus, que le code (et particulièrement les jointures) a été vérifié et que
les clients gueulent toujours, chose que je ne peux leur reprocher.
Toute (bonne) idée sera la bienvenue.
Jean-Yves AUGER
Bonjour,
J'ai un GROS souci sur un lot de procédures stockées, dont les
performances
fluctuent énormément dans le temps et provoquent des timeouts bloquants
pour
les utilisateurs. A l'analyse du code, il sembleraient qu'elles accèdent à
des tables assez volumineuses (certaines ont des dizaines de millions de
lignes) par le biais d'index dont les clés ne sont pas en cause.
Jusqu'il y a très peu, je recréais nocturnement tous les index de ma base
(300 tables de tailles diverses, index clustered pour les clés primaires),
afin de bénéficier de pointeurs frais et de chemins de parcours d'index
les
plus courts. Dans la foulée, histoire que tout le monde profite de cette
fraîcheur, je marquais à recompilation toutes les procédures dépendantes
de
toutes les tables de ma base.
Constatant que le premier utilisateur matinal de certaines de ces 20 p.s
se
prenait timeout sur timeout (le code a été vérifié et même réécrit pour
limiter les gabegies de ressources) avant de décrocher son téléphone pour
m'incendier, en dépit de ce que je pensais être un modèle d'optimisation.
J'ai donc fait appel à un consultant qui m'a conseillé de laisser faire
SQL2000 autant que possible, de désactiver la recréation automatique des
index (via mon plan de maintenance) et de coder un script qui le ferait en
utilisant DBCC et que je ferais tourner en hebdo, voir en bimensuel. Ceci
aurait pour effet d'éviter les recompilations en cascade de chaque
procédure
référencée, même si elle ne change pas. Dont acte, ça me paraissaît
logique,
sauf qu'une semaine plus tard, c'était toujours (au moins) pareil.
J'ai du mal à comprendre ce qui peut produire ces ralentissements ni le
côté
cyclique irrégulier du phénomène. La seule chose que je comprends, c'est
que
la base respecte les formes normales, les index ne sont pas faits en dépit
du
bon sens, que la machine est une bombe, que l'OS est censé la booster
encore
plus, que le code (et particulièrement les jointures) a été vérifié et que
les clients gueulent toujours, chose que je ne peux leur reprocher.
Toute (bonne) idée sera la bienvenue.
Jean-Yves AUGER
Bonjour,
J'ai un GROS souci sur un lot de procédures stockées, dont les
performances
fluctuent énormément dans le temps et provoquent des timeouts bloquants
pour
les utilisateurs. A l'analyse du code, il sembleraient qu'elles accèdent à
des tables assez volumineuses (certaines ont des dizaines de millions de
lignes) par le biais d'index dont les clés ne sont pas en cause.
Jusqu'il y a très peu, je recréais nocturnement tous les index de ma base
(300 tables de tailles diverses, index clustered pour les clés primaires),
afin de bénéficier de pointeurs frais et de chemins de parcours d'index
les
plus courts. Dans la foulée, histoire que tout le monde profite de cette
fraîcheur, je marquais à recompilation toutes les procédures dépendantes
de
toutes les tables de ma base.
Constatant que le premier utilisateur matinal de certaines de ces 20 p.s
se
prenait timeout sur timeout (le code a été vérifié et même réécrit pour
limiter les gabegies de ressources) avant de décrocher son téléphone pour
m'incendier, en dépit de ce que je pensais être un modèle d'optimisation.
J'ai donc fait appel à un consultant qui m'a conseillé de laisser faire
SQL2000 autant que possible, de désactiver la recréation automatique des
index (via mon plan de maintenance) et de coder un script qui le ferait en
utilisant DBCC et que je ferais tourner en hebdo, voir en bimensuel. Ceci
aurait pour effet d'éviter les recompilations en cascade de chaque
procédure
référencée, même si elle ne change pas. Dont acte, ça me paraissaît
logique,
sauf qu'une semaine plus tard, c'était toujours (au moins) pareil.
J'ai du mal à comprendre ce qui peut produire ces ralentissements ni le
côté
cyclique irrégulier du phénomène. La seule chose que je comprends, c'est
que
la base respecte les formes normales, les index ne sont pas faits en dépit
du
bon sens, que la machine est une bombe, que l'OS est censé la booster
encore
plus, que le code (et particulièrement les jointures) a été vérifié et que
les clients gueulent toujours, chose que je ne peux leur reprocher.
Toute (bonne) idée sera la bienvenue.
Jean-Yves AUGER
Bonjour,
J'ai un GROS souci sur un lot de procédures stockées, dont les
fluctuent énormément dans le temps et provoquent des timeouts bloquants
les utilisateurs. A l'analyse du code, il sembleraient qu'elles accèdent à
des tables assez volumineuses (certaines ont des dizaines de millions de
lignes) par le biais d'index dont les clés ne sont pas en cause.
Jusqu'il y a très peu, je recréais nocturnement tous les index de ma base
(300 tables de tailles diverses, index clustered pour les clés primaires),
afin de bénéficier de pointeurs frais et de chemins de parcours d'index
plus courts. Dans la foulée, histoire que tout le monde profite de cette
fraîcheur, je marquais à recompilation toutes les procédures dépendantes
toutes les tables de ma base.
Constatant que le premier utilisateur matinal de certaines de ces 20 p.s
prenait timeout sur timeout (le code a été vérifié et même réécrit pour
limiter les gabegies de ressources) avant de décrocher son téléphone pour
m'incendier, en dépit de ce que je pensais être un modèle d'optimisation.
J'ai donc fait appel à un consultant qui m'a conseillé de laisser faire
SQL2000 autant que possible, de désactiver la recréation automatique des
index (via mon plan de maintenance) et de coder un script qui le ferait en
utilisant DBCC et que je ferais tourner en hebdo, voir en bimensuel. Ceci
aurait pour effet d'éviter les recompilations en cascade de chaque
référencée, même si elle ne change pas. Dont acte, ça me paraissaît
sauf qu'une semaine plus tard, c'était toujours (au moins) pareil.
J'ai du mal à comprendre ce qui peut produire ces ralentissements ni le
cyclique irrégulier du phénomène. La seule chose que je comprends, c'est
la base respecte les formes normales, les index ne sont pas faits en dépit
bon sens, que la machine est une bombe, que l'OS est censé la booster
plus, que le code (et particulièrement les jointures) a été vérifié et que
les clients gueulent toujours, chose que je ne peux leur reprocher.
Toute (bonne) idée sera la bienvenue.
Jean-Yves AUGER
Bonjour,
J'ai un GROS souci sur un lot de procédures stockées, dont les
fluctuent énormément dans le temps et provoquent des timeouts bloquants
les utilisateurs. A l'analyse du code, il sembleraient qu'elles accèdent à
des tables assez volumineuses (certaines ont des dizaines de millions de
lignes) par le biais d'index dont les clés ne sont pas en cause.
Jusqu'il y a très peu, je recréais nocturnement tous les index de ma base
(300 tables de tailles diverses, index clustered pour les clés primaires),
afin de bénéficier de pointeurs frais et de chemins de parcours d'index
plus courts. Dans la foulée, histoire que tout le monde profite de cette
fraîcheur, je marquais à recompilation toutes les procédures dépendantes
toutes les tables de ma base.
Constatant que le premier utilisateur matinal de certaines de ces 20 p.s
prenait timeout sur timeout (le code a été vérifié et même réécrit pour
limiter les gabegies de ressources) avant de décrocher son téléphone pour
m'incendier, en dépit de ce que je pensais être un modèle d'optimisation.
J'ai donc fait appel à un consultant qui m'a conseillé de laisser faire
SQL2000 autant que possible, de désactiver la recréation automatique des
index (via mon plan de maintenance) et de coder un script qui le ferait en
utilisant DBCC et que je ferais tourner en hebdo, voir en bimensuel. Ceci
aurait pour effet d'éviter les recompilations en cascade de chaque
référencée, même si elle ne change pas. Dont acte, ça me paraissaît
sauf qu'une semaine plus tard, c'était toujours (au moins) pareil.
J'ai du mal à comprendre ce qui peut produire ces ralentissements ni le
cyclique irrégulier du phénomène. La seule chose que je comprends, c'est
la base respecte les formes normales, les index ne sont pas faits en dépit
bon sens, que la machine est une bombe, que l'OS est censé la booster
plus, que le code (et particulièrement les jointures) a été vérifié et que
les clients gueulent toujours, chose que je ne peux leur reprocher.
Toute (bonne) idée sera la bienvenue.
Jean-Yves AUGER
Bonjour,
J'ai un GROS souci sur un lot de procédures stockées, dont les
fluctuent énormément dans le temps et provoquent des timeouts bloquants
les utilisateurs. A l'analyse du code, il sembleraient qu'elles accèdent à
des tables assez volumineuses (certaines ont des dizaines de millions de
lignes) par le biais d'index dont les clés ne sont pas en cause.
Jusqu'il y a très peu, je recréais nocturnement tous les index de ma base
(300 tables de tailles diverses, index clustered pour les clés primaires),
afin de bénéficier de pointeurs frais et de chemins de parcours d'index
plus courts. Dans la foulée, histoire que tout le monde profite de cette
fraîcheur, je marquais à recompilation toutes les procédures dépendantes
toutes les tables de ma base.
Constatant que le premier utilisateur matinal de certaines de ces 20 p.s
prenait timeout sur timeout (le code a été vérifié et même réécrit pour
limiter les gabegies de ressources) avant de décrocher son téléphone pour
m'incendier, en dépit de ce que je pensais être un modèle d'optimisation.
J'ai donc fait appel à un consultant qui m'a conseillé de laisser faire
SQL2000 autant que possible, de désactiver la recréation automatique des
index (via mon plan de maintenance) et de coder un script qui le ferait en
utilisant DBCC et que je ferais tourner en hebdo, voir en bimensuel. Ceci
aurait pour effet d'éviter les recompilations en cascade de chaque
référencée, même si elle ne change pas. Dont acte, ça me paraissaît
sauf qu'une semaine plus tard, c'était toujours (au moins) pareil.
J'ai du mal à comprendre ce qui peut produire ces ralentissements ni le
cyclique irrégulier du phénomène. La seule chose que je comprends, c'est
la base respecte les formes normales, les index ne sont pas faits en dépit
bon sens, que la machine est une bombe, que l'OS est censé la booster
plus, que le code (et particulièrement les jointures) a été vérifié et que
les clients gueulent toujours, chose que je ne peux leur reprocher.
Toute (bonne) idée sera la bienvenue.
Jean-Yves AUGER
Avoir une fenêtre de temps pour récréer les index de sa base est un luxe que
beaucoup d'applications ne peuvent pas se permettrent .
Autant s'estimer heureux donc. Quelques remarques cependant à la lecture de
ton message
a) Ce n'est pas forcément une bonne chose de choisir une clef primaire en
index cluster
Il est vrai que c'est l'option par défaut de SQL Server mais ce n'est pas
une raison pour la suivre à chaque fois
b) Le temps aléatoire d'exécution d'un SP ne peut s'expliquer par le temps
de compilation
Il est fort possible que le plan d'exécution compilé et sauvegardé pour une
procédure ne corresponde pas forcement à un autre jeu de paramètres de cette
même SP
Avoir une fenêtre de temps pour récréer les index de sa base est un luxe que
beaucoup d'applications ne peuvent pas se permettrent .
Autant s'estimer heureux donc. Quelques remarques cependant à la lecture de
ton message
a) Ce n'est pas forcément une bonne chose de choisir une clef primaire en
index cluster
Il est vrai que c'est l'option par défaut de SQL Server mais ce n'est pas
une raison pour la suivre à chaque fois
b) Le temps aléatoire d'exécution d'un SP ne peut s'expliquer par le temps
de compilation
Il est fort possible que le plan d'exécution compilé et sauvegardé pour une
procédure ne corresponde pas forcement à un autre jeu de paramètres de cette
même SP
Avoir une fenêtre de temps pour récréer les index de sa base est un luxe que
beaucoup d'applications ne peuvent pas se permettrent .
Autant s'estimer heureux donc. Quelques remarques cependant à la lecture de
ton message
a) Ce n'est pas forcément une bonne chose de choisir une clef primaire en
index cluster
Il est vrai que c'est l'option par défaut de SQL Server mais ce n'est pas
une raison pour la suivre à chaque fois
b) Le temps aléatoire d'exécution d'un SP ne peut s'expliquer par le temps
de compilation
Il est fort possible que le plan d'exécution compilé et sauvegardé pour une
procédure ne corresponde pas forcement à un autre jeu de paramètres de cette
même SP
Avoir une fenêtre de temps pour récréer les index de sa base est un luxe que
beaucoup d'applications ne peuvent pas se permettrent .
Autant s'estimer heureux donc. Quelques remarques cependant à la lecture de
ton message
a) Ce n'est pas forcément une bonne chose de choisir une clef primaire en
index cluster
Il est vrai que c'est l'option par défaut de SQL Server mais ce n'est pas
une raison pour la suivre à chaque fois
b) Le temps aléatoire d'exécution d'un SP ne peut s'expliquer par le temps
de compilation
Il est fort possible que le plan d'exécution compilé et sauvegardé pour une
procédure ne corresponde pas forcement à un autre jeu de paramètres de cette
même SP
--
Bien cordialement
Med Bouchenafa
"Jean-Yves" a écrit dans le message de
news:
> Bonjour,
>
> J'ai un GROS souci sur un lot de procédures stockées, dont les
> performances
> fluctuent énormément dans le temps et provoquent des timeouts bloquants
> pour
> les utilisateurs. A l'analyse du code, il sembleraient qu'elles accèdent à
> des tables assez volumineuses (certaines ont des dizaines de millions de
> lignes) par le biais d'index dont les clés ne sont pas en cause.
>
> Jusqu'il y a très peu, je recréais nocturnement tous les index de ma base
> (300 tables de tailles diverses, index clustered pour les clés primaires),
> afin de bénéficier de pointeurs frais et de chemins de parcours d'index
> les
> plus courts. Dans la foulée, histoire que tout le monde profite de cette
> fraîcheur, je marquais à recompilation toutes les procédures dépendantes
> de
> toutes les tables de ma base.
>
> Constatant que le premier utilisateur matinal de certaines de ces 20 p.s
> se
> prenait timeout sur timeout (le code a été vérifié et même réécrit pour
> limiter les gabegies de ressources) avant de décrocher son téléphone pour
> m'incendier, en dépit de ce que je pensais être un modèle d'optimisation.
> J'ai donc fait appel à un consultant qui m'a conseillé de laisser faire
> SQL2000 autant que possible, de désactiver la recréation automatique des
> index (via mon plan de maintenance) et de coder un script qui le ferait en
> utilisant DBCC et que je ferais tourner en hebdo, voir en bimensuel. Ceci
> aurait pour effet d'éviter les recompilations en cascade de chaque
> procédure
> référencée, même si elle ne change pas. Dont acte, ça me paraissaît
> logique,
> sauf qu'une semaine plus tard, c'était toujours (au moins) pareil.
>
> J'ai du mal à comprendre ce qui peut produire ces ralentissements ni le
> côté
> cyclique irrégulier du phénomène. La seule chose que je comprends, c'est
> que
> la base respecte les formes normales, les index ne sont pas faits en dépit
> du
> bon sens, que la machine est une bombe, que l'OS est censé la booster
> encore
> plus, que le code (et particulièrement les jointures) a été vérifié et que
> les clients gueulent toujours, chose que je ne peux leur reprocher.
>
> Toute (bonne) idée sera la bienvenue.
> Jean-Yves AUGER
Avoir une fenêtre de temps pour récréer les index de sa base est un luxe que
beaucoup d'applications ne peuvent pas se permettrent .
Autant s'estimer heureux donc. Quelques remarques cependant à la lecture de
ton message
a) Ce n'est pas forcément une bonne chose de choisir une clef primaire en
index cluster
Il est vrai que c'est l'option par défaut de SQL Server mais ce n'est pas
une raison pour la suivre à chaque fois
b) Le temps aléatoire d'exécution d'un SP ne peut s'expliquer par le temps
de compilation
Il est fort possible que le plan d'exécution compilé et sauvegardé pour une
procédure ne corresponde pas forcement à un autre jeu de paramètres de cette
même SP
--
Bien cordialement
Med Bouchenafa
"Jean-Yves" <JeanYves@discussions.microsoft.com> a écrit dans le message de
news: 18120A77-B888-4C63-8A0D-85B32BA9988B@microsoft.com...
> Bonjour,
>
> J'ai un GROS souci sur un lot de procédures stockées, dont les
> performances
> fluctuent énormément dans le temps et provoquent des timeouts bloquants
> pour
> les utilisateurs. A l'analyse du code, il sembleraient qu'elles accèdent à
> des tables assez volumineuses (certaines ont des dizaines de millions de
> lignes) par le biais d'index dont les clés ne sont pas en cause.
>
> Jusqu'il y a très peu, je recréais nocturnement tous les index de ma base
> (300 tables de tailles diverses, index clustered pour les clés primaires),
> afin de bénéficier de pointeurs frais et de chemins de parcours d'index
> les
> plus courts. Dans la foulée, histoire que tout le monde profite de cette
> fraîcheur, je marquais à recompilation toutes les procédures dépendantes
> de
> toutes les tables de ma base.
>
> Constatant que le premier utilisateur matinal de certaines de ces 20 p.s
> se
> prenait timeout sur timeout (le code a été vérifié et même réécrit pour
> limiter les gabegies de ressources) avant de décrocher son téléphone pour
> m'incendier, en dépit de ce que je pensais être un modèle d'optimisation.
> J'ai donc fait appel à un consultant qui m'a conseillé de laisser faire
> SQL2000 autant que possible, de désactiver la recréation automatique des
> index (via mon plan de maintenance) et de coder un script qui le ferait en
> utilisant DBCC et que je ferais tourner en hebdo, voir en bimensuel. Ceci
> aurait pour effet d'éviter les recompilations en cascade de chaque
> procédure
> référencée, même si elle ne change pas. Dont acte, ça me paraissaît
> logique,
> sauf qu'une semaine plus tard, c'était toujours (au moins) pareil.
>
> J'ai du mal à comprendre ce qui peut produire ces ralentissements ni le
> côté
> cyclique irrégulier du phénomène. La seule chose que je comprends, c'est
> que
> la base respecte les formes normales, les index ne sont pas faits en dépit
> du
> bon sens, que la machine est une bombe, que l'OS est censé la booster
> encore
> plus, que le code (et particulièrement les jointures) a été vérifié et que
> les clients gueulent toujours, chose que je ne peux leur reprocher.
>
> Toute (bonne) idée sera la bienvenue.
> Jean-Yves AUGER
Avoir une fenêtre de temps pour récréer les index de sa base est un luxe que
beaucoup d'applications ne peuvent pas se permettrent .
Autant s'estimer heureux donc. Quelques remarques cependant à la lecture de
ton message
a) Ce n'est pas forcément une bonne chose de choisir une clef primaire en
index cluster
Il est vrai que c'est l'option par défaut de SQL Server mais ce n'est pas
une raison pour la suivre à chaque fois
b) Le temps aléatoire d'exécution d'un SP ne peut s'expliquer par le temps
de compilation
Il est fort possible que le plan d'exécution compilé et sauvegardé pour une
procédure ne corresponde pas forcement à un autre jeu de paramètres de cette
même SP
--
Bien cordialement
Med Bouchenafa
"Jean-Yves" a écrit dans le message de
news:
> Bonjour,
>
> J'ai un GROS souci sur un lot de procédures stockées, dont les
> performances
> fluctuent énormément dans le temps et provoquent des timeouts bloquants
> pour
> les utilisateurs. A l'analyse du code, il sembleraient qu'elles accèdent à
> des tables assez volumineuses (certaines ont des dizaines de millions de
> lignes) par le biais d'index dont les clés ne sont pas en cause.
>
> Jusqu'il y a très peu, je recréais nocturnement tous les index de ma base
> (300 tables de tailles diverses, index clustered pour les clés primaires),
> afin de bénéficier de pointeurs frais et de chemins de parcours d'index
> les
> plus courts. Dans la foulée, histoire que tout le monde profite de cette
> fraîcheur, je marquais à recompilation toutes les procédures dépendantes
> de
> toutes les tables de ma base.
>
> Constatant que le premier utilisateur matinal de certaines de ces 20 p.s
> se
> prenait timeout sur timeout (le code a été vérifié et même réécrit pour
> limiter les gabegies de ressources) avant de décrocher son téléphone pour
> m'incendier, en dépit de ce que je pensais être un modèle d'optimisation.
> J'ai donc fait appel à un consultant qui m'a conseillé de laisser faire
> SQL2000 autant que possible, de désactiver la recréation automatique des
> index (via mon plan de maintenance) et de coder un script qui le ferait en
> utilisant DBCC et que je ferais tourner en hebdo, voir en bimensuel. Ceci
> aurait pour effet d'éviter les recompilations en cascade de chaque
> procédure
> référencée, même si elle ne change pas. Dont acte, ça me paraissaît
> logique,
> sauf qu'une semaine plus tard, c'était toujours (au moins) pareil.
>
> J'ai du mal à comprendre ce qui peut produire ces ralentissements ni le
> côté
> cyclique irrégulier du phénomène. La seule chose que je comprends, c'est
> que
> la base respecte les formes normales, les index ne sont pas faits en dépit
> du
> bon sens, que la machine est une bombe, que l'OS est censé la booster
> encore
> plus, que le code (et particulièrement les jointures) a été vérifié et que
> les clients gueulent toujours, chose que je ne peux leur reprocher.
>
> Toute (bonne) idée sera la bienvenue.
> Jean-Yves AUGER
La recompilation est sans doute une mauvaise idée.
La mise à jour des index la nuit si c'est possible est une bonne idée
rajouter un fillfactor peut etre une bonne idée si les tables sont modifiées
en journée
ajouter un NOLOCK pour les lectures peut etre une bonne idée aussi (ou
passer en read uncommited)
HTH
br
"Jean-Yves" wrote in message
news:
> Bonjour,
>
> J'ai un GROS souci sur un lot de procédures stockées, dont les
performances
> fluctuent énormément dans le temps et provoquent des timeouts bloquants
pour
> les utilisateurs. A l'analyse du code, il sembleraient qu'elles accèdent à
> des tables assez volumineuses (certaines ont des dizaines de millions de
> lignes) par le biais d'index dont les clés ne sont pas en cause.
>
> Jusqu'il y a très peu, je recréais nocturnement tous les index de ma base
> (300 tables de tailles diverses, index clustered pour les clés primaires),
> afin de bénéficier de pointeurs frais et de chemins de parcours d'index
les
> plus courts. Dans la foulée, histoire que tout le monde profite de cette
> fraîcheur, je marquais à recompilation toutes les procédures dépendantes
de
> toutes les tables de ma base.
>
> Constatant que le premier utilisateur matinal de certaines de ces 20 p.s
se
> prenait timeout sur timeout (le code a été vérifié et même réécrit pour
> limiter les gabegies de ressources) avant de décrocher son téléphone pour
> m'incendier, en dépit de ce que je pensais être un modèle d'optimisation.
> J'ai donc fait appel à un consultant qui m'a conseillé de laisser faire
> SQL2000 autant que possible, de désactiver la recréation automatique des
> index (via mon plan de maintenance) et de coder un script qui le ferait en
> utilisant DBCC et que je ferais tourner en hebdo, voir en bimensuel. Ceci
> aurait pour effet d'éviter les recompilations en cascade de chaque
procédure
> référencée, même si elle ne change pas. Dont acte, ça me paraissaît
logique,
> sauf qu'une semaine plus tard, c'était toujours (au moins) pareil.
>
> J'ai du mal à comprendre ce qui peut produire ces ralentissements ni le
côté
> cyclique irrégulier du phénomène. La seule chose que je comprends, c'est
que
> la base respecte les formes normales, les index ne sont pas faits en dépit
du
> bon sens, que la machine est une bombe, que l'OS est censé la booster
encore
> plus, que le code (et particulièrement les jointures) a été vérifié et que
> les clients gueulent toujours, chose que je ne peux leur reprocher.
>
> Toute (bonne) idée sera la bienvenue.
> Jean-Yves AUGER
La recompilation est sans doute une mauvaise idée.
La mise à jour des index la nuit si c'est possible est une bonne idée
rajouter un fillfactor peut etre une bonne idée si les tables sont modifiées
en journée
ajouter un NOLOCK pour les lectures peut etre une bonne idée aussi (ou
passer en read uncommited)
HTH
br
"Jean-Yves" <JeanYves@discussions.microsoft.com> wrote in message
news:18120A77-B888-4C63-8A0D-85B32BA9988B@microsoft.com...
> Bonjour,
>
> J'ai un GROS souci sur un lot de procédures stockées, dont les
performances
> fluctuent énormément dans le temps et provoquent des timeouts bloquants
pour
> les utilisateurs. A l'analyse du code, il sembleraient qu'elles accèdent à
> des tables assez volumineuses (certaines ont des dizaines de millions de
> lignes) par le biais d'index dont les clés ne sont pas en cause.
>
> Jusqu'il y a très peu, je recréais nocturnement tous les index de ma base
> (300 tables de tailles diverses, index clustered pour les clés primaires),
> afin de bénéficier de pointeurs frais et de chemins de parcours d'index
les
> plus courts. Dans la foulée, histoire que tout le monde profite de cette
> fraîcheur, je marquais à recompilation toutes les procédures dépendantes
de
> toutes les tables de ma base.
>
> Constatant que le premier utilisateur matinal de certaines de ces 20 p.s
se
> prenait timeout sur timeout (le code a été vérifié et même réécrit pour
> limiter les gabegies de ressources) avant de décrocher son téléphone pour
> m'incendier, en dépit de ce que je pensais être un modèle d'optimisation.
> J'ai donc fait appel à un consultant qui m'a conseillé de laisser faire
> SQL2000 autant que possible, de désactiver la recréation automatique des
> index (via mon plan de maintenance) et de coder un script qui le ferait en
> utilisant DBCC et que je ferais tourner en hebdo, voir en bimensuel. Ceci
> aurait pour effet d'éviter les recompilations en cascade de chaque
procédure
> référencée, même si elle ne change pas. Dont acte, ça me paraissaît
logique,
> sauf qu'une semaine plus tard, c'était toujours (au moins) pareil.
>
> J'ai du mal à comprendre ce qui peut produire ces ralentissements ni le
côté
> cyclique irrégulier du phénomène. La seule chose que je comprends, c'est
que
> la base respecte les formes normales, les index ne sont pas faits en dépit
du
> bon sens, que la machine est une bombe, que l'OS est censé la booster
encore
> plus, que le code (et particulièrement les jointures) a été vérifié et que
> les clients gueulent toujours, chose que je ne peux leur reprocher.
>
> Toute (bonne) idée sera la bienvenue.
> Jean-Yves AUGER
La recompilation est sans doute une mauvaise idée.
La mise à jour des index la nuit si c'est possible est une bonne idée
rajouter un fillfactor peut etre une bonne idée si les tables sont modifiées
en journée
ajouter un NOLOCK pour les lectures peut etre une bonne idée aussi (ou
passer en read uncommited)
HTH
br
"Jean-Yves" wrote in message
news:
> Bonjour,
>
> J'ai un GROS souci sur un lot de procédures stockées, dont les
performances
> fluctuent énormément dans le temps et provoquent des timeouts bloquants
pour
> les utilisateurs. A l'analyse du code, il sembleraient qu'elles accèdent à
> des tables assez volumineuses (certaines ont des dizaines de millions de
> lignes) par le biais d'index dont les clés ne sont pas en cause.
>
> Jusqu'il y a très peu, je recréais nocturnement tous les index de ma base
> (300 tables de tailles diverses, index clustered pour les clés primaires),
> afin de bénéficier de pointeurs frais et de chemins de parcours d'index
les
> plus courts. Dans la foulée, histoire que tout le monde profite de cette
> fraîcheur, je marquais à recompilation toutes les procédures dépendantes
de
> toutes les tables de ma base.
>
> Constatant que le premier utilisateur matinal de certaines de ces 20 p.s
se
> prenait timeout sur timeout (le code a été vérifié et même réécrit pour
> limiter les gabegies de ressources) avant de décrocher son téléphone pour
> m'incendier, en dépit de ce que je pensais être un modèle d'optimisation.
> J'ai donc fait appel à un consultant qui m'a conseillé de laisser faire
> SQL2000 autant que possible, de désactiver la recréation automatique des
> index (via mon plan de maintenance) et de coder un script qui le ferait en
> utilisant DBCC et que je ferais tourner en hebdo, voir en bimensuel. Ceci
> aurait pour effet d'éviter les recompilations en cascade de chaque
procédure
> référencée, même si elle ne change pas. Dont acte, ça me paraissaît
logique,
> sauf qu'une semaine plus tard, c'était toujours (au moins) pareil.
>
> J'ai du mal à comprendre ce qui peut produire ces ralentissements ni le
côté
> cyclique irrégulier du phénomène. La seule chose que je comprends, c'est
que
> la base respecte les formes normales, les index ne sont pas faits en dépit
du
> bon sens, que la machine est une bombe, que l'OS est censé la booster
encore
> plus, que le code (et particulièrement les jointures) a été vérifié et que
> les clients gueulent toujours, chose que je ne peux leur reprocher.
>
> Toute (bonne) idée sera la bienvenue.
> Jean-Yves AUGER
Merci Bruno,
La recompilation a été désactivée depuis déjà 4 semaines, j'ai un
de 90% au niveau de la base elle-même, et ces procédures stockées ont été
"nolockées" intégralement.
J'ai une question : admettons que je ne reconstruise pas un index sur une
table de 10 millions de ligne pendant 2/3 semaines avec des modifications
régulières, même si peu nombreuses en ce moment. Si j'ai bien compris, au
cours du temps, il va se creuser "des trous" dans mon joli maillage
d'enregistrements chaînés. Que se passe-t-il si des modifications dans mes
pages font qu'elles ne tiennent plus dans une page, mais doivent être mise
sur d'autres, etc... ? Mon fillfactor a quelle utilité, si ce n'est
ce genre de manip. Bref, serait-il trop important ?
Jean-Yves AUGER
"bruno reiter [MVP]" a écrit :
> La recompilation est sans doute une mauvaise idée.
>
> La mise à jour des index la nuit si c'est possible est une bonne idée
>
> rajouter un fillfactor peut etre une bonne idée si les tables sont
> en journée
>
> ajouter un NOLOCK pour les lectures peut etre une bonne idée aussi (ou
> passer en read uncommited)
>
> HTH
>
> br
>
> "Jean-Yves" wrote in message
> news:
> > Bonjour,
> >
> > J'ai un GROS souci sur un lot de procédures stockées, dont les
> performances
> > fluctuent énormément dans le temps et provoquent des timeouts
> pour
> > les utilisateurs. A l'analyse du code, il sembleraient qu'elles
> > des tables assez volumineuses (certaines ont des dizaines de millions
> > lignes) par le biais d'index dont les clés ne sont pas en cause.
> >
> > Jusqu'il y a très peu, je recréais nocturnement tous les index de ma
> > (300 tables de tailles diverses, index clustered pour les clés
> > afin de bénéficier de pointeurs frais et de chemins de parcours
> les
> > plus courts. Dans la foulée, histoire que tout le monde profite de
> > fraîcheur, je marquais à recompilation toutes les procédures
> de
> > toutes les tables de ma base.
> >
> > Constatant que le premier utilisateur matinal de certaines de ces 20
> se
> > prenait timeout sur timeout (le code a été vérifié et même réécrit
> > limiter les gabegies de ressources) avant de décrocher son téléphone
> > m'incendier, en dépit de ce que je pensais être un modèle
> > J'ai donc fait appel à un consultant qui m'a conseillé de laisser
> > SQL2000 autant que possible, de désactiver la recréation automatique
> > index (via mon plan de maintenance) et de coder un script qui le
> > utilisant DBCC et que je ferais tourner en hebdo, voir en bimensuel.
> > aurait pour effet d'éviter les recompilations en cascade de chaque
> procédure
> > référencée, même si elle ne change pas. Dont acte, ça me paraissaît
> logique,
> > sauf qu'une semaine plus tard, c'était toujours (au moins) pareil.
> >
> > J'ai du mal à comprendre ce qui peut produire ces ralentissements ni
> côté
> > cyclique irrégulier du phénomène. La seule chose que je comprends,
> que
> > la base respecte les formes normales, les index ne sont pas faits en
> du
> > bon sens, que la machine est une bombe, que l'OS est censé la booster
> encore
> > plus, que le code (et particulièrement les jointures) a été vérifié et
> > les clients gueulent toujours, chose que je ne peux leur reprocher.
> >
> > Toute (bonne) idée sera la bienvenue.
> > Jean-Yves AUGER
>
>
>
Merci Bruno,
La recompilation a été désactivée depuis déjà 4 semaines, j'ai un
de 90% au niveau de la base elle-même, et ces procédures stockées ont été
"nolockées" intégralement.
J'ai une question : admettons que je ne reconstruise pas un index sur une
table de 10 millions de ligne pendant 2/3 semaines avec des modifications
régulières, même si peu nombreuses en ce moment. Si j'ai bien compris, au
cours du temps, il va se creuser "des trous" dans mon joli maillage
d'enregistrements chaînés. Que se passe-t-il si des modifications dans mes
pages font qu'elles ne tiennent plus dans une page, mais doivent être mise
sur d'autres, etc... ? Mon fillfactor a quelle utilité, si ce n'est
ce genre de manip. Bref, serait-il trop important ?
Jean-Yves AUGER
"bruno reiter [MVP]" a écrit :
> La recompilation est sans doute une mauvaise idée.
>
> La mise à jour des index la nuit si c'est possible est une bonne idée
>
> rajouter un fillfactor peut etre une bonne idée si les tables sont
> en journée
>
> ajouter un NOLOCK pour les lectures peut etre une bonne idée aussi (ou
> passer en read uncommited)
>
> HTH
>
> br
>
> "Jean-Yves" <JeanYves@discussions.microsoft.com> wrote in message
> news:18120A77-B888-4C63-8A0D-85B32BA9988B@microsoft.com...
> > Bonjour,
> >
> > J'ai un GROS souci sur un lot de procédures stockées, dont les
> performances
> > fluctuent énormément dans le temps et provoquent des timeouts
> pour
> > les utilisateurs. A l'analyse du code, il sembleraient qu'elles
> > des tables assez volumineuses (certaines ont des dizaines de millions
> > lignes) par le biais d'index dont les clés ne sont pas en cause.
> >
> > Jusqu'il y a très peu, je recréais nocturnement tous les index de ma
> > (300 tables de tailles diverses, index clustered pour les clés
> > afin de bénéficier de pointeurs frais et de chemins de parcours
> les
> > plus courts. Dans la foulée, histoire que tout le monde profite de
> > fraîcheur, je marquais à recompilation toutes les procédures
> de
> > toutes les tables de ma base.
> >
> > Constatant que le premier utilisateur matinal de certaines de ces 20
> se
> > prenait timeout sur timeout (le code a été vérifié et même réécrit
> > limiter les gabegies de ressources) avant de décrocher son téléphone
> > m'incendier, en dépit de ce que je pensais être un modèle
> > J'ai donc fait appel à un consultant qui m'a conseillé de laisser
> > SQL2000 autant que possible, de désactiver la recréation automatique
> > index (via mon plan de maintenance) et de coder un script qui le
> > utilisant DBCC et que je ferais tourner en hebdo, voir en bimensuel.
> > aurait pour effet d'éviter les recompilations en cascade de chaque
> procédure
> > référencée, même si elle ne change pas. Dont acte, ça me paraissaît
> logique,
> > sauf qu'une semaine plus tard, c'était toujours (au moins) pareil.
> >
> > J'ai du mal à comprendre ce qui peut produire ces ralentissements ni
> côté
> > cyclique irrégulier du phénomène. La seule chose que je comprends,
> que
> > la base respecte les formes normales, les index ne sont pas faits en
> du
> > bon sens, que la machine est une bombe, que l'OS est censé la booster
> encore
> > plus, que le code (et particulièrement les jointures) a été vérifié et
> > les clients gueulent toujours, chose que je ne peux leur reprocher.
> >
> > Toute (bonne) idée sera la bienvenue.
> > Jean-Yves AUGER
>
>
>
Merci Bruno,
La recompilation a été désactivée depuis déjà 4 semaines, j'ai un
de 90% au niveau de la base elle-même, et ces procédures stockées ont été
"nolockées" intégralement.
J'ai une question : admettons que je ne reconstruise pas un index sur une
table de 10 millions de ligne pendant 2/3 semaines avec des modifications
régulières, même si peu nombreuses en ce moment. Si j'ai bien compris, au
cours du temps, il va se creuser "des trous" dans mon joli maillage
d'enregistrements chaînés. Que se passe-t-il si des modifications dans mes
pages font qu'elles ne tiennent plus dans une page, mais doivent être mise
sur d'autres, etc... ? Mon fillfactor a quelle utilité, si ce n'est
ce genre de manip. Bref, serait-il trop important ?
Jean-Yves AUGER
"bruno reiter [MVP]" a écrit :
> La recompilation est sans doute une mauvaise idée.
>
> La mise à jour des index la nuit si c'est possible est une bonne idée
>
> rajouter un fillfactor peut etre une bonne idée si les tables sont
> en journée
>
> ajouter un NOLOCK pour les lectures peut etre une bonne idée aussi (ou
> passer en read uncommited)
>
> HTH
>
> br
>
> "Jean-Yves" wrote in message
> news:
> > Bonjour,
> >
> > J'ai un GROS souci sur un lot de procédures stockées, dont les
> performances
> > fluctuent énormément dans le temps et provoquent des timeouts
> pour
> > les utilisateurs. A l'analyse du code, il sembleraient qu'elles
> > des tables assez volumineuses (certaines ont des dizaines de millions
> > lignes) par le biais d'index dont les clés ne sont pas en cause.
> >
> > Jusqu'il y a très peu, je recréais nocturnement tous les index de ma
> > (300 tables de tailles diverses, index clustered pour les clés
> > afin de bénéficier de pointeurs frais et de chemins de parcours
> les
> > plus courts. Dans la foulée, histoire que tout le monde profite de
> > fraîcheur, je marquais à recompilation toutes les procédures
> de
> > toutes les tables de ma base.
> >
> > Constatant que le premier utilisateur matinal de certaines de ces 20
> se
> > prenait timeout sur timeout (le code a été vérifié et même réécrit
> > limiter les gabegies de ressources) avant de décrocher son téléphone
> > m'incendier, en dépit de ce que je pensais être un modèle
> > J'ai donc fait appel à un consultant qui m'a conseillé de laisser
> > SQL2000 autant que possible, de désactiver la recréation automatique
> > index (via mon plan de maintenance) et de coder un script qui le
> > utilisant DBCC et que je ferais tourner en hebdo, voir en bimensuel.
> > aurait pour effet d'éviter les recompilations en cascade de chaque
> procédure
> > référencée, même si elle ne change pas. Dont acte, ça me paraissaît
> logique,
> > sauf qu'une semaine plus tard, c'était toujours (au moins) pareil.
> >
> > J'ai du mal à comprendre ce qui peut produire ces ralentissements ni
> côté
> > cyclique irrégulier du phénomène. La seule chose que je comprends,
> que
> > la base respecte les formes normales, les index ne sont pas faits en
> du
> > bon sens, que la machine est une bombe, que l'OS est censé la booster
> encore
> > plus, que le code (et particulièrement les jointures) a été vérifié et
> > les clients gueulent toujours, chose que je ne peux leur reprocher.
> >
> > Toute (bonne) idée sera la bienvenue.
> > Jean-Yves AUGER
>
>
>
>>je laisse la recréation nocturne via le plan de maintenance ou je la vire
?
Med & Fred,
Merci tout d'abord d'avoir répondu. J'ai commis un lapsus : il fallait
lire
non-clustered pour les clés primaires de mes tables.
Fred, pour ce qui est des colonnes VARCHAR, nous avons pris pour principe
(dûs à certains problèmes dans notre ancien système 6.5) de ne pas mettre
de
colonne de ce type dans les clés primaires, à 99% composites. Toutes
contiennent du CHAR ou de l'entier, et surtout pas de valeur NULL.
Med, ma société n'ayant pas de but commercial (recherche), les clients
nous
assurent une plage nocturne adéquate pour ce que je pensais être des
optimisations de ce genre. Sauf que ça n'optimise pas lourd...
Les avis des intervenants divergeant me laissent perplexe : je laisse la
recréation nocturne via le plan de maintenance ou je la vire ?
Jean-Yves AUGER
"Med Bouchenafa" a écrit :Avoir une fenêtre de temps pour récréer les index de sa base est un luxe
que
beaucoup d'applications ne peuvent pas se permettrent .
Autant s'estimer heureux donc. Quelques remarques cependant à la lecture
de
ton message
a) Ce n'est pas forcément une bonne chose de choisir une clef primaire en
index cluster
Il est vrai que c'est l'option par défaut de SQL Server mais ce n'est pas
une raison pour la suivre à chaque fois
b) Le temps aléatoire d'exécution d'un SP ne peut s'expliquer par le
temps
de compilation
Il est fort possible que le plan d'exécution compilé et sauvegardé pour
une
procédure ne corresponde pas forcement à un autre jeu de paramètres de
cette
même SP
--
Bien cordialement
Med Bouchenafa
"Jean-Yves" a écrit dans le message
de
news:
> Bonjour,
>
> J'ai un GROS souci sur un lot de procédures stockées, dont les
> performances
> fluctuent énormément dans le temps et provoquent des timeouts bloquants
> pour
> les utilisateurs. A l'analyse du code, il sembleraient qu'elles
> accèdent à
> des tables assez volumineuses (certaines ont des dizaines de millions
> de
> lignes) par le biais d'index dont les clés ne sont pas en cause.
>
> Jusqu'il y a très peu, je recréais nocturnement tous les index de ma
> base
> (300 tables de tailles diverses, index clustered pour les clés
> primaires),
> afin de bénéficier de pointeurs frais et de chemins de parcours d'index
> les
> plus courts. Dans la foulée, histoire que tout le monde profite de
> cette
> fraîcheur, je marquais à recompilation toutes les procédures
> dépendantes
> de
> toutes les tables de ma base.
>
> Constatant que le premier utilisateur matinal de certaines de ces 20
> p.s
> se
> prenait timeout sur timeout (le code a été vérifié et même réécrit pour
> limiter les gabegies de ressources) avant de décrocher son téléphone
> pour
> m'incendier, en dépit de ce que je pensais être un modèle
> d'optimisation.
> J'ai donc fait appel à un consultant qui m'a conseillé de laisser faire
> SQL2000 autant que possible, de désactiver la recréation automatique
> des
> index (via mon plan de maintenance) et de coder un script qui le ferait
> en
> utilisant DBCC et que je ferais tourner en hebdo, voir en bimensuel.
> Ceci
> aurait pour effet d'éviter les recompilations en cascade de chaque
> procédure
> référencée, même si elle ne change pas. Dont acte, ça me paraissaît
> logique,
> sauf qu'une semaine plus tard, c'était toujours (au moins) pareil.
>
> J'ai du mal à comprendre ce qui peut produire ces ralentissements ni le
> côté
> cyclique irrégulier du phénomène. La seule chose que je comprends,
> c'est
> que
> la base respecte les formes normales, les index ne sont pas faits en
> dépit
> du
> bon sens, que la machine est une bombe, que l'OS est censé la booster
> encore
> plus, que le code (et particulièrement les jointures) a été vérifié et
> que
> les clients gueulent toujours, chose que je ne peux leur reprocher.
>
> Toute (bonne) idée sera la bienvenue.
> Jean-Yves AUGER
>>je laisse la recréation nocturne via le plan de maintenance ou je la vire
?
Med & Fred,
Merci tout d'abord d'avoir répondu. J'ai commis un lapsus : il fallait
lire
non-clustered pour les clés primaires de mes tables.
Fred, pour ce qui est des colonnes VARCHAR, nous avons pris pour principe
(dûs à certains problèmes dans notre ancien système 6.5) de ne pas mettre
de
colonne de ce type dans les clés primaires, à 99% composites. Toutes
contiennent du CHAR ou de l'entier, et surtout pas de valeur NULL.
Med, ma société n'ayant pas de but commercial (recherche), les clients
nous
assurent une plage nocturne adéquate pour ce que je pensais être des
optimisations de ce genre. Sauf que ça n'optimise pas lourd...
Les avis des intervenants divergeant me laissent perplexe : je laisse la
recréation nocturne via le plan de maintenance ou je la vire ?
Jean-Yves AUGER
"Med Bouchenafa" a écrit :
Avoir une fenêtre de temps pour récréer les index de sa base est un luxe
que
beaucoup d'applications ne peuvent pas se permettrent .
Autant s'estimer heureux donc. Quelques remarques cependant à la lecture
de
ton message
a) Ce n'est pas forcément une bonne chose de choisir une clef primaire en
index cluster
Il est vrai que c'est l'option par défaut de SQL Server mais ce n'est pas
une raison pour la suivre à chaque fois
b) Le temps aléatoire d'exécution d'un SP ne peut s'expliquer par le
temps
de compilation
Il est fort possible que le plan d'exécution compilé et sauvegardé pour
une
procédure ne corresponde pas forcement à un autre jeu de paramètres de
cette
même SP
--
Bien cordialement
Med Bouchenafa
"Jean-Yves" <JeanYves@discussions.microsoft.com> a écrit dans le message
de
news: 18120A77-B888-4C63-8A0D-85B32BA9988B@microsoft.com...
> Bonjour,
>
> J'ai un GROS souci sur un lot de procédures stockées, dont les
> performances
> fluctuent énormément dans le temps et provoquent des timeouts bloquants
> pour
> les utilisateurs. A l'analyse du code, il sembleraient qu'elles
> accèdent à
> des tables assez volumineuses (certaines ont des dizaines de millions
> de
> lignes) par le biais d'index dont les clés ne sont pas en cause.
>
> Jusqu'il y a très peu, je recréais nocturnement tous les index de ma
> base
> (300 tables de tailles diverses, index clustered pour les clés
> primaires),
> afin de bénéficier de pointeurs frais et de chemins de parcours d'index
> les
> plus courts. Dans la foulée, histoire que tout le monde profite de
> cette
> fraîcheur, je marquais à recompilation toutes les procédures
> dépendantes
> de
> toutes les tables de ma base.
>
> Constatant que le premier utilisateur matinal de certaines de ces 20
> p.s
> se
> prenait timeout sur timeout (le code a été vérifié et même réécrit pour
> limiter les gabegies de ressources) avant de décrocher son téléphone
> pour
> m'incendier, en dépit de ce que je pensais être un modèle
> d'optimisation.
> J'ai donc fait appel à un consultant qui m'a conseillé de laisser faire
> SQL2000 autant que possible, de désactiver la recréation automatique
> des
> index (via mon plan de maintenance) et de coder un script qui le ferait
> en
> utilisant DBCC et que je ferais tourner en hebdo, voir en bimensuel.
> Ceci
> aurait pour effet d'éviter les recompilations en cascade de chaque
> procédure
> référencée, même si elle ne change pas. Dont acte, ça me paraissaît
> logique,
> sauf qu'une semaine plus tard, c'était toujours (au moins) pareil.
>
> J'ai du mal à comprendre ce qui peut produire ces ralentissements ni le
> côté
> cyclique irrégulier du phénomène. La seule chose que je comprends,
> c'est
> que
> la base respecte les formes normales, les index ne sont pas faits en
> dépit
> du
> bon sens, que la machine est une bombe, que l'OS est censé la booster
> encore
> plus, que le code (et particulièrement les jointures) a été vérifié et
> que
> les clients gueulent toujours, chose que je ne peux leur reprocher.
>
> Toute (bonne) idée sera la bienvenue.
> Jean-Yves AUGER
>>je laisse la recréation nocturne via le plan de maintenance ou je la vire
?
Med & Fred,
Merci tout d'abord d'avoir répondu. J'ai commis un lapsus : il fallait
lire
non-clustered pour les clés primaires de mes tables.
Fred, pour ce qui est des colonnes VARCHAR, nous avons pris pour principe
(dûs à certains problèmes dans notre ancien système 6.5) de ne pas mettre
de
colonne de ce type dans les clés primaires, à 99% composites. Toutes
contiennent du CHAR ou de l'entier, et surtout pas de valeur NULL.
Med, ma société n'ayant pas de but commercial (recherche), les clients
nous
assurent une plage nocturne adéquate pour ce que je pensais être des
optimisations de ce genre. Sauf que ça n'optimise pas lourd...
Les avis des intervenants divergeant me laissent perplexe : je laisse la
recréation nocturne via le plan de maintenance ou je la vire ?
Jean-Yves AUGER
"Med Bouchenafa" a écrit :Avoir une fenêtre de temps pour récréer les index de sa base est un luxe
que
beaucoup d'applications ne peuvent pas se permettrent .
Autant s'estimer heureux donc. Quelques remarques cependant à la lecture
de
ton message
a) Ce n'est pas forcément une bonne chose de choisir une clef primaire en
index cluster
Il est vrai que c'est l'option par défaut de SQL Server mais ce n'est pas
une raison pour la suivre à chaque fois
b) Le temps aléatoire d'exécution d'un SP ne peut s'expliquer par le
temps
de compilation
Il est fort possible que le plan d'exécution compilé et sauvegardé pour
une
procédure ne corresponde pas forcement à un autre jeu de paramètres de
cette
même SP
--
Bien cordialement
Med Bouchenafa
"Jean-Yves" a écrit dans le message
de
news:
> Bonjour,
>
> J'ai un GROS souci sur un lot de procédures stockées, dont les
> performances
> fluctuent énormément dans le temps et provoquent des timeouts bloquants
> pour
> les utilisateurs. A l'analyse du code, il sembleraient qu'elles
> accèdent à
> des tables assez volumineuses (certaines ont des dizaines de millions
> de
> lignes) par le biais d'index dont les clés ne sont pas en cause.
>
> Jusqu'il y a très peu, je recréais nocturnement tous les index de ma
> base
> (300 tables de tailles diverses, index clustered pour les clés
> primaires),
> afin de bénéficier de pointeurs frais et de chemins de parcours d'index
> les
> plus courts. Dans la foulée, histoire que tout le monde profite de
> cette
> fraîcheur, je marquais à recompilation toutes les procédures
> dépendantes
> de
> toutes les tables de ma base.
>
> Constatant que le premier utilisateur matinal de certaines de ces 20
> p.s
> se
> prenait timeout sur timeout (le code a été vérifié et même réécrit pour
> limiter les gabegies de ressources) avant de décrocher son téléphone
> pour
> m'incendier, en dépit de ce que je pensais être un modèle
> d'optimisation.
> J'ai donc fait appel à un consultant qui m'a conseillé de laisser faire
> SQL2000 autant que possible, de désactiver la recréation automatique
> des
> index (via mon plan de maintenance) et de coder un script qui le ferait
> en
> utilisant DBCC et que je ferais tourner en hebdo, voir en bimensuel.
> Ceci
> aurait pour effet d'éviter les recompilations en cascade de chaque
> procédure
> référencée, même si elle ne change pas. Dont acte, ça me paraissaît
> logique,
> sauf qu'une semaine plus tard, c'était toujours (au moins) pareil.
>
> J'ai du mal à comprendre ce qui peut produire ces ralentissements ni le
> côté
> cyclique irrégulier du phénomène. La seule chose que je comprends,
> c'est
> que
> la base respecte les formes normales, les index ne sont pas faits en
> dépit
> du
> bon sens, que la machine est une bombe, que l'OS est censé la booster
> encore
> plus, que le code (et particulièrement les jointures) a été vérifié et
> que
> les clients gueulent toujours, chose que je ne peux leur reprocher.
>
> Toute (bonne) idée sera la bienvenue.
> Jean-Yves AUGER
