Discussion :

[Ikebukuro]

Hello,

Je dois optimiser des requêtes sur une base Siebel.
Sur une base Oracle je sais faire, sur Siebel je découvre des normes qui me posent de gros problèmes :
1) Les stats ne sont calculées que sur certaines tables, identifiées via l'exécution d'un script officiel Oracle
2) Le paramètre optimizer_index_cost_adj est à 1 (FORTEMENT recommandé par Oracle dans un white paper)

Résultat : je me retrouve avec des requêtes qui n'utilisent QUE des index, 20 000 blocs lus sur disque dur et 500 000 en mémoire pour ramener UNE SEULE ligne d'un SELECT, des Estimated rows à 1 mais un Actual rows à 8000...

Bref, par rapport aux contraintes très fortes imposées sur Siebel, je me résous à lancer le SQL Tuning Advisor qui trouve parfois (pas toujours) un meilleur plan mais sans que ce soit bouleversant.

Est-ce que vous auriez des retours d'expérience pour me dire comment tuner des requêtes Siebel? Faut-il remettre le paramètre optimizer_index_cost_adj à 100 pour éviter de court-circuiter le CBO?
Faut-il calculer les stats de toutes les tables du schéma Siebel? Faut-il plutôt lancer le SQL Access Advisor etc etc?


Par avance un gros merci pour votre aide

[pachot]

Bonjour,
Peut-être voir ce que ça donne en remettant tout paramètre d'optimiseur à sa valeur par défaut et peut-être fixer quelques rapports avec des profiles.
Mais, oui, Siebel est un catastrophe...

[Ikebukuro]

Malheureusement le client ne veut pas toucher à ce paramètre... il va falloir que je pique une grosse gueulante mais je suis d'accord, c'est la première chose qu'il aurait fallu faire avec le recalcul des stats.
Sinon, content de lire que ce logiciel est une catastrophe; pour tout dire, j'ai vu des requêtes avec 31 tables dans le FROM, soit 8,22283865417792281772556288e+33 combinaisons possibles comment tu veux que le CBO trouve un bon plan avec ça!

[13thFloor]

...c'est la première chose qu'il aurait fallu faire avec le recalcul des stats.

Hello,
pas tout le temps.
J'ai connu un cas, avec JD Edwards, où il ne fallait pas de stats sur certaines tables.
Un DBA était intervenu chez mon ancien client et avait remarqué qu'il manquait certaines stats => allez hop, gather_table_stat.
Et patatra le lendemain ! Certains batchs étaient en retard. Le progiciel était optimisé de telle façon que les stats ajoutées mettaient le bazar.
Retour en arrière. Bon, ok, il s'agissait d'une version 9i.

Avec les versions récentes et le dynamic sampling activé par défaut, les stats seront calculées (ou plutôt échantillonnées) à la volée.

Prudence quand on ne respecte pas les pré-requis éditeur (même s'ils semblent inadéquats).

Tu peux néanmoins hinter (avec optimizer_index_cost_adj) certaines requêtes et comparer le résultats. Tu auras des arguments pour envisager un chagement de paramètre mais il sera global à la DB et il y aura des risques de dégradation.
Après, tant que le paramètre n'est pas mandatory, mais seulement recommended...

[Ikebukuro]

Le problème est surtout que ce paramétrage à 1 et l'absence de stats sur des tables de moins de 15 lignes (ce sont les recos Oracle) mettent le CBO à terre, d'après mes observations.

Par exemple dans le Cloud Control, le plan d'exécution monitoré montre pour un SELECT des étapes avec "Estimated Rows" à 1 mais "Actual Rows" à 8 000 ==> comment veux-tu que le CBO calcule un bon plan avec de telles stats?
Autre choses, quand je regarde les stats d'un SELECT avec une vingtaine de tables, je tombe souvent, pour une ligne ramenée, aux stats suivantes : 20 000 Physical Read et 500 000 Consistents Gets. On est quand même à 4 Go de données lues (500 000 * 8 Ko) pour afficher une ligne; c'est un gâchis immonde!

Et quand j'utilise le SQL Tuning Advisor, soit il ne propose rien, soit il dit qu'il manque des stats sur une table et il s'arrête soit il propose un plan permettant de gagner 2% :-(