Your container database, CDB1, is in local undo mode.
You successfully execute this command while connected to CDB1:
CREATE PLUGGABLE DATABASE pdb1 -
ADMIN USER pdb1_admin IDENTIFIED BY pdb123 ROLES=(CONNECT)
CREATE_FILE_DEST='/u01/app/oracle/oradata/cdb1/pdb1';
Which three are true about PDB1? (Choose three.)
After the PDB1 pluggable database is created, a service named PDB1 is automatically created to allow remote logins, ensuring that connections can be established to the PDB1. It is initially in a mount state because the default action after creation is to place the PDB in this state before it can be opened. PDB1 contains the same common users as CDB1 because these users are defined across the entire container database architecture, ensuring that all PDBs within the CDB have access to these common users.
ABE correct
Seems ABD is correct because GSMROOTUSER is only for CDB$ROOT
ABD is the correct answer
You cant create local roles in CDB, only common, so always you will have the same number of roles when you create a pdb, all common roles that you have in CDB. ABD is the correct answer.
ABD. I created pdb3 with con_id=9. SQL> select con_id, count(1) from cdb_users where con_id in (1,9) and common='YES' group by con_id; CON_ID COUNT(1) ---------- ---------- 9 36 1 37 SQL> select con_id, count(1) from cdb_roles where con_id in (1,9) and common='YES' group by con_id; CON_ID COUNT(1) ---------- ---------- 9 89 1 89
The number of roles are the sema even when the condition common='YES' is removed. SQL> select con_id, count(1) from cdb_roles where con_id in (1,9) group by con_id; CON_ID COUNT(1) ---------- ---------- 1 89 9 89 Ref.: https://docs.oracle.com/en/database/oracle/oracle-database/19/multi/overview-of-the-multitenant-architecture.html#GUID-3BB161DA-9CC0-4D61-A2C1-5D3662E0DECF https://docs.oracle.com/en/database/oracle/oracle-database/19/multi/overview-of-the-multitenant-architecture.html#GUID-16473474-7F47-4E40-A592-01836E7D911C
I think E is right because documentation says "common user is a database user that has the same identity in the root and in every existing and future PDB within this container." It's possible that the tests done in the lab are unreliable
ABD correct
SQL> select count(*) from dba_users where common='YES'; COUNT(*) ---------- 36 SQL> alter session set container=CDB$ROOT; Session altered. SQL> select count(*) from dba_users where common='YES'; COUNT(*) ---------- 37 SQL> select count(*) from dba_roles; COUNT(*) ---------- 89 SQL> alter session set container=PDB1; Session altered. SQL> select count(*) from dba_roles; COUNT(*) ---------- 89 Seems like ABD
agree with ABD . tested
from freshly created PDB SQL> select count(*) from cdb_roles group by con_id; COUNT(*) ---------- 66 66 SQL> select count(*) from cdb_users where common='YES' group by con_id; COUNT(*) ---------- 25 24
ABE, D is wrong because it has the same comun roles dont roles.
ABD correct
ABE correct D It has the same number of roles as CDB1. > "not common roles?"
ABD correct. See MSShaikh re GSMROOTUSER SYS@CDB1:CDB1> select con_id, count(1) from cdb_users where con_id in (1,5,11) and common='YES' group by con_id; CON_ID COUNT(1) ------ ----------- 1 26 11 25 5 25 3 rows selected. SYS@CDB1:CDB1> select con_id, count(1) from cdb_roles where con_id in (1,5,11) and common='YES' group by con_id; CON_ID COUNT(1) ------ ----------- 1 71 11 71 5 71
I tested and correct are ABE
I think AEF
RinD is right. I missed the keyword "roles". I thought it was "user".