Version imprimable
J'ai un tablespace qui contient les indexes et un tablespace qui contiennent les tables. j'ai un besoin d'ajouter un autre index sur un field de la table employee.
aprés l'ajout de cet index j'ai remarqué que le process que je l'ai ajouté un index devient rapide alors que les anciens process qui utilisent un ancien index devienent lente.
Noté bien : j'ai ajouté l'index alors que la table employé contienne des informations.
N'est-il pas envisageable que l'ajout d'un index ait modifié la plan d'exécution des autres process ? Plans qui deviendraient moins judicieux car moins performants.
C'est plus que probable !! :?Citation:
Envoyé par nuke_y
La création d'index ne doit pas être pris à la légère, les impacts sont non négligeables et il faut impérativement avoir une vision globale de tous les traitements qui peuvent être faits.
Si c'était aussi simple et aussi magique que ça, toutes les colonnes et toutes les combinaisons de colonnes seraient systématiquement indexées... ;-)
L'ajout d'un index ralentit tous les process d'insertion c'est systématique...
(car en plus d'insérer dans la table il faut insérer dans l'index).
Cela peut accélérer les update et les delete en général.
Par contre si tu n'as pas supprimé les anciens index et si tes process ne sont pas de l'insertion ce n'est pas très normal.
Est ce que l'utilisation de tel ou tel index est spécifiée dans un de tes process (par des hints /*+ ... */ )?
Si c'est le cas il vaudrait peut être mieux les enlever ...
Pas forcément.... il suffit que les stats ne soient pas à jour et/ou qu'il y ait déjà un grand nombre d'indexes pour que l'optimizer se plante...Citation:
Envoyé par dyvim
+1Citation:
Envoyé par dyvim
On ne doit pas utiliser de hint sauf cas vraiment exceptionnels...
Par contre pour vérifier si c'est bien un problème de l'optimiseur, ça peut être utile les hints.
Pour parler de mon cas perso, il m'est déjà arrivé de planter des traitements qui marchaient bien en rajoutant un index sur une table pour accélerer un autre traitement.