27 agosto 2014

ASO y HSM Wallet (Parte 1 de 2)

En el anterior artículo hablamos de cifrar datos mediante el uso de una fichero que almacena nuestra clave maestra (wallet), ahora veremos como asegurar ese fichero para, evitar ataques, es una capa más para tener mayores garantías de que nuestros datos están asegurados. 

Mini guía de Integración de Oracle Database con HSM Thales ncipher
Debido a anteriores experiencias laborales, estuve trabajando con esta tecnología, integrando los HSM de mi anterior compañía, Thales, con las Bases de Datos Oracle. HSM son las siglas de "Hardware Security Module" (Módulo de Seguridad Hardware).


Un HSM es un dispositivo criptográfico basado en hardware que genera, almacena y protege claves criptográficas y suele aportar aceleración hardware para operaciones criptográficas. Estos dispositivos pueden tener conectividad SCSI / IP u otras y aportar funcionalidad criptográfica de clave pública (PKI) de alto rendimiento que se efectúa dentro del propio hardware.


Oracle Database 11g Release 2 TDE cifra de forma transparente los datos que se almacenan en la base de datos Oracle, sin requerir ningún cambio de código en la aplicación que se ejecuta. Es compatible tanto con TDE cifrado de tabla y columna de cifrado TDE. El HSM asegura la clave maestra para cifrar tablespaces y tablas.

El HSM es usado en lugar del fichero Oracle Wallet para proveer un más alto nivel de garantía de seguridad, incluyendo:
  • Almacenamiento centralizado y gestión de las claves maestras. El fichero de clave ya no está en servidor de base de datos, reside en el hardware.
  • Gestión del ciclo de vida completo de la clave (s) de cifrado principal.
  • Mayor nivel de garantía de la seguridad, las claves nunca se almacenan en el dispositivo como texto plano.
  • Certificación FIPS 140-2 level 3 en el hardware. Añade resistencia a la intrusión física con fines de desmontaje o modificación, de manera que dificulta al máximo los ataques. Si se detecta la intrusión, el dispositivo debe ser capaz de borrar los parámetros de seguridad críticos. El Nivel 3 también incluye protección criptográfica eficaz y administración de claves, autenticación basada en la identidad y separación física o lógica entre las interfaces a través de las que se accede a los parámetros de seguridad crítica y se sale de ellos.
  • Soporte de fallos.

 Dependiendo de cómo esté tu instalación de la base de datos esta pequeña guía servirá para:
  • Crear e inicializar un nuevo Wallet protegido mediante un dispositivo HSM. Si no tienes ninguna tabla o tablespace cifrado.
  • Migrar de un Oracle Wallet, que actualmente cifra tablas y tablespaces a un Wallet protegido mediante un HSM.

Al utilizar Oracle TDE, Yo recomiendo utilizar un fichero Wallet separada para almacenar la clave de cifrado principalLa integración entre el HSM y Oracle TDE utiliza la API criptográfica PKCS # 11. La integración ha sido probado con éxito en, y sólo se admite en las siguientes configuraciones:


Para integrar Oracle Database 11g Release 2 TDE con un HSM tendremos que pasar por las siguientes fases:
  • Instalar Oracle Database 11g Release 2 y aplicar los correspondientes parches.
  • Instalar el dispositivo HSM.
  • Instalar el software de soporte y configurar el HSM.
  • Configurar Oracle Database 11g Release 2 TDE para usar el HSM.

Nos centraremos únicamente en la configuración de la base de datos, dado, que los otros pasos se salen del ámbito de esta guía, instalar la base de datos es algo trivial y lo relacionado con los HSM de Thales  se salen de ámbito de este blog, para cualquier duda al respecto, deberéis consultar la web del fabricante, o consultar a algún experto.

Configurar Oracle Database 11g Release 2 TDE para usar el HSM


Copiar la librería  PKCS #11 localizada en  /opt/nfast/toolkits/pkcs11/libcknfast-64.so (o libcknfast.so dependiendo de la arquitectura de tu Sistema operativo) a una de las siguientes localizaciones dependiendo del sistema operativo:

    • Red Hat Enterprise Linux 5 (x86) /opt/oracle/extapi/32/hsm/libcknfast.so
    • Solaris 10 SPARC (64-bit) /opt/oracle/extapi/64/hsm/libcknfast-64.so
    • IBM AIX (PPC64) /opt/oracle/extapi/64/hsm/libcknfast-64.so
Asegúrese de que el directorio existe y que oracle: oinstall es el propietario:grupo del
directorio con acceso de lectura.

Agregue el usuario oracle al grupo nFast. Puede verificar esta adición al ver la entrada correspondiente el grupo nFast en /etc/group.

En el archivo $TNS_ADMIN /sqlnet.ora  añadir o editar las líneas siguientes, dependiendo de si está migrando desde un Oracle wallet:


Autentícate en la base de datos usando uno de estos comandos:
  • Si estás en la shell con UNIX: sqlplus / as sysdba
  • Si estás en SQL*Plus: connect / as sysdba

Cree la clave de cifrado principal dentro del HSM usando uno de los siguientes comandos, dependiendo de cómo desea proteger la clave y si está migrando desde un Oracle wallet:

Protección mediante una tarjeta del juego de operador de HSM (OCS):


Protección de clave OCS requiere una tarjeta OCS para ser insertada en la ranura del módulo. Debe Especificar el nombre de la tarjeta OCS después de la clave de esta,  para identificar una tarjeta OCS en particular en el dominio de seguridad del HSM. 
En el archivo cknfastrc, debe establecer CKNFAST_LOADSHARING = 1

Protección mediante una tarjeta "soft", tarjeta virtual:

Protección de clave soft debe especificar el nombre de la tarjeta soft después de la clave de esta, en el archivo cknfastrc, debe establecer CKNFAST_LOADSHARING = 1

Protección solo HSM:



Esta forma admite cualquier clave dada, únicamente ha de ser alfanumérica de 8 dígitos, en el archivo cknfastrc, debe establecer CKNFAST_FAKE_ACCELERATOR_LOGIN=1


ASO y Oracle Database Vault (Prueba de concepto)

Hasta ahora hemos intentado cubrir ataques externos que vulneren la confidencialidad de nuestros datos, por eso ciframos los datos almacenados, mediante ka tecnología TDE de Oracle, pero la amenaza interna es la mas peligrosa y los DBAs, se han convertido por, culpa de algunos ejemplos de mala praxis, en fuente de inseguridad. Las regulaciones como Sarbanes-Oxley (SOX), la Ley de Portabilidad y Responsabilidad de Seguros de Salud (HIPAA), Basilea II y PCI-DSS tienen temas comunes que incluyen controles internos, separación de tareas y estrictos controles de acceso a la información sensible



Un buen CISOque los hay, recomendaría usar políticas severas de auditorias a los superusuarios, como sysdba y sysadmin y para evitar a priori cualquier tentación recomendaría usar Oracle Database Vault, este producto brinda controles de seguridad flexible, transparente y altamente adaptable sin realizar cambios en la aplicación.

Pero Oracle Database Vault y la opción TDE de cifrado de tablespaces no son suficientes para ocultar datos de los administradores base de datos. Vamos a demostrarlo.

Descripción del entorno de laboratorio
  • OS Oracle Linux Server release 6.3
  • Database Oracle Database 11.2.0.4 EE with Database Vault and Transparent Data  Encryption


Detalles de la prueba de concepto
Queremos demostrar que ODV and TDE for tablespaces puede no ser suficiente para proteger los datos sensibles del “todopoderososysdba. En este pequeño experimento hemos usado el esquema de ejemplo HR y su tabla EMPLOYEES para ilustrar esta incidencia en la seguridad de nuestros datos.

Vamos a suponer que mis datos sensibles son, por ejemplo, los números de teléfono de los empleados. He creado un ámbito (realm) que protege esquema HR conjunto, por lo que SYSDBA no tiene acceso a ella.

SQL> select user from dual;
USER
-----------
SYS
SQL> select count(1) from hr.jobs;
From hr.jobs
           *
ERROR at line 2;
ORA-01031: insufficient privileges

La base de datos que estamos usando se ha habilitado el AMM (Gestión automática de la memoria de la SGA de la base de datos)

SQL> show parameters memory_target;

NAME                                TYPE                    VALUE
-------------------------           -------------              -----------------
Memory_target                 big integer             1520M
SQL>

La tabla Employees esta en un tablespace cifrado, así que acceder al datafile no es posible.

SQL> select table_name, t.tablespace_name, ts.encrypted from DBA_TABLES, t,
2  DBA_TABLESPACES ts where t.tablespace_name=ts.tablespace_name and t.owner=’HR’ and
3   t.table_name=’EMPLOYEES’;

TABLE_NAME                                   TABLESPACE_NAME                              ENC
--------------------------                           ---------------------------------                          ---------
EMPLOYEES                                     EMPLOYEES_AES128                            YES

Cuando estoy usando AMM en Linux, la memoria está representada por los archivos en  /dev/shm, que se puede comprobar mediante los comandos ipcs y lsof.

  • lsof (Lista de archivos abiertos, en español) es una conocida herramienta de monitorización de sistemas operativos tipo Unix que se utiliza para mostrar todos los archivos de disco que mantienen abiertos los procesos, incluyendo los sockets de red abiertos, tuberías, entre otros tipos.
  • ipcs: proporciona información sobre los recursos ipc para los cuales el proceso de llamada tiene derechos de lectura



Ahora un usuario conectado como HR hace una consulta sobre EMPLOYEES:

SQL> select user from dual;
USER
-------------
HR

SQL> select phone_number from hr.jobs;

PHONE_NUMBER
----------------------------
650.507.9833
650.507.9844
515.123.4444
515.123.5555
.
.
.


Después de esta consulta que deberíamos tener los bloques del segmento EMPLOYEES copiados en el búfer cache. Ahora vamos a ver qué podemos hacer con él a nivel de sistema operativo sin ningún privilegio especial...

[oracle@dbaFhell]$ cd /dev/shm/
[oracle@dbaFhell]$ strings ora_orcl_* | egrep …^ {[0-9] {3}\.[0-9] {3}\.}\.[0-9] {4}$” | sort | uniq | tail -10
650.507.9833
650.507.9844
515.123.4444
515.123.5555


Conclusión
Cuando la base de datos Oracle está utilizando AMM en Linux (parámetro MEMORY_TARGET) Oracle Database Vault y TDE no es suficiente para mantener los datos confidenciales ocultos de administrador de base de datos

Si ellos saben lo que están buscando... y lo saben, ¿verdad?

25 agosto 2014

ASO y Oracle Wallet

ASO y Oracle Wallet

En estos días, cualquier organización “seria”, la protección de los datos es una de las prioridades principales, si no quieres tener problemas regulatorios con organismos públicos (Ley de Protección de Datos Española) o privados (PCI DSS, por ejemplo).

Si me pidieran proteger las bases de datos de una organización de ataques externos me plantearía una serie de medidas a tomar de manera inmediata.
  • Implementar un interfaz seguro de red.
  • Restringir el acceso a los servidores de base de datos, añadiendo restricciones por dirección IP.
  • Proteger las bases de datos añadiendo unos cortafuegos, normalmente dos y de compañías distintas.
  • Cifrar datos sensibles “at rest”, es decir almacenados en disco.
Usualmente como parte de un plan de recuperación de desastres de una organización, las copias de seguridad de la base de datos son almacenados fuera del recinto de la organización. Esto quiere decir que las cintas necesitan moverse de un sitio a otro, esta es la parte más vulnerable de la seguridad de los datos.

Para proteger los datos en este escenario, podemos proteger los datos mediante una clave, que reside fuera de la estructura de base de datos. Sin esta clave, todos los datos confidenciales cifrados serán de ninguna utilidad.  

Este problema se aborda en Oracle 10g R2. Para datos sensibles, podemos declarar que una columna como cifrada. Cuando se insertan los datos, se almacenan como cifrados. Cuando se recuperan, se descifran sobre la marcha. El usuario no sabe, lo que está ocurriendo en la capa de base de datos. También podemos cifrar los datos existentes, con sólo modificar la columna como cifrado. Esta función se denomina como "Cifrado de datos transparente" o  TDE (“Transparent Data Encryption”).      

Oracle Database 10g cifra los datos usando una clave maestra, la cual es almacenada en una localización segura llamada  wallet, que no es más que un fichero en el servidor de base de datos. La tabla de claves se almacena en el diccionario de datos. Oracle Database 10g genera un única tabla de claves cifrada para la tabla y la usa para cifrar las columnas.

Dado que los datos se almacenan encriptados, todos los componentes dependientes, como copia de seguridad y los registros archivados, etc. están también en formato cifrado.

Para usar TDE, necesitamos configurar el wallet de la base de datos. Podemos especificar la ubicación del wallet en $ORACLE_HOME/network/admin/sqlnet.ora

ENCRYPTION_WALLET_LOCATION =
 (SOURCE=
 (METHOD=file)
 (METHOD_DATA=
 (DIRECTORY=/u01/app/oracle/admin/DEVDB/wallet)))

Una vez definida la ubicación, tenemos que crear el wallet.

SQL> ALTER SYSTEM SET ENCRYPTION KEY AUTHENTICATED BY <”clave”>;


Nota: Las comillas dobles son obligatorias, la clave tiene que contener al menos un número y un carácter especial, tal y como nos lo pide el wizard de la consola GUI.


Este comando llevará a cabo las acciones siguientes
  • Crea el fichero wallet en la localización definida en sqlnet.ora, por ejemplo. /u01/app/oracle/admin/DEVDB/wallet.
  • Define la clave del wallet como “clave”.
  • Abre el Wallet para su uso.
$ /u01/app/oracle/admin/DEVDB/wallet> ls -al

-rw——- 1 oracle oinstall 1358 Ago 25 12:04 ewallet.p12


Si activa la función del wallet de auto-login, usted verá otro archivo

 $ /u01/app/oracle/admin/DEVDB/wallet> ls -al

-rw——- 1 oracle oinstall 1358 Ago 25 12:44 ewallet.p12

-rw——- 1 oracle oinstall 1366 Ago 25 12:44 cwallet.sso


Esta es una copia de su fichero wallet, pero en un formato cifrado / propietario. El archivo cwallet.sso no requiere una contraseña para abrir, y puedes abrirlo con el proveedor de Oracle PKI (Infraestructura de clave pública) en java. También puede abrir el archivo ewallet.p12 utilizando el proveedor de PKI, pero ese archivo sí requiere una contraseña para abrir. El uso del archivo cwallet.sso significa que usted no tendrá que guardar la contraseña en texto plano en cualquier lugar, por lo que lo hace más portátil.

El wallet debe de estar abierto explícitamente, después del inicio de la instancia de base de datos.

SQL> ALTER SYSTEM SET ENCRYPTION WALLET OPEN AUTHENTICATED BY “clave”;


De lo contrario si el wallet no está abierto, incluso el propietario de la tabla no es capaz de seleccionar los datos y recuperarlos

ERROR at line 1:
 ORA-28365: wallet is not open


Podemos cerrar explícitamente el wallet mediante

SQL> ALTER SYSTEM SET ENCRYPTION WALLET CLOSE;


 Para el cifrado de los datos, podemos simplemente utilizar

SQL> ALTER TABLE EMP MODIFY (SAL ENCRYPT);


 Los detalles de la columna cifrada son almacenados en DBA_ENCRYPTED_COLUMNS

SQL> SELECT * FROM DBA_ENCRYPTED_COLUMNS;

OWNER TABLE_NAME  COLUMN_NAME ENCRYPTION_ALG   SAL
 ------------ ---------------------  ------------------------- -----------------------------   --------------
 SCOTT         EMP                 SAL              ES 192 bits key        NO



Nosotros podemos también cambiar la clave usando  ALTER TABLE con la cláusula REKEY.


La consola visual de Oracle wallet se puede iniciar en  $ORACLE_HOME/bin/owm


Hay otros datos a tener en cuenta a la hora de implementar TDE en tu organización:
  •  Impacto de rendimiento de las sentencias SELECT & INSERTEn el momento de la inserción, se tiene que leer la clave de cifrado de la cartera, cifrar los datos y luego escribir. Enfrente, en caso de recuperación de datos. Se tiene que descifrar los datos mediante la lectura de la clave de cifrado desde el monedero. Estas operaciones tendrán alguna sobrecarga de rendimiento. Pero es mucho mejor que perder la confianza y los datos del cliente. 
  • Coste adicional en la licencia. TDE está considerado parte de Oracle Advanced Security, así que no hay coste de licenciamiento adicional. 





Sigueme en Google+



18 julio 2014

¿Qué es Oracle Advanced Security Option?



Oracle Advanced Security es una opción de seguridad de la BD para Oracle Database 11g. Liberada desde la versión Oracle8i, Oracle Advanced Security combina capacidades de Cifrado en red, base  de datos y autenticación fuerte todos juntos para ayudar a resolver los retos de las compañías en cuanto a requerimientos de privacidad cumplimiento:  
1.       Cifrado transparente de datos  TDE.
2.       Cifrado de Red  
3.       Autenticación fuerte  



TDE (Transparent Data Encryption)

TDE está diseñado para proveer a los clientes la habilidad de cifrar de manera transparente dentro de la base de datos sin impactar a las aplicaciones existentes. Retorna los datos en formato Cifrado podría impactar a las aplicaciones existentes. TDE provee la ventaja de Cifrar sin el impacto asociados a soluciones tradicionales de base de datos que típicamente requieren triggers  y vistas.
Oracle Database Vault puede ser usado para proteger los datos de las aplicaciones ante interacciones del DBA y otros usuarios privilegiados además de implementar robustos controles sobre el acceso a la base de datos y la aplicación.
TDE no soporta Cifrado de columnas con restricciones en llaves foráneas. Esto se debe al hecho de que cada tabla tiene su propia y única llave de Cifrado.  
Los pasos para la configuración de Oracle TDE son los siguientes:
  • Identifica aquellas columnas que contienen datos sensibles.
  • Verifica que el tipo de dato soporta TDE.
  • Verifica que el dato no es parte de la clave foránea.
  • Cifra los datos nuevos y los ya existentes.

Identificar los datos sensitivos

Identificar información relacionada con datos PII (Personally Identifiable Information) tales como números de seguridad social y tarjetas de credito, se sugiere comenzar por una sencilla técnica en la que es fácil realizar búsquedas en el diccionario de datos de Oracle para encontrar nombres de columnas y tipos de datos que sean frecuentemente usados para almacenar esa información..


SQL> select column_name, table_name, data_type from dba_tab_cols where column_name like '%SOCIAL%'  or column_name like '%SSN%' or column_name like '%SECNUM%' or column_name like "%SOC%' and owner='<owner>';

Verificar soporte de datos TDE

TDE soporta la mayoría de los tipos de datos más comunes usados en la base de  datos, de los cuales se incluyen:  

  •  VARCHAR2 
  • CHAR
  •  DATE
  • NUMBER
  • NVARCHAR2
  • NCHAR
  •  RAW 
  • RAW SECUREFILES (LOBS)
  • BINARY_DOUBLE 
  • BINARY_FLOAT

SQL> create index cust_idx on customers (credit_card);

Cuando una columna indexada está para ser cifrada, se recomienda primero hacer drop de los índices existentes, cifrar la columna y finalmente reconstruir los índices. 

ORACLE DATAMASKING



Las organizaciones tienen la necesidad de compartir los datos de producción con los usuarios internos y externos para varios fines de negocio, como las pruebas de aplicación. Con Data Masking Pack, las organizaciones ahora pueden compartir la información interna de manera segura, y con los socios de negocio, y seguir cumpliendo con las regulaciones del gobierno. Los administradores de base de datos y seguridad de la información pueden mejorar su productividad al eliminar los procesos manuales y aplicar políticas de seguridad de la información a sus organizaciones.

¿Qué es para Oracle el concepto de Datamasking?

Oracle Enterprise Manager Data Masking Pack brinda una solución completa y fácil de utilizar para compartir los datos de producción con las entidades internas y externas al tiempo que se evita que ciertas partes sensibles o confidenciales de la información sean reveladas a entidades no autorizadas

Data Masking y Cumplimiento Regulatorio  

Resguardar los datos de producción y evitar la filtración de información confidencial o sensible a usuarios no productivos se ha vuelto un imperativo corporativo para todas las organizaciones– gracias al giro de regulaciones globales que gobiernan la privacidad de datos.

  • La Ley Sarbanes Oxley de 2002 en los EE. UU.
  • La Ley de Instrumentos Financieros (FIEL) de Japón (también denominada J‐SOX) brinda mejores estándares sobre los controles internos para la información corporativa. 
  • La Ley de Portabilidad y Responsabilidad de Seguros de Salud (HIPAA) de 1996 en los EE.UU.
  • La Directiva sobre la Protección de Datos en la Unión Europea son parte de las leyes globales que rigen la privacidad de los datos personales relacionados con los individuos. 
  • Incluso los procesadores de pagos con tarjeta de crédito han adoptado los estándares de la Industria de Tarjetas de Pago (PCI) respecto del uso y la distribución de información sobre tarjetas de crédito.  

Las organizaciones siempre han mantenido la información confidencial, personalmente identificable o sensible en sus bases de datos de producción. Estas organizaciones deben proteger el uso y la distribución de la información en cumplimiento con las regulaciones, o arriesgarse a las multas y penalidades que implica la violación a estas leyes sobre privacidad de datos. Estas multas y penalidades pueden ser de miles de dólares por día. En consecuencia, ninguna organización puede permitirse violar estas leyes y arriesgar la indigna publicidad causada por violaciones no autorizadas a los datos.

Oracle Data Masking Pack

Oracle Data Masking Pack puede ayudar a las organizaciones a cumplir con las leyes de privacidad y confidencialidad al enmascarar los datos sensibles o confidenciales en los entornos de desarrollo, prueba o staging. 

Data Masking Pack utiliza un proceso irreversible para reemplazar los datos sensibles con datos que parecen reales pero que están cancelados sobre la base de reglas de enmascaramiento, y garantiza que los datos originales no puedan ser recuperados ni restaurados. Oracle Data Masking Pack ayuda a mantener la integridad de la aplicación mientras enmascara los datos.

Definición de Enmascarado de datos

Las actuales aplicaciones empresariales tienen esquemas de base de datos muy complejos que contienen cientos o miles de objetos de base de datos. Los administradores tienen la desalentadora tarea, que a su vez consume mucho tiempo, de identificar todas las tablas y columnas que contienen información confidencial o sensible, y organizarlas en los formatos adecuados de enmascaramiento. Afortunadamente, Data Masking Pack facilita esta tarea mediante la función de búsqueda incorporada que permite que el administrador de seguridad de la información consulte todo el diccionario de datos a fin de identificar las columnas o tablas potenciales que contienen los datos sensibles.  

Proceso de Enmascarado de datos




Antes de iniciar el proceso de enmascaramiento, Data Masking Pack realiza una serie de pasos de validación para garantizar que el proceso de enmascaramiento de datos prosiga hacia un fin exitoso sin errores. Algunas de las verificaciones que realiza incluyen validar los formatos de enmascaramiento. Este es un paso necesario en el proceso de enmascaramiento de datos para garantizar que los formatos de enmascaramiento elegidos cumplan con los requerimientos dev integridad de las aplicaciones y la base de datos. Estos requerimientos pueden incluir la generación de valores exclusivos de la columna que se enmascara debido a restricciones de exclusividad o la generación de valores que cumplen con los requisitos de tipo y longitud de columna.  

Data Masking Pack utiliza un mecanismo altamente eficiente y sólido para crear datos enmascarados. Data Masking realiza operaciones en bloque para reemplazar con rapidez la tabla que contiene datos sensibles por una tabla idéntica que contiene datos enmascarados, y reteniendo al mismo tiempo las restricciones de la base de datos original, estructuras asociadas de acceso e integridad referencial, como ÍNDICES, PARTICIONES y permisos de acceso, como GRANTs.

A diferencia de los procesos de enmascaramiento que son tradicionalmente lentos debido a que realizan actualizaciones de tabla, Data Masking Pack aprovecha las optimizaciones incorporadas en la base de datos para desactivar el ingreso a la base de datos y lograr una ejecución en paralelo para crear rápidamente un reemplazo enmascarado de la tabla original. La tabla original que contiene datos sensibles se elimina completamente de la base de datos y ya no es accesible.  

Los administradores de base de datos cuentan con la flexibilidad de programar el proceso de enmascaramiento en una ventana adecuada para el mantenimiento, de manera que el proceso de enmascaramiento puede iniciarse justo después de que se haya clonado la base de datos de producción en un entorno staging. 

Para los DBA avanzados, Data Masking Pack proporciona la opción de guardar el proceso de enmascaramiento como un script de manera que se pueda personalizar más adelante, de acuerdo con las necesidades de su organización.


08 julio 2014

Monitorización en tiempo Real de SQL utilizando DBMS_SQLTUNE


Los informes de Real-Time SQL Monitoring se pueden encontrar dentro de las herramientas de Oracle en:
  • Enterprise Manager – Haz Click en la pestaña "Performance", entonces aparece el link  "SQL Monitoring" en la parte inferior derecho  de la página para dar paso a la ventana "Monitored SQL Executions". Haz click en las SQL_ID que te interesen para mostrar los informes de monitorización de SQL.
  • SQL Developer – disponible en el menu de  "Tools > Monitor SQL".
  • El paquete DBMS_SQLTUNE.

En este pequeño artículo voy a demostrar el uso del paquete DBMS_SQLTUNE para mostrar los informes de seguimiento de SQL sin utilizar las herramientas Enterprise Manager o SQL Developer. Este artículo ha incluido la funcionalidad adicional introducida en Oracle 12c.

SQL monitoring require que
  • El parámetro STATISTICS_LEVEL esté inicializado a 'TYPICAL' o 'ALL'
  • El parámetro CONTROL_MANAGEMENT_PACK_ACCESS esté inicializado a 'DIAGNOSTIC+TUNING'.


SQL> CONN / AS SYSDBA
Connected.
SQL> SHOW PARAMETER statistics_level

NAME                                                                      TYPE       VALUE
------------------------------------                                         -----------    ------------------------------
statistics_level                                                         string     TYPICAL

SQL> SHOW PARAMETER control_management_pack_access

NAME                                                                      TYPE       VALUE
------------------------------------                                          ----------- ------------------------------
control_management_pack_access                              string     DIAGNOSTIC+TUNING

SQL>


MONITOR Hint
El hint MONITOR habilita la monitorización SQL para sentencias, que de otra manera no las iniciaría.

SELECT /*+ MONITOR */ d.dname, WM_CONCAT(e.ename) AS employees
FROM   emp e JOIN dept d 
ON e.deptno = d.deptno
GROUP BY d.dname
ORDER BY d.dname;


REPORT_SQL_MONITOR


La función puede aceptar muchos parámetros opcionales, aquí puedes revisarlos, pero la mayoría que vas a usar están descritos como sigue: