Archive

Posts Tagged ‘Administración’

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…

Oracle MAA – Arquitecturas de referencia

diciembre 17, 2015 Deja un comentario

Oracle MAA best practices definen cuatro arquitecturas de referencia de alta disponibilidad que se ocupan de la gama completa de la disponibilidad y protección de datos requeridos por las empresas de todos los tamaños y líneas de negocio. Las arquitecturas o niveles se designan como Platino, Oro, Plata y Bronce.

MAA01

BRONZE

El nivel Bronze es el más indicado para las bases de datos donde un simple reinicio o restaurar la copia de seguridad es “HA enough”.

El nivel Bronze se basa en una sola instancia de base de datos Oracle con las MAA best practices, que utilizan muchas capacidades de protección de datos y alta disponibilidad que se incluye con cada licencia Oracle Enterprise Edition.

El Backup utilizando Oracle Recovery Manager (RMAN) proporciona protección de los datos y se utiliza para restaurar las bases de datos. La política de retención para los Backup’s vendrá dada por el RTO que tengamos. En los entornos productivos la necesidad de archivelog es imprescindible.

SILVER

El nivel Silver proporciona un nivel adicional de alta disponibilidad para las bases de datos que requieren unos tiempos mínimos, o cero, de inactividad en caso de problemas con la instancia de base de datos o fallo en el servidor, así como muchas tareas de mantenimiento planificado. El nivel de Silver agrega tecnología de Clustering, ya sea Oracle RAC u Oracle RAC One Node.

A este escenario le sumaríamos los pertinentes Backup’s con RMAN.

Estos Backup’s los podremos ir optimizando conforme a la arquitectura Silver que tengamos. Es decir: si se trata de un Cluster de base de datos, y manejamos grandes volúmenes Very Large Database (VLDB), la mejor solución para reducir la ventana será paralelizar el Backup, lanzándolo desde todos los nodos; a esta opción de Backup le podemos añadir compresión, dado que esta opción no requiere licenciamiento adicional.

Este es un ejemplo de cómo alocar canales en varios nodos de un RAC:

ALLOCATE CHANNEL ch00 TYPE ‘SBT_TAPE’ PARMS=”ENV=(NB_ORA_CLIENT=srvcrmp01-vip)” CONNECT=’sys/password@CRM1′;
ALLOCATE CHANNEL ch01 TYPE ‘SBT_TAPE’ PARMS=”ENV=(NB_ORA_CLIENT=srvcrmp02-vip)” CONNECT=’sys/password@CRM2′;

GOLD

El nivel Gold aumenta las expectativas, sustancialmente, para aplicaciones críticas de negocio que no pueden aceptar la vulnerabilidad a los puntos de fallo individuales. Este nivel añade tecnologías de replicación de bases de datos Oracle. En esta arquitectura se puede incluir, además: Oracle Active Data Guard, para poder descargar de trabajo la base de datos primaria (necesita un licenciamiento adicional y también está incluida en la licencia de GoldenGate) y Oracle GoldenGate, que sincroniza una o varias réplicas de la base de datos de producción, para proporcionar una protección de datos en tiempo real y disponibilidad. La replicación de bases de datos aware mejora sustancialmente la alta disponibilidad y protección de datos,  más allá de lo que es posible con las tecnologías de replicación de almacenamiento.

PLATINUM

El nivel Platinum introduce varias nuevas capacidades de Oracle Database 12c y muchas características que se han mejorado con la última versión. Estas capacidades incluyen: Application Continuity y Active Data Guard Far Sync para la protección con cero pérdida de datos a cualquier distancia, mejoras en Oracle GoldenGate para zero downtime ante actualizaciones y migraciones, y Global Data Services para la gestión automática del workload balancing en entornos de bases de datos replicadas. Cada una de estas tecnologías requiere un esfuerzo adicional para ponerlas en práctica, pero entregan un valor sustancial para las aplicaciones más críticas, en las que el tiempo de inactividad y la pérdida de los datos no son una opción.

En la Siguiente tabla podemos ver un resumen de los distintos niveles de protección y perdida de datos:

Table01

 

Para mas información sobre Oracle MAA os dejo este enlace a otro post muy interesante:

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.

Oracle Database 12c, ¿con “c” de “cloud” o de “consolidación”?

abril 24, 2014 1 comentario

En un post anterior presente la nueva versión de Oracle Database 12c como la “autopista hacia la nube”. Su arquitectura facilita en gran manera el traslado de las BBDD a datacenters remotos (al llamado “cloud”), convirtiendo nuestras BBDD en un servicio mas.

En caso que no queramos/podamos realizar este paso hacia la nube, la arquitectura “multitenant” sigue aportándonos grandes ventajas, entre ellas la de la consolidación.

Simplify Database Consolidation

Hasta la fecha era posible ejecutar varias instancias de BBDD en una misma maquina, pero esto a cambio de:

  • Tener una gran cantidad de servicios y “pools” de memoria repetidos y con muy pocas posibilidades de trasladar recursos entre ellos.
  • Necesidad de gestionar configuraciones de monitorización, políticas de passwords, auditorias, gestión de usuarios y autorizaciones por separado para cada una de las BBDD.
  • Parcheado separado de cada una, necesitando realizar tantos “parcheos” como bases de datos dispongamos.
  • Disponer de múltiples scripts de backup, que se tendrán que lanzar y controlar por separado.
  • Dificultad en crear nuevas BBDD, ya que implicará tener que reconfigurar parámetros de kernel en el servidor para permitir ejecutar los “n” nuevos servicios a arrancar, las nuevas zonas de memoria a asignar e incluso posiblemente sea necesario presentar nuevo storage.
  • El traslado de BBDD a este nuevo entorno puede ser simple o complicado dependiendo de las versiones de BBDD origen/destino.

Por otra parte la opción de crear una sola BBDD por servidor y configurar allí todas las aplicaciones de la empresa normalmente queda descartada por problemas de colisión de roles/esquemas, por temas de seguridad, de configuración o de uso de las aplicaciones.

La nueva versión de Oracle, y su arquitectura “pluggable”, nos da solución a muchos de los problemas anteriores:

  • Podemos usar un solo conjunto de procesos y “pools” de memoria en la maquina, compartidos por todas las PDB (Pluggable Database), de manera que los recursos se podrán distribuir de la manera mas optima.
  • Muchas de las tareas de gestión se podrán realizar sobre todas la BBDD a la vez desde la CDB (Container Database).
  • Si así lo deseamos podremos tener un solo backup y por tanto una sola tarea a lanzar y monitorizar.
  • Podremos disponer de “plantillas de BBDD” que nos permitirán crear nuevas BBDD conectadas a nuestro CDB en pocos minutos.
  • El traslado/upgrade de las BBDD se facilita en gran manera ya que consiste básicamente en la desconexión de la BBDD del CDB actual y conectarla al nuevo, de esta misma manera los upgrades consisten en actualizar el CDB actualizando al mismo tiempo todas las CBD que tenga conectadas.

En resumen, que esta nueva versión nos facilita en gran medida concentrar servicios en una menor cantidad de hardware aprovechando mucho mejor éste. Y pensemos que  menos hardware implica:

  • Menos administración (actualización de sistemas operativos, incidencias, backups)
  • Menos licencias de soporte hardware/software
  • Menos tareas de migración a nuevas plataformas cada pocos años

Es para pensarlo, ¿no?

Protegido: Tuning de aplicaciones desarrolladas con Oracle Forms 11gR2

noviembre 6, 2013 Escribe tu contraseña para ver los comentarios.

Este contenido está protegido por contraseña. Para verlo introduce tu contraseña a continuación:

Oracle Enterprise Manager 12c & Management Packs

octubre 22, 2013 1 comentario
OEM-12c Oracle Enterprise Manager 12c & Management Packs Conozca en esta presentación técnica la última versión de la herramienta de gestión y monitorización de todo el stack tecnológico de Oracle. Descubra cómo, con la ayuda de múltiples packs, esta herramienta le puede ayudar a mejorar el rendimiento y disponibilidad de sus sistemas, aumentar la productividad y reducir los errores humanos de sus administradores.

(Rafael Planella – Arquitecto de sistemas)

Tareas programadas en entornos Oracle

avanttic scheduled tasksEn varias ocasiones he encontrado clientes con dudas sobre cómo se ejecutan las tareas programadas en sus sistemas Oracle (BBDD y servidores). No tienen claro quién es el responsable de su programación y ejecución, y esto puede ser un problema en caso de tener que modificarlas o desactivarlas.

A grandes trazos, podemos ejecutar tareas de 4 formas:

  • Sistema operativo
  • Tareas de la consola de administración
  • Jobs de BBDD
  • Scheduler de BBDD

Sistema operativo

Podemos programar tareas desde sistema operativo mediante el “crontab” en entornos Unix/Linux o el “Programador de tareas” en Windows.

Es bueno saber que en el caso concreto de los entornos Linux las tareas programadas en el crontab se almacenan de manera particular para cada usuario (cada uno puede tener las suyas) y, además, existen unos directorios de cron “horario”, “diario” y “mensual” en los que si dejamos algún script se ejecutará en esos intervalos de tiempo.

Tareas de la consola de administración

Podemos programar tareas desde la DBConsole o el Enterprise Manager/Grid Control, almacenándose en la BBDD de repositorio de estos productos. Pueden realizar tareas de todo tipo, sobre diferentes objetivos locales y remotos, hosts, BBDD, Servidores de Aplicaciones… (en el caso de objetivos remotos mediante agentes y solo en el caso del EM/GC).

Es bueno saber que estas tareas pueden generar confusión en el caso de la DBConsole, ya que en muchos casos se confunden con tareas de BBDD. Si por ejemplo programamos una “Tarea de Backup de BBDD” desde la DBConsole, se programará como una tarea de consola y solo podremos controlar su ejecución y logs desde la misma, además no se ejecutará si la consola está parada. En la siguiente imagen podemos ver el link de las tareas programadas en la DBConsole:

jobs_consola

Jobs de BBDD

Estas eran las tareas típicas de BBDD hasta la versión 9.2. Consisten en un programador “simple” que permite ejecutar código PL/SQL o SQL de manera repetitiva a ciertos intervalos. Podemos programar estas tareas mediante el paquete de PL/SQL DBMS_JOB y controlar las tareas que tenemos programadas en la tabla DBA_JOBS (las que están en marcha en  DBA_JOBS_RUNNING).

Es bueno saber que si el código programado no finaliza correctamente la tarea se intentará repetir a intervalos de tiempo que se irán doblando en cada iteración (en 1 minuto, en 2 minutos, en 4 minutos… hasta llegar al tiempo programado de la próxima ejecución “normal” prevista), al llegar a los 16 intentos la tarea se marcará como “broken” y no se repetirá. Esto es importante si tenemos una tarea que realiza ciertas modificaciones parciales antes de fallar, ya que estas modificaciones parciales se podrían repetir múltiples veces.

Otro detalle interesante es que podemos decidir cuántas tareas se pueden ejecutar simultáneamente (o parar completamente la ejecución de tareas) mediante el parámetro de inicialización “JOB_QUEUE_PROCESSES”, este parámetro es dinámico (lo podemos cambiar sobre la marcha sin parar el gestor). Por ejemplo si lo definimos a cero dejan de ejecutarse tareas mediante el sistema de JOBS.

Scheduler de BBDD

Finalmente tenemos el “SCHEDULER”, un sistema avanzado de programación de tareas aparecido en la versión 10g de la BBDD y que se ha ampliado y mejorado en versiones posteriores. Podemos crear una biblioteca de tareas, lanzar scripts de sistema operativo, crear cadenas de trabajos, ejecuciones condicionadas a eventos, ventanas de ejecución, vincular tareas al gestor de recursos, etc.  En resumen, mucho más potente que el anterior sistema de jobs.

Se pueden programar las tareas mediante el paquete DBMS_SCHEDULER o desde el apartado de tareas de la BBDD en la DBConsole o en el EM/GC. Este es el sistema recomendado para programar tareas en las BBDD 10g y superiores.

En la siguiente imagen tenéis el resumen de componentes que forman el scheduler y sus relaciones:

scheduler

Es bueno saber que si nos interesa arrancar la BBDD sin que se ejecute ningún job del scheduler, y estamos en versión 11.2, podemos definir a cero el parámetro job_queue_processes ya que en esta versión no solo desactiva los DMB_JOBS sino también los trabajos del scheduler. Para otras versiones tendremos que arrancar la BBDD en modo MIGRATE o UPGRADE y ejecutar el siguiente código:

exec dbms_scheduler.set_scheduler_attribute(‘SCHEDULER_DISABLED’,’TRUE’);

En la siguiente imagen tenéis la entrada de la DBConsole correspondiente a la programación de tareas en el Scheduler:

dbconsole_scheduler

Categorías:Sistemas Etiquetas: , , ,