03 enero 2019

¿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.

02 enero 2019

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.

07 noviembre 2018

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".





    15 octubre 2018

    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

     

    12 octubre 2018

    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:



    07 octubre 2018

    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.






    04 octubre 2018

    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.



    03 octubre 2018

    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

    30 septiembre 2018

    Proceso en PL/SQL para matar sesiones en Oracle 11g RAC


    Alguna que otra vez, en tu que hacer diario, necesitas eliminar una sesión en una instalación Oracle database 11g RAC y más tarde, recibes un mensaje en el  que no se puede cancelar la sesión debido a que la sesión está conectada a una instancia diferente. Te tienes que conectar a esa instancia y matarla

    Comenzando con 11g, el fabricante incluyó el nombre de instancia en el comando de alterar el sistema (3º parámetro o @instance_id). Por lo tanto, para matar la sesión de bloqueo en cualquier nodo desde cualquier nodo que ejecutaría:



    Si ejecutamos nuestro código tenemos la siguiente salida:

    Ya puedes matar sesiones en un servidorRAC por instancia de este.




    Otra cosa interesante que hacer con la "tabla" DUAL

    Esta entrada en el blog es pequeña a modo de receta, veremos una aplicación que se puede usar con dual, aparte de las consabidas y ya habituales. A veces es bastante útil tener una consulta que siempre regresa a un cierto número de filas, imagina que te piden un informe que devuelva una fila para cada día del mes. El uso de DUAL y CONNECT BY le permite devolver tantas filas como sea necesario.
    Por ejemplo, esta consulta devuelve una fila para cada día del mes.

    En la siguiente imagen podemos ver como construir esta sentencia y su resultado en SQL DEVELOPER: