Index manquants sur tables de TRCANLZR ?

Bonjour,

Dans le cadre d'une migration d'un outil fondé sur Oracle (EIS de la gamme Oracle EPM), je constate que sur mon nouveau serveur une requête est considérablement plus lente que sur l'ancien, avec en outre un plan d'exécution différent (un enchaînement de NESTED JOIN sur le nouveau, un HASH JOIN sur l'ancien).

J'ai donc commencé par comparer les index, et je constate que l'ancienne a deux index de plus que la nouvelle :

• TRCA$_PLAN_TABLE_N1 sur la table TRCANLZR.TRCA$_PLAN_TABLE
• TRCA$_TABLES_PK sur la table TRCANLZR.TRCA$_TABLES

Est-ce que ça veut dire que l'optimiseur est mal déployé, ce qui explique les différences de comportement, ou bien est-ce totalement anecdotique ?

Merci d'avance pour toute contribution !

HASH JOIN sur l'ancien signifie que les index n'étaient probablement pas utilisés pour les jointures.
NESTED JOIN sur le nouveau signifie très probablement des statistiques à 0 !

Salut Waldar, et merci de ta réponse.

Du coup, qu'est-ce que je devrais faire pour que le nouveau se comporte comme l'ancien ?

C'est une piste qu'il faut confirmer, en regardant si les statistiques sont bien à jour sur le nouvel environnement.
Ou dans la plan d'exécution, si en nombre de lignes estimées il y a 0 ou 1, ça va dans ce sens.

Dans ce cas, il faut recalculer les stats :

Code:

---

1 2 3 4 5 6 7 8

begin dbms_stats.gather_schema_stats ( owname => 'TRCANLZR' , options => 'GATHER AUTO' , degree => 8 ); end; /

---

OK, je te remercie.

Autre question liée : sur l'ancien serveur (qui fonctionne), mon appli utilise une chaîne de connexion qui est rédigée sur ce modèle :

Code:

---

DSN=Oracle:TOTO;CODEPAGE=English.Latin1@Binary;UID=alibaba;PWD=sesame;

---

Habituellement avec cette appli j'ai des chaînes de connexion sur le modèle ci-dessous, avec TITI qui référence un ODBC.

Code:

---

DSN=TITI;CODEPAGE=English.Latin1@Binary;UID=alibaba;PWD=sesame;

---

As-tu une idée de ce que représente ce Oracle: ? Mon objectif final est de forcer l'appli à utiliser un OCI plutôt qu'un ODBC, mais je ne sais pas à quoi fait référence le TOTO de mon premier exemple...

Pas d'idée pour celui-ci, désolé !

C'est assez significatif que tu ne connaisses pas, ça doit vouloir dire que c'est une syntaxe spécifique à mon applicatif...

Ah pas du tout, le paramétrage de connexion ce n'est vraiment pas mon fort.

Citation:

---

Envoyé par Waldar

HASH JOIN sur l'ancien signifie que les index n'étaient probablement pas utilisés pour les jointures.
NESTED JOIN sur le nouveau signifie très probablement des statistiques à 0 !

---

Quand tu dis des statistiques à 0, ça implique quoi ?

Que l'optimiseur pense que la table est vide alors que ce n'est pas le cas, ça se voit bien dans le plan d'exécution (E-Rows = 0), en regardant les statistiques de la table avec un outil type Toad ou SQL Developer ou en exécutant une requête de ce genre :

Code:

---

1 2 3

select table_name, tablespace_name, last_analyzed from all_tables where owner = 'TRCANLZR';

---

Donc, si je comprends bien, quand il pense que la table est vide il fait un NESTED JOIN au cas où il y ait des données quand même ?

Difficile de réduire toute la complexité de l'optimiseur à cette phrase, mais oui c'est une possibilité.
Une autre pourrait être des index pas très efficaces.

Le mieux à faire c'est de comparer les plans d'exécutions réel (avec l'hint gather_statistics) voire la trace serveur.