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!

Similar Messages

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?

What is the reason for query take more time to execute

Hi,
What is the reason for the query take more time inside procedure.
but if i execute that query alone then it excute within a minutes.
query includes update and insert.

I have a insert and update query when I execute
without Procedure then that query execute faster but
If I execute inside procedure then It takes 2 hours
to execute.Put you watch 2 hours back and the problem will disappear.
do you understand what I want to say?I understood what you wanted to say and I understood you didn't understood what I said.
What does the procedure, what does the query, how can you say the query does the same as the procedure that takes longer. You didn't say anything useful to have an idea of what you're talking about.
Everyone knows what means that something is slower than something else, but it means nothing if you don't say what you're talking about.
To begin with something take a look at this
When your query takes too long ...
especially the part regarding the trace.
Bye Alessandro

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

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.

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/

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

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

Is index range scan the reason for query running long time

I would like to know whether index range scan is the reason for the query running long time. Below is the explain plan. If so, how to optimise it? Please help
Operation     Object     COST     CARDINALITY     BYTES
SELECT STATEMENT ()          413     1000     265000
COUNT (STOPKEY)
FILTER ()
TABLE ACCESS (BY INDEX ROWID)     ORDERS     413     58720     15560800
INDEX (RANGE SCAN)     IDX_SERV_PROV_ID     13     411709
TABLE ACCESS (BY INDEX ROWID)     ADDRESSES     2     1     14
INDEX (UNIQUE SCAN)     SYS_C004605     1     1
TABLE ACCESS (BY INDEX ROWID)     ADDRESSES     2     1     14
INDEX (UNIQUE SCAN)     SYS_C004605     1     1
TABLE ACCESS (BY INDEX ROWID)     ADDRESSES     2     1     14
INDEX (UNIQUE SCAN)     SYS_C004605     1     1

The index range scan means that the optimiser has determined that it is better to read the index rather than perform a full table scan. So in answer to your question - quite possibly but the alternative might take even longer!
The best thing to do is to review your query and check that you need every table included in the query and that you are accessing the tables via the best route. For example if you can access a table via primary key index that would be better than using a non-unique index. But the best way of reducing the time the query takes to run is to give it less tables (and indexes) to read.
John Seaman
http://www.asktheoracle.net

Stopping a Query taking more time to execute in runtime in Oracle Forms.

Hi,
In the present application one of the oracle form screen is taking long time to execute a query, user wanted an option to stop the query in between and browse the result (whatever has been fetched before stopping the query).
We have tried three approach.
1. set max fetch record in form and block level.
2. set max fetch time in form and block level.
in above two method does not provide the appropiate solution for us.
3. the third approach we applied is setting the interaction mode to "NON BLOCKING" at the form level.
It seems to be worked, while the query took long time to execute, oracle app server prompts an message to press Esc to cancel the query and it a displaying the results fetched upto that point.
But the drawback is one pressing esc, its killing the session itself. which is causing the entire application to collapse.
Please suggest if there is any alternative approach for this or how to overcome this perticular scenario.
This kind of facility is alreday present in TOAD and PL/SQL developer where we can stop an executing query and browse the results fetched upto that point, is the similar facility is avialable in oracle forms ,please suggest.
Thanks and Regards,
Suraj
Edited by: user10673131 on Jun 25, 2009 4:55 AM

Hello Friend,
You query will definitely take more time or even fail in PROD,becuase the way it is written. Here are my few observations, may be it can help :-
1. XLA_AR_INV_AEL_SL_V XLA_AEL_SL_V : Never use a view inside such a long query , becuase View is just a window to the records.
and when used to join other table records, then all those tables which are used to create a view also becomes part of joining conition.
First of all please check if you really need this view. I guess you are using to check if the records have been created as Journal entries or not ?
Please check the possbility of finding it through other AR tables.
2. Remove _ALL tables instead use the corresponding org specific views (if you are in 11i ) or the sysnonymns ( in R12 )
For example : For ra_cust_trx_types_all use ra_cust_trx_types.
This will ensure that the query will execute only for those ORG_IDs which are assigned to that responsibility.
3. Check with the DBA whether the GATHER SCHEMA STATS have been run atleast for ONT and RA tables.
You can also check the same using
SELECT LAST_ANALYZED FROM ALL_TABLES WHERE TABLE_NAME = 'ra_customer_trx_all'.
If the tables are not analyzed , the CBO will not be able to tune your query.
4. Try to remove the DISTINCT keyword. This is the MAJOR reason for this problem.
5. If its a report , try to separate the logic in separate queries ( using a procedure ) and then populate the whole data in custom table, and use this custom table for generating the
report.
Thanks,
Neeraj Shrivastava
[email protected]
Edited by: user9352949 on Oct 1, 2010 8:02 PM
Edited by: user9352949 on Oct 1, 2010 8:03 PM

Query taking much time to execute

The following query is taking more than 4hrs to execute.
select l_extendedprice , count(l_extendedprice) from dbo.lineitem group by l_extendedprice
Cardinality of table : 6001215 ( > 6 million)
Index on l_extendedprice is there
ReadAheadLobThreshold = 500
Database version 7.7.06.09
I need to optimize this query. Kindly suggest way out.
Thanks
Priyank

Data Cache : 80296 KB
Ok, that's 8 Gigs for cache.
The index takes 16335 pages à 8 KB = 130.680 KB = 128 MB.
Fits completely into RAM - the same is true for the additional temp resultset.
So once the index has been read to cache I assume the query is a lot quicker than 4 hours.
6 Data Volumes
first 3 of size 51.200 KB
other 3 of size 1,048,576 KB
Well, that's not the smartest thing to do.
That way the larger volumes will get double the I/O requests which eventually saturates the I/O channel.
Yes looking at the cardinality of the table lots of I/O required but still more than 4 hrs is quite unrealistic. Some tuning is required.
We're not talking about the cardinality here - you want all the data.
We talk pages then.
And as we've seen, the table is not touched for this query.
Instead the smaller index is completely read in a index only strategy.
Loading 128MB from disk, creating temporary data in the same size and spilling out the information (and thereby reading the 128 MB temp size again) in 4 hours add up to ca. 384 MB/4 hours = 96 MB/hour = 1,6 MB/minute.
Not too good really - I suspect that the I/O system here is not the quickest one.
You may want to activate the time measurement and set the DB Analyzer interval to 120 secs.
Then activate Command and Resourcemonitor and look for statements taking longer than 10 minutes.
Now run your statement again and let us know the information from Command/Resourcemonitor and check for warnings in the DBanalyzer output.
regards,
Lars

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/

Reasons for query taking so long to execute?

Similar Messages

Maybe you are looking for