SQL Performance tuning advice

The SQL is application generated (peoplesoft) and has a number literals which change every time it is run, so SQL Plan management can't be used. Are there any options for controlling the execution plans of parts of SQL statements? SQL Plan Directives seem like the solution here. Apart from seeing how many were used in a plan there doesn't seem to be any way to find out what they are or what impact they had. I note the non-production (faster) plan (from dbms_xplan) says 19 baselines were used, where production (slower) says there were 18, so I wonder if one has disappeared somehow (though I thought this wasn't supposed to happen). Is there a way to find out what differences in SQL plan directives exist between fast and slow environments? This is complicated further as we are hitting bug 29937655 meaning we have millions of directives, and setting _fix_control='29937655:ON' doesn't seem to have helped us. I took a copy of production to try to reproduce the slow plan in a test database, but the fast plan is selected.

We get issues with this area periodically, especially during upgrades, and I tend to spend a long time looking at explain plans without getting very far, so I would appreciate pointers to a good approach. I have identified one part of the plan that is slow, but I am struggling to think how to tell the database to use the faster plan when the SQL keeps changing. Using the SQL from Oracle Base to look at the SQL Plan Directives returns over 300,000 rows, and it is very slow, so it's not useful to work out what was actually used.

I will take a look at the columns being joined and see if I can add some extended stats to get better cardinality. It's really irritating that I can't reproduce the issue in a non-production database, so I can't try things out.

As I say, if anyone has pointers as to an approach I could take I would be very grateful to hear them!

Database is version 19.23

--
http://www.freelists.org/webpage/oracle-l