Archivo por meses: agosto 2017

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!

Uso del gestor de recursos en un CBD y PDB

Posted on por
Responder

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

Posted on por
Responder

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

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

CRS-6706: Oracle Clusterware Release patch level (‘xx’) does not match Software patch level (‘0’). Oracle Clusterware cannot be started.

Posted on por
Responder

Hoy vamos a ver la resolución de un problema que puede darnos al aplicar un PSU sobre el grid infraestructure de un alone server. Tras aplicar correctamente un PSU sobre el Grid y una Base de datos al intentar arrancar de nuevo el clusterware recibimos el siguiente error

CRS-6706: Oracle Clusterware Release patch level (‘nnn’) does not match Software patch level (‘mmm’) (Doc ID 1639285.1)

bash-4.2# /etc/ohasd start
Starting ohasd:
CRS-6706: Oracle Clusterware Release patch level ('1591286773') does not match Software patch level ('0'). Oracle Clusterware cannot be started.
CRS-4000: Command Start failed, or completed with errors.

La primera impresión es la de extrañeza, puesto que la aplicación de este mismo parche siguiendo el mismo proceso había sido satisfactoria en varios servidores.
Tras revisar los logs del Opatch y no encontrar ningún indicio de error, rebuscamos en soporte e y los grupos de ayuda en busca de alguna opción antes de tener que hacer marcha atrás en la aplicación del parche , y, «afortunadamente», encontramos una nota que indica que, este tipo de error puede ser normal en servidores alone en los que no se lleva a cabo el paso ‘rootcrs.pl -postpatch’

Así pues, la solución es tan sencilla como ejecuta los siguientes comandos como root comandos 

$GRID_HOME/crs/install/roothas.sh -unlock
$GRID_HOME/crs/install/roothas.sh -patch

bash-4.2# ./crs/install/roothas.sh -unlock
Using configuration parameter file: /opt/app/oracle/product/12.1.0/grid/crs/install/crsconfig_params
2017/08/07 16:16:13 CLSRSC-347: Successfully unlock /opt/app/oracle/product/12.1.0/grid

bash-4.2# .//crs/install/roothas.sh -patch
Using configuration parameter file: /opt/app/oracle/product/12.1.0/grid/crs/install/crsconfig_params

Esto solventa el problema y levanta automáticamente el ohas tras lo que, esperando un ratillo ( ya sabemos que el ohas no es lo mas rápido del mundo) tendremos nuesrta infraestructura levantada correctamente 

bash-4.2# crsctl stat res -t
-----------------------------------------------------------
Name           Target  State      erver  State details
-----------------------------------------------------------
Local Resources
-----------------------------------------------------------
ora.DATA.dg
               ONLINE  ONLINE       test    STABLE
ora.LISTENER.lsnr
               ONLINE  ONLINE       test    STABLE
ora.REDO.dg
               ONLINE  ONLINE       test     STABLE
ora.asm
               ONLINE  ONLINE       test    Started,STABLE
ora.ons
               OFFLINE OFFLINE      test    STABLE
-----------------------------------------------------------
Cluster Resources
-----------------------------------------------------------
ora.cssd
      1        ONLINE  ONLINE       test     STABLE
ora.diskmon
      1        OFFLINE OFFLINE               STABLE
ora.evmd
      1        ONLINE  ONLINE       test     STABLE
ora.bbddtest.db
      1        ONLINE  ONLINE       test     Open,STABLE
-----------------------------------------------------------
bash-4.2#

Mas información como siempre en soporte de Oracle en las notas

  • CRS-1153: There was an error setting Oracle Clusterware to rolling patch mode. (Doc ID 1943498.1)
  • CRS-6706: Oracle Clusterware Release patch level (‘nnn’) does not match Software patch level (‘mmm’) (Doc ID 1639285.1)