Which two are true about changing the LOCAL_UNDO_ENABLED property to false in a CDB? (Choose two.)
Which two are true about changing the LOCAL_UNDO_ENABLED property to false in a CDB? (Choose two.)
Changing the LOCAL_UNDO_ENABLED property to false in a CDB means that only a common user with the required privileges can create an undo tablespace in the CDB root. This change results in a shared undo mode, where the undo tablespace is managed at the CDB root level instead of locally within each PDB. Consequently, for the new undo mode to take effect, each existing PDB needs to be reopened after the change.
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
C is also wrong for a single instance too because after you change from true to false, the existing PDB's undo tablespace will still be there. They are not deleted automatically. They are not going to be used, but they are still there.
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.
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
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
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
BF are correct Shared Undo Mode Shared undo mode means that there is one active undo tablespace for a single-instance CDB. For an Oracle RAC CDB, there is one active undo tablespace for each instance. 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. Undo tablespaces are visible in static data dictionary views and dynamic performance (V$) views when the current container is the CDB root. Undo tablespaces are visible only in dynamic performance views when the current container is a PDB, an application root, or an application PDB.
AF are correct.