Verificar datafiles corruptos

Estimados tecnólogos Oracle reciban un cordial saludo nuevamente desde Guatemala, como ustedes saben, un DBA se enfrenta diariamente a diferentes problemas con las bases de datos que administra, problemas de performance, de IO, de red, storage, CPU, etc., para poder encontrar  la solución a estos problemas, el DBA debe ir delimitando la causa, y es por eso que en esta ocasión veremos una manera fácil de verificar si una base de datos posee corrupciones.

Oracle provee desde la versión 7.3.2, una herramienta llamada DBVERIFY la cual es usada para lo siguiente:

• Validar corrupciones en  la cabecera de un datafile
• Cada Bloque de dato dentro de un Datafile tiene un "wrapper" en el cual se encuentra metadata de  dicho bloque, este wrapper también es validado en busca de corrupciones.
• Validar Consistencia en tablas e índices dentro de los datafiles.
• Desde la versión 8.1.6 también se validan todos los demás tipos de bloques, por ejemplo  bloques de segmentos rollback.

Una de las ventajas de esta herramientas es que puede ser ejecutada cuando la base de datos está abierta, esto en ambiente de producción es muy importante pues se evita downtime.

La herramienta es muy sencilla de utilizar y provee los siguientes parámetros de entrada:

FILE:               nombre del datafile que se verificará.

START:           Bloque inicial

END:               Bloque Final

BLOCKSIZE: Tamaño del Bloque

LOGFILE:       Una archivo de log en el que se escribirá el feedback de la operación.

FEEDBACK:   Muestra detalladamente el avance del proceso.

PARFILE:        Archivo de parámetro

USERID:         Usuario/Constraseña

Entre las limitantes que tiene esta herramienta  están las siguientes:

• No valida errores entre tablas e sus indices.
• Solo puede ser utilizada con datafiles, no redologs, ni controlfiles.
• dbverify puede ser usada para bases de datos en ASM, sin embargo, la base de datos debe estar abierta y el parámetro USERID debe necesariamente ser especificado.
• Los datafiles necesitan tener una extensión.
• No se pueden validar datafiles mayores a 2GB  en 8.1.6 por los bugs: 710888 y 1372172.

El uso de la herramienta es muy fácil, a continuación describo la manera de validar una base de datos completa:

Primero obtenemos el tamaño del bloque que se está utilizando en la base de datos mediante la siguiente consulta:

SQL> SELECT value  FROM v$parameter WHERE name = 'db_block_size';

VALUE

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

8192

Ahora continuamos realizando un script con las sentencias necesarias para validar todos nuestros datafiles:

SET ECHO OFF

set heading off

set feedback off

spool validardb.sql

select 'dbv file=' ||file_name|| ' logfile=archivo_'||rownum||'.log  blocksize=8192' from dba_data_files;

spool off

exit

Verificamos que el archivo haya sido generado correctamente:

[oracle@soa1 ~]$ ls -ltr

-rw-r--r-- 1 oracle oinstall      5092 Mar  8 01:25 validardb.sql

El archivo debería quedar de la siguiente manera:

Le damos permisos de ejecución al script creado:

[oracle@soa1 ~]$ chmod 777 validardb.sql

Ejecutamos el script:

[oracle@soa1 ~]$ ./validardb.sql

DBVERIFY: Release 11.2.0.1.0 - Production on Fri Mar 8 02:33:01 2013

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.

Verificamos la salida del archivo:

[oracle@soa1 ~]$ ls -ltr

-rwxrwxrwx 1 oracle oinstall      1718 Mar  8 02:32 validardb.sql

-rw-r--r-- 1 oracle oinstall       729 Mar  8 02:33 archivo_2.log

-rw-r--r-- 1 oracle oinstall       726 Mar  8 02:33 archivo_1.log

-rw-r--r-- 1 oracle oinstall       809 Mar  8 02:33 archivo_3.log

-rw-r--r-- 1 oracle oinstall       739 Mar  8 02:33 archivo_4.log

-rw-r--r-- 1 oracle oinstall       736 Mar  8 02:33 archivo_5.log

-rw-r--r-- 1 oracle oinstall       738 Mar  8 02:33 archivo_6.log

-rw-r--r-- 1 oracle oinstall       734 Mar  8 02:33 archivo_7.log

-rw-r--r-- 1 oracle oinstall       740 Mar  8 02:33 archivo_8.log

-rw-r--r-- 1 oracle oinstall       735 Mar  8 02:33 archivo_9.log

-rw-r--r-- 1 oracle oinstall       729 Mar  8 02:33 archivo_10.log

-rw-r--r-- 1 oracle oinstall       733 Mar  8 02:33 archivo_11.log

-rw-r--r-- 1 oracle oinstall       726 Mar  8 02:33 archivo_12.log

-rw-r--r-- 1 oracle oinstall       732 Mar  8 02:33 archivo_13.log

-rw-r--r-- 1 oracle oinstall       728 Mar  8 02:33 archivo_14.log

-rw-r--r-- 1 oracle oinstall       738 Mar  8 02:33 archivo_17.log

-rw-r--r-- 1 oracle oinstall       729 Mar  8 02:33 archivo_16.log

-rw-r--r-- 1 oracle oinstall       732 Mar  8 02:33 archivo_15.log

Escaneamos los archivos con extensión .log en busca de corrupción:

[oracle@soa1 ~]$ grep Failing  archivo*.log

[oracle@soa1 ~]$ grep Corrupt archivo*.log

[oracle@soa1 ~]$ grep Influx archivo*.log

La salida sería parecida a lo siguiente, en mi caso, la base de datos que estoy usando para realizar este articulo no contiene corrupciones:

[oracle@soa1 ~]$ grep Failing  archivo*.log

archivo_10.log:Total Pages Failing   (Data) : 0

archivo_10.log:Total Pages Failing   (Index): 0

archivo_10.log:Total Pages Failing   (Seg)  : 0

archivo_11.log:Total Pages Failing   (Data) : 0

archivo_11.log:Total Pages Failing   (Index): 0

archivo_11.log:Total Pages Failing   (Seg)  : 0

archivo_12.log:Total Pages Failing   (Data) : 0

archivo_12.log:Total Pages Failing   (Index): 0

archivo_12.log:Total Pages Failing   (Seg)  : 0

archivo_13.log:Total Pages Failing   (Data) : 0

archivo_13.log:Total Pages Failing   (Index): 0

archivo_13.log:Total Pages Failing   (Seg)  : 0

archivo_14.log:Total Pages Failing   (Data) : 0

archivo_14.log:Total Pages Failing   (Index): 0

archivo_14.log:Total Pages Failing   (Seg)  : 0

archivo_15.log:Total Pages Failing   (Data) : 0

archivo_15.log:Total Pages Failing   (Index): 0

archivo_15.log:Total Pages Failing   (Seg)  : 0

archivo_16.log:Total Pages Failing   (Data) : 0

archivo_16.log:Total Pages Failing   (Index): 0

archivo_16.log:Total Pages Failing   (Seg)  : 0

archivo_17.log:Total Pages Failing   (Data) : 0

archivo_17.log:Total Pages Failing   (Index): 0

archivo_17.log:Total Pages Failing   (Seg)  : 0

archivo_1.log:Total Pages Failing   (Data) : 0

archivo_1.log:Total Pages Failing   (Index): 0

archivo_1.log:Total Pages Failing   (Seg)  : 0

archivo_2.log:Total Pages Failing   (Data) : 0

archivo_2.log:Total Pages Failing   (Index): 0

archivo_2.log:Total Pages Failing   (Seg)  : 0

archivo_3.log:Total Pages Failing   (Data) : 0

archivo_3.log:Total Pages Failing   (Index): 0

archivo_3.log:Total Pages Failing   (Lob)  : 0

archivo_3.log:Total Pages Failing   (Seg)  : 0

archivo_4.log:Total Pages Failing   (Data) : 0

archivo_4.log:Total Pages Failing   (Index): 0

archivo_4.log:Total Pages Failing   (Seg)  : 0

archivo_5.log:Total Pages Failing   (Data) : 0

archivo_5.log:Total Pages Failing   (Index): 0

archivo_5.log:Total Pages Failing   (Seg)  : 0

archivo_6.log:Total Pages Failing   (Data) : 0

archivo_6.log:Total Pages Failing   (Index): 0

archivo_6.log:Total Pages Failing   (Seg)  : 0

archivo_7.log:Total Pages Failing   (Data) : 0

archivo_7.log:Total Pages Failing   (Index): 0

archivo_7.log:Total Pages Failing   (Seg)  : 0

archivo_8.log:Total Pages Failing   (Data) : 0

archivo_8.log:Total Pages Failing   (Index): 0

archivo_8.log:Total Pages Failing   (Seg)  : 0

archivo_9.log:Total Pages Failing   (Data) : 0

archivo_9.log:Total Pages Failing   (Index): 0

archivo_9.log:Total Pages Failing   (Seg)  : 0

[oracle@soa1 ~]$ grep Corrupt archivo*.log

archivo_10.log:Total Pages Marked Corrupt   : 0

archivo_11.log:Total Pages Marked Corrupt   : 0

archivo_12.log:Total Pages Marked Corrupt   : 0

archivo_13.log:Total Pages Marked Corrupt   : 0

archivo_14.log:Total Pages Marked Corrupt   : 0

archivo_15.log:Total Pages Marked Corrupt   : 0

archivo_16.log:Total Pages Marked Corrupt   : 0

archivo_17.log:Total Pages Marked Corrupt   : 0

archivo_1.log:Total Pages Marked Corrupt   : 0

archivo_2.log:Total Pages Marked Corrupt   : 0

archivo_3.log:Total Pages Marked Corrupt   : 0

archivo_4.log:Total Pages Marked Corrupt   : 0

archivo_5.log:Total Pages Marked Corrupt   : 0

archivo_6.log:Total Pages Marked Corrupt   : 0

archivo_7.log:Total Pages Marked Corrupt   : 0

archivo_8.log:Total Pages Marked Corrupt   : 0

archivo_9.log:Total Pages Marked Corrupt   : 0

[oracle@soa1 ~]$ grep Influx archivo*.log

archivo_10.log:Total Pages Influx           : 0

archivo_11.log:Total Pages Influx           : 0

archivo_12.log:Total Pages Influx           : 0

archivo_13.log:Total Pages Influx           : 0

archivo_14.log:Total Pages Influx           : 0

archivo_15.log:Total Pages Influx           : 0

archivo_16.log:Total Pages Influx           : 0

archivo_17.log:Total Pages Influx           : 0

archivo_1.log:Total Pages Influx           : 0

archivo_2.log:Total Pages Influx           : 0

archivo_3.log:Total Pages Influx           : 0

archivo_4.log:Total Pages Influx           : 0

archivo_5.log:Total Pages Influx           : 0

archivo_6.log:Total Pages Influx           : 0

archivo_7.log:Total Pages Influx           : 0

archivo_8.log:Total Pages Influx           : 0

archivo_9.log:Total Pages Influx           : 0

¿Bug con Generador de XSD en JDeveloper 11.1.1.5?

Hace unos dias estaba desarrollando unos servicios en BPEL utilizando JDeveloper 11.1.1.5 para un ambiente SOA 11.1.1.5 en un sistema operativo AIX.

Uno de las tablas  legadas en un AS400 en el cual el cliente necesitaba realizar inserciones, recibia para dos campos distintos un mismo valor, es decir, el mismo valor era enviado a dos campos de la tabla legada.

Se fabricó un servicio BPEL utilizando un DBAdapter. Se utilizó la característidca "Pure SQL"  con la que cuenta el DBAdapter en el que ingresando una tarea SQL , el motor genera automáticamente el XSD del "Insert". Se generó la siguiente sentencia:

Insert into tabla values (1,1, #parametro1, #parametro2, #parametro3, #parametro4, #parametro5, #parametro6, #parametro7, #parametro8, #parametro9, #parametro10, #parametro11, #parametro12, #parametro13, #parametro14, #parametro15, #parametro1)

Vean que el #parametro1 fué enviado dos veces.

El XSD fué generado exitosamente por JDeveloper. En lo personal, pensé que el XSD se generaría con 15 parametros ya que el parametro1 es utilizado dos veces. Consideré que el motor de JDeveloper vería este detalle. Sin embargo, mi sorpresa fué cuando el XSD generado por JDeveloper ¡¡tenía dos campos con el mismo nombre (parametro1) y con el mismo tipo de dato (integer)!!

Intenté utilizar el "segundo" #parametro1, en un elemento ASSIGN y después en un elemento TRANSFORM, tal como se muestra en la siguiente imagen:

Mi sorpresa fué que el "segundo" #parametro1 ¡¡no podía ser utilizado!! Generaba el siguiente error que se muestra en la imagen y después el mapeo era redireccionado al "primer" #parametro1!.

Conceptualmente, el motor de BPEL en JDeveloper no debería dejar generar dos campos del mismo nombre con el mismo tipo de dato en el mismo XSD.  Y tal como lo vimos, aunque dos campos fuesen permitidos en el mismo XSD , el segundo, no puede ser utilizado.

Entonces preguntó a mis estimados lectores: 

¿Es este comportamiento un Bug?

Caracteristicas de un Servicio SOA

Un servicio es descrito como un servicio genérico de negocio. En los Sistemas de Información (IT), un servicio es un elemento que encapsula una funcionalidad atómica, usado para soportar los servicios de negocio que la organización proporciona.  Típicamente un servicio es parte de un completo servicio de negocio en una organización.  En un ambiente computacional orientado a servicios, los servicios se convierten en bloques pre-construidos usados en la construcción de bloques más complejos que solucionarán una necesidad. Para ser útil, un servicio necesita proveer una funcionalidad que sea utilizada en varios procesos de negocio. El servicio necesita ser implementado en software y necesita ser desplegado y manejado. A la combinación de varios servicios para crear un proceso más complejo se le da el nombre de “orquestación”.

Todos los servicios SOA deben contar con las siguientes características:

Definido: El servicio debe ser definido en términos de qué es lo que hace. Los procesos de negocio en los que formaran parte, la interfaz que están usando para comunicarse con otros servicios. Cómo debe ser invocado el servicio. Los datos que el servicio da como resultado. Cómo debe ser manejado el servicio.

Implementado: El servicio tiene que estar implementado con algún software, es decir, debe estar construido o desarrollado.

Desplegado: Para ser usado, el servicio necesita estar disponible para ser usado por otros servicios.

Manejado: El despliegue del servicio debe estar a cargo de alguien quien controle las versiones y el mantenimiento del mismo. Que monitoreé que el servicio está disponible y que está cumpliendo las funcionalidades para las cuales se creó.

Reusable: Al proveer una definición del servicio, su funcionalidad, su interfaz, cómo debe de ser usado, etc., habilita la reutilización del mismo, es decir, puede ser usado en otro proceso de negocio donde su funcionalidad sea requerida.

Comunicación: Un servicio debe ser accedido mediante envió y recepción de mensajes en el estándar eXtensible Markup Languaje (XML).

Abstracción: El servicio debe ser usado mediante su definición únicamente. No se debe saber cómo está construido. Debe ser una caja negra.

Orquestado: Un servicio debe ser fácilmente orquestado para formar procesos más complejos.

Granularidad: La complejidad de un servicio puede sencilla o muy compleja. Entre más sencilla sea la funcionalidad mejor. Un servicio no debe encapsular funcionalidad compleja dentro de él, sin reutilización. Debe buscarse siempre alcanzar esa funcionalidad compleja mediante orquestamiento.

Desacoplamiento: Mientras un servicio dependa menos de otro servicio se dice que esta desacoplado. Los servicios SOA deben desarrollarse tomando en cuenta el desacoplamiento, de esta manera cuando se necesiten hacer modificaciones a un servicio, pocos o ningún servicio serían afectados.

Estado: El servicio para poderse ejecutar sus tareas óptimamente debería de mantener información sobre su estado y qué tareas está ejecutando, para que en base a esos metadatos pueda ser gestionado lo más adecuado posible.

Primer Simposio Nacional de Oracle, Guatemala 2013

Este será el primer evento, en Guatemala, en el que varios expertos tecnólogos guatemaltecos se reunirán con el objetivo de compartir el conocimiento que han adquirido a lo largo de años, en cargos en los cuales han usado la tecnología Oracle en muy diversos campos, entre los que se pueden citar: el comercio, la banca, la industria, las telecomunicaciones, la educación, en consultorías, en soporte, etc.

Se ha creado a un grupo selecto  de conferencistas en base a la experiencia que poseen, la preparación académica y su aportación a la comunidad Oracle. El grupo está formado por consultores de varias empresas importantes en Guatemala como lo son:

• BYTE
• MCDONALDS
• XEROX
• DATUM
• GBM
• NETSOFTCA, Centro America
• EXANET

Las conferencias serán desarrolladas usando un lenguaje técnico genérico, ya que el dominio técnico de la audiencia a las que estará dirigido este evento será muy diverso; entre los asistentes que se esperan están: estudiantes universitarios, personas de negocio, tecnólogos expertos, profesionales, vendedores, etc.

Los temas que se tratarán en este primer Simposio abarcan varios productos que actualmente están rigiendo la tecnología guatemalteca. Otros temas serán de carácter innovador tratando tecnologías atractivas para el desarrollo de la agilidad en las empresas guatemaltecas, entre ellas están:

• Frameworks de Desarrollo
• Bases de Datos
• Alta Disponibilidad
• Sitios de Contigencia
• Servidor de Aplicaciones
• Afinamiento del Rendimiento

Cada una de las conferencias enriquecerá la experiencia de los participantes pues se tratarán casos de estudios reales. Los asistentes podrán participar activamente al plantear su solución  a un problema real, con lo cual se generará una dinámica al tenerse  varios puntos de vista para solucionar el mismo problema. Con esta modalidad se busca crear una comunicación técnica clara entre los participantes, lo que tendrá como consecuencia el compartir las experiencias que cada uno de ellos posee

Fecha y Lugar: 

• Viernes 15 de Marzo.
• Instalaciones de la Universidad InterNaciones, Blvd. San Isidro y 12 calle, zona 16, Acatán. Teléfono: 23798171, www.uni.edu.gt

Donación: Q50.00

*Se dará Diploma a los participantes.

Programa de Actividades:

Inscripción de participantes: 14:00 a 15:15 horas

Acto de Inauguración: 15:30 a 16:00 horas.

Conferencias 1 y 2: 16:00 a 16:40 horas.

Conferencias 3 y 4: 16:40 a 17:20 horas.

Coffe Break: 17:20 a 17:50 horas.

Conferencias 5 y 6: 17:50 a 18:30 horas.

Conferencias 7 y 8: 18:30 a 19:10 horas.

Conferencias 9 y 10: 19:10 a 19:50 horas.

Actividad de Cierre: 19:50 a 20:00 horas.

Entrega de Diplomas: 20:00 a 20:30 horas.

Descripción de Acto de Inauguración

Estará a cargo de Deiby Gómez y Anibal García, quienes darán una pequeña bienvenida a los participantes y conferencista. Luego de la bienvenida local se  transmitirá en directo al Tercer Oracle ACE Director de Latinoamérica Joel Pérez, quien también dará una pequeña bienvenida desde Ecuador.  Lic. Marcel Reichenbach Coloma, rector de la Universidad InterNaciones declarará inaugurado el Primer Simposio de Oracle.

Descripción de la Actividad de Cierre

Estará a cargo de Deiby Gómez y Anibal García quienes brevemente darán las gracias a los participantes, patrocinadores, organizadores y colaboradores por llevar a cabo el Primer Simposio Nacional de Oracle.

Descripción de la Actividad de Entrega de Diplomas

Entrega de diplomas a cada uno de los participantes y una pequeña bolsa con información de los patrocinadores. Para la entrega de los diplomas se dispondrán mesas en las que se colocarán los diplomas ordenados alfabéticamente por apellidos.

 Descripción de  las Actividades de la Conferencia

El periodo de duración de cada conferencia estará integrado de la siguiente forma: treinta minutos de exposición en el que se tratará el tema, conceptos fundamentales, puntos críticos, un caso breve de estudio. Al faltar cinco minutos para que termine este tiempo, se le mostrará una tarjeta amarilla al expositor, al concluir este tiempo se le mostrará una tarjeta roja y se dará por finalizada la exposición. A continuación se darán diez minutos de debate en el que se  responderán las preguntas de la audiencia y se creará conversación entre los participantes con el fin de dar a conocer otros puntos de vista asociados al tema tratado.

Conferencistas

Deiby Gómez: Consultor de DATUM S.A., Oracle Service Oriented Architecture Infrastructure Implementation Certified Expert, Oracle Database 11g Administrator Certified Expert, Oracle Linux Certified Implementation Specialist.

Aníbal García: DBA Senior Coordinator para  Goverment Solutions ACS-Xerox ,  División que opera con el gobierno de Estados Unidos (16 Estados) , coordina con múltiples DBA de  ORACLE en la India, China y USA , Experto en soluciones de Base de datos relacionales y multidimensionales. Oracle Certified Administrator.

Augusto López: Consultor de DATUM S.A., Oracle 10g Data base RAC Certified Expert, Oracle 10g and 11g Administrator Certified Expert, Experto en Configuraciones de Bases de Datos Oracle en Alta Disponibilidad, más de 15 años de experiencia.

Daniel Cacía: Consultor en DATUM S.A. Oracle Forms Developer Certified Professional, Oracle PL/SQL Developer Certified Associate, Oracle 10g Technical Presales Champion, Oracle Application Server Administrator 10g Certified Associate.

Byron Maldonado: Consultor de Tecnología, Administrador de Negocios, Administrador de Base de Datos Oracle, Analista de Sistemas de Información, Programador de Sistemas de Información, Administrador de Sistemas Operativos AIX, Windows y Linux, Manejo de software en ambientes Mac OS y MS Windows, Certificado en Soluciones de Dell Quest Software.

Juan René Simón: Consultor en Mcdonalds, Experto en desarrollo de aplicaciones web Java, Experto en Oracle Application Development Framework, más de 10 años de experiencia.

Julio Méndez: Consultor en EXANET; más de 10 años de experiencia en Administración de Sistemas Operativos, Sistemas de Archivos, Almacenamiento, afinamiento de Rendimiento, configuraciones en Alta Disponibilidad, Oracle Solaris Administrator Certified Expert.

Fabriccio Díaz: Gerente de Infraestructura y Tecnología para  BYTE Latinoamérica, más de 18 años de experiencia en Administración de Bases de Datos Oracle  en múltiples Plataformas,  BYTE actualmente es la empresa Nacional mas grande exportadora de Software.

Ronald Vargas:  Primer Oracle ACE de Centroamerica, Conferencista en OTN Tour 2010, 2011 y 2012, ha realizado conferencias en Guatemala, Honduras y Costa Rica, actualmente nominado a Oracle ACE Director.

Conferencias:

Oracle Database 12c: New Features, Nuevas funcionalidades con las que contará la nueva versión de base de Datos de Oracle en su versión 12c. Comparativa en rendimiento, administración y seguridad con su predecesor versión 11g.

Service Oriented Architecture (SOA): Business Agility, Fundamentos de la nueva filosofía para agilizar el negocio y hacerlo más rápido a cambios produciendo alta competitividad. IT será tan ágil y rápido que el área de negocio se enfocará en ser innovadores y productivos.

Oracle RAC 11gR2: Fundamentos y Recomendaciones derivadas de la práctica, una serie de tips técnicos que el consultor ha ido adquiriendo en sus más de 10 años de experiencia en configuraciones de Alta Disponibilidad de Bases de Datos Oracle, concluyendo en recomendaciones.

Oracle Application Development Framework: Construyendo aplicaciones web de forma rápida y eficiente, Conceptos fundamentales del framework de Oracle ADF con el objetivo de desarrollar aplicaciones empresariales rápidamente sin descuidar la seguridad, rendimiento y administración de la misma.

Monitoreo para la Administración y Mejores Prácticas de Afinamiento con Toad for Oracle v. 11.6.1  para Bases de Datos Oracle: Monitoreo y Diagnóstico en tiempo real para los Administradores de Bases de Datos Oracle, análisis de complejidad y recomendación de mejores prácticas en el código PL/SQL y afinamiento de SQLs en base a las Mejores Prácticas de la Industria para Desarrolladores y Modelamiento de Datos Multiplataforma.

Respaldo eficiente de Sistemas críticos: El  consultor dará una serie de tips técnicos y best practices para realizar respaldos rápidos de sistemas de producción con el fin de obtener puntos de restauración ante posibles problemas lógicos y físicos.

Monitoreo Preventivo/Correctivo  de Bases de datos de Producción: El consultor dará a conocer una serie de escenarios en los cuales se pueden definir una metodología que permite identificar patrones y compartirá  scripts y métodos de monitoreo para crear acciones preventivas con el fin contribuir a la alta disponibilidad de ambientes de producción.

Oracle Cloud 2013: Infraestructura, Software, Aplicaciones, Plataforma y Base de Datos “Como Servicio”: Tratando el tema de mayor importancia en informática: La nube. La forma en que Oracle expone como servicio la base de datos, la infraestructura, software, etc., y así poder  estar alineado con agilidad empresarial y virtualización de servicios.

Oracle Application Development Framework Mobile: Conferencia en donde se da a conocer conceptos de desarrollo de aplicaciones empresariales y el uso de framework para agilizar el desarrollo enfocado en tecnología mobile.

Dimensionando una BD Oracle, Tips & Tricks: De manos de un experto en tecnología se podrá observar cuales los factores principales a tomar en cuenta para recrear una solución que sea factible y rentable en el futuro y cuales son las tendencias que en nuestro mercado latinoamericano se puede encontrar y soportar fácilmente

Link para reservar tu lugar en el evento (Cupo Limitado):

https://docs.google.com/forms/d/19Cg__VCszn5xCmvg5UUPDsnydLH9BJGSKSuoBdXOVKw/viewform

Hasta aqui la información del evento, así que a reservar tiempo el dia 15 de marzo. ¡Los Esperamos!

www.comunidadoraclehispana.ning.com Por medio de Fernando Garcia (Oracle ACE / Presidente del IOUG Argentina) también nos apoyan:

Pablo Ciccarello desde http://www.oracle.com/technetwork/es/index.html también nos esta apoyando:

http://www.oracle.com/technetwork/es/community/user-groups/index.html

Invitación de Joel Pérez (Oracle ACE Director) al Primer Simposio Nacional de Oracle:

Con el apoyo de:

¿Cómo elegir un método de migración de Base de Datos?

Reciban un cordial saludo amigos tecnólogos, esta vez trataremos un tema que a simple vista parece ser sencillo, sin embargo, la mayoría de veces suele ser complicado o ambiguo, se trata de elegir un método adecuado de migración.

Existen varios método de migración, los cuales se prestan a diferentes necesidades que el negocio requiera, los hay desde sencillos hasta muy complicados y arriesgados; también existen rápidos o muy lentos; existen gráficos y a nivel de ejecución manual de scripts. Todo depende del entorno que se pretende migrar.

A continuación algunos métodos de migración:

• Usando Database Upgrade Assistant (DBUA)
• Migración Manual
• Oracle Data Pump Export e Import 
• Oracle Export e Import  originales
• Oracle Transportable Tablespaces 
• Oracle Data Guard SQL Apply (Logical Standby)
• Oracle Golden Gate 

Antes de poder crear un “algortimo” de elección de un método de migración adecuado, considero que es necesario, dar una pequeña descripción de cada uno de ellos.

Usando Database Upgrade Asssitant (DBUA): Este método es fuertemente recomendado por oracle, es gráfico, ejecuta todos los scripts necesarios en el orden correcto, realiza recomendaciones para mejorar la migración o acelerarla, valida la base de datos origen, migra instancias de Automatic Storage Management (ASM), realiza migraciones de ambientes en alta disponibilidad con Real Application Cluster (RAC), etc.

Como ven, es una herramienta muy completa, sin embargo posee algunas restricciones:

• Requiere un buen porcentaje de tiempo muerto (downtime), el cual es una ventana de tiempo en que el ambiente no está disponible.
• Únicamente migra bases de datos donde la plataforma origen y destino son las mismas.

Migración Manual: Este método de migración le otorga todo el control sobre la migración al Administrador de Base de Datos (DBA), el cual es el encargado de ejecutar todos los scripts necesarios, debe conocer el orden de ejecución de cada uno de ellos, debe realizar las validaciones necesarias antes de migrar, etc.

Este método se presta mucho a errores, pues es muy sensible.

Las principales restricciones de este método son:

• Requiere más tiempo de downtime que la migración con DBUA, pues todo debe ser realizado manualmente.
• Únicamente migra bases de datos donde la plataforma origen y destino son las mismas.

Oracle Data Pump Export e Import: Este método es muy flexible comparado con los demás métodos, pues se puede migrar toda o solo una parte de la base de datos origen, se puede realizar una migración completamente por red con la funcionalidad “network_link”. Es útil cuando se desea que la base de datos objetivo sea reestructurada pues todos los datos vuelven a ser insertados nuevamente, esto es útil cuando existen índices que necesitan ser recreados o los objetos están físicamente mal ubicados. Esta herramienta también puede utilizarse con paralelismo si el servidor posee varios cores. Para poder utilizar este método la base de datos origen debe ser al menos 10g. Esta herramienta es útil para migrar una base de datos origen a una plataforma diferente.

Las restricciones de este método son:

• Se requiere espacio adicional para almacenar el archivo que genera el Export, esto es si no se usa la opción “network_link”.
• Requiere un largo tiempo de downtime, desde que se empieza el export hasta que termina el import.

Oracle Export e Import originales: Esté método es útil para realizar migraciones de bases de datos muy antiguas, también posee la flexibilidad de poder migrar toda la base de datos origen o solo una parte de ella. No posee la funcionalidad “network_link”. Esta herramienta es útil para migrar una base de datos origen a una plataforma diferente.

Las restricciones de este método son:

• Se requiere espacio adicional para almacenar el archivo que genera el Export, esto es si no se usa la opción “network_link”.
• Requiere un largo tiempo de downtime, desde que se empieza el export hasta que termina el import.

Oracle transportable tablespaces: Este método requiere que el DBA posea bastante experiencia, ya que es posible que si no se realice correctamente los datos terminen dañados. La característica principal de éste método es que provee una migración rápida, menos de una hora aproximadamente (según oracle). Toda la metadata de los objetos debe ser migrada por medio de un export e import.

Las restricciones principales de éste método son:

• La plataforma origen y destino deben tener el mismo Endian Format si la base de datos origen es menor a 10g.
• A partir de 10g pueden convertirse tablespaces a diferentes plataformas.

A continuación muestro una tabla en la que se muestran algunos Sistemas Operativos y sus respectivos Endian_Format:

Para poder verificar el endian format de nuestra base de datos origen se puede ejecutar la siguiente consulta:

SQL> SELECT tp.platform_id,substr(d.PLATFORM_NAME,1,30), ENDIAN_FORMAT FROM V$TRANSPORTABLE_PLATFORM tp, V$DATABASE d WHERE tp.PLATFORM_NAME = d.PLATFORM_NAME;

Oracle Data Guard SQL Apply: Este método utiliza una base de datos standby de tipo “Logical” para poder realizar la migración. La base de datos destino, por medio de “SQL Apply” está sincronizando todos los datos y prácticamente el downtime se reduce al tiempo que tarda la configuración en realizar el cambio de roles (Switchover). La manera en que funciona una Logical Standby es por medio de los Archivelogs generados en la base de datos origen, trasladados por el proceso “Log Writter” a través de la red, almacenados después en la base de datos destino y luego son aplicados en la misma por medio de “SQL Apply”.  SQL Apply se encarga de abrir los Archivelogs y convertir toda la información en sentencias SQL, las cuales son ejecutadas en la base de datos objetivo, de esta manera se obtiene la característica de “reestructuración”, pues todos los objetos son creados nuevamente, a diferencia de una Physical Standby en la cual la base de datos destino es una copia bloque a bloque de la base de datos origen.

Las principales restricciones de este método son:

• Base de datos origen es al menos 10.1.0.3
• Plataforma origen y destino es la misma

Oracle Golden Gate: Con este método al igual que SQL Apply son de los más rápido, el downtime se resume al tiempo que implica el cambio de roles (Swtichover), sin embargo, esta herramienta es más flexible: Se puede realizar transformaciones de los datos, ruteo, mirar solo una parte o toda la base de datos origen.

Se pueden migrar bases de datos a través de plataformas diferentes, incluso a RDBMS distintos, por ejemplo desde un SQL Server a Oracle.

Las restricciones de este método son:

• Se necesita comprar la licencia de Oracle Golden Gate.
• Base de datos origen es al menos 8.1 (Si se trata de Oracle).

Existen más métodos de migración, sin embargo, ya son más complejos o no son tan comunes. Como por ejemplo el uso de Oracle Streams o el uso de Backups Incrementales en el Método de Tablespaces Transportables, entre otros.

Ahora, regresando al objetivo del artículo, el cual es un algoritmo para poder elegir un adecuado método de migración, organizaremos los métodos en base a downtime, plataformas diferentes y antigüedad de la versión origen.

Nuestro algoritmo a nivel general será de esta manera:

1. En base a la antigüedad de la versión de base de datos origen: ¿Cuántas migraciones debo hacer para llegar a la versión destino?
2. Al tener el número de migraciones necesarias, debemos ahora preguntarnos: ¿Son plataformas diferentes?
3. Al saber si son plataformas diferentes, ahora debemos preguntarnos ¿Cuanto Downtime es permitido?

Para determinar el número de migraciones que debemos realizar utilizaremos la siguiente imagen:

Para poder determinar finalmente el método en base al Downtime permitido y si las plataformas son las mismas utilizaremos la siguiente imagen:

Espero que con estos algoritmos se haya eliminado toda ambiguedad encontrada al elegir un método adecuado de migración para nuestra base de Datos.

Algunas notas importantes de metalink que siempre es bueno tener a la mano son:

429825.1    Complete Checklist for Manual Upgrades to 11gR1

837570.1    Complete Checklist for Manual Upgrades to 11gR2

421191.1    Complete Checklist for Manual Upgrades from X to Y

870814.1    Complete Checklist to Upgrade to 11gR2 using DBUA

551141.1    Database  Upgrade/Downgrade Compatibility Matrix

286775.1    How to Perform a Full Database Export Import during Upgrade

419550.1    Different Upgrade Methods for Upgrading Your Database

437276.1    Upgrading Oracle Database with a Logical Standby Database In Place

949322.1    Oracle11g Data Guard: Database Rolling Upgrade Shell                       Script

1320966.1  Things to consider before upgrade to 11.2.0.2 in relation to Performance