Archivo de la categoría: dummie

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!

ROW_LIMITING Mejoras importantes en la visualización de datos en 12c

Posted on por
Responder

Las consultas que ordenan los datos y obtienen partes de ellos ordenados son llamadas TOP_N consultas. Al contrario que en otros motores de bases de datos, hasta el momento Oracle resolvia estas consultas mediante el ROWNUM y otras tecnicas similares
.
En la version 12c Oracle ya nos brinda la funcionalida de ROW_LIMITING, que viene a ser el uso de un offset y un principio y fin en estas consultas. La sintaxis para usarla en la cláusula SELECT es:

[ OFFSET offset { ROW | ROWS } ]
[ FETCH { FIRST | NEXT } [ { rowcount | percent PERCENT } ]
    { ROW | ROWS } { ONLY | WITH TIES } ]

Algunas consultas serín:

SELECT val  FROM   tabla1  ORDER BY campo 
   FETCH FIRST 5 ROWS;

SELECT val  FROM   tabla1  ORDER BY campo 
   FETCH FIRST 10 PERCENT ROWS ONLY;

SELECT val  FROM   tabla1  ORDER BY campo
    OFFSET 10 ROWS FETCH NEXT 5 ROWS ONLY;

Si lo quisiesemos con duplicados 

SELECT val  FROM   tabla1   ORDER BY campo DESC
  FETCH FIRST 5 ROWS WITH TIES;

Cosas a tener en cuenta

  • Si no especificamos offset este será cero
  • Igualmente, si ponemos un offset negativo sera cero también
  • Si ponemos un valor nulo en offset,rowcount o porcentaje, la consulta no devolver nada
  • Los valores de offset,rowcount o porcentaje son truncados en caso de no ser enteros
  • Si el porcentaje que indicas es mayor que el numero de filas que quedan devolverá todas
  • Las palabras ROW y ROWS son intercambiables

NOTA:Estas opciones no pueden usarse en clasulas FOR UPDATE , en secuencias CURRVAL/NEXTVAL o en cláusulas de fast refresh de vistas materializadas.

ms información como siempre en

Uso de RMAN con PDBs

Posted on por
Responder

Con la llegada de los plugable databases se nos abre un mar de dudas, especialmente en un campo tan delicado como el backup.
Hoy vamos a ver en una entrada muy por encima las opciones de backup que tenemos con la nueva funcionalidad de la 12c

Llevar a cabo backups en CDB/PDB

Igual que las bases de datos no cdv se pueden lanzar desde RMAN y/o Enterprise manager Cloud Control El backup del CDB es igual al de un “no-cdb”, de esta backup de rman podríamos recuperar tanto el CDB completo como alguno de los PDBs del backup

  • Backup completo del CDB: Conectando al cdb y BACKUP DATABASE
  • Backup del PDB root: BACKUP DATABASE ROOT
  • Backup de un PDB:
    • conectando al CDB y BACKUP PLUGGABLE DATABASE test1
    • conectando al CDB y BACKUP PLUGGABLE DATABASE test1,test2,test3
    • Conectando al PDB y ejecutando BACKUP DATABASE

Recuperación de CDB and PDB

A la hora de llevar a cabo una recuperación de la base de datos se puede hacer también el CBD completo, solamente el root o un PDB independiente.
Si en la cadena de conexión del RMAN te conectas al CBD recuperarás todo, si te conectas a un PDB específico será este PDB lo que recuperarás
NOTA:Aunque técnicamente es posible restaurar solamente el root, Oracle recomienda no hacerlo , y si has de restaurar el root restaurar también los PDBs de la base de datos.
Puedes restaurar también un PDB con 

RESTORE PLUGGABLE DATABASE

Mientras estas restaurando un PDB el resto de ellos puede dar servicio normalmente
Los comandos a la hora de restaurar datafiles específicos son como los de no-cbd, pero incluyendo el PLUGGABLE database (al tratarse de un PDB).