Performance issue with multiple installations of 1 application in 1 databas

Question

In our company we use JD Edwards. Every branch has its own JD Edwards installation in a separate schema but in the same database (Oracle9i Enterprise Edition Release 9.2.0.7.0) => In 1 database there are 10-20 copies of each table.
On top of JD Edwards we are developing a Java/JSP application which accesses the JD Edwards data by means of pl/sql stored functions returning ref_cursors. Our DBA states we have to prefix all our tables/views within our stored functions for performance reasons. According to him omitting the schema name would result in increase of hard parses, because the shared_pool can only store 1 occurrence of an sql statement. So only the statement of 1 branch is cached. The execution of the same statement in anothers schema would lead to a hard parse and not to a soft parse.
For us developers the use of schema names complicates the development process, because we have to use a substitution parameter (&schema_name) in our coding which prevents us from maintaining our code in tools like Toad.
Questions
* Does it make sense to use the schema name in this case?
* Is there another way (not using schema names) to get a good performance in this situation?
Thanks,
Matthieu de Graaf

Answer 1

1) I'm not a JD Edwards person, but I would wager that if you're to the point where you have consolidated all the schemas to a single instance that it would be possible and preferrable to consolidate everything further into a single schema. I have to believe that JD Edwards provides tools to restrict what bits a particular branch can see without requiring separate instances.
2) What data are you accessing exactly? Are you always accessing data for a particular branch? Or do you need information from every branch?
3) Is your application logging in as a single user? Or will there be 1 application user for every JD Edwards schema?
4) Are you deploying your PL/SQL into 10-20 different schemas? Or into just 1?
Whether or not you are explicitly using the schema name, Oracle will have to do a hard parse of every logically distinct SQL statement. Two SQL statements that access different tables that happen to share the same name are logically distinct, so your shared pool will end up with 10-20 copies of the "SELECT * FROM <<some table name>>" SQL statement if it is executed against every instance of <<some table name>>.
The question may be whether it is better to explicitly provide the schema name or to rely on synonyms. You generate the same number of hard parses either way, but explicit schema names may improve latch contention during parses if Oracle has to do a lot of synonym resolution. Not many people/ applications are really hurt by this latch contention, though, so it is very hard to say whether this is a legitimate concern.
Justin