Bug in FGAC (11g)

Question

Hello,
I perform this script under system user
create user test_schema
identified by 111;
alter user test_schema quota unlimited on users;
create table TEST_SCHEMA.TBL1
  ID        NUMBER not null,
  TBL2_ID NUMBER
alter table TEST_SCHEMA.TBL1
  add constraint TBL1_PK primary key (ID);
create index TEST_SCHEMA.TBL1_FK_I on TEST_SCHEMA.TBL1 (TBL2_ID);
create table TEST_SCHEMA.TBL2
  ID NUMBER not null
alter table TEST_SCHEMA.TBL2
  add constraint TBL2_PK primary key (ID);
insert into TEST_SCHEMA.tbl2(ID)
( select level from dual
connect by level < 30 );
insert into TEST_SCHEMA.tbl1(ID,TBL2_ID)
( select level, trunc(dbms_random.value(1,30)) from dual
connect by level < 8000 );
commit;
create function test_schema.vpd_getaccess_read(
  obj_schema in varchar2, -- схема таблицы
  obj_name in varchar2    -- имя таблицы
return varchar2
as
begin  
    return '(ID in (2,3))';
end vpd_getaccess_read;
begin
     DBMS_RLS.ADD_POLICY( OBJECT_SCHEMA   => 'TEST_SCHEMA',
                          OBJECT_NAME     =>  'TBL2',
                          POLICY_NAME     => 'READOF_TBL2',
                          FUNCTION_SCHEMA => 'TEST_SCHEMA',
                          POLICY_FUNCTION => 'VPD_GETACCESS_READ',
                          STATEMENT_TYPES => 'SELECT' );
     commit;
end;
select t1.*
/*     , t2.id*/
from TEST_SCHEMA.tbl1 t1,
     TEST_SCHEMA.tbl2 t2
where t1.tbl2_id = t2.id(+)Query returns 0 rows.
select t1.*
     , t2.id
from TEST_SCHEMA.tbl1 t1,
     TEST_SCHEMA.tbl2 t2
where t1.tbl2_id = t2.id(+)Query returns 7999 rows.
Oracle Database 11.2.0.1.0
Does anybody know solution?
Igor

Answer 1

Same in 10.2.0.4.0:
SQL> explain plan for
  2   select t1.*
  3       , t2.id
  4  from TEST_SCHEMA.tbl1 t1,
  5       TEST_SCHEMA.tbl2 t2
  6  where t1.tbl2_id = t2.id(+)
  7  /
Explained.
SQL> @?\rdbms\admin\utlxpls
PLAN_TABLE_OUTPUT
Plan hash value: 1646294756
| Id  | Operation             | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT      |         |  7999 |   304K|     9  (12)| 00:00:01 |
|*  1 |  HASH JOIN RIGHT OUTER|         |  7999 |   304K|     9  (12)| 00:00:01 |
|   2 |   VIEW                | TBL2    |     2 |    26 |     2   (0)| 00:00:01 |
|   3 |    INLIST ITERATOR    |         |       |       |            |          |
|*  4 |     INDEX UNIQUE SCAN | TBL2_PK |     2 |    26 |     2   (0)| 00:00:01 |
|   5 |   TABLE ACCESS FULL   | TBL1    |  7999 |   203K|     6   (0)| 00:00:01 |
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
   1 - access("T1"."TBL2_ID"="T2"."ID"(+))
   4 - access("ID"=2 OR "ID"=3)
Note
   - dynamic sampling used for this statement
22 rows selected.
SQL> explain plan for
  2  select count(*) from (
  3   select t1.*
  4       , t2.id
  5  from TEST_SCHEMA.tbl1 t1,
  6       TEST_SCHEMA.tbl2 t2
  7  where t1.tbl2_id = t2.id(+)
  8  )
  9  /
Explained.
SQL> @?\rdbms\admin\utlxpls
PLAN_TABLE_OUTPUT
Plan hash value: 3130026541
| Id  | Operation              | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT       |         |     1 |    26 |     9  (12)| 00:00:01 |
|   1 |  SORT AGGREGATE        |         |     1 |    26 |            |          |
|*  2 |   HASH JOIN RIGHT OUTER|         |  7999 |   203K|     9  (12)| 00:00:01 |
|   3 |    VIEW                | TBL2    |     2 |    26 |     2   (0)| 00:00:01 |
|   4 |     INLIST ITERATOR    |         |       |       |            |          |
|*  5 |      INDEX UNIQUE SCAN | TBL2_PK |     2 |    26 |     2   (0)| 00:00:01 |
PLAN_TABLE_OUTPUT
|   6 |    TABLE ACCESS FULL   | TBL1    |  7999 |   101K|     6   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("T1"."TBL2_ID"="T2"."ID"(+))
   5 - access("ID"=2 OR "ID"=3)
Note
PLAN_TABLE_OUTPUT
   - dynamic sampling used for this statement
23 rows selected.
SQL> explain plan for
  2  select t1.*
  3  /*     , t2.id*/
  4  from TEST_SCHEMA.tbl1 t1,
  5       TEST_SCHEMA.tbl2 t2
  6  where t1.tbl2_id = t2.id(+)
  7  /
Explained.
SQL> @?\rdbms\admin\utlxpls
PLAN_TABLE_OUTPUT
Plan hash value: 1646294756
| Id  | Operation             | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT      |         |  7999 |   304K|     9  (12)| 00:00:01 |
|*  1 |  HASH JOIN RIGHT OUTER|         |  7999 |   304K|     9  (12)| 00:00:01 |
|   2 |   VIEW                | TBL2    |     2 |    26 |     2   (0)| 00:00:01 |
|   3 |    INLIST ITERATOR    |         |       |       |            |          |
|*  4 |     INDEX UNIQUE SCAN | TBL2_PK |     2 |    26 |     2   (0)| 00:00:01 |
|   5 |   TABLE ACCESS FULL   | TBL1    |  7999 |   203K|     6   (0)| 00:00:01 |
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
   1 - access("T1"."TBL2_ID"="T2"."ID"(+))
   4 - access("ID"=2 OR "ID"=3)
Note
   - dynamic sampling used for this statement
22 rows selected.
SQL> So first difference is in FGA+outer join. In 10g policy produces predicate ID in (2,3) no matter what. In 11g it is smart enough to change ID in (2,3) with ("ID"(+)=2 OR "ID"(+)=3). However, when it realizes there is no t2 in select list it tries to optimize it with filter(NULL IS NOT NULL) which always retults in FALSE while it shoul not use any filters at all and just do full scan of t1 or at least apply filter(NULL IS NULL) which always retults in TRUE. So yes, it does sound like a bug and you should open a SR.
SY.