Oracle 12C: Dos características interesantes en cuanto a seguridad

Hay muchas características nuevas en la base de datos de 12c que me gustan y que he discutido y hablado sobre ellas con varios colegas. Dos simples adiciones a la base de datos 12c hacen mi vida mucho más fácil en lo relativo a la seguridad de las bases de datos. El requisito era bloquear las cuentas de usuario que no hayan iniciado sesión en la base de datos durante 60 días consecutivos.

Last Login Time 

En las versiones anteriores a Oracle Database 12c (12.1) para averiguar cuándo un usuario inició sesión por última vez con éxito en la base de datos, debemos habilitar la auditoria de sesión, lo que conlleva cierta sobrecarga y el DBA debe configurar rutinas para limpiar la tabla de auditoria, etc. En 11g En la base de datos, tuve que habilitar la auditoría de sesión (mantener los registros de auditoria de la sesión durante al menos 61 días) y escribir un SQL que consultara a DBA_USERS y DBA_AUDIT_SESSION para enumerar a todos los usuarios activos que no usaron la base de datos durante 60 días.

En 12.1, Oracle registra automáticamente el tiempo de inicio de sesión exitoso en la tabla SYS.USER $ y está visible en DBA_USERS. La columna LAST_LOGIN de DBA_USERS muestra la última hora de inicio de sesión del usuario en la base de datos. En la base de datos 12.1, mi requisito se cumple al escribir un SQL simple contra DBA_USERS utilizando la columna LAST_LOGIN. No se requiere auditoria. El resultado se utiliza para crear SQL dinámico para bloquear cada cuenta mediante la instrucción ALTER USER ACCOUNT LOCK (similar a 11g).

Por cierto, notó que cuando inicie sesión en la base de datos utilizando SQL * Plus, también verá el último tiempo de inicio de sesión.

Bloqueo de cuenta inactiva

Mi requerimiento se automatizó completamente en la base de datos 12.2. Oracle introdujo el parámetro INACTIVE_ACCOUNT_TIME para los perfiles de usuario. El parámetro del perfil INACTIVE_ACCOUNT_TIME bloquea una cuenta de usuario que no ha iniciado sesión en la instancia de la base de datos en un número específico de días. El valor predeterminado para INACTIVE_ACCOUNT_TIME es 35. La configuración mínima es 15 y la máxima es 24855.

¿Cómo encontrar los metadatos de cualquier objeto en Oracle Database?

Normalmente nos vemos en la situación de necesitar definición de tablas, índices, vistas, etc. para replicar la estructura en otra base de datos. Oracle tiene un comando muy útil para encontrar la definición de metadatos de la estructura diversa. Este comando es muy útil para extraer los metadatos de cualquier objeto, como tabla, índice, vistas, vistas materializadas.

La salida de la consulta es de tipo de carácter large. Por favor, establezca la longitud length antes de comenzar la consulta.

Ejemplos variados:

Como es sabido, tenemos un comando para toda la creación de objetos en la base de datos Oracle. Este es un comando bastante poderoso y podemos usarlo para extraer la definición de tabla de todas las tablas en el esquema también.

¿Qué es Oracle Flex ASM?

No descubro nada si digo que Oracle Real Application Cluster (RAC) es un producto bien conocido entre las soluciones de Oracle para mantener una alta disponibilidad de los datos de cualquier negocio. Gracias a Oracle RAC puedes balancear la carga de trabajo, esta  se comparte entre todos los nodos del clúster, con la configuración de tolerancia N-1 en caso de fallas de nodo, siendo N es el número total de nodos. Desde las primeras versiones Oracle RAC está mejorando constantemente en cada versión y esta vez no fue diferente. 

La nueva versión 12.1.0.1 incorpora dos propiedades llamadas:

• Flex ASM
• Flex Cluster

,que dan soporte a los requisitos de demanda en entornos orientados a la computación en nube.

En la versión 12c Oracle RAC introduce dos nuevos conceptos:

• Nodos Hub: están conectados entre sí a través de una red privada y tienen acceso directo al almacenamiento compartido, al igual que las versiones anteriores. Estos nodos son los que acceden directamente al Oracle Cluster Registry (OCR) y Voiting Disk (VD).
• Nodos leaf: estos nodos son más ligeros y no están conectados entre ellos, ni acceden al almacenamiento compartido como los nodos de concentrador. Cada nodo hoja se comunica con el nodo concentrador que está conectado y está conectado al clúster a través del nodo concentrador vinculado. 

Esta topología permite que los servidores de aplicaciones débilmente acoplados formen un clúster con servidores de bases de datos estrechamente acoplados. Los servidores estrechamente acoplados son servidores centrales que comparten el almacenamiento para dispositivos de base de datos, OCR y Voiting Disk (VD), así como la comunicación de igual a igual con otros servidores centrales en el clúster. Un servidor débilmente acoplado es un servidor Leaf que tiene una asociación de comunicación suelta con un solo Servidor Hub en el clúster y no requiere almacenamiento compartido ni comunicación de igual a igual con otros Servidores Hub o Leaf en el clúster, excepto para comunicarse con el Hub al que está asociado. En la versión de Oracle database 12.1.0.1, los servidores Leaf están diseñados para una mayor disponibilidad de aplicaciones y administración de recursos de múltiples niveles.

Lo bueno de Flex ASM es que el bloqueo de una instancia de ASM no arrastra las instancias de base de datos en el host. Imagine un entorno de base de datos como servicio en, por ejemplo, una máquina Exadata X3-8,  esta máquina viene con 8s80c160t y 2 TB de memoria más 8 discos internos para binarios de Oracle. Esto debería ser una gran cantidad de equipos para consolidar sus bases de datos. 

Ahora imagina lo que sucede si la instancia de ASM se bloquea ... o mejor no.  Al introducir Oracle uzca Flex ASM puedes elegir el modo ASM durante la instalación de Grid Infrastructure 12c o habilitarlo más tarde. 

Antes de la puesta en marcha de Oracle 12c, para que una instancia de base de datos use ASM, se esperaba que la instancia de ASM esté funcionando en todos los nodos antes de que se active la instancia de la base de datos. Si la instancia de ASM no aparece, significa que la instancia de la base de datos que utiliza ASM en el nivel de almacenamiento no se puede activar. Esto implicaliteralmente que no se puede acceder a la instancia de la base de datos sin importar las tecnologías puestas en uso, es decir:

• RAC
• ASM
• almacenamiento compartido

Al lanzar Oracle 12c, la restricción anterior se abordó con la función denominada Oracle Flex ASM, que principalmente tiene una función para conmutar por error a otro nodo del clúster. 

Esencialmente una arquitectura de Hub y Leaf, la conexión de un nodo fallido se transfiere sin problemas a otro nodo participante mediante una instancia de ASM de reemplazo por Oracle Clusterware. El número de instancias de ASM que se ejecutan en un clúster dado se denomina cardinalidad de ASM con un valor predeterminado de 3. Sin embargo, el valor de cardinalidad se puede modificar con el comando Clusterware.

Mejores prácticas en Oracle Flex ASM

• Si tenemos un despliegue en modo mixto, recomendamos establecer la cardinalidad con el parámetro: ALL
• ¿Cuantas instancias ASM son necesarias?
• Para menos de cuatro nodos, una instancia ASM en cada nodo
• Para cuatro o mas nodos: Tres instancias ASM o todas si hay bases de datos pre 12c.
• ¿Cuantos Disk Groups son necesarios?
• 3 DATA, FRA y GRID
• GRID DG para OCR, Voting File, SPFILE
• Utiliza la redundancia externa para la mayoría de las matrices de almacenamiento de gama alta
• ¿Qué tamaño y cuántos discos hay en un grupo de discos?
• Discos mínimos: 4 veces el número de rutas para cada grupo de discos
• Grupo de discos de redundancia normal con rutas múltiples de 2 vías> = 8 discos
• Máximo: <1000 discos en un grupo de discos
• Tiempos de descubrimiento de disco largos y adiciones frecuentes de capacidad con demasiados discos

Oracle FLEX ASM

Arquitectónicamente, Oracle Flex Cluster se compone de una arquitectura de Hub y Leaf donde  los nodos de Hub únicamente tendrán acceso directo tanto a Oracle Cluster Registry (OCR) y al Voting Disk (VD). Sin embargo, la aplicación puede acceder a la base de datos a través de los nodos Leaf sin que la instancia de ASM NO se ejecute en los nodos Leaf. La conexión a la base de datos se realiza a través de Hub, lo que la hace transparente para la aplicación.

¿Cómo implementamos Oracle FLEX ASM?

• Pure 12c Flex ASM (misma versión)

• Tanto la infraestructura de Grid (GI) como la base de datos se ejecutan en Oracle 12c

• Pre Oracle 12c Mixto (diferentes versiones)

Como instancia normal de ASM, se ejecutará en cada nodo con la configuración de Flex para admitir la base de datos pre 12c. El parámetro de compatibilidad del grupo de discos ASM se utiliza para administrar la compatibilidad entre y entre las instancias de base de datos. La ventaja de este enfoque es que si una instancia de la base de datos Oracle 12c pierde conectividad con una instancia de ASM, entonces las conexiones de la base de datos cambiarán a otra instancia de ASM en un servidor diferente. Este failover se logra estableciendo la cardinalidad a todos.
Se han implementado algunas mejoras:

• Oracle Flex ASM admite tamaños de LUN más grandes para clientes de Oracle Database 12c.
• El número máximo de grupos de discos admitidos es 511, se ha aumentado desde 63.
• La reconexión de una instancia de base de datos hacia otra instancia de ASM es automática.
• La instancia de ASM usa Automatic Memory Management (AMM)
• Ningún parámetro especifico es requerido dentro de la base de datos para usar "Oracle Flex ASM".
• Ahora hay un comando para renombrar un "ASM Disk" en un "Disk Group".

Oracle RAC 12c con Oracle FLEX ASM 

La configuración estándar de Oracle FLEX ASM sería:

Error de instancia de ASM en la configuración de Oracle Flex ASM:

1. Autentícate en la instancia RAC (rac1)
[oracle@oel6-112-rac1 Desktop]$ hostname
oel6-112-rac1.localdomain

2. Comprueba el estado de las instancias de la base de datos de ASM y RAC
[oracle@oel6-112-rac1 Desktop]$ ps -ef | grep pmon
oracle    3325     1  0 17:39 ?        00:00:00 asm_pmon_+ASM1
oracle    3813     1  0 17:40 ?        00:00:00 mdb_pmon_-MGMTDB
oracle    5806     1  0 17:42 ?        00:00:00 ora_pmon_orcl1
oracle    6193     1  0 17:42 ?        00:00:00 apx_pmon_+APX1

3. Comprueba el estado de la instancia de ASM en las instancias de la base de datos de RAC desde la instancia 1 (rac1)
[oracle@oel6-112-rac1 Desktop]$ srvctl status asm
ASM is running on oel6-112-rac2,oel6-112-rac1

4. Comprueba el estado de Cluster en instance1 (rac1)
[oracle@oel6-112-rac1 Desktop]$ crsctl check cluster
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online

5. Comando para verificar si Oracle Flex ASM está habilitado o no (rac1)
[oracle@oel6-112-rac1 Desktop]$ asmcmd
ASMCMD> showclustermode
ASM cluster : Flex mode enabled
ASMCMD> showclusterstate
Normal

6. Comando para cambiar la cardinalidad del ASM (rac1)
[oracle@oel6-112-rac1 Desktop]$ srvctl status asm -detail
ASM is running on oel6-112-rac2,oel6-112-rac1
ASM is enabled.
[oracle@oel6-112-rac1 Desktop]$ srvctl config asm -detail
ASM home: /u01/app/12.1.0/grid
Password file: +DATA/orapwASM
ASM listener: LISTENER
ASM is enabled.
ASM instance count: 3
Cluster ASM listener: ASMNET1LSNR_ASM

7. Comando para verificar si Oracle Flex ASM está habilitado o no (rac2)
[oracle@oel6-112-rac2 Desktop]$ asmcmd
ASMCMD> showclustermode
ASM cluster : Flex mode enabled
ASMCMD> showclusterstate
Normal
ASMCMD> exit

8. Cómo cambiar la cardinalidad del ASM (rac2)
[oracle@oel6-112-rac2 Desktop]$ srvctl config  asm -detail
ASM home: /u01/app/12.1.0/grid
Password file: +DATA/orapwASM
ASM listener: LISTENER
ASM is enabled.
ASM instance count: 3
Cluster ASM listener: ASMNET1LSNR_ASM

9. Bajar la instancia de ASM en la instancia de la base de datos de RAC1 (rac1)
[oracle@oel6-112-rac1 Desktop]$ srvctl stop asm -node oel6-112-rac1 -stopoption abort -force

10. Comprueba el estado de la instancia de ASM en la instancia de la base de datos de RAC1 (rac1)
[oracle@oel6-112-rac1 Desktop]$ srvctl status asm
PRCR-1070 : Failed to check if resource ora.asm is registered
Cannot communicate with crsd

11. Comprobación del estado de los servicios de clúster en RAC Database instance1 (rac1)
[oracle@oel6-112-rac1 Desktop]$ crsctl check cluster
CRS-4535: Cannot communicate with Cluster Ready Services
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online

12. Verificación del estado de la base de datos de ASM y RAC en la instancia 1 (rac1)
[oracle@oel6-112-rac1 Desktop]$ ps -ef | grep pmon
oracle    3813     1  0 17:40 ?        00:00:00 mdb_pmon_-MGMTDB
oracle    5806     1  0 17:42 ?        00:00:00 ora_pmon_orcl1
oracle    6193     1  0 17:42 ?        00:00:00 apx_pmon_+APX1

Aquí, una instancia de base de datos está asociada con la instancia ASM específica que se ejecuta en el nodo específico. Si, por alguna razón, si la instancia de ASM no se pudo activar / los servicios se desactiva, la instancia de la base de datos se puede activar ya que la instancia de la base de datos buscará una instancia de ASM que se ejecute en el mismo grupo. La Figura 3 muestra la alta característica disponible de Flex ASM.

13. Compruebe el estado de la instancia de la base de datos de RAC que se ejecuta sin la instancia de ASM en la instancia de base de datos de RAC1 (rac1)
[oracle@oel6-112-rac1 Desktop]$ . oraenv
ORACLE_SID = [orcl1] ? orcl1
ORACLE_HOME = [/home/oracle] ? /u01/app/oracle/product/12.1.0/db_1
The Oracle base remains unchanged with value /u01/app/oracle
14. nicie sesión en la instancia de la base de datos desde la instancia de la base de datos RAC1 (rac1)
[oracle@oel6-112-rac1 Desktop]$ sqlplus /nolog
SQL*Plus: Release 12.1.0.1.0 Production on Wed Sep 25 18:24:36 2013
Copyright (c) 1982, 2013, Oracle.  All rights reserved.

SQL> connect sys/oracle@orcl as sysdba
Connected.

SQL> select instance_name,instance_number from gv$instance;


INSTANCE_NAME           INSTANCE_NUMBER
-------------------------------------------
orcl2                         2
orcl1                         1
SQL> select instance_name,instance_number from v$instance;


INSTANCE_NAME           INSTANCE_NUMBER
-------------------------------------------
orcl2                         2

SQL> connect sys/oracle@orcl as sysdba
Connected.

SQL> select instance_name,instance_number from gv$instance;

INSTANCE_NAME           INSTANCE_NUMBER
-------------------------------------------
orcl1                         1

15. Conexión a la instancia ASM de la instancia de la base de datos de RAC2 (rac2) desde la instancia de la base de datos de RAC1 (rac1)
[oracle@oel6-112-rac1 Desktop]$ . oraenv
ORACLE_SID = [orcl1] ? +ASM2
ORACLE_HOME = [/home/oracle] ? /u01/app/12.1.0/grid
The Oracle base remains unchanged with value /u01/app/oracle

[oracle@oel6-112-rac1 Desktop]$ asmcmd --privilege sysasm --inst +ASM2

ASMCMD> lsdg
State    Type    Rebal  Sector  Block       AU  Total_MB  Free_MB  Req_mir_free_MB  Usable_file_MB  Offline_disks  Voting_files  Name
MOUNTED  EXTERN  N         512   4096  1048576     15342     4782                0            4782              0             Y  DATA/
ASMCMD>

Oracle RAC 11.2 o anteriores con Oracle FLEX ASM 

Como se mencionó en la introducción anterior para Oracle 12c, la asociación de ASM a la instancia de la base de datos es de naturaleza específica. Esto significa que si una instancia de ASM no se pudo activar, entonces la instancia de la base de datos asociada en ese nodo / ASM no se puede activar, lo que hace que la base de datos sea inaccesible.

1. Inicie sesión en la instancia de RAC Database1 (rac1)

login as: oracle

oracle@192.168.xx.xx's password:

Last login: Fri Sep 27 06:05:44 2013

2. Compruebe el estado de las instancias de la base de datos de ASM y RAC:

[oracle@rac1 ~]$ ps -ef | grep pmon

oracle    3053     1  0 05:56 ?        00:00:00 asm_pmon_+ASM1

oracle    3849     1  0 05:57 ?        00:00:00 ora_pmon_flavia1

3. Comprueba el estado de la instancia de ASM en la instancia de la base de datos de RAC1 (rac1)

[oracle@rac1 ~]$ srvctl status asm

ASM is running on rac2,rac1

4. Comprueba el estado de Cluster en RAC Database instance1 (rac1)

[oracle@rac1 ~]$ crsctl check cluster

CRS-4537: Cluster Ready Services is online

CRS-4529: Cluster Synchronization Services is online

CRS-4533: Event Manager is online

5. Detén la instancia de ASM en la instancia de la base de datos de RAC1 (rac1)

[oracle@rac1 ~]$ srvctl stop asm -n rac1 -o abort -f

6. Compruebe el estado de la instancia de ASM en la instancia de la base de datos de RAC1 (rac1)

[oracle@rac1 ~]$ srvctl status asm

ASM is running on rac2

7. Compruebe el estado de la instancia de la base de datos de ASM y RAC (rac1)

[oracle@rac1 ~]$ ps -ef | grep pmon

oracle    7885  5795  0 06:20 pts/0    00:00:00 grep pmon

¿Oracle 18c for Exadata en Virtualbox? ¡Sí se puede!

El software Oracle Database 18c está disponible para las instalaciones de Exadata y se puede descargar desde aquí

• La versión 18c se dió a conocer en el mes de julio de 2018.
• Esto está en línea con la política de Oracle Cloud & Engineered Systems First.

Esta primera instalación de Oracle Database 18c ahora se está ejecutando en una VM de VirtualBox, está claro que solo vale para para jugar con las nuevas funciones.

El mérito del siguiente truco a añadir a nuestro grimorio no es mio sino de  @andrewlacy2.

Aquí están los pasos que he tomado:

• Como VM: Oracle virtual box OEL 7.4 instalación mínima
• ssh conectar como root a mi instancia de vbox
• configurar oracle yum repo
• yum install oracle-database-server-12cR2-preinstall   
• usermod -a -G vboxsf oracle #grant permiso para el acceso compartido de archivos vbox
• mkdir -p / u01 / app /
• chown oracle: oinstall / u01 / app
• su - oracle
• mkdir -p /u01/app/oracle/product/18.0.0/dbhome_1
• cd /u01/app/oracle/product/18.0.0/dbhome_1
• Descomprima /media/sf_CSoftware/Oracle/Ora18c/V974953-01.zip
• export DISPLAY = <my-vbox-ip>: 0.0
• export ORACLE_HOME = / u01 / app / oracle / product / 18.0.0 / dbhome_1
• cd $ ORACLE_HOME
• ./runInstaller & 

Sólo instalamos el software y luego creamos la base de datos mediante DBCA

• ./bin/dbca -createDatabase -initParams „_exadata_feature_on = true“

Et Voilá, ya tenemos una VM con una base de datos 18c con características EXADATA, para cacharrear. Ni que decir tiene los años luz, que estamos de un verdadero EXADATA amiguitos.

PL/SQL: Colecciones para crear funciones de parámetros variables.

Bueno, lo primero, feliz año 2019, iniciamos este año con una entrada en el blog el 2 de Enero, espero que sea un año de trabajo, el justo y bien pagado, ojala, para todos. Y sin más dilación al lío.

Si aparte de ser un tarado del PL/SQL y del mundo de base de datos Oracle le has dado caña a algún lenguaje, tal como C, java o incluso la abominación de c#, igual te has encontrado funciones que permiten un número variable de parámetros de entrada sin requerir un conjunto fijo de sobrecarga.

En C

En Java

PL/SQL no expone una sintaxis similar para funciones definidas por el usuario. Sin embargo, es posible pasar en una colección que contiene un número variable de valores para lograr la misma funcionalidad, aunque con una sintaxis "ligeramente" más voluminosa.

Tal función podría ser utilizada como sigue:

Una de las situaciones que resolví con esta técnica es un código que valida fechas de varios formatos y / o un constructor de fechas. Primero, necesitamos un tipo de colección. En el ejemplo anterior tuve una colección de enteros, en esta siguiente será una colección de valores Varchar2, definidos de la siguiente manera:

Y se invoca como sigue:

A menudo, cuando construyo este tipo de funciones, incluyo+ un parámetro opcional para proporcionar un manejo alternativo de errores. Por ejemplo, devolver un mensaje definido por el invocador a excepción, o devolver NULL.

Entonces podemos usar la función con éxito o resultados diferentes en caso de fallo.

Con estos mimbres, puedes ampliar tus propias funciones con colecciones de entrada de fechas, números, tipos definidos por el usuario o incluso valores ANYDATA.

Oracle Linux 7 Update 6, ya está aquí

Oracle anunció el pasado 18 de Octubre del 2018 la disponibilidad de la vista previa para desarrolladores de Oracle Linux 7 Update 6 como parte de nuestro objetivo continuo de hacer de Oracle Linux la distribución para el desarrollo.

La versión previa para "viciosos" (a.k.a. desarrolladores) de Oracle Linux 7 Update 6 incluye los siguientes paquetes de kernel:

• kernel-uek-4.14.35-1818.2.1.el7uek.x86_64

El Unbreakable Enterprise Kernel Release 5, que es el kernel predeterminado.

• kernel-3.10.0-933.el7.x86_64

El último kernel compatible con Red Hat (RHCK), antes de los tiempos oscuros antes del IBMperio.

Para comenzar a usar Oracle Linux 7 Update 6 Developer Preview, puede simplemente realizar una instalación nueva utilizando las imágenes ISO disponibles para descargar desde Oracle Technology Network.

O bien, puede realizar una actualización de una instalación existente de Oracle Linux 7 utilizando los canales de vista previa del desarrollador para Oracle Linux 7 Update 6 en el servidor Oracle Linux y la Red de Linux Unbreakable (ULN).

# vi /etc/yum.repos.d/public-yum-ol7.repo

[ol7_u6_developer]
name=Oracle Linux $releasever Update 6 installation media copy ($basearch)
baseurl=https://yum.oracle.com/repo/OracleLinux/OL7/6/developer/$basearch/
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle
gpgcheck=1
enabled=1

[ol7_u6_developer_optional]
name=Oracle Linux $releasever Update 6 optional packages ($basearch)
baseurl=https://yum.oracle.com/repo/OracleLinux/OL7/optional/developer/$basearch/
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle
gpgcheck=1
enabled=1

El servidor Oracle Linux yum se refleja dentro de Oracle Cloud Infrastructure para permitir descargas más rápidas. Sigue las instrucciones para configurar las réplicas del servidor Oracle Linux yum en Oracle Cloud Infrastructure.

Sigue este enlace para más información sobre los paquetes  proporcionados por la utilidad yum.

Modifica la configuración del canal yum y habilite los canales de vista previa para desarrolladores de Oracle Linux 7 Update 6. A continuación, realiza la actualización.

# yum update

Una vez completada la actualización, reinicie el sistema y tendrá ejecutada la versión preliminar de Oracle Linux 7 Update 6 Developer.

# cat /etc/oracle-release
Oracle Linux Server release 7.6

Recuerda que esta versión se proporciona solo para fines de desarrollo y prueba y no está cubierta por el soporte de Oracle Linux y la gente de Oracle y cualquiera con dos dedos de frente, NO recomienda el uso de este tipo de versiones en producción, solo para "jugar".

GDPR en el contexto de Oracle E-Business Suite

El Reglamento general de protección de datos (GDPR) de la UE entró en vigencia el 25 de mayo de 2018. Este nuevo reglamento afecta a todas las organizaciones, agencias gubernamentales y empresas de todo el mundo que recopilan o utilizan datos personales vinculados a residentes de la UE.

Un primer paso importante es determinar si la aplicación Oracle E-Business Suite está dentro del alcance de GDPR. Cualquier aplicación o base de datos que contenga información personal sobre ciudadanos o residentes de la UE está dentro del alcance de GDPR, incluidos, entre otros, clientes, empleados, trabajos de contingencia y proveedores. Las siguientes consultas SQL ayudarán a determinar si el entorno de Oracle E-Business Suite contiene datos de GDPR en el ámbito. Estas consultas no son definitivas, pero proporcionan, al menos, un punto de partida en el proceso de alcance del GDRP.

Recursos Humanos: Solicitantes, trabajadores eventuales, empleados

TCA: Clientes, Organizaciones, Personas, Grupos

Proveedores

 

Auditoría unificada en Oracle Database 12c

Una de las principales funciones de un DBA es implementar seguridad en la base de datos. Aunque si bien hay muchos aspectos relacionados a la aplicación de la misma, no siempre todos son utilizados en todos las empresas. Pero a pesar de esto, puede que un DBA no tenga que llegar a implementar una solución de autenticación basada en Kerberos pero siempre va a tener la responsabilidad de saber que está pasando en su base de datos. Es decir, quien se está conectado, que sentencias se están ejecutando, etc,.... La auditoria ha sido desde hace años la manera de satisfacer esta necesidad. No solamente es fácil de implementar y administrar, sino que además cubre todos los aspectos necesarios que un DBA tiene que cuidar cuando se trata de proteger su base de datos.

La política de auditoria unificada es como un grupo de opciones de auditoria con diferentes condiciones. Para habilitar la auditoria, primero debe crear una política con diferentes opciones de auditoria y luego debe habilitar o deshabilitar para todos o pocos usuarios, según los requisitos que tengamos. Todos los registros de auditoria se almacenarán en la tabla UNIFIED_AUDIT_TRAIL. 

Por defecto, hay 7 políticas de auditoria que estarán presentes en una base de datos Oracle 12c.

En versiones anteriores a 12c, el DBA tiene a su disposición 5 tipos diferentes de  auditoria. Estas son:

Auditoria obligatoria: Este tipo de auditoria está siempre habilitada y monitoriza las operaciones que involucren el inicio o apagado de la base de datos. Además de estas acciones, en cualquier momento que alguien utilice los roles predefinidos del sistema SYSDBA, SYSASM o SYSOPER esa acción será auditada.

Auditoria estándar: Este tipo de auditoria se habilita con el comando de AUDIT cuando es necesario auditar sentencias SQL, privilegios, objetos de esquema, y actividades de red o multicapa. Este tipo de auditoria se define y controla completamente a nivel de base de datos.

Auditoria basada en valores: La auditoria basada en valores fue introducida para poder capturar los valores reales que se cambian cada vez que algún tipo de sentencia DML es ejecutada en todas o determinadas filas de una tabla. Este tipo de auditoria aprovecha la funcionalidad de los triggers de base de datos (construcciones PL/SQL que responden a eventos) para lograr este objetivo.

Auditoria de grano fino: La auditoria de grano fino se centra en una auditoria de nivel  mas granular y las acciones auditadas se capturan basándose en el contenido accedido o modificado. Se puede simplemente crear políticas para disparar eventos de auditoria cuando alguien trata de realizar acciones que responden a las condiciones especificadas en la definición de la política.

Auditoria SYS: Este tipo de auditoria en realidad permite monitorizar las actividades de un administrador del sistema. Los usuarios que se conecten como SYS serán auditados y los registros de sus acciones serán escritos en un archivo de sistema operativo para evitar que sean borrados de la tabla AUD$ dentro de la base de datos. El parámetro de inicialización AUDIT_SYS_OPERATIONS se utiliza para activar y desactivar la auditoria de SYS.

Auditoria mixta: por defecto está habilitada en 12c. Permite utilizar tanto la auditoria tradicional como los métodos de auditoria unificada. Es decir. Además de la auditoria tradicional, podemos usar todas las características de la auditoria unificada. Una vez que nos sentimos cómodos con el concepto unificado, podemos migrar la configuración de auditoria existente a una política unificada, podemos habilitar la auditoria pura.
Esto sirve como un buen mediador para un cambio fácil y sin problemas a la auditoria Unificada preferida.

Auditoria pura: una vez que se habilita la auditoria pura. No podemos utilizar los métodos de auditoria tradicionales.

• Valor: FALSE  -> AUDITORIA MIXTA
• Valor: TRUE   -> AUDITORIA PURA

¿Qué modo de auditoria unificado está habilitado para mi base de datos?

¿Cómo cambiar de una auditoria mixta a pura?

Políticas por defecto en la base de datos Oracle 12c:

Pero no todos están habilitados. Consulta AUDIT_UNIFIED_ENABLED_POLICIES para buscar, qué políticas están habilitadas.

Consulta para comprobar las opciones de auditoria incluidas en una política:

Incluso si no se crea una nueva política en la base de datos, la acción de auditoria de las opciones de auditoria anteriores se registrará en UNIFIED_AUDIT_TRAIL.

Eliminamos la política de auditoria:

Purgamos la pista de auditoria:

Migrar de Oracle 11g a Oracle 12c: ¿Qué hacemos con la auditoria?

Si estas pensando en migrar a Oracle Database 12c, sin importar el tipo de entorno implicado (desarrollo, prueba, certificación producción), una de las muchas decisiones que debes consolidar con tu equipo es definir qué hacer con la auditoria. La nueva característica más importante en esta área es la denominada Auditoría Unificada, que captura información de auditoria de diferentes fuentes, como por ejemplo registros de auditoria "normales" y FGA, contextos de aplicación, RMAN o DataPump más algunas otras y las almacena en un formato y lugar comunes. , que es de solo lectura, tabla particionada en el esquema AUDSYS, que reside de forma predeterminada en el tablespace SYSAUX y utiliza la función Oracle SecureFiles.

Afortunadamente, Oracle nos dio flexibilidad en cuanto a las opciones de migración disponibles. Por ejemplo, en 12c todavía es posible utilizar la auditoría tradicional, de manera similar a como lo haciamos en la versión 11g. Incluso existe la posibilidad de realizar auditorias de modo mixto, en las que se completan las pistas de auditoria tradicionales y unificadas. Por supuesto, usar solo un enfoque unificado también es posible.

Independientemente del modo que desees utilizar después de la migración, es una buena idea habilitar la auditoria unificada desde el principio, volviendo a vincular los binarios de la base de datos con el parámetro uniaud_on. Esto le permitirá evitar la no disponibilidad si decide realizar una auditoria unificada (o de modo mixto) en una etapa posterior. Utilice la siguiente consulta para encontrar si está correctamente habilitado:

Todos los parámetros de inicialización de auditoria utilizados anteriormente:

• audit_trail
• audit_file_dest
• audit_sys_operations
• audit_syslog_level

No tienen significado (en caso de usar solo auditoria unificada). Sin embargo, todavía están disponibles, ya que son necesarios para los modos tradicional y mixto.

Teniendo en cuenta las migraciones, también debe decidir qué hacer con los registros de auditoria antiguos. Incluso cuando la auditoria tradicional está deshabilitada, todavía existe la posibilidad de archivar y luego purgar los registros de auditoria de las pistas de auditoria tradicionales utilizando el paquete dbms_audit_mgmt, por lo que podría hacerse antes, durante o después de la actualización.

¿Qué debería convencerlo de que la auditoria unificada es una mejora significativa en comparación con el enfoque tradicional?

Probablemente la ventaja más importante está incorporada en la palabra "unificada": el hecho de que todos los registros de auditoria están disponibles a través de la vista unificada_audit_trail y en el caso de un entorno multitenant en la vista cdb_unified_audit_trail, que proporciona registros de auditoria de cada PDB (disponible solo en la raíz). Parece que Oracle ha analizado todas las opciones y características de auditoria disponibles en versiones anteriores y ha diseñado la auditoria unificada como más consistente, segura y más fácil de administrar. 

A partir de 12c, podría olvidarse del manejo diferente de los registros ubicados en aud $, fga_log $ o archivos del sistema operativo. Aún así, cuando la base de datos no se puede escribir (por ejemplo, cerrada, montada, abierta de solo lectura), los registros de auditoría se colocarán en archivos del sistema operativo (ubicados en $ ORACLE_BASE / audit / $ ORACLE_SID, que desafortunadamente parece no ser modificable). Se debe hacer de esa manera: es crucial para auditar operaciones como la conexión como sysdba, pero, por supuesto, no puede persistir en una base de datos que no se pueda escribir. Afortunadamente, actualmente existe la posibilidad de cargar archivos de auditoria ubicados en este directorio en la base de datos utilizando el procedimiento dbms_audit_mgmt.load_unified_audit_files. Posteriormente, podrían manejarse como otros registros de auditoria, sin la necesidad de implementar analizadores dedicados, etc.

Gestión de auditoria distinta, pero más sencilla

Hablando de una gestión de auditoria más fácil, debemos recordar no solo el manejo de los registros de auditoria, sino también la configuración de lo que se debe auditar. Es muy diferente en comparación con 11g, ahora se define en las políticas de auditoria. Podría tener muchas de estas políticas definidas y habilitarlas / deshabilitarlas de forma independiente, pero tenga en cuenta que, según la documentación de Oracle, la cantidad de políticas de auditoria habilitadas al mismo tiempo en la base de datos debe ser limitada.

Como puede encontrar en el archivo $ ORACLE_HOME / rdbms / admin / secconf.sql, hay 3 políticas de auditoría predeterminadas definidas para nuevas instalaciones de 12c: 

• ora_account_mgmt
• ora_database_parameter
• ora_secureconfig.

Solo el último está habilitado de forma predeterminada, pero es una buena idea borrar la configuración predeterminada y usarla como punto de partida para diseñar su propia política de auditoria. Al hacer eso, tenga en cuenta que hay una serie de actividades que se auditan obligatoriamente.

La administración en términos de acceso a los datos de auditoria también se simplifica, gracias a la introducción de dos nuevos roles, con nombres autodescriptivos: audit_admin y audit_viewer.

Desde el punto de vista de la seguridad, esta era una limitación bastante grande, que actualmente, como resultado del nuevo diseño  de la auditoria en la versión 12c de la base de datos, se ha eliminado.

PL/SQL: Server Result cache otra herramienta más en nuestro cinturón

Una característica desde Oracle 11g, el llamado Result Cache, es una herramienta poderosa que se puede usar para almacenar en la memoria resultados de consultas y funciones. La información almacenada en caché se almacena en un área dedicada dentro de la Shared Pool donde puede ser compartida por otros programas PL/SQL que realizan cálculos similares. Si los datos almacenados en este caché cambian, los valores que se almacenan en el caché pierden su validez. Esta función es útil para las bases de datos con sentencias que necesitan acceder a un gran número de filas y devolver solo algunas de ellas. Como puede ocurrir en tiendas online, bancos, etc, ...

La caché de resultados se configura utilizando el parámetro de inicialización result_cache_mode con uno de estos tres valores:

• auto: los resultados que deben almacenarse se resuelven mediante el optimizador de Oracle
• manual: Almacene en caché los resultados indicando la declaración usando la sugerencia result_cache | no_result_cache
• force: todos los resultados serán cacheados.

El paquete dbms_result_cache se usa para proporcionar las opciones de administración de DBA de la memoria utilizada tanto por la caché de resultados de SQL como por la caché de resultados de la función PL / SQL. Estos son los procedimientos y funciones del paquete dbms_result_cache:


A continuación se describe una descripción práctica de cómo utilizar estos procedimientos y funciones.

Para este ejemplo, la result cache de SQL se muestra y se explica cómo limpiar la memoria caché de resultados y cómo utilizar las sugerencias para corregir los resultados de una consulta en la memoria caché de resultados. Primero, eche un vistazo a los parámetros de inicialización del caché de resultados. Todos están configurados en sus valores predeterminados; por lo tanto, es necesario usar la sugerencia result_cache para mantener los resultados de las consultas en la memoria, ya que el parámetro de inicialización result_cache_mode es manual.

Ahora consulta las vistas de caché de resultados que proporcionan información como objetos en memoria, dependencias de relación y estadísticas de caché de resultados.

Seguimos con la comprobación

Ejecute la operación "flush" para eliminar todos los objetos de la memoria caché de resultados. Existe la opción de conservar o liberar la memoria y / o las estadísticas según sea necesario. Aquí se encuentran todas las posibilidades de vaciar el caché de resultados:

Es muy fácil mantener los resultados de las consultas en la memoria, pero presta atención a la columna de invalidaciones de la tabla v $ result_cache_objects. Esta columna muestra cuándo los resultados asociados a un objeto en la memoria dejan de ser válidos debido a una modificación de los datos.

El parámetro result_cache se usa para que los resultados devueltos por esta función se almacenen en la memoria caché hasta que se modifiquen los datos de la tabla de empleados, lo que invalidará los resultados almacenados en caché para esta función.

Analizador jerárquico PL / SQL en Oracle Database 11g

El paquete DBMS_HPROF proporciona una interfaz para perfilar la ejecución de aplicaciones PL / SQL. Proporciona servicios para recopilar los datos del perfilador jerárquico, analizar la salida del perfilador sin procesar y la generación de información de perfilado.

El generador de perfiles jerárquico PL / SQL se introdujo en Oracle 11g Versión 1 para permitir a los desarrolladores reunir y analizar datos de perfiles jerárquicos para programas PL / SQL. El generador de perfiles jerárquico consiste en el paquete DBMS_HPROF, que se siente similar a los paquetes DBMS_PROFILER y DBMS_TRACE, y la utilidad de línea de comandos plshprof para convertir la información de perfil en formato HTML.

DBMS_HPROF
El paquete DBMS_HPROF está instalado de forma predeterminada, pero para usarlo debemos otorgar permiso de ejecución en el paquete y proporcionar un directorio para escribir la información del generador de perfiles sin formato.

Ahora podemos usar el generador de perfiles del usuario de prueba, pero para analizar los resultados, necesitamos instalar las tablas de perfil jerárquico en el usuario de prueba ejecutando el script:
"$ ORACLE_HOME / rdbms / admin / dbmshptab.sql".

Este script crea tres tablas y una secuencia en el usuario de prueba.

A continuación creamos algunos procedimientos ficticios para perfilar. El procedimiento haz_algo_1 llama al procedimiento haz_algo_2, que a su vez llama al procedimiento haz_algo_3.

A continuación, iniciamos el perfilador jerárquico utilizando el procedimiento START_PROFILING, ejecutamos el procedimiento haz_algo_1 y detenemos el perfilador usando el procedimiento STOP_PROFILING.

Con el perfil completo, podemos ejecutar la función ANALIZE para analizar los datos sin procesar y colocarlos en las tablas de perfiles jerárquicos.

La salida nos muestra el RUNID de la ejecución de análisis. También podemos encontrar esto en la tabla DBMSHP_RUNS.

Usamos el valor RUNID apropiado para consultar la tabla DBMSHP_FUNCTION_INFO

Podemos combinar esto con la información de la tabla dbmshp_parent_child_info para mostrar la vista jerárquica de los datos. para el RUNID específico.

En otra entrada de este blog, seguiremos con la función: plshprof