Implementation plan of DAC

Hi all

I'm new to the DAC. I have a new domain with tasks for the new fact and dimension tables custom. Now

I have to add this new already existing domain of the execution plan that allows to launch at full load.

My question is when I add this new plan already existing domain running and when I build it he will be

set the order of tasks with the new tasks that are there in the new domain or do it automatically

I need to assign order of discipline before adding to the execution plan.

Also can someone help me how can I give order to the tasks of discipline as to run the first mapping of SDE and run the mapping of SIL.

I have created groups of tasks, but I don't know what I should add to plan of execution or not because I like the customized 3 dimensional mappings and

I created 3 groups of different tasks for each table.

Any help would be really appreciated.

Thanks in advance!

You don't have to do anything dac will take care of him.

Just add new domain to EP, build and run that's all.

The tables related to the new domain will be loaded as full and rest as yen

If brand aid

~ http://cool-bi.com

Tags: Business Intelligence

Similar Questions

  • Could someone tell me how I can I spend the sql_id/plan_hash_value and corresponding implementation plans?

    Hi experts,

    I want to know, how to get the past (like a week older) sql_id/plan_jash_values and corresponding implementation plans.

    I am aware that v$ session contains these last sql_id/hash_value, distinguished by a sql statement that is executed and we can get the plan_hash_value from v$ sql using the following query.

    Select sql_id, hash_value, plan_hash_value from v$ sql where sql_id = & sql_id;

    Once you leave this session, session $ v clears the session information, subsequently sql_id will be also deleted.

    I want to know,

    1 how long v$ sql holds the plan_hash_value, is there a retention period?

    2. when we issue ' select * table ((dbms_xplan.display_cursor ('& sql_id')) ", when the execution plan is read since?").

    3. I need to compare the implementation plans for a perticular query last week one, what are my options?

    Please help me with my questions, experts.

    Kind regards

    Ravi K

    Yes, the AWR repository is accessible by SQL queries on the DBA_HIST views.  (these are the same!)

    Thus, the AWR retention period applies to data in views DBA_HIST.

    A SQL query that is not reported by a snapshot of the CWA would not be in the views DBA_HIST.

    Hemant K Collette

  • How to understand the implementation of the plan in oracle I mean if I see two implementation plans for a single sql_id plans 2 How to determine the best execution plan? Links and answers are much appreciated. Thank you

    How to understand the implementation of the plan in oracle I mean if I see two implementation plans for a single sql_id plans 2 How to determine the best execution plan? Links and answers are much appreciated. Thank you

    How to understand the implementation of the plan in oracle I mean if I see two implementation plans for a single sql_id plans 2 How to determine the best execution plan? Links and answers are much appreciated. Thank you

    After two execution plans that have the same sql_id, so we can see what you're talking about.

    See "Oracle Explain Explain Plan optimizer" by Maria Colgan of the Oracle optimizer group

    http://www.Oracle.com/technetwork/database/bi-Datawarehousing/TWP-explain-the-explain-plan-052011-393674.PDF

    Examine the various aspects of a selectivity to parallel execution plan

    performance and understand what information you should be brilliant

    the plan can be overwhelming even for the most experienced DBA. This document

    offers a detailed explanation on each of the aspects of the execution plan and a

    Overview of what caused the CBO to make the decision, he did.

  • How to run a SQL statement to use a specific implementation plan

    Hi all

    I have a SQL that has recently been run badly. I tried the Advisor tuning SQL for the given SQL query and it gives the following information:

    GENERAL INFORMATION SECTION

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

    Name of the task of tuning: 2q94zb7djr2xn

    The owner task of tuning: LMDBPROD

    Type of work: single SQL statement

    County of execution: 2

    The current run: EXEC_8869

    Type of execution: TUNE SQL

    Scope: COMPLETE

    Time Limit (seconds): 60

    Status: COMPLETED

    Started on the: 03/02/2014-20:43:39

    To the: 03/02/2014 20:44:25

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

    Name of the schema: LMDBPROD

    SQL ID: 2q94zb7djr2xn

    SQL text: SELECT NPCOMMON. FGET_ACTION_CODE (ORDNUM) ACTIONCODE, STATUS,

    SUMA COUNT (*) FROM SORDER, WHERE HEADORDNUM IS NOT NULL AND

    NPCOMMON. FGET_PRODUCTOFFER4ORDER (ORDNUM) IN (SELECT ID FROM)

    PRODUCTOFFER WHERE PPSPECIFICATION_ID IN (SELECT ID FROM)

    PPSPECIFICATION WHERE PCLASS_CODE IN (SELECT PCLASS_CODE FROM)

    ARUSERGROUP WHERE CODE IN (SELECT ARUSERGROUP_CODE FROM)

    ARUSER_ARUSERGROUP WHERE ARUSER_USERNAME =: B1 AND STATUS = '1')

    AND STATUS = '1'))) GROUP BY NPCOMMON. FGET_ACTION_CODE (ORDNUM),

    STATUS

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

    RESULTS SECTION (1 result)

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

    1-alternative Plan conclusion

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

    Some implementation plans alternative for this statement was found by searching

    performance data in real-time and historical of the system.

    The following table lists these plans sorted by their average time.

    See "SECTION of ALTERNATIVE PLANS" section for detailed information on each

    plan.

    plan ID hash last visit elapsed note of origin (s)

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

    1 617797893 2013-07-11/07: 45:20 9.555 no reproducible STS

    2 1311086720 2014-01-31/04: 00:44 19.569 AWR

    3 1226863820 2014-01-31/18: 00:24 AWR 21.158

    4 1359606848 2014-02-03/16: 00:34 21.492 AWR original plan

    The plan with hash 617797893 seems the most efficient one and is based on some specific SQL Tuning Set I ran on this time. But the note says that the plan is not reproducible. Is there anyway how can I force the SQL statement to execute the plan? The database version is Standard Edition 11.2.0.1.0

    Best regards

    Rodriguez

    Hello

    I think you can use this

    http://rnm1978.WordPress.com/2011/06/28/Oracle-11g-how-to-force-a-sql_id-to-use-a-plan_hash_value-using-SQL-baselines/

    before 11 g, we used to create an outline stored for this.

    concerning

  • Hello, please tell me how to subscribe only 2 requests for a single implementation plan. Thank you

    Hello, please tell me how to subscribe only 2 requests for a single implementation plan. Thank you

    Please see our plans:https://creative.adobe.com/plans

    In the case where you can't find a plan consisting of applications, you want to subscribe.

    Subscribe to unique app membership plans.

    I hope this helps.

    Concerning

    Megha Rawat

  • Is there a way to PL/SQL to force Oracle to re-evaluate the implementation plan

    In a packaged procedure, I have sturctured of code like this:
    for rec1 in cursor1
    loop
      -- do some calculations
      for rec2 in cursor2(cursor_params)
      loop
        -- do more stuff
      end loop;
    end loop;
    The problem is that the first time through the outer loop, that he is on an implementation plan for the cursor from inside. But the plan, with what happens isn't the best plan for later iterations of the loop. I want to do is something like this:
    for rec1 in cursor1
    loop
      -- do some calculations
      if rec1.column1 != prev_column1
      then
        -- forget previously calculated cursor2 execution plan
      end if;
      for rec2 in cursor2(cursor_params)
      loop
        -- do more stuff
      end loop;
    end loop;

    http://prutser.WordPress.com/2009/04/19/flushing-a-cursor-out-of-the-library-cache/

  • Difference of cardinality estimate on explain plan and implementation plan

    I think some of you know the 5% rule, which is explained in the note on metalink # 68992.1.
    In short, this means that (with bind peeking out voltage)
    - c1 > :b1 : 5% of selectivity
    - c1 >= :b1 :5% of selectivity
    - c1 between :b1 and :b2 : 0.25% of selectivity (5% * 5%)
    It is also well explained fundamentals of the CBO by Jonathan Lewis.

    But I found a few odd cases where the 5% rule is broken DURATION estimate.
    The most interesting part is explain plan watch again the 5% rule.
    Why the difference?

    I think that with bind peeking out, explain the plan and the implementation plan should show the same things.
    (Assuming that all values of the environment are identical)
    Am I wrong?

    It's the long story to tell, but simple test cases will show what I mean.
    UKJA@ukja102> @version
    
    BANNER
    ---------------------------------------------------------------------
    ---------------------------------------------------------------------
    Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod
    PL/SQL Release 10.2.0.1.0 - Production
    CORE    10.2.0.1.0      Production
    TNS for 32-bit Windows: Version 10.2.0.1.0 - Production
    NLSRTL Version 10.2.0.1.0 - Production
    
    UKJA@ukja102>
    UKJA@ukja102> set echo on
    UKJA@ukja102>
    UKJA@ukja102> drop table t1 purge;
    
    Table dropped.
    
    Elapsed: 00:00:00.09
    UKJA@ukja102>
    UKJA@ukja102> create table t1(c1 int, c2 int)
      2  ;
    
    Table created.
    
    Elapsed: 00:00:00.01
    UKJA@ukja102>
    UKJA@ukja102> insert into t1
      2  select 1, level
      3  from dual
      4  connect by level <= 10000
      5  union all
      6  select 2, level
      7  from dual
      8  connect by level <= 1000
      9  union all
     10  select 3, level
     11  from dual
     12  connect by level <= 100
     13  union all
     14  select 4, level
     15  from dual
     16  connect by level <= 10
     17  union all
     18  select 5, level
     19  from dual
     20  connect by level <= 1
     21  ;
    
    11111 rows created.
    
    Elapsed: 00:00:00.32
    UKJA@ukja102>
    UKJA@ukja102> exec dbms_stats.gather_table_stats(user, 't1', method_opt=>'for all columns size 1');
    
    PL/SQL procedure successfully completed.
    * Disable bind peeking. *
    UKJA@ukja102>
    UKJA@ukja102> alter session set "_optim_peek_user_binds" = false;
    In the following result, explain the plan following the 5% rule.
    (11111 * 0.05 = 555)
    UKJA@ukja102>
    UKJA@ukja102> explain plan for
      2  select count(*)
      3  from t1
      4  where c1 > :b1
      5  ;
    
    Explained.
    
    Elapsed: 00:00:00.01
    UKJA@ukja102>
    UKJA@ukja102> @plan
    UKJA@ukja102> select * from table(dbms_xplan.display)
      2  /
    
    PLAN_TABLE_OUTPUT                                                              
    --------------------------------------------------------------------------------
    Plan hash value: 3724264953                                                    
                                                                                   
    ---------------------------------------------------------------------------    
    | Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |    
    ---------------------------------------------------------------------------    
    |   0 | SELECT STATEMENT   |      |     1 |     3 |     6   (0)| 00:00:01 |    
    |   1 |  SORT AGGREGATE    |      |     1 |     3 |            |          |    
    |*  2 |   TABLE ACCESS FULL| T1   |   556 |  1668 |     6   (0)| 00:00:01 |    
    ---------------------------------------------------------------------------    
                                                                                   
    Predicate Information (identified by operation id):                            
    ---------------------------------------------------                            
                                                                                   
       2 - filter("C1">TO_NUMBER(:B1))                                             
    
    14 rows selected.
    
    Elapsed: 00:00:00.01
    But the term plan does'nt follow the 5% rule. It uses its own density
    (11111 * density (c1) = 11111 * 0.2 = 2222)
    UKJA@ukja102> select /*+ gather_plan_statistics */
      2    count(*)
      3  from t1
      4  where c1 > :b1
      5  ;
    
      COUNT(*)                                                                     
    ----------                                                                     
          1111                                                                     
    
    Elapsed: 00:00:00.00
    UKJA@ukja102>
    UKJA@ukja102> @stat
    UKJA@ukja102> select * from table
      2  (dbms_xplan.display_cursor(null,null,'allstats cost last'));
    
    PLAN_TABLE_OUTPUT                                                              
    --------------------------------------------------------------------------------
    SQL_ID  0nmqsysmr3ap9, child number 0                                          
    -------------------------------------                                          
    select /*+ gather_plan_statistics */   count(*) from t1 where c1 > :b1         
                                                                                   
    Plan hash value: 3724264953                                                    
                                                                                   
    --------------------------------------------------------------------------------
    ------------------                                                             
                                                                                   
    | Id  | Operation          | Name | Starts | E-Rows | Cost (%CPU)| A-Rows |   A-
    Time   | Buffers |                                                             
                                                                                   
    --------------------------------------------------------------------------------
    ------------------                                                             
                                                                                   
    |   1 |  SORT AGGREGATE    |      |      1 |      1 |            |      1 |00:00
    :00.01 |      23 |                                                             
                                                                                   
    |*  2 |   TABLE ACCESS FULL| T1   |      1 |   2223 |     6   (0)|   1111 |00:00
    :00.01 |      23 |                                                             
                                                                                   
    --------------------------------------------------------------------------------
    ------------------                                                             
                                                                                   
                                                                                   
    Predicate Information (identified by operation id):                            
    ---------------------------------------------------                            
                                                                                   
       2 - filter("C1">:B1)                                                        
                                                                                   
    
    18 rows selected.
    the 5% rule seems to be
    -applied to explain the plan always
    -applied at the level of enforcement only when density 5 < %. When the density > 5%, he uses the density not 5%

    I'm not sure it's a designed feature or a bug.
    But estimates of different cardinality explain a plan and DURATION (with bind peeking out voltage) is not that desirable thing.


    One's opinion on this?

    Dion Cho

    Sorry to take some time to get back on this one.

    I can reproduce your results in 10.2.0.1, but the anomaly is not present in 9.2.0.8 and 10.2.0.3 and 11.1.0.6.
    As Charles, the calculation has a boundary condition when a num_diistinct falls below 20
    (i.e. when a value is more than 5% of the total data set - average).

    However, the fact that explain the plan and the run time you give estimates of different cardinality is a bug.
    Everything they say, they should say the same thing at least that the introduction of the variable binding
    introduced a possible type conversion or the NLS conversion feature that has changed the
    calculation of the expected cardinality. In this case there is no reason why the use of links should be
    cause confusion - so we can reasonably assume that it is a bug.

    Concerning
    Jonathan Lewis
    http://jonathanlewis.WordPress.com
    http://www.jlcomp.demon.co.UK

    "The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge." (Stephen Hawking)

  • DEA before constructing an execution plan in DAC

    Guys,

    can someone help me what are the settings to do before building a performance indicator in CAD based on a new map?

    I see that we need to provide some information configuartion for mappings on the Design tab.

    I see below in the Design tab.
    -Areas
    -Tables
    -Indices
    -Working groups
    -Tasks
    -Tags configuration
    -source system parametrs
    -source of the system folders.

    What is the order in which you must complete the above. Can you explain the steps in detail?

    Thank you
    SK.

    Hello
    Check here... http://download.oracle.com/docs/cd/E12513_01/doc/bic.101/e12652/dacexecutionplans.htm
    Execution of DAC building plan crashes and does not complete
    http://obieetips.blogspot.com/2009/06/DAC-custom-execution-plan-steps.html

    Kind regards
    Srikanth

  • Implementation plan: what does it mean "2 - access("DEPARTMENT_ID"=:B1)"?

    Hello

    I'm looking on the execution plan for a query that doesn't use bind variable or a predicate that uses a literal, and yet what follows
       2 - access("DEPARTMENT_ID"=:B1)
    lands in the execution plan, which suggests a variable binding (or maybe just a variable... I don't know). Can anyone tell me please what this line means? What is ": B1?" The complete plan is below.
    Thank you very much
    Jason
    2DAYPLUS@ORCL> l
      1  SELECT d.DEPARTMENT_ID,
      2      d.DEPARTMENT_NAME,
      3      (select count(*)from oehr_employees where department_id = d.department_id)  "Number of Employees",
      4      substr(e.first_name,1,1)||'.'||e.last_name "Manager Name",
      5      c.COUNTRY_NAME "Location"
      6  FROM OEHR_DEPARTMENTS d,
      7     OEHR_EMPLOYEES e,
      8     OEHR_LOCATIONS l,
      9     OEHR_COUNTRIES c
     10  WHERE d.LOCATION_ID=l.LOCATION_ID
     11      AND l.COUNTRY_ID=c.COUNTRY_ID
     12      AND d.DEPARTMENT_ID=e.department_id
     13*     AND d.manager_id=e.employee_id
    2DAYPLUS@ORCL> set autotrace traceonly
    2DAYPLUS@ORCL> /
    
    11 rows selected.
    
    
    Execution Plan
    ----------------------------------------------------------
    Plan hash value: 1307235721
    
    ----------------------------------------------------------------------------------------------------------
    | Id  | Operation                       | Name                   | Rows  | Bytes | Cost (%CPU)| Time  |
    ----------------------------------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT                |                        |    27 |  4077 |     2   (0)| 00:00:01 |
    |   1 |  SORT AGGREGATE                 |                        |     1 |    13 |            |       |
    |*  2 |   INDEX RANGE SCAN              | OEHR_EMP_DEPARTMENT_IX |     1 |    13 |     1   (0)| 00:00:01 |
    |   3 |  NESTED LOOPS                   |                        |       |       |            |       |
    |   4 |   NESTED LOOPS                  |                        |    27 |  4077 |     2   (0)| 00:00:01 |
    |   5 |    NESTED LOOPS                 |                        |    27 |  2673 |     2   (0)| 00:00:01 |
    |   6 |     NESTED LOOPS                |                        |    23 |   989 |     2   (0)| 00:00:01 |
    |   7 |      INDEX FAST FULL SCAN       | OEHR_COUNTRY_C_ID_PK   |    25 |   650 |     2   (0)| 00:00:01 |
    |   8 |      TABLE ACCESS BY INDEX ROWID| OEHR_LOCATIONS         |     1 |    17 |     0   (0)| 00:00:01 |
    |*  9 |       INDEX RANGE SCAN          | OEHR_LOC_COUNTRY_IX    |     1 |       |     0   (0)| 00:00:01 |
    |  10 |     TABLE ACCESS BY INDEX ROWID | OEHR_DEPARTMENTS       |     1 |    56 |     0   (0)| 00:00:01 |
    |* 11 |      INDEX RANGE SCAN           | OEHR_DEPT_LOCATION_IX  |     4 |       |     0   (0)| 00:00:01 |
    |* 12 |    INDEX RANGE SCAN             | OEHR_EMP_DEPARTMENT_IX |     8 |       |     0   (0)| 00:00:01 |
    |* 13 |   TABLE ACCESS BY INDEX ROWID   | OEHR_EMPLOYEES         |     1 |    52 |     0   (0)| 00:00:01 |
    ----------------------------------------------------------------------------------------------------------
    
    Predicate Information (identified by operation id):
    ---------------------------------------------------
    
       2 - access("DEPARTMENT_ID"=:B1)
       9 - access("L"."COUNTRY_ID"="C"."COUNTRY_ID")
      11 - access("D"."LOCATION_ID"="L"."LOCATION_ID")
      12 - access("D"."DEPARTMENT_ID"="E"."DEPARTMENT_ID")
      13 - filter("D"."MANAGER_ID"="E"."EMPLOYEE_ID")
    
    Note
    -----
       - dynamic sampling used for this statement (level=2)
    
    
    Statistics
    ----------------------------------------------------------
              0  recursive calls
              0  db block gets
             33  consistent gets
              0  physical reads
              0  redo size
           1265  bytes sent via SQL*Net to client
            520  bytes received via SQL*Net from client
              2  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
             11  rows processed
    
    2DAYPLUS@ORCL>

    I'm looking on the execution plan for a query that doesn't use bind variable or a predicate that uses a literal, and yet what follows

    2 - access("DEPARTMENT_ID"=:B1)
    

    It is the access to the scalar subquery predicate correlated in the SELECT clause:

     (select count(*)from oehr_employees where department_id = d.department_id)
    

    In this case, Oracle cannot merge the subquery in the main query, so it runs for each row in the result set by forcing the department_id against the main request:

    select count(*) from oehr_employees where department_id = :B1
    
  • Compare the implementation plans for SELECT and DELETE

    Hello

    Version: 10.2.0.3

    I REMOVE slow running in the Production db. I can't import and data, or run the REMOVE to get the Plan. For now, I managed to get the history of the plan.

    However I would like to know if it is reasonable to assume the plans to SELECT and DELETE the same?

    Rgds,
    Guenoun

    Gugui wrote:
    Hello

    Version: 10.2.0.3

    I REMOVE slow running in the Production db. I can't import and data, or run the REMOVE to get the Plan. For now, I managed to get the history of the plan.

    However I would like to know if it is reasonable to assume the plans to SELECT and DELETE the same?

    Rgds,
    Guenoun

    Do not understand your question.
    Because I can very easy do a:

    explain plan for
    remove from... where...;

    And then take a look at the plan generated in the PLAN_TABLE.

    However, I guess that plans for a DELETE and a SELECT statement must be the same, because they need to finish work on the same data, in any case...
    A simple test showed that I'm right.

       PLAN_ID OPERATION                      OPTIONS              OBJECT_TYPE                          COST CARDINALITY      BYTES
    ---------- ------------------------------ -------------------- ------------------------------ ---------- ----------- ----------
             3 DELETE STATEMENT                                                                       177714     7702839
             3 DELETE
             3 TABLE ACCESS                   FULL                 TABLE                              177714     7702839
             4 SELECT STATEMENT                                                                       179707     7702839 3928447890
             4 TABLE ACCESS                   FULL                 TABLE                              179707     7702839 3928447890
    
  • Implementation plan: suddenly no information displayed more predicates

    Hello readers of the forum.

    on one of my 10.2.0.4 databases, I suddenly cannot display the main information of an execution plan more.

    I tried with this script, as I have always done:
    ===============
    set timing on;
    set serveroutput off;
    set termout off;
    SELECT /*+ gather_plan_statistics */ table_name from user_tables;
    set termout on;
    select * from table(dbms_xplan.display_cursor(null,null,'COST IOSTATS LAST'));
    ===============
    Unfortunately, the result is:
    SQL_ID  cjgkchwa4vpnm, child number 0                                                                                            
    -------------------------------------                                                                                            
    SELECT /*+ gather_plan_statistics */ table_name from user_tables                                                                 
                                                                                                                                     
    Plan hash value: 4190597607                                                                                                      
                                                                                                                                     
    -------------------------------------------------------------------------------------------------------------------------------- 
    | Id  | Operation                           | Name     | Starts | E-Rows | Cost (%CPU)| A-Rows |   A-Time   | Buffers | Reads  | 
    -------------------------------------------------------------------------------------------------------------------------------- 
    |   1 |  HASH JOIN RIGHT OUTER              |          |      1 |   1147 |  3172   (1)|     99 |00:00:00.20 |   12197 |    367 | 
    |   2 |   TABLE ACCESS FULL                 | USER$    |      1 |    123 |     3   (0)|    123 |00:00:00.01 |       9 |      0 | 
    |   3 |   HASH JOIN OUTER                   |          |      1 |   1147 |  3169   (1)|     99 |00:00:00.20 |   12188 |    367 | 
    |   4 |    NESTED LOOPS OUTER               |          |      1 |   1147 |  2241   (1)|     99 |00:00:00.15 |    7970 |    367 | 
    |   5 |     HASH JOIN OUTER                 |          |      1 |   1147 |  2241   (1)|     99 |00:00:00.15 |    7970 |    367 | 
    |   6 |      HASH JOIN                      |          |      1 |   1147 |   761   (1)|     99 |00:00:00.05 |    1231 |     15 | 
    |   7 |       TABLE ACCESS FULL             | TS$      |      1 |     25 |     8   (0)|     25 |00:00:00.01 |      31 |      0 | 
    |   8 |       NESTED LOOPS                  |          |      1 |   1147 |   753   (1)|     99 |00:00:00.05 |    1200 |     15 | 
    |   9 |        MERGE JOIN CARTESIAN         |          |      1 |   1147 |   634   (1)|    656 |00:00:00.04 |     299 |      0 | 
    |  10 |         HASH JOIN                   |          |      1 |      1 |     1 (100)|      1 |00:00:00.04 |       0 |      0 | 
    |  11 |          FIXED TABLE FULL           | X$KSPPI  |      1 |      1 |     0   (0)|      1 |00:00:00.01 |       0 |      0 | 
    |  12 |          FIXED TABLE FULL           | X$KSPPCV |      1 |    100 |     0   (0)|   1495 |00:00:00.01 |       0 |      0 | 
    |  13 |         BUFFER SORT                 |          |      1 |   1147 |   634   (1)|    656 |00:00:00.01 |     299 |      0 | 
    |  14 |          TABLE ACCESS BY INDEX ROWID| OBJ$     |      1 |   1147 |   633   (0)|    656 |00:00:00.01 |     299 |      0 | 
    |  15 |           INDEX RANGE SCAN          | I_OBJ2   |      1 |   1147 |    11   (0)|    656 |00:00:00.01 |      12 |      0 | 
    |  16 |        TABLE ACCESS CLUSTER         | TAB$     |    656 |      1 |     1   (0)|     99 |00:00:00.01 |     901 |     15 | 
    |  17 |         INDEX UNIQUE SCAN           | I_OBJ#   |    656 |      1 |     0   (0)|    206 |00:00:00.01 |     658 |      0 | 
    |  18 |      TABLE ACCESS FULL              | SEG$     |      1 |  32975 |  1479   (1)|  32527 |00:00:00.03 |    6739 |    352 | 
    |  19 |     INDEX UNIQUE SCAN               | I_OBJ1   |     99 |      1 |     0   (0)|      0 |00:00:00.01 |       0 |      0 | 
    |  20 |    TABLE ACCESS FULL                | OBJ$     |      1 |  91731 |   927   (1)|  91727 |00:00:00.01 |    4218 |      0 | 
    -------------------------------------------------------------------------------------------------------------------------------- 
    As you can see, no leaders of the asterisks that follow any don't predicate infromation.

    On all other machines (this version and later), the result looks like:
    SQL_ID  cjgkchwa4vpnm, child number 0                            
    -------------------------------------                            
    SELECT /*+ gather_plan_statistics */ table_name from user_tables 
                                                                     
    Plan hash value: 2241718361                                      
    
    --------------------------------------------------------------------------------------------------------------  
    | Id  | Operation                  | Name     | Starts | E-Rows | Cost (%CPU)| A-Rows |   A-Time   | Buffers |  
    --------------------------------------------------------------------------------------------------------------  
    |*  1 |  HASH JOIN RIGHT OUTER     |          |      1 |   1129 |   284   (5)|    233 |00:00:00.05 |    3816 |  
    |   2 |   TABLE ACCESS FULL        | USER$    |      1 |     41 |     2   (0)|     41 |00:00:00.01 |       5 |  
    |*  3 |   HASH JOIN OUTER          |          |      1 |   1129 |   281   (5)|    233 |00:00:00.05 |    3811 |  
    |   4 |    NESTED LOOPS OUTER      |          |      1 |   1129 |   230   (5)|    233 |00:00:00.04 |    3614 |  
    |*  5 |     HASH JOIN RIGHT OUTER  |          |      1 |   1129 |   230   (5)|    233 |00:00:00.04 |    3614 |  
    |   6 |      TABLE ACCESS FULL     | SEG$     |      1 |   4723 |    37   (3)|   4723 |00:00:00.01 |     146 |  
    |*  7 |      HASH JOIN             |          |      1 |   1129 |   192   (5)|    233 |00:00:00.03 |    3468 |  
    |   8 |       TABLE ACCESS FULL    | TS$      |      1 |     16 |     7   (0)|     16 |00:00:00.01 |      23 |  
    |   9 |       NESTED LOOPS         |          |      1 |   1129 |   185   (5)|    233 |00:00:00.02 |    3445 |  
    |  10 |        MERGE JOIN CARTESIAN|          |      1 |   1129 |    54  (12)|   1950 |00:00:00.01 |     196 |  
    |* 11 |         HASH JOIN          |          |      1 |      1 |     1 (100)|      1 |00:00:00.01 |       0 |  
    |* 12 |          FIXED TABLE FULL  | X$KSPPI  |      1 |      1 |     0   (0)|      1 |00:00:00.01 |       0 |  
    |  13 |          FIXED TABLE FULL  | X$KSPPCV |      1 |    100 |     0   (0)|   1495 |00:00:00.01 |       0 |  
    |  14 |         BUFFER SORT        |          |      1 |   1129 |    54  (12)|   1950 |00:00:00.01 |     196 |  
    |* 15 |          TABLE ACCESS FULL | OBJ$     |      1 |   1129 |    53  (10)|   1950 |00:00:00.01 |     196 |  
    |* 16 |        TABLE ACCESS CLUSTER| TAB$     |   1950 |      1 |     1   (0)|    233 |00:00:00.01 |    3249 |  
    |* 17 |         INDEX UNIQUE SCAN  | I_OBJ#   |   1950 |      1 |     0   (0)|    763 |00:00:00.01 |    1952 |  
    |* 18 |     INDEX UNIQUE SCAN      | I_OBJ1   |    233 |      1 |     0   (0)|      0 |00:00:00.01 |       0 |  
    |  19 |    TABLE ACCESS FULL       | OBJ$     |      1 |  14712 |    50   (4)|  14855 |00:00:00.01 |     197 |  
    --------------------------------------------------------------------------------------------------------------  
                                                                                                                    
    Predicate Information (identified by operation id):                                                             
    ---------------------------------------------------                                                             
                                                                                                                    
       1 - access("CX"."OWNER#"="CU"."USER#")                                                                       
       3 - access("T"."DATAOBJ#"="CX"."OBJ#")                                                                       
       5 - access("T"."FILE#"="S"."FILE#" AND "T"."BLOCK#"="S"."BLOCK#" AND "T"."TS#"="S"."TS#")                    
       7 - access("T"."TS#"="TS"."TS#")                                                                             
      11 - access("KSPPI"."INDX"="KSPPCV"."INDX")                                                                   
      12 - filter("KSPPI"."KSPPINM"='_dml_monitoring_enabled')                                                      
      15 - filter(("O"."OWNER#"=USERENV('SCHEMAID') AND BITAND("O"."FLAGS",128)=0))                                 
      16 - filter(BITAND("T"."PROPERTY",1)=0)                                                                       
      17 - access("O"."OBJ#"="T"."OBJ#")                                                                            
      18 - access("T"."BOBJ#"="CO"."OBJ#")                                                                          
    .. that is what I want.

    So my question:
    What affects the fact if the predicate information are displayed or not? The client is the same twice (tried with native SQL * more and Developer SQL 1.5.5).)

    Any idea is appreciated, thanks in advance!
    Martin Klier

    MartinKlier wrote:
    Thanks for your response: they are empty!

    CN  ID ACCESS_PREDICATES              FILTER_PREDICATES
    --- --- ------------------------------ ------------------------------
    0   1
    0   2
    ...
    1  20
    

    Best regards
    Martin

    Interesting.

    I see that Dominic Brooks gave you a suggestion on Oracle-L. try this script that uses his suggestion:

    SPOOL OUTPUT.TXT
    ALTER SYSTEM FLUSH SHARED_POOL;
    ALTER SESSION SET "_cursor_plan_unparse_enabled"=FALSE;
    
    SELECT /*+ gather_plan_statistics */ table_name from user_tables;
    
    select * from table(dbms_xplan.display_cursor(null,null,'COST IOSTATS LAST'));
    
    COLUMN ACCESS_PREDICATES FORMAT A30
    COLUMN FILTER_PREDICATES FORMAT A30
    COLUMN ID FORMAT 99
    COLUMN CN FORMAT 99
    
    SELECT
      CHILD_NUMBER CN,
      ID,
      ACCESS_PREDICATES,
      FILTER_PREDICATES
    FROM
      V$SQL_PLAN_STATISTICS_ALL
    WHERE
      SQL_ID='cjgkchwa4vpnm'
    ORDER BY
      CHILD_NUMBER,
      ID;
    
    ALTER SESSION SET "_cursor_plan_unparse_enabled"=TRUE;
    
    SELECT /*+ gather_plan_statistics */ table_name from user_tables;
    
    select * from table(dbms_xplan.display_cursor(null,null,'COST IOSTATS LAST'));
    
    SELECT
      CHILD_NUMBER CN,
      ID,
      ACCESS_PREDICATES,
      FILTER_PREDICATES
    FROM
      V$SQL_PLAN_STATISTICS_ALL
    WHERE
      SQL_ID='cjgkchwa4vpnm'
    ORDER BY
      CHILD_NUMBER,
      ID;
    
    SPOOL OFF
    

    I see the following:

    ...
    SQL> ALTER SESSION SET "_cursor_plan_unparse_enabled"=FALSE;
    ...
    SQL_ID  cjgkchwa4vpnm, child number 0
    -------------------------------------
    SELECT /*+ gather_plan_statistics */ table_name from user_tables                  
    
    Plan hash value: 2718527396                          
    
    --------------------------------------------------------------------------------------------------------------
    | Id  | Operation                  | Name     | Starts | E-Rows | Cost (%CPU)| A-Rows |   A-Time   | Buffers |
    --------------------------------------------------------------------------------------------------------------
    |   1 |  HASH JOIN                 |          |      1 |   1441 |    88  (12)|    395 |00:00:00.05 |    1475 |
    |   2 |   TABLE ACCESS FULL        | TS$      |      1 |     11 |     2   (0)|     11 |00:00:00.01 |      15 |
    |   3 |   HASH JOIN RIGHT OUTER    |          |      1 |   1441 |    85  (11)|    395 |00:00:00.05 |    1460 |
    |   4 |    TABLE ACCESS FULL       | SEG$     |      1 |   5301 |     9   (0)|   5303 |00:00:00.01 |     156 |
    |   5 |    HASH JOIN RIGHT OUTER   |          |      1 |   1441 |    75  (11)|    395 |00:00:00.04 |    1304 |
    |   6 |     TABLE ACCESS FULL      | USER$    |      1 |    154 |     2   (0)|    154 |00:00:00.01 |      15 |
    |   7 |     NESTED LOOPS OUTER     |          |      1 |   1441 |    73  (11)|    395 |00:00:00.03 |    1289 |
    |   8 |      HASH JOIN OUTER       |          |      1 |   1441 |    73  (11)|    395 |00:00:00.04 |    1289 |
    |   9 |       HASH JOIN            |          |      1 |   1441 |    61  (10)|    395 |00:00:00.02 |    1078 |
    |  10 |        TABLE ACCESS FULL   | TAB$     |      1 |   2245 |    46   (3)|   2246 |00:00:00.01 |     892 |
    |  11 |        MERGE JOIN CARTESIAN|          |      1 |   1441 |    14  (29)|    986 |00:00:00.01 |     186 |
    |  12 |         HASH JOIN          |          |      1 |      1 |     2 (100)|      1 |00:00:00.01 |       0 |
    |  13 |          FIXED TABLE FULL  | X$KSPPI  |      1 |      1 |     1 (100)|      1 |00:00:00.01 |       0 |
    |  14 |          FIXED TABLE FULL  | X$KSPPCV |      1 |   1410 |     1 (100)|   1410 |00:00:00.01 |       0 |
    |  15 |         BUFFER SORT        |          |      1 |   1441 |    13  (24)|    986 |00:00:00.01 |     186 |
    |  16 |          TABLE ACCESS FULL | OBJ$     |      1 |   1441 |    12  (17)|    986 |00:00:00.01 |     186 |
    |  17 |       TABLE ACCESS FULL    | OBJ$     |      1 |  15853 |    11  (10)|  15855 |00:00:00.01 |     211 |
    |  18 |      INDEX UNIQUE SCAN     | I_OBJ1   |    395 |      1 |     0   (0)|      0 |00:00:00.01 |       0 |
    --------------------------------------------------------------------------------------------------------------
    ...
     CN  ID ACCESS_PREDICATES              FILTER_PREDICATES
    --- --- ------------------------------ ------------------------------
      0   1
      0   2
      0   3
      0   4
      0   5
      0   6
      0   7
      0   8
      0   9
      0  10
      0  11
      0  12
      0  13
      0  14
      0  15
      0  16
      0  17
      0  18
    ...
    SQL> ALTER SESSION SET "_cursor_plan_unparse_enabled"=TRUE;
    ...
    SQL_ID  cjgkchwa4vpnm, child number 0
    -------------------------------------
    SELECT /*+ gather_plan_statistics */ table_name from user_tables                  
    
    Plan hash value: 2718527396                          
    
    --------------------------------------------------------------------------------------------------------------
    | Id  | Operation                  | Name     | Starts | E-Rows | Cost (%CPU)| A-Rows |   A-Time   | Buffers |
    --------------------------------------------------------------------------------------------------------------
    |*  1 |  HASH JOIN                 |          |      1 |   1441 |    88  (12)|    395 |00:00:00.05 |    1475 |
    |   2 |   TABLE ACCESS FULL        | TS$      |      1 |     11 |     2   (0)|     11 |00:00:00.01 |      15 |
    |*  3 |   HASH JOIN RIGHT OUTER    |          |      1 |   1441 |    85  (11)|    395 |00:00:00.05 |    1460 |
    |   4 |    TABLE ACCESS FULL       | SEG$     |      1 |   5301 |     9   (0)|   5303 |00:00:00.01 |     156 |
    |*  5 |    HASH JOIN RIGHT OUTER   |          |      1 |   1441 |    75  (11)|    395 |00:00:00.04 |    1304 |
    |   6 |     TABLE ACCESS FULL      | USER$    |      1 |    154 |     2   (0)|    154 |00:00:00.01 |      15 |
    |   7 |     NESTED LOOPS OUTER     |          |      1 |   1441 |    73  (11)|    395 |00:00:00.03 |    1289 |
    |*  8 |      HASH JOIN OUTER       |          |      1 |   1441 |    73  (11)|    395 |00:00:00.04 |    1289 |
    |*  9 |       HASH JOIN            |          |      1 |   1441 |    61  (10)|    395 |00:00:00.02 |    1078 |
    |* 10 |        TABLE ACCESS FULL   | TAB$     |      1 |   2245 |    46   (3)|   2246 |00:00:00.01 |     892 |
    |  11 |        MERGE JOIN CARTESIAN|          |      1 |   1441 |    14  (29)|    986 |00:00:00.01 |     186 |
    |* 12 |         HASH JOIN          |          |      1 |      1 |     2 (100)|      1 |00:00:00.01 |       0 |
    |* 13 |          FIXED TABLE FULL  | X$KSPPI  |      1 |      1 |     1 (100)|      1 |00:00:00.01 |       0 |
    |  14 |          FIXED TABLE FULL  | X$KSPPCV |      1 |   1410 |     1 (100)|   1410 |00:00:00.01 |       0 |
    |  15 |         BUFFER SORT        |          |      1 |   1441 |    13  (24)|    986 |00:00:00.01 |     186 |
    |* 16 |          TABLE ACCESS FULL | OBJ$     |      1 |   1441 |    12  (17)|    986 |00:00:00.01 |     186 |
    |  17 |       TABLE ACCESS FULL    | OBJ$     |      1 |  15853 |    11  (10)|  15855 |00:00:00.01 |     211 |
    |* 18 |      INDEX UNIQUE SCAN     | I_OBJ1   |    395 |      1 |     0   (0)|      0 |00:00:00.01 |       0 |
    -------------------------------------------------------------------------------------------------------------- 
    
    Predicate Information (identified by operation id):
    ---------------------------------------------------
       1 - access("T"."TS#"="TS"."TS#")
       3 - access("T"."FILE#"="S"."FILE#" AND "T"."BLOCK#"="S"."BLOCK#" AND "T"."TS#"="S"."TS#")
       5 - access("CX"."OWNER#"="CU"."USER#")
       8 - access("T"."DATAOBJ#"="CX"."OBJ#")
       9 - access("O"."OBJ#"="T"."OBJ#")
      10 - filter(BITAND("T"."PROPERTY",1)=0)
      12 - access("KSPPI"."INDX"="KSPPCV"."INDX")
      13 - filter("KSPPI"."KSPPINM"='_dml_monitoring_enabled')
      16 - filter(("O"."OWNER#"=USERENV('SCHEMAID') AND BITAND("O"."FLAGS",128)=0))
      18 - access("T"."BOBJ#"="CO"."OBJ#")
    ...
     CN  ID ACCESS_PREDICATES              FILTER_PREDICATES
    --- --- ------------------------------ ------------------------------
      0   1 "T"."TS#"="TS"."TS#"
      0   2
      0   3 "T"."FILE#"="S"."FILE#" AND "T
            "."BLOCK#"="S"."BLOCK#" AND "T
            "."TS#"="S"."TS#"
    
      0   4
      0   5 "CX"."OWNER#"="CU"."USER#"
      0   6
      0   7
      0   8 "T"."DATAOBJ#"="CX"."OBJ#"
      0   9 "O"."OBJ#"="T"."OBJ#"
      0  10   BITAND("T"."PROPERTY",1)=0
      0  11
      0  12 "KSPPI"."INDX"="KSPPCV"."INDX"
      0  13   "KSPPI"."KSPPINM"='_dml_monito
              ring_enabled'                              
    
      0  14
      0  15
      0  16   ("O"."OWNER#"=USERENV('SCHEMAI
              D') AND BITAND("O"."FLAGS",128
              )=0)          
    
      0  17
      0  18 "T"."BOBJ#"="CO"."OBJ#" 
    

    Charles Hooper
    Co-author of "Expert Oracle practices: Oracle Database Administration of the Oak Table.
    http://hoopercharles.WordPress.com/
    IT Manager/Oracle DBA
    K & M-making Machine, Inc.

  • Plan implementation is the next DAC but in Informatica error

    Hi all
    can someone help me with this problem
    I'm runining a plan of execution by DAC status is successful, but informatica, I get an error.
    The error message:
    TM_6193 error has occurred during the expansion of DB connection settings

    TM_6193 error has occurred during the expansion of DB connection settings

    Hello

    Could you describe the problem a little bit?
    If you run it with DAC, not the loaded data?
    Maps of how much do you have in your implementation Plan?

    In a first time - check the relational connections in Informatica Workflow Manager. They should be identical to your physical data source connections in DAC.

    It could be that useful...

  • What the implementation of plans to choose for 7.9.6.4 BIApps and EBS 12.1.3?

    Hi gurus,

    We have installed OBI 11.1.1.7.0 with biapps 7.9.6.4 (vanilla imported metadata and integration work DAC/Informatica) successfully. We are approved for these modules:

    • Purchases and spend analytics Fusion Edition
    • Human resources Analytics Fusion Edition
    • Supply chain and order Analytics Fusion edition management
    • Edition of Fusion financial analytics

    The source system is EBS 12.1.3

    We want to start testing some of the ETLs DAC, but we don't know which ones to choose from a long list of execution plans. Can someone provide links to the documentation or other sources of knowledge that explain that DAC implementation plans correspond to what above Application modules?

    -bidays

    http://bidays.WordPress.com/

    Hello

    By default execution plans will be there... but you need to create a system of source container, after the creation of container assemble these disciplines and create an implementation plan for each module you have four modules... then create four execution plans and produces parameters and build execution plans and run. If you have any doubts means let me know...

    Kind regards

    Naga

  • How can I create custom DAC execution plan

    Hello

    I need to create custom DAC execution plan to load data into tables. in fact schema we build with 2 custom tables Sun, 8 tables OOTB (fact and Sun). So I need to copy the OOTB existing execution plan, delete unwanted tables, stains ect and rebuild. But I do not know the exact process to do could you please provide step by step details?

    We use 10.1.3.4.1 OBIEE, BI Apps 7.9.6.1 and customer DAC is on windows XP.

    Grateful for your help!

    Thank you
    Jay.

    Visit this link...

    DAC-> Execute-> implementation plans-> click New and add your domains, settings, etc. see this link which details

    http://download.Oracle.com/docs/CD/E12104_01/books/DAC/DADesignETL16.html

  • execution of multiple DAC running plan, is this posible?

    Hi guru BI

    is it possible to run several implementation plan in the same container?

    or if we have several containers for kids free HR and finance, in this case the execution plan will be executed in each separate containers?
    What are the impacts on the DAC Server?

    Kind regards
    Kamlesh

    We can create multiple execution plans in a single container.
    But it can be scheduled one after the other don't.

Maybe you are looking for