Usando el "Last Login Time" para mejorar la seguridad de la base de datos

Es bastante común que en una base de datos Oracle tengamos la necesidad de saber si se están realizando conexiones con determinados usuarios. Esto puede ser por diferentes motivos, esquemas o usuarios creados y que nunca se han utilizado, empleados desvinculados, aplicaciones que se han migrado de base de datos pero sus esquemas originales aún permanecen, etc. Pueden existir muchas y variada razones.

Para poder detectar esto, sin necesidad de recurrir a la auditoria, desde la versión 12c Oracle comenzó a registrar el último inicio de sesión exitoso.

Esta información es almacenada en la tabla  SYS.USER $ y pueder ser consultada en la columna LAST_LOGIN de la vista DBA_USERS. Como ya mencioné, esta funcionalidad es independiente de la auditoria.

Cuando iniciamos sesión utilizando SQL*Plus, podemos ver esta información en el texto del banner.

[oracle@server01 ORADB12C][~]$ sqlplus test01

SQL*Plus: Release 12.1.0.2.0 Production on Sat Feb 13 06:31:51 2021

Copyright (c) 1982, 2014, Oracle.  All rights reserved.

Enter password:

Last Successful login time: Sat Feb 13 2021 06:31:01 -05:00

Connected to:

Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production

With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,

Advanced Analytics, Real Application Testing and Unified Auditing options

Diferencia entre "Session User" y "Current User"

En esta breve publicación voy a trata de explicar dos conceptos que en muchas oportunidades suelen confundirse (o por lo menos no quedan del todo claros). Estoy hablando de “session user” y “current user”.

En bases de datos Oracle, durante el tiempo de vida de una sesión, es muy probable que el usuario conectado utilice privilegios de diferentes usuarios. Esto sucede muy a menudo y de manera transparente (en el detrás de escena de la sesión). 

En todo momento, mientras esté viva la sesión, podemos identificar dos usuarios prinicpales: el usuario de sesión (“session user”)  y el usuario actual (“current user”). Estas dos identidades pueden referirse  al mismo usuario o pueden ser diferentes de acuardo al privilegio que se esté utilizando.

Veamos primero de que se trata cada uno de estos conceptos y posteriormente voy a usar un ejemplo para tratar de ilustrarlo.

Session user: Es el usuario con el que fue iniciada la sesión en la base de datos. Este usuario permanece sin cambios durante el tiempo de vida de la sesión. A veces se denomina también usuario de inicio de sesión. Podemos conocer cuál es, utilizando la función sys_context con el namespace USERENV(que hace referencia a la sesión actual) y el parámetro SESSION_USER: SYS_CONTEXT ('USERENV', 'SESSION_USER'). 

Si, por ejemplo, nos conectamos a la base de datos como USERS1, entonces el usuario de sesión será USERS1.

Current user: Es el usuario cuyos privilegios están actualmente activos. Este usuario puede cambiar a lo largo del tiempo de vida de la sesión. Podemos saber cuál es “current user” en determinado momento utilizando también la función sys_context con USERENV, pero en este caso con el parámetro ‘CURRENT_USER’: 

SYS_CONTEXT ('USERENV', 'CURRENT_USER').

Por ejemplo, si el usuario USER1 está ejecutando un procedimiento almacenado propiedad del usuario USER2, durante el tiempo que dure la ejecución del mismo, el usuario actual será USER2 y el usuario de sesión permanecerá sin cambios como USER1.(Cuando un usuario ejecuta un procedimiento o función, del cual no es propietario, y al cual se le han otorgado permisos  de ejecución, los privilegios del owner del procedimiento o función son activados). 

Oracle 21c: Common Mandatory Profiles

Oracle Database 21c incorpora la posibilidad de forzar restricciones en cuanto a la longitud y composición de las contraseña en las PDBs. Esto se puede realizar, creando un perfil mandatorio (“mandatory profile”) en el CDB raíz y aplicándolo luego a una, varias o todas las PDBs.

El perfil mandatorio, es un nuevo tipo de perfil genérico donde sólo pueden ser configurados los parámetros password_verify_function y password_grace_time para determinar la longitud de la contraseña. 
Para crearlo se utiliza la sentencia:

SQL> create mandatory profile ...

Este perfil agrega una verificación de longitud mínima de contraseña a los perfiles locales que están asociados con los usuarios de las PDBs por medio de una función de validación.

Definido en el contenedor raíz (CDB $ ROOT),  actúa como un perfil de usuario que está permanentemente activo. Los límites definidos en este, se aplican de manera adicional a los límites existentes del perfil que tenga asignado el usuario. Esto crea un efecto de unión ya que la función de verificación de complejidad de la contraseña del perfil mandatorio se ejecutará antes que la propia función (si es que la hubiera) del perfil asignado a la cuenta de usuario.

Esto quiere decir que la longitud de la contraseña definida en el perfil mandatorio tendrá prioridad sobre cualquier longitud de contraseña definida en otro perfil asociado al usuario.

Al poder ser creado o modificado solamente desde el CDB $ ROOT, un administrador de PDB no puede eliminar el requisito de complejidad de contraseña impuesto por el perfil mandatorio  facilitando de esta manera que los usuarios puedan establecer contraseñas más cortas e inseguras.

Perfiles para STIG y CIS en Oracle 21c

Con cada nueva versión de base de datos, Oracle mejora varios aspectos relacionados con la seguridad. En esta línea, con la versión 12.2 incorporó un nuevo perfil de usuario llamado ORA_STIG_PROFILE para cumplir con el estándar de configuración STIG (Security Technical Implementation Guide).

Este perfil aborda varios requisitos de STIG, como la necesidad de una función de complejidad de contraseña, tiempo de reutilización de las mismas, número máximo de intentos fallidos de login y algunos otros más.

La configuración de ORA_STIG_PROFILE en las versiones 12.2, 18c y 19c es la siguiente:

SQL> SELECT profile,resource_name,limit 

FROM dba_profiles 

WHERE profile='ORA_STIG_PROFILE' 

ORDER BY resource_name;

 

PROFILE                      RESOURCE_NAME                  LIMIT

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

ORA_STIG_PROFILE             COMPOSITE_LIMIT                DEFAULT

ORA_STIG_PROFILE             CONNECT_TIME                   DEFAULT

ORA_STIG_PROFILE             CPU_PER_CALL                   DEFAULT

ORA_STIG_PROFILE             CPU_PER_SESSION                DEFAULT

ORA_STIG_PROFILE             FAILED_LOGIN_ATTEMPTS          3

ORA_STIG_PROFILE             IDLE_TIME                      15

ORA_STIG_PROFILE             INACTIVE_ACCOUNT_TIME          35

ORA_STIG_PROFILE             LOGICAL_READS_PER_CALL         DEFAULT

ORA_STIG_PROFILE             LOGICAL_READS_PER_SESSION      DEFAULT

ORA_STIG_PROFILE             PASSWORD_GRACE_TIME            5

ORA_STIG_PROFILE             PASSWORD_LIFE_TIME             60

ORA_STIG_PROFILE             PASSWORD_LOCK_TIME             UNLIMITED

ORA_STIG_PROFILE             PASSWORD_REUSE_MAX             10

ORA_STIG_PROFILE             PASSWORD_REUSE_TIME            365

ORA_STIG_PROFILE             PASSWORD_VERIFY_FUNCTION       ORA12C_STIG_VERIFY_FUNCTION

ORA_STIG_PROFILE             PRIVATE_SGA                    DEFAULT

ORA_STIG_PROFILE             SESSIONS_PER_USER              DEFAULT

 

17 rows selected.

Oracle 21c: Novedades en la seguridad de la base de datos

Finalmente, Oracle Database 20c fué sólo un versión de "preview" y no va a existir oficialmente como release (de hecho ya no está disponible para prueba en el cloud de Oracle).

Por otro lado, los primeros dias de diciembre fue disponibilizada en Always Free Autonomous Database (solamente en las siguientes regiones: IAD, PHX, LHR, FRA) y Database Cloud Service (RAC y single-instance sobre VM; single-instance en "Bare Metal") la nueva versión Oracle Database 21c y su correspondiente documentación.

Se debe tener en cuenta que 21c es un "Innovation Release", con lo cual sólo estará soportada 2 años y medio a partir de su liberación, y no tendrá disponible soporte extendido.

En este artículo, mi colega Lisandro Fernigrini explica detalladamente las diferencias entre las versiones "Innovation Release" y "Long Term Support Release" para quien quiera comprender mejor estos conceptos.

En el post "What's new in Oracle Database 20c Security?" de febrero de este año, enumeraba algunas de las nuevas funcionalidades y cambios de comportamiento relacionados con seguridad, del (en ese momento) nuevo release 20c.

Que sucederá con ellas entonces? 

Pues, al haber sido 20c una versión de prueba, todas estas funcionalidades siguen presentes también en el nuevo release 21c.

A continuación, un breve resumen de las novedades más destacadas relacionadas con funcionalidades de seguridad para la nueva versión.

What's new in Oracle Database 20c Security?

A cloud preview of Oracle Database 20c was recently released and your documentation is also available.

Oracle Database 20c Documentation.

As usual, many changes are introduced (new features incorporated, behavior changes, deprecated and desupported Features, etc.)

Regarding to database security features, the most relevant things are:

Behavior Changes, Deprecated and Desupported Features:

It is important to take a look at these sections of the 20c documentation, to ensure that none of the security features we are using are affected.

Behavior Changes for Oracle Database 20c Upgrade Planning

• About Read-Only Oracle Homes

Deprecated Features in Oracle Database 20c

• Deprecation of Traditional Auditing
• Deprecation of Older Algorithms in DBMS_CRYPTO
• Deprecation of Enterprise User Security (EUS) User Migration Utility
• Deprecation of TLS 1.0 (Transport Layer Security

Desupported Features in Oracle Database 20c

• Desupport of DBMS_OBFUSCATION_TOOLKIT Package
• Desupport of DBMS_CRYPTO_TOOLKIT_TYPES and DBMS_CRYPTO_TOOLKIT
• Desupport of Oracle ACFS Security (Vault) and ACFS Auditing
• Desupport of ACFS Encryption on Solaris and Windows

Desupported Parameters in Oracle Database 20c

• Desupport of UNIFIED_AUDIT_SGA_QUEUE_SIZE
• Desupport of IGNORECASE Parameter for Passwords

Ya está disponible Oracle Key Vault 18.2

Ya está disponible para su descarga, instalación o actualización la versión 18.2 de Oracle Key Vault. OKV, como es denominado comúnmente, es una plataforma para la gestión de claves  de manera robusta, segura y totalmente compatible con los estándares del mercado. Permite almacenar, administrar y compartir de manera simple  “objetos de seguridad” tales como: claves de encriptación, Oracle Wallets,  Java Key Store(JKS), Java Cryptography Extension KeyStore (JCEKS) y credentialstores. Esto convierte a OKV en una excelente opción para centralizar las claves de seguridad de manera robusta en un ambiente principalmente nutrido de productos del Oracle Stack.

Desde el punto del DBA, sin lugar a dudas, es un producto que facilita muchísimo la gestión centralizada a nivel “corporativo” de las claves utilizadas por las bases de datos Oracle (también MySQL) tanto en ambientes on-premises como híbridos.  Según mi opinión, esto hace buenos aportes tanto al mundo de la administración (DBA) como al de la seguridad corporativa y gestión de riesgos.

Con la versión previa de Oracle Key Vault (18.1) se introdujo además una arquitectura de cluster “multimaster” que permite que distintos nodos geográficamente distribuidos brinden servicio, lo cual mejora notablemente la disponibilidad de las “claves”.

Con este nuevo release (18.2) se incorporan mejoras en la administración y seguridad del producto así como también una implementación más sencilla.

Dentro de estas mejoras y nuevas funcionalidades podemos encontrar:

1.) Rotación del certificado para el servidor OKV

OKV 18.2 introduce la capacidad de poder rotar los certificados del servidor OKV sin ningún tipo de “downtime” ni  intervención del lado de la base de datos, eliminando así la necesidad de actualizar los certificados de forma manual y volver a tener que enrolar  todos los “endpoints”.

Oracle CPU de Enero 2020 (Critical Patch Update)

El último CPU (Critical Patch Update) liberado el pasado martes 14 de enero, aborda 334 nuevas vulnerabilidades de seguridad en diversas familias de productos Oracle dentro de las que se incluyen: Oracle Database Server, Oracle Communications Applications, Oracle Construction and Engineering, Oracle E-Business Suite, Oracle Enterprise Manager, Oracle Financial Services Applications, Oracle Food and Beverage Aplicaciones, Oracle Fusion Middleware, Oracle GraalVM, Oracle Health Sciences Applications, Oracle Hospitality Applications, Oracle Hyperion, Oracle iLearning, Oracle Java SE, Oracle JD Edwards, Oracle MySQL, Oracle PeopleSoft, Oracle Retail Applications, Oracle Siebel CRM, Oracle Systems, Oracle Supply Chain, Oracle Utilities Applications, Oracle Virtualization.

Este CPU comprende aproximadamente un 35% de vulnerabilidades (Common Vulnerabilities and Exposures- CVEs) que no son propias de productos Oracle,  es decir,  de los 334 parches de seguridad proporcionados por este CPU, 117 son para CVEs de productos "non-Oracle", lo cual implica correcciones de seguridad para productos de terceros (por ejemplo, componentes de código abierto) que si son incluidos en las distribuciones tradicionales de productos de Oracle. En varios casos, el mismo CVE aparece varias veces en el “Critical Patch Update Advisory”, porque un componente con determinada vulnerabilidad (por ejemplo, Apache) puede estar presente en muchos productos Oracle diferentes.

El estándar CVSS v3 considera que las vulnerabilidades con un puntaje base de CVSS entre 9.0 y 10.0 tienen una calificación cualitativa de "Crítica". Las vulnerabilidades con un puntaje base de CVSS entre 7.0 y 8.9 tienen una calificación cualitativa de "Alta". Al igual que con el CPU anterior, la cantidad de CVEs que no son propias de Oracle,  representan una cantidad significativa de expuestos críticos y de alta gravedad: 27 de las 117 CVE que no son propias de productos Oracle, son por vulnerabilidades altas y críticas. Lo cual resulta significativo.

Oracle 18c: Como hacer un MERGE ONLINE de Particiones y Subparticiones

A partir de Oracle 18c tenemos la posibilidad de realizar un MERGE de manera ONLINE de particiones (y subparticiones) cuando estamos utilizando el feature de "Partitioning".
Veamos un ejemplo de como hacerlo:

Primero creamos una tabla para la demostración:
La table tiene tres columnas, una de ellas del tipo fecha particionada por rangos (BY RANGE)

create table vtas
(
nro_fc number,
fecha_vta date,
precio number
)
partition BY RANGE (fecha_vta)
(
partition vtas_q1_16 values less than (TO_DATE('01-APR-2016', 'DD-MON-YYYY')),
partition vtas_q2_16 values less than (TO_DATE('01-JUL-2016', 'DD-MON-YYYY')),
partition vtas_q3_16 values less than (TO_DATE('01-OCT-2016', 'DD-MON-YYYY')),
partition vtas_q4_16 values less than (TO_DATE('01-JAN-2017', 'DD-MON-YYYY')),
partition vtas_q1_17 values less than (TO_DATE('01-APR-2017', 'DD-MON-YYYY')),
partition vtas_q2_17 values less than (TO_DATE('01-JUL-2017', 'DD-MON-YYYY')),
partition vtas_q3_17 values less than (TO_DATE('01-OCT-2017', 'DD-MON-YYYY')),
partition vtas_q4_17 values less than (TO_DATE('01-JAN-2018', 'DD-MON-YYYY')),
partition vtas_futuro values less than (TO_DATE('01-JAN-2020', 'DD-MON-YYYY'))
)
ENABLE ROW MOVEMENT
/

Monitoreando el uso de indices de otros esquemas

La vista v$object_usage permite ver información de la utilización de indices sobre los cuales se ha activado la opción de monitoreo con:

alter index index_name monitoring usage;

Esta vista nos brinda info de aquellos indices monitoreados pertenecientes al propio schema con el cual se está corriendo la consulta.

 SQL> select index_name, table_name, monitoring, used from v$object_usage;

INDEX_NAME                     TABLE_NAME                     MONITORING USED
------------------------------ ------------------------------ ---------- ----
T1_IDX1                        T1                             YES        NO

Si queremos ver información de todos los indices monitoreados en la base de datos, o si simplemente necesitamos verificar uno o varios owners en particular. 

Podemos utilizar la siguiente consulta:

SQL> select
           u.name "owner",
           io.name "index_name",
           t.name "table_name",
           decode(bitand(i.flags, 65536), 0, 'no', 'yes') "monitoring",
           decode(bitand(nvl(ou.flags,0), 1), 0, 'no', 'yes') "used",
           ou.start_monitoring "start_monitoring",
           ou.end_monitoring "end_monitoring"
         from
           sys.obj$ io,
           sys.obj$ t,
           sys.ind$ i,
           sys.object_usage ou,
           sys.user$ u
        where
           t.obj# = i.bo#
           and
          io.owner# = u.user#
          and
          io.obj# = i.obj#
          and
          u.name in ('<OWNER>')
          and
          i.obj# = ou.obj#(+);

 owner      index_name     table_name        monitoring used start_monitoring    end_monitoring

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

TST1       T1_IDX1        T1                        no  yes 11/06/2018 13:09:24 11/06/2018 13:14:04

Nota: Lógicamente necesitaremos los privilegios necesarios de SELECT para acceder a las tablas de "sys" utilizadas y que la consulta se ejecute correctamente. 

ODC Appreciation Day: Minimizando contención con “scalable sequences” en Oracle 18c

Es la primera vez que participo en el Oracle Development Community Appreciation Day, promovido por Tim Hall  para contribuir con la comunidad publicando algo de información sobre la tecnología Oracle que utilizamos a diario. 

En mi caso, trataré en este artículo una nueva funcionalidad incorporada en el último release de Oracle Database 18c.

Con la versión 18.1, se ha introducido una nueva funcionalidad en la base de datos Oracle: Las  "secuencias escalables” o en inglés  "Scalable Sequences".

Se trata de la capacidad de poder crear secuencias escalables para mejorar el rendimiento durante la carga masiva de datos, en tablas que utilizan como claves el valor generado por una secuencia. Las secuencias escalables optimizan el proceso de generación de valores secuenciales mediante el uso de una combinación única del número de instancia y el número de sesión para minimizar la contención sobre los bloques “leaf” en índices durante cargas masivas. Esta es una de las pocas funciones que no es habilita automáticamente y requiere la intervención del DBA para garantizar que su implementación no afecte ni cambie la lógica de negocio necesaria.

Por su parte, desde el punto de vista de negocio, esta funcionalidad brinda una mejora notable en los procesos de carga masiva de datos al reducir, como comenté anteriormente, la contención generada al insertar  datos en tablas que utilizan valores de secuencia.

Al incorporar la capacidad de poder crear valores de secuencias con componente de instancia e identificadores de sesión agregados al valor propio de la secuencia, la contención en la generación  y en las inserciones en bloques de índice para los valores clave, se reduce significativamente. Esto significa que Oracle Database es aún más escalable para la carga de datos y puede admitir tasas de rendimiento en este tipo de operaciones todavía más altas.

Interpretando un "Explain Plan" (Parte I)

¿Qué es un explain plan?

Un explain plan es una representación de la ruta de acceso que el optimizador de Oracle Database toma cuando es ejecutada una consulta SQL en la base de datos. El procesamiento de una consulta SQL se puede dividir en 7 fases:

1-  Sintáctica:   se verifica la sintaxis de la consulta

2-  Semántica: comprueba que todos los objetos existan  y sean accesibles

3-  View Merging: se reescribe la consulta como join en tablas base en lugar de usar vistas

4-  Transformación de sentencias: se reescribe la consulta transformando algunas construcciones complejas en otras más simples siempre que sea posible (por ejemplo, subconsulta unnesting, in/or transformation, etc.). Algunas transformaciones usan reglas mientras que otras tienen un costo basado en estadísticas.

5-  Optimización: determina la ruta de acceso óptima para la consulta. El optimizador basado en costos (CBO) usa estadísticas para analizar los costos relativos de acceso a los objetos.

6-  Query Evaluation Plan (QEP): Se evalúan las diferentes opciones de acceso y se  genera el plan.

7-  QEP execution: Se llevan adelante la acciones indicadas en el plan de ejecución determinado.

Los pasos del 1 al 6 a veces se agrupan y se denominan 'parsing', fase de 'parseo' o simplemente análisis.

El paso 7 es la ejecución misma de la sentencia.

El  "explain plan" es fundamentalmente una representación de la ruta de acceso generada en el paso 6.

Una vez que se ha determinado el “access path” o ruta de acceso, éste se almacena en memoria en la “library cache”  junto con la sentencia correspondiente. Las consultas se almacenan en la “library cache” en función de una representación en hash del literal de la sentencia, este hash luego lo utiliza Oracle para ubicarla en memoria. Antes de realizar las fases 1-6 antes mencionadas para un SQL determinado, Oracle busca la sentencia en la “library cache” para ver si ya fue "parseada" y utilizar el plan ya generado. Primero aplica un algoritmo hash al texto del SQL en cuestión y luego se busca este valor hash en  “library cache”.  Si el hash coincide con alguno de los almacenados, se utilizará ese “Access path” o método de acceso para resolver la consulta. Este será siempre utilizado (para la misma consulta) hasta  tanto la misma vuelva a parseada. Dependiendo de las circunstancias, el plan de ejecución tal vez varie de un parseo a otro. (En futuros posteos veremos que determina que una consulta vuelva a ser parseada). 

Privilegios necesarios para ejecutar un Explain Plan

Como sabemos, una de las maneras que tenemos  para obtener el plan de ejecución de una sentencia SQL es utilizar  la cláusula EXPLAIN PLAN.  De esta forma podemos determinar el plan de ejecución que una base de datos Oracle esta utiliza o utilizará para la ejecución  de determinada instrucción SQL. El comando EXPLAIN PLAN, inserta una fila en una tabla especifica (output table),  con la descripción de cada operación correspondiente a  cada paso del plan de ejecución. También se puede utilizar EXPLAIN PLAN como parte de la herramienta SQL trace.

EXPLAIN PLAN también determina el costo de ejecutar la sentencia SQL. En el costo calculado, entran en juego diversas variables como por ejemplo el número de bloques leídos, tiempo de lectura, lectura simple o multibloque, ciclos de procesador, velocidad de CPU, etc. pero en definitiva es lo que hace que Oracle determine un plan de ejecución específico sobre todos los calculados.

En el software de instalación del motor de base de datos podemos encontrar un script de ejemplo con la definición de la output table (PLAN_TABLE). La tabla de salida que finalmente  utilicemos debe tener los mismos nombres de columna y tipos de datos que esta tabla. Por lo general , el nombre común de este script es utlxplan.sql en versiones anteriores a 10.2 y catplan.sql a partir de esta versión. Lo podemos encontrar en @?/rdbms/admin/

Agenda ODC Tour 2018 - Buenos Aires

Nuevamente los Grupos de Usuarios de la región y el apoyo de LAOUC organizamos el Oracle Developer Community Tour antes conocido como OTN Tour.
Los Grupos de Usuarios de América Latina somos pioneros en la realización de esta iniciativa que se ha replicado en todo el mundo.
El esperado encuentro ser desarrollará el día 9 de agosto en la Fundación UADE y con la participación de 21 speakers de nivel internacional difundiendo presentaciones de diversas áreas de interés: Base de Datos, Middleware, Java, MySQL, Virtualización, Linux, Docker, Cloud y Aplicaciones.
La agenda tentativa es la siguiente:

Inscripción aqui

Privilegios necesarios para generar reportes AWR

Resulta bastante común que bajo ciertas situaciones especiales, o en determinados proyectos, haya usuarios no administradores requieran la posibilidad de ejecutar reportes AWR de una base de datos para analizar distintas cuestiones.

Para permitir esto, aplicando el principio de “mínimos privilegios”, podemos construir un role de base de datos con los "grants" necesarios para poder generar los reportes, y asignarlo luego a los usuarios que lo necesiten.

Los privilegios necesarios para generar un reporte son los siguientes:

grant select on sys.v_$database to rol_exec_awr;

grant select on sys.v_$instance to rol_exec_awr;

grant execute on sys.dbms_workload_repository to rol_exec_awr;

grant select on sys.dba_hist_database_instance to rol_exec_awr;

grant select on sys.dba_hist_snapshot to rol_exec_awr;

Veamos un ejemplo de como hacerlo:

Vamos a crear primero un usuario (awrusr) con privilegios de connect y resource para simular el usuario que necesita correr los reportes AWR. 

[oracle@server01 ~]$ sqlplus / as sysdba

SQL> create user awrusr identified by oracle

     default tablespace users

     temporary tablespace temp;

User created.

ODC (Oracle Developer Community) Tour 2018 - Argentina

El próximo 9 de Agosto llega a la Argentina (Buenos Aires) la primera edición del ODC (Oracle Developer Community) Tour, que no es más ni menos que la evolución renovada del clásico OTN Tour, el cual desde hace ya varios años se viene realizando en nuestro país, organizado por AROUG (Grupo de usuarios Oracle de Argentina). Como siempre, vas a encontrar  los mejores especialistas del mundo en las diversas tecnologías Oracle:

Bases de datos, Middleware,Security, Integration,  Big Data, BI & Analytics, Developer tools (Java, APEX, PL/Sql, Microservices, Chatbots), Devops (Containers, etc), Open Source, Applications, etc.

En esta oportunidad el evento se realizará en:

Fundación UADE, Lima 775, C1073AAO CABA

Como verificar, habilitar y deshabilitar paralelismo SQL a nivel sesión

Para saber si está habilitada o no la ejecución de sentencias SQL con paralelismo en nuestra sesión,  podemos consultar la vista v$session. Con sentencias SQL me refiero a operaciones DDL, DML o consultas (queries). Necesitamos como mínimo tener privilegios de select_catalog_role o SELECT sobre la vista para poder hacerlo.

Los campos que nos muestran la información necesaria son:

PDML_ENABLED y  PDML_STATUS: Indican si las operaciones DML en paralelo esta habilitadas o no (ENABLE/DISABLE). Por defecto están deshabilitadas (DISABLED).

PDDL_STATUS:  Indica si está habilitado o no (ENABLE/DISABLE)  el paralelismo para sentencias DDL. Por defecto está habilitado (ENABLED).

PQ_STATUS:  Indica si el “parallel query” está habilitado o deshabilitado (ENABLE/DISABLE).  Por defecto está habilitado (ENABLED)

Veamos un ejemplo de como consultar la vista:

SQL> select PDML_ENABLED, PDML_STATUS, PDDL_STATUS, PQ_STATUS

           from v$session where sid = (select sid from v$mystat where rownum = 1);

PDML_ENABLED PDML_STATUS PDDL_STATUS PQ_STATUS

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

NO           DISABLED    ENABLED     ENABLED

Restaurando versiones previas de estadísticas (optimizer statistics)

En ciertos casos, es probable que luego de una actualización de estadísticas (en una o varias tablas y/o índices), el plan ejecución para ciertas consultas puede llegar a variar, ocasionando una posible degradación de la performance. Si bien está claro que las estadísticas “frescas” deberían a ayudar al optimizador (CBO) a seleccionar el mejor plan de ejecución posible, no siempre las cosas funciona de esta manera y por el contrario el rendimiento puede llegar a verse afectado. Si esta situación  ocurre  en un ambiente productivo, es probable que no tengamos mucho tiempo para analizar las causas  y determinar una posible solución.

Una buena opción para intentar  revertir el problema de manera rápida, es restaurar las estadísticas a valores previos.

Para esto, a partir de la versión 10g de Oracle Database, cuando nuevas estadísticas son tomadas en un objeto, los valores de la estadísticas anteriores son conservadas para que en el caso de ser necesario puedan ser restaurados.

Por defecto, el tiempo de retención de 31 días. Esto significa que serán conservadas todas las estadísticas tomadas durante ese periodo.

Podemos verificarlo con la siguiente consulta:

SQL> select DBMS_STATS.GET_STATS_HISTORY_RETENTION from dual;

GET_STATS_HISTORY_RETENTION

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

                         31

Si queremos modificar este tiempo de retención, podemos hacerlo ejecutando el siguiente procedimiento:

SQL> execute DBMS_STATS.ALTER_STATS_HISTORY_RETENTION (XXXX);

Novedades Oracle Database Cloud Service - Junio 2018

June 2018

Feature	Description
Cloud tooling update available for deployments hosting Oracle RAC databases	The 18.2.5 update to cloud tooling is available to apply to existing Database Cloud Servicedatabase deployments that host Oracle RAC databases. To apply this update, use the tag 1825 when following the instructions Updating the Cloud Tooling by Using the raccli Utility in Administering Oracle Database Cloud Service.
Apr 2018 BP or RU integrated into base image for Oracle RAC databases	The April 2018 BP (Bundle Patch) or RU (Release Update), depending on Oracle Database version, is now integrated into the base image for new Database Cloud Service database deployments that host Oracle RAC databases and Data Guard configurations with Oracle RAC primary and standby databases. When you create such a database deployment, it will already include the BP or RU functionality.

Fuente: What's New for Oracle Database Cloud Service

El evento de espera: "Buffer Exterminate"

Dias atrás, analizando un problema de performance en una sentencia SQL, me encontré con un evento de espera a tope de un reporte ASH el cual no es muy común ver:  "buffer exterminate".

Profundizando un poco más sobre la causa de este evento, su origen y su impacto, pude allanar bastante el camino hacia la resolución del caso.

El reporte mostraba los siguientes indicadores: