Mejoras de auditoría (DBMS_AUDIT_MGMT) en Oracle Database 11g Release 2

Oracle, para la release 11g R1 activó la auditoría por defecto por primera vez. Oracle 11g Release 2 ahora permite una mejor administración de la pista de auditoría utilizando el paquete DBMS_AUDIT_MGMT.

Mover la pista de auditoría de base de datos a un espacio de tabla diferente

El procedimiento SET_AUDIT_TRAIL_LOCATION te permite modificar la ubicación de la pista de auditoría de base de datos (normal / detallada). Aunque no permite la alteración de la pista de auditoría del sistema operativo,  la documentación sugiere que esto puede suceder en el futuro. 
Este procedimiento acepta dos parámetros.

• AUDIT_TRAIL_TYPE: tipo de pista de auditoría que se va a mover.
• AUDIT_TRAIL_LOCATION_VALUE: el espacio de tabla al que deben moverse las tablas de seguimiento de auditoría.

El parámetro AUDIT_TRAIL_TYPE se especifica utilizando una de estas constantes.

• DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD: pista de auditoría estándar (AUD $).
• DBMS_AUDIT_MGMT.AUDIT_TRAIL_FGA_STD: pista de auditoría detallada (FGA_LOG $).
• DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STD: pistas de auditoría estándar y de grano fino.

Primero vemos la ubicación actual de las tablas de seguimiento de auditoría.

A continuación, creamos un nuevo tablespace para contener el seguimiento de auditoría.

Luego movemos la pista de auditoría estándar al nuevo espacio de tabla.

A continuación, movemos la pista de auditoría detallada.

Controlar el tamaño y la antigüedad de la pista de auditoría del sistema operativo

El procedimiento SET_AUDIT_TRAIL_PROPERTY le permite establecer el tamaño máximo y / o la edad de los archivos del registro de auditoría del sistema operativo. El procedimiento puede establecer parámetros para varios propósitos, pero restringiré la discusión solo a aquellos relevantes para esta sección. Se puede encontrar una lista completa de las constantes disponibles aquí.

El procedimiento acepta tres parámetros.

• AUDIT_TRAIL_TYPE: el tipo de pista de auditoría a modificar (AUDIT_TRAIL_OS, AUDIT_TRAIL_XML o AUDIT_TRAIL_FILES).
• AUDIT_TRAIL_PROPERTY: el nombre de la propiedad que se establecerá (OS_FILE_MAX_SIZE o OS_FILE_MAX_AGE).
• AUDIT_TRAIL_PROPERTY_VALUE: el valor requerido para la propiedad.

Para verificar la configuración actual, consulte la vista DBA_AUDIT_MGMT_CONFIG_PARAMS.

Para estableder  el tamaño máximo de los archivos de auditoría del sistema operativo en 15,000 Kb, ejecuta el siguiente script:

Para establecer la edad máxima de los archivos de auditoría XML en 30 días, ejecuta el siguiente script.

El procedimiento CLEAR_AUDIT_TRAIL_PROPERTY se puede utilizar para eliminar las restricciones de tamaño y edad o restablecerlas a los valores predeterminados. Establecer el valor del parámetro USE_DEFAULT_VALUES en FALSE elimina las restricciones, mientras que establecerlo en TRUE devuelve la restricción al valor predeterminado.

Purga de registros de seguimiento de auditoría

Al igual que en versiones anteriores, puede eliminar manualmente registros de las tablas AUD $ y FGA_LOG $ y eliminar manualmente los archivos de auditoría del sistema de archivos, pero el paquete DBMS_AUDIT_MGMT le brinda algunos mecanismos nuevos y más seguros para mantener la pista de auditoría.

Inicializando la infraestructura de gestión

Para poder purgar la pista de auditoría de la base de datos, se debe realizar una inicialización única de la infraestructura de administración de auditoría. Esto se hace usando el procedimiento INIT_CLEANUP. El procedimiento acepta dos parámetros.

• AUDIT_TRAIL_TYPE: la pista de auditoría a inicializar (constantes).
• DEFAULT_CLEANUP_INTERVAL: El intervalo predeterminado en horas, después del cual el procedimiento de limpieza se debe volver a llamar (1-999).

El siguiente script SQL verifica la configuración de parámetros actual, inicializa la infraestructura de administración de auditoría para todas las pistas de auditoría con un intervalo predeterminado de 12 horas y vuelve a verificar la configuración.

Observa que el 'DB AUDIT TABLESPACE' para las pistas de auditoría de la base de datos no ha cambiado y que se ha establecido el 'INTERVALO DE LIMPIEZA POR DEFECTO' para las cuatro pistas de auditoría. El estado de inicialización actual de una pista de auditoría específica se puede verificar utilizando IS_CLEANUP_INITIALIZED.

Para desconfigurar la infraestructura de gestión de auditoría, ejecute el procedimiento DEINIT_CLEANUP.

Gestión de marca de tiempo

Lo siguiente a considerar antes de purgar la pista de auditoría es la cantidad de datos que desea depurar. El paquete DBMS_AUDIT_MGMT nos permite purgar todos los registros, o todos los registros anteriores a una marca de tiempo específica. La marca de tiempo en cuestión se especifica individualmente para cada pista de auditoría utilizando el procedimiento SET_LAST_ARCHIVE_TIMESTAMP, que acepta tres parámetros.

• AUDIT_TRAIL_TYPE: el seguimiento de auditoría cuya marca de tiempo debe establecerse (constantes). Solo son válidos los registros de auditoría individuales, no las constantes que especifican los múltiplos.
• LAST_ARCHIVE_TIME: se borrarán los registros o archivos anteriores a esta hora.
• RAC_INSTANCE_NUMBER: opcionalmente especifique el nodo RAC para las pistas de auditoría del sistema operativo. Si no está configurado, asume la instancia actual.

Purga manual

El procedimiento CLEAN_AUDIT_TRAIL es el mecanismo básico para purgar manualmente el seguimiento de auditoría. Acepta dos parámetros.

• AUDIT_TRAIL_TYPE: la pista de auditoría a purgar (constantes).
• USE_LAST_ARCH_TIMESTAMP: establézcalo en FALSE para purgar todos los registros / archivos, o TRUE solo purgue los registros / archivos anteriores a la marca de tiempo especificada para la pista de auditoría.

Purga automatizada

El procedimiento CREATE_PURGE_JOB le permite programar un trabajo para llamar al procedimiento CLEAN_AUDIT_TRAIL. Al crear un trabajo de purga, puede especificar 4 parámetros.

• AUDIT_TRAIL_TYPE: la pista de auditoría a purgar por el trabajo programado (constantes).
• AUDIT_TRAIL_PURGE_INTERVAL: intervalo en horas entre purgas.
• AUDIT_TRAIL_PURGE_NAME: un nombre para el trabajo de depuración.
• USE_LAST_ARCH_TIMESTAMP: establézcalo en FALSE para purgar todos los registros / archivos, o TRUE solo purgue los registros / archivos anteriores a la marca de tiempo especificada para la pista de auditoría.

.

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.