Query is taking too long fetch data

Hi,
Working on EBS Version 11.5.10.2
This below query takes 7 minutes reterive to job orders. I need some help to improve this query to retrieve faster.
select inventory_item_id
,job
,item_code
,item_description
,subinventory_code
,locators
,quantity_open
,sum(transaction_quantity) qoh
from
select wrv.inventory_item_id
,wdj.wip_entity_name Job
,rtrim(wrv.concatenated_segments) item_code
,wrv.item_description
,mil.subinventory_code
,mil.segment1||'.'||mil.segment2||'.'||mil.segment3 locators
,wrv.quantity_open
,transaction_quantity
from wip_discrete_jobs_v wdj
,wip_requirement_operations_v wrv
,mtl_onhand_quantities moh
,mtl_item_locations mil
where wdj.wip_entity_id = wrv.wip_entity_id
and moh.inventory_item_id = wrv.inventory_item_id
and mil.inventory_location_id = moh.locator_id
and wdj.job_type_meaning = 'Standard'
and wdj.status_type_disp = 'Released'
and wrv.quantity_open > 0
and wrv.organization_id = 0
and moh.organization_id = 0
and mil.organization_id = 0
--and rtrim(wrv.concatenated_segments) = '2124 2014-336'
and wdj.wip_entity_name in ('D477334') --,'D612664')
group by
inventory_item_id
,job
,item_code
,item_description
,subinventory_code
,locators
,quantity_open
Thanks and Regards

{message:id=9360003}

Similar Messages

When query is taking too long time

When query is taking too long time,Where and how to start tuning it?
Here i've listed few things need to be considered,out of my knowledge and understanding
1.What the sql is waiting for(wait events)
2.Parameter modification need to be done at system/session level
3.The query has to be tuned (using hints )
4.Gathering/deleting statistics
List out any other things that need to be taken into account?
Which approach must be followed and on what basis that approach must be considered?

When query is taking too long time,Where and how to start tuning it?explain plan will be good start . trace also
Here i've listed few things need to be considered,out of my knowledge and understanding
1.What the sql is waiting for(wait events)When Oracle executes an SQL statement, it is not constantly executing. Sometimes it has to wait for a specific event to happen befor it can proceed.
Read
http://www.adp-gmbh.ch/ora/tuning/event.html
2.Parameter modification need to be done at system/session levelDepend on parameter , define parameter , trace done on session level for example
3.The query has to be tuned (using hints )Could be help you but you must know how to use .
4.Gathering/deleting statisticsDo it in non working hours , it will impact on database performance , but its good
List out any other things that need to be taken into account?Which account ?
Which approach must be followed and on what basis that approach must be considered?you could use lot of tools , Trace , AWR

Query is taking too long to execute - contd

I am unable to post the entire explain plan in one post as it exceeds maximum length.
Please advise on how to post this.
Previous post Link : Link: Query is taking too long to execute
Regards,
Sreekanth Munagala.
Edited by: Sreekanth Munagala on Oct 27, 2009 8:31 AM
Edited by: Sreekanth Munagala on Oct 27, 2009 8:34 AM

Hi Tubby,
Today i executed only the first query in the view and it took almost 2.5 hrs.
Here is the explain plan for this query
SQL> SET SERVEROUTPUT ON
SQL> set linesize 200
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
| Id | Operation                                        | Name                         | Rows | Bytes | Cost |
|   0 | SELECT STATEMENT                                 |                               |     1 |   766 | 2448 |
|   1 | TABLE ACCESS BY INDEX ROWID                     | PO_VENDORS                    |     1 |    13 |     3 |
|* 2 |   INDEX UNIQUE SCAN                              | PO_VENDORS_U1                 |     1 |       |     2 |
|   3 | TABLE ACCESS BY INDEX ROWID                     | PO_VENDORS                    |     1 |    29 |     3 |
|* 4 |   INDEX UNIQUE SCAN                              | PO_VENDORS_U1                 |     1 |       |     2 |
|   5 | VIEW                                            | POC_ASN_PICKUP_LOCATIONS_V    |     2 | 2426 |    17 |
|   6 |   UNION-ALL                                      |                               |       |       |       |
|   7 |    NESTED LOOPS                                  |                               |     1 |    85 |     4 |
|   8 |     NESTED LOOPS                                 |                               |     1 |    78 |     4 |
|* 9 |      TABLE ACCESS BY INDEX ROWID                 | PO_VENDOR_SITES_ALL           |     1 |    73 |     3 |
|* 10 |       INDEX UNIQUE SCAN                          | PO_VENDOR_SITES_U2            |     1 |       |     2 |
|* 11 |      INDEX UNIQUE SCAN                           | PO_VENDORS_U1                 |     1 |     5 |     1 |
|* 12 |     INDEX UNIQUE SCAN                            | FND_TERRITORIES_TL_U1         |     1 |     7 |       |
| 13 |    NESTED LOOPS                                  |                               |     1 |    91 |    13 |
| 14 |     NESTED LOOPS                                 |                               |     1 |    84 |    13 |
| 15 |      TABLE ACCESS BY INDEX ROWID                 | PO_VENDORS                    |     1 |    13 |     3 |
|* 16 |       INDEX UNIQUE SCAN                          | PO_VENDORS_U1                 |     1 |       |     2 |
PLAN_TABLE_OUTPUT
|* 17 |      TABLE ACCESS BY INDEX ROWID                 | FND_LOOKUP_VALUES             |     1 |    71 |    10 |
|* 18 |       INDEX RANGE SCAN                           | FND_LOOKUP_VALUES_U2          |    13 |       |     2 |
|* 19 |     INDEX UNIQUE SCAN                            | FND_TERRITORIES_TL_U1         |     1 |     7 |       |
|* 20 | COUNT STOPKEY                                   |                               |       |       |       |
| 21 |   TABLE ACCESS BY INDEX ROWID                    | MTL_SYSTEM_ITEMS_B            |     8 |   136 |    12 |
|* 22 |    INDEX RANGE SCAN                              | MTL_SYSTEM_ITEMS_B_U1         |     8 |       |     3 |
|* 23 | COUNT STOPKEY                                   |                               |       |       |       |
| 24 |   TABLE ACCESS BY INDEX ROWID                    | MTL_SYSTEM_ITEMS_B            |     8 |   288 |    12 |
|* 25 |    INDEX RANGE SCAN                              | MTL_SYSTEM_ITEMS_B_U1         |     8 |       |     3 |
| 26 | TABLE ACCESS BY INDEX ROWID                     | FND_TERRITORIES_TL            |     1 |    24 |     2 |
|* 27 |   INDEX UNIQUE SCAN                              | FND_TERRITORIES_TL_U1         |     1 |       |     1 |
| 28 | NESTED LOOPS                                    |                               |     1 |    40 |     5 |
| 29 |   TABLE ACCESS BY INDEX ROWID                    | HZ_CUST_ACCOUNTS              |     1 |    11 |     3 |
|* 30 |    INDEX UNIQUE SCAN                             | HZ_CUST_ACCOUNTS_U1           |     1 |       |     2 |
| 31 |   TABLE ACCESS BY INDEX ROWID                    | HZ_PARTIES                    |     1 |    29 |     2 |
|* 32 |    INDEX UNIQUE SCAN                             | HZ_PARTIES_U1                 |     1 |       |     1 |
| 33 | TABLE ACCESS BY INDEX ROWID                     | FND_TERRITORIES_TL            |     1 |    24 |     2 |
|* 34 |   INDEX UNIQUE SCAN                              | FND_TERRITORIES_TL_U1         |     1 |       |     1 |
| 35 | TABLE ACCESS BY INDEX ROWID                     | FND_TERRITORIES_TL            |     1 |    24 |     2 |
|* 36 |   INDEX UNIQUE SCAN                              | FND_TERRITORIES_TL_U1         |     1 |       |     1 |
|* 37 | COUNT STOPKEY                                   |                               |       |       |       |
PLAN_TABLE_OUTPUT
|* 38 |   TABLE ACCESS BY INDEX ROWID                    | ONTC_MTC_PROFORMA_HEADERS     |     1 |    21 |     3 |
|* 39 |    INDEX RANGE SCAN                              | ONTC_MTC_PROFORMA_HEADERS_U2 |     1 |       |     2 |
| 40 | TABLE ACCESS BY INDEX ROWID                     | FND_TERRITORIES_TL            |     1 |    24 |     2 |
|* 41 |   INDEX UNIQUE SCAN                              | FND_TERRITORIES_TL_U1         |     1 |       |     1 |
|* 42 | COUNT STOPKEY                                   |                               |       |       |       |
|* 43 |   TABLE ACCESS BY INDEX ROWID                    | ONTC_MTC_PROFORMA_HEADERS     |     1 |    21 |     3 |
|* 44 |    INDEX RANGE SCAN                              | ONTC_MTC_PROFORMA_HEADERS_U2 |     1 |       |     2 |
| 45 | SORT AGGREGATE                                  |                               |     1 |    39 |       |
| 46 |   NESTED LOOPS OUTER                             |                               |     2 |    78 | 1828 |
|* 47 |    TABLE ACCESS FULL                             | ONTC_MTC_PROFORMA_HEADERS     |     1 |    24 | 1825 |
| 48 |    TABLE ACCESS BY INDEX ROWID                   | ONTC_MTC_PROFORMA_LINES       |     5 |    75 |     3 |
|* 49 |     INDEX RANGE SCAN                             | ONTC_MTC_PROFORMA_LINES_PK    |    11 |       |     2 |
| 50 | NESTED LOOPS                                    |                               |     1 |   766 | 2448 |
| 51 |   NESTED LOOPS                                   |                               |     1 |   761 | 2447 |
| 52 |    NESTED LOOPS                                  |                               |     1 |   746 | 2445 |
| 53 |     NESTED LOOPS                                 |                               |     1 |   694 | 2443 |
| 54 |      NESTED LOOPS                                |                               |     1 |   682 | 2441 |
| 55 |       NESTED LOOPS                               |                               |     1 |   671 | 2439 |
| 56 |        NESTED LOOPS                              |                               |     1 |   612 | 2437 |
| 57 |         NESTED LOOPS                             |                               |     1 |   600 | 2435 |
| 58 |          NESTED LOOPS                            |                               |     1 |   575 | 2433 |
PLAN_TABLE_OUTPUT
| 59 |           NESTED LOOPS                           |                               |     1 |   552 | 2431 |
| 60 |            NESTED LOOPS                          |                               |     1 |   533 | 2429 |
| 61 |             NESTED LOOPS                         |                               |     1 |   524 | 2428 |
| 62 |              NESTED LOOPS                        |                               |     1 |   455 | 2427 |
| 63 |               NESTED LOOPS                       |                               |     1 |   429 | 2426 |
| 64 |                NESTED LOOPS                      |                               |     1 |   389 | 2424 |
| 65 |                 NESTED LOOPS                     |                               |     1 |   368 | 2422 |
| 66 |                  NESTED LOOPS                    |                               |     1 |   308 | 2421 |
| 67 |                   NESTED LOOPS                   |                               |     1 |   281 | 2419 |
| 68 |                    NESTED LOOPS                  |                               |     1 |   253 | 2418 |
| 69 |                     NESTED LOOPS                 |                               |     1 |   214 | 2416 |
| 70 |                      NESTED LOOPS                |                               |    39 | 7371 | 2338 |
|* 71 |                       TABLE ACCESS FULL          | RCV_SHIPMENT_HEADERS          |    39 | 5070 | 2221 |
|* 72 |                       TABLE ACCESS BY INDEX ROWID| RCV_SHIPMENT_LINES            |     1 |    59 |     3 |
|* 73 |                        INDEX RANGE SCAN          | RCV_SHIPMENT_LINES_U2         |     1 |       |     2 |
|* 74 |                      TABLE ACCESS BY INDEX ROWID | PO_LINES_ALL                  |     1 |    25 |     2 |
|* 75 |                       INDEX UNIQUE SCAN          | PO_LINES_U1                   |     1 |       |     1 |
|* 76 |                     TABLE ACCESS BY INDEX ROWID | PO_LINE_LOCATIONS_ALL         |     1 |    39 |     2 |
|* 77 |                      INDEX UNIQUE SCAN           | PO_LINE_LOCATIONS_U1          |     1 |       |     1 |
|* 78 |                    TABLE ACCESS BY INDEX ROWID   | PO_HEADERS_ALL                |     1 |    28 |     1 |
|* 79 |                     INDEX UNIQUE SCAN            | PO_HEADERS_U1                 |     1 |       |       |
PLAN_TABLE_OUTPUT
|* 80 |                   TABLE ACCESS BY INDEX ROWID    | OE_ORDER_LINES_ALL            |     1 |    27 |     2 |
|* 81 |                    INDEX UNIQUE SCAN             | OE_ORDER_LINES_U1             |     1 |       |     1 |
| 82 |                  TABLE ACCESS BY INDEX ROWID     | OE_ORDER_HEADERS_ALL          |     1 |    60 |     1 |
|* 83 |                   INDEX UNIQUE SCAN              | OE_ORDER_HEADERS_U1           |     1 |       |       |
|* 84 |                 TABLE ACCESS BY INDEX ROWID      | HZ_CUST_SITE_USES_ALL         |     1 |    21 |     2 |
|* 85 |                  INDEX UNIQUE SCAN               | HZ_CUST_SITE_USES_U1          |     1 |       |     1 |
|* 86 |                TABLE ACCESS BY INDEX ROWID       | HZ_CUST_SITE_USES_ALL         |     1 |    40 |     2 |
|* 87 |                 INDEX UNIQUE SCAN                | HZ_CUST_SITE_USES_U1          |     1 |       |     1 |
| 88 |               TABLE ACCESS BY INDEX ROWID        | WSH_CARRIERS                  |     1 |    26 |     1 |
|* 89 |                INDEX UNIQUE SCAN                 | WSH_CARRIERS_U2               |     1 |       |       |
|* 90 |              TABLE ACCESS BY INDEX ROWID         | WSH_CARRIER_SERVICES          |     1 |    69 |     1 |
|* 91 |               INDEX RANGE SCAN                   | WSH_CARRIER_SERVICES_N1       |     2 |       |       |
|* 92 |             TABLE ACCESS BY INDEX ROWID          | WSH_ORG_CARRIER_SERVICES      |     1 |     9 |     1 |
|* 93 |              INDEX RANGE SCAN                    | WSH_ORG_CARRIER_SERVICES_N1   |     1 |       |       |
| 94 |            TABLE ACCESS BY INDEX ROWID           | HZ_CUST_ACCOUNTS              |     1 |    19 |     2 |
|* 95 |             INDEX UNIQUE SCAN                    | HZ_CUST_ACCOUNTS_U1           |     1 |       |     1 |
|* 96 |           TABLE ACCESS BY INDEX ROWID            | HZ_CUST_ACCT_SITES_ALL        |     1 |    23 |     2 |
|* 97 |            INDEX UNIQUE SCAN                     | HZ_CUST_ACCT_SITES_U1         |     1 |       |     1 |
|* 98 |          TABLE ACCESS BY INDEX ROWID             | HZ_CUST_ACCT_SITES_ALL        |     1 |    25 |     2 |
|* 99 |           INDEX UNIQUE SCAN                      | HZ_CUST_ACCT_SITES_U1         |     1 |       |     1 |
| 100 |         TABLE ACCESS BY INDEX ROWID              | HZ_PARTY_SITES                |     1 |    12 |     2 |
PLAN_TABLE_OUTPUT
|*101 |          INDEX UNIQUE SCAN                       | HZ_PARTY_SITES_U1             |     1 |       |     1 |
| 102 |        TABLE ACCESS BY INDEX ROWID               | HZ_LOCATIONS                  |     1 |    59 |     2 |
|*103 |         INDEX UNIQUE SCAN                        | HZ_LOCATIONS_U1               |     1 |       |     1 |
|*104 |       INDEX RANGE SCAN                           | HZ_LOC_ASSIGNMENTS_N1         |     1 |    11 |     2 |
| 105 |      TABLE ACCESS BY INDEX ROWID                 | HZ_PARTY_SITES                |     1 |    12 |     2 |
|*106 |       INDEX UNIQUE SCAN                          | HZ_PARTY_SITES_U1             |     1 |       |     1 |
| 107 |     TABLE ACCESS BY INDEX ROWID                  | HZ_LOCATIONS                  |     1 |    52 |     2 |
|*108 |      INDEX UNIQUE SCAN                           | HZ_LOCATIONS_U1               |     1 |       |     1 |
|*109 |    INDEX RANGE SCAN                              | HZ_LOC_ASSIGNMENTS_N1         |     1 |    15 |     2 |
|*110 |   INDEX UNIQUE SCAN                              | HZ_PARTIES_U1                 |     1 |     5 |     1 |
I will put the predicate information in another post.
193 rows selected.
SQL> spool offPlease suggest on how can we improve the performance.
Regards,
Sreekanth Munagala.

Streamline query ? Taking too long

First I wanted to say thanks to all in this forum, its been a huge help learning sql.
Hoping someone can take a look at this query. It works but it takes a very long time to run.
maybe there is a way to streamline it. right now its using one project number, but typically I would put in 60 or 70 project numbers here..
select proj_id from project_master where status='A' and project_number IN(
'502998'
)))c,
if someone knows a better way to run this please let me know , I will try anything. currently it takes about an hour to run it for 1 project number.
select * from(
select
b.doc_folder_id,c.project_number,b.name,a.doc_file_name,a.rec_update_date,a.rec_create_date,d.rnk
from
select doc_id,proj_id, doc_file_name,rec_create_date,rec_update_date from document_master where doc_status ='A'
and doc_file_extension like 'pdf' or doc_file_extension like 'jpg'
or doc_file_extension like 'xls' or doc_file_extension like 'doc'
or doc_file_extension like 'txt' or doc_file_extension like 'png'
or doc_file_extension like 'tif' or doc_file_extension like 'ppt'
or doc_file_extension like 'pps' or doc_file_extension like 'msg'
) a,
(select * from doc_folder_master
where upper(name) LIKE '%DAILY REPORTS%'
OR upper(name) LIKE '%MANPOWER REPORTS%'
OR upper(name) LIKE '%SITE PURCHASES%'
OR upper(name) LIKE '%SETE EHS ISSUES%'
OR upper(name) LIKE '%TURNOVER PACKAGES%'
OR upper(name) LIKE '11.04.01 PAD%'
OR upper(name) LIKE '%EDSR%'
OR upper(name) LIKE '%COQ WORKFLOW%'
and status='A'
) b,
(select proj_id,project_number from project_master where proj_id IN (
select proj_id from project_master where status='A' and project_number IN(
'502998'
)))c,
(select child_doc_type,
parent_doc_id,child_doc_id,to_char(rec_create_date,'mm/dd/yyyy hh24:mi:ss'),
row_number() over (partition by parent_doc_id,child_doc_type order by rec_create_date desc) rnk
from document_relations)d
where a.proj_id=b.proj_id
and c.proj_id=a.proj_id
and c.proj_id=b.proj_id
and d.parent_doc_id=b.doc_folder_id
and a.doc_id=d.child_doc_id)
where rnk <3
thanks for any assistance.
Edited by: Jay on Dec 29, 2010 12:08 PM

Hi,
Please, you might want to read this post:
When your query takes too long ...
Providing further information is key to obtaining quality answers.
Now on to the actual subject:
It seems you want some sort of top-n query. Depending on the cardinality and the data that you have, you probably would want to prune the rows from the DOCUMENT_RELATIONS table early, before joining to the other tables. This way you can avoid the database wasting effort of looking up matches on the other tables to only then discard those joined rows. You can do that by pushing the WHERE rnk < 3 predicate into the inline view.
SELECT *
FROM (SELECT b.doc_folder_id, c.project_number, b.name, a.doc_file_name, a.rec_update_date, a.rec_create_date, d.rnk
          FROM (SELECT doc_id, proj_id, doc_file_name, rec_create_date, rec_update_date
                  FROM document_master
                 WHERE doc_status = 'A'
                       AND doc_file_extension IN ('pdf', 'jpg', 'xls', 'doc', 'txt', 'png', 'tif', 'ppt', 'pps', 'msg')) a,
               (SELECT *
                  FROM doc_folder_master
                 WHERE upper(NAME) LIKE '%DAILY REPORTS%'
                       OR upper(NAME) LIKE '%MANPOWER REPORTS%'
                       OR upper(NAME) LIKE '%SITE PURCHASES%'
                       OR upper(NAME) LIKE '%SETE EHS ISSUES%'
                       OR upper(NAME) LIKE '%TURNOVER PACKAGES%'
                       OR upper(NAME) LIKE '11.04.01 PAD%'
                       OR upper(NAME) LIKE '%EDSR%'
                       OR upper(NAME) LIKE '%COQ WORKFLOW%'
                       AND status = 'A') b,
               (SELECT proj_id, project_number
                  FROM project_master
                 WHERE proj_id IN (SELECT proj_id
                                     FROM project_master
                                    WHERE status = 'A'
                                          AND project_number IN ('502998'))) c,
               (SELECT *
                  FROM (SELECT child_doc_type,
                               parent_doc_id,
                               child_doc_id,
                               to_char(rec_create_date, 'mm/dd/yyyy hh24:mi:ss'),
                               row_number() over(PARTITION BY parent_doc_id, child_doc_type ORDER BY rec_create_date DESC) rnk
                          FROM document_relations)
                 WHERE rnk < 3) d
         WHERE a.proj_id = b.proj_id
               AND c.proj_id = a.proj_id
               AND c.proj_id = b.proj_id
               AND d.parent_doc_id = b.doc_folder_id
               AND a.doc_id = d.child_doc_id)Like Toon said, if not needed you should avoid the 2nd scan in the PROJECT_MASTER table.
Perhaps you should check the possibility of creating a function-based index on the doc_folder_master table, with the upper(NAME) expression, to improve those Like conditions.
Docs on Function-based Indexes:
http://download.oracle.com/docs/cd/E11882_01/server.112/e16638/data_acc.htm#PFGRF94785

Connect by level query is taking too long time to run

Hello,
I have a query that returns quarters (YYYYQ) of a begin- and enddate within a specific id, that is built with a connect by level clause, but the query is running to long. I have used explain plan to see what the query is doing, but no silly things to see, just a full table scan, with low costs.
This is the query:
select to_char(add_months( cpj.crpj_start_date,3*(level - 1)),'YYYYQ') as sales_quarter
, cpj.crpj_id as crpj_id
from mv_gen_cra_projects cpj
where cpj.crpj_start_date >= to_date('01/01/2009','mm/dd/yyyy')
and cpj.crpj_start_date <= cpj.crpj_end_date
and cpj.crpj_routing_type = 'A'
and ( cpj.crpj_multi_artist_ind = 'N'
or cpj.crpj_multi_artist_ind is null)
connect by level <= 1 + ceil(months_between(cpj.crpj_end_date,cpj.crpj_start_date)/3);
The result have to be like this:
SALES_QUARTER CRPJ_ID
20091 100
20092 100
20093 100
20094 100
20101 100
20102 100
Can anyone help me out with this?

but no silly things to see, just a full table scan, with low costs.Well, maybe an index scan would be faster?
However:
You will need to provide us some more details, like:
- database version (the result of: SQL> select * from v$version;)
- post the explain plan output (put the tag before and after it, so indentation and formatting are maintained, see the [FAQ|http://forums.oracle.com/forums/help.jspa] for more explanation regarding tags )
- what are your optimizer settings (the result of: SQL> show parameter optimizer)
- if applicable: are your table statistics up to date?
- mv_gen_cra_projects is a materialized view perhaps?
Edited by: hoek on Jan 26, 2010 10:50 AM

Mirrored RAID taking too long for Data Rebuild

I have created a RAID 1 (Mirrored RAID) using Disk Utility in my Mac Pro. I have used 2 x 4TB WD Enterprise Grade HDDs. I copied 10 gb data on to this 4 TB RAID volume. Then removed one of the HDDs & installed in my other Mac Pro. It mounted as normal HDD & showed all the data that I had copied. To check if Disk Utility will rebuild the data, I deleted some part of this data (2 GBs out of 10 GBs) & installed this drive back in the system on which I had Created this RAID volume.
Initially I was surprised to find that Deleted data is now absent on this RAID volume. But on Launching Disk Utility it started rebuilding data on RAID volume.
BUT for Rebuilding 2 GB data estimated time shown by system was 9 hrs.
Is this NORMAL?
I intend to fill this 4 TB RAID volume with approximately 3.5 TB Data. In case one of the drive fails, how long should it take for Disk Utility to rebuild this amount of Data?
Is there any alternative way of speeding up this process?
Will Apple's RAID card help?
All your suggestions will be appreciated.
Thanks

I know this is an old thread but I'd be interested in what you came up with for a solution.
Here's my RAID journey thus far.
https://discussions.apple.com/message/25119317#25119317
Again, a gig of info and its taking 1 day 10 hours.
I hope theres a solution somewhere.
Drew

Query taking too long on Oracle9i

Hi All
I am running a query on our prod database (Oracle8i 8.1.7.4) and again running the same query on Test db (Oracle9i version 4). The query is taking too long(more then 10 min) in test db. Both the database are installed on the same machine IBM AIX V4 and table schema and data are same.
Any help would be appreciated.
Here are the results.
FASTER ONE
ORACLE 8i using Production
Statistics
864 recursive calls
68 db block gets
159855 consistent gets
20297 physical reads
0 redo size
1310148 bytes sent via SQL*Net to client
68552 bytes received via SQL*Net from client
1036 SQL*Net roundtrips to/from client
28 sorts (memory)
1 sorts (disk)
15525 rows processed
SLOWER ONE
ORACLE 9i using Test
Statistics
819 recursive calls
80 db block gets
22981568 consistent gets
1361 physical reads
0 redo size
1194902 bytes sent via SQL*Net to client
34193 bytes received via SQL*Net from client
945 SQL*Net roundtrips to/from client
0 sorts (memory)
1 sorts (disk)
14157 rows processed

319404-
To help us better understand the problem,
1) Could you post your execution plan on the two different databases?
2) Could you list indexes (if any, on these tables)?
3) Are any of the objects in the 'from list' a view?
If so, are you using a user defined function to create the view?
4) Why are you using the table 'cal_instance_relationship' twice in the 'from ' clause'?
5) Can't your query be the following?
SELECT f.person_id, f.course_cd, cv.responsible_org_unit_cd cowner, f.fee_cal_type Sem, f.fee_ci_sequence_number seq_no,
sua.unit_cd, uv.owner_org_unit_cd uowner, uv.supervised_contact_hours hours, 0 chg_rate, sum(f.transaction_amount) tot_fee,
' ' tally
FROM unit_version uv,
cal_instance_relationship cir1,
chg_method_apportion cma,
student_unit_attempt sua,
course_version cv,
fee_ass f
WHERE f.fee_type = 'VET-MATFEE'
AND f.logical_delete_dt IS NULL
AND f.s_transaction_type IN ('ASSESSMENT', 'MANUAL ADJ')
AND f.fee_ci_sequence_number > 400
AND f.course_cd = cv.course_cd
AND cv.version_number = (SELECT MAX(v.version_number) FROM course_version v
WHERE v.course_cd = cv.course_cd)
AND f.person_id = sua.person_id
and f.course_cd = sua.course_cd
AND f.fee_type = cma.fee_type
AND f.fee_ci_sequence_number = cma.fee_ci_sequence_number
AND cma.load_ci_sequence_number = cir1.sub_ci_sequence_number
AND cir1.sup_cal_type = 'ACAD-YR'
AND cir1.sub_cal_type = sua.cal_type
AND cir1.sub_ci_sequence_number = sua.ci_sequence_number
AND sua.unit_attempt_status NOT IN ('DUPLICATE','DISCONTIN')
AND sua.unit_cd = uv.unit_cd
AND sua.version_number = uv.version_number
GROUP BY f.person_id, f.course_cd, cv.responsible_org_unit_cd , f.fee_cal_type, f.fee_ci_sequence_number,
sua.unit_cd, uv.owner_org_unit_cd, uv.supervised_contact_hours;

Connect by taking too long

Hello,
I have a table "a" that has:
left_id right_id type
4 5 1
4 6 1
4 7 1
5 9 2
5 10 2
5 11 2
9 13 3
13 14 4
10 15 3
QUERY:
select left_id, right_id, type from
a
connect by left_id = prior right_id
start with left_id = 4;
Execution Plan
Plan hash value: 2739023583
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 29 | 1131 | 18 (12)| 00:00:01 |
|* 1 | CONNECT BY WITH FILTERING| | | | | |
|* 2 | INDEX RANGE SCAN | a_PK | 5 | 65 | 3 (0)| 00:00:01 |
| 3 | NESTED LOOPS | | 24 | 624 | 13 (0)| 00:00:01 |
| 4 | CONNECT BY PUMP | | | | | |
|* 5 | INDEX RANGE SCAN | a_PK | 5 | 65 | 2 (0)| 00:00:01 |
Predicate Information (identified by operation id):
1 - access("LEFT_ID"=PRIOR "RIGHT_ID")
2 - access("LEFT_ID"=4)
5 - access("LEFT_ID"="connect$_by$_pump$_002"."prior right_id ")
Is there a way to optimize the query?
The query is taking too long.
-Thanks
Karthik
Edited by: user3934098 on Nov 14, 2010 1:50 AM

Here is the detailed explaination:
Version: oracle 10g R2
Create table statement:
CREATE TABLE A
"LEFT_ID" NUMBER(9,0) NOT NULL ENABLE,
"RIGHT_ID" NUMBER(9,0) NOT NULL ENABLE,
"TYPE" NUMBER(9,0) NOT NULL ENABLE,
CONSTRAINT "A_PK" PRIMARY KEY ("LEFT_ID", "RIGHT_ID", "TYPE") USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT) TABLESPACE "DATA" ENABLE,
CONSTRAINT "A_FK1" FOREIGN KEY ("TYPE") REFERENCES "B" ("TYPE") ENABLE
SEGMENT CREATION IMMEDIATE PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING STORAGE
INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT
TABLESPACE "DATA" ;
Insert statements:
INSERT INTO A VALUES(4, 5, 1);
INSERT INTO A VALUES(4, 6, 1);
INSERT INTO A VALUES(4, 7, 1);
INSERT INTO A VALUES(5, 9, 2);
INSERT INTO A VALUES(5, 10, 2);
INSERT INTO A VALUES(5, 11, 2);
INSERT INTO A VALUES(9, 13, 3);
INSERT INTO A VALUES(13, 14, 4);
INSERT INTO A VALUES(10, 15, 3);
INDEXES:
CREATE UNIQUE INDEX "A_PK" ON "A" ("LEFT_ID", "RIGHT_ID", "TYPE") PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT) TABLESPACE "DATA" ;
QUERY:
select left_id, right_id, type from
a
connect by left_id = prior right_id
start with left_id = 4;
THE table has 951053 rows
The explain plan is:"
Execution Plan
Plan hash value: 2739023583
Id Operation Name Rows Bytes Cost (%CPU) Time
0 SELECT STATEMENT 29 1131 18 (12) 00:00:01
* 1 CONNECT BY WITH FILTERING
* 2 INDEX RANGE SCAN a_PK 5 65 3 (0) 00:00:01
3 NESTED LOOPS 24 624 13 (0) 00:00:01
4 CONNECT BY PUMP
* 5 INDEX RANGE SCAN a_PK 5 65 2 (0) 00:00:01
Predicate Information (identified by operation id):
1 - access("LEFT_ID"=PRIOR "RIGHT_ID")
2 - access("LEFT_ID"=4)
5 - access("LEFT_ID"="connect$_by$_pump$_002"."prior right_id ")
Now is there a way to optimize the query? The query takes about a min to excute. This will be my inner query.
" Is there any other information that you may need? Am I missing something here? "
-Thanks
Karthik
Edited by: user3934098 on Nov 14, 2010 2:22 AM

Oracle - Query taking too long (Materialized view)

Hi,
I am extracting billing informaiton and storing in 3 different tables... in order to show total billing (80 to 90 columns, 1 million rows per month), I've used a materialized view... I do not have indexes on 3 billing tables - do have 3 indexes on Materialized view...
at the moment it's taking too long to query the data (running a query via toad fails and shows "Out of Memory" error message; runing a query via APEX though is providing results but taking way too long)...
Please advice how to make the query efficient...

tparvaiz,
Is it possible when building your materialized view to summarize and consolidate the data?
Out of a million rows, what would your typical user do with that amount data if they could retrieve it readily? The answer to this question may indicate if and how to summarize the data within the materialized view.
Jeff
Edited by: jwellsnh on Mar 25, 2010 7:02 AM

Query taking too long to finish

Hi,
I'm running a query which is
Delete from msg where ID IN (select ID from deletedtrans );
It's taking too long to complete, it has been running for 24 hours already and not completed executing the query, I cancelled the query. I don't understand why it's taking too long, does anyone have any idea? I feel that this query should not take too long to complete

That seems to be too small piece of information to comment anything.
1. How many records are there in "deletedtrans" table ?
2. How many records from "msg" table are expected to be deleted ?
3. Are statistics up-to-date on "msg" and "deletedtrans" tables ?
4. Is "ID" column defined as NULL or NOT NULL in both "msg" and "deletedtrans" tables ? (Not sure whether this will cause any problem, but...)
5. Is this statement being executed when other users/applications are accessing/updating "msg" table ?

Data Archive Script is taking too long to delete a large table

Hi All,
We have data archive scripts, these scripts move data for a date range to a different table. so the script has two parts first copy data from original table to archive table; and second delete copied rows from the original table. The first part is executing very fast but the deletion is taking too long i.e. around 2-3 hours. The customer analysed the delete query and are saying the script is not using index and is going into full table scan. but the predicate itself is the primary key, Please help... More info below
CREATE TABLE "APP"."MON_TXNS"
   (    "ID_TXN" NUMBER(12,0) NOT NULL ENABLE,
    "BOL_IS_CANCELLED" VARCHAR2(1 BYTE) DEFAULT 'N' NOT NULL ENABLE,
    "ID_PAYER" NUMBER(12,0),
    "ID_PAYER_PI" NUMBER(12,0),
    "ID_PAYEE" NUMBER(12,0),
    "ID_PAYEE_PI" NUMBER(12,0),
    "ID_CURRENCY" CHAR(3 BYTE) NOT NULL ENABLE,
    "STR_TEXT" VARCHAR2(60 CHAR),
    "DAT_MERCHANT_TIMESTAMP" DATE,
    "STR_MERCHANT_ORDER_ID" VARCHAR2(30 BYTE),
    "DAT_EXPIRATION" DATE,
    "DAT_CREATION" DATE,
    "STR_USER_CREATION" VARCHAR2(30 CHAR),
    "DAT_LAST_UPDATE" DATE,
    "STR_USER_LAST_UPDATE" VARCHAR2(30 CHAR),
    "STR_OTP" CHAR(6 BYTE),
    "ID_AUTH_METHOD_PAYER" NUMBER(1,0),
    "AMNT_AMOUNT" NUMBER(23,0) DEFAULT 0,
    "BOL_IS_AUTOCAPTURE" VARCHAR2(1 BYTE) DEFAULT 'N' NOT NULL ENABLE,
    "ID_USE_CASE" NUMBER(4,0) NOT NULL ENABLE,
    "ID_AUTH_METHOD_PAYEE" NUMBER(2,0),
     CONSTRAINT "CKC_BOL_IS_CANCELLED_MON_TXNS" CHECK (BOL_IS_CANCELLED in ('Y','N')) ENABLE,
     CONSTRAINT "PK_MON_TXNS" PRIMARY KEY ("ID_TXN")
USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "LARGE_INDEX" ENABLE,
     CONSTRAINT "FK_MON_TXNS_CURRENCIES" FOREIGN KEY ("ID_CURRENCY")
      REFERENCES "APP"."CURRENCIES" ("ID_CURRENCY") ENABLE,
     CONSTRAINT "FK_MON_TXNS_TO_PAYER" FOREIGN KEY ("ID_PAYER")
      REFERENCES "APP"."CUSTOMERS" ("ID_CUSTOMER") ENABLE,
     CONSTRAINT "FK_MON_TXNS_TO_PAYEE" FOREIGN KEY ("ID_PAYEE")
      REFERENCES "APP"."CUSTOMERS" ("ID_CUSTOMER") ENABLE,
     CONSTRAINT "FK_MON_TXNS_REFERENCE_TXNS" FOREIGN KEY ("ID_TXN")
      REFERENCES "APP"."TXNS" ("ID_TXN") ENABLE,
     CONSTRAINT "FK_MON_TXNS_TO_PI_PAYER" FOREIGN KEY ("ID_PAYER_PI")
      REFERENCES "APP"."PIS" ("ID_PI") ENABLE,
     CONSTRAINT "FK_MON_TXNS_TO_PI_PAYEE" FOREIGN KEY ("ID_PAYEE_PI")
      REFERENCES "APP"."PIS" ("ID_PI") ENABLE,
     CONSTRAINT "FK_MON_TXNS_TO_AUTHMETHOD" FOREIGN KEY ("ID_AUTH_METHOD_PAYER")
      REFERENCES "APP"."AUTHENTICATION_METHODS" ("ID_AUTHENTICATION_METHOD") ENABLE,
     CONSTRAINT "FK_MON_TXNS_USE_CASE_ID" FOREIGN KEY ("ID_USE_CASE")
      REFERENCES "APP"."USE_CASES" ("ID_USE_CASE") ENABLE,
     CONSTRAINT "FK_MON_TXN_AUTH_PAYEE" FOREIGN KEY ("ID_AUTH_METHOD_PAYEE")
      REFERENCES "APP"."AUTHENTICATION_METHODS" ("ID_AUTHENTICATION_METHOD") ENABLE
CREATE INDEX "APP"."IDX_MON_TXNS" ON "APP"."MON_TXNS" ("ID_PAYER")
PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "LARGE_INDEX" ;
CREATE INDEX "APP"."IDX_PAYEE_MON_TXNS" ON "APP"."MON_TXNS" ("ID_PAYEE")
PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "LARGE_DATA" ;
CREATE INDEX "APP"."IDX_PYE_PI_MON_TXNS" ON "APP"."MON_TXNS" ("ID_PAYEE_PI")
PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "LARGE_DATA" ;
CREATE INDEX "APP"."IDX_PYR_PI_MON_TXNS" ON "APP"."MON_TXNS" ("ID_PAYER_PI")
PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "LARGE_DATA" ;
CREATE INDEX "APP"."IDX_USE_CASE_MON_TXNS" ON "APP"."MON_TXNS" ("ID_USE_CASE")
PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "LARGE_DATA" ;
CREATE UNIQUE INDEX "APP"."PK_MON_TXNS" ON "APP"."MON_TXNS" ("ID_TXN")
PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "LARGE_INDEX" ;
Data is first moved to table in schema3.OTW. and then we are deleting all the rows in otw from original table. below is the explain plan for delete
SQL> explain plan for
2 delete from schema1.mon_txns where id_txn in (select id_txn from schema3.OTW);
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 2798378986
| Id | Operation              | Name       | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | DELETE STATEMENT       |            | 2520 |   233K|    87   (2)| 00:00:02 |
|   1 | DELETE                | MON_TXNS   |       |       |            |          |
|* 2 |   HASH JOIN RIGHT SEMI |            | 2520 |   233K|    87   (2)| 00:00:02 |
|   3 |    INDEX FAST FULL SCAN| OTW_ID_TXN | 2520 | 15120 |     3   (0)| 00:00:01 |
|   4 |    TABLE ACCESS FULL   | MON_TXNS   | 14260 | 1239K|    83   (0)| 00:00:02 |
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
Please help,
thanks,
Banka Ravi

'Best practice' is just what Oracle is already doing as you have already been told: DELETE FROM myTable WHERE myDate between myStart and Myend.
Your use case is why many orgs elect to use partitioning and use that DATE column as the partition key. Then it is VERY FAST and VERY EASY to truncate or drop partitions that contain old data when you no longer need them.
The other solution used is to quit waiting so long to delete data and then you don't have to delete large amounts at the same time. So instead of deleting data once a month delete it once a week or even every night. Then the number of rows being deleted will be much smaller and, if the stats are kept current, Oracle may decide to use the index.

I was backing up my iphone by changing the location of library beacause i don't have enough space.My phone was taking too long to copying file so i can celled it.the data is stored in desired location . And now i can't delete that back up

I was backing up my iphone by changing the location of library because i don't have enough space.My phone was taking too long to copying file so i can celled it.the data is stored in desired location . And now i can't delete that back up.
Also tell me about the performance of iphone 4 with ios 7.1.1...........
T0X1C

rabidrabbit wrote:
Can I back up my iPhone 4S to my ipad 3 (64 gb)?
no
rabidrabbit wrote:
However, now I don't have enough space in iCloud to backup either device. Why not?
iCloud only give so much space for free storage, then if you exceed the limit of 5gb you have to pay for additional storage.

Query taking too long

I am running a fairly complex query with several table joins
and it is taking too long. What can I do to improve performance?
Thanks.
Frank

Dan's first suggestion is key - if you are doing multiple
table joins, you want to make sure your indexes are set up on your
tables correctly. If you have access to the database, this should
be your first step. Rationalize's stored procedure suggestion is
also a great idea (again, if you have access to create and manage
stored procedures on your DB).
Other than than, most databases usually have some sort of SQL
efficiency analysis tool. SQL server has one built into their Query
Analyzer tool. I would recommend using something like that to
streamline your SQL. Like Dan said, something as simple as the
order of elements in your where clause might make a big
difference.

R/3 Extraction taking too long to load data into BW

HI There,
I'm trying to extract SAP Standard extractor 0FI_AP_4 into BW, and its taking endless time.
Even the Extract checker RSA3 is taking too long to execute the data. Dont know why its taking so long to execute.
Since there in not much data to take such a long time.
Enhanced the datasource with three fields from BSEG using user exits.
Is that the reason why its taking too long? Does User Exit slows down the extraction process?
What measures i should take to quicken the process?
Thanks for your time
Vandana

Thanks for all you replies.
Please go through the steps I've gone through :
- Installed the Business Content and its in version 3.5
- Changed the update rules, Transfer rules and migrated the datasource to BI 7
- Enhanced the 0FI_AP_3 to include three fields BSEG table
- Ran RSA3 and the new fields are showing but the loading is quite slow.
- Commented the code and ran RSA3 and with little difference data is showing up
- Removed the comments and ran, its fine, though it takes little more time then previous step...but data is showing up
- Replicated the datasource into BW
- Created the info package and started the init process (before this deleted the previous stored init process)
- Data isn't loading and please see the error message below.
Diagnosis
The data request was a full update. In this case, the corresponding table in the source system does not
contain any data. System Response Info IDoc received with status 8. Procedure Check the data basis in the source system.
- Checked the transformation between datasource 0FI_AP_4 and Infosource ZFI_AP_4
and I DID NOT found the three fields which i enhanced from BSEG table in the 0FI_AP_4 datasource.
- Replicated the datasource 0FI_AP_4 again, but no change.
Now...I dont know whats happening here.
When i check the datasource 0FI_AP_4 in RSA6, i can see the three new fields from BSEG.
When i check RSA3, i can see the data getting populated with the three new fields from BSEG,
When i check the fields in the datasource 0FI_AP_4 in BW, I can see the three new fields. It shows
that the connection between BW and R/3 is fine, isn't it?
Now...Can anyone please suggest me how to go forward from here?
Thanks for your time
Vandana

SQL Statement taking too long to get the data

Hi,
There are over 2500 records in a table and when retrieve all using ' SELECT * From Table' it is taking too long to get the data. ie .. 4.3 secs.
Is there any possible way to shorten the process time.
Thanks

Hi Patrick,
Here is the sql statement and table desc.
ID     Number
SN     Varchar2(12)
FN     Varchar2(30)
LN     Varchar2(30)
By     Varchar(255)
Dt     Date(7)
Add     Varchar2(50)
Add1     Varchar2(30)
Cty     Varchar2(30)
Stt     Varchar2(2)
Zip     Varchar2(12)
Ph     Varchar2(15)
Email     Varchar2(30)
ORgId     Number
Act     Varchar2(3)
select A."FN" || '' '' || A."LN" || '' ('' || A."SN" || '')'' "Name",
A."By", A."Dt",
A."Add" || ''
'' || A."Cty" || '', '' || A."Stt" || '' '' || A."Zip" "Location",
A."Ph", A."Email", A."ORgId", A."ID",
A."SN" "OSN", A."Act"
from "TBL_OPTRS" A where A."ID" <> 0 ';
I'm displaying all rows in a report.
if I use 'select * from TBL_OPTRS' , this also takes 4.3 to 4.6 secs.
Thanks.

Query is taking too long fetch data

Similar Messages

Maybe you are looking for