WebSphere Enterprise Service Bus, Versão 6.2.0 Sistemas Operacionais: AIX, HP-UX, i5/OS, Linux, Solaris, Windows


Atualizando o Cloudscape Manualmente

Durante o upgrade do WebSphere ESB versão 6.2, as ferramentas de migração tentam atualizar instâncias do Cloudscape que são acessadas somente através da estrutura integrada. (A nova versão do Cloudscape é a versão 10.1.x, que é baseada no Derby.) O upgrade automático exclui instâncias do Cloudscape que efetuam transações com aplicativos através da estrutura do Network Server. Essa exclusão elimina o risco de corromper aplicativos de terceiros que acessam as mesmas instâncias do banco de dados que o WebSphere ESB. Você deve atualizar as instâncias de banco de dados manualmente que são acessadas através da estrutura do Network Server. Faça o mesmo para bancos de dados que falham a migração automática.

Antes de Iniciar

Não utilize o Cloudscape v10.1.x como um banco de dados de produção. Utilize-o somente para finalidades de desenvolvimento e teste.

Saiba mais: A nova versão do Cloudscape combina o tempo de execução do Derby com benefícios adicionais, como IBM® QA (Garantia de Qualidade) e NLS (Suporte ao Idioma Nacional).
Para instâncias do Cloudscape que são acessadas através da estrutura integrada, determine quais instâncias falharam completamente o processo de upgrade automático e quais foram atualizadas somente parcialmente. O tópico Verificando a Migração Automática do Cloudscape v10.1.x documenta como descobrir os erros de banco de dados e os dados de diagnóstico de diversos logs de migração. As mensagens de log contêm os nomes de caminho exatos antigo e novo do banco de dados que você deve utilizar para executar a migração manual. Observe esses novos nomes de caminho de forma precisa.

Para minimizar o risco de erros de migração para bancos de dados que foram somente parcialmente atualizados durante o processo de migração automática, exclua o novo banco de dados. Solucione problemas do banco de dados original de acordo com os dados de diagnóstico do log, em seguida, execute a migração manual no banco de dados original.

Sobre Esta Tarefa

A seção a seguir consiste em etapas para migrar as instâncias do Cloudscape que são acessadas através de ambas as estruturas: a integrada, assim como a estrutura do Network Server. As etapas que se aplicam somente à estrutura do Cloudscape Network Server são marcadas conforme necessário. Como uma boa prática de migração, assegure-se de que seu ID de usuário tem uma das seguintes autoridades: Caso contrário, você poderá ver erros de tempo de execução de que a instância do banco de dados é de leitura.
Procedimento
  1. Somente estrutura do Network Server: Assegure-se de que cada cliente do banco de dados Cloudscape possa suportar o Cloudscape v10.1.x. Clientes do WebSphere ESB do banco de dados devem executar versões 6.0.1.x ou superior do WebSphere ESB.
  2. Somente estrutura do Network Server: Coloque o banco de dados off-line. Nenhum cliente pode acessá-lo durante o processo de migração.
  3. Examine um script de migração de amostra Cloudscape fornecido pelo WebSphere ESB. Dependendo de seu sistema operacional, o WebSphere ESB fornece um dos seguintes scripts de migração:
    • For Linux operating systemFor UNIX operating system Nas plataformas Linux® e UNIX®: Utilize o script db2jmigrate.sh, localizado no seguinte diretório: install_root/derby/bin/embedded/...
    • For Windows operating system Nas plataformas Windows®: Utilize o script db2jmigrate.bat, localizado no seguinte diretório: install_root\derby\bin\embedded\...
    É possível modificar o script de acordo com os requisitos de seu ambiente. Consulte Migrando o IBM Cloudscape para a Versão 10 para obter informações sobre opções que podem ser utilizadas com o script. Por exemplo, é possível utilizar a opção -DB2j.migrate.ddlFile=filename para especificar o arquivo DDL para o novo banco de dados.
  4. Para gerar logs de depuração do banco de dados ao executar o script de migração, assegure-se de que o rastreio de migração de depuração esteja ativo. Por padrão, essa função de rastreio está ativada. Ative o rastreio de depuração novamente se estiver desativada.
    1. Para configurar as opções de rastreio no console administrativo, clique em Resolução de Problemas > Criação de Log e Rastreio na árvore de navegação do console.
    2. Selecione o nome do servidor.
    3. Clique em Alterar Detalhes do Nível de Log.
    4. Opcional: Se Todos os Componentes tiver sido ativado, você pode querer desativá-lo e, em seguida, ativar componentes específicos.
    5. Opcional: Selecione um nome de componente ou de grupo. Para obter informações adicionais, consulte Configurações do Nível de Log no Centro de Informações do WebSphere Application Server Network Deployment, versão 6.1. Se o servidor selecionado não estiver em execução, não será possível ver o componente individual no modo gráfico.
    6. Insira uma cadeia de rastreio na caixa de cadeia de rastreio. Nesse caso, digite um dos seguintes:
      • all traces*=all
      • com.ibm.ws.migration.WASUpgrade=all

      Para obter informações adicionais sobre rastreio, leia Trabalhando com Rastreio no Centro de Informações do WebSphere Application Server Network Deployment, versão 6.1.

    7. Selecione Aplicar, em seguida, OK.
  5. Especifique o nome do banco de dados antigo e o caminho pós-migração completo do nome do novo banco de dados ao executar o script. Por exemplo: E:\WebSphere\ProcServer\derby\bin\embedded>db2jMigrate.bat myOldDB myNewDB Os logs da migração automática fornecem os nomes de caminho exatos para o banco de dados antigo e o banco de dados de destino. Você deve utilizar esse nome de banco de dados de destino para especificar o novo banco de dados, pois suas origens de dados Cloudscape migradas (atualizadas pelos utilitários de migração do WebSphere ESB) agora apontam para o nome do banco de dados de destino. O texto de amostra a seguir demonstra como as mensagens de log exibem nomes de bancos de dados de destino:
    Cloudscape migration of database instance C:\temp\migration2\profiles\Srv01\
    installedApps\ghongellNode01Cell\DynamicQuery.ear\EmployeeFinderDB to 
    new database instance 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 instâncias do Cloudscape que são acessadas através da estrutura do Network Server, digite qualquer nome desejado para o novo banco de dados. Lembre-se de modificar suas origens de dados existentes para apontar para o novo nome de banco de dados.
  6. Quando o processo de migração termina, examine o log de migração do banco de dados para verificar os resultados. O nome do caminho de cada log de migração de banco de dados é install_root/logs/derby/myFulldbPathName_migrationLog.log.
    Para uma migração bem-sucedida, o log de migração do banco de dados exibe uma mensagem que é semelhante ao texto a seguir:
    Check E:\WebSphere\ESB\derby\myOldDB_migrationLog.log for progress 
    Migration Completed Successfully 
    E:\WebSphere\ESB\derby\bin\embedded>
    Caso contrário, o log exibe mensagens de erro no formato do exemplo a seguir:
    Check E:\WebSphere\ESB\derby\myOldDB_migrationLog.log for progress
    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)
  7. Para obter dados adicionais sobre um erro de migração, consulte o log de depuração que corresponde ao log de migração do banco de dados. O nome do caminho completo de um arquivo de log de depuração é install_root/logs/derby/myFulldbPathName_migrationDebug.log
    As linhas a seguir são uma amostra do texto de depuração.
    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

Conforme indicado nas etapas anteriores, o log de migração de banco de dados exibe uma mensagem Migração Concluída com Êxito ou uma mensagem que contém exceções de falha de migração.

O que Fazer Depois


task Tópico de Tarefa

Termos de Uso | Feedback


Ícone de registro de data e hora Última Atualização: 01 julho 2010


http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic//com.ibm.websphere.wesb620.doc/doc/tdat_vtv_mancloudsmig.html
Copyright IBM Corporation 2005, 2010. Todos os Direitos Reservados.
Este Centro de Informações foi desenvolvido com tecnologia Eclipse (http://www.eclipse.org).