Real explain plan differs from one in v$sqlarea

I have some more or less complex queries which I catch on runtime by reading v$sqlarea table to find sql with high cost..
but..
I found some highly costed sql, but when I run it through client ti see it's explain plan and execution time, it's much faster with very little cost
why?
am I wrong when I read v$sqlarea?
I'm using Oracle 11g R2

This is not at all surprising. Jonathan Lewis and many other have discussed this numerous times both in these forums, in books, in white papers, and in conference presentations.
That said ... you should be looking in gv$sql_plan.

Similar Messages

What are the ways to Copy Firm Planned Order from one ASCP Plan to another?

We run two EDD Plans with very similar options, but with different plan horizons.
To have the suggestions synchronized, we need to copy the "Firm Planned Orders" from one plan to another.
We tried inserting the records in MSC_ST_SUPPLIES with Order type 5 and firm planned type 1 with appropriate plan id, but Planning ODS Load is not considering those inserted records.
We don't want to insert directly into MSC_SUPPLIES.
Any inputs is appreciated.
Thanks
Sundar

You can also call a custom DTSX package in SSIS via the datamanager.
there are at least 5 ways of transfering data in BPC between apps.
1. Through the front end (excel etc) via evdre/evsnds
2. Through Script logic using *Dest App
3. Using BPC's standard export dtsx package via DM
4. Using SSIS using BPC's custom SSIS tasks
5. Through Script logic using stored procs.
i am sure people will come up with more.
remember if you use ssis and move data into any table but the wb, you need to process the cube afterwards.

Copy billing plan lines from one sales document to another

HI,
we want to copy the open billing plan lines from one sales document to another, which routine should we use in the copy control in configuration?
we tried to use,401 and 402 but with no success..
it's should'nt be a standard process with out any development?
Best Regards
Yehudit

Hi,
Check where you entering this routine
If your billing plan at header then enter it at header in copy control, if billing plan is item level then maintain at Item level in copy control
Kapil

Does Closed Captioning display differently from one Player/TV to another?

Hi Everyone,
We just completed our first project at our facility that involved Closed Captioning from an .SCC file produced by CPC and when we preview a DVD Test of the project, the captions are not displaying as expected. We received a VHS preview copy which display the captions fine, but when we look at the DVD Test in the Apple DVD Player, the captions are not justified in a consistant manner, and sometimes a couple appear as if they were haphazardly placed on the screen.
Is possible that Captioning as how it is interpreted/displayed might vary from one TV or DVD Player to another?
Any help or comments would be greatly appreciated. Thank you in advance, everyone.
Regards,
-James-

UPDATE:
So far I've tested the DVD created with Closed Captions from the *.scc file, and my findings are that the PC software I've tested in closely match that of the VHS open-caption dub that the captioning company provided us. I have tried the VLC Player on the Mac, but have not had success in enabling the captions, nor been able to find any posts on the VLC support forum.
I've also been successful at finding and testing a DVD Player that can display the captions on the DVD, and find that they play similarly to that on both the VHS open-caption an PC Playback, but the position on the screen is slightly different.
Does anyone have any other experience with Closed Captioning that could either offer insight to the working theory that each TV/DVD Player/Computer DVD Software platform interprets closed captions differently from one another?
Regards and thanks in advance,
-James-

Explain plan different with no stats but with no rows & rows in a table

Hi All,
This is in Oracle 8.1.7.4.0 DB.
1. Query was taking long time to return rows. It was based on a view.
2. View has multiple tables.
3. The explain plan was showing one of the Table(e.g. TABLE1) using incorrect INDEX. At the time of explain plan table has no statistics.
4. truncated Table TABLE1
5. The explain plan now taking correct INDEX for the table TABLE1.
How does optimizer choosing the incorrect index when rows in a table & correct index when there are no rows in the table ?
any insights.
Thanks
Sandeep

I don't know about your particular db version, but CBO in absence of statistics uses some default values (e.g. average row length 100 bytes) and also uses actual number of block for the table. I assume something similar might be for indexes.
To be sure what has changed you can run 10053 level trace.
Gints Plivna
http://www.gplivna.eu

BPS Copy plan data from one cost center to another using vairables

Hi experts,
I am trying to copy the planning data from one cost center to another in BPS.
I have just done it using a copy function and in the parameter group entering the costs centers for source and destinations.
What I am trying now it is to let the user select what this destination cost center could be.
I don`t know if this can be done using a variable. What I am thinking is; when the user enters executes the parameter group a pop-up appear that let him select the cost center for the destination.
May be this is not possible. Can you suggest me other ways of doing this?
Thanks in advance

Hi,
u can achieve this by creating a variable with the replacement type as 'User Defined Values'. You also need to enable the check box 'Input Allowed by user'. And at the planning level, in the 'Selection' tab, you should map the charecteristic (Cost Center) with the created variable. Same thing should be done at the planning package level.
Then, when you execute the parameter group, a pop-up comes asking for the value of the costcenter.
Regards,
Srinivas Kamireddy.

Is the PSD created from Multi-page PDF to PSD different from one created using File- Open?

My printer is telling me that a PSD created using the Automate->Multi-page PDF to PSD is different from one created by using File->Open. Does anyone know if this is true? If so, why?

CMD I on the .ai file
Change open with to AICS6
Click Change All

Explain plan different for same query

Hi all,
I have a query, which basically selects some columns from a remote database view. The query is as follows:
select * from tab1@remotedb, tab2@remotedb
where tab1.cash_id = tab2.id
and tab1.date = '01-JAN-2003'
and tab2.country_code = 'GB';
Now, i am working on two environments, one is production and other is development. Production environment has following specification:
1. Remotedb = Oracle9i, Linux OS
2. Database on which query is running = Oracle10g, Linux OS
Development environment has following specification:
1. Remotedb = Oracle10g, Windows OS
2. Database on which query is running = Oracle10g, Linux OS
Both databases in development and production environments are on different machines.
when i execute the above query on production, i see full table scans on both tables in execution plan(TOAD), but when i execute the query in development, i see that both remote database tables are using index.
Why am i getting different execution plans on both databases? is there is any difference of user rights/priviliges or there is a difference of statistics on both databases. I have checked the statistics for both tables on Production and Development databases, they are updated.
This issue is creating a performance disaster in our Production system. Any kind of help or knowledge sharing is appreciated.
Thank you and Best Regards.

We ran into a similar situation yesterday morning, though our implementation was easier than yours. Different plans in development and production though both systems were 10gR2 at the time. Production was doing a Merge Join Cartesian (!) instead of nested loop joins. Our DBA figured out that the production stats had been locked for some tables preventing stat refresh; she unlocked them and re-analyzed so which fixed our problem.
Of some interest was discovering that I got different execution plans from the same UPDATE via EXPLAIN PLAN and SQL*PLUS AUTOTRACE in development. Issue appears to have been bind peeking. Converting bind variables to constants yielded the AUTOTRACE plan, as did turning bind peeking off while using the bind variables. CURSOR_SHARING was set to EXACT too.
Message was edited by:
riedelme

Explain Plan Differing

The below same query runs fast at PL/SQL , while the same query run from front end (EBS R 12.0.4) using concurrent request runs verl slow , both has diffrent plan , please share some thought.
Below query when i run from backend (PL/SQL Developer) it returns row within a second
SELECT /*+ gather_plan_statistics product_item_2.txt */ OH.ORG_ID,BUNIT.BU_ID,OL.INVENTORY_ITEM_ID,CUST.account_number,CUST.ACCOUNT_NAME,CUST.CUSTOMER_CLASS_CODE,
NVL(SUM(OL.FULFILLED_QUANTITY),0) as sale_qty
FROM
OE_ORDER_HEADERS_ALL OH,OE_ORDER_LINES_ALL OL,
HZ_CUST_ACCOUNTS CUST,mtl_categories_vl CAT,
mtl_item_categories IC,(select FLEX_VALUE BU_ID,DESCRIPTION B_NAME from fnd_flex_values_vl t
     where t.FLEX_VALUE_SET_ID ='1012990') BUNIT
WHERE OH.HEADER_ID = OL.HEADER_ID
AND CUST.CUST_ACCOUNT_ID =
(SELECT DISTINCT ACCT.CUST_ACCOUNT_ID
FROM HZ_CUST_ACCOUNTS ACCT,HZ_CUST_ACCT_SITES_ALL ACCT_SITE,
HZ_LOCATIONS LOC,HZ_PARTY_SITES PARTY_SITE,
HZ_CUST_SITE_USES_ALL SUSE,HZ_PARTIES P
WHERE ACCT.PARTY_ID = PARTY_SITE.PARTY_ID
AND   ACCT.CUST_ACCOUNT_ID = ACCT_SITE.CUST_ACCOUNT_ID
AND   SUSE.CUST_ACCT_SITE_ID = ACCT_SITE.CUST_ACCT_SITE_ID
AND   ACCT_SITE.PARTY_SITE_ID = PARTY_SITE.PARTY_SITE_ID
AND   LOC.LOCATION_ID = PARTY_SITE.LOCATION_ID
AND   SUSE.SITE_USE_ID = OL.SHIP_TO_ORG_ID
AND P.PARTY_ID = ACCT.PARTY_ID
AND P.PARTY_ID = PARTY_SITE.PARTY_ID
AND   SUSE.SITE_USE_CODE = 'SHIP_TO'
AND ACCT_SITE.ORG_ID = &P_ORG_ID
AND OH.ORG_ID = &P_ORG_ID
AND OL.ACTUAL_SHIPMENT_DATE BETWEEN &P_FROM_DATE AND &P_TO_DATE
AND OL.UNIT_SELLING_PRICE != 0
AND OL.LINE_CATEGORY_CODE = 'ORDER'
AND OL.ORDERED_ITEM = NVL(&ITEM_HIGH, OL.ORDERED_ITEM)
AND BUNIT.BU_ID = nvl(&p_business_unit,bunit.bu_id)
AND CAT.CATEGORY_ID   =   IC.CATEGORY_ID
AND CAT.STRUCTURE_ID = 50289
AND IC.INVENTORY_ITEM_ID = OL.INVENTORY_ITEM_ID
AND IC.ORGANIZATION_ID   = OH.SHIP_FROM_ORG_ID
and     cat.SEGMENT3 = BUNIT.BU_ID
GROUP BY
OH.ORG_ID,BUNIT.BU_ID,OL.INVENTORY_ITEM_ID,CUST.account_number,CUST.ACCOUNT_NAME,CUST.CUSTOMER_CLASS_CODE
ORDER BY 1Plan for above query is as follows
SQL> set pagesize 1000
SQL> /
PLAN_TABLE_OUTPUT
SQL_ID 5g71mvqaat8x3, child number 0
Plan hash value: 610424373
| Id | Operation                             | Name                   | Starts | E-Rows | A-Rows |   A-Time   | Buffers | OMem | 1Mem | Used-Mem |
|   1 | HASH GROUP BY                        |                        |      1 |      1 |      2 |00:00:00.64 |     144K|       |       |          |
|   2 |   NESTED LOOPS                        |                        |      1 |      1 |     71 |00:00:00.30 |     144K|       |       |          |
|   3 |    NESTED LOOPS                       |                        |      1 |      1 |   1704 |00:00:00.26 |     138K|       |       |          |
|* 4 |     HASH JOIN                         |                        |      1 |      1 |   3312 |00:00:00.05 |     132K|   887K|   887K| 1236K (0)|
|   5 |      TABLE ACCESS BY INDEX ROWID      | MTL_ITEM_CATEGORIES    |      1 |    506 |   1075 |00:00:00.02 |     361 |       |       |          |
|   6 |       NESTED LOOPS                    |                        |      1 |      1 |   1077 |00:00:00.04 |      24 |       |       |          |
|   7 |        NESTED LOOPS                   |                        |      1 |      1 |      1 |00:00:00.01 |      19 |       |       |          |
|   8 |         NESTED LOOPS                  |                        |      1 |      1 |      1 |00:00:00.01 |      18 |       |       |          |
|   9 |          NESTED LOOPS                 |                        |      1 |      1 |      1 |00:00:00.01 |      15 |       |       |          |
|* 10 |           TABLE ACCESS BY INDEX ROWID | FND_FLEX_VALUES        |      1 |      1 |      1 |00:00:00.01 |      13 |       |       |          |
|* 11 |            INDEX RANGE SCAN           | IDX$$_65860003         |      1 |     22 |     52 |00:00:00.01 |       2 |       |       |          |
|* 12 |           INDEX UNIQUE SCAN           | FND_FLEX_VALUES_TL_U1 |      1 |      1 |      1 |00:00:00.01 |       2 |       |       |          |
|* 13 |          TABLE ACCESS BY INDEX ROWID | MTL_CATEGORIES_B       |      1 |      1 |      1 |00:00:00.01 |       3 |       |       |          |
|* 14 |           INDEX RANGE SCAN            | IDX$$_79530001         |      1 |      1 |      2 |00:00:00.01 |       1 |       |       |          |
|* 15 |         INDEX UNIQUE SCAN             | MTL_CATEGORIES_TL_U1   |      1 |      1 |      1 |00:00:00.01 |       1 |       |       |          |
|* 16 |        INDEX RANGE SCAN               | IDX$$_78250002         |      1 |   1528 |   1075 |00:00:00.01 |       5 |       |       |          |
|* 17 |      TABLE ACCESS BY INDEX ROWID      | OE_ORDER_LINES_ALL     |      1 |     51 |    138 |00:00:00.01 |     132K|       |       |          |
|* 18 |       INDEX SKIP SCAN                 | OE_ORDER_LINES_N26     |      1 | 14977 |    113K|00:00:00.57 |    1208 |       |       |          |
| 19 |     TABLE ACCESS BY INDEX ROWID       | HZ_CUST_ACCOUNTS       |   3312 |      1 |   1704 |00:00:00.09 |    5188 |       |       |          |
|* 20 |      INDEX UNIQUE SCAN                | HZ_CUST_ACCOUNTS_U1    |   3312 |      1 |   1704 |00:00:00.04 |    3484 |       |       |          |
| 21 |       NESTED LOOPS                    |                        |      8 |      1 |      2 |00:00:00.01 |      76 |       |       |          |
| 22 |        NESTED LOOPS                   |                        |      8 |      1 |      2 |00:00:00.01 |      72 |       |       |          |
| 23 |         NESTED LOOPS                  |                        |      8 |      1 |      2 |00:00:00.01 |      66 |       |       |          |
| 24 |          NESTED LOOPS                 |                        |      8 |      1 |      2 |00:00:00.01 |      62 |       |       |          |
| 25 |           NESTED LOOPS                |                        |      8 |      1 |      2 |00:00:00.01 |      56 |       |       |          |
|* 26 |            TABLE ACCESS BY INDEX ROWID| HZ_CUST_SITE_USES_ALL |      8 |      1 |      8 |00:00:00.01 |      32 |       |       |          |
|* 27 |             INDEX UNIQUE SCAN         | HZ_CUST_SITE_USES_U1   |      8 |      1 |      8 |00:00:00.01 |      24 |       |       |          |
|* 28 |            TABLE ACCESS BY INDEX ROWID| HZ_CUST_ACCT_SITES_ALL |      8 | 25087 |      2 |00:00:00.01 |      24 |       |       |          |
|* 29 |             INDEX UNIQUE SCAN         | HZ_CUST_ACCT_SITES_U1 |      8 |      1 |      8 |00:00:00.01 |      16 |       |       |          |
| 30 |           TABLE ACCESS BY INDEX ROWID | HZ_CUST_ACCOUNTS       |      2 |    176K|      2 |00:00:00.01 |       6 |       |       |          |
|* 31 |            INDEX UNIQUE SCAN          | HZ_CUST_ACCOUNTS_U1    |      2 |      1 |      2 |00:00:00.01 |       4 |       |       |          |
|* 32 |          INDEX UNIQUE SCAN            | HZ_PARTIES_U1          |      2 |    176K|      2 |00:00:00.01 |       4 |       |       |          |
|* 33 |         TABLE ACCESS BY INDEX ROWID   | HZ_PARTY_SITES         |      2 |    188K|      2 |00:00:00.01 |       6 |       |       |          |
|* 34 |          INDEX UNIQUE SCAN            | HZ_PARTY_SITES_U1      |      2 |      1 |      2 |00:00:00.01 |       4 |       |       |          |
|* 35 |        INDEX UNIQUE SCAN              | HZ_LOCATIONS_U1        |      2 |    174K|      2 |00:00:00.01 |       4 |       |       |          |
|* 36 |    TABLE ACCESS BY INDEX ROWID        | OE_ORDER_HEADERS_ALL   |   1704 |      1 |     71 |00:00:00.05 |    6816 |       |       |          |
|* 37 |     INDEX UNIQUE SCAN                 | OE_ORDER_HEADERS_U1    |   1704 |      1 |   1704 |00:00:00.03 |    5112 |       |       |          |
Predicate Information (identified by operation id):
   4 - access("IC"."INVENTORY_ITEM_ID"="OL"."INVENTORY_ITEM_ID")
10 - filter("B"."FLEX_VALUE"=NVL('02',"B"."FLEX_VALUE"))
11 - access("B"."FLEX_VALUE_SET_ID"=1012990)
12 - access("B"."FLEX_VALUE_ID"="T"."FLEX_VALUE_ID" AND "T"."LANGUAGE"=USERENV('LANG'))
13 - filter("B"."STRUCTURE_ID"=50289)
14 - access("B"."SEGMENT3"="B"."FLEX_VALUE")
       filter("B"."SEGMENT3" IS NOT NULL)
15 - access("B"."CATEGORY_ID"="T"."CATEGORY_ID" AND "T"."LANGUAGE"=USERENV('LANG'))
16 - access("B"."CATEGORY_ID"="IC"."CATEGORY_ID")
17 - filter(("OL"."ORDERED_ITEM"=NVL('101468',"OL"."ORDERED_ITEM") AND "OL"."UNIT_SELLING_PRICE"<>0))
18 - access("OL"."LINE_CATEGORY_CODE"='ORDER' AND "OL"."ACTUAL_SHIPMENT_DATE">=TO_DATE('2012-02-20 00:00:00', 'yyyy-mm-dd hh24:mi:ss') AND
              "OL"."ACTUAL_SHIPMENT_DATE"<=TO_DATE('2012-02-23 00:00:00', 'yyyy-mm-dd hh24:mi:ss'))
       filter(("OL"."ACTUAL_SHIPMENT_DATE">=TO_DATE('2012-02-20 00:00:00', 'yyyy-mm-dd hh24:mi:ss') AND "OL"."LINE_CATEGORY_CODE"='ORDER'
              AND "OL"."ACTUAL_SHIPMENT_DATE"<=TO_DATE('2012-02-23 00:00:00', 'yyyy-mm-dd hh24:mi:ss')))
20 - access("CUST"."CUST_ACCOUNT_ID"=)
26 - filter("SUSE"."SITE_USE_CODE"='SHIP_TO')
27 - access("SUSE"."SITE_USE_ID"=:B1)
28 - filter("ACCT_SITE"."ORG_ID"=142)
29 - access("SUSE"."CUST_ACCT_SITE_ID"="ACCT_SITE"."CUST_ACCT_SITE_ID")
31 - access("ACCT"."CUST_ACCOUNT_ID"="ACCT_SITE"."CUST_ACCOUNT_ID")
32 - access("P"."PARTY_ID"="ACCT"."PARTY_ID")
33 - filter(("ACCT"."PARTY_ID"="PARTY_SITE"."PARTY_ID" AND "P"."PARTY_ID"="PARTY_SITE"."PARTY_ID"))
34 - access("ACCT_SITE"."PARTY_SITE_ID"="PARTY_SITE"."PARTY_SITE_ID")
35 - access("LOC"."LOCATION_ID"="PARTY_SITE"."LOCATION_ID")
36 - filter(("OH"."ORG_ID"=142 AND "IC"."ORGANIZATION_ID"="OH"."SHIP_FROM_ORG_ID"))
37 - access("OH"."HEADER_ID"="OL"."HEADER_ID")
85 rows selected.Below plan for the above same query when i run from front end concurrent request it completed within an hour.
SQL> select * from table(dbms_xplan.display_cursor('1gnb26b0q2vxx',NULL,'ALLSTATS LAST'))
2 /
PLAN_TABLE_OUTPUT
SQL_ID 1gnb26b0q2vxx, child number 0
Plan hash value: 408306916
| Id | Operation                              | Name                           | Starts | E-Rows | A-Rows |   A-Time   | Buffers | OMem | 1Mem | Used-Mem |
|   1 | HASH GROUP BY                         |                                |      1 |      1 |      2 |00:36:41.83 |     379M|       |       |          |
|   2 |   CONCATENATION                        |                                |      1 |        |     71 |00:09:30.14 |     379M|       |       |          |
|* 3 |    FILTER                              |                                |      1 |        |      0 |00:00:00.01 |       0 |       |       |          |
|   4 |     NESTED LOOPS                       |                                |      0 |      1 |      0 |00:00:00.01 |       0 |       |       |          |
|   5 |      NESTED LOOPS                      |                                |      0 |      1 |      0 |00:00:00.01 |       0 |       |       |          |
|* 6 |       HASH JOIN                        |                                |      0 |      4 |      0 |00:00:00.01 |       0 |   715K|   715K|          |
|   7 |        TABLE ACCESS BY INDEX ROWID     | MTL_ITEM_CATEGORIES            |      0 |    506 |      0 |00:00:00.01 |       0 |       |       |          |
|   8 |         NESTED LOOPS                   |                                |      0 |     26 |      0 |00:00:00.01 |       0 |       |       |          |
|   9 |          NESTED LOOPS                  |                                |      0 |      1 |      0 |00:00:00.01 |       0 |       |       |          |
| 10 |           NESTED LOOPS                 |                                |      0 |      1 |      0 |00:00:00.01 |       0 |       |       |          |
| 11 |            NESTED LOOPS                |                                |      0 |      1 |      0 |00:00:00.01 |       0 |       |       |          |
|* 12 |             TABLE ACCESS BY INDEX ROWID| FND_FLEX_VALUES                |      0 |     22 |      0 |00:00:00.01 |       0 |       |       |          |
|* 13 |              INDEX RANGE SCAN          | IDX$$_65860003                 |      0 |     22 |      0 |00:00:00.01 |       0 |       |       |          |
|* 14 |             TABLE ACCESS BY INDEX ROWID| MTL_CATEGORIES_B               |      0 |      1 |      0 |00:00:00.01 |       0 |       |       |          |
|* 15 |              INDEX RANGE SCAN          | MTL_CATEGORIES_B_N3            |      0 |      2 |      0 |00:00:00.01 |       0 |       |       |          |
|* 16 |            INDEX UNIQUE SCAN           | FND_FLEX_VALUES_TL_U1          |      0 |      1 |      0 |00:00:00.01 |       0 |       |       |          |
|* 17 |           INDEX UNIQUE SCAN            | MTL_CATEGORIES_TL_U1           |      0 |      1 |      0 |00:00:00.01 |       0 |       |       |          |
|* 18 |          INDEX RANGE SCAN              | IDX$$_78250002                 |      0 |   1528 |      0 |00:00:00.01 |       0 |       |       |          |
|* 19 |        TABLE ACCESS FULL               | OE_ORDER_LINES_ALL             |      0 |     97 |      0 |00:00:00.01 |       0 |       |       |          |
|* 20 |       TABLE ACCESS BY INDEX ROWID      | OE_ORDER_HEADERS_ALL           |      0 |      1 |      0 |00:00:00.01 |       0 |       |       |          |
|* 21 |        INDEX UNIQUE SCAN               | OE_ORDER_HEADERS_U1            |      0 |      1 |      0 |00:00:00.01 |       0 |       |       |          |
| 22 |      TABLE ACCESS BY INDEX ROWID       | HZ_CUST_ACCOUNTS               |      0 |      1 |      0 |00:00:00.01 |       0 |       |       |          |
|* 23 |       INDEX UNIQUE SCAN                | HZ_CUST_ACCOUNTS_U1            |      0 |      1 |      0 |00:00:00.01 |       0 |       |       |          |
| 24 |        NESTED LOOPS                    |                                |      2 |      1 |      2 |00:00:00.01 |      34 |       |       |          |
| 25 |         NESTED LOOPS                   |                                |      2 |      1 |      2 |00:00:00.01 |      30 |       |       |          |
| 26 |          NESTED LOOPS                  |                                |      2 |      1 |      2 |00:00:00.01 |      24 |       |       |          |
| 27 |           NESTED LOOPS                 |                                |      2 |      1 |      2 |00:00:00.01 |      20 |       |       |          |
| 28 |            NESTED LOOPS                |                                |      2 |      1 |      2 |00:00:00.01 |      14 |       |       |          |
|* 29 |             TABLE ACCESS BY INDEX ROWID| HZ_CUST_SITE_USES_ALL          |      2 |      1 |      2 |00:00:00.01 |       8 |       |       |          |
|* 30 |              INDEX UNIQUE SCAN         | HZ_CUST_SITE_USES_U1           |      2 |      1 |      2 |00:00:00.01 |       6 |       |       |          |
|* 31 |             TABLE ACCESS BY INDEX ROWID| HZ_CUST_ACCT_SITES_ALL         |      2 |   9420 |      2 |00:00:00.01 |       6 |       |       |          |
|* 32 |              INDEX UNIQUE SCAN         | HZ_CUST_ACCT_SITES_U1          |      2 |      1 |      2 |00:00:00.01 |       4 |       |       |          |
| 33 |            TABLE ACCESS BY INDEX ROWID | HZ_CUST_ACCOUNTS               |      2 |    176K|      2 |00:00:00.01 |       6 |       |       |          |
|* 34 |             INDEX UNIQUE SCAN          | HZ_CUST_ACCOUNTS_U1            |      2 |      1 |      2 |00:00:00.01 |       4 |       |       |          |
|* 35 |           INDEX UNIQUE SCAN            | HZ_PARTIES_U1                  |      2 |    176K|      2 |00:00:00.01 |       4 |       |       |          |
|* 36 |          TABLE ACCESS BY INDEX ROWID   | HZ_PARTY_SITES                 |      2 |    188K|      2 |00:00:00.01 |       6 |       |       |          |
|* 37 |           INDEX UNIQUE SCAN            | HZ_PARTY_SITES_U1              |      2 |      1 |      2 |00:00:00.01 |       4 |       |       |          |
|* 38 |         INDEX UNIQUE SCAN              | HZ_LOCATIONS_U1                |      2 |    174K|      2 |00:00:00.01 |       4 |       |       |          |
|* 39 |    FILTER                              |                                |      1 |        |     71 |00:09:30.14 |     379M|       |       |          |
| 40 |     NESTED LOOPS                       |                                |      1 |      1 |     71 |00:09:30.14 |     379M|       |       |          |
| 41 |      NESTED LOOPS                      |                                |      1 |      1 |     71 |00:09:30.11 |     379M|       |       |          |
| 42 |       NESTED LOOPS                     |                                |      1 |     18 |     16M|00:03:49.48 |      34M|       |       |          |
| 43 |        NESTED LOOPS                    |                                |      1 |      1 |   1075 |00:00:00.03 |     351 |       |       |          |
| 44 |         NESTED LOOPS                   |                                |      1 |      1 |      1 |00:00:00.01 |       9 |       |       |          |
| 45 |          NESTED LOOPS                  |                                |      1 |      1 |      1 |00:00:00.01 |       8 |       |       |          |
| 46 |           NESTED LOOPS                 |                                |      1 |      1 |      1 |00:00:00.01 |       6 |       |       |          |
| 47 |            TABLE ACCESS BY INDEX ROWID | FND_FLEX_VALUES                |      1 |      1 |      1 |00:00:00.01 |       3 |       |       |          |
|* 48 |             INDEX RANGE SCAN           | FND_FLEX_VALUES_N4             |      1 |      1 |      1 |00:00:00.01 |       2 |       |       |          |
|* 49 |            TABLE ACCESS BY INDEX ROWID | MTL_CATEGORIES_B               |      1 |      1 |      1 |00:00:00.01 |       3 |       |       |          |
|* 50 |             INDEX RANGE SCAN           | IDX$$_79530001                 |      1 |      1 |      2 |00:00:00.01 |       1 |       |       |          |
|* 51 |           INDEX UNIQUE SCAN            | FND_FLEX_VALUES_TL_U1          |      1 |      1 |      1 |00:00:00.01 |       2 |       |       |          |
|* 52 |          INDEX UNIQUE SCAN             | MTL_CATEGORIES_TL_U1           |      1 |      1 |      1 |00:00:00.01 |       1 |       |       |          |
| 53 |         TABLE ACCESS BY INDEX ROWID    | MTL_ITEM_CATEGORIES            |      1 |    506 |   1075 |00:00:00.02 |     342 |       |       |          |
|* 54 |          INDEX RANGE SCAN              | IDX$$_78250002                 |      1 |   1528 |   1075 |00:00:00.01 |       5 |       |       |          |
|* 55 |        TABLE ACCESS BY INDEX ROWID     | OE_ORDER_HEADERS_ALL           |   1075 |   6485 |     16M|00:12:38.97 |      34M|       |       |          |
|* 56 |         INDEX RANGE SCAN               | OE_ORDER_HEADER_ALL_ORG_ID_NDX |   1075 |    141K|    394M|00:19:52.50 |    2141K|       |       |          |
|* 57 |       TABLE ACCESS BY INDEX ROWID      | OE_ORDER_LINES_ALL             |     16M|      1 |     71 |00:23:47.72 |     345M|       |       |          |
|* 58 |        INDEX RANGE SCAN                | OE_ORDER_LINES_N21             |     16M|      6 |    108M|00:08:35.98 |      32M|       |       |          |
| 59 |      TABLE ACCESS BY INDEX ROWID       | HZ_CUST_ACCOUNTS               |     71 |      1 |     71 |00:00:00.01 |     247 |       |       |          |
|* 60 |       INDEX UNIQUE SCAN                | HZ_CUST_ACCOUNTS_U1            |     71 |      1 |     71 |00:00:00.01 |     176 |       |       |          |
| 61 |        NESTED LOOPS                    |                                |      2 |      1 |      2 |00:00:00.01 |      34 |       |       |          |
| 62 |         NESTED LOOPS                   |                                |      2 |      1 |      2 |00:00:00.01 |      30 |       |       |          |
| 63 |          NESTED LOOPS                  |                                |      2 |      1 |      2 |00:00:00.01 |      24 |       |       |          |
| 64 |           NESTED LOOPS                 |                                |      2 |      1 |      2 |00:00:00.01 |      20 |       |       |          |
| 65 |            NESTED LOOPS                |                                |      2 |      1 |      2 |00:00:00.01 |      14 |       |       |          |
|* 66 |             TABLE ACCESS BY INDEX ROWID| HZ_CUST_SITE_USES_ALL          |      2 |      1 |      2 |00:00:00.01 |       8 |       |       |          |
|* 67 |              INDEX UNIQUE SCAN         | HZ_CUST_SITE_USES_U1           |      2 |      1 |      2 |00:00:00.01 |       6 |       |       |          |
|* 68 |             TABLE ACCESS BY INDEX ROWID| HZ_CUST_ACCT_SITES_ALL         |      2 |   9420 |      2 |00:00:00.01 |       6 |       |       |          |
|* 69 |              INDEX UNIQUE SCAN         | HZ_CUST_ACCT_SITES_U1          |      2 |      1 |      2 |00:00:00.01 |       4 |       |       |          |
| 70 |            TABLE ACCESS BY INDEX ROWID | HZ_CUST_ACCOUNTS               |      2 |    176K|      2 |00:00:00.01 |       6 |       |       |          |
|* 71 |             INDEX UNIQUE SCAN          | HZ_CUST_ACCOUNTS_U1            |      2 |      1 |      2 |00:00:00.01 |       4 |       |       |          |
|* 72 |           INDEX UNIQUE SCAN            | HZ_PARTIES_U1                  |      2 |    176K|      2 |00:00:00.01 |       4 |       |       |          |
|* 73 |          TABLE ACCESS BY INDEX ROWID   | HZ_PARTY_SITES                 |      2 |    188K|      2 |00:00:00.01 |       6 |       |       |          |
|* 74 |           INDEX UNIQUE SCAN            | HZ_PARTY_SITES_U1              |      2 |      1 |      2 |00:00:00.01 |       4 |       |       |          |
|* 75 |         INDEX UNIQUE SCAN              | HZ_LOCATIONS_U1                |      2 |    174K|      2 |00:00:00.01 |       4 |       |       |          |
Predicate Information (identified by operation id):
   3 - filter((:P_FROM_DATE<=:P_TO_DATE AND :P_BUSINESS_UNIT IS NULL))
   6 - access("IC"."INVENTORY_ITEM_ID"="OL"."INVENTORY_ITEM_ID")
12 - filter("B"."FLEX_VALUE" IS NOT NULL)
13 - access("B"."FLEX_VALUE_SET_ID"=1012990)
14 - filter("B"."STRUCTURE_ID"=50289)
15 - access("B"."SEGMENT3"="B"."FLEX_VALUE")
       filter("B"."SEGMENT3" IS NOT NULL)
16 - access("B"."FLEX_VALUE_ID"="T"."FLEX_VALUE_ID" AND "T"."LANGUAGE"=USERENV('LANG'))
17 - access("B"."CATEGORY_ID"="T"."CATEGORY_ID" AND "T"."LANGUAGE"=USERENV('LANG'))
18 - access("B"."CATEGORY_ID"="IC"."CATEGORY_ID")
19 - filter(("OL"."ACTUAL_SHIPMENT_DATE">=:P_FROM_DATE AND "OL"."ACTUAL_SHIPMENT_DATE"<=:P_TO_DATE AND
              "OL"."ORDERED_ITEM"=NVL(:ITEM_HIGH,"OL"."ORDERED_ITEM") AND "OL"."LINE_CATEGORY_CODE"='ORDER' AND "OL"."UNIT_SELLING_PRICE"<>0))
20 - filter(("OH"."ORG_ID"=:P_ORG_ID AND "IC"."ORGANIZATION_ID"="OH"."SHIP_FROM_ORG_ID"))
21 - access("OH"."HEADER_ID"="OL"."HEADER_ID")
23 - access("CUST"."CUST_ACCOUNT_ID"=)
29 - filter("SUSE"."SITE_USE_CODE"='SHIP_TO')
30 - access("SUSE"."SITE_USE_ID"=:B1)
31 - filter("ACCT_SITE"."ORG_ID"=:P_ORG_ID)
32 - access("SUSE"."CUST_ACCT_SITE_ID"="ACCT_SITE"."CUST_ACCT_SITE_ID")
34 - access("ACCT"."CUST_ACCOUNT_ID"="ACCT_SITE"."CUST_ACCOUNT_ID")
35 - access("P"."PARTY_ID"="ACCT"."PARTY_ID")
36 - filter(("ACCT"."PARTY_ID"="PARTY_SITE"."PARTY_ID" AND "P"."PARTY_ID"="PARTY_SITE"."PARTY_ID"))
37 - access("ACCT_SITE"."PARTY_SITE_ID"="PARTY_SITE"."PARTY_SITE_ID")
38 - access("LOC"."LOCATION_ID"="PARTY_SITE"."LOCATION_ID")
39 - filter((:P_FROM_DATE<=:P_TO_DATE AND :P_BUSINESS_UNIT IS NOT NULL))
48 - access("B"."FLEX_VALUE"=:P_BUSINESS_UNIT AND "B"."FLEX_VALUE_SET_ID"=1012990)
49 - filter("B"."STRUCTURE_ID"=50289)
50 - access("B"."SEGMENT3"="B"."FLEX_VALUE")
       filter("B"."SEGMENT3" IS NOT NULL)
51 - access("B"."FLEX_VALUE_ID"="T"."FLEX_VALUE_ID" AND "T"."LANGUAGE"=USERENV('LANG'))
52 - access("B"."CATEGORY_ID"="T"."CATEGORY_ID" AND "T"."LANGUAGE"=USERENV('LANG'))
54 - access("B"."CATEGORY_ID"="IC"."CATEGORY_ID")
55 - filter("IC"."ORGANIZATION_ID"="OH"."SHIP_FROM_ORG_ID")
56 - access("OH"."ORG_ID"=:P_ORG_ID)
57 - filter(("OL"."ACTUAL_SHIPMENT_DATE">=:P_FROM_DATE AND "OL"."ACTUAL_SHIPMENT_DATE"<=:P_TO_DATE AND
              "OL"."ORDERED_ITEM"=NVL(:ITEM_HIGH,"OL"."ORDERED_ITEM") AND "OL"."LINE_CATEGORY_CODE"='ORDER' AND "OL"."UNIT_SELLING_PRICE"<>0 AND
              "IC"."INVENTORY_ITEM_ID"="OL"."INVENTORY_ITEM_ID"))
58 - access("OH"."HEADER_ID"="OL"."HEADER_ID")
60 - access("CUST"."CUST_ACCOUNT_ID"=)
66 - filter("SUSE"."SITE_USE_CODE"='SHIP_TO')
67 - access("SUSE"."SITE_USE_ID"=:B1)
68 - filter("ACCT_SITE"."ORG_ID"=:P_ORG_ID)
69 - access("SUSE"."CUST_ACCT_SITE_ID"="ACCT_SITE"."CUST_ACCT_SITE_ID")
71 - access("ACCT"."CUST_ACCOUNT_ID"="ACCT_SITE"."CUST_ACCOUNT_ID")
72 - access("P"."PARTY_ID"="ACCT"."PARTY_ID")
73 - filter(("ACCT"."PARTY_ID"="PARTY_SITE"."PARTY_ID" AND "P"."PARTY_ID"="PARTY_SITE"."PARTY_ID"))
74 - access("ACCT_SITE"."PARTY_SITE_ID"="PARTY_SITE"."PARTY_SITE_ID")
75 - access("LOC"."LOCATION_ID"="PARTY_SITE"."LOCATION_ID")
145 rows selected.one thing looking strange at predicate section at line 23 and 60 access("CUST"."CUST_ACCOUNT_ID"=),Plan is also differing why?

Just look at filter predicates 3 and 39 which I highlighted previously.
With a query using bind variable, p_business_unit might be supplied with a null value and therefore two possible paths exist in the CONCATENTATION plan to cope with those possibilities (and the possibility that P_FROM_DATE is not <= P_TO_DATE).
If instead of using bind variable you supply a literal - i.e. '101468' - then the optimizer doesn't not have to worry about the fact that '101468' might be null. As far as this piece of SQL is concerned, it's a constant.
Therefore you shouldn't compare SQL that runs with binds with SQl that runs with literals, particularly where the sql involves conditional predicates.
To use a simplification, consider the difference here:
SQL> explain plan for
2 select 1 from dual where 1 = nvl(1,1);
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 1388734953
| Id | Operation        | Name | Rows | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |      |     1 |     2   (0)| 00:00:01 |
|   1 | FAST DUAL       |      |     1 |     2   (0)| 00:00:01 |
8 rows selected.
SQL> explain plan for
2   select 1 from dual where 1 = nvl(:1,1);
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 4034615273
| Id | Operation        | Name | Rows | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |      |     1 |     2   (0)| 00:00:01 |
|* 1 | FILTER          |      |       |            |          |
|   2 |   FAST DUAL      |      |     1 |     2   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - filter(NVL(:1,1)=1)
14 rows selected.Furthermore, to emphasis my point about substition variables (&variable_name) consider this:
SQL> explain plan for
2 select 1 from dual where 1 = nvl(&1,1);
Enter value for 1: 1
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 1388734953
| Id | Operation        | Name | Rows | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |      |     1 |     2   (0)| 00:00:01 |
|   1 | FAST DUAL       |      |     1 |     2   (0)| 00:00:01 |
8 rows selected.
SQL> Does the substitution variable behave like a bind variable or like a literal?
A literal, because that's what it is. Substituted in before the statement is sent to the database and parsed.

Explain Plan different in SQLPlus then production

We have a query that is consuming 95%+ of the CPU in production, but the same query in sqlplus takes seconds. The explain plan through OEM is different than the explain plan in sqlplus, but the query is the same? Any thoughts?
Thanks.

Your explanation raises many question.
We have a query that is consuming 95%+ of the CPU in production, How do you measure this?
but the same query in sqlplus takes seconds.What do you mean, by running in production or running in sqlplus?
How do you run on production? I mean, do you run through any application or what?
Are they running under the same user?
It is possible to post both execution plans and a more explanation on what you are saying.

Migration of Planned Orders from one SAP system to another one

Hi,
A quick help needed.
We are migrating SAP data from one SAP system to other due to business split. Regarding PP data, can Planned orders be migrated as it is from one SAP System to another? What is the impact if we do so?
Appreciate your response.
Kind Regards,
tanuji

hi ,
As suggested , you can propose to migrate only Firmed Planned orders from SAP to SAP system .
How to acheive it ?
You can use below BAPI to extract details of planned order from Table PLAF and upload in TARGET SYSTEM
BAPI_PLANNEDORDER_CREATE
Please note newly created Planned order in Target system would not have BOM EXPLOSION and Scheduling .
If need , Make a BDC recording as a add on step to explode Bom and Schedule by clicking those icons in Planned order .
Technical Team can do this .

Session state of page item different from one region to another region

hi,
on one particular page I have two regions. A page item (LOV pop-up) is set in the first region. I leave this region with a button and jump back with a branch to the same page. The page item has now the selected value (as is shown by session state window). So far so good.
The second region (SQL query type) uses this page item. However, for some reason the page item is NULL in that second region.
Can anyone explain this behavior ?
ron

thanks Joel,
I did already what you suggested. The title in region 2 is evaluated to the same value as in region 1.
The SQL query (that actually runned with identical syntax before) is:
select bla from blatable where bla = :P920_RU
this generates:
report error:
ORA-12801: error signaled in parallel query server P000
ORA-01741: illegal zero-length identifier
So apperently the bind variable is evaluted to (or cached as) NULL.
I noticed something strange in the session window. There are several page items in the application. All of them are listed in the 'Session State' region. The page item that makes problems is the only one that is also listed in the 'Page Items' region. It is even listed when I start the session window from another page. Weird.
any other ideas ?
Actually, how could you possibly clear session state between rendering two regions ?
Ron

Role content different from one AS to another after a role transport

Dear all,
I have a trouble after a simple role transport in the production system. The PROD system is built with one CI and 5 AS. (System ECC 5.0 kernel 6.40)
After a transport role, the changes are not replicated on all aplication servers in PFCG. For ex. once connected on the Application Server 1, the TC CK11 is well added to the role Z_Role; but when I'm connected on the AS 2, the content of the role Z_Role is different (the TC CK11 is absent).
Is someone have an idea?
Thanks,
Fabrice

Sounds like a bug, or there are some buffers which are corrupted.
Is this a very large role, or do the users have other very large roles?
I will move this to the NW Admin forum first, to see what they think of it - as I suspect that it is a server administration difference between the appservers.
Cheers,
Julius

Variable screen of webi rich client differs from one of Infoview

Hello
We are on BO XI 3.1 sp3, universe of the top of SAP BI 7.01 query.Webi version 12.3.0
Char1 is set to delegated search. Variable1 for char1 is mandatory, multiple single values on SAP BI side.
Webi reports (executed from webi rich client) allows search by value for this char1. Webi report (executed from infoview) doesnt allow any search for char1.
Button FIND (match case) looks inactive. It doesnt start search.
I tried different combinations (see below) but it doesnt help.
*XXX
XXX
XXX
Does anybody know that cases the difference?
Thanks

Herr Kommandante
Does it make a difference if you switch between HTML and JAVA viewers in Infoview?
Does it make a difference if you switch between View and Modify modes in Infoview?
Are you patched to the same level on both Client and Sercer?
Regards,
Henry

Oracle spatial relationships works differently from one version to another

Hi, recently we migrate versión of Oracle, from 11.1.0.6 to 11.2.0.4, and we have some troubles with relationships in Oracle, in previous version the next script return COVERS but in actual version return TOUCH, we have many functions in Oracle using the function SDO_RELATE so its very dificult to change plsql code, my question is why is diferent the logic of relationships with this new version? or we have to do something to configure this?
I appreciate all the help...
(the script uses information that is not in the database)
DECLARE
PTX1 NUMBER;
PTY1 NUMBER;
PTX2 NUMBER;
PTY2 NUMBER;
RESULTADO VARCHAR2(100);
SDO_GEOM_LINEA SDO_GEOMETRY;
SDO_GEOM_PREDIO SDO_GEOMETRY;
BEGIN
   PTX1 := 560144.777960335;
    PTY1 := 1857775.09679448;
    PTX2 := 560141.702578807;
    PTY2 := 1857762.185737;
    SDO_GEOM_PREDIO:= SDO_UTIL.FROM_WKTGEOMETRY('POLYGON((560121.962326818 1857765.46802773, 560123.085106786 1857777.05962037, 560144.777960335 1857775.09679448, 560141.702578807 1857762.185737, 560121.962326818 1857765.46802773))');
    SDO_GEOM_PREDIO.SDO_SRID:=90180;
    SDO_GEOM_LINEA := SDO_GEOMETRY(2002,90180,NULL,SDO_ELEM_INFO_ARRAY(1,2,1),SDO_ORDINATE_ARRAY(PTX1,PTY1,PTX2,PTY2));
    SELECT SDO_GEOM.RELATE(SDO_GEOM_PREDIO,'DETERMINE',SDO_GEOM_LINEA,0.005) INTO RESULTADO
    FROM DUAL;
    DBMS_OUTPUT.PUT_LINE('ELEMENTOS: '||RESULTADO);
END;

This is not true, because the script should return COVERS, the example in script is a polygon and the line that is compared with SDO_GEOM.RELATE is one side of the polygon, following the concepts:
COVERS: The interior of one object is completely contained in the interior or the boundary of the other object and their boundaries intersect.
TOUCH: The boundaries intersect but the interiors do not intersect.
The line is completely contained in the boundary of the polygon, that is why the result must be COVERS not TOUCH

Real explain plan differs from one in v$sqlarea

Similar Messages

Maybe you are looking for