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
Similar Messages
-
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 AMHi 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?
Thankspolasa 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/ -
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,
RaghavaHi 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 -
Background Job RSPPFPROCESS Taking too long to execute.
Hi Gurus,
I'm working with SAP CRM 2007 - Interaction Centre
We have configured first response date and to do by date in item category.
If agent fails to response within the first response date or if agent fails to complete
to close the ticket within the to do by date,An action is configured to trigger and an
escalation email(Smart Form) is sent to agent`s manager inbox.
We have scheduled background job for the program RSPPFPROCESS with variant in background
to trigger this actions( It is scheduled 4 times in a day ).
Previously this job used to take 6 hours to complete execution.
But now its taking 12 hours to complete the execution and there is no change in the
variant.
Can anyone please advice me reason for this behavior.
Kind Regards,
VinodHi Manfred,
We are experiencing similar performance issue when running the RSPPFPROCESS Job. We opened a OSS message for quite some time but didn't get any useful help from SAP.
Can you please provide more information regarding your ZRSPPFPROCESS program on identifying the crtical performance steps to resolve the performance issue? We are also thinking of archiving the record in table PPFTTRIGG , we have over 73+ millions records in the table but there is no archiving object for PPF actions. We would like to focus on reducing the number of entries in the table PPFTTRIGG hopefully to improve the performance. Any thoughts on it?
Thanks in advance for your kind help!
Best Regards,
Madeline -
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
JNJohn
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. -
R/3 Extraction taking too long to load data into BW
HI There,
I'm trying to extract SAP Standard extractor 0FI_AP_4 into BW, and its taking endless time.
Even the Extract checker RSA3 is taking too long to execute the data. Dont know why its taking so long to execute.
Since there in not much data to take such a long time.
Enhanced the datasource with three fields from BSEG using user exits.
Is that the reason why its taking too long? Does User Exit slows down the extraction process?
What measures i should take to quicken the process?
Thanks for your time
VandanaThanks for all you replies.
Please go through the steps I've gone through :
- Installed the Business Content and its in version 3.5
- Changed the update rules, Transfer rules and migrated the datasource to BI 7
- Enhanced the 0FI_AP_3 to include three fields BSEG table
- Ran RSA3 and the new fields are showing but the loading is quite slow.
- Commented the code and ran RSA3 and with little difference data is showing up
- Removed the comments and ran, its fine, though it takes little more time then previous step...but data is showing up
- Replicated the datasource into BW
- Created the info package and started the init process (before this deleted the previous stored init process)
- Data isn't loading and please see the error message below.
Diagnosis
The data request was a full update. In this case, the corresponding table in the source system does not
contain any data. System Response Info IDoc received with status 8. Procedure Check the data basis in the source system.
- Checked the transformation between datasource 0FI_AP_4 and Infosource ZFI_AP_4
and I DID NOT found the three fields which i enhanced from BSEG table in the 0FI_AP_4 datasource.
- Replicated the datasource 0FI_AP_4 again, but no change.
Now...I dont know whats happening here.
When i check the datasource 0FI_AP_4 in RSA6, i can see the three new fields from BSEG.
When i check RSA3, i can see the data getting populated with the three new fields from BSEG,
When i check the fields in the datasource 0FI_AP_4 in BW, I can see the three new fields. It shows
that the connection between BW and R/3 is fine, isn't it?
Now...Can anyone please suggest me how to go forward from here?
Thanks for your time
Vandana -
Hi,
RPM_FIN02 is taking too long to execute it actually takes about 10 hours running on the background, How can we resolve this issue.
Regards,
SiyabongaHi Siya
Have you setup variants for all the projects?
In order to them run as 'batch jobs'?
Let me know if this helps, but it has to be done, thereafter we can look at a few SAP Notes that I can provide.
Regards,
Ihsaan Mayet -
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...
Asmit966523 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? -
When query is taking too long time
When query is taking too long time,Where and how to start tuning it?
Here i've listed few things need to be considered,out of my knowledge and understanding
1.What the sql is waiting for(wait events)
2.Parameter modification need to be done at system/session level
3.The query has to be tuned (using hints )
4.Gathering/deleting statistics
List out any other things that need to be taken into account?
Which approach must be followed and on what basis that approach must be considered?When query is taking too long time,Where and how to start tuning it?explain plan will be good start . trace also
Here i've listed few things need to be considered,out of my knowledge and understanding
1.What the sql is waiting for(wait events)When Oracle executes an SQL statement, it is not constantly executing. Sometimes it has to wait for a specific event to happen befor it can proceed.
Read
http://www.adp-gmbh.ch/ora/tuning/event.html
2.Parameter modification need to be done at system/session levelDepend on parameter , define parameter , trace done on session level for example
3.The query has to be tuned (using hints )Could be help you but you must know how to use .
4.Gathering/deleting statisticsDo it in non working hours , it will impact on database performance , but its good
List out any other things that need to be taken into account?Which account ?
Which approach must be followed and on what basis that approach must be considered?you could use lot of tools , Trace , AWR -
Query 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 completeThat 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 ? -
Network event is taking too long (100%)
Hi everybody. We have a 10g DB on Windows. We're using OEM to manage the DB, and it has started to show an alert about database time spend waiting for "Network" event. It arises when we execute one module that updates several tables, that is taking too long. Before we had this app on 8i, also on Windows, and that operation was much more faster than now. The indexes on tables are valid, and I've gathered statistics for the CBO, so I suppose the problem is, as the OEM says, related with network, but I don't know why, because the connection speed is the same tan before, and the two machines are in the same LAN.
Any ideas??Here is the output requested:
SQL> select * from v$system_event
2 where event like 'SQL%';
EVENT TOTAL_WAITS TOTAL_TIMEOUTS TIME_WAITED
AVERAGE_WAIT TIME_WAITED_MICRO EVENT_ID
SQL*Net message to client 1159200 0 252
0 2516408 2067390145
SQL*Net message to dblink 2234 0 1
0 5590 3655533736
SQL*Net more data to client 5753 0 166
0 1657387 554161347
EVENT TOTAL_WAITS TOTAL_TIMEOUTS TIME_WAITED
AVERAGE_WAIT TIME_WAITED_MICRO EVENT_ID
SQL*Net more data to dblink 12 0 0
0 548 1958556342
SQL*Net message from client 1159181 0 218341084
188 2,1834E+12 1421975091
SQL*Net more data from client 23299 0 180602
8 1806015123 3530226808
EVENT TOTAL_WAITS TOTAL_TIMEOUTS TIME_WAITED
AVERAGE_WAIT TIME_WAITED_MICRO EVENT_ID
SQL*Net message from dblink 2234 0 3693
2 36934861 4093028837
SQL*Net more data from dblink 4021 0 39
0 390002 1136294303
SQL*Net break/reset to client 182986 0 2740
0 27397165 1963888671
9 filas seleccionadas. -
RMAN - upgrade catalog taking too long
Hello ,
I am trying to upgrade the rman catalog and it is taking too long to upgrade , infact after 4 hours wait time it is still excuting the upgrade command .
Target database is : 11.2.0.3 PSU1
catalog database : 11.2.0.2
upgrading the rman catalog to 11.2.0.3 .
I tried executing the command at a very quiet time of the day when catalog is not been used by any database . Please advice if you have encountered the similar issue and fixed it .
Thanks
VenkatAfter some time into execution of "upgrade catalog" i got the output as below , and after that i let all the jobs of rman execute completely from diff databases that are connected to catalog and re-executed the "upgrade catalog" command , which finally completed the upgrade process with out the issues .
Error :
RMAN> upgrade catalog;
error creating upgcat_strt_0
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-06004: ORACLE error from recovery catalog database: ORA-00060: deadlock detected while waiting for resource
Re-executed when no sessions are connected to catalog and the upgrade process is successful .
RMAN> connect catalog rman/rman@database
connected to recovery catalog database
PL/SQL package RMAN.DBMS_RCVCAT version 11.02.00.02 in RCVCAT database is not cu
PL/SQL package RMAN.DBMS_RCVMAN version 11.02.00.02 in RCVCAT database is not cu
RMAN> upgrade catalog;
recovery catalog owner is RMAN
enter UPGRADE CATALOG command again to confirm catalog upgrade
RMAN> upgrade catalog;
recovery catalog upgraded to version 11.02.00.03
DBMS_RCVMAN package upgraded to version 11.02.00.03
DBMS_RCVCAT package upgraded to version 11.02.00.03
Thanks
Venkat -
Data Archive Script is taking too long to delete a large table
Hi All,
We have data archive scripts, these scripts move data for a date range to a different table. so the script has two parts first copy data from original table to archive table; and second delete copied rows from the original table. The first part is executing very fast but the deletion is taking too long i.e. around 2-3 hours. The customer analysed the delete query and are saying the script is not using index and is going into full table scan. but the predicate itself is the primary key, Please help... More info below
CREATE TABLE "APP"."MON_TXNS"
( "ID_TXN" NUMBER(12,0) NOT NULL ENABLE,
"BOL_IS_CANCELLED" VARCHAR2(1 BYTE) DEFAULT 'N' NOT NULL ENABLE,
"ID_PAYER" NUMBER(12,0),
"ID_PAYER_PI" NUMBER(12,0),
"ID_PAYEE" NUMBER(12,0),
"ID_PAYEE_PI" NUMBER(12,0),
"ID_CURRENCY" CHAR(3 BYTE) NOT NULL ENABLE,
"STR_TEXT" VARCHAR2(60 CHAR),
"DAT_MERCHANT_TIMESTAMP" DATE,
"STR_MERCHANT_ORDER_ID" VARCHAR2(30 BYTE),
"DAT_EXPIRATION" DATE,
"DAT_CREATION" DATE,
"STR_USER_CREATION" VARCHAR2(30 CHAR),
"DAT_LAST_UPDATE" DATE,
"STR_USER_LAST_UPDATE" VARCHAR2(30 CHAR),
"STR_OTP" CHAR(6 BYTE),
"ID_AUTH_METHOD_PAYER" NUMBER(1,0),
"AMNT_AMOUNT" NUMBER(23,0) DEFAULT 0,
"BOL_IS_AUTOCAPTURE" VARCHAR2(1 BYTE) DEFAULT 'N' NOT NULL ENABLE,
"ID_USE_CASE" NUMBER(4,0) NOT NULL ENABLE,
"ID_AUTH_METHOD_PAYEE" NUMBER(2,0),
CONSTRAINT "CKC_BOL_IS_CANCELLED_MON_TXNS" CHECK (BOL_IS_CANCELLED in ('Y','N')) ENABLE,
CONSTRAINT "PK_MON_TXNS" PRIMARY KEY ("ID_TXN")
USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "LARGE_INDEX" ENABLE,
CONSTRAINT "FK_MON_TXNS_CURRENCIES" FOREIGN KEY ("ID_CURRENCY")
REFERENCES "APP"."CURRENCIES" ("ID_CURRENCY") ENABLE,
CONSTRAINT "FK_MON_TXNS_TO_PAYER" FOREIGN KEY ("ID_PAYER")
REFERENCES "APP"."CUSTOMERS" ("ID_CUSTOMER") ENABLE,
CONSTRAINT "FK_MON_TXNS_TO_PAYEE" FOREIGN KEY ("ID_PAYEE")
REFERENCES "APP"."CUSTOMERS" ("ID_CUSTOMER") ENABLE,
CONSTRAINT "FK_MON_TXNS_REFERENCE_TXNS" FOREIGN KEY ("ID_TXN")
REFERENCES "APP"."TXNS" ("ID_TXN") ENABLE,
CONSTRAINT "FK_MON_TXNS_TO_PI_PAYER" FOREIGN KEY ("ID_PAYER_PI")
REFERENCES "APP"."PIS" ("ID_PI") ENABLE,
CONSTRAINT "FK_MON_TXNS_TO_PI_PAYEE" FOREIGN KEY ("ID_PAYEE_PI")
REFERENCES "APP"."PIS" ("ID_PI") ENABLE,
CONSTRAINT "FK_MON_TXNS_TO_AUTHMETHOD" FOREIGN KEY ("ID_AUTH_METHOD_PAYER")
REFERENCES "APP"."AUTHENTICATION_METHODS" ("ID_AUTHENTICATION_METHOD") ENABLE,
CONSTRAINT "FK_MON_TXNS_USE_CASE_ID" FOREIGN KEY ("ID_USE_CASE")
REFERENCES "APP"."USE_CASES" ("ID_USE_CASE") ENABLE,
CONSTRAINT "FK_MON_TXN_AUTH_PAYEE" FOREIGN KEY ("ID_AUTH_METHOD_PAYEE")
REFERENCES "APP"."AUTHENTICATION_METHODS" ("ID_AUTHENTICATION_METHOD") ENABLE
CREATE INDEX "APP"."IDX_MON_TXNS" ON "APP"."MON_TXNS" ("ID_PAYER")
PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "LARGE_INDEX" ;
CREATE INDEX "APP"."IDX_PAYEE_MON_TXNS" ON "APP"."MON_TXNS" ("ID_PAYEE")
PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "LARGE_DATA" ;
CREATE INDEX "APP"."IDX_PYE_PI_MON_TXNS" ON "APP"."MON_TXNS" ("ID_PAYEE_PI")
PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "LARGE_DATA" ;
CREATE INDEX "APP"."IDX_PYR_PI_MON_TXNS" ON "APP"."MON_TXNS" ("ID_PAYER_PI")
PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "LARGE_DATA" ;
CREATE INDEX "APP"."IDX_USE_CASE_MON_TXNS" ON "APP"."MON_TXNS" ("ID_USE_CASE")
PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "LARGE_DATA" ;
CREATE UNIQUE INDEX "APP"."PK_MON_TXNS" ON "APP"."MON_TXNS" ("ID_TXN")
PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "LARGE_INDEX" ;
Data is first moved to table in schema3.OTW. and then we are deleting all the rows in otw from original table. below is the explain plan for delete
SQL> explain plan for
2 delete from schema1.mon_txns where id_txn in (select id_txn from schema3.OTW);
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 2798378986
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | DELETE STATEMENT | | 2520 | 233K| 87 (2)| 00:00:02 |
| 1 | DELETE | MON_TXNS | | | | |
|* 2 | HASH JOIN RIGHT SEMI | | 2520 | 233K| 87 (2)| 00:00:02 |
| 3 | INDEX FAST FULL SCAN| OTW_ID_TXN | 2520 | 15120 | 3 (0)| 00:00:01 |
| 4 | TABLE ACCESS FULL | MON_TXNS | 14260 | 1239K| 83 (0)| 00:00:02 |
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
Please help,
thanks,
Banka Ravi'Best practice' is just what Oracle is already doing as you have already been told: DELETE FROM myTable WHERE myDate between myStart and Myend.
Your use case is why many orgs elect to use partitioning and use that DATE column as the partition key. Then it is VERY FAST and VERY EASY to truncate or drop partitions that contain old data when you no longer need them.
The other solution used is to quit waiting so long to delete data and then you don't have to delete large amounts at the same time. So instead of deleting data once a month delete it once a week or even every night. Then the number of rows being deleted will be much smaller and, if the stats are kept current, Oracle may decide to use the index.
Maybe you are looking for
-
Are there any Panoramic Friendly Layouts for long photos in iPhoto?
With the frequency of digital cameras that take panoramic photos on the rise, I'd like to have a spread with two or three page wide long strips for panoramic. Or user configurable sized areas for images in iPhoto.
-
No lights=cord or adapter probl
I couldn't find answer on product board or FAQ. My model SB0300 quit working. No lights. I don't know if the adapter cord or adapter is bad or if the unit is bad. Any ideas where to buy a new adapter/cord? Or how to know if the unit itself is bad? th
-
Firefox does not display frames, only lists. Help!
popular websites, e.g. youtube, are not displayed properly in so far frames are not displayed, only clickable lists of text. Please help!
-
Is table maintenance generator only for custom table?
hi , i have doubt is table maintenance generator only for custom table?
-
Hello i have created a logo for my website but i want to save the logo as a picture not as an Illustrator so i can open the logo like a picture not like an illustrator product please help me thanks