Il y a des années, j'ai travaillé sur une base de données DR qui était entièrement en LECTURE SEULE, et même l'espace de table TEMP n'était pas accessible en écriture. Toute requête qui tentait de se déverser sur temp échouait (même si l'espace temp à utiliser était assez trivial).
Si c'est la même situation, je ne serais pas surpris s'il y avait un login.sql (ou glogin.sql ou un déclencheur de connexion) qui fait une ALTER SESSION pour définir une plus grande valeur de mémoire PGA pour la session, et/ou change le objectif de l'optimiseur sur FIRST_ROWS.
Si vous le pouvez, comparez les résultats des éléments suivants des deux clients :
select * from v$parameterwhere ismodified !='FALSE';
Également à partir de chaque client pour le problème SQL, essayez EXPLAIN PLAN FOR SELECT...et SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);
Voyez s'il propose différents plans de requête.
