Optimize 10gR2 All_rows ou Choose

Bonjour,

Je vous expose ma problématique. J'utilise une base 10.2.0.1 x64 Windows. L'éditeur de logiciel, pour des questions de performances, demande de positionner les paramètres suivants :

optimizer_features_enable=8.1.7
optimizer_index_caching=99
optimizer_index_cost_adj=1
optimizer_mode=CHOOSE
CURSOR_SHARING = "EXACT"

La seule chose qui me gêne c'est de passer du mode ALL_ROWS en CHOOSE.

Qu'en pensez-vous ?
Que faut t'il faire ?

Merci de vos réponses

Cdt

Citation:

---

Envoyé par reivilot

La seule chose qui me gêne c'est de passer du mode ALL_ROWS en CHOOSE.

---

8O tu devrait plutôt t'inquiéter de : optimizer_features_enable=8.1.7 :roll:

pour le CHOOSE c'est pas abérant puisque ALL_ROWS ne devait pas être disponible en 8i tu peux pas mettre une compatibilité 8i avec un optimizer_mode 11g :?

l'éditeur ne parait pas super sérieux... c'est le support qui t'a demandé ça ou un pré-requis du soft ?

optimizer_index_caching=99
optimizer_index_cost_adj=1

c'est n'importe quoi aussi, désormais Oracle fait bien mieux avec les stats systèmes.

A ta place, je passerais outre ces recommandations farfelues :?

Même le cursor_sharing est surprenant :mouarf: En fait, il sont restés bloqués au siècle dernier :aie:

Citation:

---

Envoyé par orafrance

En fait, il sont restés bloqués au siècle dernier :aie:

---

C'est aussi l'impression que ça me donne.

Je pense qu'il faudrait que vous contactiez votre fournisseur pour leur demander quelles raisons ils ont d'en rester à des réglages obsolètes. Vous verrez à ce moment si vous avez un interlocuteur qui sait de quoi il parle (chez les éditeurs, on trouve à la fois de vagues bricoleurs et des gens très pointus en optimisation).

A la limite une appli qui impose le mode RULE, je peux encore comprendre... mais ces paramètres n'ont aucun sens... en effet, la justification qui va avec me parait être la moindre des choses ;)

Pour ma part je dirais que nous avons là un bel exemple d'un beau produit à la française. Depuis le temps que je bosse en SSII j'ai vu passer ce schéma je ne sais combien de fois. Le problème n'a qu'un seul et unique nom : RENTABILITE.

Autrement dit, autant le petit éditeur va peaufiner son bébé car chaque installation est un risque pour sa survie, autant tout gros progiciel lui s'en bat l'oeil avec une force peu commune et il est très courant de voir les DBA exclus du circuit car dans la tête d'énormément de monde un DBA c'est avant tout un luxe couteux et malheureusement nécessaire dédié à l'exploitation.

Ensuite il y a les plus malins, parmi les gros bien sûr, qui vont mettre sciemment des trappes dans leur installation de manière à justifier le support qu'ils vendent à prix d'or. C'est pas qu'ils savent pas, c'est qu'ils maîtrisent mieux que tous l'art de faire des sous...

:roll:

Bref, n'hésite pas à faire confiance à toi même et à tester dans ton coin afin de bien comprendre chaque paramètre que te demande un éditeur...

Citation:

---

Envoyé par reivilot

optimizer_features_enable=8.1.7
optimizer_index_caching=99
optimizer_index_cost_adj=1
optimizer_mode=CHOOSE
CURSOR_SHARING = "EXACT"

---

A la lecture de ces paramètres, j'en déduis que l'éditeur veut forcer impérativement l'utilisation des index et ne veut pas utiliser tout ce que Oracle a mis en place dans les v9 et 10.
Sans doute leur applicatif était réglé au petits oignons dans une ancienne version et ils n'ont pas cherché à le faire évoluer. C'était sans doute optimal avec des nested loops mais Oracle a su évoluer, lui.

Si tu a l'occasion d'avoir une base de test, laisse ses paramètres à leur valeur par défaut en 10g dans cette base et mesure s'il y a écart de performance.

PS : j'espère que ton éditeur ne préconise les tablespaces en dictionnary managed :D

C'est assez fréquent de trouver de petits éditeurs qui veulent rester figer sur une version qui a déja fait ces preuves.

Moi ce qui me choque le plus c'est ca :

Code:

---

CURSOR_SHARING = "EXACT"

---

Parce qu'il ne peut y avoir une justification. Ce seul paramétre obligeant à ne pas reparser uniquement les codes exactes peut être source de problémes de performances.

Je serais vraiment curieux de connaitre les raisons pour ce paramétres

Citation:

---

Envoyé par 13thFloor

Si tu a l'occasion d'avoir une base de test

---

bah j'espère bien quand même qu'il ne va pas migrer la prod directement :aie:

Citation:

---

Envoyé par Jaouad

C'est assez fréquent de trouver de petits éditeurs qui veulent rester figer sur une version qui a déja fait ces preuves.

---

Sauf que l'usage systématique des indexes n'est pas forcément le plus judicieux... le CBO ne choisit pas le FTS uniquement pour embêter les DBA :mouarf:

En parlant d'éditeurs qui veulent rester figés, j'en connais même qui, pour leur produit, supportent la 9.2.0.7 mais pas la 9.2.0.8, et incitent donc à une prestation de migration applicative si on passe en 10g :evilred:

c'est pas forcément idiot puisque la 9.2.0.8 a des bugs connus qui peuvent être facheux... si l'éditeur sait que son développement sera buggé selon le matériel utilisé, c'est tout à fait justifié :)

genre : False ORA-979 from SELECT with GROUP BY and ORDER BY

Citation:

---

Envoyé par orafrance

Sauf que l'usage systématique des indexes n'est pas forcément le plus judicieux... le CBO ne choisit pas le FTS uniquement pour embêter les DBA :mouarf:

---

Personne n'a jamais dit que c'était pertinent , fréd :mouarf: .

Citation:

---

Envoyé par orafrance

c'est pas forcément idiot puisque la 9.2.0.8 a des bugs connus qui peuvent être facheux... si l'éditeur sait que son développement sera buggé selon le matériel utilisé, c'est tout à fait justifié :)

---

Sauf que tu migres en 10G et tu es content, tu as des données financiéres hautement sensible et tu t'apercois que tes ordres SQL simples comme le Select sont faux , ou plus précisément le select te raméne 442 lignes et le insert sur le même select ne t'en raméne que 353 lignes :

Extrait de la TAR :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34

SQL> insert into test2 2 SElect rownum 3 FROM ps_intfc_bi_cmp cmp, ps_b2_revalcalc_vw px, ps_b2_reval_select rev 4 WHERE cmp.invoice = px.invoice 5 AND cmp.line_seq_num = px.line_seq_num 6 AND px.invoice = rev.invoice 7 AND rev.selected_flag = 'Y' 8 AND rev.business_unit = '00300' 9 AND rev.b2_reval_code = 'REV20070021' 10 AND rev.setid = 'MCORE' 11 AND px.setid = 'MCORE' 12 AND px.business_unit = '00300' 13 AND cmp.trans_type_bi = 'LINE' 14 AND ROUND (px.price, 3) <> 0 ;   353 ligne(s) créée(s).     SQL> SeLecT count (*) 2 FROM ps_intfc_bi_cmp cmp, ps_b2_revalcalc_vw px, ps_b2_reval_select rev 3 WHERE cmp.invoice = px.invoice 4 AND cmp.line_seq_num = px.line_seq_num 5 aND px.invoice = rev.invoice 6 AND rev.selected_flag = 'Y' 7 AND rev.business_unit = '00300' 8 AND rev.b2_reval_code = 'REV20070021' 9 AND rev.setid = 'MCORE' 10 AND px.setid = 'MCORE' 11 AND px.business_unit = '00300' 12 AND cmp.trans_type_bi = 'LINE' 13 AND ROUND (px.price, 3) <> 0 14 ;   442 ligne(s) créée(s).

---

Pour info :
Le paramétre en cause : _table_lookup_prefetch_size

https://metalink.oracle.com/metalink...,1,1,helvetica

Citation:

---

Envoyé par Jaouad

Sauf que tu migres en 10G et tu es content, tu as des données financiéres hautement sensible et tu t'apercois que tes ordres SQL simples comme le Select sont faux , ou plus précisément le select te raméne 442 lignes et le insert sur le même select ne t'en raméne que 353 lignes

---

bah oui, il n'y a pas encore de version sans bug :aie:

mais je fais une différence entre un bug qui impacte tous les dévs sur un type de requête très souvent utilisé et un bug du noyau ;)

effectivement , mais les conséquences sont les mêmes .

Elles sont même pire dans le cas du mauvais nombre Select, puisque tu as l'impression que tout vas bien puisque tu n'as pas d'erreur Oracle alors que tes données sont fausses.

Citation:

---

Envoyé par Jaouad

C'est assez fréquent de trouver de petits éditeurs qui veulent rester figer sur une version qui a déja fait ces preuves.

Moi ce qui me choque le plus c'est ca :

Code:

---

CURSOR_SHARING = "EXACT"

---

Parce qu'il ne peut y avoir une justification. Ce seul paramétre obligeant à ne pas reparser uniquement les codes exactes peut être source de problémes de performances.

Je serais vraiment curieux de connaitre les raisons pour ce paramétres

---

Je vois au moins une justification: si le SQL utilise correctement les bind variables, il ne devrait pas être nécessaire de changer la valeur de CURSOR_SHARING (dont EXACT est bien la valeur par défaut). Le Performance and Tuning Guide dit clairement:

Citation:

---

The optimal solution is to write sharable SQL, rather than rely on the CURSOR_SHARING parameter. This is because although CURSOR_SHARING does significantly reduce the amount of resources used by eliminating hard parses, it requires some extra work as a part of the soft parse to find a similar statement in the shared pool.

---

Ou dit d'une autre façon dans le Designing applications for performance and scalability:

Citation:

---

It is highly recommended not to write applications dependent on this parameter,
and to use the parameter only when needed for existing applications incorrectly
using literals

---

en attendant on n'a plus de nouvelle du posteur :(

Sans vouloir me la jouer, il a dû s'arrêter à mon conseil.

Citation:

---

Bref, n'hésite pas à faire confiance à toi même et à tester dans ton coin afin de bien comprendre chaque paramètre que te demande un éditeur...

---

:mouarf:

Bonjour à tous,

Merci pour l'ensemble de vos réponses.
Désolé pour ne pas avoir répondu plus tôt vacances oblige.
J'ai posé quelques questions à l'éditeur, j'attends et vous tiens informé des ses réponses

Bonjour,

Voici la réponse de l'éditeur

Dans le cas où votre instance est une instance Oracle dédiée , les paramètres Oracle envoyés précédement sont les mieux adaptés.

Dans le cas où l'instance n'est pas dédiée, voici les paramètres à mettre en place :
optimizer_features_enable : 10.2.0.1
optimizer_index_caching: 90
optimizer_index_cost_adj : 50
optimizer_mode : ALL_ROWS
CURSOR_SHARING : EXACT