.
\nI’ve described Oracle 12c metadata and object links internals in a previous post. But before that, the first time I investigated on it, I made a wrong assumption because I was looking at AUDIT_ACTIONS which is not correctly implemented. That investigation came from a question on dba-village. And recently Ivica Arsov (@IvicaArsov) has made an interesting comment about AUDIT_ACTIONS object link table, so I’ll explain here what is special with it.
Here is how is defined AUDIT_ACTIONS:
\nSQL> select object_name,object_type,sharing from dba_objects where object_name in ('DBA_AUDIT_TRAIL','AUDIT_ACTIONS') order by object_name,object_type;\n\nOBJECT_NAME OBJECT_TYPE SHARING\n-------------------- --------------- -------------\nAUDIT_ACTIONS SYNONYM METADATA LINK\nAUDIT_ACTIONS TABLE OBJECT LINK\nDBA_AUDIT_TRAIL SYNONYM METADATA LINK\nDBA_AUDIT_TRAIL VIEW METADATA LINK\nIt’s a sharing=object table so you expect that the data is common to all containers. And we will also query a view that reads that table – DBA_AUDIT_TRAIL.
\nThen let’s query the table from CDB$ROOT and from a PDB and check from ROWID if we read the same rows:
\nSQL> alter session set container=CDB$ROOT;\nSession altered.\n\nSQL> select rowid,action,name,dbms_rowid.rowid_to_absolute_fno(rowid,'SYS','AUDIT_ACTIONS') file_id from AUDIT_ACTIONS where action=3;\n\nROWID ACTION NAME FILE_ID\n------------------ ---------- ------- ----------\nAAABG7AABAAACo5AAD 3 SELECT 1\n\nSQL> alter session set container=PDB1;\nSession altered.\n\nSQL> select rowid,action,name,dbms_rowid.rowid_to_absolute_fno(rowid,'SYS','AUDIT_ACTIONS') file_id from AUDIT_ACTIONS where action=3;\n\nROWID ACTION NAME FILE_ID\n------------------ ---------- ------- ----------\nAAABG5AABAAAA3pAAD 3 SELECT 8\n\nThe rows are not coming from the same file, but from the local SYSTEM tablespace of each container. This is a proof that this OBJECT LINK table is not common at all.
\nNow I want to check what happens when we query through the view. I don’t have the ROWID so let’s update the table in the PDB so that we can distinguish rows coming from CDB$ROOT and from PDB1:
\nSQL> update AUDIT_ACTIONS set name='select' where action=3;\n\n1 row updated.\n\nSQL> select rowid,action,name from AUDIT_ACTIONS where action=3;\n\nROWID ACTION NAME\n------------------ ---------- -------\nAAABG5AABAAAA3pAAD 3 select\n\nSQL> select distinct dbid,action,action_name from DBA_AUDIT_TRAIL;\n\n DBID ACTION ACTION_NAME\n---------- ---------- ----------------------------\n 314687597 3 select\n\nOk. I’ve changed one ‘ACTION_NAME’ to lowercase – only in the PDB1. And when I query through the view I see the local row. This definitly prooves that the implementation of AUDIT_ACTIONS is not achieving the goal of multinenant dictionary: store common oracle objects only in CDB$ROOT to avoid duplication and faciliate upgrade. Note that it is not a big problem anyway as it is just a 200 rows table.
\nIn order to show the normal behaviour of object links I’ll do the same with DBA_CPOOL_INFO which is a view over SYS.CPOOL$. I’ve described this behaviour previously by creating my own objects but here I’ll show how it is used to store the DRCP information which is at CDB level. Here are the involved table and views:
\nSQL> select object_name,object_type,sharing from dba_objects where object_name in ('CPOOL$','INT$DBA_CPOOL_INFO','DBA_CPOOL_INFO') order by object_name,object_type;\n\nOBJECT_NAME OBJECT_TYPE SHARING\n-------------------- --------------- -------------\nCPOOL$ TABLE OBJECT LINK\nDBA_CPOOL_INFO SYNONYM METADATA LINK\nDBA_CPOOL_INFO VIEW METADATA LINK\nINT$DBA_CPOOL_INFO VIEW OBJECT LINK\nCPOOL$ is defined with sharing=object. An internal view INT$DBA_CPOOL_INFO is defined on it with sharing=object as well. And finally that view is exposed through DBA_CPOOL_INFO.
\nAs before, I check the ROWID of CPOOL$ row from CDB$ROOT and PDB1:
\nSQL> alter session set container=CDB$ROOT;\nSession altered.\n\nSQL> select rowid,minsize,dbms_rowid.rowid_to_absolute_fno(rowid,'SYS','CPOOL$') file_id from SYS.CPOOL$;\n\nROWID MINSIZE FILE_ID\n------------------ ---------- ----------\nAAABz5AABAAADb5AAA 4 1\n\nSQL> alter session set container=PDB1;\nSession altered.\n\nSQL> select rowid,minsize,dbms_rowid.rowid_to_absolute_fno(rowid,'SYS','CPOOL$') file_id from SYS.CPOOL$;\n\nROWID MINSIZE FILE_ID\n------------------ ---------- ----------\nAAABz3AABAAABQJAAA 4 8\n\nSo this is the same as we have seen before: an OBJECT LINK has its data in each PDB.
\nBut what is different here is the view charing which is sharing=object. Let’s query that view after changing the value in PDB1:
\nSQL> update SYS.CPOOL$ set minsize=0;\n1 row updated.\n\nSQL> select rowid,minsize,dbms_rowid.rowid_to_absolute_fno(rowid,'SYS','CPOOL$') file_id from SYS.CPOOL$;\n\nROWID MINSIZE FILE_ID\n------------------ ---------- ----------\nAAABz3AABAAABQJAAA 0 8\n\nSQL> select minsize from INT$DBA_CPOOL_INFO;\n\n MINSIZE\n----------\n 4\n\nSQL> select minsize from DBA_CPOOL_INFO;\n\n MINSIZE\n----------\n 4\n\nNow we have a view which will always show the CDB$ROOT rows, even when we are in a PDB container. We still have rows in the PDB containers, but they will not be used. Once again, this defeats the goal of deduplication, but this is a very small table.
\nThe main advantage of multitenant dictionary architecture is with the big tables storing data which is common in the whole CDB, such as the AWR data:
\nSQL> alter session set container=CDB$ROOT;\nSession altered.\n\nSQL> select con_id,count(*) from containers(WRH$_SQLTEXT) group by con_id;\n\n CON_ID COUNT(*)\n---------- ----------\n 1 5549\n\nSQL> alter session set container=PDB1;\n\nSession altered.\n\nSQL> select count(*) from WRH$_SQLTEXT;\n\n COUNT(*)\n----------\n 0\n\nThis information – stored only from CDB$ROOT – is shared in all PDB through the OBJECT LINK view.
\n", "protected": false } }