Discussion :

[DIJON]

ORACLE 7.3
est-ce que quelqu'un sait s'il y a un paramètre spécifique à renseigner dans le fichier de configuration ORACLE pour pouvoir utiliser plusieurs sous-select dans la clause FROM ?

j'ai une requête avec 3 sous-select qui passe très bien sur un serveur de test (également en 7.3) et qui ne rend jamais la main sur notre serveur de prod (la session disparait et l'appli est sans réponse)
avec 2 sous-select cela ne passe pas non plus, avec 1 seul c'est ok

merci de votre aide

[orafrance]

c'est un problème de perf pas de syntaxe. Vérifie que la volumétrie est la même et que les indexes sont bien créés à l'identique.

[DIJON]

c'est un problème de perf pas de syntaxe. Vérifie que la volumétrie est la même et que les indexes sont bien créés à l'identique.

la volumétrie est la même, le USER de la base réelle a été dupliqué sur la base de test,
la requête retourne 400 lignes en 15 secondes sur la BDD de test,

je pense qu'il s'agit d'un problème avec l'optimizer qui rend son tablier devant une requête trop complexe : 3 sous-select + 5 tables dans la clause FROM
après vérification des paramètres :
optimizer_search_limit = 5 sur la BDD réelle n'est pas défini sur la BDD de test
timed_statistics = true sur BDD réelle et = False sur BDD de test
log_archive_start = true sur BDD réelle et = False sur BDD de test

cela peut-il avoir une incidence ?

je pense qu'une solution serait de zapper l'optimizer, mais j'ai du mal avec la doc en anglais, où puis-je trouver de la doc en français sur les HINT ?

[orafrance]

timed_statistics peut-être optimizer_search_limit probablement pas puisque 5 est la valeur par défaut... éventuellement essaye 10

log_archive_start n'a rien à voir avec les perfs

[mnitu]

D'accord timed_statistics ajout un surcharge mais mais j'ai de doute que c'est lui la cause.

Il n'est pas clair si sur le serveur de production la requête s'exécute ou pas, si non quelle est l'erreur ?

Donc je pense que pour le serveur de test l'optimiseur des requêtes travail en mode règle et probablement en mode coût sur la base de production. Il est simple de vérifier par un hint SQL sur la base de production:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
select /*+ RULE */ col1, col2, ... from ...

[orafrance]

Je ne pensais pas que le CBO était dispo en 7.3... faudrait en effet vérifier l'optimizer mode

[DIJON]

Il n'est pas clair si sur le serveur de production la requête s'exécute ou pas, si non quelle est l'erreur ?

Donc je pense que pour le serveur de test l'optimiseur des requêtes travail en mode règle et probablement en mode coût sur la base de production. Il est simple de vérifier par un hint SQL sur la base de production:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
select /*+ RULE */ col1, col2, ... from ...

il n'y a aucun message d'erreur, la session est virée sans autre explication,

sinon les EXPLAIN PLAN sont les mêmes (sans hint) sur les 2 BDD,

le hint /*+ RULE */ n'est pas reconnu sur la BDD d'epxloitation : aucun changement dans l'EXPLAIN PLAN alors qu'il est amélioré sur la BDD de test

je pense qu'il s'agit bien d'un problème avec l'optimizer et les stats

[dyvim]

je pense qu'une solution serait de zapper l'optimizer, mais j'ai du mal avec la doc en anglais, où puis-je trouver de la doc en français sur les HINT ?

Si tu veux juste te passer de l'optimiseur, tu peux utiliser /*+ RULE */.
Quand à la doc Oracle officielle elle est malheureusement uniquement disponible en anglais à ma connaissance.
(attention les hints ne sont pas recommandés... peut être qu'il te faut juste mettre à jour les stats)
Quoi que je suis en train de me demander si l'optimiseur ne fonctionne pas forcément en mode RULE (c'est à dire utilisation des index en priorité) en version 7.3