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 12.2.0.1. To be fair, the exclude_seed_cdb_view
is listed in the list of obsolete parameters in Oracle Database 12.2.0.1.
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 exclude_seed_cdb
_view to 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 12.1.0.2.
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 12.2.0.1. Though I stay with my recommendation: set it to FALSE
:
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 12.2.0.1 SUCCESS APPLY DATABASE RELEASE UPDATE 12.2.0.1.170718 3 26123830 12.2.0.1 SUCCESS APPLY DATABASE RELEASE UPDATE 12.2.0.1.170718 4 26123830 12.2.0.1 SUCCESS APPLY DATABASE RELEASE UPDATE 12.2.0.1.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 PDB$SEED
(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.
–Mike
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.
Hi Rakesh,
I have no idea – I use my check_patches_19.sql script from here:
https://mikedietrichde.com/scripts/
and it works perfectly fine.
Cheers,
Mike