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

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

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)

Trucos para crear un dataguard standby

Si consultamos la documentación de Oracle la creación de un datagurard es algo facilísimo, pero a la hora de la verdad, siempre hay pequeños flecos de configuración antes de la creación que es lo que nos puede traer de cabeza, vamos a ver en esta entrada algunos puntos que mirar antes de empezar para que todo funcione.

Suponemos que :

  • EL SID de la base de datos va a ser cdbtest
  • A la base de datos primaria la llamaremos primary , su nombre único será cdbtest
  • A la base de datos standby la llamaremos standby ,su nombre único será cdbtest_sdby

Pasos a llevar a cabo en primary

Se gun la documentación de Oracle, debería de bastar con:

, pero siempre hay cosas que podemos ir haciendo para que todo vaya a la primera

Activar el standby file management

Mediante esta opción los cambios que llevemos a cabo en la primary database se llevaran a cabo en la standby

alter system set STANDBY_FILE_MANAGEMENT=AUTO ;

Crear grupos de standby redo logs

Estos grupos serán necesarios en standby, si los tenemos creados en primary ademas solucionaremos antes de que ocurran los problemas en caso de switchover.

La sintaxis es igual que la de la creación de un grupo normal añadiendo standby

alter database add standby logfile group 4  '/u01/app/oracle/oradata/cdbtest/standby_redo04.log' size 52428800;

Hay que crear un grupo de standby redo log file mas que los grupos de redo logs normales.

Configurar el tnsnames del servidor

Este es uno de los puntos importantes, el servidor debe de ser capaz de acceder por oraclenet al standby.
Dado que los dos SID van a ser iguales, aconsejamos el poner una entrada clara en el listener.ora, en nuestro caso los llamaremos exactamente igual que el DB_UNIQU_NAME que es CDBTEST_STDBY

CDBTEST_STANDBY =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = standby.pamplona.name)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = cdbtest)
    )
  )

Además de esta entrada, deberá de haber una entrada para el LOCAL_LISTENER,la teoría indica que esto ya debería de estar configurado, pero la realidad a veces es distinta, por lo que nos aseguraremos que la variable LOCAL_LISTENER de nuestra base de datos este correctamente configurada y tenga su entrada en el nsnames.ora .


LISTENER_CDBTEST =
  (ADDRESS = (PROTOCOL = TCP)(HOST = alone.pamplona.name)(PORT = 1521))

Configurar parametros en spfile

Antes de proseguir, es obligatorio el uso de spfile , la creación de la replica va a ser mediante RMAN, por lo que, en caso de usar file fallaría la creación del spfile en standby

Los parámetros que hemos de poner son:

DB_UNIQUE_NAME

Este parámetro no es obligatorio en el primary, pero es recomendable, por lo que lo pondremos

alter system set db_unique_name='cdbtest' scope=spfile sid='*';

LOG_ARCHIVE_CONFIG

LOG_ARCHIVE_CONFIG habilita o deshabita la recepcion/envio de los redo, pero lo que realmente nos interesa es que especifica para cada una de las bases de datos del Dataguard los nombres únicos de las mismas (DB_UNIQUE_NAME)

alter system LOG_ARCHIVE_CONFIG='DG_CONFIG=(cdbtest,cdbtest_stby)'

LOG_ARCHIVE_DEST_X

Otro de los valores que cambiaremos es la ubicación de los redo logs, aquí indicaremos donde va el primary y el standby, así como los casos.

ALTER SYSTEM SET LOG_ARCHIVE_DEST_1= 'LOCATION=/u01/app/oracle/oradata/cdbtest/archivelog
  VALID_FOR=(ALL_LOGFILES,ALL_ROLES)';
ALTER SYSTEM SET log_archive_dest_2='service=CDBTEST_STANDBY ASYNC NOAFFIRM delay=0 optional compression=disable max_failure=0 max_connections=1 reopen=300 net_timeout=30 DB_UNIQUE_NAME=cdbtest_sdby valid_for=(online_logfile,all_roles)' ;

Configuraciones en el servidor de Standby

Estas configuraciones son seguramente las que mas nos hagan fallar en el proceso, ya que en muchos documentos se dejan como algo que se asume ya está.
Las configuraciones son:

Configuraciones de tnsnames.ora

Este es posiblemente el fichero que vaya a marcar el éxito de nuestra acción a la primera, deberá de contar con las lineas:

  • LOCAL_LISTENER deberemos de tener una entrada distinta a la de producción que fijaremos en la BBDD standby
  • BBDD primaria debemos de tener una entrada que apunte a la BBDD primaria
  • BBDD standbydebemos de tener una entrada que apunte a la BBDD standby

LISTENER_CDBTEST_STANDBY =
(ADDRESS = (PROTOCOL = TCP)(HOST = standby.pamplona.name)(PORT = 1521))

CDBTEST_PRIMARY =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = alone.pamplona.name)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = cdbtest)
)
)

CDBTEST,CDBTEST_STANDBY =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = standby.pamplona.name)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SID = cdbtest)
)
)

IMPORTANTE:Si miramos con atención el código que hemos puesto, veremos como el truco es que en el nodo standby la conexión a cdbtest será a si mismo, denotando el primario con otro nombre.

Configuraciones estática del listener

Además de la configuración standard del Listener, deberemos de definir una linea estática con la definición del standby.

# Configuracion estatica para el Dataguard
SID_LIST_LISTENER=
  (SID_LIST=
    (SID_DESC= (DB_UNIQUE_NAME=cdbtest_sandby) (ORACLE_HOME=/u01/app/oracle/product/12.1.0/dbhome_1) 
(SID_NAME=cdbtest))

Si no tenemos esta opción, al intentar conectar con el rman obtendremos el error

RMAN-04006: error from auxiliary database: ORA-12528: TNS:listener: all appropriate instances are blocking new connections

Creación de las rutas físicas de la BBDD

En el caso como es el del ejemplo que haya rutas físicas para los datafiles, deberán de estar creadas en el servidor de standby con los permisos necesarios.

Copiado de fichero init.ora

Aunque hemos dicho que es necesario que la base de datos primaria necesitaba de un fichero sprite, para poder arrancar nuestra base de datos de dataguard , la base de datos standby necesitará un init.ora mínimo para arrancar.
Este init.ora va a ser cambiado por el spfile que recuperaremos de la primary,
Es importante que tengamos:

  • db_name
  • db_unique_name
  • local_listener

El resto como decimos lo eliminará substituirá el proceso.

*.audit_file_dest='/u01/app/oracle/admin/cdbtest/adump'
*.audit_trail='db'
*.compatible='12.1.0.2.0'
*.db_block_size=8192
*.db_domain=''
*.db_name='cdbtest'
*.db_unique_name='cdbtest_sdby'
*.diagnostic_dest='/u01/app/oracle'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=cdbtestXDB)'
*.enable_pluggable_database=true
*.local_listener='LISTENER_CDBTEST_STANDBY'
*.log_archive_config='DG_CONFIG=(cdbtest,cdbtest_sdby)'
*.memory_target=4000m
*.open_cursors=300
*.processes=300
*.remote_login_passwordfile='EXCLUSIVE'
*.standby_file_management='AUTO'
*.undo_tablespace='UNDOTBS1'

Creación de fichero de duplicado

Llegamos al punto importante, el fichero de duplicado de aman.
Este proceso que era bastante costoso en las versiones 9 y 10 se ha facilitado muchísimo en la 11 y 12.

El fichero viene a ser algo así

connect target sys/XXX@cdbtest_primary
connect auxiliary sys/XXX@cdbtest
DUPLICATE TARGET DATABASE
  FOR STANDBY
  FROM ACTIVE DATABASE
  DORECOVER
NOFILENAMECHECK
  SPFILE
	SET db_unique_name="cdbtest_sdby"  comment "Base de datos sandby"
	SET LOCAL_LISTENER="LISTENER_CDBTEST_STANDBY"
	SET standby_file_management='AUTO'
	set log_file_name_convert='/u01/app/oracle/oradata/cdbtest/','/u01/app/oracle/oradata/cdbtest/'

Y los puntos importantes son:

  • NOFILENAMECHECK Esto nos dejará todos los ficheros exactamente como en la primary
  • Apartado set Aqui le decimos lo que va a cambiar del spfile respecto de la original, nosotros cambiamos:
    • db_unique_name. Indicamos el unique name de la standby
    • LOCAL_LISTENER Este es importante para que encuentre el listener de la maquina de la standby
    • log_file_name_convert La teoría indica que no deberíamos de tener que indicar este parámetro, pero en diversas pruebas he tenido problemas con los redo log files, mediante esta cláusula, indicándole el path de los redo log Files por duplicado (para que no cambie nada) los crea correctamente

Duplicacion

Con esto solamente nos queda el proceso de duplicación, que ya es algo tan sencillo como ejecutar en el servidor de standby

#!/bin/bash
SET ORACLE_SID=cdbtest 
sqlplus "/as sysdba" << EOF
startup nomount;
exit;
EOF
rman cmdfile comandos_rman.cmd 

Evento de espera enq: HW

Hoy vamos a ver un tipo de evento relaccionado habitualmente con las inserciones.

El HW High Water enqueue enq: HW se da cuando varios procesos compiten para aumentar el high water mark de una tabla .

Si disponemos del Enterprise manager console, podremos ver como aparece claramente un area marron de configuracion.

Esta carga se asocia claramente a una consulta de insert

Este caso puede ser comun en procesos de aplicacion con actualizaciones en paralelo sobre la misma tabla.

La manera de la resolución del mismo puede pasar por ampliar los freelists.

Mas informacion como siempre en soporte oracle

  • WAITEVENT: «enq: HW – contention» Reference Note (Doc ID 2098543.1)
  • Analyzing ‘enq: HW – contention’ Wait Event (Doc ID 740075.1)