I have a similar problem as well. The rule what to do is simple:
1) tune app first if can do that. For example, can always create/drop indexes. 2) Else upgrade HW. 3) If you are lucky, something wrong is with DB config.

To tune application:
1. find out most active SQL by block visits:
select kind of buffer_gets/executions, ... from sql_area order by 1
a) If you have 2/3 minutes of activity, so can do the folowing do get deltas:
create table hist_sql as select sysdate cr_date, a.* from v$sqlarea a
then find deltas, ex., most often executed SQL:
select (a.executions-b.executions)/((sysdate-b.cr_date*24*60*60), b.* from hist_sql b, v$sqlarea a where a.HASH_VALUE=b.HASH_VALUE and a.ADDRESS=b.ADDRESS and a.sql_text=b.sql_text
order by 1 desc
b) the same for calculating statistics deltas from v$sysstat, v$sesstat, but this does not help much unless there are obvious anomalies in some sessions: then you can identify which sessions is using x time more of CPU then others and concentrate on that.

2. do a trace and analyse with TKPROF:
a) enable timing with alter system set timed_statistics = true
b) switch on trace for any session you need with:
sys.DBMS_SYSTEM.SET_SQL_TRACE_IN_SESSION(SID, SERIAL,TRUE/FALSE);

c) tkprof in.trc out.trc SORT=(EXEQRY, EXECU, FCHQRY, FCHCU) for visited blocks
tkprof in.trc out.trc SORT=(PRSCPU, EXECPU, FCHCPU) for CPU time, etc

3. PIN stored PL/SQL into shared pool, for systems which use a lot of dynamic SQL it is healthy - if have enough RAM.