Archivo por meses: noviembre 2017

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

    • Problemas con optachauto y resolucion de nombres (error code 238)

    Posted on por
    Responder

    Hoy vamos a ver una entrada rápida

    Recientemente me he encontrado con el error code 238 intentando llevar a cabo la aplicación de un parche con el optachauto.

    Al intentar llevar a cabo el parcheado me devolvía el siguiente error:

    root:$GRID_HOME/OPatch/opatchauto apply $PARCHES/26610308 
OPatchauto session is initiated at Sun Nov 18 15:56:14 2017 

Patch version not found


OPatchauto session completed atSun Nov 18 15:56:20 2017 
Time taken to complete the session 0 minute, 7 seconds 

opatchauto bootstrapping failed with error code 238.

    La primera conclusion que debemos de sacar de esto. siempre hay que hacer el analize antes de la aplicacion, ya que de esa manera habríamos comprobado el error .

    Tras mucho buscar en la web de soporte y abrir un caso con Oracle, encontramos el problema.

    El fichero /etc/hosts de mi servidor tenia mas de dos entradas, supongamos que fuese algo similar a:

    
10.0.0.1  SERVER server server.dominio  server-vip.dominio

    Si desde el sistema operativo preguntábamos por cualquiera de las 4 entradas, el servidor funcionaba correctamente.

    Sin embargo, al cambiar esa linea por

    
10.0.0.1  server server.dominio
10.0.0.1  SERVER  SERVER.dominio 
10.0.0.1  serve-vip  server-vip.dominio

    Todo volvió a funcionar a la perfeccion.

    Un expediente X que nos sirve para recordar que no todo vale a la hora de solcitar las instalaciones a los equipos responsables de los sistemas operativos, las nuevas herramientas de gestion de los componentes de oracle (opatchauto,datapatch …) son muy potentes, pero no dejan de ser componentes externos a la base de datos que requieren de configuraciones correctas que, desgraciadamente no suelen estar tan documentadas como los prerrequisitos del GRID, RAC o Base de datos, por lo que siempre deberemos de velar por que los sistemas operativos donde se encuentran nuestros motores esten prefectametne configurados

    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.