SQL query Cost is high

Hi,
Every day over night batches run. For a perticular batch it is taking too much of time to execute as one of its procedure is taking maximum time to execute. Could anyone pls suggest what need to be done to reduce the cost for this sql.
Effected SQL:
DECLARE
var_trans_session invtrnee.trans_session%TYPE;
BEGIN
-- ADDED BY SHANKAR ON 08/29/97
-- GET THE NEXT AVAILABLE TRANS_SESSION
bastkey('trans_session',0,var_trans_session,'T');
-- MAS001
uk_trfbapuo_auto(var_trans_session,'UPLOAD','T',300);
-- MAS001 end
END;
Please let me know if any further information is required for this case
Edited by: user8610659 on Sep 22, 2011 4:36 AM

Hi!
Why do you think anyone outside of your site knows what these procedures are doing?:
* bastkey('trans_session',0,var_trans_session,'T');
* uk_trfbapuo_auto(var_trans_session,'UPLOAD','T',300);
If we shall help you, we need the code for these at least.
Regards,
Matt
Edited by: msschulz on Sep 22, 2011 1:39 PM

Similar Messages

SQL Query Cost Report..

Hi all,
I am novice to OEM. I wanted to do / run sql query cost report.. How can i do it in OEM.?? Is it possible to do in OEM..??? Please guide me to solve this problem.??
Your suggestion will be helpful.
Thanks,
-Mahesh.

Hi,
Thanks for your reply, but I want info about Oracle Enterprise Manager 10g.
Actual requirement is like this,
We have script files written in Linux Shell scripts, which are related to DB activities like Startup DB, Shutdown DB, perfstat, checking free space etc etc. These we want to migrate into OEM using OEM built-in features, few of which we've already migrated. We have analyzed scripts. One of the script is for SQL Query Cost Report (Which i didn't get what it does..)
So is there any option/inbuilt feature through which we can do "SQL Cost Report".
Once again thanks for your reply.
-Mahesh.

Dynamically extracting SQL query costs/statistics at runtime

Hi there,
I need to measure the I/O cost (such as 'physical reads')of a SQL statement at runtime. What I'm looking to do is to test the total cost of a number of queries in a java program. So I need to get the cost automatically and add them up.
There are a few tools that can give statistics on I/O cost, such as autotrace, but I need to collect these information using Java through JDBC.
Any pointers?
Also I am a little confused about the terms used in oralce. What I need is the number of db blocks accessed by the query, either from buffer or disk. Are these referred as 'logical read' and 'physical read' respectively? Or are 'logical read' and 'physical read' just mean the number of reads?
Thank you,

Logical and consistent reads are against the DB Buffers, Physical reads are disk io. When evaluating the cost of a query, pay attention to an abnormally high number of logical reads. This is usually an indicator of a poorly performing query ie a correlated sub-query.

Any difference between distinct and aggregate function in sql query cost???

Hi,
I have executed many sql stmts patterns- such as:
a) using a single table
b) using two tables, using simple joins or outer joins
but i have not noticed any difference in sql stmts in cost and in execution plan....
Anyway, my colleague insists on that using aggregate function is less costly compared to
distinct....(something i have not confirmed, that's why i beleive that they are exactly the same...)
For the above reffered 1st sql pattern.. we could for example use
select distinct deptno
from emp
select count(*), deptno
from emp
group by deptno select distinct owner, object_type from all_objects
select count(*), owner, object_type from all_objects
group by owner, object_typeHave you found any difference between the two ever...????
Note: I use Ora DB 10g v2.
Thank you,
Sim

distinct and aggregate function are for different uses and may give same result but if u r using aggregate function to get distinct records, it will be expensive...
ex
select distinct deptno from scott.dept;
Statistics
0 recursive calls
0 db block gets
2 consistent gets
0 physical reads
0 redo size
584 bytes sent via SQL*Net to client
488 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
4 rows processed
select deptno from scott.emp group by deptno;
Statistics
307 recursive calls
0 db block gets
60 consistent gets
6 physical reads
0 redo size
576 bytes sent via SQL*Net to client
488 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
6 sorts (memory)
0 sorts (disk)
3 rows processed
Nimish Garg
Software Developer
*(Oracle & ASP.NET)*
Indiamart Intermesh Limited, Noida
To Get Free Oracle & ASP.NET Code Snippets
Follow: http://nimishgarg.blogspot.com

Less sql query cost ... but more time to fetch the records...

Hi,
I faced up to a 'peculiar' situation with a costly db view.
I attempted to reduce the total view cost
specifically for 223 records fetched{the cost from 149 reduced to 74,
                                                       the recursive calls from 796 reduced to 224,
                                                       the consistent gets from 311516 reduced to 310341,
                                                        the physical reads from 7 reduced to 0}
but the amount of time needed to fetch the results is greater than the old version of the db view....{it may be the double...}
Have you any idea about this...????
Note: I have got fresh statistics...
         I use db 10g v.2
Thanks,
Sim

Try tracing the query and see what tkprofs shows you.
alter session set events '10046 trace name context forever, level 12';
run the query
alter session set events '10046 trace name context off';
Then run tkprofs on the trace file produced to see where the database is spending its time/effort. Do likewise for the baseline query in a different session (so you will generate a different trace file).
If that does not produce anything useful, try using
alter session set events '10053 trace name context forever';
run the query
alter session set events '10053 trace name context off';
Then examine the trace file to see if you can learn anything.
Since you have not given us anything more to go on, that is about all the help I can give....

Improve Efficiency of SQL Query (reducing Hash Match cost)

I have the following SQL query that only takes 6 seconds to run, but I am trying to get it down to around 3 seconds if possible. I've noticed that there are 3 places in the Execution Plan that have pretty high costs. 1: Hash Match (partial aggregate) - 12%.
2: Hash Match (inner join) - 36%. 3: Index Scan - 15%.
I've been researching Hash Match for a couple days now, but I just don't seem to be getting it. I can't seem to figure out how to decrease the cost. I've read that OUTER APPLY is really inefficient and I have two of those in my query, but I haven't been
able to figure out a way to get the results I need without them.
I am fairly new to SQL so I am hoping I can get some help with this.
SELECT wi.WorkItemID,
wi.WorkQueueID as WorkQueueID,
wi.WorkItemTypeID,
wi.WorkItemIdentifier,
wi.DisplayIdentifier,
wi.WorkItemStatusID,
wi.SiteID,
wi.AdditionalIdentifier,
wi.WorkQueueDescription,
wi.WorkItemTypeDescription,
wi.WorkQueueCategoryDescription,
wi.Active,
wi.CheckedOutOn,
wi.CheckedOutBy_UserID,
wi.CheckedOutBy_UserName,
wi.CheckedOutBy_FirstName,
wi.CheckedOutBy_LastName,
wi.CheckedOutBy_FullName,
wi.CheckedOutBy_Alias,
b.[Description] as BatchDescription,
bt.[Description] as BatchType,
bs.[Description] as PaymentBatchStatus,
b.PostingDate AS PostingDate,
b.DepositDate,
b.BatchDate,
b.Amount as BatchTotal,
PostedAmount = ISNULL(PostedPayments.PostedAmount, 0),
TotalPayments = ISNULL(PostedPayments.PostedAmount, 0), --Supporting legacy views
TotalVariance = b.Amount - ISNULL(PostedPayments.PostedAmount, 0), -- ISNULL(Payments.TotalPayments, 0),
PaymentsCount = ISNULL(Payments.PaymentsCount, 0),
ISNULL(b.ReferenceNumber, '') AS PaymentBatchReferenceNumber,
b.CreatedOn,
b.CreatedBy_UserID,
cbu.FirstName AS CreatedBy_FirstName,
cbu.LastName AS CreatedBy_LastName,
cbu.DisplayName AS CreatedBy_DisplayName,
cbu.Alias AS CreatedBy_Alias,
cbu.UserName AS CreatedBy_UserName,
b.LastModifiedOn,
b.LastModifiedBy_UserID,
lmbu.FirstName AS LastModifiedBy_FirstName,
lmbu.LastName AS LastModifiedBy_LastName,
lmbu.DisplayName AS LastModifiedBy_DisplayName,
lmbu.Alias AS LastModifiedBy_Alias,
lmbu.UserName AS LastModifiedBy_UserName,
0 AS VisitID, --Payment work items are not associated with VisitID, but it is a PK field on all the Work Queue view models...for now...
0 AS RCMPatientID, --Payment work items are not associated with RCMPatientID, but it is a PK field on all the Work Queue view models...for now...
0 AS PatientID
FROM Account.PaymentBatch AS b (NOLOCK)
INNER JOIN ViewManager.WorkItems AS wi (NOLOCK)
ON wi.WorkitemIdentifier = b.PaymentBatchID
AND wi.WorkItemTypeID = 3
INNER JOIN Account.PaymentBatchStatus AS bs (NOLOCK)
ON b.PaymentBatchStatusID = bs.PaymentBatchStatusID
LEFT JOIN Account.PaymentBatchType bt (NOLOCK)
ON b.PaymentBatchTypeID = bt.PaymentBatchTypeID
INNER JOIN ViewManager.[User] AS cbu (NOLOCK)
ON b.CreatedBy_UserID = cbu.UserID
INNER JOIN ViewManager.[User] AS lmbu (NOLOCK)
ON b.LastModifiedBy_UserID = lmbu.UserID
LEFT JOIN (
SELECT p.PaymentBatchID
, SUM(p.Amount) AS TotalPayments
, COUNT(0) AS PaymentsCount
FROM Account.Payment AS p (NOLOCK)
WHERE p.PaymentTypeID = 1
AND ISNULL(p.Voided, 0) = 0
GROUP BY p.PaymentBatchID
) AS Payments ON b.PaymentBatchID = Payments.PaymentBatchID
LEFT JOIN (
SELECT p.PaymentBatchID
, SUM(pa.Amount) AS PostedAmount
FROM Account.Payment AS p (NOLOCK)
INNER JOIN Account.PaymentAllocation AS PA (NOLOCK)
ON p.PaymentID = pa.PaymentID
AND (pa.AllocationTypeID = 101 OR pa.AllocationTypeID = 111)
WHERE p.PaymentTypeID = 1
AND ISNULL(p.Voided, 0) = 0
GROUP BY p.PaymentBatchID
) AS PostedPayments ON b.PaymentBatchID = PostedPayments.PaymentBatchID
OUTER APPLY (
SELECT
P.PaymentBatchID,
SUM(CASE WHEN P.PaymentTypeID = 1 THEN 1 ELSE 0 END) as PaymentsCount --only count regular payments not adjustments
FROM
Account.Payment p (NOLOCK)
WHERE
p.PaymentBatchID = b.PaymentBatchID
AND p.PaymentTypeID IN (1,2) AND ISNULL(p.Voided, 0)= 0
GROUP BY
P.PaymentBatchID
) payments
OUTER APPLY (
SELECT
P.PaymentBatchID,
SUM(pa.Amount) as PostedAmount
FROM
Account.PaymentAllocation pa (NOLOCK)
INNER JOIN
Account.Payment p (NOLOCK) ON pa.PaymentID = p.PaymentID
INNER JOIN
Account.AllocationType t (NOLOCK) ON pa.AllocationTypeID = t.AllocationTypeID
WHERE
p.PaymentBatchID = b.PaymentBatchID
AND p.PaymentTypeID IN (1,2)
AND ISNULL(p.Voided, 0)= 0
--AND (t.Credit = 0
--OR (t.Credit <> 0 And Offset_PaymentAllocationID IS NULL AND (SELECT COUNT(1) FROM Account.paymentAllocation pa2 (NOLOCK)
-- WHERE pa2.PaymentID = pa.PaymentID AND pa2.AllocationTypeID IN (101, 111)
-- AND pa2.Offset_PaymentAllocationID IS NULL) > 0))
GROUP BY
P.PaymentBatchID
) PostedPayments

The percentages you see are only estimates and may not necessarily not reflect where the real bottleneck is. Particularly, if it is due to a misestimate somewhere.
To be able to help you improve the performance, we need to see the CREATE TABLE and CREATE INDEX statements for the tables. We also need to see the actual query plan. (In XML format, not a screen shot.) Posting all this here is not practical, but you could
upload it somewhere. (Dropbox, Google Drive etc.)
Be very careful with the NOLOCK hint. Using the NOLOCK hint casually lead to transient erratic behaviour which is very difficult to understand. Using it consistenly through a query like you do, is definitely bad practice.
Erland Sommarskog, SQL Server MVP, [email protected]

Query Cost vs SQL statistics

I have a query and when I execute it it gives a cost of 4000+, however after I optimized it came down to about 300 or so.
My problem is that after discussing the query with my manager he showed me that the statistics of the first query version where better than the second one (we made sure it was not cached ).
How come that the second one runs faster and has less cost even if the SQL statistics is worse?
example:
first query:
cost: 4000
time to run: 2:00+ minutes
1 recursive call
1310 consistent gets
2600 physical reads
second query:
cost: 290
time to run: ~1:30 minutes
1200 recursive calls
13000 consistent gets
30000 physical read

user8973401 wrote:
I have a query and when I execute it it gives a cost of 4000+, however after I optimized it came down to about 300 or so.
How come that the second one runs faster and has less cost even if the SQL statistics is worse?
example:
first query:
cost: 4000
time to run: 2:00+ minutes
1 recursive call
1310 consistent gets
2600 physical reads
second query:
cost: 290
time to run: ~1:30 minutes
1200 recursive calls
13000 consistent gets
30000 physical readI personally use execution time along with the metrics you listed together to determine when one version of a query is better than another. There are gray areas like the situation you listed where "better" is hard to determine. Another useful metric is CPU, which AUTOTRACE does not list but can be found using V$SQL, traces, or AWR reports. Sometimes the biggest challenge is making sure the result set of the tuned query is the same as the original one ;)
You listed mixed results which can happen. The run time was 2 minutes vs 1:30 but other metrics were higher. The CPU on the first query might be lower.
Oh, it DOES happen that a higher-cost version of a query executes faster and uses fewer resources than a lower-cost version. Remember that the COST is an estimate which is usally but not alway accurate

Sql query runing slow with lower cost

Hello
I am working on Oracle 11g and AIX.I have one sql query which is ruing slow as reported by user.
When i am commenting few line of code it is runing fast.
I noticed that the execution plan cost of first query is less and second ...as cost of sccond qurey is more.But users are say it is runing fast.
How it can possiable ?
Any idea why second query is runing fast after commenting few columns in select and group by clause.
Query 1
SELECT PH.CTRL_NBR, PD.SEQ_NBR,PH.CNTRY,PH.SHIP_DATE, PHI.WAVE_NBR, PD.ID, PD.QTY,
IM.PACK_QTY,
IM.UNIT_VOL,
IM.PACK_QTY,
MAX(CD.PACK_QTY) AS CASE_QTY,
IM.UNIT_WT
FROM HDR PH,
HDR_INTRNL PHI,
DTL PD,
HDR CH,
CASEDTL CD,
IMASTER IM
WHERE PH.CTRL_NBR = PHI.CTRL_NBR
AND PD.CTRL_NBR = PH.CTRL_NBR
AND PD.QTY > 0
AND SUBSTR(CD.ID, 1, 9) = SUBSTR(PD.ID, 1, 9)
AND CD.CASENBR = CH.CASENBR
AND CH.STAT_CODE BETWEEN '10' AND '90'
AND IM.ID = PD.ID
AND PHI.WAVE_NBR='EL57893'
GROUP BY PH.CTRL_NBR, PD.SEQ_NBR, PH.CNTRY, PH.SHIP_DATE, PHI.WAVE_NBR, PD.ID, PD.QTY,
IM.PACK_QTY,
IM.UNITVOL,
IM.UNITWT,
IM.PACK_QTY
Query 2 .
SELECT PH.CTRL_NBR,
PD.SEQ_NBR,
PH.CNTRY,
PH.SHIP_DATE,
PHI.WAVE_NBR,
PD.ID,
PD.QTY,
-- IM.PACK_QTY,
-- IM.UNIT_VOL,
-- IM.PACK_QTY,
MAX(CD.PACK_QTY) AS CASE_QTY,
-- IM.UNIT_WT
FROM HDR PH,
HDR_INTRNL PHI,
DTL PD,
HDR CH,
CASEDTL CD,
IMASTER IM
WHERE PH.CTRL_NBR = PHI.CTRL_NBR
AND PD.CTRL_NBR = PH.CTRL_NBR
AND PD.QTY > 0
AND SUBSTR(CD.ID, 1, 9) = SUBSTR(PD.ID, 1, 9)
AND CD.CASENBR = CH.CASENBR
AND CH.STAT_CODE BETWEEN '10' AND '90'
AND IM.ID = PD.ID
AND PHI.WAVE_NBR='EL57893'
GROUP BY PH.CTRL_NBR, PD.SEQ_NBR, PH.CNTRY, PH.SHIP_DATE, PHI.WAVE_NBR, PD.ID, PD.QTY,
--IM.PACK_QTY,
--IM.UNITVOL,
--IM.UNITWT,
--IM.PACK_QTY
Edited by: oradba11 on Sep 6, 2012 2:11 PM
Edited by: oradba11 on Sep 6, 2012 2:12 PM

oradba11 wrote:
Hello
I am working on Oracle 11g and AIX.I have one sql query which is ruing slow as reported by user.
When i am commenting few line of code it is runing fast.
I noticed that the execution plan cost of first query is less and second ...as cost of sccond qurey is more.But users are say it is runing fast.
How it can possiable ? <snip>
This doesn't address your question, but let me suggest that for your own sanity you start brining some formatting to your sql. And for the sanity of those on this forum of whom you expect assistance, you preserve that formatting through the use of the code tags (see the FAQ for details).
I've done the first one for you, as an example of what I mean
SELECT
     PH.CTRL_NBR
,     PD.SEQ_NBR
,     PH.CNTRY
,     PH.SHIP_DATE
,     PHI.WAVE_NBR
,     PD.ID
,     PD.QTY
,     IM.PACK_QTY
,     IM.UNIT_VOL
,     IM.PACK_QTY
,     MAX(CD.PACK_QTY) AS CASE_QTY
,     IM.UNIT_WT
FROM
     HDR PH
,     HDR_INTRNL PHI
,     DTL PD
,     HDR CH
,     CASEDTL CD
,     IMASTER IM
WHERE
     PH.CTRL_NBR = PHI.CTRL_NBR
   AND PD.CTRL_NBR = PH.CTRL_NBR
   AND PD.QTY > 0
   AND SUBSTR(CD.ID, 1, 9) = SUBSTR(PD.ID, 1, 9)
   AND CD.CASENBR = CH.CASENBR
   AND CH.STAT_CODE BETWEEN '10' AND '90'
   AND IM.ID = PD.ID
   AND PHI.WAVE_NBR='EL57893'
GROUP BY
     PH.CTRL_NBR
,     PD.SEQ_NBR
,     PH.CNTRY
,     PH.SHIP_DATE
,      PHI.WAVE_NBR
,      PD.ID
,      PD.QTY
,      IM.PACK_QTY
,     IM.UNITVOL
,     IM.UNITWT
,     IM.PACK_QTY

High Concurrent SQL query of DBSNMP user

OS Linux
DB 11.2.0.2
we have a 12 node RAC box on exadata. We are doing the monitoring through the OEM GRID. In the 12th node we see a high concurrent sql query owned by the DBSNMP user.The concurrency is about 98% and it the top query in that instance. Please suggest me what we shoud do to decrease it.
Below is the query
SELECT s.inst_id, s.name, i.instance_name
FROM gv$active_services s, gv$instance i
WHERE s.name = :p1 AND s.inst_id = i.inst_id

Hi,
We applied the patch 9482559 which was suggested by oracle for a different issue and after applying this patch the high concurrent dbsnmp sql issue is gone.

SQL Query Performance

Hi There,
We have a sql query that runs between 2 databases on the same machine, the sql takes about 2 mins and returns about 6400 rows. When the process started running we used to see results in about 13 secs, now it's taking almost 2 mins for the same data set. We have updated the stats (table and index) but to no use. I've been trying to get the execution plan to see if there is anything abnormal going on but as the core of the sql is done remotely, we haven't been able to get much out of it.
Here is the sql:
SELECT
--/*+ DRIVING_SITE(var) ALL_ROWS */
         ventity_id, ar_action_performed, action_date,
         'ventity_ar' ar_tab
    FROM (SELECT var.ventity_id, var.ar_action_performed, var.action_date,
                 var.familyname_id, var.status, var.isprotected,
                 var.dateofbirth, var.gender, var.sindigits,
                 LAG (var.familyname_id) OVER (PARTITION BY var.ventity_id ORDER BY action_date)
                                                            lag_familyname_id,
                 LAG (var.status) OVER (PARTITION BY var.ventity_id ORDER BY action_date)
                                                                   lag_status,
                 LAG (var.isprotected) OVER (PARTITION BY var.ventity_id ORDER BY action_date)
                                                              lag_isprotected,
                 LAG (var.dateofbirth) OVER (PARTITION BY var.ventity_id ORDER BY action_date)
                                                              lag_dateofbirth,
                 LAG (var.gender) OVER (PARTITION BY var.ventity_id ORDER BY action_date)
                                                                   lag_gender,
                 LAG (var.sindigits) OVER (PARTITION BY var.ventity_id ORDER BY action_date)
                                                                lag_sindigits
            FROM cpp_schema.ventity_ar@CdpP var,
                 -- reduce the set to ventity_id that had a change within the time frame,
                 -- and filter out RETRIEVEs as they do not signal change
                 (SELECT DISTINCT ventity_id
                             FROM cpp_schema.ventity_ar@CdpP
                            WHERE action_date BETWEEN '01-MAR-10' AND '10-APR-10'
                              AND ar_action_performed <> 'RTRV') m
           WHERE var.action_date <= '10-APR-10'
             AND var.ventity_id = m.ventity_id
             AND var.ar_action_performed <> 'RTRV') mm
   WHERE action_date BETWEEN '01-MAR-10' AND '10-APR-10'
     -- most of the columns from the data table allow nulls
     AND (   (NVL (familyname_id, 0) <> NVL (lag_familyname_id, 0))
          OR (NVL (status, 'x') <> NVL (lag_status, 'x'))
          OR (NVL (isprotected, 2) <> NVL (lag_isprotected, 2))
          OR (NVL (dateofbirth, TO_DATE ('15000101', 'yyyymmdd')) <>
                       NVL (lag_dateofbirth, TO_DATE ('15000101', 'yyyymmdd'))
          OR (NVL (gender, 'x') <> NVL (lag_gender, 'x'))
          OR (NVL (sindigits, 'x') <> NVL (lag_sindigits, 'x'))
ORDER BY ventity_id, action_date DESC
6401 rows selected.
Elapsed: 00:01:47.03
Execution Plan
Plan hash value: 3953446945
| Id | Operation        | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time     | Inst   |IN-OUT|
|   0 | SELECT STATEMENT |      |    12M| 1575M|       |   661K (1)| 02:12:22 |        |      |
|   1 | SORT ORDER BY   |      |    12M| 1575M| 2041M|   661K (1)| 02:12:22 |        |      |
|* 2 |   VIEW           |      |    12M| 1575M|       |   291K (2)| 00:58:13 |        |      |
|   3 |    REMOTE        |      |       |       |       |            |          | CCP01 | R->S |
   2 - filter("action_date">='01_MAR-10' AND "action_date"<='10-APR-10' AND
              (NVL("FAMILYNAME_id",0)<>NVL("LAG_FAMILYNAME_id",0) OR
              NVL("STATUS",'x')<>NVL("LAG_STATUS",'x') OR NVL("ISPROTECTED",2)<>NVL("LAG_ISPROTECTED",2
              ) OR NVL("DATEOFBIRTH",TO_DATE(' 1500-01-01 00:00:00', 'syyyy-mm-dd
              hh24:mi:ss'))<>NVL("LAG_DATEOFBIRTH",TO_DATE(' 1500-01-01 00:00:00', 'syyyy-mm-dd
              hh24:mi:ss')) OR NVL("GENDER",'x')<>NVL("LAG_GENDER",'x') OR
              NVL("SINDIGITS",'x')<>NVL("LAG_SINDIGITS",'x')))
Remote SQL Information (identified by operation id):
   3 - EXPLAIN PLAN SET STATEMENT_ID='PLUS4294967295' INTO PLAN_TABLE@! FOR SELECT
       "A2"."ventity_id","A2"."AR_ACTION_PERFORMED","A2"."action_date","A2"."FAMILYNAME_id","A2"
       ."STATUS","A2"."ISPROTECTED","A2"."DATEOFBIRTH","A2"."GENDER","A2"."SINDIGITS",DECODE(COU
       NT(*) OVER ( PARTITION BY "A2"."ventity_id" ORDER BY "A2"."action_date" ROWS BETWEEN 1
       PRECEDING AND 1 PRECEDING ),1,FIRST_VALUE("A2"."FAMILYNAME_id") OVER ( PARTITION BY
       "A2"."ventity_id" ORDER BY "A2"."action_date" ROWS BETWEEN 1 PRECEDING AND 1 PRECEDING
       ),NULL),DECODE(COUNT(*) OVER ( PARTITION BY "A2"."ventity_id" ORDER BY
       "A2"."action_date" ROWS BETWEEN 1 PRECEDING AND 1 PRECEDING ),1,FIRST_VALUE("A2"."STATUS")
       OVER ( PARTITION BY "A2"."ventity_id" ORDER BY "A2"."action_date" ROWS BETWEEN 1
       PRECEDING AND 1 PRECEDING ),NULL),DECODE(COUNT(*) OVER ( PARTITION BY
       "A2"."ventity_id" ORDER BY "A2"."action_date" ROWS BETWEEN 1 PRECEDING AND 1 PRECEDING
       ),1,FIRST_VALUE("A2"."ISPROTECTED") OVER ( PARTITION BY "A2"."ventity_id" ORDER BY
       "A2"."action_date" ROWS BETWEEN 1 PRECEDING AND 1 PRECEDING ),NULL),DECODE(COUNT(*) OVER (
       PARTITION BY "A2"."ventity_id" ORDER BY "A2"."action_date" ROWS BETWEEN 1 PRECEDING
       AND 1 PRECEDING ),1,FIRST_VALUE("A2"."DATEOFBIRTH") OVER ( PARTITION BY
       "A2"."ventity_id" ORDER BY "A2"."action_date" ROWS BETWEEN 1 PRECEDING AND 1 PRECEDING
       ),NULL),DECODE(COUNT(*) OVER ( PARTITION BY "A2"."ventity_id" ORDER BY
       "A2"."action_date" ROWS BETWEEN 1 PRECEDING AND 1 PRECEDING ),1,FIRST_VALUE("A2"."GENDER")
       OVER ( PARTITION BY "A2"."ventity_id" ORDER BY "A2"."action_date" ROWS BETWEEN 1
       PRECEDING AND 1 PRECEDING ),NULL),DECODE(COUNT(*) OVER ( PARTITION BY
       "A2"."ventity_id" ORDER BY "A2"."action_date" ROWS BETWEEN 1 PRECEDING AND 1 PRECEDING
       ),1,FIRST_VALUE("A2"."SINDIGITS") OVER ( PARTITION BY "A2"."ventity_id" ORDER BY
       "A2"."action_date" ROWS BETWEEN 1 PRECEDING AND 1 PRECEDING ),NULL) FROM
       "CPP_SCHEMA"."ventity_AR" "A2", (SELECT DISTINCT "A3"."ventity_id"
       "ventity_id" FROM "CPP_SCHEMA"."ventity_AR" "A3" WHERE
       "A3"."action_date">='01_MAR-10' AND "A3"."action_date"<='10-APR-10' AND
       "A3"."AR_ACTION_PERFORMED"<>'RETRIEVE' AND TO_DATE('01_MAR-10')<=TO_DATE('10-APR-10'))
       "A1" WHERE "A2"."action_date"<='10-APR-10' AND "A2"."ventity_id"="A1"."ventity_id"
       AND "A2"."AR_ACTION_PERFORMED"<>'RETRIEVE' (accessing 'EBCP01.EBC.GOV.BC.CA' )Your advise and/or help is highly appreciated.
THanks
Edited by: rsar001 on Apr 20, 2010 6:57 AM

Maybe I'm missing something but this subquery seems inefficient:
SELECT var.ventity_id, var.ar_action_performed, var.action_date,
                 var.familyname_id, var.status, var.isprotected,
                 var.dateofbirth, var.gender, var.sindigits,
                 LAG (var.familyname_id) OVER (PARTITION BY var.ventity_id ORDER BY action_date)
                                                            lag_familyname_id,
                 LAG (var.status) OVER (PARTITION BY var.ventity_id ORDER BY action_date)
                                                                   lag_status,
                 LAG (var.isprotected) OVER (PARTITION BY var.ventity_id ORDER BY action_date)
                                                              lag_isprotected,
                 LAG (var.dateofbirth) OVER (PARTITION BY var.ventity_id ORDER BY action_date)
                                                              lag_dateofbirth,
                 LAG (var.gender) OVER (PARTITION BY var.ventity_id ORDER BY action_date)
                                                                   lag_gender,
                 LAG (var.sindigits) OVER (PARTITION BY var.ventity_id ORDER BY action_date)
                                                                lag_sindigits
            FROM cpp_schema.ventity_ar@CdpP var,
                 -- reduce the set to ventity_id that had a change within the time frame,
                 -- and filter out RETRIEVEs as they do not signal change
                 (SELECT DISTINCT ventity_id
                             FROM cpp_schema.ventity_ar@CdpP
                            WHERE action_date BETWEEN '01-MAR-10' AND '10-APR-10'
                              AND ar_action_performed <> 'RTRV') m
           WHERE var.action_date <= '10-APR-10'
             AND var.ventity_id = m.ventity_id
             AND var.ar_action_performed != 'RTRV'I don't think accessing the VENTITY_AR table twice is helping you here. The comments looks like you want to restrict the set of VENTITY_IDs but if you look at the plan it is not happening. The plan is reading them from the index and joining against the full VENTITY_AR table anyways. I recommend you consolidate it into something like this:
SELECT var.ventity_id
,       var.ar_action_performed
,       var.action_date
,       var.familyname_id
,       var.status
,       var.isprotected
,       var.dateofbirth
,       var.gender
,       var.sindigits
,       LAG (var.familyname_id) OVER (PARTITION BY var.ventity_id ORDER BY action_date)         AS lag_familyname_id
,       LAG (var.status) OVER (PARTITION BY var.ventity_id ORDER BY action_date)                AS lag_status
,       LAG (var.isprotected) OVER (PARTITION BY var.ventity_id ORDER BY action_date)           AS lag_isprotected
,       LAG (var.dateofbirth) OVER (PARTITION BY var.ventity_id ORDER BY action_date)           AS lag_dateofbirth
,       LAG (var.gender) OVER (PARTITION BY var.ventity_id ORDER BY action_date)                AS lag_gender
,       LAG (var.sindigits) OVER (PARTITION BY var.ventity_id ORDER BY action_date)             AS lag_sindigits
FROM    cpp_schema.ventity_ar@CdpP var
WHERE   var.action_date BETWEEN TO_DATE('01-MAR-10','DD-MON-YY') AND TO_DATE('10-APR-10','DD-MON-YY')
AND     var.ar_action_performed != 'RTRV'It may then be useful to put an index on (ACTION_DATE,AR_ACTION_PERFORMED) if one doesn't already exist.
*::EDIT::*
I noticed the large amount of NVL calls in your outer query. These NVLs could possibly be eliminated if you use the optional second and third arguments of the LAG analytical function. I'm not sure if this would improve performance but it may make the query more readable and maintainable.
HTH!
Edited by: Centinul on Apr 20, 2010 10:50 AM

Query cost and CASE statement

Hi, I'm working on a performance issue for a customer.
I'm tuning some suspect SQL that uses complex DECODE statements to perform IF/THEN/ELSE logic.
I've taken a statement and rewritten it using CASE however what I've noticed is the cost of the query execution plan has increased dramatically as a result. N.B. I haven't changed the WHERE clause of the query as yet, just replaced one DECODE with the equivalent CASE.
The db version is 9.2.0.4. Does anyone know of issues with the performance of CASE as opposed to DECODE. I'm wondering should I leave the DECODEs as is even though they're way too complicated.
Tks,
Paul.

Here's an example of a DECODE:
nvl(count(distinct decode
(decode(sign(ords.dwh_created_date_id-:v_start_cycle_id),1,1,0,1,-1,0) *
decode(sign(:v_end_cycle_id-ords.dwh_created_date_id),1,1,0,1,-1,0),1,ords.dwh_order_id,NULL)),0) calc1
The equivalent CASE I've coded is:
NVL(COUNT(DISTINCT(CASE WHEN (ords.dwh_created_date_id BETWEEN :v_start_cycle_id AND :v_end_cycle_id)
THEN
ords.dwh_order_id
ELSE
NULL
END)),0) calc1
I've been doing further testing with an amended WHERE clause and did run both CASE and DECODE versions. The performance difference between the two was negligible. So it seems (as I'd hoped) that the amendment of the execution path doesn't appear to be affected by CASE even though Oracle reports the query cost of it is higher.
It is slightly confusing though. Is the query cost in this case a red herring ?

Error while executing a sql query for select

HI All,
ORA-01652: unable to extend temp segment by 128 in tablespace PSTEMP i'm getting this error while i'm executing the sql query for selecting the data.

I am having 44GB of temp space, while executing the below query my temp space is getting full, Expert please let us know how the issue can be resolved..
1. I dont want to increase the temp space
2. I need to tune the query, please provide your recomendations.
insert /*+APPEND*/ into CST_DSA.HIERARCHY_MISMATCHES
(REPORT_NUM,REPORT_TYPE,REPORT_DESC,GAP,CARRIED_ITEMS,CARRIED_ITEM_TYPE,NO_OF_ROUTE_OF_CARRIED_ITEM,CARRIED_ITEM_ROUTE_NO,CARRIER_ITEMS,CARRIER_ITEM_TYPE,CARRIED_ITEM_PROTECTION_TYPE,SOURCE_SYSTEM)
select
REPORTNUMBER,REPORTTYPE,REPORTDESCRIPTION ,NULL,
carried_items,carried_item_type,no_of_route_of_carried_item,carried_item_route_no,carrier_items,
carrier_item_type,carried_item_protection_type,'PACS'
from
(select distinct
c.REPORTNUMBER,c.REPORTTYPE,c.REPORTDESCRIPTION ,NULL,
a.carried_items,a.carried_item_type,a.no_of_route_of_carried_item,a.carried_item_route_no,a.carrier_items,
a.carrier_item_type,a.carried_item_protection_type,'PACS'
from CST_ASIR.HIERARCHY_asir a,CST_DSA.M_PB_CIRCUIT_ROUTING b ,CST_DSA.REPORT_METADATA c
where a.carrier_item_type in('Connection') and a.carried_item_type in('Service')
AND a.carrier_items=b.mux
and c.REPORTNUMBER=(case
when a.carrier_item_type in ('ServicePackage','Service','Connection') then 10
else 20
end)
and a.carrier_items not in (select carried_items from CST_ASIR.HIERARCHY_asir where carried_item_type in('Connection') ))A
where not exists
(select *
from CST_DSA.HIERARCHY_MISMATCHES B where
A.REPORTNUMBER=B.REPORT_NUM and
A.REPORTTYPE=B.REPORT_TYPE and
A.REPORTDESCRIPTION=B.REPORT_DESC and
A.CARRIED_ITEMS=B.CARRIED_ITEMS and
A.CARRIED_ITEM_TYPE=B.CARRIED_ITEM_TYPE and
A.NO_OF_ROUTE_OF_CARRIED_ITEM=B.NO_OF_ROUTE_OF_CARRIED_ITEM and
A.CARRIED_ITEM_ROUTE_NO=B.CARRIED_ITEM_ROUTE_NO and
A.CARRIER_ITEMS=B.CARRIER_ITEMS and
A.CARRIER_ITEM_TYPE=B.CARRIER_ITEM_TYPE and
A.CARRIED_ITEM_PROTECTION_TYPE=B.CARRIED_ITEM_PROTECTION_TYPE
AND B.SOURCE_SYSTEM='PACS'
Explain Plan
==========
Plan
INSERT STATEMENT ALL_ROWSCost: 129 Bytes: 1,103 Cardinality: 1
     20 LOAD AS SELECT CST_DSA.HIERARCHY_MISMATCHES
          19 PX COORDINATOR
               18 PX SEND QC (RANDOM) PARALLEL_TO_SERIAL SYS.:TQ10002 :Q1002Cost: 129 Bytes: 1,103 Cardinality: 1
                    17 NESTED LOOPS PARALLEL_COMBINED_WITH_PARENT :Q1002Cost: 129 Bytes: 1,103 Cardinality: 1
                         15 HASH JOIN RIGHT ANTI NA PARALLEL_COMBINED_WITH_PARENT :Q1002Cost: 129 Bytes: 1,098 Cardinality: 1
                              4 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT :Q1002Cost: 63 Bytes: 359,283 Cardinality: 15,621
                                   3 PX SEND BROADCAST PARALLEL_TO_PARALLEL SYS.:TQ10001 :Q1001Cost: 63 Bytes: 359,283 Cardinality: 15,621
                                        2 PX BLOCK ITERATOR PARALLEL_COMBINED_WITH_CHILD :Q1001Cost: 63 Bytes: 359,283 Cardinality: 15,621
                                             1 MAT_VIEW ACCESS FULL MAT_VIEW PARALLEL_COMBINED_WITH_PARENT CST_ASIR.HIERARCHY :Q1001Cost: 63 Bytes: 359,283 Cardinality: 15,621
                              14 NESTED LOOPS ANTI PARALLEL_COMBINED_WITH_PARENT :Q1002Cost: 65 Bytes: 40,256,600 Cardinality: 37,448
                                   11 HASH JOIN PARALLEL_COMBINED_WITH_PARENT :Q1002Cost: 65 Bytes: 6,366,160 Cardinality: 37,448
                                        8 BUFFER SORT PARALLEL_COMBINED_WITH_CHILD :Q1002
                                             7 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT :Q1002Cost: 1 Bytes: 214 Cardinality: 2
                                                  6 PX SEND BROADCAST PARALLEL_FROM_SERIAL SYS.:TQ10000 Cost: 1 Bytes: 214 Cardinality: 2
                                                       5 INDEX FULL SCAN INDEX CST_DSA.IDX$$_06EF0005 Cost: 1 Bytes: 214 Cardinality: 2
                                        10 PX BLOCK ITERATOR PARALLEL_COMBINED_WITH_CHILD :Q1002Cost: 63 Bytes: 2,359,224 Cardinality: 37,448
                                             9 MAT_VIEW ACCESS FULL MAT_VIEW PARALLEL_COMBINED_WITH_PARENT CST_ASIR.HIERARCHY :Q1002Cost: 63 Bytes: 2,359,224 Cardinality: 37,448
                                   13 TABLE ACCESS BY INDEX ROWID TABLE PARALLEL_COMBINED_WITH_PARENT CST_DSA.HIERARCHY_MISMATCHES :Q1002Cost: 0 Bytes: 905 Cardinality: 1
                                        12 INDEX RANGE SCAN INDEX PARALLEL_COMBINED_WITH_PARENT SYS.HIERARCHY_MISMATCHES_IDX3 :Q1002Cost: 0 Cardinality: 1
                         16 INDEX RANGE SCAN INDEX PARALLEL_COMBINED_WITH_PARENT CST_DSA.IDX$$_06EF0001 :Q1002Cost: 1 Bytes: 5 Cardinality: 1

SQL query with Bind variable with slower execution plan

I have a 'normal' sql select-insert statement (not using bind variable) and it yields the following execution plan:-
Execution Plan
0 INSERT STATEMENT Optimizer=CHOOSE (Cost=7 Card=1 Bytes=148)
1 0 HASH JOIN (Cost=7 Card=1 Bytes=148)
2 1 TABLE ACCESS (BY INDEX ROWID) OF 'TABLEA' (Cost=4 Card=1 Bytes=100)
3 2 INDEX (RANGE SCAN) OF 'TABLEA_IDX_2' (NON-UNIQUE) (Cost=3 Card=1)
4 1 INDEX (FAST FULL SCAN) OF 'TABLEB_IDX_003' (NON-UNIQUE)
(Cost=2 Card=135 Bytes=6480)
Statistics
0 recursive calls
18 db block gets
15558 consistent gets
47 physical reads
9896 redo size
423 bytes sent via SQL*Net to client
1095 bytes received via SQL*Net from client
3 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
55 rows processed
I have the same query but instead running using bind variable (I test it with both oracle form and SQL*plus), it takes considerably longer with a different execution plan:-
Execution Plan
0 INSERT STATEMENT Optimizer=CHOOSE (Cost=407 Card=1 Bytes=148)
1 0 TABLE ACCESS (BY INDEX ROWID) OF 'TABLEA' (Cost=3 Card=1 Bytes=100)
2 1 NESTED LOOPS (Cost=407 Card=1 Bytes=148)
3 2 INDEX (FAST FULL SCAN) OF TABLEB_IDX_003' (NON-UNIQUE) (Cost=2 Card=135 Bytes=6480)
4 2 INDEX (RANGE SCAN) OF 'TABLEA_IDX_2' (NON-UNIQUE) (Cost=2 Card=1)
Statistics
0 recursive calls
12 db block gets
3003199 consistent gets
54 physical reads
9448 redo size
423 bytes sent via SQL*Net to client
1258 bytes received via SQL*Net from client
3 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
55 rows processed
TABLEA has around 3million record while TABLEB has 300 records. Is there anyway I can improve the speed of the sql query with bind variable? I have DBA Access to the database
Regards
Ivan

Many thanks for your reply.
I have run the statistic already for the both tableA and tableB as well all the indexes associated with both table (using dbms_stats, I am on 9i db ) but not the indexed columns.
for table I use:-
begin
dbms_stats.gather_table_stats(ownname=> 'IVAN', tabname=> 'TABLEA', partname=> NULL);
end;
for index I use:-
begin
dbms_stats.gather_index_stats(ownname=> 'IVAN', indname=> 'TABLEB_IDX_003', partname=> NULL);
end;
Is it possible to show me a sample of how to collect statisc for INDEX columns stats?
regards
Ivan

How to measure the performance of sql query?

Hi Experts,
How to measure the performance, efficiency and cpu cost of a sql query?
What are all the measures available for an sql query?
How to identify i am writing optimal query?
I am using Oracle 9i...
It ll be useful for me to write efficient query....
Thanks & Regards

psram wrote:
Hi Experts,
How to measure the performance, efficiency and cpu cost of a sql query?
What are all the measures available for an sql query?
How to identify i am writing optimal query?
I am using Oracle 9i... You might want to start with a feature of SQL*Plus: The AUTOTRACE (TRACEONLY) option which executes your statement, fetches all records (if there is something to fetch) and shows you some basic statistics information, which include the number of logical I/Os performed, number of sorts etc.
This gives you an indication of the effectiveness of your statement, so that can check how many logical I/Os (and physical reads) had to be performed.
Note however that there are more things to consider, as you've already mentioned: The CPU bit is not included in these statistics, and the work performed by SQL workareas (e.g. by hash joins) is also credited only very limited (number of sorts), but e.g. it doesn't cover any writes to temporary segments due to sort or hash operations spilling to disk etc.
You can use the following approach to get a deeper understanding of the operations performed by each row source:
alter session set statistics_level=all;
alter session set timed_statistics = true;
select /* findme */ ... <your query here>
SELECT
         SUBSTR(LPAD(' ',DEPTH - 1)||OPERATION||' '||OBJECT_NAME,1,40) OPERATION,
         OBJECT_NAME,
         CARDINALITY,
         LAST_OUTPUT_ROWS,
         LAST_CR_BUFFER_GETS,
         LAST_DISK_READS,
         LAST_DISK_WRITES,
FROM     V$SQL_PLAN_STATISTICS_ALL P,
         (SELECT *
          FROM   (SELECT   *
                  FROM     V$SQL
                  WHERE    SQL_TEXT LIKE '%findme%'
                           AND SQL_TEXT NOT LIKE '%V$SQL%'
                           AND PARSING_USER_ID = SYS_CONTEXT('USERENV','CURRENT_USERID')
                  ORDER BY LAST_LOAD_TIME DESC)
          WHERE ROWNUM < 2) S
WHERE    S.HASH_VALUE = P.HASH_VALUE
         AND S.CHILD_NUMBER = P.CHILD_NUMBER
ORDER BY ID
/Check the V$SQL_PLAN_STATISTICS_ALL view for more statistics available. In 10g there is a convenient function DBMS_XPLAN.DISPLAY_CURSOR which can show this information with a single call, but in 9i you need to do it yourself.
Note that "statistics_level=all" adds a significant overhead to the processing, so use with care and only when required:
http://jonathanlewis.wordpress.com/2007/11/25/gather_plan_statistics/
http://jonathanlewis.wordpress.com/2007/04/26/heisenberg/
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/

SQL query execution Issue

Hi,
Facing Database performance issue while runing overnight batches.
Generate tfprof output for that batch and found some sql query which is having high elapsed time. Could any one please let me know what is the issue for this. It will also be great help if anyone suggest what need to be done as per tuning of this sql queries so as to get better responce time.
Waiting for your reply.
Effected SQL List:
INSERT INTO INVTRNEE (TRANS_SESSION, TRANS_SEQUENCE, TRANS_ORG_CHILD,
TRANS_PRD_CHILD, TRANS_TRN_CODE, TRANS_TYPE_CODE, TRANS_DATE, INV_MRPT_CODE,
INV_DRPT_CODE, TRANS_CURR_CODE, PROC_SOURCE, TRANS_REF, TRANS_REF2,
TRANS_QTY, TRANS_RETL, TRANS_COST, TRANS_VAT, TRANS_POS_EXT_TOTAL,
INNER_PK_TECH_KEY, TRANS_INNERS, TRANS_EACHES, TRANS_UOM, TRANS_WEIGHT,
TRANS_WEIGHT_UOM )
VALUES
(:B22 , :B1 , :B2 , :B3 , :B4 , :B5 , :B21 , :B6 , :B7 , :B8 , :B20 , :B19 ,
NULL, :B9 , :B10 , :B11 , 0.0, :B12 , :B13 , :B14 , :B15 , :B16 , :B17 ,
:B18 )
call count cpu elapsed disk query current rows
Parse 722 0.09 0.04 0 0 0 0
Execute 1060 7.96 83.01 11442 21598 88401 149973
Fetch 0 0.00 0.00 0 0 0 0
total 1782 8.05 83.06 11442 21598 88401 149973
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
UPDATE /*+ ROWID(TRFDTLEE) */TRFDTLEE SET TRF_STATUS = :B2
WHERE
ROWID = :B1
call count cpu elapsed disk query current rows
Parse 635 0.03 0.01 0 0 0 0
Execute 49902 14.48 271.25 41803 80704 355837 49902
Fetch 0 0.00 0.00 0 0 0 0
total 50537 14.51 271.27 41803 80704 355837 49902
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
DECLARE
var_trans_session     invtrnee.trans_session%TYPE;
BEGIN
-- ADDED BY SHANKAR ON 08/29/97
-- GET THE NEXT AVAILABLE TRANS_SESSION
bastkey('trans_session',0,var_trans_session,'T');
-- MAS001
uk_trfbapuo_auto(var_trans_session,'UPLOAD','T',300);
-- MAS001 end
END;
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 1 24191.23 24028.57 8172196 10533885 187888 1
Fetch 0 0.00 0.00 0 0 0 0
total 1 24191.23 24028.57 8172196 10533885 187888 1
Misses in library cache during parse: 0
Misses in library cache during execute: 1
Optimizer goal: CHOOSE
SELECT INNER_PK_TECH_KEY
FROM
PRDPCDEE WHERE PRD_LVL_CHILD = :B1 AND LOOSE_PACK_FLAG = 'T'
call count cpu elapsed disk query current rows
Parse 1 0.01 0.00 0 0 0 0
Execute 56081 1.90 2.03 0 0 0 0
Fetch 56081 11.07 458.58 53792 246017 0 56081
total 112163 12.98 460.61 53792 246017 0 56081
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
******************

First off, be aware of the assumptions I'm making. The SQL you presented above strongly suggests (to me at least) that you have cursor for loops. If that's the case, you need to review what their purpose is and look to convert them into single statement DML commands. For example if you have something like this
DECLARE
    ln_Count        NUMBER;
    ln_SomeValue    NUMBER;
BEGIN
    FOR lcr_Row IN (    SELECT pk_id,col1,col2 FROM some_table)
    LOOP
        SELECT
            COUNT(*)
        INTO
            ln_COunt
        FROM
            target_table
        WHERE
            pk_id = lcr_Row.pk_id;
        IF ln_Count = 0 THEN
            SELECT
                some_value
            INTO
                ln_SomeValue
            FROM
                some_other_table
            WHERE
                pk_id = lcr_Row.col1
            INSERT
            INTO
                target_table
                (   pk_id,
                    some_other_value,
                    col2
            VALUES
                (   lcr_Row.col1,
                    ln_SomeValue,
                    lcr_Row.col2
        ELSE
            UPDATE
                target_table
            SET
                some_other_value = ln_SomeValue
            WHERE
                pk_id = lcr_Row.col1;
        END IF;
    END LOOP;
END;                            it could be rewritten as
DECLARE
BEGIN
    MERGE INTO target_table b
    USING ( SELECT
                a.pk_id,
                a.col2,
                b.some_value
            FROM
                some_table a,
                some_other_table b
            WHERE
                b.pk_id = a.col1
           ) e
    ON (b.pk_id = e.pk_id)
    WHEN MATCHED THEN
      UPDATE SET b.some_other_value = e.some_value
    WHEN NOT MATCHED THEN
      INSERT ( b.pk_id,
                b.col2,
                b.some_other_value)
      VALUES(   b.pk_id,
                b.col2,
                b.some_value);
END;It's going to take a bit of analysis and work but the fastest and most scalable way to approach processing data is to use SQL rather than PL/SQL. PL/SQL data processing i.e. cursor loops should be an option of last resort.
HTH
David

SQL query Cost is high

Similar Messages

Maybe you are looking for