Query taking so long to execute.

I have one table with 211 rows, When i am executing Delete from TEHSIL_TBL; its taking too long time to delete 211 rows. I execute explain plan then i am getting the following results.
SQL> explain plan for delete from TEHSIL_TBL;
Explained.
SQL> @C:\oracle\product\10.2.0\db_1\RDBMS\ADMIN\utlxpls.sql
PLAN_TABLE_OUTPUT
Plan hash value: 3350021484
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | DELETE STATEMENT | | 205 | 1435 | 1 (0)| 00:00:01 |
| 1 | DELETE | TEHSIL_TBL | | | | |
| 2 | INDEX FULL SCAN| PK_TEH_ID | 205 | 1435 | 1 (0)| 00:00:01 |
Please suggest why that query taking so long tome to execute.
Thanks in Advance...
Asmit

966523 wrote:
I have one table with 211 rows, When i am executing Delete from TEHSIL_TBL; its taking too long time to delete 211 rows. I execute explain plan then i am getting the following results.
SQL> explain plan for delete from TEHSIL_TBL;
Explained.
SQL> @C:\oracle\product\10.2.0\db_1\RDBMS\ADMIN\utlxpls.sql
PLAN_TABLE_OUTPUT
Plan hash value: 3350021484
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | DELETE STATEMENT | | 205 | 1435 | 1 (0)| 00:00:01 |
| 1 | DELETE | TEHSIL_TBL | | | | |
| 2 | INDEX FULL SCAN| PK_TEH_ID | 205 | 1435 | 1 (0)| 00:00:01 |
Please suggest why that query taking so long tome to execute.Please quantify "long time".
>
>
Thanks in Advance...
AsmitEXPLAIN PLAN shows time of 1 SECOND!
How must faster should it be?

Similar Messages

Query taking too long to execute after clone

Hi All,
We have a query which is working fine in our development environment and taking around 15 secs to execute the query. When we run the same query with same parameters in a recently cloned instance, the query is taking 1200 secs to execute.
Please help us on this issue.
Thanks,
Raghava

Hi All,
I have 4 unions in my query. individual sqls are running in very less time. But when i use all of them in UNION then im getting performance issue. Below is my query:
SELECT /*+ parallel(xla_l) parallel(xla_h) leading(xla_h) */
XLA_L.code_combination_id,
gl.name,
fnd_flex_ext.get_segs('SQLGL', 'GL#', gl.chart_of_accounts_id, xla_l.code_combination_id) ACCOUNT,
xla_oa_functions_pkg.get_ccid_description (gl.chart_of_accounts_id, xla_l.code_combination_id) account_description ,
xla_h.accounting_date,
XLA_L.accounting_class_code,
NVL(lk7.meaning, xla_l.accounting_class_code) accounting_class,
xla_h.entity_id,
xla_h.event_type_code,
et.event_class_code,
bud.budget_name,
xla_h.ledger_id,
xla_l.entered_dr,
xla_l.entered_cr,
te.ledger_id trx_ledger_id,
te.legal_entity_id,
et.entity_code,
te.source_id_int_1,
te.source_id_int_2,
te.source_id_int_3,
te.source_id_int_4,
te.source_id_char_1,
te.source_id_char_2,
te.source_id_char_3,
te.source_id_char_4,
te.security_id_int_1,
te.security_id_int_2,
te.security_id_int_3,
te.security_id_char_1,
te.security_id_char_2,
te.security_id_char_3,
te.valuation_method,
xla_h.application_id,
xs.drilldown_procedure_name,
GL_CUSTOM_DRILL_DOWN.get_trx_description(te.source_id_int_1,et.entity_code) description,
null fleet_number,
null Vendor_Name,
xs.je_source_name JournalSource,
xla_h.je_category_name JournalCategory,
XLA_L.AE_LINE_NUM Line
FROM xla.xla_ae_lines XLA_L,
xla.xla_ae_headers xla_h,
xla_gl_ledgers_v gl ,
xla_lookups lk5 ,
xla_lookups lk7,
xla.xla_events xla_e ,
xla.xla_event_types_tl et ,
xla.xla_event_classes_tl ec ,
xla.xla_transaction_entities te,
gl_budget_versions bud ,
--gl_import_references ir,
xla.xla_subledgers xs
--gl_je_lines gl_l
where
--ir.gl_sl_link_id=XLA_L.gl_sl_link_id
--and ir.gl_sl_link_table=XLA_L.gl_sl_link_table
--and gl.ledger_id = xla_h.ledger_id
--AND
xla_h.ae_header_id = xla_l.ae_header_id
AND xla_h.application_id = xla_l.application_id
AND lk7.lookup_code(+) = xla_l.accounting_class_code
AND lk7.lookup_type(+) = 'XLA_ACCOUNTING_CLASS'
AND xla_e.event_id = xla_h.event_id
AND xla_e.application_id = xla_h.application_id
AND xs.application_id =xla_h.application_id
AND te.entity_id =xla_h.entity_id
AND te.application_id =xla_l.application_id --xla_h.application_id
AND ec.application_id = et.application_id
AND ec.entity_code = et.entity_code
AND ec.event_class_code = et.event_class_code
AND ec.language = USERENV('LANG')
AND et.application_id = xla_h.application_id
AND et.event_type_code = xla_h.event_type_code
AND et.language = USERENV('LANG')
AND lk5.lookup_code = NVL(xla_h.funds_status_code, 'REQUIRED')
AND lk5.lookup_type = 'XLA_FUNDS_STATUS'
AND bud.budget_version_id(+) = xla_h.budget_version_id
and xs.je_source_name != 'Cost Management'
and (xla_l.gl_sl_link_id,xla_l.gl_sl_link_table) in (select ir.gl_sl_link_id, ir.gl_sl_link_table from
gl_import_references ir,
gl_je_lines gl_l
where ir.je_header_id = gl_l.je_header_id
and gl_l.je_line_num=ir.je_line_num
and gl_l.period_name =NVL(:1,gl_l.period_name)
and gl_l.code_combination_id =:2)
UNION
SELECT
lines.code_combination_id LINE_CODE_COMBINATION_ID,
lr.target_ledger_name LEDGER_NAME,
fnd_flex_ext.get_segs('SQLGL', 'GL#', b.chart_of_accounts_id, lines.code_combination_id) ACCOUNT,
xla_oa_functions_pkg.get_ccid_description (b.chart_of_accounts_id, lines.code_combination_id) account_description,
h.date_created,
null,
null,
null,
null,
null,
null,
h.ledger_id LEDGER_ID,
lines.entered_dr LINE_ENTERED_DR,
lines.entered_cr LINE_ENTERED_CR,
lines.ledger_id LINE_LEDGER_ID,
null,
null,
null,
null,
null,
null,
null,
null,
null,
null,
null,
null,
null,
null,
null,
null,
null,
null,
null,
lines.description LINE_DESCRIPTION,
null FLEET_NUMBER,
null Vendor_Name,
h.je_source JournalSource,
h.je_category JournalCategory,
lines.JE_LINE_NUM Line
FROM gl_period_statuses ps,
gl_je_lines lines,
gl_je_headers h,
gl_je_batches b,
gl_ledger_relationships lr
WHERE lr.source_ledger_id = lr.target_ledger_id
--AND lr.target_currency_code = DECODE ( GLR03300_pkg.get_ledger_currency, 'ALL123456789012345', lr.target_currency_code, GLR03300_pkg.get_ledger_currency )
AND lr.application_id = 101
AND b.average_journal_flag = 'N'
AND b.je_batch_id = h.je_batch_id
AND b.actual_flag = 'A'
AND h.je_header_id = lines.je_header_id
AND h.currency_code = DECODE ( GLR03300_PKG.get_entered_currency_code, 'ALL123456789012345', h.currency_code, NULL, h.currency_code, GLR03300_pkg.get_entered_currency_code )
AND h.ledger_id = lr.source_ledger_id
AND lines.period_name = ps.period_name
and lines.period_name = NVL(:3,lines.period_name)
AND ps.ledger_id = lines.ledger_id
AND ps.application_id = 101
AND lines.code_combination_id=:4
AND h.je_source != 'Cost Management'
UNION
SELECT /*+ parallel(xla_l) parallel(xla_h) leading(xla_h) */ gl_l.code_combination_id LINE_CODE_COMBINATION_ID,
gl.name,
fnd_flex_ext.get_segs('SQLGL', 'GL#', gl.chart_of_accounts_id, xla_l.code_combination_id) ACCOUNT,
xla_oa_functions_pkg.get_ccid_description (gl.chart_of_accounts_id, xla_l.code_combination_id) account_description,
xla_h.accounting_date,--gjh.date_created,
XLA_L.accounting_class_code,
NVL(lk7.meaning, xla_l.accounting_class_code) accounting_class,
null,
null,
null,
null,
xla_h.ledger_id LEDGER_ID,
NVL(xla_l.entered_dr,0) LINE_ENTERED_DR,
NVL(xla_l.entered_cr,0) LINE_ENTERED_CR,
te.ledger_id trx_ledger_id,
te.legal_entity_id,
et.entity_code,
te.source_id_int_1,
te.source_id_int_2,
te.source_id_int_3,
te.source_id_int_4,
te.source_id_char_1,
te.source_id_char_2,
te.source_id_char_3,
te.source_id_char_4,
te.security_id_int_1,
te.security_id_int_2,
te.security_id_int_3,
te.security_id_char_1,
te.security_id_char_2,
te.security_id_char_3,
te.valuation_method,
xla_h.application_id,
xs.drilldown_procedure_name,
GL_CUSTOM_DRILL_DOWN.get_trx_description(te.source_id_int_1,et.entity_code) description,-- gl_l.description LINE_DESCRIPTION,
cii.instance_number FLEET_NUMBER,
(select a.vendor_name
from RCV_VRC_TXS_VENDINT_V a
where a.wip_entity_id = mmt.TRANSACTION_SOURCE_ID
AND a.organization_id = mmt.organization_id
and a.item_id = mmt.inventory_item_id) Vendor_Name,
xs.je_source_name JournalSource,
xla_h.je_category_name JournalCategory,
gl_l.JE_LINE_NUM Line
FROM xla.xla_ae_lines XLA_L,
xla.xla_ae_headers xla_h,
xla_gl_ledgers_v gl ,
xla_lookups lk5,
xla_lookups lk7,
xla.xla_events xla_e ,
xla.xla_event_types_tl et,
xla.xla_event_classes_tl ec,
xla.xla_transaction_entities te,
gl_budget_versions bud,
gl_import_references ir,
xla.xla_subledgers xs,
gl_je_lines gl_l,
mtl_transaction_accounts mta,
XLA_TRANSACTION_ENTITIES_upg xte,
xla_distribution_links xdl,
mtl_material_transactions mmt,
WIP_ENTITIES WIE,
WIP_DISCRETE_JOBS WDJ,
csi_item_instances CII
where
ir.gl_sl_link_id=XLA_L.gl_sl_link_id
and ir.je_header_id = gl_l.je_header_id
and gl_l.je_line_num=ir.je_line_num
and ir.gl_sl_link_table=XLA_L.gl_sl_link_table
and gl_l.period_name =NVL(:5,gl_l.period_name)
and gl_l.code_combination_id = :6
and xla_h.ae_header_id = xla_l.ae_header_id
AND xla_h.application_id = xla_l.application_id
AND lk7.lookup_code(+) = xla_l.accounting_class_code
AND lk7.lookup_type(+) = 'XLA_ACCOUNTING_CLASS'
AND xla_e.event_id = xla_h.event_id
AND xla_e.application_id = xla_h.application_id
AND xs.application_id =xla_h.application_id
AND te.entity_id =xla_h.entity_id
AND te.application_id =xla_l.application_id --xla_h.application_id
AND ec.application_id = et.application_id
AND ec.entity_code = et.entity_code
AND ec.event_class_code = et.event_class_code
AND ec.language = USERENV('LANG')
AND et.application_id = xla_h.application_id
AND et.event_type_code = xla_h.event_type_code
AND et.language = USERENV('LANG')
AND lk5.lookup_code = NVL(xla_h.funds_status_code, 'REQUIRED')
AND lk5.lookup_type = 'XLA_FUNDS_STATUS'
AND bud.budget_version_id(+) = xla_h.budget_version_id
AND mta.reference_account = gl_l.code_combination_id
AND mmt.transaction_id = mta.transaction_id
and mta.transaction_id = xte.source_id_int_1
AND mta.inventory_item_id =mmt.inventory_item_id
AND mta.organization_id = mmt.organization_id
AND mmt.transaction_type_id = 35
and xte.entity_id = xla_e.entity_id
and xdl.source_distribution_type = 'MTL_TRANSACTION_ACCOUNTS'
and xdl.source_distribution_id_num_1 = mta.inv_sub_ledger_id
and xdl.APPLICATION_ID=707
and xla_h.ae_header_id = xdl.ae_header_id
and xdl.ae_header_id = XLA_L.ae_header_id
and ir.gl_sl_link_table = 'XLAJEL'
and ir.gl_sl_link_id = XLA_L.gl_sl_link_id
and gl_l.je_header_id = ir.je_header_id
and gl_l.je_line_num = ir.je_line_num
and mmt.TRANSACTION_SOURCE_ID = wie.wip_entity_id
AND mmt.organization_id = wdj.organization_id
and wie.wip_entity_id = wdj.wip_entity_id
and wdj.asset_group_id = cii.inventory_item_id
and wdj.maintenance_object_id=cii.instance_id
and xs.je_source_name = 'Cost Management'
UNION
SELECT /*+ parallel(XLA_L) parallel(xla_h) leading(xla_h) */ gl_l.code_combination_id LINE_CODE_COMBINATION_ID,
gl.name,
fnd_flex_ext.get_segs('SQLGL', 'GL#', gl.chart_of_accounts_id, xla_l.code_combination_id) ACCOUNT,
xla_oa_functions_pkg.get_ccid_description (gl.chart_of_accounts_id, xla_l.code_combination_id) account_description,
xla_h.accounting_date,--gjh.date_created,
XLA_L.accounting_class_code,
NVL(lk7.meaning, xla_l.accounting_class_code) accounting_class,
null,
null,
null,
null,
xla_h.ledger_id LEDGER_ID,
NVL(xla_l.entered_dr,0) LINE_ENTERED_DR,
NVL(xla_l.entered_cr,0) LINE_ENTERED_CR,
te.ledger_id trx_ledger_id,
te.legal_entity_id,
et.entity_code,
te.source_id_int_1,
te.source_id_int_2,
te.source_id_int_3,
te.source_id_int_4,
te.source_id_char_1,
te.source_id_char_2,
te.source_id_char_3,
te.source_id_char_4,
te.security_id_int_1,
te.security_id_int_2,
te.security_id_int_3,
te.security_id_char_1,
te.security_id_char_2,
te.security_id_char_3,
te.valuation_method,
xla_h.application_id,
xs.drilldown_procedure_name,
GL_CUSTOM_DRILL_DOWN.get_trx_description(te.source_id_int_1,et.entity_code) description,-- gl_l.description LINE_DESCRIPTION,
cii.instance_number FLEET_NUMBER,
(select a.vendor_name
from RCV_VRC_TXS_VENDINT_V a
where a.wip_entity_id = wta.wip_entity_id
AND a.organization_id = wta.organization_id
and a.item_id = cii.inventory_item_id) Vendor_Name,
xs.je_source_name JournalSource,
xla_h.je_category_name JournalCategory,
gl_l.JE_LINE_NUM Line
FROM xla.xla_ae_lines XLA_L,
xla.xla_ae_headers xla_h,
xla_gl_ledgers_v gl ,
xla_lookups lk5,
xla_lookups lk7,
xla.xla_events xla_e ,
xla.xla_event_types_tl et,
xla.xla_event_classes_tl ec,
xla.xla_transaction_entities te,
gl_budget_versions bud,
gl_import_references ir,
xla.xla_subledgers xs,
gl_je_lines gl_l,
wip_transaction_accounts wta,
XLA_TRANSACTION_ENTITIES_upg xte,
xla_distribution_links xdl,
-- mtl_material_transactions mmt,
WIP_ENTITIES WIE,
WIP_DISCRETE_JOBS WDJ,
csi_item_instances CII
where
ir.gl_sl_link_table=XLA_L.gl_sl_link_table
and gl_l.period_name =NVL(:7,gl_l.period_name)
and gl_l.code_combination_id = :8
and xla_h.ae_header_id = xla_l.ae_header_id
AND xla_h.application_id = xla_l.application_id
AND lk7.lookup_code(+) = xla_l.accounting_class_code
AND lk7.lookup_type(+) = 'XLA_ACCOUNTING_CLASS'
AND xla_e.event_id = xla_h.event_id
AND xla_e.application_id = xla_h.application_id
AND xs.application_id =xla_h.application_id
AND te.entity_id =xla_h.entity_id
AND te.application_id =xla_l.application_id --xla_h.application_id
AND ec.application_id = et.application_id
AND ec.entity_code = et.entity_code
AND ec.event_class_code = et.event_class_code
AND ec.language = USERENV('LANG')
AND et.application_id = xla_h.application_id
AND et.event_type_code = xla_h.event_type_code
AND et.language = USERENV('LANG')
AND lk5.lookup_code = NVL(xla_h.funds_status_code, 'REQUIRED')
AND lk5.lookup_type = 'XLA_FUNDS_STATUS'
AND bud.budget_version_id(+) = xla_h.budget_version_id
AND wta.reference_account = gl_l.code_combination_id
and wta.transaction_id = xte.source_id_int_1(+)
and xte.entity_id = xla_e.entity_id
and xdl.source_distribution_type = 'WIP_TRANSACTION_ACCOUNTS'
and xdl.source_distribution_id_num_1 = wta.wip_sub_ledger_id(+)
and xdl.APPLICATION_ID=707
and xla_h.ae_header_id = xdl.ae_header_id
and xdl.ae_header_id = XLA_L.ae_header_id
and ir.gl_sl_link_table = 'XLAJEL'
and ir.gl_sl_link_id = XLA_L.gl_sl_link_id
and gl_l.je_header_id = ir.je_header_id
and gl_l.je_line_num = ir.je_line_num
and wie.wip_entity_id = wta.wip_entity_id
AND wta.organization_id = wdj.organization_id
and wie.wip_entity_id = wdj.wip_entity_id
and wdj.asset_group_id = cii.inventory_item_id
and wdj.maintenance_object_id=cii.instance_id
and xs.je_source_name = 'Cost Management'
Please help me in tuning the above query.
Thanks
Raghava

Query taking too long to execute

Hi All,
I have just moved a cube from DEV to Q and loaded the data(using INIT). I have created a query to test the data. When I execute the query, the initial result is showing up quickly but when I drill down using one char, say CHAR ABC, it is taking a lot time(I am waiting from last 25 min to see the result but it is still running). The same query is not taking any time when run in T. What could be the problem. This query is my first query in Q.
Any suggestions would be highly appreciated.
Best Rgds,
James.

GO to RSRV and you will see a an option " All combined tests.
IN that, you will see " Check data for master data". Double click that and enter your CHAR* and run the test.
Next under transaction data " run each of the tests" for the ODS / Cube that you run the report from.
These tests usually will point to inconsistency. You may also want to look the design of cube / ODS. In ODS, you may have to check the key fields.
Ravi Thothadri

Reasons for query taking so long to execute?

Hi All,
We have a table in our database which contains more than 7 million records. The table has 34 columns. We have defined a unique identifier to act as primary key for the table, (which is a number, generated from a sequence)
When I execute the below mentioned query, it takes on an average more than 6 minutes to fecth the records!
SELECT * FROM MY_TABLE
ORDER BY year_prd
year_prd stores the year in YYYY format and is defined as simply NUMBER data type in table definition. An index is already defined over this column.
Can you let me know what may be the possible reason for such a delay? What's the area I should be looking to get this fixed ASAP.
Any help will be highly appreciated!
Thanks!

Actually, there's a front-end app (Search Application). There are a hell lot of search criterion for the users and they can seach based on one or more attributes.
The problem is that the end result which is returned to them has to be sorted on year_prd field! The search criteria by the users might fetch a single record or 10000 records. In no case all 7 million records are fetched :) But in recent days we are seeing that for some cirterion users are getting 1000+ records returned and its taking too much time.
When we did a backtrack, we came across that the ordering on year_prd is the thing which is killing us and in doing so I executed the above stmt (query posted by me) and came across the depressing results.
Let me know if I need to furnish more details.
Thanks!

Query taking to long to execute

Oracle9i Enterprise Edition Release 9.2.0.7.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.7.0 - Production
System: Microsoft Windows Server 2003 Enterprise Edition
Hello SAP/Oracle experts. Can someone please give me some feedback on why a query using a prime key would take 4 seconds to execute on a table with only 300,000 records?????
Thanks for your time.

Hi,
Perhaps you can take a look at what the query exactly is doing.
Check if you can find the query on the sql cache ( st04 -> detail analysis menu -> SQL Request )
There you can consult the explain plan as mentioned by Vinod, but also other data -> buffer gets, disk reads, rows ...
Also, you mention that the query is using the primary key, but, does the conditions on the query "MATCH" the primary key?
Rgds

Query taking too long to execute on Oracle 9i

Mark,
If you remember, I was working on a large xml document with deep nested complex elements.
I am trying to query the document and as such I am running a join query. The database is not able to run this query and I am wondering if there is any alternate way to rephrase this query.
PS: I have run this query for almost 24 hrs without any result.
Here is the query:
select extract(value(X),'//eNest[@aSixtyFour=2][@aUnique1=//eNest[@aSixtyFour=2]/@aUnique1]/@aUnique1')
from OracleBench_No_Schema X
any feedback would be extremely helpful
Thanks
JN

John
I'm not sure that I can be of much more help at the moment. We are working to improive the performance of //queries over recursive structures. These enhancements will appear in future release of the product.

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.

Sql Query taking very long time to complete

Hi All,
DB:oracle 9i R2
OS:sun solaris 8
Below is the Sql Query taking very long time to complete
Could any one help me out regarding this.
SELECT MAX (md1.ID) ID, md1.request_id, md1.jlpp_transaction_id,
md1.transaction_version
FROM transaction_data_arc md1
WHERE md1.transaction_name = :b2
AND md1.transaction_type = 'REQUEST'
AND md1.message_type_code = :b1
AND NOT EXISTS (
SELECT NULL
FROM transaction_data_arc tdar2
WHERE tdar2.request_id = md1.request_id
AND tdar2.jlpp_transaction_id != md1.jlpp_transaction_id
AND tdar2.ID > md1.ID)
GROUP BY md1.request_id,
md1.jlpp_transaction_id,
md1.transaction_version
Any alternate query to get the same results?
kindly let me know if any one knows.
regards,
kk.
Edited by: kk001 on Apr 27, 2011 11:23 AM

Dear
/* Formatted on 2011/04/27 08:32 (Formatter Plus v4.8.8) */
SELECT   MAX (md1.ID) ID, md1.request_id, md1.jlpp_transaction_id,
         md1.transaction_version
    FROM transaction_data_arc md1
   WHERE md1.transaction_name = :b2
     AND md1.transaction_type = 'REQUEST'
     AND md1.message_type_code = :b1
     AND NOT EXISTS (
            SELECT NULL
              FROM transaction_data_arc tdar2
             WHERE tdar2.request_id = md1.request_id
               AND tdar2.jlpp_transaction_id != md1.jlpp_transaction_id
               AND tdar2.ID > md1.ID)
GROUP BY md1.request_id
        ,md1.jlpp_transaction_id
        ,md1.transaction_versionCould you please post here :
(a) the available indexes on transaction_data_arc table
(b) the description of transaction_data_arc table
(c) and the formatted explain plan you will get after executing the query and issuing:
select * from table (dbms_xplan.display_cursor);Hope this helps
Mohamed Houri

Update statement taking too long to execute

Hi All,
I'm trying to run this update statement. But its taking too long to execute.
    UPDATE ops_forecast_extract b SET position_id = (SELECT a.row_id
        FROM s_postn a
        WHERE UPPER(a.desc_text) = UPPER(TRIM(B.POSITION_NAME)))
        WHERE position_level = 7
        AND b.am_id IS NULL;
        SELECT COUNT(*) FROM S_POSTN;
        214665
        SELECT COUNT(*) FROM ops_forecast_extract;
        49366
SELECT count(*)
        FROM s_postn a, ops_forecast_extract b
        WHERE UPPER(a.desc_text) = UPPER(TRIM(B.POSITION_NAME));
575What could be the reason for update statement to execute so long?
Thanks

polasa wrote:
Hi All,
I'm trying to run this update statement. But its taking too long to execute.
What could be the reason for update statement to execute so long?You haven't said what "too long" means, but a simple reason could be that the scalar subquery on "s_postn" is using a full table scan for each execution. Potentially this subquery gets executed for each row of the "ops_forecast_extract" table that satisfies your filter predicates. "Potentially" because of the cunning "filter/subquery optimization" of the Oracle runtime engine that attempts to cache the results of already executed instances of the subquery. Since the in-memory hash table that holds these cached results is of limited size, the optimization algorithm depends on the sort order of the data and could suffer from hash collisions it's unpredictable how well this optimization works in your particular case.
You might want to check the execution plan, it should tell you at least how Oracle is going to execute the scalar subquery (it doesn't tell you anything about this "filter/subquery optimization" feature).
Generic instructions how to generate a useful explain plan output and how to post it here follow:
Could you please post an properly formatted explain plan output using DBMS_XPLAN.DISPLAY including the "Predicate Information" section below the plan to provide more details regarding your statement. Please use the {noformat}[{noformat}code{noformat}]{noformat} tag before and {noformat}[{noformat}/code{noformat}]{noformat} tag after or the {noformat}{{noformat}code{noformat}}{noformat} tag before and after to enhance readability of the output provided:
In SQL*Plus:
SET LINESIZE 130
EXPLAIN PLAN FOR <your statement>;
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);Note that the package DBMS_XPLAN.DISPLAY is only available from 9i on.
In 9i and above, if the "Predicate Information" section is missing from the DBMS_XPLAN.DISPLAY output but you get instead the message "Plan table is old version" then you need to re-create your plan table using the server side script "$ORACLE_HOME/rdbms/admin/utlxplan.sql".
In previous versions you could run the following in SQL*Plus (on the server) instead:
@?/rdbms/admin/utlxplsA different approach in SQL*Plus:
SET AUTOTRACE ON EXPLAIN
<run your statement>;will also show the execution plan.
In order to get a better understanding where your statement spends the time you might want to turn on SQL trace as described here:
When your query takes too long ...
and post the "tkprof" output here, too.
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/

UIMsg_RefreshWindows is taking too long to execute

Hi all,
I have a Process Model sequence file that calls the PostUIMessageEx method with the UIMsg_RefreshWindows parameter on the SequenceFielPostStepRuntimeError and the SequenceFilePostStepFailure callbacks. This has been taking really long to execute (>3 minutes) since I moved to TS3.5 about a month ago. Do you guys know of any issue of this method with these particular parameters on TS3.5? What could be causing this problem?
Attachments:
UIMsg.jpg ‏92 KB

Hi, <<...
There is nothing out of normal among your parameters. The synchronize option you selected is going to make the method wait until the operator interface process the message. So it depends on what you put in your UI message event handler. I'm not aware of anything related to this method itself that could cause this slow execution behavior. If you could send us a simplified version of the project, maybe we can further investigate the issue.
Song D
Regards,
Song Du
Systems Software
National Instruments R&D

Query taking too long, yet cost is low

hi guys,
I am running a query on two databases that were created the same way and have the same data.
On one the cost is nearly a million, and it runs in a matter of a few seconds
On the other, the cost is 40000, and it doesn't finish executing
I have looked at the explain plan, and there is no cartesian merge join on the second query, yet it is taking so long. What can I do to investigate this?
thanks

Could you please post an properly formatted explain plan output using DBMS_XPLAN.DISPLAY including the "Predicate Information" section below the plan to provide more details regarding your statement. Please use the \[code\] and \[code\] tags to enhance readability of the output provided:
In SQL*Plus:
SET LINESIZE 130
EXPLAIN PLAN FOR <your statement>;
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);Note that the package DBMS_XPLAN.DISPLAY is only available from 9i on.
In previous versions you could run the following in SQL*Plus (on the server) instead:
@?/rdbms/admin/utlxplsA different approach in SQL*Plus:
SET AUTOTRACE ON EXPLAIN
<run your statement>;will also show the execution plan.
In order to get a better understanding where your statement spends the time you might want to turn on SQL trace as described here:
[When your query takes too long|http://forums.oracle.com/forums/thread.jspa?threadID=501834]
and post the "tkprof" output here, too.
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/

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 ?

Query taking very long time

DB 11.2.0.3.4
Server HP-UX IA 11.31
One big query is taking very long time. I am giving the explain plan along with stats from tkprof. If needed will give the query also. Can sombody tell me how can we improve this.
call     count       cpu    elapsed       disk      query    current        rows
Parse        1     23.26      23.90          0         20          0           0
Execute      1   8055.11    9453.52     684215     348696   18750740     1306001
Fetch        0      0.00       0.00          0          0          0           0
total        2   8078.37    9477.42     684215     348716   18750740     1306001
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 322 (EDW_DM)   (recursive depth: 1)
Rows     Row Source Operation
      0 LOAD TABLE CONVENTIONAL (cr=352254 pr=684215 pw=682074 time=863655932 us)
1306001   PX COORDINATOR (cr=15823 pr=682074 pw=682074 time=499947892 us)
      0    PX SEND QC (RANDOM) :TQ20004 (cr=0 pr=0 pw=0 time=0 us cost=276195 size=126736955032 card=9998182)
      0     BUFFER SORT (cr=0 pr=0 pw=0 time=0 us)
      0      VIEW VW_FCT_PLN_SUMM_ADL_WK_XARH317 (cr=0 pr=0 pw=0 time=0 us cost=276195 size=126736955032 card=9998182)
      0       UNION-ALL (cr=0 pr=0 pw=0 time=0 us)
      0        SORT GROUP BY (cr=0 pr=0 pw=0 time=0 us cost=9167 size=95469948 card=378849)
      0         PX RECEIVE (cr=0 pr=0 pw=0 time=0 us cost=9167 size=95469948 card=378849)
      0          PX SEND HASH :TQ20003 (cr=0 pr=0 pw=0 time=0 us cost=9167 size=95469948 card=378849)
      0           SORT GROUP BY (cr=0 pr=0 pw=0 time=0 us cost=9167 size=95469948 card=378849)
      0            HASH JOIN RIGHT SEMI (cr=0 pr=0 pw=0 time=0 us cost=2714 size=95469948 card=378849)
      0             BUFFER SORT (cr=0 pr=0 pw=0 time=0 us)
      0              PX RECEIVE (cr=0 pr=0 pw=0 time=0 us cost=26 size=16428 card=4107)
      0               PX SEND BROADCAST :TQ20000 (cr=0 pr=0 pw=0 time=0 us cost=26 size=16428 card=4107)
   4857                VIEW VW_SQ_1 (cr=47 pr=0 pw=0 time=25403 us cost=26 size=16428 card=4107)
   4857                 HASH JOIN (cr=47 pr=0 pw=0 time=23353 us cost=26 size=229992 card=4107)
   1115                  TABLE ACCESS FULL DMN_PROD (cr=11 pr=0 pw=0 time=863 us cost=6 size=13380 card=1115)
   4873                  HASH JOIN (cr=36 pr=0 pw=0 time=12991 us cost=20 size=180840 card=4110)
     55                   TABLE ACCESS FULL DMN_MKT_DEFN (cr=3 pr=0 pw=0 time=286 us cost=4 size=1980 card=55)
18235                   TABLE ACCESS FULL FCT_MKT_PROD_BRDG (cr=33 pr=0 pw=0 time=13550 us cost=15 size=145880 card=18235)
      0             HASH JOIN (cr=0 pr=0 pw=0 time=0 us cost=2686 size=93954552 card=378849)
      0              BUFFER SORT (cr=0 pr=0 pw=0 time=0 us)
      0               PX RECEIVE (cr=0 pr=0 pw=0 time=0 us cost=111 size=403328 card=8768)
      0                PX SEND BROADCAST :TQ20001 (cr=0 pr=0 pw=0 time=0 us cost=111 size=403328 card=8768)
   8768                 NESTED LOOPS (cr=274 pr=0 pw=0 time=15077 us cost=111 size=403328 card=8768)
      1                  NESTED LOOPS (cr=5 pr=0 pw=0 time=203 us cost=5 size=28 card=1)
      1                   TABLE ACCESS FULL DMN_WK_END (cr=2 pr=0 pw=0 time=81 us cost=3 size=8 card=1)
      1                   TABLE ACCESS BY INDEX ROWID DMN_CALN (cr=3 pr=0 pw=0 time=110 us cost=2 size=20 card=1)
      1                    INDEX RANGE SCAN XNU1_DMN_CALN (cr=2 pr=0 pw=0 time=73 us cost=1 size=0 card=1)(object id 303867)
   8768                  TABLE ACCESS FULL DMN_CALN (cr=269 pr=0 pw=0 time=11719 us cost=106 size=157824 card=8768)
      0              PX BLOCK ITERATOR PARTITION: KEY KEY (cr=0 pr=0 pw=0 time=0 us cost=2573 size=76527498 card=378849)
      0               TABLE ACCESS FULL FCT_NONRET_SLS_CURR_TRANS_WKLY PARTITION: 32 32 (cr=0 pr=0 pw=0 time=0 us cost=2573 size=76527498 card=378849)
      0        BUFFER SORT (cr=0 pr=0 pw=0 time=0 us)
      0         PX RECEIVE (cr=0 pr=0 pw=0 time=0 us cost=267028 size=2741509905 card=9619333)
      0          PX SEND ROUND-ROBIN :TQ20002 (cr=0 pr=0 pw=0 time=0 us cost=267028 size=2741509905 card=9619333)
1284599           SORT GROUP BY (cr=15497 pr=682074 pw=682074 time=3839060439 us cost=267028 size=2741509905 card=9619333)
6439189            FILTER (cr=15486 pr=0 pw=0 time=57890179 us)
8986531             PX COORDINATOR (cr=279 pr=0 pw=0 time=52453034 us)
      0              PX SEND QC (RANDOM) :TQ10001 (cr=0 pr=0 pw=0 time=0 us cost=80940 size=2741509905 card=9619333)
      0               HASH JOIN (cr=0 pr=0 pw=0 time=0 us cost=80940 size=2741509905 card=9619333)
      0                BUFFER SORT (cr=0 pr=0 pw=0 time=0 us)
      0                 PX RECEIVE (cr=0 pr=0 pw=0 time=0 us cost=111 size=403328 card=8768)
      0                  PX SEND BROADCAST :TQ10000 (cr=0 pr=0 pw=0 time=0 us cost=111 size=403328 card=8768)
   8768                   NESTED LOOPS (cr=274 pr=0 pw=0 time=14462 us cost=111 size=403328 card=8768)
      1                    NESTED LOOPS (cr=5 pr=0 pw=0 time=345 us cost=5 size=28 card=1)
      1                     TABLE ACCESS FULL DMN_WK_END (cr=2 pr=0 pw=0 time=193 us cost=3 size=8 card=1)
      1                     TABLE ACCESS BY INDEX ROWID DMN_CALN (cr=3 pr=0 pw=0 time=136 us cost=2 size=20 card=1)
      1                      INDEX RANGE SCAN XNU1_DMN_CALN (cr=2 pr=0 pw=0 time=76 us cost=1 size=0 card=1)(object id 303867)
   8768                    TABLE ACCESS FULL DMN_CALN (cr=269 pr=0 pw=0 time=9447 us cost=106 size=157824 card=8768)
      0                PX BLOCK ITERATOR PARTITION: KEY KEY (cr=0 pr=0 pw=0 time=0 us cost=80801 size=2299020587 card=9619333)
      0                 TABLE ACCESS FULL FCT_PLN_RET_SLS_CURR_WKLY PARTITION: 30 30 (cr=0 pr=0 pw=0 time=0 us cost=80801 size=2299020587 card=9619333)
    834             NESTED LOOPS (cr=15207 pr=0 pw=0 time=990747 us)
   2269              NESTED LOOPS (cr=12938 pr=0 pw=0 time=1090852 us cost=17 size=56 card=1)
   2269               NESTED LOOPS (cr=12101 pr=0 pw=0 time=1065238 us cost=16 size=20 card=1)
    834                TABLE ACCESS BY INDEX ROWID DMN_PROD (cr=1676 pr=0 pw=0 time=37175 us cost=1 size=12 card=1)
    838                 INDEX UNIQUE SCAN XPKDIMENSION_PRODUCT (cr=838 pr=0 pw=0 time=23645 us cost=0 size=0 card=1)(object id 303870)
   2269                TABLE ACCESS FULL FCT_MKT_PROD_BRDG (cr=10425 pr=0 pw=0 time=1024973 us cost=15 size=8 card=1)
   2269               INDEX UNIQUE SCAN SYS_C0040182 (cr=837 pr=0 pw=0 time=15842 us cost=0 size=0 card=1)(object id 301873)
    834              TABLE ACCESS BY INDEX ROWID DMN_MKT_DEFN (cr=2269 pr=0 pw=0 time=16488 us cost=1 size=36 card=1)
It would be appreciated if somebody check this.
Regards,
Virendra

Below is with the index on one of the table:
call     count       cpu    elapsed       disk      query    current        rows
Parse        1     49.33      49.61          0         16          0           0
Execute      1   8374.08   10745.82     953712     473861   18818854     1306001
Fetch        0      0.00       0.00          0          0          0           0
total        2   8423.41   10795.43     953712     473877   18818854     1306001
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 322     (recursive depth: 1)
Rows     Row Source Operation
      0 LOAD TABLE CONVENTIONAL (cr=481416 pr=953712 pw=917687 time=2156047932 us)
1306001   PX COORDINATOR (cr=131828 pr=917687 pw=917687 time=1528317728 us)
      0    PX SEND QC (RANDOM) :TQ10004 (cr=0 pr=0 pw=0 time=0 us cost=144212 size=16362383616 card=1290816)
      0     BUFFER SORT (cr=0 pr=0 pw=0 time=0 us)
      0      VIEW VW_FCT_PLN_SUM_ADL_WK_XRH317_1 (cr=0 pr=0 pw=0 time=0 us cost=144212 size=16362383616 card=1290816)
      0       UNION-ALL (cr=0 pr=0 pw=0 time=0 us)
      0        SORT GROUP BY (cr=0 pr=0 pw=0 time=0 us cost=9568 size=101394468 card=402359)
      0         PX RECEIVE (cr=0 pr=0 pw=0 time=0 us cost=9568 size=101394468 card=402359)
      0          PX SEND HASH :TQ10003 (cr=0 pr=0 pw=0 time=0 us cost=9568 size=101394468 card=402359)
      0           SORT GROUP BY (cr=0 pr=0 pw=0 time=0 us cost=9568 size=101394468 card=402359)
      0            HASH JOIN RIGHT SEMI (cr=0 pr=0 pw=0 time=0 us cost=2714 size=101394468 card=402359)
      0             BUFFER SORT (cr=0 pr=0 pw=0 time=0 us)
      0              PX RECEIVE (cr=0 pr=0 pw=0 time=0 us cost=26 size=16428 card=4107)
      0               PX SEND BROADCAST :TQ10000 (cr=0 pr=0 pw=0 time=0 us cost=26 size=16428 card=4107)
   4857                VIEW VW_SQ_1 (cr=47 pr=0 pw=0 time=25732 us cost=26 size=16428 card=4107)
   4857                 HASH JOIN (cr=47 pr=0 pw=0 time=23041 us cost=26 size=229992 card=4107)
   1115                  TABLE ACCESS FULL DMN_PROD (cr=11 pr=0 pw=0 time=1040 us cost=6 size=13380 card=1115)
   4873                  HASH JOIN (cr=36 pr=0 pw=0 time=12797 us cost=20 size=180840 card=4110)
     55                   TABLE ACCESS FULL DMN_MKT_DEFN (cr=3 pr=0 pw=0 time=185 us cost=4 size=1980 card=55)
18235                   TABLE ACCESS FULL FCT_MKT_PROD_BRDG (cr=33 pr=0 pw=0 time=10014 us cost=15 size=145880 card=18235)
      0             HASH JOIN (cr=0 pr=0 pw=0 time=0 us cost=2686 size=99785032 card=402359)
      0              BUFFER SORT (cr=0 pr=0 pw=0 time=0 us)
      0               PX RECEIVE (cr=0 pr=0 pw=0 time=0 us cost=111 size=403328 card=8768)
      0                PX SEND BROADCAST :TQ10001 (cr=0 pr=0 pw=0 time=0 us cost=111 size=403328 card=8768)
   8768                 NESTED LOOPS (cr=274 pr=0 pw=0 time=13429 us cost=111 size=403328 card=8768)
      1                  NESTED LOOPS (cr=5 pr=0 pw=0 time=206 us cost=5 size=28 card=1)
      1                   TABLE ACCESS FULL DMN_WK_END (cr=2 pr=0 pw=0 time=82 us cost=3 size=8 card=1)
      1                   TABLE ACCESS BY INDEX ROWID DMN_CALN (cr=3 pr=0 pw=0 time=111 us cost=2 size=20 card=1)
      1                    INDEX RANGE SCAN XNU1_DMN_CALN (cr=2 pr=0 pw=0 time=80 us cost=1 size=0 card=1)(object id 303867)
   8768                  TABLE ACCESS FULL DMN_CALN (cr=269 pr=0 pw=0 time=9306 us cost=106 size=157824 card=8768)
      0              PX BLOCK ITERATOR PARTITION: KEY KEY (cr=0 pr=0 pw=0 time=0 us cost=2573 size=81276518 card=402359)
      0               TABLE ACCESS FULL FCT_NONRET_SLS_CURR_TRANS_WKLY PARTITION: 32 32 (cr=0 pr=0 pw=0 time=0 us cost=2573 size=81276518 card=402359)
      0        BUFFER SORT (cr=0 pr=0 pw=0 time=0 us)
      0         PX RECEIVE (cr=0 pr=0 pw=0 time=0 us cost=134645 size=256764073 card=888457)
      0          PX SEND ROUND-ROBIN :TQ10002 (cr=0 pr=0 pw=0 time=0 us cost=134645 size=256764073 card=888457)
1284599           HASH GROUP BY (cr=131502 pr=917687 pw=917687 time=1052831032 us cost=134645 size=256764073 card=888457)
6439189            HASH JOIN RIGHT SEMI (cr=131490 pr=138092 pw=138092 time=374140098 us cost=100193 size=256764073 card=888457)
   4857             VIEW VW_SQ_2 (cr=47 pr=0 pw=0 time=22869 us cost=26 size=16428 card=4107)
   4857              HASH JOIN (cr=47 pr=0 pw=0 time=21073 us cost=26 size=229992 card=4107)
   1115               TABLE ACCESS FULL DMN_PROD (cr=11 pr=0 pw=0 time=687 us cost=6 size=13380 card=1115)
   4873               HASH JOIN (cr=36 pr=0 pw=0 time=12522 us cost=20 size=180840 card=4110)
     55                TABLE ACCESS FULL DMN_MKT_DEFN (cr=3 pr=0 pw=0 time=242 us cost=4 size=1980 card=55)
18235                TABLE ACCESS FULL FCT_MKT_PROD_BRDG (cr=33 pr=0 pw=0 time=9883 us cost=15 size=145880 card=18235)
8986531             HASH JOIN (cr=131443 pr=138092 pw=138092 time=402921160 us cost=100161 size=253210245 card=888457)
   8768              TABLE ACCESS FULL DMN_CALN (cr=269 pr=0 pw=0 time=11228 us cost=106 size=157824 card=8768)
8986531              MERGE JOIN CARTESIAN (cr=131174 pr=138092 pw=138092 time=382931385 us cost=100049 size=237218019 card=888457)
      1               NESTED LOOPS (cr=5 pr=0 pw=0 time=251 us)
      1                NESTED LOOPS (cr=4 pr=0 pw=0 time=225 us cost=5 size=28 card=1)
      1                 TABLE ACCESS FULL DMN_WK_END (cr=2 pr=0 pw=0 time=127 us cost=3 size=8 card=1)
      1                 INDEX RANGE SCAN XNU1_DMN_CALN (cr=2 pr=0 pw=0 time=88 us cost=1 size=0 card=1)(object id 303867)
      1                TABLE ACCESS BY INDEX ROWID DMN_CALN (cr=1 pr=0 pw=0 time=17 us cost=2 size=20 card=1)
8986531               BUFFER SORT (cr=131169 pr=138092 pw=138092 time=378126634 us cost=100047 size=212341223 card=888457)
8986531                TABLE ACCESS BY GLOBAL INDEX ROWID FCT_PLN_RET_SLS_CURR_WKLY PARTITION: 30 30 (cr=131157 pr=0 pw=0 time=144384133 us cost=100044 size=212341223 card=888457)
9066976                 INDEX RANGE SCAN SUBSTR_FCT_RET_SLS_CUR_WLY (cr=84385 pr=0 pw=0 time=93762049 us cost=83615 size=0 card=2856894)(object id 311617)
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
os thread startup                               2        0.08          0.15
PX Deq: Join ACK                                4        0.00          0.00
PX Deq Credit: send blkd                      455        2.21         55.10
PX Deq: Parse Reply                             4        0.01          0.01
PX Deq: Execute Reply                      250046      247.89        439.12
asynch descriptor resize                        9        0.00          0.00
PX Deq Credit: need buffer                    549        1.54         15.84
PX qref latch                                 235        0.01          0.18
Disk file operations I/O                       42        0.00          0.00
direct path write temp                      62665        0.25        365.50
direct path read temp                       99442        0.46       1024.89
db file sequential read                     36025        0.15        186.86
latch: object queue header operation           17        0.00          0.00
latch free                                      2        0.00          0.00
log file switch (private strand flush incomplete)
                                                  1        0.07          0.07
latch: messages                                 1        0.00          0.00
log file switch completion                     14        0.08          0.79
latch: cache buffers chains                     2        0.00          0.00
latch: redo allocation                          1        0.00          0.00
PX Deq: Signal ACK RSG                          4        0.06          0.07
PX Deq: Signal ACK EXT                          4        0.00          0.01
PX Deq: Slave Session Stats                     4        0.00          0.00
enq: PS - contention                            1        0.00          0.00

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

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.

Query taking so long to execute.

Similar Messages

Maybe you are looking for