Durante la actualización de
WebSphere ESB versión 6.2, las
herramientas de migración intentan actualizar instancias de
Cloudscape
a las que se accede únicamente a través de la infraestructura incorporada. (La nueva versión de
Cloudscape
es la 10.1.x, que está basada en Derby.) La actualización automática excluye las
instancias de
Cloudscape
que tratan con aplicaciones a través de la infraestructura de
Network Server. Esta exclusión evita el riesgo de dañar aplicaciones de terceros que acceden a las mismas instancias de base de datos como
WebSphere ESB.
Debe actualizar manualmente instancias de base de datos a las que se accede a través de la infraestructura de Network Server. Haga lo mismo para las bases de datos cuya migración automática ha fallado.
Antes de empezar
No utilice
Cloudscape
v10.1.x como base de datos de producción.
Utilícela sólo con fines de desarrollo y prueba.
Información detallada: La nueva versión de
Cloudscape
combina el tiempo de ejecución de Derby con beneficios adicionales, como
IBM®
Quality Assurance (QA) y el soporte multilingüístico (NLS).
Para las instancias de Cloudscape
a las que se accede a través de la infraestructura incorporada, determine qué instancias han fallado
completamente el proceso de actualización automática y qué instancias sólo se
actualizaron parcialmente. El tema
Verificación de la migración automática de Cloudscape v10.1.x documenta cómo descubrir errores de base de datos y datos de diagnóstico de distintas anotaciones cronológicas de migración. Los mensajes de anotación cronológica contienen los nombres de vía de acceso de base de datos antiguos y nuevos que se deben utilizar para ejecutar la migración manual. Anote correctamente estos nombres de vía de acceso nuevos.
Para minimizar el riesgo de errores de migración para bases de datos que sólo se actualizaron parcialmente durante el proceso de migración automática, suprima la nueva base de datos. Resuelva los problemas de la base de datos original de acuerdo con los datos de
diagnóstico de la anotación cronológica y luego lleve a cabo la migración manual de la base de datos
original.
Acerca de esta tarea
En la siguiente sección se muestran los pasos para migrar instancias
de Cloudscape
a las que se accede a través de las dos infraestructuras: la
infraestructura incorporada y la infraestructura de Network Server. Los pasos
que sólo se aplican a la infraestructura de Cloudscape
Network Server se marcan como tales. Como procedimiento recomendado para la migración, asegúrese de que el ID de usuario tiene una de las siguientes autoridades:
- Administrador del servidor que accede a la instancia de
Cloudscape
- Una máscara U que pueda acceder a la instancia de base de datos
De lo contrario, puede ver errores de tiempo de ejecución indicando que la instancia de base de es de sólo lectura.
Procedimiento
- Sólo infraestructura de Network Server: asegúrese de que cada
cliente de la base de datos
Cloudscape
pueda dar soporte a
Cloudscape v10.1.x. Los clientes de WebSphere ESB de la base de datos deben ejecutar versiones 6.0.1.x o posteriores de WebSphere ESB.
- Sólo la infraestructura de Network Server: ponga la base de datos fuera de línea. Ningún cliente puede acceder a la misma durante el proceso de migración.
- Examine un script de migración de Cloudscape de muestra que proporciona WebSphere ESB. En función de su sistema operativo,WebSphere ESB proporciona
uno de los scripts de migración siguientes:

En las plataformas Linux® y UNIX®: Utilice el script db2jmigrate.sh, que se encuentra en el directorio siguiente:
raíz_instalación/derby/bin/embedded/...
En las plataformas Windows®: Utilice el script db2jmigrate.bat,
que se encuentra en el directorio siguiente: raíz_instalación\derby\bin\embedded\...
Puede modificar el script de acuerdo con los requisitos del entorno. Consulte
Migración
de IBM Cloudscape
a la Versión 10 para obtener información sobre las opciones que puede
utilizar con el script. Por ejemplo, puede utilizar la opción
-DB2j.migrate.ddlFile=nombre_archivo para especificar el archivo
DDL para la nueva base de datos.
- Para generar las anotaciones cronológicas de depuración de base de datos cuando se ejecuta el script de migración, asegúrese de que el rastreo de migración de depuración esté activo. Por omisión, esta función de rastreo está habilitada. Vuelva a activar la función de rastreo de depuración si está inhabilitada.
- Para establecer las opciones de rastreo en la consola administrativa, pulse Resolución de problemas > Anotación cronológica y rastreo en el árbol de navegación de la consola.
- Seleccione el nombre de servidor.
- Pulse Cambiar detalles de nivel de anotaciones.
- Opcional: Si se han habilitado Todos los componentes, es posible que desee desactivarlo y luego habilite componentes específicos.
- Opcional: Seleccione un nombre de grupo o componente.
Para obtener más información, consulte
Valores de niveles de anotaciones en el centro de información de WebSphere Application Server Network
Deployment, versión 6.1. Si el servidor seleccionado no está en ejecución, no podrá ver un componente individual en modalidad gráfica.
- Escriba una serie de rastreo en el recuadro de serie de rastreo. En este caso, escriba uno de lo siguiente:
- all traces*=all
- com.ibm.ws.migration.WASUpgrade=all
Para obtener más información sobre el rastreo, lea Utilización del rastreo en el centro de información de WebSphere Application Server Network
Deployment, versión 6.1.
- Seleccione Aplicar y luego Aceptar.
- Especifique el nombre de la base de datos antigua y la vía de acceso
completa posterior a la migración del nuevo nombre de base de datos al ejecutar
el script. Por ejemplo: E:\WebSphere\ProcServer\derby\bin\embedded>db2jMigrate.bat mibdantigua midbnueva Las anotaciones cronológicas de la migración automática proporcionan los nombres de vía de acceso exactos que se deben especificar tanto para la base de datos antigua como para la base de datos de destino.
Debe
utilizar este nombre de base de datos de destino para especificar la nueva base
de datos, porque los orígenes de datos de
Cloudscape
migrados (actualizados por los programas de utilidad de migración de
WebSphere ESB)
apuntan ahora al nombre de la base de datos de destino. El siguiente texto de ejemplo muestra cómo aparecen los nombres de base de datos de destino en los mensajes de anotación cronológica:
Migración Cloudscape de la instancia de base de datos
C:\temp\migration2\profiles\Srv01\
installedApps\ghongellNode01Cell\DynamicQuery.ear\EmployeeFinderDB a
una instancia de base de datos nueva C:\WebSphere\ESB
\profiles\Srv01\databases\C__WAS602_ProcServer_profiles_ProcSrv01_
installedApps_ghongellNode01Cell_DynamicQuery.ear_
EmployeeFinderDB failed, reason: java.sql.SQLException:
Failure creating target db
Para las instancias de
Cloudscape
a las que se accede a través de la infraestructura de
Network Server, especifique el nombre que desee para la nueva base de datos. Recuerde modificar los orígenes de datos existentes de forma que apunten al nuevo nombre de base de datos.
- Cuando el proceso de migración finalice, examine la anotación cronológica de migración de base de datos para verificar los resultados. El nombre de vía de acceso de cada anotación cronológica de migración de base de datos esraíz_instalación/logs/derby/mi_nombre_vía_acceso_bd_completo_migrationLog.log.
En el caso de una migración satisfactoria, la anotación cronológica de migración de base de datos muestra un mensaje parecido al siguiente texto:
Compruebe el progreso en
E:\WebSphere\ESB\derby\myOldDB_migrationLog.log
La migración se ha realizado satisfactoriamente
E:\WebSphere\ESB\derby\bin\embedded>
De lo contrario, la anotación cronológica muestra mensajes de error en el formato del siguiente ejemplo:
Compruebe el progreso en
E:\WebSphere\ESB\derby\myOldDB_migrationLog.log
ERROR: An error occurred during migration. See debug.log for more details.
ERROR XMG02: Failure creating target db
java.sql.SQLException: Failure creating target db
at com.ibm.db2j.tools.migration.MigrationState.getCurrSQLException(Unknown
Source)
at com.ibm.db2j.tools.migration.MigrateFrom51Impl.handleException(Unknown
Source)
at com.ibm.db2j.tools.migration.MigrateFrom51Impl.go(Unknown Source)
at com.ibm.db2j.tools.migration.MigrateFrom51Impl.main(Unknown Source)
at com.ibm.db2j.tools.MigrateFrom51.main(Unknown Source)
- Para obtener más datos sobre un error de migración, consulte la anotación cronológica de depuración que corresponde a la anotación cronológica de migración de base de datos. El nombre de vía de acceso completo de un archivo de anotación cronológica de depuración es
raíz_instalación/logs/derby/mi_nombre_vía_acceso_bd_completo_migrationDebug.log
Las siguientes líneas son un ejemplo del texto de depuración.
sourceDBURL=jdbc:db2j:E:\WebSphere\myOldDB
newDBURL=jdbc:derby:e:\tempo\myNewDB
ddlOnly=false
connecting to source db <jdbc:db2j:E:\WebSphere\myOldDB>
connecting to source db <jdbc:db2j:E:\WebSphere\myOldDB> took 0.611 seconds
creating target db <jdbc:derby:e:\tempo\myNewDB>
creating target db <jdbc:derby:e:\tempo\myNewDB> took 6.589 seconds
initializing source db data structures
initializing source db data structures took 0.151 seconds
recording DDL to create db <E:\WebSphere\myOldDB>
recording DDL to create db <E:\WebSphere\myOldDB> took 5.808 seconds
Resultados
Como se indica en los pasos anteriores, la anotación cronológica de migración de base de datos muestra un mensaje
La migración se ha completado satisfactoriamente o un mensaje que contiene excepciones de anomalías de la migración.
Qué hacer a continuación
- Para las bases de datos cuya migración no se lleva a cabo satisfactoriamente, resuelva los problemas de acuerdo con los datos de error anotados. A continuación, vuelva a ejecutar el script de migración.
- Para acceder a bases de datos actualizadas satisfactoriamente a través de la infraestructura incorporada, modifique los orígenes de datos de forma que apunten a los nuevos nombres de base de datos.
- Para acceder satisfactoriamente a las bases de datos actualizadas a
través de la infraestructura de Network Server, puede utilizar el controlador
JDBC de
DB2
Universal o el controlador JDBC del cliente Derby.
- Si desea que las configuraciones JDBC existentes sigan utilizando el
controlador JDBC de DB2
Universal, modifique los orígenes de datos de modo que
apunten a los nuevos nombres de base de datos.
- Si desea utilizar el controlador JDBC de Derby Client, que puede dar soporte a orígenes de datos XA, modifique los proveedores JDBC para que utilicen la nueva clase de controlador JDBC de Derby Client y las nuevas clases de implementación de origen de datos.
A continuación, vuelva a configurar cada uno de los orígenes de datos existentes para que utilice la clase de ayuda de origen de datos Derby correcta y para que apunte al nuevo nombre de base de datos.
Consulte el tema Valores mínimos necesarios del origen de datos, por proveedor
en el centro de información de WebSphere Application Server Network
Deployment, versión 6.1 para todos los nuevos nombres de clase.
- Ejecute los scripts de actualización de base de datos del directorio
raíz_instalación/dbscripts/nombre_componente/Derby
para actualizar las tablas y esquema de base de datos al nivel de
WebSphere ESB versión 6.2.
Para obtener más información, consulte el apartado Actualización de bases de datos para la migración.