Optimizer with Oracle Database 18c

Uno de los componentes más importantes de la base de datos Oracle es el Optimizador o CBO, fascinante por su funcionalidad y complejidad actúa como el cerebro en la ejecución de instrucciones SQL, determinando el plan de ejecución más eficiente en base a la estructura de la consulta y la información estadística de los objetos subyacentes. Sin dudas, entender a fondo su funcionamiento es de vital importancia tanto para los DBAs como para los equipos de desarrollo.

Como toda nueva versión, Oracle Database 18c incorpora cambios y novedades a nivel Optimizador. Junto con el lanzamiento de este nuevo release se publicaron también varios “Papers” técnicos como ya comenté en una entrada anterior.

En uno de ellos, “Optimizer with Oracle Database 18c “, se presentan todas las nuevas funciones relacionadas con el optimizador y las estadísticas en 18c.  Se proporcionan además ejemplos simples y  fácilmente reproducibles para permitir  familiarizarse rápidamente con ellas, especialmente al momento de migrar desde versiones anteriores.

También se describe cómo se han mejorado las funcionalidades existentes destinadas a optimización de performance y administración. Lógicamente este documento describe lo anteriormente comentado a grandes rasgos, para profundizar más sobre estas características recomiendo consultar la documentación: https://docs.oracle.com/en/database/oracle/oracle-database/18/index.html.

Aquí se puede leer y descargar el paper: Optimizer with Oracle Database 18c

Ejecutando manualmente una "Optimizer Statistics Auto Task"

Bajo ciertas circunstancias puede ser necesario lanzar manualmente el job de recopilación automática de estadísticas del optimizador.  Esto es habitual en casos donde se está evaluando la performance de algún SQL o luego de depuraciones grandes de datos.

A partir de la versión 11g,  el mecanismo de ejecución de “Auto-Tasks” para tareas de mantenimiento, reemplazó la necesidad de gather_stats_job.

También  existe la posibilidad de forzar la ejecución manual (fuera de la ventana de mantenimiento) utilizando la siguiente sentencia:

SQL> exec DBMS_AUTO_TASK_IMMEDIATE.GATHER_OPTIMIZER_STATS

Para utilizar este comando es necesario el privilegio de DBA.

Esto le indica al subsistema "Automated Maintenance Tasks" iniciar un job para recolectar estadísticas, siempre y cuando no exista ya un job en ejecución.

Este caso puede darse si una ventana de mantenimiento está abierta en ese momento. Si el job es finalmente lanzado sin problemas, tendrá un nombre con el formato: ORA $ _AT_OS_MANUAL_nnnnnn (nnnnn son uno o más dígitos decimales).

Como comentaba, a diferencia de los jobs de mantenimiento automatizados normales , el job "MANUAL" no está directamente vinculado a una ventana de mantenimiento específica.

Introducing Oracle Database 18c

Como había comentado en la entrada anterior, ya está disponible para “Oracle Cloud” y “Oracle Exadata Cloud” la versión de Oracle Database 18c. Se trata simplemente de 12.2.0.2 con la nueva modalidad de nomenclatura.

Esta última versión liberada (como así también los futuros “releases” anuales) incorpora características y funcionalidades que la convierten en el componente principal de "Autonomous Database Cloud Services" anunciado por Oracle el año pasado.

Junto con el anuncio de la liberación de 18c se publicó un “Oracle White Paper” donde se analizan más a detalle algunas de las funcionalidades principales de esta versión, y como

estas pueden ayudar a los usuarios a mejorar aspectos críticos como  performance, escalabilidad, confiabilidad y seguridad. Tanto en ambiente transaccionales productivos o de "analytical" como en plataformas de desarrollo de aplicaciones.

Aquí se puede leer y descargar el paper: Introducing OracleDatabase 18c

Oracle Database 18c para Oracle Cloud y Engineered Systems

El viernes 16 de febrero Oracle liberó oficialmente Oracle Database 18c para “Oracle Public Cloud” y “Oracle Engineered Systems”. Esta es la primera versión del producto que incorpora el nuevo modelo de lanzamiento anual, bajo el cual, cada año será liberada una nueva versión junto con sus correspondientes actualizaciones trimestrales. Quien guste, puede encontrar más detalles sobre este cambio en la nota 2285040.1 de Oracle Support o bien en el blog de Mike Dietrich (el gurú del Upgrade).

A no desesperarse que Oracle Database 18c no es ni más ni menos que "Oracle Database 12c Release 2 12.2.0.2,  simplemente se ha cambiado la denominación para reflejar el año en que es lanzado el producto.

La idea de este modelo de lanzamiento anual, es la simplificación del proceso de parchado y/o upgrade introduciendo cambios, más pequeños y con mayor frecuencia, evitando de esta manera los potenciales problemas que acarrea una upgrade monolítico.

Por tal motivo, al tener categoría de parche, queda claro que no vamos a encontrar cambios trasendentales en la nueva 18c. Sin embargo, incorpora muchas pequeñas mejoras incrementales que resultan igualmente muy útiles, y que  en su mayoría están enfocadas en las tres características centrales de Oracle 12.2:

§  Multitenant

§  Database In-Memory

§  Oracle Database Sharding

Oracle Database 12.2: Reportes AWR a nivel PDB

Artículo publicado en Oracle Technology Network (OTN) en español -  febrero de 2018 

Introducción

Desde su aparición en Oracle Database 10g, Automatic Workload Repository (AWR) ha ido evolucionando constantemente con el correr de las versiones.

Oracle 12c introdujo un gran cambio en la arquitectura de la base de datos incorporando el concepto de “multitenant”.  En el primer release de 12c, los reportes de AWR solamente pueden ser generados a nivel “Container Database” (CDB). Esto nos impide, en cierta manera, poder analizar en profundidad el comportamiento de determinadas PDBs puntuales.
La versión 12.2 introduce una notable mejora en AWR,  la capacidad de poder correr snapshots  tanto a nivel CDB como de PDB cuando trabajamos en ambientes “multitenant”.

Esta nueva característica nos permite un diagnóstico más granular de problemas de performance focalizados en una PDB en particular, situación que resulta sumamente interesante y útil en soluciones DBaaS donde se espera que el rol de DBA tienda a ser el de un “pDBA” ( Pluggable Database Administrator), es decir un DBA responsable de la administración de una o varias PDBs en particular, pero que a nivel físico comparten recursos con otras en el mismo CDB.

Oracle Database 12.2: Acceso con EM Express a múltiples PDBs utilizando un único puerto

Una de las mejoras introducidas en Oracle Enterprise Manager Database Express ("EM Express") a partir de 12.2, particularmente para ambientes multitenant,  es la posibilidad de utilizar un único puerto o URL para acceder a cualquiera de las PDBs dentro de un CDB.

Cuando realizamos un inicio de sesión en "EM Express",  ahora podemos especificar  el nombre de una “pluggable database” lo cual nos permite ingresar directamente a la misma. El principal beneficio de esta nueva opción, es no tener que configurar más un puerto diferente por cada una de las PDB de la base de datos. En el caso que no indiquemos ninguna PDB durante el "logging", entraremos directamente al root container.

Veamos como funciona:

Usamos para ejemplificar un CDB (cdb12cr2) con una PDB (pdb12cr2) a la cual accederemos por "EM Express".

1) Primero identificamos el puerto utilizado por "EM Express" y verificamos el acceso “default” luego de la creación de una base.

Por defecto, el uso de esta nueva característica (único puerto para acceder a las "pluggables databases") viene deshabilitado. Por lo tanto no podremos acceder a la PDB hasta que no lo habilitemos.

Veamos qué pasa entonces cuando el acceso está deshabilitado e intentamos ingresar a la consola.

Como primer paso averiguamos cual es el puerto que está utilizando "EM Express". La URL de acceso tendrá la siguiente forma:

https://{database-hostname}:{portnumber}/em/

Para obtener el puerto utilizamos la siguiente consulta:

SQL> select dbms_xdb_config.gethttpsport() from dual;

DBMS_XDB_CONFIG.GETHTTPSPORT()

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

                          5500