En marzo del año pasado, en una presentación de Cebit sobre DB2 9.7 que realicé, quemé un altoparlante de computador de 110 V que enchufé sin pensar a la red eléctrica alemana de 230 V sin usar un transformador. En el mismo viaje, también destruí el cargador de mi cepillo de dientes eléctrico y mi maquinilla de afeitar en accidentes semejantes. Poniendo a un lado la incapacidad de aprender con mis propios errores, no es de admirarse que una de mis frases favoritas (de origen desconocido) es: "El problema de los estándares es que hay muchos de ellos."
En el área de los sistemas de gestión de bases de datos relacionales (RDBMS), tenemos por lo menos tres estándares importantes e innúmeras variaciones de ellos:
- ANSI SQL y ANSI SQL/PSM
- Oracle SQL y PL/SQL
- Sybase y Microsoft TSQL
La Figura 1 ilustra con un diagrama de Venn cómo los dialectos de SQL se solapan:
Figura 1. Torre de Babel del SQL

Siempre que escribe una aplicación, tiene que elegir qué proveedor de RDBMS va a usar. Después de esa selección, uno queda básicamente comprometido. Cualquier intento de cambiar de proveedor para aprovechar precios más bajos, tecnología mejor o una sociedad mejor es impedido por un código legado que requiere que se reescriba mucha cosa para usar con otro RDBMS. Además, no es posible transferir de un producto a otro el conjunto de habilidades con la facilidad que se espera.
IBM DB2 9.7 para Linux, UNIX y Windows (DB2) busca disminuir drásticamente las barreras para las aplicaciones escritas para Oracle al habilitarlas para DB2. Eso ofrece a los clientes y proveedores la capacidad de elegir un DBMS de acuerdo con sus méritos y no con el historial de aplicaciones.
DB2 9.7 añade dispositivos de compatibilidad con Oracle
Para permitir que una aplicación escrita para un RDBMS ejecute en otro prácticamente sin cambios, varias piezas tienen que encajarse en su lugar. Diferentes mecanismos de bloqueo, tipos de datos, SQL, lenguaje de procedimientos que reside en el servidor y aun las interfaces de cliente usadas por la aplicación en sí deben estar alineados en términos no sólo de sintaxis, sino también de semántica.
Todos esos pasos fueron realizados en el DB2. Los cambios son la excepción, no la regla (IBM puede evaluar rápidamente qué cambios en la aplicación son necesarios). La Tabla 1 proporciona una rápida visión general de los dispositivos más utilizados:
Tabla 1. Dispositivos más utilizados
| Oracle | --> | DB2 |
|---|---|---|
| Control de concurrencia | --> | Soporte nativo |
| Dialecto SQL | --> | Soporte nativo |
| PL/SQL | --> | Soporte nativo |
| Paquetes PL/SQL | --> | Soporte nativo |
| Paquetes incorporados | --> | Soporte nativo |
| Cliente JDBC con ampliaciones | --> | Soporte nativo |
| Scripts SQL* Plus | --> | Soporte nativo |
Con DB2 9.7, ya no necesita portar una aplicación. Uno simplemente habilita la aplicación. En el caso de una aplicación empaquetada, se puede incluso compartir un origen para DB2 y Oracle.
En otras palabras, la habilitación de una aplicación Oracle a DB2 no es más compleja que habilitar un programa en C escrito para HP-UX para ejecutar en AIX.
En el pasado, una de las principales diferencias entre Oracle y DB2 era el enfoque al control de concurrencia. La consigna es: "Los lectores no bloquean los grabadores y los grabadores no bloquean los lectores."
Tabla 2. Comportamiento de concurrencia de Oracle
| Transacción pendiente | Comportamiento | Nueva transacción |
|---|---|---|
| Lector | no bloquea | Lector |
| Lector | no bloquea | Grabador |
| Grabador | no bloquea | Lector |
| Grabador | bloquea | Grabador |
Sin entrar en detalles acerca de niveles de aislamiento, basta con decir que la gran mayoría de las aplicaciones que usan el Aislamiento a Nivel de Cláusula predeterminado de Oracle funcionarán bien con el valor predeterminado del DB2, que es Estabilidad del Cursor (CS).
Sin embargo, tradicionalmente se ha implementado CS para que los escritores puedan bloquear los lectores y, en algunos casos, los lectores puedan bloquear los grabadores. La razón de eso es que, tradicionalmente, una transacción bajo aislamiento CS "aguarda el resultado" de los cambios en la transacción concurrente pendiente.
Tabla 3. Comportamiento tradicional de concurrencia del DB2 con CS
| Transacción pendiente | Comportamiento | Nueva transacción |
|---|---|---|
| Lector | no bloquea | Lector |
| Lector | raramente bloquea | Grabador |
| Grabador | bloquea | Lector |
| Grabador | bloquea | Grabador |
Resulta que no hay razón semántica para que una transacción que ejecuta bajo aislamiento CS aguarde el resultado al encontrar una fila cambiada. Un comportamiento igualmente satisfactorio es leer la versión actualmente confirmada de la fila cambiada.
Se ha implementado ese comportamiento en el DB2 9.7. Lo que sucede es que el DB2 simplemente recupera del registro la versión actualmente confirmada de una fila bloqueada. En los casos más comunes, la fila aún está en el almacenamiento intermedio del registro pues aún no se ha confirmado el cambio. Pero aun si la fila haya sido suprimida y también sobrescrita en el almacenamiento intermedio del registro, el DB2 sabe exactamente dónde encontrarlo, para que una única entrada/ salida lleve la versión deseada a la agrupación de almacenamiento intermedio.
Imagine (consulte la Figura 2) que un usuario está actualizando un nombre en una tabla de empleados. Antes que ese usuario haya confirmado el cambio, otro usuario examina la tabla. Tradicionalmente, el segundo usuario tendría que haber esperado a que el primer usuario confirmara o retrocediera. Gracias a la lectura de los datos confirmados actualmente, el examen realizado por el segundo usuario simplemente recupera del almacenamiento intermedio del registro la versión de la fila que no contiene los cambios del primer usuario.
Figura 2. Grabadores no bloquean lectores

Es importante resaltar que ese comportamiento:
- No introduce nuevos objetos como un segmento de retrotracción
- No tiene sobrecarga de rendimiento para el grabador ya que de toda manera se necesita grabar el registro
- No puede producir ninguna situación de "instantánea demasiado antigua" porque, en el caso muy improbable de que el archivo de registro necesario haya sido archivado (¡mientras una transacción aún estaba abierta!), el DB2 simplemente vuelve atrás y espera que el bloqueo termine
Además de esos cambios, se introdujeron en el DB2 otras técnicas de evitar bloqueos para eliminar un lector que mantiene un bloqueo bajo el aislamiento CS.
Tabla 4. Nuevo comportamiento de concurrencia del DB2 con CS
| Transacción pendiente | Comportamiento | Nueva transacción |
|---|---|---|
| Lector | no bloquea | Lector |
| Lector | no bloquea | Grabador |
| Grabador | no bloquea | Lector |
| Grabador | bloquea | Grabador |
Como se puede ver, ahora el comportamiento de concurrencia es idéntico al de Oracle. De hecho, las bases de datos de DB2 recién creadas tienen ese comportamiento en forma predeterminada.
Los datos son el corazón de toda base de datos. Tipos que no coinciden o semántica de esos tipos que no coincide pueden afectar gravemente la capacidad de habilitar una aplicación a otro RDBMS. Por tanto, para permitir que las aplicaciones Oracle ejecuten en el DB2, es fundamental soportar sus tipos básicos que no son estándar, como series, fechas y tipos numéricos. Además de la alineación de esos tipos básicos, hay otros tipos más complejos y usados frecuentemente en PL/SQL de Oracle que fueron añadidos al DB2 9.7.
Tabla 5. Nuevos tipos de datos de DB2
| Tipo de dato | Descripción |
|---|---|
| NUMBER | Se añadió el soporte de NUMBER y NUMBER(p [, s]) de acuerdo con DECFLOAT (con aceleración de hardware Power6) y DECIMAL. |
| VARCHAR2 | El comportamiento del tipo VARCHAR2 incluye series vacías que se interpretan como NULL y cotejo sensible a espacios en blanco iniciales. |
| DATE Oracle | Una base de datos en la modalidad DATE Oracle incluye el componente TIME además de la fecha de calendario. |
| TIMESTAMP(n) | Se puede elegir la escala de fracción de segundos en cualquier punto entre 0 (fecha + hora) y 12 (picosegundos). |
| BOOLEAN | Se puede usar ese tipo en la lógica de procedimientos, variables y parámetros para rutinas. |
| VARRAY | El soporte de ARRAY en los procedimientos fue ampliado para soportar métodos y sintaxis del estilo VARRAY. |
| INDEX BY | Además de las matrices regulares el DB2 también soporta matrices asociativas. |
| ROW TYPE | Se puede usar ese tipo compuesto en variables y parámetros y como un elemento para matrices y matrices asociativas. |
| Tipo Ref Cursor | Los cursores pueden ser asignados a variables o pasados a través de parámetros. |
Casting implícito y resolución de tipo
"Si camina como un pato y habla como un pato, tiene que ser un pato."
Ése el el mantra de muchos de los nuevos lenguajes como PHP y Ruby. Todo literal es una serie y luego se le usa como otro tipo de acuerdo con el contexto. En cumplimiento al estándar SQL y la filosofía según la cual una no coincidencia es probablemente la indicación de un error de codificación, el DB2 tradicionalmente viene siguiendo reglas fuertes de tipificación, donde no es posible comparar series y numéricos a no ser que uno haga cast específicamente al otro.
Desafortunadamente, cuando una aplicación Oracle usa tipificación débil en su SQL, esa aplicación no habría compilado anteriormente en DB2. En el DB2 9.7, se añadió el casting implícito (o tipificación débil). Es decir, es posible comparar, asignar y operar series y números en forma muy flexible.
Además, se pueden usar NULLs sin tipo en muchos lugares más, mientras que es posible usar marcadores de parámetro sin tipo en prácticamente cualquier parte, gracias a la preparación aplazada (deferred prepare). Es decir, DB2 sólo resolverá el tipo de un marcador de parámetro después de ver el primer valor real.
Para perfeccionar el casting implícito, el DB2 también soporta el uso de valores predeterminados de procedimientos de parámetros como también la asociación de argumentos a parámetros por el nombre.
Biblioteca ampliada de funciones incorporada en el DB2
Todos los RDBMs proporcionan bibliotecas de funciones para hacer operaciones con los datos. El problema es que cada una usa sus propios nombres de funciones, aun si al fin y al cabo la funcionalidad es muy semejante.
Además de su propio conjunto tradicional de funciones, ahora el DB2 soporta una biblioteca compatible con Oracle. La lista a continuación proporciona una visión general rápida, pero no completa:
- Funciones de conversión y cast
TO_DATETO_CHARTO_CLOBTO_NUMBERTO_TIMESTAMP
- Aritmética de fechas
EXTRACTADD_MONTHSMONTHS_BETWEENNEXT_DAY- Más (+) para añadir fracciones de días
- Manipulación de series
LPADRPADINSTRINITCAP- Ampliaciones de
SUBSTR
- Diversos
NVLDECODELEASTGREATESTBITAND
El solapamiento mucho mayor de funciones soportadas entre los dos productos implica en un éxito de fábrica mucho mayor al habilitar una aplicación Oracle para DB2.
Hasta ahora, este artículo ha tratado de concurrencia, tipos de datos, tipificación y funciones. Sin embargo, las diferencias entre Oracle y DB2 son más profundas. El propio tejido de los dialectos de SQL, sus palabras clave y su semántica son distintos en algunas áreas. Además, cada producto soporta algunos dispositivos que el otro simplemente no soporta. Cuando esos dispositivos son muy conocidos, limitan la capacidad de enviar SQL común a los dos productos. La Tabla 6 lista algunos puntos importantes de los varios ajustes grandes y pequeños entre los lenguajes:
Tabla 6. Nuevo soporte de SQL
| Característica | Descripción |
|---|---|
Recurrencia de CONNECT BY | DB2, hasta el momento, ha soportado la recurrencia ANSI SQL. Ahora se ha añadido CONNECT BY al estilo Oracle, incluyendo las varias funciones y pseudocolumnas como LEVEL y CONNECT_BY_PATH. |
| sintaxis de unión (+) | Actualmente esa sintaxis no es recomendada ni siquiera por Oracle, pero hay varias aplicaciones y desarrolladores que aún usan esa forma de sintaxis OUTER JOIN. |
Tabla DUAL | Una tabla de una fila y una columna usada ubicuamente en aplicaciones Oracle como tabla ficticia. |
Pseudocolumna ROWNUM | Normalmente se usa esa pseudocolumna para limitar el número de filas retornadas y enumerar filas en un conjunto de resultados. |
Pseudocolumna ROWID | Los Rowids se usan para recuperar rápidamente una fila que fue captada anteriormente de acuerdo con su dirección física. |
Operador SQL MINUS | En Oracle, se usa MINUS en lugar de EXCEPT para restar un conjunto de resultados del otro. |
SELECT INTO FOR UPDATE
| El concepto FOR UPDATE en SELECT INTO permite la extracción de una fila del DB2 con el objetivo de modificarla más tarde sin usar un cursor. |
PUBLIC SYNONYM
| Un sinónimo público es un alias sin nombre de esquema. El DB2 soporta sinónimos públicos para objetos de tabla, secuencias y paquetes PL/SQL. |
CREATE TEMPORARY TABLE
| El DB2 soporta tablas temporales creadas, además de las tablas temporales declaradas. |
Cláusula de tabla TRUNCATE | Esa cláusula suprime rápidamente el contenido de una tabla entera sin accionar los desencadenantes. |
| Resolución de nombres menos rigurosa | El DB2 9.7 ya no requiere que las vistas incorporadas sean nombradas. Además, es posible heredar los nombres de columna más fácilmente de operadores de conjunto como UNION. |
Eso concluye la visión general de los cambios realizados en el DB2 para que las aplicaciones Oracle que envían SQL a la base de datos puedan ejecutar prácticamente sin cambios. Sin embargo, hay secciones importantes de varias aplicaciones que ejecutan el propio servidor. El mejor lenguaje de servidor para aplicaciones Oracle es PL/SQL. No se puede declarar seriamente la compatibilidad sin el soporte de PL/SQL.
Normalmente, cuando se porta una aplicación de un producto a otro, el SQL y el lenguaje de procedimiento es traducido de un dialecto de SQL a otro. Eso produce varios problemas:
- El código traducido resultante tiende a ser confuso debido a la automatización y no coincidencia de impedancia entre el dialecto de origen y el de destino.
- Los desarrolladores de aplicaciones no están familiarizados con el dialecto de destino del lenguaje SQL. Eso dificulta la depuración del código portado. A lo largo del tiempo, el mantenimiento se vuelve difícil debido a la falta de habilidades.
- En el caso de aplicaciones empaquetadas, se necesita repetir la traducción en todos los nuevos releases de la aplicación.
- Al final, el resultado es una emulación — que, por definición, ejecuta más lentamente que el original.
Para evitar esos problemas, el DB2 9.7 incluye soporte nativo de PL/SQL. ¿Qué significa eso?
Como se puede ver en la Figura 3, ahora el motor del DB2 incluye un compilador de PL/SQL lado a lado con el compilador de SQL PL. Ambos compiladores producen código de máquina virtual para el Motor de Tiempo de Ejecución Unificado de SQL del DB2. Es importante resaltar que herramientas de supervisión y desarrollo como Optim Development Studio están vinculadas al DB2 al nivel del motor de tiempo de ejecución.
Figura 3. Soporte de compilador PL/SQL

La integración de PL/SQL a DB2 como lenguaje de procedimiento de primera clase tiene varias implicaciones:
- No hay traducción. El código de origen permanece tal como está en el catálogo del esquema.
- Los desarrolladores pueden seguir trabajando en el lenguaje con el cual están familiarizados. No es necesario mover la lógica al dialecto del DB2 aun si se escribe una lógica nueva en SQL PL. Rutinas que usan dialectos diferentes pueden llamar las unas a las otras.
- Los proveedores de aplicaciones empaquetadas pueden usar un código de origen para Oracle y DB2.
- Tanto PL/SQL como SQL PL producen el mismo código de máquina virtual para el SQL Unified Runtime Engine del DB2. Por tanto, estructuralmente, tanto PL/SQL como SQL PL funcionan a la misma velocidad.
- Ya que la infraestructura del depurador se vincula directamente al SQL Unified Runtime Engine, PL/SQL es soportado naturalmente por el Optim Development Studio.
La Figura 4 ilustra una sesión de depuración de PL/SQL. El depurador soporta varios dispositivos estándar como step into, step over y puntos de interrupción. Además, permite que el usuario cambie variables locales de PL/SQL mientras el programa está ejecutando.
Figura 4. Soporte de depurador PL/SQL en el DB2

Detalles de sintaxis de PL/SQL
¿Qué significa exactamente el soporte de PL/SQL? En primero lugar, hay el soporte de sintaxis central. El DB2 soporta todas las construcciones comunes de PL/SQL, como:
- if then else
- bucles de while
- := asignaciones
- variables locales y constantes
- Manejo de excepciones y #PRAGMA EXCEPTION
- Varias formas de bucles de "for" (intervalo, cursor y consulta)
- Anclaje %TYPE y %ROWTYPE de variables y parámetros a otros objetos
- Transacciones #PRAGMA AUTONOMOUS que permiten la ejecución de los procedimientos en una transacción privada.
Se puede usar PL/SQL en varios objetos diferentes que permiten lógica de procedimiento:
- Funciones escalares
- Antes de la desencadenación de cada fila
- Después de la desencadenación de cada fila
- Procedimientos
- Bloqueos anónimos
- Paquetes de PL/SQL
La mayor parte del PL/SQL en aplicaciones Oracle está contenido en los así llamados PAQUETES. Un paquete de PL/SQL—no confundir con un paquete de DB2—es un conjunto de objetos individuales que tiene la capacidad de diferenciar objetos accesibles externamente y objetos que no son nada más que auxiliares para uso dentro del paquete. El equivalente de un paquete en ANSI SQL es un MÓDULO. Ahora el DB2 proporciona soporte de módulos de ANSI SQL y paquetes de PL/SQL. Específicamente, se proporcionan las siguientes posibilidades:
- CREATE [O REPLACE] PACKAGE, que define prototipos para rutinas visibles externamente. También define todos los objetos que no son de procedimiento y son visibles externamente, como variables y tipos.
- CREATE [OR REPLACE] PACKAGE BODY, que implementa todas las rutinas públicas y privadas, como también todos los otros objetos privados.
- Dentro de un paquete o cuerpo de paquete, es posible definir los siguientes objetos:
- Variables y constantes
- Tipos de datos
- Excepciones
- Funciones escalares
- Procedimientos
- Cursores
- Inicialización de paquetes
- Sinónimos públicos en paquetes
El DB2 proporciona paquetes incorporados comunes
Algunas aplicaciones Oracle usan paquetes ofrecidos por el RDBMS. Específicamente, las bibliotecas que proporcionan emisión de informes, e-mail o comunicación de conexión cruzada pueden ser muy utilizadas. Para facilitar la habilitación de esas aplicaciones para DB2, el DB2 proporciona los paquetes listados en la Tabla 7:
Tabla 7. Paquetes incorporados proporcionados por el DB2
| Paquete | Descripción |
|---|---|
| DBMS_OUTPUT | Proporciona posibilidades básicas de emisión de informes que pueden ser activadas o desactivadas desde la línea de comandos. |
| UTL_FILE | Un módulo que permite el trabajo con archivos en el servidor del DB2. |
| DBMS_SQL | Un paquete que ofrece una API de SQL para realizar SQL dinámico además de las cláusulas EXECUTE y EXECUTE IMMEDIATE ya existentes. |
| UTL_MAIL | Un módulo que permite el envío de notificaciones por e-mail desde SQL. |
| UTL_SMTP | Una API de nivel más bajo semejante a UTL_MAIL que proporciona integración a SMTP. |
| DBMS_ALERT | Un paquete que, cuando se utiliza, permite que diferentes sesiones actúen como semáforo entre sí. |
| DBMS_PIPE | Un módulo que permite que las sesiones envíen datos entre sí. |
| DBMS_JOB | Proporciona una API que se integra al planificador de tareas del DB2. |
| DBMS_LOB | Una API de Oracle para el procesamiento de LOB que hace eco de las funciones incorporadas de LOB del DB2. |
| DBMS_UTILITY | Un conjunto de varios procedimientos usados en aplicaciones. |
Ampliaciones de JDBC específicas para Oracle
JDBC es una interfaz de cliente estándar de Java. Sin embargo, hay ampliaciones que fueron añadidas al controlador de JDBC de Oracle para soportar tipos de datos específicos que no son estándar.
Para maximizar el nivel de compatibilidad de las aplicaciones basadas en la tecnología Java, el controlador JDBC del DB2 9.7 proporciona, entre otras cosas, soporte para llamar procedimientos con cursor de referencia y parámetros VARRAY.
Soporte de script SQL*Plus a través de CLPPlus
Frecuentemente se escriben scripts de DDL e incluso informes a través del procesador de línea de comandos de SQL*Plus. Para facilitar la transferencia de esos scripts y de las habilidades de los desarrolladores que los escriben, el DB2 proporciona un procesador de línea de comandos compatible con SQL*Plus, llamado CLPPlus. La herramienta proporciona la siguiente funcionalidad:
- Opciones de comandos compatibles con SQL*Plus
- Sustitución de variables
- Formateo de columnas
- Funciones de informes
- Variables de control
Figura 5. Herramienta CLPLus compatible con SQL*Plus

La habilitación a DB2 es fácil como arrastrar y soltar
Debido a la estrecha alineación del DB2 al PL/SQL y Oracle SQL, ahora no se necesita un kit de herramientas complejo para migración. En lugar de eso, puede usar el IBM Data Movement Tool para simplemente arrastrar y soltar tablas, paquetes o esquemas enteros de Oracle al DB2. Sólo se necesitan ajustes mínimos en casos excepcionales para mover una aplicación al DB2 o modificar una aplicación para que el mismo origen pueda operar tanto en DB2 como en Oracle.
Los pasos pueden ser muy simples:
- Configurar las variables de registro necesarias:
db2set DB2_COMPATIBILITY_VECTOR=ORAdb2set DB2_DEFERRED_PREPARE_SEMANTICS=YES
- Reiniciar el gestor de base de datos:
db2stopdb2start
- Crear una base de datos compatible con Oracle:
db2 create database mydb pagesize 32 Kdb2 update db cfg for mydb using auto_reval deferred_force
- Iniciar el IBM Data Movement Tool y conectarse a las bases de datos de Oracle y DB2 (consulte la Figura 6). Una vez conectado, puede optar por extraer sólo la DDL o la DDL y los datos. Por fin, tiene dos opciones: Desplegar directamente al ejecutar los scripts generados o continuar con el panel de despliegue interactivo. (Se recomienda esa última opción para la mayoría de las aplicaciones no triviales.)
Figura 6. Arrastre y suelte esquemas de Oracle en el DB2 a través de IBM Data Movement Tool
- Mover los esquemas deseados de Oracle al DB2 a través del despliegue interactivo (consulte la Figura 7). En la modalidad de despliegue interactivo, se ve un árbol de navegación que muestra todos los objetos extraídos de la base de datos Oracle. Seleccione todos los objetos y ejecute la opción de menú "deploy". La herramienta copiará los objetos al DB2 y registrará el progreso. Es posible que algunos objetos no desplieguen exitosamente, y la herramienta ofrece la opción de trabajar con ellos. Al seleccionar un objeto, verá la DDL junto con el error que el DB2 encontró. Ahora puede corregir la definición como sea necesario y volver a desplegar a través del editor incorporado. La meta es mover interactivamente todos los objetos al DB2 excepcionalmente.
Figura 7. Arrastre y suelte esquemas de Oracle en el DB2 a través de IBM Data Movement Tool

Dimensionando la habilitación al DB2
¿Qué tan fácil es habilitar su aplicación para el DB2 9.7? Por supuesto, la respuesta es: depende. IBM tiene una herramienta interna llamada MEET DB2 que puede analizar todos los objetos de la base de datos Oracle y asignarles una puntuación. Produce un informe de las cosas que funcionarán tal como están y de los ajustes necesarios. El representante de cuenta o contacto de ventas de IBM puede ejecutar ese utilitario para ayudar a proporcionar rápidamente una evaluación de la compatibilidad de su base de datos Oracle actual con el DB2.
Figura 8. Herramienta de informe MEET DB2 para evaluación

Durante la fase beta del DB2 9.7, que llevó un año, se analizaron detalladamente varias aplicaciones que totalizaron más de 750.000 líneas de código PL/SQL con una tasa promedio de 90%-99% de transferencia tal como están.
Figura 9. Tasa promedio de 98% de cláusulas soportadas

PL/SQL, la biblioteca de paquetes incorporada y CLPPlus actualmente no están disponibles para DB2 Express, DB2 Express-C y DB2 Personal Editions.
Gracias al soporte nativo a varios dialectos de SQL, ahora el DB2 9.7 permite la habilitación fácil de aplicaciones Oracle para el DB2. Los proveedores de aplicaciones empaquetadas pueden ofrecer sus aplicaciones tanto en Oracle como en DB2 a un costo adicional mínimo. Los clientes pueden elegir libremente el proveedor que ofrece la tecnología que necesitan, sin estar limitados por las opciones anteriores.
Puede descargar una versión de evaluación del DB2 9.7 para probar esos dispositivos (consulte Recursos).
¿Qué versión de Oracle el DB2 9.7 soporta?
La cobertura ofrecida a los dialectos de SQL y PL/SQL se basa estrictamente en lo que las aplicaciones están usando. Hay dispositivos introducidos en versiones recientes como Oracle 11g que son soportados, mientras que algunas construcciones disponibles en Oracle no son soportadas. En un estudio de 18 aplicaciones que totalizan más de 750.000 líneas, se movió 90%-99% del código al DB2 sin cambios. Muchos de los ajustes restantes pueden ser automatizados o son repetitivos de otra forma.
¿Con qué velocidad mi aplicación Oracle ejecutará en el DB2?
¡Ésa es la gran pregunta! Desafortunadamente, los términos de licencia de Oracle prohíben que se publiquen los resultados de pruebas de comparación sin consentimiento previo por escrito. No hace falta pedir que no nos dimos la molestia de pedir. Sin embargo, debido a su propio diseño y con la confirmación de las pruebas de comparación para garantía de calidad, una aplicación escrita en PL/SQL en el DB2 es tan rápida como una escrita en SQL PL en el DB2. Los proveedores que pasaron por el proceso de habilitación ya están, en forma general, agradablemente sorprendidos.
¿Qué tanto trabajo tuvieron para ofrecer esos dispositivos?
No tanto como parece. Parte del trabajo inicial, como CONNECT BY y NUMBER, se realizó en forma táctica para el DB2 9.5. Francamente: se concluyó el trabajo en menos de 18 meses.
¿Cuáles son las complicaciones comunes al habilitar de Oracle al DB2?
Obviamente, la compatibilidad del DB2 no es 100%. Por tanto, es probable que ocurran algunos problemas en la primera vez que se habilita para DB2. Sin embargo, muchas de esas complicaciones son banales y fáciles de corregir. Por ejemplo: el DB2 soporta los desencadenantes de PL/SQL, pero no permite la combinación de acciones desencadenantes. Es decir, se comparte un desencadenante para las acciones de UPDATE, DELETE e INSERT. Ahora, dado un desencadenante multiacción de PL/SQL, resulta muy fácil copiarlo a tres desencadenantes de DB2 PL/SQL a través de una variable booleana para los predicados INSERTED, UPDATED y DELETED.
Aprender
-
Launchpad de DB2 9.7: Obtenga una visión general de los valores del DB2.
-
Chat con el Laboratorio: Mire y escuche videos sobre temas como profundización técnica en DB2 9.7 y una versión de este artículo en webcast.
-
"Moving to DB2 is Easy" (youTube): Siga una demostración en video que proporciona una visión general de la habilitación de aplicaciones para el DB2.
-
"DB2 9.7 CLPPlus" (youTube): Mire un video que demuestra el uso del shell de CLPPlus compatible con SQL*PLus.
-
"DB2 9.7: Native PL/SQL Support" (youTube): Mire un video corto que muestra los varios dispositivos de PL/SQL soportados por el DB2 9.7.
-
"Break Free with IBM DB2 9.7" (youTube): Mire un video con testimonios de varios clientes y socios.
- Zona de Gestión de Informaciones en developerWorks: Aprenda más acerca de la Gestión de Informaciones. Encuentre documentación técnica, artículos de instrucciones, educación, descargas, información sobre los productos y más.
- Manténgase informado con eventos técnicos y webcasts de developerWorks.
Obtener los productos y tecnologías
-
DB2 9.7 para Linux, Unix y Windows: Descargue una versión de evaluación gratis del DB2 9.7 para Linux, UNIX y Windows.
- DB2 Express-C 9.7: Descargue el DB2 Express-C 9.7, una versión gratis del servidor de bases de datos DB2 Express para la comunidad.
- Compile su próximo proyecto de desarrollo con el software de evaluación de IBM, disponible para descarga directamente desde developerWorks.
Comentar
- Participar en el foro de debate.
- Participe en los blogs de developerWorks y en la comunidad de My developerWorks; con su perfil personal y página de inicio personalizada, puede ajustar developerWorks a sus intereses e interactuar con otros usuarios de developerWorks.

Serge Rielau viene trabajando hace 12 años en DB2 para Linux y UNIX y en el compilador SQL de Windows. Actualmente es el arquitecto de SQL para DB2 para Linux, UNIX y Windows. Es el arquitecto responsable de la compatibilidad con SQL en el DB2 9.7. Se puede contactar a Serge en comp.databases.ibm-db2.