Monitorización de índices en base de datos Oracle: El mal necesario

Para aquellos que no están familiarizados con él, monitorizar índices es la forma de la base de datos Oracle de rastrear si se está usando un índice, lo que le permite saber si es necesario o no. O sea, como vengo a decir normalmete si "el índice se ha ido a Parla"

Dos cosas para tener en cuenta:

• No siempre marca un índice como se usa, incluso si se usa. Si no se utiliza en un plan de ejecución, pero se utiliza para aplicar una clave externa o una restricción única, no se marcará como se usa.
• La vista utilizada para ver el uso del índice es específica del esquema. Es posible que esté supervisando índices, pero los índices no se mostrarán en v$object_usage a menos que inicie sesión como propietario del esquema. Es mejor ir directamente a la consulta subyacente para ver todos los índices supervisados (consultar más abajo).

Dado que la monitorización de un índice tiene un costo muy bajo, tiene sentido activarlo para todos los índices candidatos. Los índices de FK e índices únicos funcionan, incluso si no se utilizan en los planes de ejecución, por lo que no son candidatos para descartar. Aquí está la consulta para obtener todos los índices non-unique, non-FK, se asume que no hay PK concatenadas, (Por Tutatis!) si eso ocurre, la consulta se vuelve más complicada:

SELECT 'ALTER INDEX '||ic.index_name||' MONITORING USAGE;'
  FROM all_ind_columns ic, all_indexes i
 WHERE i.uniqueness = 'NONUNIQUE' --no monitoriza índices únicos
   AND i.table_owner = 'NOMBRE_ESQUEMA'
   AND ic.index_owner = i.owner
   AND ic.index_name = i.index_name
   AND ic.position = 1
   AND NOT EXISTS (SELECT 'x' --No monitoriza índices en FK 
                     FROM all_cons_columns cc, all_constraints c
                    WHERE ic.table_name = cc.table_name
                      AND ic.column_name = cc.column_name
                      AND c.constraint_name = cc.constraint_name
                      AND c.constraint_type IN ('R'));

Aquí está la consulta para ver los objetos monitoreados si no se ha iniciado sesión como propietario del esquema:

select d.username, io.name, t.name,
       decode(bitand(i.flags, 65536), 0, 'NO', 'YES'),
       decode(bitand(ou.flags, 1), 0, 'NO', 'YES'),
       ou.start_monitoring,
       ou.end_monitoring 
from sys.obj$ io, sys.obj$ t, sys.ind$ i, sys.object_usage ou,
     dba_users d
where io.owner# = d.user_id
  AND d.username = 'SCHEMA_OWNER_HERE'
  and i.obj# = ou.obj#
  and io.obj# = ou.obj#
  and t.obj# = i.bo#;

Y aquí hay un ejemplo de monitorización de índice en acción, incluido el uso del índice exclusivo que no se marca:

CREATE TABLE test_monitoring AS SELECT level id, dbms_random.value(1,1000) value FROM dual CONNECT BY LEVEL <= 5000;

Table created.

CREATE UNIQUE INDEX test_monitoring_idx ON test_monitoring(id);

Index created.

ALTER INDEX test_monitoring_idx MONITORING USAGE;

Index altered.

Forzamos el índice para la aplicación de PK, este no marca el índice como usado:

INSERT INTO test_monitoring VALUES (100,0);
INSERT INTO test_monitoring VALUES (100,0)
*
ERROR at line 1:
ORA-00001: unique constraint (RAFA.TEST_MONITORING_IDX) violated 

SELECT index_name, used FROM v$object_usage WHERE index_name = UPPER('test_monitoring_idx');

INDEX_NAME                     USE                                              
------------------------------ ---                                              
TEST_MONITORING_IDX            NO                                               

Pero ejecutamos una sentencia "Select" que usará el índice

SELECT * FROM test_monitoring WHERE id = 100;

        ID      VALUE                                                           
---------- ----------                                                           
       100   255.5571                                                           
Y ahora el índice aparece como usado:

SELECT index_name, used FROM v$object_usage WHERE index_name = 'TEST_MONITORING_IDX';

INDEX_NAME                     USE                                              
------------------------------ ---                                              

TEST_MONITORING_IDX            YES 

Tener índices sin usar en la base de datos puede quitarnos espacio necesario y reducir el rendimiento en las sentencias  de borrado o actualización, por eso es importante eliminar aquellos que no son utilizados.

Dimensionamiento de la base de datos.

Toca crear una base de datos para un nuevo proyecto y llegan las ¡Vaya preguntas!  como por ejemplo: ¿Cuánto disco necesito para mi nueva base de datos Oracle? Suponemos que nuestra instalación no tiene ASM instalado, de ser esto cierto, no necesitas seguir leyendo mas este artículo, bueno tendrás que leer algo si quieres tener en cuenta los demás componentes de tu instalación.

ASM es un administrador de volúmenes y un sistema de archivos para bases de datos Oracle que admite configuraciones de base de datos Oracle de una sola instancia y Oracle Real Application Clusters (Oracle RAC). ASM es la solución de administración de almacenamiento recomendada de Oracle que proporciona una alternativa a los administradores de volúmenes convencionales, sistemas de archivos y dispositivos sin formato.

Pasemos a mi receta:

• 8-10 veces el volumen de datos en bruto para un sistema OLTP
• 2-4 veces el volumen de datos en bruto para un Almacén de datos.
• Cuanto más grande sea la base de datos, más cerca estará de los factores de multiplicación inferiores.

Aclaración: Por supuesto, esta es solo mi opinión, basada en alguna que otra experiencia. Si usas las cifras anteriores para un proyecto real y no obtienes el espacio total en disco que necesitas, no me eches las culpas ;P. Si lo haces y está bien, entonces por supuesto, ahora me debes una cerveza :)

Muchos de nosotros probablemente hemos tenido que calcular el tamaño esperado de una base de datos antes (bajo la atenta mirada del manager, en el momento de hacer el pliego de una oferta), pero la base de datos real es solo un componente de todo lo que necesita para ejecutar Oracle en tu sistema. También debe dimensionar los demás componentes:

• Registros de rehacer archivados (redo logs), 
• Área de preparación de copias de seguridad, 
• Área de transferencia de datos. 
• Archivos externos, si los hubiera. 
• El sistema operativo. 
• Espacio de intercambio (swap), 
• Espacio para los ficheros log, trace, dump
• Los "benditos" binarios de Oracle (que generalmente aumentan cada año) etc ...

En primer lugar, debe saber la cantidad de "datos sin procesar" que tiene. Con esto me refiero a lo que se convertirá en la tabla de datos. Ya a principios de este siglo, este podía ser el tamaño total de los archivos planos que usaba el sistema anterior, incluso el tamaño de los datos tal como estaba en las hojas de cálculo. Un archivo de exportación de Oracle del sistema también da una idea bastante buena del volumen de datos en bruto. Al carecer de todo esto, entonces necesitas un tamaño aproximado de tus datos brutos. Haz un cálculo esta manera:

• "numero_de_filas * Suma_de_columnas" para tus 10 tablas más grandes. Y no tengas la tentación de sobreestimar, mis multiplicadores te permiten el relleno.

Digamos que ya has hecho esto y son 60GB de datos sin formato para un sistema OLTP. Deja que los chicos de almacenamiento sepan que probablemente querrás 500GB de espacio. Luego mentalmente lo dejarán como "sin consecuencias", ya que probablemente tengan muchos terabytes de almacenamiento. Luego he de aclarar una cosa: No estoy considerando la redundancia en absoluto, en el espacio que se proporciona. 

Si obtienes 5TB de datos brutos para un sistema DW, necesitará alrededor de 12-15 TB de almacenamiento en disco.

Si obtienes más de un Terabyte de datos en bruto para un sistema OLTP o de 10 a 20 Terabytes para un DW, cuando le das cifras a los chicos de almacenamiento , entonces es posible que palidezcan y digan algo como " ¡tienes que estar bromeando!". Esto es parte de por qué el factor de multiplicación para Data Warehouses y sistemas más grandes en general es menor, ya que se lo fuerza a tener más cuidado con el espacio que asigna y cómo lo usa.

La sobrecarga del espacio total en el disco sobre los datos Raw se reduce a medida que la base de datos se agranda por varias razones:

• El tamaño de los binarios de Oracle y el sistema operativo no cambia a medida que la base de datos crece.
• El tamaño del espacio de intercambio no aumenta en línea con la base de datos ya que, en términos generales, si aumenta el tamaño de la base de datos de 100 GB a 1 TB, no puede darse el lujo de aumentar la memoria del sistema de su servidor. Probablemente se duplique.
• Las bases de datos muy grandes tienden a tener algo que las hace grandes, como imágenes o documentos incrustados, que no están indexados. Por lo tanto, la relación de segmentos de tabla a segmentos de índice aumenta.
• Si tienes una base de datos muy grande, empieza a eliminar índices (a menudo aquellos que soportan restricciones) para ayudar al rendimiento de la carga y administración de datos, nuevamente mejorando la proporción de segmentos de tabla a segmentos de índice.
• Las copias de seguridad se vuelven parciales o incrementales para reducir el tamaño y la duración de la copia de seguridad.
• Como se mencionó anteriormente, el tamaño del sistema es tal que se debe tener más cuidado al limpiar las áreas de trabajo, reducir las áreas archivadas de registro de rehacer (esos archivos se comprimen bien) y otras áreas.
• Si las cosas se vuelven extremas usted comienza a alterar PCTFREE y verificando el tamaño de las extensiones, aunque estos problemas de dimensionamiento desaparecen con Oracle ASM.

Pruebas unitarias con utPLSQL

Las pruebas son un mal necesario del proceso de desarrollo de aplicaciones. Lamentablemente, las pruebas a menudo se pasan por alto o se pasan por alto cuando el tiempo es corto (seamos sinceros, ¿Quién no odia la fase de pruebas?). La distribución de código no probado o no marcado puede llevar a un código plagado de errores y a usuarios decepcionados. Las pruebas unitarias con un marco bien construido pueden ayudar a aliviar parte del tiempo que lleva ajustarse a un proceso de desarrollo bien probado.

Hay algunas opciones diferentes disponibles para probar tu código PL / SQL. La herramienta de Oracle SQL Developer:

• http://www.oracle.com/technetwork/es/developer-tools/sql-developer/overview/index.html

Proporciona algunas buenas opciones de depuración.

También puede usar instrucciones DBMS_OUTPUT dentro de su código para mostrar los resultados de las variables a medida que se ejecuta su código. Esta es una buena técnica para ayudar a identificar problemas en su código.

Frameworks de prueba para PL/SQL

Los más conocidos en la comunidad de Oracle son quizás Quest's Code Tester, especialmente con personas que trabajan con Toad y utPLSQL, que ha sido desarrollado por el superhombre de PL / SQL Steven Feuerstein, y las características integradas de Oracle SQL Developer.

• DbFit                                   
• Desarrollador Oracle SQL
• Pruebas unitarias PL / SQL para Oracle (PLUTO)
• PL / Unidad
• Quest Code Tester para Oracle
• ruby-plsql-spec
• utPLSQL

Por ejemplo el framework PLUTO (PL / SQL Unit Testing for Oracle) (http://code.google.com/p/pluto-test-framework/) es uno de esos marcos.

Otro es el marco de pruebas unitarias utPLSQL, creado por Steven Feuerstein  y este artículo se centrará en utPLSQL ya que es más ampliamente adoptado que los demás. El framework de pruebas unitarias  utPLSQL (http://utplsql.org/downloads/) puede aliviar parte del dolor de realizar las pruebas unitarias. El marco es fácil de usar y funciona muy bien para probar código bajo cualquier circunstancia que pueda imaginarse. Ahí también hay muchas opciones en utPLSQL que se pueden usar para mejorar el proceso de prueba de su unidad. Como resultado del uso de pruebas unitarias, sus aplicaciones serán más fiables, y pasará mucho menos tiempo manteniendo la base de código.

Prueba de código PL / SQL almacenado sin pruebas unitarias

Problema

Desea asegurarse de que un bloque de código PL / SQL funciona correctamente, pero no quiere tomarse el tiempo para escribe una prueba unitaria

Solución

Envuelves el código en las sentencias DBMS_OUTPUT que muestran o imprimen los resultados de intermedio y final, así como los resultados de pasos y ramas condicionales complejos. Esto te permitirá ver la ruta que toma el código cuando se llama a la función con los parámetros especificados. El siguiente ejemplo muestra esta táctica para colocar comentarios en ubicaciones estratégicas dentro de un código PL / SQL para ayudar a determinar si el código está funcionando como se esperaba. Por ejemplo, supongamos que desea pruebe rápidamente la función que presentamos en el ejemplo. Así es como lo modificarías para probar rápidamente la exactitud de sus resultados.

Cuando la función CALC_HORAS_TRIMESTRALES se ejecuta con un valor de 7.34, los comentarios se mostrarán como se ve en el siguiente fragmento de una sesión:

SQL> set serveroutput on

SQL> select calc_horas_trimestrales(7.34) from dual;

CALC_HORAS_TRIMESTRALES(7.34)

-----------------------

7.25

El valor pasado fue mayor a una hora ...

La porción decimal <= .375

El uso de instrucciones DBMS_OUTPUT dentro del código PL / SQL para mostrar datos o información perteneciente a la funcionalidad del código ha sido una gran táctica para probar el código en cualquier idioma. Como una cuestión de hecho,

es probablemente una de las técnicas más utilizadas para depurar código. La capacidad de ver valores como se calculan o para determinar cómo se maneja una condición puede ser muy útil para determinar si su código se está ejecutando como debería.

Para utilizar las sentencias DBMS_OUTPUT para probar tu código, debes colocarlas en estrategias ubicaciones. En el ejemplo de esta receta, los comentarios se han colocado dentro de cada uno de los bloques IF-ELSE para mostrar un poco de texto que le dirá al desarrollador cómo se procesan los valores dentro de la función.

Esto puede ser muy útil cuando se prueba el código porque una serie de números se puede pasar al función para determinar si se está devolviendo el resultado correcto. Si no, entonces podrás  para ver exactamente dónde se está evaluando incorrectamente el código.

Aunque el uso de instrucciones DBMS_OUTPUT en el código puede ser muy útil para determinar dónde se encuentra el código funcionando correctamente, puede causar desorden y también puede crear sus propios problemas. Por ejemplo, si te olvidas de colocar una cita después de una de las instrucciones DBMS_OUTPUT que coloca en su código, entonces el código no se compila correctamente, lo que hace que busques la causa de otro problema. Además, es una buena idea eliminar las instrucciones de salida antes de que el código se libere en producción. Esto puede tomar un tiempo, que podría ser mejor invertido en el desarrollo. Como un medio para probar pequeñas unidades de código, usando DBMS_OUTPUT funciona bastante bien. Sin embargo, si desea desarrollar suites de prueba completas y una unidad automatizada probando, entonces debes de continuar leyendo el resto del artículo.

Instalar utPLSQL

Problema

Has elegido el marco de pruebas de unidad utPLSQL para PL / SQL para tu trabajo y quieres instalarlo.

Solución

Primero, descarga las fuentes de utPLSQL. Una vez que hayas obtenido las fuentes, sigue los siguientes pasos para instalar el paquete utPLSQL en la base de datos para la cual desea escribir las pruebas unitarias y ponerlo a disposición para todos los esquemas.

Crea un usuario para alojar las tablas, paquetes y otros objetos de utPLSQL. Por ejemplo, el usuario se llamará UTP y se usarán los tablespaces permanentes y temporales predeterminados.

Otorga privilegios al usuario UTP recién creado utilizando GRANT <privilege_name> TO  <user_name>, reemplazando valores con el privilegio apropiado y nombre de usuario El usuario requerirá los siguientes privilegios:

• Create session
• Create procedure
• Create table
• Create view
• Create sequence
• Create public synonym
• Drop public synonym

Instalaa los objetos ejecutando el script ut_i_do.sql.

SQL> @ut_i_do instalar

Una vez que se hayan completado estos pasos, tendrás la posibilidad de ejecutar pruebas unitarias en paquetes que se cargan en diferentes esquemas dentro de la base de datos.

Usar utPLSQL

Problema

Te gustaría construir un paquete de prueba de unidad para uno o más de los objetos PL / SQL en su esquema de base de datos.

Solución

Deseas construir un paquete de prueba utPLSQL para probar un objeto en su base de datos. Un paquete de prueba consta de dos archivos separados, un encabezado de paquete y un cuerpo de paquete.

Cree un encabezado para el paquete de prueba y guárdelo en un archivo con el mismo nombre que le ha asignado al encabezado y con un sufijo .pks.

Un archivo de encabezado contiene tres procedimientos: 

• ut_setup, 
• ut_teardown 
• El procedimiento que realiza las pruebas unitarias del objeto de destino en su base de datos. 

Por ejemplo, supòn que deseas crear un paquete de prueba de unidad para probar el código de la función CALC_HORAS_TRIMESTRALES. Este encabezado de paquete debe almacenarse en un archivo llamado ut_calc_horas_trimestrales.pks y cargado en la base de datos cuyos objetos estás probando.

Cree el cuerpo del paquete que implemente los procedimientos especificados por el encabezado del paquete de prueba de la unidad y guárdelo como un archivo con el mismo nombre que el encabezado, pero esta vez con un sufijo .pkb. El siguiente cuerpo del paquete debe almacenarse en un archivo llamado ut_calc_horas_trimestre.pkb y cargarse en la base de datos.

El cuerpo del paquete en este ejemplo se ajusta al formato que se debe usar para probar paquetes usando el marco utPLSQL.

¿Hay vida más allá de Oracle? El Oráculo en la nube de las amazonas

Como bien reza el título del artículo sacado de una película de serie b de los cincuenta, en este artículo vamos a abordar como Amazon Web Services (AWS) te ofrece la posibilidad de ejecutar nuestra base de datos favorita en su nube pública. 

La ejecución de Oracle Database en la nube de AWS es muy similar a  ejecutar Oracle Database en su centro de datos. Para un administrador o desarrollador de base de datos, no hay diferencias entre los dos entornos. Sin embargo, hay una serie de consideraciones de la plataforma AWS relacionadas con

• La seguridad
• El almacenamiento de la información
• La gestión de la configuración 
• Administración y monitoreo de la base de datos

que nos facilitan a obtener lo mejor de su base de datos Oracle implementación en AWS. 

En este artículo proporcionaremos las mejores prácticas para lograr  un mejor rendimiento, disponibilidad y confiabilidad óptimas, y, por supuesto, un menor coste  (TCO) mientras ejecuta Oracle Database en AWS. 

El público objetivo para este artículo incluye administradores de bases de datos, arquitectos empresariales, administradores de sistemas y desarrolladores que deseen ejecutar su base de datos Oracle en AWS.

Introducción a AWS

Amazon Web Services (AWS) proporciona un conjunto integral de servicios y herramientas para implementar Oracle Database en la infraestructura confiable y segura de nube de AWS. AMAZON ofrece a sus clientes dos opciones para ejecutar Oracle Database en AWS:

Amazon RDS para bases de datos Oracle

Utilizando Amazon Relational Database Service (Amazon RDS) para Oracle, que es un servicio de base de datos administrado que ayuda a simplificar el aprovisionamiento y la administración de bases de datos Oracle. Amazon RDS facilita la configuración, el funcionamiento y la escalabilidad de una base de datos relacional en la nube al automatizar la instalación, el aprovisionamiento y la administración del disco, el parcheo, las actualizaciones menores de la versión, el reemplazo fallido de instancias y las tareas de respaldo y recuperación.

La función Multi-AZ de Amazon RDS opera dos bases de datos en múltiples zonas de disponibilidad con replicación síncrona, creando así un entorno de alta disponibilidad con failover automático. La función de escalado de botón de Amazon RDS le permite escalar la instancia de la base de datos hacia arriba y hacia abajo fácilmente para una mejor gestión de costos y rendimiento. Amazon RDS también viene con una opción de licencia incluida, que permite pagar por uso por hora.

Base de datos Oracle autogestionada Amazon EC2

Ejecución de una base de datos Oracle autogestionada directamente en Amazon Elastic Compute Cloud (Amazon EC2). Esta opción le brinda control total sobre la configuración de la infraestructura y el entorno de la base de datos. Ejecutar la base de datos en Amazon EC2 es muy similar a ejecutar la base de datos en su propio servidor. Tu tienes el control  total de la base de datos y tienes acceso a nivel de sistema operativo, por lo que puedes ejecutar agentes de supervisión y administración y usar tu elección de herramientas para la replicación de datos, la copia de seguridad y la restauración. Además, tiene la capacidad de utilizar cada módulo opcional disponible en Oracle Database. Sin embargo, esta opción requiere que se configure, administre y ajuste todos los componentes, incluidas las instancias de Amazon EC2, los volúmenes de almacenamiento, la escalabilidad, las redes y la seguridad, según las mejores prácticas de arquitectura de AWS.

Arquitecturas para seguridad y rendimiento

Ya sea que elijas ejecutar Oracle Database en Amazon RDS o Amazon EC2, la optimización de cada componente de la infraestructura mejorará la seguridad, el rendimiento y la confiabilidad. En las siguientes secciones, analizaremos las mejores prácticas para optimizar la configuración de la red, el tipo de instancia y el almacenamiento de la base de datos en una implementación de Oracle Database en AWS.

Configuración de la red

La nube privada virtual de Amazon (Amazon VPC) le permite aprovisionar una sección aislada lógicamente de la nube de AWS que está dedicada a su cuenta. Tiene control total sobre su entorno de red virtual, incluida la selección de su propio rango de direcciones IP, la creación de subredes y la configuración de tablas de rutas y puertas de enlace de red, y la configuración de seguridad.

Una subred es un rango de direcciones IP en su Amazon VPC. Puede iniciar los recursos de AWS en una subred que seleccione. Utilice una subred pública para recursos que deben estar conectados a Internet, y una subred privada para recursos que no estarán conectados a Internet.

Para proteger los recursos de AWS en cada subred, puede usar varias capas de seguridad, incluidos los grupos de seguridad y las listas de control de acceso a la red (ACL).

La siguiente tabla describe las diferencias básicas entre los grupos de seguridad y las ACL de red.

Amazon VPC proporciona aislamiento, seguridad adicional y la capacidad de separar instancias de Amazon EC2 en subredes, y permite el uso de direcciones IP privadas. Todos estos son importantes en la implementación de la base de datos. Implemente la instancia de Oracle Database en una subred privada y permita que solo los servidores de aplicaciones dentro de Amazon VPC, o un host Bastion dentro de Amazon VPC, accedan a la instancia de la base de datos. Cree grupos de seguridad apropiados que permitan el acceso solo a direcciones IP específicas a través de los puertos designados. Estas recomendaciones se aplican a Oracle Database independientemente de si está utilizando Amazon RDS o Amazon EC2.

Sobre las licencias Oracle

Como se indica en el documento de Oracle en el site My Oracle Support Doc ID: 2174134.1, Oracle es totalmente compatible con la implementación de Oracle Database en AWS. (Si quieres ver el documento, ha de registrarse para obtener una cuenta de Oracle, que es gratuita.) Las licencias de Oracle Database en AWS se basan en el tamaño de la instancia en la que está instalada la base de datos. 
Algunos puntos clave:

• El recuento de núcleos virtuales de las instancias de Amazon EC2 se considera igual al recuento de núcleos físicos para fines de licencia. Para conocer el recuento de núcleos virtuales de cada tipo de instancia de Amazon EC2, consulte Núcleos virtuales de Amazon EC2 y Tipo de instancia de base de datos de RDS.
• Oracle Database Standard Edition solo puede tener licencia en instancias de Amazon EC2 que tengan hasta 16 núcleos virtuales.
• Oracle Standard Edition One y Standard Edition Two solo pueden tener licencia en instancias de Amazon EC2 que tengan hasta 8 núcleos virtuales.
• Para Oracle Database Standard Edition, Standard Edition One o Standard Edition Two, las instancias de Amazon EC2 con 4 o menos núcleos virtuales se cuentan como un solo socket.
• Para Oracle Database Enterprise Edition, las instancias de Amazon EC2 con 2 o menos núcleos virtuales se cuentan como un solo socket.

Portabilidad de licencia de Oracle a AWS

Sujeto a los términos y condiciones del acuerdo de licencia específico, las licencias de Oracle pueden ser transferibles a AWS. En otras palabras, sus licencias existentes se pueden transferir para su uso en AWS. Éstas incluyen:

• Licencias basadas en servidor (basadas en CPU utilizadas)
• Acuerdos de licencia empresarial (ELA)
• Acuerdos de licencia ilimitados (ULA)
• Licencias de Business Process Outsourcing (BPO)
• Licencias de Oracle PartnerNetwork (OPN)
• Licencias de User Plus con nombre

Es posible que se apliquen condiciones o limitaciones adicionales (incluidos los posibles costos) para las licencias que se transfieren a AWS. Verifique su contrato de licencia específico para obtener detalles y limitaciones adicionales.

Las licencias de Oracle se aplican de manera similar a Oracle Database en Amazon RDS y en Amazon EC2, con la excepción de que las licencias por hora solo están disponibles en Amazon RDS.

Conclusión

Dependiendo de su escenario de uso, puede utilizar Amazon RDS para Oracle Database o ejecutar una base de datos Oracle autogestionada en Amazon EC2. Independientemente de su elección, seguir las mejores prácticas proporcionadas en este artículo te ayudará a aprovechar tu implementación de Oracle Database en AWS.

Jolokia, una potente especia, para condimentar con Oracle Weblogic

Jolokia es uno de los chiles mas fuertes de planeta y también una utilidad para administrar Oracle Weblogic.

Jolokia es un puente JMX-HTTP que ofrece una alternativa a los conectores JSR-160. Es un enfoque basado en agentes con soporte para muchas plataformas. Además de las operaciones básicas de JMX, mejora la comunicación remota JMX con características exclusivas, como solicitudes masivas y políticas de seguridad detalladas.

Jolokia es un enfoque basado en agentes para el acceso remoto JMX. Es una alternativa a los conectores estándar JSR 160 (). La comunicación entre el cliente y el agente pasa por HTTP (GET o POST), donde la carga útil de solicitud y respuesta se representa en JSON.

El protocolo Jolokia admite las siguientes operaciones:

• Lectura y escritura de atributos JMX
• Ejecución de operaciones JMX
• Búsqueda de nombres MBean por patrón
• Listado de metadatos MBean como atributos, operaciones y notificaciones compatibles
• Hasta ahora las notificaciones JMX aún no son compatibles (pero están en la hoja de ruta para una versión futura).

La arquitectura general de Jolokia se muestra en el siguiente diagrama. El agente traduce entre JSON a través de HTTP y llamadas a MBeans locales, incluida una serialización JSON de los valores devueltos.

Este enfoque tiene algunas ventajas:

• Con la ayuda del agente, Jolokia puede proporcionar servicios que van más allá de la funcionalidad de los conectores JSR-160:

• Solicitudes masivas que permiten múltiples llamadas JMX en una sola solicitud
• Seguridad de grano fino con restricción de acceso en el funcionamiento de MBean y nivel de atributo.
• Fusión de múltiples MBeanServer en una vista virtual, por lo que no es necesario saber con antelación qué MBean está registrado en qué MBeanServer. Con JSR-160 el objetivo MBeanServer debe conocerse con anticipación.
• Modo de historial para almacenar valores recuperados previamente en un caché en el lado del servidor, junto con un sello de tiempo. Esto es especialmente útil para calcular el cambio de atributos JMX sin necesidad de un almacenamiento de cliente.
• No se requiere Java en el lado del cliente debido a la naturaleza neutral de plataforma de HTTP y JSON.
• La serialización JSON permite un acceso profundo a los objetos devueltos sin tener instaladas definiciones de tipos personalizados en el lado del cliente.
• Dado que HTTP usa un solo puerto predefinido, esta configuración funciona muy bien con la configuración del firewall. El conector predeterminado JSR-160, por el contrario, no es tan inteligente ya que RMI usa un puerto aleatorio para su comunicación por defecto.
• Por paradoja que pueda parecer, configurar un agente es a menudo más fácil que configurar la exportación JSR-160 JMX, especialmente cuando se trata de seguridad. Normalmente, para JSR-160, se deben adaptar los archivos de inicio de exportación y la configuración del servidor de aplicaciones. El agente estándar se implementa como una aplicación web normal, que es un procedimiento bien conocido.

La única desventaja de este modo es que se debe instalar un agente. Esto puede deberse a razones de política por la que no se permite instalar ninguna aplicación externa. O todos los servidores a monitorear ya están preparados para la exportación JSR-160 JMX, por lo que un paso de instalación adicional no es bienvenido. Además, actualizar Jolokia normalmente implica una redistribución del agente. 

Estas son todas buenas razones, por lo que Jolokia también tiene una respuesta. Al instalar un servidor JEE dedicado con un agente implementado, Jolokia puede operar en modo proxy, en cuyo caso traduce la solicitud de JOLOKIA JSON a la solicitud del cliente JSR-160 para la operación en el servidor de destino. Viceversa, el resultado sobre un conector JSR-160 luego se traduce en una respuesta JSON que se devuelve al cliente Jolokia.

Ejemplo

Para tener una idea de cómo es el protocolo de Jolokia, aquí hay un ejemplo de una simple solicitud y respuesta de Jolokia. Suponiendo que un agente está instalado, la siguiente solicitud HTTP GET lee las estadísticas de la memoria de montón utilizada de la JVM instrumentada:

 http://localhost:8080/jolokia/read/java.lang:type=Memory/HeapMemoryUsage

http: // localhost: 8080 / jolokia es la URL base bajo la cual se puede acceder al agente. La misma solicitud se puede realizar al enviar el siguiente cuerpo a la URL http: // localhost: 8080 / jolokia:

  {
    "mbean":"java.lang:type=Memory",
    "attribute":"HeapMemoryUsage",
    "type":"READ"
  }

En ambos casos, la respuesta contiene un objeto JSON:

 {
    "timestamp":1285531108,
    "status":200,
    "request": {
                 "mbean":"java.lang:type=Memory",
                 "attribute":"HeapMemoryUsage",
                 "type":"read"
               }, 
     "value": {
                "max":"129957888",
                "committed":"85000192",
                "init":"0",
                "used":"7713440"
              }
  }

Gestión RESTful de WebLogic con Jolokia

La administración y el monitoreo de los recursos de WebLogic es el pan de caa día para muchos administradores. La programación de una solución de gestión mediante la escritura de código JMX en Java es un proceso de bajo nivel y lento que puede evitarse utilizando la herramienta de scripts WebLogic basada en Jython (WLST).

WLST es un lenguaje de dominio específico de nivel superior (DSL) especialmente desarrollado para abordar problemas de gestión. Algunas líneas de código WLST suelen encapsular cientos de líneas de código Java utilizando JMX. Aunque WLST es compacto y fácil de escribir, aún adolece de la "J" en JMX: cada vez que ejecuta un script WLST para monitorear algún atributo en el servidor de aplicaciones, debe iniciarse una JVM en el lado del cliente para WLST. Esta sobrecarga puede ser bastante importante si está monitoreando muchos servidores y recuperando atributos a intervalos regulares. En particular, para sistemas de monitoreo como Nagios (o el Shinken más nuevo), el enfoque WLST no es adecuado.

Una de las nuevas características distintivas de WebLogic 12c es su servicio de administración RESTful, que se puede habilitar con un simple clic en DOMAIN / Configuration / General / Advanced / Enable RESTful Management Services  seguido de un reinicio del servidor.

Una vez habilitado, puede acceder a los valores de tiempo de ejecución de WebLogic 12c más importantes utilizando una sintaxis de URL simple de su navegador web o una herramienta de línea de comandos de Unix, como curl. Por ejemplo, puede recuperar datos de tiempo de ejecución del servidor de administración con una solicitud HTTP rápida en lugar de generar un proceso de JVM para WLST:

• http://localhost:7001/management/tenant-monitoring/servers/AdminServer/

Instalación

El proceso de instalación está bien descrito en el sitio de Jolokia. Simplemente puede obtener el archivo jolokia.war del sitio de descarga de Jolokia o el repositorio central de Maven, no se necesita nada más para WebLogic.

Incluso es posible usarlo sin ninguna implementación en absoluto. Comenzando con JDK6, puede ejecutarlo como un agente JVM, una técnica que se usa típicamente para los perfiladores, etc. Por lo tanto, su llamada java que inicia WebLogic tiene el siguiente formato:

java -javaagent:agent.jar ...

Si desea instalar todo el proyecto Jolokia (incluido el shell JMX que se describe más adelante, el complemento Nagios, un complemento Spring Roo, etc.) en un sistema UNIX con Perl y CPAN ya instalados, puede ser tan fácil como:

[root@ccloud ~]# perl -MCPAN -e shell cpan shell -- CPAN exploration and modules installation (v1.9800)

cpan[1]&gt; install JMX:Jmx4Perl

[... you have to confirm the installation of several dependencies ...]

Comparación de funciones: Jolokia y WebLogic 12c RESTful Management Service

Ahora, ¿cómo se compara Jolokia con lo que ya tiene listo en la WebLogic 12c? Aquí hay una breve descripción:

La URL GET para una solicitud de lectura Jolokia tiene el siguiente formato:

&lt;base-url&gt;/read/&lt;<a title="MBean Object Name" href="http://docs.oracle.com/javase/6/docs/api/javax/management/ObjectName.html">mbean name</a>&gt;/&lt;attribute name&gt;/&lt;inner path&gt;

Para comenzar, simplemente pegue la siguiente URL en su navegador o use el curl de la utilidad de línea de comandos de Unix (suponiendo que tiene el servidor de administración ejecutándose en localhost: 7001). Recuperará los atributos configurados de ListenPort:

[JavaScript]

{ "request" : { "attribute" : "ListenPort",

      "mbean" : "com.bea:Type=Server,*",

      "type" : "read"

    },

  "status" : 200,

  "timestamp" : 1334776908,

  "value" : { "com.bea:Name=AdminServer,Type=Server" : { "ListenPort" : 7001 },

      "com.bea:Name=surf1,Type=Server" : { "ListenPort" : 7003 },

      "com.bea:Name=surf2,Type=Server" : { "ListenPort" : 7005 },

      "com.bea:Name=surf3,Type=Server" : { "ListenPort" : 7007 }

    }

}

[/JavaScript]

La respuesta se mostrará en una sola línea. Para obtener el formato anterior, puede pasar el resultado a uno de los muchos formateadores JSON en línea (o canalizar la salida curl a una utilidad adecuada).