En el artículo de hoy vamos a resolver el error «CDB is using local undo, but no undo tablespace found in the PDB» que puede surgir durante una migración de no-multitenant a multitenant.
En un entorno multitenant, hay un contenedor de base de datos (CDB) que contiene varias bases de datos pluggable (PDB).
Para migrar una base de datos single tenant a una base de datos Multitenant tendremos que crear una nueva CDB, luego una nueva PDB y, finalmente, procededer a la migración de los datos de la single tenant a la PDB.
Es durante este proceso cuando puede aparecer el error «CDB está usando undo local, pero no se encuentra tablespace de undo en PDB», el que tenemos en inglés en el título.
¿Qué es el UNDO?
En primer lugar, es importante entender el concepto de undo. En Oracle, el undo se utiliza para mantener una versión anterior de los datos modificados en caso de que sea necesario deshacer una transacción.
En el caso de una base de datos Multitenant, cada PDB tiene su propio tablespace de undo.
¿Por qué ocurre este error?
Normalmente, este error ocurrirá después de ejecutar el script noncdb_to_pdb.sql.
El problema viene del hecho de que en nuestra DB de origen, que no es una CDB, tiene el parámetro cluster_database = false.
Cuando convertimos este tipo de instancia a una PDB alojada en una CDB RAC se da el problema de que tenemos 2 instancias y, por tanto, 2 PDBs, pero un solo tablespace de UNDO.
Podemos comprobar el problema fácilmente echando un vistazo a la vista de pdb_plug_in_violations:
SQL> select status, message from pdb_plug_in_violations;
STATUS MESSAGE
--------- --------------------------------------------------------------------------------------------
PENDING CDB is using local undo, but no undo tablespace found in the PDB.
1 rows selected.
Diagnosticar el problema
Lo primero que vamos a hacer es confirmar a nivel de CDB que el parámetro local_undo_enabled está a TRUE.
SQL> show con_name
CON_NAME
------------
CDB$ROOT
SQL> select property_name, property_value from database_properties where property_name = 'LOCAL_UNDO_ENABLED';
PROPERTY_NAME PROPERTY_VALUE
------------------------------ --------------------
LOCAL_UNDO_ENABLED TRUE
Como está activo, podemos pasar al siguiente punto. Como estamos en un entorno RAC de 2 nodos, en cada PDB debería haber 2 tablespace de UNDO:
SQL> select a.con_id, b.name, tablespace_name from cdb_tablespaces a, v$pdbs b where a.con_id=b.con_id and contents = 'UNDO' order by con_id;
CON_ID NAME TABLESPACE_NAME
---------- ------------------ --------------
3 TESTPDB1 UNDOTBS1
3 TESTPDB1 UNDOTBS2
4 TESTPDB2 UNDOTBS1
Cómo véis arriba se cumple para la TESTPDB1, pero no para la TESTPDB2 que solo tiene un tablespace de UNDO.
Podríamos hacer una comprobación adicional entrando a la PDB (alter session set container = TESTPDB2) y listando los tablespaces.
Otra comprobación válida sería listar los datafiles destinados al UNDO, donde solo deberíamos ver uno en este caso.
Solución
Tras hacer todas nuestras comprobaciones ya deberías saber por donde van los tiros… Necesitamos un tablespace de UNDO para nuestra PDB ¿no? Pues vamos a crearlo:
SQL> alter session set container=TESTPDB2;
Session altered.
SQL> create undo tablespace UNDOTBS2 datafile '+DATA_RAC1' size 1G;
Tablespace created.
Si comprobamos los datafiles destinados al UNDO ahora, vemos uno extra:
SQL> select file_name from dba_data_files where tablespace_name like '%UNDO%';
FILE_NAME
---------------------------------------------------
+DATA_RAC1/TEST_CDB/7543F569C85A0827E0538E05680AC21A/DATAFILE/undotbs1.536.1159283017
+DATA_RAC1/TEST_CDB/7543F569C85A0827E0538E05680AC21A/DATAFILE/undotbs2.550.1159291013
Asignamos el tablespace a a la segunda instancia, es decir, la que NO estamos logados:
SQL> alter system set undo_tablespace=UNDOTBS2 container=current sid='TEST_CDB2' scope=both;
System altered.
Reinciamos la PDB:
SQL> alter pluggable database TESTPDB2 close instances=all;
Pluggable database altered.
SQL> alter pluggable database TESTPDB2 open instances=all;
Pluggable database altered.
Y ahora sí, deberíamos ver que tenemos el tablespace asignado en ambas instancias:
SQL> select inst_id, name, value from gv$parameter where upper(name)='UNDO_TABLESPACE';
INST_ID NAME VALUE
---------- ------------------------- --------------
1 undo_tablespace UNDOTBS1
2 undo_tablespace UNDOTBS2
Y además, que el estado de la pdb_plug_in_violations ha cambiado a RESOLVED (o resuelto, si lo tenéis en español):
SQL> select status, message from pdb_plug_in_violations;
STATUS MESSAGE
--------- --------------------------------------------------------------------------------------------
RESOLVED CDB is using local undo, but no undo tablespace found in the PDB.
1 rows selected.
Resumen
En resumen, migrar de una base de datos single-tenant a una base de datos Multitenant es un proceso complejo que puede llevar a errores como «CDB está usando undo local, pero no se encuentra tablespace de undo en PDB».
Sin embargo, siguiendo los pasos mencionados anteriormente para crear un nuevo tablespace de undo en tu PDB y configurarlo como el tablespace de undo por defecto, solucionando este error con éxito.
Únete a la lista de emails para no perderte nada
No tengo ningún producto, publicidad, ni nada que venderte. De hecho, aún no tengo nada que hacer con estos emails. Pero si te interesa estar en contacto o no perderte las próximas actualizaciones en el futuro… Ya sabes 😉
¿Quieres trabajar con nosotros?
Ya sea que necesites mejorar el rendimiento de consultas existentes, planificar y ejecutar migraciones de datos críticas, diseñar bases de datos desde cero o mantener un entorno de base de datos estable, estamos aquí para ayudarte.
Trabajamos con una amplia variedad de sistemas de gestión de bases de datos (DBMS) y estamos comprometidos en proporcionar soluciones adaptadas a tus necesidades específicas. Puedes consultar nuestra lista completa de servicios aquí.
Confía en nosotros para optimizar tus bases de datos y liberar tiempo y recursos para que puedas concentrarte en lo que realmente importa: hacer crecer tu negocio.
¡Contáctanos hoy mismo y descubre cómo podemos ayudarte a lograr un rendimiento óptimo en tu entorno de bases de datos!
Deja una respuesta