ORA-65092 (nuevos errores de la 12c)

Tras las vacaciones vamos a ver una entrada rápida y sencilla para «dummies de la 12c»

Como sabemos, la versión 12c con las bases de datos multicontenedoras nos han traído una nueva diferenciación de usuarios de bases de datos, los usuarios globales y los usuarios locales.

A nivel de usuarios locales , apenas cambia nada, pero , cuando hablamos de usuarios y privilegios globales, podemos hacernos un poco de lío.

Supongamos tenemos un sistema con un CDB y multiples PDBs, tenemos un usuario que queremos esté en todas las bases de datos, este usuario pongamos que es el usuario PEPE, y al ser un usuaro global ( está en todos los pdbs) su nombre de esquema será C##PEPE

Si quisiéramos darle el privilegio CREATE TABLE solamente tendríamos que conectarnos al CDB$ROOT y ejecutar

SQL >GRANT CREATE TABLE TO C##PEPE;

Como veis, no hemos incluido la clausula CONTAINER=ALL por que en este tipo de sentencias es implícita.
Pero, ¿que ocurre si se lo queremos quitar?. Si ahora ejecutamos

SQL > REVOKE create table FROM C##PEPE;

recibiríamos el error

ORA-65092:system privilege granted with a different scope to C##PEPE

¿Como es posible?

Desafortunadamente vamos a tener que ir acostumbrándonos a este tipo de cosas con la gestion de los usuarios globales, la causa del error es que, al contrario de lo que ocurre cuando das un permiso a un usuario global ( donde la cáusula CONTAINER=ALL es implicita), cuando se los quitas no lo es, por lo que, a no ser que la especifiques manualmente recibiremos el error visto anteriormente.

Para revocar el privilegio solamente habría que hacer:

SQL > REVOKE create table FROM C##PEPE CONTAINER=ALL;

Mas información como siempre en:
Documentación de errores de ORACLE

Asignar un EM Express para un PDB específico

Vamos a seguir viendo pequeñas entradas sencillas sobre aspectos básicos de las PDB y las 12c . En este caso veremos como habilitar el EMexprss para un PDB específico.

En la entrada Donde está la consola en la 12c? vimos que en la version 12c había desaparecido el EM console tal y como lo conocíamos, habiendo sido substituido por una version mucho mas ligera integrada en la propia base de datos y que funciona mediante XMLdb.

Hasta el momento, teníamos acceso a este EMXpress , hemos visto como Dar permisos solo lectura a un usuario del EM express, pero estábamos dando acceso a todo el CDB , algo que seguramente no queramos hacer.

Como habilitamos el acceso a un único PDB

La respuesta es tremendamente sencilla, solamente hay que logarse a este pDB y asignarle un puerto libre a el EM express.
Veamos la secuencia de comandos:



SQL> SHOW CON_NAME
CON_NAME 
------------------------------
CDB$ROOT

SQL> ALTER SESSION SET container = test1;

Session alterado.


SQL> select dbms_xdb_config.gethttpsport () from dual;

DBMS_XDB_CONFIG.GETHTTPSPORT()
------------------------------
                             0

SQL> exec dbms_xdb_config.Sethttpsport (5501);
Procedimiento PL/SQL terminado correctamente.
SQL> 

Si ejecutamos el comando DBMS_XDB_CONFIG.GETHTTPSPORT dentro de un PDB veremos que no aparece ningún puerto configurado, esto es por que por defecto el EM solamente está configurado en el CBD principal. Como vemos en los comandos, simplemente asignando un puerto con dbms_xdb_config.Sethttpsport obtenemos en el puerto elegido la consola del EM Express dedicada unidamente a este PDB

A pesar de que nos hemos logrado con SYS, que es un usuario global del CDB, en el puerto 5501 solamente podemos acceder al PDB TEST1

ORA-39866 haciendo flashback con CDB/PDB

Hoy vamos a seguir viendo pequeñas diferencias entre la 12c y las versiones anteriores.

El funcionamiento del FlashbackDatabase es similar al que tiene la base de datos tradicional(no-cdb) , aunque tenemos que tener en cuenta un punto importante.
No se puede llevar a cabo un flashback de todo un CDB si se ha llevado a cabo un point-in-time recovery de uno de sus PDBs.
El intentar llevar un CBD a un punto anterior a la recuperación de uno de sus PDBs darán el error

ORA-39866: Data files for Pluggable Database TEST1 must be offline 
to flashback across PDB point-in-time recovery

Si quisieses llevar a cabo el volver el CBD después de haber restaurado un PDB a un punto tendríamos que :

  • Llevar a cabo un backup de todo
  • Parar el PDB
  • Dejar offline todos los ficheros del PDB
  • Hacer flashback del CDB
  • Restaurar el PDB al punto en el que estaba antes del flashback del PDB

Como veis, un cambio muy pequeño, pero que es conveniente conocer para no tener quebraderos de cabeza

Parámetros de inicio en los PDB

Hoy vamos a ver una entrada muy breve sobre los parámetros de inicio en la nueva versión 12c

Los PDBS no tienen un fichero de inicialización propio, comparten el spfile único del CDB pero algunos de los parámetros de este spfile son modificables a nivel de PDB
La manera de ver cuales son es mediante la consulta

select name from v$system_parameter where ispdb_modifiable=‘TRUE';

Cada uno de estos (185) son heredados del CDB, y pueden ser modificados mediante .
Si el scoops es SPFILE o BOTH viajarán con la PDB cuando se haga una operación de plug/unplug

Arranque y paradas de los PDB

Hoy vamos a ver una entrada de iniciación a las bases de datos 12c

Veremos las diferencias y similitudes entre no-cdb y doc

Si no forma parte de un RAC, la mecánica de un DBC es la misma que tenemos en una base de datos normal.
La vista en la que se ve el estado de los PDB es la v$PDBS

SQL> select con_id,DBID,NAME,OPEN_MODE from v$pdbs;
   CON_ID       DBID NAME                           OPEN_MODE 
---------- ---------- ------------------------------ ----------
         2 3975244989 PDB$SEED                       READ ONLY 
         3 2001395940 TEST1                          READ WRITE
         4  810296607 TEST2                          MOUNTED  

Estados del CBD

NOMOUNT: Cuando la CBD está en estado nomount los PDB no tienen status, si preguntamos por ellos no tendremos información

SQL> select con_id,DBID,NAME,OPEN_MODE from v$pdbs;
no rows selected

MOUNT:Cuando la CBD está en estado mount los controlfiles de el CDB y PDB ya cuentan con información por lo que los dos están en estado Mount .

  CON_ID	 DBID NAME			     OPEN_MODE

---------- ---------- ------------------------------ ----------
	 2 3975244989 PDB$SEED		             MOUNTED
	 3 2001395940 TEST1			     MOUNTED
	 4  810296607 TEST2			     MOUNTED

OPEN: Con la base de datos abierta la base de datos SEED estará en modo REEAD ONLY, el resto estará en alguno de los estados de los PDB

    CON_ID       DBID NAME                           OPEN_MODE 
    -------- ---------- ------------------------------ ----------
         2 3975244989 PDB$SEED                       READ ONLY 
         3 2001395940 TEST1                          READ WRITE
         4  810296607 TEST2                          MOUNTED  

Estados del PDB

Los PDB se administran de manera similar a la base de datos, algunos ejemplos de nuestro caso serían

ALTER PLUGGABLE DATABASE TEST2 OPEN ;  (La abre en modo read write)
ALTER PLUGGABLE DATABASE TEST2,TEST1 OPEN READ ONLY;
ALTER PLUGGABLE DATABASE ALL OPEN ;
ALTER PLUGGABLE DATABASE ALL EXCEPT test2 OPEN ;

Si el contenedor (CDB) es un PHYSYCAL STANDBY entonces el modo open por defecto la deja en modo read only.
Los modos en los que pueden estar los CDB son:

  • OPEN READ WRITE: como el nombre indica abierta lectura escritura (puedes generar redos)
  • OPEN READ ONLY: como el nombre indica abierta lectura escritura
  • OPEN MIGRATE: Este modo permite ejecutar un upgrade del PDB , si desde el root hacer un ALTER DATABASE OPEN UPGRADE el PDB se pone así
  • MOUNTED: Es como una base de datos normal en modo MOUNT , no permite hacer cambios de los objetos y solo es accesible a los administradores
    La parada es igual que el arranque, en este modo de parada tiene mas sentido el de la cláusula EXCEPT

    ALTER PLUGGABLE DATABASE TEST2 CLOSE ;  (La abre en modo read write)
    ALTER PLUGGABLE DATABASE TEST2,TEST1 CLOSE ABORT;
    ALTER PLUGGABLE DATABASE ALL CLOSE ;
    ALTER PLUGGABLE DATABASE ALL EXCEPT test2 CLOSE ;
    

NOTA: Cuando estas conectado a una pluggable Database el comando SHUTDOWN IMMEDIATE, es el equivalente a si ejecutaras ALTER PLUGGABLE DATABASE CLOSE;