I have received several questions from customers in the past weeks using Oracle Multitenant about the parameter
exclude_seed_cdb_view.It magically disappeared and morphed into
_exclude_seed_cdb_view since Oracle Database 18.104.22.168. To be fair, the
exclude_seed_cdb_view is listed in the list of obsolete parameters in Oracle Database 22.214.171.124.
What is EXCLUDE_SEED_CDB_VIEW?
This parameter hides everything belonging to the
PDB$SEED from the usual queries. For instance you ran a query against
CDB_DATA_FILES but you won’t see the data files belonging to
PDB$SEED in the result set. Whether this is good or bad, at least RMAN (Recovery Manager) worked always correctly.
But I’m not a big fan of “hiding” something. Why do things belonging to the
PDB$SEED are hidden? To me that does not make much sense. I’m one of these people always turning off the “hide file extensions” and “hide system files” on Windows boxes.
In this case I don’t know the deeper reason. For Oracle Database 12.1 I recommend to set
FALSE if you are using Oracle Single-/Multitenant.
SQL> alter system set EXCLUDE_SEED_CDB_VIEW=FALSE scope=both;
Just on the side, the parameter was undocumented in Oracle Database 126.96.36.199.
Why is EXCLUDE_SEED_CDB_VIEW now _EXCLUDE_SEED_CDB_VIEW in Oracle 12.2?
Good question – maybe because underscores don’t have to be documented?I have really no idea.
Fact is that the parameter
exclude_seed_cdb_view morphed into an underscore parameter
_exclude_seed_cdb_view in Oracle Database 188.8.131.52. Though I stay with my recommendation: set it to
SQL> alter system set "_EXCLUDE_SEED_CDB_VIEW"=FALSE scope=both;
Why do I set it to FALSE?
I came across several customer examples where it is essential to see everything. Dagmar Förster from a German insurance raised an issue to me. She is checking if all PDBs are patches correctly by the recent
datapatch run. But when the seed’s objects get excluded by default you won’t find it out:
select CON_ID,PATCH_ID,VERSION,STATUS,ACTION,DESCRIPTION from cdb_registry_sqlpatch order by action_time; CON_ID PATCH_ID VERSION STATUS ACTION DESCRIPTION ------ -------- -------- ------- ------ ---------------------------------------- 1 26123830 184.108.40.206 SUCCESS APPLY DATABASE RELEASE UPDATE 220.127.116.11.170718 3 26123830 18.104.22.168 SUCCESS APPLY DATABASE RELEASE UPDATE 22.214.171.124.170718 4 26123830 126.96.36.199 SUCCESS APPLY DATABASE RELEASE UPDATE 188.8.131.52.170718
Reminds me a lot on Where’s Wally? Obviously you don’t see information about whether the July 2017 RU’s SQL changes have been applied to the
CON_ID=2) or not. Everything belonging to
CON_ID=2 gets hidden.
And this is just one of a number of examples I’ve heard about in the past weeks.
cdb_registry_sqlpatch is not showing any data, returning no rows. I see data in dba_registry_sqlpatch when i logged into the ROOT ,SEED$ and other PDB’s. This behavior is consistence across all 19.8.0 and 19.10.0 databases. What we missing here ? Please advise.
I have no idea – I use my check_patches_19.sql script from here:
and it works perfectly fine.