If I understand your question correctly, you are asking if it is possible to determine which SQL statements cause performance problems based on the calculated CPU_COST. I do not think that it is safe to determine which SQL statements will cause performance problem based only on the calculated CPU_COST or IO_COST – those numbers are only estimated values. It is not completely clear what the unit of measure is for the CPU_COST values, other than it is related to CPUSPEED from SYS.AUX_STATS$, which indicates the relative performance of the CPU when performing some sort of Oracle Database task (possibly directly related to the number of consistent gets that may be performed per second).

A 10046 extended SQL trace produces much better information about which queries executed by a session potentially cause performance problems. I have a three part series on my blog that describes 10046 extended SQL traces. Part 3 of the series is found here:
http://hoopercharles.wordpress.com/2010/09/06/10046-extended-sql-trace-interpretation-3/

You can process the 10046 extended SQL trace files using tkprof or many other utilities to help summarize the information, or you can look directly at the 10046 trace file. For example:

WAIT #3: nam='direct path read temp' ela= 874 file number=201 first dba=276414 block cnt=31 obj#=82052 tim=4482620835
WAIT #3: nam='asynch descriptor resize' ela= 0 outstanding #aio=0 current aio limit=4294967295 new aio limit=767 obj#=82052 tim=4482696314
WAIT #3: nam='asynch descriptor resize' ela= 1 outstanding #aio=0 current aio limit=4294967295 new aio limit=702 obj#=82052 tim=4482696416
FETCH #3:c=8704855,e=11028077,p=317918,cr=267225,cu=0,mis=0,r=1,dep=0,og=1,plh=4284856579,tim=4482696455

In the above we see “c=8704855,e=11028077″. That means fetching one row (“r=1″ in the line) required 8.704855 seconds of CPU time and 11.028077 seconds of total time.

On pages 215 through 218 of the “Expert Oracle Practices” book, Randolf Geist and I showed how to monitor the V$SQLSTATS view to watch in real-time for CPU intensive SQL statements. See the following link:
http://books.google.com/books?id=tUNtyMCwDWQC&pg=PA215#v=onepage&q&f=false

Statspack and AWR (if the database is licensed for the Diagnostics Pack) are also helpful. I have a couple of blog articles on the topic of Statspack reports, see:
http://hoopercharles.wordpress.com/2009/11/30/11-2-0-1-statspack-report-contents/
http://hoopercharles.wordpress.com/2009/12/14/statspackawr-report-resources/

Jonathan Lewis has a very well written collection of Statspack articles. You will find those articles here:
http://jonathanlewis.wordpress.com/statspack-examples/

Another approach that you can use is sampling the time model statistics. I have a three part series on that topic, with part three listed below:
http://hoopercharles.wordpress.com/2010/02/09/working-with-oracle%e2%80%99s-time-model-data-3/

Good luck.

(edit: translate.google.com: Interesting, but I know if machine x cycles represent a significant cost and involve loss of performance?)

Excellent explanation of %CPU column.

Regards
Girish

Thank you for the compliment.

Thanks for making understand the %CPU column meaning so easy.

Regards,
Anand