Filter Predicate information

Hi,
Below is the execution plan for one long running query. I would like to get one information clear from any of you.
ID 7 returns 1145 rows as per plan.
I ran the 7th operation manually ( 7 - access("FCT"."CND_KEY"=1 AND "FCT"."MRKT_KEY"="MKT"."MRKT_KEY")
filter("FCT"."MRKT_KEY"=2 OR "FCT"."MRKT_KEY"=14 OR "FCT"."MRKT_KEY"=23 OR "FCT"."MRKT_KEY"=47 OR "FCT"."MRKT_KEY"=61))
it returns only very less rows, should it return 1145 rows? Please let me know why this is?
| 0 | SELECT STATEMENT | | 3 | 255 | 85 (0)| | | |
| |
| 1 | NESTED LOOPS | | 3 | 255 | 85 (0)| | | 87,00 | P
->S | QC (RAND) |
| 2 | NESTED LOOPS | | 1331 | 91839 | 68 (0)| | | 87,00 | P
CWP | |
|* 3 | TABLE ACCESS FULL | MKTTAB | 2 | 26 | 5 (0)| | | 87,00 | P
CWP | |
| 4 | PARTITION RANGE INLIST | | | | |KEY(I) |KEY(I) | 87,00 | P
CWP | |
| 5 | PARTITION LIST ITERATOR | | | | | KEY | KEY | 87,00 | P
CWP | |
|* 6 | TABLE ACCESS BY LOCAL INDEX ROWID| CONDFCT | 532 | 29792 | 17 (6)|KEY(I) |KEY(I) | 87,00 | P
CWP | |
|* 7 | INDEX RANGE SCAN | IDX_CONDFCT_CND_MRKT_PRDC | 1145 | | 56 (2)|KEY(I) |KEY(I) | 87,00 | P
CWP | |
|* 8 | TABLE ACCESS BY INDEX ROWID | PRODTAB | 1 | 16 | 2 (50)| | | 87,00 | P
CWP | |
|* 9 | INDEX UNIQUE SCAN | INX_PRODTAB_PK | 1 | | | | | 87,00 | P
CWP | |
Predicate Information (identified by operation id):
3 - filter("MKT"."MRKT_KEY"=2 OR "MKT"."MRKT_KEY"=14 OR "MKT"."MRKT_KEY"=23 OR "MKT"."MRKT_KEY"=47 OR "MKT"."MRKT_KEY"=61)
6 - filter(("FCT"."PRD_KEY"=2006010701 OR "FCT"."PRD_KEY"=2006011401 OR "FCT"."PRD_KEY"=2006012101 OR "FCT"."PRD_KEY"=2006012801
OR
"FCT"."PRD_KEY"=2006020401 OR "FCT"."PRD_KEY"=2006021101 OR "FCT"."PRD_KEY"=2006021801 OR "FCT"."PRD_KEY"=2006022501 O
R "FCT"."PRD_KEY"=2006030401 OR
"FCT"."PRD_KEY"=2006031101 OR "FCT"."PRD_KEY"=2006031801 OR "FCT"."PRD_KEY"=2006032501 OR "FCT"."PRD_KEY"=2006040101 O
R "FCT"."PRD_KEY"=2006040801 OR
"FCT"."PRD_KEY"=2006041501 OR "FCT"."PRD_KEY"=2006042201 OR "FCT"."PRD_KEY"=2006042901 OR "FCT"."PRD_KEY"=2006050601 O
R "FCT"."PRD_KEY"=2006051301 OR
"FCT"."PRD_KEY"=2006052001 OR "FCT"."PRD_KEY"=2006052701 OR "FCT"."PRD_KEY"=2006060301 OR "FCT"."PRD_KEY"=2006061001 O
R "FCT"."PRD_KEY"=2006061701 OR
"FCT"."PRD_KEY"=2006062401 OR "FCT"."PRD_KEY"=2006070101 OR "FCT"."PRD_KEY"=2006070801 OR "FCT"."PRD_KEY"=2006071501 O
R "FCT"."PRD_KEY"=2006072201 OR
"FCT"."PRD_KEY"=2006072901 OR "FCT"."PRD_KEY"=2006080501 OR "FCT"."PRD_KEY"=2007010601 OR "FCT"."PRD_KEY"=2007011301 O
R "FCT"."PRD_KEY"=2007012001 OR
"FCT"."PRD_KEY"=2007012701 OR "FCT"."PRD_KEY"=2007020301 OR "FCT"."PRD_KEY"=2007021001 OR "FCT"."PRD_KEY"=2007021701 O
R "FCT"."PRD_KEY"=2007022401 OR
"FCT"."PRD_KEY"=2007030301 OR "FCT"."PRD_KEY"=2007031001 OR "FCT"."PRD_KEY"=2007031701 OR "FCT"."PRD_KEY"=2007032401 O
R "FCT"."PRD_KEY"=2007033101 OR
"FCT"."PRD_KEY"=2007040701 OR "FCT"."PRD_KEY"=2007041401 OR "FCT"."PRD_KEY"=2007042101 OR "FCT"."PRD_KEY"=2007042801 O
R "FCT"."PRD_KEY"=2007050501 OR
"FCT"."PRD_KEY"=2007051201 OR "FCT"."PRD_KEY"=2007051901 OR "FCT"."PRD_KEY"=2007052601 OR "FCT"."PRD_KEY"=2007060201 O
R "FCT"."PRD_KEY"=2007060901 OR
"FCT"."PRD_KEY"=2007061601 OR "FCT"."PRD_KEY"=2007062301 OR "FCT"."PRD_KEY"=2007063001 OR "FCT"."PRD_KEY"=2007070701 O
R "FCT"."PRD_KEY"=2007071401 OR
"FCT"."PRD_KEY"=2007072101 OR "FCT"."PRD_KEY"=2007072801 OR "FCT"."PRD_KEY"=2007080401 OR "FCT"."PRD_KEY"=2008010501 O
R "FCT"."PRD_KEY"=2008011201 OR
"FCT"."PRD_KEY"=2008011901 OR "FCT"."PRD_KEY"=2008012601 OR "FCT"."PRD_KEY"=2008020201 OR "FCT"."PRD_KEY"=2008020901 O
R "FCT"."PRD_KEY"=2008021601 OR
"FCT"."PRD_KEY"=2008022301 OR "FCT"."PRD_KEY"=2008030101 OR "FCT"."PRD_KEY"=2008030801 OR "FCT"."PRD_KEY"=2008031501 O
R "FCT"."PRD_KEY"=2008032201 OR
"FCT"."PRD_KEY"=2008032901 OR "FCT"."PRD_KEY"=2008040501 OR "FCT"."PRD_KEY"=2008041201 OR "FCT"."PRD_KEY"=2008041901 O
R "FCT"."PRD_KEY"=2008042601 OR
"FCT"."PRD_KEY"=2008050301 OR "FCT"."PRD_KEY"=2008051001 OR "FCT"."PRD_KEY"=2008051701 OR "FCT"."PRD_KEY"=2008052401 O
R "FCT"."PRD_KEY"=2008053101 OR
"FCT"."PRD_KEY"=2008060701 OR "FCT"."PRD_KEY"=2008061401 OR "FCT"."PRD_KEY"=2008062101 OR "FCT"."PRD_KEY"=2008062801 O
R "FCT"."PRD_KEY"=2008070501 OR
"FCT"."PRD_KEY"=2008071201 OR "FCT"."PRD_KEY"=2008071901 OR "FCT"."PRD_KEY"=2008072601 OR "FCT"."PRD_KEY"=2008080201)
AND
"FCT"."CMPNT_NM"="MKT"."MRKT_SCN_CMPNT_NM")
7 - access("FCT"."CND_KEY"=1 AND "FCT"."MRKT_KEY"="MKT"."MRKT_KEY")
filter("FCT"."MRKT_KEY"=2 OR "FCT"."MRKT_KEY"=14 OR "FCT"."MRKT_KEY"=23 OR "FCT"."MRKT_KEY"=47 OR "FCT"."MRKT_KEY"=61)
8 - filter("PRODTAB"."H2_MANUF" IS NOT NULL AND ("PRODTAB"."H2_MANUF"='P&G' OR "PRODTAB"."H2_MANUF"='PRIVATE LABEL') AND
DECODE("PRODTAB"."DZ02_NM",NULL,'NA',"PRODTAB"."DZ02_NM")='MANUFACTURER' AND "PRODTAB"."H2_PC#"='TOTAL CATEGORY')
9 - access("FCT"."PRDC_KEY"="PRODTAB"."PRDC_KEY")

Hi,
Adding to the damorgan,
In order to Check the Number of Records, you can Debug it (Execute it Part by Part) and you get to know.
As he stated if you got any problems make sure you do, update stats up to date... !!
If you think that number of rows returned in wrong, check the joining Conditions, since some times based on the conditions of joins between the table unncessary rows will be fetching... which make the query performance degraded
- Pavan Kumar N

Similar Messages

  • Index usage for retrieving data  without filter predicate

    Hi,
    does someone have a explanation for the following scenario:
    I have a table T1 with an index OID_IX on column ( object_id ) - The table is a CTAS from dba_objects just to populate it with data.
    There are no other Indexes present. The table and the index are analyzed !
    When I run the following query the table is accessed FULL ( not using the index )
    SELECT OBJECT_ID FROM T1;
    SQL> select object_id from t1;
    485984 rows selected.
    Elapsed: 00:00:01.76
    Execution Plan
    Plan hash value: 3617692013
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 485K| 2372K| 1528 (1)| 00:00:19 |
    | 1 | TABLE ACCESS FULL| T1 | 485K| 2372K| 1528 (1)| 00:00:19 |
    Statistics
    1 recursive calls
    0 db block gets
    7396 consistent gets
    0 physical reads
    0 redo size
    2887158 bytes sent via SQL*Net to client
    5684 bytes received via SQL*Net from client
    487 SQL*Net roundtrips to/from client
    0 sorts (memory)
    0 sorts (disk)
    485984 rows processed
    But if I add a predicate ( even though it is useless in this case ) the index is taken and the query runs faster:
    JDBC@toekb> select object_id from t1 where object_id != -999;
    485960 rows selected.
    Elapsed: 00:00:01.40
    Execution Plan
    Plan hash value: 3555700789
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 485K| 2372K| 242 (3)| 00:00:03 |
    |* 1 | INDEX FAST FULL SCAN| OID_IX | 485K| 2372K| 242 (3)| 00:00:03 |
    Predicate Information (identified by operation id):
    1 - filter("OBJECT_ID"<>(-999))
    Statistics
    1 recursive calls
    0 db block gets
    1571 consistent gets
    0 physical reads
    0 redo size
    2766124 bytes sent via SQL*Net to client
    5684 bytes received via SQL*Net from client
    487 SQL*Net roundtrips to/from client
    0 sorts (memory)
    0 sorts (disk)
    485960 rows processed
    here my setup:
    sqlsql--
    drop table t1 purge ;
    create table t1 tablespace users as select * from dba_objects;
    insert into t1 ( select * from t1);
    commit;
    insert into t1 ( select * from t1);
    commit;
    insert into t1 ( select * from t1);
    commit;
    create index oid_ix on t1 (object_id) tablespace users ;
    exec dbms_stats.gather_table_stats(null,'t1',cascade=>true, estimate_percent=>100);
    sqlsql--
    In my case the Table and Index looks this way:
    JDBC@toekb> select table_name, NUM_ROWS,BLOCKS,AVG_SPACE from user_tables;
    TABLE_NAME NUM_ROWS BLOCKS AVG_SPACE
    =======================================
    T1 485984 6944 0
    Elapsed: 00:00:00.11
    JDBC@toekb> select INDEX_NAME,BLEVEL,LEAF_BLOCKS,DISTINCT_KEYS,NUM_ROWS from user_indexes;
    INDEX_NAME BLEVEL LEAF_BLOCKS DISTINCT_KEYS NUM_ROWS
    ===================================================
    OID_IX 2 1074 60745 485960
    Elapsed: 00:00:00.07
    The table holds 7 times more blocks than the index !
    any reply welcome
    best regards
    Edited by: guenterp on Aug 12, 2010 2:44 PM

    guenterp wrote:
    Hi,
    does someone have a explanation for the following scenario:
    I have a table T1 with an index OID_IX on column ( object_id ) - The table is a CTAS from dba_objects just to populate it with data.
    There are no other Indexes present. The table and the index are analyzed !
    When I run the following query the table is accessed FULL ( not using the index )
    SELECT OBJECT_ID FROM T1;
    SQL> select object_id from t1;
    485984 rows selected.
    Elapsed: 00:00:01.76
    Execution Plan
    Plan hash value: 3617692013
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 485K| 2372K| 1528 (1)| 00:00:19 |
    | 1 | TABLE ACCESS FULL| T1 | 485K| 2372K| 1528 (1)| 00:00:19 |
    Statistics
    1 recursive calls
    0 db block gets
    7396 consistent gets
    0 physical reads
    0 redo size
    2887158 bytes sent via SQL*Net to client
    5684 bytes received via SQL*Net from client
    487 SQL*Net roundtrips to/from client
    0 sorts (memory)
    0 sorts (disk)
    485984 rows processed
    But if I add a predicate ( even though it is useless in this case ) the index is taken and the query runs faster:
    JDBC@toekb> select object_id from t1 where object_id != -999;
    485960 rows selected.
    Elapsed: 00:00:01.40
    Execution Plan
    Plan hash value: 3555700789
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 485K| 2372K| 242 (3)| 00:00:03 |
    |* 1 | INDEX FAST FULL SCAN| OID_IX | 485K| 2372K| 242 (3)| 00:00:03 |
    Predicate Information (identified by operation id):
    1 - filter("OBJECT_ID"<>(-999))
    Statistics
    1 recursive calls
    0 db block gets
    1571 consistent gets
    0 physical reads
    0 redo size
    2766124 bytes sent via SQL*Net to client
    5684 bytes received via SQL*Net from client
    487 SQL*Net roundtrips to/from client
    0 sorts (memory)
    0 sorts (disk)
    485960 rows processed
    here my setup:
    sqlsql--
    drop table t1 purge ;
    create table t1 tablespace users as select * from dba_objects;
    insert into t1 ( select * from t1);
    commit;
    insert into t1 ( select * from t1);
    commit;
    insert into t1 ( select * from t1);
    commit;
    create index oid_ix on t1 (object_id) tablespace users ;
    exec dbms_stats.gather_table_stats(null,'t1',cascade=>true, estimate_percent=>100);
    sqlsql--
    In my case the Table and Index looks this way:
    JDBC@toekb> select table_name, NUM_ROWS,BLOCKS,AVG_SPACE from user_tables;
    TABLE_NAME NUM_ROWS BLOCKS AVG_SPACE
    =======================================
    T1 485984 6944 0
    Elapsed: 00:00:00.11
    JDBC@toekb> select INDEX_NAME,BLEVEL,LEAF_BLOCKS,DISTINCT_KEYS,NUM_ROWS from user_indexes;
    INDEX_NAME BLEVEL LEAF_BLOCKS DISTINCT_KEYS NUM_ROWS
    ===================================================
    OID_IX 2 1074 60745 485960
    Elapsed: 00:00:00.07
    The table holds 7 times more blocks than the index !
    any reply welcome
    best regards
    Edited by: guenterp on Aug 12, 2010 2:44 PMSorry, but I am in doubt with your statists:
    Statistics
    1 recursive calls
    0 db block gets
    7396 consistent gets
    0 physical reads ---->>>>>>>>>>>> Why it is 0 in any case(bnoth full scan and index FFS)
    0 redo size
    2887158 bytes sent via SQL*Net to client
    5684 bytes received via SQL*Net from client
    487 SQL*Net roundtrips to/from client
    0 sorts (memory)
    0 sorts (disk)
    485984 rows processedCould you pls retry below operation before execuion of each sql:
    alter system flush buffer_cache;In my case with 10.2.0.4 on HPUX:
    SQL> exec dbms_stats.gather_table_stats(null,'t1',cascade=>true, estimate_percent=>100);
    PL/SQL procedure successfully completed.
    Elapsed: 00:00:03.61
    SQL> alter system flush buffer_cache;
    System altered.
    Elapsed: 00:00:14.00
    SQL> select * from t1;
    82016 rows selected.
    Elapsed: 00:00:06.48
    Execution Plan
    Plan hash value: 838529891
    | Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT  |      | 82016 |  6888K|   394   (1)| 00:00:05 |
    |   1 |  TABLE ACCESS FULL| T1   | 82016 |  6888K|   394   (1)| 00:00:05 |
    Statistics
              0  recursive calls
              0  db block gets
           6455  consistent gets
           1039  physical reads
              0  redo size
        3480570  bytes sent via SQL*Net to client
          38508  bytes received via SQL*Net from client
           5469  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
          82016  rows processed
    SQL> alter system flush buffer_cache;
    System altered.
    Elapsed: 00:00:18.26
    SQL> select * from t1 where object_id !=999;
    81976 rows selected.
    Elapsed: 00:00:07.09
    Execution Plan
    Plan hash value: 838529891
    | Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT  |      | 81976 |  6884K|   394   (1)| 00:00:05 |
    |*  1 |  TABLE ACCESS FULL| T1   | 81976 |  6884K|   394   (1)| 00:00:05 |
    Predicate Information (identified by operation id):
       1 - filter("OBJECT_ID"<>999)
    Statistics
              0  recursive calls
              0  db block gets
           6443  consistent gets
           1039  physical reads
              0  redo size
        3478961  bytes sent via SQL*Net to client
          38494  bytes received via SQL*Net from client
           5467  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
          81976  rows processed
    SQL>

  • DBMS_XPLAN.DISPLAY - predicate information

    As mentioned in Oracle® Database PL/SQL Packages and Types Reference oracle predicate information is only displayed when applicable.
    Do you konow when it is not applicable .
    First System Which shows predicate information
    SQL> create table ttt (a number);
    Table created.
    SQL> explain plan for select * from ttt where a=333;
    Explained.
    SQL> Select * from table(dbms_xplan.display());
    PLAN_TABLE_OUTPUT
    Plan hash value: 774701505
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 1 | 13 | 2 (0)| 00:00:01 |
    |* 1 | TABLE ACCESS FULL| TTT | 1 | 13 | 2 (0)| 00:00:01 |
    Predicate Information (identified by operation id):
    PLAN_TABLE_OUTPUT
    *1 - filter("A"=333)*
    Second System Which doesn't show predicate information
    SQL> create table ttt (a number);
    Table created.
    SQL> explain plan for select * from ttt where a=333;
    Explained.
    SQL> Select * from table(dbms_xplan.display());
    Plan hash value: 774701505
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 1 | 13 | 2 (0)| 00:00:01 |
    | 1 | TABLE ACCESS FULL| TTT | 1 | 13 | 2 (0)| 00:00:01 |
    Note
    - dynamic sampling used for this statement
    12 rows selected.
    SQL>
    Edited by: user8308823 on 11.Şub.2011 05:42

    Check your value of cursorplan_unparse_enabled
    There have been bugs around access to the predicates column in v$sql_plan in certain
    versions (Metalink ids 2791172,763607.1,3267299)
    One of the recommendations was to alter the
    setting of " _cursor_plan_unparse_enabled"
    E.g.
    ALTER SESSION set "_cursor_plan_unparse_enabled"=FALSE
    which had this effect.
    See also
    Execution plan: Suddenly no predicate information displayed anymore
    Edited by: Dom Brooks on Feb 11, 2011 2:15 PM

  • No Predicate Information showing in typical display

    same sql statement, in other environment, when I display plan with dbms_xplan, it shows predicate information, only in one environment, not showing, even I used ALL option, compared two environment, there is no difference, what is could be possible reason for this? Thanks in advance.

    user8918387 wrote:
    plan_table is not old version.Welcome to the forum.
    That is good to hear that the PLAN_TABLE is the not the old version. If possible, I would like to see a reproducible test case using the following script:
    SET LINESIZE 140
    SET TRIMSPOOL ON
    SET PAGESIZE 1000
    SELECT /*+ GATHER_PLAN_STATISTICS */
      1 MY_VALUE
    FROM
      DUAL
    WHERE
      ROWNUM<=1;
    SELECT
    FROM
      TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,'ALLSTATS LAST +NOTE'));When I execute the above, this is what I see:
    SQL> SELECT /*+ GATHER_PLAN_STATISTICS */
      2    1 MY_VALUE
      3  FROM
      4    DUAL
      5  WHERE
      6    ROWNUM<=1;
      MY_VALUE
             1
    SQL>
    SQL> SELECT
      2    *
      3  FROM
      4    TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,'ALLSTATS LAST +NOTE'));
    PLAN_TABLE_OUTPUT
    SQL_ID  a9wsgk0qtb83c, child number 0
    SELECT /*+ GATHER_PLAN_STATISTICS */   1 MY_VALUE FROM   DUAL WHERE
    ROWNUM<=1
    Plan hash value: 3227170792
    | Id  | Operation        | Name | Starts | E-Rows | A-Rows |   A-Time   |
    |   0 | SELECT STATEMENT |      |      1 |        |      1 |00:00:00.01 |
    |*  1 |  COUNT STOPKEY   |      |      1 |        |      1 |00:00:00.01 |
    |   2 |   FAST DUAL      |      |      1 |      1 |      1 |00:00:00.01 |
    Predicate Information (identified by operation id):
       1 - filter(ROWNUM<=1)
    13 rows selected.When you post the output, use a { code } tag before and after the output so that the spaces in the explain plan test are retained (do not include the space on either side of the word code). For example:
    { code } (do not include the space between the bracket and the word code)
    | Id  | Operation        | Name | Starts | E-Rows | A-Rows |   A-Time   |
    |   0 | SELECT STATEMENT |      |      1 |        |      1 |00:00:00.01 |
    |*  1 |  COUNT STOPKEY   |      |      1 |        |      1 |00:00:00.01 |
    |   2 |   FAST DUAL      |      |      1 |      1 |      1 |00:00:00.01 |
    Predicate Information (identified by operation id):
       1 - filter(ROWNUM<=1){ code }
    Charles Hooper
    Co-author of "Expert Oracle Practices: Oracle Database Administration from the Oak Table"
    http://hoopercharles.wordpress.com/
    IT Manager/Oracle DBA
    K&M Machine-Fabricating, Inc.
    Edited by: Charles Hooper on May 31, 2010 11:51 AM
    Original test case did not specify a WHERE clause - fixed now.

  • Radius server not returning Filter-id information to access device

    I have set up a Radius server (v. 4.15 16 april 2003) on NW65sp2 server
    and I'm trying to use it to authenticate to a Watchguard Firebox II
    firewall. The authentication functions but apparently the firewall is
    not getting (or not parsing) the Filter-Id information to assign access
    rights via groups. When I login to the firewall with "user1", the
    response is "Authenticationsucceeded, but no access grantedfor user". If
    I define "user1" on the firewall and assign it to an access policy, then
    everything works. But if I define an access group "group1" and assign
    it to an access policy on the firewall and then assign "group1" to the
    eDir Access Profile object that is assigned to "user1", (Filter-Id =
    group1) I get the above authentication succesful, but no access granted.
    Is there a way to identify exactly what information is being sent from
    the Radius server to the access device so I can determine if the problem
    is on the Novell Radius server side or the Watchguard Firewall side?
    I've activated the Radius Debug Log, but that only tells me that it
    finds all the relevant objects in eDirectory and that authentication is
    successfull, but there is no indication that any other information is
    being sent to the access device.
    As I understand it, the filer-id's are supposed to allow a link between
    the eDir user objects and what access rights are allowed on the access
    device (firewall). Essentially this is how I define group memberships on
    the firewall using eDir user. Is this assumption correct?
    The goal of course is to allow access over the firewall without having
    to type in 500 user names on the firewall.
    Any ideas or tips on what I could check or configure differently would
    be helpful. thanks
    bill reading

    thanks for the feedback. I will take a look at the thread you mentioned
    and I'll get back to you with the trace as soon as I can arrange it.
    Scott Kiester wrote:
    > There is a thread titled "RADIUS Group with VASCO Digipass" in this group
    > from November where someone else was trying to use the filter-Id attribute
    > with their firewall. The customer was able to get this attribute to working
    > after tweaking his RADIUS configuration.
    >
    > Your understanding of the filter-Id attribute is correct. Either the RADIUS
    > server is not sending this attribute for some reason, or something on your
    > firewall has been misconfigured. A good starting point would be to take a
    > sniffer trace to see if the filter-Id attribute is in the access-request
    > packet. (You can use Ethereal, which is a free download from
    > www.ethereal.com, for the trace.) Post the trace here or send it to me at
    > [email protected] and I'll take a look at it.
    >
    >
    >>>>bill reading<[email protected]> 12/07/04 8:36 AM >>>
    >
    > I have set up a Radius server (v. 4.15 16 april 2003) on NW65sp2 server
    > and I'm trying to use it to authenticate to a Watchguard Firebox II
    > firewall. The authentication functions but apparently the firewall is
    > not getting (or not parsing) the Filter-Id information to assign access
    > rights via groups. When I login to the firewall with "user1", the
    > response is "Authenticationsucceeded, but no access grantedfor user". If
    > I define "user1" on the firewall and assign it to an access policy, then
    > everything works. But if I define an access group "group1" and assign
    > it to an access policy on the firewall and then assign "group1" to the
    > eDir Access Profile object that is assigned to "user1", (Filter-Id =
    > group1) I get the above authentication succesful, but no access granted.
    > Is there a way to identify exactly what information is being sent from
    > the Radius server to the access device so I can determine if the problem
    > is on the Novell Radius server side or the Watchguard Firewall side?
    > I've activated the Radius Debug Log, but that only tells me that it
    > finds all the relevant objects in eDirectory and that authentication is
    > successfull, but there is no indication that any other information is
    > being sent to the access device.
    >
    > As I understand it, the filer-id's are supposed to allow a link between
    > the eDir user objects and what access rights are allowed on the access
    > device (firewall). Essentially this is how I define group memberships on
    > the firewall using eDir user. Is this assumption correct?
    >
    > The goal of course is to allow access over the firewall without having
    > to type in 500 user names on the firewall.
    >
    > Any ideas or tips on what I could check or configure differently would
    > be helpful. thanks
    >
    > bill reading
    >
    >

  • Filter AD information from Kerberos logonticket

    Hi,
    I have recently configured SSO with Kerberos and SPNego for a portal system. And it's working fine. The LDAP configuration is pointing to a location on Active Directory. At this level, below, there are some more subfolders that indicates the usertype: for example there's a subfolder administrators and a subfolder production.
    At this moment all users under folders administrators and production are able to logon to the portal by means of their useraccount on LDAP. Is there a possibility to filter on a specific group of users? Let's say, all users from the production folder are allowed to make use of SSO, but all users from folder adminstrators should get a logon screen.
    I already did some testing by adding the login module "clientcertloginmodule" and tried to make use of the different rule-filter options but it's not working. I even wonder if it's possible. Has anyone experience or some tips?
    thank you

    Hello Danny
    The kind of login module to be used affects directly the application, not the user. This means that, if webdynpro applications are configured to use the spnego login module, this will be the first authentication mechanism to be checked, independently of the user.
    As far as I know, the solution would be to configure a "redirect" application for the users to logon into the portal (removing spnego login module from "ticket" login module stack). This way, most of users will use the "ticket" authentication mechanism (configured, for example, to use basic authentication), and then configure the "redirect" applications to use the spnego login module.
    There are several threads which discuss this situation, for example:
    /message/5811023#5811023
    Regards,
    Désiré

  • Interpreting Predicate  and Filter information from the explain plan

    Can somebody help in understanding how does the predicate and filter operation effects the execution plan.or how can I conclude the predicate or filter operation chosen by optimizer is not optimized.

    User445775,
    The paraphrase that I provided in my previous post was from page 74 of "Cost-Based Oracle Fundamentals".
    How to word the explanation...
    Assume that you have a database table which contains all of the phone numbers and addresses for people in a state. A query is executed to find user445775 in the city named "Redmond". Assume that the query looks like this:
    SELECT
      PHONE
    FROM
      PHONE_NUMBERS
    WHERE
      CITY = 'Redmond'
      AND FULL_NAME = 'user445775';Assume that there are no indexes on the table. The DBMS_XPLAN would show two filter predicates applied during a full tablescan - this probably indicates an inefficient access path, especially if there are a very small percentage of people matching the WHERE clause restrictions on the table.
    Now, assume that an index is created on the CITY column. The DBMS_XPLAN would show an access predicate applied to the index on the CITY column, and a filter predicate on the table access by index for the FULL_NAME. We eliminated a large number of possible rows by applying the access predicate to jump directly to the rows with the city of interest, and then filtered out those names which were not 'user445775'. This is not terribly efficient, especially if there are a large number of people in 'Redmond' that need to be filtered out.
    Now, assume that we drop the index on the CITY column and create an index on the FULL_NAME column. The DBMS_XPLAN would show an access predicate applied to the index on the FULL_NAME column, and a filter predicate on the table access by index for the CITY column. This could be a fairly efficient plan if there are only a couple rows in the table with FULL_NAME of 'user445775', as few rows will be discarded after the index access to find those with CITY = 'Redmond'.
    Now, assume that we drop the index on the FULL_NAME column and create a composite index on CITY,FULL_NAME. The DBMS_XPLAN would show an access predicate applied to the index on the CITY and FULL_NAME columns and there would not be a filter predicate on the table access by index - in this case, we will not discard any rows once retrieved by the index access.
    Page 211 of "Troubleshooting Oracle Performance" also shows a clear explanation of access and filter predicates.
    Think of access predicates (on indexes at least) as throwing out rows before they are retrieved from disk (or memory), and filter predicates as throwing out rows after they are retrieved from disk (or memory).
    Charles Hooper
    IT Manager/Oracle DBA
    K&M Machine-Fabricating, Inc.

  • Filter Information for two parameters in Query Designer

    Hi Gurus !!
    I have a problem for filter information for two parameters in Query Designer,
    the first parameter correspond a Ejercise-Period, the second parameter correspond
    a Compensation Date of document, both parmeters must have date less than or equal to
    to the parameter date input for screen (mm.aaaa).
    Internally the Report must filter countable information for Countable Date <= Parameter Input and
    Compensation Date of document <= Parameter Input.
    If i assign two filter parameter in Query Designer, not could realise this.
    Exist any simple form to realise this ??
    Wait for yours responses.
    Thank You.

    Hi shanthi bhaskar,
    Thanks a lot for your answer.
    I have one doubt about it:  with this solution that you propoused the user will be able to select the values for plant?.
    I mean, the user make the selection of the value for Zone, then he wants to see the in plan´s variable the values that corresponds with this Zone for make a new selection of plan.
    What happens if I need this dependency also in another variable like time variable?
    Thanks  a lot

  • Not Understanding the filter in Explain Plan - filter(NULL IS NOT NULL)

    Hi All,
    Request your help in understanding the below scenario. (I am not aware of teh application and table details. Just trying to help my friend)
    SQL> conn
    Enter user-name: [email protected]
    Enter password:
    Connected.
    SQL> select * from v$version;
    BANNER
    Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bi
    PL/SQL Release 10.2.0.3.0 - Production
    CORE    10.2.0.3.0      Production
    TNS for Linux: Version 10.2.0.3.0 - Production
    NLSRTL Version 10.2.0.3.0 - Production
    --Checking the count in PO_LINES
    SQL> select count(*) from po_lines;
      COUNT(*)
             0
    --PO_LINES is a synonym
    SQL> select object_type,owner from dba_objects where object_name = 'PO_LINES';
    OBJECT_TYPE         OWNER
    SYNONYM             APPS
    --The synonym is pointing to PO.PO_LINES_ALL
    SQL> select * from user_synonyms where synonym_name = 'PO_LINES';
    SYNONYM_NAME                   TABLE_OWNER                    TABLE_NAME                     DB_LINK
    PO_LINES                       PO                             PO_LINES_ALL
    --But when counting PO.PO_LINES_ALL I am getting different result
    SQL> select count(*) c from po.po_lines_all;
             C
          8828
    --Explain plan of teh original query is
    SQL> explain plan for
      2  select
      3  * from po_lines;
    Explained.
    SQL> select * from table(dbms_xplan.display);
    PLAN_TABLE_OUTPUT
    | Id  | Operation          | Name         | Rows  | Bytes | Cost (%CPU)|
    |   0 | SELECT STATEMENT   |              |     1 |   252 |     0   (0)|
    |*  1 |  FILTER            |              |       |       |            |
    |   2 |   TABLE ACCESS FULL| PO_LINES_ALL |  8796 |  2164K|   106   (4)|
    Predicate Information (identified by operation id):
       1 - filter(NULL IS NOT NULL)
    --Now the object PO.PO_LINES_ALL is TABLE, not an mview.
    SQL> select object_type,owner from dba_objects where object_name = 'PO_LINES_ALL';
    OBJECT_TYPE         OWNER
    TABLE               POSeek your help in understanding what is happening here.
    Thanks in Advance,
    jeneesh

    Next time, prefix with APPS. when you show us the explain plan:
    SQL> explain plan for
      2  select
      3  * from apps.po_lines;  -- added the prefix of owner.Just like you prefixed with PO. when you showed us the query on PO_LINES_ALL. It ensures that you are using the synonym which you showed us.
    Btw. PO_LINES_ALL, could still be a VIEW given your overview of the situation.
    Anyway a filter "NULL IS NOT NULL" is indicative that the optimizer performed something called semantic query optimization (SQO).
    SQO is the process of deducing new predicates based upon a) existing predicates in your query (which there is none), b) added predicates to your query (eg. by a VPD policy function), and c) declared constraints on the tables invovled in your query.
    A typical example of when a "NOT is NOT NULL" predicate will show up is when for instance in the EMP table there is a declared constraint on EMPNO like this:
    check(EMPNO > 0)And your query would hold a predicate that is inconsistent with the constraint, for instance like this:
    select *
    from EMP
    where EMPNO <= 0Oracle will deduce that EMPNO cannot be both greater than zero (constraint) as well as smaller than or equal to zero (your query predicate), and will transform the query into:
    select *
    from EMP
    where EMPNO <= 0
      and NULL is NOT NULLThus preventing accessing the EMP table all together, and immediately returning this query with no data found.
    Edited by: Toon Koppelaars on Mar 15, 2010 7:17 AM

  • NULL IS NOT NULL filter issue

    Can someone explain why 'Y' = 'N' is not working with PARALLEL Plan? i.e. With the filter like 'Y' = 'N' specified and if PQ is used , it does not return instantly. In fact it reads the entire table.
    Here is the test case.. Goal is to execute only one of the SQL joined by union all. I have included 'Y' = 'N' in both SQLs for the test purpose.
    DB Version is 10.2.0.4
    Create table test_tbl_01 nologging as select do.* from dba_objects do , dba_objects d1 where rownum < 22000001;
    Create table test_tbl_02 nologging as select do.* from dba_objects do , dba_objects d1 where rownum < 22000001;
    execute DBMS_STATS.GATHER_TABLE_STATS('SCOTT', 'TEST_TBL_01');
    execute DBMS_STATS.GATHER_TABLE_STATS('SCOTT', 'TEST_TBL_02');
    *Serial path with 2 table join*
    SQL> select
      2    /* parallel(t1,2 ) parallel(t2,2) */
      3    t1.*
      4    from test_tbl_01 t1 ,test_tbl_02 t2
      5    where t1.object_name = t2.object_name
      6    and  'Y' = 'N'
      7    and  t1.object_type = 'TABLE'
      8    union all
      9    select
    10    /* parallel(t1,2 ) parallel(t2,2) */
    11    t1.*
    12    from test_tbl_01 t1 ,test_tbl_02 t2
    13    where t1.object_name = t2.object_name
    14    and  'Y' = 'N'
    15  /
    no rows selected
    Elapsed: 00:00:00.01
    Execution Plan
    Plan hash value: 3500703583
    | Id  | Operation            | Name        | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT     |             |     2 |   168 |       |     0   (0)|          |
    |   1 |  UNION-ALL           |             |       |       |       |            |          |
    |*  2 |   FILTER             |             |       |       |       |            |          |
    |*  3 |    HASH JOIN         |             |   660G|    50T|   449M|  6242K (99)| 24:16:38 |
    |*  4 |     TABLE ACCESS FULL| TEST_TBL_01 |  5477K|   386M|       | 41261   (2)| 00:09:38 |
    |   5 |     TABLE ACCESS FULL| TEST_TBL_02 |    22M|   212M|       | 40933   (2)| 00:09:34 |
    |*  6 |   FILTER             |             |       |       |       |            |          |
    |*  7 |    HASH JOIN         |             |  2640G|   201T|   467M|    24M(100)| 95:54:53 |
    |   8 |     TABLE ACCESS FULL| TEST_TBL_02 |    22M|   212M|       | 40933   (2)| 00:09:34 |
    |   9 |     TABLE ACCESS FULL| TEST_TBL_01 |    21M|  1546M|       | 41373   (3)| 00:09:40 |
    Predicate Information (identified by operation id):
       2 - filter(NULL IS NOT NULL)
       3 - access("T1"."OBJECT_NAME"="T2"."OBJECT_NAME")
       4 - filter("T1"."OBJECT_TYPE"='TABLE')
       6 - filter(NULL IS NOT NULL)
       7 - access("T1"."OBJECT_NAME"="T2"."OBJECT_NAME")
    Statistics
              1  recursive calls
              0  db block gets
              0  consistent gets
              0  physical reads
              0  redo size
            567  bytes sent via SQL*Net to client
            232  bytes received via SQL*Net from client
              1  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
              0  rows processed
    *Parallel path with 2 table join*
    SQL> select
      2    /*+ parallel(t1,2 ) parallel(t2,2) */
      3    t1.*
      4    from test_tbl_01 t1 ,test_tbl_02 t2
      5    where t1.object_name = t2.object_name
      6    and  'Y' = 'N'
      7    and  t1.object_type = 'TABLE'
      8    union all
      9    select
    10    /*+ parallel(t1,2 ) parallel(t2,2) */
    11    t1.*
    12    from test_tbl_01 t1 ,test_tbl_02 t2
    13    where t1.object_name = t2.object_name
    14    and  'Y' = 'N'
    15  /
    no rows selected
    Elapsed: 00:01:09.34
    Execution Plan
    Plan hash value: 1557722279
    | Id  | Operation                   | Name        | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |    TQ  |IN-OUT| PQ Distrib |
    |   0 | SELECT STATEMENT            |             |     2 |   168 |       |     0   (0)|          |     |         |            |
    |   1 |  PX COORDINATOR             |             |       |       |       |            |          |     |         |            |
    |   2 |   PX SEND QC (RANDOM)       | :TQ10004    |       |       |       |            |          |  Q1,04 | P->S | QC (RAND)  |
    |   3 |    BUFFER SORT              |             |     2 |   168 |       |            |          |  Q1,04 | PCWP |            |
    |   4 |     UNION-ALL               |             |       |       |       |            |          |  Q1,04 | PCWP |            |
    |*  5 |      FILTER                 |             |       |       |       |            |          |  Q1,04 | PCWC |            |
    |*  6 |       HASH JOIN             |             |   660G|    50T|   224M|  3465K (99)| 13:28:42 |  Q1,04 | PCWP |            |
    |   7 |        PX JOIN FILTER CREATE| :BF0000     |  5477K|   386M|       | 22861   (2)| 00:05:21 |  Q1,04 | PCWP |            |
    |   8 |         PX RECEIVE          |             |  5477K|   386M|       | 22861   (2)| 00:05:21 |  Q1,04 | PCWP |            |
    |   9 |          PX SEND HASH       | :TQ10000    |  5477K|   386M|       | 22861   (2)| 00:05:21 |  Q1,00 | P->P | HASH       |
    |  10 |           PX BLOCK ITERATOR |             |  5477K|   386M|       | 22861   (2)| 00:05:21 |  Q1,00 | PCWC |            |
    |* 11 |            TABLE ACCESS FULL| TEST_TBL_01 |  5477K|   386M|       | 22861   (2)| 00:05:21 |  Q1,00 | PCWP |            |
    |  12 |        PX RECEIVE           |             |    22M|   212M|       | 22679   (1)| 00:05:18 |  Q1,04 | PCWP |            |
    |  13 |         PX SEND HASH        | :TQ10001    |    22M|   212M|       | 22679   (1)| 00:05:18 |  Q1,01 | P->P | HASH       |
    |  14 |          PX JOIN FILTER USE | :BF0000     |    22M|   212M|       | 22679   (1)| 00:05:18 |  Q1,01 | PCWP |            |
    |  15 |           PX BLOCK ITERATOR |             |    22M|   212M|       | 22679   (1)| 00:05:18 |  Q1,01 | PCWC |            |
    |  16 |            TABLE ACCESS FULL| TEST_TBL_02 |    22M|   212M|       | 22679   (1)| 00:05:18 |  Q1,01 | PCWP |            |
    |* 17 |      FILTER                 |             |       |       |       |            |          |  Q1,04 | PCWC |            |
    |* 18 |       HASH JOIN             |             |  2640G|   201T|   233M|    13M(100)| 53:15:52 |  Q1,04 | PCWP |            |
    |  19 |        PX RECEIVE           |             |    22M|   212M|       | 22679   (1)| 00:05:18 |  Q1,04 | PCWP |            |
    |  20 |         PX SEND HASH        | :TQ10002    |    22M|   212M|       | 22679   (1)| 00:05:18 |  Q1,02 | P->P | HASH       |
    |  21 |          PX BLOCK ITERATOR  |             |    22M|   212M|       | 22679   (1)| 00:05:18 |  Q1,02 | PCWC |            |
    |  22 |           TABLE ACCESS FULL | TEST_TBL_02 |    22M|   212M|       | 22679   (1)| 00:05:18 |  Q1,02 | PCWP |            |
    |  23 |        PX RECEIVE           |             |    21M|  1546M|       | 22924   (2)| 00:05:21 |  Q1,04 | PCWP |            |
    |  24 |         PX SEND HASH        | :TQ10003    |    21M|  1546M|       | 22924   (2)| 00:05:21 |  Q1,03 | P->P | HASH       |
    |  25 |          PX BLOCK ITERATOR  |             |    21M|  1546M|       | 22924   (2)| 00:05:21 |  Q1,03 | PCWC |            |
    |  26 |           TABLE ACCESS FULL | TEST_TBL_01 |    21M|  1546M|       | 22924   (2)| 00:05:21 |  Q1,03 | PCWP |            |
    Predicate Information (identified by operation id):
       5 - filter(NULL IS NOT NULL)
       6 - access("T1"."OBJECT_NAME"="T2"."OBJECT_NAME")
      11 - filter("T1"."OBJECT_TYPE"='TABLE')
      17 - filter(NULL IS NOT NULL)
      18 - access("T1"."OBJECT_NAME"="T2"."OBJECT_NAME")
    Statistics
           1617  recursive calls
              3  db block gets
         488929  consistent gets
         493407  physical reads
            636  redo size
            567  bytes sent via SQL*Net to client
            232  bytes received via SQL*Net from client
              1  SQL*Net roundtrips to/from client
              6  sorts (memory)
              0  sorts (disk)
              0  rows processedHowever single table with UNION ALL and PQ works..
    *NO Joins (i.e. Single Table with PQ )  , Issue does not show-up.*
    _*SERIAL PLAN with one Table*_
    SQL> select
      2    /* parallel(t1,2 )   */
      3    t1.*
      4    from test_tbl_01 t1
      5    where 'Y' = 'N'
      6    and  t1.object_type = 'TABLE'
      7    union all
      8    select
      9    /* parallel(t1,2 )   */
    10    t1.*
    11    from test_tbl_01 t1
    12    where 'Y' = 'N'
    13  /
    no rows selected
    Elapsed: 00:00:00.01
    Execution Plan
    Plan hash value: 2870519681
    | Id  | Operation           | Name        | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT    |             |     2 |   148 |     0   (0)|          |
    |   1 |  UNION-ALL          |             |       |       |            |          |
    |*  2 |   FILTER            |             |       |       |            |          |
    |*  3 |    TABLE ACCESS FULL| TEST_TBL_01 |  5477K|   386M| 41261   (2)| 00:09:38 |
    |*  4 |   FILTER            |             |       |       |            |          |
    |   5 |    TABLE ACCESS FULL| TEST_TBL_01 |    21M|  1546M| 41373   (3)| 00:09:40 |
    Predicate Information (identified by operation id):
       2 - filter(NULL IS NOT NULL)
       3 - filter("T1"."OBJECT_TYPE"='TABLE')
       4 - filter(NULL IS NOT NULL)
    Statistics
              0  recursive calls
              0  db block gets
              0  consistent gets
              0  physical reads
              0  redo size
            567  bytes sent via SQL*Net to client
            232  bytes received via SQL*Net from client
              1  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
              0  rows processed
    _*PARALLEL PLAN with one Table*_
    SQL> select
      2    /*+ parallel(t1,2 )      */
      3    t1.*
      4    from test_tbl_01 t1
      5    where 'Y' = 'N'
      6    and  t1.object_type = 'TABLE'
      7    union all
      8    select
      9    /*+ parallel(t1,2 )      */
    10    t1.*
    11    from test_tbl_01 t1
    12    where 'Y' = 'N'
    13  /
    no rows selected
    Elapsed: 00:00:00.09
    Execution Plan
    Plan hash value: 3114025180
    | Id  | Operation              | Name        | Rows  | Bytes | Cost (%CPU)| Time     |    TQ  |IN-OUT| PQ Distrib |
    |   0 | SELECT STATEMENT       |             |     2 |   148 |     0   (0)|          |        |      |            |
    |   1 |  PX COORDINATOR        |             |       |       |            |          |        |      |            |
    |   2 |   PX SEND QC (RANDOM)  | :TQ10000    |       |       |            |          |  Q1,00 | P->S | QC (RAND)  |
    |   3 |    UNION-ALL           |             |       |       |            |          |  Q1,00 | PCWP |            |
    |*  4 |     FILTER             |             |       |       |            |          |  Q1,00 | PCWC |            |
    |   5 |      PX BLOCK ITERATOR |             |  5477K|   386M| 22861   (2)| 00:05:21 |  Q1,00 | PCWC |            |
    |*  6 |       TABLE ACCESS FULL| TEST_TBL_01 |  5477K|   386M| 22861   (2)| 00:05:21 |  Q1,00 | PCWP |            |
    |*  7 |     FILTER             |             |       |       |            |          |  Q1,00 | PCWC |            |
    |   8 |      PX BLOCK ITERATOR |             |    21M|  1546M| 22924   (2)| 00:05:21 |  Q1,00 | PCWC |            |
    |   9 |       TABLE ACCESS FULL| TEST_TBL_01 |    21M|  1546M| 22924   (2)| 00:05:21 |  Q1,00 | PCWP |            |
    Predicate Information (identified by operation id):
       4 - filter(NULL IS NOT NULL)
       6 - filter("T1"."OBJECT_TYPE"='TABLE')
       7 - filter(NULL IS NOT NULL)
    Statistics
             28  recursive calls
              3  db block gets
              7  consistent gets
              0  physical reads
            628  redo size
            567  bytes sent via SQL*Net to client
            232  bytes received via SQL*Net from client
              1  SQL*Net roundtrips to/from client
              2  sorts (memory)
              0  sorts (disk)
              0  rows processed

    The same behvious appears in 11.1.0.6, and you don't need such a large data set to prove the point. The paralllel distribution may change to a broadcast with a smaller data set, but I demonstrated the effect when my two tables simply selected 30,000 rows each from all_objects.
    I think you should pass this to Oracle Corp. as a bug - using the smaller data set.
    The problem seems to be the way that Oracle combines multiple lines of a plan into groups of operations (as in PCWC, PCWC, PCWP). It looks like this particularly example has managed to fold the FILTER into a group in such a way that Oracle has lost track of the fact that it is a 'pre-emptng - i.e. always false' filter rather than an ordinary data filter; consequently the filter doesn't apply until after the hash join starts running.
    In my example (which did a broadcast distribution) I could see that Oracle read the entire first table, then started to read the second table, but stopped after one row of the second table, because my plan allowed the join and filter to be applied immediately after the first row from the second table. And I think Oracle decided that the filter was alway going to be false at that moment - so stopped running the second tablescan. You've used a hash/hash distribriution, which has resulted in both scans completing because the slaves in each layer don't talk to each other.
    Regards
    Jonathan Lewis
    http://jonathanlewis.wordpress.com
    http://www.jlcomp.demon.co.uk
    "Science is more than a body of knowledge; it is a way of thinking"
    Carl Sagan

  • Filter(NULL IS NOT NULL) in Explain Plan ??

    Hi All,
    Can someone please explain what this explain plan statement means? I see a filter(NULL IS NOT NULL) as the first statement - could not figure out why it came up so from googling.
    My Query Used:
    EXPLAIN PLAN FOR
    MERGE INTO summary_bysrccd
    USING
    (SELECT LAST_DAY(TRUNC(to_timestamp(os.requestdatetime, 'yyyymmddhh24:mi:ss.ff4'))) AS SUMMARY_DATE,
    os.acctnum,
    ol.sourcecode AS sourcecode,
    ol.sourcename AS sourcename,
    count(1) cnt_articleview
    FROM article_views os , master_sourcecode ol
    where os.sourcecode = ol.sourcecode
    AND os.acctnum IS NOT NULL
    AND ol.sourcecode IS NOT NULL
    AND os.requestdatetime IS NOT NULL
    AND UPPER(os.success_ind) = 'S'
         AND (
              ('INCR'  = 'FULL'
              AND  (get_date_timestamp(os.requestdatetime) BETWEEN TO_DATE('23-AUG-2011 00:00:00','DD-MON-YYYY HH24:MI:SS') AND TO_DATE('27-AUG-2011 23:59:59','DD-MON-YYYY HH24:MI:SS')
              AND   os.entry_CreatedDate BETWEEN TO_DATE('22-AUG-2011 00:00:00','DD-MON-YYYY HH24:MI:SS') AND TO_DATE('28-AUG-2011 00:00:00','DD-MON-YYYY HH24:MI:SS')
              OR ('INCR' = 'FULL'
              AND os.entry_createddate BETWEEN TO_DATE('23-AUG-2011 00:00:00','DD-MON-YYYY HH24:MI:SS') AND TO_DATE('27-AUG-2011 23:59:59','DD-MON-YYYY HH24:MI:SS') )
    group by LAST_DAY(TRUNC(to_timestamp(os.requestdatetime, 'yyyymmddhh24:mi:ss.ff4'))),
    os.acctnum,ol.sourcecode,ol.sourcename) mrg_query
    ON (ods_av_summary_bysrccd.acctnum = mrg_query.acctnum AND
    ods_av_summary_bysrccd.summary_date=mrg_query.summary_date AND
    ods_av_summary_bysrccd.sourcecode=mrg_query.sourcecode)
    WHEN NOT MATCHED THEN
    INSERT (SUMMARY_date,ACCTNUM,SOURCECODE,SOURCENAME,CNT_ARTICLEVIEW,ENTRY_LASTUPDATEDDATE)
    VALUES(mrg_query.summary_date,mrg_query.acctnum,mrg_query.sourcecode,mrg_query.sourcename,
    mrg_query.cnt_articleview,sysdate)
    WHEN MATCHED THEN
    UPDATE SET ods_av_summary_bysrccd.cnt_articleview=
    CASE WHEN NVL('INCR','INCR') = 'FULL' THEN mrg_query.cnt_articleview
    ELSE ods_av_summary_bysrccd.cnt_articleview+mrg_query.cnt_articleview
    END,
    ods_av_summary_bysrccd.entry_lastupdateddate=sysdate;My Explain Plan:
    SQL> select * from table(dbms_xplan.display);
    PLAN_TABLE_OUTPUT
    Plan hash value: 268591246
    | Id  | Operation                                 | Name                      | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     | Pstart| Pstop |
    |   0 | MERGE STATEMENT                           |                           |     1 |   456 |       |     3   (0)| 00:00:01 |       |       |
    |   1 |  MERGE                                    | ODS_AV_SUMMARY_BYSRCCD    |       |       |       |            |          |       |       |
    |   2 |   VIEW                                    |                           |       |       |       |            |          |       |       |
    |   3 |    NESTED LOOPS OUTER                     |                           |     1 |   417 |       |     3   (0)| 00:00:01 |       |       |
    |   4 |     VIEW                                  |                           |     1 |   360 |       |     5 (100)| 00:00:01 |       |       |
    |   5 |      SORT GROUP BY                        |                           |     1 |    73 |   595M|            |          |       |       |
    PLAN_TABLE_OUTPUT
    |*  6 |       FILTER                              |                           |       |       |       |            |          |       |       |
    |*  7 |        HASH JOIN                          |                           |  6975K|   485M|  3944K| 17594   (1)| 00:03:32 |       |       |
    |   8 |         TABLE ACCESS FULL                 | ODS_MASTER_SOURCECODE     | 84021 |  2953K|       |   273   (1)| 00:00:04 |       |       |
    |*  9 |         TABLE ACCESS BY GLOBAL INDEX ROWID| ODS_ARTICLE_VIEWS         |  7007K|   247M|       |   826   (0)| 00:00:10 |    33 |    33 |
    |* 10 |          INDEX FULL SCAN                  | IDX_AV_ACCTNUM            |    25M|       |       |    26   (0)| 00:00:01 |       |       |
    |  11 |     TABLE ACCESS BY GLOBAL INDEX ROWID    | ODS_AV_SUMMARY_BYSRCCD    |     1 |    57 |       |     3   (0)| 00:00:01 | ROWID | ROWID |
    |* 12 |      INDEX UNIQUE SCAN                    | ODS_AV_SUMMARY_BYSRCCD_PK |     1 |       |       |     2   (0)| 00:00:01 |       |       |
    Predicate Information (identified by operation id):
    PLAN_TABLE_OUTPUT
       6 - filter(NULL IS NOT NULL)
       7 - access("OS"."SOURCECODE"="OL"."SOURCECODE")
       9 - filter("OS"."REQUESTDATETIME" IS NOT NULL AND "OS"."ENTRY_CREATEDDATE">=TO_DATE(' 2011-08-23 00:00:00', 'syyyy-mm-dd
                  hh24:mi:ss') AND "OS"."ENTRY_CREATEDDATE"<=TO_DATE(' 2011-08-27 23:59:59', 'syyyy-mm-dd hh24:mi:ss') AND UPPER("OS"."SUCCESS_IND")='S')
      10 - filter("OS"."ACCTNUM" IS NOT NULL)
      12 - access("ODS_AV_SUMMARY_BYSRCCD"."SUMMARY_DATE"(+)=INTERNAL_FUNCTION("MRG_QUERY"."SUMMARY_DATE") AND
                  "ODS_AV_SUMMARY_BYSRCCD"."ACCTNUM"(+)="MRG_QUERY"."ACCTNUM" AND "ODS_AV_SUMMARY_BYSRCCD"."SOURCECODE"(+)="MRG_QUERY"."SOURCECODE")
    Note
    PLAN_TABLE_OUTPUT
       - dynamic sampling used for this statement

    Hi Toon,
    Thanks for the quick resolution. I went back and verified the table's colunm details and it has a NOT NULL constraint.
    Regards,
    Chaitanya
    P.S: Is it ok if I ask you for some help regarding a production issue I have been encountering since 15 days but haev no clear resolution yet about what/why is the reason (the said issue is neither uniform nor regular - its affecting some modules and happening on some days - i shall give the full details if you are willing to have a look) - i shall start a new post or email you directly - yur convenience.

  • How can we specify the order of the predicates execution?

    I am going to write the following query
    select answer, answer_id from surveys s join answers a on s.survey_id = a.survey_seq_id
    where question_uid = 206400374 and insertdate = to_date('31/12/2012') and answer > 0;However, when I look at the execution plan, I see that the last predicate (to_number(answer) > 0) has been executed the first. Henceforth, it checks many rows first. Normally, 75 rows belong to 31/12/2012 as you see from the following. Can I specify the execution order?
    select count(*) from surveys s join answers a on s.survey_id = a.survey_seq_id
    where question_uid = 206400374 and insertdate = to_date('31/12/2012');
    COUNT(*)
    75If so, how? Because, the type of answer is varchar2 and some of answers contain text characters such as 'Yes' or 'No'. Therefore, before 31/12/2012 some answers contain 'Yes' or 'No'. However in 31/12/2012 all answers are numeric.
    Plan hash value: 3217836037
    | Id  | Operation          | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT   |         |     2 |    68 |  9401   (1)| 00:01:53 |
    |*  1 |  HASH JOIN         |         |     2 |    68 |  9401   (1)| 00:01:53 |
    |*  2 |   TABLE ACCESS FULL| SURVEYS |     2 |    26 |   239   (1)| 00:00:03 |
    |*  3 |   TABLE ACCESS FULL| ANSWERS |   337 |  7077 |  9162   (1)| 00:01:50 |
    Predicate Information (identified by operation id):
       1 - access("S"."SURVEY_ID"="A"."SURVEY_SEQ_ID")
       2 - filter("S"."INSERTDATE"=TO_DATE(' 2012-12-31 00:00:00',
                  'syyyy-mm-dd hh24:mi:ss'))
       3 - filter("A"."QUESTION_UID"=206400374 AND
                  TO_NUMBER("A"."ANSWER")>0)
    select distinct answer from surveys s join answers a on s.survey_id = a.survey_seq_id
    where question_uid = 206400374 and insertdate = to_date('31/12/2012');
    ANSWER
    1
    3
    0
    2And, also I can execute the following query without any error
    select to_number(answer) from surveys s join answers a on s.survey_id = a.survey_seq_id
    where question_uid = 206400374 and insertdate = to_date('31/12/2012');

    In answer to your original question:
    970992 wrote:
    However, when I look at the execution plan, I see that the last predicate (to_number(answer) > 0) has been executed the first. Henceforth, it checks many rows first. Normally, 75 rows belong to 31/12/2012 as you see from the following. Can I specify the execution order?According to the execution plan, it will do a full scan of surveys using the predicate on insertdate to build the (presumably in-memory) hash table (hash based on survey_id) to do the joins (Step 2). Then, it does a full scan of the answers table using the question_uid and answer predicates (Step 3). For each row it finds that matches those predicate, it will prpobe the hash table created in step 2 using the hashed value of survey_seq_id. So, it is doing the insertdate predicate first.
    In answer to your last post
    970992 wrote:
    >
    First of all i would get rid of the implizit type conversion:
    TO_NUMBER("A"."ANSWER")>0)it is not implicit conversion, I reckon it is explicit type conversion, isnt it?
    No, it is an implicit type conversion. Your code says answer > 0, since the answer column is a varchar2 column, Oracle implicitly converts the answer column to a number to compare against the number on the right side of the comparison. Note that if something like 'A' ever becomes a valid answer, then this query will fail with ORA-01722: invalid number.
    >
    >
    Obviously "A"."ANSWER" is not a number colmun, problably varchar, so use something like
    A.ANSWER != "0"
    or
    A.ANSWER > "0"Yes answer column is varchar2 but can you type A.ANSWER > "0" as a predicate? I mean, you can not varchar > varchar, can you?
    Of course you can use inequality predicates on a varcahr column. Is the string A greater than the string B?
    Based on the explain plan, your statistics might be a little off, not hugely so. The esitmates are at least in the right order of magnitude based on what you have posted so far.
    What indexes, if any, are available on the two tables?
    John

  • XMLQuery starts using XMLSEQUENCEFROMXMLTYPE when adding filter to query

    Hi,
    I'm creating a single XML view on 3 relational tables. These table represent:
    1. a dataset description (table: refs)
    2. a keyset (table: keyset, a table with between refs )
    3. a data set (table: data, consisting of reference to key, value, and reference to a dataset)
    Per dataset I can have multiple keys, per key I have multiple values
    (1:N for dataset:keys, 1:N keys:values)
    The definition is given below:
    DROP TABLE data;
    DROP TABLE refs;
    DROP TABLE keyset;
    CREATE TABLE data (ref int, key int, value float);
    CREATE TABLE refs (ref int);
    CREATE TABLE keyset (key int, ref int);
    CREATE INDEX data_krv ON data (key,ref,value);
    CREATE INDEX keyset_kr ON keyset (key,ref);
    INSERT INTO refs VALUES (1);
    INSERT INTO refs VALUES (2);
    INSERT INTO data VALUES (1,1,1.5);
    INSERT INTO data VALUES (1,1,2.5);
    INSERT INTO data VALUES (1,2,3.5);
    INSERT INTO data VALUES (1,2,4.5);
    INSERT INTO data VALUES (2,1,5.5);
    INSERT INTO data VALUES (2,1,6.5);
    INSERT INTO data VALUES (2,2,7.5);
    INSERT INTO data VALUES (2,2,8.5);
    INSERT INTO keyset SELECT DISTINCT key, ref FROM data;
    CREATE OR REPLACE VIEW drk_xml_view OF XMLType
    with OBJECT ID
      extract(object_value,'/ref').getnumberval()
    AS
    SELECT xmlElement(
         "ref",
         xmlElement("ref_id", refs.ref),
         (SELECT xmlAgg(
                    xmlElement("key",
                      xmlElement("key_id",keyset.key),
                      xmlElement("values",
                          (SELECT xmlAgg(xmlElement("value",data.value))
                           FROM data
                           WHERE data.key=keyset.key AND data.ref=keyset.ref)
          FROM keyset WHERE refs.ref = keyset.ref
    ) FROM refs
    /When I do a query like:
    SELECT xmlQuery('for $i in /ref return max($i/key/values/value)' passing object_value returning content) from drk_xml_view;the explain plan looks as expected:
    | Id  | Operation              | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT       |           |     2 |    26 |     3   (0)| 00:00:01 |
    |   1 |  SORT AGGREGATE        |           |     1 |    65 |            |          |
    |   2 |   NESTED LOOPS         |           |     1 |    65 |     6   (0)| 00:00:01 |
    |*  3 |    INDEX FAST FULL SCAN| KEYSET_KR |     1 |    26 |     3   (0)| 00:00:01 |
    |*  4 |    INDEX RANGE SCAN    | DATA_KRV  |     1 |    39 |     3   (0)| 00:00:01 |
    |   5 |  SORT AGGREGATE        |           |     1 |       |            |          |
    |   6 |   FAST DUAL            |           |     1 |       |     2   (0)| 00:00:01 |
    |   7 |  TABLE ACCESS FULL     | REFS      |     2 |    26 |     3   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       3 - filter("KEYSET"."REF"=:B1)
       4 - access("DATA"."KEY"="KEYSET"."KEY" AND "DATA"."REF"=:B1)
           filter("DATA"."REF"="KEYSET"."REF")
    Note
       - dynamic sampling used for this statementThis is very nicely optimized.
    But now I do this one:
    SELECT xmlQuery('for $i in /ref[./ref_id<2] return max($i/key/values/value)' passing object_value returning content) from drk_xml_view;(where I only added a constraint on the /ref/ref_id) the following occurs:
    | Id  | Operation                          | Name                   | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT                   |                        |     2 |    26 |     3   (0)| 00:00:01 |
    |   1 |  SORT AGGREGATE                    |                        |     1 |     2 |            |          |
    |   2 |   COLLECTION ITERATOR PICKLER FETCH| XMLSEQUENCEFROMXMLTYPE |       |       |            |          |
    |   3 |  SORT AGGREGATE                    |                        |     1 |       |            |          |
    |*  4 |   FILTER                           |                        |       |       |            |          |
    |   5 |    FAST DUAL                       |                        |     1 |       |     2   (0)| 00:00:01 |
    |   6 |  TABLE ACCESS FULL                 | REFS                   |     2 |    26 |     3   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       4 - filter(:B1<2)
    Note
       - dynamic sampling used for this statementSo, it doesn't use any index any more and creates a XMLSequenceFromXMLType instead. This one is then parsed which results in really bad performance.
    I've tried to add extra indexes to the tables, but that didn't result in an optimilization. From a SQL point of view this seems quite easy, but using the view it gives me problems.
    Is there someone who can explain me what is happening here? Or give me some pointers?
    Please let me know if you need to know more, or if something is unclear.
    Best regards

    SQL> SELECT xmlQuery('for $i in /ref where $i/ref_id < 2 return max($i/key/values/value) ' passing object_value returning content)
      2    from drk_xml_view
      3  /
    XMLQUERY('FOR$IIN/REFWHERE$I/REF_ID<2RETURNMAX($I/KEY/VALUES/VALUE)'PASSINGOBJECT_VALUERETURNINGCONTENT)
    4.5
    Execution Plan
    Plan hash value: 2754328746
    | Id  | Operation           | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT    |        |     2 |    26 |     2   (0)| 00:00:01 |
    |   1 |  SORT AGGREGATE     |        |     1 |    65 |            |          |
    |*  2 |   HASH JOIN         |        |     1 |    65 |     5  (20)| 00:00:01 |
    |*  3 |    TABLE ACCESS FULL| KEYSET |     1 |    26 |     2   (0)| 00:00:01 |
    |*  4 |    TABLE ACCESS FULL| DATA   |     1 |    39 |     2   (0)| 00:00:01 |
    |   5 |  SORT AGGREGATE     |        |     1 |       |            |          |
    |*  6 |   FILTER            |        |       |       |            |          |
    |   7 |    FAST DUAL        |        |     1 |       |     2   (0)| 00:00:01 |
    |   8 |  TABLE ACCESS FULL  | REFS   |     2 |    26 |     2   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       2 - access("DATA"."KEY"="KEYSET"."KEY" AND
                  "DATA"."REF"="KEYSET"."REF")
       3 - filter("KEYSET"."REF"=:B1)
       4 - filter("DATA"."REF"=:B1)
       6 - filter(:B1<2)
    Note
       - dynamic sampling used for this statement
    SQL>

  • When to filter on table

    I have a table that contains a XML field.
    To make things easier, a view is created with extracted XML fields.
    This is deemed to be an expensive operation.
    A bunch of table is then joined with the view on a filter condition.
    My question is:
    Does every XML row gets extracted when doing the join?
    In other word, should put the filter condition on the view first.
    create view XML as
    select
    id,extractvalue(xml,'/COMPONENT/START_DATE/DATE') startdate from trans
    select * from XML x join product p on x.id = p.id

    Look at this test:
    SQL> select * from trans;
            ID XML
             1
               <COMPONENT>
                 <START_DATE>
                    <DATE>2009-12-31</DATE>
                 </START_DATE>
               </COMPONENT>
             2
               <COMPONENT>
                 <START_DATE>
                    <DATE>2010-12-31</DATE>
                 </START_DATE>
               </COMPONENT>
             3
               <COMPONENT>
                 <START_DATE>
                    <DATE>2011-12-31</DATE>
                 </START_DATE>
               </COMPONENT>
    SQL> create view XML as
      2  select
      3  id,extractvalue(xml,'/COMPONENT/START_DATE/DATE') startdate from trans
      4  ;
    View created.
    SQL> select * from xml;
            ID STARTDATE
             1 2009-12-31
             2 2010-12-31
             3 2011-12-31
    SQL> create index trans_ind on trans(id);
    Index created.
    SQL> set autot on exp
    SQL> select * from xml
      2  where id=2;
            ID STARTDATE
             2 2010-12-31
    Execution Plan
    Plan hash value: 128389523
    | Id  | Operation                   | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT            |           |     1 |  2015 |     2   (0)| 00:00:01 |
    |   1 |  TABLE ACCESS BY INDEX ROWID| TRANS     |     1 |  2015 |     2   (0)| 00:00:01 |
    |*  2 |   INDEX RANGE SCAN          | TRANS_IND |     1 |       |     1   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       2 - access("ID"=2)
    Note
       - dynamic sampling used for this statement
    SQL> create table product (id number);
    Table created.
    SQL> insert into product values (2);
    1 row created.
    SQL> select * from XML x join product p on x.id = p.id;
            ID STARTDATE                    ID
             2 2010-12-31                    2
    Execution Plan
    Plan hash value: 3807437055
    | Id  | Operation                   | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT            |           |     1 |  2028 |     4   (0)| 00:00:01 |
    |   1 |  TABLE ACCESS BY INDEX ROWID| TRANS     |     1 |  2015 |     1   (0)| 00:00:01 |
    |   2 |   NESTED LOOPS              |           |     1 |  2028 |     4   (0)| 00:00:01 |
    |   3 |    TABLE ACCESS FULL        | PRODUCT   |     1 |    13 |     3   (0)| 00:00:01 |
    |*  4 |    INDEX RANGE SCAN         | TRANS_IND |     1 |       |     0   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       4 - access("ID"="P"."ID")
    Note
       - dynamic sampling used for this statementAs you can see in the last execution plan, the query has been rewrote by the optimizer and it has fist of all selected the row to return (id=2) from the index and then is gone to read data from the TRANS table.
    So the extracvalue function has been evaluated only on one row.
    Max
    [My Italian Oracle blog|http://oracleitalia.wordpress.com/2010/01/17/supporto-di-xml-schema-in-oracle-xmldb/]
    Edited by: Massimo Ruocchio on Jan 18, 2010 5:44 PM
    Adjusted layout

  • Bloom filter and performance

    I have the following query:
    SELECT 
                    obst.obst_id obstructionId
                   ,oost.comment_clob CommentClob
                   ,chp1.ptcar_no StartPtcar
                   ,chp2.ptcar_no EndPtcar
                   ,oost.track_code Track
                   ,oost.start_date StartPeriod
                   ,oost.end_date EndPeriod
                   ,oost.doc_no RelaasId
                   ,obst.status_code Status
            FROM   T1 obst
                 , T2 oost
                 , T3 chp1
                 , T3 chp2
              where obst.oost_id      = oost.oost_id
              and oost.chp_id_start = chp1.chp_id
              and oost.chp_id_end   = chp2.chp_id
              and obst.obs_stat     = 2
       and add_months(obst.mod_date,13) >= :ld_curr_date
       and oost.start_date between :ld_from_date and :ld_to_date         
              and exists (select 1
                            from T4  obsv
                               , T5  veh
                            where  obsv.veh_id = veh.veh_id
                            and (:ln_opr_id is null
                                   OR veh.opr_id = :ln_opr_id)
                            and  obsv.obst_id = obst.obst_id
                            and  veh.ac_number between :ln_min_number and :ln_max_number
                            and  obsv.start_date > obst.start_date
             order by obst.obst_id;
    Giving the following execution plan where a bloom filter has been used.
    | Id  | Operation                           | Name                    | Starts | E-Rows | A-Rows |   A-Time   | Buffers | Reads  |
    |   0 | SELECT STATEMENT                    |                         |      1 |        |     10 |00:02:13.09 |     128K|  94376 |
    |   1 |  SORT ORDER BY                      |                         |      1 |      8 |     10 |00:02:13.09 |     128K|  94376 |
    |   2 |   NESTED LOOPS                      |                         |      1 |        |     10 |00:02:13.06 |     128K|  94376 |
    |   3 |    NESTED LOOPS                     |                         |      1 |      8 |     10 |00:02:13.06 |     128K|  94376 |
    |   4 |     NESTED LOOPS                    |                         |      1 |      8 |     10 |00:02:13.06 |     128K|  94376 |
    |*  5 |      HASH JOIN SEMI                 |                         |      1 |      8 |     10 |00:02:13.06 |     128K|  94376 |
    |   6 |       JOIN FILTER CREATE            | :BF0000                 |      1 |        |   1469 |00:00:02.06 |   12430 |     76 |
    |   7 |        NESTED LOOPS                 |                         |      1 |        |   1469 |00:00:00.17 |   12430 |     76 |
    |   8 |         NESTED LOOPS                |                         |      1 |    307 |   5522 |00:00:00.11 |   10545 |     52 |
    |*  9 |          TABLE ACCESS BY INDEX ROWID| T2                      |      1 |    316 |   5522 |00:00:00.07 |    3383 |     46 |
    |* 10 |           INDEX RANGE SCAN          | T2_OOST_START_DATE_I    |      1 |   1033 |   8543 |00:00:00.03 |      33 |      3 |
    |* 11 |          INDEX RANGE SCAN           | T1_OBST_OOST_DK_I       |   5522 |      1 |   5522 |00:00:00.08 |    7162 |      6 |
    |* 12 |         TABLE ACCESS BY INDEX ROWID | T1                      |   5522 |      1 |   1469 |00:00:00.13 |    1885 |     24 |
    |  13 |       VIEW                          | VW_SQ_1                 |      1 |  64027 |   1405 |00:00:07.82 |     115K|  94300 |
    |* 14 |        FILTER                       |                         |      1 |        |   1405 |00:00:07.82 |     115K|  94300 |
    |  15 |         JOIN FILTER USE             | :BF0000                 |      1 |  64027 |   1405 |00:00:07.82 |     115K|  94300 |
    |  16 |          PARTITION REFERENCE ALL    |                         |      1 |  64027 |  64027 |00:01:48.22 |     115K|  94300 |
    |* 17 |           HASH JOIN                 |                         |     52 |  64027 |  64027 |00:02:03.37 |     115K|  94300 |
    |  18 |            TABLE ACCESS FULL        | T4                      |     52 |  64027 |  64027 |00:00:00.34 |    1408 |    280 |
    |* 19 |            TABLE ACCESS FULL        | T5                      |     41 |    569K|   5555K|00:02:08.32 |     114K|  94020 |
    |  20 |      TABLE ACCESS BY INDEX ROWID    | T3                      |     10 |      1 |     10 |00:00:00.01 |      22 |      0 |
    |* 21 |       INDEX UNIQUE SCAN             | T3_CHP_PK               |     10 |      1 |     10 |00:00:00.01 |      12 |      0 |
    |* 22 |     INDEX UNIQUE SCAN               | T3_CHP_PK               |     10 |      1 |     10 |00:00:00.01 |      12 |      0 |
    |  23 |    TABLE ACCESS BY INDEX ROWID      | T3                      |     10 |      1 |     10 |00:00:00.01 |      10 |      0 |
    Predicate Information (identified by operation id):
       5 - access("ITEM_1"="OBST"."OBST_ID")
           filter("ITEM_2">"OBST"."START_DATE")
       9 - filter(("OOST"."CHP_ID_START" IS NOT NULL AND "OOST"."CHP_ID_END" IS NOT NULL))
      10 - access("OOST"."START_DATE">=:LD_FROM_DATE AND "OOST"."START_DATE"<=:LD_TO_DATE)
      11 - access("OBST"."OOST_ID"="OOST"."OOST_ID")
      12 - filter(("OBST"."OBS_STAT"=2 AND ADD_MONTHS(INTERNAL_FUNCTION("OBST"."MOD_DATE"),13)>=:LD_CURR_DATE))
      14 - filter((:LN_MIN_ac_number<=:ln_max_number AND TO_DATE(:LD_FROM_DATE)<=TO_DATE(:LD_TO_DATE)))
      17 - access("OBSV"."VEH_ID"="VEH"."VEH_ID")
      19 - filter(((:LN_OPR_ID IS NULL OR "VEH"."OPR_ID"=:LN_OPR_ID) AND "VEH"."ac_number">=:LN_MIN_ac_number AND
                  "VEH"."ac_number"<=:ln_max_number))
      21 - access("OOST"."CHP_ID_START"="CHP1"."CHP_ID")
      22 - access("OOST"."CHP_ID_END"="CHP2"."CHP_ID")
    This query completes in a not acceptable response time of more than 2 minutes and this is why it has been handled to me for possible improvement.
    As you might have already pointed it out from the above execution plan, the operation number 19 is the most time consuming operation (TABLE ACCESS FULL of T5). The query without the EXISTS part represents our data. This part of the query is very fast. It gives about 1500 rows. However, when we want to limit those 1500 records to only records satisfying the exists clause (10 records), the query starts not performing very well because of this full table scan on T5 (5,5 millions).
    The ideal situation would have been to :
    (a) first join table T5(alias veh) with the table T4(alias obs) using the join condition (predicate 17) limiting the number of record from T5 table
    (b) and then filter from T5 table (predicate 19)
    But in this case the CBO is starting by a costly full scan of the entire T5 table (5,5 millions of rows operation 19) before sending this enormous amount of data to the HASH JOIN operation 17 which finally throw away the majority of T5 rows not satisfying the join condition : access("OBSV"."VEH_ID"="VEH"."VEH_ID")
    I have already verified that the table statistics and their join column statistics are up-to-date and are reflecting the reality. But failed to know how to let the CBO automatically doing what I want it to do i.e. Join first and then filter.
    When I discussed with the client we agreed to re-factor a little bit this query so that it is now completing in few seconds.
    The new plan is not using bloom filter and the veh table is accessed via its unique index on VEH_ID (18 - access("OBSV"."VEH_ID"="VEH"."VEH_ID")) before applying the filter operation. Exactly as I wanted it to be in the original query
    Have you any idea on how to change this join method/order so that the full table scan is post poned? of course without refactoring the query
    Do you think that bloom filter is the culprit here?
    Thanks in advance
    Mohamed Houri
    PS : and  veh.ac_number between :ln_min_number and :ln_max_number
    These two imput parameters are beyound the known low and high value. But even when I used min and max value taken from the table (min = low_value from stats and max = high value from stat), the plan didn't changed

    Jonathan,
    I got the plan I was looking for.
    It is not exactly the same as the execution plan that corresponds to the re-factored query but it is what I wanted to have.
    SELECT  /*+ gather_plan_statistics */
                   obst.obst_id obstructionId
                   ,oost.comment_clob CommentClob
                   ,chp1.ptcar_no StartPtcar
                   ,chp2.ptcar_no EndPtcar
                   ,oost.track_code Track
                   ,oost.start_date StartPeriod
                   ,oost.end_date EndPeriod
                   ,oost.doc_no RelaasId
                   ,obst.status_code Status
            FROM   T1 obst
                 , T2 oost
                 , T3 chp1
                 , T3 chp2
            where obst.oost_id = oost.oost_id
              and oost.chp_id_start = chp1.chp_id
              and oost.chp_id_end = chp2.chp_id
              and obst.obs_stat = 2 -- only reeel       
                    and exists (select /*+ no_unnest push_subq */ 1
                            from T4 obsv
                               , T5 veh
                            where obsv.veh_id = veh.veh_id
                              and (null is null
                                   OR veh.opr_id = null
                              and  obsv.obst_id = obst.obst_id
                              and veh.ac_number between 1 and 99999
                              and obsv.start_date > obst.start_date
              and oost.start_date between to_date ('20/11/2013','DD/MM/YYYY') and to_date ('27/11/2013','DD/MM/YYYY')
              and add_months(obst.mod_date,13) >= sysdate
             order by obst.obst_id
    | Id  | Operation                                 | Name                    | Starts | E-Rows | A-Rows |   A-Time   |
    |   0 | SELECT STATEMENT                          |                         |      1 |        |      6 |00:00:00.56 |
    |   1 |  SORT ORDER BY                            |                         |      1 |    254 |      6 |00:00:00.56 |
    |*  2 |   HASH JOIN                               |                         |      1 |    254 |      6 |00:00:00.11 |
    |   3 |    TABLE ACCESS FULL                      | T3                      |      1 |   2849 |   2849 |00:00:00.01 |
    |*  4 |    HASH JOIN                              |                         |      1 |    254 |      6 |00:00:00.11 |
    |   5 |     TABLE ACCESS FULL                     | T3                      |      1 |   2849 |   2849 |00:00:00.01 |
    |   6 |     NESTED LOOPS                          |                         |      1 |        |      6 |00:00:00.10 |
    |   7 |      NESTED LOOPS                         |                         |      1 |    254 |   5012 |00:00:00.09 |
    |*  8 |       TABLE ACCESS BY INDEX ROWID         | T2                      |      1 |    262 |   5012 |00:00:00.06 |
    |*  9 |        INDEX RANGE SCAN                   | T2_OOST_START_DATE_I    |      1 |    857 |   7722 |00:00:00.01 |
    |* 10 |       INDEX RANGE SCAN                    | T1_OBST_OOST_DK_I       |   5012 |      1 |   5012 |00:00:00.03 |
    |* 11 |      TABLE ACCESS BY INDEX ROWID          | T1                      |   5012 |      1 |      6 |00:00:00.48 |
    |  12 |       NESTED LOOPS                        |                         |   1277 |        |      6 |00:00:00.46 |
    |  13 |        NESTED LOOPS                       |                         |   1277 |      2 |      6 |00:00:00.46 |
    |  14 |         PARTITION REFERENCE ALL           |                         |   1277 |      4 |      6 |00:00:00.46 |
    |* 15 |          TABLE ACCESS BY LOCAL INDEX ROWID| T4                      |  66380 |      4 |      6 |00:00:00.43 |
    |* 16 |           INDEX RANGE SCAN                | T4_OBSV_OBST_FK_I       |  66380 |     86 |      6 |00:00:00.28 |
    |* 17 |         INDEX UNIQUE SCAN                 | T5_VEH_PK               |      6 |      1 |      6 |00:00:00.01 |
    |* 18 |        TABLE ACCESS BY GLOBAL INDEX ROWID | T5                      |      6 |      1 |      6 |00:00:00.01 |
    Predicate Information (identified by operation id):
       2 - access("OOST"."CHP_ID_END"="CHP2"."CHP_ID")
       4 - access("OOST"."CHP_ID_START"="CHP1"."CHP_ID")
       8 - filter(("OOST"."CHP_ID_START" IS NOT NULL AND "OOST"."CHP_ID_END" IS NOT NULL))
       9 - access("OOST"."START_DATE">=TO_DATE(' 2013-11-20 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "OOST"."START_DATE"<=TO_DATE(' 2013-11-27
                  00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
      10 - access("OBST"."OOST_ID"="OOST"."OOST_ID")
      11 - filter(("OBST"."OBS_STAT"=2 AND ADD_MONTHS(INTERNAL_FUNCTION("OBST"."MOD_DATE"),13)>=SYSDATE@! AND  IS NOT NULL))
      15 - filter("OBSV"."START_DATE">:B1)
      16 - access("OBSV"."OBST_ID"=:B1)
      17 - access("OBSV"."VEH_ID"="VEH"."VEH_ID")
      18 - filter(("VEH"."ac_number">=1 AND "VEH"."ac_number"<=99999))
    Spot how the predicate 17 and 18 are now in the position I wanted them to be i.e probe first the T5 unique index using the join condition and then filter the table T5
    But, there is always a but, why am I obliged to hint?
    Where did I got something wrong (statistics, optimizer parameter, etc...) so that the CBO did not opted for this execution plan without a hint?
    Thanks
    Mohamed Houri

Maybe you are looking for

  • Arithmatic operations on fields in tables

    Hello Members, My query might seem pretty basic, but seems uphill to me, as i have no idea how to perform arithmatic operations between fields in tables. I have two tables temp1 and temp2. each of these tables have 2 fields : account no. and balance

  • The Safari Can't Find The Server - Error!

    After updating my iPad and Mac OSX to the latest version, I am constantly getting 'The Safari Can't find the server' error on valid addresses. I have to refresh a few times to access the website. I have gone through many posts and I gathere that it i

  • How to outline report regions

    Hi, I have a page with three report regions. Two (with column 1 and 2) on the region 4, and one in region 5 (with column 1). The report in region 5 starts 3 or 4 characters earlier on the page then the first report of region 4. How to get a correct o

  • Call front-end API from WD ABAP

    Hi experts,   I'm trying to call font-end API (Destination: SAP_SSFATGUI) from webdynpro. It giving me communication_error but if i call it from ABAP its working. Pls help.

  • Export PDF to Excel, won't open Acrobat files

    I bought a one year subscription to be able to export PDF files to Word or Excel.  I get an error message: "error occurred while trying to access service" when I try to export Acrobat PDF's.  I don't have Acrobat installed.  Why can't I open and expo