Locate the INT $ DBA_CONSTRAINTS definition under $ ORACLE_HOME/rdbms/admin in 12c, dbaconstraints
[oracle@rhel59 admin]$ pwd/u01/app/oracle/product/12.1.0/dbhome_1/rdbms/admin[oracle@rhel59 admin]$ grep -rn 'INT$DBA_CONSTRAINTS' ././e1201000.sql:138:Rem thbaby 09/17/13 - lrg 9710290: reload INT$DBA_CONSTRAINTS./e1201000.sql:150:Rem thbaby 08/13/13 - 16956123: drop view INT$INT$DBA_CONSTRAINTS./e1201000.sql:881:drop view INT$INT$DBA_CONSTRAINTS;./e1201000.sql:883:-- lrg 9710290: 12.1.0.2->12.1.0.1 downgrade drops INT$INT$DBA_CONSTRAINTS, ./e1201000.sql:884:-- which causes INT$DBA_CONSTRAINTS to be marked invalid. This, in turn, ./e1201000.sql:887:-- definition of INT$DBA_CONSTRAINTS right after INT$INT$DBA_CONSTRAINTS ./e1201000.sql:889:create or replace view INT$DBA_CONSTRAINTS COMMON_DATA ./cdcore.sql:37:Rem querying INT$DBA_CONSTRAINTS./cdcore.sql:76:Rem thbaby 05/31/13 - 16813682: INT$DBA_CONSTRAINTS is not common data ./cdcore.sql:14122:create or replace view INT$INT$DBA_CONSTRAINTS COMMON_DATA ./cdcore.sql:14181:-- INT$DBA_CONSTRAINTS has two object types - a view and a table../cdcore.sql:14191:create or replace view INT$DBA_CONSTRAINTS./cdcore.sql:14205:from INT$INT$DBA_CONSTRAINTS INT$INT$DBA_CONSTRAINTS./cdcore.sql:14206:where INT$INT$DBA_CONSTRAINTS.OBJECT_TYPE# = 4./cdcore.sql:14207: OR (INT$INT$DBA_CONSTRAINTS.OBJECT_TYPE# = 2./cdcore.sql:14208: AND (INT$INT$DBA_CONSTRAINTS.ORIGIN_CON_ID IN (0,1)./cdcore.sql:14209: OR INT$INT$DBA_CONSTRAINTS.SHARING = 0))./cdcore.sql:14211:-- Even though DBA_CONSTRAINTS and INT$DBA_CONSTRAINTS look very similar ./cdcore.sql:14213:-- selects fewer columns than INT$DBA_CONSTRAINTS../cdcore.sql:14228:from INT$DBA_CONSTRAINTS ./cdcore.sql:14320:from NO_ROOT_SW_FOR_LOCAL(INT$INT$DBA_CONSTRAINTS) INT$INT$DBA_CONSTRAINTS./cdcore.sql:14321:where INT$INT$DBA_CONSTRAINTS.OBJECT_TYPE# = 4 /* views */./cdcore.sql:14322: and INT$INT$DBA_CONSTRAINTS.OWNER=SYS_CONTEXT('USERENV', 'CURRENT_USER')./cdcore.sql:14330:from NO_COMMON_DATA(INT$INT$DBA_CONSTRAINTS) INT$INT$DBA_CONSTRAINTS./cdcore.sql:14331:where INT$INT$DBA_CONSTRAINTS.OBJECT_TYPE# = 2 /* tables */./cdcore.sql:14332: and INT$INT$DBA_CONSTRAINTS.OWNER=SYS_CONTEXT('USERENV', 'CURRENT_USER')./cdcore.sql:14416:from INT$DBA_CONSTRAINTS ./upobjxt.lst:60914:SYS,INT$DBA_CONSTRAINTS,,4, ./upobjxt.lst:61068:SYS,INT$INT$DBA_CONSTRAINTS,,4, ./e1102000.sql:9039:drop view INT$DBA_CONSTRAINTS;
Locate the following line:
./cdcore.sql:14191:create or replace view INT$DBA_CONSTRAINTS
Then vi cdcore. SQL finds the following information:
-- INT$DBA_CONSTRAINTS has two object types - a view and a table.-- The dictionary information about linked views is stored only in ROOT,-- with a dummy obj$ row in PDB to indicate this. Hence we can use common-- data view mechanism to fetch view constraints.-- The dictionary information about linked tables however is stored in-- all the containers. Hence using common data view mechanism would fetch-- duplicate constraints. So we added a condition that if the object is-- a not a linked table then fetch the constraint and if it is a linked-- table then fetch the constraint only if the origin con id is root or-- non-cdb.create or replace view INT$DBA_CONSTRAINTS (OWNER, CONSTRAINT_NAME, CONSTRAINT_TYPE, TABLE_NAME, OBJECT_ID, OBJECT_TYPE#, SEARCH_CONDITION, SEARCH_CONDITION_VC, R_OWNER, R_CONSTRAINT_NAME, DELETE_RULE, STATUS, DEFERRABLE, DEFERRED, VALIDATED, GENERATED, BAD, RELY, LAST_CHANGE, INDEX_OWNER, INDEX_NAME, INVALID, VIEW_RELATED, SHARING, ORIGIN_CON_ID)asselect OWNER, CONSTRAINT_NAME, CONSTRAINT_TYPE, TABLE_NAME, OBJECT_ID, OBJECT_TYPE#, SEARCH_CONDITION, SEARCH_CONDITION_VC, R_OWNER, R_CONSTRAINT_NAME, DELETE_RULE, STATUS, DEFERRABLE, DEFERRED, VALIDATED, GENERATED, BAD, RELY, LAST_CHANGE, INDEX_OWNER, INDEX_NAME, INVALID, VIEW_RELATED, SHARING, ORIGIN_CON_IDfrom INT$INT$DBA_CONSTRAINTS INT$INT$DBA_CONSTRAINTSwhere INT$INT$DBA_CONSTRAINTS.OBJECT_TYPE# = 4 OR (INT$INT$DBA_CONSTRAINTS.OBJECT_TYPE# = 2 AND (INT$INT$DBA_CONSTRAINTS.ORIGIN_CON_ID IN (0,1) OR INT$INT$DBA_CONSTRAINTS.SHARING = 0))/-- Even though DBA_CONSTRAINTS and INT$DBA_CONSTRAINTS look very similar-- in their definitions, we need both these views because DBA_CONSTRAINTS-- selects fewer columns than INT$DBA_CONSTRAINTS.create or replace view DBA_CONSTRAINTS (OWNER, CONSTRAINT_NAME, CONSTRAINT_TYPE, TABLE_NAME, SEARCH_CONDITION, SEARCH_CONDITION_VC, R_OWNER, R_CONSTRAINT_NAME, DELETE_RULE, STATUS, DEFERRABLE, DEFERRED, VALIDATED, GENERATED, BAD, RELY, LAST_CHANGE, INDEX_OWNER, INDEX_NAME, INVALID, VIEW_RELATED, ORIGIN_CON_ID)asselect OWNER, CONSTRAINT_NAME, CONSTRAINT_TYPE, TABLE_NAME, SEARCH_CONDITION, SEARCH_CONDITION_VC, R_OWNER, R_CONSTRAINT_NAME, DELETE_RULE, STATUS, DEFERRABLE, DEFERRED, VALIDATED, GENERATED, BAD, RELY, LAST_CHANGE, INDEX_OWNER, INDEX_NAME, INVALID, VIEW_RELATED, ORIGIN_CON_IDfrom INT$DBA_CONSTRAINTS/