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.

Novedades Oracle Database Cloud Service - Diciembre 2018

December 2018

Feature	Description
Updated notices of future deprecations and removals	Soon, Oracle Database Cloud Service (Database Classic on the My Services Dashboard), will drop the option to create database deployments on OCI regions. Oracle recommends creating new database deployments for OCI using the Oracle Cloud Infrastructure Database service (Database on the My Services Dashboard). This service offers database deployments on Bare Metal, VM, and Exadata. Cloud support for Oracle Database 12c Release 2 ends July 2020. Cloud support for Oracle Database 11g Release 2 ends December 2020. These actions apply to all cloud services: DBCS, ExaCS, ExaCC, and OCI Database. If you are using, or are planning to use, one of the release versions listed above, Oracle recommends that you plan an upgrade to a supported RDBMS release (for example, Oracle Database 18c or Oracle Database 12c Release 1) before services using Oracle Database 12c Release 2 or Oracle Database 11g Release 2 enter the unsupported state.
Cloud tooling update available for deployments hosting Oracle RAC databases	The 18.3.1 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 18331 when following the instructions Updating the Cloud Tooling by Using the raccli Utility in Administering Oracle Database Cloud Service.
October 2018 PSU, BP and RU patches available to apply to existing deployments	The October 2018 Patch Set Update (PSU), Bundle Patch (BP) and Release Update (RU) are now available to patch existing Database Cloud Service database deployments, provided that you use a command-line utility to apply the patch. Which of these patches you apply depends on the Oracle Database version of your deployment. Before you apply the appropriate patch, make sure your deployment has the latest version of cloud tooling, as described in Updating the Cloud Tooling on Database Cloud Service in Administering Oracle Database Cloud Service. For information about using command-line utilities to apply a patch, see these topics in Administering Oracle Database Cloud Service: For database deployments hosting a single-instance database, see Applying a Patch by Using the dbaascli Utility. For database deployments hosting an Oracle Data Guard configuration of single-instance databases, see Applying a Patch by Using the dbpatchmdg Utility. For database deployments hosting an Oracle RAC database or Oracle Data Guard configuration of Oracle RAC databases, see Applying a Patch by Using the raccli Utility and provide the tag value for your database version: 28659165 for Oracle Database Release 18c 28672345 for Oracle Database Release 12.2 28349951 for Oracle Database Release 12.1 28429134 for Oracle Database Release 11.2

Fuente: What's New for Oracle Database Cloud Service

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
/

Novedades Oracle Database Cloud Service - Noviembre 2018

November 2018

Feature	Description
Jul 2018 PSU, BP or RU integrated into base image for single-instance databases	The July 2018 PSU (Patch Set Update), 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 single-instance databases and Data Guard configurations with single-instance primary and standby databases. When you create such a database deployment, it will already include the PSU, BP or RU functionality.
Faster patching	Database Cloud Service patching time is now faster by approximately fifty percent.
New versions for SQL Developer Web, ORDS, APEX and ORE	New versions of several components have been integrated into the base image for single-instance databases: Oracle SQL Developer Web version 18.2.1 Oracle REST Data Services (ORDS) version 18.1.0 Oracle Application Express (APEX) version 18.1.0.00.45 Oracle R Enterprise (ORE) version 1.5.1

Fuente: What's New for Oracle Database Cloud Service

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. 

Oracle Critical Patch Update Advisory - Octubre 2018

October 16, 2018

The Critical Patch Update for October 2018 was released on October 16th, 2018.

Oracle strongly recommends applying the patches as soon as possible.

If you are new to this process, please review Oracle's Security Fixing Policies and the Critical Patch Update Advisory. After reviewing these resources, if you are unable to determine if you require a software update, or how to apply it, please contact Oracle Support.

The Critical Patch Update Advisory is the starting point for relevant information.
It includes the list of products affected, pointers to obtain the patches, a summary of the security vulnerabilities for each product suite, and links to other important documents. Supported products that are not listed in the "Affected Products and Components" section of the advisory do not require new patches to be applied.

Also, it is essential to review the Critical Patch Update supporting documentation
referenced in the Advisory before applying patches, as this is where you can find important pertinent information.

Critical Patch Update Advisories are available at the following location:

Oracle Technology Network: http://www.oracle.com/SecurityAlerts

Oracle Cloud Customers should review:
http://www.oracle.com/SecurityAlerts#cloud

The Critical Patch Update Advisory for October 2018 is available at the following location:

Oracle Technology Network:
http://www.oracle.com/technetwork/security-advisory/cpuoct2018-4428296.html

Important information can also be found at:
https://blogs.oracle.com/security/

Oracle's Security Fixing Policies are available at the following location:

http://www.oracle.com/support/assurance/vulnerability-remediation/security-fixing.html

The next four dates for Critical Patch Updates are:

• January 15, 2019
• April 16, 2019
• July 16, 2019
• October 15, 2019

Oracle Critical Patch Update Advisory - October 2018

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.

Novedades Oracle Database Cloud Service - Septiembre 2018

September 2018

Feature	Description
New short name for Oracle Database Cloud Service in My Services	As of late September, 2018, the short name used by the My Services console for Oracle Database Cloud Service changed from Database to Database Classic. Also, the short name for the Oracle Database cloud service that is specific to Oracle Cloud Infrastructure changed from Database (OCI) to Database.
Extreme Performance QuickStart option creates a single-instance database	Previously, when you used the Extreme Performance QuickStart option, Oracle Database Cloud Service created a database deployment hosting a clustered database using Oracle Real Application Clusters (Oracle RAC), housed on two compute nodes. Now, when you use the Extreme Performance QuickStart option, Oracle Database Cloud Service creates a database deployment hosting a single-instance database, housed on one compute node. For more information, see the Extreme Performance section of "Creating a QuickStart Database Deployment" in Administering Oracle Database Cloud Service.
Consolidated patching commands for deployments hosting an Oracle Data Guard configuration of single-instance databases	Previously, you used different command-line utilities with different subcommands and options to perform patching operations on the cloud tooling, database and OS software on deployments hosting an Oracle Data Guard configuration of single-instance databases. Now, all the patching operations across all these types of software are consolidated under a single command: dbaascli patch software action where software is db (database), os (OS) or tools (cloud tooling) and action is a patching operation like list or apply. When you create a new database deployment hosting an Oracle Data Guard configuration of single-instance databases, it will include these consolidated patching commands. To use these new commands in an existing deployment, you must first update the deployment's cloud tooling by running the following, now-obsolete command (as the root user) one last time: dbaascli dbpatchm --run -toolsinst -rpmversion=LATEST

Fuente: What's New for Oracle Database Cloud Service

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

Novedades Oracle Database Cloud Service - Agosto 2018

Agosto 2018

Feature	Description
"Bring Your Own License" now enabled by default	The "Bring Your Own License" (BYOL) feature is now enabled by default: When creating a QuickStart database deployment, the "Bring Your Own License" feature is now used. When creating a customized database deployment, the "Bring Your Own License" option is enabled by default. To create a database deployment that does not use the "Bring Your Own License" feature, you must create a customized database deployment and disable the "Bring Your Own License" option. For more information about the "Bring Your Own License" feature, see FAQ: Oracle BYOL to PaaS.
July 2018 PSU, BP and RU patches available in console	Last month, the July 2018 Patch Set Update (PSU), Bundle Patch (BP) and Release Update (RU) became available if you used a command-line utility to apply the patch. They are now available in the Oracle Database Cloud Service console as well. For information about applying database patches using the console, see Applying a Patch in Administering Oracle Database Cloud Service.
Simplified patching of Database Clustering with RAC and Data Guard Standby deployments	Previously, to check or apply a database patch to a deployment of two Oracle RAC databases as the primary and standby databases of an Oracle Data Guard configuration, you had to check or apply the patch separately to each of the Oracle RAC databases. Now, the raccli apply patch command includes the -dg option, which enables you to check or apply a database patch to both the primary and standby Oracle RAC databases. For more information, see raccli apply patch in Administering Oracle Database Cloud Service.
Oracle for Insurance Products certified for use with Database Cloud Service	The Oracle for Insurance solutions team has certified the following product components for use with Database Cloud Service deployments created using the Oracle Database 12c Release 2 software release and the Enterprise Edition - High Performance or Enterprise Edition - Extreme Performance software edition: Oracle Health Insurance components: OHI Components 2.17.2 and higher Oracle Insurance Policy Administration for Life and Annuity: OIPA 11.1.0 and higher Oracle Insurance Policy Administration for Group Benefits: OIPA 11.1.0 and higher

Fuente: What's New for Oracle Database Cloud Service

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/