{"id":8712,"date":"2016-08-07T16:13:53","date_gmt":"2016-08-07T14:13:53","guid":{"rendered":"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-object-links-on-fixed-tables\/"},"modified":"2016-08-07T16:13:53","modified_gmt":"2016-08-07T14:13:53","slug":"multitenant-internals-object-links-on-fixed-tables","status":"publish","type":"post","link":"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-object-links-on-fixed-tables\/","title":{"rendered":"Multitenant internals: object links on fixed tables"},"content":{"rendered":"

By Franck Pachot<\/h2>\n

.
\nThe previous post<\/a> partly answered to the original question (why an object link to V$SESSION is refreshed only every 30 seconds): recursive queries on shared=object views. Now let’s see what is different with fixed tables.
\n
\nDisclaimer: this is research only. Don’t do that anywhere else than a lab. This is implicit when the title is ‘internals’.<\/p>\n

Result cache<\/h3>\n

When query on a shared=object view is executed from a PDB, the session switches to the CDB to run a recursive query to get the rows. This query uses result cache by adding the following hint:<\/p>\n

\/*+ RESULT_CACHE (SYSOBJ=TRUE) *\/<\/code><\/pre>\n
This enables result cache for the rows fetched by this query, and even for system object. The ‘SYSOBJ=TRUE’ is there because the “_rc_sys_obj_enabled” defaults to true.<\/p>\n
Here is the result cache from the previous post (I flushed the result cache just before the second run because in 12c<\/em> hard parsing is also using a lot the result cache):<\/p>\n
\n16:34:00 SQL> 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,3551671056) order by last_active_time;\n \n    CON_ID SQL_ID        ROWS_PROCESSED PLAN_HASH_VALUE EXECUTIONS PARSE_CALLS    FETCHES BUFFER_GETS SQL_TEXT\n---------- ------------- -------------- --------------- ---------- ----------- ---------- ----------- --------------------------------------------------------------------------------\n         1 350gg6247sfa6            200      3598352655          2           2          2          26 SELECT \/*+ RESULT_CACHE (SYSOBJ=TRUE) *\/ ID,NUM FROM NO_OBJECT_LINK(\"SYS\".\"DEMOV\n         3 bynmh7xm4bf54              0      3598352655          0           5          0          51 SELECT * FROM NO_OBJECT_LINK(\"SYS\".\"DEMOV\")\n         3 duy45bn72jr35            200      3551671056          2           2         16         269 select id from DEMOV where num column name format a120 trunc\n16:34:00 SQL> select type,status,name,row_count from v$result_cache_objects order by row_count desc fetch first 10 rows only;\n \nTYPE       STATUS    NAME                                                                                                                      ROW_COUNT\n---------- --------- ------------------------------------------------------------------------------------------------------------------------ ----------\nResult     Published SELECT \/*+ RESULT_CACHE (SYSOBJ=TRUE) *\/ ID,NUM FROM NO_OBJECT_LINK(\"SYS\".\"DEMOV\") \"DEMOV\" WHERE \"DEMOV\".\"NUM\"<=100             100\nDependency Published SYS.DEMOT                                                                                                                         0\nDependency Published SYS.DEMOV                                                                                                                         0\n<\/code><\/pre>\n
As with regular result cache, there is dependency tracking: as soon as the underlying table has some modification, the cache will be invalidated. So this query is always guaranteed to get fresh results.<\/p>\n
Invalidation<\/h3>\n
I did the same when deleting half of the rows before the second execution in order to invalidate the result cache:<\/p>\n
\n16:43:46 SQL> 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,3551671056) order by last_active_time;\n \n    CON_ID SQL_ID        ROWS_PROCESSED PLAN_HASH_VALUE EXECUTIONS PARSE_CALLS    FETCHES BUFFER_GETS SQL_TEXT\n---------- ------------- -------------- --------------- ---------- ----------- ---------- ----------- --------------------------------------------------------------------------------\n         1 350gg6247sfa6            150      3598352655          2           2          2          26 SELECT \/*+ RESULT_CACHE (SYSOBJ=TRUE) *\/ ID,NUM FROM NO_OBJECT_LINK(\"SYS\".\"DEMOV\n         3 bynmh7xm4bf54              0      3598352655          0           5          0          51 SELECT * FROM NO_OBJECT_LINK(\"SYS\".\"DEMOV\")\n         3 duy45bn72jr35            150      3551671056          2           2         13         269 select id from DEMOV where num column name format a120 trunc\n16:43:46 SQL> select type,status,name,row_count from v$result_cache_objects order by row_count desc fetch first 10 rows only;\n \nTYPE       STATUS    NAME                                                                                                                      ROW_COUNT\n---------- --------- ------------------------------------------------------------------------------------------------------------------------ ----------\nResult     Invalid   SELECT \/*+ RESULT_CACHE (SYSOBJ=TRUE) *\/ ID,NUM FROM NO_OBJECT_LINK(\"SYS\".\"DEMOV\") \"DEMOV\" WHERE \"DEMOV\".\"NUM\"<=100             100\nResult     Published SELECT \/*+ RESULT_CACHE (SYSOBJ=TRUE) *\/ ID,NUM FROM NO_OBJECT_LINK("SYS"."DEMOV") "DEMOV" WHERE "DEMOV"."NUM"<=100              50\nDependency Published SYS.DEMOT                                                                                                                         0\nDependency Published SYS.DEMOV                                                                                                                         0\n<\/code><\/pre>\n
I’ve 100 rows from the first run, invalidated, and them 50 rows from the second one.<\/p>\n
Note that I’ve the same result when I set “_disable_cdb_view_rc_invalidation”=true. Sometimes undocumented parameters behavior cannot be guessed only from their name.<\/p>\n
Fixed tables<\/h3>\n
I’ve run the same testcase but with the following definition of DEMOV:<\/p>\n
\ncreate view DEMOV sharing=object as select saddr id, rownum num from V$SESSION;\n<\/code><\/pre>\n
Here is the trace of the recursive query run in CDB$ROOT, at first execution:<\/p>\n
PARSING IN CURSOR #140436732146672 len=112 dep=1 uid=0 oct=3 lid=0 tim=769208810641 hv=3298783355 ad='108ee92f0' sqlid=' 10qf9kb29yw3v'\nSELECT \/*+ RESULT_CACHE (SYSOBJ=TRUE SHELFLIFE=30) *\/ ID,NUM FROM \"SYS\".\"DEMOV\" \"DEMOV\" WHERE \"DEMOV\".\"NUM\"<=100\nEND OF STMT\nPARSE #140436732146672:c=4000,e=10614,p=0,cr=6,cu=0,mis=1,r=0,dep=1,og=4,plh=350654732,tim=769208810640\nEXEC #140436732146672:c=0,e=17,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,plh=350654732,tim=769208810701\nFETCH #140436732146672:c=1000,e=961,p=0,cr=0,cu=0,mis=0,r=53,dep=1,og=4,plh=350654732,tim=769208811687\nSTAT #140436732146672 id=1 cnt=53 pid=0 pos=1 obj=0 op='RESULT CACHE  byq3fbkawmkm34gtfk1csvwv52 (cr=0 pr=0 pw=0 time=877 us)'\nSTAT #140436732146672 id=2 cnt=53 pid=1 pos=1 obj=98258 op='VIEW  DEMOV (cr=0 pr=0 pw=0 time=655 us cost=0 size=171 card=9)'\nSTAT #140436732146672 id=3 cnt=53 pid=2 pos=1 obj=0 op='COUNT  (cr=0 pr=0 pw=0 time=652 us)'\nSTAT #140436732146672 id=4 cnt=53 pid=3 pos=1 obj=0 op='NESTED LOOPS  (cr=0 pr=0 pw=0 time=597 us cost=0 size=306 card=9)'\nSTAT #140436732146672 id=5 cnt=53 pid=4 pos=1 obj=0 op='NESTED LOOPS  (cr=0 pr=0 pw=0 time=436 us cost=0 size=270 card=9)'\nSTAT #140436732146672 id=6 cnt=53 pid=5 pos=1 obj=0 op='FIXED TABLE FULL X$KSLWT (cr=0 pr=0 pw=0 time=219 us cost=0 size=352 card=44)'\nSTAT #140436732146672 id=7 cnt=53 pid=5 pos=2 obj=0 op='FIXED TABLE FIXED INDEX X$KSUSE (ind:1) (cr=0 pr=0 pw=0 time=101 us cost=0 size=22 card=1)'\nSTAT #140436732146672 id=8 cnt=53 pid=4 pos=2 obj=0 op='FIXED TABLE FIXED INDEX X$KSLED (ind:2) (cr=0 pr=0 pw=0 time=70 us cost=0 size=4 card=1)'<\/code><\/pre>\n
The difference here is that SHELFLIFE=30 has been added to the generated result cache hint.<\/p>\n
The second run has very short parse time (c=0) because it’s a soft parse but you also see very short fetch time (c=0) because it’s a cache hit:<\/p>\n
PARSING IN CURSOR #140436733602136 len=112 dep=1 uid=0 oct=3 lid=0 tim=769208821904 hv=3298783355 ad='108ee92f0' sqlid=' 10qf9kb29yw3v'\nSELECT \/*+ RESULT_CACHE (SYSOBJ=TRUE SHELFLIFE=30) *\/ ID,NUM FROM \"SYS\".\"DEMOV\" \"DEMOV\" WHERE \"DEMOV\".\"NUM\"<=100\nEND OF STMT\nPARSE #140436733602136:c=0,e=29,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,plh=350654732,tim=769208821904\nEXEC #140436733602136:c=0,e=13,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,plh=350654732,tim=769208821955\nFETCH #140436733602136:c=0,e=18,p=0,cr=0,cu=0,mis=0,r=53,dep=1,og=4,plh=350654732,tim=769208821990<\/code><\/pre>\n
When I look at the result cache, there were no invalidations:<\/p>\n
TYPE       STATUS    NAME                                                                                                                      ROW_COUNT\n---------- --------- ------------------------------------------------------------------------------------------------------------------------ ----------\nResult     Published SELECT \/*+ RESULT_CACHE (SYSOBJ=TRUE SHELFLIFE=30) *\/ ID,NUM FROM \"SYS\".\"DEMOV\" \"DEMOV\" WHERE \"DEMOV\".\"NUM\"<=100                 55\nDependency Published SYS.DEMOV                                                                                                                         0<\/code><\/pre>\n
When SHELFLIFE is set in a result cache hint, there is no dependency tracking. I’ve described RESULT_CACHE hint expiration options<\/a> in a previous post.<\/p>\n
The V$ views are on fixed tables, structures in memory, where there is no dependency tracking possibility. This is probably why the recursive query for sharing=object views use a SHELFLIFE instead.<\/p>\n
This means that if you create an object link view on a fixed table the query will show same result for the next executions for 30 seconds.<\/p>\n
“_cdb_view_rc_shelflife”<\/h3>\n
I’ve tested a shared=object view on V$SESSION as an answer to a previous blog comment<\/a>. My query selects MAX(LAST_ET_CALL) which is supposed to increase every second for the inactive sessions. And we see that the result changes only every 30 seconds.<\/p>\n
Those 30 seconds are parametered by “_cdb_view_rc_shelflife”. Here is the same test where I set “_cdb_view_rc_shelflife” to 5 seconds:<\/p>\n
\n15:31:48 SQL> alter session set \"_cdb_view_rc_shelflife\"=5;\nSession altered.\n \n15:31:48 SQL> set serveroutput on\n15:31:48 SQL> declare\n15:31:48   2   x varchar2(100);\n15:31:48   3  begin\n15:31:48   4   for i in 1..60 loop\n15:31:48   5    dbms_lock.sleep(1);\n15:31:48   6    select to_char(current_timestamp)||' --> '||max(last_call_et) into x from DEMOV;\n15:31:48   7    dbms_output.put_line(x);\n15:31:48   8   end loop;\n15:31:48   9  end;\n15:31:48  10  \/\n \n07-AUG-16 03.31.49.852081 PM +00:00 --> 775144\n07-AUG-16 03.31.50.863742 PM +00:00 --> 775144\n07-AUG-16 03.31.51.863753 PM +00:00 --> 775144\n07-AUG-16 03.31.52.864697 PM +00:00 --> 775144\n07-AUG-16 03.31.53.864706 PM +00:00 --> 775144\n07-AUG-16 03.31.54.864726 PM +00:00 --> 775144\n07-AUG-16 03.31.55.864669 PM +00:00 --> 775150\n07-AUG-16 03.31.56.864711 PM +00:00 --> 775150\n07-AUG-16 03.31.57.864754 PM +00:00 --> 775150\n07-AUG-16 03.31.58.864702 PM +00:00 --> 775150\n07-AUG-16 03.31.59.864711 PM +00:00 --> 775150\n07-AUG-16 03.32.00.864779 PM +00:00 --> 775150\n07-AUG-16 03.32.01.865710 PM +00:00 --> 775156\n07-AUG-16 03.32.02.866738 PM +00:00 --> 775156\n07-AUG-16 03.32.03.866719 PM +00:00 --> 775156\n07-AUG-16 03.32.04.866787 PM +00:00 --> 775156\n07-AUG-16 03.32.05.866758 PM +00:00 --> 775156\n07-AUG-16 03.32.06.866805 PM +00:00 --> 775156\n07-AUG-16 03.32.07.867738 PM +00:00 --> 775162\n07-AUG-16 03.32.08.868743 PM +00:00 --> 775162\n07-AUG-16 03.32.09.868727 PM +00:00 --> 775162\n07-AUG-16 03.32.10.868724 PM +00:00 --> 775162\n07-AUG-16 03.32.11.868758 PM +00:00 --> 775162\n07-AUG-16 03.32.12.869763 PM +00:00 --> 775167\n07-AUG-16 03.32.13.870741 PM +00:00 --> 775167\n07-AUG-16 03.32.14.870742 PM +00:00 --> 775167\n07-AUG-16 03.32.15.870721 PM +00:00 --> 775167\n07-AUG-16 03.32.16.870734 PM +00:00 --> 775167\n07-AUG-16 03.32.17.870883 PM +00:00 --> 775167\n07-AUG-16 03.32.18.872741 PM +00:00 --> 775173\n07-AUG-16 03.32.19.873837 PM +00:00 --> 775173\n<\/code><\/pre>\n
And here is the same test after setting:<\/p>\n
\nSQL> exec dbms_result_cache.bypass(true);\n<\/code><\/pre>\n
I’ve not tested, but I expect the same in Standard Edition where result cache is disabled<\/p>\n
\n07-AUG-16 03.43.32.158741 PM +00:00 --> 775846\n07-AUG-16 03.43.33.185793 PM +00:00 --> 775847\n07-AUG-16 03.43.34.186633 PM +00:00 --> 775848\n07-AUG-16 03.43.35.186738 PM +00:00 --> 775849\n07-AUG-16 03.43.36.187696 PM +00:00 --> 775850\n07-AUG-16 03.43.37.188684 PM +00:00 --> 775851\n07-AUG-16 03.43.38.188692 PM +00:00 --> 775852\n07-AUG-16 03.43.39.189755 PM +00:00 --> 775853\n07-AUG-16 03.43.40.190697 PM +00:00 --> 775854\n07-AUG-16 03.43.41.191763 PM +00:00 --> 775855\n07-AUG-16 03.43.42.192706 PM +00:00 --> 775856\n07-AUG-16 03.43.43.193736 PM +00:00 --> 775857\n<\/code><\/pre>\n
Conclusion<\/h3>\n
Don’t be afraid. There are very few sharing=object views in the dictionary, and only few of them have dependencies on fixed tables:<\/p>\n
\nSQL> select owner,name,referenced_name from dba_dependencies\n     where (referenced_owner,referenced_name) in (select 'SYS',view_name from v$fixed_view_definition union select 'SYS',name from v$fixed_table)\n     and (owner,name,type) in (select owner,object_name,object_type from dba_objects where sharing='OBJECT LINK')\n     ;\n \nOWNER                          NAME                           REFERENCED_NAME\n------------------------------ ------------------------------ ------------------------------\nSYS                            INT$DBA_HIST_SQLSTAT           X$MODACT_LENGTH\nSYS                            INT$DBA_HIST_ACT_SESS_HISTORY  X$MODACT_LENGTH\nSYS                            INT$DBA_OUTSTANDING_ALERTS     X$KELTGSD\nSYS                            INT$DBA_OUTSTANDING_ALERTS     X$KELTSD\nSYS                            INT$DBA_OUTSTANDING_ALERTS     X$KELTOSD\nSYS                            INT$DBA_ALERT_HISTORY          X$KELTGSD\nSYS                            INT$DBA_ALERT_HISTORY          X$KELTSD\nSYS                            INT$DBA_ALERT_HISTORY          X$KELTOSD\nSYS                            INT$DBA_ALERT_HISTORY_DETAIL   X$KELTGSD\nSYS                            INT$DBA_ALERT_HISTORY_DETAIL   X$KELTSD\nSYS                            INT$DBA_ALERT_HISTORY_DETAIL   X$KELTOSD\nSYS                            DEMOV                          GV$SESSION\n \n6 rows selected.\n<\/code><\/pre>\n
I’ve described how AWR views are stacked onto each other in a previous post<\/a>.<\/p>\n
And don’t worry, you don’t need to have a fresh view of those X$ tables. As an example, behind DBA_HIST_ACTIVE_SES_HISTORY the fixed table X$MODACT_LENGTH holds only the length of module and action strings:<\/p>\n
SQL> select * from X$MODACT_LENGTH;\n \nADDR                   INDX    INST_ID     CON_ID  KSUMODLEN  KSUACTLEN\n---------------- ---------- ---------- ---------- ---------- ----------\n00007FF2EF280920          0          1          0         48         32<\/code><\/pre>\n
And the others (X$KELTSD, X$KELTGSD, X$KELTOSD) are the structures behind V$ALERT_TYPES that are not supposed to change.<\/p>\n
So don’t panic. The multitenant architecture has some strange implementation stuff, but mostly harmless…<\/p>\n","protected":false},"excerpt":{"rendered":"
By Franck Pachot . The previous post partly answered to the original question (why an object link to V$SESSION is refreshed only every 30 seconds): recursive queries on shared=object views. Now let’s see what is different with fixed tables.<\/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-8712","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":"\nMultitenant internals: object links on fixed tables - 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-object-links-on-fixed-tables\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Multitenant internals: object links on fixed tables\" \/>\n<meta property=\"og:description\" content=\"By Franck Pachot . The previous post partly answered to the original question (why an object link to V$SESSION is refreshed only every 30 seconds): recursive queries on shared=object views. Now let’s see what is different with fixed tables.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-object-links-on-fixed-tables\/\" \/>\n<meta property=\"og:site_name\" content=\"dbi Blog\" \/>\n<meta property=\"article:published_time\" content=\"2016-08-07T14:13:53+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\/multitenant-internals-object-links-on-fixed-tables\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-object-links-on-fixed-tables\/\"},\"author\":{\"name\":\"Oracle Team\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee\"},\"headline\":\"Multitenant internals: object links on fixed tables\",\"datePublished\":\"2016-08-07T14:13:53+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-object-links-on-fixed-tables\/\"},\"wordCount\":653,\"commentCount\":0,\"keywords\":[\"CDB\",\"internals\",\"multitenant\",\"Oracle 12c\",\"Oracle Multitenant\",\"PDB\",\"Pluggable Databases\"],\"articleSection\":[\"Database Administration & Monitoring\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-object-links-on-fixed-tables\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-object-links-on-fixed-tables\/\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-object-links-on-fixed-tables\/\",\"name\":\"Multitenant internals: object links on fixed tables - dbi Blog\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#website\"},\"datePublished\":\"2016-08-07T14:13:53+00:00\",\"author\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee\"},\"breadcrumb\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-object-links-on-fixed-tables\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-object-links-on-fixed-tables\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-object-links-on-fixed-tables\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Accueil\",\"item\":\"https:\/\/www.dbi-services.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Multitenant internals: object links on fixed tables\"}]},{\"@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: object links on fixed tables - 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-object-links-on-fixed-tables\/","og_locale":"en_US","og_type":"article","og_title":"Multitenant internals: object links on fixed tables","og_description":"By Franck Pachot . The previous post partly answered to the original question (why an object link to V$SESSION is refreshed only every 30 seconds): recursive queries on shared=object views. Now let’s see what is different with fixed tables.","og_url":"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-object-links-on-fixed-tables\/","og_site_name":"dbi Blog","article_published_time":"2016-08-07T14:13:53+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\/multitenant-internals-object-links-on-fixed-tables\/#article","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-object-links-on-fixed-tables\/"},"author":{"name":"Oracle Team","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee"},"headline":"Multitenant internals: object links on fixed tables","datePublished":"2016-08-07T14:13:53+00:00","mainEntityOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-object-links-on-fixed-tables\/"},"wordCount":653,"commentCount":0,"keywords":["CDB","internals","multitenant","Oracle 12c","Oracle Multitenant","PDB","Pluggable Databases"],"articleSection":["Database Administration & Monitoring"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.dbi-services.com\/blog\/multitenant-internals-object-links-on-fixed-tables\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-object-links-on-fixed-tables\/","url":"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-object-links-on-fixed-tables\/","name":"Multitenant internals: object links on fixed tables - dbi Blog","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/#website"},"datePublished":"2016-08-07T14:13:53+00:00","author":{"@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee"},"breadcrumb":{"@id":"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-object-links-on-fixed-tables\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.dbi-services.com\/blog\/multitenant-internals-object-links-on-fixed-tables\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/www.dbi-services.com\/blog\/multitenant-internals-object-links-on-fixed-tables\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Accueil","item":"https:\/\/www.dbi-services.com\/blog\/"},{"@type":"ListItem","position":2,"name":"Multitenant internals: object links on fixed tables"}]},{"@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\/8712","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=8712"}],"version-history":[{"count":0,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/8712\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/media?parent=8712"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/categories?post=8712"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/tags?post=8712"},{"taxonomy":"type","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/type_dbi?post=8712"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}