Query on dba_scheduler_job_run_details slow
- DBMS_SCHEDULER.PURGE_LOG purges the log information successfully.
- Scheduler global attribute LOG_HISTORY is set to 7.
- Log history attribute for the job classes is set to NULL.
Eventhough, there are only less than 100 rows each in scheduler$_job_log_details and scheduler$_event_log tables, over a period of time, these tables have grown and have more than 100,000 blocks allocated. So the query against dba_scheduler_job_run_details takes time to return as it is doing a FTS on these tables.
Is there a way to TRUNCATE (and to reset the HWM) the scheduler$_job_log_details and scheduler$_event_log tables using DBMS_SCHEDULER.PURGE_LOG?
Is it okay to manually TRUNCATE these 2 log tables?
I would appreciate any help on this.
Hi,
I can't comment on how to improve the tables performance, I guess the same techniques that would work on any other table would work here.
Doing a dbms_scheduler.purge_log() should to the equivalent of a truncate on the 2 base tables so you shouldn't need to yourself.
In case you do need to, doing a truncate on the two base tables is safe, but only if there are no chain jobs running. The two base tables that these views select from are
sys.scheduler$_event_log
sys.scheduler$_job_run_details
Hope this helps,
Ravi.
Similar Messages
-
declare @search varchar(100)
select id,name,grade from VCustomer(10 million records)
where cast(id as varchar) like @search +%
here id is bigint and cast operation used in where condition so query is getting slow.Please do the needful.How to avoid this cast opeartion in query.
Cheers,Thanks for your valuable response.But still I am getting table scan.
I have modified the column data type into Varchar.But in where clause there are two string search i.e.
declare @search varchar(100)
ID varchar(50),CustomerID varchar(50)
select id,name,grade from VCustomer(10 million records) VC LEFT OUTER JOIN VBooking VB(20 Millions)
ON VC.ID=VB.CustomerID
where ID like @search +'%' or CustomerID like @search +'%'
Here I am getting both table scans.Please do the needful.
Cheers, -
Query runs much slower the second time!
I am doing a simple SELECT on a fairly complex view:
select * from balances where day = date'2011-08-15';The results are correct, and they arrive in about 3 seconds. However, immediately repeating the exact same query takes about 3 minutes!
Using a different SELECT list and/or WHERE clause gives a quick result, but only once; repeating any past query triggers the big slowdown.
Doing ANALYZE TABLE on any of the tables involved in the view seems to reset things and the queries become fast again, but still only once for each specific query.
This view worked fine on 9i and has only started doing this since we moved to 11g.
Weird, eh?Here's EXPLAIN PLAN, which is the same before the fast query, before the slow query, and after the slow query.
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 184K| 11M| | 364K (1)| 01:12:52 |
| 1 | HASH GROUP BY | | 184K| 11M| 13M| 364K (1)| 01:12:52 |
|* 2 | FILTER | | | | | | |
| 3 | NESTED LOOPS OUTER | | 184K| 11M| | 361K (1)| 01:12:17 |
| 4 | NESTED LOOPS | | 3071 | 82917 | | 27 (0)| 00:00:01 |
| 5 | TABLE ACCESS BY INDEX ROWID | GL_DAYS | 1 | 12 | | 2 (0)| 00:00:01 |
|* 6 | INDEX UNIQUE SCAN | GL_DAYS_DAY | 1 | | | 1 (0)| 00:00:01 |
|* 7 | TABLE ACCESS FULL | GL_ACCOUNTS | 3071 | 46065 | | 25 (0)| 00:00:01 |
| 8 | VIEW | | 60 | 2340 | | 118 (0)| 00:00:02 |
|* 9 | FILTER | | | | | | |
|* 10 | TABLE ACCESS BY INDEX ROWID | GL_ENTRIES | 60 | 1380 | | 28 (0)| 00:00:01 |
|* 11 | INDEX RANGE SCAN | GL_ENTRIES_BY_ACCOUNT | 46 | | | 2 (0)| 00:00:01 |
| 12 | NESTED LOOPS | | 1 | 15 | | 3 (0)| 00:00:01 |
| 13 | TABLE ACCESS BY INDEX ROWID| GL_VOUCHERS | 1 | 7 | | 2 (0)| 00:00:01 |
|* 14 | INDEX UNIQUE SCAN | GL_VOUCHERS_PK | 1 | | | 1 (0)| 00:00:01 |
|* 15 | TABLE ACCESS BY INDEX ROWID| GL_PERIODS | 104 | 832 | | 1 (0)| 00:00:01 |
|* 16 | INDEX UNIQUE SCAN | GL_PERIODS_PK | 1 | | | 0 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - filter(TO_DATE(' 2011-08-15 00:00:00', 'syyyy-mm-dd hh24:mi:ss')<CURRENT_DATE+730)
6 - access("D"."DAY"=TO_DATE(' 2011-08-15 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
filter("D"."DAY"<CURRENT_DATE+730)
7 - filter("A"."HAS_SUB"=0)
9 - filter("D"."FISCAL_YEAR"= (SELECT "P"."FISCAL_YEAR" FROM MFA4."GL_PERIODS" "P",MFA4."GL_VOUCHERS"
"V" WHERE "V"."ID"=:B1 AND "P"."ID"="V"."PERIOD_ID" AND "P"."PERIOD_NO"<13))
10 - filter("E"."ENTRY_DATE"<="D"."DAY")
11 - access("E"."ACCOUNT_ID"="A"."ID")
14 - access("V"."ID"=:B1)
15 - filter("P"."PERIOD_NO"<13)
16 - access("P"."ID"="V"."PERIOD_ID")As for the trace file, did you want the raw .trc file or the tkprof output? -
Parallel hint causes a query to run slower?
I have an insert...select query where the select is a join between a table with one billion rows (although there is a where clause on an indexed column that restricts it to "only" 300 million), a table with 30 million rows, and a table with about 100,000 rows, where the result is about 20 rows. When I first ran it, it took about 2 hours. I added a Parallel hint, and explain plan showed that it was being used (and v$session showed that I had about 30 additional connections while it ran). but not it takes four hours.
Is there a reason parallel processing would cause a query to run slower?
insert /*+ append */ into employees_by_age_group
pay_plan
, age_range
, pay_level
, fy
, employee_count
select /*+ parallel */
emp.pay_plan
, to_char(d.min_age) || '-' || to_char(d.max_age) as age_range
, emp.pay_level
, pay.fy
, count(pay.employee_id) as employee_count
from
select /*+ index(pay_info pay_info_index_on_site) */
employee_id
, extract(year from (dte_ppe_end + 92)) as fy
, count(employee_id) as num_recs
from pay_info
where extract(month from dte_ppe_end) = 10
and extract(day from dte_ppe_end) between 14 and 27
and substr(pay_type, 1, 1) IN ('A', 'B', 'C')
and site like 'Z%'
group by employee_id, extract(year from (dte_ppe_end + 92))
) pay
join
select employee_id
, pay_plan
, pay_grade
, pay_step
, file_date
from
select /*+ index(employee_info employee_info_index_on_site) */
employee_id
, pay_level
, file_date
, max(file_date)
over (partition by extract(year from (file_date + 61)))
as last_file_date
from employee_info
where site like 'Z%'
where file_date = last_file_date
) emp
on (
emp.employee_id = pay.employee_id
and extract(year from emp.file_date) = pay.fy - 1
join (
select employee_id
, dob
from (
select employee_id
, date_birth
, row_number() over (partition by employee_id order by date_file desc) as r
from employee_birthdates
where site like 'Z%'
where r = 1
) dob
on dob.employee_id = pay.employee_id
join
select 20 as min_age, 24 as max_age from dual
union all select 25 as min_age, 29 as max_age from dual
union all select 30 as min_age, 34 as max_age from dual
union all select 35 as min_age, 39 as max_age from dual
union all select 40 as min_age, 44 as max_age from dual
union all select 45 as min_age, 49 as max_age from dual
union all select 50 as min_age, 54 as max_age from dual
union all select 55 as min_age, 59 as max_age from dual
union all select 60 as min_age, 64 as max_age from dual
union all select 65 as min_age, 69 as max_age from dual
union all select 70 as min_age, 74 as max_age from dual
union all select 75 as min_age, 79 as max_age from dual
union all select 80 as min_age, 84 as max_age from dual
union all select 85 as min_age, 89 as max_age from dual
union all select 90 as min_age, 94 as max_age from dual
union all select 95 as min_age, 99 as max_age from dual
) d
group by emp.pay_plan, d.min_age, d.max_age, emp.pay_level, pay.fy;Paul - here are three different explain plans
First, the original one (without the parallel hint):
INSERT STATEMENT ALL_ROWS Cost: 26,684,255 Bytes: 114 Cardinality: 1
35 LOAD AS SELECT EMPLOYEES_BY_AGE_GROUP
34 HASH GROUP BY Cost: 26,684,255 Bytes: 114 Cardinality: 1
33 NESTED LOOPS Cost: 26,684,254 Bytes: 114 Cardinality: 1
14 HASH JOIN Cost: 26,684,222 Bytes: 108 Cardinality: 1
9 MERGE JOIN Cost: 4,408,803 Bytes: 8,322 Cardinality: 146
3 VIEW DONBOT_DBA. Cost: 114,863 Bytes: 29,625,180 Cardinality: 987,506
2 WINDOW SORT PUSHED RANK Cost: 114,863 Bytes: 35,550,216 Cardinality: 987,506
1 TABLE ACCESS FULL TABLE EMPLOYEE_BIRTHDATES Cost: 108,983 Bytes: 35,550,216 Cardinality: 987,506
8 SORT JOIN Cost: 4,293,940 Bytes: 3,645 Cardinality: 135
7 VIEW DONBOT_DBA. Cost: 4,293,939 Bytes: 3,645 Cardinality: 135
6 SORT GROUP BY Cost: 4,293,939 Bytes: 4,185 Cardinality: 135
5 TABLE ACCESS BY INDEX ROWID TABLE PAY_INFO Cost: 4,293,938 Bytes: 4,185 Cardinality: 135
4 INDEX RANGE SCAN INDEX PAY_INFO_INDEX_ON_SITE Cost: 487,124 Cardinality: 402,683,034
13 VIEW DONBOT_DBA Cost: 22,275,300 Bytes: 1,160,143,257 Cardinality: 22,747,907
12 WINDOW SORT Cost: 22,275,300 Bytes: 841,672,559 Cardinality: 22,747,907
11 TABLE ACCESS BY INDEX ROWID TABLE EMPLOYEE_INFO Cost: 22,137,046 Bytes: 841,672,559 Cardinality: 22,747,907
10 INDEX RANGE SCAN INDEX EMPLOYEE_INFO_INDEX_ON_SITE Cost: 50,419 Cardinality: 38,019,281
32 VIEW DONBOT_DBA
31 UNION-ALL
15 FAST DUAL Cost: 2 Cardinality: 1
16 FAST DUAL Cost: 2 Cardinality: 1
17 FAST DUAL Cost: 2 Cardinality: 1
18 FAST DUAL Cost: 2 Cardinality: 1
19 FAST DUAL Cost: 2 Cardinality: 1
20 FAST DUAL Cost: 2 Cardinality: 1
21 FAST DUAL Cost: 2 Cardinality: 1
22 FAST DUAL Cost: 2 Cardinality: 1
23 FAST DUAL Cost: 2 Cardinality: 1
24 FAST DUAL Cost: 2 Cardinality: 1
25 FAST DUAL Cost: 2 Cardinality: 1
26 FAST DUAL Cost: 2 Cardinality: 1
27 FAST DUAL Cost: 2 Cardinality: 1
28 FAST DUAL Cost: 2 Cardinality: 1
29 FAST DUAL Cost: 2 Cardinality: 1
30 FAST DUAL Cost: 2 Cardinality: 1 Next, one with the parallel hint:
INSERT STATEMENT ALL_ROWS Cost: 26,507,111 Bytes: 114 Cardinality: 1
51 LOAD AS SELECT EMPLOYEES_BY_AGE_GROUP
50 PX COORDINATOR
49 PX SEND QC (RANDOM) PARALLEL_TO_SERIAL SYS.:TQ10005 :Q1005 Cost: 26,507,111 Bytes: 114 Cardinality: 1
48 HASH GROUP BY PARALLEL_COMBINED_WITH_PARENT :Q1005 Cost: 26,507,111 Bytes: 114 Cardinality: 1
47 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT :Q1005 Cost: 26,507,111 Bytes: 114 Cardinality: 1
46 PX SEND HASH PARALLEL_TO_PARALLEL SYS.:TQ10004 :Q1004 Cost: 26,507,111 Bytes: 114 Cardinality: 1
45 HASH GROUP BY PARALLEL_COMBINED_WITH_PARENT :Q1004 Cost: 26,507,111 Bytes: 114 Cardinality: 1
44 NESTED LOOPS PARALLEL_COMBINED_WITH_PARENT :Q1004 Cost: 26,507,111 Bytes: 114 Cardinality: 1
25 HASH JOIN PARALLEL_COMBINED_WITH_PARENT :Q1004 Cost: 26,507,109 Bytes: 108 Cardinality: 1
17 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT :Q1004 Cost: 4,301,500 Bytes: 4,104 Cardinality: 72
16 PX SEND HASH PARALLEL_TO_PARALLEL SYS.:TQ10003 :Q1003 Cost: 4,301,500 Bytes: 4,104 Cardinality: 72
15 HASH JOIN PARALLEL_COMBINED_WITH_PARENT :Q1003 Cost: 4,301,500 Bytes: 4,104 Cardinality: 72
7 BUFFER SORT PARALLEL_COMBINED_WITH_CHILD :Q1003
6 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT :Q1003 Cost: 4,293,939 Bytes: 1,809 Cardinality: 67
5 PX SEND BROADCAST PARALLEL_FROM_SERIAL SYS.:TQ10000 Cost: 4,293,939 Bytes: 1,809 Cardinality: 67
4 VIEW DONBOT_DBA. Cost: 4,293,939 Bytes: 1,809 Cardinality: 67
3 SORT GROUP BY Cost: 4,293,939 Bytes: 2,077 Cardinality: 67
2 TABLE ACCESS BY INDEX ROWID TABLE PAY_INFO Cost: 4,293,938 Bytes: 2,077 Cardinality: 67
1 INDEX RANGE SCAN INDEX PAY_INFO_INDEX_ON_SITE Cost: 487,124 Cardinality: 199,756,151
14 VIEW PARALLEL_COMBINED_WITH_PARENT DONBOT_DBA. :Q1003 Cost: 7,561 Bytes: 29,625,180 Cardinality: 987,506
13 WINDOW SORT PUSHED RANK PARALLEL_COMBINED_WITH_PARENT :Q1003 Cost: 7,561 Bytes: 35,550,216 Cardinality: 987,506
12 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT :Q1003 Cost: 7,561 Bytes: 35,550,216 Cardinality: 987,506
11 PX SEND HASH PARALLEL_TO_PARALLEL SYS.:TQ10002 :Q1002 Cost: 7,561 Bytes: 35,550,216 Cardinality: 987,506
10 WINDOW CHILD PUSHED RANK PARALLEL_COMBINED_WITH_PARENT :Q1002 Cost: 7,561 Bytes: 35,550,216 Cardinality: 987,506
9 PX BLOCK ITERATOR PARALLEL_COMBINED_WITH_CHILD :Q1002 Cost: 7,557 Bytes: 35,550,216 Cardinality: 987,506
8 TABLE ACCESS FULL TABLE PARALLEL_COMBINED_WITH_PARENT EMPLOYEE_BIRTHDATES :Q1002 Cost: 7,557 Bytes: 35,550,216 Cardinality: 987,506
24 BUFFER SORT PARALLEL_COMBINED_WITH_CHILD :Q1004
23 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT :Q1004 Cost: 22,205,605 Bytes: 575,504,145 Cardinality: 11,284,395
22 PX SEND HASH PARALLEL_FROM_SERIAL SYS.:TQ10001 Cost: 22,205,605 Bytes: 575,504,145 Cardinality: 11,284,395
21 VIEW DONBOT_DBA. Cost: 22,205,605 Bytes: 575,504,145 Cardinality: 11,284,395
20 WINDOW SORT Cost: 22,205,605 Bytes: 417,522,615 Cardinality: 11,284,395
19 TABLE ACCESS BY INDEX ROWID TABLE EMPLOYEE_INFO Cost: 22,137,046 Bytes: 417,522,615 Cardinality: 11,284,395
18 INDEX RANGE SCAN INDEX EMPLOYEE_INFO_INDEX_ON_SITE Cost: 50,419 Cardinality: 18,859,958
43 VIEW PARALLEL_COMBINED_WITH_PARENT DONBOT_DBA. :Q1004 Cost: 32 Bytes: 6 Cardinality: 1
42 UNION-ALL PARALLEL_COMBINED_WITH_PARENT :Q1004
26 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004 Cost: 2 Cardinality: 1
27 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004 Cost: 2 Cardinality: 1
28 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004 Cost: 2 Cardinality: 1
29 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004 Cost: 2 Cardinality: 1
30 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004 Cost: 2 Cardinality: 1
31 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004 Cost: 2 Cardinality: 1
32 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004 Cost: 2 Cardinality: 1
33 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004 Cost: 2 Cardinality: 1
34 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004 Cost: 2 Cardinality: 1
35 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004 Cost: 2 Cardinality: 1
36 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004 Cost: 2 Cardinality: 1
37 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004 Cost: 2 Cardinality: 1
38 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004 Cost: 2 Cardinality: 1
39 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004 Cost: 2 Cardinality: 1
40 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004 Cost: 2 Cardinality: 1
41 FAST DUAL PARALLEL_COMBINED_WITH_PARENT :Q1004 Cost: 2 Cardinality: 1 Finally, one without the parallel hint, and without the index hint on PAY_TABLE:
INSERT STATEMENT ALL_ROWS Cost: 23,348,654 Bytes: 114 Cardinality: 1
34 LOAD AS SELECT ARMYMP.EMPLOYEES_BY_AGE
33 HASH GROUP BY Cost: 23,348,654 Bytes: 114 Cardinality: 1
32 NESTED LOOPS Cost: 23,348,653 Bytes: 114 Cardinality: 1
13 HASH JOIN Cost: 23,348,621 Bytes: 108 Cardinality: 1
8 MERGE JOIN Cost: 1,073,202 Bytes: 8,322 Cardinality: 146
3 VIEW DONBOT_DBA. Cost: 114,863 Bytes: 29,625,180 Cardinality: 987,506
2 WINDOW SORT PUSHED RANK Cost: 114,863 Bytes: 35,550,216 Cardinality: 987,506
1 TABLE ACCESS FULL TABLE EMPLOYEE_BIRTHDATES Cost: 108,983 Bytes: 35,550,216 Cardinality: 987,506
7 SORT JOIN Cost: 958,339 Bytes: 3,645 Cardinality: 135
6 VIEW DONBOT_DBA. Cost: 958,338 Bytes: 3,645 Cardinality: 135
5 SORT GROUP BY Cost: 958,338 Bytes: 4,185 Cardinality: 135
4 TABLE ACCESS FULL TABLE PAY_INFO Cost: 958,337 Bytes: 4,185 Cardinality: 135
12 VIEW DONBOT_DBA. Cost: 22,275,300 Bytes: 1,160,143,257 Cardinality: 22,747,907
11 WINDOW SORT Cost: 22,275,300 Bytes: 841,672,559 Cardinality: 22,747,907
10 TABLE ACCESS BY INDEX ROWID TABLE EMPLOYEE_INFO Cost: 22,137,046 Bytes: 841,672,559 Cardinality: 22,747,907
9 INDEX RANGE SCAN INDEX EMPLOYEE_INFO_UIC Cost: 50,419 Cardinality: 38,019,281
31 VIEW DONBOT_DBA. Cost: 32 Bytes: 6 Cardinality: 1
30 UNION-ALL
14 FAST DUAL Cost: 2 Cardinality: 1
15 FAST DUAL Cost: 2 Cardinality: 1
16 FAST DUAL Cost: 2 Cardinality: 1
17 FAST DUAL Cost: 2 Cardinality: 1
18 FAST DUAL Cost: 2 Cardinality: 1
19 FAST DUAL Cost: 2 Cardinality: 1
20 FAST DUAL Cost: 2 Cardinality: 1
21 FAST DUAL Cost: 2 Cardinality: 1
22 FAST DUAL Cost: 2 Cardinality: 1
23 FAST DUAL Cost: 2 Cardinality: 1
24 FAST DUAL Cost: 2 Cardinality: 1
25 FAST DUAL Cost: 2 Cardinality: 1
26 FAST DUAL Cost: 2 Cardinality: 1
27 FAST DUAL Cost: 2 Cardinality: 1
28 FAST DUAL Cost: 2 Cardinality: 1
29 FAST DUAL Cost: 2 Cardinality: 1 I am surprised the cost without the index is less than the cost with it, considering that it is replacing a Table Access By Index Rowid with a Table Access Full on a table with 1 billion (1000 million) records.
Igor - two questions:
One - I cannot find "Materialize" in the hints in the SQL Reference anywhere. What does it do?
Two - does replacing subqueries with With clauses make that much of a difference? -
SQL Query running really slow, any help in improving will be Great!
Hi,
I am really new to this performance tuning and optimization techniques. Explain plan also, I only have theoretical knowledge, no clues on how to find out the real issue which is making the query slow..So if anyone can give me a good direction on where to start even, it will be great..
Now, my issue is, I have a query which runs really really slow. If I run this query for a small subset of data, it runs fast(Its flying, actually..) but if I give the same query for everything(Full required data), its running for ages..(Actually it is running for 2 days now and still running.)
I am pasting my query here, the output shows that the query stucks after "Table created"
SQL> @routinginfo
Table dropped.
Table created.
Please please help!
I also ran explain plan for this query and there are a number of rows in the plan_table now..
SORRY!IS there a way to insert a file here, as I want to attach my explain plan also?
My query -Routinginfo.sql
set trimspool on
set heading on
set verify on
set serveroutput on
drop table routinginfo;
CREATE TABLE routinginfo
( POST_TOWN_NAME VARCHAR2(22 BYTE),
DELIVERY_OFFICE_NAME VARCHAR2(40 BYTE),
ROUTE_ID NUMBER(10),
ROUTE_NAME VARCHAR2(40 BYTE),
BUILDING_ID NUMBER(10),
SUB_BUILDING_ID NUMBER(10),
SEQUENCE_NO NUMBER(4),
PERSONAL_NAME VARCHAR2(60 BYTE),
ADDRESS VARCHAR2(1004 BYTE),
BUILDING_USE VARCHAR2(1 BYTE),
COMMENTS VARCHAR2(200 BYTE),
EAST NUMBER(17,5),
NORTH NUMBER(17,5)
insert into routinginfo
(post_town_name,delivery_office_name,route_id,route_name,
building_id,sub_building_id,sequence_no,personal_name,
address,building_use,comments,east,north)
select
p.name,
d.name,
b.route_id,
r.name,
b.building_id,
s.sub_build_id,
b.sequence_no,
b.personal_name,
ad.addr_line_1||' '||ad.addr_line_2||' '||ad.addr_line_3||' '||ad.addr_line_4||' '||ad.addr_line_5,
b.building_use,
rtrim(replace(b.comments,chr(10),'')),
b.east,
b.north
from t_buildings b,
(select * from t_sub_buildings where nvl(invalid,'N') = 'N') s,
t_routes r,
t_delivery_offices d,
t_post_towns p,
t_address_model ad
where b.building_id = s.building_id(+)
and s.building_id is null
and r.route_id=b.route_id
and (nvl(b.residential_delivery_points,0) > 0 OR nvl(b.commercial_delivery_points,0) > 0)
and r.delivery_office_id=d.delivery_office_id
--and r.delivery_office_id=303
and D.POST_TOWN_ID=P.post_town_id
and ad.building_id=b.building_id
and ad.sub_building_id is null
and nvl(b.invalid, 'N') = 'N'
and nvl(b.derelict, 'N') = 'N'
union
select
p.name,
d.name ,
b.route_id ,
r.name ,
b.building_id ,
s.sub_build_id ,
NVL(s.sequence_no,b.sequence_no),
b.personal_name ,
ad.addr_line_1||' '||ad.addr_line_2||' '||ad.addr_line_3||' '||ad.addr_line_4||' '||ad.addr_line_5,
b.building_use,
rtrim(replace(b.comments,chr(10),'')),
b.east,
b.north
from t_buildings b,
(select * from t_sub_buildings where nvl(invalid,'N') = 'N') s,
t_routes r,
t_delivery_offices d,
t_post_towns p,
t_address_model ad
where s.building_id = b.building_id
and r.route_id = s.route_id
and (nvl(b.residential_delivery_points,0) > 0 OR nvl(b.commercial_delivery_points,0) > 0)
and r.delivery_office_id=d.delivery_office_id
--and r.delivery_office_id=303
and D.POST_TOWN_ID=P.post_town_id
and ad.building_id=b.building_id
and ad.sub_building_id = s.sub_build_id
and nvl(b.invalid, 'N') = 'N'
and nvl(b.derelict, 'N') = 'N'
union
select
p.name,
d.name,
b.route_id ,
r.name ,
b.building_id,
s.sub_build_id ,
NVL(s.sequence_no,b.sequence_no) ,
b.personal_name ,
ad.addr_line_1||' '||ad.addr_line_2||' '||ad.addr_line_3||' '||ad.addr_line_4||' '||ad.addr_line_5 ,
b.building_use,
rtrim(replace(b.comments,chr(10),'')),
b.east,
b.north
from t_buildings b,
(select * from t_sub_buildings where nvl(invalid,'N') = 'N') s,
t_routes r,
t_delivery_offices d,
t_post_towns p,
t_localities l,
t_localities lo,
t_localities loc,
t_tlands tl,
t_address_model ad
where s.building_id = b.building_id
and s.route_id is null
and r.route_id = b.route_id
and (nvl(b.residential_delivery_points,0) > 0 OR nvl(b.commercial_delivery_points,0) > 0)
and r.delivery_office_id=d.delivery_office_id
--and r.delivery_office_id=303
and D.POST_TOWN_ID=P.post_town_id
and ad.building_id=b.building_id
and ad.sub_building_id = s.sub_build_id
and nvl(b.invalid, 'N') = 'N'
and nvl(b.derelict, 'N') = 'N';
commit; Edited by: Krithi on 16-Jun-2009 01:48
Edited by: Krithi on 16-Jun-2009 01:51
Edited by: Krithi on 16-Jun-2009 02:44This link is helpful alright..but as a beginner, it is taking me too long to understand..But I am going to learn the techniques for sure..
Fo the time being,I am pasting my explain plan for the above query here, so that I hope any expert can really help me on this one..
STATEMENT_ID TIMESTAMP REMARKS OPERATION OPTIONS OBJECT_NODE OBJECT_OWNER OBJECT_NAME OBJECT_INSTANCE OBJECT_TYPE OPTIMIZER SEARCH_COLUMNS ID PARENT_ID POSITION COST CARDINALITY BYTES
06/16/2009 09:33:01 SELECT STATEMENT CHOOSE 0 829,387,159,200 829,387,159,200 3,720,524,291,654,720 703,179,091,122,042,000
06/16/2009 09:33:01 SORT UNIQUE 1 0 1 829,387,159,200 3,720,524,291,654,720 703,179,091,122,042,000
06/16/2009 09:33:01 UNION-ALL 2 1 1
06/16/2009 09:33:01 HASH JOIN 3 2 1 11,209 87,591 15,853,971
06/16/2009 09:33:01 FILTER 4 3 1
06/16/2009 09:33:01 HASH JOIN OUTER 5 4 1
06/16/2009 09:33:01 HASH JOIN 6 5 1 5,299 59,325 6,585,075
06/16/2009 09:33:01 VIEW GEO2 index$_join$_006 6 7 6 1 4 128 1,792
06/16/2009 09:33:01 HASH JOIN 8 7 1 5,299 59,325 6,585,075
06/16/2009 09:33:01 INDEX FAST FULL SCAN GEO2 POST_TOWN_NAME_I NON-UNIQUE ANALYZED 9 8 1 1 128 1,792
06/16/2009 09:33:01 INDEX FAST FULL SCAN GEO2 POST_TOWN_PK UNIQUE ANALYZED 10 8 2 1 128 1,792
06/16/2009 09:33:01 HASH JOIN 11 6 2 5,294 59,325 5,754,525
06/16/2009 09:33:01 TABLE ACCESS FULL GEO2 T_DELIVERY_OFFICES 5 ANALYZED 12 11 1 7 586 10,548
06/16/2009 09:33:01 HASH JOIN 13 11 2 5,284 59,325 4,686,675
06/16/2009 09:33:01 TABLE ACCESS FULL GEO2 T_ROUTES 4 ANALYZED 14 13 1 7 4,247 118,916
06/16/2009 09:33:01 TABLE ACCESS FULL GEO2 T_BUILDINGS 1 ANALYZED 15 13 2 5,265 59,408 3,029,808
06/16/2009 09:33:01 TABLE ACCESS FULL GEO2 T_SUB_BUILDINGS 3 ANALYZED 16 5 2 851 278,442 3,898,188
06/16/2009 09:33:01 TABLE ACCESS FULL GEO2 T_ADDRESS_MODEL 7 ANALYZED 17 3 2 3,034 1,582,421 88,615,576
06/16/2009 09:33:01 NESTED LOOPS 18 2 2 10,217 1 189
06/16/2009 09:33:01 NESTED LOOPS 19 18 1 10,216 1 175
06/16/2009 09:33:01 HASH JOIN 20 19 1 10,215 1 157
06/16/2009 09:33:01 HASH JOIN 21 20 1 6,467 80,873 8,168,173
06/16/2009 09:33:01 TABLE ACCESS FULL GEO2 T_ROUTES 11 ANALYZED 22 21 1 7 4,247 118,916
06/16/2009 09:33:01 HASH JOIN 23 21 2 6,440 80,924 5,907,452
06/16/2009 09:33:01 TABLE ACCESS FULL GEO2 T_BUILDINGS 8 ANALYZED 24 23 1 5,265 59,408 3,029,808
06/16/2009 09:33:01 TABLE ACCESS FULL GEO2 T_SUB_BUILDINGS 10 ANALYZED 25 23 2 851 278,442 6,125,724
06/16/2009 09:33:01 TABLE ACCESS FULL GEO2 T_ADDRESS_MODEL 14 ANALYZED 26 20 2 3,034 556,000 31,136,000
06/16/2009 09:33:01 TABLE ACCESS BY INDEX ROWID GEO2 T_DELIVERY_OFFICES 12 ANALYZED 27 19 2 1 1 18
06/16/2009 09:33:01 INDEX UNIQUE SCAN GEO2 DELIVERY_OFFICE_PK UNIQUE ANALYZED 1 28 27 1 1
06/16/2009 09:33:01 TABLE ACCESS BY INDEX ROWID GEO2 T_POST_TOWNS 13 ANALYZED 29 18 2 1 1 14
06/16/2009 09:33:01 INDEX UNIQUE SCAN GEO2 POST_TOWN_PK UNIQUE ANALYZED 1 30 29 1 1
06/16/2009 09:33:01 MERGE JOIN CARTESIAN 31 2 3 806,976,583,802 3,720,524,291,567,130 703,179,091,106,188,000
06/16/2009 09:33:01 MERGE JOIN CARTESIAN 32 31 1 16,902,296 73,359,971,046 13,865,034,527,694
06/16/2009 09:33:01 MERGE JOIN CARTESIAN 33 32 1 1,860 1,207,174 228,155,886
06/16/2009 09:33:01 MERGE JOIN CARTESIAN 34 33 1 1,580 20 3,780
06/16/2009 09:33:01 NESTED LOOPS 35 34 1 1,566 1 189
06/16/2009 09:33:01 NESTED LOOPS 36 35 1 1,565 1 175
06/16/2009 09:33:01 NESTED LOOPS 37 36 1 1,564 1 157
06/16/2009 09:33:01 NESTED LOOPS 38 37 1 1,563 1 129
06/16/2009 09:33:01 NESTED LOOPS 39 38 1 1,207 178 12,994
06/16/2009 09:33:01 TABLE ACCESS FULL GEO2 T_SUB_BUILDINGS 17 ANALYZED 40 39 1 851 178 3,916
06/16/2009 09:33:01 TABLE ACCESS BY INDEX ROWID GEO2 T_BUILDINGS 15 ANALYZED 41 39 2 2 1 51
06/16/2009 09:33:01 INDEX UNIQUE SCAN GEO2 BUILDING_PK UNIQUE ANALYZED 1 42 41 1 1 31
06/16/2009 09:33:01 TABLE ACCESS BY INDEX ROWID GEO2 T_ADDRESS_MODEL 25 ANALYZED 43 38 2 2 1 56
06/16/2009 09:33:01 INDEX UNIQUE SCAN GEO2 MODEL_MODEL2_UK UNIQUE ANALYZED 2 44 43 1 1 1
06/16/2009 09:33:01 TABLE ACCESS BY INDEX ROWID GEO2 T_ROUTES 18 ANALYZED 45 37 2 1 1 28
06/16/2009 09:33:01 INDEX UNIQUE SCAN GEO2 ROUTE_PK UNIQUE ANALYZED 1 46 45 1 1
06/16/2009 09:33:01 TABLE ACCESS BY INDEX ROWID GEO2 T_DELIVERY_OFFICES 19 ANALYZED 47 36 2 1 1 18
06/16/2009 09:33:01 INDEX UNIQUE SCAN GEO2 DELIVERY_OFFICE_PK UNIQUE ANALYZED 1 48 47 1 1
06/16/2009 09:33:01 TABLE ACCESS BY INDEX ROWID GEO2 T_POST_TOWNS 20 ANALYZED 49 35 2 1 1 14
06/16/2009 09:33:01 INDEX UNIQUE SCAN GEO2 POST_TOWN_PK UNIQUE ANALYZED 1 50 49 1 1
06/16/2009 09:33:01 BUFFER SORT 51 34 2 1,579 60,770
06/16/2009 09:33:01 INDEX FAST FULL SCAN GEO2 LOCAL_COUNTY_FK_I NON-UNIQUE ANALYZED 52 51 1 14 60,770
06/16/2009 09:33:01 BUFFER SORT 53 33 2 1,846 60,770
06/16/2009 09:33:01 INDEX FAST FULL SCAN GEO2 LOCAL_COUNTY_FK_I NON-UNIQUE ANALYZED 54 53 1 14 60,770
06/16/2009 09:33:01 BUFFER SORT 55 32 2 16,902,282 60,770
06/16/2009 09:33:01 INDEX FAST FULL SCAN GEO2 LOCAL_COUNTY_FK_I NON-UNIQUE ANALYZED 56 55 1 14 60,770
06/16/2009 09:33:01 BUFFER SORT 57 31 2 806,976,583,788 50,716
06/16/2009 09:33:01 INDEX FAST FULL SCAN GEO2 TLAND_COUNTY_FK_I NON-UNIQUE ANALYZED 58 57 1 11 50,716 -------------------------------------------------------------
Edited by: Krithi on 16-Jun-2009 02:47 -
MS-Access query running very slow
Hi,
We've MS-Access application which was pointing to UDB. Now we migrated it to point Oracle DB 9.2. After migration some of the query is running very slow.
These queries used to take less than 30 seconds in UDB now taking more than 5 Minutes in Oracle.
some more obeservation :
(1) Some of the queries using "HAVING" clause without any aggregate function. When I moved this condition to "WHERE" clause, performance improved a lot.
But problem is that I can't suggest this solution to "USERS". They are creating query using "query wizard" in MS-Access and they started creating noise on this.
(2) I tested same MDB in two different PCs and same query is returning records in 4 seconds in one system, is taking more than 10 minutes in other system.
Since I'm new to MS-Access, I don't know what other information I need to provide here.
Please help me out.I have seen the problem like this,too
can i have you -
Hi All,
I am sitting on 10.2.0.4.0 on linux box. I've got one complain from the application folks regarding the query the slow query , it's running quite long time. I extracted out the explain plan and commulative wait events for sessions and system and found db file sequenciial read caused us the most waits. the same query was running fine a day before. not sure , where to focus ??
++ Query ++
SELECT A.ITEM, A.LOC, MAX(CO1.AFFBILLPR) AFFBILLPR, MAX(CO1.UNIT_COST) UNIT_COST FROM INVOPT_STG.TMP_COST_OCS CO1,
(SELECT SS.LOC, SS.MANUF_LOC, SS.ITEM, MAX(CO.ITEM_10D) ITEM_10D, COUNTRY_CD FROM INVOPT_STG.STG_LOC SL, TMP_COST_OCS CO, STG_SKU SS WHERE
CASE WHEN SL.COUNTRY_CD_COST = CO.COUNTRY_CD THEN SL.COUNTRY_CD_COST
WHEN SL.COUNTRY_CD_COST != NVL((SELECT DISTINCT CO3.COUNTRY_CD FROM INVOPT_STG.TMP_COST_OCS
CO3 WHERE CO3.ITEM_10D = CO.ITEM_10D AND CO3.FYEAR = CO.FYEAR AND CO3.COUNTRY_CD = SL.COUNTRY_CD_COST),' ')
AND SL.COUNTRY_CD_COST= 'US' THEN 'CAN' WHEN SL.COUNTRY_CD_COST != NVL((SELECT DISTINCT CO3.COUNTRY_CD
FROM INVOPT_STG.TMP_COST_OCS CO3 WHERE CO3.ITEM_10D = CO.
ITEM_10D AND CO3.FYEAR = CO.FYEAR AND CO3.COUNTRY_CD = SL.COUNTRY_CD_COST),' ')
AND SL.COUNTRY_CD_COST = 'CAN' THEN 'US' ELSE SL.COUNTRY_CD_COST END = CO.COUNTRY_CD AND CO.COST_TYPE IN ('F') AND CO.ITEM_10D !=
SS.ITEM_10D AND CO.ITEM_10D < SS.ITEM_10D AND
SUBSTR(CO.ITEM_10D,1,9) = SUBSTR(SS.ITEM_10D,1,9)
AND SUBSTR(SL.LOC,1,3) = SS.MANUF_LOC GROUP BY SS.LOC, SS.MANUF_LOC, SS.ITEM,
CO.COUNTRY_CD) A WHERE CO1.ITEM_10D = A.ITEM_10D AND CO1.FYEAR =
(SELECT MAX(CO2.FYEAR) FROM INVOPT_STG.TMP_COST_OCS CO2 WHERE CO2.ITEM_10D
= A.ITEM_10D AND CO2.COST_TYPE = 'F' AND CO2.COUNTRY_CD = A.COUNTRY_CD)
AND CO1.COST_TYPE = 'F' AND CO1.COUNTRY_CD = A.COUNTRY_CD GROUP BY A.ITEM, A.LOC
------ Eplain plan generated from shared pool +++++++++++
| Id | Operation | Name | E-Rows | OMem | 1Mem | Used-Mem | Used-Tmp|
| 1 | HASH GROUP BY | | 1 | 11M| 2139K| 3095K (1)| 8192 |
|* 2 | FILTER | | | | | | |
|* 3 | TABLE ACCESS BY INDEX ROWID | TMP_COST_OCS | 1 | | | | |
| 4 | NESTED LOOPS | | 1 | | | | |
| 5 | VIEW | | 1 | | | | |
| 6 | HASH GROUP BY | | 1 | 22M| 4334K| 3898K (1)| 17408 |
|* 7 | FILTER | | | | | | |
|* 8 | TABLE ACCESS BY INDEX ROWID | TMP_COST_OCS | 1 | | | | |
| 9 | NESTED LOOPS | | 1 | | | | |
|* 10 | HASH JOIN | | 1 | 1179K| 1179K| 1210K (0)| |
| 11 | TABLE ACCESS FULL | STG_LOC | 155 | | | | |
| 12 | TABLE ACCESS FULL | STG_SKU | 1738K| | | | |
|* 13 | INDEX RANGE SCAN | TMP_COST_OCS_01 | 1 | | | | |
| 14 | SORT UNIQUE NOSORT | | 1 | | | | |
|* 15 | TABLE ACCESS BY INDEX ROWID | TMP_COST_OCS | 1 | | | | |
|* 16 | INDEX RANGE SCAN | TMP_COST_OCS_01 | 3 | | | | |
| 17 | SORT UNIQUE NOSORT | | 1 | | | | |
|* 18 | TABLE ACCESS BY INDEX ROWID| TMP_COST_OCS | 1 | | | | |
|* 19 | INDEX RANGE SCAN | TMP_COST_OCS_01 | 3 | | | | |
|* 20 | INDEX RANGE SCAN | TMP_COST_OCS_01 | 3 | | | | |
| 21 | SORT AGGREGATE | | 1 | | | | |
|* 22 | TABLE ACCESS BY INDEX ROWID | TMP_COST_OCS | 1 | | | | |
|* 23 | INDEX RANGE SCAN | TMP_COST_OCS_01 | 3 | | | | |
Predicate Information (identified by operation id):
2 - filter("CO1"."FYEAR"=)
3 - filter(("CO1"."COST_TYPE"='F' AND "CO1"."COUNTRY_CD"="A"."COUNTRY_CD"))
7 - filter("CO"."COUNTRY_CD"=CASE WHEN ("SL"."COUNTRY_CD_COST"="CO"."COUNTRY_CD") THEN
"SL"."COUNTRY_CD_COST" WHEN (("SL"."COUNTRY_CD_COST"<>NVL(,' ')) AND ("SL"."COUNTRY_CD_COST"='US'))
THEN 'CAN' WHEN (("SL"."COUNTRY_CD_COST"<>NVL(,' ')) AND ("SL"."COUNTRY_CD_COST"='CAN')) THEN 'US'
ELSE "SL"."COUNTRY_CD_COST" END )
8 - filter("CO"."COST_TYPE"='F')
10 - access("SS"."MANUF_LOC"=SUBSTR("SL"."LOC",1,3))
13 - access("CO"."ITEM_10D"<"SS"."ITEM_10D")
filter(("CO"."ITEM_10D"<>"SS"."ITEM_10D" AND
SUBSTR("CO"."ITEM_10D",1,9)=SUBSTR("SS"."ITEM_10D",1,9)))
15 - filter(("CO3"."COUNTRY_CD"=:B1 AND "CO3"."FYEAR"=:B2))
16 - access("CO3"."ITEM_10D"=:B1)
18 - filter(("CO3"."COUNTRY_CD"=:B1 AND "CO3"."FYEAR"=:B2))
19 - access("CO3"."ITEM_10D"=:B1)
20 - access("CO1"."ITEM_10D"="A"."ITEM_10D")
22 - filter(("CO2"."COUNTRY_CD"=:B1 AND "CO2"."COST_TYPE"='F'))
23 - access("CO2"."ITEM_10D"=:B1)
Note
- Warning: basic plan statistics not available. These are only collected when:
* hint 'gather_plan_statistics' is used for the statement or
* parameter 'statistics_level' is set to 'ALL', at session or system level
+++++ System Waits ++++++++
EVENT TOTAL_WAITS TIME_WAITED AVERAGE_WAIT
db file sequential read 11887758 3643542 .31
jobq slave wait 4434 1297399 292.6
db file scattered read 3821415 615568 .16
log file parallel write 778118 476860 .61
db file parallel write 652969 456530 .7
SQL*Net more data to client 93400714 364435 0
PX Idle Wait 1078 208509 193.42
control file parallel write 141212 62082 .44
log file switch (checkpoint incomplete) 323 22567 69.87
log buffer space 786 10051 12.79
log file sync 17816 7988 .45
db file single write 42869 5994 .14
read by other session 13713 5051 .37
log file switch completion 1125 4963 4.41
db file parallel read 756 3951 5.23
Data file init write 18444 3569 .19
cursor: pin S wait on X 3280 3409 1.04
os thread startup 452 2250 4.98
direct path read 4438445 1629 0
SQL*Net more data from client 73118 1613 .02
control file sequential read 291106 1523 .01
local write wait 4707 1169 .25
latch: shared pool 166 954 5.75
direct path read temp 4657234 921 0
library cache load lock 313 753 2.41
enq: KO - fast object checkpoint 5286 734 .14
PL/SQL lock timer 7 682 97.43
latch: library cache 501 614 1.23
+++ commulative events for session +++
EVENT TOTAL_WAITS TIME_WAITED AVERAGE_WAIT
db file sequential read 6224 1978 .32
SQL*Net message from client 20 2 .09
SQL*Net message to client 20 0 0
log file sync 1 0 .17Edited by: user11983993 on May 18, 2012 11:12 AMAll,
Thanks all of you for your inputs. Well, 2 days back, i logged in as a user , who ran the application query and enabled the level 12 trace and discovered the query never going to complete and press the control-c after 10 min or so and I was left with broken trace file. however , I tkprof'd it and found the "Row Source Operation" and other stuff. now , when I ran the same query it ran in no time and I was start getting the rows in 15 sec of time. I was just unable to figure out ,what had fixed this ? I am also going to past below the comparison stats and hope you guys will able to identify the cause of this behaviour. I tried to do it by comparing the execution plan , but could not able to arrive on any thought. one thing , i would like you to bring into your notice about the fact that while , the bad query were executing (2 days before) , I tried to find out the session waits and discovered , for intiial 5 minutes , it was "SQL*Net message to client ,SQL*Net message from client" and after that it was only "cache buffer chain lru" wait event till i press control-c.
once agian , thanks a lot !!
---bad query explian plan ----
| Id | Operation | Name | E-Rows | OMem | 1Mem | Used-Mem | Used-Tmp|
| 1 | HASH GROUP BY | | 1 | 11M| 2139K| 3095K (1)| 8192 |
|* 2 | FILTER | | | | | | |
|* 3 | TABLE ACCESS BY INDEX ROWID | TMP_COST_OCS | 1 | | | | |
| 4 | NESTED LOOPS | | 1 | | | | |
| 5 | VIEW | | 1 | | | | |
| 6 | HASH GROUP BY | | 1 | 22M| 4334K| 3898K (1)| 17408 |
|* 7 | FILTER | | | | | | |
|* 8 | TABLE ACCESS BY INDEX ROWID | TMP_COST_OCS | 1 | | | | |
| 9 | NESTED LOOPS | | 1 | | | | |
|* 10 | HASH JOIN | | 1 | 1179K| 1179K| 1210K (0)| |
| 11 | TABLE ACCESS FULL | STG_LOC | 155 | | | | |
| 12 | TABLE ACCESS FULL | STG_SKU | 1738K| | | | |
|* 13 | INDEX RANGE SCAN | TMP_COST_OCS_01 | 1 | | | | |
| 14 | SORT UNIQUE NOSORT | | 1 | | | | |
|* 15 | TABLE ACCESS BY INDEX ROWID | TMP_COST_OCS | 1 | | | | |
|* 16 | INDEX RANGE SCAN | TMP_COST_OCS_01 | 3 | | | | |
| 17 | SORT UNIQUE NOSORT | | 1 | | | | |
|* 18 | TABLE ACCESS BY INDEX ROWID| TMP_COST_OCS | 1 | | | | |
|* 19 | INDEX RANGE SCAN | TMP_COST_OCS_01 | 3 | | | | |
|* 20 | INDEX RANGE SCAN | TMP_COST_OCS_01 | 3 | | | | |
| 21 | SORT AGGREGATE | | 1 | | | | |
|* 22 | TABLE ACCESS BY INDEX ROWID | TMP_COST_OCS | 1 | | | | |
|* 23 | INDEX RANGE SCAN | TMP_COST_OCS_01 | 3 | | | | |
---- good query explain plan ------
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 5451K| 493M| | 632K (6)| 02:06:27 |
| 1 | HASH GROUP BY | | 5451K| 493M| 1183M| 632K (6)| 02:06:27 |
|* 2 | HASH JOIN | | 5451K| 493M| 26M| 512K (7)| 01:42:36 |
|* 3 | TABLE ACCESS FULL | TMP_COST_OCS | 649K| 18M| | 779 (4)| 00:00:10 |
|* 4 | HASH JOIN | | 16M| 1037M| 24M| 449K (8)| 01:29:55 |
| 5 | VIEW | VW_SQ_1 | 649K| 17M| | 6865 (2)| 00:01:23 |
| 6 | HASH GROUP BY | | 649K| 21M| 64M| 6865 (2)| 00:01:23 |
|* 7 | TABLE ACCESS FULL | TMP_COST_OCS | 649K| 21M| | 779 (4)| 00:00:10 |
| 8 | VIEW | | 27M| 974M| | 376K (9)| 01:15:22 |
| 9 | HASH GROUP BY | | 27M| 1290M| 3397M| 376K (9)| 01:15:22 |
|* 10 | FILTER | | | | | | |
|* 11 | HASH JOIN | | 27M| 1290M| 14M| 38992 (71)| 00:07:48 |
|* 12 | HASH JOIN | | 361K| 9M| | 9151 (3)| 00:01:50 |
| 13 | TABLE ACCESS FULL | STG_LOC | 155 | 1085 | | 3 (0)| 00:00:01 |
| 14 | TABLE ACCESS FULL | STG_SKU | 1738K| 36M| | 9127 (3)| 00:01:50 |
|* 15 | TABLE ACCESS FULL | TMP_COST_OCS | 649K| 12M| | 779 (4)| 00:00:10 |
| 16 | SORT UNIQUE NOSORT | | 1 | 18 | | 2 (50)| 00:00:01 |
|* 17 | TABLE ACCESS BY INDEX ROWID | TMP_COST_OCS | 1 | 18 | | 1 (0)| 00:00:01 |
|* 18 | INDEX RANGE SCAN | TMP_COST_OCS_01 | 3 | | | 1 (0)| 00:00:01 |
| 19 | SORT UNIQUE NOSORT | | 1 | 18 | | 2 (50)| 00:00:01 |
|* 20 | TABLE ACCESS BY INDEX ROWID| TMP_COST_OCS | 1 | 18 | | 1 (0)| 00:00:01 |
|* 21 | INDEX RANGE SCAN | TMP_COST_OCS_01 | 3 | | | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - access("CO1"."ITEM_10D"="A"."ITEM_10D" AND "CO1"."FYEAR"="VW_COL_1" AND
"CO1"."COUNTRY_CD"="A"."COUNTRY_CD")
3 - filter("CO1"."COST_TYPE"='F')
4 - access("ITEM_10D"="A"."ITEM_10D" AND "COUNTRY_CD"="A"."COUNTRY_CD")
7 - filter("CO2"."COST_TYPE"='F')
10 - filter("CO"."COUNTRY_CD"=CASE WHEN ("SL"."COUNTRY_CD_COST"="CO"."COUNTRY_CD") THEN
"SL"."COUNTRY_CD_COST" WHEN (("SL"."COUNTRY_CD_COST"<>NVL( (SELECT DISTINCT "CO3"."COUNTRY_CD" FROM
"INVOPT_STG"."TMP_COST_OCS" "CO3" WHERE "CO3"."ITEM_10D"=:B1 AND "CO3"."COUNTRY_CD"=:B2 AND
"CO3"."FYEAR"=:B3),' ')) AND ("SL"."COUNTRY_CD_COST"='US')) THEN 'CAN' WHEN
(("SL"."COUNTRY_CD_COST"<>NVL( (SELECT DISTINCT "CO3"."COUNTRY_CD" FROM "INVOPT_STG"."TMP_COST_OCS"
"CO3" WHERE "CO3"."ITEM_10D"=:B4 AND "CO3"."COUNTRY_CD"=:B5 AND "CO3"."FYEAR"=:B6),' ')) AND
("SL"."COUNTRY_CD_COST"='CAN')) THEN 'US' ELSE "SL"."COUNTRY_CD_COST" END )
11 - access(SUBSTR("CO"."ITEM_10D",1,9)=SUBSTR("SS"."ITEM_10D",1,9))
filter("CO"."ITEM_10D"<>"SS"."ITEM_10D" AND "CO"."ITEM_10D"<"SS"."ITEM_10D")
12 - access("SS"."MANUF_LOC"=SUBSTR("SL"."LOC",1,3))
15 - filter("CO"."COST_TYPE"='F')
17 - filter("CO3"."COUNTRY_CD"=:B1 AND "CO3"."FYEAR"=:B2)
18 - access("CO3"."ITEM_10D"=:B1)
20 - filter("CO3"."COUNTRY_CD"=:B1 AND "CO3"."FYEAR"=:B2)
21 - access("CO3"."ITEM_10D"=:B1)
-------- bad query's tkprof stuff , which was cancel in the middle of query execution ++++
call count cpu elapsed disk query current rows
Parse 1 0.00 0.01 0 0 0 0
Execute 1 0.00 0.01 0 0 0 0
Fetch 1 2996.84 2926.75 0 38309573 0 0
total 3 2996.85 2926.78 0 38309573 0 0
Misses in library cache during parse: 1
Optimizer mode: CHOOSE
Parsing user id: 66
Rows Row Source Operation
0 HASH GROUP BY (cr=0 pr=0 pw=0 time=139 us)
0 FILTER (cr=0 pr=0 pw=0 time=86 us)
0 TABLE ACCESS BY INDEX ROWID TMP_COST_OCS (cr=0 pr=0 pw=0 time=77 us)
1 NESTED LOOPS (cr=0 pr=0 pw=0 time=66 us)
0 VIEW (cr=0 pr=0 pw=0 time=59 us)
0 HASH GROUP BY (cr=0 pr=0 pw=0 time=55 us)
38000 FILTER (cr=38309122 pr=0 pw=0 time=2955467939 us)
329898 TABLE ACCESS BY INDEX ROWID TMP_COST_OCS (cr=34815004 pr=0 pw=0 time=3206861519 us)
357855 NESTED LOOPS (cr=34485441 pr=0 pw=0 time=2877866697 us)
27718 HASH JOIN (cr=2390 pr=0 pw=0 time=307908 us)
157 TABLE ACCESS FULL STG_LOC (cr=7 pr=0 pw=0 time=361 us)
85765 TABLE ACCESS FULL STG_SKU (cr=2383 pr=0 pw=0 time=171835 us)
330137 INDEX RANGE SCAN TMP_COST_OCS_01 (cr=34483052 pr=0 pw=0 time=2912095494 us)(object id 306305)
46627 SORT UNIQUE NOSORT (cr=1930740 pr=0 pw=0 time=6990387 us)
46738 TABLE ACCESS BY INDEX ROWID TMP_COST_OCS (cr=1930740 pr=0 pw=0 time=5650002 us)
1538792 INDEX RANGE SCAN TMP_COST_OCS_01 (cr=391948 pr=0 pw=0 time=3003592 us)(object id 306305)
45806 SORT UNIQUE NOSORT (cr=1563378 pr=0 pw=0 time=4985698 us)
45911 TABLE ACCESS BY INDEX ROWID TMP_COST_OCS (cr=1563378 pr=0 pw=0 time=4041604 us)
1245053 INDEX RANGE SCAN TMP_COST_OCS_01 (cr=318325 pr=0 pw=0 time=2173830 us)(object id 306305)
0 INDEX RANGE SCAN TMP_COST_OCS_01 (cr=0 pr=0 pw=0 time=0 us)(object id 306305)
0 SORT AGGREGATE (cr=0 pr=0 pw=0 time=0 us)
0 TABLE ACCESS BY INDEX ROWID TMP_COST_OCS (cr=0 pr=0 pw=0 time=0 us)
0 INDEX RANGE SCAN TMP_COST_OCS_01 (cr=0 pr=0 pw=0 time=0 us)(object id 306305)
+++++ good query's tkprof stuuf ++++
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 7501 15.96 15.85 0 2276084 0 112498
total 7503 15.96 15.85 0 2276084 0 112498
Misses in library cache during parse: 0
Optimizer mode: CHOOSE
Parsing user id: 66
Rows Row Source Operation
112498 HASH GROUP BY (cr=2276084 pr=0 pw=0 time=15772334 us)
116586 HASH JOIN (cr=2276084 pr=0 pw=0 time=16810414 us)
646757 TABLE ACCESS FULL TMP_COST_OCS (cr=3847 pr=0 pw=0 time=646966 us)
116586 HASH JOIN (cr=2272237 pr=0 pw=0 time=15790569 us)
346815 VIEW VW_SQ_1 (cr=3847 pr=0 pw=0 time=1533825 us)
346815 HASH GROUP BY (cr=3847 pr=0 pw=0 time=840189 us)
646757 TABLE ACCESS FULL TMP_COST_OCS (cr=3847 pr=0 pw=0 time=646848 us)
116586 VIEW (cr=2268390 pr=0 pw=0 time=14541517 us)
116586 HASH GROUP BY (cr=2268390 pr=0 pw=0 time=14308341 us)
464160 FILTER (cr=2268390 pr=0 pw=0 time=5393370 us)
3839448 HASH JOIN (cr=49577 pr=0 pw=0 time=8893424 us)
484783 HASH JOIN (cr=45730 pr=0 pw=0 time=1454928 us)
157 TABLE ACCESS FULL STG_LOC (cr=7 pr=0 pw=0 time=217 us)
1738212 TABLE ACCESS FULL STG_SKU (cr=45723 pr=0 pw=0 time=1738234 us)
646757 TABLE ACCESS FULL TMP_COST_OCS (cr=3847 pr=0 pw=0 time=648498 us)
38587 SORT UNIQUE NOSORT (cr=1312207 pr=0 pw=0 time=4759042 us)
38924 TABLE ACCESS BY INDEX ROWID TMP_COST_OCS (cr=1312207 pr=0 pw=0 time=3864377 us)
1017138 INDEX RANGE SCAN TMP_COST_OCS_01 (cr=295069 pr=0 pw=0 time=1974848 us)(object id 306305)
36877 SORT UNIQUE NOSORT (cr=906606 pr=0 pw=0 time=3136870 us)
37214 TABLE ACCESS BY INDEX ROWID TMP_COST_OCS (cr=906606 pr=0 pw=0 time=2506882 us)
701899 INDEX RANGE SCAN TMP_COST_OCS_01 (cr=204707 pr=0 pw=0 time=1305913 us)(object id 306305)
+++++++ -
Dear All,
when I run the below query, it takes around 1 to 2 minutes.
What exact improvement can be made to increase the speed of queries on this table?
SELECT count(*),j.event_year
FROM PRC_EVENTS J
WHERE J.EVENT_TYPE_ID = 63424
AND J.E1 = '3'
and j.event_date between to_date('01-01-2011','dd-mm-rrrr') and to_date('31-12-2011','dd-mm-rrrr')
group by j.event_year;I got Result data as below in 1 or 2 minutes.....
TOTAL_ROWS EVENT_YEAR
2838 2010
33 2009
6 2007
39153 2011
2 2008explain plan for this query is
SQL> SELECT *
2 FROM TABLE(DBMS_XPLAN.DISPLAY);
PLAN_TABLE_OUTPUT
Plan hash value: 3649959670
| Id | Operation | Name | Rows | Bytes | Cost (
| 0 | SELECT STATEMENT | | 16 | 320 | 10546
| 1 | HASH GROUP BY | | 16 | 320 | 10546
|* 2 | TABLE ACCESS BY INDEX ROWID| PRC_EVENTS | 3299 | 65980 | 10545
|* 3 | INDEX SKIP SCAN | PRC_EVENTS_IDX27 | 17006 | | 2404
Predicate Information (identified by operation id):
2 - filter("JUDG"."E1"='3')
3 - access("JUDG"."EVENT_TYPE_ID"=63424 AND "JUDG"."EVENT_DATE">=TO_DATE('201
00:00:00', 'yyyy-mm-dd hh24:mi:ss') AND "JUDG"."EVENT_DATE"<=TO_DA
00:00:00', 'yyyy-mm-dd hh24:mi:ss'))
filter("JUDG"."EVENT_DATE">=TO_DATE('2011-01-01 00:00:00', 'yyyy-mm-dd
hh24:mi:ss') AND "JUDG"."EVENT_DATE"<=TO_DATE('2011-12-31 00:00:00
PLAN_TABLE_OUTPUT
hh24:mi:ss'))
21 rows selectedThe complete structure of prc_events table is as below (showing its indexes, tablespaces,triggers and all its related objects)
CREATE TABLE moj.prc_events
ID NUMBER NOT NULL,
server_id NUMBER(6) NOT NULL,
parent_id NUMBER,
event_type_id NUMBER NOT NULL,
event_year NUMBER(4),
event_no NUMBER(8),
event_date DATE NOT NULL,
hijra_date VARCHAR2(50 BYTE),
security_level_lkp NUMBER,
subject VARCHAR2(4000 BYTE) NOT NULL,
site_id NUMBER NOT NULL,
dn_site_type_id NUMBER NOT NULL,
wrksec_id_created_by NUMBER NOT NULL,
remarks VARCHAR2(1000 BYTE),
signed_onbehalf_prefix VARCHAR2(80 BYTE),
signed_by_prefix VARCHAR2(80 BYTE),
signed_position_desc VARCHAR2(240 BYTE),
signed_by_id NUMBER,
signed_onbehalf_by_id NUMBER,
signed_position_id NUMBER,
certify_date DATE,
certify_user VARCHAR2(30 BYTE),
execution_date DATE,
execution_user VARCHAR2(30 BYTE),
eligibility_check_flag VARCHAR2(1 BYTE) NOT NULL,
eligibility_executed_flag VARCHAR2(1 BYTE) NOT NULL,
flex_ref_no NUMBER,
attachment_link_no NUMBER,
audit_trail_no NUMBER,
created_by VARCHAR2(30 BYTE) NOT NULL,
creation_date DATE NOT NULL,
last_updated_by VARCHAR2(30 BYTE) NOT NULL,
last_update_date DATE NOT NULL,
e1 VARCHAR2(255 BYTE),
e2 VARCHAR2(255 BYTE),
e3 VARCHAR2(255 BYTE),
e4 VARCHAR2(255 BYTE),
e5 VARCHAR2(255 BYTE),
e6 VARCHAR2(255 BYTE),
e7 VARCHAR2(255 BYTE),
e8 VARCHAR2(255 BYTE),
e9 VARCHAR2(255 BYTE),
e10 VARCHAR2(255 BYTE),
e11 VARCHAR2(255 BYTE),
e12 VARCHAR2(255 BYTE),
e13 VARCHAR2(255 BYTE),
e14 VARCHAR2(255 BYTE),
e15 VARCHAR2(255 BYTE),
event_status_lkp NUMBER,
e16 VARCHAR2(255 BYTE),
e17 VARCHAR2(255 BYTE),
e18 VARCHAR2(255 BYTE),
e19 VARCHAR2(255 BYTE),
e20 VARCHAR2(255 BYTE),
e21 VARCHAR2(255 BYTE),
e22 VARCHAR2(255 BYTE),
e23 VARCHAR2(255 BYTE),
e24 VARCHAR2(255 BYTE),
e25 VARCHAR2(255 BYTE),
executable_trans_flag VARCHAR2(1 BYTE) NOT NULL,
record_status_lkp NUMBER,
parent_type_id NUMBER,
nd_parent_id NUMBER,
dn_event_type_code VARCHAR2(30 BYTE),
status_date DATE,
long_e1 VARCHAR2(4000 BYTE),
long_e2 VARCHAR2(4000 BYTE),
long_e3 VARCHAR2(4000 BYTE),
dn_owner_party_person_id NUMBER,
e26 VARCHAR2(255 BYTE),
e27 VARCHAR2(255 BYTE),
e28 VARCHAR2(255 BYTE),
e29 VARCHAR2(255 BYTE),
e30 VARCHAR2(255 BYTE),
dn_business_class_lkp NUMBER NOT NULL,
dn_event_class_lkp NUMBER NOT NULL,
security_class_lkp NUMBER NOT NULL,
site_no NUMBER(4) NOT NULL,
long_e4 VARCHAR2(4000 BYTE),
long_e5 VARCHAR2(4000 BYTE),
long_e6 VARCHAR2(4000 BYTE),
long_e7 VARCHAR2(4000 BYTE),
long_e8 VARCHAR2(4000 BYTE),
web_request_id NUMBER,
attached_topic_id NUMBER,
adult_flag VARCHAR2(1 BYTE),
dn_location_id NUMBER,
dn_loc_staff_id NUMBER,
dn_receive_date DATE,
receive_flag VARCHAR2(1 BYTE),
ll_parent_id NUMBER,
ll_object_id NUMBER,
io_type NUMBER(2),
io_id NUMBER(12),
io_out_seq NUMBER,
file_name VARCHAR2(256 BYTE),
send_police_org_unit_id NUMBER,
io_timestamp DATE,
inves_no NUMBER,
inves_year NUMBER,
event_no_sno NUMBER,
prc_unit_id NUMBER,
document_flag VARCHAR2(2 BYTE),
copy_serial NUMBER,
machine_name VARCHAR2(255 BYTE),
hearing_date DATE
TABLESPACE ts16k_data
PCTUSED 0
PCTFREE 10
INITRANS 1
MAXTRANS 255
STORAGE (
INITIAL 1414 m
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
LOGGING
NOCOMPRESS
NOCACHE
NOPARALLEL
MONITORING;
CREATE INDEX moj.dn_location_id_idx ON moj.prc_events
(dn_location_id)
LOGGING
TABLESPACE ts16k_indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 47 m
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE INDEX moj.dn_loc_staff_id_idx ON moj.prc_events
(dn_loc_staff_id)
LOGGING
TABLESPACE ts16k_indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 21 m
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE INDEX moj.e1_indx ON moj.prc_events
(e1)
LOGGING
TABLESPACE ts16k_indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 20 m
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE INDEX moj.e4_indx ON moj.prc_events
(e4)
NOLOGGING
TABLESPACE ts16k_indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 18 m
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE INDEX moj.env_server_id_i ON moj.prc_events
(server_id)
NOLOGGING
TABLESPACE ts16k_indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 49 m
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE INDEX moj.env_wrksec_i ON moj.prc_events
(wrksec_id_created_by)
NOLOGGING
TABLESPACE ts16k_indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 51 m
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE INDEX moj.event_no_sno_i ON moj.prc_events
(event_no_sno)
LOGGING
TABLESPACE ts16k_indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 128 k
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE INDEX moj.event_status_i ON moj.prc_events
(event_status_lkp)
LOGGING
TABLESPACE ts16k_indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 11 m
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE INDEX moj.evn_date ON moj.prc_events
(event_date)
NOLOGGING
TABLESPACE ts16k_indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 72 m
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE INDEX moj.evn_date_year_no_idx ON moj.prc_events
(event_date, event_year, event_no)
LOGGING
TABLESPACE ts16k_indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 89 m
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE INDEX moj.evn_evn_typ_i ON moj.prc_events
(event_type_id)
NOLOGGING
TABLESPACE ts16k_indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 56 m
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE INDEX moj.evn_nd_parent_fk_i ON moj.prc_events
(nd_parent_id)
NOLOGGING
TABLESPACE ts16k_indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 17 m
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE INDEX moj.evn_parent_appcmp_fk_i ON moj.prc_events
(parent_type_id)
NOLOGGING
TABLESPACE ts16k_indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 42 m
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE UNIQUE INDEX moj.evn_pk_i ON moj.prc_events
(ID)
NOLOGGING
TABLESPACE ts16k_indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 57 m
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE INDEX moj.evn_prnt_i ON moj.prc_events
(parent_id)
NOLOGGING
TABLESPACE ts16k_indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 41 m
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE INDEX moj.evn_prt_prs_i ON moj.prc_events
(dn_owner_party_person_id)
NOLOGGING
TABLESPACE ts16k_indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 14 m
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE INDEX moj.evn_site_i ON moj.prc_events
(site_id)
NOLOGGING
TABLESPACE ts16k_indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 49 m
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE INDEX moj.evnt_sngdbyid_indx ON moj.prc_events
(signed_by_id)
LOGGING
TABLESPACE moj_data
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 21600 k
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE INDEX moj.evnt_sngonhkbyid_indx ON moj.prc_events
(signed_onbehalf_by_id)
LOGGING
TABLESPACE moj_data
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 864 k
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE INDEX moj.evn_year_no_i ON moj.prc_events
(event_year, event_no)
LOGGING
TABLESPACE ts16k_indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 58 m
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE INDEX moj.i1 ON moj.prc_events
(dn_event_type_code)
NOLOGGING
TABLESPACE ts16k_indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 75 m
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE INDEX moj.i2 ON moj.prc_events
(security_class_lkp)
LOGGING
TABLESPACE ts16k_indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 53 m
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE INDEX moj.ix1 ON moj.prc_events
(event_type_id, e5, event_date, event_year)
LOGGING
TABLESPACE ts16k_indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 104 m
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL
COMPRESS 2;
CREATE INDEX moj.ix2 ON moj.prc_events
(e4, dn_event_type_code)
LOGGING
TABLESPACE ts16k_indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 72 m
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL
COMPRESS 1;
CREATE INDEX moj.ix6 ON moj.prc_events
(event_type_id, event_year, event_no)
LOGGING
TABLESPACE ts16k_indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 53 m
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL
COMPRESS 2;
CREATE INDEX moj.prc_event_idx1 ON moj.prc_events
(e25, event_type_id)
LOGGING
TABLESPACE ts16k_indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 72 m
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE INDEX moj.prc_event_idx10 ON moj.prc_events
(event_type_id, security_class_lkp, event_date)
LOGGING
TABLESPACE ts16k_indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 122 m
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE INDEX moj.prc_event_idx11 ON moj.prc_events
(e4, dn_event_type_code, e5)
LOGGING
TABLESPACE ts16k_indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 108 m
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE INDEX moj.prc_event_idx12 ON moj.prc_events
(event_no, event_year)
LOGGING
TABLESPACE ts16k_indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 82 m
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE INDEX moj.prc_event_idx13 ON moj.prc_events
(subject)
LOGGING
TABLESPACE ts16k_indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 128 m
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE INDEX moj.prc_event_idx14 ON moj.prc_events
(e13, event_type_id, long_e1)
LOGGING
TABLESPACE ts16k_indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 190 m
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE INDEX moj.prc_event_idx15 ON moj.prc_events
(event_type_id, ID)
LOGGING
TABLESPACE ts16k_indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 112 m
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE INDEX moj.prc_event_idx16 ON moj.prc_events
(dn_event_class_lkp)
LOGGING
TABLESPACE ts16k_indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 56 m
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE INDEX moj.prc_event_idx17 ON moj.prc_events
(e26, event_type_id)
LOGGING
TABLESPACE ts16k_indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 80 m
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE INDEX moj.prc_event_idx18 ON moj.prc_events
(e16, event_type_id)
LOGGING
TABLESPACE ts16k_indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 72 m
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE INDEX moj.prc_event_idx19 ON moj.prc_events
(created_by)
LOGGING
TABLESPACE ts16k_indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 76 m
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE INDEX moj.prc_event_idx2 ON moj.prc_events
(e25, event_type_id, e26)
LOGGING
TABLESPACE ts16k_indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 89 m
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE INDEX moj.prc_event_idx20 ON moj.prc_events
(event_type_id, security_class_lkp, TO_NUMBER(TO_CHAR("EVENT_YEAR")))
LOGGING
TABLESPACE indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 64 k
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE INDEX moj.prc_event_idx21 ON moj.prc_events
(dn_owner_party_person_id, event_status_lkp, event_type_id)
LOGGING
TABLESPACE indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 64 k
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE INDEX moj.prc_event_idx22 ON moj.prc_events
(event_type_id, prc_unit_id, e5, event_date)
LOGGING
TABLESPACE indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 64 k
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE INDEX moj.prc_event_idx23 ON moj.prc_events
(event_type_id, e5)
LOGGING
TABLESPACE indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 64 k
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE INDEX moj.prc_event_idx24 ON moj.prc_events
(event_type_id, security_class_lkp, e5)
LOGGING
TABLESPACE indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 64 k
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE INDEX moj.prc_event_idx25 ON moj.prc_events
(ID, event_year)
LOGGING
TABLESPACE indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 64 k
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE INDEX moj.prc_event_idx3 ON moj.prc_events
(event_type_id, parent_id)
LOGGING
TABLESPACE ts16k_indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 80 m
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE INDEX moj.prc_event_idx4 ON moj.prc_events
(event_type_id, prc_unit_id, event_date)
LOGGING
TABLESPACE ts16k_indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 100 m
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE INDEX moj.prc_event_idx5 ON moj.prc_events
(status_date, event_type_id)
LOGGING
TABLESPACE ts16k_indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 91 m
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE INDEX moj.prc_event_idx6 ON moj.prc_events
(e4, event_type_id)
LOGGING
TABLESPACE ts16k_indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 81 m
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE INDEX moj.prc_event_idx7 ON moj.prc_events
(e15, event_type_id, e18)
LOGGING
TABLESPACE ts16k_indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 88 m
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE INDEX moj.prc_event_idx8 ON moj.prc_events
(e15, event_type_id, e18, e12)
LOGGING
TABLESPACE ts16k_indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 94 m
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE INDEX moj.prc_event_idx9 ON moj.prc_events
(event_no, dn_event_type_code, event_year, e5, e4)
LOGGING
TABLESPACE ts16k_indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 136 m
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE INDEX moj.prc_event_io_timestamp_idx ON moj.prc_events
(io_timestamp)
LOGGING
TABLESPACE ts16k_indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 10 m
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE INDEX moj.prc_events_e5_i ON moj.prc_events
(e5)
NOLOGGING
TABLESPACE ts16k_indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 28 m
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE INDEX moj.prc_events_idx27 ON moj.prc_events
(event_type_id, event_status_lkp, event_date)
LOGGING
TABLESPACE ts16k_indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 64 k
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE INDEX moj.prc_unit_id_indx ON moj.prc_events
(prc_unit_id)
NOLOGGING
TABLESPACE ts16k_indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 53 m
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
CREATE INDEX moj.signed_position_idx ON moj.prc_events
(signed_position_id)
LOGGING
TABLESPACE ts16k_indx
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 64 k
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOPARALLEL;
ALTER TABLE moj.prc_events ADD (
CONSTRAINT evn_evn_fk
FOREIGN KEY (parent_id)
REFERENCES moj.prc_events (ID),
CONSTRAINT evn_evn_ndirect_prnt_fk
FOREIGN KEY (nd_parent_id)
REFERENCES moj.prc_events (ID),
CONSTRAINT evn_org_unt_fk
FOREIGN KEY (site_id)
REFERENCES moj.env_organization_units (ID),
CONSTRAINT evn_parent_typ_appcmp_fk
FOREIGN KEY (parent_type_id)
REFERENCES base_2000.bsh_application_components (ID),
CONSTRAINT evn_prt_prs_fk
FOREIGN KEY (dn_owner_party_person_id)
REFERENCES moj.env_persons_table (ID),
CONSTRAINT evn_signed_fk
FOREIGN KEY (signed_by_id)
REFERENCES moj.env_persons_table (ID),
CONSTRAINT evn_signed_onbehalf_fk
FOREIGN KEY (signed_onbehalf_by_id)
REFERENCES moj.env_persons_table (ID),
CONSTRAINT evn_signed_pos_fk
FOREIGN KEY (signed_position_id)
REFERENCES moj.env_positions (ID),
CONSTRAINT evn_typ_appcmp_fk
FOREIGN KEY (event_type_id)
REFERENCES base_2000.bsh_application_components (ID));
GRANT DELETE, INSERT, SELECT, UPDATE ON moj.prc_events TO base_2000_role;
GRANT DELETE, INSERT, SELECT, UPDATE ON moj.prc_events TO moj_role;Please note that this table is having around 8 million rows and many other queries are slow on this table especially in case of self joins. Further all transactions are saving in this table and also the child transactions and child of the child transactions therefore normally we have to select this table mutiple times in the FROM CLAUSE LIKE887419 wrote:
Yes there are dozens of indexes. I also don't like this table structure, no normalization. Actually this one table should be 10 are more tables but unfortunately, what I can do now because a big application is based on this ugly design.You could normalise this table and put a view in place to recreate the table structure as it stands now, that way you wouldn't break the application from a query point of view. You could also add INSTEAD OF triggers to allow inserts, updates and deletes and redirect them to the new normalised structures.
>
Will table partitioning will work for this table.It might do, or it might make things worse. You need to identify a key that is used in all or the vast majority of queries to partition by. Event date might be one, but then again it might not. Another could be event type id, or a category of some type, but if it's only used in a handful of queries you run the risk of slowing all the other queries down to speed your one up.
user6806750 already mentioned that you could create a new index just to service your query
maybe something like
CREATE INDEX xyz on PRC_EVENTS
( event_type_id,
e1,
event_date,
event_year
/Have you looked at index monitoring to see which of these indexes is actually being used? You've got lots of indexes on individual columns and it might be that you can combine quite a number of them into composite indexes that can serve more than one query.
HTH
David -
Query runs very slow and sometime freezes
Hi Experts,
I have just installed SAP GUI 710 but when i open a query in analyzer it runs very slow and if the variables are set for more than 6 months it just sits there and finally times out. It takes at least 5 minutes to open the query if it opens at all. Can you please advise me on how to resolve this issue??
Thanks, point will be awarded.Worth running RSRT .
Ravi Thothadri -
Query running sometimes slow and sometimes fast on both prod and dev. Help
We are running a job that is behaving so inconsistently that I am ready to jump off the 19th floor. :-)
This query that goes against one table, was just coming to halt in production. After 4 days of investigation we thought it was the resource on production box. Now we have another dev box where we were also having the same issue. This box gets updated with production data everyday. There is a 3rd box. DBA ran update statistics on the 3rd box and the job was never slow there. When we updated 2nd box (dev) with statistics from th 3rd box, the job also ran fine. So we thought we know for sure that it is the statistics that we need to up. Now for business testing, the 2nd and 3rd box got updated with data and statistics from production box (the troubled one). We thought surely we will see issues on the 2nd and 3rd box, but the job was just running fine on these boxes. As I said, the 2nd box gets updated with production data everyday. After last night's refresh this job is running long on the 2nd box again. We are really puzzled. Has any one experience anything like this before?
thanks in advance.
Reaz.We got our dba who is checking the plan when ever we run the job.
The dba is running the trace right now. Here is the trace result from the trace:
SELECT STATUS_FLAG, FSI_TID, FSI_REC_TID, AREA, VALUE_DATE, CANCEL_DATE,
TO_DATE(ENTRY_DATE_TIME), PRODUCT, CUST_TID
FROM
ORD_FX WHERE WSS_GDP_SITE = :B3 AND DEAL_NUMBER = :B2 AND TICKET_AREA = :B1
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 514 0.23 0.27 0 0 0 0
Fetch 514 253.40 247.44 0 16932188 0 514
total 1028 253.63 247.71 0 16932188 0 514
Misses in library cache during parse: 0
Optimizer mode: CHOOSE
Parsing user id: 26 (recursive depth: 1)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
latch: cache buffers chains 2 0.00 0.00
no IO issue in any database at any time. We saw a little high IO in production yesterday so we thought we are looking at a resource issue, but today the system is fine and we had no luck with the job. -
The below Query runs very slow
SELECT
ACT1.PROJ,
ACT1.ACT,
ACT1.VER,
ACT1.DS,
ACT1.UC,
ACT1.ACT_RN,
PRED1.PRED,
PRED_DS.DS,
PRED_DS.UC01 ACT_TYPE ,
PRED1.RN,
SUCC.SUC
,SUCC.SUC_NAME
,SUCC.SUC_TYPE
,SUCC.SUCC_RN
FROM
(SELECT A.PROJ , A.VER , A.ACT , A.DS , A.UC01 UC , B.RN ACT_RN
FROM PM_PORTAL.AV_ACTIVITY A , PM_PORTAL.AV_RESREQ B
WHERE A.PROJ = B.PROJ(+)
AND A.ACT = B.ACT(+)
AND A.VER = B.VER(+)
AND A.VER = 50
AND A.PROJ LIKE 'BOM_%'
AND A.UC01 = '560'
) ACT1 ,
( SELECT A.PROJ , A.ACT , A.VER , A.PRED , B.RN
FROM PM_PORTAL.AV_RELN A , PM_PORTAL.AV_RESREQ B
WHERE A.PROJ LIKE 'BOM_%'
AND A.VER = 50
AND A.PROJ = B.PROJ(+)
AND A.PRED = B.ACT(+)
AND A.VER = B.VER(+)
) PRED1,
( SELECT DS , UC01 ,ACT ,VER , PROJ
FROM PM_PORTAL.AV_ACTIVITY
WHERE PROJ LIKE 'BOM_%'
AND VER = 50
) PRED_DS ,
(SELECT A.PROJ , A.VER , A.ACT SUC , A.PRED , B.DS SUC_NAME ,B.UC01 SUC_TYPE , C.RN SUCC_RN
FROM PM_PORTAL.AV_RELN A , PM_PORTAL.AV_ACTIVITY B , PM_PORTAL.AV_RESREQ C
WHERE A.PROJ = B.PROJ
AND A.ACT = B.ACT
AND A.VER = B.VER
AND B.PROJ = C.PROJ
AND B.ACT = C.ACT
AND B.VER = C.VER
) SUCC
WHERE ACT1.PROJ=PRED1.PROJ(+)
AND ACT1.ACT=PRED1.ACT(+)
AND ACT1.VER=PRED1.VER(+)
AND PRED1.PRED = PRED_DS.ACT
AND PRED1.PROJ = PRED_DS.PROJ
AND PRED1.VER = PRED_DS.VER
AND SUCC.PROJ = PRED1.PROJ
AND SUCC.VER = PRED1.VER
AND SUCC.PRED = PRED1.PRED
--Execution Plan
SELECT STATEMENT, GOAL = CHOOSE 293 1 337
NESTED LOOPS 293 1 337
NESTED LOOPS 290 1 305
NESTED LOOPS 287 1 242
NESTED LOOPS 282 1 206
FILTER
HASH JOIN OUTER
VIEW PM_PORTAL_READ 65 2 194
NESTED LOOPS OUTER 65 2 190
TABLE ACCESS BY INDEX ROWID TRN_ARTE AV_ACTIVITY_NPART 59 2 126
INDEX RANGE SCAN TRN_ARTE AV_ACTIVITY_1_NPART 55 2
INDEX RANGE SCAN TRN_ARTE AV_RESREQ_1_NPART 3 35 1120
VIEW PM_PORTAL_READ 210 101 4646
HASH JOIN OUTER 210 101 6868
INDEX RANGE SCAN TRN_ARTE AV_RELN_1_NPART 161 101 3636
INDEX RANGE SCAN TRN_ARTE AV_RESREQ_1_NPART 48 35 1120
TABLE ACCESS BY INDEX ROWID TRN_ARTE AV_ACTIVITY_NPART 3 56 3528
INDEX UNIQUE SCAN TRN_ARTE AV_ACTIVITY_1_NPART 2 56
INDEX RANGE SCAN TRN_ARTE AV_RELN_1_NPART 5 101 3636
TABLE ACCESS BY INDEX ROWID TRN_ARTE AV_ACTIVITY_NPART 3 56 3528
INDEX UNIQUE SCAN TRN_ARTE AV_ACTIVITY_1_NPART 2 56
INDEX RANGE SCAN TRN_ARTE AV_RESREQ_1_NPART 3 35 1120Here's the verbatim response I gave yesterday to another user also posting his SQL and asking the same question.. why is it slow?
Who says it is not already running as fast as possible?
In order to solve a problem, you need to know the problem. Stating something like 'a query is slow and should be faster' is stating an opinion - it is not describing a problem that can be resolved.
My suggestion is to turn a complex problem, into a bunch of smaller and simpler problems. If you suspect that the query could be faster, pull it apart. Test each step/component of the query in isolation. E.g. start with a single table and progressively add joins to determine what the CBO does with each additional join, what you're asking Oracle to do ito processing, and not only checking that the CBO does not make obvious errors, but that what you're asking via SQL is the best approach to get to the answer. -
Single Query suddenly goes slow until database restart or query change
Hello all,
Configuration I'm using is Oracle 10g EE 10.1.0.4.0 on Windows 2003 Server
I have performance issue with one single query. The query is called using dbExpress from Delphi application.
Since a month, almost every week this query starts going VERY slow. Usually it executes in a 0.5-1 second, but when it's slowed down, it takes approx. 4-5 minutes to execute.
The query runs on a single table (~4 000 000 rows) and runs on primary index. The index itself consists of 5 fields - the query uses the first 4 of them. I know it's not a good design but restructuring the table/index is out of question, AFAIK.
Until now, I figured out two ways to speed things up. The first and obvious is to restart the server or shut/start the database. It works. For a week. Then we're back at first square.
The second way is some kind of a mystery to me: If I change the query a little bit, never mind how - for example, adding 'and (1=1)' in the clause, after deploying the application, it starts running fast. Again for a week or so.
I've attached an jpeg showing the explain plans on slow and fast executing queries. They look almost the same.
I'm running out of ideas for now. It's very annoying (and unsafe) to restart the machine on a week basis. Thus any help is greatly appreciated.
Things I've done so far:
- installed last service packs from Oracle and Microsoft.
- tried different versions of dbexpora.dll.
- Regularly gathered and estimated statistics and analyzings.
- Made sure that the server is not under heavy load (antiviruses, firewalls, archive loggers are stopped or uninstalled for a while).
- made sure that there is enough free space on hard disks.
- the disk array itself is in good health - defragmented, HDD tools doesn't find anything suspicious.
Final thoughts: Maybe the sql cache is going overloaded and someway stops executing the query. That's why when I restart the machine or change the query clause insignificantly, it starts running fast. I took a peek on v$sql and v$sqlarea but there is nothing special, and honestly, I'm not very familiar reading the values in this view - I'm just comparing the values returned by this query with the others - they look similar.
Anyway, if someone could help, it would be great.
Regards,
Ivan
Screenshots showing the explain plans for slow and fast query:
Image: !http://img254.imageshack.us/img254/6674/queryr.jpg!Sorry for the incomplete information. I tried to gather the mentioned in your second link additional data. Unfortunately, I cannot find the TKPROF utility - it's not in the bin directory, neither in any other folder. Guess it's not installed at all.
About rewriting the query, suggested in the first link you gave: it's so simple and clear that it should not be rewriten. As I mentioned before, every time I change the query even a little bit, it starts running well for a couple of days.
Anyway, here are the stats I've just gathered. Unfortunately, now the query performs well and I'm not able to give you stats, showing the slowed down query.
These are the parameters relevant to the optimizer:
SQL> show parameter optimizer
NAME TYPE VALUE
optimizer_dynamic_sampling integer 2
optimizer_features_enable string 10.1.0.4
optimizer_index_caching integer 0
optimizer_index_cost_adj integer 100
optimizer_mode string ALL_ROWS
SQL> show parameter db_file_multi
NAME TYPE VALUE
db_file_multiblock_read_count integer 32
SQL> show parameter db_block_size
NAME TYPE VALUE
db_block_size integer 8192
SQL> show parameter cursor_sharing
NAME TYPE VALUE
cursor_sharing string EXACT
Screenshots of explain plan is posted in my first post - both for fast and slow executed query.
output of SQL_Plus AUTOTRACE including the TIMING information:
SQL> set autotrace traceonly arraysize 1000
SQL> SELECT * FROM "AOPERITEM"
WHERE (FOPER = 201)
AND (FCLIENT = 1)
AND (FDATEOPER = '2009-10-28')
AND (FNUMOPER = 95532)
Execution Plan
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
| 0 | SELECT STATEMENT | | 1 | 132 | 5 (0)|
| 1 | TABLE ACCESS BY INDEX ROWID| AOPERITEM | 1 | 132 | 5 (0)|
| 2 | INDEX RANGE SCAN | AOPERITEM_IDX | 1 | | 4 (0)|
Note
- 'PLAN_TABLE' is old version
Statistics
1 recursive calls
0 db block gets
9 consistent gets
0 physical reads
0 redo size
3098 bytes sent via SQL*Net to client
369 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
4 rows processed
The DBMS_XPLAN.DISPLAY_CURSOR output:
SQL> select /*+ gather_plan_statistics */
* FROM "AOPERITEM"
WHERE (FOPER = 201)
AND (FCLIENT = 1)
AND (FDATEOPER = '2009-10-28')
AND (FNUMOPER = 95532)
Execution Plan
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
| 0 | SELECT STATEMENT | | 1 | 132 | 5 (0)|
| 1 | TABLE ACCESS BY INDEX ROWID| AOPERITEM | 1 | 132 | 5 (0)|
| 2 | INDEX RANGE SCAN | AOPERITEM_IDX | 1 | | 4 (0)|
Note
- 'PLAN_TABLE' is old version
Statistics
0 recursive calls
0 db block gets
9 consistent gets
4 physical reads
0 redo size
2937 bytes sent via SQL*Net to client
369 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
4 rows processed
PS: I'm not a DBA myself, I'm just trying to find a solution to this problem.
Thanks in advance. -
Challenging Query working very slow
Hi Guys
my query is working very slow .. i think i am using old functions to fetch data .. is anybody can recommand changes into it to make it faster
SELECT a.Student_Updated,
a.Course_Updated,
b.Notes_Updated,
a.School_ID,
a.School_Code,
a.School_Name,
a.Course_Code,
a.Course_Name,
ass.ass_type Assessment_Type,
ass.ass_status Assessment_Status,
ass.ass_work_due_date Assessment_Date,
ass.ass_result_achieved Assessment_result,
a.Last_Name,
a.First_Name,
a.Initials,
a.Stud_ID,
a.User_ID,
a.Email,
b.Code1,
b.Code2,
b.Code3,
b.Code4,
b.Code5,
b.Code6,
b.Code7,
b.Code8,
b.Code9,
b.Code10,
b.Code11,
b.Code12,
b.Code13,
b.Code14,
b.Code15,
b.Code16,
b.Code17,
b.Code18,
b.Code19,
b.Code20,
b.Code21,
b.Code22,
b.Code23,
b.Code24,
a.Cert_Status,
a.Class_Status,
b.Notes1,
b.Notes2,
b.Notes3,
b.Notes4
FROM
(SELECT s.s_ref Stud_ID,
s.s_date_changed Student_Updated,
max(sba.sba_date_changed) Course_Updated,
cc.cc_user_value_1 School_ID,
lv.lv_high_value School_Code,
lv.lv_meaning School_Name,
sba.sba_sb_ref Course_Code,
sb.sb_name Course_Name,
s.s_surname Last_Name,
s.s_forename_1 First_Name,
substr(s.s_forename_2, 1, 1) Initials,
s.s_vehicle_reg_no User_ID,
decode(s.s_e_mail_address,
null, decode(s.s_vehicle_reg_no,
null, null, s.s_vehicle_reg_no||'@abdn.ac.uk'),
s.s_e_mail_address||'@aberdeen.ac.uk') Email,
sba.sba_significance Cert_Status,
sba.sba_status Class_Status
FROM students s,
study_block_associations sba,
study_blocks sb,
cost_centres cc,
calendar_periods cp,
local_values lv
WHERE s.s_ref = sba.sba_s_ref
AND sba.sba_sb_ref = sb.sb_ref
AND sb.sb_cc_ref = cc.cc_ref
AND cc.cc_user_value_1 = lv.lv_value(+)
AND lv.lv_domain = 'CC USER VALUE 1'
-- AND nvl(s.s_disabilities, '99') not in ('0', '0T', '00', '97', '98', '99')
AND length(sba.sba_sb_ref) = '6'
AND instr('L|W', sba.sba_status) > 0
AND sba.sba_type = 'E'
AND sba.sba_calp_period_code = cp.calp_period_code
AND calp_cal_ref = 'RYEAR'
AND trunc(sysdate) BETWEEN calp_start_date AND calp_end_date
GROUP BY
s.s_ref,
s.s_date_changed,
sba.sba_sb_ref,
sb.sb_name,
cc.cc_user_value_1,
lv.lv_high_value,
lv.lv_meaning,
s.s_surname,
s.s_forename_1,
substr(s.s_forename_2, 1, 1),
s.s_disabilities,
s.s_vehicle_reg_no,
decode( s.s_e_mail_address,
null, decode( s.s_vehicle_reg_no,
null, null,
s.s_vehicle_reg_no||'@abdn.ac.uk'),
s.s_e_mail_address||'@aberdeen.ac.uk'),
sba.sba_significance,
sba.sba_status
) a,
(SELECT sle.sle_s_ref Stud_ID,
max(sle.sle_date_created) Notes_Updated,
sum(case when sle.sle_le_ref = '01' then 1 else 0 end) Code1,
sum(case when sle.sle_le_ref = '02' then 1 else 0 end) Code2,
sum(case when sle.sle_le_ref = '03' then 1 else 0 end) Code3,
sum(case when sle.sle_le_ref = '04' then 1 else 0 end) Code4,
sum(case when sle.sle_le_ref = '05' then 1 else 0 end) Code5,
sum(case when sle.sle_le_ref = '06' then 1 else 0 end) Code6,
sum(case when sle.sle_le_ref = '07' then 1 else 0 end) Code7,
sum(case when sle.sle_le_ref = '08' then 1 else 0 end) Code8,
sum(case when sle.sle_le_ref = '09' then 1 else 0 end) Code9,
sum(case when sle.sle_le_ref = '10' then 1 else 0 end) Code10,
sum(case when sle.sle_le_ref = '11' then 1 else 0 end) Code11,
sum(case when sle.sle_le_ref = '12' then 1 else 0 end) Code12,
sum(case when sle.sle_le_ref = '13' then 1 else 0 end) Code13,
sum(case when sle.sle_le_ref = '14' then 1 else 0 end) Code14,
sum(case when sle.sle_le_ref = '15' then 1 else 0 end) Code15,
sum(case when sle.sle_le_ref = '16' then 1 else 0 end) Code16,
sum(case when sle.sle_le_ref = '17' then 1 else 0 end) Code17,
sum(case when sle.sle_le_ref = '18' then 1 else 0 end) Code18,
sum(case when sle.sle_le_ref = '19' then 1 else 0 end) Code19,
sum(case when sle.sle_le_ref = '20' then 1 else 0 end) Code20,
sum(case when sle.sle_le_ref = '21' then 1 else 0 end) Code21,
sum(case when sle.sle_le_ref = '22' then 1 else 0 end) Code22,
sum(case when sle.sle_le_ref = '23' then 1 else 0 end) Code23,
sum(case when sle.sle_le_ref = '24' then 1 else 0 end) Code24,
sle4.Notes1,
sle4.Notes2,
sle4.Notes3,
sle4.Notes4
FROM abdn_student_le_provisions sle,
(SELECT sle3.sle_s_ref,
max(case when sle3.ord = 1 then sle3.sle_description end) Notes1,
max(case when sle3.ord = 2 then sle3.sle_description end) Notes2,
max(case when sle3.ord = 3 then sle3.sle_description end) Notes3,
max(case when sle3.ord = 4 then sle3.sle_description end) Notes4
FROM (SELECT row_number() over (partition by sle2.sle_s_ref order by sle2.sle_s_ref) as ord,
sle2.sle_s_ref,
sle2.sle_description
FROM abdn_student_le_provisions sle2
WHERE sle2.sle_description is not null
) sle3
GROUP BY
sle3.sle_s_ref
) sle4
WHERE sle.sle_s_ref = sle4.sle_s_ref(+)
GROUP BY
sle.sle_s_ref,
sle4.Notes1,
sle4.Notes2,
sle4.Notes3,
sle4.Notes4
) b,
assessments ass
WHERE a.Stud_ID = b.Stud_ID
AND a.Stud_ID = ass.ass_s_ref(+)
AND a.Course_Code = ass.ass_sb_ref(+);Thread: HOW TO: Post a SQL statement tuning request - template posting
HOW TO: Post a SQL statement tuning request - template posting -
Oracle query running very slow
Hi,
We've MS-Access application which was pointing to UDB. Now we migrated it to point Oracle DB 9.2. After migration some of the query is running very slow.
These queries used to take less than 30 seconds in UDB now taking more than 5 Minutes in Oracle.
some more obeservation :
(1) Some of the queries using "HAVING" clause without any aggregate function. When I moved this condition to "WHERE" clause, performance improved a lot.
But problem is that I can't suggest this solution to "USERS". They are creating query using "query wizard" in MS-Access and they started creating noise on this.
(2) I tested same MDB in two different PCs and same query is returning records in 4 seconds in one system, is taking more than 10 minutes in other system.
Since I'm new to MS-Access, I don't know what other information I need to provide here.
Please help me out.ms wrote:
Hi All
I am using Oracle 11g . My table contains 10-12 lac rows.Do not use the word lac: it is common in the Indian sub-continent but not known much outside of
there because it is not standard English.
>
1) what is the difference between a index on one column and an index of number of columns ( i.e composite index). The obvious answer of one contains only one column and the other contains more than one.
2) For what columns in a where clause should index be created ( single columns index or composite index ).Depends
3) Also can u suggest how to improve the perfomane of thsi query?Please read: SQL and PL/SQL FAQ
which tells you how to ask a performance related question -
Some body please help about the Inventory FIFO (FIRST IN FISRT OUT ) query is very slow
I have table ''tran_stock'' to store a transaction (IN-OUT) of the stock.
The problem is when the transaction rows are more than 50000 the query to get the balance
stock (Total 'IN' - Total'Out' by FIFO) is very slow . Somebody please suggest me to do this.
This is my query
;WITH OrderedIn as (
select *,ROW_NUMBER() OVER (PARTITION BY Stock_ID ORDER BY TranDate) as rn
from Tran_Stock
where TxnType = 'IN'
), RunningTotals as (
select Stock_ID ,Qty,Price,Qty as Total,Cast(0 as decimal(10,2)) as PrevTotal , trandate , rn from OrderedIn where rn = 1
union all
select rt.Stock_ID,oi.Qty,oi.Price,Cast(rt.Total + oi.Qty as decimal(10,2)),Cast(rt.Total as decimal(10,2)) , oi.TranDate ,oi.rn
from
RunningTotals rt
inner join
OrderedIn oi
on
rt.Stock_ID = oi.Stock_ID and
rt.rn = oi.rn - 1
, TotalOut as (
select Stock_ID ,SUM(Qty) as Qty from Tran_Stock where TxnType='OUT' group by Stock_ID
) , GrandTotal as
select
rt.Stock_ID , rt.QTY AS original ,SUM(CASE WHEN PrevTotal > isNULL(out.Qty, 0) THEN rt.Qty ELSE rt.Total - isNULL(out.Qty, 0) END) AS QTY , Price , SUM(CASE WHEN PrevTotal > isNULL(out.Qty, 0) THEN rt.Qty ELSE rt.Total - isNULL(out.Qty,
0) END * Price) AS Ending , rt.TranDate
from
RunningTotals rt
LEFT join
TotalOut out
on
rt.Stock_ID = out.Stock_ID
where rt.Total > isNull(out.Qty , 0)
group by rt.Stock_ID , Price , rt.TranDate , rt.QTY
) SELECT * FROM GrandTotal order by TranDate option (maxrecursion 0)
AND this is my Table with some example data
USE [TestInventory]
GO
/****** Object: Table [dbo].[Tran_Stock] Script Date: 12/15/2014 3:55:56 AM ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[Tran_Stock](
[TranID] [int] IDENTITY(1,1) NOT NULL,
[Stock_ID] [int] NULL,
[TranDate] [date] NULL,
[TxnType] [nvarchar](3) NULL,
[Qty] [decimal](10, 2) NULL,
[Price] [decimal](10, 2) NULL
) ON [PRIMARY]
GO
SET IDENTITY_INSERT [dbo].[Tran_Stock] ON
INSERT [dbo].[Tran_Stock] ([TranID], [Stock_ID], [TranDate], [TxnType], [Qty], [Price]) VALUES (1, 1, CAST(0x81350B00 AS Date), N'IN', CAST(200.00 AS Decimal(10, 2)), CAST(750.00 AS Decimal(10, 2)))
INSERT [dbo].[Tran_Stock] ([TranID], [Stock_ID], [TranDate], [TxnType], [Qty], [Price]) VALUES (2, 1, CAST(0x85350B00 AS Date), N'OUT', CAST(100.00 AS Decimal(10, 2)), NULL)
INSERT [dbo].[Tran_Stock] ([TranID], [Stock_ID], [TranDate], [TxnType], [Qty], [Price]) VALUES (3, 1, CAST(0x8A350B00 AS Date), N'IN', CAST(50.00 AS Decimal(10, 2)), CAST(700.00 AS Decimal(10, 2)))
INSERT [dbo].[Tran_Stock] ([TranID], [Stock_ID], [TranDate], [TxnType], [Qty], [Price]) VALUES (4, 1, CAST(0x90350B00 AS Date), N'IN', CAST(75.00 AS Decimal(10, 2)), CAST(800.00 AS Decimal(10, 2)))
INSERT [dbo].[Tran_Stock] ([TranID], [Stock_ID], [TranDate], [TxnType], [Qty], [Price]) VALUES (5, 1, CAST(0x99350B00 AS Date), N'OUT', CAST(175.00 AS Decimal(10, 2)), NULL)
INSERT [dbo].[Tran_Stock] ([TranID], [Stock_ID], [TranDate], [TxnType], [Qty], [Price]) VALUES (6, 2, CAST(0x82350B00 AS Date), N'IN', CAST(150.00 AS Decimal(10, 2)), CAST(350.00 AS Decimal(10, 2)))
INSERT [dbo].[Tran_Stock] ([TranID], [Stock_ID], [TranDate], [TxnType], [Qty], [Price]) VALUES (7, 2, CAST(0x88350B00 AS Date), N'OUT', CAST(40.00 AS Decimal(10, 2)), NULL)
INSERT [dbo].[Tran_Stock] ([TranID], [Stock_ID], [TranDate], [TxnType], [Qty], [Price]) VALUES (8, 2, CAST(0x8C350B00 AS Date), N'OUT', CAST(10.00 AS Decimal(10, 2)), NULL)
INSERT [dbo].[Tran_Stock] ([TranID], [Stock_ID], [TranDate], [TxnType], [Qty], [Price]) VALUES (9, 2, CAST(0x98350B00 AS Date), N'IN', CAST(90.00 AS Decimal(10, 2)), CAST(340.00 AS Decimal(10, 2)))
INSERT [dbo].[Tran_Stock] ([TranID], [Stock_ID], [TranDate], [TxnType], [Qty], [Price]) VALUES (12, 2, CAST(0x98350B00 AS Date), N'IN', CAST(10.00 AS Decimal(10, 2)), CAST(341.00 AS Decimal(10, 2)))
INSERT [dbo].[Tran_Stock] ([TranID], [Stock_ID], [TranDate], [TxnType], [Qty], [Price]) VALUES (13, 2, CAST(0x99350B00 AS Date), N'OUT', CAST(30.00 AS Decimal(10, 2)), NULL)
INSERT [dbo].[Tran_Stock] ([TranID], [Stock_ID], [TranDate], [TxnType], [Qty], [Price]) VALUES (14, 2, CAST(0x81350B00 AS Date), N'IN', CAST(120.00 AS Decimal(10, 2)), CAST(350.00 AS Decimal(10, 2)))
INSERT [dbo].[Tran_Stock] ([TranID], [Stock_ID], [TranDate], [TxnType], [Qty], [Price]) VALUES (15, 2, CAST(0x89350B00 AS Date), N'OUT', CAST(90.00 AS Decimal(10, 2)), NULL)
INSERT [dbo].[Tran_Stock] ([TranID], [Stock_ID], [TranDate], [TxnType], [Qty], [Price]) VALUES (17, 3, CAST(0x89350B00 AS Date), N'IN', CAST(90.00 AS Decimal(10, 2)), CAST(350.00 AS Decimal(10, 2)))
INSERT [dbo].[Tran_Stock] ([TranID], [Stock_ID], [TranDate], [TxnType], [Qty], [Price]) VALUES (18, 3, CAST(0x8A350B00 AS Date), N'OUT', CAST(60.00 AS Decimal(10, 2)), NULL)
INSERT [dbo].[Tran_Stock] ([TranID], [Stock_ID], [TranDate], [TxnType], [Qty], [Price]) VALUES (19, 3, CAST(0x5D390B00 AS Date), N'OUT', CAST(20.00 AS Decimal(10, 2)), NULL)
INSERT [dbo].[Tran_Stock] ([TranID], [Stock_ID], [TranDate], [TxnType], [Qty], [Price]) VALUES (20, 1, CAST(0x81350B00 AS Date), N'IN', CAST(200.00 AS Decimal(10, 2)), CAST(750.00 AS Decimal(10, 2)))
INSERT [dbo].[Tran_Stock] ([TranID], [Stock_ID], [TranDate], [TxnType], [Qty], [Price]) VALUES (21, 1, CAST(0x85350B00 AS Date), N'OUT', CAST(100.00 AS Decimal(10, 2)), NULL)Hi,
You dont have any Index on the table, so the filters (where part in the queries) and the sorting (order by, group by) make your query slow. it take time to sort or filter data without Index. It is like reading a book with 3k pages and trying to find a specific
subject. You have to read the all books, but if you have "table of contents" which is the book index, then this can be done fast.
* check the Execution plan (the image here show part of your query's execution plan). the query scan the all table 3 times...
there is one sort that use 81% of the query resources... I will go sleep soon (it is
23:58 In Israel now), and I don't know if I will have time to read the query itself and improved it, so lets start with indexes :-)
** as a first step after or before you create the right Indexes you should remove the recursive all together. there is no reason for lopping the data when you can use it as a SET. This is where the relational database's power come to life :-)
for example check this code. I only use your first part of the code using the first 2 CTE tables. compare result.
;WITH
OrderedIn as (
select *,ROW_NUMBER() OVER (PARTITION BY Stock_ID ORDER BY TranDate) as rn
from Tran_Stock
where TxnType = 'IN'
, RunningTotals as (
select Stock_ID ,Qty, Price, Qty as Total, Cast(0 as decimal(10,2)) as PrevTotal, trandate , rn
from OrderedIn where rn = 1
union all
select
rt.Stock_ID, oi.Qty, oi.Price, Cast(rt.Total + oi.Qty as decimal(10,2))
,Cast(rt.Total as decimal(10,2))
, oi.TranDate ,oi.rn
from RunningTotals rt
inner join OrderedIn oi on rt.Stock_ID = oi.Stock_ID and rt.rn = oi.rn - 1
select * from RunningTotals
-- This will do the same as the above query
select
Stock_ID, Qty, Price
, SUM(Qty) over (PARTITION BY Stock_ID order by TranDate ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) as Total
,TranDate--,TranID, TxnType
from Tran_Stock
where TxnType = 'IN'
order by Stock_ID
Ronen Ariely
[Personal Site] [Blog] [Facebook]
Maybe you are looking for
-
How can my users unpause a printer without admin login?
Everytime a printer goes into a paused state it requires me to login as the admin for the que to unpause the printer. Any ideas?
-
I have photos in Photo Elements 11 that I want to back up to iCloud, Can this be done
I have photos in Photo Elements 11,not on my iPad, that I want to back up to iCloud, Can this be done?
-
Trouble linking pages to the home page
I had a sales page, one page, designed in Dreamweaver. Its file name is index.html. I created a template from it to save the header and footer and look and feel to create second level pages. I have assigned each of those a file name ending in .html I
-
Exit for PR fields updation from sc for Account assignment
Hi All, I have a requirement where I need to update fields from Shopping Cart account assignment to Purchase requisiton customer data tab. could any one let me know how to make data flow from SC and make the data appear in PR. Thanks
-
Is it possible with adobe pro X to kopie a list from an adobe docment to an excel document. Now i have to type it over.