I want to understand What exactly User calls and Executes suggests in above load-profile for awr snap which is taken for 30 min interval. Do they have any relation in between?
I got almost double Executes than User-calls, what does that suggest ?

A related question on awr ...Is that any script to get 'Top 5 Timed Foreground Events' section of AWR in SQLPLUS ?

That was really good observation.Answer for the same might reside in AWR Instance Efficiency Percentages ( Execute to Parse % , Soft Parse %).
It would be better if 958830 can post Instance Efficiency section of the same AWR report to make some conclusion

I want to understand What exactly User calls and Executes suggests in above load-profile for awr snap which is taken for 30 min interval. Do they have any relation in between?

Sometimes you can make some sensible guesses by comparing user calls with parses and executes, but sometimes there's very little implied by the values. In this case we can see that you're doing a lot of them, and hope that you have a fairly high powered machine that can cope, but apart from general business there's little more to say.

User calls from from a client program to the server - and typically consist of parse calls, execute calls and fetch calls - and Oracle doesn't maintain a global count of fetch calls - with commits and rollback calls as a possibility. Depending on version of Oracle, the client code generator, and various session-related parameters, there could be many ways in which figures like yours could appear.

Example - your user calls could have been a few parse calls and executes per second, with thousands of fetches per second, while most of the parses and executes could have been the result of PL/SQL function calls inside a few pl/sql packages that you may have called.

I got almost double Executes than User-calls, what does that suggest ?

Other way round. The only thing we can say about your figures is that since parses + executes > user calls, you must have had some code in the database generating recursive calls (not necessarily sys-recursive).

That was really good observation.Answer for the same might reside in AWR Instance Efficiency Percentages ( Execute to Parse % , Soft Parse %).
It would be better if 958830 can post Instance Efficiency section of the same AWR report to make some conclusion

The instance efficiency figures are virtually useless.
We've got the parse cound and execute count in load profile so, allowing for a little rounding error, we can work out the "Execute to Parse %", and we also have the hard parse count, so we can work out the "Soft Parse %"

What we need to see to get some idea of what's going on is a subset of the Instance Activity figures - the OP might be interested in the session cursor cache hits because in this version of Oracle parse calls which are satisfied through the session cursor cache don't increment the cache hit count - and the SQL Ordered by Parse Count and Execution Count.

I have session_cached_cursors=50 which i am sure a very small number and worth incrementing it to leverage softer soft parse. If i increase it, should i expect few parse calls ?
open_cursors is set to 600. Max open_Cursors ('opened cursors current') i found is 2 for most of the sessions.

My OLTP system got 1400 hibernate connections which stays connected all time. Talking about fetch calls, most of them are 'single row returned' sqls. However, such select have very large executions/sec. ~250 connections are commit single record per every second (update statement). That almost matches with TRANSACTION/SEC count.

User call is a request from client to server like parse, execute and fetch, so for example it has hard parses included sisnt it ?

Exections if they are large per user call means lets say function in plsql is called too often in 1 call because of a bad plan, In such cases looking into “SQL ordered by executions” will be the logical next step.

You pointed out that your question was simply to acquire knowledge, so here are a few thoughts that might help:

I have session_cached_cursors=50 which i am sure a very small number and worth incrementing it to leverage softer soft parse. If i increase it, should i expect few parse calls ?
open_cursors is set to 600. Max open_Cursors ('opened cursors current') i found is 2 for most of the sessions.

If you have 1,400 Hiberbate connections that are always open, but most of them only have 2 open cursors most of the time then you've probably got far more connections open than you need. (This is a common error - picking a suitable number of connections, and queueing method, depends on the envirnoment, application, and resources available).

Queries against V$sysstat (et. al.) give cumulative results since startup - they are usually a total waste of time.
Ratios hide scale, they are usually a total waste of time
In this version of Oracle a call that goes through the session cursor cache does NOT get recorded as a "parse count (total)" - so your "soft parses" calculation is wrong (though it would be right in (e.g.) 10gR2)

My OLTP system got 1400 hibernate connections which stays connected all time. Talking about fetch calls, most of them are 'single row returned' sqls. However, such select have very large executions/sec. ~250 connections are commit single record per every second (update statement). That almost matches with TRANSACTION/SEC count.

Was this a standard 1 hour snapshot - if so there are a lot of "missing" statement. Your parse list here shows less than 1M calls, but your load profile shows 4,700 per second - even assuming the AWR has show 16 more statements at 80,000 calls per statement, it's still showing only about 8 minutes worth of parse calls: so I'd be interested in where the rest are going. (Similar arithmetic applies to the execute counts - AWR seems to have captured a small percentage of the total).

Increasing the session_cached_cursors parameter may reduce the number of parse calls reported (and improving the efficiency a little) - but it does depend on how hibernate is calling the database - it may be doing a "reset session state" and clearing all session information after each little piece of work, so you may see very little difference - but it won't cost you anything to try.

I wouldn't be surprised, by the way, if the 'select HIBERBATE_SEQUENCE.nectval from dual' was embedded in the seq_pkg.nextval() call with an "execute immediate" implementation.

I apologies for the formatting here.
If i count parse calls for all 19 statements under 'sql order by parse calls', it comes to 1,731,600 (1.7M). That would be just 2866/sec. Load-profile says 6892/sec
Count for executions (sql order by executions) comes to 2,151,299 (2.1M). That came to 3585/sec. Again, load profiles says 7981/sec. Dont know why is such gap. Am i having rest as recursive calls ?

Is that hibernate's "reset session state" that is leaving just 2 open cursors for all 1,400 Hiberbate connections ? Is there any negatives on db performance by 'resetting session stat' too aggressively ?

Can you educate me on advantages of embedding 'select HIBERBATE_SEQUENCE.nectval from dual' in 'seq_pkg.nextval()' ? seems like a great recommendation.