Simple query taking so long time to run
Below are the queries which are taking very long time to run. It pulls 4 million records approx on first query.
How can it run fast?
Thank you.
SELECTPerson_DEID[CP1] ,
Admit_DT,
Discharge_DT, DRG_CD,
cast (LineAllowedAmount
AS money)
as FacAA
into
FOET
FROMdbo.mh_fac_claims_final[CP2]
group
by Person_DEID,
Admit_DT,
Discharge_DT, DRG_CD,
LineAllowedAmount;
go
select
Person_DEID,
Admit_DT, Discharge_DT,
DRG_CD, sum(facAA)
as FacAA_SUM[CP3]
from
dbo.FOET
group
by Person_DEID,
Admit_DT,
Discharge_DT, DRG_CD,
facAA;
Below are the queries which are taking very long time to run. It pulls 4 million records approx on first query.
How can it run fast?
Thank you.
SELECTPerson_DEID[CP1] ,
Admit_DT,
Discharge_DT, DRG_CD,
cast (LineAllowedAmount
AS money)
as FacAA
into
FOET
FROMdbo.mh_fac_claims_final[CP2]
group
by Person_DEID,
Admit_DT,
Discharge_DT, DRG_CD,
LineAllowedAmount;
go
select
Person_DEID,
Admit_DT, Discharge_DT,
DRG_CD, sum(facAA)
as FacAA_SUM[CP3]
from
dbo.FOET
group
by Person_DEID,
Admit_DT,
Discharge_DT, DRG_CD,
facAA;
select Person_DEID,Admit_DT,Discharge_DT,DRG_CD, convert(money,sum(LineAllowedAmount)) as FacAA_SUM[CP3]
into FOET
FROM dbo.mh_fac_claims_final[CP2]
group by Person_DEID, Admit_DT, Discharge_DT, DRG_CD
There is no grouping, u are calculating 4m records in second query. Maybe try above instead (already suggested)? Can u check how long above query takes to run?
Similar Messages
-
Sql Query taking very long time to complete
Hi All,
DB:oracle 9i R2
OS:sun solaris 8
Below is the Sql Query taking very long time to complete
Could any one help me out regarding this.
SELECT MAX (md1.ID) ID, md1.request_id, md1.jlpp_transaction_id,
md1.transaction_version
FROM transaction_data_arc md1
WHERE md1.transaction_name = :b2
AND md1.transaction_type = 'REQUEST'
AND md1.message_type_code = :b1
AND NOT EXISTS (
SELECT NULL
FROM transaction_data_arc tdar2
WHERE tdar2.request_id = md1.request_id
AND tdar2.jlpp_transaction_id != md1.jlpp_transaction_id
AND tdar2.ID > md1.ID)
GROUP BY md1.request_id,
md1.jlpp_transaction_id,
md1.transaction_version
Any alternate query to get the same results?
kindly let me know if any one knows.
regards,
kk.
Edited by: kk001 on Apr 27, 2011 11:23 AMDear
/* Formatted on 2011/04/27 08:32 (Formatter Plus v4.8.8) */
SELECT MAX (md1.ID) ID, md1.request_id, md1.jlpp_transaction_id,
md1.transaction_version
FROM transaction_data_arc md1
WHERE md1.transaction_name = :b2
AND md1.transaction_type = 'REQUEST'
AND md1.message_type_code = :b1
AND NOT EXISTS (
SELECT NULL
FROM transaction_data_arc tdar2
WHERE tdar2.request_id = md1.request_id
AND tdar2.jlpp_transaction_id != md1.jlpp_transaction_id
AND tdar2.ID > md1.ID)
GROUP BY md1.request_id
,md1.jlpp_transaction_id
,md1.transaction_versionCould you please post here :
(a) the available indexes on transaction_data_arc table
(b) the description of transaction_data_arc table
(c) and the formatted explain plan you will get after executing the query and issuing:
select * from table (dbms_xplan.display_cursor);Hope this helps
Mohamed Houri -
DB 11.2.0.3.4
Server HP-UX IA 11.31
One big query is taking very long time. I am giving the explain plan along with stats from tkprof. If needed will give the query also. Can sombody tell me how can we improve this.
call count cpu elapsed disk query current rows
Parse 1 23.26 23.90 0 20 0 0
Execute 1 8055.11 9453.52 684215 348696 18750740 1306001
Fetch 0 0.00 0.00 0 0 0 0
total 2 8078.37 9477.42 684215 348716 18750740 1306001
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 322 (EDW_DM) (recursive depth: 1)
Rows Row Source Operation
0 LOAD TABLE CONVENTIONAL (cr=352254 pr=684215 pw=682074 time=863655932 us)
1306001 PX COORDINATOR (cr=15823 pr=682074 pw=682074 time=499947892 us)
0 PX SEND QC (RANDOM) :TQ20004 (cr=0 pr=0 pw=0 time=0 us cost=276195 size=126736955032 card=9998182)
0 BUFFER SORT (cr=0 pr=0 pw=0 time=0 us)
0 VIEW VW_FCT_PLN_SUMM_ADL_WK_XARH317 (cr=0 pr=0 pw=0 time=0 us cost=276195 size=126736955032 card=9998182)
0 UNION-ALL (cr=0 pr=0 pw=0 time=0 us)
0 SORT GROUP BY (cr=0 pr=0 pw=0 time=0 us cost=9167 size=95469948 card=378849)
0 PX RECEIVE (cr=0 pr=0 pw=0 time=0 us cost=9167 size=95469948 card=378849)
0 PX SEND HASH :TQ20003 (cr=0 pr=0 pw=0 time=0 us cost=9167 size=95469948 card=378849)
0 SORT GROUP BY (cr=0 pr=0 pw=0 time=0 us cost=9167 size=95469948 card=378849)
0 HASH JOIN RIGHT SEMI (cr=0 pr=0 pw=0 time=0 us cost=2714 size=95469948 card=378849)
0 BUFFER SORT (cr=0 pr=0 pw=0 time=0 us)
0 PX RECEIVE (cr=0 pr=0 pw=0 time=0 us cost=26 size=16428 card=4107)
0 PX SEND BROADCAST :TQ20000 (cr=0 pr=0 pw=0 time=0 us cost=26 size=16428 card=4107)
4857 VIEW VW_SQ_1 (cr=47 pr=0 pw=0 time=25403 us cost=26 size=16428 card=4107)
4857 HASH JOIN (cr=47 pr=0 pw=0 time=23353 us cost=26 size=229992 card=4107)
1115 TABLE ACCESS FULL DMN_PROD (cr=11 pr=0 pw=0 time=863 us cost=6 size=13380 card=1115)
4873 HASH JOIN (cr=36 pr=0 pw=0 time=12991 us cost=20 size=180840 card=4110)
55 TABLE ACCESS FULL DMN_MKT_DEFN (cr=3 pr=0 pw=0 time=286 us cost=4 size=1980 card=55)
18235 TABLE ACCESS FULL FCT_MKT_PROD_BRDG (cr=33 pr=0 pw=0 time=13550 us cost=15 size=145880 card=18235)
0 HASH JOIN (cr=0 pr=0 pw=0 time=0 us cost=2686 size=93954552 card=378849)
0 BUFFER SORT (cr=0 pr=0 pw=0 time=0 us)
0 PX RECEIVE (cr=0 pr=0 pw=0 time=0 us cost=111 size=403328 card=8768)
0 PX SEND BROADCAST :TQ20001 (cr=0 pr=0 pw=0 time=0 us cost=111 size=403328 card=8768)
8768 NESTED LOOPS (cr=274 pr=0 pw=0 time=15077 us cost=111 size=403328 card=8768)
1 NESTED LOOPS (cr=5 pr=0 pw=0 time=203 us cost=5 size=28 card=1)
1 TABLE ACCESS FULL DMN_WK_END (cr=2 pr=0 pw=0 time=81 us cost=3 size=8 card=1)
1 TABLE ACCESS BY INDEX ROWID DMN_CALN (cr=3 pr=0 pw=0 time=110 us cost=2 size=20 card=1)
1 INDEX RANGE SCAN XNU1_DMN_CALN (cr=2 pr=0 pw=0 time=73 us cost=1 size=0 card=1)(object id 303867)
8768 TABLE ACCESS FULL DMN_CALN (cr=269 pr=0 pw=0 time=11719 us cost=106 size=157824 card=8768)
0 PX BLOCK ITERATOR PARTITION: KEY KEY (cr=0 pr=0 pw=0 time=0 us cost=2573 size=76527498 card=378849)
0 TABLE ACCESS FULL FCT_NONRET_SLS_CURR_TRANS_WKLY PARTITION: 32 32 (cr=0 pr=0 pw=0 time=0 us cost=2573 size=76527498 card=378849)
0 BUFFER SORT (cr=0 pr=0 pw=0 time=0 us)
0 PX RECEIVE (cr=0 pr=0 pw=0 time=0 us cost=267028 size=2741509905 card=9619333)
0 PX SEND ROUND-ROBIN :TQ20002 (cr=0 pr=0 pw=0 time=0 us cost=267028 size=2741509905 card=9619333)
1284599 SORT GROUP BY (cr=15497 pr=682074 pw=682074 time=3839060439 us cost=267028 size=2741509905 card=9619333)
6439189 FILTER (cr=15486 pr=0 pw=0 time=57890179 us)
8986531 PX COORDINATOR (cr=279 pr=0 pw=0 time=52453034 us)
0 PX SEND QC (RANDOM) :TQ10001 (cr=0 pr=0 pw=0 time=0 us cost=80940 size=2741509905 card=9619333)
0 HASH JOIN (cr=0 pr=0 pw=0 time=0 us cost=80940 size=2741509905 card=9619333)
0 BUFFER SORT (cr=0 pr=0 pw=0 time=0 us)
0 PX RECEIVE (cr=0 pr=0 pw=0 time=0 us cost=111 size=403328 card=8768)
0 PX SEND BROADCAST :TQ10000 (cr=0 pr=0 pw=0 time=0 us cost=111 size=403328 card=8768)
8768 NESTED LOOPS (cr=274 pr=0 pw=0 time=14462 us cost=111 size=403328 card=8768)
1 NESTED LOOPS (cr=5 pr=0 pw=0 time=345 us cost=5 size=28 card=1)
1 TABLE ACCESS FULL DMN_WK_END (cr=2 pr=0 pw=0 time=193 us cost=3 size=8 card=1)
1 TABLE ACCESS BY INDEX ROWID DMN_CALN (cr=3 pr=0 pw=0 time=136 us cost=2 size=20 card=1)
1 INDEX RANGE SCAN XNU1_DMN_CALN (cr=2 pr=0 pw=0 time=76 us cost=1 size=0 card=1)(object id 303867)
8768 TABLE ACCESS FULL DMN_CALN (cr=269 pr=0 pw=0 time=9447 us cost=106 size=157824 card=8768)
0 PX BLOCK ITERATOR PARTITION: KEY KEY (cr=0 pr=0 pw=0 time=0 us cost=80801 size=2299020587 card=9619333)
0 TABLE ACCESS FULL FCT_PLN_RET_SLS_CURR_WKLY PARTITION: 30 30 (cr=0 pr=0 pw=0 time=0 us cost=80801 size=2299020587 card=9619333)
834 NESTED LOOPS (cr=15207 pr=0 pw=0 time=990747 us)
2269 NESTED LOOPS (cr=12938 pr=0 pw=0 time=1090852 us cost=17 size=56 card=1)
2269 NESTED LOOPS (cr=12101 pr=0 pw=0 time=1065238 us cost=16 size=20 card=1)
834 TABLE ACCESS BY INDEX ROWID DMN_PROD (cr=1676 pr=0 pw=0 time=37175 us cost=1 size=12 card=1)
838 INDEX UNIQUE SCAN XPKDIMENSION_PRODUCT (cr=838 pr=0 pw=0 time=23645 us cost=0 size=0 card=1)(object id 303870)
2269 TABLE ACCESS FULL FCT_MKT_PROD_BRDG (cr=10425 pr=0 pw=0 time=1024973 us cost=15 size=8 card=1)
2269 INDEX UNIQUE SCAN SYS_C0040182 (cr=837 pr=0 pw=0 time=15842 us cost=0 size=0 card=1)(object id 301873)
834 TABLE ACCESS BY INDEX ROWID DMN_MKT_DEFN (cr=2269 pr=0 pw=0 time=16488 us cost=1 size=36 card=1)
It would be appreciated if somebody check this.
Regards,
VirendraBelow is with the index on one of the table:
call count cpu elapsed disk query current rows
Parse 1 49.33 49.61 0 16 0 0
Execute 1 8374.08 10745.82 953712 473861 18818854 1306001
Fetch 0 0.00 0.00 0 0 0 0
total 2 8423.41 10795.43 953712 473877 18818854 1306001
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 322 (recursive depth: 1)
Rows Row Source Operation
0 LOAD TABLE CONVENTIONAL (cr=481416 pr=953712 pw=917687 time=2156047932 us)
1306001 PX COORDINATOR (cr=131828 pr=917687 pw=917687 time=1528317728 us)
0 PX SEND QC (RANDOM) :TQ10004 (cr=0 pr=0 pw=0 time=0 us cost=144212 size=16362383616 card=1290816)
0 BUFFER SORT (cr=0 pr=0 pw=0 time=0 us)
0 VIEW VW_FCT_PLN_SUM_ADL_WK_XRH317_1 (cr=0 pr=0 pw=0 time=0 us cost=144212 size=16362383616 card=1290816)
0 UNION-ALL (cr=0 pr=0 pw=0 time=0 us)
0 SORT GROUP BY (cr=0 pr=0 pw=0 time=0 us cost=9568 size=101394468 card=402359)
0 PX RECEIVE (cr=0 pr=0 pw=0 time=0 us cost=9568 size=101394468 card=402359)
0 PX SEND HASH :TQ10003 (cr=0 pr=0 pw=0 time=0 us cost=9568 size=101394468 card=402359)
0 SORT GROUP BY (cr=0 pr=0 pw=0 time=0 us cost=9568 size=101394468 card=402359)
0 HASH JOIN RIGHT SEMI (cr=0 pr=0 pw=0 time=0 us cost=2714 size=101394468 card=402359)
0 BUFFER SORT (cr=0 pr=0 pw=0 time=0 us)
0 PX RECEIVE (cr=0 pr=0 pw=0 time=0 us cost=26 size=16428 card=4107)
0 PX SEND BROADCAST :TQ10000 (cr=0 pr=0 pw=0 time=0 us cost=26 size=16428 card=4107)
4857 VIEW VW_SQ_1 (cr=47 pr=0 pw=0 time=25732 us cost=26 size=16428 card=4107)
4857 HASH JOIN (cr=47 pr=0 pw=0 time=23041 us cost=26 size=229992 card=4107)
1115 TABLE ACCESS FULL DMN_PROD (cr=11 pr=0 pw=0 time=1040 us cost=6 size=13380 card=1115)
4873 HASH JOIN (cr=36 pr=0 pw=0 time=12797 us cost=20 size=180840 card=4110)
55 TABLE ACCESS FULL DMN_MKT_DEFN (cr=3 pr=0 pw=0 time=185 us cost=4 size=1980 card=55)
18235 TABLE ACCESS FULL FCT_MKT_PROD_BRDG (cr=33 pr=0 pw=0 time=10014 us cost=15 size=145880 card=18235)
0 HASH JOIN (cr=0 pr=0 pw=0 time=0 us cost=2686 size=99785032 card=402359)
0 BUFFER SORT (cr=0 pr=0 pw=0 time=0 us)
0 PX RECEIVE (cr=0 pr=0 pw=0 time=0 us cost=111 size=403328 card=8768)
0 PX SEND BROADCAST :TQ10001 (cr=0 pr=0 pw=0 time=0 us cost=111 size=403328 card=8768)
8768 NESTED LOOPS (cr=274 pr=0 pw=0 time=13429 us cost=111 size=403328 card=8768)
1 NESTED LOOPS (cr=5 pr=0 pw=0 time=206 us cost=5 size=28 card=1)
1 TABLE ACCESS FULL DMN_WK_END (cr=2 pr=0 pw=0 time=82 us cost=3 size=8 card=1)
1 TABLE ACCESS BY INDEX ROWID DMN_CALN (cr=3 pr=0 pw=0 time=111 us cost=2 size=20 card=1)
1 INDEX RANGE SCAN XNU1_DMN_CALN (cr=2 pr=0 pw=0 time=80 us cost=1 size=0 card=1)(object id 303867)
8768 TABLE ACCESS FULL DMN_CALN (cr=269 pr=0 pw=0 time=9306 us cost=106 size=157824 card=8768)
0 PX BLOCK ITERATOR PARTITION: KEY KEY (cr=0 pr=0 pw=0 time=0 us cost=2573 size=81276518 card=402359)
0 TABLE ACCESS FULL FCT_NONRET_SLS_CURR_TRANS_WKLY PARTITION: 32 32 (cr=0 pr=0 pw=0 time=0 us cost=2573 size=81276518 card=402359)
0 BUFFER SORT (cr=0 pr=0 pw=0 time=0 us)
0 PX RECEIVE (cr=0 pr=0 pw=0 time=0 us cost=134645 size=256764073 card=888457)
0 PX SEND ROUND-ROBIN :TQ10002 (cr=0 pr=0 pw=0 time=0 us cost=134645 size=256764073 card=888457)
1284599 HASH GROUP BY (cr=131502 pr=917687 pw=917687 time=1052831032 us cost=134645 size=256764073 card=888457)
6439189 HASH JOIN RIGHT SEMI (cr=131490 pr=138092 pw=138092 time=374140098 us cost=100193 size=256764073 card=888457)
4857 VIEW VW_SQ_2 (cr=47 pr=0 pw=0 time=22869 us cost=26 size=16428 card=4107)
4857 HASH JOIN (cr=47 pr=0 pw=0 time=21073 us cost=26 size=229992 card=4107)
1115 TABLE ACCESS FULL DMN_PROD (cr=11 pr=0 pw=0 time=687 us cost=6 size=13380 card=1115)
4873 HASH JOIN (cr=36 pr=0 pw=0 time=12522 us cost=20 size=180840 card=4110)
55 TABLE ACCESS FULL DMN_MKT_DEFN (cr=3 pr=0 pw=0 time=242 us cost=4 size=1980 card=55)
18235 TABLE ACCESS FULL FCT_MKT_PROD_BRDG (cr=33 pr=0 pw=0 time=9883 us cost=15 size=145880 card=18235)
8986531 HASH JOIN (cr=131443 pr=138092 pw=138092 time=402921160 us cost=100161 size=253210245 card=888457)
8768 TABLE ACCESS FULL DMN_CALN (cr=269 pr=0 pw=0 time=11228 us cost=106 size=157824 card=8768)
8986531 MERGE JOIN CARTESIAN (cr=131174 pr=138092 pw=138092 time=382931385 us cost=100049 size=237218019 card=888457)
1 NESTED LOOPS (cr=5 pr=0 pw=0 time=251 us)
1 NESTED LOOPS (cr=4 pr=0 pw=0 time=225 us cost=5 size=28 card=1)
1 TABLE ACCESS FULL DMN_WK_END (cr=2 pr=0 pw=0 time=127 us cost=3 size=8 card=1)
1 INDEX RANGE SCAN XNU1_DMN_CALN (cr=2 pr=0 pw=0 time=88 us cost=1 size=0 card=1)(object id 303867)
1 TABLE ACCESS BY INDEX ROWID DMN_CALN (cr=1 pr=0 pw=0 time=17 us cost=2 size=20 card=1)
8986531 BUFFER SORT (cr=131169 pr=138092 pw=138092 time=378126634 us cost=100047 size=212341223 card=888457)
8986531 TABLE ACCESS BY GLOBAL INDEX ROWID FCT_PLN_RET_SLS_CURR_WKLY PARTITION: 30 30 (cr=131157 pr=0 pw=0 time=144384133 us cost=100044 size=212341223 card=888457)
9066976 INDEX RANGE SCAN SUBSTR_FCT_RET_SLS_CUR_WLY (cr=84385 pr=0 pw=0 time=93762049 us cost=83615 size=0 card=2856894)(object id 311617)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
os thread startup 2 0.08 0.15
PX Deq: Join ACK 4 0.00 0.00
PX Deq Credit: send blkd 455 2.21 55.10
PX Deq: Parse Reply 4 0.01 0.01
PX Deq: Execute Reply 250046 247.89 439.12
asynch descriptor resize 9 0.00 0.00
PX Deq Credit: need buffer 549 1.54 15.84
PX qref latch 235 0.01 0.18
Disk file operations I/O 42 0.00 0.00
direct path write temp 62665 0.25 365.50
direct path read temp 99442 0.46 1024.89
db file sequential read 36025 0.15 186.86
latch: object queue header operation 17 0.00 0.00
latch free 2 0.00 0.00
log file switch (private strand flush incomplete)
1 0.07 0.07
latch: messages 1 0.00 0.00
log file switch completion 14 0.08 0.79
latch: cache buffers chains 2 0.00 0.00
latch: redo allocation 1 0.00 0.00
PX Deq: Signal ACK RSG 4 0.06 0.07
PX Deq: Signal ACK EXT 4 0.00 0.01
PX Deq: Slave Session Stats 4 0.00 0.00
enq: PS - contention 1 0.00 0.00 -
Hi All,
Working in EBS Version 11.5.10.2
The below query takes a long time, Please i need some help in this issue
select ood.organization_name
,to_char(cd.transaction_date,'RRRR/MM/DD HH24:MI:SS') trx_date
,gcc.segment1||'.'||gcc.segment2||'.'||gcc.segment3||'.'||gcc.segment4||'.'||gcc.segment5||'.'||gcc.segment6||'.'||gcc.segment7 account
,cd.base_transaction_value
,decode(transaction_type_name,
'Resource transaction',resource_code,
'WIP Assy Completion', (select msi.segment1 from mtl_system_items_b msi where msi.inventory_item_id = cd.primary_item_id and msi.organization_id = cd.organization_id)
,(select msi.segment1 from mtl_system_items_b msi where msi.inventory_item_id = cd.inventory_item_id and msi.organization_id = cd.organization_id)
) item_sub_element
,cd.transaction_type_name
,cd.operation_seq_num
,cd.department_code
,cd.resource_seq_num
,cd.subinventory_code
,cd.line_type_name accounting_type
,cd.primary_uom
,cd.primary_quantity
,cd.wip_entity_name job
,cd.basis
,cd.line_id line
,(select wsg.schedule_group_name from wip_schedule_groups wsg
where wsg.schedule_group_id = wdj.schedule_group_id
and wsg.organization_id = wdj.organization_id
) schedule_group_name
,(select msib.segment1 from mtl_system_items_b msib
where msib.inventory_item_id = wdj.primary_item_id
and msib.organization_id = wdj.organization_id
) assembly
,decode(wdj.status_type,3,'Released',4,'Complete',6,'On-Hold',14,'Pending Close',15,'Failed Close',12,'Closed') job_status
,wdj.date_released
,wdj.date_completed job_completion_date
,wdj.date_closed job_closed_date
,decode(wdj.job_type,1,'Standard',3,'Non-Standard') job_type
,wdj.class_code job_class
,cd.reason_name
,cd.reference
from cst_distribution_v cd
,org_organization_definitions ood
,gl_code_combinations gcc
,wip_discrete_jobs wdj
where cd.organization_id = ood.organization_id
and cd.reference_account = gcc.code_combination_id
and cd.wip_entity_id = wdj.wip_entity_id
and cd.organization_id = wdj.organization_id
and cd.transaction_date between to_date(fdate, 'RRRR/MM/DD HH24:MI:SS') and to_date(tdate, 'RRRR/MM/DD HH24:MI:SS')
and cd.organization_id = nvl(p_org_id, cd.organization_id)
Regards
VijayThanks Pravin,
You are right,but after created the function based
index also it is going for FTS.
for example ,i created this sample table.
create index pp_idx1 on pp(substr(mobile_no,-10,4))
My DB Version :- 10.2
Optimizer_mode=FIRST_ROWS
If you can help me.
Thanks,
ChitrasenInstead of:
select * from <table_name> where substr(called_calling_no,-10,4)=9904;Try to stay with the same datatype. Don't rely in implizit type conversions.
select * from <table_name> where substr(called_calling_no,-10,4)='9904'; -
Connect by level query is taking too long time to run
Hello,
I have a query that returns quarters (YYYYQ) of a begin- and enddate within a specific id, that is built with a connect by level clause, but the query is running to long. I have used explain plan to see what the query is doing, but no silly things to see, just a full table scan, with low costs.
This is the query:
select to_char(add_months( cpj.crpj_start_date,3*(level - 1)),'YYYYQ') as sales_quarter
, cpj.crpj_id as crpj_id
from mv_gen_cra_projects cpj
where cpj.crpj_start_date >= to_date('01/01/2009','mm/dd/yyyy')
and cpj.crpj_start_date <= cpj.crpj_end_date
and cpj.crpj_routing_type = 'A'
and ( cpj.crpj_multi_artist_ind = 'N'
or cpj.crpj_multi_artist_ind is null)
connect by level <= 1 + ceil(months_between(cpj.crpj_end_date,cpj.crpj_start_date)/3);
The result have to be like this:
SALES_QUARTER CRPJ_ID
20091 100
20092 100
20093 100
20094 100
20101 100
20102 100
Can anyone help me out with this?but no silly things to see, just a full table scan, with low costs.Well, maybe an index scan would be faster?
However:
You will need to provide us some more details, like:
- database version (the result of: SQL> select * from v$version;)
- post the explain plan output (put the tag before and after it, so indentation and formatting are maintained, see the [FAQ|http://forums.oracle.com/forums/help.jspa] for more explanation regarding tags )
- what are your optimizer settings (the result of: SQL> show parameter optimizer)
- if applicable: are your table statistics up to date?
- mv_gen_cra_projects is a materialized view perhaps?
Edited by: hoek on Jan 26, 2010 10:50 AM -
Hello all i hav a query which is taking result from 4 tables
select name, date, emp_id, salary from table1, table2, table3,table4 where date= :date and other conditions
but when im doing same query and changin date format
select name, date, emp_id, salary from table1, table2, table3,table4 where date= TO_DATE(:date,'DD/MM/RRRR') and other conditions
the query is gettin hang no response
please advice.
ThanksExecution Plan
Plan hash value: 2265139331
Id Operation Name Rows Bytes Cost (%CPU) Time
0 SELECT STATEMENT 14647 3146K 1443 (1) 00:00:18
1 HASH GROUP BY 14647 3146K
2 CONCATENATION
3 MERGE JOIN CARTESIAN 8444 1814K 738 (1) 00:00:09
4 NESTED LOOPS
5 NESTED LOOPS 1 202 635 (1) 00:00:08
6 NESTED LOOPS 1 138 633 (1) 00:00:08
7 NESTED LOOPS 1 103 632 (1) 00:00:08
8 NESTED LOOPS 1 85 631 (1) 00:00:08
9 VIEW table 3 84 628 (1) 00:00:08
10 UNION-ALL
* 11 HASH JOIN 1 37 279 (1) 00:00:04
* 12 TABLE ACCESS BY INDEX ROWID table 1 31 4 (0) 00:00:01
* 13 INDEX RANGE SCAN table 1 3 (0) 00:00:01
14 TABLE ACCESS FULL table 9472 56832 275 (1) 00:00:04
* 15 HASH JOIN 1 37 319 (1) 00:00:04
* 16 TABLE ACCESS BY INDEX ROWID table 1 31 10 (0) 00:00:01
* 17 INDEX RANGE SCAN table 1 9 (0) 00:00:01
18 TABLE ACCESS FULL table 36233 212K 308 (1) 00:00:04
* 19 HASH JOIN 1 43 31 (4) 00:00:01
* 20 TABLE ACCESS BY INDEX ROWID table 1 37 3 (0) 00:00:01
* 21 INDEX RANGE SCAN table 1 2 (0) 00:00:01
22 TABLE ACCESS FULL table 2546 15276 27 (0) 00:00:01
23 TABLE ACCESS BY INDEX ROWID table 1 57 1 (0) 00:00:01
* 24 INDEX UNIQUE SCAN table 1 0 (0) 00:00:01
25 TABLE ACCESS BY INDEX ROWID table 1 18 1 (0) 00:00:01
* 26 INDEX UNIQUE SCAN table 1 0 (0) 00:00:01
27 TABLE ACCESS BY INDEX ROWID table 1 35 1 (0) 00:00:01
* 28 INDEX UNIQUE SCAN table 1 0 (0) 00:00:01
* 29 INDEX RANGE SCAN table 2 1 (0) 00:00:01
30 TABLE ACCESS BY INDEX ROWID table 2 128 2 (0) 00:00:01
31 BUFFER SORT 7977 140K 736 (1) 00:00:09
32 TABLE ACCESS FULL table 7977 140K 102 (0) 00:00:02
33 NESTED LOOPS 310 68200 704 (1) 00:00:09
34 NESTED LOOPS 1 202 635 (1) 00:00:08
35 NESTED LOOPS 1 138 633 (1) 00:00:08
36 NESTED LOOPS 1 103 632 (1) 00:00:08
37 NESTED LOOPS 1 85 631 (1) 00:00:08
38 VIEW table 3 84 628 (1) 00:00:08
39 UNION-ALL
* 40 HASH JOIN 1 37 279 (1) 00:00:04
* 41 TABLE ACCESS BY INDEX ROWID table 1 31 4 (0) 00:00:01 * 41 TABLE ACCESS BY INDEX ROWID table131 4 (0) 00:00:01
* 42 INDEX RANGE SCAN table 1 3 (0) 00:00:01
43 TABLE ACCESS FULL table 9472 56832 275 (1) 00:00:04
* 44 HASH JOIN 1 37 319 (1) 00:00:04
* 45 TABLE ACCESS BY INDEX ROWID table 1 31 10 (0) 00:00:01
* 46 INDEX RANGE SCAN table 1 9 (0) 00:00:01
47 TABLE ACCESS FULL table 36233 212K 308 (1) 00:00:04
* 48 HASH JOIN 1 43 31 (4) 00:00:01
* 49 TABLE ACCESS BY INDEX ROWID table 1 37 3 (0) 00:00:01
* 50 INDEX RANGE SCAN table 1 2 (0) 00:00:01
51 TABLE ACCESS FULL table 2546 15276 27 (0) 00:00:01
52 TABLE ACCESS BY INDEX ROWID table 1 57 1 (0) 00:00:01
* 53 INDEX UNIQUE SCAN table 1 0 (0) 00:00:01
54 TABLE ACCESS BY INDEX ROWID table 1 18 1 (0) 00:00:01
* 55 INDEX UNIQUE SCAN table 1 0 (0) 00:00:01
56 TABLE ACCESS BY INDEX ROWID table 1 35 1 (0) 00:00:01
* 57 INDEX UNIQUE SCAN table 1 0 (0) 00:00:01
58 TABLE ACCESS BY INDEX ROWID table 2 128 2 (0) 00:00:01
* 59 INDEX RANGE SCAN table 2 1 (0) 00:00:01
* 60 TABLE ACCESS FULL table 293 5274 68 (0) 00:00:01
Predicate Information (identified by operation id):
3 - access("a.id"="b.id")
12 - access("a.id"="b.id")
13 - filter("a.id"="b.id")
14 - access("a.id"="b.id")
16 - access("a.id"="b.id")
17 - filter("a.id"="b.id")
18 - access("a.id"="b.id")
20 - access("a.id"="b.id")
21 - filter("a.id"="b.id")
22 - access("a.id"="b.id")
25 - access("a.id"="b.id")AND ("a.id"="b.id")
27 - access("a.id"="b.id")
28 - access("a.id"="b.id")
32 - access("a.id"="b.id")
36 - access("a.id"="b.id")AND ("a.id"="b.id")
37 - filter("a.id"="b.id")
40 - access("a.id"="b.id")
41 - filter("a.id"="b.id")
42 - access("a.id"="b.id")
44 - access("a.id"="b.id")
45 - filter("a.id"="b.id")
46 - access("a.id"="b.id")
48 - access("a.id"="b.id")
49 - filter("a.id"="b.id")
50 - access("a.id"="b.id")
Statistics
71 recursive calls
0 db block gets
2975 consistent gets
0 physical reads
0 redo size
2172 bytes sent via SQL*Net to client
520 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
1 rows processed -
Urgent: Query taking a long time
Hi, I have this query which is taking about 1 hour to complete. It is suppose to complete in less than 2 min. Please help to tune it. I have given the details below.
SQL> SELECT co_trans_master.co_trans_no, co_charge.co_no,
2 co_charge.charge_no,
3 co_charge.created_date created_date,
4 NVL (co_ch_amt_variation.ch_amt_owing_ind,
5 co_charge_amount.ch_amt_owing_ind
6 ) ch_amt_owing_ind,
7 NVL (co_ch_amt_variation.ch_secured_amt,
8 co_charge_amount.ch_secured_amt
9 ) ch_secured_amt,
10 NVL (co_ch_det_variation.ch_chargee_name,
11 NVL (co_chargee_detail.ch_chargee_name, '-')
12 ) ch_chargee_name,
13 NVL (co_ch_det_variation.ch_chargee_id,
14 co_chargee_detail.ch_chargee_id
15 ) ch_chargee_id,
16 NVL (m_currency_variation.currency_desc,
17 m_currency.currency_desc
18 ) currency_desc,
19 NULL satisfaction_type
20 FROM co_charge co_charge,
21 co_trans_master,
22 co_charge_amount co_charge_amount,
23 co_chargee_detail co_chargee_detail,
24 m_currency,
25 co_charge_variation ch_variation,
26 co_charge_amount co_ch_amt_variation,
27 co_chargee_detail co_ch_det_variation,
28 m_currency m_currency_variation
29 WHERE co_charge.co_trans_no(+) = co_trans_master.co_trans_no
30 AND co_charge.co_trans_no = co_charge_amount.co_trans_no(+)
31 AND co_charge.co_trans_no = co_chargee_detail.co_trans_no(+)
32 AND co_charge_amount.ch_currency_code = m_currency.currency_code(+)
33 AND co_charge.charge_no = ch_variation.charge_no(+)
34 AND ch_variation.co_trans_no = co_ch_amt_variation.co_trans_no(+)
35 AND ch_variation.co_trans_no = co_ch_det_variation.co_trans_no(+)
36 AND co_ch_amt_variation.ch_currency_code = m_currency_variation.currency_code(+)
37 AND NVL (co_trans_master.void_ind, 'N') = 'N'
38 AND NVL (co_trans_master.expunged_ind, 'N') = 'N'
39 AND NVL (co_charge.approved_ind, 'Y') = 'Y'
40 AND NVL (co_charge.void_ind, 'N') = 'N'
41 AND NVL (co_trans_master.status_ind, '1') <> '2'
42 AND NOT EXISTS (
43 SELECT 'x'
44 FROM co_charge_satisfaction a, co_chargee_endorse b
45 WHERE b.co_trans_no = a.co_trans_no
46 AND b.ch_endorse_date IS NULL
47 AND a.receipt_no IS NULL
48 AND a.charge_no = co_charge.charge_no)
49 ORDER BY 3, 7;
6268140 rows selected.
Elapsed: 00:02:01.28
Execution Plan
Plan hash value: 596548904
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 158K| 38M| | 82555 (1)| 00:16:31 |
| 1 | SORT ORDER BY | | 158K| 38M| 41M| 82555 (1)| 00:16:31 |
|* 2 | HASH JOIN RIGHT OUTER | | 158K| 38M| | 73751 (1)| 00:14:46 |
| 3 | INDEX FULL SCAN | PK_M_CURRENCY | 170 | 3910 | | 1 (0)| 00:00:01 |
|* 4 | HASH JOIN RIGHT OUTER | | 158K| 35M| | 73749 (1)| 00:14:45 |
| 5 | INDEX FULL SCAN | PK_M_CURRENCY | 170 | 3910 | | 1 (0)| 00:00:01 |
|* 6 | HASH JOIN RIGHT OUTER | | 158K| 31M| 3368K| 73746 (1)| 00:14:45 |
| 7 | TABLE ACCESS FULL | CO_CHARGE_AMOUNT | 127K| 1867K| | 208 (1)| 00:00:03 |
|* 8 | HASH JOIN RIGHT OUTER | | 124K| 23M| 2944K| 72146 (1)| 00:14:26 |
| 9 | TABLE ACCESS FULL | CO_CHARGEE_DETAIL | 47048 | 2389K| | 223 (1)| 00:00:03 |
|* 10 | HASH JOIN RIGHT OUTER | | 124K| 17M| | 70859 (1)| 00:14:11 |
| 11 | VIEW | index$_join$_006 | 120 | 2280 | | 3 (34)| 00:00:01 |
|* 12 | HASH JOIN | | | | | | |
| 13 | INDEX FAST FULL SCAN | IDX_CO_CH_VARIATION_CHARGENO | 120 | 2280 | | 1 (0)| 00:00:01 |
| 14 | INDEX FAST FULL SCAN | SYS_C0099185 | 120 | 2280 | | 1 (0)| 00:00:01 |
|* 15 | HASH JOIN RIGHT ANTI | | 62457 | 7624K| | 70855 (1)| 00:14:11 |
| 16 | VIEW | VW_SQ_1 | 116 | 928 | | 119 (0)| 00:00:02 |
| 17 | NESTED LOOPS | | | | | | |
| 18 | NESTED LOOPS | | 116 | 3828 | | 119 (0)| 00:00:02 |
|* 19 | TABLE ACCESS FULL | CO_CHARGEE_ENDORSE | 116 | 1392 | | 3 (0)| 00:00:01 |
|* 20 | INDEX UNIQUE SCAN | SYS_C0099142 | 1 | | | 0 (0)| 00:00:01 |
|* 21 | TABLE ACCESS BY INDEX ROWID| CO_CHARGE_SATISFACTION | 1 | 21 | | 1 (0)| 00:00:01 |
|* 22 | HASH JOIN RIGHT OUTER | | 6245K| 696M| 2944K| 70704 (1)| 00:14:09 |
| 23 | TABLE ACCESS FULL | CO_CHARGEE_DETAIL | 47048 | 2389K| | 223 (1)| 00:00:03 |
|* 24 | HASH JOIN RIGHT OUTER | | 6245K| 387M| 3368K| 47539 (1)| 00:09:31 |
| 25 | TABLE ACCESS FULL | CO_CHARGE_AMOUNT | 127K| 1867K| | 208 (1)| 00:00:03 |
|* 26 | FILTER | | | | | | |
|* 27 | HASH JOIN RIGHT OUTER | | 6245K| 297M| 7592K| 28796 (2)| 00:05:46 |
| 28 | TABLE ACCESS FULL | CO_CHARGE | 158K| 5727K| | 932 (2)| 00:00:12 |
|* 29 | TABLE ACCESS FULL | CO_TRANS_MASTER | 6245K| 77M| | 20050 (2)| 00:04:01 |
Predicate Information (identified by operation id):
2 - access("CO_CH_AMT_VARIATION"."CH_CURRENCY_CODE"="M_CURRENCY_VARIATION"."CURRENCY_CODE"(+))
4 - access("CO_CHARGE_AMOUNT"."CH_CURRENCY_CODE"="M_CURRENCY"."CURRENCY_CODE"(+))
6 - access("CH_VARIATION"."CO_TRANS_NO"="CO_CH_AMT_VARIATION"."CO_TRANS_NO"(+))
8 - access("CH_VARIATION"."CO_TRANS_NO"="CO_CH_DET_VARIATION"."CO_TRANS_NO"(+))
10 - access("CO_CHARGE"."CHARGE_NO"="CH_VARIATION"."CHARGE_NO"(+))
12 - access(ROWID=ROWID)
15 - access("ITEM_1"="CO_CHARGE"."CHARGE_NO")
19 - filter("B"."CH_ENDORSE_DATE" IS NULL)
20 - access("B"."CO_TRANS_NO"="A"."CO_TRANS_NO")
21 - filter("A"."RECEIPT_NO" IS NULL)
22 - access("CO_CHARGE"."CO_TRANS_NO"="CO_CHARGEE_DETAIL"."CO_TRANS_NO"(+))
24 - access("CO_CHARGE"."CO_TRANS_NO"="CO_CHARGE_AMOUNT"."CO_TRANS_NO"(+))
26 - filter(NVL("CO_CHARGE"."APPROVED_IND",'Y')='Y' AND NVL("CO_CHARGE"."VOID_IND",'N')='N')
27 - access("CO_CHARGE"."CO_TRANS_NO"(+)="CO_TRANS_MASTER"."CO_TRANS_NO")
29 - filter(NVL("CO_TRANS_MASTER"."VOID_IND",'N')='N' AND NVL("CO_TRANS_MASTER"."STATUS_IND",'1')<>'2' AND
NVL("CO_TRANS_MASTER"."EXPUNGED_IND",'N')='N')
Statistics
225 recursive calls
9 db block gets
78959 consistent gets
101976 physical reads
0 redo size
121969396 bytes sent via SQL*Net to client
690014 bytes received via SQL*Net from client
62683 SQL*Net roundtrips to/from client
0 sorts (memory)
1 sorts (disk)
6268140 rows processedStatistics
225 recursive calls
9 db block gets
78959 consistent gets
101976 physical reads
0 redo size
121969396 bytes sent via SQL*Net to client
690014 bytes received via SQL*Net from client
62683 SQL*Net roundtrips to/from client
0 sorts (memory)
1 sorts (disk)
6268140 rows processedWith 101976 physical reads you get 6268140 rows with 121969396 bytes and send them over SQL*Net to your client application. That's interesting.
Hi, I have this query which is taking about 1 hour to complete. It is suppose to complete in less than 2 minThere is NO system outside of museums that takes 1 hours to do 101976 physical reads.
What is your client? I'd say the DB executes ok but it takes time to transfer the 116MB in 62683 SQL*Net round trips => 20 roundtrips per sec are reasonable.
Try something like
SELECT COUNT(*) FROM (your query);
or
CREATE TABLE mytest AS SELECT * FROM (your query);your will finish in seconds. And that will prove the speed of the DB / query
-- andy -
Query taking too much time when running through discover
Hi
I have created report with sql query by creating custom folder in oracle discover desktop. Query is using parameter with sys_context. When report is executed from discover it takes more than 5 minutes and same query is executed in 30 seconds when executed in database through toad.
Pls. let me know what could be the reason for this?
ThanksHi,
The first thing to check is whether the query is running to completion in TOAD. By default, TOAD just selects the first 50 rows, where as Discoverer must return all the rows before displaying results if a crosstab report is used.
Secondly, check that the queries and the explain plans are the same in Discoverer and Toad. Although, Discoverer shows the SQL in the SQL inspector this isn't necessarily the SQL actually sent to the database. Use TOAD to interogate the Discoverer session to determine the actual SQL and compare this SQL and explain plan to SQL you ran in TOAD.
Thirdly, check that the session context is the same in both cases. So check that any custom contexts and the USER_ENV context is the same, and if any security packages or VPD policies are used in the SQL that these have been initialised the same.
If you still cannot determine the difference then trace both sessions.
Rod West -
Discoverer reports taking a long time!!!
Hi all,
One of our clients is complaining that the discoverer reports are taking a long time to run for the last few days, the report used to take 30 minutes before but now is running for hours!!
I have checked the SGA and I have killed the idle sessions but still there was no improvement in the performance.
The version of BI discoverer is 10 and database also is 10g and the platform is win server 2003.
I have checked the forums and they talk about explain plan and tkprof and other commands, but my problem is that i am unable to find the query that discoverer is running i mean once the report is clicked the query runs and gives the estimate time it would take. can some one tell me where this query is stored so that i can check this query,
Also there were no changes made in the query or to the database.
The temp space fills up 100%, i increased the size of temp space but still it goes to 100% also i noticed that the CPU utilisation goes to 100%
i also increased the SGA but still no go.
can someone kindly help me as to what could be causing this problem
also kindly guide me to some good documents for tuning the discoverer.
thanks in advance,
regards,
Edited by: user10243788 on Jan 4, 2010 12:47 AMHi,
The fact that the report used to work fast and now not can be related to many things but my guess is that the database statistics were changed and so the explain plan has changed.
This can be done due to change in the volume of the data that crossed a level were oracle optimizer change the behavior but it can be other things as well.
Anyway it is not relevant since it will be easier to tune the SQL than to find what have changed.
In order to find whether the problem is with the discoverer or in the SQL extract the SQL as described above and run it in SQL tool (SQL Plus, TOAD, SQL Developer and so on).
The best way to get to the problem is run a trace on your session and then use the TKPROF command to translate it to a text file you can analyze - you can assist your DBA team they should have no problem doing that.
By doing that you will get the problematic statements/ functions/ procedures that the report uses.
From there you can start working on improving the performance.
Performance is expertise for itself so i'm sorry i don't know to tell you where to start from, I guess the start will be from understanding the meaning of the explain plan.
Hope I helped a little although I wish Ii had a magic answer for you
BTW, until you resolve that problem you can use the discoverer scheduler to run the reports in the background and so the users will get the data.
Tamir -
Query takes very long time and analyze table hangs
Hi
One of the oracle query taking very long time (ie more than a day) and affecting business requirment of getting the report in time.
I tried to analyze the table with compute statistics option, however it hangs/runs forever on one of the huge table?
Please let me know how to troubleshoot this issueHi,
What's your Oracle version?
You should use DBMS_STATS package not ANALYZE..
Regards, -
Time_out Dump on this query take too long time
hi experts,
in my report a query taking too long time
pl. provide performance tips or suggestions
select mkpf~mblnr mkpf~mjahr mkpf~usnam mkpf~vgart
mkpf~xabln mkpf~xblnr mkpf~zshift mkpf~frbnr
mkpf~bktxt mkpf~bldat mkpf~budat mkpf~cpudt
mkpf~cputm mseg~anln1 mseg~anln2 mseg~aplzl
mseg~aufnr mseg~aufpl mseg~bpmng mseg~bprme
mseg~bstme mseg~bstmg mseg~bukrs mseg~bwart
mseg~bwtar mseg~charg mseg~dmbtr mseg~ebeln
mseg~ebelp mseg~erfme mseg~erfmg mseg~exbwr
mseg~exvkw mseg~grund mseg~kdauf mseg~kdein
mseg~kdpos mseg~kostl mseg~kunnr mseg~kzbew
mseg~kzvbr mseg~kzzug mseg~lgort mseg~lifnr
mseg~matnr mseg~meins mseg~menge mseg~lsmng
mseg~nplnr mseg~ps_psp_pnr mseg~rsnum mseg~rspos
mseg~shkzg mseg~sobkz mseg~vkwrt mseg~waers
mseg~werks mseg~xauto mseg~zeile mseg~SGTXT
into table itab
from mkpf as mkpf
inner join mseg as mseg
on mkpf~MBLNR = mseg~mblnr
and mkpf~mjahr = mseg~mjahrno the original query is, i use where clouse with conditions.
select mkpf~mblnr mkpf~mjahr mkpf~usnam mkpf~vgart
mkpf~xabln mkpf~xblnr mkpf~zshift mkpf~frbnr
mkpf~bktxt mkpf~bldat mkpf~budat mkpf~cpudt
mkpf~cputm mseg~anln1 mseg~anln2 mseg~aplzl
mseg~aufnr mseg~aufpl mseg~bpmng mseg~bprme
mseg~bstme mseg~bstmg mseg~bukrs mseg~bwart
mseg~bwtar mseg~charg mseg~dmbtr mseg~ebeln
mseg~ebelp mseg~erfme mseg~erfmg mseg~exbwr
mseg~exvkw mseg~grund mseg~kdauf mseg~kdein
mseg~kdpos mseg~kostl mseg~kunnr mseg~kzbew
mseg~kzvbr mseg~kzzug mseg~lgort mseg~lifnr
mseg~matnr mseg~meins mseg~menge mseg~lsmng
mseg~nplnr mseg~ps_psp_pnr mseg~rsnum mseg~rspos
mseg~shkzg mseg~sobkz mseg~vkwrt mseg~waers
mseg~werks mseg~xauto mseg~zeile mseg~SGTXT
into table itab
from mkpf as mkpf
inner join mseg as mseg
on mkpf~MBLNR = mseg~mblnr
and mkpf~mjahr = mseg~mjahr
WHERE mkpf~budat IN budat
AND mkpf~usnam IN usnam
AND mkpf~vgart IN vgart
AND mkpf~xblnr IN xblnr
AND mkpf~zshift IN p_shift
AND mseg~bwart IN bwart
AND mseg~matnr IN matnr
AND mseg~werks IN werks
AND mseg~lgort IN lgort
AND mseg~charg IN charg
AND mseg~sobkz IN sobkz
AND mseg~lifnr IN lifnr
AND mseg~kunnr IN kunnr. -
Where would you check performance of webi? query is taking long time to run
Hello All,
In the bex query world running on portal you were able to go to sm50 and check what the query is doing and where it is taking a long time or atleast you were able to see the processes runing.
Where would you check the running processes when you are running a webi query, we are trying to write a webi report which is on universe which is created on bex query. The report is very simple just two fields and an mandatory variable which is coming from bex query (have defined the variable in bex query). When we exeute the query it is taking a long time just spinning and I am not getting any data back, on the same query before even hitting the run query button, I am trying to put a object in query filters and set the filter as In list from Value(s) from list and it is taking forever to set that filter.
Can we go to CMC or BW backend and check anywhere we are using sap authentication, I see the number of sessions in CMC but that is it.
Thanks for help in advance.Thank you both for the replies.
How would I get the MDX that is generated by the query, I remember there is a note for starting the MDX logging. Can you please let em know how would I get the MDX statement. Thanks.
Gowtham - What is the optimal array fetch size that needs to set for the universes, can you explain bit more about array fetch size?
All our universes are on BEx queries designed in SAP BW in that case does the array fetch size matter and array bind size matter? I had read this in oneof the universe designer manuals for OLAP universes The Array fetch size, Array bind size, and Login timeout parameters are not used for OLAP connections
Thanks again for replies. -
Query taking long time to run.
The following query is taking long time to run, is there anything can be done to make it run faster by changing the sql etc.
select distinct
A.DEPTID,
A.POSITION_NBR,
A.EMPLID,
A.EMPL_RCD_NBR,
A.EFFDT,
B.NAME,
A.EMPL_STATUS,
A.JOBCODE,
A.ANNUAL_RT,
A.STD_HOURS,
A.PRIMARY_JOB,
C.POSN_STATUS,
case when A.POSITION_NBR = ' ' then 0 else C.STD_HOURS end,
case when A.POSITION_NBR = ' ' then ' ' else C.DEPTID end
from PS_JOB A,
PS_PERSONAL_DATA B,
PS_POSITION_DATA C
where A.EMPLID = B.EMPLID
and
((A.POSITION_NBR = C.POSITION_NBR
and A.EFFSEQ = (select max(D.EFFSEQ)
from PS_JOB D
where D.EMPLID = A.EMPLID
and D.EMPL_RCD_NBR = A.EMPL_RCD_NBR
and D.EFFDT = A.EFFDT)
and C.POSN_STATUS <> 'G'
and C.EFFDT = (select max(E.EFFDT)
from PS_POSITION_DATA E
where E.POSITION_NBR = A.POSITION_NBR
and E.EFFDT <= A.EFFDT)
and C.EFFSEQ = (select max(F.EFFSEQ)
from PS_POSITION_DATA F
where F.POSITION_NBR = A.POSITION_NBR
and F.EFFDT = C.EFFDT))
or
(A.POSITION_NBR = C.POSITION_NBR
and A.EFFDT = (select max(D.EFFDT)
from PS_JOB D
where D.EMPLID = A.EMPLID
and D.EMPL_RCD_NBR = A.EMPL_RCD_NBR
and D.EFFDT <= C.EFFDT)
and A.EFFSEQ = (select max(E.EFFSEQ)
from PS_JOB E
where E.EMPLID = A.EMPLID
and E.EMPL_RCD_NBR = A.EMPL_RCD_NBR
and E.EFFDT = A.EFFDT)
and C.POSN_STATUS <> 'G'
and C.EFFSEQ = (select max(F.EFFSEQ)
from PS_POSITION_DATA F
where F.POSITION_NBR = A.POSITION_NBR
and F.EFFDT = C.EFFDT)))
or
(A.POSITION_NBR = ' '
and A.EFFSEQ = (select max(E.EFFSEQ)
from PS_JOB D
where D.EMPLID = A.EMPLID
and E.EMPL_RCD_NBR = A.EMPL_RCD_NBR
and D.EFFDT = A.EFFDT)))Using distributive law A and (B or C) = (A and B) or (A and C) from right to left we can have:
select distinct A.DEPTID,A.POSITION_NBR,A.EMPLID,A.EMPL_RCD_NBR,A.EFFDT,B.NAME,A.EMPL_STATUS,
A.JOBCODE,A.ANNUAL_RT,A.STD_HOURS,A.PRIMARY_JOB,C.POSN_STATUS,
case when A.POSITION_NBR = ' ' then 0 else C.STD_HOURS end,
case when A.POSITION_NBR = ' ' then ' ' else C.DEPTID end
from PS_JOB A,PS_PERSONAL_DATA B,PS_POSITION_DATA C
where A.EMPLID = B.EMPLID
and (
A.POSITION_NBR = C.POSITION_NBR
and A.EFFSEQ = (select max(D.EFFSEQ)
from PS_JOB D
where D.EMPLID = A.EMPLID
and D.EMPL_RCD_NBR = A.EMPL_RCD_NBR
and D.EFFDT = A.EFFDT
and C.EFFSEQ = (select max(F.EFFSEQ)
from PS_POSITION_DATA E
where E.POSITION_NBR = A.POSITION_NBR
and E.EFFDT = C.EFFDT
and C.POSN_STATUS != 'G'
and (
C.EFFDT = (select max(E.EFFDT)
from PS_POSITION_DATA E
where E.POSITION_NBR = A.POSITION_NBR
and E.EFFDT <= A.EFFDT
or
A.EFFDT = (select max(D.EFFDT)
from PS_JOB D
where D.EMPLID = A.EMPLID
and D.EMPL_RCD_NBR = A.EMPL_RCD_NBR
and D.EFFDT <= C.EFFDT
or
A.POSITION_NBR = ' '
and A.EFFSEQ = (select max(E.EFFSEQ)
from PS_JOB D
where D.EMPLID = A.EMPLID
and E.EMPL_RCD_NBR = A.EMPL_RCD_NBR
and D.EFFDT = A.EFFDT
)may not help much as the optimizer might have guessed it already
Regards
Etbin -
Hyperion Report taking a long time to process local query
Hi All,
I am trying to run a report on Hyperion IR 9.3.1. I am facing a performance issue with this report. I am joining 13 tables using full outer join. Each table is having data about 900 rows and the final output i am getting from the local query is about 11000 rows. This local query is taking a long time to get process about 3 - 5 minutes. I suppose it should run with in 30 sec as number of rows are very few. Can anyone tell me what is the problem with this local query and how the performance of the report can be increased?
Thanks in advance.
Regards
UjjawalBe aware that XP takes approx 1gb of your RAM leaving you with 1gb for whatever else is running. MS Outlook is also a memory hog.
To check Virtual Memory Settings:
Control Panel -> System
System Properties -> Advanced Tab -> Performance Settings
Performance Options -> Adavanced Tab - Virtual Memory section
Virtual Memory -
what are
* Initial Size
* Maximum Size
In a presentation at one of the Hyperion conferences years ago, Mark Ostroff suggested that the initial be set to the same as Max. (Max is typically 2x physical RAM)
These changes may provide some improvement. -
Queries taking long time to run
Hi BW Folks,
I am working on virtual cube 0bcs_vc10 for bcs(business consolidation) the base cube is 0bcs_c10. We compressed and partitioned the base cube. The queries which i developed are running fine and are in production.
Now when a new req came for some more queries after developing them and running in DEv they are taking 20 to 25 mins to run.
Suprisingly the queries which are running in production they are also taking long time to run, we havent disturbed the performance tuning process we did earlier .
Can any one of share their experience in how to tackle this. Will assign full points
THanksHi Nick,
Do you have a lot of navigational attributes? That could be slowing you down. Also, if it's going too slow, try caching and pre-calculation (pre-loads the cache). Although I'm not sure if this will work with a Virtual Cube. By their nature they will be much slower than a physical cube.....so worst case scenario for me would be to load the VC data into a regular cube. If the query is still slow, then at least you know it's a query issue and not the VC.
Brian
Maybe you are looking for
-
User cannot retrieve data in app on local PC
A certain user cannot retrieve data in one application whilst being able to send data in that application. She can access the 'Finance' application, send data in that application and retrieve data but in another application, 'ICM', she cannot retriev
-
High-units reflect twice the amount with dual JVM's in a distributed cache
HI all, I have a question - i have a near cache scheme defined - running 4 JVM's with my application deployed to it (localstorage=false) - and 2 JVM's for the distributed cache (localstorage=true) The high-units is set to 2000 - but the cache is allo
-
Hello JDev Team, I want to use SSL encryption and authentication in my InfoSwing BC4J Oracle8i application. For Local Deployment it's quite transparent you just define appropriate LocalConnection class and SSL works fine. But for EJB/8i Deployment it
-
[SOLVED] gtk3 living with gtk2
I am using Xfce, and after updating today I noticed that the Gnome applications I have installed that are now running under gtk3 look like crap. I followed the instructions in this thread (https://bbs.archlinux.org/viewtopic.php?id=116451), but there
-
AVERAGE on crosstable with NULLs
Hi, I try to set average function on column in crosstable. Data contains NULLs. I got error during displaing report in HTML format (in Interactive format it's ok) - "oracle.xdo.XDOException: java.lang.reflect.InvocationTargetException". Oracle suppor