Hi Ne,
i get your analogy, but technically Oracle parallel execution (e.g. parallel query) is based on granules. You can get the concept from the official Oracle documentation (Granules of Parallelism).
In your case you would need to parallelize the INDEX RANGE SCAN (and TABLE ACCESS BY ROWID) and for that you need partition granules. Your query that should benefit from it uses a WHERE clause like "MANDT=:A0 AND OBJNR=:A1", which would end up in the same partition (= same granule) - so nothing to parallelize here. I quote from the official Oracle documentation in that scenario.
Partition granules are the basic unit of parallel index range scans, joins between two equipartitioned tables where the query optimizer has chosen to use partition-wise joins, and parallel operations that modify multiple partitions of a partitioned object.
Because partition granules are statically determined by the structure of the table or index when a table or index is created, partition granules do not give you the flexibility in executing an operation in parallel that block granules do. The maximum allowable DOP is the number of partitions.
Block granules are easier to parallelize, but i really doubt that an INDEX FAST FULL SCAN or a FULL TABLE SCAN (even on partition level) is faster than an index range scan lookup on that unique (primary key) index by just visiting a few blocks. You need to consider the amount of work that needs to be done for co-ordination and building up such granules as well.
However you already think about implementing/testing a solution without knowing the real time consuming part at all. Based on your description of the application behavior (few hundred million single executions) i am pretty sure that you should verify and consider the "SQL*Net message from client" problem.
> While I go through the threads/blog you have suggested(and i must say they are pretty technical getting down to the internals of oracle[deep considering from my basis perspective])
I know - i am sorry, but (Oracle) performance tuning is a pretty technical topic and you need to understand the concepts behind for being able to troubleshoot, identify and fix the real problem in a systematic and economic way. Oracle is a beast and gives you a lot of possibilities to trace and identify the issue (or make it even worse based on wrong assumptions), which is pretty technical in consequence.
Regards
Stefan