Following the recommendation we got.
In brief
What can be implemented:
move each redo group to a separate non raid5, faster disk
move user tables from dictionary to locally managed tablespaces
What should be implemented if possible
change the application to reduce the number of commits
Following the text of the recommendations from the tar

High recursive CPU usage due to PL/SQL.
-----------------------------------------------------------

Statements in the "Top SQL Statements by Buffer Gets" should be tuned .
obtain SQL Trace / TKProf data from typical user sessions and look for statements comsuming the highest CPU. The "sort=fchcpu" option of TKProf is usually helpful in finding the worst statements.


High recursive CPU usage due to Oracle system operations
------------------------------------------------------------------------------------

In the "Dictionary Cache Statistics" table we notice : indicate space management operations are occuring and locally managed tablespaces should be used).


Get Pct Scan Pct Mod Final Pct
Cache Requests Miss Requests Miss Req Usage SGA
---------------------- ------------ ------ -------- ----- -------- ------ ----
dc_free_extents 53 11.3 3 0.0 15 10 37
dc_used_extents 6 50.0 0 6 21 62

These statistics indicate that space management operations are occuring and locally managed tablespaces should be used

2/ log file sync

To reduce this wait , you can make tuning at 2 levels

Application level:
-------------------------

if the application commit after every INSERT, rather than batching COMMITs. Applications can reduce this wait by committing after inserting a number of rows, rather than every row.

System level
------------------

use dedicated disks.
Move the redolog files from RAID 5 devices. RAID 5 is not efficient for writes.
Alternate redo logs on different disks to minimize the effect of the archiver on the log writer