Discussion :

[LEK]

Bonjour,
j'ai une application qui permet de gérer la liste des fournitures/inventaires/calendrier disponibilité des ressources d'entreprises (une sorte d'appli multitenant car chaque entreprise utilise le même modèlme mais n'est pas apparentée à sa voisine).
Il y a un import de la liste des différentes données qui se lance périodiquement et permet de charger toutes les informations mise à jour pour une entreprise.
Chacune d'entre elle n'a pas les mêmes volumétrie et complexité de calendrier de ressources.

Une autre application permet de consulter ces informations et tous les select utilisent des bind variables. Je m'aperçois que lorsqu'un plan d'exécution a été stocké lors de la première exécution et concerne une entreprise avec faible volumétrie (notamment sur calendrier), les requêtes suivantes pour les entreprises ayant des données plus riches sont pénalisées...

Quelle est l'approche correcte ici ? Est-ce qu'il faut que j'étudie les plans optimaux et force oracle à les suivre? est ce qu'il faut que j'enlève les bind variables sur mes id_entreprise pour avoir un plan d'exécution différent par entreprise ?

Merci pour vos retours d'expériences et conseils.

[Ikebukuro]

C'est vaste comme sujet...

Je te conseille TRES fortement de garder les bind variables car c'est une recommandation forte d'Oracle : ça permet d'économiser de la mémoire, ne pas avoir à recalculer des plans d'exécution etc etc.
Le souci, c'est que parfois Oracle garde un bon plan d'exécution pour une valeur de bind variable (utilisation d'un index car sélectivité de la bind de 1% par exemple sur une grosse table) et l'applique à une autre valeur de la bind qui elle aurait du utiliser un full table scan (car sélectivité de 80% par exemple sur une grosse table).
Ca fait un bout de temps que je n'ai plus testé cela, mais Oracle ne détecte pas ces changements de sélectivité, pour lui chaque valeur de bind est présente en proportion égale : 2 valeurs distinctes --> 50%, 10 valeurs --> 10% et donc il utilisera le même plan d'exécution pour chaque valeur de ta bind.

Dans le cas où ta bind a une sélectivité différente selon la valeur, ce serait bien de créer un histogramme (genre Frequency ou Top Frequency) sur la colonne, comme ça Oracle utilisera le meilleur plan d'exécution selon la valeur de ta bind.

J'espère que c'est clair

[LEK]

Je pense avoir compris dans les grandes lignes (n'étant pas dba)...
Merci : je vais voir si je trouve de l'infor en ligne et testé cette solution.

[pachot]

Bonjour,
Ca dépend du nombre d'entreprises. S'il y en a 2000, et 100 de plus tous les mois, ce serait problématique de stocker tous ces plans d'exécution en shared pool. S'il y en a 4, ou 20, et que ça augmente rarement, ce serait dommage de ne pas avoir un plan optimal pour chacun.

une sorte d'appli multitenant

Alors là c'est assez clair qu'on est dans le cas où on voudrait des plans d'exécution différents. Donc, oui, id_entreprise en litéral serait une bonne idée. Ou alors simplement rajouter un commentaire avec le nom de l'entreprise.
Dans ce cas, il faut aussi s'assurer d'avoir des histogrammes sur id_entreprise pour les tables concernées.
Cordialement,
Franck.

[JeitEmgie]

Voir "Adaptive Cursor Sharing" sur https://docs.oracle.com/database/121...htm#TGSQL94740

[Mohamed.Houri]

Bonjour,
Je m'aperçois que lorsqu'un plan d'exécution a été stocké lors de la première exécution et concerne une entreprise avec faible volumétrie (notamment sur calendrier), les requêtes suivantes pour les entreprises ayant des données plus riches sont pénalisées...

Quelle est l'approche correcte ici ? Est-ce qu'il faut que j'étudie les plans optimaux et force oracle à les suivre? est ce qu'il faut que j'enlève les bind variables sur mes id_entreprise pour avoir un plan d'exécution différent par entreprise ?

C'est le problème qu'Oracle a voulu adresser en implémentant le Adaptive Cursor Sharing(ACS). Si vous voulez avoir plus de détails sur ACS je vous invite alors à lire gratuitement le chapitre 4 que j'ai écrit dans le livre suivant

https://books.google.fr/books?id=feX...page&q&f=false

Mais pour cela il faut d'abord que votre curseur soit bind sensitive. Pour être bind sensitive, comme mentionné dans le livre, il faut certaines conditions entre autres la colonne de la where clause doit posséder des histogrammes par exemple.

Cependant mon expérience pratique m'a montré que ACS créé plus de problèmes qu'il n'en résout.

Je vous conseille donc, si ce problème est gênant, de trouver le plan d’exécution satisfaisant le plus grand nombre de valeurs des 'bind variables' possible et de le fixer via une SPM (SQL Plan Management).

Bien Cordialement
Mohamed

PS : pour avoir une idée du meilleur plan possible il faut utiliser un script qui montre les statistiques des executions histriques (dba_hist_sqlstat et dba_hist_snapshot)