Bouclage d'un script sous Oracle application

Bonjour les forumistes ...
Les utilisateurs ont envoyé un script sur oracle application : OK
Ce script est très long, et j'aimerai voir ce qu'il fait (Je n'ai pas accès au source programme) : OK

Sur oracle appli il trouve bien 2 traitements simultanés dans le STANDARD MANAGER:
- JEFB_SUBMIT (demandeur SCHEMATOTO)
et
- Mon traitement en cours (demandeur BATCH)
OK...

Sur TOAD... quand je choisi 'SESSIONS ACTIVES' je n'arrive pas à voir mon traitement qui boucle, alors que JEFB_SUBMIT est bien présent dans le pannel 'SESSION BROWSER'..
Quand je choisi 'SESSIONS INACTIVES' j'ai bien toutes les sessions mais je ne trouve pas non plus ma session qui boucle...

Question:
1°) Comment faire pour voir les ordres SQL de mon traitement qui boucle ?
2°) Est-ce possible ou bien ce raitement est-il un sous traitement de JEFB_SUBMIT et qu'il ne me donne pas le droit de la voir (Ce qui serait un comble !)
3°) Puis-je alors voir ce qu'il y a dans mon traitement qui boucle, à partir d'Oracle Appli et comment ?

Merci pour vos réponses car là, je cale complètement !

1°) tu peux cocher la case Active trace dans la définition du concurrent program
2°) ça peut être un fils de JEFB_SUBMIT mais il peut aussi tout simplement manquer un EXIT à la fin :?
3°) non, il faut aller le voir sur le serveur. Dans le panneau EXECUTABLE, l'application de permet de retrouver le répertoire (General Ledgber = GL :arrow: $GL_TOP) et le nom du SQL lancé.

Merci Fred pour tes réponses mais... je n'ai pas trop compris les manips !
Saches que tu t'adresses à un très petit scarabée sur 'Oracle Application'...
J'ai donc 3 autres questions sur tes réponses ...
1°) Je n'ai pas trouvé de case 'Active trace' dans 'concurrent program' ... est-ce d

Je recommence...

Merci Fred pour tes réponses mais... je n'ai pas trop compris les manips !
Saches que tu t'adresses à un très petit scarabée sur 'Oracle Application'...
J'ai donc 3 autres questions sur tes réponses ...
1°) Je n'ai pas trouvé de case 'Active trace' dans 'concurrent program' ... est-ce dans le pannel 'Administrateur system', 'simultané' etc... et si oui, où ?
2°) Comment savoir que c'est un fils de JEFB_SUBMIT ?

quand tu dis :

Citation:

---

3°) non, il faut aller le voir sur le serveur. Dans le panneau EXECUTABLE, l'application de permet de retrouver le répertoire (General Ledgber = GL $GL_TOP) et le nom du SQL lancé.

---

Là, c'est la big panade...

Je suis allé sur 'Administrateur GL Bancaire' et j'ai vu les options suivantes :
+ Piece
+ budget
+ etat
+ rechercher
+ configurer
+ devise
+ consolidation
+ autre
1°) faut-il aller sur 'administrateur GL quand tu me parles de 'General Ledger' ? Mais là, je ne trouve pas de paneau 'executable' !
2°) Ou puis-je trouver ce $GL_TOP ?
3°) Faut-il se servir de OAM tant on m'a dit quer le logiciel était buggé ?

4°) J'ai essayé de trouver les exécutables... dans option 'Administrer system' je trouve bien les 'traitements' qui tournent mais pour le code sql des programmes, j'ai pas trouvé ...

Sans vouloir te déranger, peux-tu m'en dire un peu plus ?
Merci d'avance pour tes réponses...

1°) Sytem Administrator -> Concurrent -> Program -> Define :arrow: Enable Trace
2°) faut demander au dév et/ou analyste
3°) euh... j'suis désolé mais si tu n'y connais absolument rien, t'auras du mal à t'en sortir... j'vais pas pouvoir te former via le forum :?

Par exemple, recherche le programme : Purge Concurrent Request and/or Manager Data, l'exécutable s'appelle Purge Requests and/or Managers. Quand tu cherches cet exécutable, tu vois que l'appli est Application Object Library et le spawned (binaire) s'appelle FNDCPPUR.

Maintenant tu vas dans le panneau Application -> Register, et tu cherches Application Object Library. Basepath est FND_TOP.

Sous Unix, tu te connecte avec le user applicatif (applmgr par exemple) et tu vas dans le répertoire $FND_TOP/bin (bin = spawned). Ici tu dois trouver le fichier FNDCPPUR. Et bien si c'était un exécutable SQL*Plus, tu l'aurais trouvé dans FND_TOP/sql.

OAM fonctionne pas trop mal et peut être très utile. La stabilité dépend de sa version, la 2.3 est très compléte.

Je ne saurais trop te conseiller de lire le guide d'administration que tu trouveras dans l'onglet OA 11i de Metalink ;)

Merci pour tes réponses, je verrais ça demain !
Une dernière question... suite à mon traitement qui prend un temps fou (8heures pour un select) j'ai effectué un explain sur mon ordre SQL et, il a l'air bon... il n'y a qu'un 'table acces full' sur une toute petite table... le reste à l'air correct...
Je me suis rendu compte que la taille de ma SORT_AREA_SIZE est ridicule (65536 K) ... peux-tu me confirmer que le problème de perf peut venir de là ?

Je te souhaite une excellente soirée !

En principe en 11i tu passes par la PGA donc la SAZ n'a plus d'importance. Tu peux vérifier plusieurs choses :
- Tablespace en Locally Managed plutôt que DICTIONARY
- Stats à jour (Concurrent Program : Gather Schema Statistics)
- Si tu es en 9i (ça devrait être le cas), calcul les stats sur SYS

Enfin, vérifie les waits et les events comme je te l'ai déjà dit ;)

Merci pour toutes tes explications... effectivement je suis en train de ma farcir le guide d'admin... puis-je encore t'embêter sur un truc ?
J'ai beau suivre tes indications à la lettre, mes recherches d'exécutables sont infructueuses...
Je t'ai rattaché un format word qui t'en dira plus... peux-tu me dire où j'ai fait une bêtise...

"suis-je neuneu ? "

Oui :aie:

F11 pour entrer en mode recherche, tu tapes le nom du programme et CTRL+F11 pour lancer la recherche ;)

PS : tu serais pas à Marseille par hasard ? :mouarf:

Euh non, je serais plutôt supporter du SECB... Sporting Etoile Club Bastiais... et c'est bien pire !

En tout cas, je te remercie pour tous tes conseils !

Si je peux encore abuser ...
Voilà, suite à mes dbms-stats-gather d'hier (entre autres sur le schéma SYSTEM) sur notre base de prod un traitement d'imputation est bloqué, et il bloque tous les autres...
Je ne sais quoi penser car, j'ai cru effectuer les bonnes manip et patatras ça plante...
Je t'envoie un word avec des copies d'écran afin de te montrer ce qui ne va pas... le traitement d'imputation qui bloque, passe normalement très bien, tous les jours...
Les utilisateurs me disent qu'après tatonnement (passage de dbms-stats-gather à 30 % et ensuite re-passage d'analyze à 20 %) quelquefois ça passe tranquillement... sans bloquer..
Etant un informaticien averti, cela m'é"tonne quand même ...
Verrais-tu, après avoir lu mon word, une action à faire afin de débloquer cette imputation... car je ne crois pas aux vertus des analyzes modifiés...
1°) Faut-il que je retire les analyse d'hier sur mon schéma system ?
2°) Help me !
Merci encore pour tes explications ...

Sur SYSTEM ? 8O

Attends, tu peux le faire sur SYS mais seulement à partir de Oracle 9i et OA 11i SURTOUT PAS AVANT... quand à SYSTEM, j'vois pas l'intérêt :koi:

100% de lecture physique ça sent le cache trop petit :? et quasiment 13 millions d'I/O, ça m'étonne pas que ça rame :?

Vérifie tes stats sur GL surtout.

Ok pour le SYS... autant pour moi !
Les stats sur GL, GLCO et GLCA sont d'aujourd'hui... en fait sur metalink quand tu fais la recherche sur glpini, qui a été détecté dans le journal, ils disent d'effectuer un truncate de la table GL_date_PERIOD_MAP et de la recréer avec le programme GLUABCAL.sql ...
D'après toi est-ce une bonne solution ?
L'as-tu déjà fait ?

Merci encore ...

je me garderais bien de contredire Metalink :mouarf:

Il doit d'agir de faire redescendre la HWM mais je suis sceptique... ça doit pas faire de mal remarque. Mais encore une fois, sans les événements d'attente point de salut... statpack et v$session_wait sont tes amis :mrgreen: