How to measure performance of query in oracle

There is button above the SQL editor called "Explain Plan". This tool will tell you what each route costs, and how the statement will use indexes and partitions. Note, you may get an error, your DBA will need to turn on a feature for your user account, I believe it is "trace", but could be wrong on that point. Reading the execute statement output can be challenging at first, but it is a good tool to helping write good SQL.

I'm afraid EXPLAIN PLAN is the only way. Start off by assuming that a lower cost (if you look at the explain plan there should be a column called COST) is better, but you need to read up about it so that you learn more and more. Maybe you have a DBA there that you could chat stuff through with? Without having your data and the queries it is difficult to advise further

For anything to do with developing Oracle, a good place to start is anything by Tom Kyte (Google him) or search through the Ask Tom website. If you really want to get involved

Only running the query a few times is a pretty bad idea - equivalent to just accepting that the cost of the explain plan tells you the best query. You really need to take into account what resources your query is taking up and therefore how it could affect you production system.

Depending on how often the query gets called affects how well you need to track a query's performance (sorry to purists, but it does). If the query only runs once a week and takes a minute to run without affecting anything else then do you need to optimise that query? Is it easier for maintenance to use a query that is more easy to logically follow?

If the query is being called multiple times a second then you need to completely understand the explain plan, and have a further understanding on how you can optimise the query to its best performance

Basic answer - execute each query a couple of times and see which one is faster. Best part - you can do this without learning about Oracle performance. The only thing you need to know is that you can not trust the first try because most of the time it will read data from disk while second try will use cached data from RAM. That is why you try each query a couple of times.