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
Philippe T [MS]
Bonjour,
Cela fonctionne de la même façon que pour les tables. Cela permet d'éviter d'avoir trop de fragmentation au niveau des index.
Phil. ________________________________________________________ Philippe TROTIN Microsoft Services France http://www.microsoft.com/france "Dji_c" wrote in message news:44a236c7$0$31821$
Bonjour,
Je me pose la question sur l'option remplissage dans les index, a quoi sert elle et comment ajuster la valeur au mieu ?
Merci d'avance.
++
Bonjour,
Cela fonctionne de la même façon que pour les tables. Cela permet d'éviter
d'avoir trop de fragmentation au niveau des index.
Phil.
________________________________________________________
Philippe TROTIN
Microsoft Services France http://www.microsoft.com/france
"Dji_c" <jean-claude.perruche@aviso.fr> wrote in message
news:44a236c7$0$31821$626a54ce@news.free.fr...
Bonjour,
Je me pose la question sur l'option remplissage dans les index, a quoi
sert elle et comment ajuster la valeur au mieu ?
Cela fonctionne de la même façon que pour les tables. Cela permet d'éviter d'avoir trop de fragmentation au niveau des index.
Phil. ________________________________________________________ Philippe TROTIN Microsoft Services France http://www.microsoft.com/france "Dji_c" wrote in message news:44a236c7$0$31821$
Bonjour,
Je me pose la question sur l'option remplissage dans les index, a quoi sert elle et comment ajuster la valeur au mieu ?
Merci d'avance.
++
Dji_c
D'accord, c'est bien cela que j'avais compris, mais il est donc recommandé de specifier une valeur.
Cependant la valeur doit elle plutot etre basse, moyenne ou haute ?
Merci "Philippe T [MS]" a écrit dans le message de news:
Bonjour,
Cela fonctionne de la même façon que pour les tables. Cela permet d'éviter d'avoir trop de fragmentation au niveau des index.
Phil. ________________________________________________________ Philippe TROTIN Microsoft Services France http://www.microsoft.com/france "Dji_c" wrote in message news:44a236c7$0$31821$
Bonjour,
Je me pose la question sur l'option remplissage dans les index, a quoi sert elle et comment ajuster la valeur au mieu ?
Merci d'avance.
++
D'accord, c'est bien cela que j'avais compris, mais il est donc recommandé
de specifier une valeur.
Cependant la valeur doit elle plutot etre basse, moyenne ou haute ?
Merci
"Philippe T [MS]" <ptrotin@online.microsoft.com> a écrit dans le message de
news: utH53jqmGHA.3980@TK2MSFTNGP02.phx.gbl...
Bonjour,
Cela fonctionne de la même façon que pour les tables. Cela permet d'éviter
d'avoir trop de fragmentation au niveau des index.
Phil.
________________________________________________________
Philippe TROTIN
Microsoft Services France http://www.microsoft.com/france
"Dji_c" <jean-claude.perruche@aviso.fr> wrote in message
news:44a236c7$0$31821$626a54ce@news.free.fr...
Bonjour,
Je me pose la question sur l'option remplissage dans les index, a quoi
sert elle et comment ajuster la valeur au mieu ?
D'accord, c'est bien cela que j'avais compris, mais il est donc recommandé de specifier une valeur.
Cependant la valeur doit elle plutot etre basse, moyenne ou haute ?
Merci "Philippe T [MS]" a écrit dans le message de news:
Bonjour,
Cela fonctionne de la même façon que pour les tables. Cela permet d'éviter d'avoir trop de fragmentation au niveau des index.
Phil. ________________________________________________________ Philippe TROTIN Microsoft Services France http://www.microsoft.com/france "Dji_c" wrote in message news:44a236c7$0$31821$
Bonjour,
Je me pose la question sur l'option remplissage dans les index, a quoi sert elle et comment ajuster la valeur au mieu ?
Merci d'avance.
++
Rudi Bruchez
Dji_c a écrit:
D'accord, c'est bien cela que j'avais compris, mais il est donc recommandé de specifier une valeur.
Cependant la valeur doit elle plutot etre basse, moyenne ou haute ?
Bonjour,
Cela dépend de la fréquence de mises à jour de ta table. Si tu effectues principalement des lectures (comme dans une base type OLAP), tu peux remplir les pages d'index, les requêtes seront plus efficaces. Si tu fais de nombreuses mises à jour (update des colonnes indexées, ou insert), tu peux laisser plus de place pour permettre aux nouvelles entrées de l'index de s'insérer dans les pages existantes, et éviter les split.
A moins d'avoir des index de taille importante, ce n'est pas un élément très significatif, selon mes expériences (d'aucuns ne seront peut-être pas d'accord avec ça). Pour optimiser tes index, pense d'abord à mettre les colonnes les plus sélectives, et les plus utilisées dans tes requêtes, d'abord. Et à créer des index de la plus petite taille possible.
-- Rudi Bruchez, MCDBA http://www.babaluga.com/
Dji_c a écrit:
D'accord, c'est bien cela que j'avais compris, mais il est donc recommandé
de specifier une valeur.
Cependant la valeur doit elle plutot etre basse, moyenne ou haute ?
Bonjour,
Cela dépend de la fréquence de mises à jour de ta table. Si tu effectues
principalement des lectures (comme dans une base type OLAP), tu peux
remplir les pages d'index, les requêtes seront plus efficaces.
Si tu fais de nombreuses mises à jour (update des colonnes indexées, ou
insert), tu peux laisser plus de place pour permettre aux nouvelles entrées
de l'index de s'insérer dans les pages existantes, et éviter les split.
A moins d'avoir des index de taille importante, ce n'est pas un élément
très significatif, selon mes expériences (d'aucuns ne seront peut-être pas
d'accord avec ça). Pour optimiser tes index, pense d'abord à mettre les
colonnes les plus sélectives, et les plus utilisées dans tes requêtes,
d'abord. Et à créer des index de la plus petite taille possible.
D'accord, c'est bien cela que j'avais compris, mais il est donc recommandé de specifier une valeur.
Cependant la valeur doit elle plutot etre basse, moyenne ou haute ?
Bonjour,
Cela dépend de la fréquence de mises à jour de ta table. Si tu effectues principalement des lectures (comme dans une base type OLAP), tu peux remplir les pages d'index, les requêtes seront plus efficaces. Si tu fais de nombreuses mises à jour (update des colonnes indexées, ou insert), tu peux laisser plus de place pour permettre aux nouvelles entrées de l'index de s'insérer dans les pages existantes, et éviter les split.
A moins d'avoir des index de taille importante, ce n'est pas un élément très significatif, selon mes expériences (d'aucuns ne seront peut-être pas d'accord avec ça). Pour optimiser tes index, pense d'abord à mettre les colonnes les plus sélectives, et les plus utilisées dans tes requêtes, d'abord. Et à créer des index de la plus petite taille possible.
-- Rudi Bruchez, MCDBA http://www.babaluga.com/
Dji_c
Oui, en faite je suis dans le cas des updates et inserts à tout va. A l'heure actuelle j'ai un remplissage à 50 sur mes index mais on me dit de decocher la case ??
Je ne suis pas trop pour la decocher !
Qu'en pensez-vous ?
"Rudi Bruchez" <"rudi#nospam#[at]babaluga.com"> a écrit dans le message de news:
Dji_c a écrit:
D'accord, c'est bien cela que j'avais compris, mais il est donc recommandé de specifier une valeur.
Cependant la valeur doit elle plutot etre basse, moyenne ou haute ?
Bonjour,
Cela dépend de la fréquence de mises à jour de ta table. Si tu effectues principalement des lectures (comme dans une base type OLAP), tu peux remplir les pages d'index, les requêtes seront plus efficaces. Si tu fais de nombreuses mises à jour (update des colonnes indexées, ou insert), tu peux laisser plus de place pour permettre aux nouvelles entrées de l'index de s'insérer dans les pages existantes, et éviter les split.
A moins d'avoir des index de taille importante, ce n'est pas un élément très significatif, selon mes expériences (d'aucuns ne seront peut-être pas d'accord avec ça). Pour optimiser tes index, pense d'abord à mettre les colonnes les plus sélectives, et les plus utilisées dans tes requêtes, d'abord. Et à créer des index de la plus petite taille possible.
-- Rudi Bruchez, MCDBA http://www.babaluga.com/
Oui, en faite je suis dans le cas des updates et inserts à tout va. A
l'heure actuelle j'ai un remplissage à 50 sur mes index mais on me dit de
decocher la case ??
Je ne suis pas trop pour la decocher !
Qu'en pensez-vous ?
"Rudi Bruchez" <"rudi#nospam#[at]babaluga.com"> a écrit dans le message de
news: 1v0keq753h8f2.1k7zwd32k03jq.dlg@40tude.net...
Dji_c a écrit:
D'accord, c'est bien cela que j'avais compris, mais il est donc
recommandé
de specifier une valeur.
Cependant la valeur doit elle plutot etre basse, moyenne ou haute ?
Bonjour,
Cela dépend de la fréquence de mises à jour de ta table. Si tu effectues
principalement des lectures (comme dans une base type OLAP), tu peux
remplir les pages d'index, les requêtes seront plus efficaces.
Si tu fais de nombreuses mises à jour (update des colonnes indexées, ou
insert), tu peux laisser plus de place pour permettre aux nouvelles
entrées
de l'index de s'insérer dans les pages existantes, et éviter les split.
A moins d'avoir des index de taille importante, ce n'est pas un élément
très significatif, selon mes expériences (d'aucuns ne seront peut-être pas
d'accord avec ça). Pour optimiser tes index, pense d'abord à mettre les
colonnes les plus sélectives, et les plus utilisées dans tes requêtes,
d'abord. Et à créer des index de la plus petite taille possible.
Oui, en faite je suis dans le cas des updates et inserts à tout va. A l'heure actuelle j'ai un remplissage à 50 sur mes index mais on me dit de decocher la case ??
Je ne suis pas trop pour la decocher !
Qu'en pensez-vous ?
"Rudi Bruchez" <"rudi#nospam#[at]babaluga.com"> a écrit dans le message de news:
Dji_c a écrit:
D'accord, c'est bien cela que j'avais compris, mais il est donc recommandé de specifier une valeur.
Cependant la valeur doit elle plutot etre basse, moyenne ou haute ?
Bonjour,
Cela dépend de la fréquence de mises à jour de ta table. Si tu effectues principalement des lectures (comme dans une base type OLAP), tu peux remplir les pages d'index, les requêtes seront plus efficaces. Si tu fais de nombreuses mises à jour (update des colonnes indexées, ou insert), tu peux laisser plus de place pour permettre aux nouvelles entrées de l'index de s'insérer dans les pages existantes, et éviter les split.
A moins d'avoir des index de taille importante, ce n'est pas un élément très significatif, selon mes expériences (d'aucuns ne seront peut-être pas d'accord avec ça). Pour optimiser tes index, pense d'abord à mettre les colonnes les plus sélectives, et les plus utilisées dans tes requêtes, d'abord. Et à créer des index de la plus petite taille possible.
-- Rudi Bruchez, MCDBA http://www.babaluga.com/
Rudi Bruchez
Dji_c a écrit:
Oui, en faite je suis dans le cas des updates et inserts à tout va. A l'heure actuelle j'ai un remplissage à 50 sur mes index mais on me dit de decocher la case ??
Je ne suis pas trop pour la decocher !
Peut-être faut-il la décocher puis la recocher... Bon, je plaisante, je ne sais pas de quelle coche tu parles. Une instruction SQL du type CREATE INDEX ... WITH FILLFACTOR ... serait plus parlant.
Il y a deux notions : - FILLFACTOR : le remplissage du dernier niveau de l'index (leaf node) - PAD_INDEX : le remplissage des noeuds intermédiaires, selon le pourcentag indiqué avec FILLFACTOR
Personnellement, je n'ai jamais utilisé PAD_INDEX, ou senti le besoin de l'utiliser, mais peut-être suis-je léger... Si tu as une grande table avec beaucoup d'updates ou d'insert, qui se font sur un index qui va se trouver modifié à l'intérieur (par opposition à un index qui grandit de façon monotone, sur une colonne identity par exemple), peut-être peux-tu essayer le PAD_INDEX avec un FILLFACTOR à 50 ou 70. En sachant que cela va diminuer les performances de lecture, puisque SQL Server aura à parcourir plus de pages d'index pour retrouver les mêmes informations.
Il faut aussi savoir que ce pourcentage n'est pas maintenu dynamiquement le long du remplissage de l'index. Il est valable à la création, et à la recréation de l'index.
Pour voir si tu es très atteint par les splits de pages d'index, tu as un compteur du performance manager : SQL Server:Access Methods - > Pages splits/Sec
-- Rudi Bruchez, MCDBA http://www.babaluga.com/
Dji_c a écrit:
Oui, en faite je suis dans le cas des updates et inserts à tout va. A
l'heure actuelle j'ai un remplissage à 50 sur mes index mais on me dit de
decocher la case ??
Je ne suis pas trop pour la decocher !
Peut-être faut-il la décocher puis la recocher...
Bon, je plaisante, je ne sais pas de quelle coche tu parles. Une
instruction SQL du type CREATE INDEX ... WITH FILLFACTOR ... serait plus
parlant.
Il y a deux notions :
- FILLFACTOR : le remplissage du dernier niveau de l'index (leaf node)
- PAD_INDEX : le remplissage des noeuds intermédiaires, selon le pourcentag
indiqué avec FILLFACTOR
Personnellement, je n'ai jamais utilisé PAD_INDEX, ou senti le besoin de
l'utiliser, mais peut-être suis-je léger... Si tu as une grande table avec
beaucoup d'updates ou d'insert, qui se font sur un index qui va se trouver
modifié à l'intérieur (par opposition à un index qui grandit de façon
monotone, sur une colonne identity par exemple), peut-être peux-tu essayer
le PAD_INDEX avec un FILLFACTOR à 50 ou 70.
En sachant que cela va diminuer les performances de lecture, puisque SQL
Server aura à parcourir plus de pages d'index pour retrouver les mêmes
informations.
Il faut aussi savoir que ce pourcentage n'est pas maintenu dynamiquement le
long du remplissage de l'index. Il est valable à la création, et à la
recréation de l'index.
Pour voir si tu es très atteint par les splits de pages d'index, tu as un
compteur du performance manager :
SQL Server:Access Methods - > Pages splits/Sec
Oui, en faite je suis dans le cas des updates et inserts à tout va. A l'heure actuelle j'ai un remplissage à 50 sur mes index mais on me dit de decocher la case ??
Je ne suis pas trop pour la decocher !
Peut-être faut-il la décocher puis la recocher... Bon, je plaisante, je ne sais pas de quelle coche tu parles. Une instruction SQL du type CREATE INDEX ... WITH FILLFACTOR ... serait plus parlant.
Il y a deux notions : - FILLFACTOR : le remplissage du dernier niveau de l'index (leaf node) - PAD_INDEX : le remplissage des noeuds intermédiaires, selon le pourcentag indiqué avec FILLFACTOR
Personnellement, je n'ai jamais utilisé PAD_INDEX, ou senti le besoin de l'utiliser, mais peut-être suis-je léger... Si tu as une grande table avec beaucoup d'updates ou d'insert, qui se font sur un index qui va se trouver modifié à l'intérieur (par opposition à un index qui grandit de façon monotone, sur une colonne identity par exemple), peut-être peux-tu essayer le PAD_INDEX avec un FILLFACTOR à 50 ou 70. En sachant que cela va diminuer les performances de lecture, puisque SQL Server aura à parcourir plus de pages d'index pour retrouver les mêmes informations.
Il faut aussi savoir que ce pourcentage n'est pas maintenu dynamiquement le long du remplissage de l'index. Il est valable à la création, et à la recréation de l'index.
Pour voir si tu es très atteint par les splits de pages d'index, tu as un compteur du performance manager : SQL Server:Access Methods - > Pages splits/Sec
