Can we write a join on a view and a table

Hi all,
can we write a join on a view and a table. i got the requirement from my functional people about the following one
Select CAUFV-AFUNR, CAUFV-AUART, AFVC-VORNR, CAUFV-FTRMI, CRHD-ARBPL
into <ProOrd>, <OrdTyp>, <Opt>, <RelDat>, <WorCen>
from CAUFV, AFVC, CRHD
where CAUFV-WERKS = plant in selection screen
and CAUFV-AFUNR = production order in selection screen
and CAUFV-AUART = production order type in selection screen
and CAUFV-FTRMI = range of release date in selection screen
and CAUFV-AUFPL = AFVC-AUFPL
and AFVC-ARBID = CRHD-OBJID
and CRHD-OBJTY = A
here CAUFV is a view and CRHD and AFVC are transperent tables.
please tell me any feasible solution for this..
Thanks in Advance..

Hi
Refer these links:
http://help.sap.com/saphelp_nw04/helpdata/en/cf/21ec84446011d189700000e8322d00/content.htm
http://www.sap-img.com/abap/what-is-the-different-types-and-usage-of-views.htm
http://www.karakas-online.de/forum/viewtopic.php?t=730
Thanks
Vasudha
Message was edited by:
Vasudha L

Similar Messages

Can I write photo captions in Elements 12 and upload the Photo to Revel, keeping the same Caption?

Can I write photo captions in Elements 12 and upload the Photo to Revel, keeping the same Caption?

Yes. Even if you edit Captions post uploading to Revel from Elements Organizer, the updated caption syncs to Revel.
Thanks
Andaleeb

Difference between materailized view and a table

hey hiii
i want to know what is a difference between a materialized view and a table i.e suppose i create a table A and another table B on table A i have created a trigger which will upload all the changes made in A ie insert,update or delete so whether this will perform all the action that a materialized view can perform on A or is there any difference between them
thks

I'll add to Nicolas' answer that the MV maintenance does have access to mechsnisms other than row-by-row replication of the trigger-based type. Direct path inserts to the base table are very efficiently propagated to the MV, as are partition-based DDL operations. Also MV's come with optional query rewrite built in (you need 10g+ to query rewrite to a non-MV data set), and scheduled refresh so you can defer maintenance of the data set until later.
MV maintenance can be less efficient though -- you may know something about the data and the way that it changes that allows you to write more efficient meintenance than the MV code.

Poor performance while join of 2 comprehensive large views and small table

Hi,
The following SQL statement has been identified to perform poorly. It currently takes up to 6 seconds to execute, but it's supposed to take ~30-40ms at most.
This is the statement(all bind variables change to numbers):
SELECT v__96.connector_objectid, v__96.connector_classid, v__96.from_objectid,
 v__96.to_objectid, v__96.from_classid, v__96.to_classid,
 v__96.from_firstunit, v__96.to_firstunit, v__96.number_of_units,
 tmp_trace.first_unit, tmp_trace.last_unit, v__96.inv_status_number,
 tmp_trace.first_unit, tmp_trace.last_unit, v__96.answers,
 v__96.priority, v__97.first_unit, v__97.n_units,
 v__97.mid_span_distance
FROM ne.tmp_trace,
 (SELECT b.objectid, b.answers, b.connector_classid,
 b.connector_objectid, b.from_classid, b.from_objectid,
 b.to_classid, b.to_objectid, b.from_firstunit, b.to_firstunit,
 b.number_of_units, b.inv_status_number, b.splice_closure_name,
 b.work_order_name, b.work_order_item_number,
 b.inventory_status_code, b.priority
 FROM ne.connection b
 WHERE b.objectid NOT IN (
 SELECT /*+ HASH_AJ */
 sde_deletes_row_id
 FROM ne.d96
 WHERE deleted_at IN (
 SELECT l.lineage_id
 FROM sde.state_lineages l
 WHERE l.lineage_name = 2
 AND l.lineage_id <= 115)
 AND sde_state_id = 0)
 UNION ALL
 SELECT a.objectid, a.answers, a.connector_classid,
 a.connector_objectid, a.from_classid, a.from_objectid,
 a.to_classid, a.to_objectid, a.from_firstunit, a.to_firstunit,
 a.number_of_units, a.inv_status_number, a.splice_closure_name,
 a.work_order_name, a.work_order_item_number,
 a.inventory_status_code, a.priority
 FROM ne.a96 a, sde.state_lineages sl
 WHERE (a.objectid, a.sde_state_id) NOT IN (
 SELECT /*+ HASH_AJ */
 sde_deletes_row_id, sde_state_id
 FROM ne.d96
 WHERE deleted_at IN (
 SELECT l.lineage_id
 FROM sde.state_lineages l
 WHERE l.lineage_name = 2
 AND l.lineage_id <= 115)
 AND sde_state_id > 0)
 AND a.sde_state_id = sl.lineage_id
 AND sl.lineage_name = 2
 AND sl.lineage_id <= 115) v__96,
 (SELECT b.objectid, b.tray_number, b.db_loss, b.first_unit, b.n_units,
 b.connection_objectid, b.connector_type_name,
 b.dedicated_status, b.mid_span_distance
 FROM ne.connection_attributes b
 WHERE b.objectid NOT IN (
 SELECT /*+ HASH_AJ */
 sde_deletes_row_id
 FROM ne.d97
 WHERE deleted_at IN (
 SELECT l.lineage_id
 FROM sde.state_lineages l
 WHERE l.lineage_name = 2
 AND l.lineage_id <= 115)
 AND sde_state_id = 0)
 UNION ALL
 SELECT a.objectid, a.tray_number, a.db_loss, a.first_unit, a.n_units,
 a.connection_objectid, a.connector_type_name,
 a.dedicated_status, a.mid_span_distance
 FROM ne.a97 a, sde.state_lineages sl
 WHERE (a.objectid, a.sde_state_id) NOT IN (
 SELECT /*+ HASH_AJ */
 sde_deletes_row_id, sde_state_id
 FROM ne.d97
 WHERE deleted_at IN (
 SELECT l.lineage_id
 FROM sde.state_lineages l
 WHERE l.lineage_name = 2
 AND l.lineage_id <= 115)
 AND sde_state_id > 0)
 AND a.sde_state_id = sl.lineage_id
 AND sl.lineage_name = 2
 AND sl.lineage_id <= 115) v__97
WHERE ( ( ( ( ( ( ne.tmp_trace.equipment_object_id =
 v__96.to_objectid
 AND v__96.to_classid = 9
 OR ( ne.tmp_trace.transmedia_object_id =
 v__96.to_objectid
 AND v__96.to_classid = 5
 AND ( (v__96.to_firstunit
 BETWEEN ne.tmp_trace.first_unit
 AND ne.tmp_trace.last_unit
 OR (ne.tmp_trace.first_unit
 BETWEEN v__96.to_firstunit
 AND v__96.to_firstunit
 + v__96.number_of_units
 - 1
 AND v__96.answers = 0
 AND v__96.objectid = v__97.connection_objectid
 AND (ne.tmp_trace.session_id = -1234)
 );It should return many values from 2 comprehensive views (v__96, v__97) and business table (tmp_trace). 2 comprehensive views ~1,000,000 recs each, business table ~ 10 recs.
The version of the database is 11.1.0.6.
These are the parameters relevant to the optimizer:
SQL> show parameter optimizer
NAME TYPE VALUE
optimizer_capture_sql_plan_baselines boolean FALSE
optimizer_dynamic_sampling integer 2
optimizer_features_enable string 11.1.0.6
optimizer_index_caching integer 0
optimizer_index_cost_adj integer 100
optimizer_mode string ALL_ROWS
optimizer_secure_view_merging boolean TRUE
optimizer_use_invisible_indexes boolean FALSE
optimizer_use_pending_statistics boolean FALSE
optimizer_use_sql_plan_baselines boolean TRUE
SQL> show parameter db_file_multi
NAME TYPE VALUE
db_file_multiblock_read_count integer 128
SQL> show parameter db_block_size
NAME TYPE VALUE
db_block_size integer 8192
SQL> show parameter cursor_sharing
NAME TYPE VALUE
cursor_sharing string FORCE
SQL> column sname format a20
SQL> column pname format a20
SQL> column pval2 format a20
SQL> select sname, pname, pval1, pval2 from sys.aux_stats$;
SNAME PNAME PVAL1 PVAL2
SYSSTATS_INFO STATUS COMPLETED
SYSSTATS_INFO DSTART 07-15-2009 10:27
SYSSTATS_INFO DSTOP 07-15-2009 10:27
SYSSTATS_INFO FLAGS 1
SYSSTATS_MAIN CPUSPEEDNW 1812.32129
SYSSTATS_MAIN IOSEEKTIM 10
SYSSTATS_MAIN IOTFRSPEED 4096
SYSSTATS_MAIN SREADTIM
SYSSTATS_MAIN MREADTIM
SYSSTATS_MAIN CPUSPEED
SYSSTATS_MAIN MBRC
SNAME PNAME PVAL1 PVAL2
SYSSTATS_MAIN MAXTHR
SYSSTATS_MAIN SLAVETHR
13 rows selected.Here is the output of EXPLAIN PLAN:
explain plan for -- statement above
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 1005186751
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 282 | 268 (2)| 00:00:04 |
| 1 | NESTED LOOPS | | 1 | 282 | 268 (2)| 00:00:04 |
| 2 | MERGE JOIN CARTESIAN | | 1 | 119 | 260 (1)| 00:00:04 |
|* 3 | TABLE ACCESS FULL | TMP_TRACE | 1 | 65 | 2 (0)| 00:00:01 |
| 4 | BUFFER SORT | | 103K| 5467K| 258 (1)| 00:00:04 |
| 5 | VIEW | | 103K| 5467K| 258 (1)| 00:00:04 |
| 6 | UNION-ALL | | | | | |
| 7 | NESTED LOOPS ANTI | | 1 | 82 | 3 (0)| 00:00:01 |
| 8 | TABLE ACCESS FULL | CONNECTION_ATTRIBUTES | 1 | 78 | 2 (0)| 00:00:01 |
| 9 | VIEW PUSHED PREDICATE | VW_NSO_1 | 1 | 4 | 1 (0)| 00:00:01 |
| 10 | NESTED LOOPS | | 1 | 20 | 1 (0)| 00:00:01 |
|* 11 | INDEX RANGE SCAN | LINEAGES_PK | 5 | 35 | 1 (0)| 00:00:01 |
|* 12 | INDEX UNIQUE SCAN | D97_PK | 1 | 13 | 0 (0)| 00:00:01 |
|* 13 | HASH JOIN RIGHT ANTI | | 103K| 5568K| 255 (1)| 00:00:04 |
| 14 | VIEW | VW_NSO_2 | 1 | 26 | 2 (0)| 00:00:01 |
| 15 | NESTED LOOPS | | 1 | 20 | 2 (0)| 00:00:01 |
|* 16 | INDEX FAST FULL SCAN | D97_PK | 1 | 13 | 2 (0)| 00:00:01 |
|* 17 | INDEX UNIQUE SCAN | LINEAGES_PK | 1 | 7 | 0 (0)| 00:00:01 |
| 18 | NESTED LOOPS | | | | | |
| 19 | NESTED LOOPS | | 103K| 2936K| 252 (1)| 00:00:04 |
|* 20 | INDEX RANGE SCAN | LINEAGES_PK | 5 | 35 | 1 (0)| 00:00:01 |
|* 21 | INDEX RANGE SCAN | A97_STATEID_IX1 | 17731 | | 32 (0)| 00:00:01 |
| 22 | TABLE ACCESS BY INDEX ROWID| A97 | 21491 | 461K| 123 (1)| 00:00:02 |
|* 23 | VIEW | | 1 | 163 | 8 (13)| 00:00:01 |
| 24 | UNION ALL PUSHED PREDICATE | | | | | |
| 25 | NESTED LOOPS ANTI | | 1 | 185 | 1 (0)| 00:00:01 |
|* 26 | TABLE ACCESS BY INDEX ROWID | CONNECTION | 1 | 181 | 0 (0)| 00:00:01 |
|* 27 | INDEX UNIQUE SCAN | R96_SDE_ROWID_UK | 1 | | 0 (0)| 00:00:01 |
| 28 | VIEW PUSHED PREDICATE | VW_NSO_3 | 1 | 4 | 1 (0)| 00:00:01 |
| 29 | NESTED LOOPS | | 1 | 20 | 1 (0)| 00:00:01 |
|* 30 | INDEX RANGE SCAN | LINEAGES_PK | 5 | 35 | 1 (0)| 00:00:01 |
|* 31 | INDEX UNIQUE SCAN | D96_PK | 1 | 13 | 0 (0)| 00:00:01 |
|* 32 | HASH JOIN ANTI | | 1 | 97 | 7 (15)| 00:00:01 |
| 33 | NESTED LOOPS | | 1 | 71 | 4 (0)| 00:00:01 |
|* 34 | TABLE ACCESS BY INDEX ROWID | A96 | 1 | 64 | 4 (0)| 00:00:01 |
|* 35 | INDEX RANGE SCAN | A96_PK | 1 | | 3 (0)| 00:00:01 |
|* 36 | INDEX UNIQUE SCAN | LINEAGES_PK | 1 | 7 | 0 (0)| 00:00:01 |
| 37 | VIEW | VW_NSO_4 | 1 | 26 | 2 (0)| 00:00:01 |
| 38 | NESTED LOOPS | | 1 | 20 | 2 (0)| 00:00:01 |
|* 39 | INDEX FAST FULL SCAN | D96_PK | 1 | 13 | 2 (0)| 00:00:01 |
|* 40 | INDEX UNIQUE SCAN | LINEAGES_PK | 1 | 7 | 0 (0)| 00:00:01 |
Predicate Information (identified by operation id):
 3 - filter("TMP_TRACE"."SESSION_ID"=(-1234))
11 - access("L"."LINEAGE_NAME"=2 AND "L"."LINEAGE_ID"<=115)
12 - access("DELETED_AT"="L"."LINEAGE_ID" AND "SDE_DELETES_ROW_ID"="B"."OBJECTID" AND
 "SDE_STATE_ID"=0)
 filter("DELETED_AT"<=115)
13 - access("A"."OBJECTID"="SDE_DELETES_ROW_ID" AND "A"."SDE_STATE_ID"="SDE_STATE_ID")
16 - filter("DELETED_AT"<=115 AND "SDE_STATE_ID"<=115 AND "SDE_STATE_ID">0)
17 - access("L"."LINEAGE_NAME"=2 AND "DELETED_AT"="L"."LINEAGE_ID")
 filter("L"."LINEAGE_ID"<=115)
20 - access("SL"."LINEAGE_NAME"=2 AND "SL"."LINEAGE_ID"<=115)
21 - access("A"."SDE_STATE_ID"="SL"."LINEAGE_ID")
 filter("A"."SDE_STATE_ID"<=115)
23 - filter(("TMP_TRACE"."EQUIPMENT_OBJECT_ID"="V__96"."TO_OBJECTID" AND "V__96"."TO_CLASSID"=9
 OR "TMP_TRACE"."TRANSMEDIA_OBJECT_ID"="V__96"."TO_OBJECTID" AND "V__96"."TO_CLASSID"=5) AND
 ("V__96"."TO_FIRSTUNIT">="TMP_TRACE"."FIRST_UNIT" AND
 "V__96"."TO_FIRSTUNIT"<="TMP_TRACE"."LAST_UNIT" OR "TMP_TRACE"."FIRST_UNIT">="V__96"."TO_FIRSTUNIT"
 AND "TMP_TRACE"."FIRST_UNIT"<="V__96"."TO_FIRSTUNIT"+"V__96"."NUMBER_OF_UNITS"-1))
26 - filter("B"."ANSWERS"=0)
27 - access("B"."OBJECTID"="V__97"."CONNECTION_OBJECTID")
30 - access("L"."LINEAGE_NAME"=2 AND "L"."LINEAGE_ID"<=115)
31 - access("DELETED_AT"="L"."LINEAGE_ID" AND "SDE_DELETES_ROW_ID"="B"."OBJECTID" AND
 "SDE_STATE_ID"=0)
 filter("DELETED_AT"<=115)
32 - access("A"."OBJECTID"="SDE_DELETES_ROW_ID" AND "A"."SDE_STATE_ID"="SDE_STATE_ID")
34 - filter("A"."ANSWERS"=0)
35 - access("A"."OBJECTID"="V__97"."CONNECTION_OBJECTID" AND "A"."SDE_STATE_ID"<=115)
36 - access("SL"."LINEAGE_NAME"=2 AND "A"."SDE_STATE_ID"="SL"."LINEAGE_ID")
 filter("SL"."LINEAGE_ID"<=115)
39 - filter("DELETED_AT"<=115 AND "SDE_STATE_ID"<=115 AND
 "SDE_DELETES_ROW_ID"="V__97"."CONNECTION_OBJECTID" AND "SDE_STATE_ID">0)
40 - access("L"."LINEAGE_NAME"=2 AND "DELETED_AT"="L"."LINEAGE_ID")
 filter("L"."LINEAGE_ID"<=115)
Note
 - dynamic sampling used for this statement
87 rows selected.Here is the output of SQL*Plus AUTOTRACE including the TIMING information:
SQL> set autotrace traceonly arraysize 100
Elapsed: 00:00:01.64
Execution Plan
Plan hash value: 1198408274
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 876K| 238M| 1301 (2)| 00:00:16 |
| 1 | CONCATENATION | | | | | |
|* 2 | HASH JOIN | | 438K| 119M| 651 (2)| 00:00:08 |
|* 3 | HASH JOIN | | 423 | 98559 | 390 (2)| 00:00:05 |
|* 4 | TABLE ACCESS FULL | TMP_TRACE | 82 | 5330 | 29 (0)| 00:00:01 |
|* 5 | VIEW | | 103K| 16M| 360 (1)| 00:00:05 |
| 6 | UNION-ALL | | | | | |
| 7 | NESTED LOOPS ANTI | | 1 | 185 | 3 (0)| 00:00:01 |
|* 8 | TABLE ACCESS FULL | CONNECTION | 1 | 181 | 2 (0)| 00:00:01 |
| 9 | VIEW PUSHED PREDICATE | VW_NSO_3 | 1 | 4 | 1 (0)| 00:00:01 |
| 10 | NESTED LOOPS | | 1 | 20 | 1 (0)| 00:00:01 |
|* 11 | INDEX RANGE SCAN | LINEAGES_PK | 5 | 35 | 1 (0)| 00:00:01 |
|* 12 | INDEX UNIQUE SCAN | D96_PK | 1 | 13 | 0 (0)| 00:00:01 |
|* 13 | HASH JOIN RIGHT ANTI | | 103K| 9820K| 357 (1)| 00:00:05 |
| 14 | VIEW | VW_NSO_4 | 1 | 26 | 2 (0)| 00:00:01 |
| 15 | NESTED LOOPS | | 1 | 20 | 2 (0)| 00:00:01 |
|* 16 | INDEX FAST FULL SCAN | D96_PK | 1 | 13 | 2 (0)| 00:00:01 |
|* 17 | INDEX UNIQUE SCAN | LINEAGES_PK | 1 | 7 | 0 (0)| 00:00:01 |
| 18 | NESTED LOOPS | | | | | |
| 19 | NESTED LOOPS | | 103K| 7188K| 354 (1)| 00:00:05 |
|* 20 | INDEX RANGE SCAN | LINEAGES_PK | 5 | 35 | 1 (0)| 00:00:01 |
|* 21 | INDEX RANGE SCAN | A96_STATEID_IX1 | 17731 | | 32 (0)| 00:00:01 |
|* 22 | TABLE ACCESS BY INDEX ROWID| A96 | 21491 | 1343K| 224 (1)| 00:00:03 |
| 23 | VIEW | | 103K| 5264K| 258 (1)| 00:00:04 |
| 24 | UNION-ALL | | | | | |
| 25 | NESTED LOOPS ANTI | | 1 | 82 | 3 (0)| 00:00:01 |
| 26 | TABLE ACCESS FULL | CONNECTION_ATTRIBUTES | 1 | 78 | 2 (0)| 00:00:01 |
| 27 | VIEW PUSHED PREDICATE | VW_NSO_1 | 1 | 4 | 1 (0)| 00:00:01 |
| 28 | NESTED LOOPS | | 1 | 20 | 1 (0)| 00:00:01 |
|* 29 | INDEX RANGE SCAN | LINEAGES_PK | 5 | 35 | 1 (0)| 00:00:01 |
|* 30 | INDEX UNIQUE SCAN | D97_PK | 1 | 13 | 0 (0)| 00:00:01 |
|* 31 | HASH JOIN RIGHT ANTI | | 103K| 5568K| 255 (1)| 00:00:04 |
| 32 | VIEW | VW_NSO_2 | 1 | 26 | 2 (0)| 00:00:01 |
| 33 | NESTED LOOPS | | 1 | 20 | 2 (0)| 00:00:01 |
|* 34 | INDEX FAST FULL SCAN | D97_PK | 1 | 13 | 2 (0)| 00:00:01 |
|* 35 | INDEX UNIQUE SCAN | LINEAGES_PK | 1 | 7 | 0 (0)| 00:00:01 |
| 36 | NESTED LOOPS | | | | | |
| 37 | NESTED LOOPS | | 103K| 2936K| 252 (1)| 00:00:04 |
|* 38 | INDEX RANGE SCAN | LINEAGES_PK | 5 | 35 | 1 (0)| 00:00:01 |
|* 39 | INDEX RANGE SCAN | A97_STATEID_IX1 | 17731 | | 32 (0)| 00:00:01 |
| 40 | TABLE ACCESS BY INDEX ROWID | A97 | 21491 | 461K| 123 (1)| 00:00:02 |
|* 41 | HASH JOIN | | 438K| 119M| 651 (2)| 00:00:08 |
|* 42 | HASH JOIN | | 423 | 98559 | 390 (2)| 00:00:05 |
|* 43 | TABLE ACCESS FULL | TMP_TRACE | 82 | 5330 | 29 (0)| 00:00:01 |
|* 44 | VIEW | | 103K| 16M| 360 (1)| 00:00:05 |
| 45 | UNION-ALL | | | | | |
| 46 | NESTED LOOPS ANTI | | 1 | 185 | 3 (0)| 00:00:01 |
|* 47 | TABLE ACCESS FULL | CONNECTION | 1 | 181 | 2 (0)| 00:00:01 |
| 48 | VIEW PUSHED PREDICATE | VW_NSO_3 | 1 | 4 | 1 (0)| 00:00:01 |
| 49 | NESTED LOOPS | | 1 | 20 | 1 (0)| 00:00:01 |
|* 50 | INDEX RANGE SCAN | LINEAGES_PK | 5 | 35 | 1 (0)| 00:00:01 |
|* 51 | INDEX UNIQUE SCAN | D96_PK | 1 | 13 | 0 (0)| 00:00:01 |
|* 52 | HASH JOIN RIGHT ANTI | | 103K| 9820K| 357 (1)| 00:00:05 |
| 53 | VIEW | VW_NSO_4 | 1 | 26 | 2 (0)| 00:00:01 |
| 54 | NESTED LOOPS | | 1 | 20 | 2 (0)| 00:00:01 |
|* 55 | INDEX FAST FULL SCAN | D96_PK | 1 | 13 | 2 (0)| 00:00:01 |
|* 56 | INDEX UNIQUE SCAN | LINEAGES_PK | 1 | 7 | 0 (0)| 00:00:01 |
| 57 | NESTED LOOPS | | | | | |
| 58 | NESTED LOOPS | | 103K| 7188K| 354 (1)| 00:00:05 |
|* 59 | INDEX RANGE SCAN | LINEAGES_PK | 5 | 35 | 1 (0)| 00:00:01 |
|* 60 | INDEX RANGE SCAN | A96_STATEID_IX1 | 17731 | | 32 (0)| 00:00:01 |
|* 61 | TABLE ACCESS BY INDEX ROWID| A96 | 21491 | 1343K| 224 (1)| 00:00:03 |
| 62 | VIEW | | 103K| 5264K| 258 (1)| 00:00:04 |
| 63 | UNION-ALL | | | | | |
| 64 | NESTED LOOPS ANTI | | 1 | 82 | 3 (0)| 00:00:01 |
| 65 | TABLE ACCESS FULL | CONNECTION_ATTRIBUTES | 1 | 78 | 2 (0)| 00:00:01 |
| 66 | VIEW PUSHED PREDICATE | VW_NSO_1 | 1 | 4 | 1 (0)| 00:00:01 |
| 67 | NESTED LOOPS | | 1 | 20 | 1 (0)| 00:00:01 |
|* 68 | INDEX RANGE SCAN | LINEAGES_PK | 5 | 35 | 1 (0)| 00:00:01 |
|* 69 | INDEX UNIQUE SCAN | D97_PK | 1 | 13 | 0 (0)| 00:00:01 |
|* 70 | HASH JOIN RIGHT ANTI | | 103K| 5568K| 255 (1)| 00:00:04 |
| 71 | VIEW | VW_NSO_2 | 1 | 26 | 2 (0)| 00:00:01 |
| 72 | NESTED LOOPS | | 1 | 20 | 2 (0)| 00:00:01 |
|* 73 | INDEX FAST FULL SCAN | D97_PK | 1 | 13 | 2 (0)| 00:00:01 |
|* 74 | INDEX UNIQUE SCAN | LINEAGES_PK | 1 | 7 | 0 (0)| 00:00:01 |
| 75 | NESTED LOOPS | | | | | |
| 76 | NESTED LOOPS | | 103K| 2936K| 252 (1)| 00:00:04 |
|* 77 | INDEX RANGE SCAN | LINEAGES_PK | 5 | 35 | 1 (0)| 00:00:01 |
|* 78 | INDEX RANGE SCAN | A97_STATEID_IX1 | 17731 | | 32 (0)| 00:00:01 |
| 79 | TABLE ACCESS BY INDEX ROWID | A97 | 21491 | 461K| 123 (1)| 00:00:02 |
Predicate Information (identified by operation id):
 2 - access("V__96"."OBJECTID"="V__97"."CONNECTION_OBJECTID")
 3 - access("TMP_TRACE"."TRANSMEDIA_OBJECT_ID"="V__96"."TO_OBJECTID")
 filter("V__96"."TO_FIRSTUNIT">="TMP_TRACE"."FIRST_UNIT" AND
 "V__96"."TO_FIRSTUNIT"<="TMP_TRACE"."LAST_UNIT" OR "TMP_TRACE"."FIRST_UNIT">="V__96"."TO_FIRSTUNIT"
 AND "TMP_TRACE"."FIRST_UNIT"<="V__96"."TO_FIRSTUNIT"+"V__96"."NUMBER_OF_UNITS"-1)
 4 - filter("TMP_TRACE"."SESSION_ID"=(-1234))
 5 - filter("V__96"."TO_CLASSID"=5)
 8 - filter("B"."ANSWERS"=0)
11 - access("L"."LINEAGE_NAME"=2 AND "L"."LINEAGE_ID"<=115)
12 - access("DELETED_AT"="L"."LINEAGE_ID" AND "SDE_DELETES_ROW_ID"="B"."OBJECTID" AND
 "SDE_STATE_ID"=0)
 filter("DELETED_AT"<=115)
13 - access("A"."OBJECTID"="SDE_DELETES_ROW_ID" AND "A"."SDE_STATE_ID"="SDE_STATE_ID")
16 - filter("DELETED_AT"<=115 AND "SDE_STATE_ID"<=115 AND "SDE_STATE_ID">0)
17 - access("L"."LINEAGE_NAME"=2 AND "DELETED_AT"="L"."LINEAGE_ID")
 filter("L"."LINEAGE_ID"<=115)
20 - access("SL"."LINEAGE_NAME"=2 AND "SL"."LINEAGE_ID"<=115)
21 - access("A"."SDE_STATE_ID"="SL"."LINEAGE_ID")
 filter("A"."SDE_STATE_ID"<=115)
22 - filter("A"."ANSWERS"=0)
29 - access("L"."LINEAGE_NAME"=2 AND "L"."LINEAGE_ID"<=115)
30 - access("DELETED_AT"="L"."LINEAGE_ID" AND "SDE_DELETES_ROW_ID"="B"."OBJECTID" AND
 "SDE_STATE_ID"=0)
 filter("DELETED_AT"<=115)
31 - access("A"."OBJECTID"="SDE_DELETES_ROW_ID" AND "A"."SDE_STATE_ID"="SDE_STATE_ID")
34 - filter("DELETED_AT"<=115 AND "SDE_STATE_ID"<=115 AND "SDE_STATE_ID">0)
35 - access("L"."LINEAGE_NAME"=2 AND "DELETED_AT"="L"."LINEAGE_ID")
 filter("L"."LINEAGE_ID"<=115)
38 - access("SL"."LINEAGE_NAME"=2 AND "SL"."LINEAGE_ID"<=115)
39 - access("A"."SDE_STATE_ID"="SL"."LINEAGE_ID")
 filter("A"."SDE_STATE_ID"<=115)
41 - access("V__96"."OBJECTID"="V__97"."CONNECTION_OBJECTID")
42 - access("TMP_TRACE"."EQUIPMENT_OBJECT_ID"="V__96"."TO_OBJECTID")
 filter((LNNVL("TMP_TRACE"."TRANSMEDIA_OBJECT_ID"="V__96"."TO_OBJECTID") OR
 LNNVL("V__96"."TO_CLASSID"=5)) AND ("V__96"."TO_FIRSTUNIT">="TMP_TRACE"."FIRST_UNIT" AND
 "V__96"."TO_FIRSTUNIT"<="TMP_TRACE"."LAST_UNIT" OR "TMP_TRACE"."FIRST_UNIT">="V__96"."TO_FIRSTUNIT"
 AND "TMP_TRACE"."FIRST_UNIT"<="V__96"."TO_FIRSTUNIT"+"V__96"."NUMBER_OF_UNITS"-1))
43 - filter("TMP_TRACE"."SESSION_ID"=(-1234))
44 - filter("V__96"."TO_CLASSID"=9)
47 - filter("B"."ANSWERS"=0)
50 - access("L"."LINEAGE_NAME"=2 AND "L"."LINEAGE_ID"<=115)
51 - access("DELETED_AT"="L"."LINEAGE_ID" AND "SDE_DELETES_ROW_ID"="B"."OBJECTID" AND
 "SDE_STATE_ID"=0)
 filter("DELETED_AT"<=115)
52 - access("A"."OBJECTID"="SDE_DELETES_ROW_ID" AND "A"."SDE_STATE_ID"="SDE_STATE_ID")
55 - filter("DELETED_AT"<=115 AND "SDE_STATE_ID"<=115 AND "SDE_STATE_ID">0)
56 - access("L"."LINEAGE_NAME"=2 AND "DELETED_AT"="L"."LINEAGE_ID")
 filter("L"."LINEAGE_ID"<=115)
59 - access("SL"."LINEAGE_NAME"=2 AND "SL"."LINEAGE_ID"<=115)
60 - access("A"."SDE_STATE_ID"="SL"."LINEAGE_ID")
 filter("A"."SDE_STATE_ID"<=115)
61 - filter("A"."ANSWERS"=0)
68 - access("L"."LINEAGE_NAME"=2 AND "L"."LINEAGE_ID"<=115)
69 - access("DELETED_AT"="L"."LINEAGE_ID" AND "SDE_DELETES_ROW_ID"="B"."OBJECTID" AND
 "SDE_STATE_ID"=0)
 filter("DELETED_AT"<=115)
70 - access("A"."OBJECTID"="SDE_DELETES_ROW_ID" AND "A"."SDE_STATE_ID"="SDE_STATE_ID")
73 - filter("DELETED_AT"<=115 AND "SDE_STATE_ID"<=115 AND "SDE_STATE_ID">0)
74 - access("L"."LINEAGE_NAME"=2 AND "DELETED_AT"="L"."LINEAGE_ID")
 filter("L"."LINEAGE_ID"<=115)
77 - access("SL"."LINEAGE_NAME"=2 AND "SL"."LINEAGE_ID"<=115)
78 - access("A"."SDE_STATE_ID"="SL"."LINEAGE_ID")
 filter("A"."SDE_STATE_ID"<=115)
Note
 - dynamic sampling used for this statementThe TKPROF output for this statement looks like the following:
TKPROF: Release 11.1.0.6.0 - Production on Thu Sep 24 09:30:01 2009
Copyright (c) 1982, 2007, Oracle. All rights reserved.
Trace file: pro &

The TKPROF output for this statement looks like the following:
TKPROF: Release 11.1.0.6.0 - Production on Thu Sep 24 09:30:01 2009
Copyright (c) 1982, 2007, Oracle. All rights reserved.
Trace file: problem.trc
Sort options: default
count = number of times OCI procedure was executed
cpu = cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk = number of physical reads of buffers from disk
query = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows = number of rows processed by the fetch or execute call
SELECT V__96.CONNECTOR_OBJECTID, V__96.CONNECTOR_CLASSID, V__96.FROM_OBJECTID, V__96.TO_OBJECTID, V__96.FROM_CLASSID, V__96.TO_CLASSID,
V__96.FROM_FIRSTUNIT, V__96.TO_FIRSTUNIT, V__96.NUMBER_OF_UNITS, TMP_TRACE.FIRST_UNIT, TMP_TRACE.LAST_UNIT, V__96.INV_STATUS_NUMBER,
TMP_TRACE.FIRST_UNIT, TMP_TRACE.LAST_UNIT, V__96.ANSWERS, V__96.PRIORITY, V__97.FIRST_UNIT, V__97.N_UNITS, V__97.MID_SPAN_DISTANCE FROM
NE.TMP_TRACE,(SELECT
b.OBJECTID,b.ANSWERS,b.CONNECTOR_CLASSID,b.CONNECTOR_OBJECTID,b.FROM_CLASSID,b.FROM_OBJECTID,b.TO_CLASSID,b.TO_OBJECTID,b.FROM_FIRSTUNIT,b.TO_FIRSTUNIT,b.NUM
BER_OF_UNITS,b.INV_STATUS_NUMBER,b.SPLICE_CLOSURE_NAME,b.WORK_ORDER_NAME,b.WORK_ORDER_ITEM_NUMBER,b.INVENTORY_STATUS_CODE,b.PRIORITY FROM NE.connection b
WHERE b.OBJECTID NOT IN (SELECT /*+ HASH_AJ */ SDE_DELETES_ROW_ID FROM NE.D96 WHERE DELETED_AT IN (SELECT l.lineage_id FROM SDE.state_lineages l WHERE
l.lineage_name = :"SYS_B_00" AND l.lineage_id <= :"SYS_B_01") AND SDE_STATE_ID = :"SYS_B_02") UNION ALL SELECT
a.OBJECTID,a.ANSWERS,a.CONNECTOR_CLASSID,a.CONNECTOR_OBJECTID,a.FROM_CLASSID,a.FROM_OBJECTID,a.TO_CLASSID,a.TO_OBJECTID,a.FROM_FIRSTUNIT,a.TO_FIRSTUNIT,a.NUM
BER_OF_UNITS,a.INV_STATUS_NUMBER,a.SPLICE_CLOSURE_NAME,a.WORK_ORDER_NAME,a.WORK_ORDER_ITEM_NUMBER,a.INVENTORY_STATUS_CODE,a.PRIORITY FROM NE.A96
a,SDE.state_lineages SL WHERE (a.OBJECTID, a.SDE_STATE_ID) NOT IN (SELECT /*+ HASH_AJ */ SDE_DELETES_ROW_ID,SDE_STATE_ID FROM NE.D96 WHERE DELETED_AT IN
(SELECT l.lineage_id FROM SDE.state_lineages l WHERE l.lineage_name = :"SYS_B_03" AND l.lineage_id <= :"SYS_B_04") AND SDE_STATE_ID > :"SYS_B_05") AND
a.SDE_STATE_ID = SL.lineage_id AND SL.lineage_name = :"SYS_B_06" AND SL.lineage_id <= :"SYS_B_07") V__96,(SELECT
b.OBJECTID,b.TRAY_NUMBER,b.DB_LOSS,b.FIRST_UNIT,b.N_UNITS,b.CONNECTION_OBJECTID,b.CONNECTOR_TYPE_NAME,b.DEDICATED_STATUS,b.MID_SPAN_DISTANCE FROM
NE.connection_attributes b WHERE b.OBJECTID NOT IN (SELECT /*+ HASH_AJ */ SDE_DELETES_ROW_ID FROM NE.D97 WHERE DELETED_AT IN (SELECT l.lineage_id FROM
SDE.state_lineages l WHERE l.lineage_name = :"SYS_B_08" AND l.lineage_id <= :"SYS_B_09") AND SDE_STATE_ID = :"SYS_B_10") UNION ALL SELECT
a.OBJECTID,a.TRAY_NUMBER,a.DB_LOSS,a.FIRST_UNIT,a.N_UNITS,a.CONNECTION_OBJECTID,a.CONNECTOR_TYPE_NAME,a.DEDICATED_STATUS,a.MID_SPAN_DISTANCE FROM NE.A97
a,SDE.state_lineages SL WHERE (a.OBJECTID, a.SDE_STATE_ID) NOT IN (SELECT /*+ HASH_AJ */ SDE_DELETES_ROW_ID,SDE_STATE_ID FROM NE.D97 WHERE DELETED_AT IN
(SELECT l.lineage_id FROM SDE.state_lineages l WHERE l.lineage_name = :"SYS_B_11" AND l.lineage_id <= :"SYS_B_12") AND SDE_STATE_ID > :"SYS_B_13") AND
a.SDE_STATE_ID = SL.lineage_id AND SL.lineage_name = :"SYS_B_14" AND SL.lineage_id <= :"SYS_B_15") V__97 WHERE ((((( (
 NE.tmp_trace.equipment_object_id = V__96.to_objectid
 AND
 V__96.to_classid = :"SYS_B_16"
 OR
 NE.tmp_trace.transmedia_object_id = V__96.to_objectid
 AND
 V__96.to_classid = :"SYS_B_17"
 )) AND (
 (V__96.to_firstunit
 BETWEEN NE.tmp_trace.first_unit AND NE.tmp_trace.last_unit)
 OR
 (NE.tmp_trace.first_unit BETWEEN V__96.to_firstunit
 AND V__96.to_firstunit + V__96.number_of_units - :"SYS_B_18")
 )) AND V__96.answers = :"SYS_B_19") AND V__96.objectid = V__97.connection_objectid) AND (NE.tmp_trace.session_id =
:"SYS_B_20"))
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 5.98 5.99 0 22652 0 10
total 3 5.98 5.99 0 22652 0 10
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 45
Rows Row Source Operation
 10 NESTED LOOPS (cr=22652 pr=0 pw=0 time=654515 us cost=67 size=282 card=1)
 10 NESTED LOOPS (cr=22436 pr=0 pw=0 time=653673 us cost=61 size=235 card=1)
 10 TABLE ACCESS FULL TMP_TRACE (cr=5 pr=0 pw=0 time=7 us cost=2 size=65 card=1)
 10 VIEW (cr=22431 pr=0 pw=0 time=0 us cost=59 size=170 card=1)
1773000 UNION-ALL (cr=22431 pr=0 pw=0 time=93649 us)
 0 NESTED LOOPS ANTI (cr=30 pr=0 pw=0 time=0 us cost=3 size=185 card=1)
 0 TABLE ACCESS FULL CONNECTION (cr=30 pr=0 pw=0 time=0 us cost=2 size=181 card=1)
 0 VIEW PUSHED PREDICATE VW_NSO_3 (cr=0 pr=0 pw=0 time=0 us cost=1 size=4 card=1)
 0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=1 size=20 card=1)
 0 INDEX RANGE SCAN LINEAGES_PK (cr=0 pr=0 pw=0 time=0 us cost=1 size=7 card=1)(object id 34021)
 0 INDEX UNIQUE SCAN D96_PK (cr=0 pr=0 pw=0 time=0 us cost=0 size=13 card=1)(object id 35121)
1773000 HASH JOIN RIGHT ANTI (cr=22401 pr=0 pw=0 time=75084 us cost=56 size=46948 card=484)
 0 VIEW VW_NSO_4 (cr=180 pr=0 pw=0 time=0 us cost=2 size=26 card=1)
 0 FILTER (cr=180 pr=0 pw=0 time=0 us)
 0 NESTED LOOPS (cr=180 pr=0 pw=0 time=0 us cost=2 size=20 card=1)
 0 INDEX FAST FULL SCAN D96_PK (cr=180 pr=0 pw=0 time=0 us cost=2 size=13 card=1)(object id 35121)
 0 INDEX UNIQUE SCAN LINEAGES_PK (cr=0 pr=0 pw=0 time=0 us cost=0 size=7 card=1)(object id 34021)
1773000 NESTED LOOPS (cr=22221 pr=0 pw=0 time=56155 us)
1773000 NESTED LOOPS (cr=3231 pr=0 pw=0 time=15078 us cost=53 size=34364 card=484)
 50 INDEX RANGE SCAN LINEAGES_PK (cr=10 pr=0 pw=0 time=7 us cost=1 size=7 card=1)(object id 34021)
1773000 INDEX RANGE SCAN A96_STATEID_IX1 (cr=3221 pr=0 pw=0 time=6810 us cost=32 size=0 card=1774)(object id 35116)
1773000 TABLE ACCESS BY INDEX ROWID A96 (cr=18990 pr=0 pw=0 time=0 us cost=52 size=82560 card=1290)
 10 VIEW (cr=216 pr=0 pw=0 time=0 us cost=7 size=47 card=1)
 10 UNION ALL PUSHED PREDICATE (cr=216 pr=0 pw=0 time=0 us)
 0 NESTED LOOPS ANTI (cr=1 pr=0 pw=0 time=0 us cost=2 size=82 card=1)
 0 TABLE ACCESS BY INDEX ROWID CONNECTION_ATTRIBUTES (cr=1 pr=0 pw=0 time=0 us cost=1 size=78 card=1)
 0 INDEX RANGE SCAN GDB_59_CONNECTIO (cr=1 pr=0 pw=0 time=0 us cost=1 size=0 card=1)(object id 34346)
 0 VIEW PUSHED PREDICATE VW_NSO_1 (cr=0 pr=0 pw=0 time=0 us cost=1 size=4 card=1)
 0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=1 size=20 card=1)
 0 INDEX RANGE SCAN LINEAGES_PK (cr=0 pr=0 pw=0 time=0 us cost=1 size=7 card=1)(object id 34021)
 0 INDEX UNIQUE SCAN D97_PK (cr=0 pr=0 pw=0 time=0 us cost=0 size=13 card=1)(object id 35127)
 10 HASH JOIN ANTI (cr=215 pr=0 pw=0 time=0 us cost=5 size=55 card=1)
 10 NESTED LOOPS (cr=35 pr=0 pw=0 time=0 us cost=2 size=29 card=1)
 10 TABLE ACCESS BY INDEX ROWID A97 (cr=25 pr=0 pw=0 time=0 us cost=2 size=22 card=1)
 10 INDEX RANGE SCAN GDB_59_CONNECTIO_A (cr=15 pr=0 pw=0 time=0 us cost=1 size=0 card=1)(object id 35122)
 10 INDEX UNIQUE SCAN LINEAGES_PK (cr=10 pr=0 pw=0 time=0 us cost=0 size=7 card=1)(object id 34021)
 0 VIEW VW_NSO_2 (cr=180 pr=0 pw=0 time=0 us cost=2 size=26 card=1)
 0 FILTER (cr=180 pr=0 pw=0 time=0 us)
 0 NESTED LOOPS (cr=180 pr=0 pw=0 time=0 us cost=2 size=20 card=1)
 0 INDEX FAST FULL SCAN D97_PK (cr=180 pr=0 pw=0 time=0 us cost=2 size=13 card=1)(object id 35127)
 0 INDEX UNIQUE SCAN LINEAGES_PK (cr=0 pr=0 pw=0 time=0 us cost=0 size=7 card=1)(object id 34021)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 2 0.00 0.00
SQL*Net message from client 2 0.00 0.00After manually rewrite query in TOAD it produces nested loops on business table and than access v__96, v__97 produce desired quick performance.
I can use stored outlines but this is the last chance. I am playing with hints right now to produce desired plan with no result yet.
Does anybody know how to insist Oracle to merge internal views to bigger query block, so Oracle can choose better plan?
Or any guide what hints to use from ol$hints to get desired result via hints addition to original sql query (thanks God application don't cut hints just pass-through to Oracle)?
Thanks,
Sergiy

How can I write a SQL statement which checks if a table exists?

How can I write a SQL statement which tells me whether a table exists?

execute an sql query: select * from <tablename>
catch the exception n check whether the erroe code
matches the one that occurs for table doesn't exist
that's itHow is your answer any different from the one given in the first reply?
It isn't.
As WorkForFood says DatabaseMetaData has a bunch of methods for getting information about tables but this is more useful when you don't know the names of any of the tables.. it sounds like you do so I would concur SELECT from table is probably the quickest way to go. If it helps the Xopen error should be either S1000 or 42S01 (I think) but I would try and see if there is a specific vendor code for table not found/not exists error and check for that.

Optimization of Join statement between MKPF and MSEG table for improving pe

Hi All,
I had a issue where we are executing one custom report and it is getting timed out after 45 minutes. We further executed with trace on and got to the conclusion with the help of BASIS that about 42 minutes of the 45 minutes tracetime are spent by a join over the tables MKPF en MSEG.
This join is done by the abap statement:
SELECT mkpf~mblnr
 mkpf~mjahr
 mkpf~bldat
 mkpf~blart
 mseg~matnr
 mseg~werks
 INTO CORRESPONDING FIELDS OF TABLE i_matdoc_we
 FROM mkpf INNER JOIN mseg ON mkpfmblnr = msegmblnr
 AND mkpfmjahr = msegmjahr
FOR ALL entries IN i_list
 WHERE mkpf~mblnr BETWEEN lv_interval-fromnumber
 AND lv_interval-tonumber
 AND mkpf~blart = 'WE'
 AND mkpf~bldat LE gv_last_day_fisc_period
 AND mseg~matnr = i_list-matnr
 AND mseg~werks IN s_werks.
Here, I_LIST comprises of stock for specific period as entered in the selection screen for that particular Material and plant
LV_INTERVAL is range of all goods receipts for material and gv_last_day_fisc_period is current date.
During the tracetime this statement was executed more than 20.000 times, until the transaction timed out.
The individual executions of this select stmnt varied (roughly) between 50 and 1200 miliseconds. (depends wheter the requested database block is in the buffercache or must be read from disk).
The acesspath used to execute the query ( see below) is optimal, given the present indexes.
Index MSEG~M is covering al the specified selection criteria for MSEG.
Index MKPF-0 is used to search the specified MBLNR criterium in MKPF.
The remaining selection criteria MKPF-BLART and MKPF-BLDAT are not indexed, and imho this would also not make sense for this query.
BLART has only 3 different values n the MKPF table, and the selected value 'WE' has more than 1 million occurences.
BLDAT is selected with =<20110903, so this is not distinctive as well.
Can any one suggest some better way to write this query.
Regards,
Subhajit

Actually there are 2 select statements where JOIN have been introduced and especially the time out is occurring in the second JOIN.
Find all goods receipts for material
PERFORM get_number_range_matdoc USING '03'
 CHANGING lv_interval.
SELECT mkpf~mblnr
 mkpf~mjahr
 mkpf~bldat
 mkpf~blart
 mseg~matnr
 mseg~werks
 INTO CORRESPONDING FIELDS OF TABLE i_matdoc_we
 FROM mkpf INNER JOIN mseg ON mkpfmblnr = msegmblnr
 AND mkpfmjahr = msegmjahr
FOR ALL entries IN i_list
 WHERE mkpf~mblnr BETWEEN lv_interval-fromnumber
 AND lv_interval-tonumber
 AND mkpf~blart = 'WE'
 AND mkpf~bldat LE gv_last_day_fisc_period
AND mseg~matnr = i_list-matnr
 AND mseg~werks IN s_werks.
CLEAR lv_interval.
PERFORM get_number_range_matdoc USING '02'
 CHANGING lv_interval.
Find all goods issues for material
SELECT mkpf~mblnr
 mkpf~mjahr
 mkpf~bldat
 mkpf~blart
 mseg~matnr
 mseg~werks
 INTO CORRESPONDING FIELDS OF TABLE i_matdoc_wa
 FROM mkpf INNER JOIN mseg ON mkpfmblnr = msegmblnr
 AND mkpfmjahr = msegmjahr
FOR ALL entries IN i_list
 WHERE mkpf~mblnr BETWEEN lv_interval-fromnumber
 AND lv_interval-tonumber
 AND ( mkpfblart = 'WA' OR mkpfblart = 'WI' )
 AND mkpf~bldat LE gv_last_day_fisc_period
AND mseg~matnr = i_list-matnr
 AND mseg~bwart NE '561'
 AND mseg~bwart NE '562'
 AND mseg~bwart NE '961'
AND mseg~bwart NE '962'
AND mseg~werks IN s_werks.
Mainly the second JOIN is creating the problem... In the backend ORACLE is being used as database.
Please suggest how I can improve the performance of these joins as its taking more than 45 mins..

Updatable Materialized View and Master Table on same database

Hi all,
My first question - Is it possible to have an Updatable Materialized View and the associated Master Table located on the same database?
This is the requirement scenario:
One unique database D exists.
A is a batch table. Only inserts are allowed on Table A.
M is an updatable materialized view on Table A (Master). Only updates are allowed on M (no insert or delete).
Requirement is to push updates/changes from M to A periodically and then get the new inserted records from A into M via a refresh.
Is this possible? What other approaches are applicable here?

John,
My question is related to the implementation and setup of the environment as explained in the above example. How can I achieve this considering that I have created an updatable m-view?
If possible, how do I push changes made to an updatable m-view back to it's master table when/before I execute DBMS_MVIEW.REFRESH on the m-view? What is the procedure to do this if both table and mview exist on the same database? Do I need to create master groups, materialized view refresh groups, etc.?
One more thing.. Is there a way to retain changes to the m-view during refresh? In this case, only newly inserted/updated records in the associated table would get inserted into m-view. Whereas changes made to m-view records would stay as-is.
Hope my question is directed well. Thanks for your help.
- Ankit

Creating a master-detail relation between a view and a table

Hi all,
I have a problem with creating a master-detail relation between a database-view with lots of customer data and a small table with per customer a list of entities of our companies who may work for that customer.
Somehow I seem to be unable to create a relation between these two. I can't find where I can make a foreign key using Toplink to implement the relationship. And neither can I get a Viewlink object doing the job using ADF Business Components.
Somebody any suggestions on this problems?
Regards,
Birgit

There is a key relationship between two fields which form the primary key in the main table of the view and two fields in the second table.
I created a viewlink manually, but I still couldn't get the data correct i.e. a form with one record of a customer from the main view and a small table with all entities of our company who can make performances for that customer.
I tried to find a manual or a how-to on this topic but I didn't find anything helpfull yet.
Regards,
Birgit
After a couple more tries, I got the master-detail working. With all the fiddling I am not sure what caused the problem but I think the finally action was checking which fields of the view were marked as primary keys.
Now everthing is up and running.
Birgit
Message was edited by:
user492355

Performance tuning fro a select stmnt consisting of View and DB Table

Hi Gurus ,
I have a select query which is consuming a lot of time for execution. Well it selects details from a custom view ZV_MKPF_MSEG (join of MKPF and MSEG) and table MARA as following
SELECT GI~BUKRS                                   "company code
         GI~WERKS                                    "Plant
         GI~BWART                                    "Movement Type
         GI~BUDAT                                    "Posting Date
         GI~MBLNR                                    "Mat Doc Number
         GI~ZEILE                                    "Item
         GI~KOSTL                                    "cost center
         GI~MENGE                                    "Quantity
         GI~SHKZG                                    "Debit credit ind
         MAMATKL MAMATNR MA~MEINS
         INTO CORRESPONDING FIELDS OF TABLE PT_GITAB
         FROM ZV_MKPF_MSEG AS GI INNER JOIN MARA AS MA
              ON MAMATNR = GIMATNR
         WHERE GI~BUKRS IN S_BUKRS AND
               GI~WERKS IN S_WERKS AND
               GI~BUDAT IN S_BUDAT AND
               GI~BWART IN S_BWART AND
               GI~MBLNR IN S_MBLNR AND
               MA~MATKL IN S_MATKL
         ORDER BY GIMBLNR GIZEILE.
how we should manipulate this query in order to increase the perfromance ? And could anybody give some idea about the use of indexes for a table since both MSEG and MKPF tables have indexes attached.
Thanx
Kylie
Edited by: kylietisha on Jun 7, 2010 5:01 PM

Moderator message - Please see Please Read before Posting in the Performance and Tuning Forum before posting - post locked
Rob

Can please tell me how to implement expand and collapse table row data?

i am trying implement expand and collapse table row data but i do not get any ideas..can please any one help me its an urgent requirement

Yes, we can.
I think the best place for you to start for this is the NI Developer Zone. I recommend beginning with these tutorials I found by searching on "data log rio". There were more than just these few that might be relevant to your project but I'll leave that for you to decide.
NI Compact RIO Setup and Services -> http://zone.ni.com/devzone/cda/tut/p/id/11394
Getting Started with CompactRIO - Logging Data to Disk -> http://zone.ni.com/devzone/cda/tut/p/id/11198
Getting Started with CompactRIO - Performing Basic Control -> http://zone.ni.com/devzone/cda/tut/p/id/11197
These will probably give you links to more topics/tutorials/examples that can help you design and implement your target system.
Jason
Wire Warrior
Behold the power of LabVIEW as my army of Roomba minions streaks across the floor!

Project Pro 2013 Crashing - has something to do with Global Views and or Tables?

I have 800 or so active project files in my 2013 PWA instance. I am just starting to get my head around this potential bug. I have not reproduced it yet but I have seen it a number of times. MS Project Pro randomly
freezes after one of the following actions
1) Attempting to change Gantt Chart Task text format
2) Attempting to changing from one view to another
3) Attempting to save the file
In each case this behavior is corrected by going to the Organizer and removing any and all local Views and Tables that have the same name as the a View or Table in the Global.
The fix is easy but users are pretty upset when they lost work from a multi-hour meeting.
I imagine this is a conflict with the view or table name? ?
Has anyone heard of this before? Clues?

John,
I have not seen this issue myself, nor have I found a reference to it in the fixes in the CU. Having said that, I am a little confused as to how users would have local views with the same name as the enterprise ones?
May be one thing to try is to rename the enterprise views with the word 'Enterprise' at the beginning and see if it fixes the issue?
Cheers,
Prasanna Adavi, Project MVP
Blog:
Podcast:
Twitter:
LinkedIn:

Can I write a program in C/C++ and call iPlanet APIs and get the performance related information directly from iPlanet webserver ?

Just to give an example, Microsoft IIS webserver provides the
performance counters, which one can read from registry using
APIs provided by Microsoft from a C/C++ program and get all the
performance related data ... r some similar interfaces
provided by iPlanet webserver ???

The spell checked version...
I really appreciate the replies. I have looked into RMI and think it might fit the bill, ,BUT, let me clarify a bit and see if there are any other ideas floating around out there.
A user, using a web interface on machine A will click the , "I want my file" button. This flags the DB to create a file for that user. I will have multiple daemons running on other machines B,C,D whose sole job is to check the db, compile the file (This is the part that takes huge overhead so I wanted it distributed), then write the file. The trick is the file needs to be written to machine A. So I figure, using RMI, I can write a simple "write this file" object that will accept a byte stream or byte array, and a correct path to write to. Does this sound like a good methodology?
I've never done anything like this so I am really shooting in the dark.
Thanks again for the posts.
Paul

I resized the window to 150% and now I can't get it back to 100% view and keep it that size. How do I get it back to the right size?

I resized the adobe window to 150% and now I can't get it back to the 100% size and keep it that size. How do I get the original 100% back and keep it that size?

Hi Linda,
To control the page zoom option you can also go to Edit> Preferences> Page Display.
Regards,
Rave

Is is possible to have the images as thumbnails and make it so you can click on them for a larger view and then click them again to have it go back to the original size? In an interactive pdf?

I am designing an interactive catalog in a pdf. Is it possible to have the images as a thumbnail and then click them to enlarge the image and then click again to make them go back to the original size?
Thank you in advance!
Stephanie

It can be done with Show/Hide buttons:
Here's a button created from a small version of the image (notice that it's selected in the image below):
The small button has a Show/Hide Buttons and Forms action. It's action is to make the Larger Image visible (eyeball turned on) with the small image hidden (eyeball turned off).
The large image is also turned into a button (shown below):
Notice the checkbox "Hidden Until Triggered". The large button is hidden until it's triggered by the small button. Clicking on the large image also causes a Show/Hide action which shows the Small button and hides the large button.

Can I have separate Style Formatting for viewing and sending emails?

Hey All
I was just wondering if it was possible to have separate style settings for viewing emails sent to you and sending emails to others.
Basically I want to set up a kind of style template for all my outgoing emails but I don't necessarily want my incoming mail to be like that if you see where I am coming from.
Any help would be greatly appreciated.
Thanks
Derek

Thanks for that.
That would certainly be an option. However after some further investigation I came across this article which shows me exactly what I was looking for:
http://www.apple.com/pro/tips/mail_templates.html
But thanks for your help though. It is really appreciated.
Derek

Can we write a join on a view and a table

Similar Messages

Maybe you are looking for