{"id":8711,"date":"2016-08-07T10:33:33","date_gmt":"2016-08-07T08:33:33","guid":{"rendered":"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-how-object-links-are-parsedexecuted\/"},"modified":"2016-08-07T10:33:33","modified_gmt":"2016-08-07T08:33:33","slug":"multitenant-internals-how-object-links-are-parsedexecuted","status":"publish","type":"post","link":"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-how-object-links-are-parsedexecuted\/","title":{"rendered":"Multitenant internals: how object links are parsed\/executed"},"content":{"rendered":"<h2>By Franck Pachot<\/h2>\n<p>.<br \/>\nI had a <a href=\"http:\/\/dbi-services.com\/blog\/oracle-12c-cdb-metadata-a-object-links-internals\/#comment-4178\" title=\"comment\" target=\"_blank\" rel=\"noopener noreferrer\">comment<\/a> on object links internals when creating a sharing=object view on GV$SESSION. Before posting about this specific case, I realized that I&#8217;ve never explained how a query on an object link is run on the CDB$ROOT container.<br \/>\n<!--more--><\/p>\n<h3>Data link testcase<\/h3>\n<p>Here is how I create the DEMOT table and DEMOV view as object link.<\/p>\n<pre><code>\n14:48:58 SQL&gt; connect \/ as sysdba\nConnected.\n14:48:59 SQL&gt; alter session set container=CDB$ROOT;\nSession altered.\n14:48:59 SQL&gt; alter session set \"_oracle_script\"=true;\nSession altered.\n14:48:59 SQL&gt; create table DEMOT as select rownum id, rownum num from xmltable('10 to 1000000');\nTable created.\nSQL&gt; exec dbms_stats.gather_table_stats('','DEMOT');\n14:49:00 SQL&gt; create view DEMOV sharing=object as select * from DEMOT;\nView created.\n14:49:00 SQL&gt; alter session set container=PDB;\nSession altered.\n14:49:00 SQL&gt; create table DEMOT as select rownum id, rownum num from xmltable('1 to 1');\nTable created.\nSQL&gt; exec dbms_stats.gather_table_stats('','DEMOT');\n14:49:01 SQL&gt; create view DEMOV sharing=object as select * from DEMOT;\nView created.\n14:49:01 SQL&gt; alter session set \"_oracle_script\"=false;\nSession altered.\n<\/code><\/pre>\n<p>And I run the following query two times (easier to look at trace without hard parsing)<\/p>\n<pre><code>\n14:49:02 SQL&gt; select id from DEMOV where num&lt;=100;\n...\n100 rows selected.\n<\/code><\/pre>\n<h3>SQL_TRACE<\/h3>\n<p>I&#8217;ll detail the sql_trace of the last run.<\/p>\n<p>First, the query is parsed in our PDB:<\/p>\n<pre><code>\nPARSING IN CURSOR #140360238365672 len=35 dep=0 uid=0 oct=3 lid=0 tim=687080512770 hv=237558885 ad='10cf55ae8' sqlid=' duy45bn72jr35'\nselect id from DEMOV where num&lt;=100\nEND OF STMT\nPARSE #140360238365672:c=0,e=86,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=3055399777,tim=687080512769\nEXEC #140360238365672:c=0,e=61,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=3055399777,tim=687080512872\n<\/code><\/pre>\n<p>There was no hard parse for this second parse call (mis=0 means no &#8216;Misses in library cache during parse&#8217;). Execution occurred but no fetch yet.<\/p>\n<p>At that point, the session switches to CDB$ROOT container (you have to trust me as there is no information about it in the trace file in 12.1)<\/p>\n<pre><code>\nPARSING IN CURSOR #140360238643592 len=99 dep=1 uid=0 oct=3 lid=0 tim=687080513015 hv=2967959178 ad='107be5590' sqlid=' 3b9x1rasffxna'\nSELECT \/*+ RESULT_CACHE (SYSOBJ=TRUE) *\/ ID,NUM FROM \"SYS\".\"DEMOV\" \"DEMOV\" WHERE \"DEMOV\".\"NUM\"&lt;=100\nEND OF STMT\nPARSE #140360238643592:c=0,e=33,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,plh=3598352655,tim=687080513014\nEXEC #140360238643592:c=0,e=16,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,plh=3598352655,tim=687080513084\nFETCH #140360238643592:c=0,e=32,p=0,cr=0,cu=0,mis=0,r=100,dep=1,og=4,plh=3598352655,tim=687080513137\nSTAT #140360238643592 id=1 cnt=100 pid=0 pos=1 obj=0 op=&#039;RESULT CACHE  cgn1rxw6ycznac8fyzfursq2z6 (cr=0 pr=0 pw=0 time=12 us)&#039;\nSTAT #140360238643592 id=2 cnt=0 pid=1 pos=1 obj=98422 op=&#039;TABLE ACCESS FULL DEMOT (cr=0 pr=0 pw=0 time=0 us)&#039;\n<\/code><\/pre>\n<p>We have here a recursive query (dep=1) that is run on the view in CDB$ROOT. It&#8217;s not the same query as ours: FROM clause is our sharing=object view, WHERE clause is the predicates that applies on it, and SELECT clause the columns that we need (ID was in my SELECT clause and NUM was in my WHERE  clause). The query is parsed, executed, the 100 rows are fetched and interestingly the result goes to result cache. Yes, if you query V$RESULT_CACHE_OBJECTS in a CDB you will see lot of objects:<\/p>\n<blockquote class=\"twitter-tweet\" data-width=\"500\" data-dnt=\"true\">\n<p lang=\"en\" dir=\"ltr\"><a href=\"https:\/\/twitter.com\/hashtag\/multitenant?src=hash&amp;ref_src=twsrc%5Etfw\">#multitenant<\/a> object links uses result cache internally. AWR views are object links. <a href=\"https:\/\/t.co\/V5IMW2qQx2\">pic.twitter.com\/V5IMW2qQx2<\/a><\/p>\n<p>&mdash; Franck Pachot (@FranckPachot) <a href=\"https:\/\/twitter.com\/FranckPachot\/status\/762195342804738048?ref_src=twsrc%5Etfw\">August 7, 2016<\/a><\/p><\/blockquote>\n<p><script async src=\"https:\/\/platform.twitter.com\/widgets.js\" charset=\"utf-8\"><\/script><\/p>\n<p>If you look at the FETCH line above, you see that the second execution was a result cache hit (cr=0)<\/p>\n<p>So, the rows we require from the object link are fetched, then the execution of our query continues in our PDB:<\/p>\n<pre><code>\nFETCH #140360238365672:c=0,e=235,p=0,cr=0,cu=0,mis=0,r=1,dep=0,og=1,plh=3055399777,tim=687080513194\nFETCH #140360238365672:c=0,e=11,p=0,cr=0,cu=0,mis=0,r=15,dep=0,og=1,plh=3055399777,tim=687080513375\nFETCH #140360238365672:c=0,e=10,p=0,cr=0,cu=0,mis=0,r=15,dep=0,og=1,plh=3055399777,tim=687080513586\nFETCH #140360238365672:c=0,e=9,p=0,cr=0,cu=0,mis=0,r=15,dep=0,og=1,plh=3055399777,tim=687080513776\nFETCH #140360238365672:c=0,e=9,p=0,cr=0,cu=0,mis=0,r=15,dep=0,og=1,plh=3055399777,tim=687080513983\nFETCH #140360238365672:c=0,e=9,p=0,cr=0,cu=0,mis=0,r=15,dep=0,og=1,plh=3055399777,tim=687080514188\nFETCH #140360238365672:c=0,e=8,p=0,cr=0,cu=0,mis=0,r=15,dep=0,og=1,plh=3055399777,tim=687080514375\n<\/code><\/pre>\n<p>Up there 91 rows were fetched. We can see in the trace that the recursive cursor is closed there (session switches to CDB$ROOT for that):<\/p>\n<pre><code>\nCLOSE #140360238643592:c=0,e=3,dep=1,type=0,tim=687080514584\n<\/code><\/pre>\n<p>And our session is back on PDB container where the remaining rows are fetched and our cursor closed:<\/p>\n<pre><code>\nFETCH #140360238365672:c=0,e=40,p=0,cr=0,cu=0,mis=0,r=9,dep=0,og=1,plh=3055399777,tim=687080514610\nSTAT #140360238365672 id=1 cnt=100 pid=0 pos=1 obj=0 op='FIXED TABLE FULL X$OBLNK$ (cr=0 pr=0 pw=0 time=263 us cost=0 size=13000 card=500)'\nCLOSE #140360238365672:c=0,e=3,dep=0,type=0,tim=687080516173\n<\/code><\/pre>\n<p>As I&#8217;ve explained at DOAGDB16 and SOUG Day (next session is planned for <a href=\"http:\/\/www.tech16.ukoug.org\/default.asp?p=14778&amp;dlgact=shwprs&amp;prs_prsid=11878&amp;day_dayid=108\" target=\"_blank\" rel=\"noopener noreferrer\">UKOUG TECH16<\/a>), following metadata and object links is done by the session switching from PDB to CDB$ROOT.<\/p>\n<h3>TKPROF<\/h3>\n<p>Here is the tkprof of the full trace with two executions<\/p>\n<h4>Our query on PDB<\/h4>\n<pre><code>\nSQL ID:  duy45bn72jr35 Plan Hash: 3055399777\n&nbsp;\nselect id\nfrom\n DEMOV where num&lt;=100\n&nbsp;\ncall     count       cpu    elapsed       disk      query    current        rows\n------- ------  -------- ---------- ---------- ---------- ----------  ----------\nParse        2      0.00       0.00          0          0          0           0\nExecute      2      0.00       0.00          0          0          0           0\nFetch       16      0.00       0.00          0          0          0         200\n------- ------  -------- ---------- ---------- ---------- ----------  ----------\ntotal       20      0.00       0.00          0          0          0         200\n&nbsp;\nMisses in library cache during parse: 1\nOptimizer mode: ALL_ROWS\nParsing user id: SYS\nNumber of plan statistics captured: 2\n&nbsp;\nRows (1st) Rows (avg) Rows (max)  Row Source Operation\n---------- ---------- ----------  ---------------------------------------------------\n       100        100        100  FIXED TABLE FULL X$OBLNK$ (cr=1040 pr=1034 pw=0 time=42636 us cost=0 size=13000 card=500)\n<\/code><\/pre>\n<p>The number of executions and row count is correct, but there&#8217;s no logical reads here because all block reads occurred through the recursive query. The execution plan shows are full table scan on X$OBLNK$ which is how object link access path are displayed in 12.1<\/p>\n<h4>Query on CDB$ROOT<\/h4>\n<pre><code>\nSQL ID:  3b9x1rasffxna Plan Hash: 3598352655\n&nbsp;\nSELECT \/*+ RESULT_CACHE (SYSOBJ=TRUE) *\/ ID,NUM\nFROM\n \"SYS\".\"DEMOV\" \"DEMOV\" WHERE \"DEMOV\".\"NUM\"&lt;=100\n&nbsp;\ncall     count       cpu    elapsed       disk      query    current        rows\n------- ------  -------- ---------- ---------- ---------- ----------  ----------\nParse        2      0.00       0.00          0          0          0           0\nExecute      2      0.00       0.00          0          0          0           0\nFetch        2      0.03       0.08       2068       2074          0         200\n------- ------  -------- ---------- ---------- ---------- ----------  ----------\ntotal        6      0.03       0.08       2068       2074          0         200\n&nbsp;\nMisses in library cache during parse: 1\nOptimizer mode: CHOOSE\nParsing user id: SYS   (recursive depth: 1)\nNumber of plan statistics captured: 2\n&nbsp;\nRows (1st) Rows (avg) Rows (max)  Row Source Operation\n---------- ---------- ----------  ---------------------------------------------------\n       100        100        100  RESULT CACHE  cgn1rxw6ycznac8fyzfursq2z6 (cr=1037 pr=1034 pw=0 time=662 us)\n       100         50        100   TABLE ACCESS FULL DEMOT (cr=1037 pr=1034 pw=0 time=522 us)\n<\/code><\/pre>\n<p>Here is where the work to get rows from the view is, in CDB$ROOT. Only two fetches there (one per execution). As we have seen in the row trace, all rows from the object link were fetched before we issue any fetch call from our query. I did same test with more rows selected and it seems that the fetch size is 200 rows: when 200 rows are fetched from CDB$ROOT, session switches back to PDB to fetch those rows (15 by 15 with the default sqlplus arraysize) and comes again to CDB$ROOT for next 200 rows. This means that they are probably buffered.<\/p>\n<p>Actually there&#8217;s a hidden parameter to define that: &#8220;_cdb_view_prefetch_batch_size&#8221; is set to 200 by default.<\/p>\n<p>Note that the 2000 logical reads are from the first execution only because the second one found the result in result cache.<\/p>\n<h3>V$SQL<\/h3>\n<p>From SQL_TRACE, the work done in the other container is not included in statement statistics. This makes tuning more difficult as we are used to see recursive work cumulated in the top level statement.<\/p>\n<p>From CDB$ROOT here is what we can see from the shared pool (V$SQL) about the queries I&#8217;ve seen in the SQL_TRACE. I query V$SQL with the PLAN_HASH_VALUE (&#8216;phv&#8217; in the SQL_TRACE dump).<\/p>\n<pre><code>\n14:49:02 SQL&gt; select con_id,sql_id,rows_processed,plan_hash_value,executions,parse_calls,fetches,buffer_gets,sql_text from v$sql where  plan_hash_value in (3598352655,3055399777) order by last_active_time;\n&nbsp;\n    CON_ID SQL_ID        ROWS_PROCESSED PLAN_HASH_VALUE EXECUTIONS PARSE_CALLS    FETCHES BUFFER_GETS SQL_TEXT\n---------- ------------- -------------- --------------- ---------- ----------- ---------- ----------- --------------------------------------------------------------------------------\n         4 duy45bn72jr35            200      3055399777          2           2         16        2721 select id from DEMOV where num&lt;=100\n         4 bynmh7xm4bf54              0      3598352655          0           1          0          61 SELECT * FROM NO_OBJECT_LINK(&quot;SYS&quot;.&quot;DEMOV&quot;)\n         1 3b9x1rasffxna            200      3598352655          2           2          2        2080 SELECT \/*+ RESULT_CACHE (SYSOBJ=TRUE) *\/ ID,NUM FROM &quot;SYS&quot;.&quot;DEMOV&quot; &quot;DEMOV&quot; WHERE\n<\/code><\/pre>\n<p>For the two queries we have seen above, the number of executions and fetches matches what we have seen in the trace. However, buffer_gets from the user query includes the logical reads from the recursive query.<\/p>\n<p>But there&#8217;s more here. A statement is there with the same PLAN_HASH_VALUE than the internal query. It&#8217;s the query on the shared=object view, with the undocumented NO_OBJECT_LINK() function. It is parsed but not executed. This parse occurred in PDB just before switching to CDB$ROOT. This parse occurend only one time when our query was hard parsed. It has the same plan hash value than the internal query because the plan is the same: full table scan on the table.<\/p>\n<p>My understanding of that is that when hard parsing our query and executing the recursive query on CDB$ROOT, the optimizer checks the view definition in the current container (the PDB) by parsing it without following object links (reason for the NO_OBJECT_LINK).<\/p>\n<h3>NO_OBJECT_LINK<\/h3>\n<p>Here is the parsing of that query with NO_OBJECT_LINK that occurs in the PDB:<\/p>\n<pre><code>\nPARSING IN CURSOR #140360238422472 len=43 dep=1 uid=0 oct=3 lid=0 tim=687080413554 hv=1715845284 ad='108fc0230' sqlid=' bynmh7xm4bf54'\nSELECT * FROM NO_OBJECT_LINK(\"SYS\".\"DEMOV\")\nEND OF STMT\nPARSE #140360238422472:c=3000,e=2948,p=0,cr=61,cu=0,mis=1,r=0,dep=1,og=4,plh=3598352655,tim=687080413553\nCLOSE #140360238422472:c=0,e=3,dep=1,type=0,tim=687080413614\n<\/code><\/pre>\n<p>There is no where clause here. I guess that the goal is just to validate the view in the PDB before executing the full query on CDB$ROOT.<\/p>\n<p>Note that query in the CDB$ROOT do not use the NO_OBJECT_LINK here in 12.1 but could have use it to ensure that there are no further links.<\/p>\n<h3>Execution plans<\/h3>\n<p>With all those recursive queries, how the cardinalities are estimated? DEMOT has no rows in PDB and 1000000 rows in CDB$ROOT. Statistics gathered and I query only 100 rows (they are evenly distributed between low and high value);<\/p>\n<p>The query that is only parsed in PDB:<\/p>\n<pre><code>\nPLAN_TABLE_OUTPUT\n------------------------------------------------------------------------------------------------------------------------\nSQL_ID  bynmh7xm4bf54, child number 0\n-------------------------------------\nSELECT * FROM NO_OBJECT_LINK(\"SYS\".\"DEMOV\")\nPlan hash value: 3598352655\n---------------------------------------------------------------------------\n| Id  | Operation         | Name  | Rows  | Bytes | Cost (%CPU)| Time     |\n---------------------------------------------------------------------------\n|   0 | SELECT STATEMENT  |       |       |       |     2 (100)|          |\n|   1 |  TABLE ACCESS FULL| DEMOT |     1 |     6 |     2   (0)| 00:00:01 |\n---------------------------------------------------------------------------\n<\/code><\/pre>\n<p>The query that is run in CDB$ROOT:<\/p>\n<pre><code>\nPLAN_TABLE_OUTPUT\n------------------------------------------------------------------------------------------------------------------------\nSQL_ID  3b9x1rasffxna, child number 0\n-------------------------------------\nSELECT \/*+ RESULT_CACHE (SYSOBJ=TRUE) *\/ ID,NUM FROM \"SYS\".\"DEMOV\"\n\"DEMOV\" WHERE \"DEMOV\".\"NUM\"&lt;=100\nPlan hash value: 3598352655\n-------------------------------------------------------------------------------------------------\n| Id  | Operation          | Name                       | Rows  | Bytes | Cost (%CPU)| Time     |\n-------------------------------------------------------------------------------------------------\n|   0 | SELECT STATEMENT   |                            |       |       |   568 (100)|          |\n|   1 |  RESULT CACHE      | 9cv1sbwyz16651fgh17234v67g |       |       |            |          |\n|*  2 |   TABLE ACCESS FULL| DEMOT                      |   100 |  1000 |   568   (2)| 00:00:01 |\n-------------------------------------------------------------------------------------------------\nPredicate Information (identified by operation id):\n---------------------------------------------------\n   2 - filter(&quot;NUM&quot;&lt;=100)\n<\/code><\/pre>\n<p>Estimation is ok here.<\/p>\n<p>And my user query:<\/p>\n<pre><code>\nPLAN_TABLE_OUTPUT\n------------------------------------------------------------------------------------------------------------------------\nSQL_ID  duy45bn72jr35, child number 0\n-------------------------------------\nselect id from DEMOV where num&lt;=100\nPlan hash value: 3055399777\n------------------------------------------------------------------\n| Id  | Operation        | Name     | Rows  | Bytes | Cost (%CPU)|\n------------------------------------------------------------------\n|   0 | SELECT STATEMENT |          |       |       |     1 (100)|\n|*  1 |  FIXED TABLE FULL| X$OBLNK$ |   500 | 13000 |     0   (0)|\n------------------------------------------------------------------\nPredicate Information (identified by operation id):\n---------------------------------------------------\n   1 - filter(&quot;NUM&quot;&lt;=100)\n<\/code><\/pre>\n<p>Here, this estimation is not accurate at all, seems to have an hardcoded value of 500.<\/p>\n<h3>Conclusion<\/h3>\n<p>Lot of interesting things here. Object link (that you can call data links as well) are processed in a very special way. But don&#8217;t worry. Remember that you are not allowed to create them yourself. And there are only very few oracle maintained object links: some PDB information that must be available when PDB are not opened, AWR information that is consolidated in root, some audit reference tables,&#8230;<\/p>\n<p>It interesting to see (and think about all consequences) that result cache is used here for internal optimization. Even when you don&#8217;t use result cache for your application, you should have a look at it and maybe size it differently than default. In a future post I&#8217;ll create a sharing=object view on V$ fixed views and result cache will be even more fun.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>By Franck Pachot . I had a comment on object links internals when creating a sharing=object view on GV$SESSION. Before posting about this specific case, I realized that I&#8217;ve never explained how a query on an object link is run on the CDB$ROOT container.<\/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":[229],"tags":[220,455,64,209,875,66,223],"type_dbi":[],"class_list":["post-8711","post","type-post","status-publish","format-standard","hentry","category-database-administration-monitoring","tag-cdb","tag-internals","tag-multitenant","tag-oracle-12c","tag-oracle-multitenant","tag-pdb","tag-pluggable-databases"],"acf":[],"yoast_head":"<!-- This site is optimized with the Yoast SEO Premium plugin v27.2 (Yoast SEO v27.2) - https:\/\/yoast.com\/product\/yoast-seo-premium-wordpress\/ -->\n<title>Multitenant internals: how object links are parsed\/executed - 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-how-object-links-are-parsedexecuted\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Multitenant internals: how object links are parsed\/executed\" \/>\n<meta property=\"og:description\" content=\"By Franck Pachot . I had a comment on object links internals when creating a sharing=object view on GV$SESSION. Before posting about this specific case, I realized that I&#8217;ve never explained how a query on an object link is run on the CDB$ROOT container.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-how-object-links-are-parsedexecuted\/\" \/>\n<meta property=\"og:site_name\" content=\"dbi Blog\" \/>\n<meta property=\"article:published_time\" content=\"2016-08-07T08:33:33+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=\"10 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-how-object-links-are-parsedexecuted\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-how-object-links-are-parsedexecuted\/\"},\"author\":{\"name\":\"Oracle Team\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee\"},\"headline\":\"Multitenant internals: how object links are parsed\/executed\",\"datePublished\":\"2016-08-07T08:33:33+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-how-object-links-are-parsedexecuted\/\"},\"wordCount\":1119,\"commentCount\":0,\"keywords\":[\"CDB\",\"internals\",\"multitenant\",\"Oracle 12c\",\"Oracle Multitenant\",\"PDB\",\"Pluggable Databases\"],\"articleSection\":[\"Database Administration &amp; Monitoring\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-how-object-links-are-parsedexecuted\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-how-object-links-are-parsedexecuted\/\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-how-object-links-are-parsedexecuted\/\",\"name\":\"Multitenant internals: how object links are parsed\/executed - dbi Blog\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#website\"},\"datePublished\":\"2016-08-07T08:33:33+00:00\",\"author\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee\"},\"breadcrumb\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-how-object-links-are-parsedexecuted\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-how-object-links-are-parsedexecuted\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-how-object-links-are-parsedexecuted\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Accueil\",\"item\":\"https:\/\/www.dbi-services.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Multitenant internals: how object links are parsed\/executed\"}]},{\"@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: how object links are parsed\/executed - 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-how-object-links-are-parsedexecuted\/","og_locale":"en_US","og_type":"article","og_title":"Multitenant internals: how object links are parsed\/executed","og_description":"By Franck Pachot . I had a comment on object links internals when creating a sharing=object view on GV$SESSION. Before posting about this specific case, I realized that I&#8217;ve never explained how a query on an object link is run on the CDB$ROOT container.","og_url":"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-how-object-links-are-parsedexecuted\/","og_site_name":"dbi Blog","article_published_time":"2016-08-07T08:33:33+00:00","author":"Oracle Team","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Oracle Team","Est. reading time":"10 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-how-object-links-are-parsedexecuted\/#article","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-how-object-links-are-parsedexecuted\/"},"author":{"name":"Oracle Team","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee"},"headline":"Multitenant internals: how object links are parsed\/executed","datePublished":"2016-08-07T08:33:33+00:00","mainEntityOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-how-object-links-are-parsedexecuted\/"},"wordCount":1119,"commentCount":0,"keywords":["CDB","internals","multitenant","Oracle 12c","Oracle Multitenant","PDB","Pluggable Databases"],"articleSection":["Database Administration &amp; Monitoring"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.dbi-services.com\/blog\/multitenant-internals-how-object-links-are-parsedexecuted\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-how-object-links-are-parsedexecuted\/","url":"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-how-object-links-are-parsedexecuted\/","name":"Multitenant internals: how object links are parsed\/executed - dbi Blog","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/#website"},"datePublished":"2016-08-07T08:33:33+00:00","author":{"@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee"},"breadcrumb":{"@id":"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-how-object-links-are-parsedexecuted\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.dbi-services.com\/blog\/multitenant-internals-how-object-links-are-parsedexecuted\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-how-object-links-are-parsedexecuted\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Accueil","item":"https:\/\/www.dbi-services.com\/blog\/"},{"@type":"ListItem","position":2,"name":"Multitenant internals: how object links are parsed\/executed"}]},{"@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\/8711","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=8711"}],"version-history":[{"count":0,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/8711\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/media?parent=8711"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/categories?post=8711"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/tags?post=8711"},{"taxonomy":"type","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/type_dbi?post=8711"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}