Performance problem in delete query

Hi,
I have to delete nearly 900 records from a table having 10 million records.
Each time I am deleting 100 of these records and calling this query from my
application many times. If I increase the rownum to 1000 then I get rollback
segment error due to limitation of user buffer.
Delete query is as follows
DELETE FROM try
WHERE DATEY2K<:b1
AND DATEY2K>0
AND ROWNUM<=100
where DATEY2K is a number field storin date information.
The TKPROF are as following
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 9 765.22 5705.34 1340105 1580307 27501 759
Fetch 0 0.00 0.00 0 0 0 0
total 9 765.22 5705.34 1340105 1580307 27501 759
Misses in library cache during parse: 0
Misses in library cache during execute: 1
Optimizer goal: FIRST_ROWS
Parsing user id: 14
Rows Execution Plan
0 DELETE STATEMENT GOAL: FIRST_ROWS
0 COUNT (STOPKEY)
0 TABLE ACCESS (BY ROWID) OF 'TRY'
0 INDEX (RANGE SCAN) OF 'ASH' (NON-UNIQUE)
The index ASH is on 2 columns of which first is DATEY2K.
Please advice/suggest to improve the performance of the above query.
Regards,
Ashish

What is the exact error message you are getting. It strikes me that if you cannot delete 900 records from any table, then your rollback is way too small.
Can you issue the query as a SELECT without the rownum?
John

Similar Messages

Performance Problem in Select query

Hi,
I have performance Problem in following Select Query :
SELECT VBELN POSNR LFIMG VRKME VGBEL VGPOS
FROM LIPS INTO CORRESPONDING FIELDS OF TABLE GT_LIPS
   FOR ALL ENTRIES IN GT_EKPO1
   WHERE VGBEL = GT_EKPO1-EBELN
     AND VGPOS = GT_EKPO1-EBELP.
as per trace i have analysed that it is fetch the complete table scan from the LIPS table and table contants almost 3 lakh records.
Kindly Suggest what we can do to optimize this query.
Regards,
Harsh

types: begin of line,
          vbeln type lips-vbeln
          posnr type lips-posnr
          lfimg type lips-lfimg
         vrkme type lips-vrkme
         vgbel type lips- vgbel
         vgpos type lips-vgpos
         end of line.
data: itab type standard table of line,
         wa type line.
IF GT_EKPO1[] IS NOT INITIAL.
SELECT VBELN POSNR LFIMG VRKME VGBEL VGPOS
FROM LIPS INTO TABLE ITAB
FOR ALL ENTRIES IN GT_EKPO1
WHERE VGBEL = GT_EKPO1-EBELN
AND VGPOS = GT_EKPO1-EBELP.
ENDIF.

Performance problem with report query

Hi,
I am encountering a performance issue with a page returning a report.
I have a page that has a region which joins 2 tables. One table has about 220,00 rows, while the other contains roughly 60,000 rows. In the region source of the report region, the query includes join condition with local variables. For example, the page is page 70, and some join conditions are:
and a.id=:P70_ID
and a.name like :P70_NAME
I run the query that returns a large number of rows from sqlplus, and it takes less than 30 sec to complete.
When I run the page, the report took about 3 minutes to return.
In this case, :P70_NAME is initialized to '%' on the page.
I then tried to substitute variable value directly in the query:
and a.id=1000
and a.name like '%'
this time the report returned in about 30 sec.
I then tried another thing which specified the region as "PL/SQL Function returning sql query", and modified the region as follows:
l_sql := '.......';
l_sql := l_sql || 'and a.id=' || v('P70_ID')
and similar substituting :P70_NAME to v('P70_NAME') and append its value to the l_sql string.
The report query page also returned in 30 sec.
Is there any known performance issue with using the bind variable (:PXX_XXX) in the report region?

If you are able.. flush the shared_pool, run your
report then query the v$sql_area or v$sql_text tables.
Or do a google query and look up Cary Milsap's piece on enabling extended trace .. there is your sure fire way of finding the problem sql. I am still learning htmldb but is there a way to alter session enable trace in some pre-query block?

Performance problem using distributed query

Hi,
Can anyone provide an explanation/solution to the following problem encountered on an 8.1.7 database:
SELECT /*+ DRIVING_SITE(vs) */
vs.col2
,user_defined_function
FROM v_remote_table_1 vs
,v_remote_table_2 vc
,local_table_1 s
WHERE vp.col1 = vs.col1
AND s.col1 = vs.col2
AND vs.col2 = &some_val
This generalised query joins two tables in a remote database schema to a table in the local database schema and returns a single row. Without the call to the local user defined function, my specific query returns the row in less than a second. As soon as I include any local user defined function call, even a call to a dummy function which simply returns a string, my query takes several minutes to return its row. Explain plan gives exactly the same plan for both versions of the query, but the statistics are different:
Version without call to function
================================
8 recursive calls
0 db block gets
7 consistent gets
0 physical reads
0 redo size
235 bytes sent via SQL*Net to client
311 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
Version with call to function
=============================
93 recursive calls
4 db block gets
109 consistent gets
1998 physical reads
0 redo size
288 bytes sent via SQL*Net to client
312 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
2 sorts (memory)
2 sorts (disk)
1 rows processed
I'm assuming that, when calling a local function, the DRIVING_SITE hint is ignored, but I don't know why. It's quite important that we are able to include the results of function calls in the query. Any ideas as to the cause of the degraded performance and possible solutions to it would be most welcome!
Thanks.....

I would try something like:
SELECT r.col2,user_defined_function
FROM (SELECT vs.col2
      FROM v_remote_table_1 vs, v_remote_table_2 vp
      WHERE vp.col1 = vs.col1 AND
            vs.col2 = &some_val) r,
     local_table_1 s
WHERE s.col1 = r.col2Thismay allow Oracle to better seperate the calls to the two databases.
HTH
John

Performance Problem with SQL Query

Hi
I have a SQL Query (say, SSS) which runs quite fast when I run it from TOAD.
But when the same query is being used as
INSERT INTO <table> VALUES <SSS>;
It is taking hours to complete.
The Original Query(OSQ) was changed to this SQL query(SSS) for Performance improvement.
The Cost has also improved quite a lot from OSQ to SSS. But when SSS runs from inside a procedure it is taking the same long hours as OSQ used to take.
Please help ASAP as it needs to get fixed.
Thanks
Arnab

SELECT SRM.ID PROJECT_ID,
SRM.UNIQUE_NAME PROJECT_CODE,
ODFP.GS_FINANCE_PROJ_CODE,
ODFP.GS_PRODUCT_CODE,
ODFP.GS_CUSTOMER,
ODFP.GS_LEGAL_ENT_REF,
ODF_PRJ_TYPE.NAME GS_PROJ_TYPE,
ODF_SRC_SYS.NAME GS_SOURCE_SYSTEM,
RESM.FIRST_NAME||' '||RESM.LAST_NAME GS_PROJECT_MANAGER,
ODFP.GS_LEG_PROJ_NUM,
ODFP.GS_SUPP_DOC ,
ODFP.GS_REQUEST_ID ,
ODFP.GS_CONTRACT ,
ODFP.GS_SIEBEL_REF,
DECODE(budg.ODF_PARENT_ID,NULL,PRJP.bdgt_cst_total, budg.lab_budg)LAB_BDGT,
DECODE(budg.ODF_PARENT_ID,NULL,0,budg.nli_budg)NLI_BDGT,
(DECODE(budg.ODF_PARENT_ID,NULL,PRJP.bdgt_cst_total, budg.lab_budg))+(DECODE(budg.ODF_PARENT_ID,NULL,0,budg.nli_budg)) sum_lab_nonlab_budg,
frct.LABOUR,
frct.NON_LABOUR,
frct.LABOUR+frct.NON_LABOUR FORCAST_TOT_SUM,
gfr.code GFR_CODE,
odfp.gs_rev_recognition,
rev_rec.NAME gs_rev_recognition,
DECODE(odfp.gs_prevent_reqtxn,1,'YES','0','NO','NO'),
GS_PROGTYPE.NAME,
COMM_APPR.UNIQUE_NAME COMM_APPROVER_EIN,
COMM_APPR.FIRST_NAME||' '||COMM_APPR.LAST_NAME COMM_APPROVER_NAME,
PR_APPR.UNIQUE_NAME PR_APPROVER_EIN,
PR_APPR.FIRST_NAME||' '||PR_APPR.LAST_NAME PR_APPROVER_NAME,
ODFP.GS_BILL_BUD,
frct.FRCST_REVENUE TOTAL_FRC_REVENUE,
actuals.LABOUR_ACTUALS,
actuals.NL_ACTUALS,
-- get_wip_totalcost(prjp.prid,'L') LABOUR_ACTUALS,
-- get_wip_totalcost(prjp.prid,'M') NL_ACTUALS,
ODFP.GS_ASS_PRODUCT_CODE,
PROJ_TEMPLATE.ID GS_PROJ_TEMPLATE_ID,
PROJ_TEMPLATE.UNIQUE_NAME GS_PROJ_TEMPLATE_CODE,
PROJ_TEMPLATE.name GS_PROJ_TEMPLATE_NAME,
DECODE( NVL(ODFP.GS_FIN_TEMPLATE,0) ,0,'NO',1,'YES') GS_FIN_TEMPLATE,
ODF_PRJ_TYPE.LOOKUP_CODE GS_PROJ_TYPE
FROM PROJECTS SRM,
J_PROJECTS PRJP,
A_PROJECT ODFP,
RESOURCES RESM,
s_gfr gfr,
RESOURCES PROJ_ACCT,
RESOURCES COMM_APPR,
RESOURCES PR_APPR,
(SELECT CAP.NAME
,LOOKUP.LOOKUP_CODE
FROM S_NLS CAP,
N_LOOKUPS LOOKUP
WHERE LOOKUP_TYPE ='GS_PROJECT_TYPE'
AND LOOKUP.ID =CAP.PK_ID
AND CAP.LANGUAGE_CODE='en'
AND CAP.TABLE_NAME = 'CMN_LOOKUPS') ODF_PRJ_TYPE,
(SELECT CAP.NAME
,LOOKUP.LOOKUP_CODE
FROM S_NLS CAP,
N_LOOKUPS LOOKUP
WHERE LOOKUP_TYPE ='GS_SOURCE_SYSTEM'
AND LOOKUP.ID =CAP.PK_ID
AND CAP.LANGUAGE_CODE='en'
AND CAP.TABLE_NAME = 'CMN_LOOKUPS') ODF_SRC_SYS,
(SELECT CAP.NAME
,LOOKUP.LOOKUP_CODE
FROM S_NLS CAP,
N_LOOKUPS LOOKUP
WHERE LOOKUP_TYPE ='GS_PROG_TYPE'
AND LOOKUP.ID =CAP.PK_ID
AND CAP.LANGUAGE_CODE='en'
AND CAP.TABLE_NAME = 'CMN_LOOKUPS')GS_PROGTYPE,
(SELECT odf_parent_id
,SUM(gs_lab_budg) lab_budg
,SUM(gs_nl_budg) nli_budg
FROM T_CHANGES
WHERE gs_status='APPR'
GROUP BY odf_parent_id) budg,
(SELECT CAP.NAME
,LOOKUP.LOOKUP_CODE
FROM S_NLS CAP,
N_LOOKUPS LOOKUP
WHERE LOOKUP_TYPE ='GS_REV_RECOGNITION'
AND LOOKUP.ID = CAP.PK_ID
AND CAP.LANGUAGE_CODE='en'
AND CAP.TABLE_NAME = 'CMN_LOOKUPS') rev_rec,
(SELECT FRCP1.project_id,
NVL(SUM(CASE WHEN srmr.resource_type=0 THEN for_val.cost ELSE NULL END),0) AS LABOUR,
NVL(SUM(CASE WHEN srmr.resource_type <> 0 THEN for_val.cost ELSE NULL END),0) AS NON_LABOUR,
NVL(SUM(for_val.revenue),0) AS FRCST_REVENUE
FROM T_PROPERTIES FRCP1,
T_DETAILS FOR_DET,
RESOURCES SRMR,
T_VALUES FOR_VAL
WHERE (FRCP1.project_id, revision) IN (SELECT project_id, MAX(revision)
FROM T_PROPERTIES FRCP
WHERE FRCP.status=2
AND FRCP.PERIOD_TYPE='SEMI_MONTHLY'
GROUP BY project_id)
AND FRCP1.PERIOD_TYPE='SEMI_MONTHLY'
AND FOR_DET.forecast_id=frcp1.id
AND SRMR.id(+)=FOR_DET.detail_id
AND FOR_VAL.currency_type='BILLING'
AND FOR_VAL.forecast_details_id=FOR_DET.ID
GROUP BY FRCP1.project_id) frct,
(SELECT srmp.id
,NVL(SUM(CASE WHEN wip.transtype='L' THEN WIPVAL.TOTALCOST ELSE NULL END),0) AS LABOUR_ACTUALS
,NVL(SUM(CASE WHEN wip.transtype='M' THEN WIPVAL.TOTALCOST ELSE NULL END),0) AS NL_ACTUALS
FROM A_WIP WIP
,om_periods biz
,P_VALUES WIPVAL
,PROJECTS SRMP
,A_PROJECT ODF
WHERE biz.period_type ='SEMI_MONTHLY'
AND TRUNC(wip.TRANSDATE) BETWEEN biz.start_date AND biz.end_date
AND WIP.TRANSNO=WIPVAL.TRANSNO
AND WIPVAL.CURRENCY_TYPE='BILLING'
AND SRMP.UNIQUE_NAME=WIP.PROJECT_CODE
AND SRMP.ID=ODF.ID
AND UPPER(ODF.partition_code)='GLOBAL'
AND UPPER(WIP.external_id) <> 'SPREADSHEET'
GROUP BY srmp.id) actuals,
RESOURCES BUD_HOLDER,
PROJECTS PROJ_TEMPLATE
WHERE SRM.ID = PRJP.PRID
AND ODFP.ID=PRJP.PRID
AND ODFP.PARTITION_CODE='GLOBAL'
AND RESM.id(+)=prjp.manager_id
AND ODFP.GS_PROJECT_TYPE = ODF_PRJ_TYPE.LOOKUP_CODE(+)
AND ODFP.GS_SOURCE_SYSTEM = ODF_SRC_SYS.LOOKUP_CODE(+)
AND ODFP.GS_prog_type = GS_PROGTYPE.LOOKUP_CODE(+)
AND budg.odf_parent_id(+)=SRM.ID
AND frct.project_id(+) = prjp.prid
AND ODFP.gs_risk_gfr=gfr.code(+)
AND ODFP.GS_REV_RECOGNITION=rev_rec.LOOKUP_CODE(+)
AND ODFP.GS_PROJ_ACCT = PROJ_ACCT.ID(+)
AND ODFP.GS_COMM_APPR = COMM_APPR.ID(+)
AND ODFP.GS_PR_APPR = PR_APPR.ID(+)
AND actuals.id(+) = prjp.prid -- Arnab
AND ODFP.GS_BUDGET_HOLDER=BUD_HOLDER.ID(+)
AND ODFP.GS_TEMPLATE_USED=PROJ_TEMPLATE.ID(+)
The above is OSQ with cost 45000. ... takes 1-1.5 hours through Toad
SELECT SRM.ID PROJECT_ID,
SRM.UNIQUE_NAME PROJECT_CODE,
ODFP.GS_FINANCE_PROJ_CODE,
ODFP.GS_PRODUCT_CODE,
ODFP.GS_CUSTOMER,
ODFP.GS_LEGAL_ENT_REF,
ODF_PRJ_TYPE.NAME GS_PROJ_TYPE,
ODF_SRC_SYS.NAME GS_SOURCE_SYSTEM,
RESM.FIRST_NAME||' '||RESM.LAST_NAME GS_PROJECT_MANAGER,
ODFP.GS_LEG_PROJ_NUM,
ODFP.GS_SUPP_DOC ,
ODFP.GS_REQUEST_ID ,
ODFP.GS_CONTRACT ,
ODFP.GS_SIEBEL_REF,
DECODE(budg.ODF_PARENT_ID,NULL,PRJP.bdgt_cst_total, budg.lab_budg)LAB_BDGT,
DECODE(budg.ODF_PARENT_ID,NULL,0,budg.nli_budg)NLI_BDGT,
(DECODE(budg.ODF_PARENT_ID,NULL,PRJP.bdgt_cst_total, budg.lab_budg))+(DECODE(budg.ODF_PARENT_ID,NULL,0,budg.nli_budg)) sum_lab_nonlab_budg,
frct.LABOUR,
frct.NON_LABOUR,
frct.LABOUR+frct.NON_LABOUR FORCAST_TOT_SUM,
gfr.code GFR_CODE,
odfp.gs_rev_recognition,
rev_rec.NAME gs_rev_recognition,
DECODE(odfp.gs_prevent_reqtxn,1,'YES','0','NO','NO'),
GS_PROGTYPE.NAME,
COMM_APPR.UNIQUE_NAME COMM_APPROVER_EIN,
COMM_APPR.FIRST_NAME||' '||COMM_APPR.LAST_NAME COMM_APPROVER_NAME,
PR_APPR.UNIQUE_NAME PR_APPROVER_EIN,
PR_APPR.FIRST_NAME||' '||PR_APPR.LAST_NAME PR_APPROVER_NAME,
ODFP.GS_BILL_BUD,
frct.FRCST_REVENUE TOTAL_FRC_REVENUE,
-- actuals.LABOUR_ACTUALS, -- Arnab
-- actuals.NL_ACTUALS, -- Arnab
get_wip_totalcost(prjp.prid,'L') LABOUR_ACTUALS, -- Arnab
get_wip_totalcost(prjp.prid,'M') NL_ACTUALS, -- Arnab
ODFP.GS_ASS_PRODUCT_CODE,
PROJ_TEMPLATE.ID GS_PROJ_TEMPLATE_ID,
PROJ_TEMPLATE.UNIQUE_NAME GS_PROJ_TEMPLATE_CODE,
PROJ_TEMPLATE.name GS_PROJ_TEMPLATE_NAME,
DECODE( NVL(ODFP.GS_FIN_TEMPLATE,0) ,0,'NO',1,'YES') GS_FIN_TEMPLATE,
ODF_PRJ_TYPE.LOOKUP_CODE GS_PROJ_TYPE
FROM PROJECTS SRM,
J_PROJECTS PRJP,
A_PROJECT ODFP,
RESOURCES RESM,
s_gfr gfr,
RESOURCES PROJ_ACCT,
RESOURCES COMM_APPR,
RESOURCES PR_APPR,
(SELECT CAP.NAME
,LOOKUP.LOOKUP_CODE
FROM S_NLS CAP,
N_LOOKUPS LOOKUP
WHERE LOOKUP_TYPE ='GS_PROJECT_TYPE'
AND LOOKUP.ID =CAP.PK_ID
AND CAP.LANGUAGE_CODE='en'
AND CAP.TABLE_NAME = 'CMN_LOOKUPS') ODF_PRJ_TYPE,
(SELECT CAP.NAME
,LOOKUP.LOOKUP_CODE
FROM S_NLS CAP,
N_LOOKUPS LOOKUP
WHERE LOOKUP_TYPE ='GS_SOURCE_SYSTEM'
AND LOOKUP.ID =CAP.PK_ID
AND CAP.LANGUAGE_CODE='en'
AND CAP.TABLE_NAME = 'CMN_LOOKUPS') ODF_SRC_SYS,
(SELECT CAP.NAME
,LOOKUP.LOOKUP_CODE
FROM S_NLS CAP,
N_LOOKUPS LOOKUP
WHERE LOOKUP_TYPE ='GS_PROG_TYPE'
AND LOOKUP.ID =CAP.PK_ID
AND CAP.LANGUAGE_CODE='en'
AND CAP.TABLE_NAME = 'CMN_LOOKUPS')GS_PROGTYPE,
(SELECT odf_parent_id
,SUM(gs_lab_budg) lab_budg
,SUM(gs_nl_budg) nli_budg
FROM T_CHANGES
WHERE gs_status='APPR'
GROUP BY odf_parent_id) budg,
(SELECT CAP.NAME
,LOOKUP.LOOKUP_CODE
FROM S_NLS CAP,
N_LOOKUPS LOOKUP
WHERE LOOKUP_TYPE ='GS_REV_RECOGNITION'
AND LOOKUP.ID = CAP.PK_ID
AND CAP.LANGUAGE_CODE='en'
AND CAP.TABLE_NAME = 'CMN_LOOKUPS') rev_rec,
(SELECT FRCP1.project_id,
NVL(SUM(CASE WHEN srmr.resource_type=0 THEN for_val.cost ELSE NULL END),0) AS LABOUR,
NVL(SUM(CASE WHEN srmr.resource_type <> 0 THEN for_val.cost ELSE NULL END),0) AS NON_LABOUR,
NVL(SUM(for_val.revenue),0) AS FRCST_REVENUE
FROM T_PROPERTIES FRCP1,
T_DETAILS FOR_DET,
RESOURCES SRMR,
T_VALUES FOR_VAL
WHERE (FRCP1.project_id, revision) IN (SELECT project_id, MAX(revision)
FROM T_PROPERTIES FRCP
WHERE FRCP.status=2
AND FRCP.PERIOD_TYPE='SEMI_MONTHLY'
GROUP BY project_id)
AND FRCP1.PERIOD_TYPE='SEMI_MONTHLY'
AND FOR_DET.forecast_id=frcp1.id
AND SRMR.id(+)=FOR_DET.detail_id
AND FOR_VAL.currency_type='BILLING'
AND FOR_VAL.forecast_details_id=FOR_DET.ID
GROUP BY FRCP1.project_id) frct,
/* (SELECT srmp.id
,NVL(SUM(CASE WHEN wip.transtype='L' THEN WIPVAL.TOTALCOST ELSE NULL END),0) AS LABOUR_ACTUALS
,NVL(SUM(CASE WHEN wip.transtype='M' THEN WIPVAL.TOTALCOST ELSE NULL END),0) AS NL_ACTUALS
FROM A_WIP WIP
,om_periods biz
,P_VALUES WIPVAL
,PROJECTS SRMP
,A_PROJECT ODF
WHERE biz.period_type ='SEMI_MONTHLY'
AND TRUNC(wip.TRANSDATE) BETWEEN biz.start_date AND biz.end_date
AND WIP.TRANSNO=WIPVAL.TRANSNO
AND WIPVAL.CURRENCY_TYPE='BILLING'
AND SRMP.UNIQUE_NAME=WIP.PROJECT_CODE
AND SRMP.ID=ODF.ID
AND UPPER(ODF.partition_code)='GLOBAL'
AND UPPER(WIP.external_id) <> 'SPREADSHEET'
GROUP BY srmp.id) actuals, */ -- Arnab
RESOURCES BUD_HOLDER,
PROJECTS PROJ_TEMPLATE
WHERE SRM.ID = PRJP.PRID
AND ODFP.ID=PRJP.PRID
AND ODFP.PARTITION_CODE='GLOBAL'
AND RESM.id(+)=prjp.manager_id
AND ODFP.GS_PROJECT_TYPE = ODF_PRJ_TYPE.LOOKUP_CODE(+)
AND ODFP.GS_SOURCE_SYSTEM = ODF_SRC_SYS.LOOKUP_CODE(+)
AND ODFP.GS_prog_type = GS_PROGTYPE.LOOKUP_CODE(+)
AND budg.odf_parent_id(+)=SRM.ID
AND frct.project_id(+) = prjp.prid
AND ODFP.gs_risk_gfr=gfr.code(+)
AND ODFP.GS_REV_RECOGNITION=rev_rec.LOOKUP_CODE(+)
AND ODFP.GS_PROJ_ACCT = PROJ_ACCT.ID(+)
AND ODFP.GS_COMM_APPR = COMM_APPR.ID(+)
AND ODFP.GS_PR_APPR = PR_APPR.ID(+)
AND actuals.id(+) = prjp.prid Arnab
AND ODFP.GS_BUDGET_HOLDER=BUD_HOLDER.ID(+)
AND ODFP.GS_TEMPLATE_USED=PROJ_TEMPLATE.ID(+)
This one in SSS where "-- Arnab " are only changes .....
The cost of this 7000.....finishes in 1 - 1.5 min in Toad
This is used as INSERT INTO TABLE <Select Query> ... this was taking 1.5 Hours to run.
It was changed using BULK COLLECT - still its taking around 1.5 hours to run...
Thanks
Arnab

Performance problem at Select Query

Hello all,
I have a performance question. Which code can i use instead of this code
" select * from t001a into table it_tp_auth where bukrs in kd_bukrs ".
thus the program runs faster ?
Regards
Heidi

Hi all,
that was my estimation. But I go into wrong direction.
I must TC : FB1lN optimize.
My Problem:
if I select my interval for company code largely, the program (RFITEMAP) is very slow. What I can make in this report, so that preformance becomes better.
Example: ( selection criterion )
company code : 1 to 200 -
> very slow
company code: 1 ---> normal
My estimation:
if I write a report, with same selection screen. In this report
can I call with (Submit) FBL1N and transfer all entered values to FBL1N ?
report:
report dummy.
tables: lfa.
select-options: bukrs for lfa-bukrs.
start-of-selection.
loop at bukrs into wa_bukrs.
SUBMIT FBL1N with p_param1 =wa_bukrs.
endloop.
is this realizable ?
best regards
Heidi
Edited by: Heidi Heinzberger on Sep 16, 2008 10:13 PM

Performance problem in select query again

Hi Experts,
I have another performance issue with this.
Select matnr werks from marc
          Into table i_marc
          For all entries in i_mara
          Where matnr eq i_mara-matnr.
     Loop at I_mara.
     Read table i_marc with key matnr = I_mara-matnr.
     Endloop.
When I showed this code to my boss he suggested me to do some performance tuning.But i do not have any idea what to do.I am already using for all entries.
Please suggest.
Neeti

Read statement fetches the record from the internal table using implicit key or explicit key. When no key or index is specified for the search criteria the key in the WA of the internal table is used implicitly for searching. Here the key or index is explicitly specified which is used for searching the records from internal table. This is faster than an implicit search.
When reading a single record in an internal table, the READ TABLE WITH KEY is not a direct READ. Therefore, SORT the table and use READ TABLE WITH KEY BINARY SEARCH.
Select matnr from mara
     Into table i_mara
     Where matnr in s_matnr.
     Select matnr werks from marc
     Into table i_marc
     For all entries in i_mara
Where matnr eq i_mara-matnr.
     Sort I_marc by matnr.
Loop at I_mara.
     Read table i_marc with key
matnr = I_mara-matnr
binary search.
     Endloop.

Query performance problem

I am having performance problems executing a query.
System:
Windows 2003 EE
Oracle 9i version 9.2.0.6
DETAIL table with 120Million rows partitioned in 19 partitions by SD_DATEKEY field
We are trying to retrieve the info from an account (SD_KEY) ordered by date (SD_DATEKEY). This account has about 7000 rows and it takes about 1 minute to return the first 100 rows ordered by SD_DATEKEY. This time should be around 5 seconds to be acceptable.
There is a partitioned index by SD_KEY and SD_DATEKEY.
This is the query:
SELECT * FROM DETAIL WHERE SD_KEY = 'xxxxxxxx' AND ROWNUM < 101 ORDER BY SD_DATEKEY
The problem is that all the 7000 rows are read prior to be ordered. I think that it is not necessary for the optimizer to access all the partitions to read all the rows because only the first 100 are needed and the partitions are bounded by SD_DATEKEY.
Any idea to accelerate this query? I know that including a WHERE clause for SD_DATEKEY will increase the performance but I need the first 100 rows and I don't know the date to limit the query.
Anybody knows if this time is a normal response time for tis query or should it be improved?
Thank to all in advance for the future help.

Thank to all for the replies.
- We have computed statistics and no changes in the response time.
- We are discussing about restrict the query to some partitions but for the moment this is not the best solution because we don't know where are the latest 100 rows.
- The query from Maurice had the same response time (more or less)
select * from
(SELECT * FROM DETAIL WHERE SD_KEY = 'xxxxxxxx' ORDER BY SD_DATEKEY)
where ROWNUM < 101
- We have a local index on SD_DATEKEY. Do we need another one on SD_KEY? Should it be created as BITMAP?
I can't test inmediately your sugestions because this is a problem with one of our customers. In our test system (that has only 10Million records) the indexes accelerate the query but this is not the same in the customer system. I think the problem is the total records on the table.

Query Performance Problem!! Oracle 25 minutes || SQLServer 3 minutes

Hi all,
I'm having a performance problem with this query bellow. It runs in 3 minutes on SQLServer and 25 minutes in Oracle.
SELECT
CASE WHEN (GROUPING(a.estado) = 1) THEN 'TOTAL'
ELSE ISNULL(a.estado, 'UNKNOWN')
END AS estado,
CASE WHEN (GROUPING(m.id_plano) = 1) THEN 'GERAL'
ELSE ISNULL(m.id_plano, 'UNKNOWN')
END AS id_plano,
sum(m.valor_2s_parcelas) valor_2s_parcelas,
convert(decimal(15,2),convert(int,sum(convert(int,(m.valor_2s_parcelas+.0000000001)*100)*
isnull(e.percentual,0.0))/100.0+.0000000001))/100 BB_Educar
FROM
movimento_dco m ,
evento_plano e,
agencia_tb a
WHERE
m.id_plano = e.id_plano
AND m.agencia *= a.prefixo
--AND m.id_plano LIKE 'pm60%'
AND m.data_pagamento >= '20070501'
AND m.data_pagamento <= '20070531'
AND m.codigo_retorno = '00'
AND m.id_parcela > 1
AND m.valor_2s_parcelas > 0.
AND e.id_evento = 'BB-Educar'
AND a.banco_id = '001'
AND a.ordem = '00'
group by m.id_plano, a.estado WITH ROLLUP
order by a.estado, m.id_plano DESC
Can anyone help me with this query?

What version of Oracle, what version of SQL? Are the tables the same exact size? are they both indexed the same? Are you running on the some or similar hardware? Are the Oracle parameters similar like SGA size and PGA_AGGREGATE Target? Did you run statistics in Oracle?
Did you compare execution plans in SQL Server vs Oracle to see if SQl Servers execution plan is more superior than the one Oracle is trying to use? (most likely stale statistics).
There are many variables and we need more information than just the Query : ).

Query performance problem - events 2505-read cache and 2510-write cache

Hi,
I am experiencing severe performance problems with a query, specifically with events 2505 (Read Cache) and 2510 (Write Cache) which went up to 11000 seconds on some executions. Data Manager (400 s), OLAP data selection (90 s) and OLAP user exit (250 s) are other the other event with noticeable times. All other events are very quick.
The query settings (RSRT) are
persistent cache across each app server -> cluster table,
update cache in delta process is checked ->group on infoprovider type
use cache despite virtual characteristics/key figs checked (one info-cube has1 virtual key figure which should have a static result for a day)
=>Do you know how I can get more details than what's in 0TCT_C02 to break down the read and write cache events time or do you have any recommandation?
I have checked and no dataloads were in progres on the info-providers and no master data loads (change run). Overall system performance was acceptable for other queries.
Thanks

Hi,
Looks like you're using BDB, not BDB JE, and this is the BDB JE forum. Could you please repost here?:
Berkeley DB
Thanks,
mark

Need Performance tuning in delete operation

Hi Gurus,
I am performing delete operation by following SQL query.
delete from gl_account where bu_id = -99
but it take long time to execute. Table contains 1 trigger and 5 index. I have disabled the trigger and rebuild the index but still it not executing.
Here is my explain plan.
Operation     Object Name     Rows     Bytes     Cost     Object Node     In/Out     PStart     PStop
DELETE STATEMENT Optimizer Mode=ALL_ROWS          561            19
DELETE     OFFLINETESTDB.GL_ACCOUNT
INDEX RANGE SCAN     OFFLINETESTDB.BU_ID     561      27 K     2
Pls help me out to solve this.

Hi All,
I am still facing the same performs problem for deleting row in a table.
here by i have attached my TKPROF for your consideration.
TKPROF: Release 10.2.0.1.0 - Production on Tue Oct 12 14:01:13 2010
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Trace file: rubikon_s002_3952.trc
Sort options: exeela exerow
count    = number of times OCI procedure was executed
cpu      = cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk     = number of physical reads of buffers from disk
query    = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows     = number of rows processed by the fetch or execute call
DELETE FROM GL_ACCOUNT
WHERE
GL_ACCT_ID IN (16908,16909,16456)
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.01       0.13          0          0          0           0
Execute      1      0.03       0.26          0          6        221           3
Fetch        0      0.00       0.00          0          0          0           0
total        2      0.04       0.40          0          6        221           3
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 40 (OFFLINETESTDB)
Rows     Row Source Operation
      0 DELETE GL_ACCOUNT (cr=177742 pr=160538 pw=0 time=31518664 us)
      3   INLIST ITERATOR (cr=6 pr=0 pw=0 time=103 us)
      3    INDEX RANGE SCAN GL_ACCOUNT_PK (cr=6 pr=0 pw=0 time=86 us)(object id 65637)
Rows     Execution Plan
      0 DELETE STATEMENT   MODE: ALL_ROWS
      0   DELETE OF 'GL_ACCOUNT'
      3    INLIST ITERATOR
      3     INDEX   MODE: ANALYZED (RANGE SCAN) OF 'GL_ACCOUNT_PK'
                (INDEX (UNIQUE))
select /*+ all_rows */ count(1)
from
"OFFLINETESTDB"."GL_ACCOUNT_SUMMARY" where "GL_ACCT_ID" = :1 and
"GL_ACCT_NO" = :2
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      3      0.00       0.06          0          0          0           0
Fetch        3      0.00       0.00          0          6          0           3
total        7      0.00       0.06          0          6          0           3
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS   (recursive depth: 1)
Rows     Row Source Operation
      3 SORT AGGREGATE (cr=6 pr=0 pw=0 time=236 us)
      0   VIEW index$_join$_001 (cr=6 pr=0 pw=0 time=185 us)
      0    HASH JOIN (cr=6 pr=0 pw=0 time=172 us)
      0     INDEX RANGE SCAN GL_ACCOUNT_SUMMARY_IX2 (cr=6 pr=0 pw=0 time=82 us)(object id 65648)
      0     INDEX RANGE SCAN GL_ACCOUNT_SUMMARY_IX1 (cr=0 pr=0 pw=0 time=0 us)(object id 65647)
select /*+ all_rows */ count(1)
from
"OFFLINETESTDB"."GL_ACCOUNT_QUARTERLY_STAT" where "GL_ACCT_ID" = :1 and
"GL_ACCT_NO" = :2
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      3      0.00       0.06          0          0          0           0
Fetch        3      1.64      20.79     108398     109500          0           3
total        7      1.64      20.86     108398     109500          0           3
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS   (recursive depth: 1)
Rows     Row Source Operation
      3 SORT AGGREGATE (cr=109500 pr=108398 pw=0 time=20797344 us)
      0   TABLE ACCESS FULL GL_ACCOUNT_QUARTERLY_STAT (cr=109500 pr=108398 pw=0 time=20797279 us)
select /*+ all_rows */ count(1)
from
"OFFLINETESTDB"."GL_ACCOUNT_MONTHLY_STAT" where "GL_ACCT_ID" = :1 and
"GL_ACCT_NO" = :2
call     count       cpu    elapsed       disk      query    current        rows
Parse        2      0.00       0.00          0          0          0           0
Execute      4      0.00       0.06          0          0          1           0
Fetch        3      0.75      10.11      52140      59532          0           3
total        9      0.75      10.18      52140      59532          1           3
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Parsing user id: SYS
Rows     Row Source Operation
      3 SORT AGGREGATE (cr=59532 pr=52140 pw=0 time=10116280 us)
      0   TABLE ACCESS FULL GL_ACCOUNT_MONTHLY_STAT (cr=59532 pr=52140 pw=0 time=10116221 us)
select /*+ all_rows */ count(1)
from
"OFFLINETESTDB"."GL_ACCOUNT_RECON_TXN_JOURNAL" where "GL_ACCT_ID" = :1
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      3      0.00       0.02          0          0          0           0
Fetch        3      0.00       0.00          0          9          0           3
total        7      0.00       0.02          0          9          0           3
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS   (recursive depth: 1)
Rows     Row Source Operation
      3 SORT AGGREGATE (cr=9 pr=0 pw=0 time=138 us)
      0   TABLE ACCESS FULL GL_ACCOUNT_RECON_TXN_JOURNAL (cr=9 pr=0 pw=0 time=97 us)
select text
from
view$ where rowid=:1
call     count       cpu    elapsed       disk      query    current        rows
Parse        3      0.01       0.00          0          0          0           0
Execute      3      0.01       0.00          0          0          2           0
Fetch        3      0.00       0.00          0          6          0           3
total        9      0.03       0.00          0          6          2           3
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: SYS   (recursive depth: 1)
Rows     Row Source Operation
      1 TABLE ACCESS BY USER ROWID VIEW$ (cr=1 pr=0 pw=0 time=34 us)
select /*+ all_rows */ count(1)
from
"OFFLINETESTDB"."GL_BULK_CRITERIA" where "GL_ACCT_ID" = :1
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      3      0.00       0.00          0          0          0           0
Fetch        3      0.00       0.00          0          9          0           3
total        7      0.00       0.00          0          9          0           3
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS   (recursive depth: 1)
Rows     Row Source Operation
      3 SORT AGGREGATE (cr=9 pr=0 pw=0 time=109 us)
      0   TABLE ACCESS FULL GL_BULK_CRITERIA (cr=9 pr=0 pw=0 time=71 us)
select /*+ all_rows */ count(1)
from
"OFFLINETESTDB"."GL_ACCOUNT_HISTORY" where "GL_ACCT_ID" = :1
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      3      0.00       0.00          0          0          0           0
Fetch        3      0.01       0.02          0       5070          0           3
total        7      0.01       0.02          0       5070          0           3
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS   (recursive depth: 1)
Rows     Row Source Operation
      3 SORT AGGREGATE (cr=5070 pr=0 pw=0 time=22519 us)
      0   TABLE ACCESS FULL GL_ACCOUNT_HISTORY (cr=5070 pr=0 pw=0 time=22472 us)
select /*+ all_rows */ count(1)
from
"OFFLINETESTDB"."GL_ACCOUNT_BULK_HISTORY" where "GL_ACCT_ID" = :1
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      3      0.00       0.00          0          0          0           0
Fetch        3      0.00       0.00          0          9          0           3
total        7      0.00       0.00          0          9          0           3
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS   (recursive depth: 1)
Rows     Row Source Operation
      3 SORT AGGREGATE (cr=9 pr=0 pw=0 time=106 us)
      0   TABLE ACCESS FULL GL_ACCOUNT_BULK_HISTORY (cr=9 pr=0 pw=0 time=69 us)
select /*+ all_rows */ count(1)
from
"OFFLINETESTDB"."GL_ALLOTMENT" where "POOL_ACCT_ID" = :1 and "POOL_ACCT_NO" =
   :2
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.02          0          0          0           0
Execute      3      0.00       0.00          0          0          0           0
Fetch        3      0.00       0.00          0          3          0           3
total        7      0.00       0.02          0          3          0           3
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS   (recursive depth: 1)
Rows     Row Source Operation
      3 SORT AGGREGATE (cr=3 pr=0 pw=0 time=113 us)
      0   TABLE ACCESS BY INDEX ROWID GL_ALLOTMENT (cr=3 pr=0 pw=0 time=68 us)
      0    INDEX RANGE SCAN GL_ALLOTMENT_IX1 (cr=3 pr=0 pw=0 time=50 us)(object id 65651)
select /*+ all_rows */ count(1)
from
"OFFLINETESTDB"."GL_ACCOUNT_YEARLY_STAT" where "GL_ACCT_ID" = :1 and
"GL_ACCT_NO" = :2
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      3      0.00       0.00          0          0          0           0
Fetch        3      0.01       0.01          0       3453          0           3
total        7      0.01       0.01          0       3453          0           3
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS   (recursive depth: 1)
Rows     Row Source Operation
      3 SORT AGGREGATE (cr=3453 pr=0 pw=0 time=10485 us)
      0   TABLE ACCESS FULL GL_ACCOUNT_YEARLY_STAT (cr=3453 pr=0 pw=0 time=10440 us)
select /*+ all_rows */ count(1)
from
"OFFLINETESTDB"."BU_GL_INTERFACE_ACCOUNT" where "CASH_GL_ACCT_ID" = :1 and
"CASH_GL_ACCT_NO" = :2
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      3      0.00       0.00          0          0          0           0
Fetch        3      0.00       0.00          0          9          0           3
total        7      0.00       0.00          0          9          0           3
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS   (recursive depth: 1)
Rows     Row Source Operation
      3 SORT AGGREGATE (cr=9 pr=0 pw=0 time=110 us)
      0   TABLE ACCESS FULL BU_GL_INTERFACE_ACCOUNT (cr=9 pr=0 pw=0 time=71 us)
select /*+ all_rows */ count(1)
from
"OFFLINETESTDB"."BU_GL_INTERFACE_ACCOUNT" where "DEPOT_GL_ACCT_ID" = :1 and
"DEPOT_GL_ACCT_NO" = :2
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      3      0.00       0.00          0          0          0           0
Fetch        3      0.00       0.00          0          9          0           3
total        7      0.00       0.00          0          9          0           3
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS   (recursive depth: 1)
Rows     Row Source Operation
      3 SORT AGGREGATE (cr=9 pr=0 pw=0 time=107 us)
      0   TABLE ACCESS FULL BU_GL_INTERFACE_ACCOUNT (cr=9 pr=0 pw=0 time=71 us)
select /*+ all_rows */ count(1)
from
"OFFLINETESTDB"."GL_TXN_ALLOTTEE" where "GL_ALLOTTEE_ACCT_ID" = :1 and
"GL_ALLOTTEE_ACCT_NO" = :2
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      3      0.00       0.00          0          0          0           0
Fetch        3      0.00       0.00          0          9          0           3
total        7      0.00       0.00          0          9          0           3
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS   (recursive depth: 1)
Rows     Row Source Operation
      3 SORT AGGREGATE (cr=9 pr=0 pw=0 time=122 us)
      0   TABLE ACCESS FULL GL_TXN_ALLOTTEE (cr=9 pr=0 pw=0 time=84 us)
select /*+ all_rows */ count(1)
from
"OFFLINETESTDB"."BU_GL_INTERFACE_ACCOUNT" where "POSN_GL_ACCT_ID" = :1 and
"POSN_GL_ACCT_NO" = :2
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      3      0.00       0.00          0          0          0           0
Fetch        3      0.00       0.00          0          9          0           3
total        7      0.00       0.00          0          9          0           3
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS   (recursive depth: 1)
Rows     Row Source Operation
      3 SORT AGGREGATE (cr=9 pr=0 pw=0 time=110 us)
      0   TABLE ACCESS FULL BU_GL_INTERFACE_ACCOUNT (cr=9 pr=0 pw=0 time=69 us)
select /*+ all_rows */ count(1)
from
"OFFLINETESTDB"."GL_ALLOTTEE" where "RECIPIENT_ACCT_ID" = :1 and
"RECIPIENT_ACCT_NO" = :2
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      3      0.00       0.00          0          0          0           0
Fetch        3      0.00       0.00          0          9          0           3
total        7      0.00       0.00          0          9          0           3
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS   (recursive depth: 1)
Rows     Row Source Operation
      3 SORT AGGREGATE (cr=9 pr=0 pw=0 time=155 us)
      0   TABLE ACCESS FULL GL_ALLOTTEE (cr=9 pr=0 pw=0 time=119 us)
select /*+ all_rows */ count(1)
from
"OFFLINETESTDB"."BU_GL_INTERFACE_ACCOUNT" where "INTER_BU_GL_ACCT_ID" = :1
and "INTER_BU_GL_ACCT_NO" = :2
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      3      0.00       0.00          0          0          0           0
Fetch        3      0.00       0.00          0          9          0           3
total        7      0.00       0.00          0          9          0           3
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS   (recursive depth: 1)
Rows     Row Source Operation
      3 SORT AGGREGATE (cr=9 pr=0 pw=0 time=102 us)
      0   TABLE ACCESS FULL BU_GL_INTERFACE_ACCOUNT (cr=9 pr=0 pw=0 time=67 us)
select /*+ all_rows */ count(1)
from
"OFFLINETESTDB"."GL_BUDGET_ITEM_DATA" where "GL_ACCT_ID" = :1
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      3      0.00       0.00          0          0          0           0
Fetch        3      0.00       0.00          0          9          0           3
total        7      0.00       0.00          0          9          0           3
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS   (recursive depth: 1)
Rows     Row Source Operation
      3 SORT AGGREGATE (cr=9 pr=0 pw=0 time=151 us)
      0   TABLE ACCESS FULL GL_BUDGET_ITEM_DATA (cr=9 pr=0 pw=0 time=108 us)
select /*+ all_rows */ count(1)
from
"OFFLINETESTDB"."GL_TOTALLING_ACCOUNT_LINE" where "GL_ACCT_ID" = :1
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.02          0          0          0           0
Execute      3      0.00       0.00          0          0          0           0
Fetch        3      0.00       0.00          0          9          0           3
total        7      0.00       0.02          0          9          0           3
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS   (recursive depth: 1)
Rows     Row Source Operation
      3 SORT AGGREGATE (cr=9 pr=0 pw=0 time=119 us)
      0   TABLE ACCESS FULL GL_TOTALLING_ACCOUNT_LINE (cr=9 pr=0 pw=0 time=82 us)
select /*+ all_rows */ count(1)
from
"OFFLINETESTDB"."SWEEP_FUNDS_XFER" where "TO_GL_ACCT_ID" = :1
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      3      0.01       0.00          0          0          0           0
Fetch        3      0.00       0.00          0          9          0           3
total        7      0.01       0.00          0          9          0           3
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS   (recursive depth: 1)
Rows     Row Source Operation
      3 SORT AGGREGATE (cr=9 pr=0 pw=0 time=123 us)
      0   TABLE ACCESS FULL SWEEP_FUNDS_XFER (cr=9 pr=0 pw=0 time=84 us)
select /*+ all_rows */ count(1)
from
"OFFLINETESTDB"."GL_ACCESS_ACCOUNT_LIST" where "GL_ACCT_ID" = :1
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      3      0.00       0.00          0          0          0           0
Fetch        3      0.00       0.00          0          9          0           3
total        7      0.00       0.00          0          9          0           3
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS   (recursive depth: 1)
Rows     Row Source Operation
      3 SORT AGGREGATE (cr=9 pr=0 pw=0 time=117 us)
      0   TABLE ACCESS FULL GL_ACCESS_ACCOUNT_LIST (cr=9 pr=0 pw=0 time=79 us)
select /*+ all_rows */ count(1)
from
"OFFLINETESTDB"."SETTLEMENT_BANK_ACCOUNT" where "MIRROR_GL_ACCT_ID" = :1
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      3      0.00       0.00          0          0          0           0
Fetch        3      0.00       0.00          0          9          0           3
total        7      0.00       0.00          0          9          0           3
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS   (recursive depth: 1)
Rows     Row Source Operation
      3 SORT AGGREGATE (cr=9 pr=0 pw=0 time=121 us)
      0   TABLE ACCESS FULL SETTLEMENT_BANK_ACCOUNT (cr=9 pr=0 pw=0 time=86 us)
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
Parse        8      0.01       0.29          0          0          8           0
Execute     11      0.03       0.32          0          6        222           3
Fetch        7      0.75      10.11      52140      59532          0           7
total       26      0.79      10.73      52140      59538        230          10
Misses in library cache during parse: 7
Misses in library cache during execute: 2
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call     count       cpu    elapsed       disk      query    current        rows
Parse       47      0.01       0.06          0          0          0           0
Execute     85      0.03       0.18          0          0          2           0
Fetch       85      1.67      20.83     108398     118214          0          85
total      217      1.71      21.08     108398     118214          2          85
Misses in library cache during parse: 21
Misses in library cache during execute: 20
    7 user SQL statements in session.
   48 internal SQL statements in session.
   55 SQL statements in session.
    5 statements EXPLAINed in this session.
Trace file: rubikon_s002_3952.trc
Trace file compatibility: 10.01.00
Sort options: exeela exerow
       1 session in tracefile.
       7 user SQL statements in trace file.
      48 internal SQL statements in trace file.
      55 SQL statements in trace file.
      29 unique SQL statements in trace file.
       5 SQL statements EXPLAINed using schema:
           OFFLINETESTDB.prof$plan_table
             Default table was used.
             Table was created.
             Table was dropped.
     548 lines in trace file.
      32 elapsed seconds in trace file.Thanks & Regards
Sami

XMLAGG performance problems

Hello,
I've been having performance problems with one query using XMLAGG. Explain plan shows that all tables are joined using correct indexes - there is nothing wrong with it. After series of experiments with the query I found out that the problem is in use of XMLAGG function. It aggregates the data before submitting it to the result XML document.
I there any way to generate something like
<Main attr1="...">
<el1>...</el1>
<el2>...</el2>
<SubElement>
<row>row1 from the database</row>
<row>row2 from the database</row>
<row>rowN from the database</row>
</SubElement>
<Main>
without using XMLAGG in the subquery or somehow switch the aggregation off? I dont really need the records to be aggregated, all I need is to be able to generate multiple record based XML in the subquery which would have normally failed on (single-row query returned more than one record exception) without XMLAGG.
Thanks in advance
Alexey

TKPROF: Release 9.2.0.1.0 - Production on Wed Jan 31 15:21:34 2007
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Trace file: lnsqd1_ora_7350_perfoamance_test_01.trc
Sort options: default
count = number of times OCI procedure was executed
cpu = cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk = number of physical reads of buffers from disk
query = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows = number of rows processed by the fetch or execute call
ALTER SESSION SET EVENTS '10046 trace name context forever, level 1'
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
total 1 0.00 0.00 0 0 0 0
Misses in library cache during parse: 0
Optimizer goal: ALL_ROWS
Parsing user id: 113
create table tmp_003
as
select a.*, 'NEW ' as eventtype
from v_deal_xml a
where a.deal_id in
select a.pk_value
from da_history a, gx_type b
where a.evtime <= to_date('1/22/2007 12:59:26', 'MM/DD/RRRR HH24:MI:SS')
and a.type_id = b.type_id
and b.xmltype = 'GDP/DEAL'
and a.eventtype = 'NEW'
call count cpu elapsed disk query current rows
Parse 1 0.12 0.12 0 60 1 0
Execute 1 108.30 105.87 0 6343 1387 172
Fetch 0 0.00 0.00 0 0 0 0
total 2 108.42 106.00 0 6403 1388 172
Misses in library cache during parse: 1
Optimizer goal: ALL_ROWS
Parsing user id: 113
insert into tmp_003
select a.*, 'UPDATE' as eventtype
from v_deal_xml a
where a.deal_id in
select a.pk_value --b.xmltype, a.*
from da_history a, gx_type b
where a.evtime <= to_date('1/22/2007 12:59:26', 'MM/DD/RRRR HH24:MI:SS')
and a.type_id = b.type_id
and b.xmltype = 'GDP/DEAL'
and a.eventtype = 'UPDATE'
call count cpu elapsed disk query current rows
Parse 1 0.13 0.13 0 60 0 0
Execute 1 256.74 250.96 0 18752 3815 381
Fetch 0 0.00 0.00 0 0 0 0
total 2 256.87 251.09 0 18812 3815 381
Misses in library cache during parse: 1
Optimizer goal: ALL_ROWS
Parsing user id: 113
Rows Row Source Operation
381 NESTED LOOPS (cr=1194 pr=0 pw=0 time=26458 us)
381 VIEW VW_NSO_1 (cr=430 pr=0 pw=0 time=6665 us)
381 SORT UNIQUE (cr=430 pr=0 pw=0 time=6285 us)
381 MERGE JOIN (cr=430 pr=0 pw=0 time=3761 us)
1 TABLE ACCESS BY INDEX ROWID GX_TYPE (cr=2 pr=0 pw=0 time=67 us)
5 INDEX FULL SCAN XPKGX_TYPE (cr=1 pr=0 pw=0 time=24 us)(object id 71282)
381 SORT JOIN (cr=428 pr=0 pw=0 time=3698 us)
603 TABLE ACCESS FULL DA_HISTORY (cr=428 pr=0 pw=0 time=1339 us)
381 TABLE ACCESS BY INDEX ROWID DEAL (cr=764 pr=0 pw=0 time=16692 us)
381 INDEX UNIQUE SCAN DEAL_PK (cr=383 pr=0 pw=0 time=8926 us)(object id 71236)
commit
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 1 0
Fetch 0 0.00 0.00 0 0 0 0
total 2 0.00 0.00 0 0 1 0
Misses in library cache during parse: 0
Parsing user id: 113
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 3 0.25 0.25 0 120 1 0
Execute 4 365.04 356.84 0 25095 5203 553
Fetch 0 0.00 0.00 0 0 0 0
total 7 365.29 357.10 0 25215 5204 553
Misses in library cache during parse: 2
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 83 0.01 0.01 0 0 0 0
Execute 125 0.03 0.03 0 108 201 46
Fetch 114 0.01 0.00 0 221 0 72
total 322 0.05 0.04 0 329 201 118
Misses in library cache during parse: 3
Misses in library cache during execute: 3
4 user SQL statements in session.
125 internal SQL statements in session.
129 SQL statements in session.
Trace file: lnsqd1_ora_7350_perfoamance_test_01.trc
Trace file compatibility: 9.00.01
Sort options: default
1 session in tracefile.
4 user SQL statements in trace file.
125 internal SQL statements in trace file.
129 SQL statements in trace file.
45 unique SQL statements in trace file.
11196 lines in trace file.

Performance Problems on Faces Navigation Diagram and Hyperthreading query

Am I the only one having performance problems when dealing with Faces-Config Diagrams of about 35 JSPs displayed on the sheet. using Jdev 10.1.3 It's taking my workstation about a full minute and a half to update the name of an arrow. The most stressed component during this task seems to be the CPU.
And just another question has anybody investigated how is the performance of Jdev affected by either enabling or disabling hyperthreading? In my case my CPU usage manages to reach only 50%. I'm tempted to switch HT off to let JDev use all the cpu power. if that would be the case.

Hello Diego,
you mentioned that you compared a BEx Query with the Web INtelligence report. Could you provide more details here ?
- what are the elements in the rows, columns and free characterisitcs in the BEx Query ?
- was the query execute as designed in the BEx Query Designer with BEx Web Reporting ?
- what are the elements in the WebIntelligence Query panel ?
thanks
Ingo

Top N query with INLIST Iterator performance problem

I have a top N query that is giving me problems on Oracle 11.2.0.3.
First of all, I have a query like the following (simplified from the real query, but produces the same problem):
    select /*+ gather_plan_statistics */ * from
      select rowid
      from payer_subscription ps
      where ps.subscription_status = :i_subscription_status
      and ps.merchant_id           = :merchant_id2
      order by transaction_date desc
    ) where rownum <= :i_rowcount; This query works well. It can very efficiently find me the top 10 rows for a massive data set, using an index on merchant_id, subscription_status, transaction_date.
    | Id | Operation                     | Name        | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
    |   0 | SELECT STATEMENT              |             |      1 |        |     10 |00:00:00.01 |       4 |
    |* 1 | COUNT STOPKEY                |             |      1 |        |     10 |00:00:00.01 |       4 |
    |   2 |   VIEW                        |             |      1 |     11 |     10 |00:00:00.01 |       4 |
    |* 3 |    INDEX RANGE SCAN DESCENDING| SODTEST2_IX |      1 |    100 |     10 |00:00:00.01 |       4 |
    -------------------------------------------------------------------------------------------------------As you can see the estimated actual rows at each stage are 10, which is correct.
Now, I have a requirement to get the top N records for a set of merchant_Ids, so if I change the query to include two merchant_ids, the performance tanks:
    select /*+ gather_plan_statistics */ * from
      select rowid
      from payer_subscription ps
      where ps.subscription_status = :i_subscription_status
          and (ps.merchant_id = :merchant_id or
               ps.merchant_id = :merchant_id2 )
      order by transaction_date desc
    ) where rownum <= :i_rowcount;
    | Id | Operation               | Name        | Starts | E-Rows | A-Rows |   A-Time   | Buffers | OMem | 1Mem | Used-Mem |
    |   0 | SELECT STATEMENT        |             |      1 |        |     10 |00:00:00.17 |     178 |       |       |          |
    |* 1 | COUNT STOPKEY          |             |      1 |        |     10 |00:00:00.17 |     178 |       |       |          |
    |   2 |   VIEW                  |             |      1 |    200 |     10 |00:00:00.17 |     178 |       |       |          |
    |* 3 |    SORT ORDER BY STOPKEY|             |      1 |    200 |     10 |00:00:00.17 |     178 | 2048 | 2048 | 2048 (0)|
    |   4 |     INLIST ITERATOR     |             |      1 |        | 42385 |00:00:00.10 |     178 |       |       |          |
    |* 5 |      INDEX RANGE SCAN   | SODTEST2_IX |      2 |    200 | 42385 |00:00:00.06 |     178 |       |       |          |Notice now that there are 42K rows coming out of the two index range scans - Oracle is no longer aborting the index range scan when it reaches 10 rows. What I thought would happen, is that Oracle would get at most 10 rows for each merchant_id, knowing that at most 10 rows are to be returned by the query. Then it would sort that 10 + 10 rows and output the top 10 based on the transaction date, but it refuses to do that.
Does anyone know how I can get the performance of the first query, when I need to pass a list of merchants into the query? I could probably get the performance using a union all, but the list of merchants is variable, and could be anywhere between 1 or 2 to several 100, so that makes that a bit unworkable.

Across the two merchants_id's there are about 42K rows (this is in test, on Prod there could be several million). In the first query example, Oracle can answer the query in about 4 logical IOs and without even doing a sort as it uses the index to scan and get the relevant rows in Oracle.
In the second case, I hoped it would pull 10 rows for each merchant_id and then sort the resulting 20 rows to find the top 10 ordered by transaction_date, but instead it is scanning far more rows than it needs to.
In my example, it takes 4 logical IOs to answer the first query, but ~ 170 to answer the second, while I think it is achievable in 8 or so. For example, this query does what I want, but it is not a feasible option due to how many merchant_id's I may have to deal with:
select /*+ gather_plan_statistics */ *
from
select *
from
    select * from
      select merchant_id, transaction_date
      from payer_subscription ps
      where ps.subscription_status = :i_subscription_status
      and ps.merchant_id = :merchant_id
      order by transaction_date desc
    ) where rownum <= :i_rowcount
    union all
    select * from
      select merchant_id, transaction_date
      from payer_subscription ps
      where ps.subscription_status = :i_subscription_status
      and ps.merchant_id = :merchant_id2
      order by transaction_date desc
    ) where rownum <= :i_rowcount
) order by transaction_date desc
) where rownum <= :i_rowcount;
| Id | Operation                          | Name        | Starts | E-Rows | A-Rows |   A-Time   | Buffers | OMem | 1Mem | Used-Mem |
|   0 | SELECT STATEMENT                   |             |      1 |        |     10 |00:00:00.01 |    6 |          |       |          |
|* 1 | COUNT STOPKEY                     |             |      1 |        |     10 |00:00:00.01 |    6 |          |       |          |
|   2 |   VIEW                             |             |      1 |     20 |     10 |00:00:00.01 |    6 |          |       |          |
|* 3 |    SORT ORDER BY STOPKEY           |             |      1 |     20 |     10 |00:00:00.01 |    6 | 2048 | 2048 | 2048 (0)|
|   4 |     VIEW                           |             |      1 |     20 |     20 |00:00:00.01 |    6 |          |       |          |
|   5 |      UNION-ALL                     |             |      1 |        |     20 |00:00:00.01 |    6 |          |       |          |
|* 6 |       COUNT STOPKEY                |             |      1 |        |     10 |00:00:00.01 |    3 |          |       |          |
|   7 |        VIEW                        |             |      1 |    100 |     10 |00:00:00.01 |    3 |          |       |          |
|* 8 |         INDEX RANGE SCAN DESCENDING| SODTEST2_IX |      1 |    100 |     10 |00:00:00.01 |    3 |          |       |          |
|* 9 |       COUNT STOPKEY                |             |      1 |        |     10 |00:00:00.01 |    3 |          |       |          |
| 10 |        VIEW                        |             |      1 |     11 |     10 |00:00:00.01 |    3 |          |       |          |
|* 11 |         INDEX RANGE SCAN DESCENDING| SODTEST2_IX |      1 |    100 |     10 |00:00:00.01 |    3 |          |       |          |
---------------------------------------------------------------------------------------------------------------------------------------This UNION ALL query completes in 6 logical IOs - the original query I posted with 2 IDs takes 178 to return the same results.

Performance problem querying multiple CLOBS

We are running Oracle 8.1.6 Standard Edition on Sun E420r, 2 X 450Mhz processors, 2 Gb memory
Solaris 7. I have created an Oracle Text indexes on several columns in a large table, including varchar2 and CLOB. I am simulating search engine queries where the user chooses to find matches on the exact phrase, all of the words (AND) and any of the words (OR). I am hitting performance problems when querying on multiple CLOBs using the OR, e.g.
select count(*) from articles
where contains (abstract , 'matter OR dark OR detection') > 0
or contains (subject , 'matter OR dark OR detection') > 0
Columns abstract and subject are CLOBs. However, this query works fine for AND;
select count(*) from articles
where contains (abstract , 'matter AND dark AND detection') > 0
or contains (subject , 'matter AND dark AND detection') > 0
The explain plan gives a cost of 2157 for OR and 14.3 for AND.
I realise that multiple contains are not a good thing, but the AND returns sub-second, and the OR is taking minutes! The indexes are created thus:
create index article_abstract_search on article(abstract)
INDEXTYPE IS ctxsys.context parameters ('STORAGE mystore memory 52428800');
The data and index tables are on separate tablespaces.
Can anyone suggest what is going on here, and any alternatives?
Many thanks,
Geoff Robinson

Thanks for your reply, Omar.
I have read the performance FAQ already, and it points out single CONTAINS clauses are preferred, but I need to check 2 columns. Also, I don't just want a count(*), I will need to select field values. As you can see from my 2 queries, the first has multiple CLOB columns using OR, and the second AND, with the second taking that much longer. Even with only a single CONTAINS, the cost estimate is 5 times more for OR than for AND.
Add an extra CONTAINS and it becomes 300 times more costly!
The root table is 3 million rows, the 2 token tables have 6.5 and 3 million rows respectively. All tables have been fully analyzed.
Regards
Geoff

Performance problem in delete query

Similar Messages

Maybe you are looking for