Envy, envy ... Upgrade without a harsh justification... Well, surely, this db config appears to be ** questionable ** at least. Some points :

a) sort_area_size of just 2 Mb, with SO MUCH RAM available ???? ANy special desire for disk sorts , here ?

b) hash_area_size around 10 Mb, BUT without hash_multiblock_io_count ? MAYBE this could be correct, but many times, not. And talkink about blocked I/O, how about db_file_multiblock_read_count, sort_multiblock_read_count, this WAS considered / analyzed ??

c) with SO MUCH ram, how about a keep pool ?? And a bigger large_pool_size , maybe ?

d) you REALLY want a timeout for logs, sometimes this will NOT be the best approach, maybe log files of BIG sizes, NO timeout and a even bigger log_checkpoint_interval would be better

e) NO timed_statistics ??? the performance impact of this parameters is REALLY small in recent versions of Oracle dbs, and the info is SO EXTREMELY useful and important what I leave it activated in ALL my dbs

f) cursor_sharing ??? This is just a BIG and UGLY "crutch" to a ILL-CONFORMED app, and it CAN bring collateral bad effects, SPECIALLY in internal db SQLs, see http://asktom.oracle.com/pls/ask/f?p...:3696883368520 for some examples. IF this is a PROD system, DEMAND corrections from the system producer.


In resume, BRING URGENTLY a DBA here, many possible improvements are showing.

Regards,

Chiappa