Archivo

Archivo del autor

Uso de SQL Performance Advisor durante los upgrades de BBDD Oracle

Entre las tareas a realizar cuando planificamos un upgrade de BBDD deberíamos incluir pruebas de rendimiento en el nuevo entorno. Estas pruebas nos pueden decir si el nuevo hardware, configuración y recursos asignados, así como la nueva versión del gestor, funcionan como esperamos.

db4

En lo que a rendimiento de las sentencias SQL se refiere, el comportamiento general al cambiar de una versión a otra superior es el mantenimiento o mejora; no obstante, en algunos casos puntuales se pueden producir regresiones (sentencias con un rendimiento peor que en origen).

En caso de que dispongamos de los packs de Diagnostics y Tuning podremos usar las funcionalidades de SQL Performance Analyzer (SPA) para revisar el comportamiento de las sentencias clave de nuestras aplicaciones en el nuevo entorno antes de realizar la migración real.

Podemos usar las funcionalidades de SPA tanto mediante una interface gráfica (con Enterprise Manager Cloud Control) o mediante la API PL/SQL del propio producto.

En este ejemplo usaremos la API de SPA para comparar los planes de ejecución de sentencias SQL entre un entorno origen 11g y un entorno destino 12c.

A grandes trazos vamos a capturar sentencias SQL en la BBDD de versión 11g, trasladar las sentencias y sus datos de rendimiento a la 12c y ejecutarlas nuevamente en la 12c para finalmente poder comparar ambas ejecuciones.

Las sentencias a analizar las almacenaremos en lo que se denomina SQL Tuning Set (STS), una estructura que almacena la sentencia, las bind variables, el plan de ejecución y los datos de rendimiento.

sts

En primer lugar deberemos escoger el método de captura de estas sentencias SQL en origen. Podemos capturar sentencias “al vuelo” desde la cache de cursores, del repositorio AWR, de otro SQL Tuning Set ya existente, de ficheros de traza (para versiones antiguas de la BBDD en las que no existían los STS) o indicar manualmente que sentencias deseamos que se incluyan en la captura.

Leer más…

Oracle Database Standard Edition 2 (SE2) – Licenciamiento y conversión desde SE/SE1

Oracle_DB_12c_SE2Desde el pasado mes de septiembre es posible descargar el parche 12.1.0.2 de Oracle Database Standard Edition. Este parche no sólo soluciona bugs detectados, sino que aporta gran cantidad de nuevas funcionalidades y hasta la fecha sólo estaba disponible para la versión Enterprise Edition.

Juntamente con la publicación del parche se notificó una modificación relevante del sistema de licenciamiento: desde el 01/12/2015 las versiones Standard Edition y Standard Edition One ya no pueden adquirirse y en su lugar ha aparecido en la tarifa de precios la nueva versión Oracle Database Standard Edition 2. Las versiones Enterprise Edition (EE) y Personal Edition (PE) no han sufrido variación alguna. Por tanto, ahora disponemos de las siguientes versiones de Oracle Database:

  • Enterprise Edition
  • Standard Edition 2
  • Personal Edition

Las licencias de Oracle Database Standard Edition 2 tienen el mismo coste que tenían las licencias de Oracle Database Standard Edition.

Vamos a revisar las normas de licenciamiento de Oracle Database Oracle Database Standard Edition 2 (SE2) y cómo afecta este nuevo licenciamiento a los clientes con licencias compradas de las versiones Standard Edition (SE) o Standard Edition One (SE1).
Leer más…

Restauración y mantenimiento de backups de Oracle Database en “la nube”


En este post anterior vimos cómo configurar los backups en el servicio de Cloud de Oracle. En esta entrada veremos cómo restaurar ficheros a partir de uno de estos backups y como administrar nuestros backups (básicamente como eliminar los que ya consideremos obsoletos).

Restauración de un backup

En este caso la única diferencia entre hacer una restauración de cinta o disco y hacerlo desde la nube será que deberemos especificar la clave de cifrado, tener configurado el Wallet de TDE o ambos según lo hubiéramos hecho durante el backup.

Partiendo del de backup usado en el anterior post (cifrado con una clave) lanzaremos una restauración de un fichero.

En primer lugar eliminamos el fichero de la BBDD, seleccionamos un tablespace y lo ponemos “offline”.


[oracle@centos1 ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.4.0 Production on Wed Oct 14 04:32:24 2015

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


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Data Mining and Real Application Testing options

SYS @ one > select tablespace_name,file_name from dba_data_files;

TABLESPACE_NAME
------------------------------
FILE_NAME
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
USERS
+DATOS/one/datafile/users.257.848555587

UNDOTBS1
+DATOS/one/datafile/undotbs1.258.848555587

SYSAUX
+DATOS/one/datafile/sysaux.259.848555585

SYSTEM
+DATOS/one/datafile/system.265.848555585


SYS @ one > alter tablespace users offline;

Tablespace altered.

Nos conectamos a la instancia ASM y eliminamos el fichero.

Leer más…

Backup de Oracle Database en “la nube”

Desde hace ya un tiempo es posible contratar el servicio Database Backup en el Cloud de Oracle, que nos permite almacenar nuestros backups de BBDD en “la nube”.

Esto es una oportunidad para todos aquellos que o bien no tienen un sistema de backup de BBDD con el que se sientan cómodos (backups únicamente a disco, backups copiados de una maquina a otra, gestión de cintas manual, etc.) o para los que los backups a cinta automatizados empiecen a ser un problema, por complejidad de administración y costes.

Es más, no tenemos por qué plantear el cambio de manera rompedora ya que podemos disponer de manera simultánea del actual sistema de backup a disco o cinta y del backup en la nube. A todo esto podemos añadir que este servicio puede ser el punto de entrada perfecto de nuestra empresa en los servicios de tipo Cloud.

A nivel práctico tendremos a nuestra disposición todas las copias almacenadas desde cualquier lugar (ideal para duplicar BBDD en datacenters remotos) y al momento, sin tener que esperar el traslado de las cintas desde su ubicación de almacenamiento (en muchos casos una empresa de custodia externa).

Los backups en la nube se encuentran multiplexados entre diferentes centros de storage cloud de Oracle para evitar pérdidas de datos, se enviaran comprimidos para minimizar el consumo de ancho de banda y cifrados (con una llave de cifrado privada custodiada por el cliente) para securizar el acceso a los datos.

mqdefault

 

El funcionamiento del backup en la nube es idéntico al de un backup a cinta, la puesta en marcha de este backup consiste básicamente en la instalación de una Media Management Library idéntica a la que estemos usando actualmente para cintas físicas, con la diferencia que ésta va a comprimir, cifrar y enviar las copias por red a la nube.

Los comandos RMAN usados para las copias son los mismos, por lo que los scripts de copia y restauración de que dispongamos siguen siendo válidos.

Al adquirir el producto de backup en la nube, Oracle proporciona una licencia de uso limitado de la compresión y el cifrado de backups (opciones que on-premise implicarían tener que licenciar Enterprise Edition, Advanced Security y Advanced Compression). Esta licencia limitada es tanto para BBDD Enterprise Edition como para Standard Edition. En el caso de las BBDD Standard Edition es necesario instalar un parche en la BBDD que permite activar estas funcionalidades.

Podemos usar Oracle Backup en la nube desde la versión 10gR2 en adelante en la gran mayoría de plataformas, proporcionando Oracle una librería de gestión de medios apropiada al sistema operativo de que dispongamos.

Después de esta introducción al servicio vamos a realizar una demostración de configuración y backup de una BBDD Oracle en la nube.

Leer más…

Crear BBDD Oracle de desarrollo de manera ágil y con mínimo consumo de recursos

septiembre 15, 2015 1 comentario

El titulo de este post parece una panacea: imaginaros poder disponer de entornos de desarrollo “bajo demanda”, creándolos muy rápidamente y sin preocuparnos del espacio que ocupan (independientemente del tamaño de la BBDD origen)…

Existe la posibilidad de poder hacer algo parecido a esto si disponemos de un sistema de storage que nos permita replicar producción y realizar “snapshots” de esa replica o bien podemos aprovechar la funcionalidad de snapshot clone que nos proporciona Oracle Database desde la versión 11.2.

Las BBDD de tipo snapshot clone de Oracle prácticamente no ocupan espacio, ya que la BBDD clonada usa un backup de la BBDD origen para acceder a los datos (realmente no dispone de copia de los datos) y es cuando modificamos algún bloque que se realiza una copia con los nuevos datos modificados en los ficheros de la BBDD clonada (por lo que a medida que modifiquemos la BBDD clonada el espacio que ocupa irá creciendo).

BBDD clonadas usando Backup como origen de datos

El hecho de que los datos “base” de nuestro clon sean los de un backup nos permite desacoplar totalmente el entorno clonado del productivo (no interfiere uno con otro, pueden estar en servidores, cabinas e incluso CPD’s separados), y podemos crear tantos clones como queramos basados en el mismo backup (que habremos trasladado de producción al entorno de desarrollo o test). La copia debe ser de tipo “datafilecopy” y la podemos realizar en caliente mediante RMAN, en caliente manualmente con “begin/end backup” o en frío, y puede proceder de la BBDD origen o de una physical standby de ésta.

Notar que estos clones no están pensados para pruebas de rendimiento ya que el hecho de ir a buscar los bloques originales en el backup y los modificados en sus ficheros penaliza ese aspecto y por lo general los sistemas de storage de los entornos de desarrollo o test tampoco acostumbran a prestarse a este tipo de pruebas.

NOVEDAD: Indicar que a partir de la versión 12.1.0.2 se han relajado mucho los requisitos necesarios para poder usar esta funcionalidad, en esta versión podemos realizar clones sobre sistemas de ficheros locales. En versiones anteriores era necesario disponer de un sistema de ficheros NFS montado mediante el driver especifico de Oracle “dNFS” en el que crear la BBDD clon (notar que el backup no sufre esta restricción).

A continuación realizaremos una pequeña demostración de esta funcionalidad. En primer lugar lanzamos un backup de nuestra BBDD “origen”, realizamos un backup online con RMAN:

Leer más…

Upgrade Oracle Database a 12c mediante scripts y RMAN

2225367En esta entrada mostraremos un ejemplo de migración de 11g a 12c mediante scripts manuales y RMAN, al mismo tiempo que pasamos de una BBDD con almacenamiento ASM a otra sobre sistema de ficheros.

La idea general del proceso es realizar un backup con RMAN en la BBDD 11gR2 origen y restaurarlo en una maquina nueva con los binarios de 12cR1 para, acto seguido, aplicar los scripts de upgrade. La BBDD destino usará sistema de ficheros para almacenar los datos mientras que la de origen usaba ASM; notar que este ejemplo valdría también para el caso contrario.

Los pasos a realizar son:

  • Lanzar el backup RMAN en origen con los binarios de 11g
  • Traspaso del backup a destino (mediante SCP, ftp o similares)
  • Realizar la restauración con los binarios de 12c
  • Ejecutar los scripts de upgrade

En el fondo realizamos un upgrade mediante scripts, por lo que aplican las mismas restricciones y es necesario realizar los mismos pasos previos indicados en la documentación de migración mediante scritps.

Empecemos con el backup en origen con una sentencia similar a esta:

RUN {

ALLOCATE CHANNEL d1 TYPE DISK;

BACKUP TAG 'COPIA_MIGRACION' AS COMPRESSED BACKUPSET DATABASE format '/home/oracle/backup/temporal/%U' ;

backup TAG 'COPIA_MIGRACION' archivelog all format '/home/oracle/backup/temporal/%U';

RELEASE CHANNEL d1;

}

Una vez realizado el backup lo podemos copiar a la maquina destino con las herramientas de que dispongamos.

La máquina destino tiene que ser de la misma plataforma que la origen (si bien podría ser una versión de sistema operativo diferente) porque, como ya hemos comentado, este procedimiento equivale a un upgrade manual mediante scripts.

Leer más…

Generar comandos SQL a partir de los ficheros de trail de Oracle GoldenGate

Como ya hemos comentado en otras entradasGoldenGate es una herramienta que “permite capturar, enrutar, transformar y enviar datos transaccionales entre entornos heterogéneos en tiempo real”. Los datos (las transacciones) una vez capturados se almacenan en unos ficheros con formato propietario (independientes de la plataforma) llamados ficheros de “trail”. Vamos a revertir este proceso y obtener, de estos ficheros de trail, las sentencias SQL equivalentes a las transacciones almacenadas en ellos.

En esta entrada considero que el lector ya tiene un mínimo conocimiento de Goldengate, por lo que en caso contrario os recomiendo que reviséis la presentación que acompaña al post indicado anteriormente (ya que os estáis perdiendo un producto muy muy interesante).

Los datos capturados por GoldenGate se pueden almacenar en forma de ficheros de trail en diferentes puntos (dependiendo de la arquitectura escogida) y estos ficheros tendrán mas o menos información dependiendo de si ésta ha estado filtrada en la ruta hasta ese fichero concreto.

oracle_config

Pueden existir casos en que sea interesante disponer de las sentencias “SQL” que equivalen a los datos almacenados en estos ficheros de trail, o lo que es lo mismo, obtener las sentencias que GoldenGate ejecutaría en la BBDD destino al aplicar en ella esos ficheros de trail.

Existe una herramienta propia de GoldenGate llamada logdump que nos permite abrir estos ficheros, movernos entre las diferentes transacciones y sentencias, filtrar, buscar transacciones determinadas e incluso modificar el contenido de los ficheros.

El “aspecto” que tienen las transacciones mostradas mediante logdump dista mucho de lo que podríamos esperar si estamos acostumbrados a trabajar con sentencias SQL en herramientas tipo SQL*Plus o SQL*Developer:

logdumprecord_wseqinfoNo obstante podemos pasar estas sentencias SQL a formato “texto”, lo que nos permitirá trabajar con ellas (modificarlas/auditarlas/contabilizarlas) mas fácilmente.

La manera de conseguir esto consiste en crear un proceso de replica replicat, que leerá de los ficheros de trail y escribirá en un fichero de texto las sentencias (en lugar de aplicarlas a una BBDD).

Leer más…