Archivo de la categoría: CDB/PDB

renombrando un PDB

Posted on por
Responder

Hoy vamos a ver una entrada sencilla para un problema bastante comun.
Supongamos que queremos renombrar un PDB
Tenemus :

  • Nombre origina: OLDNAME
  • Nombre nuevo : NEWNAME

Los pasos a segir son muy sencillos

alter session set container=OLDNAME;

-- reiniciamos en modo restrict
shutdown immediate;
startup open restrict;
--cambiamos nombre
alter pluggable database OLDNAME rename global_name to NEWNAME;

--comprobamos
show con_name;
show pdbs;

--reiniciamos normal
shutdown immediate;
startup;

--vemos el resultado
select name,open_mode from v$pdbs;

Com podeis ver, altamente sencillo

Checklist de informacion sobre usuarios en 12c con CDB/PDB

Posted on por
Responder

En esta entrada seguiremos con las cheklist de cosas a tener en cuenta en la nueva version 12c, en este caso trataremos la informacion sobre usuarios

Tenemos dos tipos de usuario.

  • Commonuser: Tendrá la misma identidad en el root y en los PDB donde se le den permisos
  • Local user: Solamente exisistirá en el PDB donde se declare.

Common users

  • Para crearlo has de estar logado al CDB$ROOT
  • El nombre debe de comenzar por c## o C## y contener solo caracteres ASCII o EBCDIC
  • Para indicar explícitamente que el usuario va a estar en todos los contenedores hay que poner la cápsula CONTAINER=ALL
  • Si te encuentras en el root y no indicas la cláusula CONTAINER se presupone que es ALL
  • Los usuarios common users no pueden tener objetos creados en sus esquemas
  • Para podrán navegar entre los contenedores en los que tengan los permisos SET CONTAINER y CREATE SESSION
  • Para poder crear mas usuarios comunes debe de tener los privilegios SET CONTAINER y CREATE USER
  • Un usuario comun puede hacer:

    Grant privileges a common users o common roles

  • Run anALTER DATABASE statement que especifiquen clausulas de recuperacion que afectan a todo el CDB

    Usuarios locales

  • No puedes tener usuarios locales llamados SYS o SYSTEM
  • No puedes definir usuarios locales el el ROOT$CDB
  • Los local users pueden administrar un PDB, incluido arrancarlo y/o abrirlo
  • Están limitados a su PDB, NO pueden hacer SET CONTAINER
  • No pueden comenzar por c## o C##
  • La cláusula CONTAINER=CURRENT debe de especificarse en su creación
  • Para poder crear mas usuarios locales
  • Para crearlo has de estar conectado al PDB donde quieres crearlo
  • Se puede dar privilegios con los comunes y que le den privilegios comunes
  • En la sintaxis SQL de estos usuarios la cláusula CONTAINER indica en que containers aplica el comando

    Privilegios globales y locales

  • Lo privilegios globales una deben de ser otorgados a PUBLIC
  • Un privilegio local solo puede usarse en el container donde ha sido otorgado, incluso si ese container es ROOT
  • Un usuario local solo puede tener privilegios locales, pero uno común puede tener globales y locales.
  • Se dan con GRANT y REVOKE, solo que hay que añadir la clausula del CONTAINER
  • Para poder dar SYSTEM PRIVILEGES has de ter el privilegio SET CONTAINER

    Roles locales y globales

  • Los roles globales se crean en root y existen en los containers presentes y futuros.
  • Los usuarios globales pueden crear roles globales y darlos a otros users globales o locales
  • Los usuarios locales no pueden crear roles globales pero si que pueden darlos a usuarios globales o locales
  • Los usuarios locales puedan grantcommon roles a usuarios globales o locales
  • Al igual que los nombres de usuarios, los nombres de roles globales han de empezar por C##o c##
  • Si creas un role global desde un container has de poner la cláusula CONTAINER=ALL
  • Si otorgas un role global a un user global sin añadir la cláusula CONTAINER se aplica solo al container en el que estás, aunque este sea el CDBROOT

    • Checklist de informacion sobre tablespaces en 12c con CDB/PDB

    Posted on por
    Responder

    Vamos a ver una serie de entradas rápidas a modo de resumen sobre la version 12c

    Administrar tablespaces en CDB/PDB

    En general los tablespaces se gestionan de la misma manera que en las non-cdb-database, sin embargo hay algunas consideraciones para los tablespaces en los CBD

    • Un tablespace permanente solamente puede estar asociado a un contenedor (PDB)
    • Los tablespaces en un PDB se crean solo desde ese pdb
    • Cada PDB deberá de tener su propio default tablespace
    • Si un tablespace es creado en un contenedor (PDB), el tablespace se asocia directamente a este contenedor
    • Un CDB (o cada instancia de un CDB en RAC ) solamente puede tener activo un Undotablespace
    • Solamente hay un tablespace temporal (o un grupo temporal) para un CDB, el root usa este temporal, los PDB pueden usar este o crearse su propio temporarytablespace. Cuando un PDB se desconecta del CDB sus temporales también se desconectan con el .
    • Cuando un usuario entre a un PDB y su tablespace por defecto no esté asociado a este PDB automáticamente se le asociará al usuario el tablespace por defecto del PDB
    • El UNDO tablespace es común, al contrario que ocurre con el temporal un PDB no puede tener un tablespace UNDO especifico para el.
    • Todos los PDB tienen su propio tablespace SYSTEM y SYSAUX, pero este tablespaceactua como un subconjunto del del ROOT$CDB,en estos tablespaces solamente se guardará información relativa a estos solo guardan los metadatos de usuario, los metadatos de Oracle están guardados en el el CDB.

    Tablespace por defecto

    • Cada PDB debe de tener un tablespace por defecto.
    • Si ejecutas un ALTER DATABASE DEFAULT TABLESPACE XX; en el CDB$ROOT lo que estás cambiando es el del CDB$ROOT, para cambiar el default tablespace en uno de los PDBs has d ejecutar
      ALTER PLUGGABLE DATABASE DEFAULT TABLESPACE XX;

    Administrar tablespaces temporales

    Como indicábamos arriba,solamente hay un tablespace temporal (o un grupo temporal) para un CDB, el root usa este temporal, los PDB pueden usar este o crearse su propio temporarytablespace. Cuando un PDB se desconecta del CDB sus temporales también se desconectan con el.

    ORA-65092 (nuevos errores de la 12c)

    Posted on por
    Responder

    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

    ORA-16179: incremental changes to “log_archive_dest_1” not allowed with SPFILE

    Posted on por
    Responder

    Vamos a ver una pequeña entrada rápida muy muy de dummie sobre un error ORA-XX

    Intentando modificar el parámetro de los archivers de mi CDB de pruebas me encuentro con que, al ejecutar 

    alter system set LOG_ARCHIVE_DEST_1 ='LOCATION   =/u01/app/oracle/oradata/cdbtest/archivelog/' scope=both sid='*'

    Recibimo el error 

    ERROR at line 1:
ORA-32017: failure in updating SPFILE
ORA-16179: incremental changes to "log_archive_dest_1" not allowed with SPFILE

    Si miramos la configuración del archivado

    SQL>  archive log list
Database log mode	       Archive Mode
Automatic archival	       Enabled
Archive destination	       /u01/app/oracle/product/12.1.0/dbhome_1/dbs/arch
Oldest online log sequence     38
Next log sequence to archive   40
Current log sequence	       40

    Después de muchas muchas vueltas, he visto lo sencilla que era la solución .
    La cláusula LOCATION de og_archive_dest_1 no puede tener espacios.
    Así pues

    ‘LOCATION = /path/’; -> ERROR
    ‘LOCATION=/path/’; -> CORRECTO

    Como veis, otra de las soluciones sencillas a problemas que pueden traernos de cabeza!