Arrancando E4 en Barcelona

En unas horas empieza el evento de E4 en Barcelona organizado por Accenture Enkitec. Creo que va a ser un evento que va a valer la pena, veremos experiencias reales aplicadas con las distintas generaciones de Exadata y pinceladas de Big Data. Los que van a contar son la gente que tiene experiencia sobre el campo, no son charlas de Pre Sales!

Y es una buena ocasion para reencontrar con viejos conocidos y ex-compañeros!

 

TNS-1189 Enterprise Manager en Cold Failover Cluster

Hace un par de semanas desplegue Oracle Enterprise Manager 12c Releae 5 (AKA Cloud Control) en un cliente. Este cliente tiene 4 servidores de base de datos de los cuales cada par forma un Cluster Activo Pasivo (Cold Failover). Inicialmente deje la instalacion hecha y los agentes desplegados en los 4 nodos y esta semana he empezado a configurar las reglas de notificaciones, traps de snmp, metricas adaptativas, metricas customizadas etc. Basicamente relizando una configuracion un poco mas avanzada que el out-of-box.

Los dias siguientes me empezó a llegar unos mails de Enterprise Manager quejando de TNS-1189 The listener could not authenticate the user en los dos Clusters. Revisando los logs de listener se ve que algún proceso del nodo PASIVO ejecuta varios comandos tipo

lsnrctl version

lsnrctl show oracle_home

lsnrctl status

lsnrctl show log_directory

lsnrctl show trc_directory

Comparando el timestamp de estos eventos con el timestamp de Auto Discovery de Enterprise Manager se ve que es el agente de Enterprise Manager que ejecuta dichos comandos durante el proceso de Auto Discovery.

Y la razón de TNS-1189 es porque el listener.ora (que es local en cada nodo) de todos los nodos de Cluster apuntan a la IP Virtual, y cualquier comando de lsnrctl se ejecuta con la IP Virtual, desde el nodo pasivo es un problema porque esta intentando hacer un lsnrctl contra un nodo remoto y sale este error:

 

lsnrctl status

LSNRCTL for IBM/AIX RISC System/6000: Version 12.1.0.2.0 – Production on 19-MAR-2016 13:31:00

Copyright (c) 1991, 2014, Oracle.  All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=smcc1-vrt)(PORT=1981)))
TNS-01189: The listener could not authenticate the user

 

La solucion que se ha optado es mover el listener.ora a los discos compartidos y los listener.ora de $ORACLE_HOME/network/admin pasan a ser link simbolico que apunta al listener.ora del disco compartido.

 

 

 

 

AWR y Multitenant (a nivel de PDB)

Realizo bastantes “Performance Assesments” y desde hace unos meses estoy realizando para un cliente que usa Multitenant de 12c. Este cliente esta en el extranjero (en España de momento no he estado en clientes que use Multitenant) tiene 3 PDB desplegados en un CDB en arquitectura RAC. Consolidó 3 bases de datos en 3 PDB.

En todos los analisis de rendimiento que realizo uso extensivamente estadisticas de AWR como KPI de Bases de Datos para determinar el uso, el tipo de workload, la carga (CPU, I/O, Interconnect) etc. En arquitectura Multitenant con varios PDB esto es una tarea imposible ya que los AWR no bajan hasta la granularidad de los PDB excepto “Service Statistics”, “Service Wait Class Stats” y “SQL Statistics”, insuficientes en mi opinion.

Creo que el AWR esta preparado para bajar al nivel de PDB porque las tablas bases de AWR tiene campos de CON_ID y CON_DBID sin embargo en 12.1.0.2 solamente se esta rellenando datos del CDB. Hay otro indicador que es probable que en una version proxima (12.2?) se pueda bajar las metricas a nivel de PDB por estas vistas:

V$CON_SYS_TIME_MODEL
V$CON_SYSSTAT
V$CON_SYSTEM_EVENT
V$CON_SYSTEM_WAIT_CLASS

Existen en 12.1.0.2 y tienen datos desglosados desde el CDB hasta los PDB pero por alguna razon que desconozco no se esta llevando a AWR.

De momento he tenido que hacer unos procesos customizados contra las 4 vistas de V$CON_* para sacar los KPI de los PDB.

En mi opinion es un “Drawback” de utilizar Multitenant en 12cR1. No esta preparado para realizar en condiciones las tareas de Capacity Planning y Forecasting. Antes podia medir el uso de recurso de la base de datos pero una vez movido a un CDB que convive con mas PDB todo se vuelve mas complicado.

 

SQL Server 2016 on Linux

Microsoft acaba de anunciar el Preview de SQL Server 2016 para Linux. La idea parece que es para competir en los Cloud Publicos.

La verdad es que nunca se me habia pasado por la cabeza que Microsoft pueda desarrollar un software Enterprise para la plataforma de Linux. Esto muestra el empuje de Opensource, software tipo Hadoop, Openstack, Docker, Jenkins etc.

 

 

 

Latencia sobre Write Back Cache de Exadata

El otro dia, impartiendo un Workshop de Exadata a unos clientes alguien pregunto como trata Exadata con los problemas de latencia en los discos de Flash. Como se sabe los Flash tienen problemas de outliers (escrituras atipicas) que pasa de vez en cuando.

Esta pregunta surgio a raiz de que estaba explicando el funcionamiento de Write Back Cache y Flashlog. En el caso de Flashlog las escrituras de redo se envia tanto al Flash como a los discos normales (HP, HC o EF) de las celdas y el que realiza ACK primero es el que valida la escritura. Cuando ocurren los outliers de las escritura sera del disco normal que var a responder antes con el ACK. Con esto se consigue unos tiempos uniformes en las escrituras de redo.

En el caso de Writeback Cache no existe ese tipo de mecanismo simplemente porque no es necesario. Las escrituras de los bloques sucios de Buffer de la base de datos a disco se realiza de manera asincrona por lo que si alguna escritura es mas lenta no se ven afectadas las sesiones de usuarios. De todos modos en la version 12.1.2.1.0 de software de Exadata se ha extendido la funcionalidad “I/O Latency Capping” (introducido en 11.2.3.3.0) que palia los problemas de lentitud de escrituras a Flash. Cuando las escrituras son lentas en los Flash internamente son redirigidas al otro Flash en la misma celda.

Previamente esta funcionalidad paliaba los problemas de lecturas, redireccionaba las lentas a otras celdas.

Exadata Quorum Disk Manager

En todos los releases de parches de Exadata se suele introducir mejoras y funcionalidades nuevas. En el ultimo parche, la 12.1.2.3.0, hay una mejora que merece una mencion especial en mi opinion que es el “Quorum Disk Manager”.

En los Exadata de 1/8 y 1/4 de RACK solo es posible tener 3 copias de Voting Disks porque el numero de celdas es de 3 (por defecto son 3 celdas pero es ampliable). Parece que no pero para aquellos que tienen que parchear las celdas a veces da un poco de inseguridad ya que si durante el parcheo de una celda (rolling upgrade) y por alguna razon la otra celda falla el cluster entero se va a caer por no tener la mayoria de quorum (1 de 3) y esto considerando que el mirroring de ASM en un Exadata de produccion deberia ser Triple Mirroring y uno se pregunta de que le sirve si no se puede redundar mas los Voting Disks cuando pasa lo que pasa.

En el ultimo parche de Exadata, la 12.1.2.3.0 se ha introducido Quorum Disk Manager que permite pasar de 3 a 5 Voting Disks y asi poder evitar la situacion que se ha mencionado. Los 2 Voting Disks extras se alojaran en los nodos de computacion (Database Nodes) y por lo visto se expone unos discos locales de estos nodos via iSCSI a otros nodos.

Lo de tener solamente 3 Voting Disks en 1/8 y 1/4 RACK es un problema que lo reconocia incluso el propio Oracle en su WP del año 2013, Best Practices for Database Consolidation On Exadata Database Machine.