In Oracle 12c multitenant container, there are some new views that complement the USER_, ALL_ and DBA_Views, the CDB_ views.
For example, CDB_TABLES, CDB_OBJECTS, CDB_VIEWS etc. Those views give information for all containers. For example, CDB_TABLES references all tables information in all containers (CDB$ROOT, PDB$SEED and all plugabble databases). Those views have a new column CON_ID that reference the container id, for example:
If you have a closer look to the view definition, you will find that every CDB_ view uses a specific function named CDB$VIEW:
[SYS@CDB$ROOT | SID:CDB]> select dbms_metadata.get_ddl('VIEW','CDB_TABLES') from dual;
DBMS_METADATA.GET_DDL('VIEW','CDB_TABLES')
--------------------------------------------------------------------------------
CREATE OR REPLACE FORCE NONEDITIONABLE VIEW "SYS"."CDB_TABLES" CONTAINER_DATA
("OWNER", "TABLE_NAME", "TABLESPACE_NAME", "CLUSTER_NAME", "IOT_NAME", "STATUS"
, "PCT_FREE", "PCT_USED", "INI_TRANS", "MAX_TRANS", "INITIAL_EXTENT", "NEXT_EXTE
NT", "MIN_EXTENTS", "MAX_EXTENTS", "PCT_INCREASE", "FREELISTS", "FREELIST_GROUPS
", "LOGGING", "BACKED_UP", "NUM_ROWS", "BLOCKS", "EMPTY_BLOCKS", "AVG_SPACE", "C
HAIN_CNT", "AVG_ROW_LEN", "AVG_SPACE_FREELIST_BLOCKS", "NUM_FREELIST_BLOCKS", "D
EGREE", "INSTANCES", "CACHE", "TABLE_LOCK", "SAMPLE_SIZE", "LAST_ANALYZED", "PAR
TITIONED", "IOT_TYPE", "TEMPORARY", "SECONDARY", "NESTED", "BUFFER_POOL", "FLASH
_CACHE", "CELL_FLASH_CACHE", "ROW_MOVEMENT", "GLOBAL_STATS", "USER_STATS", "DURA
TION", "SKIP_CORRUPT", "MONITORING", "CLUSTER_OWNER", "DEPENDENCIES", "COMPRESSI
ON", "COMPRESS_FOR", "DROPPED", "READ_ONLY", "SEGMENT_CREATED", "RESULT_CACHE",
"CLUSTERING", "ACTIVITY_TRACKING", "DML_TIMESTAMP", "HAS_IDENTITY", "CONTAINER_D
ATA", "CON_ID") AS
SELECT "OWNER","TABLE_NAME","TABLESPACE_NAME","CLUSTER_NAME","IOT_NAME","STATU
S","PCT_FREE","PCT_USED","INI_TRANS","MAX_TRANS","INITIAL_EXTENT","NEXT_EXTENT",
"MIN_EXTENTS","MAX_EXTENTS","PCT_INCREASE","FREELISTS","FREELIST_GROUPS","LOGGIN
G","BACKED_UP","NUM_ROWS","BLOCKS","EMPTY_BLOCKS","AVG_SPACE","CHAIN_CNT","AVG_R
OW_LEN","AVG_SPACE_FREELIST_BLOCKS","NUM_FREELIST_BLOCKS","DEGREE","INSTANCES","
CACHE","TABLE_LOCK","SAMPLE_SIZE","LAST_ANALYZED","PARTITIONED","IOT_TYPE","TEMP
ORARY","SECONDARY","NESTED","BUFFER_POOL","FLASH_CACHE","CELL_FLASH_CACHE","ROW_
MOVEMENT","GLOBAL_STATS","USER_STATS","DURATION","SKIP_CORRUPT","MONITORING","CL
USTER_OWNER","DEPENDENCIES","COMPRESSION","COMPRESS_FOR","DROPPED","READ_ONLY","
SEGMENT_CREATED","RESULT_CACHE","CLUSTERING","ACTIVITY_TRACKING","DML_TIMESTAMP"
,"HAS_IDENTITY","CONTAINER_DATA","CON_ID" FROM CDB$VIEW("SYS"."DBA_TABLES")
After searching a long time, I didn’t find any definition of this function, so I decided to search more about its behaviour.
First of all, this function seems “to transform” the view or the table given in parameter by adding a CON_ID table. We will see later that it’s not a CBO transformation as we know it but a “low level” transformation performed before SQL parsing.
CDB$VIEW function can be used with static views (DBA_TABLES, DBA_OBJECTS etc.), dictionary tables (OBJ$, USER$, FILE$ etc.), on dynamic performance views and X$ fixed tables, but on those two last items, the result is a little bit different than other.
[SYS@CDB$ROOT | SID:CDB]> select count(*) from cdb$view("DBA_TABLES");
COUNT(*)
----------
6956
[SYS@CDB$ROOT | SID:CDB]> select count(*) from cdb$view("OBJ$");
COUNT(*)
----------
272326
In a multitenant database, each container has its own dictionary, for example, CDB$ROOT has its OBJ$ table, the PDB$SEED has its own one and every pluggable database has its own OBJ$ table. So, the goal of this function is to give a global view from all containers.
But, as the OBJ$ table has the same name in every container, and as there’s no method to access a specific dictionary table of a pluggable database from the root container, the CDB$VIEW function is used to aggregate data from a specific view or table executed in each container:
[SYS@CDB$ROOT | SID:CDB]> show con_id;
CON_ID
------------------------------
1
[SYS@CDB$ROOT | SID:CDB]> select count(*) from obj$;
COUNT(*)
----------
90847
[SYS@CDB$ROOT | SID:CDB]> select con_id,count(*) from cdb$view("OBJ$") group by con_id;
CON_ID COUNT(*)
---------- ----------
1 90847
2 90716
3 90763
Now, let’s have a closer look to the generated plan:
[SYS@CDB$ROOT | SID:CDB]> select count(*) from obj$;
COUNT(*)
----------
90847
Execution Plan
----------------------------------------------------------
Plan hash value: 3951003077
------------------------------------------------------------------------
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 91 (0)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | | |
| 2 | INDEX FAST FULL SCAN| I_OBJ1 | 90910 | 91 (0)| 00:00:01 |
------------------------------------------------------------------------
[SYS@CDB$ROOT | SID:CDB]> select count(*) from cdb$view("OBJ$");
COUNT(*)
----------
272326
Execution Plan
----------------------------------------------------------
Plan hash value: 2345629731
-----------------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
-----------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 2 (100)| 00:00:01 | | | | | |
| 1 | SORT AGGREGATE | | 1 | | | | | | | |
| 2 | PX COORDINATOR | | | | | | | | | |
| 3 | PX SEND QC (RANDOM) | :TQ10000 | 1 | | | | | Q1,00 | P->S | QC (RAND) |
| 4 | SORT AGGREGATE | | 1 | | | | | Q1,00 | PCWP | |
| 5 | PX PARTITION LIST ALL| | 90910 | 2 (100)| 00:00:01 | 1 | 254 | Q1,00 | PCWC | |
| 6 | FIXED TABLE FULL | X$CDBVW$c2fad3da | 90910 | 2 (100)| 00:00:01 | | | Q1,00 | PCWP | |
-----------------------------------------------------------------------------------------------------------------------------------
There are two interesting things to note:
- CDB$VIEW transform the statement to query an X$CDBVW$c2fad3da fixed table
- This fixed table is read in parallel
About the transformation, I noticed many things.
First, if we query another table or view, another X$CDBVW$ is generated:
[SYS@CDB$ROOT | SID:CDB]> select count(*) from cdb$view("TAB$");
COUNT(*)
----------
7098
Execution Plan
----------------------------------------------------------
Plan hash value: 111784239
-----------------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
-----------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 0 (0)| 00:00:01 | | | | | |
| 1 | SORT AGGREGATE | | 1 | | | | | | | |
| 2 | PX COORDINATOR | | | | | | | | | |
| 3 | PX SEND QC (RANDOM) | :TQ10000 | 1 | | | | | Q1,00 | P->S | QC (RAND) |
| 4 | SORT AGGREGATE | | 1 | | | | | Q1,00 | PCWP | |
| 5 | PX PARTITION LIST ALL| | 2372 | 0 (0)| 00:00:01 | 1 | 254 | Q1,00 | PCWC | |
| 6 | FIXED TABLE FULL | X$CDBVW$00303d4d | 2372 | 0 (0)| 00:00:01 | | | Q1,00 | PCWP | |
-----------------------------------------------------------------------------------------------------------------------------------
So, it seems that there’s a hash added at the end of this X$CDBVW$. It’s interesting to see that the fixed table X$CDBVW$ exists in the instance but have no rows recorded in:
[SYS@CDB$ROOT | SID:CDB]> desc X$CDBVW$
Name Null? Type
----------------------------------------- -------- ----------------------------
ADDR RAW(8)
INDX NUMBER
INST_ID NUMBER
CON_ID NUMBER
[SYS@CDB$ROOT | SID:CDB]> select * from X$CDBVW$;
no rows selected
Second thing to note is this transformation is not a CBO transformation, indeed if you have a closer look to a 10053 trace file, the query has already been rewrited before parsing:
Stmt: ******* UNPARSED QUERY IS *******
SELECT COUNT(*) "COUNT(*)" FROM "SYS"."X$CDBVW$00303d4d" "TAB$"
Objects referenced in the statement
X$CDBVW$00303d4d[TAB$] 4, type = 1
Objects in the hash table
Hash table Object 4, type = 1, ownerid = 795352840147398986:
Dynamic Sampling Directives at location 1:
dirid = 11259849835960924452, state = 5, flags = 1, loc = 1 {E(4)[30]}
Return code in qosdInitDirCtx: ENBLD
Concerning the parallel execution, I noticed partition pruning is made upon the CON_ID column:
[SYS@CDB$ROOT | SID:CDB]> alter session set "_partition_cdb_view_enabled"=FALSE;
Session altered.
[SYS@CDB$ROOT | SID:CDB]> select count(*) from cdb$view("TAB$");
COUNT(*)
----------
7098
Execution Plan
----------------------------------------------------------
Plan hash value: 4209588238
------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 0 (0)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | | |
| 2 | FIXED TABLE FULL| X$CDBVW$00303d4d | 2372 | 0 (0)| 00:00:01 |
------------------------------------------------------------------------------
- _px_cdb_view_enabled: this parameter seems to disable parallel scan of the X$CDBVW$ view
[SYS@CDB$ROOT | SID:CDB]> alter session set "_px_cdb_view_enabled"=FALSE;
Session altered.
[SYS@CDB$ROOT | SID:CDB]> select count(*) from cdb$view("TAB$");
COUNT(*)
----------
7098
Execution Plan
----------------------------------------------------------
Plan hash value: 3630495286
------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Cost (%CPU)| Time | Pstart| Pstop |
------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 0 (0)| 00:00:01 | | |
| 1 | SORT AGGREGATE | | 1 | | | | |
| 2 | PARTITION LIST ALL| | 2372 | 0 (0)| 00:00:01 | 1 | 254 |
| 3 | FIXED TABLE FULL | X$CDBVW$00303d4d | 2372 | 0 (0)| 00:00:01 | | |
------------------------------------------------------------------------------------------------
On the CBO side, I tried to have a closer look on how statistics are evaluated for this particular view.
It seems that the CBO uses the cardinality of the dictionary table available in the CDB$ROOT container and ignore the statistics of the other dictionary table (taken from the other containers):
[SYS@CDB$ROOT | SID:CDB]> select con_id,table_name,num_rows from cdb_tables where table_name='TAB$';
CON_ID TABLE_NAME NUM_ROWS
---------- --------------- ----------
1 TAB$ 2372
2 TAB$ 1462
3 TAB$ 2363
[SYS@CDB$ROOT | SID:CDB]> alter session set events '10053 trace name context forever, level 1';
Session altered.
[SYS@CDB$ROOT | SID:CDB]> select /* PARSE_ME */ count(*) from cdb$view("TAB$");
COUNT(*)
----------
7098
But If we have a closer look to the generated 10053 trace file, and the cardinalities seems to be a little bit different from reality:
***************************************
BASE STATISTICAL INFORMATION
***********************
Table Stats::
Table: X$CDBVW$00303d4d Alias: TAB$
#Rows: 2372 #Blks: 1487 AvgRowLen: 134.00 ChainCnt: 0.00
FixedTabRowCost: 1000.00
=======================================
SPD: BEGIN context at query block level
=======================================
Query Block SEL$1 (#0)
Return code in qosdSetupDirCtx4QB: NOCTX
=====================================
SPD: END context at query block level
=====================================
Access path analysis for X$CDBVW$00303d4d
***************************************
SINGLE TABLE ACCESS PATH
Single Table Cardinality Estimation for X$CDBVW$00303d4d[TAB$]
SPD: Return code in qosdDSDirSetup: NOCTX, estType = TABLE
Table: X$CDBVW$00303d4d Alias: TAB$
Card: Original: 2372.000000 Rounded: 2372 Computed: 2372.00 Non Adjusted: 2372.00
Access Path: TableScan
Cost: 0.06 Resp: 0.06 Degree: 0
Cost_io: 0.00 Cost_cpu: 2372000
Resp_io: 0.00 Resp_cpu: 2372000
Best:: AccessPath: TableScan
Cost: 0.06 Degree: 1 Resp: 0.06 Card: 2372.00 Bytes: 0
***************************************
.../...
============
Plan Table
============
-----------------------------------------------------+-----------------------------------+-------------------------+---------------+
| Id | Operation | Name | Rows | Bytes | Cost | Time | TQ |IN-OUT|PQ Distrib | Pstart| Pstop |
-----------------------------------------------------+-----------------------------------+-------------------------+---------------+
| 0 | SELECT STATEMENT | | | | 1 | | | | | | |
| 1 | SORT AGGREGATE | | 1 | | | | | | | | |
| 2 | PX COORDINATOR | | | | | | | | | | |
| 3 | PX SEND QC (RANDOM) | :TQ10000 | 1 | | | |:Q1000| P->S |QC (RANDOM)| | |
| 4 | SORT AGGREGATE | | 1 | | | |:Q1000| PCWP | | | |
| 5 | PX PARTITION LIST ALL | | 2372 | | 0 | |:Q1000| PCWC | | 1 | 254 |
| 6 | FIXED TABLE FULL | X$CDBVW$00303d4d| 2372 | | 0 | |:Q1000| PCWP | | | |
-----------------------------------------------------+-----------------------------------+-------------------------+---------------+
Now imagine, you have consolidated a multitenant database with 200 pdbs, each pdb host an ERP with tons of table, you will have a small difference between evaluation and real row count.
To conclude this part, If you perform the same analysis but you query the CDB_TABLES view, this one will be rewrite in CDB$VIEW(“DBA_TABLES”). As the DBA_TABLES is a view and is not analyzed, Oracle seems to set the cardinality to 10000 rows. I have made some tests on many views and it’s always the same cardinality : 10000 rows and 0 block.
***************************************
BASE STATISTICAL INFORMATION
***********************
Table Stats::
Table: X$CDBVW$73c6ce97 Alias: DBA_TABLES (NOT ANALYZED)
#Rows: 10000 #Blks: 0 AvgRowLen: 464.00 ChainCnt: 0.00
FixedTabRowCost: 1000.00
=======================================
SPD: BEGIN context at query block level
=======================================
Query Block SEL$F5BB74E1 (#0)
Return code in qosdSetupDirCtx4QB: NOCTX
=====================================
SPD: END context at query block level
=====================================
Access path analysis for X$CDBVW$73c6ce97
***************************************
SINGLE TABLE ACCESS PATH
Single Table Cardinality Estimation for X$CDBVW$73c6ce97[DBA_TABLES]
SPD: Return code in qosdDSDirSetup: NOCTX, estType = TABLE
Table: X$CDBVW$73c6ce97 Alias: DBA_TABLES
Card: Original: 10000.000000 Rounded: 10000 Computed: 10000.00 Non Adjusted: 10000.00
Access Path: TableScan
Cost: 0.25 Resp: 0.25 Degree: 0
Cost_io: 0.00 Cost_cpu: 10000000
Resp_io: 0.00 Resp_cpu: 10000000
Best:: AccessPath: TableScan
Cost: 0.25 Degree: 1 Resp: 0.25 Card: 10000.00 Bytes: 0
***************************************
To conclude this part, even if statistics on CDB$VIEW(“DBA_TABLES”) are always set to 10000 rows, it is safe to use CDB_ views directly instead on CDB$VIEW function on a dictionary table, even if I didn’t find any more accurate method.
The last researches I’ve made is on how the Oracle kernel will transform the query before parsing.
As we saw previously, the CBO receives an unparsed query which is already rewritten with the X$CDBVW$ view, so the transformation might be performed at a low level.
In Oracle 12c there’s a new object file fitted in libserver.a library (you can get this file in the 12.1 PSU2 files directory). This object file is named kpdbcv.o and it contains many function named kpdbcv* (I think this means Kernel PDB Cdb View).
[oracle@oel63 libserver12.a]$ pwd
/home/oracle/patch/17552800/files/lib/libserver12.a
[oracle@oel63 libserver12.a]$ readelf -a kpdbcv.o | grep FUNC
7: 0000000000000270 448 FUNC LOCAL DEFAULT 4 kpdbcvRwtToInlineView
10: 00000000000008f0 1216 FUNC LOCAL DEFAULT 4 kpdbcvLoadFragDescr
13: 0000000000001c60 96 FUNC LOCAL DEFAULT 4 kpdbcvLoadBaseInfo
14: 00000000000003b0 80 FUNC LOCAL DEFAULT 3 kpdbcvBuildColNames
15: 0000000000009d50 1680 FUNC LOCAL DEFAULT 3 kpdbcvGetSysCtxCurrUser
16: 0000000000001940 7616 FUNC LOCAL DEFAULT 3 kpdbcvFetchCbkCon
17: 0000000000003700 96 FUNC LOCAL DEFAULT 3 kpdbcvFetchCbkSys
18: 0000000000004ff0 1680 FUNC LOCAL DEFAULT 3 kpdbcvInsBaseViewStats
19: 0000000000005680 1744 FUNC LOCAL DEFAULT 3 kpdbcvGetBaseViewRowCnt
20: 0000000000006bc0 1792 FUNC LOCAL DEFAULT 3 kpdbcvGetBaseViewStats
21: 00000000000072c0 1136 FUNC LOCAL DEFAULT 3 kpdbcvGetFxdViewStats
22: 0000000000007730 544 FUNC LOCAL DEFAULT 3 kpdbcvFxdViewStatsCbk
23: 0000000000007b30 80 FUNC LOCAL DEFAULT 3 kpdbcvGetConIdCnt
24: 0000000000007b80 448 FUNC LOCAL DEFAULT 3 kpdbcvConIdMorph
25: 0000000000007d40 80 FUNC LOCAL DEFAULT 3 kpdbcvGatherBind
26: 0000000000007d90 2304 FUNC LOCAL DEFAULT 3 kpdbcvPrintPredText
27: 0000000000008690 304 FUNC LOCAL DEFAULT 3 kpdbcvVisitPreds
28: 00000000000087c0 384 FUNC LOCAL DEFAULT 3 kpdbcvVisitOpns
29: 0000000000008940 384 FUNC LOCAL DEFAULT 3 kpdbcvReplaceBind
30: 0000000000008ac0 2944 FUNC LOCAL DEFAULT 3 kpdbcvIsValidWhere
31: 0000000000009640 1648 FUNC LOCAL DEFAULT 3 kpdbcvPredicateToText
37: 0000000000000010 32 FUNC GLOBAL DEFAULT 3 kpdbcdbvwcbk
38: 0000000000000030 16 FUNC GLOBAL DEFAULT 3 kpdbcvComDataCbk
40: 0000000000000010 608 FUNC GLOBAL DEFAULT 4 kpdbcvXformFrodef
52: 0000000000000430 1216 FUNC GLOBAL DEFAULT 4 kpdbcvLoadPartDescr
73: 0000000000000db0 320 FUNC GLOBAL DEFAULT 4 kpdbcvIsPartitioned
88: 0000000000000050 784 FUNC GLOBAL DEFAULT 3 kpdbcvIsParallelizable
93: 0000000000000360 64 FUNC GLOBAL DEFAULT 3 kpdbcvGetDOP
99: 0000000000000f00 3232 FUNC GLOBAL DEFAULT 4 kpdbcvLoad
135: 0000000000000400 5440 FUNC GLOBAL DEFAULT 3 kpdbcvFetchStart
201: 0000000000003760 4560 FUNC GLOBAL DEFAULT 3 kpdbcvFetch
216: 0000000000004930 304 FUNC GLOBAL DEFAULT 3 kpdbcvCleanup
217: 0000000000001bb0 160 FUNC GLOBAL DEFAULT 4 kpdbcvIsCDBViewOwner
219: 0000000000004a70 1408 FUNC GLOBAL DEFAULT 3 kpdbcvDelALLBaseViewStats
221: 0000000000005d50 3696 FUNC GLOBAL DEFAULT 3 kpdbcvInsALLBaseViewStats
222: 0000000000007950 48 FUNC GLOBAL DEFAULT 3 kpdbcvCDBViewStatsCbk
223: 0000000000007980 48 FUNC GLOBAL DEFAULT 3 kpdbcvComDataStatsCbk
224: 00000000000079b0 384 FUNC GLOBAL DEFAULT 3 kpdbcvGetParamValue
241: 0000000000009cb0 160 FUNC GLOBAL DEFAULT 3 kpdbcvAllocate
Depending on the context (cdb view partitoning enabled or not, parallel scan enabled or not), you will have a different call stack, but with gdb I found that the common point is the first function called which is kpdbcvXformFrodef function.
If you are curious and want to view the kpdbcv* function call stack during a select on CDB_ view, you can use gdb:
(gdb) rbreak ^kpdbcv
(gdb) commands
Type commands for breakpoint(s) 1-38, one per line.
End with a line saying just "end".
>continue
>end
(gdb) c
Continuing.
Breakpoint 1, 0x0000000002578620 in kpdbcvXformFrodef ()
Breakpoint 6, 0x0000000002579510 in kpdbcvLoad ()
Breakpoint 5, 0x00000000025793c0 in kpdbcvIsPartitioned ()
Breakpoint 5, 0x00000000025793c0 in kpdbcvIsPartitioned ()
Breakpoint 3, 0x0000000002578a40 in kpdbcvLoadPartDescr ()
Breakpoint 4, 0x0000000002578f00 in kpdbcvLoadFragDescr ()
Breakpoint 4, 0x0000000002578f00 in kpdbcvLoadFragDescr ()
.../...
Breakpoint 4, 0x0000000002578f00 in kpdbcvLoadFragDescr ()
Breakpoint 4, 0x0000000002578f00 in kpdbcvLoadFragDescr ()
Breakpoint 4, 0x0000000002578f00 in kpdbcvLoadFragDescr ()
Breakpoint 7, 0x000000000257a1c0 in kpdbcvIsCDBViewOwner ()
Breakpoint 25, 0x00000000083cd580 in kpdbcvCDBViewStatsCbk ()
Breakpoint 24, 0x00000000083cd360 in kpdbcvFxdViewStatsCbk ()
Breakpoint 23, 0x00000000083ccef0 in kpdbcvGetFxdViewStats ()
Breakpoint 22, 0x00000000083cc7f0 in kpdbcvGetBaseViewStats ()
Breakpoint 22, 0x00000000083cc7f0 in kpdbcvGetBaseViewStats ()
Breakpoint 10, 0x00000000083c5c80 in kpdbcvIsParallelizable ()
Breakpoint 5, 0x00000000025793c0 in kpdbcvIsPartitioned ()
Breakpoint 11, 0x00000000083c5f90 in kpdbcvGetDOP ()
Breakpoint 37, 0x00000000083cf8e0 in kpdbcvAllocate ()
Breakpoint 36, 0x00000000083cf270 in kpdbcvPredicateToText ()
To sum up this post, we have to keep in mind that queries on CDB_ views use an internal function CDB$VIEW that transform the sql text before parsing and as a result, there is a new fixed table X$CDBVW$ concatenated to a hash that might identify the source table or view. The statement that will run by default in parallel mode because the X$CDBVW$ fixed table is build as partitioned (by default).
On the CBO side, the result of the CDB_ view transformation give an object which have a default cardinality that seems to be always set at a value of 10000 rows. The result is quite different if you try to run CDB$VIEW on dictionary tables (OBJ$, TAB$ etc) and can give some trouble if you have a lot of PDBs opened in your container.
All this transformations seem to be hard coded (partially) in an object file kpdbcv.o included in the libserver12.a library.
Data ... as usual 