Oracle 12c: Nuevas características (New Features

Oracle 12c)

Pues bien , ya que salió la nueva versión de Oracle, era obvio que mencionáramos
algunas nuevas características..

Las más interesantes

Adaptive Query Optimization

El optimizador puede llevar a cabo una modificación de sus planes de ejecución aunque
estos ya se encuentren habilitados para la sentencia SQL, simplemente el CBO para los
planes en ejecución y los reanaliza para encontrar el "nuevo" mejor, está característica
es invisible al usuario y se hace de forma automática.
Lo anterior no significa que una sentencia quede a medio camino de ejecución, no...
simplemente se recalcula el mejor plan , para la siguiente ejecución.

Ejecución de comandos a nivel de prompt de RMAN

Oracle 12c nos permite ejecutar comandos a nivel del prompt de RMAN , esto sin la
necesidad de colocar la cláusula sql , además podemos ejecutar cualquier sentencia SQL
que queramos, no así pre-12c que estaban limitadas. La cláusula sql sigue estando
vigente.

Para más detalles ir a la nota

Estadísticas dinámicas
Durante la compilación de una sentencia SQL, el optimizador puede chequear todas las
estadísticas sobre las tablas de la sentencia SQL y puede decidir si las utiliza o no , si no
utiliza las estadísticas para una tabla en particular o alguna de esta no posee estadísticas,
Oracle generará estadísticas dinámicas con el método del Sampling, estás estadísticas
permanecerán hasta las subsiguientes ejecuciones de la sentencia y el optimizador las
puede utilizar cuando estime conveniente.

Estadísticas ONLINE para cargas BULK

Cuando se hace una carga de datos mediante un INSERT SELECT , CREATE
TABLES AS , para versiones anteriores de Oracle , había que tomar estadísticas de
forma manual a la nueva tabla , en cambio para nuestra nueva versión 12c, las
estadísticas son tomadas de forma automática, tal cual se hace para cuando se generan
los índices mediante el comando CREATE INDEX o REBUILD INDEX

Estadísticas privadas para las tablas temporales

Las estadísticas para las tablas temporales son únicas a pesar de que por cada sesión
hubiese data distinta, esto era hasta la versión 11gr2 , para la versión 12c de Oracle,
cada sesión tendrá sus propias estadísticas lo cual mejora ostensiblemente los tiempos
de ejecución , pues se mejora la performance al tener mejores datos estadísticos.

Integración con Grupos de procesadores a nivel de Sistema Operativo

Esta característica permite especificar al DBA un parámetro llamado
PROCESSOR_GROUP_NAME , con lo cual se une una instancia de base de datos a
un conjunto de CPUs , esto mismo se puede hacer con el comando cgroups en Linux o
con un pool de recursos en Solaris.

¿Para qué ocupar está característica? Pues para parcelar un poco el uso de CPUs por
parte de una cantidad X de base de datos.

Arquitectura Multitenant
Las arquitecturas multitenant (multi-propietario) es una filosofía de software cada vez
más usada para aquellas empresas que dan servicios de SaaS (Software as a Service), el
principio básico de esto es el siguiente , una instancia del Software es ejecutada en un
servidor y desde aquí se da el servicio a múltiples clientes . Si lo pensamos del lado de
Oracle significa que cada cliente comparte un motor de datos, pero los datos de cada
cliente están totalmente separados uno de otros, o sea, colocamos muchas bases de datos
en un mismo lugar, todas operadas por un mismo RDBMS.

Toda esta arquitectura multitenant , hace que sea muy fácil para los clientes hacer una
consolidación de sus bases de datos y trabajar muchas como una.

Imaginémonos una consolidación de esquemas, para ahorrar motores, recursos y demás,

pero ahora para base de datos, cada base de datos se convierte en un Pluggable Database
y estás PDBs pueden ser agrupadas en contenedores (Container), con esto se pueden
compartir recursos de memoria , incluso se pueden compartir procesos backgrounds,
una PDBs puede ser desconectada y conectada desde y hacia cualquier contenedor de
base de datos. Incluso con esta característica, se puede parchar un contenedor y con ello
se parchan de inmediato múltiples PDBs.

Oracle Datapump soporta Database Consolidation

Dentro del soporte que da Oracle Datapump para lo que es Database Consolidation, se
nombra el FULL TRANSPORTABLE, que no es más que llevarse una base de datos
desde y hacia los contenedores.

Lo anterior implica que me puedo llevar una base no-CDB (Que no pertenezca a un
Container Database) hacía otra base no-CDB, o una PDB a una no-CDB, o una base no-
CDB a una PDB.

Respaldo y recuperación PDBs

RMAN puede trabajar sobre un CDB o sobre un PDB, como siempre se puede respaldar
un datafile o un tablespace, para dar soporte a todas estas nuevas características se
agregan las cláusulas PLUGGABLE DATABASE a los comandos RMAN.
PDBs Point in Time Recovery
Se pueden hacer recuperaciones de las PDBs en algún lugar del tiempo, lo que
comúnmente se llama point-in-time recovery

Resource Plans para PDBs

Oracle Resource Manager puede manejar los recursos a nivel de CDB y a nivel de PDB,
con esto el manejo se vuelve más dinámico y se pueden asignar y reasignar recursos de
forma más masiva

Exportar una vista como tabla con Oracle Datapump

Ahora se puede exportar una vista y Oracle deja la data de una vista en una tabla, antes
al exportar una vista, sólo se exportaba la definición, pero no la data.
Para más detalles ir a la nota

Opción de NOLOGGING con Oracle Datapump Import

Existe un parámetro para el import con el Datapump que deshabilita el logging para
cuando se está cargando data en una tabla, es la opción TRANSFORM con el valor
DISABLE_ARCHIVE_LOGGING, esto hace del proceso de import un proceso
muchísimo más rápido pues no se genera redolog, lo que se debe tener en cuenta es
sacar un respaldo después de finalizar el import.
Para más detalles ir a la nota

Oracle ASM Disk Scrubbing

Está es una nueva característica que chequea las corrupciones lógicas de los discos de
ASM y las repara de forma automática, esto sólo sucede cuando se crean grupos de
fallas, o sea, existe redundancia normal o redundancia alta.

Aplicación de los comandos ONLINE

A partir de Oracle 12c, los comandos que se pueden utilizar en forma ONLINE se han
ampliado, por ejemplo antes para borrar un índice se tenía que esperar a que este
estuviese no siendo utilizado, pues si así fuese daba el siguiente error

ORA-00054: resource busy and acquire with NOWAIT specified

Los comandos que se pueden ejecutar ONLINE a partir de Oracle 12c :

- DROP INDEX ONLINE

- DROP CONSTRAINT ONLINE
- SET UNUSED COLUMN ONLINE
- ALTER INDEX UNUSABLE ONLINE
- ALTER INDEX [VISIBLE | INVISIBLE]
Columnas invisibles
En Oracle 12c, podemos dejar una columna como invisible mediante el comando alter
table -nombre tabla- modify (-columna- invisible) , pero nosotros mismos controlamos
el cuándo ver esa columna , por ejemplo:

Cuando hacemos un DESCRIBE de la tabla, está columna no aparece, cuando hacemos

un SELECT * FROM de la tabla está columna tampoco aparece, incluso cuando
hacemos un INSERT INTO nos podemos saltar esa columna, simplemente no
incluyéndola en la lista de las columnas.
A través de SQL*Plus podemos setear el hecho de que aparezca una columna invisible,
para ello utilizamos el seteo

SHOW COLINVISIBLE ON|OFF

Para más detalles ir a la nota

Movimiento ONLINE de los datafiles

En release anteriores, para mover un datafile este se debía dejar OFFLINE , con todos
los problemas de servicio que esto podía acarrear, pues a partir de Oracle 12c, el
movimiento de los datafiles puede ser efectuado en forma ONLINE, sin pérdida de
servicio
Para más detalles ir a la nota

Creación de varios índices en las mismas columnas de una tabla

Múltiples índices pueden ser generados para un mismo set de columnas, con esto
evitamos el hecho de tener que eliminar índices en caso de haber efectuado alguna
migración, por ejemplo para los campos A,B,C de una tabla se pueden crear múltiples
índices, los índices pueden ser generados de acuerdo a la siguiente premisa

- B*Tree o Bitmap
- Unique o NoUnique
- De acuerdo al tipo de partición en que están involucrados los campos
La única condición es que sólo uno de ellos tiene que estar visible.

Dataguard Broker y las CDBs (Container Databases)

El DataGuard Broker de Oracle soporta todo lo relacionado a MULTITENANT
CONTAINER DATABASES (CDBs), sólo hay que tener en cuenta ciertas cosas :

- Cuando la base de datos primaria es una CDB , todas las bases StandBy en la
configuración del broker deben ser también CDBs
- Cuando una configuración de Broker es hecha en base a CDBs , todas las acciones del
Broker deben ser efectuadas a nivel de root , no a nivel de cada PDB (Pluggable
Database)
- Para administrar un ambiente MULTITENANT se debe tener el rol CDB_DBA

Conexiones sysdg y sysdba al Dataguard Broker

En versiones anteriores, la conexión al Dataguard debía ser hecha con el usuario
SYS/Password y la cláusula SYSDBA, pues hoy sólo se necesita indicar el usuario y
password de SYS, los usuarios que se conecten a la configuración del DataGuard
Broker, deben tener los privilegios de SYSDG o SYSDBA, por defecto Oracle intentará
conectar con SYSDBA

VALIDATE DATABASE a nivel de Dataguard

Si antes existía un comando BACKUP VALIDATE DATABASE a nivel de RMAN
para chequear la validez de ciertos respaldos, hoy en día existe un comando llamado
VALIDATE DATABASE [VERBOSE] para la configuración hecha a través de
Dataguard Broker, con esto se hace una validación más exhaustiva de los componentes
que forman parte de una configuración de Dataguard Broker

Por defecto Real-Time Apply en DataGuard

A partir de Oracle 12c, la configuración por defecto de Oracle Dataguard Broker viene
con defecto con Real-Time Apply, esto significa que las transacciones son
inmediatamente aplicadas a los archivos de Standby de Redo, más que la generación de
un archive y que este sea aplicado en el ambiente de StandBy

Retoma de las operaciones de Switchover

Cuando en Oracle 11gr2 teníamos algún problema durante el proceso de Switchover , el
proceso se tenía que hacer desde el principio, chequeando cada una de las partes de
nuestras bases de datos, de hecho alguna de las bases podía quedar en estado MOUNT y
no recuperando , a lo mejor la nueva primaria no podía quedar abierta, etc.
Pero a partir de Oracle 12c, las operaciones de Switchover pueden ser retomadas si se
caen en algún punto intermedio

Modificaciones al DUPLICATE DATABASE

En Oracle 11gr2 se puede usar la cláusula SECTION SIZE al momento de respaldar
una base de datos, con esto cada proceso (Channel) puede tomar una porción del tamaño
especificado para un datafile , con lo cual claramente se aceleran los procesos de
respaldo de una base.
Para el caso del DUPLICATE DATABASE en Oracle 12c, se puede también declarar
la cláusula SECTION SIZE, con lo cual el proceso de copia de una base también se
pueden ver acelerado
Esta cláusula de SECTION SIZE , también puede ser aplicada a los backups como
IMAGE COPY y a los backups incrementales.

Mejoras al comando RESTORE

A partir de Oracle 12c las operaciones de RESTORE se pueden hacer en modalidad
NETWORK, tal cual lo puede hacer hoy en día el comando DUPLICATE, o como lo
puede hacer un expdp

Recuperación de tablas con RMAN

Desde Oracle 12c en adelante ahora sí podemos hacer una recuperación de una tabla .
Con el nuevo comando RECOVER TABLE podemos restaurar y recuperar una o más
tablas desde respaldos RMAN ya sea que estén en Backups o en cintas.
Para más detalles ir a la nota

Límites de tamaño para la PGA

Cuando se habla de bases de datos CDBs (Containers Database) , se habla de
consolidación de bases sobre un hardware limitado, esta limitación de hardware hace
que tengamos que utilizar los recursos de una manera más óptima.
Por ende desde Oracle 12c aparece un nuevo parámetro llamado
PGA_AGGREGATE_LIMIT el cual limita la cantidad de PGA que una instancia
puede consumir.

Oracle RAT para Containers Database (CD

El RAT de Oracle también puede ser aplicado para las PDB que están en un CDB...o
dicho de otra forma, todas las bases de datos que están en un CLOUD

Una vez que se han tomado los datos estadísticos, se puede hacer un Database Replay
sobre el CDB y así poder medir de forma significativa los cambios hacía una nueva
estructura de base de datos

Oracle RAT con ASH

Desde Oracle 12c, los reportes que se saquen después del Database Replay contendrán
información de ASH , lo cual claramente ayuda en el análisis del testing de la nueva
infraestructura de base de datos.

Inventario consultable
Cada vez que queríamos saber los parches de nuestra base de datos, teníamos que irnos
al sistema operativo y ejecutar un opath -lsinventory , desde Oracle 12c, se adjunta un
nuevo package llamado DBMS_QOPATCH, con el cual se puede consultar a través de
SQL, los distintos parches aplicados a nuestra plataforma RDBMS

Oracle Flex ASM

Con Oracle Flex ASM se puede separar la instancia ASM desde los servidores de base
de datos, con ello se puede llegar a una estructura en donde un número X de servidores
con instancias ASM , puede otorgar servicio a un número N de servidores de bases de
datos.

Oracle Flex Cluster

Esta es una nueva arquitectura que permite un poco de fliexibilidad para lo que son los
nodos de un cluster, desde Oracle 12c, nace un nuevo concepto llamado Flex Cluster, en
esta nueva arquitectura nacen 2 conceptos los "Hub Nodes" y los "Leaf Nodes".
Los "Hub Nodes" son los nodos normales de un cluster, imaginense una arquitectura de
un RAC en 11gr2 , con 2 nodos y un Grid Infraestructure en ejecución, pues los "Hub
Nodes" son aquellos nodos que conforman el RAC y que están conectados "entre sí"
mediante el Interconnect.
Pues bien, los "Leaf Nodes" son aquellos nodos que se unen a los "Hub nodes" y que no
tienen que estar conectados a un Interconnect, sólo deben tener comunicación con un
"Hub Node" .
Los "Leaf Nodes" no requieren de acceso al Storage, esto se hace mediante un "Hub
Node",está arquitectura presenta un sinnúmero de ventajas ,como por ejemplo poder
colocar servicios en distintos nodos y de acuerdo a su carga de trabajo, quizás un
servicio no sea tan demandante, pues este se puede colocar en un "Leaf Node" o al
revés, sólo colocar en los "Hub Nodes" aquellos servicios que requieran un tiempo y
acceso al disco más rápido..

Respaldo en diskgroups del OCR

Antes de Oracle 12c, los respaldos del OCR eran llevados a cabo en el nodo master en
una ruta predefinida del S.O., desde Oracle 12c, estos respaldos pueden ser llevados a
cabo en Diskgroups, lo cual simplifica el trabajo de recuperación de un OCR

Soporte para IPv6

Los nodos del cluster pueden ser configurados con IPv6, con esto el SCAN esta
posibilitado de conectarse a las IPs VIP de la Grid Infraestructure.

Advanced Network Compression

La transferencia de datos a través de los servicios de Oracle Net ahora pueden ser
comprimidos, lo cual genera una mejora de performance, está compresión puede ser
definida en los siguientes niveles
- Connection level (connect string, URL)
- Service level (tnsnames.ora, ldap.ora)
- Database level (sqlnet.ora)

Restricciones para el privilegio SELECT ANY DICTIONARY

El privilegio "SELECT ANY DICTIONARY" ya no podrá tener accesos directos a
las vistas DEFAULT_PWD$, ENC$, LINK$, USER$, USER_HISTORY$ y
XS$VERIFIERS, o sea, con este cambio ya no se tendrá tan fácil acceso a password de
distintos usuarios o password de los dblinks, por ejemplo..

Información del último LOGIN a través de SQL*Plus

Cada vez que ingresemos a SQL*Plus nos mostrará cual fue nuestro último login a la
instancia , esto es posible debido a la información que se almacena en la tabla USER$
Para más detalles ir a la nota

Modificación de role RESOURCE

Se modifica el role RESOURCE para quitarle el privilegio UNLIMITED
TABLESPACE, con esto se mejora la seguridad completa de la base de datos, pues con
el rol UNLIMITED TABLESPACE se pueden ocupar recursos de una manera
incontrolada.

Privilegio SYSBACKUP
A partir de Oracle12c nace un nuevo privilegio llamado SYSBACKUP, con el se
pueden hacer actividades a través del comando RMAN , sin necesidad de tener
habilitado el rol SYSDBA, con esto separamos los roles desde la persona que hace la
administración de la base hasta la persona que lleva a cabo los respaldos.

Oracle user en Windows

Desde Oracle 12c, se da soporte a un usuario distinto de Administrador para poder
instalar y manejar las instancias Oracle, ¿que lindo cierto?

Columnas auto numéricas (IDENTITY)

Está es una característica bien agradable, tener una columna que se vaya incrementando
sola a medida que vamos insertando valores, pues está columna se conoce como
IDENTITY, la gracia está es que por debajo manera una secuencia Oracle, el problema,
pues es bien sabido los inconvenientes que poseen las secuencias en ambientes RAC
cuando se les declara como NOCACHE
Para más detalles ir a la nota
Aumento de largo en columnas varchar2, nvarchar2 y RAW
Antes de Oracle12c , las columnas varchar2, nvarchar2 y RAW sólo tenían un largo
hasta 4000 bytes, si queríamos columnas de un largo mayor, teníamos que por
obligación ocupar columnas de tipo CLOB o BLOB, pero en Oracle 12c nace un
cambio , esto se aplica mediante el parámetro MAX_STRING_SIZE, este parámetro se
cambia desde un valor STANDARD a EXTENDED y la base de datos puede soportar
hasta 32767 bytes para sus columnas varchar2, nvachar2 y raw. Una vez realizado el
cambio no se puede revertir.
Para más detalles ir a la nota

Nuevo utilitario de migración de set de caracteres DMU

Hasta Oracle 11gr2 , la manera de llevar a cabo una migración de caracteres en una base
de datos Oracle era mediante las herramientas CCSCAN y CSALTER, mientras la
herramienta CSSCAN analiza toda la base de datos y se le indica desde que set de
caracteres hacía que set de caracteres llevó mi data, con la herramienta CSALTER llevo
a cabo los cambios.

La documentación de CSSCAN y CSALTER

10gr2 :
http://docs.oracle.com/cd/B19306_01/server.102/b14225/ch12scanner.htm#i1005939
11gr2 :
http://docs.oracle.com/cd/E11882_01/server.112/e10729/ch11charsetmig.htm#NLSPG0
11

En Oracle 12c el utilitario DMU reemplaza al CCSCAN y CSALTER y presenta una

interfaz gráfica más amigable

Espero NOS sirva a todos