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

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

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!

Uso del gestor de recursos en un CBD y PDB

Con la llegada de la 12c se han introducido mejoraras en el manejo de los gestores de recursos, de manera que el Resource Manager puede ser usado a dos niveles:
• CDB: Gestiona los recursos entre los distintos PDB
• PDB: Gestiona los recursos de manera tradicional

Gestión de los recursos en el CDB: Administrando recursos entre los PDBS

Algo que puede parecer evidente pero que debemos de decir, es que esta gestión se lleva a cabo en el CBD$ROOT, No se puede poner recursos al CDB$ROOT, igualmente no aparece en el computo de los shares
El Resource Manager lleva a cabo esta tarea mediante dos conceptos, shares y límites

  • Shares
    Los shares es la manera que tiene de repartir los recursos, a más shares, mas recursos dispone el PDB
    El porcentaje que asigna cada share se obtiene dividiendo el 100% de los recursos entre el numero de shares y multiplicándolo.

  • Limites
    EL otro parámetro que puedes indicar es el límite de utilización sobre el global, este límite puedes aplicarlo solamente a:

    • CPU
    • Cantidad de ejecuciones paralelas en el servidor

[table caption=»Planes de recursos» width=500]
Contenedor,shares,utilization limit, PARALLEL SERVER LIMIT
Default, 1 ,100%, 100%
PDB1 ,4 ,50% , 100%
PDB2 ,1 ,100% ,50%
[/table]

¿Qué significa un valor de 50% en PARALLEL SERVER LIMIT?

El PARALLEL SERVER LIMIT indica un porcentaje, este porcentaje es sobre el valor de inicialización de la base de datos de PARALLEL_SERVERS_TARGET, así pues, si tenemos un valor de 200 en PARALLEL_SERVER_TARGETS tendremos que el PARALLEL_SERVER_LIMITS será de 0.50*200=100 procesos paralelos.

No todos los PDBs tienen por que tener una política de asignación, aquellos que no la tengan irán a parar a el “Default allocation”.
Las directivas sobre los PDBs se han de crear en el momento de CREATE_CDB_PLAN_DIRECTIVE, y un PDB solamente puede ser afectado por una directiva.

¿Cuáles son los parámetros por defecto de la directiva “Default allocation”?

Si no especificas ninguna política específica para un PDB irá a la de por defecto con :
Shares=1
Utilization_limit=100
Parallel_srever_limit=100

Pasos para crear/modificar un plan

Para modificarlos el paquete DMNS_RESOURCE_MANAGER tiene su propia directiva llamada UPDATE_CDB_DEFAULT_DIRECTIVE

Pasos para la creacion

Al igual que en las BBDD clásicas hay que:
1. Crear el pending area
2. Crear el plan
3. Crear directivas (DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN_DIRECTIVE)
4. Validar el pending area
5. Submit el pending area

Habilitar el plan

Al igual que en las versiones antiguas

ALTER SYSTEM SET RESOURCE_MANAGER_PLAN=’myplan;

Se puede deshabilitar el plan quitando la variable de inicialización

ALTER SYSTEM SET RESOURCE_MANAGER_PLAN=’’;

PDB: Administracion de recursos dentro de los PDB

La administracion de recursos dentro del PDB se lleva a cabo igual que se llevaba dentro de las bases de datos tradicionales, teniendo en cuenta:

  • Ha de ser un single level resource plan, ya no puede ser multilevel
  • Tienes solamente 8 grupos de consumidores ( en el no-cdb son 32)
  • No puedes tener subplans dentro del plan ( en el no-dbs se podia)

Hay que tener en cuenta que hay dos parámetros que cambian de nombre:
MAX_UTILIZATION_LIMIT pasa a ser UTILIZATION_LIMIT
PARALLEL_TARGET_PERCENTAGE pasa a ser PARALLEL_SERVER_LIMIT

Es importante que, para poder crear una politica de gestor de recursos dentro de un PDB,la política del CDB para los recursos que quieres administrar debe de debe de satisfacer :
CPU

  • La directiva debe de tener definido el valor de SHARES para ese PDB
  • La directiva debe de tener definido el valor de UTILIZATION_LIMIT a menos del 100%

PARALLEL EXECUTION

  • Las dos de arriba de CPU
  • La directiva debe de tener definido el valor de PARALLEL_SERVER_LIMIT a menos del 100%

Notas finales del resource manager

Se ha introducido un Nuevo grupo de consumidores llamado LOG_ONLY que sirve para usarlo en como switch group en los casos en los que merely want to log the runaway query but don’t want to change its consumer group or perform any other action
Puedes ver lo definido en las vistas
V$RSRC_PLAN
DBA_CDB_RSRC_PLANS

Otra de las cosas que ofrece el RESOURCE MANAGER es que ha añadido nuevas columnas en la vista V$SQL_MONITOR

  • RM_LAST_ACTION The most recent action taken by the Resource Manager, such as cancelling a SQL execution or killing a session
  • RM_LAST_ACTION_REASON The reason for the most recent action taken by theResource Manager on this SQL operation, such as SWITCH_CPU_TIME orSWITCH_ELAPSED_TIME
  • RM_LAST_ACTION_TIME The time of the most recent action taken by the Resource Manager on this SQL operation
  • RM_CONSUMER_GROUP The current consumer group for this SQL operation

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

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

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