https:\/\/www.dbi-services.com\/blog\/12c-multitenant-internals-pdb-replay-ddl-for-common-users<\/a> I’ve done some DDL on a common user to show how this is replayed later for PDBs that were not opened at that time. But what happens when one of the DDL fails on one PDB?
\n<\/p>\nPDB$LASTREPLAY<\/h3>\n
In the last post, the C##USER1 common user was created and all pluggable databases (PDB1 with con_id=3 and PDB2 with con_id=4) were opened and synchronized:<\/p>\n
\nSQL> select con_id,scnwrp,scnbas,ctime,name,auxname1,auxname2,opcode,replay#,sqlstmt from containers(pdb_sync$) where opcode=-1 and bitand(flags,8)!=8 order by con_id,replay#;\n \n CON_ID SCNWRP SCNBAS CTIME NAME AUXNAME1 AUXNAME2 OPCODE REPLAY# SQLSTMT\n ------ ------ ------ ----- ---- -------- -------- ------ ------- -------\n 1 0 0 26-jan-17 01:53:02 PDB$LASTREPLAY -1 10\n 3 0 0 26-jan-17 01:53:02 PDB$LASTREPLAY -1 10\n 4 0 0 26-jan-17 01:53:02 PDB$LASTREPLAY -1 10 \n<\/code><\/pre>\nWhen REPLAY# in the PDB is equal to the CDB$ROOT one, this means that there are no additional statements to replicate on the PDB.<\/p>\n
I have PDB1 opened read write and PDB2 in read only:<\/p>\n
\nSQL> show pdbs\n \n CON_ID CON_NAME OPEN MODE RESTRICTED\n ------ -------- ---- ---- ----------\n 2 PDB$SEED READ ONLY NO\n 3 PDB1 READ WRITE NO\n 4 PDB2 READ ONLY NO\n<\/code><\/pre>\nFor the demo my user’s default tablespace is SYSTEM:<\/p>\n
\nSQL> select con_id,username,common,default_tablespace from cdb_users where username='C##USER1' order by 1;\n \n CON_ID USERNAME COMMON DEFAULT_TABLESPACE\n ------ -------- ------ ------------------\n 1 C##USER1 YES SYSTEM\n 3 C##USER1 YES SYSTEM\n 4 C##USER1 YES SYSTEM\n<\/code><\/pre>\nFailure in opened containers<\/h3>\n
I want to change the default tablespace for C##USER1 and I have a USERS tablespace in CDB$ROOT (but not in the PDBs):<\/p>\n
\nSQL> alter user C##USER1 default tablespace USERS;\n \nError starting at line : 50 File @ common-users-pdb-sync.sql\nIn command -\nalter user C##USER1 default tablespace USERS\nError report -\nORA-65048: error encountered when processing the current DDL statement in pluggable database PDB1\nORA-00959: tablespace 'USERS' does not exist\n<\/code><\/pre>\nAs we have seen in the last post, the DDL is executed on all containers that are opened read write. Here it is fine on CDB$ROOT but fails on PDB1.<\/p>\n
Then I create the USERS tablespace in PDB1:<\/p>\n
\nSQL> alter session set container=PDB1;\nSession altered.\nSQL> create tablespace USERS datafile '\/u01\/oradata\/CDB2\/PDB1\/users.dbf' size 5M;\nTablespace USERS created.\nSQL> alter session set container=CDB$ROOT;\nSession altered.\n<\/code><\/pre>\nAnd now, the statement is successful in CDB$ROOT, replicated on PDB1:<\/p>\n
\nSQL> alter user C##USER1 default tablespace USERS;\nUser C##USER1 altered.\n<\/code><\/pre>\nThis is nice: the statement is successful in all containers or fails. When it is successful, statements are recorded in PDB_SYNC$:<\/p>\n
\nSQL> select con_id,scnwrp,scnbas,ctime,name,auxname1,auxname2,opcode,replay#,sqlstmt from containers(pdb_sync$) where con_id=1 and bitand(flags,8)!=8 order by con_id,replay#;\n \n CON_ID SCNWRP SCNBAS CTIME NAME AUXNAME1 AUXNAME2 OPCODE REPLAY# SQLSTMT\n ------ ------ ------ ----- ---- -------- -------- ------ ------- -------\n 1 0 0 26-jan-17 01:53:02 PDB$LASTREPLAY -1 11\n 1 0 852610 26-jan-17 02:57:26 CTXSYS SYS 5 1 alter user CTXSYS account unlock identified by *^@\n 1 0 853177 26-jan-17 02:57:34 CTXSYS SYS 5 2 alter user CTXSYS password expire account lock^@\n 1 0 1405359 26-jan-17 03:31:31 SYSTEM SYS 5 3 alter user system account lock password expire^@\n 1 0 1408693 23-dec-17 11:34:43 SYS SYS 5 4 alter user sys account unlock identified by *^@\n 1 0 1408703 23-dec-17 11:34:43 SYSTEM SYS 5 5 alter user system account unlock identified by *^@\n 1 0 1466615 29-dec-17 09:26:56 C##PROFILE1 SYS 7 6 create profile C##PROFILE1 limit inactive_account_time 15 container=all^@\n 1 0 1466641 29-dec-17 09:26:57 C##ROLE1 SYS 3 7 create role C##ROLE1 container=all^@\n 1 0 1466748 29-dec-17 09:26:58 C##USER1 SYS 1 8 create user C##USER1 identified by * container=all^@\n 1 0 1466812 29-dec-17 09:26:59 C##USER1 SYS 5 9 alter user C##USER1 profile C##PROFILE1^@\n 1 0 1466853 29-dec-17 09:26:59 C##USER1 C##ROLE1 SYS 10 10 grant C##ROLE1 to C##USER1 container=all^@\n 1 0 1467010 29-dec-17 09:27:01 C##USER1 SYS 5 11 alter user C##USER1 default tablespace USERS^@\n<\/code><\/pre>\nFailure in replay at open for closed containers<\/h3>\n
But PDB2 is not synchronized because it was not opened read write:<\/p>\n
\nSQL> select con_id,scnwrp,scnbas,ctime,name,auxname1,auxname2,opcode,replay#,sqlstmt from containers(pdb_sync$) where con_id>1 and bitand(flags,8)!=8 order by con_id,replay#;\n \n CON_ID SCNWRP SCNBAS CTIME NAME AUXNAME1 AUXNAME2 OPCODE REPLAY# SQLSTMT\n ------ ------ ------ ----- ---- -------- -------- ------ ------- -------\n 3 0 0 26-jan-17 01:53:02 PDB$LASTREPLAY -1 11\n 4 0 0 26-jan-17 01:53:02 PDB$LASTREPLAY -1 10\n<\/code><\/pre>\nBut I don’t have a USERS tablespace in PDB2, so the replay will fail:<\/p>\n
\nSQL> alter pluggable database PDB2 close;\nPluggable database PDB2 altered.\n \nSQL> alter pluggable database PDB2 open;\nORA-24344: success with compilation error\nPluggable database PDB2 altered.\n<\/code><\/pre>\nThis is a warning only. The SQlcl feedback is a bit misleading, mentioning a compilation error because this is where we used to have warnings, but the SQl*Plus message is more clear:<\/p>\n
\nSQL> alter pluggable database PDB2 open;\nWarning: PDB altered with errors.\n<\/code><\/pre>\nThe PDB2 cannot be left closed, because you need to create a tablespace here. But it cannot be opened to everyone, because it is not in sync with CDB$ROOT. So what happens is that the PDB is opened in restricted mode:<\/p>\n
\nSQL> show pdbs\n \n CON_ID CON_NAME OPEN MODE RESTRICTED\n ------ -------- ---- ---- ----------\n 2 PDB$SEED READ ONLY NO\n 3 PDB1 READ WRITE NO\n 4 PDB2 READ WRITE YES\n<\/code><\/pre>\nNote that if you look at PDB_SYNC$ in the PDB at that time, it looks like REPLAY#=11 has increased but you also see rows for the statement that has to be run. You have to connect to the PDB because containers() do not run in restricted session containers:<\/p>\n
\nSQL> alter session set container=PDB2;\nSession altered.\n \nSQL> select con_id,scnwrp,scnbas,ctime,name,auxname1,auxname2,opcode,replay#,sqlstmt from containers(pdb_sync$) where con_id>1 and bitand(flags,8)!=8 order by con_id,replay#;\n \n CON_ID SCNWRP SCNBAS CTIME NAME AUXNAME1 AUXNAME2 OPCODE REPLAY# SQLSTMT\n ------ ------ ------ ----- ---- -------- -------- ------ ------- -------\n 4 0 0 26-jan-17 01:53:02 PDB$LASTREPLAY -1 11\n 4 0 1469022 29-dec-17 09:27:02 C##USER1 SYS 5 11 alter user C##USER1 default tablespace USERS^@\n \nSQL> alter session set container=CDB$ROOT;\nSession altered.\n<\/code><\/pre>\nActually, the attempt to sync has inserted the statements and pushed the last replay indicator. Now, the PDB has all information to do a sync without the need to go to CDB$ROOT. The DDL was not replayed, but has been stored locally. When the sync will be successful, statements will be removed from the local PDB_SYNC$ leaving only the LASTREPLAY indicator.<\/p>\n
PDB_PLUG_IN_VIOLATIONS<\/h3>\n
More info about the warning is stored in PDB_ALERT$ which you query from PDB_PLUG_IN_VIOLATIONS (the strange name reminds the TRANSPORT_SET_VIOLATIONS view used by DBMS_TTS):<\/p>\n
\nSQL> select name, cause, type, status,action,message,time from pdb_plug_in_violations;\n \nNAME CAUSE TYPE STATUS ACTION MESSAGE TIME\n---- ----- ---- ------ ------ ------- -------------------------------\nPDB2 Sync Failure ERROR PENDING Sync PDB failed with ORA-959 during 'alter user C##USER1 default tablespace USERS' 29-DEC-17 09.27.03.266780000 PM\n<\/code><\/pre>\nHere you have the statement that failed and the error number, but no recommended ACTION. However, ORA-959 is “tablespace ‘%s’ does not exist” which gives a clue about the problem encountered.<\/p>\n
As the PDB is opened a DBA (with RESTRICTED SESSION privilege) can add the tablespace:<\/p>\n
\nSQL> alter session set container=PDB2;\nSession altered.\n \nSQL> create tablespace USERS datafile '\/u01\/oradata\/CDB2\/PDB2\/users.dbf' size 5M;\nTablespace USERS created.\n<\/code><\/pre>\nBut you cannot simply disable restricted session:<\/p>\n
\nSQL> alter system disable restricted session;\nSQL> alter system disable restricted session;\n \nError starting at line : 74 File @ common-users-pdb-sync.sql\nIn command -\nalter system disable restricted session\nError report -\nORA-65144: ALTER SYSTEM DISABLE RESTRICTED SESSION is not permitted\n65144. 00000 - \"ALTER SYSTEM DISABLE RESTRICTED SESSION is not permitted\"\n*Cause: An attempt was made to disable a restricted session while an unresolved error existed in PDB_PLUG_IN_VIOLATIONS.\n*Action: Resolve all of the errors before trying to disable a restricted session.\n<\/code><\/pre>\nOne solution is to close and open the PDB to get the DDL replay:<\/p>\n
SQL> alter session set container=CDB$ROOT;\nSession altered.\nSQL> alter pluggable database PDB2 close;\nPluggable database PDB2 altered.\nSQL> alter pluggable database PDB2 open;\nPluggable database PDB2 altered.\n<\/code><\/pre>\nThe other solution is to call DBMS_PDB.SYNC_PDB and disable restricted mode:<\/p>\n
\nSQL> exec dbms_pdb.sync_pdb; commit;\nPL\/SQL procedure successfully completed.\n \nSQL> alter system disable restricted session;\nSystem DISABLE altered.\n<\/code><\/pre>\nIn both case, no warning here, and no restricted mode:<\/p>\n
\nSQL> show pdbs\n \n CON_ID CON_NAME OPEN MODE RESTRICTED\n ------ -------- ---- ---- ----------\n 2 PDB$SEED READ ONLY NO\n 3 PDB1 READ WRITE NO\n 4 PDB2 READ WRITE NO\n<\/code><\/pre>\nand the PDB_PLUG_IN_VIOLATIONS is updated to flag the issue as resolved:<\/p>\n
\nSQL> select name, cause, type, status,action,message,time from pdb_plug_in_violations;\n \nNAME CAUSE TYPE STATUS ACTION MESSAGE TIME\n---- ----- ---- ------ ------ ------- -------------------------------\nPDB2 Sync Failure ERROR RESOLVED Sync PDB failed with ORA-959 during 'alter user C##USER1 default tablespace USERS' 29-DEC-17 09.27.04.093659000 PM\n<\/code><\/pre>\nAt that time, the local PDB_SYNC$ table in PDB2 contains only the PDB$LASTREPLAY row, with the same value as in the CDB$ROOT table. The rows with the statements have been deleted once the DDL has been successfully replayed:<\/p>\n
\nSQL> select con_id,scnwrp,scnbas,ctime,name,auxname1,auxname2,opcode,replay#,sqlstmt from containers(pdb_sync$) where con_id>1 and bitand(flags,8)!=8 order by con_id,replay#;\n \n CON_ID SCNWRP SCNBAS CTIME NAME AUXNAME1 AUXNAME2 OPCODE REPLAY# SQLSTMT\n ------ ------ ------ ----- ---- -------- -------- ------ ------- -------\n 4 0 0 26-jan-17 01:53:02 PDB$LASTREPLAY -1 11\n<\/code><\/pre>\nSo what?<\/h3>\n
The mechanism is simple: record what is done in CDB$ROOT, replicate it in PDBs when possible (opened read-write) and try to replay it, mark the last replay step. For containers that were not writeable, at open, the DDL is replicated on the PDBs that lag being CDB$ROOT and replay step is updated. Then the DDL is replayed. When sucessful, the statement is removed from the replicated DDL. When it fails, you get a warning, and a message in PDB_PLUG_IN_VIOLATIONS, and the PDB is opened in restricted session mode to let you solve the problem.
\nIf you can fix the issue so that the DDL to be replayed is successful, then you can just sync and disable restricted session, or simply close and re-open the PDB.
\nIf you can’t fix it I suppose you need to hack the statements in the local PDB_SYNC$, with Oracle Support agreement of course, and make sure that you arrive to a state which is consistent with the other containers, especially CDB$ROOT.<\/p>\n","protected":false},"excerpt":{"rendered":"
By Franck Pachot . In the previous post https:\/\/www.dbi-services.com\/blog\/12c-multitenant-internals-pdb-replay-ddl-for-common-users I’ve done some DDL on a common user to show how this is replayed later for PDBs that were not opened at that time. But what happens when one of the DDL fails on one PDB?<\/p>\n","protected":false},"author":27,"featured_media":0,"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-10716","post","type-post","status-publish","format-standard","hentry","category-oracle","tag-cdb","tag-internals","tag-multitenant","tag-oracle-12c","tag-oracle-multitenant","tag-pdb","tag-pluggable-databases"],"acf":[],"yoast_head":"\n
12c Multitenant internals: PDB_PLUG_IN_VIOLATIONS - 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\/12c-multitenant-internals-pdb_plug_in_violations\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"12c Multitenant internals: PDB_PLUG_IN_VIOLATIONS\" \/>\n<meta property=\"og:description\" content=\"By Franck Pachot . In the previous post https:\/\/www.dbi-services.com\/blog\/12c-multitenant-internals-pdb-replay-ddl-for-common-users I’ve done some DDL on a common user to show how this is replayed later for PDBs that were not opened at that time. But what happens when one of the DDL fails on one PDB?\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.dbi-services.com\/blog\/12c-multitenant-internals-pdb_plug_in_violations\/\" \/>\n<meta property=\"og:site_name\" content=\"dbi Blog\" \/>\n<meta property=\"article:published_time\" content=\"2017-12-30T18:54:51+00:00\" \/>\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=\"9 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\\\/12c-multitenant-internals-pdb_plug_in_violations\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/12c-multitenant-internals-pdb_plug_in_violations\\\/\"},\"author\":{\"name\":\"Oracle Team\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#\\\/schema\\\/person\\\/66ab87129f2d357f09971bc7936a77ee\"},\"headline\":\"12c Multitenant internals: PDB_PLUG_IN_VIOLATIONS\",\"datePublished\":\"2017-12-30T18:54:51+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/12c-multitenant-internals-pdb_plug_in_violations\\\/\"},\"wordCount\":813,\"commentCount\":0,\"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\\\/12c-multitenant-internals-pdb_plug_in_violations\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/12c-multitenant-internals-pdb_plug_in_violations\\\/\",\"url\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/12c-multitenant-internals-pdb_plug_in_violations\\\/\",\"name\":\"12c Multitenant internals: PDB_PLUG_IN_VIOLATIONS - dbi Blog\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#website\"},\"datePublished\":\"2017-12-30T18:54:51+00:00\",\"author\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#\\\/schema\\\/person\\\/66ab87129f2d357f09971bc7936a77ee\"},\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/12c-multitenant-internals-pdb_plug_in_violations\\\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/12c-multitenant-internals-pdb_plug_in_violations\\\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/12c-multitenant-internals-pdb_plug_in_violations\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Accueil\",\"item\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"12c Multitenant internals: PDB_PLUG_IN_VIOLATIONS\"}]},{\"@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":"12c Multitenant internals: PDB_PLUG_IN_VIOLATIONS - 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\/12c-multitenant-internals-pdb_plug_in_violations\/","og_locale":"en_US","og_type":"article","og_title":"12c Multitenant internals: PDB_PLUG_IN_VIOLATIONS","og_description":"By Franck Pachot . In the previous post https:\/\/www.dbi-services.com\/blog\/12c-multitenant-internals-pdb-replay-ddl-for-common-users I’ve done some DDL on a common user to show how this is replayed later for PDBs that were not opened at that time. But what happens when one of the DDL fails on one PDB?","og_url":"https:\/\/www.dbi-services.com\/blog\/12c-multitenant-internals-pdb_plug_in_violations\/","og_site_name":"dbi Blog","article_published_time":"2017-12-30T18:54:51+00:00","author":"Oracle Team","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Oracle Team","Est. reading time":"9 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.dbi-services.com\/blog\/12c-multitenant-internals-pdb_plug_in_violations\/#article","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/12c-multitenant-internals-pdb_plug_in_violations\/"},"author":{"name":"Oracle Team","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee"},"headline":"12c Multitenant internals: PDB_PLUG_IN_VIOLATIONS","datePublished":"2017-12-30T18:54:51+00:00","mainEntityOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/12c-multitenant-internals-pdb_plug_in_violations\/"},"wordCount":813,"commentCount":0,"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\/12c-multitenant-internals-pdb_plug_in_violations\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.dbi-services.com\/blog\/12c-multitenant-internals-pdb_plug_in_violations\/","url":"https:\/\/www.dbi-services.com\/blog\/12c-multitenant-internals-pdb_plug_in_violations\/","name":"12c Multitenant internals: PDB_PLUG_IN_VIOLATIONS - dbi Blog","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/#website"},"datePublished":"2017-12-30T18:54:51+00:00","author":{"@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee"},"breadcrumb":{"@id":"https:\/\/www.dbi-services.com\/blog\/12c-multitenant-internals-pdb_plug_in_violations\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.dbi-services.com\/blog\/12c-multitenant-internals-pdb_plug_in_violations\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/www.dbi-services.com\/blog\/12c-multitenant-internals-pdb_plug_in_violations\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Accueil","item":"https:\/\/www.dbi-services.com\/blog\/"},{"@type":"ListItem","position":2,"name":"12c Multitenant internals: PDB_PLUG_IN_VIOLATIONS"}]},{"@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\/10716","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=10716"}],"version-history":[{"count":0,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/10716\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/media?parent=10716"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/categories?post=10716"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/tags?post=10716"},{"taxonomy":"type","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/type_dbi?post=10716"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}