{"id":10610,"date":"2017-11-05T19:24:53","date_gmt":"2017-11-05T18:24:53","guid":{"rendered":"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-int-and-intint-views\/"},"modified":"2017-11-05T19:24:53","modified_gmt":"2017-11-05T18:24:53","slug":"multitenant-internals-int-and-intint-views","status":"publish","type":"post","link":"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-int-and-intint-views\/","title":{"rendered":"Multitenant internals: INT$ and INT$INT$ views"},"content":{"rendered":"

By Franck Pachot<\/h2>\n

.
\nThis month, I’ll talk – with lot of demos – about multitenant internals at DOAG conference<\/a>. \"CaptureMultitenantInternals\"<\/a>
\nThe multitenant dictionary architecture starts with a simple idea: system metadata and data are in CDB$ROOT and user metadata and data are in PDB. And it could have been that simple. When a session connected to a PDB needs to read some system information, the session context is switched to the CDB$ROOT container and reads from CDB$ROOT SYS tablespace and objects, and then switches back to the PDB container. This is implemented by metadata and data links: the PDB lists the objects for which the session has to switch to CDB$ROOT to get metadata or data. <\/p>\n

\"CaptureMultitenantInternals1\"<\/a>But, for compatibility reason, and ease of administration, the dictionary views must display information from both containers, transparently, and then things become a little more complex with common views and extended data views.<\/p>\n

At Oracle Open World, the multitenant architects, in the #PDBExpert session, answered questions about the multitenant architecture posted on Twitter. My first question (because I was investigating a bug<\/a> at that time) was about some views, such as INT$INT$DBA_CONSTRAINTS, introduced to implement the complexity of showing the same information in dictionary views as the ones we had on non-CDB. Of course, the architects didn’t want to go too far on this and had a very accurate answer: INT$ is for internal, and here you have two ‘INT$’ so you shouldn’t look at that.<\/p>\n

But I like to understand how things work and here is the explanation of these INT$INT$ views. And I’m not even sure that INT is for ‘internal’ but maybe ‘intermediate’. But for sure, the $ at the end is used by Oracle internal dictionary objects.<\/p>\n

<\/p>\n

INT$ Extended Data views<\/h3>\n

We are used to seeing all objects, system ones and user ones, listed by the dictionary views. For example, DBA_PROCEDURES shows all procedures, system and user ones, and then have to read from both containers (current PDB and CDB$ROOT) through extended data links. ALL_PROCEDURES shows all procedures accessible by the user, and they also have to switch to CDB$ROOT if the user has been granted to read system objects. USER_PROCEDURES shows only the objects owned by the current user, and then can read from the current container only.<\/p>\n

For the ease of the definition, in 12c<\/i> all the joins on the underlying tables(such as procedureinfo$, user$, obj$) is done by an intermediate view such as INT$DBA_PROCEDURES which is defined as EXTENDED DATA link to read from CDB$ROOT in addition to the local table. Then DBA_PROCEDURES, ALL_PROCEDURES and USER_PROCEDURES are defined on top of it with the required where clause to filter out owner and privilege accessibility.<\/p>\n

INT$INT$ Extended Data views<\/h3>\n

In this post, I’ll detail the special case of DBA_CONSTRAINTS because things are more complex to get the multitenant architecture behaving the same as the non-CDB.<\/p>\n

There are several types of constraints which are identified with the CONSTRAINT_TYPE column of DBA_CONSTRAINTS, or the TYPE# of the underlying table CDEF#<\/p>\n

Here, I query the underlying table with the CONTAINER() function to see what is stored in each container:<\/p>\n

\nSQL> select decode(type#,1,'C',2,'P',3,'U',4,'R',5,'V',6,'O',7,'C',8,'H',9,'F',10,'F',11,'F',13,'F','?') constraint_type,\n  2  type#,con_id,count(*) from containers(cdef$)\n  3  group by type#,con_id order by type#,con_id;\n \nCONSTRAINT_TYPE     TYPE#   CON_ID   COUNT(*)\n---------------     -----   ------   --------\nC                       1        1         74\nC                       1        3         74\nP                       2        1        843\nP                       2        3        844\nU                       3        1        238\nU                       3        3        238\nR                       4        1        324\nR                       4        3        324\nV                       5        1         11\nO                       6        1        172\nO                       6        3         26\nC                       7        1       5337\nC                       7        3       5337\nF                      11        1         11\nF                      11        3         11\n?                      12        1          3\n?                      12        3          3\n<\/code><\/pre>\n
I have very few user objects in this database. CON_ID=1 is CDB$ROOT and CON_ID=3 is my PDB. What we can see here is that we have nearly the same number of rows in both containers for the following constraint types: C (check constraint on a table), P (primary key), U (unique key), R (referential integrity), and other types related to tables. And some types have most of their rows in CDB$ROOT only: V (check option on views), R (read only on views)<\/p>\n
That’s an implementation specificity of the multitenant architecture which makes things more complex for the dictionary views. For some objects (such as procedures and views) the metadata is stored in only one container: system objects have all their information in CDB$ROOT and the PDB has only a link which is a dummy row in OBJ$ which mentions the sharing (such as metadata link), owner and name (to match to the object in CDB$ROOT), and a signature (to verify that the DDL creating the object is the same). But other objects (such as tables) have their information duplicated in all containers for system objects (CDB$ROOT, PDB$SEED and all user PDBs). This is the reason why we see rows in both containers for constraint definition when they are related to a table.<\/p>\n
Example on view constraint<\/h3>\n
I’ll take a constraint on system view as an example: constraint SYS_C003357 on table SYS.DBA_XS_SESSIONS<\/p>\n
\nSQL> select owner,object_name,object_type,sharing from dba_objects where owner='SYS' and object_name='DBA_XS_SESSIONS';\n \nOWNER   OBJECT_NAME       OBJECT_TYPE   SHARING\n-----   -----------       -----------   -------\nSYS     DBA_XS_SESSIONS   VIEW          METADATA LINK\n \nSQL> select owner,table_name,constraint_type,constraint_name from containers(dba_constraints) where owner='SYS' and table_name='DBA_XS_SESSIONS'  and rownum=1;\n \nOWNER   TABLE_NAME        CONSTRAINT_TYPE   CONSTRAINT_NAME\n-----   ----------        ---------------   ---------------\nSYS     DBA_XS_SESSIONS   O                 SYS_C003357\n<\/code><\/pre>\n
I’m looking at the dependencies for the DBA_CONSTRAINTS view:<\/p>\n
\nSQL> select owner,name,referenced_owner,referenced_name from dba_dependencies where owner='SYS' and name='DBA_CONSTRAINTS' and type='VIEW';\n \nOWNER   NAME              REFERENCED_OWNER   REFERENCED_NAME\n-----   ----              ----------------   ---------------\nSYS     DBA_CONSTRAINTS   SYS                GETLONG\nSYS     DBA_CONSTRAINTS   SYS                INT$DBA_CONSTRAINTS\n<\/code><\/pre>\n
So the DBA_CONSTRAINT is a view on INT$DBA_CONSTRAINTS as we have seen above. However, this view is not directly reading the tables but another view:<\/p>\n
\nSQL> select owner,name,referenced_owner,referenced_name from dba_dependencies where owner='SYS' and name='INT$DBA_CONSTRAINTS' and type='VIEW';\n \nOWNER   NAME                  REFERENCED_OWNER   REFERENCED_NAME\n-----   ----                  ----------------   ---------------\nSYS     INT$DBA_CONSTRAINTS   SYS                GETLONG\nSYS     INT$DBA_CONSTRAINTS   SYS                INT$INT$DBA_CONSTRAINTS\n<\/code><\/pre>\n
Here is our additional INT$INT$ view which is reading the tables:<\/p>\n
\nSQL> select owner,name,referenced_owner,referenced_name from dba_dependencies where owner='SYS' and name='INT$INT$DBA_CONSTRAINTS' and type='VIEW';\n \nOWNER   NAME                      REFERENCED_OWNER   REFERENCED_NAME\n-----   ----                      ----------------   ---------------\nSYS     INT$INT$DBA_CONSTRAINTS   SYS                USER$\nSYS     INT$INT$DBA_CONSTRAINTS   SYS                CDEF$\nSYS     INT$INT$DBA_CONSTRAINTS   SYS                OBJ$\nSYS     INT$INT$DBA_CONSTRAINTS   SYS                CON$\nSYS     INT$INT$DBA_CONSTRAINTS   SYS                _CURRENT_EDITION_OBJ\nSYS     INT$INT$DBA_CONSTRAINTS   SYS                _BASE_USER\nSYS     INT$INT$DBA_CONSTRAINTS   SYS                GETLONG\n<\/code><\/pre>\n
In summary, the EXTENDED DATA view which reads the tables on each container (CDB$ROOT and PDB) is here the INT$INT$DBA_CONSTRAINTS and the INT$DBA_CONSTRAINTS is another intermediate one before the DBA_CONSTRAINTS view.<\/p>\n
\nSQL> select owner,object_name,object_type,sharing from dba_objects where object_name in ('DBA_CONSTRAINTS','INT$DBA_CONSTRAINTS','INT$INT$DBA_CONSTRAINTS') order by object_id desc;\n \nOWNER    OBJECT_NAME               OBJECT_TYPE   SHARING\n-----    -----------               -----------   -------\nPUBLIC   DBA_CONSTRAINTS           SYNONYM       METADATA LINK\nSYS      DBA_CONSTRAINTS           VIEW          METADATA LINK\nSYS      INT$DBA_CONSTRAINTS       VIEW          METADATA LINK\nSYS      INT$INT$DBA_CONSTRAINTS   VIEW          EXTENDED DATA LINK\n<\/code><\/pre>\n
In this example, we don’t understand the reason for the additional intermediate view because the return all the same number of rows in each container:<\/p>\n
\nSQL> select con_id,constraint_type,constraint_name from containers(INT$INT$DBA_CONSTRAINTS) where OWNER='SYS' and constraint_name='SYS_C003357'\n \n  CON_ID CONSTRAINT_TYPE   CONSTRAINT_NAME\n  ------ ---------------   ---------------\n       1 O                 SYS_C003357\n       3 O                 SYS_C003357\n \nSQL> select con_id,constraint_type,constraint_name from containers(INT$DBA_CONSTRAINTS) where OWNER='SYS' and constraint_name='SYS_C003357'\n \n  CON_ID CONSTRAINT_TYPE   CONSTRAINT_NAME\n  ------ ---------------   ---------------\n       1 O                 SYS_C003357\n       3 O                 SYS_C003357\n \nSQL> select con_id,constraint_type,constraint_name from containers(DBA_CONSTRAINTS) where OWNER='SYS' and constraint_name='SYS_C003357'\n \n  CON_ID CONSTRAINT_TYPE   CONSTRAINT_NAME\n  ------ ---------------   ---------------\n       1 O                 SYS_C003357\n       3 O                 SYS_C003357\n<\/code><\/pre>\n
The difference is only a few additional columns from the object definition (OWNERID,OBJECT_ID,OBJECT_TYPE#,SHARING) in the INT$ and INT$INT$ which are not selected in the final view:<\/p>\n
\nSQL> select * from containers(INT$INT$DBA_CONSTRAINTS) where OWNER='SYS' and constraint_name='SYS_C003357'\n \nOWNER     OWNERID CONSTRAINT_NAME   CONSTRAINT_TYPE   TABLE_NAME          OBJECT_ID   OBJECT_TYPE# 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   CON_ID\n-----     ------- ---------------   ---------------   ----------          ---------   ------------ -------------------   -------   -----------------   -----------   ------    ----------       --------    ---------       ---------        ---   ----   -----------   -----------   ----------   -------   ------------     -------   -------------   ------\nSYS             0 SYS_C003357       O                 DBA_XS_SESSIONS         10316              4                                                                   ENABLED   NOT DEFERRABLE   IMMEDIATE   NOT VALIDATED   GENERATED NAME                26-JAN-17                                                                 1               1        1\nSYS             0 SYS_C003357       O                 DBA_XS_SESSIONS         10316              4                                                                   ENABLED   NOT DEFERRABLE   IMMEDIATE   NOT VALIDATED   GENERATED NAME                26-JAN-17                                                                 1               1        3\n \nSQL> select * from containers(INT$DBA_CONSTRAINTS) where OWNER='SYS' and constraint_name='SYS_C003357'\n \nOWNER     OWNERID CONSTRAINT_NAME   CONSTRAINT_TYPE   TABLE_NAME          OBJECT_ID   OBJECT_TYPE# 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   CON_ID\n-----     ------- ---------------   ---------------   ----------          ---------   ------------ -------------------   -------   -----------------   -----------   ------    ----------       --------    ---------       ---------        ---   ----   -----------   -----------   ----------   -------   ------------     -------   -------------   ------\nSYS             0 SYS_C003357       O                 DBA_XS_SESSIONS         10316              4                                                                   ENABLED   NOT DEFERRABLE   IMMEDIATE   NOT VALIDATED   GENERATED NAME                26-JAN-17                                                                 1               1        1\nSYS             0 SYS_C003357       O                 DBA_XS_SESSIONS         10316              4                                                                   ENABLED   NOT DEFERRABLE   IMMEDIATE   NOT VALIDATED   GENERATED NAME                26-JAN-17                                                                 1               1        3\n \nSQL> select * from containers(DBA_CONSTRAINTS) where OWNER='SYS' and constraint_name='SYS_C003357'\n \nOWNER   CONSTRAINT_NAME   CONSTRAINT_TYPE   TABLE_NAME        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   CON_ID\n-----   ---------------   ---------------   ----------        -------------------   -------   -----------------   -----------   ------    ----------       --------    ---------       ---------        ---   ----   -----------   -----------   ----------   -------   ------------     -------------   ------\nSYS     SYS_C003357       O                 DBA_XS_SESSIONS                                                                     ENABLED   NOT DEFERRABLE   IMMEDIATE   NOT VALIDATED   GENERATED NAME                26-JAN-17                                                                       1        1\nSYS     SYS_C003357       O                 DBA_XS_SESSIONS                                                                     ENABLED   NOT DEFERRABLE   IMMEDIATE   NOT VALIDATED   GENERATED NAME                26-JAN-17   \n<\/code><\/pre>\n
If we look at the INT$DBA_CONSTRAINTS definition we see some filters on those object definition:<\/p>\n
\nSQL> ddl INT$DBA_CONSTRAINTS\n \n  CREATE OR REPLACE FORCE NONEDITIONABLE VIEW \"SYS\".\"INT$DBA_CONSTRAINTS\" (\"OWNER\", \"OWNERID\", \"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\n  select OWNER, OWNERID, CONSTRAINT_NAME, CONSTRAINT_TYPE,\n       TABLE_NAME, OBJECT_ID, OBJECT_TYPE#, SEARCH_CONDITION,\n       SEARCH_CONDITION_VC, R_OWNER, R_CONSTRAINT_NAME, DELETE_RULE, STATUS,\n       DEFERRABLE, DEFERRED, VALIDATED, GENERATED,\n       BAD, RELY, LAST_CHANGE, INDEX_OWNER, INDEX_NAME,\n       INVALID, VIEW_RELATED, SHARING, ORIGIN_CON_ID\nfrom   INT$INT$DBA_CONSTRAINTS INT$INT$DBA_CONSTRAINTS\nwhere  INT$INT$DBA_CONSTRAINTS.OBJECT_TYPE# = 4         \/* views *\/\n       OR (INT$INT$DBA_CONSTRAINTS.OBJECT_TYPE# = 2     \/* tables *\/\n           AND (INT$INT$DBA_CONSTRAINTS.ORIGIN_CON_ID\n                = TO_NUMBER(SYS_CONTEXT('USERENV', 'CON_ID'))));\n<\/code><\/pre>\n
For views (OBJECT_TYPE#=4) there is no filter, which explains why we see the same number of rows in the previous example. But for tables (OBJECT_TYPE#=2) there’s an additional filter to keep the row from the current container only.<\/p>\n
Example on table constraint<\/h3>\n
Then, I’ll take another example with a constraint definition for a table:<\/p>\n
\nSQL> select owner,object_name,object_type,sharing from dba_objects where owner='SYS' and object_name='RXS$SESSIONS';\n \nOWNER   OBJECT_NAME    OBJECT_TYPE   SHARING\n-----   -----------    -----------   -------\nSYS     RXS$SESSIONS   TABLE         METADATA LINK\n \nSQL> select owner,table_name,constraint_type,constraint_name from dba_constraints where owner='SYS' and table_name='RXS$SESSIONS' and rownum=1;\n \nOWNER   TABLE_NAME     CONSTRAINT_TYPE   CONSTRAINT_NAME\n-----   ----------     ---------------   ---------------\nSYS     RXS$SESSIONS   C                 SYS_C003339\n<\/code><\/pre>\n
From the INT$INT$ view, we have a duplicate when we query on a PDB because for tables the PDB not only holds a dummy row in OBJ$ but full information about the table is duplicated in other tables such as TAB$ and CDEF$:<\/p>\n
\nSQL> select con_id,constraint_type,constraint_name from containers(INT$INT$DBA_CONSTRAINTS) where OWNER='SYS' and constraint_name='SYS_C003339'\n \n  CON_ID CONSTRAINT_TYPE   CONSTRAINT_NAME\n  ------ ---------------   ---------------\n       1 C                 SYS_C003339\n       3 C                 SYS_C003339\n       3 C                 SYS_C003339\n<\/code><\/pre>\n
This is the reason for the additional intermediate view: filtering out those duplicate by removing the rows from CDB$ROOT when queried from a PDB.<\/p>\n
\nSQL> select con_id,constraint_type,constraint_name from containers(INT$DBA_CONSTRAINTS) where OWNER='SYS' and constraint_name='SYS_C003339'\n \n  CON_ID CONSTRAINT_TYPE   CONSTRAINT_NAME\n  ------ ---------------   ---------------\n       1 C                 SYS_C003339\n       3 C                 SYS_C003339\n<\/code><\/pre>\n
Thanks to that, the duplicates are not visible to the end-user views DBA_CONSTRAINTS and PDB_CONSTRAINTS.<\/p>\n
You may wonder why only DBA_CONSTRAINTS needs this views and not DBA_TABLES, DBA_INDEXES or DBA_TAB_COLUMNS? That’s because all information about system tables and indexes are replicated in all PDBs and then there is no need for EXTENDED DATA and context switches. DBA_CONSTRAINT has the particularity of showing information about tables and views, which implement the metadata links in a different way.<\/p>\n","protected":false},"excerpt":{"rendered":"
By Franck Pachot . This month, I’ll talk – with lot of demos – about multitenant internals at DOAG conference. The multitenant dictionary architecture starts with a simple idea: system metadata and data are in CDB$ROOT and user metadata and data are in PDB. And it could have been that simple. When a session connected […]<\/p>\n","protected":false},"author":27,"featured_media":10611,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[59],"tags":[220,455,64,209,875,66,223],"type_dbi":[],"class_list":["post-10610","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oracle","tag-cdb","tag-internals","tag-multitenant","tag-oracle-12c","tag-oracle-multitenant","tag-pdb","tag-pluggable-databases"],"acf":[],"yoast_head":"\nMultitenant internals: INT$ and INT$INT$ views - dbi Blog<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-int-and-intint-views\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Multitenant internals: INT$ and INT$INT$ views\" \/>\n<meta property=\"og:description\" content=\"By Franck Pachot . This month, I’ll talk – with lot of demos – about multitenant internals at DOAG conference. The multitenant dictionary architecture starts with a simple idea: system metadata and data are in CDB$ROOT and user metadata and data are in PDB. And it could have been that simple. When a session connected […]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-int-and-intint-views\/\" \/>\n<meta property=\"og:site_name\" content=\"dbi Blog\" \/>\n<meta property=\"article:published_time\" content=\"2017-11-05T18:24:53+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/CaptureMultitenantInternals.png\" \/>\n\t<meta property=\"og:image:width\" content=\"1229\" \/>\n\t<meta property=\"og:image:height\" content=\"752\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"author\" content=\"Oracle Team\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Oracle Team\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"12 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-int-and-intint-views\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-int-and-intint-views\/\"},\"author\":{\"name\":\"Oracle Team\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee\"},\"headline\":\"Multitenant internals: INT$ and INT$INT$ views\",\"datePublished\":\"2017-11-05T18:24:53+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-int-and-intint-views\/\"},\"wordCount\":1173,\"commentCount\":0,\"image\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-int-and-intint-views\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/CaptureMultitenantInternals.png\",\"keywords\":[\"CDB\",\"internals\",\"multitenant\",\"Oracle 12c\",\"Oracle Multitenant\",\"PDB\",\"Pluggable Databases\"],\"articleSection\":[\"Oracle\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-int-and-intint-views\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-int-and-intint-views\/\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-int-and-intint-views\/\",\"name\":\"Multitenant internals: INT$ and INT$INT$ views - dbi Blog\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-int-and-intint-views\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-int-and-intint-views\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/CaptureMultitenantInternals.png\",\"datePublished\":\"2017-11-05T18:24:53+00:00\",\"author\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee\"},\"breadcrumb\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-int-and-intint-views\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-int-and-intint-views\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-int-and-intint-views\/#primaryimage\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/CaptureMultitenantInternals.png\",\"contentUrl\":\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/CaptureMultitenantInternals.png\",\"width\":1229,\"height\":752},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-int-and-intint-views\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Accueil\",\"item\":\"https:\/\/www.dbi-services.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Multitenant internals: INT$ and INT$INT$ views\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#website\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/\",\"name\":\"dbi Blog\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/www.dbi-services.com\/blog\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee\",\"name\":\"Oracle Team\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/secure.gravatar.com\/avatar\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g\",\"caption\":\"Oracle Team\"},\"url\":\"https:\/\/www.dbi-services.com\/blog\/author\/oracle-team\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"Multitenant internals: INT$ and INT$INT$ views - dbi Blog","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-int-and-intint-views\/","og_locale":"en_US","og_type":"article","og_title":"Multitenant internals: INT$ and INT$INT$ views","og_description":"By Franck Pachot . This month, I’ll talk – with lot of demos – about multitenant internals at DOAG conference. The multitenant dictionary architecture starts with a simple idea: system metadata and data are in CDB$ROOT and user metadata and data are in PDB. And it could have been that simple. When a session connected […]","og_url":"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-int-and-intint-views\/","og_site_name":"dbi Blog","article_published_time":"2017-11-05T18:24:53+00:00","og_image":[{"width":1229,"height":752,"url":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/CaptureMultitenantInternals.png","type":"image\/png"}],"author":"Oracle Team","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Oracle Team","Est. reading time":"12 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-int-and-intint-views\/#article","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-int-and-intint-views\/"},"author":{"name":"Oracle Team","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee"},"headline":"Multitenant internals: INT$ and INT$INT$ views","datePublished":"2017-11-05T18:24:53+00:00","mainEntityOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-int-and-intint-views\/"},"wordCount":1173,"commentCount":0,"image":{"@id":"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-int-and-intint-views\/#primaryimage"},"thumbnailUrl":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/CaptureMultitenantInternals.png","keywords":["CDB","internals","multitenant","Oracle 12c","Oracle Multitenant","PDB","Pluggable Databases"],"articleSection":["Oracle"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.dbi-services.com\/blog\/multitenant-internals-int-and-intint-views\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-int-and-intint-views\/","url":"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-int-and-intint-views\/","name":"Multitenant internals: INT$ and INT$INT$ views - dbi Blog","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-int-and-intint-views\/#primaryimage"},"image":{"@id":"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-int-and-intint-views\/#primaryimage"},"thumbnailUrl":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/CaptureMultitenantInternals.png","datePublished":"2017-11-05T18:24:53+00:00","author":{"@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee"},"breadcrumb":{"@id":"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-int-and-intint-views\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.dbi-services.com\/blog\/multitenant-internals-int-and-intint-views\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-int-and-intint-views\/#primaryimage","url":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/CaptureMultitenantInternals.png","contentUrl":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/CaptureMultitenantInternals.png","width":1229,"height":752},{"@type":"BreadcrumbList","@id":"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-int-and-intint-views\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Accueil","item":"https:\/\/www.dbi-services.com\/blog\/"},{"@type":"ListItem","position":2,"name":"Multitenant internals: INT$ and INT$INT$ views"}]},{"@type":"WebSite","@id":"https:\/\/www.dbi-services.com\/blog\/#website","url":"https:\/\/www.dbi-services.com\/blog\/","name":"dbi Blog","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.dbi-services.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee","name":"Oracle Team","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g","caption":"Oracle Team"},"url":"https:\/\/www.dbi-services.com\/blog\/author\/oracle-team\/"}]}},"_links":{"self":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/10610","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/users\/27"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/comments?post=10610"}],"version-history":[{"count":0,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/10610\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/media\/10611"}],"wp:attachment":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/media?parent=10610"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/categories?post=10610"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/tags?post=10610"},{"taxonomy":"type","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/type_dbi?post=10610"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}