DBMS_OLAP.VALIDATE_DIMENSION validates a dimension and inserts bad rows into 
system.mview_exceptions. But if you run VALIDATE_DIMENSION as a user that 
doesn't own the dimension, the rows are not shown in mview_exceptions. Why?

I. TEST in 9i (If you use 10g, DBMS_OLAP is deprecated in favor of 
DBMS_DIMENSION.)

As yong (a user that happens to have DBA role):
******************************************************************
create table t (n number);
insert into t values (null);
create dimension d level l is t.n;
create or replace procedure pp as
 n number;
begin
 dbms_olap.create_id(n);
 dbms_output.put_line(n);
 dbms_olap.validate_dimension('D', 'YONG', false, true, n);
end;
/
set serverout on
exec pp
select * from system.mview_exceptions;
******************************************************************
You see the bad rows in the view as expected, because t has null values.

******************************************************************
create user u identified by u default tablespace users temporary tablespace 
temp;
grant create session to u;
grant execute on pp to u;
conn u/u
set serverout on
exec yong.pp
******************************************************************

Back to yong:
select * from system.mview_exceptions;
You don't see new rows inserted.


II. RESEARCH

Now execute the procedure as yong and u but with SQL trace enabled (have to use 
event 10046 level 4 to see bind variable values).
******************************************************************
alter session set events = '10046 trace name context forever, level 4';
exec pp
alter session set events = '10046 trace name context off';
******************************************************************
Replace pp with yong.pp when run as u.

Look for the cursor "INSERT INTO SYSTEM.MVIEW$_ADV_EXCEPTIONS..." in 
the trace files for both sessions. Also look for "INSERT INTO 
system.mview$_adv_log...". You see they both ran successfully.

Then look at the definition of mview_exceptions:
******************************************************************
SQL> set long 1000
SQL> select text from dba_views where view_name = 'MVIEW_EXCEPTIONS' and owner = 'SYSTEM';

TEXT
--------------------------------------------------------------------------------
select
  t1.runid# as runid,
  owner,
  table_name,
  dimension_name,
  relationship,
  bad_rowid
from SYSTEM.MVIEW$_ADV_EXCEPTIONS t1, SYSTEM.MVIEW$_ADV_LOG t2, ALL_USERS u
where
  t1.runid# = t2.runid# and
  u.username = t2.uname and
  u.user_id = userenv('SCHEMAID')
******************************************************************
Based on the view definition, you can find the rows inserted by user u in these two
tables, SYSTEM.MVIEW$_ADV_EXCEPTIONS and SYSTEM.MVIEW$_ADV_LOG. Indeed they are 
in there. What pervents mview_exceptions from showing them is the last line of 
the view definition u.user_id = userenv('SCHEMAID').

So, the workaround to see the bad rows is run the query behind the view directly without the last filter:
select
  t1.runid# as runid,
  owner,
  table_name,
  dimension_name,
  relationship,
  bad_rowid
from SYSTEM.MVIEW$_ADV_EXCEPTIONS t1, SYSTEM.MVIEW$_ADV_LOG t2, ALL_USERS u
where
  t1.runid# = t2.runid# and
  u.username = t2.uname;
instead of select * from system.mview_exceptions.