Exam 1z0-083 topic 1 question 19 discussion

A is correct B is wrong, because PDBs must be reopened to recognize the central UNDO C is wrong because as the database is RAC and enabled with LOCAL UNDO, you need to assign specific Undo tablespace to each PDB on node-1 & node-2 by executing below commands. On node-1: alter system set undo_tablespace=UNDOTBS1 container=current sid='DBCDB1' scope=spfile; >>>> sid=First Instance On Node-2 alter system set undo_tablespace=UNDOTBS2 container=current sid='DBCDB2' scope=spfile; >>>> sid=Second Instance D is wrong becuase as long as LOCAL UNDO used you cant create UNDO in PDB E is wrong F is correct

A is correct. In shared UNDO mode, UNDO can exist in the CDB only. B is correct. The change is automatic and comes into effect as soon as you restart the CDB instance (required). C is wrong. More than one UNDO tablespace can exist in the CDB, but only one can be the actice UNDO tablespace. D is wrong. Tested this. Switched to Shared Undo, connected to PDB as SYS, created an undo tablespace (create statement succeeded). Query dba_tablespaces and dba_data_files from CDB and the tablespace nor the datafile exists. Conslusion - create undo tablespace command ignored. E is wrong. PDB UNDO tablespaces should be dropped after the change. F is wrong. The CDB has to be restarted after the change so no need to reopen each PDB.

A, F https://docs.oracle.com/en/database/oracle/oracle-database/19/multi/administering-a-cdb-with-sql-plus.html#GUID-24EA5811-94F0-4EEC-864F-23AEF48F2D51

See ama's comment

A, F. "When a CDB is in shared undo mode, the following applies: Only a common user who has the appropriate privileges and whose current container is the CDB root can create an undo tablespace. When the current container is not the CDB root, an attempt to create an undo tablespace fails and returns an error. When you change the undo mode of a CDB, the new undo mode applies to an individual container the first time the container is opened after the change. " https://docs.oracle.com/en/database/oracle/oracle-database/19/multi/administering-a-cdb-with-sql-plus.html#GUID-24EA5811-94F0-4EEC-864F-23AEF48F2D51 ""

According to this: https://docs.oracle.com/en/database/oracle/oracle-database/19/multi/administering-a-cdb-with-sql-plus.html#GUID-D54AAD88-03DA-4E22-991F-8C15306823A5

AF F - PDB has to be reopened as part of startup upgrade in CDB ALTER DATABASE LOCAL UNDO OFF - ORA-65192: database must be in UPGRADE mode for this operation SQL> shutdown immediate; ..... SQL> startup upgrade; ORACLE instance started. Total System Global Area 1124073328 bytes Fixed Size 9133936 bytes Variable Size 738197504 bytes Database Buffers 369098752 bytes Redo Buffers 7643136 bytes Database mounted. Database opened. SQL> ALTER DATABASE LOCAL UNDO OFF; Database altered. SQL> show pdbs; CON_ID CON_NAME OPEN MODE RESTRICTED ---------- ------------------------------ ---------- ---------- 2 PDB$SEED MIGRATE YES 3 ORCLPDB MOUNTED SQL>

C. False. Only one active, but many created. D. False. Command to create undo tablespaces are ignored with no error. E. False. Drop is recommended after. F. False. The CDB is restarted as part of the procedure, not individual PDBs.

A and F appear to be correct https://docs.oracle.com/en/database/oracle/oracle-database/19/multi/administering-a-cdb-with-sql-plus.html#GUID-D54AAD88-03DA-4E22-991F-8C15306823A5

i want AB C : false - When in shared undo mode, the CDB ignores any local undo tablespaces that were created when it was in local undo mode. Oracle recommends that you delete the unused local undo tablespaces. (only=x / can exist more) D : false - not (in the PDBs) / -> in CDB$ROOT E : false - reference C / not must F : false - The CDB should be opened, not the PDB. But from PDB's point of view, F might be right. In terms of (in a CDB), I think A and B are better

AB I think

B is wrong because you need to restart CDB: https://docs.oracle.com/en/database/oracle/oracle-database/19/multi/administering-a-cdb-with-sql-plus.html#GUID-D54AAD88-03DA-4E22-991F-8C15306823A5

I think is AF A - Only a common user who has the appropriate privileges and whose current container is the CDB root can create an undo tablespace. F - When you change the undo mode of a CDB, the new undo mode applies to an individual container the first time the container is opened after the change. C is incorrect - When it is in shared undo mode, the CDB ignores any local undo tablespaces that were created when it was in local undo mode. Oracle recommends that you delete these local undo tablespaces. So Oracle RECOMMENDS, is not mandatory. https://docs.oracle.com/en/database/oracle/oracle-database/12.2/admin/administering-a-cdb-with-sql-plus.html#GUID-1AAB032F-D13A-4E06-A062-59E0487C2FC5

AF = correct

A & F are the correct answers

I think it's BC. You can set a CDB in local UNDO mode either at CDB creation or by altering the CDB property. When the database property LOCAL_UNDO_ENABLE is FALSE, which is the default, there is only one UNDO tablespace that is created in the CDB root, and that is shared by all containers. When LOCAL_UNDO_ENABLE is TRUE, every container in the CDB uses local undo and each PDB must have its own local UNDO tablespace. To maintain ease of management and provisioning, UNDO tablespace creation happens automatically and does not require any action from the user. When a PDB is opened and an UNDO tablespace is not available, its automatically created.

A, C looks correct as per When a CDB is in shared undo mode, the following applies: Only a common user who has the appropriate privileges and whose current container is the CDB root can create an undo tablespace. When the current container is not the CDB root, an attempt to create an undo tablespace fails and returns an error. From https://docs.oracle.com/en/database/oracle/oracle-database/12.2/admin/administering-a-cdb-with-sql-plus.html#GUID-8F8B2FF8-7FA7-40CD-8AA5-ACABCD3964D8