Unique scanning

I have a table with the following columns year_week, year_week_prev, I have unique on each single column as well and the time constraints. And a constraint not null on year_week. But year_week_prev can be null in some cases.

The following query is a scan interval, when I put column instead of year_week_prev then scan optimizer year_week making one single.

select b.year_week_prev 
from  tst_tim b
where  b.year_week=201236 
and b.year_week_prev  is not null

I used not null in my where clause in order to make a unique analysis but no use. Clues, why single scan is not the case and how do I achieve this.

Thank you
HESH

Hi Hesh

I think that it is good and as expected. You select year_week_prev where year_week = 201236;

Scan interval is most appropriate here

If you selected YEAR_WEEK in the SELECT clause, it would have been small unique index scan.

Alternatively, if you had included a filter on YEAR_WEEK_PREV as well as YEAR_WEEK = 201236 as well, it would have been unique scan again.

What follows will make an analysis of the unique

select b.year_week_prev
from  tst_tim b
where  b.year_week=201236 and b.year_week_prev = :prev ;

This one will make a unique sweep

select b.year_week
from  tst_tim b
where  b.year_week=201236

But when you select year_week_prev from table where YEAR_WEEK = something, then he must make an analysis of range Index on the composite index.

Now, have you tested it after abandoning the composite constraint (that you have created to ensure uniqueness of the two columns)? In this case, you will see small unique index scan to filter the YEAR_WEEK and then will be to pick up the YEAR_WEEK_PREV via the index rowid.

Concerning
Vincent

Tags: Database

Similar Questions

How Envy 114 printer, scan or copy several pages?

I have a difficult document that I would like to scan into my computer, but there several pages and I would prefer that one document not several unique scans. Is it possible to create a multi-page scanned document?

Sorry, you will not be able to scan or copy several pages with the printer.

You will need an autoloader (ADF) documents, and this printer is not this feeder at the top of this one.

Unique and non-unique indexes

Hello
I have a unique index associated with no doubt. Unique and not unique indexes are used B tree architecture. But I want to know if I create a non-unique index on a column that contains unique data.
When I query this table using this column, it scans each sheet or times found that value it scan stops and give us the result?

00125 wrote:

In a non-unique index, scans all the leaves... so what's the difference between full table scan and index ull. I went through a few articles they mentioned that a non-unique index to check with rowid. How she treated? I have clear knowledge in it.

Please help me with this.

Thanks in advance

If you go through architecture index B-tree you could easily understand how indexing works. The picture here shows how a look of column datatype NUMBER indexed as / stored internally. You can imagine that your indexed column TST_COLA this will look like in the internal process. In the B-tree indexes, you have 3 main structures 1. 2 root. Branch 3. Leaves and the database retrieves lines by browsing through the root of index-> branch-> leaves. If the photo if we wanted to retrieve the row whose value indexed column = 25. First data goes to the root and finds that plugs is set to 25, then he Stoops to this particular branch of find what block sheet retains the value 25. More far away after finding the leaves block then goes to this block of sheets and research the special value of 25.

If the index is UNIQUE, the database knows that there must be only one value, where it performs INDEX UNIQUE SCAN. If the index is NOT UNIQUE it should check all values in this block of leaves to find who all are 25 - in this case INDEX RANGE SCAN is done - as you must check not only value, but all values in this block of sheets - given that the values are not unique. As you can see it that the sheet block contains the long side of the value of the column ROWID, using this database rowid, then goes to the table to retrieve that particular line.

Full table scan is a method of access where the database just to access the table directly (bypassing index structure) and analyze the ENTIRE table to satisfy the request.

scan of the index systematic range

Hello
I read about the differences between the systematic index scan range, single scan, skip scan.
According to the docs, to how the CBO Evaluates in-list of iterators, http://docs.oracle.com/cd/B10500_01/server.920/a96533/opt_ops.htm
, I can see that

"The IN -list iterator is used when a query contains a IN clause with values." The execution plan is the same which would result for a statement of equality clause instead of IN with the exception of an extra step. This step occurs when the IN -list iterator feeds section of equality with the unique values of the IN -list. »

Of course, the doc is Oracle9i Database. (I do not find it in the docs of 11 g)
And the example 2-1 list iterators initial statement, shows that is used in the INDEX RANGE SCAN.

On my Oracle 11 GR 2 database, if I issue a statement similar to the example of the doc, so: select * from employees where employee_id in (7076, 7009, 7902), I see that it uses a SINGLE SCAN

On Oracle Performance Tuning: the Index access methods: Oracle Tuning Tip #11: Unique Index Scan , I read that

If Oracle should follow the Index Unique Scan, and then in SQL, equality operator (=) must be used. If any operator is used in other than op_Equality, then Oracle cannot impose this Unique Index Scan.

(and I think this sentence is somewhere in the docs also).
Thus, when using predicates in the list, why in my case Oracle used the unique scan on primary key column index? Because it wasn't a level playing field.
Thank you.

It is Internet... find us a lot of information a lot but don't know who to trust.

Exactly! It is thought, you should ALWAYS have in the back of your mind when you visit ANY site (no matter the author), read a book or document, listen to no matter WHAT presentation or read responses from forum (that's me included).

All sources of information can and will be errors, omissions and inaccuracies. An example which is used to illustrate a point can involve/suggest that it applies to the related points as well. It's just not possible to cover everything.

Your post doc 9i is a good example. The earliest records (even 7.3 always available online docs) often have a LOT of better explanations and examples of basic concepts. One of the reasons is that there were not nearly that many advanced concepts that explaining necessary; they did not exist.

michaelrozar17 just posted a link to a 12 c doc to refute my statement that the article you used was bad. No problem. Maybe this doc has been published because of these lines:

The database performs a unique sweep when the following conditions apply:
- A query predicate refers to all columns in a unique index using an equality operator key, such as WHERE prod_id=10 .
- A SQL statement contains a predicate of equality on a column referenced in an index created with the CREATE UNIQUE INDEX statement.
The authors mean that a single scan is ONLY performed for these conditions? We do not know. There could be several reasons that an INLIST ITERATOR has not been included in this list:

1. a LIST is NOT for this use case (what michaelrozar might suggest)

2. the authors were not aware that the CBO may also consider a unique analysis for a predicate INLIST

3. the authors WERE aware but forgot to include INLIST in the document

4. the authors were simply provide the conditions most common where a single sweep would be considered

We have no way of knowing what was the real reason. This does not mean that the document is not reliable.

In the other topic, I posted on the analysis of hard steps, site of BURLESON, and Jonathan contradicted me. If neither Burleson isn't reliable, do not know which author have sufficient credibility... of course, the two Burleson and Jonathan can say anything, it's true I can say anything, of course.

If site X is false, site is fake, Z site is fake... all people should read the documentation only and not other sites?

This is the BEST statement of reality to find the info I've seen displayed.

No matter who is the author, and what credibility that they could rely on the spent items you should ALWAYS keep these statements you comes to mind.

This means you need to do ' trust and verify. " You of 'trust', and then you "checked" and now have a conflict between WORDS and REALITY.

On those which is correct. If your reality is correct, the documentation is wrong. Ok. If your reality is wrong, then you know why.

Except that nobody has posted ANY REALITY that shows that your reality is wrong. IMHO, the reason for this is because the CBO probably MUCH, done a LOT of things that are not documented and that are never explored because there is never no reason to spend time exploring other than of curiosity.

You have not presented ANY reason to think that you are really concerned that a single scan is used.

Back to your original question:

Thus, when using predicates in the list, why in my case Oracle used the unique scan on primary key column index? Because it wasn't a level playing field.

1. why not use a single sweep?

2. what you want Oracle to use instead? A full table scan? A scan of the index systematic range? An index skip scan? A Full Scan index? An analysis of index full?

A full table scan? For three key values? When there is a unique index? I hope not.

A scan of the index systematic range? Look a the doc 12 c provided for those other types of indexes

How the Index range scans work
In general, the process is as follows:
1. Read the root block.
2. Read the bundle branch block.
3. Replacing the following steps until all data is retrieved:
  1. Read a block of sheets to get a rowid.
  2. Read a block to retrieve a table row.
. . .
For example, to analyze the index, the database moves backward or forward through the pads of sheets. For example, an analysis of identifications between 20 and 40 locates the first sheet block that has the lowest value of key that is 20 or more. The analysis produced horizontally through the linked list nodes until it finds a value greater than 40 and then stops.
If that '20' was the FIRST index value and the '40' was the LAST one who reads ALL of the terminal nodes. That doesn't look good for me.

How to index full scans of work

The database reads the root block and then sailed on the side of the index (right or left hand if do a descending full scan) until it reaches a block of sheets. The database then reads down the index, one block at a time, in a sorted order. The analysis uses single e/s rather than I/O diluvium.

Which is about as the last example is not?

How to index Fast Full Scans work

The database uses diluvium I/O to read the root block and all the blocks of leaf and branch. Databases don't know branch blocks and the root and reads the index on blocks of leaves entries.

Seems not much better than the last one for your use case.

Skip index scans

An index skip scan occurs when the first column of a composite index is "skipped" or not specified in the query.

. . .

How Index Skip scan work

An index skip scan logically divides a composite index in smaller subindex. The number of distinct values in the main columns of the index determines the number of logical subindex. The more the number, the less logical subindex, the optimizer should create, and becomes the most effective analysis. The scan reads each logical index separately and "jumps" index blocks that do not meet the condition of filter on the column no leader.

Which does not apply to your use cases; you do not have a composite index, and there is nothing to jump. If Oracle were to 'jump' between the values of the list in it would be still reads these blocks 'inbetween' and them to jump.

Which brings back us to the using a single scan, one at a time, for each of the values in the list in. The root index block will be in the cache after the first value lies, so it only needs to be read once. After that just Oracle detects that the entry of only ONE necessary index. Sounds better than any other variants for me if you are only dealing with a small number of values in the IN clause.

Why the optimizer ignores Index Fast full Scan when much lower cost?

Summary (tracking details below) - to improve the performance of a query on more than one table, I created an index on a table that included all the columns referenced in the query. With the new index in place the optimizer is still choosing a full Table Scan on an Index fast full scan. However, by removing the one query tables I reach the point where the optimizer suddenly use the Index Fast Full Scan on this table. And 'Yes', it's a lot cheaper than the full Table Scan it used before. By getting a test case, I was able to get the motion down to 4 tables with the optimizer still ignoring the index and table of 3, it will use the index.

So why the optimizer not chooses the Index Fast Full Scan, if it is obvious that it is so much cheaper than a full Table Scan? And why the deletion of a table changes how the optimizer - I don't think that there is a problem with the number of join permutations (see below). The application is so simple that I can do, while remaining true to the original SQL application, and it still shows this reversal in the choice of access path. I can run the queries one after another, and he always uses a full Table Scan for the original query and Index fast full scan for the query that is modified with a table less.

Watching trace 10053 output for the two motions, I can see that for the original query 4 table costs alone way of ACCESS of TABLE UNIQUE section a full Table Scan. But for the modified query with a table less, the table now has a cost for an Index fast full scan also. And the end of the join cost 10053 does not end with a message about exceeding the maximum number of permutations. So why the optimizer does not cost the IFFS for the first query, when it does for the second, nearly identical query?

This is potentially a problem to do with OUTER joins, but why? The joins between the tables do not change when the single extra table is deleted.

It's on 10.2.0.5 on Linux (Oracle Enterprise Linux). I did not define special settings I know. I see the same behavior on 10.2.0.4 32-bit on Windows (XP).

Thank you
John
Blog of database Performance

DETAILS
I've reproduced the entire scenario via SQL scripts to create and populate the tables against which I can then run the queries. I've deliberately padded table so that the length of the average line of data generated is similar to that of the actual data. In this way the statistics should be similar on the number of blocks and so forth.

System - uname - a

Linux mysystem.localdomain 2.6.32-300.25.1.el5uek #1 SMP Tue May 15 19:55:52 EDT 2012 i686 i686 i386 GNU/Linux

Database - v$ version

Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - Prod
PL/SQL Release 10.2.0.5.0 - Production
CORE    10.2.0.5.0      Production
TNS for Linux: Version 10.2.0.5.0 - Production
NLSRTL Version 10.2.0.5.0 - Production

Original query (complete table below details):

SELECT 
    episode.episode_id , episode.cross_ref_id , episode.date_required , 
    product.number_required , 
    request.site_id 
FROM episode 
LEFT JOIN REQUEST on episode.cross_ref_id = request.cross_ref_id 
     JOIN product ON episode.episode_id = product.episode_id 
LEFT JOIN product_sub_type ON product.prod_sub_type_id = product_sub_type.prod_sub_type_id 
WHERE (
        episode.department_id = 2
    and product.status = 'I'
      ) 
ORDER BY episode.date_required
;

Execution of display_cursor after the execution plan:

SQL_ID  5ckbvabcmqzw7, child number 0
-------------------------------------
SELECT     episode.episode_id , episode.cross_ref_id , episode.date_required ,
product.number_required ,     request.site_id FROM episode LEFT JOIN REQUEST on
episode.cross_ref_id = request.cross_ref_id      JOIN product ON episode.episode_id =
product.episode_id LEFT JOIN product_sub_type ON product.prod_sub_type_id =
product_sub_type.prod_sub_type_id WHERE (         episode.department_id = 2 and
product.status = 'I'       ) ORDER BY episode.date_required

Plan hash value: 3976293091

-----------------------------------------------------------------------------------------------------
| Id  | Operation             | Name                | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT      |                     |       |       |       | 35357 (100)|          |
|   1 |  SORT ORDER BY        |                     | 33333 |  1920K|  2232K| 35357   (1)| 00:07:05 |
|   2 |   NESTED LOOPS OUTER  |                     | 33333 |  1920K|       | 34879   (1)| 00:06:59 |
|*  3 |    HASH JOIN OUTER    |                     | 33333 |  1822K|  1728K| 34878   (1)| 00:06:59 |
|*  4 |     HASH JOIN         |                     | 33333 |  1334K|       |   894   (1)| 00:00:11 |
|*  5 |      TABLE ACCESS FULL| PRODUCT             | 33333 |   423K|       |   103   (1)| 00:00:02 |
|*  6 |      TABLE ACCESS FULL| EPISODE             |   299K|  8198K|       |   788   (1)| 00:00:10 |
|   7 |     TABLE ACCESS FULL | REQUEST             |  3989K|    57M|       | 28772   (1)| 00:05:46 |
|*  8 |    INDEX UNIQUE SCAN  | PK_PRODUCT_SUB_TYPE |     1 |     3 |       |  0   (0)|          |
-----------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------
   3 - access("EPISODE"."CROSS_REF_ID"="REQUEST"."CROSS_REF_ID")
   4 - access("EPISODE"."EPISODE_ID"="PRODUCT"."EPISODE_ID")
   5 - filter("PRODUCT"."STATUS"='I')
   6 - filter("EPISODE"."DEPARTMENT_ID"=2)
   8 - access("PRODUCT"."PROD_SUB_TYPE_ID"="PRODUCT_SUB_TYPE"."PROD_SUB_TYPE_ID")

Updated the Query:

SELECT 
    episode.episode_id , episode.cross_ref_id , episode.date_required , 
    product.number_required , 
    request.site_id 
FROM episode 
LEFT JOIN REQUEST on episode.cross_ref_id = request.cross_ref_id 
     JOIN product ON episode.episode_id = product.episode_id 
WHERE (
        episode.department_id = 2
    and product.status = 'I'
      ) 
ORDER BY episode.date_required
;

Execution of display_cursor after the execution plan:

SQL_ID  gbs74rgupupxz, child number 0
-------------------------------------
SELECT     episode.episode_id , episode.cross_ref_id , episode.date_required ,
product.number_required ,     request.site_id FROM episode LEFT JOIN REQUEST on
episode.cross_ref_id = request.cross_ref_id      JOIN product ON episode.episode_id =
product.episode_id WHERE (         episode.department_id = 2     and product.status =
'I'       ) ORDER BY episode.date_required

Plan hash value: 4250628916

----------------------------------------------------------------------------------------------
| Id  | Operation              | Name        | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT       |             |       |       |       | 10515 (100)|          |
|   1 |  SORT ORDER BY         |             | 33333 |  1725K|  2112K| 10515   (1)| 00:02:07 |
|*  2 |   HASH JOIN OUTER      |             | 33333 |  1725K|  1632K| 10077   (1)| 00:02:01 |
|*  3 |    HASH JOIN           |             | 33333 |  1236K|       |   894   (1)| 00:00:11 |
|*  4 |     TABLE ACCESS FULL  | PRODUCT     | 33333 |   325K|       |   103   (1)| 00:00:02 |
|*  5 |     TABLE ACCESS FULL  | EPISODE     |   299K|  8198K|       |   788   (1)| 00:00:10 |
|   6 |    INDEX FAST FULL SCAN| IX4_REQUEST |  3989K|    57M|       |  3976   (1)| 00:00:48 |
----------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------
   2 - access("EPISODE"."CROSS_REF_ID"="REQUEST"."CROSS_REF_ID")
   3 - access("EPISODE"."EPISODE_ID"="PRODUCT"."EPISODE_ID")
   4 - filter("PRODUCT"."STATUS"='I')
   5 - filter("EPISODE"."DEPARTMENT_ID"=2)

Creating the table and Population:
1 create tables
2. load data
3 create indexes
4. collection of statistics

--
-- Main table
--
create table episode (
episode_id number (*,0),
department_id number (*,0),
date_required date,
cross_ref_id varchar2 (11),
padding varchar2 (80),
constraint pk_episode primary key (episode_id)
) ;
--
-- Product tables
--
create table product_type (
prod_type_id number (*,0),
code varchar2 (10),
binary_field number (*,0),
padding varchar2 (80),
constraint pk_product_type primary key (prod_type_id)
) ;
--
create table product_sub_type (
prod_sub_type_id number (*,0),
sub_type_name varchar2 (20),
units varchar2 (20),
padding varchar2 (80),
constraint pk_product_sub_type primary key (prod_sub_type_id)
) ;
--
create table product (
product_id number (*,0),
prod_type_id number (*,0),
prod_sub_type_id number (*,0),
episode_id number (*,0),
status varchar2 (1),
number_required number (*,0),
padding varchar2 (80),
constraint pk_product primary key (product_id),
constraint nn_product_episode check (episode_id is not null) 
) ;
alter table product add constraint fk_product 
foreign key (episode_id) references episode (episode_id) ;
alter table product add constraint fk_product_type 
foreign key (prod_type_id) references product_type (prod_type_id) ;
alter table product add constraint fk_prod_sub_type
foreign key (prod_sub_type_id) references product_sub_type (prod_sub_type_id) ;
--
-- Requests
--
create table request (
request_id number (*,0),
department_id number (*,0),
site_id number (*,0),
cross_ref_id varchar2 (11),
padding varchar2 (80),
padding2 varchar2 (80),
constraint pk_request primary key (request_id),
constraint nn_request_department check (department_id is not null),
constraint nn_request_site_id check (site_id is not null)
) ;
--
-- Activity & Users
--
create table activity (
activity_id number (*,0),
user_id number (*,0),
episode_id number (*,0),
request_id number (*,0), -- always NULL!
padding varchar2 (80),
constraint pk_activity primary key (activity_id)
) ;
alter table activity add constraint fk_activity_episode
foreign key (episode_id) references episode (episode_id) ;
alter table activity add constraint fk_activity_request
foreign key (request_id) references request (request_id) ;
--
create table app_users (
user_id number (*,0),
user_name varchar2 (20),
start_date date,
padding varchar2 (80),
constraint pk_users primary key (user_id)
) ;

prompt Loading episode ...
--
insert into episode
with generator as 
(select rownum r
          from (select rownum r from dual connect by rownum <= 1000) a,
               (select rownum r from dual connect by rownum <= 1000) b,
               (select rownum r from dual connect by rownum <= 1000) c
         where rownum <= 1000000
       ) 
select r, 2,
    sysdate + mod (r, 14),
    to_char (r, '0000000000'),
    'ABCDEFGHIJKLMNOPQRSTUVWXYZ' || to_char (r, '000000')
  from generator g
where g.r <= 300000
/
commit ;
--
prompt Loading product_type ...
--
insert into product_type
with generator as 
(select rownum r
          from (select rownum r from dual connect by rownum <= 1000) a,
               (select rownum r from dual connect by rownum <= 1000) b,
               (select rownum r from dual connect by rownum <= 1000) c
         where rownum <= 1000000
       ) 
select r, 
       to_char (r, '000000000'),
       mod (r, 2),
       'ABCDEFGHIJKLMNOPQRST' || to_char (r, '000000')
  from generator g
where g.r <= 12
/
commit ;
--
prompt Loading product_sub_type ...
--
insert into product_sub_type
with generator as 
(select rownum r
          from (select rownum r from dual connect by rownum <= 1000) a,
               (select rownum r from dual connect by rownum <= 1000) b,
               (select rownum r from dual connect by rownum <= 1000) c
         where rownum <= 1000000
       ) 
select r, 
       to_char (r, '000000'),
       to_char (mod (r, 3), '000000'),
       'ABCDE' || to_char (r, '000000')
  from generator g
where g.r <= 15
/
commit ;
--
prompt Loading product ...
--
-- product_id prod_type_id prod_sub_type_id episode_id padding 
insert into product
with generator as 
(select rownum r
          from (select rownum r from dual connect by rownum <= 1000) a,
               (select rownum r from dual connect by rownum <= 1000) b,
               (select rownum r from dual connect by rownum <= 1000) c
         where rownum <= 1000000
       ) 
select r, mod (r, 12) + 1, mod (r, 15) + 1, mod (r, 300000) + 1,
       decode (mod (r, 3), 0, 'I', 1, 'C', 2, 'X', 'U'),
       dbms_random.value (1, 100), NULL
  from generator g
where g.r <= 100000
/
commit ;
--
prompt Loading request ...
--
-- request_id department_id site_id cross_ref_id varchar2 (11) padding 
insert into request
with generator as 
(select rownum r
          from (select rownum r from dual connect by rownum <= 1000) a,
               (select rownum r from dual connect by rownum <= 1000) b,
               (select rownum r from dual connect by rownum <= 1000) c
         where rownum <= 10000000
       ) 
select r, mod (r, 4) + 1, 1, to_char (r, '0000000000'),
'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz01234567890123456789' || to_char (r, '000000'),
'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789012345678' || to_char (r, '000000')
  from generator g
where g.r <= 4000000
/
commit ;
--
prompt Loading activity ...
--
-- activity activity_id user_id episode_id request_id (NULL) padding 
insert into activity
with generator as 
(select rownum r
          from (select rownum r from dual connect by rownum <= 1000) a,
               (select rownum r from dual connect by rownum <= 1000) b,
               (select rownum r from dual connect by rownum <= 1000) c
         where rownum <= 10000000
       ) 
select r, mod (r, 50) + 1, mod (r, 300000) + 1, NULL, NULL
  from generator g
where g.r <= 100000
/
commit ;
--
prompt Loading app_users ...
--
-- app_users user_id user_name start_date padding 
insert into app_users
with generator as 
(select rownum r
          from (select rownum r from dual connect by rownum <= 1000) a,
               (select rownum r from dual connect by rownum <= 1000) b,
               (select rownum r from dual connect by rownum <= 1000) c
         where rownum <= 10000000
       ) 
select r, 
       'User_' || to_char (r, '000000'),
       sysdate - mod (r, 30),
       'ABCDEFGHIJKLMNOPQRSTUVWXYZ' || to_char (r, '000000')
  from generator g
where g.r <= 1000
/
commit ;
--

prompt Episode (1)
create index ix1_episode_cross_ref on episode (cross_ref_id) ;
--
prompt Product (2)
create index ix1_product_episode on product (episode_id) ;
create index ix2_product_type on product (prod_type_id) ;
--
prompt Request (4)
create index ix1_request_site on request (site_id) ;
create index ix2_request_dept on request (department_id) ;
create index ix3_request_cross_ref on request (cross_ref_id) ;
-- The extra index on the referenced columns!!
create index ix4_request on request (cross_ref_id, site_id) ;
--
prompt Activity (2)
create index ix1_activity_episode on activity (episode_id) ;
create index ix2_activity_request on activity (request_id) ;
--
prompt Users (1)
create unique index ix1_users_name on app_users (user_name) ;
--
prompt Gather statistics on schema ...
--
exec dbms_stats.gather_schema_stats ('JB')

10053 sections - original query

***************************************
SINGLE TABLE ACCESS PATH
  -----------------------------------------
  BEGIN Single Table Cardinality Estimation
  -----------------------------------------
  Table: REQUEST  Alias: REQUEST
    Card: Original: 3994236  Rounded: 3994236  Computed: 3994236.00  Non Adjusted: 3994236.00
  -----------------------------------------
  END   Single Table Cardinality Estimation
  -----------------------------------------
  Access Path: TableScan
    Cost:  28806.24  Resp: 28806.24  Degree: 0
      Cost_io: 28738.00  Cost_cpu: 1594402830
      Resp_io: 28738.00  Resp_cpu: 1594402830
******** Begin index join costing ********
  ****** trying bitmap/domain indexes ******
  Access Path: index (FullScan)
    Index: PK_REQUEST
    resc_io: 7865.00  resc_cpu: 855378926
    ix_sel: 1  ix_sel_with_filters: 1
    Cost: 7901.61  Resp: 7901.61  Degree: 0
  Access Path: index (FullScan)
    Index: PK_REQUEST
    resc_io: 7865.00  resc_cpu: 855378926
    ix_sel: 1  ix_sel_with_filters: 1
    Cost: 7901.61  Resp: 7901.61  Degree: 0
  ****** finished trying bitmap/domain indexes ******
******** End index join costing ********
  Best:: AccessPath: TableScan
         Cost: 28806.24  Degree: 1  Resp: 28806.24  Card: 3994236.00  Bytes: 0
***************************************

10053 - updated the Query

***************************************
SINGLE TABLE ACCESS PATH
  -----------------------------------------
  BEGIN Single Table Cardinality Estimation
  -----------------------------------------
  Table: REQUEST  Alias: REQUEST
    Card: Original: 3994236  Rounded: 3994236  Computed: 3994236.00  Non Adjusted: 3994236.00
  -----------------------------------------
  END   Single Table Cardinality Estimation
  -----------------------------------------
  Access Path: TableScan
    Cost:  28806.24  Resp: 28806.24  Degree: 0
      Cost_io: 28738.00  Cost_cpu: 1594402830
      Resp_io: 28738.00  Resp_cpu: 1594402830
  Access Path: index (index (FFS))
    Index: IX4_REQUEST
    resc_io: 3927.00  resc_cpu: 583211030
    ix_sel: 0.0000e+00  ix_sel_with_filters: 1
  Access Path: index (FFS)
    Cost:  3951.96  Resp: 3951.96  Degree: 1
      Cost_io: 3927.00  Cost_cpu: 583211030
      Resp_io: 3927.00  Resp_cpu: 583211030
  Access Path: index (FullScan)
    Index: IX4_REQUEST
    resc_io: 14495.00  resc_cpu: 903225273
    ix_sel: 1  ix_sel_with_filters: 1
    Cost: 14533.66  Resp: 14533.66  Degree: 1
******** Begin index join costing ********
  ****** trying bitmap/domain indexes ******
  Access Path: index (FullScan)
    Index: IX4_REQUEST
    resc_io: 14495.00  resc_cpu: 903225273
    ix_sel: 1  ix_sel_with_filters: 1
    Cost: 14533.66  Resp: 14533.66  Degree: 0
  Access Path: index (FullScan)
    Index: IX4_REQUEST
    resc_io: 14495.00  resc_cpu: 903225273
    ix_sel: 1  ix_sel_with_filters: 1
    Cost: 14533.66  Resp: 14533.66  Degree: 0
  ****** finished trying bitmap/domain indexes ******
******** End index join costing ********
  Best:: AccessPath: IndexFFS  Index: IX4_REQUEST
         Cost: 3951.96  Degree: 1  Resp: 3951.96  Card: 3994236.00  Bytes: 0
***************************************

I mentioned that it is a bug related to the ANSI SQL standard and transformation probably.

As suggested/asked in my first reply:
1. If you use a no_query_transformation then you should find that you get the use of the index (although not in the plan you would expect)
2. If you use the traditional Oracle syntax, then you should not have the same problem.

Full table scan full scan vs. Index
Hi all

Following is explain plan sql
SELECT 1 FROM hz_code_assignments ca, hz_relationship_types rt,
hz_hierarchy_nodes hn
WHERE ca.class_category = 'RELATIONSHIP_TYPE_GROUP' AND ca.owner_table_name = 'HZ_RELATIONSHIP_TYPES. '
AND ca.class_code = 'PARTY_REL_GRP_AR_PAY_ANY' AND ca.status = 'A' AND
CA.owner_table_id = rt.relationship_type_id AND rt.subject_type = 'ORGANIZATION '.
And hn.hierarchy_type = rt.relationship_type
=====================================================================

Operation object name lines cost TQ/exit PStart PStop bytes

SELECT Hint = ALL_ROWS 519 508
519 K 53 508 HASH JOIN
NESTED LOOPS 1-97-5
ACCESS BY INDEX ROWID 1 68 4 TABLES HZ_CODE_ASSIGNMENTS
INDEX RANGE SCAN 15 1 HZ_CODE_ASSIGNMENTS_N1
TABLE ACCESS BY INDEX ROWID 1-29-1 HZ_RELATIONSHIP_TYPES
INDEX UNIQUE SCAN HZ_RELATIONSHIP_TYPES_U1 1-0
TABLE ACCESS FULL HZ_HIERARCHY_NODES 91 K 802 502 K
===================================================================

I added more tip
SELECT / * + INDEX (HP HZ_HIERARCHY_NODES_N2) * / 1 OF hz_code_assignments ca, hz_relationship_types rt,.
hz_hierarchy_nodes hn
WHERE ca.class_category = 'RELATIONSHIP_TYPE_GROUP' AND ca.owner_table_name = 'HZ_RELATIONSHIP_TYPES. '
AND ca.class_code = 'PARTY_REL_GRP_AR_PAY_ANY' AND ca.status = 'A' AND
CA.owner_table_id = rt.relationship_type_id AND rt.subject_type = 'ORGANIZATION '.
And hn.hierarchy_type = rt.relationship_type

=========================================================================
Operation object name lines cost TQ/exit PStart PStop bytes

SELECT Hint = ALL_ROWS 519 605
519 K 53 605 NESTED LOOPS
NESTED LOOPS 1-97-5
ACCESS BY INDEX ROWID 1 68 4 TABLES HZ_CODE_ASSIGNMENTS
INDEX RANGE SCAN 15 1 HZ_CODE_ASSIGNMENTS_N1
TABLE ACCESS BY INDEX ROWID 1-29-1 HZ_RELATIONSHIP_TYPES
INDEX UNIQUE SCAN HZ_RELATIONSHIP_TYPES_U1 1-0
INDEX SCAN FULL HZ_HIERARCHY_NODES_N2 6 K 53 K 600
================================================================

Complete systematic index scan is always expensive

Same query in another instance works fine

==================================================================
Operation object name lines cost TQ/exit PStart PStop bytes

SELECT Hint = 472 19 ALL_ROWS
472 K 48 19 NESTED LOOPS
NESTED LOOPS 1-97-2
TABLE ACCESS BY INDEX ROWID 1 68 1 HZ_CODE_ASSIGNMENTS
INDEX RANGE SCAN 15 1 HZ_CODE_ASSIGNMENTS_N1
TABLE ACCESS BY INDEX ROWID 1-29-1 HZ_RELATIONSHIP_TYPES
INDEX UNIQUE SCAN 1 1 HZ_RELATIONSHIP_TYPES_U1
INDEX FULL SCAN HZ_HIERARCHY_NODES_N2 5 K 48 17 K
===============================================================

Can anyone help find why INDEX FULL SCAN is also expensive in the second case

Thank you
in the application code, add the alter session statement after opening session, either before the execution of the sql statement, how exaclty this works will depend on the design of the application and if you use connection pool etc.

Why choose wrong explain plan when there is a unique index
SQL > create table test in select * from dba_objects;

Table created.

SQL > create table test1 in select * from user_objects;

Table created.

SQL > create index unique i_test_1 on test (object_id);

The index is created.

SQL > exec dbms_stats.gather_table_stats (user, 'TEST');

PL/SQL procedure successfully completed.

SQL > exec dbms_stats.gather_table_stats (user, 'TEST1');

PL/SQL procedure successfully completed.

SQL > set autot trace
SQL > select test1.* from test, test1 where test.object_id = test1.object_id;

23037 selected lines.

Execution plan
----------------------------------------------------------
Hash value of plan: 3995284093

-------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |
-------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | 23038 | 2114K | 77 (12) | 00:00:01 |
| 1. NESTED LOOPS | 23038 | 2114K | 77 (12) | 00:00:01 |
| 2. TABLE ACCESS FULL | TEST1 | 23038 | 2002K | 70 (3) | 00:00:01 |
|* 3 | INDEX UNIQUE SCAN | I_TEST_1 | 1. 5. 0 (0) | 00:00:01 |
-------------------------------------------------------------------------------

Information of predicates (identified by the operation identity card):
---------------------------------------------------

3 - access("TEST".") OBJECT_ID '= 'TEST1'.' OBJECT_ID')

Statistics
----------------------------------------------------------
494 recursive calls
0 db block Gets
26457 consistent gets
0 physical reads
0 redo size
1090589 bytes sent via SQL * Net to client
17270 bytes received via SQL * Net from client
1537 SQL * Net back and forth to and from the client
5 kinds (memory)
0 sorts (disk)
23037 rows processed

SQL > drop index i_test_1;

The index is deleted.

SQL > create index i_test_1 on test (object_id);

The index is created.

SQL > set autot trace
SQL > select test1.* from test, test1 where test.object_id = test1.object_id;

23037 selected lines.

Execution plan
----------------------------------------------------------
Hash value of plan: 845425162

--------------------------------------------------------------------------------
--

| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time
|

--------------------------------------------------------------------------------
--

| 0 | SELECT STATEMENT | 23038 | 2114K | 99 (6) | 00:00:02
|

|* 1 | HASH JOIN | 23038 | 2114K | 99 (6) | 00:00:02
|

| 2. FULL RESTRICTED INDEX SCAN FAST | I_TEST_1 | 49887 | 243K | 27 (4) | 00:00:01
|

| 3. TABLE ACCESS FULL | TEST1 | 23038 | 2002K | 70 (3) | 00:00:01
|

--------------------------------------------------------------------------------
--

Information of predicates (identified by the operation identity card):
---------------------------------------------------

1 - access("TEST".") OBJECT_ID '= 'TEST1'.' OBJECT_ID')

Statistics
----------------------------------------------------------
1 recursive calls
0 db block Gets
1936 complies
411 physical reads
0 redo size
1090589 bytes sent via SQL * Net to client
17270 bytes received via SQL * Net from client
1537 SQL * Net back and forth to and from the client
0 sorts (memory)
0 sorts (disk)
23037 rows processed

I think the hash join is the real plan, why choose nest loop where there is a unique index.
Jinyu wrote:
I think that thought cbo cost single scan index is 0, so loop nest is less expensive than the hash join, but I do not know why here costs 0

Jinyu,

You are right - in a nested loop, the CBO gives unique access by unique index value slightly cheaper than the same access by a non-unique index--essentially subtracting 1 of the normal cost.

It is one of the reasons why you only need to create a no unique index to support a unique constraint, if you have a very good reason - if you modify a unique index that is not unique, change of costs and execution of some paths may change.

Concerning
Jonathan Lewis

Check when a release becomes available

I usually use mistake / error in signals to sequence execution of my screws. However, I use an instrument really old with an old VI (HP 54501 A oscilloscope if you are interested). In fact, my task is I want to trigger the oscilloscope via hardware (BNC cable) and then only to acquire data from the oscilloscope.

The trigger is a function of Agilent 33250 A generator (you need to use a VISA entry to light her trigger output). However, how do I properly sequence the scope read VI in the code - it must take place immediately after (the excitement is long about 200 microseconds) exit on the agilent is turned on?

There is no error in entry to the HP VI. I thought to write a dummy or a portal which offers one of the entrances to the HP VI (after calculation), but given that the operating system is not deterministic (Linux), there is no way to ensure that the oscilloscope read will take place at the right time.

I don't know if I understand your game to the top, but that's how I'd do.

Place the 54501A unique scan mode

54501A Set relaxation for the ready and waiting for the State of relaxation

Trigger the 33250A

(this trigger shoule 54501A)

Check the status of the 54501A trigger

If the 54501A triggered acquire 54501A data

34970a

Hello guys... IM new in labview, now I am working in a project, I need to use the 34970A agilent for data acquisition, I have need of voltage, current and resistance, but I don't know how to accommodate the SIE... I don't know in this order... and then I have to time graph real data acquisition...

Hello lupiita_sopa,

I would like to share with you the following link where you will find information on instrument LabVIEW for the 34970 A driver:

Using Agilent 34970 has with LabVIEW

Also, you will find six examples of ready-to-run provided by National Instruments in this link:
- EZ Scan example: Shows current measurements and frequency based on a multiplexer module
- Advanced Scan example. Shows the measures of tension and resistance on a multiplexer module and shows how to create a list of unique scanning with several types of readings.
- Switch example. Shows switch with 34901A modules and 34903 and alternates cross stitches with a LED matrix interface.
- Example of matrix switch. Illustrates switching on the 34904A matrix. (The user interface for this example is the one shown in Figure 1.)
- RF Mux example. Watch RF switch on the 34905A and 34906 a..
- Multifunction example. Illustrates the use of the 34907A module with analog output control capabilities, (counter) and digital input/output channels.
You can open the examples and see what's on the block diagram. If you have any other question, I'll keep my eyes on this forum.

Best regards!

Photosmart hp7515: completely uninstall the drivers of printers and printers windows 10

I have upgraded to windows 10 on my laptop. I uninstalled the software for my hp7515 and I installed the HP "PS7510_1315 = 1The function" software upgrade.

I can print ok, but cannot parse reliably. When I click on HP SCAN the first time that I can obtain a successful analysis. After that when I click on HP SCAN a second time, I get a dialog box saying that the scanner communication cannot be established blah blah blah. Once I have wait maybe 15 minutes or of disconnection and connection, then back on I can complete successfully another unique scan; then the process begins again. Also, every now and then I get a box saying that SCAN to COMPUTER IS NOT ENABLED any LONGER.

I've uninstalled and reinstalled the software a number of times and now he thinks there are three network printers installed. I want to go back to square one and start again as if I never had an HP printer on my system.

When I try to run a scan on the printer, it finally fails indicating that he has no connection.

The printer works perfectly with my desktop running Windows 7 Professional and another laptop running Windows 7 Home Premium. Before the upgrade to windows 10 Home on this laptop the printer worked perfectly too.

Please help me to completely uninstall my software and my printer from my system so I can start again.

Bob

This weekend I finally had a chance to reload the software of the printer on my laptop. I am happy to say that so far, everything seems to be fine. I was able to scan several times in a row from my laptop running Windows 10 House, and then with my desktop computer running Windows 7 Professional. Don't know if it has made all the difference, but during the installation of the printer and driver on window machine 10, I had both machines Windows 7 mode 'sleep'.

Whatever the reason, I thank you all for your help.

Bob

Old VI does not run in 8.5

Hi all

One of my friends is relatively new by using LabVIEW. He is currently working for a company that has just improved their lisence from 6.0 to 8.5. However, because of the upgrade its VI measure no longer exists. I offered to help him, but I'm afraid I'm not clever enough to solve the problem.

At the opening, it cannot find the following subVIs:

HAVE config.vi

HAVE start.vi

HAVE clear.vi

HAVE read.vi

Read .vi (table of scale)

Device reset.vi

Read a scan.vi

HAVE unique scan.vi

. VI singlescan (single-point waveform) HAVE

I know that this is related to the problem described in the http://zone.ni.com/devzone/cda/tut/p/id/4342 however, if you follow these steps, I'm still not able to get the VI upward and works, I don't know how to connect the replacement of screws

Is there anyone who might be able to help out me? (VI is attached)

Thanks in advance!

Or just go here, select the type of device and look for the latest version of the driver.

BlackBerry smartphone WiFi automatic switching network with OS 5.0.0.46 1?

There was an earlier version of the OS 5 (I don't remember which) that I was using with the 8900 which seems to connect to WiFi networks automatically known to me. For example, once I have connected to my home and work wireless networks (at least once), it could automatically connects with these networks when I'm in the neighborhood. I didn't change anything on the BB or manually switch networks.

However, since using 5.0.0.46 1, the 8900 is no longer connects to the known WiFi signals automatically. Someone said that this has something to do with the setting of the 'unique scan profile' option in the WiFi configuration options screen. But I tried to turn this option on AND outside, and it seems to make no difference. Indeed, if this option is disabled, the 8900 does not connect to ANY WiFi network. If this option is enabled, it only connects to the network I need to manually choose.

Can someone tell me what their experience with automatic connection with WiFi networks known? Y at - it a setting or option that I'm not aware. It's a pain to always have to manually switch networks when I go back home to work and vice versa.

Thank you.

It seems that the problem I mentioned in the opening post is related to 5.0.0.46 1. Yesterday, I saw that there was a 'leaked' to the 8900 OS. This is OS 5.0.0.50 9. I download and installed this new OS and my problem went away. Now the 8900 will connect to known WiFi networks automatically when I "Enable single profile analysis" option unchecked.

Commit to taking a lot of time for the update statement to bulk - 11 GR 2

Hi team,

We have a source table, which is the main table for our application.

When I commit a transaction after update block, it takes long about 2 to 4 minutes.

I don't understand why it takes too long...

Could you please help me on this fix, please...

It's the details on the table,

Total number of records: 35 M record

Validation interval: 500 records / commit

Total scores: 3

total number of columns: 95 - including primary, unique and foreign key columns (all columns will be updated for each update because update from the app online)

Total no of the foreign key columns: 12

Unique key column: 1

Total index: 27 ( including the key index foreign 12 + 1 + 1 index of primary key Unique key index )

example of update statement,

UPDATE DIRECTORY_LISTING_STG
SET
  COLUMN_1 = :VAL_1
  .
  .
  .
  COLUMN_94 = :VAL_94
WHERE RECORD_KEY = :P_KEY_VAL;

The table is.

Plan hash value: 2997337465

--------------------------------------------------------------------------------------------
| Id  | Operation          | Name                  | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------
|   0 | UPDATE STATEMENT   |                       |     1 |   308 |     3   (0)| 00:00:01 |
|   1 |  UPDATE            | DIRECTORY_LISTING_STG |       |       |            |          |
|*  2 |   INDEX UNIQUE SCAN| XPKDLS_STG_PARTPN     |     1 |   308 |     2   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("RECORD_KEY"=TO_NUMBER(:P_KEY))

Details of the database,

Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production
PL/SQL Release 11.1.0.7.0 - Production
"CORE 11.1.0.7.0 Production"
TNS for Linux: Version 11.1.0.7.0 - Production
NLSRTL Version 11.1.0.7.0 - Production

Thank you

RAM

2793617 wrote:

Hello

I am updating table via an application using Hibernate jdbc connection online.

If the update statement will be sent to the database in a pack of 500 documents (batch update).

Thanks Ram

line-by-line UPDATE is slow by slow transformation

In Oracle no other session can 'see' upgrade from uncommitted changes.

The only way to significantly reduce the elapsed time is to have only 1 UPDATE & 1 COMMIT!

Grant permissions for the system explicitly views vs the PLUSTRACE role

Hello everyone.
First of all, I have install the example schema:
SQL > @?/rdbms/admin/utlsampl.sql
After this create the PLUSTRACE role
create the plustrace role;
Grant select on v_$ sesstat to plustrace;
Grant select on v_$ statname to plustrace;
Grant select on v_$ mystat to plustrace;
Grant select on v_$ plustrace session;
Grant select on v_$ sql_plan to plustrace;
Grant select on v_$ sql_plan_statistics to plustrace;
Grant select on v_$ sql to plustrace;
Grant plustrace DBA with admin option;
Grant plustrace Scott;
SQL > conn scott/oracle
Connected.
@?/rdbms/admin/utlxplan.sql
SQL > set autotrace on explain
SQL > set linesize 3200
SQL > select dname from dept d including the 10000 > (select sum (sal) from emp e where e.deptno = d.deptno);
DNAME
--------------
SALES
ACCOUNTING
Execution plan
----------------------------------------------------------
Hash value of plan: 1862058361
----------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |
----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT |         |     1.    39.     5 (20) | 00:00:01 |
|   1. NESTED LOOPS |         |       |       |            |          |
|   2.   NESTED LOOPS |         |     1.    39.     5 (20) | 00:00:01 |
|   3.    VIEW                      | VW_SQ_1 |     1.    26.     4 (25) | 00:00:01 |
|* 4 |     FILTER |         |       |       |            |          |
|   5.      HASH GROUP BY.         |     1.     7.     4 (25) | 00:00:01 |
|   6.       TABLE ACCESS FULL | EMP |    14.    98.     3 (0) | 00:00:01 |
|* 7 |    INDEX UNIQUE SCAN | PK_DEPT |     1.       |     0 (0) | 00:00:01 |
|   8.   TABLE ACCESS BY INDEX ROWID | DEPT |     1.    13.     1 (0) | 00:00:01 |
----------------------------------------------------------------------------------------
Information of predicates (identified by the operation identity card):
---------------------------------------------------
4 - filter (SUM ("SAL") < 10000)
7 - access ("ITEM_1"= "D"." DEPTNO')
SQL > set autot off
SQL > alter session set optimizer_mode = rule;
Modified session.
SQL > alter session set statistics_level = all;
Modified session.
SQL > select dname from dept d including the 10000 > (select sum (sal) from emp e where e.deptno = d.deptno);
DNAME
--------------
ACCOUNTING
SALES
SQL > select * from table (dbms_xplan.display_cursor (null, null, 'allstats')) last;
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
The user has no privileges SELECT on V$ SESSION
SQL > select count (*) from V$ SESSION;
COUNT (*)
----------
22
So, as you see SCOTT has PLUSTRACE role who gets permission to see v_$ session view but it has error user has no privileges SELECT on V$ SESSION
If someone could help me solve the problem Please?

DBA092012 wrote:

another article on this topic https://martincarstenbach.wordpress.com/2010/05/27/the-difference-between-a-direct-grant-and-a-role-in-plsql/

I said already somewhere above, I don't?

Aman...

Plan of 10gr 2 don't reproduce at 11 GR 2 - try to understand why

Just did an upgrade to 10.2.0.4 to 11.2.0.4 (AIX) to our EBS environment. Especially things were going pretty well, but have a boring SQL degradation which didn't fall not by our SPA tests. Tried to create a base to Plan the gr 10, 2 SQL tuning together we created beforehand, but the tuning advisor says that's not a reproducible (plan 3341830380 below).
I compared each table / index used in the query and have confirmed that there is no change TABLE/INDEX (slight possibility since there are quite a few patches interop EBS that had to be applied for the upgrade). Consultant recommended setting a profile, but that did not help. I have a gr 10, 2 env prevail, so I used to generate an outline stored and then copied the outline to the system 11 GR 2. We confirmed he used the outline, but the plan was always different and suboptimal (> 100 s). Then migrated the outline of a basic SQL, but always different/suboptimal plan. Then tried to extract the section SKETCH of the plan 10 gr 2 use it to create a manual SQL profile with the IMPORT_SQL_PROFILE procedure, but also, which did not help (he used the profile, but still suboptimal plan).   Also tried to set optimizer_features_enabled = 10.2.0.4 but still no effect. The SQL is quite complex with a view embedded (this is EBS) 10053 trace is huge and beyond my ability to analyze. I know there must be something in the environment/params/structure that has changed so that the original plan cannot be used, but I was not able to understand.
Any help would be appreciated.
Here's the plan and 10.2.0.4 stats

SQL_ID, 20qss2003zzyn, number of children 0

-------------------------------------

SELECT THE VALUE A.ORGANIZATION_ID, A.ORGANIZATION_CODE, A.ORGANIZATION_NAME DESCRIPTION, ("N", 'N') NVL NVL (TO_NUMBER (NULL),-1), NULL, NVL ('Y', 'Y'), NVL (TO_CHAR (TO_DATE (NULL), 'J'), 0),

NVL (TO_CHAR (TO_DATE (NULL), 'J'), 0) OF ORG_ORGANIZATION_DEFINITIONS A WHERE ((EXISTE (SÉLECTIONNEZ 1 DE ORG_ACCESS_V OAV, FU FND_USER, FND_USER_RESP_GROUPS_DIRECT FUR OÙ FU.) CLAUSE)) USER_ID = FUR. USER_ID AND

OAV.ORGANIZATION_ID = A.ORGANIZATION_ID AND FU. USER_ID = FND_PROFILE. VALUE('USER_ID') AND FUR. RESPONSIBILITY_ID = FVO. (RESPONSIBILITY_ID)) AND A.ORGANIZATION_CODE NOT IN ('IMO', ' 001 ', ' 002')) AND 'Y' = 'Y '.

AND TO_DATE (: A00, ' ' YYYY/MM/DD HH24:MI:SS) BETWEEN NVL (TRUNC (TO_DATE (NULL)), TO_DATE (: A01, ' ' YYYY/MM/DD HH24:MI:SS)) AND NVL (TRUNC (TO_DATE (NULL)), TO_DATE (: A02, ' ' YYYY/MM/DD HH24:MI:SS)) ORDER BY))))

A.ORGANIZATION_CODE

Hash value of plan: 3220009238

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

| ID | Operation                                          | Name                           | Begins | E - lines. E - bytes | Cost (% CPU). E Time | Pstart. Pstop | A - lines.   A - time | Pads | OMem | 1Mem | Used Mem.

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

|* 1 | FILTER                                            |                                |      1.        |       |            |          |       |       |    323. 00:00:04.48 |     857K |       |       |          |

|   2.   SORT ORDER BY |                                |      1.      1.    99.   119 (2). 00:00:02 |       |       |    323. 00:00:04.48 |     857K | 36864 | 36864 | 32768 (0) |

|   3.    THE CARTESIAN MERGE JOIN.                                |      1.      1.    99.    17 (0) | 00:00:01 |       |       |    323. 00:00:04.47 |     857K |       |       |          |

|   4.     NESTED LOOPS |                                |      1.      1.    99.    12 (0) | 00:00:01 |       |       |    323. 00:00:04.47 |     857K |       |       |          |

|   5.      NESTED LOOPS |                                |      1.      1.    95.    11 (0) | 00:00:01 |       |       |    323. 00:00:04.47 |     857K |       |       |          |

|   6.       NESTED LOOPS |                                |      1.      1.    72.     9 (0) | 00:00:01 |       |       |    323. 00:00:04.47 |     856K |       |       |          |

|   7.        NESTED LOOPS |                                |      1.      1.    64.     8 (0) | 00:00:01 |       |       |    325. 00:00:04.46 |     856K |       |       |          |

|   8.         NESTED LOOPS |                                |      1.      1.    32.     7 (0) | 00:00:01 |       |       |    325. 00:00:04.46 |     856K |       |       |          |

|* 9 |          TABLE ACCESS BY INDEX ROWID | HR_ORGANIZATION_INFORMATION |      1.      1.    26.     6 (0). 00:00:01 |       |       |    328. 00:00:00.01 |      31.       |       |          |

| * 10 |           INDEX RANGE SCAN | HR_ORGANIZATION_INFORMATIO_IX1 |      1.     44.       |     1 (0) | 00:00:01 |       |       |    336. 00:00:00.01 |       3.       |       |          |

| * 11 |          TABLE ACCESS BY INDEX ROWID | HR_ALL_ORGANIZATION_UNITS |    328.      1.     6.     1 (0) | 00:00:01 |       |       |    325. 00:00:04.46 |     856K |       |       |          |

| * 12 |           INDEX UNIQUE SCAN | HR_ORGANIZATION_UNITS_PK |    328.      1.       |     0 (0) |          |       |       |    325. 00:00:04.44 |     855K |       |       |          |

| 13.            NESTED LOOPS |                                |    328.      1.   160.   101 (1) | 00:00:02 |       |       |    325. 00:00:04.43 |     855K |       |       |          |

| * 14 |             HASH JOIN                              |                                |    328.      1.   147.   101 (1) | 00:00:02 |       |       |    325. 00:00:04.43 |     855K | 1396K | 1396K | 1330K (0) |

| 15.              NESTED LOOPS |                                |    328.      1.   137.    62 (0) | 00:00:01 |       |       |   7117 | 00:00:04.34 |     853K |       |       |          |

| 16.               NESTED LOOPS |                                |    328.      1.   130.    62 (0) | 00:00:01 |       |       |   7117 | 00:00:04.31 |     853K |       |       |          |

| 17.                NESTED LOOPS |                                |    328.      1.   126.    62 (0) | 00:00:01 |       |       |   7117 | 00:00:04.30 |     852K |       |       |          |

| 18.                 NESTED LOOPS |                                |    328.      1.   108.    34 (0) | 00:00:01 |       |       |   7117 | 00:00:03.87 |     703K |       |       |          |

| 19.                  NESTED LOOPS |                                |    328.      1.    51.     5 (0) | 00:00:01 |       |       | 29873 | 00:00:00.09 |    9054 |       |       |          |

| 20.                   NESTED LOOPS |                                |    328.      1.    37.     3 (0) | 00:00:01 |       |       |    327. 00:00:00.03 |    2949 |       |       |          |

| 21.                    NESTED LOOPS |                                |    328.      1.    22.     2 (0) | 00:00:01 |       |       |    327. 00:00:00.03 |    1968 |       |       |          |

| 22.                     NESTED LOOPS |                                |    328.      1.    18.     2 (0) | 00:00:01 |       |       |    328. 00:00:00.03 |    1640 |       |       |          |

| 23.                      NESTED LOOPS |                                |    328.      1.    12.     1 (0) | 00:00:01 |       |       |    328. 00:00:00.01 |     984 |       |       |          |

| * 24.                       INDEX UNIQUE SCAN | FND_USER_U1 |    328.      1.     5.     1 (0) | 00:00:01 |       |       |    328. 00:00:00.01 |     656.       |       |          |

| * 25.                       INDEX UNIQUE SCAN | HR_ALL_ORGANIZATION_UNTS_TL_PK |    328.      1.     7.     0 (0) |          |       |       |    328. 00:00:00.01 |     328.       |       |          |

| * 26.                      TABLE ACCESS BY INDEX ROWID | HR_ALL_ORGANIZATION_UNITS |    328.      1.     6.     1 (0) | 00:00:01 |       |       |    328. 00:00:00.02 |     656.       |       |          |

| * 27.                       INDEX UNIQUE SCAN | HR_ORGANIZATION_UNITS_PK |    328.      1.       |     0 (0) |          |       |       |    328. 00:00:00.01 |     328.       |       |          |

| * 28.                     INDEX UNIQUE SCAN | MTL_PARAMETERS_U1 |    328.      1.     4.     0 (0) |          |       |       |    327. 00:00:00.01 |     328.       |       |          |

| 29.                    TABLE ACCESS BY INDEX ROWID | FND_USER |    327.      1.    15.     1 (0) | 00:00:01 |       |       |    327. 00:00:00.01 |     981.       |       |          |

| * 30 |                     INDEX UNIQUE SCAN | FND_USER_U1 |    327.      1.       |     0 (0) |          |       |       |    327. 00:00:00.01 |     654 |       |       |          |

| 31.                   TABLE ACCESS BY INDEX ROWID | ORG_ACCESS |    327.      1.    14.     2 (0) | 00:00:01 |       |       | 29873 | 00:00:00.03 |    6105 |       |       |          |

| * 32 |                    INDEX RANGE SCAN | ORG_ACCESS_N1 |    327.      1.       |     1 (0) | 00:00:01 |       |       | 29873 | 00:00:00.01 |     737.       |       |          |

| 33.                  RANGE OF PARTITION ALL THE |                                | 29873 |      1.    57.    29 (0) | 00:00:01 |     1.    14.   7117 | 00:00:03.76 |     694K |       |       |          |

| * 34 |                   TABLE ACCESS BY LOCAL INDEX ROWID | WF_LOCAL_USER_ROLES |    418K |      1.    57.    29 (0) | 00:00:01 |     1.    14.   7117 | 00:00:03.36 |     694K |       |       |          |

| * 35 |                    INDEX RANGE SCAN | WF_LOCAL_USER_ROLES_U1 |    418K |      1.       |    28 (0) | 00:00:01 |     1.    14.   7117 | 00:00:02.49 |     687K |       |       |          |

| 36.                 RANGE OF PARTITION ALL THE |                                |   7117 |      1.    18.    28 (0) | 00:00:01 |     1.    14.   7117 | 00:00:00.42 |     149K |       |       |          |

| * 37 |                  INDEX RANGE SCAN | WF_LOCAL_ROLES_U1 | 99638 |      1.    18.    28 (0) | 00:00:01 |     1.    14.   7117 | 00:00:00.33 |     149K |       |       |          |

| * 38 |                INDEX UNIQUE SCAN | FND_APPLICATION_U1 |   7117 |      1.     4.     0 (0) |          |       |       |   7117 | 00:00:00.01 |     326.       |       |          |

| * 39 |               INDEX UNIQUE SCAN | FND_APPLICATION_TL_U1 |   7117 |      1.     7.     0 (0) |          |       |       |   7117 | 00:00:00.01 |     326.       |       |          |

| 40.              TABLE ACCESS FULL | FND_RESPONSIBILITY |    325.   8972. 89720 |    38 (0) | 00:00:01 |       |       | 42266 | 00:00:00.01 |    1782.       |       |          |

| * 41.             INDEX UNIQUE SCAN | FND_RESPONSIBILITY_TL_U1 |    325.      1.    13.     0 (0) |          |       |       |    325. 00:00:00.01 |     650 |       |       |          |

| 42.         TABLE ACCESS BY INDEX ROWID | HR_ALL_ORGANIZATION_UNITS_TL |    325.      1.    32.     1 (0) | 00:00:01 |       |       |    325. 00:00:00.01 |     327.       |       |          |

| * 43.          INDEX UNIQUE SCAN | HR_ALL_ORGANIZATION_UNTS_TL_PK |    325.      1.       |     0 (0) |          |       |       |    325. 00:00:00.01 |       2.       |       |          |

| * 44 |        TABLE ACCESS BY INDEX ROWID | MTL_PARAMETERS |    325.      1.     8.     1 (0) | 00:00:01 |       |       |    323. 00:00:00.01 |     327.       |       |          |

| * 45 |         INDEX UNIQUE SCAN | MTL_PARAMETERS_U1 |    325.      1.       |     0 (0) |          |       |       |    325. 00:00:00.01 |       2.       |       |          |

| 46.       TABLE ACCESS BY INDEX ROWID | HR_ORGANIZATION_INFORMATION |    323.      1.    23.     2 (0) | 00:00:01 |       |       |    323. 00:00:00.01 |     653.       |       |          |

| * 47 |        INDEX RANGE SCAN | HR_ORGANIZATION_INFORMATIO_FK2 |    323.      1.       |     1 (0) | 00:00:01 |       |       |    323. 00:00:00.01 |     330.       |       |          |

| * 48 |      INDEX SCAN FULL | GL_SETS_OF_BOOKS_U2 |    323.      1.     4.     1 (0) | 00:00:01 |       |       |    323. 00:00:00.01 |       2.       |       |          |

| 49.     KIND OF BUFFER.                                |    323.      1.       |    17 (6) | 00:00:01 |       |       |    323. 00:00:00.01 |      15. 2048 | 2048 | 2048 (0) |

| 50.      TABLE ACCESS FULL | FND_PRODUCT_GROUPS |      1.      1.       |     5 (0) | 00:00:01 |       |       |      1. 00:00:00.01 |      15.       |       |          |

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Name of the query block / Alias object (identified by the operation identity card):

-------------------------------------------------------------

1 SALT 5 $160134

9 SALT$ 5 160134 / HOI1@SEL$2

10 SALT$ 5 160134 / HOI1@SEL$2

11 SALT$ 5 160134 / HAO@SEL$3

12 SALT$ 5 160134 / HAO@SEL$3

13 SALT$ 4F965A88

24 SALT$ 4F965A88 / FU@SEL$4

25 SALT$ 4F965A88 / HAOTL@SEL$6

26 SALT$ 4F965A88 / HAO@SEL$6

27 SALT$ 4F965A88 / HAO@SEL$6

28 SALT$ 4F965A88 / MP@SEL$5

29 SALT$ 4F965A88 / U@SEL$9

30 SALT$ 4F965A88 / U@SEL$9

31 SALT$ 4F965A88 / OA@SEL$5

32 SALT$ 4F965A88 / OA@SEL$5

34 SALT$ 4F965A88 / WF_LOCAL_USER_ROLES@SEL$10

35 SALT$ 4F965A88 / WF_LOCAL_USER_ROLES@SEL$10

37 SALT$ 4F965A88 / WLR@SEL$9

38 SALT$ 4F965A88 / B@SEL$8

39 SALT$ 4F965A88 / T@SEL$8

40 SALT$ 4F965A88 / B@SEL$7

41 SALT$ 4F965A88 / T@SEL$7

42 SALT$ 5 160134 / HAOTL@SEL$3

43 SALT$ 5 160134 / HAOTL@SEL$3

44 SALT$ 5 160134 / MP@SEL$2

45 SALT$ 5 160134 / MP@SEL$2

46 SALT$ 5 160134 / HOI2@SEL$2

47 SALT$ 5 160134 / HOI2@SEL$2

48 SALT$ 5 160134 / GSOB@SEL$2

50 SALT$ 5 160134 / FPG@SEL$2

Vector data

-------------

/*+

BEGIN_OUTLINE_DATA

IGNORE_OPTIM_EMBEDDED_HINTS

OPTIMIZER_FEATURES_ENABLE ('10.2.0.4')

OPT_PARAM ('_b_tree_bitmap_plans' 'false')

OPT_PARAM ('_fast_full_scan_enabled' 'false')

OPT_PARAM ('_index_join_enabled' 'false')

ALL_ROWS

OUTLINE_LEAF(@"SEL$4F965A88")

MERGE(@"SEL$0EE6DB63")

MERGE(@"SEL$443FD15E")

OUTLINE_LEAF(@"SEL$5C160134")

MERGE(@"SEL$335DD26A")

OUTLINE(@"SEL$4")

OUTLINE(@"SEL$0EE6DB63")

MERGE(@"SEL$10")

OUTLINE(@"SEL$443FD15E")

MERGE(@"SEL$6")

MERGE(@"SEL$7")

MERGE(@"SEL$8")

OUTLINE(@"SEL$1")

OUTLINE(@"SEL$335DD26A")

MERGE(@"SEL$3")

OUTLINE(@"SEL$9")

OUTLINE(@"SEL$10")

OUTLINE(@"SEL$5")

OUTLINE(@"SEL$6")

OUTLINE(@"SEL$7")

OUTLINE(@"SEL$8")

OUTLINE(@"SEL$2")

OUTLINE(@"SEL$3")

INDEX_RS_ASC (@"SALT 5 $160134" "HOI1"@"SEL$2" ("HR_ORGANIZATION_INFORMATION".) "ORG_INFORMATION1")) "

INDEX_RS_ASC (@"SALT 5 $160134" "HAO"@"SEL$3" ("HR_ALL_ORGANIZATION_UNITS".) "ORGANIZATION_ID")) "

INDEX_RS_ASC (@"SALT 5 $160134" "HAOTL"@"SEL$3" ("HR_ALL_ORGANIZATION_UNITS_TL".) "ORGANIZATION_ID" "HR_ALL_ORGANIZATION_UNITS_TL" "." " LANGUAGE'))

INDEX_RS_ASC (@"SALT 5 $160134" "MP"@"SEL$2" ("MTL_PARAMETERS".) "ORGANIZATION_ID")) "

INDEX_RS_ASC (@"SALT 5 $160134" "HOI2"@"SEL$2" ("HR_ORGANIZATION_INFORMATION".) "ORGANIZATION_ID" "HR_ORGANIZATION_INFORMATION" "." " ORG_INFORMATION_CONTEXT'))

INDEX (@"SALT 5 $160134" "GSOB"@"SEL$2" ("GL_SETS_OF_BOOKS".) "SET_OF_BOOKS_ID")) "

FULL (@"SALT 5 $160134" "FPG"@"SEL$2")

LEADING (@"SALT 5 $160134" "HOI1"@"SEL$2" "HAO"@"SEL$3" "HAOTL"@"SEL$3" "MP"@"SEL$2" "HOI2"@"SEL$2" "GSOB"@"SEL$2" "FPG"@"SEL$2")

USE_NL (@"SALT 5 $160134" "HAO"@"SEL$3")

USE_NL (@"SALT 5 $160134" "HAOTL"@"SEL$3")

USE_NL (@"SALT 5 $160134" "MP"@"SEL$2")

USE_NL (@"SALT 5 $160134" "HOI2"@"SEL$2")

USE_NL (@"SALT 5 $160134" "GSOB"@"SEL$2")

USE_MERGE_CARTESIAN (@"SALT 5 $160134" "FPG"@"SEL$2")

INDEX (@"SALT$ 4F965A88" "FU"@"SEL$4" ("FND_USER".) "USER_ID")) "

INDEX (@"SALT$ 4F965A88" "HAOTL"@"SEL$6" ("HR_ALL_ORGANIZATION_UNITS_TL".) "ORGANIZATION_ID" "HR_ALL_ORGANIZATION_UNITS_TL" "." " LANGUAGE'))

INDEX_RS_ASC (@"SALT$ 4F965A88" "HAO"@"SEL$6" ("HR_ALL_ORGANIZATION_UNITS".) "ORGANIZATION_ID")) "

INDEX (@"SALT$ 4F965A88" "MP"@"SEL$5" ("MTL_PARAMETERS".) "ORGANIZATION_ID")) "

INDEX_RS_ASC (@"SALT$ 4F965A88" "U"@"SEL$9" ("FND_USER".) "USER_ID")) "

INDEX_RS_ASC (@"SALT$ 4F965A88" "OA"@"SEL$5" ("ORG_ACCESS".) "ORGANIZATION_ID")) "

INDEX_RS_ASC (@"SALT$ 4F965A88" "WF_LOCAL_USER_ROLES"@"SEL$10" ("WF_LOCAL_USER_ROLES".) "USER_NAME" 'WF_LOCAL_USER_ROLES' "." " ROLE NAME""WF_LOCAL_USER_ROLES. " "" USER_ORIG_SYSTEM ".

'WF_LOCAL_USER_ROLES '. ' ' USER_ORIG_SYSTEM_ID ' 'WF_LOCAL_USER_ROLES '. ' ' ROLE_ORIG_SYSTEM ' 'WF_LOCAL_USER_ROLES '. ' ' ROLE_ORIG_SYSTEM_ID ' 'WF_LOCAL_USER_ROLES '. (("" ID_PARTITION "))

INDEX (@"SALT$ 4F965A88" "WLR"@"SEL$9" ("WF_LOCAL_ROLES".) "NAME" "WF_LOCAL_ROLES" "." " ORIG_SYSTEM' 'WF_LOCAL_ROLES '. ' ' ORIG_SYSTEM_ID ' 'WF_LOCAL_ROLES '. (("" ID_PARTITION "))

INDEX (@"SALT$ 4F965A88" "B"@"SEL$8" ("FND_APPLICATION".) "APPLICATION_ID'))"

INDEX (@"SALT$ 4F965A88" "T"@"SEL$8" ("FND_APPLICATION_TL".) "APPLICATION_ID" "FND_APPLICATION_TL" "." " LANGUAGE'))

FULL (@"SALT$ 4F965A88" "B"@"SEL$7")

INDEX (@"SALT$ 4F965A88" "T"@"SEL$7" ("FND_RESPONSIBILITY_TL".) "APPLICATION_ID" "FND_RESPONSIBILITY_TL" "." " RESPONSIBILITY_ID' 'FND_RESPONSIBILITY_TL '. ((' ' LANGUAGE '))

LEADING (@"SALT$ 4F965A88" "FU"@"SEL$4" "HAOTL"@"SEL$6" "HAO"@"SEL$6" "MP"@"SEL$5" "U"@"SEL$9" "OA"@"SEL$5" "WF_LOCAL_USER_ROLES"@"SEL$10" "WLR"@"SEL$9" "B"@"SEL$8" "T"@"SEL$8" "B"@"SEL$7" "T"@"SEL$7")

USE_NL (@"SALT$ 4F965A88" "HAOTL"@"SEL$6")

USE_NL (@"SALT$ 4F965A88" "HAO"@"SEL$6")

USE_NL (@"SALT$ 4F965A88" "MP"@"SEL$5")

USE_NL (@"SALT$ 4F965A88" "U"@"SEL$9")

USE_NL (@"SALT$ 4F965A88" "OA"@"SEL$5")

USE_NL (@"SALT$ 4F965A88" "WF_LOCAL_USER_ROLES"@"SEL$10")

USE_NL (@"SALT$ 4F965A88" "WLR"@"SEL$9")

USE_NL (@"SALT$ 4F965A88" "B"@"SEL$8")

USE_NL (@"SALT$ 4F965A88" "T"@"SEL$8")

USE_HASH (@"SALT$ 4F965A88" "B"@"SEL$7")

USE_NL (@"SALT$ 4F965A88" "T"@"SEL$7")

END_OUTLINE_DATA

*/

Information of predicates (identified by the operation identity card):

---------------------------------------------------

1. ((TO_DATE (: A00,'' AAAA/MM/JJ HH24:MI:SS) filter < = NVL (TRUNC (NULL), TO_DATE (: A02, "YYYY/MM/DD HH24:MI:SS)) AND TO_DATE (: A00, ' YYYY/MM/DD HH24:MI:SS') > = NVL (TRUNC (NULL), TO_DATE (: A01,' YYYY/MM/DD HH24:MI:SS')))))))))

9 filter (("HOI1". "ORG_INFORMATION2" = 'Y' AND 'HOI1'. "" ORG_INFORMATION_CONTEXT "|" = 'CLASS'))

10 - access("HOI1".") ORG_INFORMATION1 "=" INV")

11 - filter("HAO".") BUSINESS_GROUP_ID "= DECODE ("HR_GENERAL"". ")" "GET_XBG_PROFILE"(), 'Y', 'HAO'." BUSINESS_GROUP_ID', 'HR_GENERAL '. "GET_BUSINESS_GROUP_ID" (())) "

12 - access("HAO".") ORGANIZATION_ID "= 'HOI1'." ORGANIZATION_ID')

filter (IS NOT NULL)

14 - access("B".") RESPONSIBILITY_ID "=" OA ". ("' RESPONSIBILITY_ID")

24 - access("FU".") USER_ID «= TO_NUMBER ("FND_PROFILE".» VALUE "('USER_ID')))"

25 - access("HAOTL".") ORGANIZATION_ID ' =: B1 AND 'HAOTL'. '. LANGUAGE "= USERENV ('LANG'))"

filter (DECODE ("HR_SECURITY". "VIEW_ALL"(), "Y", "TRUE" ", HR_SECURITY" "." " SHOW_RECORD "("HR_ALL_ORGANIZATION_UNITS","HAOTL". ((("" ORGANIZATION_ID ")) = 'TRUE')

26 - filter("HAO".") BUSINESS_GROUP_ID "= DECODE ("HR_GENERAL"". ")" "GET_XBG_PROFILE"(), 'Y', 'HAO'." BUSINESS_GROUP_ID', 'HR_GENERAL '. "GET_BUSINESS_GROUP_ID" (())) "

27 - access("HAO".") ORGANIZATION_ID "(=:B1)"

filter ("HAO". "ORGANIZATION_ID"="HAOTL" "." " ORGANIZATION_ID')

28 - access("MP".") ORGANIZATION_ID "(=:B1)"

filter ("MP". "ORGANIZATION_ID"="HAO" "." " ORGANIZATION_ID')

30 - access("FU".") USER_ID '=' U '. (' ' USER_ID ')

32 - access("HAO".") ORGANIZATION_ID "=" OA ". ("' ORGANIZATION_ID")

filter ("OA". "ORGANIZATION_ID"(=:B1) "

34. (("ASSIGNMENT_TYPE" = "B" OU "ASSIGNMENT_TYPE" = serait ') filter)

35 - access("U".") USER_NAME "=" USERNAME"AND"ROLE_ORIG_SYSTEM"="FND_RESP"AND"ROLE_ORIG_SYSTEM_ID "=" OA ". ("' RESPONSIBILITY_ID")

filter (("ROLE_ORIG_SYSTEM" = "FND_RESP" ET "Nom_rôle» PAS COMME ' FND_RESP |)) % | ANY "AND"ROLE_ORIG_SYSTEM_ID "=" OA"". "" RESPONSIBILITY_ID'))

37 - access ("ROLE_NAME"= "WLR"." NAME")

38 - access("B".") APPLICATION_ID '="OA". ("' RESP_APPLICATION_ID")

39 - access("B".") APPLICATION_ID '=' T '. "' APPLICATION_ID ' AND 'T '. "LANGUAGE" = USERENV ('LANG')) "

41 - access("B".") APPLICATION_ID '=' T '. "' APPLICATION_ID ' AND 'B '. "" RESPONSIBILITY_ID "=" T ". "" RESPONSIBILITY_ID "AND"T ". "LANGUAGE" = USERENV ('LANG')) "

43 - access("HAO".") ORGANIZATION_ID "=" HAOTL. " "" ORGANIZATION_ID "AND"HAOTL ". "LANGUAGE" = USERENV ('LANG')) "

filter (DECODE ("HR_SECURITY". "VIEW_ALL"(), "Y", "TRUE" ", HR_SECURITY" "." " SHOW_RECORD "("HR_ALL_ORGANIZATION_UNITS","HAOTL". ((("" ORGANIZATION_ID ")) = 'TRUE')

44 filter (("MP". "ORGANIZATION_CODE"<>'OMI' AND 'MP'." ORGANIZATION_CODE' <>'001' AND 'MP '. (("' ORGANIZATION_CODE" <>' 002'))

45 - access("HAO".") ORGANIZATION_ID "=" MP ". ("' ORGANIZATION_ID")

47 - access("HAO".") ORGANIZATION_ID "= 'HOI2'." ORGANIZATION_ID')

filter ("HOI2". "ORG_INFORMATION_CONTEXT" | "="Accounting information")"

48 - filter("HOI2".") ORG_INFORMATION1 «= TO_CHAR ("GSOB".» SET_OF_BOOKS_ID'))

And here is one of 11.2.0.4 plans

SQL_ID, 20qss2003zzyn, number of children 0

-------------------------------------

SELECT THE VALUE A.ORGANIZATION_ID, A.ORGANIZATION_CODE, A.ORGANIZATION_NAME

DESCRIPTION, NVL ("N", 'N'), (TO_NUMBER (NULL),-1), NULL, NVL NVL ('Y',

'Y'), NVL (TO_CHAR (TO_DATE (NULL), 'J'), 0), NVL (TO_CHAR (TO_DATE (NULL),

"J"), 0) OF ORG_ORGANIZATION_DEFINITIONS A ((EXISTS (SELECT 1 WHERE CLAUSE

ORG_ACCESS_V FVO, FU FND_USER, FND_USER_RESP_GROUPS_DIRECT FUR

WHERE FU. USER_ID = FUR. USER_ID AND OAV.ORGANIZATION_ID =

A.ORGANIZATION_ID AND FU. USER_ID = FND_PROFILE. VALUE ('USER_ID') AND

FUR. RESPONSIBILITY_ID = FVO. RESPONSIBILITY_ID)) AND A.ORGANIZATION_CODE

NO ('IMO', ' 001 ', ' 002')) AND 'Y' = 'Y' AND TO_DATE(:A00,)

"YYYY/MM/DD HH24:MI:SS") BETWEEN NVL (TRUNC (TO_DATE (NULL)),

TO_DATE (: A01, ' YYYY/MM/DD HH24:MI:SS')) AND NVL (TRUNC (TO_DATE (NULL)),)

TO_DATE(:A02, 'YYYY/MM/DD HH24:MI:SS')) ORDER BY A.ORGANIZATION_CODE)

Hash value of plan: 3669628009

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

| ID | Operation                                        | Name                           | Begins | E - lines. E - bytes | Cost (% CPU). E Time | Pstart. Pstop | A - lines.   A - time | Pads | Bed | OMem | 1Mem | Used Mem.

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

|   0 | SELECT STATEMENT |                                |      1.        |       |   145 (100) |          |       |       |    323. 00:02:27.60 |      38 M |      2.       |       |          |

|   1. SORT ORDER BY |                                |      1.      1.    97.   145 (1) | 00:00:02 |       |       |    323. 00:02:27.60 |      38 M |      2. 33792 | 33792 | 30720 (0) |

|* 2 |   FILTER                                         |                                |      1.        |       |            |          |       |       |    323. 00:02:27.60 |      38 M |      2.       |       |          |

|   3.    THE CARTESIAN MERGE JOIN.                                |      1.      1.    97.    16 (0) | 00:00:01 |       |       |    323. 00:02:27.60 |      38 M |      2.       |       |          |

|   4.     NESTED LOOPS |                                |      1.      1.    97.    11 (0) | 00:00:01 |       |       |    323. 00:02:27.60 |      38 M |      2.       |       |          |

|   5.      NESTED LOOPS |                                |      1.      1.    93.    10 (0) | 00:00:01 |       |       |    323. 00:02:27.59 |      38 M |      2.       |       |          |

|   6.       NESTED LOOPS |                                |      1.      1.    71.     9 (0) | 00:00:01 |       |       |    323. 00:02:27.59 |      38 M |      2.       |       |          |

|   7.        NESTED LOOPS |                                |      1.      1.    46.     7 (0) | 00:00:01 |       |       |    331. 00:02:27.58 |      38 M |      2.       |       |          |

|   8.         NESTED LOOPS |                                |      1.      1.    38.     6 (0). 00:00:01 |       |       |    333. 00:02:27.58 |      38 M |      2.       |       |          |

|   9.          TABLE ACCESS BY INDEX ROWID | HR_ALL_ORGANIZATION_UNITS_TL |      1.      4.   128.     2 (0) | 00:00:01 |       |       |    360 | 00:00:00.10 |     288.      2.       |       |          |

| * 10 |           INDEX SKIP SCAN | HR_ALL_ORGANIZATION_UNTS_TL_PK |      1.      1.       |     1 (0) | 00:00:01 |       |       |    360 | 00:00:00.10 |     144.      2.       |       |          |

| * 11 |          TABLE ACCESS BY INDEX ROWID | HR_ALL_ORGANIZATION_UNITS |    360 |      1.     6.     1 (0) | 00:00:01 |       |       |    333. 00:02:27.47 |      38 M |      0 |       |       |          |

| * 12 |           INDEX UNIQUE SCAN | HR_ORGANIZATION_UNITS_PK |    360 |      1.       |     0 (0) |          |       |       |    333. 00:02:27.42 |      38 M |      0 |       |       |          |

| 13.            NESTED LOOPS |                                |    360 |      1.   178.   128 (0) | 00:00:02 |       |       |    333. 00:02:27.41 |      38 M |      0 |       |       |          |

| * 14 |             HASH JOIN |                                |    360 |      1.   165.   128 (0) | 00:00:02 |       |       |    333. 00:02:27.40 |      38 M |      0 |   789K |   789K | 1581K (0) |

| 15.              NESTED LOOPS |                                |    360 |      1.   155.    90 (0) | 00:00:02 |       |       |   7152 | 00:02:27.08 |      38 M |      0 |       |       |          |

| 16.               NESTED LOOPS |                                |    360 |      2.   224.    34 (0) | 00:00:01 |       |       |   1733K | 00:00:15.19 |    1946K |      0 |       |       |          |

| 17.                NESTED LOOPS |                                |    360 |      1.    57.     5 (0) | 00:00:01 |       |       | 30311. 00:00:00.46 |    9318.      0 |       |       |          |

| 18.                 NESTED LOOPS |                                |    360 |      1.    50.     5 (0) | 00:00:01 |       |       | 30311. 00:00:00.35 |    8981 |      0 |       |       |          |

| 19.                  NESTED LOOPS |                                |    360 |      1.    46.     5 (0) | 00:00:01 |       |       | 30311. 00:00:00.23 |    8644.      0 |       |       |          |

| 20.                   NESTED LOOPS |                                |    360 |      1.    32.     3 (0) | 00:00:01 |       |       |    335. 00:00:00.08 |    2221 |      0 |       |       |          |

| 21.                    NESTED LOOPS |                                |    360 |      1.    28.     3 (0) | 00:00:01 |       |       |    360 | 00:00:00.07 |    1861.      0 |       |       |          |

| 22.                     NESTED LOOPS |                                |    360 |      1.    22.     2 (0) | 00:00:01 |       |       |    360 | 00:00:00.03 |    1085 |      0 |       |       |          |

| 23.                      TABLE ACCESS BY INDEX ROWID | FND_USER |    360 |      1.    15.     2 (0) | 00:00:01 |       |       |    360 | 00:00:00.02 |     725 |      0 |       |       |          |

| * 24.                       INDEX UNIQUE SCAN | FND_USER_U1 |    360 |      1.       |     1 (0) | 00:00:01 |       |       |    360 | 00:00:00.02 |     365.      0 |       |       |          |

| * 25.                      INDEX UNIQUE SCAN | HR_ALL_ORGANIZATION_UNTS_TL_PK |    360 |      1.     7.     0 (0) |          |       |       |    360 | 00:00:00.01 |     360 |      0 |       |       |          |

| * 26.                     TABLE ACCESS BY INDEX ROWID | HR_ALL_ORGANIZATION_UNITS |    360 |      1.     6.     1 (0) | 00:00:01 |       |       |    360 | 00:00:00.04 |     776.      0 |       |       |          |

| * 27.                      INDEX UNIQUE SCAN | HR_ORGANIZATION_UNITS_PK |    360 |      1.       |     0 (0) |          |       |       |    360 | 00:00:00.01 |     360 |      0 |       |       |          |

| * 28.                    INDEX UNIQUE SCAN | MTL_PARAMETERS_U1 |    360 |      1.     4.     0 (0) |          |       |       |    335. 00:00:00.01 |     360 |      0 |       |       |          |

| 29.                   TABLE ACCESS BY INDEX ROWID | ORG_ACCESS |    335.      1.    14.     2 (0) | 00:00:01 |       |       | 30311. 00:00:00.14 |    6423 |      0 |       |       |          |

| * 30 |                    INDEX RANGE SCAN | ORG_ACCESS_N1 |    335.      1.       |     1 (0) | 00:00:01 |       |       | 30311. 00:00:00.05 |     752.      0 |       |       |          |

| * 31.                  INDEX UNIQUE SCAN | FND_APPLICATION_U1 | 30311.      1.     4.     0 (0) |          |       |       | 30311. 00:00:00.07 |     337.      0 |       |       |          |

| * 32 |                 INDEX UNIQUE SCAN | FND_APPLICATION_TL_U1 | 30311.      1.     7.     0 (0) |          |       |       | 30311. 00:00:00.08 |     337.      0 |       |       |          |

| 33.                RANGE OF PARTITION ALL THE |                                | 30311.      1.    55.    29 (0) | 00:00:01 |     1.    14.   1733K | 00:00:14.01 |    K 1937 |      0 |       |       |          |

| 34.                 TABLE ACCESS BY LOCAL INDEX ROWID | WF_LOCAL_USER_ROLES |    424K |      1.    55.    29 (0) | 00:00:01 |     1.    14.   1733K | 00:00:13.04 |    K 1937 |      0 |       |       |          |

| * 35 |                  INDEX RANGE SCAN | WF_LOCAL_USER_ROLES_N7 |    424K |      1.       |    28 (0) | 00:00:01 |     1.    14.   1733K | 00:00:03.56 |     615K |      0 |       |       |          |

| 36.               RANGE OF PARTITION ALL THE |                                |   1733K |      1.    43.    28 (0) | 00:00:01 |     1.    14.   7152 | 00:02:10.72 |      36 M |      0 |       |       |          |

| * 37 |                INDEX RANGE SCAN | WF_USER_ROLE_ASSIGNMENTS_N1 |     24 M |      1.    43.    28 (0) | 00:00:01 |     1.    14.   7152 | 00:01:56.00 |      36 M |      0 |       |       |          |

| 38.              TABLE ACCESS FULL | FND_RESPONSIBILITY |    333.   9041. 90410 |    38 (0) | 00:00:01 |       |       | 49837 | 00:00:00.03 |    1573.      0 |       |       |          |

| * 39 |             INDEX UNIQUE SCAN | FND_RESPONSIBILITY_TL_U1 |    333.      1.    13.     0 (0) |          |       |       |    333. 00:00:00.01 |     536.      0 |       |       |          |

| * 40 |         TABLE ACCESS BY INDEX ROWID | MTL_PARAMETERS |    333.      1.     8.     1 (0) | 00:00:01 |       |       |    331. 00:00:00.01 |     337.      0 |       |       |          |

| * 41.          INDEX UNIQUE SCAN | MTL_PARAMETERS_U1 |    333.      1.       |     0 (0) |          |       |       |    333. 00:00:00.01 |       4.      0 |       |       |          |

| * 42 |        TABLE ACCESS BY INDEX ROWID | HR_ORGANIZATION_INFORMATION |    331.      1.    25.     2 (0) | 00:00:01 |       |       |    323. 00:00:00.01 |     161.      0 |       |       |          |

| * 43.         INDEX RANGE SCAN | HR_ORGANIZATION_INFORMATIO_FK2 |    331.      2.       |     1 (0) | 00:00:01 |       |       |    662. 00:00:00.01 |      43.      0 |       |       |          |

| 44.       TABLE ACCESS BY INDEX ROWID | HR_ORGANIZATION_INFORMATION |    323.      1.    22.     1 (0) | 00:00:01 |       |       |    323. 00:00:00.01 |     164.      0 |       |       |          |

| * 45 |        INDEX RANGE SCAN | HR_ORGANIZATION_INFORMATIO_FK2 |    323.      1.       |     1 (0) | 00:00:01 |       |       |    323. 00:00:00.01 |      43.      0 |       |       |          |

| * 46 |      INDEX SCAN FULL | GL_SETS_OF_BOOKS_U2 |    323.      1.     4.     1 (0) | 00:00:01 |       |       |    323. 00:00:00.01 |       3.      0 |       |       |          |

| 47.     KIND OF BUFFER.                                |    323.      1.       |    16 (7) | 00:00:01 |       |       |    323. 00:00:00.01 |      14.      0 | 2048 | 2048 | 2048 (0) |

| 48.      TABLE ACCESS FULL | FND_PRODUCT_GROUPS |      1.      1.       |     5 (0) | 00:00:01 |       |       |      1. 00:00:00.01 |      14.      0 |       |       |          |

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Name of the query block / Alias object (identified by the operation identity card):

-------------------------------------------------------------

1 SALT 5 $160134

9 SALT$ 5 160134 / HAOTL@SEL$3

10 SALT$ 5 160134 / HAOTL@SEL$3

11 SALT$ 5 160134 / HAO@SEL$3

12 SALT$ 5 160134 / HAO@SEL$3

13 SALT$ F6C42A04

23 SALT$ F6C42A04 / FU@SEL$4

24 SALT$ F6C42A04 / FU@SEL$4

25 SALT$ F6C42A04 / HAOTL@SEL$6

26 SALT$ F6C42A04 / HAO@SEL$6

27 SALT$ F6C42A04 / HAO@SEL$6

28 SALT$ F6C42A04 / MP@SEL$5

29 SALT$ F6C42A04 / OA@SEL$5

30 SALT$ F6C42A04 / OA@SEL$5

31 SALT$ F6C42A04 / B@SEL$8

32 SALT$ F6C42A04 / T@SEL$8

34 SALT$ F6C42A04 / WF_LOCAL_USER_ROLES@SEL$12

35 SALT$ F6C42A04 / WF_LOCAL_USER_ROLES@SEL$12

37 SALT$ F6C42A04 / WURA@SEL$9

38 SALT$ F6C42A04 / B@SEL$7

39 SALT$ F6C42A04 / T@SEL$7

40 SALT$ 5 160134 / MP@SEL$2

41 SALT$ 5 160134 / MP@SEL$2

42 SALT$ 5 160134 / HOI1@SEL$2

43 SALT$ 5 160134 / HOI1@SEL$2

44 SALT$ 5 160134 / HOI2@SEL$2

45 SALT$ 5 160134 / HOI2@SEL$2

46 SALT$ 5 160134 / GSOB@SEL$2

48 SALT$ 5 160134 / FPG@SEL$2

Vector data

-------------

/*+

BEGIN_OUTLINE_DATA

IGNORE_OPTIM_EMBEDDED_HINTS

OPTIMIZER_FEATURES_ENABLE ('11.2.0.4')

DB_VERSION ('11.2.0.4')

OPT_PARAM ('_b_tree_bitmap_plans' 'false')

OPT_PARAM ('_fast_full_scan_enabled' 'false')

ALL_ROWS

OUTLINE_LEAF(@"SEL$F6C42A04")

ELIMINATE_JOIN (@"SALT$ AE42E34E" "U"@"SEL$9")

OUTLINE_LEAF(@"SEL$5C160134")

MERGE(@"SEL$335DD26A")

OUTLINE(@"SEL$AE42E34E")

MERGE(@"SEL$443FD15E")

MERGE(@"SEL$C05AD324")

OUTLINE(@"SEL$1")

OUTLINE(@"SEL$335DD26A")

MERGE(@"SEL$3")

OUTLINE(@"SEL$4")

OUTLINE(@"SEL$443FD15E")

MERGE(@"SEL$6")

MERGE(@"SEL$7")

MERGE(@"SEL$8")

OUTLINE(@"SEL$C05AD324")

MERGE(@"SEL$12")

OUTLINE(@"SEL$2")

OUTLINE(@"SEL$3")

OUTLINE(@"SEL$5")

OUTLINE(@"SEL$6")

OUTLINE(@"SEL$7")

OUTLINE(@"SEL$8")

OUTLINE(@"SEL$9")

OUTLINE(@"SEL$12")

INDEX_SS (@"SALT 5 $160134" "HAOTL"@"SEL$3" ("HR_ALL_ORGANIZATION_UNITS_TL".) "ORGANIZATION_ID" "HR_ALL_ORGANIZATION_UNITS_TL" "." " LANGUAGE'))

INDEX_RS_ASC (@"SALT 5 $160134" "HAO"@"SEL$3" ("HR_ALL_ORGANIZATION_UNITS".) "ORGANIZATION_ID")) "

INDEX_RS_ASC (@"SALT 5 $160134" "MP"@"SEL$2" ("MTL_PARAMETERS".) "ORGANIZATION_ID")) "

INDEX_RS_ASC (@"SALT 5 $160134" "HOI1"@"SEL$2" ("HR_ORGANIZATION_INFORMATION".) "ORGANIZATION_ID" "HR_ORGANIZATION_INFORMATION" "." " ORG_INFORMATION_CONTEXT'))

INDEX_RS_ASC (@"SALT 5 $160134" "HOI2"@"SEL$2" ("HR_ORGANIZATION_INFORMATION".) "ORGANIZATION_ID" "HR_ORGANIZATION_INFORMATION" "." " ORG_INFORMATION_CONTEXT'))

INDEX (@"SALT 5 $160134" "GSOB"@"SEL$2" ("GL_SETS_OF_BOOKS".) "SET_OF_BOOKS_ID")) "

FULL (@"SALT 5 $160134" "FPG"@"SEL$2")

LEADING (@"SALT 5 $160134" "HAOTL"@"SEL$3" "HAO"@"SEL$3" "MP"@"SEL$2" "HOI1"@"SEL$2" "HOI2"@"SEL$2" "GSOB"@"SEL$2" "FPG"@"SEL$2")

USE_NL (@"SALT 5 $160134" "HAO"@"SEL$3")

USE_NL (@"SALT 5 $160134" "MP"@"SEL$2")

USE_NL (@"SALT 5 $160134" "HOI1"@"SEL$2")

USE_NL (@"SALT 5 $160134" "HOI2"@"SEL$2")

USE_NL (@"SALT 5 $160134" "GSOB"@"SEL$2")

USE_MERGE_CARTESIAN (@"SALT 5 $160134" "FPG"@"SEL$2")

PUSH_SUBQ(@"SEL$F6C42A04")

INDEX_RS_ASC (@"SALT$ F6C42A04" "FU"@"SEL$4" ("FND_USER".) "USER_ID")) "

INDEX (@"SALT$ F6C42A04" "HAOTL"@"SEL$6" ("HR_ALL_ORGANIZATION_UNITS_TL".) "ORGANIZATION_ID" "HR_ALL_ORGANIZATION_UNITS_TL" "." " LANGUAGE'))

INDEX_RS_ASC (@"SALT$ F6C42A04" "HAO"@"SEL$6" ("HR_ALL_ORGANIZATION_UNITS".) "ORGANIZATION_ID")) "

INDEX (@"SALT$ F6C42A04" "MP"@"SEL$5" ("MTL_PARAMETERS".) "ORGANIZATION_ID")) "

INDEX_RS_ASC (@"SALT$ F6C42A04" "OA"@"SEL$5" ("ORG_ACCESS".) "ORGANIZATION_ID")) "

INDEX (@"SALT$ F6C42A04" "B"@"SEL$8" ("FND_APPLICATION".) "APPLICATION_ID'))"

INDEX (@"SALT$ F6C42A04" "T"@"SEL$8" ("FND_APPLICATION_TL".) "APPLICATION_ID" "FND_APPLICATION_TL" "." " LANGUAGE'))

INDEX_RS_ASC (@"SALT$ F6C42A04" "WF_LOCAL_USER_ROLES"@"SEL$12" ("WF_LOCAL_USER_ROLES".) "ROLE_ORIG_SYSTEM_ID" "WF_LOCAL_USER_ROLES" "." " ROLE_ORIG_SYSTEM'))

INDEX (@"SALT$ F6C42A04" "WURA"@"SEL$9" ("WF_USER_ROLE_ASSIGNMENTS".) "RELATIONSHIP_ID" "WF_USER_ROLE_ASSIGNMENTS" "." " USER_NAME' 'WF_USER_ROLE_ASSIGNMENTS '. "" ROLE NAME ""WF_USER_ROLE_ASSIGNMENTS. " "" START_DATE ".

'WF_USER_ROLE_ASSIGNMENTS '. (("" END_DATE "))

FULL (@"SALT$ F6C42A04" "B"@"SEL$7")

INDEX (@"SALT$ F6C42A04" "T"@"SEL$7" ("FND_RESPONSIBILITY_TL".) "APPLICATION_ID" "FND_RESPONSIBILITY_TL" "." " RESPONSIBILITY_ID' 'FND_RESPONSIBILITY_TL '. ((' ' LANGUAGE '))

LEADING (@"SALT$ F6C42A04" "FU"@"SEL$4" "HAOTL"@"SEL$6" "HAO"@"SEL$6" "MP"@"SEL$5" "OA"@"SEL$5" "B"@"SEL$8" "T"@"SEL$8" "WF_LOCAL_USER_ROLES"@"SEL$12" "WURA"@"SEL$9" "B"@"SEL$7" "T"@"SEL$7")

USE_NL (@"SALT$ F6C42A04" "HAOTL"@"SEL$6")

USE_NL (@"SALT$ F6C42A04" "HAO"@"SEL$6")

USE_NL (@"SALT$ F6C42A04" "MP"@"SEL$5")

USE_NL (@"SALT$ F6C42A04" "OA"@"SEL$5")

USE_NL (@"SALT$ F6C42A04" "B"@"SEL$8")

USE_NL (@"SALT$ F6C42A04" "T"@"SEL$8")

USE_NL (@"SALT$ F6C42A04" "WF_LOCAL_USER_ROLES"@"SEL$12")

USE_NL (@"SALT$ F6C42A04" "WURA"@"SEL$9")

USE_HASH (@"SALT$ F6C42A04" "B"@"SEL$7")

USE_NL (@"SALT$ F6C42A04" "T"@"SEL$7")

END_OUTLINE_DATA

*/

Information of predicates (identified by the operation identity card):

---------------------------------------------------

2. ((TO_DATE (: A00,'' AAAA/MM/JJ HH24:MI:SS) filter < = NVL (TRUNC (TO_DATE (NULL)), TO_DATE (: A02, "YYYY/MM/DD HH24:MI:SS)) AND TO_DATE (: A00, ' YYYY/MM/DD HH24:MI:SS') > = NVL (TRUNC (TO_DATE (NULL)), TO_DATE (: A01,' YYYY/MM/DD))))))

HH24:MI:SS')))

10 - access("HAOTL".") LANGUAGE "= USERENV ('LANG'))"

filter ((DECODE ("HR_SECURITY". "VIEW_ALL"(), "Y", "TRUE" ", HR_SECURITY" "." " SHOW_RECORD "("HR_ALL_ORGANIZATION_UNITS","HAOTL". (("" ORGANIZATION_ID ")) = 'TRUE' AND 'HAOTL '. "LANGUAGE" = USERENV ('LANG'))) "

11 - filter("HAO".") BUSINESS_GROUP_ID "= DECODE ("HR_GENERAL"". ")" "GET_XBG_PROFILE"(), 'Y', 'HAO'." BUSINESS_GROUP_ID', 'HR_GENERAL '. "GET_BUSINESS_GROUP_ID" (())) "

12 - access("HAO".") ORGANIZATION_ID "=" HAOTL. " ("' ORGANIZATION_ID")

filter (IS NOT NULL)

14 - access("B".") RESPONSIBILITY_ID "=" OA ". ("' RESPONSIBILITY_ID")

24 - access("FU".") USER_ID «= TO_NUMBER ("FND_PROFILE".» VALUE "('USER_ID')))"

25 - access("HAOTL".") ORGANIZATION_ID ' =: B1 AND 'HAOTL'. '. LANGUAGE "= USERENV ('LANG'))"

filter (DECODE ("HR_SECURITY". "VIEW_ALL"(), "Y", "TRUE" ", HR_SECURITY" "." " SHOW_RECORD "("HR_ALL_ORGANIZATION_UNITS","HAOTL". ((("" ORGANIZATION_ID ")) = 'TRUE')

26 - filter("HAO".") BUSINESS_GROUP_ID "= DECODE ("HR_GENERAL"". ")" "GET_XBG_PROFILE"(), 'Y', 'HAO'." BUSINESS_GROUP_ID', 'HR_GENERAL '. "GET_BUSINESS_GROUP_ID" (())) "

27 - access("HAO".") ORGANIZATION_ID "(=:B1)"

filter ("HAO". "ORGANIZATION_ID"="HAOTL" "." " ORGANIZATION_ID')

28 - access("MP".") ORGANIZATION_ID "(=:B1)"

filter ("MP". "ORGANIZATION_ID"="HAO" "." " ORGANIZATION_ID')

30 - access("HAO".") ORGANIZATION_ID "=" OA ". ("' ORGANIZATION_ID")

filter ("OA". "ORGANIZATION_ID"(=:B1) "

31 - access("B".") APPLICATION_ID '="OA". ("' RESP_APPLICATION_ID")

32 - access("B".") APPLICATION_ID '=' T '. "' APPLICATION_ID ' AND 'T '. "LANGUAGE" = USERENV ('LANG')) "

35 - access ("ROLE_ORIG_SYSTEM_ID"= "OA"." RESPONSIBILITY_ID"AND"ROLE_ORIG_SYSTEM"="FND_RESP")

37 - access("WURA".") RELATIONSHIP_ID "=(-1) AND"WURA". "' USER_NAME '=' USERNAME ' AND 'WURA. ("" ROLE NAME "=" ROLE_NAME ")

filter (("WURA". "" ROLE NAME "DON'T LIKE NOT ' FND_RESP | % | ANY"AND"USER_NAME "=" WURA ". (("" USER_NAME "))

39 - access("B".") APPLICATION_ID '=' T '. "' APPLICATION_ID ' AND 'B '. "" RESPONSIBILITY_ID "=" T ". "" RESPONSIBILITY_ID "AND"T ". "LANGUAGE" = USERENV ('LANG')) "

40 filter (("MP". "ORGANIZATION_CODE"<>'OMI' AND 'MP'." ORGANIZATION_CODE' <>'001' AND 'MP '. (("' ORGANIZATION_CODE" <>' 002'))

41 - access("HAO".") ORGANIZATION_ID "=" MP ". ("' ORGANIZATION_ID")

42 filter (("HOI1". "ORG_INFORMATION1"= 'INV' AND 'HOI1'." ORG_INFORMATION2 ' = 'Y')).

43 - access("HAO".") ORGANIZATION_ID "= 'HOI1'." ORGANIZATION_ID')

filter ("HOI1". "ORG_INFORMATION_CONTEXT" | "="CLASS")"

45 - access("HAO".") ORGANIZATION_ID "= 'HOI2'." ORGANIZATION_ID')

filter ("HOI2". "ORG_INFORMATION_CONTEXT" | "="Accounting information")"

46 - filter("HOI2".") ORG_INFORMATION1 «= TO_CHAR ("GSOB".» SET_OF_BOOKS_ID'))

Thank you!
Wayne

So, I was in the middle of writing an answer both of your responses when I found my problem. I was writing how I tried to manually create a SQL profile that had the suspicion on the 10.2.0.4 WF_LOCAL_USER_ROLES contour (since this is where the suboptimal plan 11.2 spends it's time (it's using a different index)), when I noticed as the 11.2.0.4 plan accesses the WF_USER_ROLE_ASSIGNMENTS table (or index it is anyway) and the 10.2.0.4 plan does not work (it accesses WF_LOCAL_ROLES). First thought that maybe 11.2 a get rid of a useless, but then realized join the simplest answer. A view has changed.   When I compared the schema objects, I only looked at tables and index, I forgot to watch the views (DOH!). It turns out that one patch interop EBS has changed the definition of one of the FND views to refer to different tables.   Then, of course, 11 2 GR system cannot reproduce the plan of 10.2.

So, now I just have to treat it as a more conventional cannot change the tuning exercise code (hopefully that won't have another post here for that...)

Thanks for the reboot to my thoughts on this guy!

Wayne

Unique scanning

Similar Questions

How the Index range scans work

How to index full scans of work

How to index Fast Full Scans work

Skip index scans

How Index Skip scan work

Maybe you are looking for