在12c的$ORACLE_HOME/rdbms/admin下找到 INT$DBA_CONSTRAINTS 的定义
[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;
于是定位到下面的一行:
./cdcore.sql:14191:create or replace view INT$DBA_CONSTRAINTS
然后vi cdcore.sql ,找到如下的信息:
-- 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) as select 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 from INT$INT$DBA_CONSTRAINTS INT$INT$DBA_CONSTRAINTS where 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) as select 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 from INT$DBA_CONSTRAINTS /
郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。