Archivo

Posts Tagged ‘Herramientas’

Exprimiendo a GoldenGate: SPECIALRUN y REMOTETASK

La semana pasada tuve que afrontar finalmente la reinstanciación de una BD del entorno PREproductivo, replicada con GoldenGate, que llevaba meses con el replicat Abended… y por lo tanto, totalmente desincronizada. Me daba mucha pereza, así que dediqué un rato a buscar la manera de hacerlo lo más rápidamente posible y con el mínimo esfuerzo.

A grandes rasgos, se trata de un esquema con 6 o 7 grandes tablas con millones de registros, y una cincuentena de tablas “maestras” con, comparativamente, pocos registros. La situación invitaba a plantear dos estrategias diferentes: una “personalizada” para la carga de cada una de las tablas grandes y otra para que permitiera transferir el mayor número posible de tablas con el menor esfuerzo de preparación y configuración.

Con este segundo objetivo en mente, recordé -y revisé- las características de GG para las cargas de datos iniciales que, a pesar de no ser una novedad (Rafael Planella ya las describió hace tiempo) , creo que no son muy conocidas, por lo que veremos con más detalles un par de ellas en este post (bajo un título un poco más marketiniano que “cargas iniciales”).

El siguiente esquema ilustra las diferencias entre la ejecución online (sin pump, por simplicidad), en gris, y procesos de integración de datos utilizando special run, sourceistable y remotetask, en verde.

GG_SR_Schema_1v0

Se trata de procesos ad-hoc que disponen básicamente de la misma funcionalidad que los extract y replicat normales (online), pero que se pueden levantar, ejecutar su tarea, y terminar, desapareciendo sin prácticamente dejar rastro en la configuración global de la instancia de GG, y sin consumir recursos del sistema mientras no está en uso. Por eso lo he considerado una posibilidad interesante para su uso en otras tareas de integración de datos más allá de la cargas iniciales, y me ha parecido interesante compartirlo.

Veamos a continuación un ejemplo de los dos posibles métodos para sincronizar tablas directamente, con sólo los recursos propios de GoldenGate (sin utilidades adicionales):

  • Extract File (Extract-Collector-Replicat)
  • Direct Load (Extract-Replicat, sin ficheros)

Leer más…

Oracle Out of Place Patching Database (Cloud Control 13c R2)

En este post vamos a parchear una Base de Datos Oracle 11.2.0.4. El parche que aplicaremos será el último publicado por el fabricante pero con alguna diferencia respecto a cómo aplicaríamos normalmente un PSU.

Out of Place Patching

Esta opción de parcheo consiste en generar una copia o clon de nuestro ORACLE_HOME. Tal y como se muestra en la imagen anterior el proceso se ejecuta de la siguiente manera:

  • Clonado del ORACLE_HOME
  • Aplicación del Parche al ORACLE_HOME Clonado
  • Switch de la Base de Datos: Este paso consiste en parar la Base de Datos y levantar desde el ORACLE_HOME en el que ya se ha aplicado el parche.
  • Aplicar SQL´s: Si el parche incluye SQL´s sera necesario aplicarlo a cada una de las Bases de Datos.

Este proceso de parcheo es tremendamente efectivo ya que minimiza los tiempos de parada y garantiza una marcha atrás totalmente transparente. Pero puede no ser una tarea fácil, o por lo menos conlleva una serie de pasos a tener en cuenta antes de ejecutar el parcheo.

Out of Place Patching desde Oracle Cloud Control 13c

En este post veremos como realizar este proceso de parcheo desde Cloud Control 13c de una manera sencilla y clara, a la vez que, eliminamos cualquier error humano y tareas adicionales como:

  • Cambio del fichero de parámetros SPFILE y passwordfile (Esto puede no ser necesario dependiendo de como se haya clonado el ORACLE_HOME).
  • Modificación del parámetro ORACLE_HOME en la capa de Clusterware.
  • Modificación del ORACLE_HOME en Enterprise Manager.

Después de esto vamos a iniciar el parcheo. Antes que nada comprobaremos en que estado esta la Base de Datos:

Leer más…

MAF 2.3 – Preparar un PC para generar Apps para Windows 10

Dentro de las novedades que incorpora MAF 2.3 la más importante es la posibilidad de generar aplicaciones para entornos Windows. Vamos a ver cómo preparar un entorno para desarrollar aplicaciones para Windows mediante Oracle MAF.

Instalar la extensión de MAF 2.3

La nueva versión de MAF se presenta como una extensión para JDeveloper 12.2.1. Este es un cambio importante, ya que las versiones anteriores se instalaban en JDeveloper 12.1.3. La instalación sigue el mismo patrón que cualquier extensión de JDeveloper, mediante la opción “Check for Updates…” en el menú “Help”.

Instalar Visual Studio 2015 Community Edition

Para generar los ejecutables, MAF se apoya en la plataforma de desarrollo de Microsoft, Visual Studio. Por lo tanto, necesitamos tener instalado en nuestro PC una copia de Visual Studio. Microsoft ofrece distintos paquetes de la herramienta, entre ellos la Community Edition, que se puede instalar sin coste. La versión gratuita es suficiente para generar con MAF. La descargamos y la instalamos.

Página principal Visual Studiio
Durante el proceso de instalación, hay que asegurarse de instalar  la opción “Visual Studio Tools For Universal Windows Apps”.
Marcar "Universal Windows App Development Tools" Leer más…

Análisis de thread dumps en WebLogic: ThreadLogic

marzo 29, 2016 4 comentarios

icono threadlogicSiguiendo con el tema de análisis de thread dumps, que se empezó en este otro post, vamos a centrarnos en la utilización de la aplicación ThreadLogic, que ha sido desarrollada por el equipo de arquitectos de Oracle FMW orientándola a dumps de servidores de aplicaciones. Se puede descargar aquí.

Al igual que Samurai y Thread Dump Analyzer (TDA), se trata de una aplicación libre que se arranca lanzando: java -jar <path fichero jar>

Comentar que para las pruebas se han utilizado las mismas aplicaciones que en el post anterior.

Diferencias con Thread Dump Analyzer (TDA)

El desarrollo de esta herramienta se ha realizado a partir de TDA:

  1. La información se muestra de una forma mucho más visual.
  2. La información está más categorizada:

threadlogic categorias dumps

  1. Está muy orientada al análisis de thread dumps de Oracle WebLogic Server:

threadlogic categorias dumps WLS

  1. Se puede filtrar por el estado del thread:

threadlogic filtro health

Stuck threads

Los stuck threads se marcan con este estado a nivel de servidor de aplicaciones cuando un thread está corriendo durante más de X segundos.

Leer más…

Análisis de thread dumps en WebLogic

marzo 3, 2016 7 comentarios

Hace unos meses escribí este post donde os explicaba qué son los stuck threads y cómo detectarlos.

En el post de hoy os voy a presentar algunas herramientas que os pueden ser útiles para realizar el análisis de thread dumps, necesarios para la detección de stuck threads, deadlocks, etc.

Sin embargo, no hay que perder de vista el hecho de que como administradores únicamente podremos saber dónde está el problema, no solventarlo.

 

Ejecución de pruebas

Por si tenéis interés en realizar vuestras propias pruebas, aquí podéis encontrar una aplicación para provocar deadlocks, gentileza de nuestro compañero Àngel Ollé.

Una vez desplegada en una instancia WebLogic, se puede provocar un deadlock realizando peticiones a http://ip:puerto/DeadLockServlet/dl

Para generar stuck threads podéis utilizar la aplicación StuckThreadForFree realizando llamadas a http://ip:puerto/StuckThreadForFree sobre la instancia WebLogic.

Se definen cuántos threads levantar, cuántos segundos mantenerlos levantados y qué operación estarán ejecutando durante ese tiempo:

stuckthreadforfree prueba

¿Qué herramienta utilizar?

Hay muchas herramientas en el mercado pero las más comúnmente utilizadas, que además son libres, son:

  1. Samurai
  2. Thread Dump Analyzer (TDA)
  3. ThreadLogic

Todas consisten en un JAR, por lo que su ejecución es tan simple como lanzar ‘java -jar <path fichero jar>’. La diferencia reside en cómo se muestra la información en la interfaz.

Una vez se ha iniciado la aplicación, abrimos el fichero de texto donde tenemos el thread dump.

Comentar que las aplicaciones pueden interpretar ficheros con varios thread dumps.

 

1. Samurai

Descarga: http://yusuke.homeip.net/samurai/en/samurai.jar

Es una aplicación muy intuitiva donde se identifican con facilidad bloqueos:

Samurai threads bloqueados

Leer más…

Oracle Enterprise Manager Cloud Control 12c – Microsoft Active Directory Authentication

febrero 11, 2016 2 comentarios

Oracle ofrece varios plugins y conectores para integrar Cloud Control en nuestros Sistemas, como por ejemplo un conector para Remedy, envió de traps a distintos gestores de monitorización como PatrolPandora entre otros, así como distintos métodos de autentificación.

En este post nos ocuparemos de integrar la autenticación por Microsoft Active Directory. Este es un procedimiento que no requiere mucha complejidad y nos facilitará la administración de Cloud Control 12c.

La arquitectura dispuesta para este post es:

  1. Controlador de Dominio Windows Server (AD)
  2. Oracle Enterprise Manager 12c Cloud Control (OEM)

Una vez que tengamos configurado la autentificación por AD crearemos varios grupos/roles para acotar los permisos en nuestra arquitectura. Para ello vamos a plantear la siguiente necesidad: “Autentificación por AD para crear los siguientes tres grupos de usuarios“.

  • EM_DDBB (Para la gestión de todas las Bases de Datos )
  • EM_MIDDLEWARE (Para la gestión de todos los targets de tipo aplicación y middleware)
  • EM_OPERATOR (Con permisos de lectura sobre toda la plataforma)

Lo primero que haremos será crear una serie de usuarios y los grupos descritos anteriormente:

Usuarios

AD1

Grupos

AD2

Asociamos a cada usuario en su grupo correspondiente:

  • EM_DDBB=Adam Fripp
  • EM_MIDDLEWARE=Alana Walsh
  • EM_OPERATOR=David Lee

Leer más…

Threads stuck en WebLogic

En este post vamos a explicar qué son y cómo analizar los threads stuck en WebLogic. Ante todo hay que tener en cuenta que el hecho que un thread sea considerado stuck (traducción literal: “atascado”) no implica, necesariamente, que existe alguna problemática de fondo.

¿Qué es un thread stuck?

Cuando un thread está levantado durante demasiado tiempo, ya sea haciendo una pausa (por ejemplo, por un sleep) como realizando trabajo activo (como calcular decimales del número pi), se marca como stuck. Este thread no ha sido capaz de completar su trabajo y, por lo tanto, no acepta nuevas peticiones. El problema viene cuando un proceso empieza a marcar todos sus threads como stuck.

¿Qué podemos hacer para detectarlos?

WebLogic detecta automáticamente los threads stuck pero se pueden tomar varias acciones ante esta situación:

  1. Overload Protection: Se puede configurar a nivel de instancia cómo reaccionar ante situaciones de sobrecarga. Se define cuánto tiempo esperar antes de marcar un thread como stuck, cuántos threads en stuck se pueden permitir y qué acción tomar entre pasar la instancia a modo ADMIN o pararla directamente. En cualquiera de los casos, se ha de tener en cuenta que la acción afecta a la instancia (en el caso que una instancia desplegase varias aplicaciones, todas se verían afectadas).
    overload protection
  2. También se puede configurar que el Work Manager asociado se pare, volviendo a estar activo en el caso que dejase de superarse el umbral de threads stuck.
    workmanager_workload
  3. Módulos de diagnóstico: WebLogic proporciona por defecto la funcionalidad de módulos de diagnóstico, configurable a través de la consola de administración o WLST. Esto consiste, básicamente, en monitorizar la métrica de StuckThreadCount de runtime del servidor y definir un umbral. En caso de superación, se pueden tomar varias acciones: enviar un correo, crear un mensaje JMS, lanzar una imagen de diagnóstico, enviar una notificación JMX o enviar un trap SNMP.
    Las imágenes de diagnóstico consisten en un fichero .zip con varios ficheros .img (que se pueden abrir en texto plano) que aportan información completa del estado de la instancia (es una captura del estado de la instancia).
    También se puede utilizar el explorador WLDF para abrir estos ficheros .zip, que organiza la información en forma de árbol.
  4. Acciones correctivas desde Cloud Control: En el supuesto que se tengan importadas las instancias en cloud Control, se pueden definir umbrales de advertencia y críticos y asociar una acción correctiva a dichos umbrales. Estas acciones pueden ir desde reiniciar la instancia a lanzar un script propio.cc_corrective_action

¿Qué análisis podemos hacer?

Para poder analizar los threads stuck, es importante disponer de la siguiente información:

  • Thread dump: es importante lanzar varios thread dumps en un intervalo de tiempo, para poder analizar la evolución en el uso de threads.
  • Consumo de los threads stuck: a partir de un thread dump se puede obtener el identificador del thread y, con este identificador, el consumo de cpu y memoria de estos threads mediante, por ejemplo, un comando ‘ps’.
  • Heap dump: en determinadas circunstancias puede ser interesante lanzar un heap dump (recordad que esto deja congelada la instancia).

Con toda esta información se ha de analizar:

  1. ¿Están consumiendo muchos recursos? En caso afirmativo sería interesante analizar los recursos de la máquina.
  2. ¿Están ejecutando lo mismo, usando las mismas clases o llamando al mismo servicio backend? Una actualización en el código de la aplicación puede provocar la aparición de estos threads, ya sea por un mal desarrollo o por factores que no se han tenido en cuenta (esperas demasiado largas, no configuración de timeouts, etc.).
    También puede ser que si la aplicación llama a otro servicio, sea ese el que esté provocando la aparición de estos threads.

En cualquier caso, descubrir la causa de estos threads no suele ser sencillo y suele ser necesario colaborar con los equipos de desarrollo para analizar la información recolectada.