{ "date": "2016-08-07T16:13:53", "slug": "multitenant-internals-object-links-on-fixed-tables", "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

\n

.
\nThe 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
\nDisclaimer: this is research only. Don’t do that anywhere else than a lab. This is implicit when the title is ‘internals’.

\n

Result cache

\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:

\n
/*+ RESULT_CACHE (SYSOBJ=TRUE) */
\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.

\n

Here is the result cache from the previous post (I flushed the result cache just before the second run because in 12c hard parsing is also using a lot the result cache):

\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
\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.

\n

Invalidation

\n

I did the same when deleting half of the rows before the second execution in order to invalidate the result cache:

\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
\n

I’ve 100 rows from the first run, invalidated, and them 50 rows from the second one.

\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.

\n

Fixed tables

\n

I’ve run the same testcase but with the following definition of DEMOV:

\n
\ncreate view DEMOV sharing=object as select saddr id, rownum num from V$SESSION;\n
\n

Here is the trace of the recursive query run in CDB$ROOT, at first execution:

\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)'
\n

The difference here is that SHELFLIFE=30 has been added to the generated result cache hint.

\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:

\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
\n

When I look at the result cache, there were no invalidations:

\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
\n

When SHELFLIFE is set in a result cache hint, there is no dependency tracking. I’ve described RESULT_CACHE hint expiration options in a previous post.

\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.

\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.

\n

“_cdb_view_rc_shelflife”

\n

I’ve tested a shared=object view on V$SESSION as an answer to a previous blog comment. 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.

\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:

\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
\n

And here is the same test after setting:

\n
\nSQL> exec dbms_result_cache.bypass(true);\n
\n

I’ve not tested, but I expect the same in Standard Edition where result cache is disabled

\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
\n

Conclusion

\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:

\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
\n

I’ve described how AWR views are stacked onto each other in a previous post.

\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:

\n
SQL> select * from X$MODACT_LENGTH;\n \nADDR                   INDX    INST_ID     CON_ID  KSUMODLEN  KSUACTLEN\n---------------- ---------- ---------- ---------- ---------- ----------\n00007FF2EF280920          0          1          0         48         32
\n

And the others (X$KELTSD, X$KELTGSD, X$KELTOSD) are the structures behind V$ALERT_TYPES that are not supposed to change.

\n

So don’t panic. The multitenant architecture has some strange implementation stuff, but mostly harmless…

\n", "protected": false } }