Query takes long when using UNION
Hi ,
I habe a query as follows;
SELECT
'9999' site_id,
m.ghi_prov_num provnum,
SUBSTR (l.seq_num, 1, 3)provloc,
t.dea_number dea,
t.license_number statelicensenumber ,
n.npi_num npi,
m.prefix prefixname,
m.lastname lastname,
m.firstname firstname,
t.middle_name middleinitial,
m.suffix suffixname,
null clinicname,
l.street1 addressline1,
l.street2 addressline2,
l.city city,
l.state state,
l.zip5 zip,
l.phone phoneprimary,
null ext,
null fax,
null email,
null alt_phone,
null alt_phone_ext
FROM provider m, LOCATION l, npi n,TEMP_VITAL_CACTUS t,test_provider_pin pin
WHERE m.ghi_prov_num=l.ghi_prov_num
and m.ghi_prov_num=n.ghi_prov_num(+)
and m.ghi_prov_num=t.ghi_prov_num(+)
and m.tax_id=pin.tax_id
UNION
SELECT
'9999', m.ghi_prov_num ,
m.location provloc,
null ,
null ,
n.npi_num ,
null ,
m.lastname ,
m.firstname ,
null,
null ,
null ,
m.street1 ,
m.street2 ,
m.city ,
m.state ,
m.zip5 ,
m.phone ,
null ,
null ,
null ,
null ,
null
FROM dental_provider m, npi n,test_provider_pin pin
WHERE m.ghi_prov_num=n.tax_id(+)
and m.location=n.location(+)
and pin.tax_id=m.ghi_prov_num;The query takes for ever;
But Individual query takes less than a sec to execute.Is there any way can i rewrite the query?
Please help
Hena.
user11253970 wrote:
But Individual query takes less than a sec to execute.Is there any way can i rewrite the query?Have a feeling you are using Toad/SQL Navigator or similar tool which returns data one screen at a time. If so, then it does not "takes less than a sec to execute" but rather to fetch first screen of rows. When you use UNION Oracle has to return distinct rows from both queries. Therefore it must fetch not just first screen but all rows. To verify, issue first query and in yiour GUI tool click on get last screen. Then you'll know how long whole select takes. Do the same for second query. Also, do you need distinct rows or akll rows? IF all rows, change UNION to UNION ALL.
SY.
Similar Messages
-
Why update query takes long time ?
Hello everyone;
My update query takes long time. In emp ( self testing) just having 2 records.
when i issue update query , it takes long time;
SQL> select * from emp;
EID ENAME EQUAL ESALARY ECITY EPERK ECONTACT_NO
2 rose mca 22000 calacutta 9999999999
1 sona msc 17280 pune 9999999999
Elapsed: 00:00:00.05
SQL> update emp set esalary=12000 where eid='1';
update emp set esalary=12000 where eid='1'
* ERROR at line 1:
ORA-01013: user requested cancel of current operation
Elapsed: 00:01:11.72
SQL> update emp set esalary=15000;
update emp set esalary=15000
* ERROR at line 1:
ORA-01013: user requested cancel of current operation
Elapsed: 00:02:22.27Hi BCV;
Thanks for your reply but it doesn't provide output, please see this.
SQL> update emp set esalary=15000;
........... Lock already occured.
>> trying to trace >>
SQL> select HOLDING_SESSION from dba_blockers;
HOLDING_SESSION
144
SQL> select sid , username, event from v$session where username='HR';
SID USERNAME EVENT
144 HR SQL*Net message from client
151 HR enq: TX - row lock contention
159 HR SQL*Net message from client
>> It does n 't provide clear output about transaction lock >>
SQL> SELECT username, v$lock.SID, TRUNC (id1 / POWER (2, 16)) rbs,
2 BITAND (id1, TO_NUMBER ('ffff', 'xxxx')) + 0 slot, id2 seq, lmode,
3 request
4 FROM v$lock, v$session
5 WHERE v$lock.TYPE = 'TX'
6 AND v$lock.SID = v$session.SID
7 AND v$session.username = USER;
no rows selected
SQL> select MACHINE from v$session where sid = :sid;
SP2-0552: Bind variable "SID" not declared. -
Query take long time in fetching when used within a procedure
The Database is : Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bi
Query just takes a second from toad but when used inside a procedure as a cursor it takes takes 3 to 5 minutes.
Following is the Tkprof information when running from procedure.
SELECT CHCLP.CLM_PRVDR_TYPE_LKPCD, CHCLP.PRVDR_LCTN_IID, TO_CHAR
(CHCLP.MODIFIED_DATE, 'MM-dd-yyyy hh24:mi:ss') MODIFIED_DATE,
CHCLP.PRVDR_LCTN_IDENTIFIER, CHCLP.CLM_HDR_CLM_LN_X_PVDR_LCTN_SID
FROM
CLM_HDR_CLM_LN_X_PRVDR_LCTN CHCLP WHERE CHCLP.CLAIM_HEADER_SID = :B1 AND
CHCLP.CLAIM_LINE_SID IS NULL AND CHCLP.IDNTFR_TYPE_CID = 7
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 1 110.79 247.79 568931 576111 0 3
total 2 110.79 247.79 568931 576111 0 3
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 93 (CMSAPP) (recursive depth: 1)
Rows Execution Plan
0 SELECT STATEMENT MODE: ALL_ROWS
0 PARTITION RANGE (SINGLE) PARTITION:KEYKEY
0 TABLE ACCESS MODE: ANALYZED (BY LOCAL INDEX ROWID) OF
'CLM_HDR_CLM_LN_X_PRVDR_LCTN' (TABLE) PARTITION:KEYKEY
0 INDEX MODE: ANALYZED (RANGE SCAN) OF
'XAK1CLM_HDR_CLM_LN_X_PRVDR_LCT' (INDEX (UNIQUE))
PARTITION:KEYKEY
Execution plan when running just the query from TOAD is: (it comes out in a second)
Plan
SELECT STATEMENT ALL_ROWSCost: 6 Bytes: 100 Cardinality: 2
3 PARTITION RANGE SINGLE Cost: 6 Bytes: 100 Cardinality: 2 Partition #: 1 Partitions accessed #13
2 TABLE ACCESS BY LOCAL INDEX ROWID TABLE CMSAPP.CLM_HDR_CLM_LN_X_PRVDR_LCTN Cost: 6 Bytes: 100 Cardinality: 2 Partition #: 2 Partitions accessed #13
Why would fetching take such a long time? Please let me know if you need any other information.
Thank You.
Edited by: spur230 on Apr 1, 2009 10:23 AM
Edited by: spur230 on Apr 1, 2009 10:26 AM
Edited by: spur230 on Apr 1, 2009 10:28 AM
Edited by: spur230 on Apr 1, 2009 10:30 AMQuery just takes a second from toad It's possible that the query starts returning rows in a second, but that's not the time required for the entire query.
-
Cannot export query output when using UNION ALL
Hi
I can run a query in SQL Developer 1.5.5 and if it's a SELECT statement it works fine, but if I output the result of several SELECT statements using UNION ALL after some 10,000 records the SQL Developer crashes and it generates a file whose size is 0 kb
Is there a workaround for this??
Thanks and Regards!
IsaacShould be fixed in the upcoming 2.1... you can try the RC1 also...
Regards,
K. -
Why NL instead of HJ(query takes long)
Hi there!
There are a db(10.2.0.5 RAC), SLES 10 and two schemes.In the first schema query takes very fast:
SQL> explain plan for
select count(distinct c.unit)
from quantity_comp_v qc, comps c, noticequant nq, notices_table n, noticediss nd
where
c.id = qc.comp
and nq.quant = qc.quantity
and n.id = nq.note
and n.type_id = 2
and nq.link = 2
and nd.note = n.id
and n.trust >=0
and nd.dis in (select dr.dismbr from disrelflat dr where dr.disgrp = 1080801245);
Explained.
Elapsed: 00:00:00.27
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 2567928671
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 91 | | 2099 (4)| 00:00:07 |
| 1 | SORT GROUP BY | | 1 | 91 | | | |
|* 2 | HASH JOIN | | 55203 | 4905K| | 2099 (4)| 00:00:07 |
|* 3 | INDEX RANGE SCAN | DISRELFLAT_UI_DISGRP_DISMBR | 10618 | 155K| | 54 (2)| 00:00:01 |
|* 4 | HASH JOIN | | 42398 | 3146K| 2984K| 2043 (4)| 00:00:06 |
|* 5 | HASH JOIN | | 42398 | 2484K| | 1262 (4)| 00:00:04 |
|* 6 | HASH JOIN | | 24173 | 1109K| | 1022 (4)| 00:00:03 |
|* 7 | HASH JOIN | | 21471 | 650K| | 951 (3)| 00:00:03 |
|* 8 | VIEW | index$_join$_004 | 21471 | 314K| | 783 (3)| 00:00:03 |
|* 9 | HASH JOIN | | | | | | |
|* 10 | INDEX RANGE SCAN | NOTICES_TABLE_I_TYPE_ID_TRUST_ | 21471 | 314K| | 141 (5)| 00:00:01 |
| 11 | INDEX FAST FULL SCAN | NOTICES_TABLE_PK | 21471 | 314K| | 832 (2)| 00:00:03 |
| 12 | INDEX FAST FULL SCAN | NOTICEDISS_UI_NOTE_DIS | 169K| 2647K| | 162 (4)| 00:00:01 |
|* 13 | TABLE ACCESS FULL | NOTICEQUANT | 38141 | 595K| | 69 (5)| 00:00:01 |
| 14 | VIEW | | 88786 | 1127K| | 236 (3)| 00:00:01 |
| 15 | SORT UNIQUE | | | | | | |
| 16 | UNION-ALL | | | | | | |
|* 17 | HASH JOIN | | 23140 | 1355K| | 130 (8)| 00:00:01 |
| 18 | INDEX FAST FULL SCAN | QUANTITIES_I_ID_OP | 50822 | 397K| | 51 (4)| 00:00:01 |
|* 19 | HASH JOIN | | 23057 | 1170K| | 76 (7)| 00:00:01 |
| 20 | INDEX FAST FULL SCAN | QOPNC_I_ALL | 37964 | 481K| | 55 (2)| 00:00:01 |
| 21 | VIEW | | 23057 | 878K| | 18 (6)| 00:00:01 |
|* 22 | CONNECT BY WITHOUT FILTERING| | | | | | |
| 23 | TABLE ACCESS FULL | QOPNQ | 23057 | 225K| | 18 (6)| 00:00:01 |
|* 24 | HASH JOIN | | 38100 | 781K| | 109 (6)| 00:00:01 |
| 25 | INDEX FAST FULL SCAN | QOPNC_I_ALL | 37964 | 481K| | 55 (2)| 00:00:01 |
| 26 | INDEX FAST FULL SCAN | QUANTITIES_I_ID_OP | 50822 | 397K| | 51 (4)| 00:00:01 |
| 27 | TABLE ACCESS FULL | COMPS | 218K| 3406K| | 282 (4)| 00:00:01 |
Predicate Information (identified by operation id):
2 - access("ND"."DIS"="DR"."DISMBR")
3 - access("DR"."DISGRP"=1080801245)
4 - access("C"."ID"="COMP")
5 - access("NQ"."QUANT"="ID")
6 - access("NQ"."NOTE"="N"."ID")
7 - access("ND"."NOTE"="N"."ID")
8 - filter("N"."TYPE_ID"=2 AND "N"."TRUST">=0)
9 - access(ROWID=ROWID)
10 - access("N"."TYPE_ID"=2 AND "N"."TRUST">=0)
13 - filter("NQ"."LINK"=2)
17 - access("ID"="RT")
19 - access("QOP"="QUANTITY")
22 - access("QUANTITY"=PRIOR "QOP")
24 - access("ID"="QUANTITY")
52 rows selected.
Elapsed: 00:00:00.06
SQL> In second schema query takes very long:
PLAN_TABLE_OUTPUT
Plan hash value: 543063124
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 92 | 333 (2)| 00:00:01 |
| 1 | SORT GROUP BY | | 1 | 92 | | |
| 2 | NESTED LOOPS | | 91 | 8372 | 333 (2)| 00:00:01 |
| 3 | NESTED LOOPS | | 91 | 6916 | 241 (2)| 00:00:01 |
| 4 | NESTED LOOPS | | 52 | 3276 | 189 (2)| 00:00:01 |
| 5 | NESTED LOOPS | | 47 | 2209 | 123 (3)| 00:00:01 |
|* 6 | HASH JOIN | | 81 | 2592 | 42 (8)| 00:00:01 |
|* 7 | INDEX RANGE SCAN | DISRELFLAT_UI_DISGRP_DISMBR | 18 | 288 | 2 (0)| 00:00:01 |
| 8 | INDEX FAST FULL SCAN | NOTICEDISS_UI_NOTE_DIS | 38127 | 595K| 38 (3)| 00:00:01 |
|* 9 | TABLE ACCESS BY INDEX ROWID | NOTICES_TABLE | 1 | 15 | 1 (0)| 00:00:01 |
|* 10 | INDEX UNIQUE SCAN | NOTICES_TABLE_PK | 1 | | 0 (0)| 00:00:01 |
|* 11 | TABLE ACCESS BY INDEX ROWID | NOTICEQUANT | 1 | 16 | 3 (0)| 00:00:01 |
|* 12 | INDEX RANGE SCAN | NOTICEQUANT_UI_NOTE_QUANT | 1 | | 1 (0)| 00:00:01 |
| 13 | VIEW | | 2 | 26 | 1 (0)| 00:00:01 |
| 14 | SORT UNIQUE | | | | | |
| 15 | UNION-ALL PARTITION | | | | | |
| 16 | NESTED LOOPS | | 1 | 60 | 19 (6)| 00:00:01 |
| 17 | NESTED LOOPS | | 1 | 47 | 18 (6)| 00:00:01 |
|* 18 | INDEX RANGE SCAN | QUANTITIES_UI_ID_OP | 1 | 8 | 2 (0)| 00:00:01 |
|* 19 | VIEW | | 1 | 39 | 16 (7)| 00:00:01 |
|* 20 | CONNECT BY WITHOUT FILTERING| | | | | |
| 21 | TABLE ACCESS FULL | QOPNQ | 19811 | 193K| 16 (7)| 00:00:01 |
|* 22 | INDEX RANGE SCAN | QOPNC_UI_QUANTITY_NUM_COMP | 1 | 13 | 1 (0)| 00:00:01 |
| 23 | NESTED LOOPS | | 1 | 21 | 3 (0)| 00:00:01 |
|* 24 | INDEX RANGE SCAN | QUANTITIES_UI_ID_OP | 1 | 8 | 2 (0)| 00:00:01 |
|* 25 | INDEX RANGE SCAN | QOPNC_UI_QUANTITY_NUM_COMP | 1 | 13 | 1 (0)| 00:00:01 |
| 26 | TABLE ACCESS BY INDEX ROWID | COMPS | 1 | 16 | 1 (0)| 00:00:01 |
|* 27 | INDEX UNIQUE SCAN | COMPS_UI_ID | 1 | | 0 (0)| 00:00:01 |
Predicate Information (identified by operation id):
6 - access("ND"."DIS"="DR"."DISMBR")
7 - access("DR"."DISGRP"=1080801245)
9 - filter("N"."TYPE_ID"=2 AND "N"."TRUST">=0)
10 - access("ND"."NOTE"="N"."ID")
11 - filter("NQ"."LINK"=2)
12 - access("NQ"."NOTE"="N"."ID")
18 - access("ID"="NQ"."QUANT")
19 - filter("ID"="RT" AND "RT"="NQ"."QUANT")
20 - access("QUANTITY"=PRIOR "QOP")
22 - access("QOP"="QUANTITY")
24 - access("ID"="NQ"."QUANT")
25 - access("QUANTITY"="NQ"."QUANT")
filter("ID"="QUANTITY")
27 - access("C"."ID"="COMP")As you can see, plans are different. Why? Statistics is up-to-date in both schemas.
In tkprof trace for the second schema i see strange thing:
select count(distinct c.unit)
from quantity_comp_v qc, comps c, noticequant nq, notices_table n,
noticediss nd
where
c.id = qc.comp
and nq.quant = qc.quantity
and n.id = nq.note
and n.type_id = 2
and nq.link = 2
and nd.note = n.id
and n.trust >=0
and nd.dis in (select dr.dismbr from disrelflat dr where dr.disgrp = 1080801245)
call count cpu elapsed disk query current rows
Parse 1 0.02 0.02 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 558.36 545.39 1 845921 0 1
total 4 558.38 545.42 1 845921 0 1
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 156
Rows Row Source Operation
1 SORT GROUP BY (cr=845921 pr=1 pw=0 time=545397464 us)
13865 NESTED LOOPS (cr=845921 pr=1 pw=0 time=546471010 us)
13865 NESTED LOOPS (cr=818189 pr=1 pw=0 time=546290764 us)
13308 HASH JOIN (cr=31053 pr=1 pw=0 time=172231 us)
13308 NESTED LOOPS (cr=30863 pr=0 pw=0 time=126100 us)
15326 HASH JOIN (cr=209 pr=0 pw=0 time=21640 us)
11522 INDEX RANGE SCAN DISRELFLAT_UI_DISGRP_DISMBR (cr=68 pr=0 pw=0 time=40 us)(object id 634347)
37432 INDEX FAST FULL SCAN NOTICEDISS_UI_NOTE_DIS (cr=141 pr=0 pw=0 time=50 us)(object id 638914)
13308 TABLE ACCESS BY INDEX ROWID NOTICES_TABLE (cr=30654 pr=0 pw=0 time=95620 us)
15326 INDEX UNIQUE SCAN NOTICES_TABLE_PK (cr=15328 pr=0 pw=0 time=41398 us)(object id 638937)
34391 TABLE ACCESS FULL NOTICEQUANT (cr=190 pr=1 pw=0 time=53 us)
13865 VIEW (cr=787136 pr=0 pw=0 time=544908246 us)
13865 SORT UNIQUE (cr=787136 pr=0 pw=0 time=544893509 us)
13950 UNION-ALL PARTITION (cr=787136 pr=0 pw=0 time=539509573 us)
1223 NESTED LOOPS (cr=733813 pr=0 pw=0 time=539271493 us)
1233 NESTED LOOPS (cr=731971 pr=0 pw=0 time=539245389 us)
13308 INDEX RANGE SCAN QUANTITIES_UI_ID_OP (cr=26647 pr=0 pw=0 time=120240 us)(object id 634738)
1233 VIEW (cr=705324 pr=0 pw=0 time=539109785 us)
275435676 CONNECT BY WITHOUT FILTERING (cr=705324 pr=0 pw=0 time=493869861 us)
263644788 TABLE ACCESS FULL QOPNQ (cr=705324 pr=0 pw=0 time=163378 us)
1223 INDEX RANGE SCAN QOPNC_UI_QUANTITY_NUM_COMP (cr=1842 pr=0 pw=0 time=10296 us)(object id 634729)
12727 NESTED LOOPS (cr=53323 pr=0 pw=0 time=216730 us)
13308 INDEX RANGE SCAN QUANTITIES_UI_ID_OP (cr=26647 pr=0 pw=0 time=111770 us)(object id 634738)
12727 INDEX RANGE SCAN QOPNC_UI_QUANTITY_NUM_COMP (cr=26676 pr=0 pw=0 time=84638 us)(object id 634729)
13865 TABLE ACCESS BY INDEX ROWID COMPS (cr=27732 pr=0 pw=0 time=235066 us)
13865 INDEX UNIQUE SCAN COMPS_UI_ID (cr=13867 pr=0 pw=0 time=128663 us)(object id 634315)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 2 0.00 0.00
gc current block 3-way 208 0.00 0.08
gc current block 2-way 93 0.00 0.02
gc cr multi block request 150 0.00 0.01
db file sequential read 1 0.01 0.01
SQL*Net message from client 2 0.00 0.00
********************************************************************************Cardinality of QOPNQ not real (over 263 millions rows instead of 19 thousands). If i set optimizer_index_cost_adj=400, plan uses HJ and cardinality in tkprof trace is right. Thanks in advance.
Best regards, Pavel.Hi there.
What I found:
In schema, where optimizer uses NL:
SQL> select TABLE_NAME,COLUMN_NAME,NUM_BUCKETS,LAST_ANALYZED from user_tab_col_statistics where table_name in ('DISRELFLAT','NOTICES_TABLE','QOPNQ','COMPS');
TABLE_NAME COLUMN_NAME NUM_BUCKETS LAST_ANALYZED
COMPS ID 254 31-JUL-10
COMPS UNIT 254 31-JUL-10
COMPS LOC 34 31-JUL-10
COMPS TIS 246 31-JUL-10
COMPS RTYP 2 31-JUL-10
DISRELFLAT DISGRP 254 31-JUL-10
DISRELFLAT DISMBR 254 31-JUL-10
DISRELFLAT CNT 174 31-JUL-10
DISRELFLAT SPL 10 31-JUL-10
DISRELFLAT DIST 16 31-JUL-10
DISRELFLAT PART 2 31-JUL-10
DISRELFLAT ISA 2 31-JUL-10
DISRELFLAT MIX 2 31-JUL-10
DISRELFLAT CLONAL 1 31-JUL-10
NOTICES_TABLE ID 1 08-SEP-10
NOTICES_TABLE TEXT 1 08-SEP-10
NOTICES_TABLE DESCRIPTION 1 08-SEP-10
NOTICES_TABLE TYPE_ID 4 08-SEP-10
NOTICES_TABLE CUSER_ID 1 08-SEP-10
NOTICES_TABLE CDATE 1 08-SEP-10
NOTICES_TABLE TRUST 10 08-SEP-10
NOTICES_TABLE RTYP 2 08-SEP-10
NOTICES_TABLE CHECKEDBY 1 08-SEP-10
NOTICES_TABLE FEATURE_ID 13 08-SEP-10
QOPNQ QUANTITY 1 31-JUL-10
QOPNQ NUM 12 31-JUL-10
QOPNQ QOP 1 31-JUL-10
27 rows selected.In schema where optimizer uses HJ:
TABLE_NAME COLUMN_NAME NUM_BUCKETS LAST_ANALYZED
COMPS ID 254 28-JUL-10
COMPS UNIT 254 28-JUL-10
COMPS LOC 29 28-JUL-10
COMPS TIS 223 28-JUL-10
COMPS RTYP 2 28-JUL-10
DISRELFLAT DISGRP 254 21-AUG-10
DISRELFLAT DISMBR 1 21-AUG-10
DISRELFLAT CNT 103 21-AUG-10
DISRELFLAT SPL 10 21-AUG-10
DISRELFLAT DIST 11 21-AUG-10
DISRELFLAT PART 2 21-AUG-10
DISRELFLAT ISA 2 21-AUG-10
DISRELFLAT MIX 2 21-AUG-10
DISRELFLAT CLONAL 2 21-AUG-10
NOTICES_TABLE ID 1 09-AUG-10
NOTICES_TABLE TEXT 254 09-AUG-10
NOTICES_TABLE DESCRIPTION 254 09-AUG-10
NOTICES_TABLE TYPE_ID 4 09-AUG-10
NOTICES_TABLE CUSER_ID 1 09-AUG-10
NOTICES_TABLE CDATE 254 09-AUG-10
NOTICES_TABLE TRUST 9 09-AUG-10
NOTICES_TABLE RTYP 2 09-AUG-10
NOTICES_TABLE CHECKEDBY 1 09-AUG-10
NOTICES_TABLE FEATURE_ID 21 09-AUG-10
QOPNQ QUANTITY 1 28-JUL-10
QOPNQ NUM 10 28-JUL-10
QOPNQ QOP 1 28-JUL-10
27 rows selected.Then i gathered statistics with estimate_percent=>null,method_opt=>'for all columns size 1'(without histogramms).
Plan became:
PLAN_TABLE_OUTPUT
Plan hash value: 2184582790
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 91 | 969 (4)| 00:00:03 |
| 1 | SORT GROUP BY | | 1 | 91 | | |
|* 2 | HASH JOIN | | 689 | 62699 | 969 (4)| 00:00:03 |
|* 3 | HASH JOIN | | 689 | 51675 | 719 (3)| 00:00:03 |
|* 4 | HASH JOIN | | 392 | 24304 | 549 (2)| 00:00:02 |
| 5 | NESTED LOOPS | | 377 | 17342 | 479 (1)| 00:00:02 |
|* 6 | HASH JOIN | | 435 | 13485 | 43 (7)| 00:00:01 |
|* 7 | INDEX RANGE SCAN | DISRELFLAT_UI_DISGRP_DISMBR | 12 | 180 | 3 (0)| 00:00:01 |
| 8 | INDEX FAST FULL SCAN | NOTICEDISS_UI_NOTE_DIS | 38127 | 595K| 38 (3)| 00:00:01 |
|* 9 | TABLE ACCESS BY INDEX ROWID | NOTICES_TABLE | 1 | 15 | 1 (0)| 00:00:01 |
|* 10 | INDEX UNIQUE SCAN | NOTICES_TABLE_PK | 1 | | 0 (0)| 00:00:01 |
|* 11 | TABLE ACCESS FULL | NOTICEQUANT | 34306 | 536K| 69 (5)| 00:00:01 |
| 12 | VIEW | | 79375 | 1007K| 167 (3)| 00:00:01 |
| 13 | SORT UNIQUE | | | | | |
| 14 | UNION-ALL | | | | | |
|* 15 | HASH JOIN | | 19811 | 1160K| 86 (11)| 00:00:01 |
| 16 | INDEX FAST FULL SCAN | QUANTITIES_UI_ID_OP | 45161 | 352K| 33 (7)| 00:00:01 |
|* 17 | HASH JOIN | | 19811 | 1006K| 51 (10)| 00:00:01 |
| 18 | TABLE ACCESS FULL | QOPNC | 34214 | 434K| 33 (7)| 00:00:01 |
| 19 | VIEW | | 19811 | 754K| 16 (7)| 00:00:01 |
|* 20 | CONNECT BY WITHOUT FILTERING| | | | | |
| 21 | TABLE ACCESS FULL | QOPNQ | 19811 | 193K| 16 (7)| 00:00:01 |
|* 22 | HASH JOIN | | 34214 | 701K| 68 (9)| 00:00:01 |
| 23 | TABLE ACCESS FULL | QOPNC | 34214 | 434K| 33 (7)| 00:00:01 |
| 24 | INDEX FAST FULL SCAN | QUANTITIES_UI_ID_OP | 45161 | 352K| 33 (7)| 00:00:01 |
| 25 | TABLE ACCESS FULL | COMPS | 212K| 3320K| 244 (5)| 00:00:01 |
Predicate Information (identified by operation id):
2 - access("C"."ID"="COMP")
3 - access("NQ"."QUANT"="ID")
4 - access("NQ"."NOTE"="N"."ID")
6 - access("ND"."DIS"="DR"."DISMBR")
7 - access("DR"."DISGRP"=1080801245)
9 - filter("N"."TYPE_ID"=2 AND "N"."TRUST">=0)
10 - access("ND"."NOTE"="N"."ID")
11 - filter("NQ"."LINK"=2)
15 - access("ID"="RT")
17 - access("QOP"="QUANTITY")
20 - access("QUANTITY"=PRIOR "QOP")
22 - access("ID"="QUANTITY")Now,query executes as fast as in first schema.
Best regards,Pavel.
Edited by: Pavel E. -
Query time affected when using dimensions that are at a lower grain
Hi all,
I have a product dimension that has one hierarchy and 7 levels: All Product -> Category -> BU -> Class -> Department -> SubDept -> Item. The lowest level has about 8 million members. The Department level has about 1500 members
Some of my Cubes are actually mapped to fact tables where the grain is at Department level. So I've ensured that in the Cube Mappings Editor, the Department Id of the fact table is mapped to the Department level of the Product Dimension, and I can actually see in the Cube's Aggmap, it is using LOAD_STATUS to limit the Product dimension to the Department level members for the aggregation.
Querying the Cube using SQL brings back the correct result across different level combination, however the query constantly takes about 2 - 3 mins to complete.
As a test, I've built another dimension that goes down to the Department level only, and issue the same query against the Cube. The difference is significant as the query takes roughly less than 1 second to complete, and returns exactly the same result.
Any idea? I am using AWM 11.2.0.1.0A
ThanksThe stats you posted are puzzling. Usually the sum of loop and fetch time is close to the total time, but there is a big missing chunk of time in your case. It is clearly related to the calculated measures, since removing them solves the problem.
The most common problem with calculated measures is that they can cause the cube to loop densely (i.e. all logical member combinations) instead of sparsely (i.e. only the member combinations that have data). But I don't think this is the problem in your case since the difference between rows_read and rows_returned is small
ROWS_READ 212ROWS_RETURNED 185
NULLTRACK_SUPPRESSED 27>
If dense looping has happened then the rows_read is often orders of magnitude greater than rows_returned. You can see the looping strategy by running
select value || ' : ' || details as loop from cube_operations_log where name = 'LOOP_OPTIMIZED'Here is an example of the output for a good (sparse) loop.
LOOP
ON : LOOP AGGMAP(PRICE_COST_CUBE_SOLVE_AGGMAP PRICE_COST_CUBE_PRT_TEMPLATE)Here is the output if I add a year to date calc to the cube.
LOOP
ON : LOOP UNION(AGGMAP(PRICE_COST_CUBE_SOLVE_AGGMAP PRICE_COST_CUBE_PRT_TEMPLATE
) AGGMAP(DENSE(TIME) PRICE_COST_CUBE_SOLVE_AGGMAP PRICE_COST_CUBE_PRT_TEMPLATE))Note that TIME is now looped densely, but the code is still trying to loop the other dimensions sparsely. Finally, here is the loop if I add a random olap dml calculation to the cube.
LOOP
DISABLED :There is now no optimized looping and the cube will be looped densely.
So it may be worth checking the loop descriptor for your fast and slow cases, but my best guess at the moment is that the performance gap has something to do with your specific calculations. If I were you I would add them back one at a time to see if you can find a particular measure, or type of measure, that is causing the slowdown. -
Query takes long time - Please help!
I've a query like below (not actual query)
update (select eds.title eds_title,edv.title edv_title from mia_data_staging eds, mia_doc_Versions edv where eds.id = edv.id and eds.title != edv.title) set edv_title = eds_title;
In the above query I've more than 70 columns to select, compare and update (I've shown only one above). The explain plan for the query is below, which does not show any significant time, but the query never returns when executed after a long long time. Any ideas?
Plan hash value: 2242214163
| Id | OpMIAtion | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | UPDATE STATEMENT | | 1627K| 1405M| | 18E (1)| |
| 1 | UPDATE | MIA_DOC_VERSIONS | | | | | |
|* 2 | HASH JOIN | | 1627K| 1405M| 720M| 18E (1)| |
| 3 | TABLE ACCESS BY INDEX ROWID | MIA_DOC_VERSIONS | 1627K| 701M| | 18E (1)| |
| 4 | BITMAP CONVERSION TO ROWIDS| | | | | | |
| 5 | BITMAP INDEX FULL SCAN | IDX_30 | | | | | |
PLAN_TABLE_OUTPUT
| 6 | TABLE ACCESS FULL | MIA_DATA_STAGING | 1628K| 705M| | 7184 (3)| 00:02:29 |
Predicate Information (identified by operation id):
---------------------------------------------------user652494 wrote:
I've a query like below (not actual query)
| 3 | TABLE ACCESS BY INDEX ROWID | MIA_DOC_VERSIONS | 1627K| 701M| | 18E (1)| |
| 4 | BITMAP CONVERSION TO ROWIDS| | | | | | |
| 5 | BITMAP INDEX FULL SCAN | IDX_30 | | | | | |This part of your execution plan looks very suspicious: It's performing a bitmap index full scan to do then a single row access by rowid apparently for all rows of the table, which seems to be a very inefficient operation. It also shows an unreasonable cost for that operation. The question is why it is not using a "full table scan" to access the MIA_DOC_VERSIONS table?
You might want to try simply the FULL hint to request a full table scan on the MIA_DOC_VERSIONS table in order to find out how the execution plan then is going to look like:
update (select /*+ FULL(EDV) */ eds.title eds_title,edv.title edv_title from mia_data_staging eds, mia_doc_Versions edv where eds.id = edv.id and eds.title != edv.title) set edv_title = eds_title;or
update /*+ FULL(a.EDV) */ (select eds.title eds_title,edv.title edv_title from mia_data_staging eds, mia_doc_Versions edv where eds.id = edv.id and eds.title != edv.title) a set edv_title = eds_title;Looking at the execution plan of the hinted statement one might get a clue why the optimizer favors an index access path instead.
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/ -
SELECT CAL_EMPCALENDAR.START_DATE as main,
bit_empname(CAL_EMPCALENDAR.EMPLOYEE_ID) || ' /' ||
CAL_EMPCALENDAR.EMPLOYEE_ID as secondary,
TO_DATE('1-4-2006', 'DD-MM-YYYY') as FROM_DATE,
TO_DATE('30-4-2006', 'DD-MM-YYYY') as TO_DATE,
bit_empname(CAL_EMPCALENDAR.EMPLOYEE_ID) || ' / ' ||
CAL_EMPCALENDAR.EMPLOYEE_ID as name,
CAL_EMPCALENDAR.START_DATE as sdate,
CAL_EMPCALENDAR.OVERTIME_REASON as OTReason,
CAL_EMPCALENDAR.POSTED_ON as POSTED_ON,
TO_CHAR(CAL_EMPCALENDAR.START_DATE, 'Dy') as dayname,
TAM_GET_ADJUSTED_IN(CAL_EMPCALENDAR.EMPCALENDAR_ID) as adj_in,
TAM_GET_ADJUSTED_OUT(CAL_EMPCALENDAR.EMPCALENDAR_ID) as adj_out,
CAL_EMPCALENDAR.SHIFT_ID AS SHIFT_ABBREV,
CAL_EMPCALENDAR.LATE_IN,
CAL_EMPCALENDAR.EARLY_OUT,
CAL_EMPCALENDAR.UNDER_TIME,
CAL_EMPCALENDAR.OVERTIME,
TAM_GET_LEAVE_DESC(CAL_EMPCALENDAR.EMPCALENDAR_ID, 'ALL') Leave,
CAL_EMPCALENDAR.EMPLOYEE_ID as empid,
HRM_CURR_CAREER_V.DEPARTMENT_CODE as deptcode,
BIT_CODEDESC(HRM_CURR_CAREER_V.DEPARTMENT_CODE) as deptname,
(SELECT shift_id
FROM CAL_GRPWORKDAY
WHERE CAL_GRPWORKDAY.calgrp_id =
(SELECT calgrp_id
FROM CAL_CALASSIGNMENT
WHERE employee_id = CAL_EMPCALENDAR.employee_id
AND CAL_CALASSIGNMENT.START_DATE <=
CAL_EMPCALENDAR.START_DATE
AND (CAL_CALASSIGNMENT.END_DATE is null or
CAL_CALASSIGNMENT.END_DATE >=
CAL_EMPCALENDAR.START_DATE))
AND CAL_GRPWORKDAY.start_date = CAL_EMPCALENDAR.start_date) AS shift_id,
(SELECT max(entry_dt)
FROM , LV_TXN txn, CAL_EMPDAILYEVENT cale
WHERE status = 'Approved'
AND LV_APPSTATUSHIST.application_id = txn.application_id
AND cale.reference_id = txn.txn_id
AND cale.empcalendar_id = CAL_EMPCALENDAR.empcalendar_id
) AS entry_dt,
(SELECT ENTITLEMENT + ADJUST
FROM TAM_ALLOWANCE
WHERE (WF_STATUS = 'Pending' OR WF_STATUS = 'Approved' OR
WF_STATUS = 'Verified' OR WF_STATUS is Null OR
WF_STATUS = 'No Action')
and EMPCALENDAR_ID = CAL_EMPCALENDAR.EMPCALENDAR_ID
AND ITEM_ID = (SELECT ITEM_ID
FROM TAM_CLAIM_FORMAT
WHERE SEQUENCE = 1
and BIZUNIT_ID like 'SG')) F1,
--TAM_GET_ENT_AND_ADJUSTED(CAL_EMPCALENDAR.EMPCALENDAR_ID, 'SG', 1) F1,
(SELECT ENTITLEMENT + ADJUST
FROM TAM_ALLOWANCE
WHERE (WF_STATUS = 'Pending' OR WF_STATUS = 'Approved' OR
WF_STATUS = 'Verified' OR WF_STATUS is Null OR
WF_STATUS = 'No Action')
and EMPCALENDAR_ID = CAL_EMPCALENDAR.EMPCALENDAR_ID
AND ITEM_ID = (SELECT ITEM_ID
FROM TAM_CLAIM_FORMAT
WHERE SEQUENCE = 2
and bizunit_id like 'SG')) F2,
(SELECT ENTITLEMENT + ADJUST
FROM TAM_ALLOWANCE
WHERE (WF_STATUS = 'Pending' OR WF_STATUS = 'Approved' OR
WF_STATUS = 'Verified' OR WF_STATUS is Null OR
WF_STATUS = 'No Action')
and EMPCALENDAR_ID = CAL_EMPCALENDAR.EMPCALENDAR_ID
AND ITEM_ID = (SELECT ITEM_ID
FROM TAM_CLAIM_FORMAT
WHERE SEQUENCE = 3
and bizunit_id like 'SG')) F3,
(SELECT ENTITLEMENT + ADJUST
FROM TAM_ALLOWANCE
WHERE (WF_STATUS = 'Pending' OR WF_STATUS = 'Approved' OR
WF_STATUS = 'Verified' OR WF_STATUS is Null OR
WF_STATUS = 'No Action')
and EMPCALENDAR_ID = CAL_EMPCALENDAR.EMPCALENDAR_ID
AND ITEM_ID = (SELECT ITEM_ID
FROM TAM_CLAIM_FORMAT
WHERE SEQUENCE = 4
and bizunit_id like 'SG')) F4,
(SELECT ENTITLEMENT + ADJUST
FROM TAM_ALLOWANCE
WHERE (WF_STATUS = 'Pending' OR WF_STATUS = 'Approved' OR
WF_STATUS = 'Verified' OR WF_STATUS is Null OR
WF_STATUS = 'No Action')
and EMPCALENDAR_ID = CAL_EMPCALENDAR.EMPCALENDAR_ID
AND ITEM_ID = (SELECT ITEM_ID
FROM TAM_CLAIM_FORMAT
WHERE SEQUENCE = 5
and bizunit_id like 'SG')) F5
From CAL_EMPCALENDAR, HRM_CURR_CAREER_V, CAL_SHIFT, HRM_EMPLOYEE
Where CAL_SHIFT.SHIFT_ID(+) = CAL_EMPCALENDAR.ACTUAL_SHIFT_ID
AND (CAL_EMPCALENDAR.WF_STATUS = 'Approved' Or
CAL_EMPCALENDAR.WF_STATUS = 'No Action')
AND CAL_EMPCALENDAR.EMPLOYEE_ID = HRM_EMPLOYEE.EMPLOYEE_ID
--and CAL_EMPCALENDAR.START_DATE between TO_DATE('1-4-2006','DD-MM-YYYY') AND TO_DATE('31-4-2006','DD-MM-YYYY')
AND CAL_EMPCALENDAR.START_DATE BETWEEN
GREATEST(HRM_EMPLOYEE.COMMENCE_DATE,
TO_DATE('1-4-2006', 'DD-MM-YYYY')) AND
LEAST(TO_DATE('30-4-2006', 'DD-MM-YYYY'),
NVL(HRM_EMPLOYEE.CESSATION_DATE,
TO_DATE('30-4-2006', 'DD-MM-YYYY')))
And CAL_EMPCALENDAR.EMPLOYEE_ID like 'SG' || '%'
And CAL_EMPCALENDAR.EMPLOYEE_ID like 'SGTAM001'
And CAL_EMPCALENDAR.EMPLOYEE_ID = HRM_CURR_CAREER_V.EMPLOYEE_ID
-- AND HRM_CURR_CAREER_V.DEPARTMENT_CODE like 'DPHR'
--AND HRM_EMPLOYEE.EMPLOYMENT_TYPE_CODE like '$P!{EmploymentType}'
--$P!{ExceptionSQL}
--$P!{iHRFilterClause}
--order by $P!{OrderBy}
order by main
Hi all this query takes a very long time to run.
On the explain plan the The table in bold letter is using full tablescan rest all go for index scanning.
Table got Indexe on those CLOMUNS REFERREED
Oracle version 9.2.0.6
Message was edited by:
Maran.E
Message was edited by:
Maran.EMaran,
With tags and indentation it should be easiest to analyze at least for you :
SELECT CAL_EMPCALENDAR.START_DATE as main,
bit_empname(CAL_EMPCALENDAR.EMPLOYEE_ID) || ' /' || CAL_EMPCALENDAR.EMPLOYEE_ID as secondary,
TO_DATE('1-4-2006', 'DD-MM-YYYY') as FROM_DATE,
TO_DATE('30-4-2006', 'DD-MM-YYYY') as TO_DATE,
bit_empname(CAL_EMPCALENDAR.EMPLOYEE_ID) || ' / ' || CAL_EMPCALENDAR.EMPLOYEE_ID as name,
CAL_EMPCALENDAR.START_DATE as sdate,
CAL_EMPCALENDAR.OVERTIME_REASON as OTReason,
CAL_EMPCALENDAR.POSTED_ON as POSTED_ON,
TO_CHAR(CAL_EMPCALENDAR.START_DATE, 'Dy') as dayname,
TAM_GET_ADJUSTED_IN(CAL_EMPCALENDAR.EMPCALENDAR_ID) as adj_in,
TAM_GET_ADJUSTED_OUT(CAL_EMPCALENDAR.EMPCALENDAR_ID) as adj_out,
CAL_EMPCALENDAR.SHIFT_ID AS SHIFT_ABBREV,
CAL_EMPCALENDAR.LATE_IN,
CAL_EMPCALENDAR.EARLY_OUT,
CAL_EMPCALENDAR.UNDER_TIME,
CAL_EMPCALENDAR.OVERTIME,
TAM_GET_LEAVE_DESC(CAL_EMPCALENDAR.EMPCALENDAR_ID, 'ALL') Leave,
CAL_EMPCALENDAR.EMPLOYEE_ID as empid,
HRM_CURR_CAREER_V.DEPARTMENT_CODE as deptcode,
BIT_CODEDESC(HRM_CURR_CAREER_V.DEPARTMENT_CODE) as deptname,
(SELECT shift_id
FROM CAL_GRPWORKDAY
WHERE CAL_GRPWORKDAY.calgrp_id = (SELECT calgrp_id
FROM CAL_CALASSIGNMENT
WHERE employee_id = CAL_EMPCALENDAR.employee_id
AND CAL_CALASSIGNMENT.START_DATE <= CAL_EMPCALENDAR.START_DATE
AND ( CAL_CALASSIGNMENT.END_DATE is null
or CAL_CALASSIGNMENT.END_DATE >= CAL_EMPCALENDAR.START_DATE))
AND CAL_GRPWORKDAY.start_date = CAL_EMPCALENDAR.start_date) AS shift_id,
(SELECT max(entry_dt)
FROM LV_TXN txn, CAL_EMPDAILYEVENT cale
WHERE status = 'Approved'
AND LV_APPSTATUSHIST.application_id = txn.application_id
AND cale.reference_id = txn.txn_id
AND cale.empcalendar_id = CAL_EMPCALENDAR.empcalendar_id) AS entry_dt,
(SELECT ENTITLEMENT + ADJUST
FROM TAM_ALLOWANCE
WHERE ( WF_STATUS = 'Pending'
OR WF_STATUS = 'Approved'
OR WF_STATUS = 'Verified'
OR WF_STATUS is Null
OR WF_STATUS = 'No Action')
and EMPCALENDAR_ID = CAL_EMPCALENDAR.EMPCALENDAR_ID
AND ITEM_ID = (SELECT ITEM_ID
FROM TAM_CLAIM_FORMAT
WHERE SEQUENCE = 1
and BIZUNIT_ID like 'SG')) F1,
--TAM_GET_ENT_AND_ADJUSTED(CAL_EMPCALENDAR.EMPCALENDAR_ID, 'SG', 1) F1,
(SELECT ENTITLEMENT + ADJUST
FROM TAM_ALLOWANCE
WHERE ( WF_STATUS = 'Pending'
OR WF_STATUS = 'Approved'
OR WF_STATUS = 'Verified'
OR WF_STATUS is Null
OR WF_STATUS = 'No Action')
and EMPCALENDAR_ID = CAL_EMPCALENDAR.EMPCALENDAR_ID
AND ITEM_ID = (SELECT ITEM_ID
FROM TAM_CLAIM_FORMAT
WHERE SEQUENCE = 2
and bizunit_id like 'SG')) F2,
(SELECT ENTITLEMENT + ADJUST
FROM TAM_ALLOWANCE
WHERE ( WF_STATUS = 'Pending'
OR WF_STATUS = 'Approved'
OR WF_STATUS = 'Verified'
OR WF_STATUS is Null
OR WF_STATUS = 'No Action')
and EMPCALENDAR_ID = CAL_EMPCALENDAR.EMPCALENDAR_ID
AND ITEM_ID = (SELECT ITEM_ID
FROM TAM_CLAIM_FORMAT
WHERE SEQUENCE = 3
and bizunit_id like 'SG')) F3,
(SELECT ENTITLEMENT + ADJUST
FROM TAM_ALLOWANCE
WHERE ( WF_STATUS = 'Pending'
OR WF_STATUS = 'Approved'
OR WF_STATUS = 'Verified'
OR WF_STATUS is Null
OR WF_STATUS = 'No Action')
and EMPCALENDAR_ID = CAL_EMPCALENDAR.EMPCALENDAR_ID
AND ITEM_ID = (SELECT ITEM_ID
FROM TAM_CLAIM_FORMAT
WHERE SEQUENCE = 4
and bizunit_id like 'SG')) F4,
(SELECT ENTITLEMENT + ADJUST
FROM TAM_ALLOWANCE
WHERE ( WF_STATUS = 'Pending'
OR WF_STATUS = 'Approved'
OR WF_STATUS = 'Verified'
OR WF_STATUS is Null
OR WF_STATUS = 'No Action')
and EMPCALENDAR_ID = CAL_EMPCALENDAR.EMPCALENDAR_ID
AND ITEM_ID = (SELECT ITEM_ID
FROM TAM_CLAIM_FORMAT
WHERE SEQUENCE = 5
and bizunit_id like 'SG')) F5
From CAL_EMPCALENDAR,
HRM_CURR_CAREER_V,
CAL_SHIFT,
HRM_EMPLOYEE
Where CAL_SHIFT.SHIFT_ID(+) = CAL_EMPCALENDAR.ACTUAL_SHIFT_ID
AND ( CAL_EMPCALENDAR.WF_STATUS = 'Approved'
Or CAL_EMPCALENDAR.WF_STATUS = 'No Action')
AND CAL_EMPCALENDAR.EMPLOYEE_ID = HRM_EMPLOYEE.EMPLOYEE_ID
--and CAL_EMPCALENDAR.START_DATE between TO_DATE('1-4-2006','DD-MM-YYYY') AND TO_DATE('31-4-2006','DD-MM-YYYY')
AND CAL_EMPCALENDAR.START_DATE BETWEEN GREATEST(HRM_EMPLOYEE.COMMENCE_DATE, TO_DATE('1-4-2006', 'DD-MM-YYYY'))
AND LEAST(TO_DATE('30-4-2006', 'DD-MM-YYYY'), NVL(HRM_EMPLOYEE.CESSATION_DATE, TO_DATE('30-4-2006', 'DD-MM-YYYY')))
And CAL_EMPCALENDAR.EMPLOYEE_ID like 'SG' || '%'
And CAL_EMPCALENDAR.EMPLOYEE_ID like 'SGTAM001'
And CAL_EMPCALENDAR.EMPLOYEE_ID = HRM_CURR_CAREER_V.EMPLOYEE_ID
-- AND HRM_CURR_CAREER_V.DEPARTMENT_CODE like 'DPHR'
--AND HRM_EMPLOYEE.EMPLOYMENT_TYPE_CODE like '$P!{EmploymentType}'
--$P!{ExceptionSQL}
--$P!{iHRFilterClause}
--order by $P!{OrderBy}
order by mainNicolas. -
My query take long time..
The output of tkprof of my trace file is :
SELECT ENEXT.NUM_PRSN_EMPLY ,ENEXT.COD_BUSUN ,ENEXT.DAT_CALDE ,ENEXT.COD_SHFT
FROM
AAC_EMPLOYEE_ENTRY_EXITS5_VIW ENEXT ,PDS.PDS_EMPLOYEES EMPL ,
PDS.PDS_EMPLOYMENT_TYPES EMPTYP ,PDS.PDS_PAY_CONDITIONS PAYCON WHERE
ENEXT.DAT_CALDE BETWEEN :B6 AND :B5 AND ENEXT.NUM_PRSN_EMPLY IN (SELECT
ATT21 FROM APPS.GLOBAL_TEMPS WHERE ATT1 = 'PRSN') AND ENEXT.NUM_PRSN_EMPLY =
EMPL.NUM_PRSN_EMPLY AND EMPL.EMTYP_COD_EMTYP = EMPTYP.COD_EMTYP AND
EMPTYP.LKP_COD_STA_PAY_EMTYP <> 3 AND
NVL(EMPL.LKP_MNTLY_WITHOUT_ENEXT_EMPLY,2) <> 1 AND EMPL.PCOND_COD_STA_PCOND
= PAYCON.COD_STA_PCOND AND NVL(EMPL.LKP_MNTLY_WITHOUT_ENEXT_EMPLY,2) <> 1
AND PAYCON.LKP_FLG_STA_PAY_PCOND = 1 AND ENEXT.DAT_CALDE >=
EMPL.DAT_EMPLT_EMPLY AND ENEXT.DAT_CALDE <= NVL(EMPL.DAT_DSMSL_EMPLY,
TO_DATE('15001229','YYYYMMDD')) AND 1 = (CASE WHEN
ENEXT.LKP_STA_HOLIDAY_CALNR = 2 AND ENEXT.LKP_CAT_SHFT_SHTAB = 1 AND
ENEXT.TYP_DAY BETWEEN 4 AND 6 THEN 0 WHEN ENEXT.LKP_STA_HOLIDAY_CALNR = 2
AND ENEXT.LKP_CAT_SHFT_SHTAB = 1 AND ENEXT.TYP_DAY NOT BETWEEN 4 AND 6 THEN
1 WHEN ENEXT.LKP_STA_HOLIDAY_CALNR = 2 AND ENEXT.LKP_CAT_SHFT_SHTAB = 2
THEN 0 WHEN ENEXT.LKP_STA_HOLIDAY_CALNR = 1 AND ENEXT.LKP_CAT_SHFT_SHTAB =
1 THEN 1 WHEN ENEXT.LKP_STA_HOLIDAY_CALNR = 1 AND ENEXT.LKP_CAT_SHFT_SHTAB =
2 THEN 0 END) AND ENEXT.LKP_COD_DPUT_BUSUN = NVL(:B4 ,
ENEXT.LKP_COD_DPUT_BUSUN) AND ENEXT.LKP_COD_MANAG_BUSUN = NVL(:B3 ,
ENEXT.LKP_COD_MANAG_BUSUN) AND ENEXT.COD_BUSUN = NVL(:B2 , ENEXT.COD_BUSUN)
AND ENEXT.COD_CAL = NVL(COD_CAL, ENEXT.COD_CAL) AND ENEXT.NUM_PRSN_EMPLY =
NVL(:B1 , ENEXT.NUM_PRSN_EMPLY) AND ENEXT.COD_SHFT IN (SELECT
SHFTBL.COD_SHTAB FROM AAC_SHIFT_TABLES SHFTBL WHERE
SHFTBL.LKP_CAT_SHFT_SHTAB = 1) AND ENEXT.DAT_CALDE NOT IN (SELECT ABN.DAT
FROM APPS.AAC_EMPL_EN_EX_ABNORMAL_VIW ABN WHERE ABN.PRSN =
ENEXT.NUM_PRSN_EMPLY AND ABN.DAT BETWEEN :B6 AND :B5 ) AND ENEXT.DAT_CALDE
IN (SELECT EMPENEXT.DAT_STR_SHFT_ENEXT FROM AAC.AAC_EMPLOYEE_ENTRY_EXITS
EMPENEXT WHERE EMPENEXT.EMPLY_NUM_PRSN_EMPLY = EMPL.NUM_PRSN_EMPLY AND
EMPENEXT.DAT_STR_SHFT_ENEXT BETWEEN :B6 AND :B5 AND
EMPENEXT.LKP_FLG_STA_ENEXT <> 3) ORDER BY ENEXT.NUM_PRSN_EMPLY,
ENEXT.DAT_CALDE
call count cpu elapsed disk query current rows
Parse 2 0.00 0.00 0 0 0 0
Execute 2 0.00 0.00 0 0 0 0
Fetch 2 40.45 40.30 306 17107740 0 24
total 6 40.45 40.30 306 17107740 0 24
what is wrong in my query?
why it take long time?user13344656 wrote:
what is wrong in my query?
why it take long time?See PL/SQL forum FAQ
https://forums.oracle.com/forums/ann.jspa?annID=1535
*3. How to improve the performance of my query? / My query is running slow.*
SQL and PL/SQL FAQ
For instructions on what information to post an how to format it. -
With my ESTK script, users select model numbers from a list and then the script inserts an element with a model number entered into an attribute, one element for each model selected.
When adding a large number of elements, each additional sibling element takes a little longer to add then the previous element. Adding 250 elements can take upwards of 3-1/2 minutes or more. While adding 20, 50, or 75 elements happens quickly, without any noticeable duration. It’s somewhere above 110 is where it starts to be noticeable.
I even used $.hiresTimer and wrote the value to the console for each time a model was added. Since the timer is reset back to zero (0) each time it's called, it was easier to notice that the amount it incremented from one element to the next got progressively larger.
Any thoughts as to why it’s taking so long or thoughts on what I could do to speed it up?
The structure looks like this:
<PartModels>
<NoteText>Text</NoteText>
<Model ModelNumber=”ABC01”/>
<Model ModelNumber=”ABC02”/>
<Model ModelNumber=”DEF03”/>
<Model ModelNumber=”DEF04”/>
<Model ModelNumber=”XYZ01-A”/>
<Model ModelNumber=”XYZ*B”/>
<Model ModelNumber=”XYZ500”/>
</PartModels>
The script is somewhat straight forward: cycle through an array of the model numbers selected, add a new element for each model number and set it's attribute value to the model number. This is the short version:
Function InsertModelElements (modelsToIns, insElemLoc, GVdoc) {
var newEleId;
var newElemLoc = insElemLoc;
var elemDef = GVdoc.GetNamedElementDef(“Model”);
for(var i = 0; i < modelsToIns.length; i++){ // modelsToIns is the array of models selected
newEleId = elemDef.NewElementInHierarchy(newElemLoc); //ElementLoc based on NoteText first, last, or not present
SetAttribute(newEleId, "ModelNumber", null, modelsToIns[i]); //more robust function to set attribute
/*Which also works for setting attribute*/
//var vattributes = newEleId.GetAttributes();
//vattributes[0].values[0] = modelsToIns[i];
//newEleId.Attributes = vattributes;
/*At one point I tried using a new element location from the last inserted element, no change*/
//var newElemRange = setElementSelection(GV_doc, EleId); //function that returns range
//newElemLoc = newNewElemRange.end;
Any help is appreciated.
Sincerely,
TrentThanks Russ,
I seriously considered trying copy/paste and started to modify the code to do so. But I couldn't let it go, the answer had to be right there in front of me, just it's been too long since I've worked with this stuff, I'm not able to see it. Then it dawned on me what is happening.
In an earlier test, I placed a timer on each action that is looped through. For example, I start with an container element that has 200 children elements, each with a specific/unique model number attribute. All 200 existing elements are deleted and then replaced with 250 new elements with a different value for the model number attribute. The timer was placed after the Element.Delete() method and ElementDef.NewElementInHierarchy() method. What I noticed with the timer is that each element deleted was deleted faster than the previous element (so it progressively took less and less time to delete an element). And of course the opposite was noticed for inserting elements, each element inserted took longer than the previous element inserted.
These elements can be inserted in two areas of the structure, one of the areas has fewer format rules that impact the formatting and is actually a little quicker. This led me to the cause being the EDD format rules. The area that takes longer has quite a few extensive format rules that apply. Every time an element is inserted or deleted, FrameMaker runs through those rules to format the content of the elements. Since the rules apply to parent, first, last, next, previous, etc., FrameMaker has to apply format rules to all the elements in the structure that the rules apply to (which are extremely complex because of the various elements, attribute values, and combinations that can be inserted).
Removing or thinning down the FormatRules in the EDD, it does get quicker. But each of the FormatRules are needed. So using app.ApplyFormatRules = false; right before the elements are deleted and inserted works great. But the key is to set ApplyFormatRules back to true before deleting the last element to be deleted and before inserting the last element to be inserted, so it will cycle through all the format rules of the EDD for all the elements in the hierarchy those format rules apply to. Setting ApplyFormatRules to true and assigning the ElementDef to the last element also works [EleId.ElementDef = GV_doc.GetNamedElementDef(insElemType);], but only before any other functions are performed or different elements are added.
doc.Reformat() isn't going to reformat the content correctly after the fact because the element was created without the format rules, so it just reformats the content of the elements without the format rules.
The FDK version that was created 10 years ago had the same problem of running slow when a large number of elements were being inserted, but was still an improvement over having to manually insert each element and type in the attribute value, so it was lived with.
It's now working amazingly fast. I hope my explanation of what I think is happening, including the cause/solution, is understandable.
Sincerely,
Trent Schwartz -
Query takes long time to return results.
I am on Oracle database 10g Enterprise Edition Release 10.2.0.4.0 – 64 bit
This query takes about 58 seconds to return 180 rows...
SELECT order_num,
order_date,
company_num,
customer_num,
address_type,
create_date as address_create_date,
contact_name,
first_name,
middle_init,
last_name,
company_name,
street_address_1,
customer_class,
city,
state,
zip_code,
country_code,
MAX(decode(media_type,
'PHH',
phone_area_code || '''' || phone_number,
NULL)) home_phone,
MAX(decode(media_type,
'PHW',
phone_area_code || '''' || phone_number,
NULL)) work_phone,
address_seq_num,
street_address_2
FROM (SELECT oh.order_num order_num,
oh.order_datetime order_date,
oh.company_num company_num,
oh.customer_num customer_num,
ad.address_type address_type,
c.create_date create_date,
con.first_name || '''' || con.last_name contact_name,
con.first_name first_name,
con.middle_init middle_init,
con.last_name last_name,
ad.company_name company_name,
ad.street_address_1 street_address_1,
c.customer_class customer_class,
ad.city city,
ad.state state,
ad.zip_code zip_code,
ad.country_code,
cph.media_type media_type,
cph.phone_area_code phone_area_code,
cph.phone_number phone_number,
ad.address_seq_num address_seq_num,
ad.street_address_2 street_address_2
FROM reporting_base.gt_gaft_orders gt,
doms.us_ordhdr oh,
doms.us_address ad,
doms.us_customer c,
doms.us_contact con,
doms.us_contph cph
WHERE oh.customer_num = c.customer_num(+)
AND oh.customer_num = ad.customer_num(+)
AND (
ad.customer_num = c.customer_num
AND
ad.address_type = 'B'
OR (
ad.customer_num = c.customer_num
AND
ad.address_type = 'S'
AND
ad.address_seq_num = oh.ship_to_seq_num
AND ad.customer_num = con.customer_num(+)
AND ad.address_type = con.address_type(+)
AND ad.address_seq_num = con.address_seq_num(+)
AND con.customer_num = cph.customer_num(+)
AND con.contact_id = cph.contact_id(+)
AND oh.order_num = gt.order_num
AND oh.business_unit_id = gt.business_unit_id)
GROUP BY order_num,
order_date,
company_num,
customer_num,
address_type,
create_date,
contact_name,
first_name,
middle_init,
last_name,
company_name,
street_address_1,
customer_class,
city,
state,
zip_code,
country_code,
address_seq_num,
street_address_2;This is the explain plan for the query:
Plan
SELECT STATEMENT FIRST_ROWS Cost: 21 Bytes: 207 Cardinality: 1
18 HASH GROUP BY Cost: 21 Bytes: 207 Cardinality: 1
17 NESTED LOOPS OUTER Cost: 20 Bytes: 207 Cardinality: 1
14 NESTED LOOPS OUTER Cost: 16 Bytes: 183 Cardinality: 1
11 FILTER
10 NESTED LOOPS OUTER Cost: 12 Bytes: 152 Cardinality: 1
7 NESTED LOOPS OUTER Cost: 8 Bytes: 74 Cardinality: 1
4 NESTED LOOPS OUTER Cost: 5 Bytes: 56 Cardinality: 1
1 TABLE ACCESS FULL TABLE (TEMP) REPORTING_BASE.GT_GAFT_ORDERS Cost: 2 Bytes: 26 Cardinality: 1
3 TABLE ACCESS BY INDEX ROWID TABLE DOMS.US_ORDHDR Cost: 3 Bytes: 30 Cardinality: 1
2 INDEX UNIQUE SCAN INDEX (UNIQUE) DOMS.USORDHDR_IXUPK_ORDNUMBUID Cost: 2 Cardinality: 1
6 TABLE ACCESS BY GLOBAL INDEX ROWID TABLE DOMS.US_CUSTOMER Cost: 3 Bytes: 18 Cardinality: 1 Partition #: 11
5 INDEX UNIQUE SCAN INDEX (UNIQUE) DOMS.USCUSTOMER_IXUPK_CUSTNUM Cost: 2 Cardinality: 1
9 TABLE ACCESS BY GLOBAL INDEX ROWID TABLE DOMS.US_ADDRESS Cost: 4 Bytes: 156 Cardinality: 2 Partition #: 13
8 INDEX RANGE SCAN INDEX (UNIQUE) DOMS.USADDR_IXUPK_CUSTATYPASEQ Cost: 3 Cardinality: 2
13 TABLE ACCESS BY GLOBAL INDEX ROWID TABLE DOMS.US_CONTACT Cost: 4 Bytes: 31 Cardinality: 1 Partition #: 15
12 INDEX RANGE SCAN INDEX DOMS.USCONT_IX_CNATAS Cost: 3 Cardinality: 1
16 TABLE ACCESS BY GLOBAL INDEX ROWID TABLE DOMS.US_CONTPH Cost: 4 Bytes: 24 Cardinality: 1 Partition #: 17
15 INDEX RANGE SCAN INDEX (UNIQUE) DOMS.USCONTPH_IXUPK_CUSTCONTMEDSEQ Cost: 3 Cardinality: 1 Cost is good. All indexes are used. However the time to return the data is very high.
Any ideas to make the query faster?.
ThanksHi, here is the tkprof output as requested by Rob..
TKPROF: Release 10.2.0.4.0 - Production on Mon Jul 13 09:07:09 2009
Copyright (c) 1982, 2007, Oracle. All rights reserved.
Trace file: axispr1_ora_15293.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
SELECT ORDER_NUM, ORDER_DATE, COMPANY_NUM, CUSTOMER_NUM, ADDRESS_TYPE,
CREATE_DATE AS ADDRESS_CREATE_DATE, CONTACT_NAME, FIRST_NAME, MIDDLE_INIT,
LAST_NAME, COMPANY_NAME, STREET_ADDRESS_1, CUSTOMER_CLASS, CITY, STATE,
ZIP_CODE, COUNTRY_CODE, MAX(DECODE(MEDIA_TYPE, 'PHH', PHONE_AREA_CODE ||
'''' || PHONE_NUMBER, NULL)) HOME_PHONE, MAX(DECODE(MEDIA_TYPE, 'PHW',
PHONE_AREA_CODE || '''' || PHONE_NUMBER, NULL)) WORK_PHONE, ADDRESS_SEQ_NUM,
STREET_ADDRESS_2
FROM
(SELECT OH.ORDER_NUM ORDER_NUM, OH.ORDER_DATETIME ORDER_DATE, OH.COMPANY_NUM
COMPANY_NUM, OH.CUSTOMER_NUM CUSTOMER_NUM, AD.ADDRESS_TYPE ADDRESS_TYPE,
C.CREATE_DATE CREATE_DATE, CON.FIRST_NAME || '''' || CON.LAST_NAME
CONTACT_NAME, CON.FIRST_NAME FIRST_NAME, CON.MIDDLE_INIT MIDDLE_INIT,
CON.LAST_NAME LAST_NAME, AD.COMPANY_NAME COMPANY_NAME, AD.STREET_ADDRESS_1
STREET_ADDRESS_1, C.CUSTOMER_CLASS CUSTOMER_CLASS, AD.CITY CITY, AD.STATE
STATE, AD.ZIP_CODE ZIP_CODE, AD.COUNTRY_CODE, CPH.MEDIA_TYPE MEDIA_TYPE,
CPH.PHONE_AREA_CODE PHONE_AREA_CODE, CPH.PHONE_NUMBER PHONE_NUMBER,
AD.ADDRESS_SEQ_NUM ADDRESS_SEQ_NUM, AD.STREET_ADDRESS_2 STREET_ADDRESS_2
FROM REPORTING_BASE.GT_GAFT_ORDERS GT, DOMS.US_ORDHDR OH, DOMS.US_ADDRESS
AD, DOMS.US_CUSTOMER C, DOMS.US_CONTACT CON, DOMS.US_CONTPH CPH WHERE
OH.ORDER_NUM = GT.ORDER_NUM AND OH.BUSINESS_UNIT_ID = GT.BUSINESS_UNIT_ID
AND OH.CUSTOMER_NUM = C.CUSTOMER_NUM(+) AND OH.CUSTOMER_NUM =
AD.CUSTOMER_NUM(+) AND AD.CUSTOMER_NUM = C.CUSTOMER_NUM AND (
AD.ADDRESS_TYPE = 'B' OR ( AD.ADDRESS_TYPE = 'S' AND AD.ADDRESS_SEQ_NUM =
OH.SHIP_TO_SEQ_NUM ) ) AND AD.CUSTOMER_NUM = CON.CUSTOMER_NUM(+) AND
AD.ADDRESS_TYPE = CON.ADDRESS_TYPE(+) AND AD.ADDRESS_SEQ_NUM =
CON.ADDRESS_SEQ_NUM(+) AND CON.CUSTOMER_NUM = CPH.CUSTOMER_NUM(+) AND
CON.CONTACT_ID = CPH.CONTACT_ID(+) ) GROUP BY ORDER_NUM, ORDER_DATE,
COMPANY_NUM, CUSTOMER_NUM, ADDRESS_TYPE, CREATE_DATE, CONTACT_NAME,
FIRST_NAME, MIDDLE_INIT, LAST_NAME, COMPANY_NAME, STREET_ADDRESS_1,
CUSTOMER_CLASS, CITY, STATE, ZIP_CODE, COUNTRY_CODE, ADDRESS_SEQ_NUM,
STREET_ADDRESS_2
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 0 0.00 0.00 0 0 0 0
Fetch 257 0.04 0.05 45 0 0 6421
total 257 0.04 0.05 45 0 0 6421
Misses in library cache during parse: 0
Parsing user id: 126
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 0 0.00 0.00 0 0 0 0
Fetch 257 0.04 0.05 45 0 0 6421
total 257 0.04 0.05 45 0 0 6421
Misses in library cache during parse: 0
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 0 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
total 0 0.00 0.00 0 0 0 0
Misses in library cache during parse: 0
1 user SQL statements in session.
0 internal SQL statements in session.
1 SQL statements in session.
Trace file: axispr1_ora_15293.trc
Trace file compatibility: 10.01.00
Sort options: default
1 session in tracefile.
1 user SQL statements in trace file.
0 internal SQL statements in trace file.
1 SQL statements in trace file.
1 unique SQL statements in trace file.
289 lines in trace file.
83 elapsed seconds in trace file.Thanks in advance! -
How to do sum when using union
hi,
i am getting following example data from a query
which uses UNION which is mandatory.
is there a way to do sum of Units column to get a single
row ?
hire date units
01.08.2003 1,00
01.08.2003 12,50
like to see as a single row
01.08.2003 13,50
rgds,
KarnaSELECT hire_date, SUM(units) units
FROM (SELECT hire_date, units
FROM table1
UNION ALL
SELECT hire_date, units
FROM table2)
GROUP BY hire_dateTTFN
John -
Need sql query to remove duplicates using UNION ALL clause
Hi,
I have a sql query which has UNION clause.But the UNION clause is causing some performance issues.
To overcome that I have used UNION ALL to improve performance but its returning duplicates.
Kindly anyone send a sample SQL query where my primary objective is used to use UNION ALL clause and to consider unique rows (elimating duplicate
ones)
Any help will be needful for me
Thanks and Regardswhy not UNION? :(
another way also use MINUS
SQL>
SQL> with t as
2 (
3 select 1 if from dual union all
4 select 2 if from dual union all
5 select 1 if from dual union all
6 select 3 if from dual union all
7 select 3 if from dual
8 )
9 ,t2 as
10 (
11 select 1 if from dual union all
12 select 2 if from dual union all
13 select 3 if from dual union all
14 select 4 if from dual union all
15 select 5 if from dual
16 )
17 (select if from t
18 union all
19 select if from t2)
20 /
IF
1
2
1
3
3
1
2
3
4
5
10 rows selected
SQL> so
SQL>
SQL> with t as
2 (
3 select 1 if from dual union all
4 select 2 if from dual union all
5 select 1 if from dual union all
6 select 3 if from dual union all
7 select 3 if from dual
8 )
9 ,t2 as
10 (
11 select 1 if from dual union all
12 select 2 if from dual union all
13 select 3 if from dual union all
14 select 4 if from dual union all
15 select 5 if from dual
16 )
17 (select if from t
18 union all
19 select if from t2)
20 minus
21 select -99 from dual
22 /
IF
1
2
3
4
5
SQL> -
Query Designer crashes when using 0CALWEK
Hi all
I have come accross an error when using the query designer in BI 7.0. If i try to restrict on 0CALWEEK the Query Designer first tells me there are errors but none show, then tells me there are no values for 0CALWEEK and finally crashes saying
"An unhandled exception has occurred in your application."
"Object reference not set to an instance of an object."
After this the desiger freezes and must be exited.
On occasions an RFC error shows on the botton of the design view suggesting a check of the RFC logs, however nothing appears in the RFC log.
Any assistance would be very much appreciated.
With Thanks
GarethAnil
Generating in RSRT does not fix the problem.
Checking the query designer shows no errors, however once we get the crash after attempting to restrict on 0CALWEEK it is not possible to use the check button (since the whole of query designer freezes).
This is happenning on our development system (the only one on which we are currently creating queries) and on all PCs.
The note, unfortunately, refers to an issue when using gui 7.X, however we are using 640 so it should not be a .net framework issue however i am asking my BASIS team to do some testing on that.
Many thanks for your suggestion though.
Any other ideas?
Regards
Gareth -
Drill down problem when using union all combination
Hi All,
I have a simple report with a drill down. The report has three columns Region, Sales, Flag... which will drill down to detail level of sales. The Flag column has Y, N values and we added 'All' Value in flag so that the user can select Y, N and All from the table prompt in the report . We have used union all in the report using combination to add the ' All ' Value in the flag. The problem is that now the main report is not passing the Flag values to the detail report. Flag is prompted in the filter in detail report.
If I remove the 'All' value from Analysis with only Y N selection criteria the drill down works.
Is there any work around? I have to use table prompt and All value selection in flag for drill down.
Thanks,
ViratThe problem is without union all when doing combination of analysis drill down works, when I use combination drill down does not work because it does not pass the parameters for flag . I have used union all to add All value in flag.
Maybe you are looking for
-
How to call a Shell Script from Report 6i
Hi All, Can anybody tell, how to call a Shell Script from Report 6i. Thanks in Advance, Bala
-
Am having no luck trying to bulk import existing forms made in .xls or .word. This product is of limited utility if I am forced to recreate forms line-by-line.
-
Images on websites are discolored and misplaced
<i>Locking duplicate thread.<br>Please continue here: [[/questions/1056278]]</i> it happens on somewebsites not all
-
Major help needed! Saving iPhoto book as a working file
I am a student teacher and I am teaching a lesson on Friday that uses iPhoto book. My cooperating teacher has asked me to create an iPhoto book template for the students to use to make the activity easier for them. I have created the template book bu
-
Hello, I have some questions regarding the VDI Core part: - I want to install 4 servers for VDI Core. I run vda-config script on primary server. I can "only" set two secondary servers within this script. What I have to do to configure the fourth serv