Can we convert a SQL (Select Statement) to Procedure.?

Question

Hi
I am using a select sql for retrieving the results - Below is a sample sql select query.
select TableC.DATEFIELD as QUERY_DATE,
TableB.COLUMN1 PROCESS,
TableC.COLUMN1 PRODUCT,
sum(TableC.COLUMN4) as OPEN_INSTANCES
from      TableA, TableB, TableC
where TableB.COLUMN1      = TableA.COLUMN2
and      TableA.COLUMN2      = TableC.COLUMN2
and      DATEFIELD <= to_date('2011-02-02' ,'YYYY-MM-DD')
and      DATEFIELD >= to_date('2011-02-02' ,'YYYY-MM-DD')
and      TableC.COLUMN4 <= (24 * 3600 )
and      TableB.COLUMN1 like 'PROCESSID'
and      TableC.COLUMN1 in ('OSRCITR')
group by TableC.DATEFIELD as QUERY_DATE,
TableA.COLUMN1 PROCESS,
TableC.COLUMN1 PRODUCT
I believe if we use a Procedure, It would be much faster. Is there any way that we can convert the above select sql to a procedure. If yes, how can it be.
Thanks in Advance.
-Sreekant

Answer 1

Sreekant wrote:
select TableC.DATEFIELD as QUERY_DATE,
TableB.COLUMN1 PROCESS,
TableC.COLUMN1 PRODUCT,
sum(TableC.COLUMN4) as OPEN_INSTANCES
from      TableA, TableB, TableC
where TableB.COLUMN1      = TableA.COLUMN2
and      TableA.COLUMN2      = TableC.COLUMN2
and      DATEFIELD <= to_date('2011-02-02' ,'YYYY-MM-DD')
and      DATEFIELD >= to_date('2011-02-02' ,'YYYY-MM-DD')
and      TableC.COLUMN4 <= (24 * 3600 )
and      TableB.COLUMN1 like 'PROCESSID'
and      TableC.COLUMN1 in ('OSRCITR')
group by TableC.DATEFIELD as QUERY_DATE,
TableA.COLUMN1 PROCESS,
TableC.COLUMN1 PRODUCT
I believe if we use a Procedure, It would be much faster. Is there any way that we can convert the above select sql to a procedure. If yes, how can it be.Using the code tags would make the query easier to read :)
What version of Oracle are you on?
Under the right conditions deconstructing a huge query into smaller components sometimes can offer performance increases, but this is more true of older versions of Oracle than recent ones. Lately I get better results from tuning queries in place - as Aman pointed out you introduce context switching (moving between the SQL and PL/SQL engines to do work) which can also hurt performance.
Try tuning the query first. Get an execution plan. Things you can look for include
* make sure the driving table is the best one
* are the join columns properly indexed? Are existing indexes being suppressed due to the functions?
Is "and      TableB.COLUMN1 like 'PROCESSID' " correct? without a wildcard LIKE should evalate to =