RECOMMENDATION 1: Application Analysis, 31% benefit (140 seconds)
ACTION: Investigate application logic for possible reduction in the
number of COMMIT operations by increasing the size of transactions.
RATIONALE: The application was performing 88 transactions per minute
with an average redo size of 3265 bytes per transaction.

RECOMMENDATION 2: Host Configuration, 31% benefit (140 seconds)
ACTION: Investigate the possibility of improving the performance of I/O
to the online redo log files.
RATIONALE: The average size of writes to the online redo log files was 3
K and the average time per write was 17 milliseconds.

FINDING 3: 27% impact (124 seconds)
-----------------------------------
SQL statements with the same text were not shared because of cursor
environment mismatch. This resulted in additional hard parses which were
consuming significant database time.

1) As the recommendation says, decrease frequency of COMMIT by committing a larger portion of a transaction instead of each individual statement. You may also get benefited by setting COMMIT_WRITE parameter. Read more about this parameter in docs as this will have adverse affects when recovery is required.

Infact we have 2 Disks which are mirrored, All the Datafiles, Controlfile and Redo log files are on that mirrrored Disk. Server Can accomoadate maximum 3 Disks only.....so we have kept all the files in that mirrored disk...

Reducing commit count is general recommendation for resolving log file I/O contention.
But it's not easy to reduce commit count in general applications.
In this case, enhancing I/O performance will be a good alternative.

2. As recommendations says, why don't you investigate v$sql_shared_cursor view?
Your SQLs seem to have high version count because of some kinds of mismatches.
For instance, bind mismatch has a bad reputation for unshareable child LCOs especially for insert statement with a long bind variable list.
v$sql_shared_cursor view will show you the exact picture.