Resolución de problemas de migración
Es posible que encuentre problemas al migrar de una versión anterior de WebSphere Application Server.
Antes de empezar

En este artículo se describe la migración de la configuración de perfil. Para migrar sus aplicaciones a la versión más reciente, utilice WebSphere Application Server Migration Toolkit. Para obtener más información, consulte Migration Toolkit en WASdev.
sptcfgProcedimiento
- Mientras utiliza el asistente de migración de la Versión 9.0 para crear un perfil antes de migrar una configuración, podría ver los
siguientes mensajes de error relacionados con la creación de perfiles.
profileName: profileName no puede estar vacío profilePath: Espacio en disco insuficiente
Estos mensajes de error podrían aparece si escribe un nombre de perfil que contiene un carácter no válido, como un espacio. Vuelva a ejecutar el asistente de migración y verifique que no existen caracteres no válidos en el nombre del perfil como, por ejemplo, un espacio, comillas o cualquier otros carácter especial.
- Si surge algún problema cuando está migrando de una versión anterior de WebSphere Application Server a laVersión 9.0, consulte los archivos de anotaciones cronológicas y la información adicional disponible.
- Busque los archivos de anotaciones cronológicas y examínelos para obtener sugerencias.
- dir_copia_seguridad_migración/logs/WASPreUpgrade.indicación_hora.log
- dir_copia_seguridad_migración/logs/WASPostUpgrade.indicación_hora.log
- raíz_servidor_aplic/logs/clientupgrade.indicación_hora.log
- Busque MIGR0259I: La migración ha finalizado
satisfactoriamente. o MIGR0271W:
La migración ha finalizado
satisfactoriamente. en uno de los archivos de anotaciones cronológicas.
- dir_copia_seguridad_migración/logs/WASPreUpgrade.indicación_hora.log
- dir_copia_seguridad_migración/logs/WASPostUpgrade.indicación_hora.log
- raíz_servidor_aplic/logs/clientupgrade.indicación_hora.log
Si aparece MIGR0286E: La migración no se ha podido completar., intente corregir cualquier problema basado en los mensajes de error que aparecen en el archivo de anotaciones cronológicas. Después de corregir los errores, vuelva a ejecutar el mandato desde el directorio bin del directorio raíz de instalación del producto.
- Abra las anotaciones cronológicas de servicio del servidor que contiene el recurso al que está intentando acceder y examine los mensajes de error y de aviso.
- Mientras WebSphere Application Server está en
ejecución, ejecute el mandato dumpNameSpace e interconecte, redirija o
realice acciones "adicionales" que permitan ver la salida fácilmente.
Este mandato permite visualizar todos los objetos del espacio de nombres de WebSphere Application Server, incluidos la vía de acceso del directorio y el nombre del objeto.
- Si no aparece el objeto al que necesita acceder un cliente, utilice la consola
administrativa para verificar las siguientes condiciones:
- El servidor que alberga el recurso de destino se ha iniciado.
- El módulo web o el contenedor EJB (Enterprise Java™ Bean) que contiene el recurso de destino está en ejecución.
- El nombre JNDI del recurso de destino se ha especificado correctamente.
- Analice los datos de rastreo de las herramientas de
migración o reenvíe los datos a la organización adecuada para su análisis. Cuando utiliza el mandato WASPreUpgrade o el mandato WASPostUpgrade, puede especificar los siguientes parámetros para el rastreo:
- -traceString
- Éste es un parámetro opcional.
El valor especificación_rastreo especifica la información de rastreo que desea recopilar.
- Especifique "*=all=enabled" (con comillas) para recopilar toda la información de rastreo posible.
De este modo se genera un archivo de rastreo muy grande; por ejemplo, puede superar 1 GB para el mandato WASPostUpgrade.
- Especifique "Migration.*=all" para recopilar solamente la información de migración.
- Especifique "Migration.Flow=all:Migration.*=finer" para recopilar la mayor parte de la información de migración.
- Especifique "Migration.Flow=finer:Migration.*=fine" para recopilar la mínima cantidad de datos de migración que necesitan los equipos de soporte.
Este es el valor predeterminado.
- Especifique "*=all=enabled" (con comillas) para recopilar toda la información de rastreo posible.
- -traceFile
- Éste es un parámetro opcional. El valor nombre_archivo especifica el nombre del archivo de salida para la información de rastreo.
Si no especifica el parámetro -traceString o -traceFile, el mandato crea un archivo de rastreo de forma predeterminada y lo coloca en el directorio directorio_copia_seguridad/logs.
Para obtener la información actual que está disponible en IBM® Support sobre los problemas conocidos y su resolución, lea la página IBM Support. El servicio de soporte de IBM también tiene documentos que pueden ahorrarle tiempo en la recopilación de la información necesaria para resolver este problema. Antes de abrir un PMR, consulte la página IBM Support.
- Busque los archivos de anotaciones cronológicas y examínelos para obtener sugerencias.
- Durante el proceso de migración, pueden surgir problemas al utilizar la herramienta WASPreUpgrade o la herramienta
WASPostUpgrade.
- Pueden surgir problemas al utilizar la herramienta WASPreUpgrade.
- Se devuelve un mensaje del tipo No encontrado o El directorio o archivo no
existe.
Este problema se puede producir si está intentando ejecutar la herramienta WASPreUpgrade desde un directorio distinto del directorio raíz_servidor_aplic\bin de la Versión 9.0. Verifique que el script WASPreUpgrade resida en el directorio raíz_servidor_aplic\bin de Versión 9.0 y lance el archivo desde esa ubicación.
- El controlador JDBC de
DB2
y el controlador JDBC de
DB2
(XA) no se pueden encontrar en la lista desplegable de proveedores JDBC soportados
en la consola administrativa.
La consola administrativa ya no muestra los nombres de los proveedores de JDBC que están en desuso. Los nuevos nombres de proveedores de JDBC que se utilizan en la consola administrativa son más descriptivos e inducen menos a confusión. Los nuevos proveedores se diferencian de los en desuso sólo en el nombre.
Los nombres en desuso continuarán existiendo en el archivo jdbc-resource-provider-templates.xml por motivos de migración (por ejemplo, para los scripts JACL existentes); sin embargo, le recomendamos utilizar los nuevos nombres de proveedores de JDBC en los scripts JACL.
- Recibirá el mensaje siguientes:
MIGR0108E: El directorio de WebSphere especificado no contiene una versión de WebSphere que se pueda actualizar.
Existen varias razones posibles para este error:- Si se ha instalado WebSphere Application Server
Versión 7.0 o posterior, es posible que no
se haya ejecutado la herramienta WASPreUpgrade
desde el directorio bin de la raíz de
instalación de la
Versión 9.0.
- Cuando se ejecute la herramienta WASPreUpgrade, busque un mensaje parecido al
siguiente: IBM WebSphere Application Server, Release 6.
Este mensaje indica que se está ejecutando el programa de utilidad de migración de WebSphere Application Server Versión 7.0 o posterior y no el programa de utilidad de migración de la Versión 9.0.
- Modifique la vía de acceso del entorno o modificar el directorio actual de modo que pueda iniciar la herramienta WASPreUpgrade de la Versión 9.0.
- Cuando se ejecute la herramienta WASPreUpgrade, busque un mensaje parecido al
siguiente: IBM WebSphere Application Server, Release 6.
- Es posible que se haya especificado un directorio no válido al iniciar la herramienta WASPreUpgrade.
- Si se ha instalado WebSphere Application Server
Versión 7.0 o posterior, es posible que no
se haya ejecutado la herramienta WASPreUpgrade
desde el directorio bin de la raíz de
instalación de la
Versión 9.0.
- La herramienta WASPreUpgrade puede existir sin realizar copia de seguridad del entorno anterior. Es posible que la herramienta parezca que funciona correctamente como en el ejemplo siguiente:
También es posible que vea un mensaje similar al del ejemplo siguiente en el archivo de rastreo de la migración:MIGR0201I: La función de migración ha inicializado el archivo de registro WASPreUpgrade.log. MIGR0300I: La función de migración está comenzando a guardar el entorno existente de Application Server. MIGR0302I: Se están guardando los archivos existentes. MIGR0303I: Se ha guardado el entorno existente de Application Server. MIGR0420I: El primer paso de la migración ha finalizado correctamente.
[10/9/08 18:26:40:363 CDT] 00000000 Save 1 Se ha omitido la instancia dmgr01 porque no existe la raíz de usuario /opt/migration_backup/profiles/dmgr01.
La herramienta WASPreUpgrade graba una copia de un archivo profileList.ser que contenga punteros al directorio de copia de seguridad que utilizará la herramienta WASPostUpgrade. Si este archivo no lo suprime posteriormente la migración por algún motivo, se utilizarán las vías de acceso antiguas en lugar de las vías de acceso actuales cuando ejecute la herramienta WASPreUpgrade en migraciones posteriores. Para resolver este problema, puede suprimir con seguridad el archivo profileList.ser y volver a ejecutar la herramienta WASPreUpgrade.
Para obtener más información, consulte Mandato WASPreUpgrade.
Avoid trouble: Cuando se realiza una migración de un nodo federado de la versión 6.1 s Versión 9.0, el mandato WASPreUpgrade podría fallar. Es posible que reciba un error similar al ejemplo siguiente:
Puede que este problema surja en un nodo de la versión 6.1 de WebSphere tras crear una base de datos DB2 que utiliza el controlador de proveedores JCC de IBM y el nodo de la versión 6.1 de WebSphere se sincroniza con el gestor de despliegue de Versión 9.0. El nodo de la Versión 6.1 no da soporte al nivel de controlador de la Versión 7.0 o posterior. El proceso de sincronización de nodos falla al eliminar todas las definiciones del controlador.[07/16/2011 11:07:10:357 CDT] MIGR0344I: Se está procesando el archivo de configuración /opt/WAS61fep/profiles/v6109node74_01/config/cells/ndcell/clusters/Station1EJBCluster /resources.xml. [07/16/2011 11:07:10:436 CDT] org.eclipse.emf.ecore.resource.Resource$IOWrappedExcept ion: Referencia no resuelta 'DataSource_1310769433958'. (archivo: /opt/WAS61fep/profiles/v6109node74_01/config/cells/ndcell/clusters/Station1EJBC luster/resources.xml, 9, 323) java.lang.Exception: org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Referencia no resuelta 'DataSource_1310769433958'. (archivo: /opt/WAS61fep/profiles/v6109node74_01/config/cells/ndcell/clusters/Station1EJBC luster/resources.xml, 9, 323) at com.ibm.wsspi.migration.document.wccm.WCCMDocument.setInputStream(WCCMDocument.ja va:162)
Para resolver este problema, realice una copia de seguridad de los archivos resources.xml que se van a modificar. Detenga el proceso del agente de nodo de la versión 6.1. Edite los archivos resources.xml del nodo de WebSphere Versión 6.1 y elimine las entradas huérfanas resources.jdbc:CMPConnectorFactory antes de ejecutar el mandato WASPreUpgrade. No edite la copia del gestor de despliegue.
gotcha - Se devuelve un mensaje del tipo No encontrado o El directorio o archivo no
existe.
- Pueden surgir problemas al utilizar la herramienta WASPostUpgrade.
- Es posible que vea una excepción en las anotaciones cronológicas de WASPostUpgrade tras migrar un nodo federado que es
similar a la excepción que se resalta en el texto siguiente:
Esta excepción se produce durante la operación syncNode y se lista como un error; pero no provoca anomalías. La acción general se completa satisfactoriamente y no se vuelve a producir el mensaje. Una vez iniciado el servidor del nodo federado migrado, se volverá a generar el archivo en cuestión. Puede ignorar este mensaje.MIGR0304I: Se está restaurando el entorno anterior de WebSphere. MIGR0367I: Se está realizando una copia de seguridad del entorno actual de Application Server. CEIMI0006I Se está comenzando la migración de Common Event Infrastructure. MIGR0486I: El valor Transportes del archivo server.xml está en desuso. MIGR0486I: El valor PMIService:initialSpecLevel del archivo server.xml está en desuso. MIGR0486I: El valor PMIService:initialSpecLevel del archivo server.xml está en desuso. MIGR0404W: No utilice el agente de nodos de la configuración antigua. Se ha inhabilitado. MIGR0351I: La función de migración está intentando sincronizar con el gestor de despliegue utilizando el protocolo SOAP. MIGR0241I: Salida de syncNode. ADMU0116I: La información de la herramienta se anota en el archivo /usr/WAS80/profiles/AppSrv01/logs/syncNode.log ADMU0128I: Iniciando herramienta con el perfil AppSrv01 ADMU0401I: Comienza la operación de syncNode para el nodo aaixae15aNode01 con Deployment Manager packppc.rtp.raleigh.ibm.com: 8879 ADMU0016I: Sincronizando configuración entre el nodo y la célula. AWXJR0006E No se ha encontrado el archivo /usr/WAS80/java/jre/PdPerm.properties. ArchiveUtil.toLocalURLs ArchiveUtil.toLocalURLs ArchiveUtil.toLocalURLs ADMU0402I: Se ha sincronizado la configuración para el nodo aaixae15aNode01 con el gestor de despliegue packppc.rtp.raleigh.ibm.com: 8879 MIGR0352I: La sincronización con el gestor de despliegue es satisfactoria. CEIMI0007I La migración de Common Event Infrastructure se ha completado. MIGR0307I: La restauración del entorno anterior de Application Server se ha completado. MIGR0271W: Migración completada satisfactoriamente, con uno o más avisos.
- Se devuelve un mensaje del tipo "No encontrado" o "El directorio o archivo no
existe".
Este problema se puede producir si está intentando ejecutar la herramienta WASPostUpgrade desde un directorio distinto del directorio raíz_servidor_aplic\bin de la Versión 9.0. Verifique que el script WASPostUpgrade resida en el directorio raíz_servidor_aplic\bin de Versión 9.0 y lance el archivo desde esa ubicación.
- Recibirá el mensaje siguientes:
MIGR0102E: Línea de mandatos no válida. MIGR0105E: Debe especificar el nombre del nodo primario.
La causa más probable de este error es que se haya instalado WebSphere Application Server Versión 7.0 o posterior y que la herramienta WASPostUpgrade no se haya ejecutado desde el directorio bin de la raíz de instalación de la Versión 9.0.
Para corregir este problema, ejecute el mandato WASPostUpgrade desde el directorio bin de la raíz de instalación de la Versión 9.0.
- Al migrar los nodos federados de una célula, recibirá los siguientes mensajes de error:
MIGR0304I: Se está restaurando el entorno anterior de WebSphere. com.ibm.websphere.management.exception.RepositoryException: com.ibm.websphere.management.exception.ConnectorException: ADMC0009E: El sistema no ha podido realizar la invocación SOAP RPC: MIGR0286E: La migración no se ha podido completar.
Se produce un tiempo de espera excedido de conexión cuando el nodo federado intenta recuperar las actualizaciones de la configuración del gestor de despliegue durante el paso de migración de WASPostUpgrade para el nodo federado. Copiar toda la configuración podría tardar más que el tiempo de espera de inactividad de la conexión, si la configuración que está migrando a la Versión 9.0 contiene cualquiera de los siguientes elementos:- Muchas aplicaciones pequeñas
- Unas cuantas aplicaciones grandes
- Una aplicación muy grande
El procedimiento recomendado es modificar el valor de tiempo de espera de inactividad antes de ejecutar el mandato WASPostUpgrade para migrar un nodo federado.- Vaya a la siguiente ubicación en el directorio de la Versión 9.0 para el perfil al cual está migrando el nodo federado:
raíz_perfil/properties
- Abra el archivo soap.client.props en dicho directorio y encuentre el valor para la propiedad com.ibm.SOAP.requestTimeout. Este es el valor del tiempo de espera en segundos. El valor predeterminado es 180 segundos.
- Cambie el valor de com.ibm.SOAP.requestTimeout para que sea lo suficiente grande para migrar la configuración. Por ejemplo, la entrada siguiente le daría un valor de tiempo de espera de media hora:
com.ibm.SOAP.requestTimeout=1800
Nota: Seleccione el valor menor de tiempo de espera que cumpla con sus necesidades. Prepárese para esperar, como mínimo, tres veces el tiempo de espera que seleccione: una vez para bajar los archivos en el directorio de copia de seguridad, una vez para subir los archivos migrados al gestor de despliegue y una vez para sincronizar el gestor de despliegue con el agente de nodo migrado. - Vaya a la siguiente ubicación en el directorio de copia de seguridad que fue creado por el mandato WASPreUpgrade:
directorioCopiaseguridad/profiles/nombre_perfil/properties
- Abra el archivo soap.client.props en dicho directorio y encuentre el valor para la propiedad com.ibm.SOAP.requestTimeout.
- Cambie el valor de com.ibm.SOAP.requestTimeout al mismo valor que utilizó en el archivo de la Versión 9.0.
De forma alternativa, podría considerar una solución en la que especificar -includeApps script en el mandato WASPostUpgrade al migrar el gestor de despliegue a la Versión 9.0, si se da una o ambas de las siguientes situaciones en su caso:- Desea migrar rápidamente todos los nodos de la célula. Sin embargo, después de migrar toda la célula, desea ejecutar manualmente el script de instalación de aplicación para cada aplicación del directorio de copia de seguridad y, a continuación, sincronizar la configuración con todos los nodos migrados.
- Puede empezar la ejecución sin ninguna aplicación instalada.
Siga estos pasos para realizar este procedimiento alternativo:- Especifique -includeApps script en el mandato WASPostUpgrade al migrar el gestor de despliegue a la versión Versión 9.0.
- Migre toda la célula a la Versión 9.0 antes de instalar ninguna aplicación.
- Ejecute el mandato wsadmin para instalar cada aplicación.
- Instale las aplicaciones en la configuración de la Versión 9.0 durante las operaciones normales o en una ventana de mantenimiento aplicable.
- Especifique -conntype NONE. Por ejemplo:
wsadmin -f script_aplicación -conntype NONE
- Sincronice la configuración con todos los nodos migrados.
- Recibirá el mensaje de error "No se ha podido copiar el documento en el archivo
temporal". A continuación figura un ejemplo:
MIGR0304I: Se está restaurando el entorno anterior de WebSphere. com.ibm.websphere.management.exception.DocumentIOException: No se ha podido copiar el documento en el archivo temporal: cells/sunblade1Network/applications/LARGEApp.ear/LARGEApp.ear
El sistema de archivos podría estar lleno. Si el sistema de archivos está lleno, borre algo de espacio y vuelva a ejecutar el mandato WASPostUpgrade.
- Recibirá el mensaje siguientes:
MIGR0108E: El directorio de WebSphere especificado no contiene una versión de WebSphere que pueda actualizarse.
Existen varias razones posibles para este error:- Si se ha instalado la versión 6.1 de WebSphere Application Server, es posible que no se haya ejecutado la herramienta WASPostUpgrade desde el directorio bin de la raíz de instalación de Versión 9.0.
- Cuando se ejecute la herramienta WASPostUpgrade, busque un
mensaje parecido al siguiente: IBM WebSphere Application Server, Release 6.1.
Este mensaje indica que se está ejecutando un programa de utilidad de migración de un release anterior, no el programa de utilidad de migración de la Versión 9.0.
- Modifique la vía de acceso del entorno o modificar el directorio actual de modo que pueda iniciar la herramienta WASPostUpgrade de la Versión 9.0.
- Cuando se ejecute la herramienta WASPostUpgrade, busque un
mensaje parecido al siguiente: IBM WebSphere Application Server, Release 6.1.
- Es posible que se haya especificado un directorio no válido al iniciar la herramienta WASPreUpgrade o WASPostUpgrade.
- No se ha ejecutado la herramienta WASPreUpgrade.
- Si se ha instalado la versión 6.1 de WebSphere Application Server, es posible que no se haya ejecutado la herramienta WASPostUpgrade desde el directorio bin de la raíz de instalación de Versión 9.0.
- Recibirá el siguiente mensaje de error:
MIGR0253E: El directorio de copia de seguridad directorio_copia_seguridad_migración no existe.
Existen varias razones posibles para este error:- La herramienta WASPreUpgrade no se ha ejecutado antes de la herramientaWASPostUpgrade.
- Compruebe si existe el directorio de copia de seguridad especificado en el mensaje de error.
- Si no existe, ejecute la herramienta WASPreUpgrade.
Consulte Mandato WASPreUpgrade si desea más información.
- Vuelva a ejecutar la herramienta WASPostUpgrade.
- Puede que se haya especificado un directorio de copia de seguridad que no sea
válido.
Por ejemplo, el directorio puede haber sido un subdirectorio del árbol de la Versión 7.0 o posterior que se ha suprimido después de ejecutar la herramienta WASPreUpgrade y se haya desinstalado la versión anterior del producto pero antes de ejecutar la herramienta WASPostUpgrade.
- Compruebe si existe la estructura de directorios completa especificada en el mensaje de error.
- Si es posible, vuelva a ejecutar la herramienta WASPreUpgrade, especificando el directorio de copia de seguridad de migración correcto completo.
- Si el directorio de copia de seguridad no existe y la versión anterior de la que procede ha desaparecido, vuelva a crear la versión anterior a partir de un repositorio de copia de seguridad o de un archivo de configuración XML.
- Vuelva a ejecutar la herramienta WASPreUpgrade.
- La herramienta WASPreUpgrade no se ha ejecutado antes de la herramientaWASPostUpgrade.
- Decida si es necesario volver a ejecutar WASPreUpgrade después de haber ejecutado el mandato WASPostUpgrade.
Durante la ejecución de un gestor de despliegue o una migración de nodo federado, es posible que WASPostUpgrade inhabilite el entorno anterior. Si después de ejecutar WASPostUpgrade desea volver a ejecutar WASPreUpgrade en la instalación anterior, debe ejecutar el script migrationDisablementReversal.jacl situado en el directorio antiguo raíz_servidor_aplic/bin. Después de ejecutar este script JACL, el entorno de la Versión 7.0 o posterior volverá a tener un estado válido, lo que le permitirá ejecutar WASPreUpgrade para generar resultados válidos.
- Una migración federada falla con el mensaje MIGR0405E.La migración ha tenido lugar en el gestor de despliegue ya que parte de la migración federada ha fallado. Para obtener una explicación más detallada de la causa de este error, abra la carpeta nombre_nodo_migration_temp ubicada en el nodo de gestor de despliegue bajo el directorio ...DeploymentManagerProfile/temp. Por ejemplo:
/websphere80/appserver/profiles/dm_profile/temp/nodeX_migration_temp
Las anotaciones cronológicas y el resto de datos implicados en la migración de este nodo en el gestor de despliegue se encuentran en esta carpeta. Esta carpeta también será necesaria para el soporte de IBM relacionado con este caso.
- Las aplicaciones de la Versión 9.0 se perderán durante la migración.
Si durante una migración federada alguna de las aplicaciones de la Versión 9.0 no se instala, se perderán durante la sincronización de las configuraciones. El motivo es que uno de los pasos finales de WASPostUpgrade es ejecutar un mandato syncNode. Esto tiene como resultado que la configuración se descarga en el nodo del gestor de despliegue y se sobrescribe en el nodo federado. Si las aplicaciones no se instalan, no estarán en la configuración ubicada en el gestor del nodo de despliegue. Para resolver este problema, instale manualmente las aplicaciones después de la migración. Si son aplicaciones estándar de la Versión 9.0, no se encontrarán en el directorio raíz_servidor_aplic/installableApps.
Para instalar manualmente una aplicación que falló durante la migración, utilice el mandato wsadmin para ejecutar el script install_nombre_aplicación.jacl que las herramientas de migración han creado en el directorio de copia de seguridad.
En un entorno Linux, por ejemplo, utilice los parámetros siguientes:./wsadmin.sh -f directorio_copia_seguridad_migración/install_nombre_aplicación.jacl -conntype NONE
- Las aplicaciones de la Versión 9.0 no se instalan.
Instale manualmente las opciones mediante el mandato wsadmin una vez que WASPostUpgrade haya finalizado.
Para instalar manualmente una aplicación que no ha podido instalarse durante la migración, utilice el mandato wsadmin para ejecutar el script install_nombre_aplicación.jacl que las herramientas de migración han creado en el directorio de copia de seguridad.
En un entorno Linux, por ejemplo, utilice los parámetros siguientes:./wsadmin.sh -f directorio_copia_seguridad_migración/install_nombre_aplicación.jacl -conntype NONE
Lea Mandato WASPostUpgrade para obtener más información.
- Es posible que vea una excepción en las anotaciones cronológicas de WASPostUpgrade tras migrar un nodo federado que es
similar a la excepción que se resalta en el texto siguiente:
- El archivo de rastreo sobrepasa su asignación de 400 megabytes, pero todavía se
está ejecutando WASPostUpgrade. Si no hay espacio de disco adicional disponible, la migración fallará. Si cree que puede producirse este problema durante la migración, realice las acciones siguientes:
- Detenga el Asistente de migración antes de que se emita el mandato WASPostUpgrade.
- Ejecute el mandato WASPostUpgrade desde la línea de mandatos
para cada perfil que esté migrando.
Cuando ejecute el mandato WASPostUpgrade desde la línea de mandatos:
- Incluya los parámetros -oldProfile y -profileName para indicar el perfil que desea migrar.
- Añada el parámetro com.ibm.ejs.ras.TraceNLS*
a la serie de rastreo para reducir el tamaño del registro
de rastreo. Por ejemplo, es posible que desee especificar el valor de
rastreo siguiente:
com.ibm.ejs.ras.TraceNLS*=info
- Pueden surgir problemas al utilizar la herramienta WASPreUpgrade.
Cuando utilice el asistente de migración para migrar un perfil de la versión 6.0.2 de WebSphere Application Server a la Versión 9.0 en un sistema basado en el procesador x64 de Solaris, la migración podría fallar durante el paso WASPostUpgrade.
Es posible que vea mensajes similares al siguiente en dir_copia_seguridad_migración/logs/WASPostUpgrade.indicación_hora.log:MIGR0327E: Se ha producido un error con stopNode. MIGR0272E: La función de migración no ha podido completar el mandato.
La versión 6.0.2 de WebSphere Application Server utiliza una máquina virtual Java (JVM) en modalidad de 32 bits. Al asistente de migración para Versión 9.0 invoca el script WASPostUpgrade.sh que intenta ejecutar la JVM para la versión 6.0.2 en la modalidad de 64 bits cuando el servidor detiene el nodo de la versión 6.0.2.
Complete las acciones siguientes para eliminar el perfil incompleto y habilitar WebSphere Application Server con el fin de migrar correctamente el perfil de la versión 6.0.2:- Desde una línea de mandatos, cambie al directorio
raíz_servidor_aplic/bin. Por ejemplo, escriba el mandato siguiente:
cd /opt/IBM/WebSphere/AppServer/bin
- Localice el script WASPostUpgrade.sh en el directorio raíz_servidor_aplic/bin y haga una copia de seguridad.
- Abra el script WASPostUpgrade.sh en un editor y realice las siguientes acciones:
- Localice la línea de código siguiente:
. "$binDir" /setupCmdLine.sh
- Inserte la línea de código siguiente después del código identificado en el paso anterior:
JVM_EXTRA_CMD_ARGS=""
- Guarde los cambios.
- Localice la línea de código siguiente:
- Utilice el siguiente mandato para suprimir el perfil incompleto de la Versión 9.0 que se creó durante el
proceso de migración:
raíz_servidor_aplic/bin/manageprofiles.sh -delete -profileName nombre_perfil
- Suprima el directorio raíz_perfil del perfil de la Versión 9.0 que fue eliminado en el paso anterior.
- Vuelva a ejecutar el asistente de migración.
- Desde una línea de mandatos, cambie al directorio
raíz_servidor_aplic/bin.
- Si selecciona la opción para el
proceso de migración para instalar las aplicaciones empresariales que
existen en la configuración de la
Versión 7.0 o posterior en la nueva
configuración de la
Versión 9.0, puede encontrar
algunos mensajes de error durante la fase de migración de la
instalación de aplicación.
Las aplicaciones que existen en la configuración de la Versión 7.0 o posterior pueden tener información de despliegue incorrecta—normalmente, documentos XML no válidos que no se han validado suficientemente en entornos de ejecución anteriores de WebSphere Application Server. El tiempo de ejecución ahora tiene un proceso de validación de instalación de aplicaciones mejorado y no podrá instalar estos archivos EAR con formato incorrecto. Esto provoca una anomalía durante la fase de instalación de aplicaciones de WASPostUpgrade y genera un mensaje de error "E". Se considera un error de migración "muy grave".
Si la migración falla durante la instalación de aplicaciones, también puede llevar a cabo una de las siguientes acciones:- Corrija los problemas en las aplicaciones de la Versión 7.0 o posterior y, a continuación, vuelva a realizar la migración.
- Proceda con la migración e ignore estos errores.
En este caso, el proceso de migración no instala las aplicaciones anómalas aunque lleva a cabo los demás pasos de migración.
Más adelante, puede resolver los problemas de las aplicaciones y, a continuación, instálelas manualmente en la nueva configuración de la Versión 9.0 mediante la consola administrativa o un script de instalación.
- Después de migrar un nodo federado a la Versión 9.0, es posible que el servidor de aplicaciones no se inicie. Al intentar iniciar el servidor de aplicaciones, podría obtener errores similares a los del ejemplo siguiente:
[5/11/06 15:41:23:190 CDT] 0000000a SystemErr R com.ibm.ws.exception.RuntimeError: com.ibm.ws.exception.RuntimeError: org.omg.CORBA.INTERNAL: CREATE_LISTENER_FAILED_4 vmcid: 0x49421000 código menor: 56 finalizado: No [5/11/06 15:41:23:196 CDT] 0000000a SystemErr R at com.ibm.ws.runtime.WsServerImpl.bootServerContainer(WsServerImpl.java:198) [5/11/06 15:41:23:196 CDT] 0000000a SystemErr R at com.ibm.ws.runtime.WsServerImpl.start(WsServerImpl.java:139) [5/11/06 15:41:23:196 CDT] 0000000a SystemErr R at com.ibm.ws.runtime.WsServerImpl.main(WsServerImpl.java:460) [5/11/06 15:41:23:196 CDT] 0000000a SystemErr R at com.ibm.ws.runtime.WsServer.main(WsServer.java:59) [5/11/06 15:41:23:196 CDT] 0000000a SystemErr R at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [5/11/06 15:41:23:196 CDT] 0000000a SystemErr R at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) [5/11/06 15:41:23:197 CDT] 0000000a SystemErr R at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
Cambie el número de puerto en el que está escuchando el servidor de aplicaciones del nodo federado. Si el gestor de despliegue está escuchando en el puerto 9101 para ORB_LISTENER_ADDRESS, por ejemplo, el servidor de aplicaciones del nodo federado no debe escuchar en el puerto 9101 para ORB_LISTENER_ADDRESS. Para resolver el problema de este ejemplo, realice los pasos siguientes:- En la consola administrativa, pulse Servidores de aplicaciones > nombre_servidor > Puertos > ORB_LISTENER_ADDRESS .
- Cambie el número de puerto de ORB_LISTENER_ADDRESS por uno que no se utilice.
- Si falla la sincronización cuando migra
un nodo federado a la Versión 9.0, es posible que el servidor de aplicaciones no
se inicie. Puede recibir mensajes similares al siguiente cuando migra un nodo federado a la Versión 9.0:
Estos mensajes indican lo siguiente:ADMU0016I: Sincronizando configuración entre el nodo y la célula. ADMU0111E: Saliendo del programa con el error: com.ibm.websphere.management.exception.AdminException: ADMU0005E: Error al sincronizar los repositorios ADMU0211I: Puede ver los detalles del error en el archivo: /opt/WebSphere/80AppServer/profiles/AppSrv02/logs/syncNode.log MIGR0350W: La sincronización con el gestor de despliegue utilizando el protocolo SOAP ha fallado. MIGR0307I: La restauración del entorno anterior de WebSphere Application Server se ha completado. MIGR0271W: Migración completada satisfactoriamente, con uno o más avisos.
- El gestor de despliegue está en el nivel de configuración de la Versión 9.0.
- El nodo federado que intenta migrar está en el nivel de configuración de la Versión 9.0 en el repositorio del gestor de despliegue (incluidas las aplicaciones).
- El propio nodo federado no se ha completado del todo dado que no se ha completado la operación syncNode.
- Vuelva a ejecutar el mandato syncNode en el nodo para sincronizarlo con el gestor de despliegue.
Para obtener más información, consulte Mandato syncNode.
- Ejecute el mandato GenPluginCfg.
Para obtener más información, consulte Mandato GenPluginCfg.
- Si migra un gestor de despliegue a la Versión 9.0 de IBM desde una
configuración de la versión 6.1 que se ha migrado de un gestor de despliegue de la versión 5.1, el mandato
syncNode podría fallar en nodo federado de la versión 5.1 de la célula. Por ejemplo, es posible que aparezcan mensajes similares a los del texto siguiente cuando ejecute el mandato syncNode en un nodo de la versión 5.1:
bash-3.00# ./syncNode.sh dmgrhostname 8879 -username MyAdminUser -password MyAdminPassword
ADMU0116I: La información de la herramienta se anota en el archivo /usr/WebSphere/AppServer/logs/syncNode.log ADMU0401I: Comienza la operación de syncNode para el nodo My511Node con el gestor de despliegue dmgrhostname: 8879 ADMU0111E: Saliendo del programa con el error: com.ibm.websphere.management.exception. AdminException: ADMU2092E: El nodo y el gestor de despliegue deben tener las mismas extensiones de producto, pero no pueden coincidir. La extensión de producto del nodo es BASE y la extensión de producto del gestor de despliegue es PME. ADMU0211I: Puede ver los detalles del error en el archivo: /usr/WebSphere/AppServer/logs/syncNode.log ADMU1211I: Para obtener un rastreo completo del error, utilice la opción -trace.
- Debido a la inclusión de la anotación
javax.ejb.Remote en la especificación de EJB 3.0, es posible que determinados beans de
EJB 2.1 fallen a la hora de la compilación si los Enterprise Java Beans se han escrito para importar todos los paquetes
javax.ejb y java.rmi. Se pueden producir errores de compilación similares a los del ejemplo siguiente:
ejbModule/com/ibm/websphere/samples/trade/ejb/QuoteHome.java(17): El tipo Remoto es ambiguo
- Cuando instale la versión 6.1 de WebSphere Application Server
y un nodo federado en un gestor de despliegue de la Versión 9.0, puede detectar mensajes de excepción de seguridad imprevistos y continuos. Las anotaciones cronológicas, system.out, del agente de nodos contienen las excepciones siguientes:
[7/8/08 16:41:31:416 EDT] 0000001c DefaultTokenP E HMGR0149E: El intento de abrir una conexión a un grupo principal DefaultCoreGroup ha sido rechazado. El proceso de envío tiene un nombre de wasinst101Cell01\ndrack104Node08\server1 y una dirección IP de /9.42.92.86. La seguridad global del proceso local está habilitada. La seguridad global del proceso de envía está habilitada. La señal recibida comienza con x2>W 9 Sv?. La excepción es com.ibm.websphere.security.auth.WSLoginFailedException: La validación de la señal LTPA ha fallado debido a claves no válidas o a un tipo de señal no válido. at com.ibm.ws.security.ltpa.LTPAServerObject. validateToken(LTPAServerObject.java:876) at com.ibm.ws.security.token.WSCredentialTokenMapper. validateLTPAToken(WSCredentialTokenMapper.java:1178) at com.ibm.ws.hamanager.runtime.DefaultTokenProvider. authenticateMember(DefaultTokenProvider.java:214) at com.ibm.ws.hamanager.coordinator.impl.DCSPluginImpl. authenticateMember(DCSPluginImpl.java:723) at com.ibm.ws.dcs.vri.transportAdapter.rmmImpl.ptpDiscovery. DiscoveryRcv.acceptStream(DiscoveryRcv.java:266) at com.ibm.rmm.ptl.tchan.receiver.PacketProcessor. fetchStream(PacketProcessor.java:470) at com.ibm.rmm.ptl.tchan.receiver.PacketProcessor. run(PacketProcessor.java:917)
El gestor de despliegue utiliza la Versión 9.0 y todos los nodos y nodos alias utilizan la versión 6.1. Para resolver este problema, actualice todos los nodos de la versión 6.1 por los de la versión 6.1.0.17 o posterior.
Los puertos nuevos que se registran en un agente de nodo de la Versión 9.0 migrado son: WC_defaulthost, WC_defaulthost_secure, WC_adminhost, WC_adminhost_secure SIB_ENDPOINT_ADDRESS, SIB_ENDPOINT_SECURE_ADDRESS, SIB_MQ_ENDPOINT_ADDRESS, SIB_MQ_ENDPOINT_SECURE_ADDRESS. Estos puertos no los necesita el agente de nodos y se pueden suprimir con seguridad.
Qué hacer a continuación
Si el problema no aparece en la lista, póngase en contacto con el servicio de soporte IBM.


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-dist&topic=tmig_troubleshoot
File name: tmig_troubleshoot.html