Qué hacer cuando tenemos una alerta de aumento de registros espectacular en el tablespace SYSAUX

Este artículo vamos a mostrar diferentes casuísticas que puedes tener cuando tienes un aumento espectacular de ocupación de tablespace SYSAUX.

A partir de Oracle 10g en adelante, hay lo que Yo llamaría un error grave (para Oracle, es una característica 💀), debido a que el tablespace SYSAUX crecerá continuamente. Sólo hay forma de limitar este crecimiento y no está claramente documentado en ninguna parte

¿Para que demonios vale ese tablespace?

El espacio de tablas SYSAUX se instaló como un tablespace auxiliar en el tablespace SYSTEM cuando creó la base de datos, apareció a partir de la versión 10g. Algunos componentes de base de datos que anteriormente creaban y utilizaban espacios de tabla independientes ahora ocupan el espacio de tablas SYSAUX.

Si el espacio de tablas de SYSAUX no está disponible, la funcionalidad de la base de datos central permanecerá operativa. Las funciones de base de datos que utilizan el espacio de tablas SYSAUX podrían fallar o funcionar con capacidad limitada.

Estos componentes pueden utilizar el espacio de tablas SYSAUX y su instalación proporciona los medios para establecer su ocupación del espacio de tablas SYSAUX. Puede controlar los ocupantes del espacio de tablas SYSAUX mediante la vista V $ SYSAUX_OCCUPANTS. Esta vista enumera la siguiente información sobre los ocupantes del espacio de tablas SYSAUX:

• Nombre del ocupante
• Descripción del ocupante
• Nombre del esquema

Configuración básica del tablespace SYSAUX

CASO #1: Uno de los ocupantes de SYSAUX, el optimizador de estadísticas, crece exponencialmente.

Tengo una base de datos de Oracle 11g R2 (11.2.0.1) donde advertí que el tablespace de SYSAUX crecía cada día más y más grande. Busqué en Metalink (perdón, Oracle My Support) y encuentro dos notas:

• Doc ID 1292724.1
• Doc ID 552880.1 

que fueron útiles.

Después de ejecutar el script awrinfo.sql, localizado en $ORACLE_HOME/rdbms/admin/, encontré que el consumidor más grande era SM / OPTSTAT en 3 GB que es más grande y no típico en comparación con mis otras bases de datos Oracle 10g R2 y Oracle 11g R1.

Investigando por la documentación encuentro lo siguiente:

"Siempre que se modifiquen las estadísticas del diccionario, las versiones antiguas de estadísticas se guardan automáticamente para futuras restauraciones. Las estadísticas antiguas se depuran automáticamente a intervalos regulares en función de la configuración de retención de historial de estadísticas y de la hora de la recopilación de estadísticas recientes realizada en el sistema. La retención se puede configurar mediante el procedimiento ALTER_STATS_HISTORY_RETENTION. El valor predeterminado es 31 días."

Para ayudar a reducir la cantidad de espacio causada por datos históricos, fijé la retención de las viejas estadísticas a 14 días.

exec dbms_stats.alter_stats_history_retention (14);

Para verificar la nueva configuración, ejecuté la siguiente declaración.

select dbms_stats.get_stats_history_retention from dual;

Procedí a depurar incrementalmente las estadísticas de 31 días a 14 días. Comenzó con 28 días, luego se trasladó a 21 días.

exec dbms_stats.purge_stats (sysdate-28);

Entonces intenté 14 días, sin embargo encontré un error del espacio de la UNDO que requiere que cambie mis incrementos usando 18, 16, y finalmente 14 para terminar la tarea de la purga.

Ahora, para recuperar el espacio utilizado por los objetos mostrados en la sección 4 del informe AWRINFO, usé el comando ALTER TABLE MOVE.

CASO #2: Otra forma de resolver el crecimiento desmesurado del optimizador de estadísticas.

A partir de 10gR1 en adelante, Oracle mantendrá la copia de seguridad de las estadísticas del optimizador automáticamente, incluso si no le pide que lo haga.

Esta información de copia de seguridad se almacena en el tablespace SYSAUX y las tablas implicadas en esto son las siguientes:

• WRI$_OPTSTAT_OPR                         
• WRI$_OPTSTAT_AUX_HISTORY                 
• WRI$_OPTSTAT_TAB_HISTORY                 
• WRI$_OPTSTAT_IND_HISTORY                 
• WRI$_OPTSTAT_HISTGRM_HISTORY             
• WRI$_OPTSTAT_HISTHEAD_HISTORY  

La retención predeterminada de esta información se obtiene con el siguiente comando:

NO se escribirá ningún mensaje en el registro de alertas ni en ningún otro lugar para indicar que no se ha producido la purga. Con cada día que pasa, la probabilidad de falla aumenta y alcanzará una etapa, donde la purga automática nunca será completada por MMON con éxito.

Alternate proporcionado por Oracle para esto es ejecutar, programa DBMS_STATS.PURGE_STATS para purgar esta información de estadísticas. Esto se puede hacer manualmente y es seguro. No hay tiempos muertos involucrados aquí. sólo una terminación manual o un fallo anormal detendrá la purga.

¿Qué más me falta aquí?

A pesar de que publicamos la retención, puede suceder que debido a la falta de purga, vamos a acumular gran cantidad de historial de estadísticas en SYSAUX, haciendo que crezca continuamente.

Como el fallo de purga no está escrito en ninguna parte, podemos perder el hecho de que hay un proceso que consume el espacio con regularidad.

El proceso PURGE_STATS suprimirá estas tablas. Por lo tanto, el espacio libre no se devuelve al espacio de tablas, lo que resulta en una fragmentación de espacio libre dentro de esta tabla.

¿Cómo sé que tengo este problema?

Compruebe su valor de retención actual utilizando la siguiente sentencia

select dbms_stats.get_stats_history_retention from dual;

Vea el historial de estadísticas más antiguo usando la siguiente declaración:

select dbms_stats.get_stats_history_available from dual;

Comparar los dos anteriores y y deberías saber qué hacer

¿Qué debería hacer ahora?

Identifique la retención del sistema tan pronto como sea posible y cambie a un valor apropiado. 30 días es el valor predeterminado. Sin embargo, los valores más pequeños no harían mucho daño.

Deshabilite el Autoextend en SYSAUX tan pronto como sea posible para asegurarse de que el espacio de tablas no crece fuera de límites y, finalmente, se convierte en inmanejable.

Comience a programar el PURGE_STATS tan pronto como sea posible y mantenga el tamaño del espacio de tablas SYSAUX en control.

Realice la reorganización de tablas relacionadas para recuperar el espacio.

¿Por qué debería importarme?

Con cada día que pasa, el tamaño de la tabla crece más grande y más grande, finalmente convirtiéndose en un consumidor superior del espacio. Los esfuerzos que se harán para la limpieza aumentará exponencialmente. HACERLO diariamente en 1hr o hacerlo en 5hr mañana.

El procedimiento PURGE_STATS realiza una supresión de comando simple con una cláusula where específica. Esto deja mucho desorden a medida que el proceso se completa completamente o no hace nada en absoluto. No se engancha a intervalos regulares en este código.

Para una base de datos promedio de 150G, en 6 meses, puede terminar con 100M filas en esta tabla. La limpieza de estos datos es siempre un dolor.

¿Algún consejo?

Identifique la información más antigua que tenga en el historial de estadísticas usando el siguiente comando.

select dbms_stats.get_stats_history_availability from dual;

Si la información es demasiado antigua, comience a purgar la información en trozos más pequeños. recuerde que si cancela el proceso en el medio, usted hará una reversión completa antes de salir.

Utilice el siguiente comando para saber en qué fechas había generación de estadísticas enormes.

select trunc(SAVTIME),count(1) from WRI$_OPTSTAT_HISTHEAD_HISTORY group by  trunc(SAVTIME) order by 1;

Comienza con la fecha más antigua y se invoca bajo el comando

exec dbms_stats.purge_stats (to_date ('01 -JAN-2010 ',' DD-MON-YYYY '));

Una vez que la cantidad de datos se reduce a un límite de tiempo razonable en las horas punta, como una actividad de mantenimiento regular.

NOTA: Tenga en cuenta que este proceso requiere muchos recursos. No lo hagas durante horas de oficina.

¿Hay vida más allá de Oracle? Riak KV:

Una base de datos de valor-clave NoSQL distribuida

Las empresas confían en los datos para alimentar sus operaciones del día a día. Cuando es imperativo que estos datos estén siempre disponibles. Incluso unos minutos de  inactividad en tus aplicativos pueden significar perdidas en los beneficios de una empresa, un usuario pobre experiencia, y una marca magullada. 

Necesitas una base de datos diferente. Basho Riak® KV Enterprise es una base de datos NoSQL distribuida diseñada para satisfacer sus necesidades de aplicación.
Riak KV ofrece alta disponibilidad y escalabilidad. Riak KV puede ser operacionalizado a que las bases de datos relacionales tradicionales y se fácil de manejar a escala.
Riak KV se integra con Apache Spark, Redis Caching, Apache Solr y Apache Mesos reducir la complejidad de la integración y desplegando otras tecnologías de Big Data.

Beneficios de RIAK KV

Una base de datos distribuida con avanzado local y multi-cluster la replicación significa que sus datos siempre están disponibles.

ESCALABILIDAD MASIVA
Distribución automática de datos en el clúster y la facilidad de añadir nodos significan un aumento de rendimiento casi lineal a medida que sus datos crecen.

SIMPLICIDAD OPERACIONAL
Fácil de ejecutar, fácil de agregar nodos al clúster. Las operaciones son potente y simple. Asegúrese de que su equipo de operaciones duerma mejor.

TOLERANCIA POR FALLO
Una arquitectura multi-nodo sin maestro asegura la pérdida de datos en el evento de fallos de red o de hardware.

ACCESO RÁPIDO DE DATOS
Sus usuarios esperan que su aplicación sea rápida. Baja latencia significa que su las solicitudes de datos se prestan de manera predecible incluso durante las horas punta.

MODELO FLEXIBLE DE DATOS
El modelo de datos NoSQL de clave / valor proporciona flexibilidad sin esquema predefinido. Llegar a la nube para la continuidad del negocio o para satisfacer su demanda máxima, Riak KV sobresale en las implementaciones privadas, públicas e híbridas de la nube.

ALMACENAMIENTO DE OBJETOS
Soporte de múltiples modelos desde una sola plataforma a través de la integración con Riak S2 para almacenamiento de objetos grandes.

DESARROLLO SIMPLIFICADO
Una amplia documentación y herramientas de embalaje funcionando en minutos, y las APIs de gran alcance son fáciles de utilizar.

Escenarios válidos para implementar RIAK

DATOS DE LA SESIÓN
Los datos de usuario incluyen información sobre los usuarios y los clientes, como nombre, dirección, datos demográficos, preferencias, los detalles de la tarjeta de crédito, la dirección de correo electrónico y los detalles históricos de las compras y las tasas de los juegos. Los datos de usuario son fundamentales para garantizar el compromiso del usuario y para completar transacciones o compras.

Los datos de la sesión de información sobre la conexión de la aplicación con el usuario y el cliente pasar de un cliente de usuario final (navegador, teléfono, etc) y luego almacenar en el servidor esperando la devolución de nuevos datos de la sesión con cambios de usuario Los datos de sesión se utilizan para las comunicaciones entre la aplicación y el usuario.

Riak KV está diseñado de manera única para manejar datos de usuario y sesión. Originalmente fue desarrollado para servir como un almacén de escenarios escalable. Dado que los ID de usuario y de la sesión se almacenan normalmente en las galletas o se conocen en el momento de la búsqueda, Riak KV puede atender estas solicitudes con una latencia predeciblemente baja.


Riak KV está diseñado para no imponer restricciones sobre el valor, por lo que los datos de sesión pueden codificarse de muchas maneras y pueden evolucionar sin cambios administrativos en los esquemas. Riak KV está diseñado para nunca perder una escritura y escalar horizontalmente de modo que, incluso en días pico, todas las acciones de su usuario se completan sin problemas.

CONTENIDO Y DOCUMENTOS
El contenido es el rey. Pero hoy en día más y más de ese contenido no está estructurado. Se trata de imágenes, documentos, archivos pdf, archivos de registro, correos electrónicos, historial de chat, libros, artículos y videos. Los días de intentar calzar este contenido en una estructura de base de datos relacional han pasado mucho tiempo.

Los problemas de la sobrecarga de la tabla de base de datos relacional (cuántos BLOBs pueden encajar en una sola tabla) se resuelven con una base de datos NoSQL distribuida. El contenido no sólo toma muchas formas tal como está escrito, sino que permite muchos casos de uso diferentes que requieren experiencias de baja latencia. El despliegue de contenido a escala requiere una plataforma distribuida que se adapte a las necesidades de sus clientes.

Riak KV es una base de datos fundamentalmente de contenido agnóstico. Puede usarlo para almacenar cualquier cosa que desee, desde JSON a XML a HTML, binarios a imágenes y más allá. Riak S2 es para almacenamiento de objetos grandes cuando necesita almacenar archivos de tamaño terabyte o escala a petabytes de almacenamiento de objetos.


En sistemas heredados, los datos están organizados por tablas que son estructuras separadas y únicas. Dentro de estas tablas existen filas de datos organizados en columnas. Por el contrario, Riak tiene un modelo de datos mucho más simple. Un objeto es el elemento más grande y más pequeño de los datos. Como tal, la interacción con la base de datos se realiza recuperando o modificando todo el objeto.

MENSAJERÍA Y CHAT
Las bases de datos relacionales tradicionales no fueron diseñadas para manejar la variedad de datos no estructurados y la velocidad requerida para aplicaciones de mensajería y chat. Riak KV cumple estos retos y es fácil de operar a escala.


Riak KV proporciona la arquitectura de datos de alta latencia, altamente disponible, requerida por las modernas aplicaciones de mensajería y chat. El diseño sin maestro de Riak KV asegura que la escalabilidad de la base de datos esté diseñada desde el inicio del diseño.

CONTINUIDAD DEL NEGOCIO
La mayoría de las bases de datos funcionan a pequeña escala, pero ¿cómo se puede escalar, subir y bajar predecible y linealmente a medida que crecen los datos? Uno de los patrones de arquitectura más comunes para la replicación de clústeres múltiples es el mantenimiento de un clúster principal que proporciona tráfico y un clúster de copia de seguridad para la conmutación por error de emergencia. El mantenimiento de un clúster de copia de seguridad también puede ser un componente importante del cumplimiento normativo y / o asegurar la continuidad del negocio durante un evento adverso.


Riak KV Enterprise con Multi-Cluster Replication asegura la continuidad del negocio en caso de una interrupción. Riak KV tiene una innovadora arquitectura de base de datos que proporciona una funcionalidad de lectura y escritura rápida para los datos distribuidos a nivel mundial. Riak KV está diseñado para una configuración sin máster. Esto significa que los administradores pueden implementar varios clústeres de Riak KV y luego replicarlos para mantenerlos sincronizados. Si el Clúster A recibe una escritura, el Clúster A asegurará a su vez que la escritura se reproduzca en los Clústeres B - Z. Y lo hace rápidamente.

IoT / SENSOR / DATOS DEL DISPOSITIVO

Las aplicaciones empresariales recopilan datos de series temporales, lo que requiere que la agregación y el análisis sean útiles. Pero no es posible almacenar y analizar de manera óptima datos de series de tiempo con bases de datos tradicionales.


Los datos del sensor y del dispositivo entran en alta velocidad con una variedad de formatos de datos y en volumen masivo. Esto requiere una base de datos que pueda leer y escribir datos de series temporales rápidamente. Riak TS es una base de datos NoSQL altamente elástica y de alto rendimiento optimizada para datos de series de tiempo. 

Colocando los datos basados en el intervalo de tiempo, es más fácil ingerir, transformar, almacenar y analizar datos de sensores y dispositivos. Riak TS escala horizontalmente con hardware de productos para satisfacer volúmenes crecientes de datos. No hay necesidad de fragmentación de datos complejos.

METRICS / LOG ANALYTICS

Todo el mundo tiene una opinión, pero las mejores decisiones se basan en los datos. ¿Cómo puede utilizar registros y datos de métricas para tomar mejores decisiones de negocio? Los sistemas siempre han incluido datos de registro, pero el volumen, la velocidad y la complejidad de estos registros ha crecido exponencialmente a medida que los sensores y dispositivos IoT han proliferado. Ahora también estamos viendo un amplio crecimiento en el análisis de métricas. Estas métricas y archivos de registro requieren lecturas y escrituras rápidas, junto con la capacidad de recuperar datos mediante consultas de rango, todo ello al mismo tiempo que se mantiene rápido, fiable y escalable. Esto no es posible con las bases de datos relacionales tradicionales.


Las métricas y registros pueden llegar a una velocidad alta y una variedad de longitudes. Algunos son informativos y otros requieren acción inmediata. A menudo, se necesita un análisis complejo para determinar si se requiere acción. Algo que inicialmente parece ser informativo puede resultar ser un problema grave cuando los datos se agregan y analizan con el tiempo. Riak TS proporciona el alto rendimiento y la resiliencia necesarios para el análisis rápido de métricas y datos de registro. La co-localización de datos hace que sea rápido almacenar y analizar estos datos de series de tiempo semiestructuradas. Con Riak TS, puede ejecutar consultas de rango para enfocar su análisis en bloques de tiempo específicos a través de sistemas o dispositivos. Las consultas SQL hacen más rápido y fácil analizar sus datos.

ANÁLISIS DE DISPOSITIVOS

Datos, datos en todas partes! ¿Cómo habilitar ideas valiosas cuando y donde las necesita y detener el flujo de datos irrelevantes? Tradicionalmente, los datos se analizan en el núcleo de su red, pero con el crecimiento de los sensores y dispositivos IoT, los datos deben ser analizados más cerca de su fuente y agregados para el análisis de núcleo. Desde los cruceros hasta el monitoreo de la salud y la utilización del sistema, los análisis de punta crean una mejor experiencia de usuario y tiempos de respuesta más rápidos.

El análisis de dispositivos de borde debe ser rápido y fiable utilizando recursos mínimos. Esto requiere una base de datos altamente resiliente y fácil de operar a escala. Riak TS es una base de datos NoSQL de alto rendimiento y altamente elástica optimizada para el análisis en tiempo real de datos de series de tiempo. Agregue fácilmente capacidad a la demanda utilizando hardware de productos. Responder a lecturas y escrituras incluso en caso de fallas de hardware o cortes de red. Riak TS requiere menos recursos de hardware para la misma potencia computacional, por lo que es una opción ideal para el análisis de bordes. Con Riak TS, es fácil hacer análisis usando consultas de rango de SQL.

Optimización de los Parámetros de UNDO

A Partir de Oracle 9i, los segmentos de rollback pasan a llamarse Undo Logs. Tradicionalmente, la información de transacciones (UNDO) se almacenaba en Rollback segments hasta el COMMIT o ROLLBACK. Oracle9i permite la gestión automática de UNDO. El DBA para especificar cuánto tiempo debe mantenerse la información de UNDO, para prevenir los errores "snapshot too old" en consultas largas. Esto se hace mediante el parámetro UNDO_RETENTION. 
El valor por defecto es de 900 segundos (15 minutos), Y puedes cambiar este parámetro para garantizar que Oracle mantiene los registros de UNDO largos períodos de tiempo. En lugar de tener que definir y gestionar los segmentos de rollback, puedes simplemente definir un tablespace UNDO y dejar que se ORACLE se encargue de lo demás. En cuanto a la gestión automática de Undo es fácil. Todo lo que necesitas es crear un Tbs UNDO y poner el UNDO_MANAGEMENT = AUTO. Sin embargo vale la pena para ajustar los siguientes parámetros: 

• El tamaño del Tbs UNDO. 
• El Parámetro UNDO_RETENTION. 
• Calcular el UNDO_RETENTION para el Undo Tablespace. 

Puedes optar por asignar un determinado tamaño del tablespace UNDO y, a continuación, establecer el UNDO_RETENTION a un valor óptimo de acuerdo con el tamaño de UNDO y la actividad de la base de datos. Si su espacio en el disco es limitado y no quiere asignar más espacio del necesario para el Tbs Undo, esta es la forma de proceder. 
 La siguiente consulta le ayudará a optimizar el 
UNDO_RETENTION (Optimo) = UNDO SIZE Actual / DB_BLOCK_SIZE * UNDO_BLOCK_PER_SEQ 

Dado que estas consultas usan las estadísticas V$UNDOSTAT, ejecute las consultas sólo después de que la Base de datos lleve funcionando con UNDO para un importante y representativo periodo de tiempo.

Actual Undo Size

SELECT SUM(a.bytes) "UNDO_SIZE"
  FROM v$datafile a,
       v$tablespace b,
       dba_tablespaces c
 WHERE c.contents = 'UNDO'
   AND c.STATUS = 'ONLINE'
   AND b.name = c.tablespace_name
   AND a.ts# = b.ts#; 

Undo Blocks per Second

SELECT MAX(undoblks/((end_time-begin_time)*3600*24))
      "UNDO_BLOCK_PER_SEC"
  FROM v$undostat; 

DB Block Size

SELECT TO_NUMBER(value) "DB_BLOCK_SIZE [KByte]"
 FROM v$parameter
WHERE name = 'db_block_size'; 

Optimal Undo Retention

SELECT d.undo_size/(1024*1024) "ACTUAL UNDO SIZE [MByte]",
       SUBSTR(e.value,1,25) "UNDO RETENTION [Sec]",
       ROUND((d.undo_size / (to_number(f.value) *
       g.undo_block_per_sec))) "OPTIMAL UNDO RETENTION [Sec]"
  FROM (
       SELECT SUM(a.bytes) undo_size
          FROM v$datafile a,
               v$tablespace b,
               dba_tablespaces c
         WHERE c.contents = 'UNDO'
           AND c.STATUS = 'ONLINE'
           AND b.name = c.tablespace_name
           AND a.ts# = b.ts#
       ) d,
       v$parameter e,
       v$parameter f,
       (
       SELECT MAX(undoblks/((end_time-begin_time)*3600*24))
              undo_block_per_sec
         FROM v$undostat
       ) g
WHERE e.name = 'undo_retention'
  AND f.name = 'db_block_size'
/ 

Calcular el UNDO necesario para la actividad de la BBDD

SELECT d.undo_size/(1024*1024) "ACTUAL UNDO SIZE [MByte]",
       SUBSTR(e.value,1,25) "UNDO RETENTION [Sec]",
       (TO_NUMBER(e.value) * TO_NUMBER(f.value) *
       g.undo_block_per_sec) / (1024*1024) 
      "NEEDED UNDO SIZE [MByte]"
  FROM (
       SELECT SUM(a.bytes) undo_size
         FROM v$datafile a,
              v$tablespace b,
              dba_tablespaces c
        WHERE c.contents = 'UNDO'
          AND c.STATUS = 'ONLINE'
          AND b.name = c.tablespace_name
          AND a.ts# = b.ts#
       ) d,
      v$parameter e,
       v$parameter f,
       (
       SELECT MAX(undoblks/((end_time-begin_time)*3600*24))
         undo_block_per_sec
         FROM v$undostat
       ) g
 WHERE e.name = 'undo_retention'
  AND f.name = 'db_block_size'
/

¿Sabías que existía la herramienta ORAchk?

La herramienta de Oracle ORAchk incluye funciones EXAchks y RACcheck y reemplaza las herramientas más antiguas. Ya no es sólo una herramienta de base de datos, sino que también realiza comprobaciones sobre E-Business Suite Financials, el repositorio de Cloud Management para Enterprise Manager, GoldenGate y Sun Systems.

La utilidad ORAchk (Oracle Check) se conocía anteriormente como RACchk. En su encarnación más antigua, RACchk examinó la configuración del sistema Oracle RAC buscando las áreas que necesitaban mejoras. Oracle Corporation decidió extender la utilidad para incluir algo más que una base de datos Oracle y centrarse en toda la pila de software de Oracle. ORAchk ahora examina las siguientes áreas.

• Oracle Database (tanto RAC como de instancia única)
• Control de la nube de Enterprise Manager 12c
• Servidores Oracle Sun
• Oracle E-Business Suite

Independientemente del componente de software de Oracle que se esté examinando, ORAchk está analizando la configuración buscando problemas. Puede proporcionar un informe que muestre riesgos para la salud. Se recomienda que el administrador de la base de datos ejecute un informe antes y después de los cambios de configuración del software para comprender si esos cambios pueden causar problemas futuros. Dado que este libro es para el rendimiento de la base de datos Oracle RAC, sólo se discutirá el primer componente de Oracle en la lista anterior. Los otros 3 componentes de software están fuera del alcance de este libro.


La utilidad ORAchk se puede descargar de la Nota 1268927.1 de Oracle My Support. La descarga es un simple archivo zip. Después de descargar el archivo, utilice la utilidad OS unzip para extraer su contenido. La instalación se completa después de descomprimir el archivo. Ejecute el ejecutable orachk para iniciar el análisis. De forma predeterminada, orachk le pedirá que verifique la ubicación actual de Grid Infrastructure. A continuación, orachk verifica la equivalencia de usuario ssh.

Características de ORAchk:

• Escanea de forma proactiva los problemas conocidos más impactantes a través de todo su sistema, así como varias capas de su apilar Simplifica y optimiza la forma de investigar y analizar qué problemas conocidos presentan un riesgo para usted.
• La herramienta ligera funciona dentro de nuestro entorno; no se enviarán datos a Oracle..
• Los informes de alto nivel muestran los riesgos para la salud del sistema con la capacidad de profundizar en problemas específicos y entender sus resoluciones.
• Se puede configurar para enviar notificaciones por correo electrónico cuando detecta problemas.
• Administrador de recopilación, una aplicación complementaria Application Express proporciona una vista única de las colecciones en toda la empresa.
• ORAchk se expandirá en el futuro con un mayor impacto; controles en áreas de productos existentes y adicionales. 

Para obtener más información sobre la herramienta ORAchk, cómo descargarlo, qué hay de nuevo en ORAchk, lea MOS Nota 1268927.2. Si no tienes acceso a MOS, aquí hay una entrada de blog que describen bastante bien la herramienta:

•  ORAchk Health Checks For The Oracle Stack by Levi Pereira

Mejores prácticas de enmascaramiento de datos

Muchas organizaciones arriesgan inadvertidamente la información cuando rutinariamente copian datos de producción sensibles o regulados en entornos que no son de producción. Como resultado, los datos en el entorno de no producción se han convertido cada vez más en el blanco de los delincuentes y pueden ser robados. Al igual que las brechas de datos en entornos de producción, las violaciones de datos en entornos no productivos pueden causar millones de euros en sanciones y causar daños irreparables a la reputación y la marca.

Con Oracle Data Masking, la información sensible y valiosa puede ser reemplazada por valores realistas. Esto permite que los datos se utilicen con seguridad en no producción e incumplimiento con requisitos regulatorios como Sarbanes-Oxley, PCI DSS, HIPAA y en breve la GDPR.

Este artículo describe las mejores prácticas para implementar Oracle Data Masking para proteger la información confidencial en bases de datos Oracle y otras bases de datos heterogéneas como IBM DB2, Microsoft SQL Server.

Las empresas comparten datos de sus aplicaciones de producción con otros usuarios para una variedad de necesidades empresariales.

• Las empresas minoristas comparten datos de puntos de venta con los investigadores de mercado para analizar los patrones de compra de los clientes.
• Las organizaciones farmacéuticas o de salud comparten los datos de los pacientes con los investigadores médicos para evaluar la eficacia de los ensayos clínicos o los tratamientos médicos.
• Las empresas para mantenerse competitivas requieren una funcionalidad nueva y mejorada en las aplicaciones de producción existentes. Como resultado, los desarrolladores de aplicaciones requieren un entorno que imita cerca de la producción para crear y probar la nueva funcionalidad asegurando que la funcionalidad existente no se rompa.

Como resultado de lo anterior, las organizaciones copian datos confidenciales de clientes y consumidores en entornos que no son de producción y muy pocas compañías hacen algo para proteger estos datos, incluso cuando comparten con terceros.

Enmascarar datos en entornos no productivos.

Las organizaciones han tomado estas amenazas en serio y se han propuesto abordar estas cuestiones tan pronto como sea posible conocer las ramificaciones. A pesar de esto, la idea de eliminar información sensible del entorno de no producción parece ser sencilla, pero puede plantear serios desafíos en varios aspectos.

Identificación de información confidencial.

• ¿Qué define la información sensible?
• ¿Dónde reside?
• ¿Cómo se hace referencia?

El desafío también se convierte en mantener el conocimiento de metadatos de la arquitectura de la aplicación a lo largo de su ciclo de vida.

El proceso de enmascaramiento ha de ser tal que la integridad de la aplicación se vuelve primordial. Como ejemplo, enmascarar una parte de la dirección de un cliente, como zip sin considerar la ciudad y el estado, puede hacer que la aplicación sea inutilizable. Por lo tanto el desarrollo o la prueba se vuelven si no imposible, no confiable.La auditoría es otro desafío que se considera seriamente. Saber quién cambió qué y cuándo se convierte en un importante requisito de control de negocios para demostrar el cumplimiento de las regulaciones y leyes.

Para implementar estos controles, se ha de instaurar:

El desafío se convierte en separaciones de deberes, permisos basados en roles y la capacidad de reportar sobre estas actividades.

Las bases de datos se están volviendo muy grandes y la frecuencia de solicitudes para un entorno seguro no relacionado con la producción ha aumentado drásticamente a lo largo de los años. La razón de este aumento es que las empresas desarrollen aplicaciones nuevas y mejores que presten servicios a sus clientes a un ritmo más rápido para mantenerse competitivas. Un proceso de enmascaramiento debe tener un rendimiento aceptable y confiabilidad.

Y, finalmente, tener una solución flexible que puede evolucionar con la aplicación y extenderse a otras aplicaciones dentro de una empresa se convierte en un reto importante para abordar.

La solución más común: scripts de base de datos. A primera vista, una ventaja del enfoque de scripts de base de datos parecería que se refieren específicamente a las necesidades de privacidad de una base de datos específica para la que fueron diseñados. Pueden incluso haber sido ajustados por un DBA para correr en su más rápido

Veamos los problemas con este enfoque.

• Reutilización: No hay capacidades comunes en un script que pueden ser fácilmente apalancadas en otras bases de datos.
• Transparencia: Como los scripts tienden a ser programas monolíticos, los auditores no tienen transparencia en los procedimientos de enmascaramiento utilizados en los scripts. Los auditores encontrarían extremadamente difícil ofrecer cualquier recomendación sobre si el proceso de enmascaramiento incorporado en un guión es seguro y ofrece a la empresa el grado apropiado de protección.
• Mantenimiento: cuando se actualizan estas aplicaciones empresariales, se pueden agregar nuevas tablas y columnas que contienen datos confidenciales como parte del proceso de actualización. Con un enfoque basado en secuencias de comandos, todo el guión tiene que ser revisado y actualizado para acomodar nuevas tablas y columnas agregadas como parte de un parche de aplicación o una actualización.

Implementación de la máscara de datos

Con estos desafíos empresariales en mente, Oracle ha desarrollado un enfoque integral de 4 pasos para implementar el enmascaramiento de datos a través de Oracle Data Masking Pack llamado: Find, Assess, Secure y Test (F.A.S.T). Estos pasos son:

• Buscar: Esta fase implica la identificación y catalogación de datos sensibles o regulados en toda la empresa. Normalmente llevado a cabo por analistas de negocios o de seguridad, el objetivo de este ejercicio es crear una lista exhaustiva de elementos de datos confidenciales específicos de la organización y descubrir las tablas, columnas y relaciones asociadas a las bases de datos empresariales que contienen los datos confidenciales.

• Evaluar: En esta fase, los desarrolladores o DBAs en conjunto con los analistas de negocios o de seguridad identifican los algoritmos de enmascaramiento que representan las técnicas óptimas para reemplazar los datos sensibles originales. Los desarrolladores pueden aprovechar la biblioteca de enmascaramiento existente o ampliarla con sus propias rutinas de enmascaramiento.

• Seguro: Este y el siguiente paso pueden ser iterativos. El administrador de seguridad ejecuta el proceso de enmascaramiento para proteger los datos confidenciales durante las pruebas de enmascaramiento. Una vez que el proceso de enmascaramiento ha finalizado y se ha verificado, el DBA entrega el entorno a los probadores de aplicaciones.

• Prueba: En el paso final, los usuarios de producción ejecutan procesos de aplicación para probar si los datos enmascarados resultantes pueden ser entregados a otros usuarios que no producen. Si las rutinas de enmascaramiento necesitan ser ajustadas aún más, el DBA restaura la base de datos al estado pre-enmascarado, corrige los algoritmos de enmascaramiento y vuelve a ejecutar el proceso de enmascaramiento.

La base de datos Oracle y GDPR, una introducción

El Reglamento General de Protección de Datos (Reglamento de la UE 2016/679) es el nuevo marco jurídico de la UE que rige el uso de los datos personales. Este texto deroga la actual Directiva 95/46/CE de protección de datos y sustituye a las leyes de protección de datos nacionales existente (En España, la Ley 15/1999 de Protección de Datos). El texto será aplicable en todos los estados de la Unión Europea de desde 25 de mayo de 2018.

La Unión Europea (UE) introdujo su norma de protección de datos hace 20 años a través de la Directiva 95/46 / CE sobre protección de datos. Debido a que una Directiva permite a los Estados miembros un cierto margen de maniobra al aplicarla en el Derecho nacional, Europa ha terminado con un mosaico de diferentes leyes de privacidad. Además, el aumento de las brechas de seguridad, los rápidos avances tecnológicos y la globalización en los últimos 20 años ha traído nuevos retos para la protección de los datos personales. En un esfuerzo por abordar esta situación, la UE desarrolló el Reglamento General de Protección de Datos (GDPR).

¿Qué debemos hacer ahora para prepararnos para el GDPR?

• Implementar medidas de seguridad desde el diseño y por defecto en todos los procesos del tratamiento mediante procedimientos y sistemas que garanticen la protección de datos y el ejercicio de los derechos de los interesados.

• Realizar un análisis de los riesgos que atañen al tratamiento y prevenir su impacto para garantizar los derechos y las libertades de las personas que puedan ser afectadas, asumiendo que la protección de datos es mucho más que un cumplimiento formal y documental.

¿Qué puede hacer Oracle para prepararnos para el GDPR?

El GDPR es aproximadamente de tres a cuatro veces la longitud de la Ley de Protección de Datos (LOPD) de  1998 que está reemplazando.

Los requisitos para las bases de datos son:

• Descubrimiento
• Clasificación
• Enmascaramiento
• Supervisión
• Informes de auditoría
• Respuesta y notificación de incidentes

La sanción máxima por incumplimiento es del 4% del ingreso anual o de 20 millones de euros, el que sea mayor. Pueden aplicarse multas inferiores al 2% para las infracciones administrativas, como no realizar evaluaciones de impacto o notificar a las autoridades o particulares en caso de incumplimiento de los datos. Esto pone las penas de protección de datos en la misma categoría que la anticorrupción o el cumplimiento de la competencia.

Lo que los DBA deben comenzar ahora es cuenta e identificar el 100% de los datos privados ubicados en todas las bases de datos.

Hay cuatro categorías principales en las que participará DBA. 

1. Evaluar
2. Evitar
3. Detectar
4. Maximizar la protección

Las principales bases legales para el procesamiento de datos son el consentimiento y la necesidad. Los datos pueden ser reconocidos como una necesidad si:

• Se relaciona con la ejecución de un contrato
• Ilustra el cumplimiento de una obligación legal
• Protege los intereses vitales del titular de los datos u otra persona
• Se relaciona con una tarea que es de interés público
• Se utiliza para fines de interés legítimo perseguido por el responsable del tratamiento o por un tercero (en caso de que los derechos de la persona afectada lo anulen)

Las solicitudes de acceso de los sujetos de los datos deben ser respondidas dentro de un mes y sin cargo alguno. Esta es una nueva legislación dentro del GDPR y el mismo plazo de un mes se aplica a la rectificación de datos inexactos.

Las notificaciones de infracción deben hacerse dentro de las 72 horas siguientes a la toma de conciencia. Si no se cumple este plazo, se puede imponer una multa de 10 millones de euros, o el 2% del volumen de negocios global. Un incumplimiento es cualquier falla de seguridad que conduzca a la destrucción, pérdida, alteración, divulgación no autorizada o acceso a datos personales. Las autoridades supervisoras deben ser notificadas si una violación resulta en un riesgo para los derechos y libertades de las personas.

Los datos almacenados de forma encriptada o seudónima no se consideran datos personales y quedan fuera del ámbito de aplicación de estas nuevas normas. A pesar de esto, los datos cifrados y considerados seguros utilizando la tecnología de hoy en día pueden volverse legibles en el futuro. Por lo tanto vale la pena considerar el formato que preserva la encriptación / o usar pseudónimos que los hacen anónimos, pero permite al procesamiento seleccionado de esos datos.

¿Qué es CPU, PSU, SPU?

Esta es una pequeña entrada para explicar ciertos conceptos y terminologia de la herramienta de actualización de las bases de datos, Oracle Critical Patch.

Todo comenzó en enero de 2005 con Actualizaciones críticas de parches, CPU. A continuación, las Actualizaciones de conjuntos de parches (PSU) se agregaron como parches acumulativos que incluían correcciones de prioridad y arreglos de seguridad. A partir de la actualización de revisión crítica de octubre de 2012, Oracle ha cambiado la terminología para diferenciar mejor los tipos de parches. Esta terminología se utilizará para la base de datos Oracle, Enterprise Manager, Fusion Middleware y WebLogic.

Actualización de revisión crítica (CPU) ahora se refiere a la liberación general de revisiones de seguridad cada trimestre en lugar de la revisión de seguridad de base de datos acumulativa para el trimestre. Piense en la CPU como la versión trimestral general y no como un solo parche.

Patch Set Updates (PSU) son los mismos parches acumulativos que incluyen las correcciones de seguridad y las correcciones de prioridad. La clave con las PSU es que son actualizaciones menores de la versión (por ejemplo, 11.2.0.1.1 a 11.2.0.1.2). Una vez que se aplique una PSU, sólo se pueden aplicar PSU en trimestres futuros hasta que la base de datos se actualice a una nueva versión base.

La terminología de Actualización de revisión de seguridad (SPU) se presenta en la actualización de revisión crítica de octubre de 2012 como el término para el parche de seguridad trimestral. Los parches SPU son los mismos que los parches anteriores de la CPU, sólo un nuevo nombre. Para la base de datos, las SPU no se pueden aplicar una vez que se hayan aplicado PSU hasta que la base de datos se actualice a una nueva versión base.

Bundle Patches son los parches trimestrales para Windows y Exadata que incluyen tanto los parches de seguridad trimestrales como las revisiones recomendadas.

Etiqueta:

El nombre de un conjunto de cambios (por ejemplo, la fijación de un error) en el código fuente; la salida de una etiqueta es un conjunto de archivos C (* .c, * .h etc)

Conflicto. Dos o más correcciones de errores que modifican los mismos archivos de código fuente; si este es el caso, sólo se puede aplicar uno, de lo contrario el código de las correcciones tendrá que ser "fusionado" para producir una nueva etiqueta

Interim Patch. Este es el nombre oficial para un parche único. Solución de errores única.

Merge Patch:Esta es una combinación de etiquetas; si por ejemplo tiene dos correcciones de errores que tocan los mismos archivos, entonces tendría que tener esas revisiones fusionadas, produciendo un nuevo parche con una nueva etiqueta

Overlay Patch: Cuando un parche interino de una sola vez entre en conflicto con una PSU, se requiere un parche de superposición. Esto es básicamente una fusión del parche que desea y la PSU.

Overlay PSU: Durante el ciclo de vida de un patchset, las PSU normalmente se publicarán cada trimestre. A medida que el patchset alcanza su madurez, se podría esperar que haya errores menos críticos que puedan ser considerados como candidatos para su inclusión en PSU.

En algún momento el número de correcciones de errores incluidas en cada PSU alcanzará un número suficientemente bajo que ya no se considera que vale la pena hacer la PSU acumulativa.

En este punto, la PSU anterior se convierte en una línea de base y todas las futuras PSU se liberan como "superposición de PSU".

Si quieres ahondar mas en esta nomenclatura consulta la siguiente nota del Oracle Metalink, sí lo sigo llamando ¡así! : Nueva Nomenclatura de Patches para Productos Oracle [ID 1430923.1]

Usar Ansible para realizar tareas de administrador de bases de datos.

La orquestación de las tecnologías de la información se ha vuelto importante con el aumento de la escala web (ampliación y descenso de aplicaciones mediante la adición de máquinas virtuales a tareas de uso intensivo de recursos de escala horizontal), para configurar las máquinas recién agregadas sin intervención manual y la gente empieza a usarlo para usarlo para algo más que tareas de aprovisionamiento de máquinas virtuales para aplicaciones web.

El proyecto Ansible decidió hacerlo radicalmente diferente a todos los demás motores. Es diferente en el sentido de que se anuncia como simple, sin agente y poderoso.

Sencillo.

La sencillez es un gran objetivo. Para aquellos de vosotros que habéis trabajado con la configuración / motores de orquestación, hay una curva de aprendizaje pronunciada. Es difícil obtener los principios básicos en la cabeza. Para ser honesto, Ansible también me tomó un tiempo demasiado, para comprender los principios básicos, y obtener la imagen correctamente en mi cabeza. Sin embargo, después de haber trabajado con cfengine comparándolo con los libros de juicio de Ansible, que son los guiones para hacer las cosas en los objetivos, es un soplo de aire fresco. Playbooks son tan limpias que (casi) se puede leer y entender como Inglés simple.

Sin agente

Aquí es donde Ansible es verdaderamente diferente a cualquiera de las otras herramientas de configuración / orquestación. Ansible no requiere ninguna instalación de agente en los objetivos. La siguiente pregunta obvia entonces es: ¿cómo puede esto funcionar? Bueno, muy sencillo: Ansible utiliza ssh para conectarse al host y ejecuta comandos a través del shell. Dicho esto, requiere un poco más de detalle; Ansible utiliza python en el host remoto para su ejecución normal. Sin embargo, puede utilizarlo sin python, por ejemplo para configurar el host para el modo de uso normal Ansible que requiere python y el módulo simple-json.

Esto es realmente importante, y lo convierte en un excelente ajuste para mi trabajo diario como consultor de TI.

Poderoso.

Ansible es poderoso en la forma en que usted puede hacer las tareas de configuración y orquestación de una manera sencilla y limpia.

En resumen, creo que ser sin agente es la verdadera característica asesina aquí. Todos los otros motores de configuración / orquestación requieren que configure y configure una conexión cliente-servidor fija e instale un proceso (demonio) y un servidor central. La autenticación de contraseña ssh o infraestructura de clave pública se puede utilizar.

Debido a que no hay ningún daemon para instalar, puede ejecutar sus playbooks creados en todas partes. Así que en lugar de una configuración fija de cliente, puede crear libros de juego para realizar tareas de rutina y repetirla en varios sitios.

Instalación: añadir EPEL e instalar ansible.

Si usas uno de los clones de RedHat Enterprise Linux (yo uso Oracle Linux), simplemente tiene que agregar el repositorio EPEL (Extra Packages for Enterprise Linux) a su lista de fuentes yum y ejecutar:

 # yum install ansible

Primeros pasos.

Una de las primeras cosas que hago, es crear un directorio para un típico 'proyecto' ansible. Proyecto significa un conjunto de tareas que desea hacer a un conjunto de hosts aquí. A continuación, creo un archivo llamado 'hosts' que es la lista de hosts que desea utilizar para ejecutar tareas en. De forma predeterminada, Ansible busca en / etc / ansible / hosts. En este caso, pongo una sola máquina en ella (una VM de prueba), pero puede ser una lista de máquinas (direcciones IP o nombres de host).

$ cat hosts
192.168.101.2

De hecho, puede crear grupos en el archivo hosts en el "estilo ini". Pero acabo de poner un anfitrión en este ejemplo.
Lo siguiente es comprobar si Ansible lee el archivo correctamente. Esto se hace de la siguiente manera:

$ ansible todos los hosts -i --list-hosts
    192.168.101.2

Bueno, esto significa que Ansible funcionará en este host si se invoca. La siguiente cosa lógica (normalmente cuando está en un nuevo entorno de cliente para comprobar si puede llegar a los hosts):

$ ansible all -i hosts -m ping
192.168.101.2 | FALLA => FALLA: Error en la autenticación.

Ping puede ser un poco engañoso para algunas personas. Lo que ping hace aquí (-m significa módulo), está tratando de conectarse al host sobre ssh, e iniciar sesión. Como no especificó un usuario, utilizó el nombre de usuario del usuario actual en la máquina, que es 'ansible '. Un usuario 'ansible' normalmente no existe en un servidor normal (y no es necesario o debe ser creado), y tampoco en mi servidor de prueba. Así que falló, como decía el mensaje, en la autenticación.

La máquina virtual de prueba es un servidor Linux 6 instalado (OL) básico. Esto significa que sólo hay un usuario: root.
Por lo tanto, vamos a especificar la raíz del usuario como usuario:

$ ansible all -i hosts -m ping -u raíz
192.168.101.2 | FALLA => FALLA: Error en la autenticación.

La autenticación falló de nuevo. Y debería! Qué está haciendo, está intentando abrir una sesión como raíz, y no hemos dado ninguna contraseña, ni he puesto la llave pública de mi usuario local en el archivo authorised_keys alejado. Así que no hay manera de que esto podría funcionar. Esto también suele ser el estado cuando desea hacer cosas con un sistema de cliente "fresco". Vamos a agregar la opción '-k' (preguntar contraseña ssh), y ejecutar de nuevo:

$ ansible all -i hosts -m ping -u root -k
SSH password:
192.168.101.2 | success >> {
    "changed": false,
    "ping": "pong"
}

Para continar: Ahora pide una contraseña, que he llenado, a continuación, lista el anfitrión y el estado: el éxito. Durante esta ejecución, no hubo cambios en el host remoto, y el comando ping dio como resultado un pong (al igual que la respuesta de ping ICMP).
Con lo que hemos aprendido ahora, podemos hacer cosas como esta:

$ ansible all -i hosts -u root -k -a "ifconfig"
SSH password:
192.168.101.2 | success | rc=0 >>
eth0      Link encap:Ethernet  HWaddr 00:0C:29:14:65:ED
          inet addr:192.168.39.145  Bcast:192.168.39.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fe14:65ed/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:47 errors:0 dropped:0 overruns:0 frame:0
          TX packets:25 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:6293 (6.1 KiB)  TX bytes:2594 (2.5 KiB)

eth1      Link encap:Ethernet  HWaddr 00:0C:29:14:65:F7
          inet addr:192.168.101.2  Bcast:192.168.101.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fe14:65f7/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:188 errors:0 dropped:0 overruns:0 frame:0
          TX packets:112 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:142146 (138.8 KiB)  TX bytes:15545 (15.1 KiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

¿Te resulta familiar? Si eres DBA de Exadata claro que sí, esto reproduce parte de la funcionalidad de dcli (aunque dcli está dirigido a ejecutar tareas simples a un grupo de hosts, mientras que Ansible está dirigido a la configuración y orquestación de la empresa).

Playbooks

Ahora vamos a progresar con los Playbooks. Estos Playbooks de Ansible es donde reside la verdadera fuerza de esta tecnología. Permite especificar las tareas que se deben ejecutar en los hosts remotos y crear secuencias de tareas y tomar decisiones basadas en el resultado de las tareas para una ejecución posterior. Permítanme mostrarles un simple libro de jugadas, y guiarlo a través de él:

- hosts: all
  gather_facts: no
  remote_user: root
  tasks:

  - name: upgrade all packages
    yum: name=* state=latest

  - name: install python-selinux
    yum: name=libselinux-python state=installed

  - name: add public key to authorized_key file of root
    authorized_key: user=root state=present key="{{ lookup('file','/home/ansible/.ssh/id_rsa.pub') }}"

Como se puede ver, este es un playbook con tres tareas:

• Actualizar todos los paquetes
• Instalar libselinux-python
• Agregar mi clave pública (local) al archivo de clave autorizado de root (para permitir el acceso sin contraseña).

La línea 1 muestra tres guiones, lo que significa el inicio de un documento YAML.
La línea 2 comienza con un solo guión, que indica una lista. Hay un guión en este nivel de indentación, por lo que es una lista de uno. Los campos de este miembro son hosts, gather_facts y tasks. Tareas tiene su propia lista (la mente del nivel de indención, que es importante). Los campos son pares clave / valor, con la separación indicada por los dos puntos (:). El primer campo es 'hosts', con el valor 'all'. Esto significa que todos los hosts en el archivo de hosts se utilizan para este libro de jugadas. No creo que sea difícil imaginar lo útil que puede ser especificar un grupo / clase de servidores en los que el libro de jugadas puede funcionar. El siguiente es 'gather_facts'. Una ejecución de libro de jugadas normal reúne primero una gran cantidad de información de todos los hosts que va a ejecutar antes de la ejecución. Éstos se pueden utilizar durante la ejecución del libro de jugadas. Siguiente 'remote_user'. Esto indica con qué usuario ansible va a iniciar sesión, por lo que no tenemos que especificarlo en la línea de comandos. Luego vemos 'tareas' para indicar la lista de tareas que se deben ejecutar en los hosts.


Es fácil ver que tenemos tres tareas. Lo que es extremadamente importante, es la identación de esta lista. El nombre no es obligatorio, pero facilita la lectura si se asignan nombres útiles a las tareas y se mostrarán cuando se ejecute el libro de jugadas. La primera tarea tiene el nombre 'actualizar todos los paquetes'. El siguiente campo muestra que la clave es 'yum' indicando que está haciendo uso del módulo yum. Esta clave tiene dos valores: name = *, que significa todos los 'todos los paquetes', y state = latest, lo que significa que queremos que todos los paquetes estén en la última versión. Esto significa que este comando es el equivalente de 'yum update'.

La segunda tarea se llama 'install python-selinux'. Hace uso del módulo del yum otra vez, y se explica por sí mismo, instala el paquete libselinux-python. Estos paquetes son necesarios para trabajar en un host que tiene selinux habilitado en cosas que están protegidas por selinux.

La siguiente tarea se llama 'agregar clave pública al archivo de raíz autorizada'. Se está utilizando el módulo authorized_key. Este módulo requiere un parámetro 'clave', para el cual usamos la función de búsqueda para buscar la clave pública local (!), Del usuario con el que ejecuto ansible, que es 'ansible'. 'Estado = presente' significa que queremos que esta clave esté presente; 'Presente' es el valor por defecto, por lo que no fue necesario ponerlo. Siguiente 'usuario = root': queremos que la clave pública se agregue al archivo authorized_keys de la raíz del usuario.


Por supuesto, estas tareas se pueden ejecutar utilizando el ejecutable 'ansible' como tareas individuales. Para mostrar la importancia de la instalación del módulo libselinux-python en un host con selinux habilitado (que es el estado de selinux en una nueva máquina Oracle Linux instalada), ejecute la tarea usando el módulo authorized_key:

$ ansible all -i hosts -k -u root -m authorized_key -a "user=root state=present key=\"{{ lookup('file','/home/ansible/.ssh/id_rsa.pub') }}\""
SSH password:
192.168.101.2 | FAILED >> {
    "failed": true,
    "msg": "Aborting, target uses selinux but python bindings (libselinux-python) aren't installed!"
}

Claro, ¿no? El anfitrión es selinux protegido. Ahora, vamos a ejecutar la instalación del paquete libselinux como una sola tarea, y luego agregamos nuestra clave pública al archivo authorized_key de root:

$ ansible all -i hosts -k -u root -m yum -a "name=libselinux-python state=installed"
SSH password:
192.168.101.2 | success >> {
    "changed": true,
    "msg": "",
    "rc": 0,
    "results": [
        "Loaded plugins: security\nSetting up Install Process\nResolving Dependencies\n--> Running transaction check\n---> Package libselinux-python.x86_64 0:2.0.94-5.3.el6_4.1 will be installed\n--> Finished Dependency Resolution\n\nDependencies Resolved\n\\n Package             Arch     Version     Repository Size\n\nInstalling:\n libselinux-python   x86_64   2.0.94-5.3.el6_4.1      public_ol6_latest   201 k\n\nTransaction Summary\n\nInstall       1 Package(s)\n\nTotal download size: 201 k\nInstalled size: 653 k\nDownloading Packages:\nRunning rpm_check_debug\nRunning Transaction Test\nTransaction Test Succeeded\nRunning Transaction\n\r  Installing : libselinux-python-2.0.94-5.3.el6_4.1.x86_64  1/1 \n\r  Verifying  : libselinux-python-2.0.94-5.3.el6_4.1.x86_64   1/1 \n\nInstalled:\n  libselinux-python.x86_64 0:2.0.94-5.3.el6_4.1\n\nComplete!\n"
    ]
}
$ ansible all -i hosts -k -u root -m authorized_key -a "user=root state=present key=\"{{ lookup('file','/home/ansible/.ssh/id_rsa.pub') }}\""
SSH password:
192.168.101.2 | success >> {
    "changed": true,
    "key": "ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAliR905hxLnsOCRlOGnmN0H9dGH4NPV88ySC6GMv0KNnU7FfCXYE51Bkk97p2IWFsPhYO9qJDyAFxRm/lia1IZRDpCFcKKKMh5eXmEJC5XSrHWFdmGZRlFcS3VQ3rpCIyU3qFM6xMazh3JHKKEtE1J6nvw/hW3slY9G/6VoJ8CzpfeQMLDOdVXUIcZXqtCPuIEDBQ7yjfMzTGz+hEmz7ImbLaUyB4MDGrDnl33L8mkBEVYu8RrwgBcagDQSiQKnIca/EL45eX/74NG1e/6vxZkHZJz/W0ak4KD+o9vF4ikz0bdrGPMZ5gRYXWoSSHrVA+Rqk8A93qBXNKUUkzGoQYTQ== ansible@ansiblevm.local",
    "key_options": null,
    "keyfile": "/root/.ssh/authorized_keys",
    "manage_dir": true,
    "path": null,
    "state": "present",
    "unique": false,
    "user": "root"
}

Tal vez su cliente no quiere que almacene sus llaves en sus servidores. Es fácil hacer lo contrario y quitar la llave del archivo authorized_key:

$ ansible all -i hosts -u root -m authorized_key -a "user=root state=absent key=\"{{ lookup('file','/home/ansible/.ssh/id_rsa.pub') }}\""
192.168.101.2 | success >> {
    "changed": true,
    "key": "ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAliR905hxLnsOCRlOGnmN0H9dGH4NPV88ySC6GMv0KNnU7FfCXYE51Bkk97p2IWFsPhYO9qJDyAFxRm/lia1IZRDpCFcKKKMh5eXmEJC5XSrHWFdmGZRlFcS3VQ3rpCIyU3qFM6xMazh3JHKKEtE1J6nvw/hW3slY9G/6VoJ8CzpfeQMLDOdVXUIcZXqtCPuIEDBQ7yjfMzTGz+hEmz7ImbLaUyB4MDGrDnl33L8mkBEVYu8RrwgBcagDQSiQKnIca/EL45eX/74NG1e/6vxZkHZJz/W0ak4KD+o9vF4ikz0bdrGPMZ5gRYXWoSSHrVA+Rqk8A93qBXNKUUkzGoQYTQ== ansible@ansiblevm.local",
    "key_options": null,
    "keyfile": "/root/.ssh/authorized_keys",
    "manage_dir": true,
    "path": null,
    "state": "absent",
    "unique": false,
    "user": "root"
}

Por favor, no especificé '-k' en la línea de comandos para enviar una contraseña: en el paso anterior añadimos nuestra clave, para que podamos acceder a nuestro host usando nuestra clave pública. Otra cosa extremadamente importante es 'cambiado'. 'Changed' indica si la tarea realmente cambió algo en el servidor de destino.

He corrido sola tarea hasta ahora, he cambiado el estado de mi VM de prueba de nuevo a su estado antes de empezar a cambiar con ansible (mediante la eliminación del paquete libselinux utilizando 'ansible todo-i hosts -k -u root -m yum -a "Nombre = libselinux-python state = ausente" '


Vamos a ejecutar la playbook descrita anteriormente, el resultado es:

$ ansible-playbook -i hosts -k linux_setup_example.yml
 [WARNING]: The version of gmp you have installed has a known issue regarding
timing vulnerabilities when used with pycrypto. If possible, you should update
it (ie. yum update gmp).

SSH password:

PLAY [all] ********************************************************************

TASK: [upgrade all packages] **************************************************
changed: [192.168.101.2]

TASK: [install python-selinux] ************************************************
changed: [192.168.101.2]

TASK: [add public key to authorized_key file of root] *************************
changed: [192.168.101.2]

PLAY RECAP ********************************************************************
192.168.101.2              : ok=3    changed=3    unreachable=0    failed=0


Ahora en este punto puede ser que pienses: Lo consigo, pero éstas son todas las tareas bastante simples, no es especial en absoluto. Bueno, ahora vamos a describir un caso real que muestra totalmente lo que la importancia de usar esto es, incluso en una sola máquina, pero aún más cuando tienes un gran grupo de servidores que tienes que administrar.

El siguiente ejemplo es una playbook creada para aplicar PSU (Actualizaciones del conjunto de parches) a una Oracle 11.2.0.4. Todavía es bastante simple, sólo se aplica PSU3 al home de Oracle, totalmente automático, ya es bueno tener automatizado mucho trabajo para una sola home, y ahorra un montón de horas (osea: mucho dinero), y te ahorra de error humano.

---
- hosts: all
  vars:
    u01_size_gb: 1
    tmp_size_gb: 1
    oracle_base: /u01/app/oracle
    oracle_home: /u01/app/oracle/product/11.2.0.4/dbhome_1
    patch_dir: /u01/install
  remote_user: oracle
  tasks:

  - name: check u01 free disk space
    action: shell df -P /u01 | awk 'END { print $4 }'
    register: u01size
    failed_when: u01size.stdout|int < {{ u01_size_gb }} * 1024 * 1024

  - name: check tmp free disk space
    action: shell df -P /tmp | awk 'END { print $4 }'
    register: tmpsize
    failed_when: tmpsize.stdout|int < {{ tmp_size_gb }} * 1024 * 1024

  - name: create directory for installation files
    action: file dest={{ patch_dir }} state=directory owner=oracle group=oinstall

  - name: copy opatch and psu
    copy: src=files/{{ item }} dest={{ patch_dir }} owner=oracle group=oinstall mode=0644
    with_items:
     - p6880880_112000_Linux-x86-64.zip
     - p18522509_112040_Linux-x86-64.zip
     - ocm.rsp

  - name: install opatch in database home
    action: shell unzip -oq {{ patch_dir }}/p6880880_112000_Linux-x86-64.zip -d {{ oracle_home }}

  - name: unzip psu patch
    action: shell unzip -oq {{ patch_dir }}/p18522509_112040_Linux-x86-64.zip -d {{ patch_dir }}

  - name: patch conflict detection
    action: shell export ORACLE_HOME={{ oracle_home }}; cd {{ patch_dir }}/18522509; $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph ./
    register: conflict_detection
    failed_when: "'Prereq \"checkConflictAgainstOHWithDetail\" passed.' not in conflict_detection.stdout"

  - name: apply psu
    action: shell export ORACLE_HOME={{ oracle_home}}; cd {{ patch_dir }}/18522509; $ORACLE_HOME/OPatch/opatch apply -silent -ocmrf {{ patch_dir }}/ocm.rsp
    register: apply_psu
    failed_when: "'Composite patch 18522509 successfully applied.' not in apply_psu.stdout"

  - name: clean up install directory
    file: path={{ patch_dir }} state=absent

Espero que esto demuestre lo que Ansible puede ser para un consultor. Este tipo de herramienta es simplemente obligatorio si tienes un entorno con más de aproximadamente diez a veinte servidores para administrar. Ansible puede utilizarse incluso si la organización no quiere dedicar tiempo a la implementación de una herramienta de configuración.