public.dhe.ibm.compublic.dhe.ibm.com/ps/products/db2/info/vr9/pdf/letter/nlv/pt_BR/db2... ·...
Transcript of public.dhe.ibm.compublic.dhe.ibm.com/ps/products/db2/info/vr9/pdf/letter/nlv/pt_BR/db2... ·...
DB2®
Guia de Migração
DB2 Versão 9
para Linux, UNIX e Windows
G517-8410-00
���
DB2®
Guia de Migração
DB2 Versão 9
para Linux, UNIX e Windows
G517-8410-00
���
Antes de utilizar estas informações e o produto a que elas se referem, certifique-se de ter lido as informações gerais na seção
Avisos.
Avisos sobre a Edição
Este documento contém informações de propriedade da IBM. Ele é fornecido sob um acordo de licença e é
protegido pela lei de copyright. As informações contidas nesta publicação não incluem garantias de produto, e
nenhuma declaração feita neste manual deve ser interpretada como tal.
Você pode solicitar publicações da IBM on-line ou através do representante IBM local.
v Para solicitar publicações on-line, acesse o IBM Publications Center em www.ibm.com/shop/publications/order
v Para localizar o representante IBM local, acesse o IBM Directory of Worldwide Contacts em www.ibm.com/planetwide
Para solicitar publicações do DB2 através do Departamento de Marketing e Vendas nos Estados Unidos e Canadá,
ligue para 1-800-IBM-4YOU (426-4968). No Brasil, ligue para 0-800-7014-262.
Quando o Cliente envia seus comentários, concede direitos, não exclusivos, à IBM para usá-los ou distribuí-los da
maneira que achar conveniente, sem que isso implique em qualquer compromisso ou obrigação para com o Cliente.
© Direitos Autorais International Business Machines Corporation 2006. Todos os direitos reservados.
Índice
Sobre Este Manual . . . . . . . . . vii
Quem Deve Utilizar Este Manual . . . . . . . vii
Como Este Manual É Estruturado . . . . . . . vii
Parte 1. Migração do Seu Ambiente
DB2 . . . . . . . . . . . . . . . . 1
Capítulo 1. Migração para o DB2 Versão
9 . . . . . . . . . . . . . . . . . . 3
Capítulo 2. Planejamento de Migração
para Seu Ambiente DB2 . . . . . . . . 5
Planejamento de Migração para o Ambiente do DB2 5
Planejando a Migração de Servidores DB2 . . . . 7
Planejando a Migração para Clientes DB2 . . . . . 9
Planejando a Migração para Aplicativos de Banco de
Dados e Rotinas . . . . . . . . . . . . . 11
Parte 2. Migrando Servidores DB2 15
Capítulo 3. Visão Geral da Migração
para Servidores DB2 . . . . . . . . . 17
Capítulo 4. Princípios Básicos da
Migração para Servidores DB2 . . . . 19
Princípios de Migração para Servidores DB2 . . . 19
O que É Migrado . . . . . . . . . . . . 20
Restrições de Migração para Servidores DB2 . . . 21
Recomendações de Migração para Servidores DB2 24
Requisitos de Espaço em Disco para a Migração do
Servidor DB2 . . . . . . . . . . . . . . 26
Alterações de Suporte para Servidores DB2 de 32
Bits e 64 Bits . . . . . . . . . . . . . . 28
Funcionalidade Obsoleta ou Descontinuada em
Produtos do Banco de Dados DB2 que Afeta a
Migração . . . . . . . . . . . . . . . 30
Suporte ao Cliente do DB2 para Migração . . . . 32
Capítulo 5. Tarefas de Pré-migração . . 35
Tarefas de Pré-migração para Servidores DB2 . . . 35
Verificando se Seus Bancos de Dados Estão Prontos
para Migração . . . . . . . . . . . . . 37
Fazendo Backup dos Bancos de Dados antes da
Migração . . . . . . . . . . . . . . . 38
Salvando Informações de Configuração . . . . . 39
Aumentando os Tamanhos de Espaço de Tabela e
Arquivo de Registro Antes da Migração . . . . . 42
Alterando Dispositivos Brutos para Bloquear
Dispositivos (Linux) . . . . . . . . . . . 44
Migrando em um Ambiente de Teste . . . . . . 46
Capturando Informações de Erros e de Diagnóstico
Durante a Migração . . . . . . . . . . . 47
Colocando um Servidor DB2 Off-line antes da
Migração . . . . . . . . . . . . . . . 49
Capítulo 6. Migrando Servidores DB2
(Windows) . . . . . . . . . . . . . 51
Migrando um Servidor DB2 (Windows) . . . . . 51
Migrando Instâncias . . . . . . . . . . . 53
Migrando o DAS (DB2 Administration Server) . . . 54
Migrando os Bancos de Dados . . . . . . . . 56
Capítulo 7. Migrando Servidores DB2
(Linux e UNIX) . . . . . . . . . . . 59
Migrando um Servidor DB2 (Linux e UNIX) . . . 59
Migrando Instâncias . . . . . . . . . . . 60
Migrando o DAS (DB2 Administration Server) . . . 62
Migrando os Bancos de Dados . . . . . . . . 64
Capítulo 8. Migrando Ambientes com
Características Específicas . . . . . . 67
Migrando Ambientes com Características Específicas 67
Migrando Servidores DB2 de 32 Bits para Sistemas
de 64 Bits (Windows) . . . . . . . . . . . 68
Migrando Servidores DB2 de 32 Bits para Sistemas
de 64 Bits (Linux e UNIX) . . . . . . . . . 69
Migrando para um Novo Servidor DB2 . . . . . 72
Migrando Ambientes de Bancos de Dados
Particionados . . . . . . . . . . . . . . 74
Migrando de um Sistema com Várias Cópias do
DB2 (Linux e UNIX) . . . . . . . . . . . 76
Migrando dos Servidores DB2 UDB Versão 7
(Windows) . . . . . . . . . . . . . . . 78
Migrando dos Servidores DB2 UDB Versão 7 (Linux
e UNIX) . . . . . . . . . . . . . . . 79
Migrando Servidores DB2 nos Ambientes do
Microsoft Cluster Server . . . . . . . . . . 79
Migrando Ambientes do DB2 Data Links Manager 81
Migrando o XML Extender . . . . . . . . . 83
Migrando de Sistemas de Gerenciamento de Banco
de Dados Relacional Não-DB2 . . . . . . . . 84
Capítulo 9. Tarefas de Pós-migração . . 87
Tarefas de Pós-migração para Servidores DB2 . . . 87
Ajustando o Tamanho do Espaço de Registro em
Bancos de Dados Migrados . . . . . . . . . 89
Banco de Dados Ativado Após a Migração . . . . 90
Alterações nas Variáveis de Registro do DB2, nos
Parâmetros de Configuração e nas Características de
Design Físico do Banco de Dados . . . . . . . 91
Conversão dos Índices Tipo 1 em Bancos de Dados
Migrados . . . . . . . . . . . . . . . 100
Alterações no Privilégio EXECUTE em PUBLIC
para Rotinas Migradas . . . . . . . . . . 101
Religando Pacotes em Bancos de Dados Migrados 102
Migrando Tabelas de Explicação . . . . . . . 103
© Direitos Autorais IBM Corp. 2006 iii
Certificando-se de que os Tamanhos de Página dos
Espaços de Tabelas Temporários Atendem aos
Requisitos . . . . . . . . . . . . . . 104
Verificando a Migração dos Servidores DB2 . . . 105
Inicialização de Replicação de HADR em Bancos
de Dados Migrados . . . . . . . . . . . 107
Capítulo 10. Revertendo a Migração
do Servidor DB2 . . . . . . . . . . 109
Parte 3. Migrando Clientes DB2 111
Capítulo 11. Visão Geral da Migração
para Clientes DB2 . . . . . . . . . 113
Capítulo 12. Essenciais da Migração
para Clientes DB2 . . . . . . . . . 115
Capítulo 13. Tarefas de Pré-migração 119
Tarefas de Pré-migração para Clientes DB2 . . . 119
Salvando Informações sobre a Configuração do
Cliente DB2 . . . . . . . . . . . . . . 119
Capítulo 14. Migrando Clientes DB2
(Windows) . . . . . . . . . . . . . 121
Migrando um Cliente DB2 (Windows) . . . . . 121
Migrando o DB2 Runtime Client (Windows) . . . 123
Migrando de Clientes DB2 Versão 7 (Windows) . . 124
Capítulo 15. Migrando Clientes DB2
(Linux e UNIX) . . . . . . . . . . . 127
Migrando Clientes DB2 (Linux e UNIX) . . . . 127
Migrando dos Clientes DB2 Versão 7 (Linux e
UNIX) . . . . . . . . . . . . . . . . 129
Capítulo 16. Tarefas de Pós-migração 131
Tarefas de Pós-migração para Clientes DB2 . . . 131
Recatalogando Nós e Bancos de Dados que
Utilizam os Protocolos NetBIOS e SNA . . . . . 131
Verificando a Migração de Clientes DB2 . . . . 133
Parte 4. Migrando Aplicativos e
Rotinas de Banco de Dados . . . . 135
Capítulo 17. Visão Geral da Migração
para Aplicativos de Banco de Dados e
Rotinas . . . . . . . . . . . . . . 137
Capítulo 18. Princípios de Migração
para Aplicativos de Banco de Dados . 139
Capítulo 19. Princípios de Migração
para Rotinas . . . . . . . . . . . . 147
Capítulo 20. Tarefas de Pré-migração
para Aplicativos de Banco de Dados e
Rotinas . . . . . . . . . . . . . . 151
Capítulo 21. Migrando Aplicativos de
Banco de Dados . . . . . . . . . . 153
Migrando Aplicativos de Banco de Dados . . . . 153
Migrando Aplicativos SQL e CLI Incorporados . . 155
Migrando Aplicativos Java que Utilizam IBM DB2
Driver para JDBC e SQLJ . . . . . . . . . 157
Migrando Aplicativos Java que Utilizam Driver
JDBC Tipo 2 ou Tipo 3 do DB2 . . . . . . . 159
Migrando Aplicativos ADO.NET . . . . . . . 160
Migrando Scripts . . . . . . . . . . . . 162
Migrando Aplicativos de Banco de Dados de 32
Bits para Execução em Instâncias de 64 Bits . . . 164
Capítulo 22. Migrando Rotinas . . . . 167
Migrando Rotinas . . . . . . . . . . . . 167
Migrando Rotinas C, C++ e COBOL . . . . . . 169
Migrando Rotinas Java . . . . . . . . . . 171
Migrando Rotinas .NET CLR . . . . . . . . 174
Migrando Procedimentos SQL . . . . . . . . 175
Migrando Rotinas Externas de 32 Bits para
Execução em Instâncias de 64 Bits . . . . . . 177
Capítulo 23. Tarefas de Pós-migração
para Aplicativos de Banco de Dados e
Rotinas . . . . . . . . . . . . . . 181
Apêndices . . . . . . . . . . . . . 183
Apêndice A. DB2 Information Center
Versão 9 . . . . . . . . . . . . . 185
Apêndice B. Referências Importantes 187
Apêndice C. Informações Técnicas
sobre o Banco de Dados DB2 . . . . 189
Visão Geral das Informações Técnicas do DB2 . . 189
Feedback das Documentações . . . . . . . 189
Biblioteca Técnica do DB2 em Formato PDF . . . 190
Solicitando Manuais Impressos do DB2 . . . . . 193
Exibindo Ajuda de Estado SQL a partir do
Processador de Linha de Comandos . . . . . . 194
Acessando Diferentes Versões do DB2 Information
Center . . . . . . . . . . . . . . . . 194
Exibindo Tópicos em Seu Idioma Preferido no
Centro de Informações do DB2 . . . . . . . 194
Atualizando o Centro de Informações do DB2
Instalado em seu Computador ou em um Servidor
de Intranet . . . . . . . . . . . . . . 195
Tutoriais do DB2 . . . . . . . . . . . . 197
Informações sobre Resolução de Problemas do DB2 198
Termos e Condições . . . . . . . . . . . 198
Apêndice D. Avisos . . . . . . . . . 201
iv Guia de Migração
Marcas Comerciais . . . . . . . . . . . 203
Índice Remissivo . . . . . . . . . . 205
Entrando em Contato com a IBM . . . 209
Índice v
vi Guia de Migração
Sobre Este Manual
O Guia de Migração descreve o processo e os conceitos de migração para cada
componente de seu ambiente do DB2. Estes componentes são servidores DB2,
clientes, aplicativos de banco de dados e rotinas do DB2.
Quem Deve Utilizar Este Manual
Este manual é destinado a administradores de banco de dados, administradores e
operações de sistema que precisam migrar servidores DB2 e clientes DB2. Ele
também é destinado a programadores e outros usuários que precisam migrar
aplicativos e rotinas de banco de dados.
Como Este Manual É Estruturado
Este manual contém informações sobre como criar um plano de migração e migrar
cada componente do seu ambiente DB2:
v Parte 1, “Migração do Seu Ambiente DB2”, na página 1
v Parte 2, “Migrando Servidores DB2”, na página 15
v Parte 3, “Migrando Clientes DB2”, na página 111
v Parte 4, “Migrando Aplicativos e Rotinas de Banco de Dados”, na página 135
v “Apêndices” na página 183
© Direitos Autorais IBM Corp. 2006 vii
viii Guia de Migração
Parte 1. Migração do Seu Ambiente DB2
Esta parte do manual contém os seguintes capítulos:
Capítulo 1, “Migração para o DB2 Versão 9”, na página 3
Capítulo 2, “Planejamento de Migração para Seu Ambiente DB2”, na página 5
© Direitos Autorais IBM Corp. 2006 1
2 Guia de Migração
Capítulo 1. Migração para o DB2 Versão 9
O upgrade para um novo release do produto do banco de dados DB2 pode exigir a
migração dos componentes do seu ambiente. A migração desses componentes
requer um entendimento dos conceitos de migração do produto do banco de dados
DB2 e um entendimento completo dos produtos do banco de dados DB2. Por
exemplo, se você tiver um ambiente existente utilizando os produtos DB2 UDB
Versão 8 e quiser instalar o DB2 Versão 9, deverá migrar seu ambiente.
O processo de migração consiste em todas as tarefas que precisam ser
desempenhadas para que o ambiente do DB2 seja executado de forma
bem-sucedida em um novo release. A migração de cada um dos componentes em
seu ambiente para o DB2 Versão 9 requer que você execute tarefas diferentes:
v A migração de servidores DB2 envolve a migração das instâncias e dos bancos
de dados existentes de modo que eles possam ser executados no DB2 Versão 9.
v A migração de clientes DB2 envolve a migração de suas instâncias clientes para
manter a configuração dos clientes DB2 existentes.
v A migração de aplicativos de banco de dados e rotinas envolve testá-los no DB2
Versão 9 e modificá-los somente quando você precisar dar suporte a alterações
no DB2 Versão 9.
As informações a seguir são fornecidas para documentar o processo de migração
para o DB2 Versão 9:
v As visões gerais de migração definem conceitos de migração e descrevem o
processo de migração para um componente.
v Os essenciais de migração incluem os detalhes sobre o suporte de migração,
restrições e recomendações que você precisar saber para planejar sua estratégia
de migração.
v As tarefas de pré-migração descrevem todas as tarefas de preparação necessárias
a executar antes da migração.
v As tarefas de migração descrevem passo a passo o processo básico de migração
para um componente e como migrar ambientes com características especiais.
v As tarefas de pós-migração descrevem todas as tarefas que precisam ser
desempenhadas após a migração para que o servidor DB2 seja executado em seu
melhor nível.
Conceitos Relacionados:
v Capítulo 18, “Princípios de Migração para Aplicativos de Banco de Dados”, na
página 139
v Capítulo 12, “Essenciais da Migração para Clientes DB2”, na página 115
v “Princípios de Migração para Servidores DB2” na página 19
v Capítulo 19, “Princípios de Migração para Rotinas”, na página 147
v “Planejamento de Migração para o Ambiente do DB2” na página 5
© Direitos Autorais IBM Corp. 2006 3
4 Guia de Migração
Capítulo 2. Planejamento de Migração para Seu Ambiente DB2
Este capítulo descreve como planejar a migração do seu ambiente. Ele contém as
seguintes seções:
v “Planejamento de Migração para o Ambiente do DB2”
v “Planejando a Migração de Servidores DB2” na página 7
v “Planejando a Migração para Clientes DB2” na página 9
v “Planejando a Migração para Aplicativos de Banco de Dados e Rotinas” na
página 11
Planejamento de Migração para o Ambiente do DB2
Seu ambiente possui diversos componentes, tais como servidores DB2, clientes
DB2, aplicativos de banco de dados, scripts, rotinas e ferramentas. O planejamento
de sua migração requer um entendimento completo do processo de migração para
cada componente em seu ambiente.
Primeiro, você precisa planejar uma estratégia sobre como abordar a migração do
seu ambiente. É necessário determinar a ordem em que cada componente será
migrado. As características do ambiente e as informações nos princípios de
migração, principalmente as recomendações e restrições de migração, podem
ajudá-lo a determinar sua estratégia. O gráfico a seguir descreve o roteiro de
migração recomendado para os componentes em seu ambiente:
A seguir está um exemplo de uma boa estratégia de migração na qual você testa
seus aplicativos de banco de dados e rotinas e determina se eles serão executados
com êxito no DB2 Versão 9:
© Direitos Autorais IBM Corp. 2006 5
1. Configure um servidor de teste do DB2 Versão 9 e crie bancos de dados de
teste.
2. Teste os aplicativos de banco de dados e as rotinas em um banco de dados de
teste do DB2 Versão 9 para determinar se eles serão executados com êxito.
3. Migre em um ambiente de teste. Determine quais são os problemas de
migração e como resolvê-los. Utilize essas informações para ajustar seu plano
de migração.
4. Migre seus servidores DB2 para o DB2 Versão 9 em seu ambiente de produção.
Certifique-se de que eles estejam operando conforme o esperado.
5. Migre seus clientes DB2 para o DB2 Versão 9 em seu ambiente de produção.
Certifique-se de que os clientes DB2 estejam operando conforme o esperado.
6. Teste seus aplicativos de banco de dados e suas rotinas no ambiente migrado
do DB2 Versão 9 para determinar se eles serão executados conforme o
esperado.
7. Disponibilize seu ambiente migrado para os usuários.
8. Identifique a utilização de recursos obsoletos que eventualmente se tornarão
recursos não-suportados e novos que podem aprimorar a funcionalidade e o
desempenho dos aplicativos e das rotinas. Planeje como modificar seus
aplicativos e suas rotinas.
9. Modifique seus aplicativos de banco de dados e suas rotinas conforme o
planejado. Certifique-se de que eles sejam executados com êxito no DB2 Versão
9.
Quando tiver uma estratégia que lhe dê o esboço para seu plano de migração, você
poderá definir os detalhes do plano de migração para cada componente em seu
ambiente. Um plano de migração deve incluir para cada componente:
v Pré-requisitos de migração
v Tarefas de pré-migração
v Tarefas de migração
v Tarefas de pós-migração
Reveja os planos de migração anteriores e compare-os com o plano de migração
para o DB2 Versão 9. Inclua em seu novo plano todas as etapas relacionadas a
procedimentos internos para solicitar acesso, instalação de software ou outros
serviços do sistema dentro de sua organização.
Finalmente, planeje a remoção da utilização de recursos obsoletos e incorpore
novos recursos do DB2 Versão 9. Embora você só precise remover a utilização de
recursos não-suportados, você também deve planejar a remoção da utilização dos
recursos obsoletos após a migração, pois eles não serão mais suportados em um
futuro release. Além disso, você deve tirar proveito dos novos recursos para os
produtos do banco de dados, aplicativos e rotinas e para aumentar a
funcionalidade e aprimorar o desempenho.
Tarefas Relacionadas:
v “Planejando a Migração para Aplicativos de Banco de Dados e Rotinas” na
página 11
v “Planejando a Migração para Clientes DB2” na página 9
v “Planejando a Migração de Servidores DB2” na página 7
6 Guia de Migração
Planejando a Migração de Servidores DB2
O planejamento da migração dos servidores DB2 requer que você reveja todos os
pré-requisitos de migração aplicáveis, tarefas de pré-migração, tarefas de migração
e tarefas de pós-migração.
Procedimento:
Para criar um plano de migração para os servidores DB2:
1. Grave o plano de migração para os servidores DB2 utilizando todos os detalhes
que se aplicam ao seu ambiente:
Tabela 1. Detalhes do Plano de Migração para Servidores DB2.
Plano de migração Detalhes
Pré-requisitos Certifique-se de:
v atender requisitos de hardware e de sistema operacional.
v resolver quaisquer problemas de suporte em princípios de
migração para servidores DB2.
v atender a todos os pré-requisitos para a tarefa e as subtarefas de
migração, principalmente obter acesso root ou de Administrador
Local e autorização requerida para o DB2.
Tarefas de
pré-migração
Incluem as seguintes tarefas:
v Migrar seu servidor DB2 em um ambiente de teste para
determinar quaisquer problemas de migração
v Verificar se os bancos de dados estão prontos para a migração do
DB2
v Fazer backup dos bancos de dados
v Salvar informações de configuração
v Aumentar os tamanhos do espaço de tabelas e do arquivo de
registro
v Capturar informações sobre erros e diagnósticos durante a
migração
v Deixar o servidor DB2 off-line para a migração do DB2
Além disso, verifique a lista de tarefas de pré-migração para
conhecer as tarefas opcionais que você pode querer executar para o
seu ambiente.
Tarefa de migração Você deve incluir estas etapas:
v Instale o DB2 Versão 9
v Migrar instâncias
v Migrar o DAS
v Migrar bancos de dados
Reveja as tarefas de migração a seguir para determinar as etapas
adicionais que são requeridas para migrar seu ambiente:
v Migrando um DB2 Server (Windows)
v Migrando um DB2 Server (Linux e UNIX)
v Migrando Ambientes com Características Específicas
Tome nota do tempo requerido para migrar seus bancos de dados.
Capítulo 2. Planejamento de Migração para Seu Ambiente DB2 7
Tabela 1. Detalhes do Plano de Migração para Servidores DB2. (continuação)
Plano de migração Detalhes
Tarefas de
pós-migração
v Reconfigure o parâmetro de configuração do gerenciador de
banco de dados diaglevel com o valor configurado antes da
migração
v Ajuste o tamanho do espaço de registro
v Reveja as alterações nas configurações dos parâmetros de
configuração e dos valores das variáveis de registro do DB2
v Converta índices do tipo 1 em índices do tipo 2 em bancos de
dados migrados
v Revogue o privilégio EXECUTE de PUBLIC em funções e
procedimentos
v Religue pacotes em bancos de dados migrados
v Migre tabelas do DB2 Explain
v Verifique o tamanho da página dos espaços de tabelas
temporários do sistema para o tamanho máximo da linha nos
conjuntos de resultados
v Ative o banco de dados após a migração
v Verificar se a migração do servidor DB2 foi bem-sucedida
v Fazer backup dos bancos de dados após a migração ser
concluída
Além disso, verifique a lista de tarefas de pós-migração para
conhecer as tarefas opcionais que você pode querer executar para o
seu ambiente. Considere a inclusão das seguintes tarefas em seu
plano de migração:
v Ajustar seu servidor DB2 após a migração ser concluída
v Remova a utilização de recursos obsoletos no DB2 Versão 9
v Implementar a utilização de novos recursos, onde apropriado,
para aprimorar o desempenho no nível do servidor DB2. Rever
aprimoramentos de maneabilidade, desempenho e escalabilidade
em O que Há de Novo para determinar quais novos recursos
você pode querer aplicar em seu ambiente
2. Caso você precise estar preparado para inverter a migração, inclua detalhes no
plano sobre as tarefas requeridas para reverter a migração do servidor DB2.
Esses detalhes devem incluir todas as etapas requeridas na tarefa de migração
que permitem reverter a migração.
3. Faça uma combinação com o plano de migração para obter outros
componentes, tais como clientes DB2, aplicativos de banco de dados e rotinas
para criar um plano de migração geral.
Conceitos Relacionados:
v “Princípios de Migração para Servidores DB2” na página 19
v “Migrando Ambientes com Características Específicas” na página 67
v “Funcionalidade Obsoleta ou Descontinuada em Produtos do Banco de Dados
DB2 que Afeta a Migração” na página 30
v “O que Há de Novo na V9.1: Resumo de Aprimoramentos na Capacidade de
Gerenciamento” em O que Há de Novo
v “O que Há de Novo na V9.1: Resumo de Aprimoramentos no Desempenho” em
O que Há de Novo
v “O que Há de Novo na V9.1: Resumo de Aprimoramentos na Escalabilidade”
em O que Há de Novo
8 Guia de Migração
v “Planejamento de Migração para o Ambiente do DB2” na página 5
Tarefas Relacionadas:
v “Migrando em um Ambiente de Teste” na página 46
v “Verificando se Seus Bancos de Dados Estão Prontos para Migração” na página
37
v “Fazendo Backup dos Bancos de Dados antes da Migração” na página 38
v “Salvando Informações de Configuração” na página 39
v “Aumentando os Tamanhos de Espaço de Tabela e Arquivo de Registro Antes da
Migração” na página 42
v “Capturando Informações de Erros e de Diagnóstico Durante a Migração” na
página 47
v “Colocando um Servidor DB2 Off-line antes da Migração” na página 49
v “Migrando Instâncias” na página 53
v “Migrando o DAS (DB2 Administration Server)” na página 54
v “Migrando os Bancos de Dados” na página 56
v “Migrando um Servidor DB2 (Windows)” na página 51
v “Migrando um Servidor DB2 (Linux e UNIX)” na página 59
v “Ajustando o Tamanho do Espaço de Registro em Bancos de Dados Migrados”
na página 89
v “Religando Pacotes em Bancos de Dados Migrados” na página 102
v “Migrando Tabelas de Explicação” na página 103
v “Certificando-se de que os Tamanhos de Página dos Espaços de Tabelas
Temporários Atendem aos Requisitos” na página 104
v “Verificando a Migração dos Servidores DB2” na página 105
v “Desenvolvendo um Processo de Aperfeiçoamento de Desempenho” em
Performance Guide
v Capítulo 10, “Revertendo a Migração do Servidor DB2”, na página 109
v “Planejando a Migração para Aplicativos de Banco de Dados e Rotinas” na
página 11
v “Planejando a Migração para Clientes DB2” na página 9
Referência Relacionada:
v “Tarefas de Pré-migração para Servidores DB2” na página 35
v “Alterações nas Variáveis de Registro do DB2, nos Parâmetros de Configuração e
nas Características de Design Físico do Banco de Dados” na página 91
v “Conversão dos Índices Tipo 1 em Bancos de Dados Migrados” na página 100
v “Alterações no Privilégio EXECUTE em PUBLIC para Rotinas Migradas” na
página 101
v “Banco de Dados Ativado Após a Migração” na página 90
v “Tarefas de Pós-migração para Servidores DB2” na página 87
Planejando a Migração para Clientes DB2
O planejamento da migração dos clientes DB2 requer que você reveja todos os
pré-requisitos de migração aplicáveis, tarefas de pré-migração, tarefas de migração
e tarefa de pós-migração.
Procedimento:
Capítulo 2. Planejamento de Migração para Seu Ambiente DB2 9
Para criar um plano de migração para os clientes DB2:
1. Grave o plano de migração para os clientes DB2 utilizando todos os detalhes
que se aplicam ao seu ambiente:
Tabela 2. Detalhes do Plano de Migração para Clientes DB2.
Plano de migração Detalhes
Pré-requisitos Certifique-se de:
v atender requisitos de hardware e de sistema operacional.
v resolver quaisquer problemas de suporte em princípios de
migração para clientes DB2 incluindo conectividade de cliente e
servidor.
v atender a todos os pré-requisitos para a tarefa e as subtarefas de
migração, principalmente obter acesso root ou de Administrador
Local e autorização requerida para o DB2.
Tarefas de
pré-migração
v Migrar seus servidores DB2
v Salvar as informações sobre a configuração do cliente DB2
Tarefa de migração Você deve incluir estas etapas:
v Instalar o cliente da V9 do DB2
v Migrar a instância cliente
Reveja as tarefas de migração a seguir para determinar as etapas
adicionais que são requeridas para migrar seu ambiente:
v Migrando Cliente do DB2 (Windows)
v Migrando o DB2 Runtime Client (Windows)
v Migrando Clientes do DB2 (Linux e UNIX)
v Migrando de Clientes do DB2 Versão 7 (Windows)
v Migrando de Clientes do DB2 Versão 7 (Linux e UNIX)
.
Tarefas de
pós-migração
v Recatalogar nós e bancos de dados utilizando protocolos
NetBIOS e SNA
v Reveja as alterações nas configurações dos parâmetros de
configuração e dos valores das variáveis de registro do DB2
v Verificar se a migração para clientes DB2 foi bem-sucedida
2. Faça uma combinação com o plano de migração para obter outros
componentes, tais como clientes DB2, aplicativos de banco de dados e rotinas
para criar um plano de migração geral.
Conceitos Relacionados:
v Capítulo 12, “Essenciais da Migração para Clientes DB2”, na página 115
v Capítulo 3, “Visão Geral da Migração para Servidores DB2”, na página 17
v “Planejamento de Migração para o Ambiente do DB2” na página 5
Tarefas Relacionadas:
v “Salvando Informações sobre a Configuração do Cliente DB2” na página 119
v “Migrando um Cliente DB2 (Windows)” na página 121
v “Migrando o DB2 Runtime Client (Windows)” na página 123
v “Migrando Clientes DB2 (Linux e UNIX)” na página 127
v “Migrando de Clientes DB2 Versão 7 (Windows)” na página 124
v “Migrando dos Clientes DB2 Versão 7 (Linux e UNIX)” na página 129
10 Guia de Migração
v “Recatalogando Nós e Bancos de Dados que Utilizam os Protocolos NetBIOS e
SNA” na página 131
v “Verificando a Migração de Clientes DB2” na página 133
v “Planejando a Migração para Aplicativos de Banco de Dados e Rotinas” na
página 11
v “Planejando a Migração de Servidores DB2” na página 7
Referência Relacionada:
v “Alterações nas Variáveis de Registro do DB2, nos Parâmetros de Configuração e
nas Características de Design Físico do Banco de Dados” na página 91
Planejando a Migração para Aplicativos de Banco de Dados e Rotinas
O planejamento da migração de aplicativos de banco de dados e rotinas requer que
você reveja todas as tarefas de pré-migração, pré-requisitos de migração, tarefas de
migração e tarefas de pós-migração aplicáveis.
Procedimento:
Para criar um plano de migração para os aplicativos de banco de dados e as
rotinas:
1. Grave o plano de migração para aplicativos de banco de dados utilizando
todos os detalhes que se aplicam ao seu ambiente:
Tabela 3. Detalhes do Plano de Migração para Aplicativos de Banco de Dados.
Plano de migração Detalhes
Pré-requisitos Certifique-se de:
v atender requisitos de hardware e de sistema operacional.
v atender aos novos requisitos de software de desenvolvimento.
v resolver quaisquer problemas de suporte em princípios de
migração para aplicativos de banco de dados durante a
migração.
v atender a todos os pré-requisitos para a tarefa e as subtarefas de
migração, principalmente obter autorização requerida para o
DB2.
Tarefas de
pré-migração
Incluem as seguintes tarefas:
v Migrar seu cliente DB2 ou instalar o driver aplicativo V9
v Teste seus aplicativos de banco de dados em um ambiente de
testes do DB2 Versão 9. Se seus aplicativos forem executados
com êxito, o restante das etapas de migração não é requerido
Além disso, verifique a lista de tarefas de pré-migração para
conhecer as tarefas opcionais que você pode querer executar para o
seu ambiente. Se seu sistema operacional e seu software de
desenvolvimento atuais forem suportados, considere a inclusão das
seguintes tarefas para aprimorar o desempenho do aplicativo:
v Fazer upgrade do sistema operacional para o nível mais recente
suportado
v Fazer upgrade do software de desenvolvimento para o nível
mais recente suportado
Capítulo 2. Planejamento de Migração para Seu Ambiente DB2 11
Tabela 3. Detalhes do Plano de Migração para Aplicativos de Banco de
Dados. (continuação)
Plano de migração Detalhes
Tarefa de migração Você deve incluir estas etapas:
v Modificar o código do aplicativo para suportar alterações no DB2
Versão 9 e para remover a utilização de recursos que não são
suportados no DB2 Versão 9
v Modificar seu aplicativo para suportar alterações específicas do
ambiente de desenvolvimento
v Reconstruir todos os aplicativos de banco de dados após concluir
suas modificações.
v Testar seus aplicativos de banco de dados utilizando o DB2
Versão 9
Reveja as seguintes tarefas de migração para determinar as etapas
adicionais que são requeridas pelo seu ambiente de
desenvolvimento para migrar aplicativos de banco de dados:
v Migrando Aplicativos com CLI e SQL Incorporado
v Migrando Aplicativos Java que Utilizam o Driver IBM DB2 para
JDBC e SQLJ
v Migrando Aplicativos Java que Utilizam o Driver DB2 JDBC Tipo
2 ou 3
v Migrando Aplicativos ADO.NET
v Migrando Scripts
v Migrando Aplicativos de Banco de Dados de 32 Bits para
Executar em Instâncias de 64 Bits
Tarefas de
pós-migração
Executar as tarefas de pós-migração para aplicativos de banco de
dados que são recomendadas, principalmente:
v Ajustar o desempenho dos aplicativos de banco de dados e das
rotinas
v Remover a utilização de recursos obsoletos no DB2 Versão 9
v Implementar a utilização de novos recursos no DB2 Versão 9
para desenvolvimento de aplicativo onde for apropriado
2. Grave o plano de migração para rotinas utilizando todos os detalhes que se
aplicam ao seu ambiente:
Tabela 4. Detalhes do Plano de Migração para Rotinas.
Plano de migração Detalhes
Pré-requisitos Certifique-se de:
v atender requisitos de hardware e de sistema operacional.
v atender aos novos requisitos de software de desenvolvimento.
v resolver todos os problemas de suporte em princípios de
migração para rotinas durante a migração.
v atender a todos os pré-requisitos para a tarefa e as subtarefas de
migração, principalmente obter autorização requerida para o
DB2.
12 Guia de Migração
Tabela 4. Detalhes do Plano de Migração para Rotinas. (continuação)
Plano de migração Detalhes
Tarefas de
pré-migração
Incluem a seguinte tarefa:
v Teste suas rotinas em um ambiente de testes do DB2 Versão 9. Se
suas rotinas forem executadas com êxito, o restante das etapas de
migração não é requerido
Além disso, verifique a lista de tarefas de pré-migração para
conhecer as tarefas opcionais que você pode querer executar para o
seu ambiente. Mesmo que o sistema operacional e o software de
desenvolvimento atuais sejam suportados, considere a inclusão das
seguintes tarefas para aprimorar o desempenho:
v Fazer upgrade do sistema operacional para o nível mais recente
suportado
v Fazer upgrade do software de desenvolvimento para o nível
mais recente suportado
Tarefa de migração Você deve incluir estas etapas:
v Modificar suas rotinas para suportar alterações no DB2 Versão 9
e para remover a utilização de recursos que não são suportados
no DB2 Versão 9
v Modifique sus rotinas para suportar alterações específicas para o
ambiente de desenvolvimento
v Reconstruir todas as rotinas externas após concluir suas
modificações
v Testar novamente suas rotinas utilizando o DB2 Versão 9
Reveja as tarefas de migração a seguir para determinar as etapas
adicionais que são requeridas pelo seu ambiente de
desenvolvimento para migrar rotinas:
v Migrando Rotinas C, C++ e COBOL
v Migrando Rotinas Java
v Migrando Rotinas .NET CLR
v Migrando Procedimentos SQL
v Migrando Rotinas Externas de 32 Bits para Executar em
Instâncias de 64 Bits
Tarefas de
pós-migração
Executar as tarefas de pós-migração para rotinas que são
recomendadas, principalmente:
v Remova a utilização de recursos obsoletos no DB2 Versão 9
v Implementar a utilização de novos recursos no DB2 Versão 9
para desenvolvimento de aplicativo onde for apropriado
3. Faça uma combinação com o plano de migração para obter outros
componentes, tais como clientes DB2 e servidores DB2 para criar um plano de
migração geral.
Conceitos Relacionados:
v “O Que Há de Novo na V9.1: Novidades e Alterações no Suporte a Software de
Desenvolvimento” em O que Há de Novo
v Capítulo 18, “Princípios de Migração para Aplicativos de Banco de Dados”, na
página 139
v Capítulo 11, “Visão Geral da Migração para Clientes DB2”, na página 113
v Capítulo 20, “Tarefas de Pré-migração para Aplicativos de Banco de Dados e
Rotinas”, na página 151
Capítulo 2. Planejamento de Migração para Seu Ambiente DB2 13
v “Funcionalidade Obsoleta ou Descontinuada em Produtos do Banco de Dados
DB2 que Afeta a Migração” na página 30
v “O que Há de Novo na V9.1: Resumo de Aprimoramentos em Desenvolvimento
de Aplicativos” em O que Há de Novo
v Capítulo 19, “Princípios de Migração para Rotinas”, na página 147
v “Planejamento de Migração para o Ambiente do DB2” na página 5
Tarefas Relacionadas:
v “Migrando Aplicativos SQL e CLI Incorporados” na página 155
v “Migrando Aplicativos Java que Utilizam IBM DB2 Driver para JDBC e SQLJ”
na página 157
v “Migrando Aplicativos Java que Utilizam Driver JDBC Tipo 2 ou Tipo 3 do DB2”
na página 159
v “Migrando Aplicativos ADO.NET” na página 160
v “Migrando Scripts” na página 162
v “Migrando Aplicativos de Banco de Dados de 32 Bits para Execução em
Instâncias de 64 Bits” na página 164
v “Migrando Rotinas C, C++ e COBOL” na página 169
v “Migrando Rotinas Java” na página 171
v “Migrando Rotinas .NET CLR” na página 174
v “Migrando Procedimentos SQL” na página 175
v “Migrando Rotinas Externas de 32 Bits para Execução em Instâncias de 64 Bits”
na página 177
v “Planejando a Migração para Clientes DB2” na página 9
v “Planejando a Migração de Servidores DB2” na página 7
14 Guia de Migração
Parte 2. Migrando Servidores DB2
Esta parte do manual contém os seguintes capítulos:
Capítulo 3, “Visão Geral da Migração para Servidores DB2”, na página 17
Capítulo 4, “Princípios Básicos da Migração para Servidores DB2”, na página 19
Capítulo 5, “Tarefas de Pré-migração”, na página 35
Capítulo 6, “Migrando Servidores DB2 (Windows)”, na página 51
Capítulo 7, “Migrando Servidores DB2 (Linux e UNIX)”, na página 59
Capítulo 8, “Migrando Ambientes com Características Específicas”, na página 67
Capítulo 9, “Tarefas de Pós-migração”, na página 87
© Direitos Autorais IBM Corp. 2006 15
16 Guia de Migração
Capítulo 3. Visão Geral da Migração para Servidores DB2
Após você instalar o DB2 Versão 9 para Linux e UNIX em um servidor DB2 onde o
servidor DB2 UDB Versão 8 está instalado, você precisa migrar todas as instâncias
e bancos de dados para poder executá-los nesta versão mais recente. Para o
Windows, você tem a opção de migrar automaticamente a instância durante a
instalação. Se optar por migrar suas instâncias durante a instalação, você precisa
somente migrar seus bancos de dados.
O nível atual do DB2 instalado determinará a maneira a proceder com a migração
para o DB2 Versão 9:
v Migração do DB2 UDB Versão 8
v Migração do DB2 UDB Versão 7 ou DataJoiner Versão 2
Migração do DB2 UDB Versão 8
Caso tenha o DB2 UDB Versão 8 instalado, você pode migrar diretamente
para o DB2 Versão 9. Saiba quais são os detalhes, as limitações sobre o
processo de migração e os possíveis problemas que você precisa conhecer
na seção “Princípios de Migração para Servidores DB2” na página 19.
Consulte Migrando um Servidor DB2 para obter detalhes sobre como
migrar para o DB2 Versão 9.
Migração do DB2 UDB Versão 7 ou DataJoiner Versão 2
Se você tiver o DB2 UDB Versão 6, DB2 UDB Versão 7 ou DataJoiner
Versão 2 instalados, será necessário migrar primeiro para o DB2 UDB
Versão 8 e, em seguida, migrar para o DB2 Versão 9. A migração direta
para o DB2 Versão 9 não é suportada. É recomendável migrar para o DB2
UDB Versão 8.2. Consulte a documentação do DB2 UDB Versão 8.2 para
obter detalhes sobre como migrar para o DB2 UDB Versão 8.2.
Suporte de Migração para Produtos DB2
A migração para o DB2 Versão 9 é suportada para os seguintes produtos
DB2:
v DB2 UDB Enterprise Server Edition, Versão 8
v DB2 UDB Workgroup Server Unlimited Edition, Versão 8
v DB2 UDB Workgroup Server Edition, Versão 8
v DB2 UDB Personal Edition, Versão 8
v DB2 Universal Developer’s Edition, Versão 8
v DB2 Personal Developer’s Edition, Versão 8
v DB2 UDB Express Edition, Versão 8
v DB2 Connect Unlimited Edition, Versão 8
v DB2 Connect Enterprise Server Edition, Versão 8
v DB2 Connect Application Server Edition, Versão 8
v DB2 Connect Personal Edition, Versão 8
v DB2 Administration Client, Versão 8
v DB2 Application Development Client, Versão 8
v DB2 Runtime Client, Versão 8
v DB2 Query Patroller, Versão 8
© Direitos Autorais IBM Corp. 2006 17
Para produtos DB2 não-suportados, consulte Funcionalidade Não
Suportada no Produto do Banco de Dados DB2 que Afeta a Migração.
Portal de Migração do produto do banco de dados DB2
A finalidade do portal de migração do produto do banco de dados DB2 é
fornecer um local para você acessar todos os recursos adicionais e as
informações mais atualizadas sobre o processo de migração, conforme elas
são disponibilizadas. Esses recursos incluem white papers e scripts de
amostra para migração.
Conceitos Relacionados:
v “O que Há de Novo na V9.1: Resumo de Alterações na Funcionalidade
Existente” em O que Há de Novo
v “O que Há de Novo na V9.1: Resumo de Funcionalidade Descontinuada” em O
que Há de Novo
v “Migrando Ambientes com Características Específicas” na página 67
Tarefas Relacionadas:
v “Migrando um Servidor DB2 (Linux e UNIX)” na página 59
v “Migrando um Servidor DB2 (Windows)” na página 51
v “Migrando dos Servidores DB2 UDB Versão 7 (Linux e UNIX)” na página 79
v “Migrando dos Servidores DB2 UDB Versão 7 (Windows)” na página 78
v “Planejando a Migração de Servidores DB2” na página 7
18 Guia de Migração
Capítulo 4. Princípios Básicos da Migração para Servidores
DB2
Este capítulo descreve os princípios básicos sobre migração necessários para seus
servidores DB2. Ele contém as seguintes seções:
v “Princípios de Migração para Servidores DB2”
v “O que É Migrado” na página 20
v “Restrições de Migração para Servidores DB2” na página 21
v “Recomendações de Migração para Servidores DB2” na página 24
v “Requisitos de Espaço em Disco para a Migração do Servidor DB2” na página 26
v “Alterações de Suporte para Servidores DB2 de 32 Bits e 64 Bits” na página 28
v “Funcionalidade Obsoleta ou Descontinuada em Produtos do Banco de Dados
DB2 que Afeta a Migração” na página 30
v “Suporte ao Cliente do DB2 para Migração” na página 32
Princípios de Migração para Servidores DB2
A migração de servidores DB2 para o DB2 Versão 9 requer um entendimento dos
conceitos de migração, das restrições de migração, das recomendações de migração
e do servidor DB2. Quando tiver um entendimento completo do que envolve a
migração do seu servidor DB2, você pode criar seu próprio plano de migração.
Considere os seguintes fatores para desenvolver um entendimento completo da
migração de servidores DB2 para o DB2 Versão 9:
v O Que É Migrado
v Recomendações de Migração para Servidores DB2
v Requisitos de Espaço em Disco para a Migração de Servidor DB2
v Restrições de Migração para Servidores DB2
v Alterações de Suporte para Servidores DB2 de 32 Bits e 64 Bits
v Funcionalidade Obsoleta ou Interrompida em Produtos de Banco de Dados DB2
que Impacta a Migração
v Suporte de Cliente DB2 para Migração
Conceitos Relacionados:
v “Migrando Ambientes com Características Específicas” na página 67
v Capítulo 18, “Princípios de Migração para Aplicativos de Banco de Dados”, na
página 139
v Capítulo 12, “Essenciais da Migração para Clientes DB2”, na página 115
v Capítulo 19, “Princípios de Migração para Rotinas”, na página 147
Tarefas Relacionadas:
v “Migrando um Servidor DB2 (Linux e UNIX)” na página 59
v “Migrando um Servidor DB2 (Windows)” na página 51
v “Planejando a Migração de Servidores DB2” na página 7
Referência Relacionada:
© Direitos Autorais IBM Corp. 2006 19
v “Tarefas de Pré-migração para Servidores DB2” na página 35
v “Tarefas de Pós-migração para Servidores DB2” na página 87
O que É Migrado
Quando a migração da instância é chamada explicitamente utilizando o comando
db2imigr ou implicitamente quando você instala o DB2 Versão 9 no Windows,
ocorrem as seguintes ações:
v Migra para uma nova instância em uma cópia do DB2 Versão 9.
v Migra variáveis de registro do perfil da instância. As variáveis de registro do
perfil global configuradas pelo usuário não são migradas.
v Migra o arquivo de configuração do gerenciador de banco de dados (dbm cfg).
v Configura o parâmetro do gerenciador de banco de dados (dbm cfg)jdk_path
apropriadamente.
v Copia sobre os arquivos de configuração.
v Em um ambiente MSCS (Microsoft Cluster Server), define um novo tipo de
recurso, atualiza todos os recursos do DB2 MSCS para utilizar o novo tipo de
recurso, remove o tipo de recurso antigo e coloca todos os recursos on-line.
Para obter uma migração de instância bem-sucedida, é essencial que existam todos
os arquivos para todas as instâncias e que o acesso de gravação seja concedido. No
entanto, é necessário rever as restrições de migração para cenários específicos que
não são suportados.
Quando a migração do banco de dados é chamada de forma explícita utilizando o
comando MIGRATE DATABASE ou implicitamente utilizando o comando
RESTORE DATABASE a partir de um backup do DB2 UDB Versão 8, as seguintes
entidades do banco de dados são convertidas utilizando migração de banco de
dados:
v Arquivo de Configuração do Banco de Dados
v Cabeçalho do arquivo de registro
v Tabelas do Catálogo
v Arquivos do conjunto de buffer
v Página da raiz do índice
v Arquivo de histórico
Conceitos Relacionados:
v “Migrando Ambientes com Características Específicas” na página 67
v “Princípios de Migração para Servidores DB2” na página 19
v Capítulo 3, “Visão Geral da Migração para Servidores DB2”, na página 17
v “Recomendações de Migração para Servidores DB2” na página 24
v “Restrições de Migração para Servidores DB2” na página 21
Tarefas Relacionadas:
v “Migrando um Servidor DB2 (Linux e UNIX)” na página 59
v “Migrando um Servidor DB2 (Windows)” na página 51
20 Guia de Migração
Restrições de Migração para Servidores DB2
Antes de começar a migração do servidor DB2, você precisa entender qual é o
suporte para a migração e quais são as restrições.
O que é suportado?
Considere as seguintes restrições antes de migrar para o DB2 Versão 9:
v A migração é suportada somente a partir do DB2 UDB Versão 8. Se você
tiver o DB2 UDB Versão 7 ou anterior, primeiro será necessário migrar
para o DB2 UDB Versão 8.
v No sistema operacional Windows, você tem uma opção de migração
para migrar automaticamente uma cópia existente do DB2 UDB versão 8
durante a instalação do DB2 Versão 9. Essa opção migra
automaticamente todas as suas instâncias e seu DAS (DB2
Administration Server) e remove sua cópia do DB2 UDB versão 8. Se
não escolher a opção de migração, você deve migrar manualmente suas
instâncias executando o comando db2imigr após a instalação e seu DAS
executando o comando dasmigr.
v No sistema operacional Linux e UNIX, você pode instalar somente uma
nova cópia do DB2 Versão 9. Você precisa migrar manualmente suas
instâncias executando o comando db2imigr após a instalação. Você
também precisa migrar manualmente seu DAS existente, executando o
comando dasmigr.
v O tamanho do bit da instância é determinado pela plataforma onde o
DB2 Versão 9 está instalado e o suporte para kernels de 32 bits e 64 bits
foi alterado. A tabela a seguir especifica qual tamanho de bit de instância
é suportado em qual plataforma:
Tabela 5. Suporte a Instâncias de 32 Bits e 64 Bits do DB2.
Tamanho do
bit da
instância
Kernel
do S.O. Sistemas operacionais suportados
32 bits 32 bits v Windows em x86 ou X64 (Utilizando a imagem de instalação
do DB2 para Windows em x86)
v Linux em x86
64-bit 64-bit Linux em IPF (Itanium Platform Family)
64 bits (com
suporte a 32
bits)
64-bit v AIX, HP-UX ou Solaris
v Windows em x86-64 (Utilizando a Imagem de Instalação do
DB2 para Windows para X64)
v Windows em IPF
v Kernel Linux em zSeries, POWER ou x86-64
v A migração é suportada a partir de um sistema com várias cópias do
DB2. Cada cópia pode estar no mesmo nível (somente o DB2 Versão 9)
ou em um nível diferente do produto do banco de dados do DB2. Cada
cópia deve ter um nome de instalação e a opção para especificar o local
da instalação. O nome da instância deve ser exclusivo para todos os
nomes da instalação.
v Um ambiente de banco de dados particionado com várias partições de
banco de dados pode ser migrado. No entanto, a migração requer
instalação anterior do DB2 Versão 9 em todos os servidores de partição
Capítulo 4. Princípios Básicos da Migração para Servidores DB2 21
de banco de dados participantes. Os comandos de migração devem ser
executados a partir do servidor de partição de banco de dados que
possui a instância.
v A restauração de backups completos off-line de banco de dados do DB2
UDB Versão 8 é suportada. No entanto, não é possível efetuar
rollforward de registros de um nível anterior. Reveja as operações de
backup e restauração entre diferentes sistemas operacionais e
plataformas de hardware para obter detalhes completos sobre o suporte
à migração utilizando o comando RESTORE DATABASE para os
backups doDB2 UDB Versão 8.
v A migração de um servidor DB2 com o Query Patroller instalado é
suportada. O comando MIGRATE DATABASE configura o parâmetro de
configuração de banco de dadosdyn_query_mgmt como DISABLE. É
necessário configurar o dyn_query_mgmt como ENABLE após você
concluir a migração de banco de dados e instalar o Query Patroller
Versão 9.
v Extensões de Índice são migradas como parte da migração do banco de
dados. No entanto, talvez seja necessário recriar seus índices se você
tiver migrado de uma instância do DB2 UDB Versão 8 de 32 bits para
uma instância do DB2 Versão 9 de 64 bits. Consulte tarefas de
pós-migração para obter detalhes.
O que não é suportado?
A instalação do DB2 Versão 9 falhará na execução quando:
v O sistema operacional não for suportado. Determinadas versões dos
sistemas operacionais UNIX, Linux e Windows não são mais suportadas,
como o AIX 4.3.3, o Solaris 8, o Windows 95, o Windows 98, o Windows
NT e o Windows Me. Será necessário fazer upgrade para uma versão
suportada do sistema operacional antes de migrar para o DB2 Versão 9.
Para obter uma lista completa do sistema operacional suportado, visite a
página da Web Requisitos do Sistema para a instalação do produto do
banco de dados DB2.
v O sistema operacional está executando um kernel de 32 bits no AIX,
HP-UX, Solaris ou Linux (em zSeries, Power ou x86-64). Um kernel de
64 bits deve ser instalado antes da instalação do DB2 Versão 9. Instâncias
de 32 bits não são suportadas nessas plataformas.
O comando db2imigr falhará na execução quando:
v A instância já é uma instância do DB2 Versão 9 ou superior. Execute o
comando db2iupdt para mover entre diferentes níveis de fix packs ou
cópias do DB2 Versão 9.
v Você tenta migrar do DB2 Versão 9 de volta ao DB2 UDB Versão 8.
v Uma conexão com um banco de dados primário HADR não pode ser
estabelecida. O comando db2imigr executa o comando db2ckmig que
requer uma conexão com o banco de dados para executar as verificações
requeridas.
v O DB2 Data Links Manager Versão 8 é instalado no servidor DB2. O
DB2 Data Links Manager não é suportado no DB2 Versão 9. No entanto,
quando você executa o comando db2imigr, a mensagem de erro que é
gerada inclui instruções sobre como migrar para uma instância padrão
do DB2 Versão 9 sem a funcionalidade do DB2 Data Links Manager.
v O DB2 Data Warehouse Manager Versão 8 e quaisquer extensões são
instalados no servidor DB2. O DB2 Data Warehouse Manager não é
22 Guia de Migração
suportado no DB2 Versão 9. No entanto, quando você executa o
comando db2imigr, a mensagem de erro que é gerada inclui instruções
sobre como migrar para uma instância padrão do DB2 Versão 9 sem a
funcionalidade do DB2 Data Warehouse Manager.
v A instância que você está tentando migrar está ativa. Execute o comando
db2stop para parar a instância.
O comando MIGRATE DATABASE falhará na execução quando:
v Você encontrar qualquer um dos problemas descritos nos códigos de
razão da mensagem de erro SQL1704N.
v
Os UDTs (Tipos Distintos Definidos pelo Usuário) são encontrados com
os nomes XML, BINARY e VARBINARY. Esses UDTs devem ser
eliminados e recriados com um nome diferente antes da migração do
banco de dados.
v Os objetos de usuário utilizam o tipo de dados DATALINK definido
pelo sistema. Esses objetos devem ser eliminados ou alterados antes da
migração do banco de dados. Além disso, se você instalou o DB2 NSE
(Net Search Extender) no servidor DB2, será necessário eliminar as UDFs
criadas pelo NSE para suporte a Data Links.v Um banco de dados que está em um dos seguintes estados:
– O banco de dados catalogado não existe
– Backup pendente
– Roll-forward pendente
– Um ou mais espaços de tabelas em estado anormal
– Transação inconsistentev Um banco de dados que foi ativado como um banco de dados de espera
HADR (Recuperação de Desastre de Alta Disponibilidade).
v Tente migrar um banco de dados de um servidor DB2 no Windows para
um servidor DB2 no Linux ou UNIX ou o contrário. A migração entre
plataformas do Windows para Linux ou UNIX não é suportada.
Conceitos Relacionados:
v “Funcionalidade Obsoleta ou Descontinuada em Produtos do Banco de Dados
DB2 que Afeta a Migração” na página 30
v “Princípios de Migração para Servidores DB2” na página 19
v Capítulo 17, “Visão Geral da Migração para Aplicativos de Banco de Dados e
Rotinas”, na página 137
v “Recomendações de Migração para Servidores DB2” na página 24
v “Alterações de Suporte para Servidores DB2 de 32 Bits e 64 Bits” na página 28
v “Incompatibilidades da Versão 9 com Releases Anteriores e Comportamentos
Alterados” em Administration Guide: Planning
Tarefas Relacionadas:
v “Migrando Ambientes de Bancos de Dados Particionados” na página 74
Referência Relacionada:
v “Recursos Obsoletos e Descontinuados” em Administration Guide: Planning
v “Version 8 incompatibilities with previous releases” em Administration Guide:
Planning
Capítulo 4. Princípios Básicos da Migração para Servidores DB2 23
Recomendações de Migração para Servidores DB2
Considere as seguintes recomendações ao planejar a migração do servidor DB2:
Reveja as alterações na funcionalidade do produto do banco de dados existente
do DB2
As alterações na funcionalidade existente introduzidas no DB2 Versão 9
podem afetar potencialmente seus aplicativos, scripts, processo de
manutenção e quaisquer outros aspectos relacionados ao processo de
migração do produto do banco de dados do DB2. É necessário rever essas
alterações e planejar como abordar essas alterações antes da migração. A
migração em um ambiente de teste permite que você aprenda sobre
possíveis problemas, avalie o impacto em seu ambiente e localize uma
resolução.
Avaliação do desempenho do DB2
Execute um número de consultas de teste antes de migrar o servidor DB2.
A ferramenta de avaliação de desempenho db2batch pode ajudar a coletar
tempos decorridos e de CPU para suas consultas de teste. Registre as
condições de ambiente exatas onde as consultas forem executadas.
Além disso, mantenha um registro da saída do comando db2expln para
cada consulta de teste. Compare os resultados antes e depois da migração.
Essa prática pode ajudar a identificar e corrigir qualquer degradação no
desempenho que possa ocorrer.
Migrando um ambiente de replicação SQL
A migração de um ambiente de replicação SQL a partir do DB2 UDB
Versão 8 requer que você prepare a migração antes de migrar o servidor
DB2.
Além de executar tarefas de pré-migração para a migração de um ambiente
de replicação SQL, você deve arquivar todos os arquivos de registro do
DB2 utilizados pelo programa Capture antes da migração. Em seguida,
após a migração do servidor DB2, utilize as ferramentas de migração para
converter o ambiente de replicação SQL para o DB2 Versão 9.
Para obter informações completas sobre a migração do ambiente de
replicação SQL, consulte o guia Migrating to Replication Version 9
disponível na página da Web para manuais do DB2 Versão 9.
Migrando o DB2 Spatial Extender
Se você tiver o DB2 Spatial Extender instalado e tiver migrado seus bancos
de dados ativados por espaço para o DB2 Versão 9, será necessário ler a
publicação DB2 Spatial Extender and Geodetic Extender User’s Guide
novamente, além da tarefa migrando o ambiente Spatial Extender, para
obter detalhes de migração.
Migrando um Ambiente do Microsoft Cluster Server
Em um ambiente MSCS (Microsoft Cluster Server), a recomendação é
instalar o DB2 Versão 9 como uma nova cópia e depois executar o
comando db2imigr para migrar a instância do MSCS.
Execute os upgrades de hardware e sistema operacional antes da migração do
produto do banco de dados do DB2
O suporte a determinadas versões dos sistemas operacionais UNIX, Linux
e Windows foi eliminado no DB2 Versão 9. Se sua versão do sistema
24 Guia de Migração
operacional não é suportada, é necessário fazer upgrade de seu sistema
operacional antes da instalação do DB2 Versão 9. Observe que versões mais
novas dos sistemas operacionais também podem trazer novos requisitos de
hardware. Para obter as informações de sistema operacional mais
atualizadas, visite a página Requisitos do Sistema DB2.
Mesmo quando não é obrigatório, mas você decide fazer upgrade, a
execução de upgrades de hardware e sistema operacional separadamente
da migração do produto do banco de dados DB2 simplifica a determinação
de problemas se ocorrerem dificuldades de migração. Se você fizer
upgrade de seu software ou hardware antes da migração de um produto
do banco de dados DB2, certifique-se de que seu sistema esteja operacional
de forma aceitável antes de tentar migrar o processo.
Migração de Aplicativos de Banco de Dados e Rotinas
Se você migrar seu servidor DB2, também será necessário migrar os
aplicativos de banco de dados e as rotinas para suportar alterações para
instâncias de 64 bits do DB2 Versão 9, procedimentos armazenados SQL,
JVM (Java Virtual Machine) e software de desenvolvimento.
Princípios de Migração para Aplicativos de Banco de Dados e Princípios de
Migração para Rotinas incluem os fatores que podem causar impacto na
migração do seu aplicativo de banco de dados ou na migração da rotina.
Reveja esses fatores e faça todas as alterações necessárias nos aplicativos de
banco de dados e nas rotinas para garantir que eles sejam executados após
a migração para o DB2 Versão 9.
Em um ambiente de teste de migração, você pode testar e verificar se seus
aplicativos de banco de dados e suas rotinas são executados com êxito no
DB2 Versão 9 para descobrir se é necessário migrá-los. Também é possível
migrar os aplicativos de banco de dados e as rotinas antes de migrar o
ambiente de produção.
Faça um plano para reverter uma migração
Não há um utilitário para inverter a migração do DB2 Versão 9 para o DB2
UDB Versão 8. Para inverter uma migração de banco de dados, você deve
reinstalar o DB2 UDB Versão 8, recriar instâncias no DB2 UDB Versão 8 e
restaurar os backups de banco de dados. Revise a tarefa Revertendo a
Migração de Sistema de Bancos de Dados DB2 para aprender sobre todas
as etapas requeridas.
Execute as tarefas de pré-migração
Há várias tarefas de pré-migração que você deve executar para obter uma
migração bem-sucedida, como fazer backup de bancos de dados, salvar
configurações de parâmetros de configuração do DB2, aumentar os espaços
de tabelas e arquivos de registro e verificar se os bancos de dados estão
prontos para migração.
Migre primeiro os servidores DB2
Conforme você faz o upgrade do seu ambiente do DB2 UDB Versão 8 para
o DB2 Versão 9, se você migrar seus clientes DB2 para o DB2 Versão 9
antes de migrar todos os servidores DB2 para o DB2 Versão 9, existirão
algumas restrições e limitações, como o suporte de novos recursos de
produto do banco de dadosDB2, protocolos de rede e conectividade.
Capítulo 4. Princípios Básicos da Migração para Servidores DB2 25
Para evitar essas restrições e limitações conhecidas, migre todos os
servidores DB2 para o DB2 Versão 9 antes de migrar qualquer cliente DB2
para o DB2 Versão 9. Essas restrições e limitações não estão associadas com
o DB2 Connect.
Ative os recursos de computação autonômicos
O DB2 Versão 9 ativa diversos recursos de computação autônoma quando
você cria um banco de dados:
v Execução automática do orientador de configuração.
v Ativação do armazenamento automático.
v Ativação dos parâmetros configuração do banco de dados auto_runstats e
self_tuning_mem.
No entanto, quando você migra seu banco de dados para o DB2 Versão 9,
o auto_runstats retém seu valor anterior e o self_tuning_mem é configurado
como off.
Você deve considerar a ativação desses recursos para obter melhorias de
desempenho e gerenciabilidade. Além disso, a ativação do recurso de
auto-ajuste de memória permite gerenciar os novos requisitos de memória.
Conceitos Relacionados:
v “Teste de Benchmark” em Performance Guide
v “Ferramentas de Explicação” em Performance Guide
v “Incompatibilidades da Versão 9 com Releases Anteriores e Comportamentos
Alterados” em Administration Guide: Planning
v “O que Há de Novo na V9.1: Resumo de Alterações na Funcionalidade
Existente” em O que Há de Novo
v “O que Há de Novo na V9.1: Resumo de Funcionalidade Descontinuada” em O
que Há de Novo
v “Migrando Ambientes com Características Específicas” na página 67
v Capítulo 12, “Essenciais da Migração para Clientes DB2”, na página 115
v Capítulo 17, “Visão Geral da Migração para Aplicativos de Banco de Dados e
Rotinas”, na página 137
v “Alterações de Suporte para Servidores DB2 de 32 Bits e 64 Bits” na página 28
Tarefas Relacionadas:
v “Migrando um Servidor DB2 (Linux e UNIX)” na página 59
v “Migrando um Servidor DB2 (Windows)” na página 51
v “Migrando em um Ambiente de Teste” na página 46
Referência Relacionada:
v “Recursos Obsoletos e Descontinuados” em Administration Guide: Planning
v “Tarefas de Pré-migração para Servidores DB2” na página 35
Requisitos de Espaço em Disco para a Migração do Servidor DB2
Você precisa estar ciente de que o processo de migração requer espaço em disco
adicional. Certifique-se de ter espaço em disco suficiente para concluir esse
processo com êxito. As recomendações de espaço em disco a seguir são aplicáveis
para a migração para o DB2 Versão 9.
26 Guia de Migração
Arquivos do diretório do banco de dados
Os arquivos SQLSPCS.1 e SQLSPCS.2 contêm informações do espaço de
tabelas. Durante a migração para o DB2 Versão 9, esses arquivos crescem
até quatro vezes seu tamanho anterior, mas o tamanho total dos dados no
disco não excede o novo tamanho dos arquivos SQLSPCS.1 e SQLSPCS.2.
Por exemplo, se você tiver dois arquivos cujo tamanho totaliza 512 KB
antes da migração, serão necessários pelo menos 2 MB de espaço em disco
livre.
Áreas de tabela
Certifique-se de ter espaço livre suficiente no catálogo de sistema e nos
espaços de tabelas temporários do sistema para os bancos de dados que
estão sendo migrados. A área de tabela do catálogo do sistema é requerida
tanto para catálogos de banco de dados antigos com o para novos durante
a migração. A quantidade de espaço livre requerido varia, dependendo da
complexidade do banco de dados, assim como do número e tamanho de
objetos de banco de dados.
Espaço de tabelas do catálogo do sistema (SYSCATSPACE)
Recomenda-se aumentar o tamanho total para duas vezes o total
de espaço utilizado. Ou seja, a quantidade de espaço livre deve ser
pelo menos igual à quantidade total de espaço utilizado.
Espaço de tabelas temporário (TEMPSPACE1 é o nome padrão)
Recomenda-se aumentar o tamanho total para duas vezes o
tamanho total do espaço de tabelas do catálogo do sistema.
Para a área de tabela do catálogo do sistema, as páginas livres devem ser
iguais ou maiores que as páginas utilizadas. O total de páginas para o
espaço de tabelas temporário do sistema deve ser duas vezes a quantidade
total de páginas para o espaço de tabelas do catálogo do sistema.
Para aumentar a quantidade de espaço livre em seus espaços de tabelas,
você pode aumentar o tamanho de contêineres existentes. Para espaços de
tabelas DMS (Database Managed Space), também é possível incluir
contêineres adicionais, apesar de isso poder acionar o reequilíbrio dos
dados. Você pode reduzir o tamanho dos contêineres após a migração.
Espaço do arquivo de registro
O processo de migração do banco de dados faz alterações nos objetos do
catálogo do sistema em uma única transação. Essas alterações precisam de
espaço de registro adequado para conter esta transação. Se houver espaço
de registro insuficiente, essa transação sofrerá rollback e a migração não
será concluída com êxito.
Para assegurar que haja espaço de arquivo de registro suficiente
disponível, você pode configurar os parâmetros de configuração de banco
de dados logfilsiz, logprimary e logsecond para duas vezes seus valores
atuais. Se já houver um espaço de arquivos de registro grande disponível,
pode não ser necessário aumentar esses parâmetros. Além disso, em
ambientes de banco de dados particionados, você precisa somente
aumentar o espaço de registro no servidor de partição de banco de dados
do catálogo.
Você deve atualizar esses valores dos parâmetros de configuração do banco
de dados antes de migrar a instância para o DB2 Versão 9, pois não será
possível atualizar esses parâmetros de configuração de banco de dados até
que o comando MIGRATE DATABASE seja emitido. Se esse comando
falhar por causa de espaço insuficiente no arquivo de registro, você poderá
Capítulo 4. Princípios Básicos da Migração para Servidores DB2 27
configurar esses parâmetros de configuração de banco de dados com
valores superiores e, então, reemitir o comando MIGRATE DATABASE.
As novas configurações dos parâmetros de configuração do banco de
dados para o espaço de registro podem ser restauradas para seu valor
original antes da migração ser concluída.
Tarefas Relacionadas:
v “Modificando Contêineres em uma Área de Tabela do DMS” em Administration
Guide: Implementation
v “Aumentando os Tamanhos de Espaço de Tabela e Arquivo de Registro Antes da
Migração” na página 42
v “Migrando um Servidor DB2 (Linux e UNIX)” na página 59
v “Migrando um Servidor DB2 (Windows)” na página 51
Referência Relacionada:
v “Instrução ALTER TABLESPACE” em SQL Reference, Volume 2
v “Comando GET DATABASE CONFIGURATION” em Command Reference
v “Comando UPDATE DATABASE CONFIGURATION” em Command Reference
Alterações de Suporte para Servidores DB2 de 32 Bits e 64 Bits
O DB2 Versão 9 fornece suporte para sistemas operacionais de 32 bits nos sistemas
operacionais Linux no x86 e Windows e para sistemas operacionais de 64 bits nos
sistemas operacionais UNIX, Linux e Windows. Verifique os requisitos de
instalação para obter detalhes sobre as arquiteturas suportadas em cada sistema
operacional.
O tamanho de bit para a instância não pode mais ser especificado quando você
cria ou migra uma instância. O tamanho de bit para novas instâncias é
determinado pelo sistema operacional onde o DB2 Versão 9 está instalado. A tabela
a seguir resume o suporte ao tamanho de bit do DB2 Versão 9 que está disponível
para cada um dos seguintes sistemas operacionais:
Tabela 6. Suporte do DB2 Versão 9 Disponível por Sistema Operacional.
Sistemas operacionais Suporte disponível do DB2 Versão 9
v Windows de 32 bits no x86 e
X64 (Utilizando o produto x86
DB2 Versão 9 de 32 bits)
v Linux de 32 bits em x86
v Somente instâncias de 32 bits
v Servidor DB2 de 32 bits, cliente DB2 e pacotes de
ferramentas de GUI
v IBM SDK (Software Development Kit) de 32 bits para
Java
v Linux de 64 bits em IPF
(Itanium Platform Family)
v Instâncias de 64 bits
v Servidor DB2 e cliente DB2 de 64 bits
v Aplicativos de 64 bits (Java e não-Java) e rotinas de
servidor de 64 bits
v IBM SDK de 64 bits para Java
28 Guia de Migração
Tabela 6. Suporte do DB2 Versão 9 Disponível por Sistema Operacional. (continuação)
Sistemas operacionais Suporte disponível do DB2 Versão 9
v Kernels de 64 bits de AIX,
HP-UX ou Solaris
v Windows de 64 bits no X64 e
IPF
v Kernel Linux de 64 bits no
x86-64, POWER e zSeries
v Instâncias de 64 bits
v Bibliotecas DB2 de 32 bits e de 64 bits disponíveis
v Servidor DB2 e cliente DB2 de 64 bits
v Aplicativos e rotinas de servidor de 64 bits
v Suporte a aplicativo do lado cliente do DB2 de 32 bits
v Somente procedimentos/UDFs armazenados
protegidos de 32 bits (não- Java)
v Procedimentos/UDFs Armazenados protegidos Java
v IBM SDK de 64 bits para Java
Ao migrar de uma instância de 32 bits para o DB2 Versão 9 em um sistema de 32
bits, não há nenhuma questão a considerar. Você pode migrar para uma instância
de 32 bits somente em Windows de 32 bits ou Linux de 32 bits no x86.
Ao migrar de uma instância de 64 bits para o DB2 Versão 9 em um sistema de 64
bits, pode haver incompatibilidades devido à especificação do caminho da
biblioteca compartilhada. Por exemplo, se o caminho especificado para ligar as
bibliotecas do DB2 a seu aplicativo for o diretório do produto DB2, o aplicativo
falha na execução, pois o DB2 Versão 9 tem um caminho diferente. No entanto, se
você tiver ligado as bibliotecas utilizando o caminho da biblioteca sob o diretório
home da instância ($INSTHOME/sqlib/lib), seu aplicativo será executado com êxito.
Você pode migrar somente para uma instância de 64 bits em um sistema de 64 bits.
Somente ao migrar de uma instância de 32 bits para o DB2 Versão 9 em um
sistema de 64 bits você terá que lidar com incompatibilidades devido à
especificação do caminho da biblioteca compartilhada e aos recursos
não-suportados (veja os detalhes sobre suporte disponível em Tabela 6 na página
28). Por exemplo, procedimentos armazenados não protegidos de 32 bits em
qualquer linguagem suportada, exceto Java, não são suportados. É possível
resolver esse problema rapidamente eliminando e recriando esses procedimentos
armazenados como protegidos.
Alguns desses problemas de migração devem-se ao suporte da migração de 32 bits
para 64 bits e não são inerentes do DB2 Versão 9.
Conceitos Relacionados:
v Capítulo 18, “Princípios de Migração para Aplicativos de Banco de Dados”, na
página 139
v “Princípios de Migração para Servidores DB2” na página 19
v “Incompatibilidades da Versão 9 com Releases Anteriores e Comportamentos
Alterados” em Administration Guide: Planning
v “Suporte a 32 Bits e 64 Bits para Aplicativos SQL Incorporados” em
Desenvolvendo Aplicativos SQL Incorporados
Tarefas Relacionadas:
v “Migrando Aplicativos de Banco de Dados de 32 Bits para Execução em
Instâncias de 64 Bits” na página 164
v “Migrando Rotinas Externas de 32 Bits para Execução em Instâncias de 64 Bits”
na página 177
Capítulo 4. Princípios Básicos da Migração para Servidores DB2 29
v “Migrando Servidores DB2 de 32 Bits para Sistemas de 64 Bits (Linux e UNIX)”
na página 69
v “Migrando Servidores DB2 de 32 Bits para Sistemas de 64 Bits (Windows)” na
página 68
Referência Relacionada:
v “Recursos Obsoletos e Descontinuados” em Administration Guide: Planning
Funcionalidade Obsoleta ou Descontinuada em Produtos do Banco de
Dados DB2 que Afeta a Migração
A utilização da funcionalidade que estava disponível no DB2 UDB Versão 8, mas
que não é mais suportada ou está obsoleta no DB2 Versão 9, pode causar um
impacto na sua migração. Além disso, você também deve estar ciente dos produtos
DB2 que não são mais suportados no DB2 Versão 9 porque a migração a partir
desses produtos não é suportada.
Você precisa estar ciente dessas alterações de funcionalidade e fazer planos para
tarefas adicionais antes e após a migração para lidar com essas alterações. Algumas
dessas tarefas são mencionadas abaixo.
Ferramentas de Administração do DB2
Na Versão 9, as ferramentas de administração do DB2, tais como Centro de
Controle, Editor de Comandos e Centro de Funcionamento, são suportadas
somente no Windows no x86, Windows no X64 (AMD64/Intel EM64T),
Linux no x86 (IA32) e Linux no AMD64 /Intel EM64T. Você precisa chamar
essas ferramentas somente a partir de um DB2 Client em qualquer uma
das plataformas suportadas.
Driver JDBC Tipo 3 do DB2
O driver JDBC tipo 3 do DB2 ficou obsoleto no DB2 UDB Versão 8 e não é
mais suportado no DB2 Versão 9. O arquivo archive do driver não é
instalado no DB2 Versão 9. Você deve modificar seus aplicativos e applets
Java para utilizar o IBM DB2 Driver para JDBC e conexões SQLJ com tipo
4. Você não precisa instalar um cliente DB2, mas precisa apenas copiar o
arquivo db2jcc.jar.
Armazenamento Estendido
O armazenamento estendido não é mais suportado no DB2 Versão 9. Não
há nenhum impacto no Linux, pois o armazenamento estendido não era
suportado. Também não há nenhum impacto nos sistemas operacionais de
64 bits, pois o armazenamento estendido não é necessário. Caso queira
alocar mais memória do que o limite de memória endereçável virtual em
sistemas operacionais Windows de 32 bits, considere a utilização dos
conjuntos de buffer AWE (Address Windowing Extensions) utilizando a
variável de registro DB2_AWE como uma solução alternativa.
A estrutura da visualização SYSCAT.BUFFERPOOLS é a mesma e o valor
da coluna ESTORE é configurado como 'N' durante a migração porque o
armazenamento estendido para conjuntos de buffers não é mais suportado.
Protocolo NetBIOS e SNA
O suporte ao protocolo NetBIOS não está mais disponível no DB2 Versão 9.
É necessário remover a palavra-chave NetBIOS na variável de registro
DB2COMM, caso contrário, o gerenciador de banco de dados retorna um
30 Guia de Migração
erro ao iniciar sua instância. Não é possível catalogar os nós utilizando
esse protocolo; o comando CATALOG NETBIOS NODE retorna um erro,
pois você está especificando um protocolo inválido. Você precisa remover
do catálogo os nós catalogados especificando-se o protocolo NetBIOS e os
bancos da dados que foram catalogados com esses nós. Se você tentar se
conectar a qualquer banco de dados catalogado em um nó utilizando o
protocolo NetBIOS, seu pedido de conexão também retornará um erro
porque você está utilizando um protocolo inválido.
Apesar de o suporte para o protocolo SNA ter sido descontinuado no DB2
UDB Versão 8, essa alteração de suporte não foi aplicada. No DB2 Versão
9, é necessário remover a palavra-chave SNA da variável de registro
DB2COMM e remover do catálogo os nós e bancos de dados que utilizam
o protocolo SNA. Os comandos CATALOG APPC NODE ou CATALOG
APPN NODE retornam um erro porque você está especificando um
protocolo inválido.
Registros Brutos
A utilização de dispositivos brutos para registro de banco de dados está
obsoleta e será removida em um release futuro. É necessário alterar a
definição do parâmetro de configuração do banco de dados newlogpath
para um dispositivo de disco em vez de um dispositivo bruto. O exemplo
a seguir ilustra como alterar a configuração do parâmetro newlogpath:
$ db2 UPDATE DATABASE CONFIGURATION USING newlogpath /disk2/newlogdir
A nova configuração não é efetivada até o banco de dados estar em um
estado consistente e todos os usuários estarem desconectados do banco de
dados. O gerenciador de banco de dados move os registros para o novo
local, após o primeiro usuário conectar ao banco de dados. Você pode
parar e reiniciar o gerenciador de banco de dados para efetivar essa nova
configuração.
Funções Snapshot da Tabela SQL do Monitor
Todas as funções da tabela SQL com nomes iniciador por SNAPSHOT_
estão obsoletas no DB2 versão 9. Essas funções são suportadas somente
para compatibilidade e serão removidas em um release futuro.
Novas funções equivalentes com nomes semelhantes iniciados por
SNAP_GET_ estão disponíveis. Essas novas funções podem ter parâmetros
diferentes e colunas adicionais, portanto, é necessário revisá-las antes de
utilizar os nomes das novas funções em seu aplicativos.
Produtos DB2
A instalação do DB2 UDB Versão 8 tem a opção de instalar produtos e
funcionalidade adicionais. O suporte para alguns desses produtos foi
eliminado no DB2 Versão 9. O DB2 UDB Versão 8 também é um
pré-requisito para instalações de outros produtos DB2. Uma instalação do
DB2 Versão 9 não suporta nenhum dos produtos a seguir como opções de
instalação nem como um componente pré-requisito:
v DB2 Data Warehouse Center
v DB2 Data Warehouse Manager
v DB2 Information Catalog Center
v DB2 Data Links Manager
v DB2 DataJoiner
Capítulo 4. Princípios Básicos da Migração para Servidores DB2 31
Esses produtos DB2 não funcionam no DB2 Versão 9. Se você instalou
qualquer um desses produtos no servidor DB2, você poderia desinstalá-los
e, em seguida, migrar o servidor DB2 para o DB2 Versão 9 sem a
funcionalidade do produto DB2. O comando db2imigr falha se algum
desses produtos estiver instalado, mas fornece instruções sobre como
migrar para uma instância do DB2 Versão 9 sem a funcionalidade do
produto DB2. A migração para uma instância do DB2 Versão 9 permite
preservar seus bancos de dados existentes.
Além disso, se qualquer um desses produtos tiver criado objetos de banco
de dados, como tipos definidos pelo usuário, funções definidas pelo
usuário e procedimentos armazenados, esses objetos de banco de dados
permanecem inalterados no banco de dados após a desinstalação de
qualquer um desses produtos. Antes de migrar o banco de dados, você
pode precisar eliminar esses objetos do banco de dados, pois eles podem
fazer com que a migração do banco de dados falhe.
Conceitos Relacionados:
v “Restrições de Migração para Servidores DB2” na página 21
v “Princípios de Migração para Servidores DB2” na página 19
v “O que Há de Novo na V9.1: Resumo de Funcionalidade Obsoleta” em O que Há
de Novo
v “O que Há de Novo na V9.1: Resumo de Funcionalidade Descontinuada” em O
que Há de Novo
v “Incompatibilidades da Versão 9 com Releases Anteriores e Comportamentos
Alterados” em Administration Guide: Planning
v “Drivers Suportados para JDBC e SQLJ” em Desenvolvendo Aplicativos Java
v “Diretório do nó” em Administration Guide: Implementation
Tarefas Relacionadas:
v “Migrando Ambientes do DB2 Data Links Manager” na página 81
Referência Relacionada:
v “Comando UNCATALOG DATABASE” em Command Reference
v “Comando UNCATALOG NODE” em Command Reference
v “Visualizações Administrativas SQL do Monitor de Captura Instantânea” em
System Monitor Guide and Reference
Suporte ao Cliente do DB2 para Migração
A migração para o cliente DB2 Versão 9 é suportada somente de clientes DB2 UDB
Versão 8, excluindo o Run-Time Client Lite e o Runtime Client.
Como os clientes do DB2 UDB Versão 8 podem se conectar aos servidores DB2
Versão 9, a recomendação é migrar primeiro o servidor DB2 e depois migrar os
clientes do DB2. Essa seqüência de migração assegura que seus aplicativos ainda
funcionem e que você evite qualquer limitação conhecida ao conectar de clientes
DB2 Versão 9 para servidores DB2 UDB Versão 8.
Clientes DB2 executando qualquer um dos seguintes produtos podem conectar a
um servidor executando o DB2 Versão 9 para Linux, UNIX e Windows:
v DB2 UDB para Linux, UNIX e Windows, Versão 8
32 Guia de Migração
v DB2 Versão 9 para Linux, UNIX e Windows
v DB2 para z/OS Versão 7 e Versão 8
v DB2 para iSeries Versão 5
v DB2 para VM e VSE Versão 7
O cliente do DB2 executando o DB2 Versão 9 para Linux, UNIX e Windows pode
se conectar a qualquer um dos seguintes servidores DB2 executando:
v DB2 UDB para Linux, UNIX e Windows, Versão 8
v DB2 Versão 9 para Linux, UNIX e Windows
v DB2 Connect Versão 8 e Versão 9
Além disso, o DB2 Connect Personal Edition pode conectar aos seguintes
servidores de banco de dados:
v DB2 para z/OS Versão 7 e Versão 8
v DB2 para iSeries Versão 5
v DB2 para VM e VSE Versão 7
Nova funcionalidade está disponível somente para clientes do DB2 executando o
DB2 Versão 9 para Linux, UNIX e Windows que estão se conectando a servidores
DB2 executando o DB2 Versão 9 para Linux, UNIX e Windows ou DB2 Connect
Versão 9.
Conceitos Relacionados:
v Capítulo 12, “Essenciais da Migração para Clientes DB2”, na página 115
v “Princípios de Migração para Servidores DB2” na página 19
v Capítulo 11, “Visão Geral da Migração para Clientes DB2”, na página 113
Referência Relacionada:
v “Combinações Suportadas de Versões de Clientes e Servidores” em Iniciação
Rápida para DB2 Clients
Capítulo 4. Princípios Básicos da Migração para Servidores DB2 33
34 Guia de Migração
Capítulo 5. Tarefas de Pré-migração
Este capítulo descreve as tarefas de pré-migração para servidores DB2. Ele contém
as seguintes seções:
v “Tarefas de Pré-migração para Servidores DB2”
v “Verificando se Seus Bancos de Dados Estão Prontos para Migração” na página
37
v “Fazendo Backup dos Bancos de Dados antes da Migração” na página 38
v “Salvando Informações de Configuração” na página 39
v “Aumentando os Tamanhos de Espaço de Tabela e Arquivo de Registro Antes da
Migração” na página 42
v “Alterando Dispositivos Brutos para Bloquear Dispositivos (Linux)” na página
44
v “Migrando em um Ambiente de Teste” na página 46
v “Capturando Informações de Erros e de Diagnóstico Durante a Migração” na
página 47
v “Colocando um Servidor DB2 Off-line antes da Migração” na página 49
Tarefas de Pré-migração para Servidores DB2
Antes de migrar seu servidor DB2, reveja os princípios de migração para
servidores DB2, incluindo recomendações, restrições e requisitos de espaço no
disco para identificar as alterações ou restrições que podem afetar sua migração.
Você deve estar pronto para abordar quaisquer problemas antes da migração para
ter uma migração bem-sucedida.
Prepare-se para a migração dos servidores DB2 executando as seguintes tarefas:
1. Se você instalou o DB2 NSE (Net Search Extender) no servidor DB2, elimine
as UDFs específicas utilizando os seguintes comandos:
db2 DROP SPECIFIC FUNCTION DB2EXT.DATALINKCONTENT1;
db2 DROP SPECIFIC FUNCTION DB2EXT.DATALINKCONTENT2;
db2 DROP SPECIFIC FUNCTION DB2EXT.DATALINKCONTENT4;
db2 DROP SPECIFIC FUNCTION DB2EXT.DATALINKCONTENT3;
Essas UDFs são sempre criadas pelo NSE para suporte a Data Links,
independentemente da instalação do Data Links Manager. Portanto, é
necessário remover essas funções mesmo quando o Data Links Manager não
está instalado.
Caso planeje migrar através da restauração de um backup de banco de dados,
você deve eliminar essas UDFs antes de fazer backup do banco de dados. Não
é possível restaurar a partir de um backup de banco de dados se essas UDFs
forem definidas.
2. Verifique se os bancos de dados estão prontos para a migração do DB2 para
identificar quaisquer problemas antes da migração real. Você deve resolvê-los
antes de continuar com a migração.
3. Faça backup dos seus bancos de dados para poder migrá-los para um novo
sistema migrado ou restaure-os no sistema original de pré-migração.
4. Salve as informações de configuração para ter um registro da configuração
atual que pode ser comparada com a configuração posterior à migração. Você
© Direitos Autorais IBM Corp. 2006 35
também pode utilizar essas informações para criar novas instâncias ou bancos
de dados utilizando a mesma configuração que havia antes da migração.
5. Arquive todos os arquivos de registro do DB2, tanto para replicação SQL se os
arquivos de registro forem necessários para o programa Capture quanto para
replicação HADR se os arquivos de registro forem necessários para criar um
banco de dados de espera.
6. Reveja os requisitos de espaço no disco para garantir que existe espaço livre
no disco, espaço de tabelas temporário e espaço de registro suficientes para a
migração e aumente os tamanhos de espaço de tabelas e arquivo de registro se
for necessário. Dependendo do número de objetos de banco de dados, você
pode precisar de mais espaço de registro para executar a migração.
7. Somente Linux: Altere dispositivos brutos para dispositivos de bloqueio.
8. Opcional: Pare HADR nos bancos de dados primário e de espera. Você pode
migrar somente o banco de dados primário.
9. Apenas Windows: Se você obteve tabelas de conversão de página de códigos
customizadas do serviço de suporte do DB2, será necessário fazer backup de
todos os arquivos no diretório DB2OLD\conv, em que DB2OLD é o local da
cópia existente do DB2 UDB Versão 8. Não é necessário fazer backup das
tabelas de conversão de páginas de códigos padrão. A migração da cópia do
DB2 UDB Versão 8 remove essas tabelas porque as tabelas de página de
códigos padrão são contidas em uma biblioteca DB2Versão 9.
10. Opcional: Migre o servidor DB2 em um ambiente de teste para identificar
problemas de migração e verificar se os aplicativos, scripts, ferramentas e
rotinas funcionam conforme esperado antes de migrar seu ambiente de
produção.
11. Opcional: Aplique o FixPak mais recente do DB2 UDB Versão 8.2. Isso permite
que você tire proveito das correções para comandos de migração e elimine
possíveis problemas. Considere fazer outro backup dos bancos de dados após
aplicar o FixPak.
12. Capture informações de erro e de diagnóstico durante a migração.
Informações adicionais sobre diagnóstico são úteis para a determinação de
problemas quando as informações normais de registro de migração no
db2diag.log não são suficientes.
13. Deixe o servidor DB2 off-line para a migração.
Conceitos Relacionados:
v “Migrando Ambientes com Características Específicas” na página 67
Tarefas Relacionadas:
v “Migrando um Servidor DB2 (Linux e UNIX)” na página 59
v “Migrando um Servidor DB2 (Windows)” na página 51
Referência Relacionada:
v “Comando ARCHIVE LOG” em Command Reference
v “Comando BACKUP DATABASE” em Command Reference
v “db2ckmig - Comando da Ferramenta de Pré-migração do Banco de Dados” em
Command Reference
v “db2stop - Comando para Parar o DB2” em Command Reference
v “Comando GET DATABASE CONFIGURATION” em Command Reference
v “Comando GET DATABASE MANAGER CONFIGURATION” em Command
Reference
36 Guia de Migração
Verificando se Seus Bancos de Dados Estão Prontos para Migração
Antes de migrar seus bancos de dados, é importante utilizar o comando db2ckmig
para verificar que seus bancos de dados estão prontos para migração.
Esse comando verifica se todas as condições a seguir são verdadeiras:
v Um banco de dados catalogado existe de fato.
v Um banco de dados não está em um estado inconsistente.
v Um banco de dados não está em um estado de backup pendente
v Um banco de dados não está em um estado de rollforward pendente
v Os espaços de tabelas estão em um estado normal.
v Um banco de dados não contém UDTs (Tipos Definidos pelo Usuário) com o
nome XML, DATALINK, BINARY ou VARBINARY.
v Um banco de dados não tem linhas órfãs nas tabelas do catálogo do sistema.
v Um banco de dados ativado como um banco de dados primário HADR permite
conexões bem-sucedidas.
v Uma função de banco de dados não está em espera para um banco de dados
primário HADR.
v Se SYSCATSPACE for um espaço de tabela DMS e AUTORESIZE não estiver
ativado, SYSCATSPACE terá pelo menos 50% de páginas livres do total de
páginas.
Um banco de dados deve transmitir todas essas verificações para ter sucesso no
processo de migração.
O db2imigr chama o comando db2ckmig. O db2imigr falha se o comando
db2ckmig achar que alguma das condições listadas acima não é verdadeira e
retorna o código de erro DBI1205E.
Pré-requisito:
Certifique-se de que tenha autoridade SYSADM.
Restrição:
Em um ambiente de banco de dados particionado, para verificar se seus bancos de
dados estão prontos para migração, você deve executar o comando db2ckmig em
cada partição de banco de dados.
Procedimento:
1. Efetue logon como o proprietário da instância do DB2 que você deseja migrar.
2. Pare a instância executando o comando db2stop.
3. A partir de um prompt de linha de comandos do DB2, vá para o diretório
apropriado:
v No UNIX ou Linux, o caminho para esse comando é $DB2DIR/bin/db2ckmig
(DB2DIR é configurado para o local especificado durante a instalação do DB2
Versão 9).
v No Windows, você precisa inserir o CD do produto DB2 Versão 9 na unidade
e alterar para o diretório \db2\Windows\utilities.4. Execute o comando db2ckmig para verificar se os bancos de dados
pertencentes à instância atual estão prontos para serem migrados ou para gerar
um arquivo de registro.
Capítulo 5. Tarefas de Pré-migração 37
db2ckmig sample -l db2ckmig.log -u adminuser -p password
db2ckmig foi bem-sucedido. O(s) banco(s) de dados pode(m) ser migrado(s).
em que sample é o nome do banco de dados e db2ckmig.log é o arquivo de
registro que inclui detalhes sobre erros e avisos.
Cada vez que você emite esse comando, ele sobrescreve o arquivo de registro
existente. Você pode renomear o arquivo de registro para evitar a perda dos
detalhes dos erros. Você deve corrigir esses erros antes da migração.
Quando o comando db2imigr executa o comando db2ckmig, o arquivo de
registro especificado é o migration.log no diretório home da instância para
Linux e UNIX ou no diretório atual para o Windows.
5. Certifique-se de que o arquivo de registro para o comando db2ckmig contenha
o texto a seguir: Versão do DB2CKMIG em execução: VERSION 9. Esse texto
confirma que você está executando o nível correto do comando db2ckmig.
6. Inicie a instância executando o comando db2start.
Conceitos Relacionados:
v “Migrando Ambientes com Características Específicas” na página 67
Tarefas Relacionadas:
v “Migrando um Servidor DB2 (Linux e UNIX)” na página 59
Referência Relacionada:
v “Tarefas de Pré-migração para Servidores DB2” na página 35
v “db2ckmig - Comando da Ferramenta de Pré-migração do Banco de Dados” em
Command Reference
Fazendo Backup dos Bancos de Dados antes da Migração
Antes de iniciar o processo de migração para o DB2 Versão 9, é altamente
recomendável executar um backup completo off-line de seus bancos de dados. Se
ocorrer um banco de dados durante o processo de migração, você precisa de
backups completos de banco de dados para recuperar e migrar seus bancos de
dados.
Pré-requisitos:
v Para fazer o backup de um banco de dados, você vai precisar de autoridade
SYSADM, SYSCTRL ou SYSMAINT.
v Os bancos de dados devem ser catalogados. Para exibir uma lista de todos os
bancos de dados catalogados na instância, execute o seguinte comando:
db2 LIST DATABASE DIRECTORY
Procedimento:
Para executar um backup completo off-line para cada um de seus bancos de dados
locais:
1. Desconecte todos os aplicativos e usuários do banco de dados. Para obter uma
lista de todas as conexões com o banco de dados para a instância atual, emita o
comando LIST APPLICATIONS. Se todos os aplicativos estiverem
desconectados, este comando retornará a seguinte mensagem:
38 Guia de Migração
db2 list applications
SQL1611W Nenhum
dado foi retornado pelo Monitor de Sistema do Banco de Dados.
SQLSTATE=00000
Para desconectar todos os aplicativos e usuários, utilize o comando FORCE
APPLICATION:
db2 force application all
2. Faça backup do banco de dados utilizando o comando BACKUP DATABASE.
Segue um exemplo para sistemas operacionais UNIX:
db2 BACKUP DATABASE sample USER arada USING password TO backup-dir
em que sample é o alias do banco de dados, o nome do usuário é arada, a
senha é password e o diretório para criar arquivos de backup é backup-dir.
3. Opcional: Teste a integridade de uma imagem de backup para assegurar que a
imagem possa ser restaurada utilizando o comando de Verificação de Backup
db2ckbkp. Segue um exemplo em sistemas operacionais UNIX:
cd backup-dir
db2ckbkp SAMPLE.0.arada.NODE0000.CATN0000.20051014114322.001
[1] Buffers processados: #######
Verificação Completa da Imagem - bem-sucedida.
Conceitos Relacionados:
v “Migrando Ambientes com Características Específicas” na página 67
v “System administration authority (SYSADM)” em Administration Guide:
Implementation
Tarefas Relacionadas:
v “Migrando um Servidor DB2 (Linux e UNIX)” na página 59
v “Migrando um Servidor DB2 (Windows)” na página 51
Referência Relacionada:
v “Comando BACKUP DATABASE” em Command Reference
v “db2ckbkp - Comando para Verificar o Backup” em Command Reference
v “Comando FORCE APPLICATION” em Command Reference
v “Comando LIST APPLICATIONS” em Command Reference
v “Tarefas de Pré-migração para Servidores DB2” na página 35
Salvando Informações de Configuração
É altamente recomendável que você salve suas configurações para parâmetros do
banco de dados e de configuração do gerenciador de banco de dados antes da
migração do servidor DB2. Você pode utilizar as configurações dos parâmetros de
configuração para verificar se a migração foi concluída e para recriar instâncias e
bancos de dados. Além disso, é possível coletar informações dos servidores DB2
sobre os catálogos do sistema de banco de dados, as configurações de variáveis de
registro do DB2, os dados da tabela de explicação e informações de diagnóstico
que podem ajudar na determinação de problemas se você encontrar alguma
diferença de pós-migração no comportamento ou no desempenho do gerenciador
de banco de dados .
Capítulo 5. Tarefas de Pré-migração 39
Após você migrar para o DB2 Versão 9, você deve comparar as definições do
parâmetro de configuração salvas com as novas configurações pós-migração.
Novos parâmetros introduzidos no DB2 Versão 9 têm valores que podem afetar o
comportamento ou o desempenho de seu aplicativo. Você deve avaliar quais
valores são mais adequados para seu aplicativo.
Pré-requisitos:
Você deve ter a autoridade SYSADM para executar todas as tarefas a seguir, apesar
de algumas tarefas precisarem de menos privilégios de autoridade ou de nenhum.
Procedimento:
Para salvar as informações sobre o diagnóstico e a configuração do servidor DB2:
1. Execute o comando db2support para coletar informações dos servidores DB2.
Esse comando permite coletar informações sobre o catálogo do sistema de
banco de dados, configurações de parâmetros de banco de dados e de
configuração do gerenciador de banco de dados, configurações de variáveis de
registro do DB2, dados da tabela de explicação e informações de diagnóstico
requeridas pelo suporte do DB2 em caso de problemas.
db2support output-directory -d database-name -cl 0
A opção -cl 0 coleta o catálogo de sistema do banco de dados, as configurações
de parâmetros de banco de dados e de configuração do gerenciador de banco
de dados e configurações de variáveis de registro do DB2. As informações
coletadas são armazenadas em um arquivo zip compactado no diretório de
saída. Um relatório de resumo no formato HTML é incluído. É necessário
executar esse comando para todos os seus bancos de dados.
É importante manter esse arquivo zip por alguns meses após a conclusão da
migração. As informações no arquivo zip podem ajudar a resolver rapidamente
quaisquer problemas de desempenho com o novo release.
2. Salve as informações sobre todos os pacotes para seus aplicativos associados
com cada banco de dados. Utilize o seguinte comando para listar pacotes
associados com seus bancos de dados e redirecione a saída do comando para
um arquivo:
db2 LIST PACKAGES FOR SCHEMA schema-name
SHOW DETAIL > /migration/sample_pckg.txt
A cláusula FOR SCHEMA permite listar todos os pacotes para um determinado
esquema, mas se seu aplicativo tiver vários esquemas, será necessário repetir
esse comando para cada nome de esquema ou utilizar a cláusula FOR ALL.
3. Opcional: O relatório HTML do comando db2support inclui as configurações
dos parâmetros de configuração do gerenciador de banco de dados para a
instância que possui o banco de dados especificado. Você pode utilizar o
comando GET DATABASE MANAGER CONFIGURATION para salvar suas
configurações para os parâmetros de configuração do gerenciador de banco
de dados e redirecionar a saída do comando para um arquivo para salvar essas
configurações para cada instância:
db2 GET DBM CFG > dbm_instname.cfg
em que instname é o nome da instância.
4. Opcional: O relatório HTML do comando db2support inclui as configurações
do parâmetro de configuração do banco de dados para o banco de dados
especificado. Você pode utilizar o comando GET DATABASE MANAGER
CONFIGURATION para salvar suas configurações para os parâmetros de
40 Guia de Migração
configuração do banco de dados e redirecionar a saída do comando para um
arquivo para salvar essas configurações para cada banco de dados:
db2 GET DB CFG FOR database_alias
SHOW DETAIL > db_database_alias.cfg
em que database_alias é o alias do banco de dados e a cláusula SHOW DETAIL
exibe os valores calculados pelo gerenciador de banco de dados quando os
parâmetros de configuração são configurados como AUTOMATIC.
Os parâmetros de configuração do banco de dados devem ser os mesmos em
cada partição de banco de dados em um ambiente de banco de dados
particionado. Se não forem os mesmos, salve as definições dos parâmetros de
configuração do banco de dados para cada partição de banco de dados.
5. Opcional: O comando db2support gera um arquivo com a saída do comando
db2look para o banco de dados especificado. No entanto, se precisar de
informações adicionais que não estejam presentes no arquivo de DDL gerado,
você pode utilizar esse comando para salvar as informações de DDL para seus
bancos de dados e as instruções para recriar seus objetos de banco de dados:
db2look -d sample -l -o sample_tbs.db2
6. Opcional: O relatório HTML do comando db2support inclui as configurações
de ambiente e de variável de registro para a instância que possui o banco de
dados especificado. Você pode utilizar o comando db2set para salvar suas
configurações de variáveis de registro de perfil DB2 e redirecionar a saída do
comando para um arquivo para salvar essas configurações:
db2set -all > reg_instname.txt
Se você configurar as variáveis de ambiente do DB2, utilize o comando do
sistema apropriado para listar variáveis de ambiente e seus valores. Por
exemplo, no AIX, você pode emitir o seguinte comando:
set |grep DB2 > env_instname.txt
Quando possível, utilize a saída do comando set e execute o comando db2set
para configurar essas variáveis de ambiente como variáveis de registro no
registro de perfil do DB2.
Após a migração, você deve rever as configurações das variáveis do registro de
perfil DB2 utilizando as informações salvas antes da migração. No DB2 Versão
9, há novas variáveis de registro e algumas variáveis existentes têm novos
valores padrão que podem influenciar o comportamento e o desempenho do
gerenciador de banco de dados. Apesar dessas alterações poderem aprimorar
seu aplicativo, você deve estar ciente das novas variáveis de registro e avaliar
quais valores melhor se adequam a seu aplicativo.
Conceitos Relacionados:
v “Recomendações de Migração para Servidores DB2” na página 24
v “Parâmetros de Configuração” em Performance Guide
Tarefas Relacionadas:
v “Migrando um Servidor DB2 (Linux e UNIX)” na página 59
v “Migrando um Servidor DB2 (Windows)” na página 51
Referência Relacionada:
v “Comando LIST PACKAGES/TABLES” em Command Reference
v “Comando LIST TABLESPACES” em Command Reference
v “Tarefas de Pré-migração para Servidores DB2” na página 35
Capítulo 5. Tarefas de Pré-migração 41
v “Alterações nas Variáveis de Registro do DB2, nos Parâmetros de Configuração e
nas Características de Design Físico do Banco de Dados” na página 91
v “db2look - Comando da Ferramenta de Estatísticas do DB2 e Extração de DDL”
em Command Reference
v “db2set - Comando do Registro de Perfil do DB2” em Command Reference
v “db2support - Comando da Ferramenta de Análise de Problema e Coleta de
Ambiente” em Command Reference
v “Comando GET DATABASE CONFIGURATION” em Command Reference
v “Comando GET DATABASE MANAGER CONFIGURATION” em Command
Reference
v “Resumo dos Parâmetros de Configuração” em Performance Guide
Aumentando os Tamanhos de Espaço de Tabela e Arquivo de Registro
Antes da Migração
Antes de iniciar a migração de seu servidor DB2, você deve garantir que existe
uma quantidade suficiente de espaço livre em seu espaço de tabelas do catálogo do
sistema e seu espaço de tabelas temporário, além de espaço de registro suficiente
para migrar seus bancos de dados.
Pré-requisito:
Assegure que você tenha a autoridade SYSCTRL ou SYSADM para poder
aumentar o tamanho dos espaços de tabelas e do espaço de registro.
Restrição:
Considerações adicionais são requeridas nos ambientes de banco de dados
particionados para aumentar os tamanhos do espaço de tabelas, já que os espaços
de tabelas se estendem pelas partições de banco de dados. Além disso, é necessário
somente aumentar o espaço de registro no servidor de partição de banco de dados
do catálogo.
Procedimento:
Para aumentar o tamanho de seus espaços de tabelas e espaço de registro:
1. Conecte ao banco de dados que você deseja migrar:
db2 CONNECT TO sample
2. Determine o uso do disco do espaço de tabelas utilizando o comando a seguir:
db2 LIST TABLESPACES SHOW DETAIL
Colete o número total de páginas, páginas utilizadas, páginas livres e tamanho
de página. Consulte a seguinte tabela para obter um resumo das informações
obtidas do comando anterior:
Tabela 7. Informações do Espaço de Tabelas para Banco de Dados de Amostra
Espaço de
Tabelas Tipo
Total de
páginas
Páginas
utilizadas Páginas livres
Tamanho da
Página
SYSCATSPACE SMS 8172 8172 N/D 4086
TEMPSPACE1 SMS 10 10 N/D 4086
42 Guia de Migração
3. Aumente o tamanho dos espaços de tabelas do catálogo do sistema. Se você
tiver um espaço de tabelas SMS, assegure que você tenha pelo menos a mesma
quantidade de páginas utilizadas no espaço de disco livre; neste exemplo,
aproximadamente 32 MB. Se você tiver um espaço de tabela DMS e o número
de páginas utilizadas for maior que o número de páginas livres, utilize a
seguinte fórmula para calcular o número de páginas a ser aumentado por
contêiner:
number_of_pages = ( used_pages - free_pages ) /
number_of_containers_in_SYSCATSPACE
Utilize o seguinte comando para aumentar o tamanho de todos os contêineres
no espaço de tabelas do catálogo do sistema:
db2 ALTER TABLESPACE SYSCATSPACE EXTEND (ALL number_of_pages)"
4. Aumente o tamanho dos espaços de tabelas temporários. Se você tiver um
espaço de tabelas SMS, será necessário assegurar somente que você tenha pelo
menos duas vezes a quantidade total de páginas para o espaço de tabelas do
catálogo do sistema no espaço de disco livre; neste exemplo, aproximadamente
64 MB. Se você tiver um espaço de tabelas DMS, utilize a seguinte fórmula
para calcular o número de páginas a aumentar por contêiner.
number_of_pages = ( number_of_total_pages_in_SYSCATSPACE ) /
number_of_containers_in_TEMPSPACE1
Utilize o seguinte comando para aumentar o tamanho de todos os contêineres
no espaço de tabelas temporário:
db2 ALTER TABLESPACE SYSCATSPACE EXTEND (ALL number_of_pages)"
Se você tiver um espaço de tabelas DMS com AUTORESIZE ativado e
MAXSIZE configurado como NONE, assegure que você tenha no mínimo o
dobro da quantidade de páginas totais para o espaço de tabela do catálogo do
sistema em espaço livre em disco. Se MAXSIZE estiver configurado como um
valor inteiro, certifique-se de que esse valor seja pelo menos duas vezes a
quantidade do total de páginas. A consulta a seguir retorna o tamanho atual
(quantidade do total de páginas em bytes) e o MAXSIZE do espaço de tabelas
TEMPSPACE1 no banco de dados SAMPLE:
db2 SELECT TBSP_CURRENT_SIZE, TBSP_MAX_SIZE
FROM table(SNAP_GET_TBSP_PART('SAMPLE', -1)) T
WHERE TBSP_NAME = 'TEMPSPACE1'
Se TBSP_MAX_SIZE for menor que duas vezes o valor de
TBSP_CURRENT_SIZE, será necessário aumentar MAXSIZE utilizando a
instrução ALTER TABLESPACE:
db2 ALTER TABLESPACE TEMPSPACE1 MAXSIZE (<TBSP_CURRENT_SIZE*2/1024>) K
O redimensionamento automático dos espaços de tabelas está disponível desde
o DB2 UDB Versão 8 FixPak 9.
5. Determine o tamanho do espaço de registro atual utilizando o comando GET
DATABASE CONFIGURATION. Registre os valores para os parâmetros de
configuração do banco de dados logfilsiz, logprimary e logsecond:
db2 GET DB CFG FOR sample |grep ’(LOG[FPS]’
Tamanho do arquivo de registro (4 KB) (LOGFILSIZ) = 1000
Número de arquivos de registro primários (LOGPRIMARY) = 3
Número de arquivos de registro secundários (LOGSECOND) = 2
6. Aumente o tamanho do espaço de registro utilizando os seguintes comandos:
db2 UPDATE DB CFG FOR sample using LOGPRIMARY current value * 2
db2 UPDATE DB CFG FOR sample using LOGSECOND current value * 2
Capítulo 5. Tarefas de Pré-migração 43
Se você já tiver um espaço de registro grande, pode não ser necessário
aumentá-lo. Considere, talvez, somente aumentar o número de arquivos de
registro secundários como uma medida de segurança somente se você tiver
criado um número muito grande de objetos de banco de dados em seu banco
de dados.
7. Opcional: Ative o registro ativo infinito em vez de aumentar o espaço de
registro, configurando logsecond para -1 e ativando o registro do archive. O
registro ativo infinito permite que uma unidade ativa de trabalho estenda-se
pelos registros primários e os registros de archive, permitindo efetivamente que
uma transação utilize um número infinito de arquivos de registro. Você deve
estar ciente de que se a migração falhar, o tempo para efetuar rollback das
transações dependerá de quantos registros arquivados precisam ser
recuperados. O comando a seguir mostra um exemplo de como ativar o registro
de archive no disco e registro infinito:
db2 UPDATE DB CFG FOR sample using LOGARCHMETH1 DISK:archive-dir
db2 UPDATE DB CFG FOR sample using LOGSECOND -1
em que archive-dir é o diretório para arquivar os arquivos de registro.
Apesar de serem parâmetros dinâmicos, todos os aplicativos devem desconectar
desse banco de dados antes dos novos valores tornarem-se efetivos.
Conceitos Relacionados:
v “Requisitos de Espaço para Arquivos do Log” em Administration Guide: Planning
v “Espaços de Tabelas em Grupos de Partição do Banco de Dados” em
Administration Guide: Implementation
Tarefas Relacionadas:
v “Migrando um Servidor DB2 (Linux e UNIX)” na página 59
v “Migrando um Servidor DB2 (Windows)” na página 51
Referência Relacionada:
v “Parâmetros de Configuração para Registro do Banco de Dados” em Data
Recovery and High Availability Guide and Reference
v “Tarefas de Pré-migração para Servidores DB2” na página 35
v “Comando GET DATABASE CONFIGURATION” em Command Reference
v “Comando LIST TABLESPACES” em Command Reference
v “Comando UPDATE DATABASE CONFIGURATION” em Command Reference
v “Instrução ALTER TABLESPACE” em SQL Reference, Volume 2
Alterando Dispositivos Brutos para Bloquear Dispositivos (Linux)
Se ainda estiver utilizando dispositivos (caracteres) brutos como contêineres para
espaços de tabela ou arquivos de registro, você deverá alterar os dispositivos
(caracteres) brutos para dispositivos de bloqueio bruto antes de migrar para o DB2
Versão 9. O método de E/S bruto anterior que requeria ligação do dispositivo de
bloqueio com um dispositivo (caractere) bruto utilizando o utilitário bruto está
obsoleto no DB2 Versão 9 e será removido de um futuro release do produto do
banco de dados DB2. Esse método de E/S bruto também está obsoleto no sistema
operacional Linux e será removido em um release futuro do Linux.
44 Guia de Migração
O método de dispositivo de bloqueio utiliza E/S Direta para obter um
desempenho equivalente comparado aquele que utiliza o método de dispositivo
(caractere) bruto.
Pré-requisito:
Assegure que o banco de dados esteja off-line para relocalizar os contêineres ou
alterar o caminho do arquivo de registro.
Restrição:
Em um ambiente de banco de dados particionado, o comando db2relocatedb deve
ser executado contra cada partição de banco de dados que requer alterações. Um
arquivo de configuração diferente deve ser fornecido para cada partição de banco
de dados e deve incluir o valor NODENUM da partição de banco de dados que
está sendo alterada.
Procedimento:
1. Execute um backup off-line completo de seu banco de dados.
2. Encerre seu banco de dados. Considere também colocar o banco de dados no
modo quiesce utilizando o comando QUIESCE DATABASE conforme mostrado
no exemplo a seguir:
db2 CONNECT TO sample
db2 QUIESCE DATABASE DEFER FORCE CONNECTIONS
db2 DEACTIVATE DATABASE database-alias
3. utilize o comando do sistema -a bruto para ver quais ligações brutas foram
definidas. Essas informações ajudarão a determinar o dispositivo de bloqueio
que você deve utilizar para substituir um dispositivo bruto para cada contêiner
em seus espaços de tabelas.
4. Crie um arquivo de configuração para o comando db2relocatedb. Utilize as
cláusulas CONT_PATH e LOG_DIR para especificar o valor antigo com o novo
valor. Por exemplo, você pode criar o arquivo moveraw.cfg com o seguinte
conteúdo:
DB_NAME=SAMPLE
DB_PATH=/databases/SAMPLE
INSTANCE=db2inst1
NODENUM=0
LOG_DIR=/dev/raw/lograw,/dev/sda5
CONT_PATH=/dev/raw/raw1,/dev/sda1
CONT_PATH=/dev/raw/raw2,/dev/sda2
5. Execute o comando db2relocatedb para alterar a configuração dos arquivos de
banco de dados:
db2relocatedb -f moveraw.cfg
6. Ative seu banco de dados:
db2 ACTIVATE DATABASE database-alias
7. Teste se seu banco de dados está funcionando conforme esperado. Conecte ao
banco de dados e execute consultas nas tabelas criadas nos espaços de tabelas
relocalizados.
8. Se você colocar o banco de dados no modo quiesce, será possível restaurar o
acesso e ativar o banco de dados utilizando o comando UNQUIESCE
DATABASE:
db2 CONNECT TO sample
db2 UNQUIESCE DATABASE
Capítulo 5. Tarefas de Pré-migração 45
Se estiver restaurando a partir de um backup DB2 UDB Versão 8 no DB2 Versão 9,
você deve realizar uma restauração redirecionada para indicar os dispositivos de
bloqueio em vez de dispositivos de caracteres brutos para seus contêineres e
caminho de registro.
Conceitos Relacionados:
v “Redefininfo Contêineres de Espaços de Tabelas Durante uma Operação de
Restauração (restauração redirecionada)” em Data Recovery and High Availability
Guide and Reference
Tarefas Relacionadas:
v “Configurando um Dispositivo de Acesso Direto ao Disco no Linux” em
Administration Guide: Implementation
v “Conectando um Dispositivo de Acesso Direto ao Disco” em Administration
Guide: Implementation
v “Fazendo Backup dos Bancos de Dados antes da Migração” na página 38
v “Migrando um Servidor DB2 (Linux e UNIX)” na página 59
Referência Relacionada:
v “Tarefas de Pré-migração para Servidores DB2” na página 35
v “Comando ACTIVATE DATABASE” em Command Reference
v “db2relocatedb - Comando para Relocalizar o Banco de Dados” em Command
Reference
v “Comando QUIESCE” em Command Reference
Migrando em um Ambiente de Teste
Se você migrar para o DB2 Versão 9 em um ambiente de teste antes de migrar seu
ambiente de produção, você poderá abordar problemas durante o processo de
migração de forma mais efetiva. Você também pode avaliar o impacto das
alterações introduzidas no DB2 Versão 9. Esse método permite verificar se os
aplicativos, scripts, ferramentas e procedimentos de manutenção funcionam
corretamente antes da migração de seu ambiente de produção. Além disso, você
pode avaliar o tempo que leva o processo de migração e solidificar seu plano de
migração.
O DB2 Versão 9 e o DB2 UDB Versão 8 podem coexistir no mesmo sistema. É
possível instalar o DB2 Versão 9 como um ambiente de teste separado enquanto
seus aplicativos ainda estão ativos e em execução sob o DB2 UDB Versão 8 em um
ambiente de produção no mesmo sistema.
Nesse ambiente de teste paralelo, é possível criar suas instâncias e bancos de dados
de teste do DB2 Versão 9 para testar seus aplicativos. Você também pode migrar
seus bancos de dados atuais para esse ambiente de teste, restaurando-os de um
backup off-line completo do DB2 UDB Versão 8, e identificar quaisquer problemas
com o processo de migração do banco de dados.
Pré-requisitos:
Você deve ter autoridade root nos sistemas operacionais UNIX ou autoridade de
Administrador Local no Windows. Você também deve ter a autoridade SYSADM.
Procedimento:
46 Guia de Migração
Para copiar seu ambiente de produção em um ambiente de teste, você precisa
executar as seguintes tarefas:
1. Instale o DB2 UDB Versão 8.
2. Recrie suas instâncias.
3. Recrie seus bancos de dados.
4. Execute tarefas de pré-migração.
5. Instale o DB2 Versão 9.
6. Migre suas instâncias.
7. Migrar bancos de dados.
8. Verifique a migração.
9. Teste seus aplicativos, scripts, ferramentas e procedimentos de manutenção.
Conceitos Relacionados:
v “O que Há de Novo na V9.1: Resumo de Alterações na Funcionalidade
Existente” em O que Há de Novo
v “O que Há de Novo na V9.1: Resumo de Funcionalidade Descontinuada” em O
que Há de Novo
v “Migrando Ambientes com Características Específicas” na página 67
v “Princípios de Migração para Servidores DB2” na página 19
Tarefas Relacionadas:
v “Migrando Instâncias” na página 53
v “Migrando os Bancos de Dados” na página 56
v “Verificando a Migração dos Servidores DB2” na página 105
v “Uma Visão Geral sobre a Instalação do Seu Produto DB2 (Linux e UNIX)” em
Iniciação Rápida para DB2 Servers
v “Uma Visão Geral sobre a Instalação de seu Produto do DB2 (Windows)” em
Iniciação Rápida para DB2 Servers
v “Migrando um Servidor DB2 (Linux e UNIX)” na página 59
v “Migrando um Servidor DB2 (Windows)” na página 51
v “Criando um Banco de Dados” em Administration Guide: Implementation
v “Criando Instâncias Adicionais” em Administration Guide: Implementation
Referência Relacionada:
v “Tarefas de Pré-migração para Servidores DB2” na página 35
Capturando Informações de Erros e de Diagnóstico Durante a
Migração
No DB2 Versão 9, todos os eventos de migração significativos são registrados no
arquivo db2diag.log quando o nível de erro de diagnóstico é configurado para 3
(valor padrão). As mensagens de falha de migração também são registradas no
arquivo db2diag.log quando o nível de erro de diagnóstico é configurado para 1
ou mais alto. É necessário configurar o parâmetro de configuração do gerenciador
de banco de dados diaglevel para 3 ou mais alto para capturar as informações sobre
os eventos de migração.
Você pode alterar o nível de erro de diagnóstico para registrar informações
adicionais durante o processo de migração; essas informações adicionais podem ser
Capítulo 5. Tarefas de Pré-migração 47
úteis na determinação do problema. Antes da migração para o DB2 Versão 9, você
deve configurar o parâmetro de configuração do gerenciador de banco de dados
diaglevel para 4 para capturar informações adicionais no arquivo db2diag.log. Um
valor igual a 4 registra todos os erros, avisos e mensagens informativas.
Pré-requisito:
Certifique-se de que tenha autoridade SYSADM.
Procedimento:
Para alterar o nível de diagnóstico para registrar informações adicionais sobre o
processo de migração no arquivo db2diag.log:
1. Efetue logon como o proprietário da instância.
2. Anote a configuração atual para o parâmetro de configuração do gerenciador
de banco de dados diaglevel:
db2 GET DBM CONFIGURATION
...
Nível de captura de erro de diagnóstico (DIAGLEVEL) = 3 ...
Você precisa estar ciente desse valor para restaurar esse nível de diagnóstico
após a migração ser concluída. O valor padrão para o parâmetro diaglevel é 3.
3. Configure o parâmetro de configuração do gerenciador de banco de dados
diaglevel para 4:
db2 UPDATE DBM CONFIGURATION USING diaglevel 4
4.
Reinicie a instância de forma que a alteração tenha efeito:
db2stop
db2start
5. Migre o banco de dados.
6. Restaure o nível de erro de diagnóstico para sua configuração original. O
exemplo a seguir restaura o nível de erro de diagnóstico para o valor padrão:
db2 UPDATE DBM CONFIGURATION USING diaglevel 3
O parâmetro do gerenciador de banco de dados diagpath permite especificar o
caminho completo para as informações de diagnóstico do DB2. Esse diretório
contém o arquivo de registro de notificação de administração e o arquivo
db2diag.log, poderia possivelmente conter arquivos de dump, arquivos de
interrupção e arquivos de registro de alerta, dependendo de seu sistema
operacional. Recomenda-se que você mantenha o valor padrão. Se precisar alterar
o parâmetro diagpath, utilize o seguinte comando:
db2 UPDATE DBM CONFIGURATION USING diagpath directory
Em que directory representa o local para armazenar todos os arquivos de registro
de erro e de diagnóstico. Utilize um local centralizado, principalmente, se você
tiver várias instâncias do banco de dados.
Conceitos Relacionados:
v “Informações sobre Primeira Captura de Dados de Falha” em Troubleshooting
Guide
Tarefas Relacionadas:
v “Migrando um Servidor DB2 (Linux e UNIX)” na página 59
48 Guia de Migração
v “Migrando um Servidor DB2 (Windows)” na página 51
Referência Relacionada:
v “diaglevel - Parâmetro de Configuração do Nível de Captura de Erro de
Diagnóstico” em Performance Guide
v “diagpath - Parâmetro de Configuração de Caminho do Diretório de Dados de
Diagnóstico” em Performance Guide
v “Tarefas de Pré-migração para Servidores DB2” na página 35
v “Comando GET DATABASE MANAGER CONFIGURATION” em Command
Reference
v “Comando UPDATE DATABASE CONFIGURATION” em Command Reference
Colocando um Servidor DB2 Off-line antes da Migração
Essa tarefa descreve como colocar seu servidor DB2 UDB Versão 8 off-line para
migração do DB2 Versão 9. Antes de poder continuar com o processo de migração,
você deve parar o serviço de licença do DB2, para todas as sessões do processador
da linha de comandos, desconectar aplicativos e usuários e parar o gerenciador de
banco de dados.
Pré-requisitos:
v Seu sistema deve atender os requisitos de instalação para o DB2 Versão 9 antes
de iniciar o processo de migração.
v Você deve ter autoridade SYSADM.
Procedimento:
Para tornar seu servidor off-line:
1. Pare o serviço de licença do DB2:
db2licd -end
2. No Windows 2000, as propriedades de um serviço podem ser configuradas de
forma que reinicie se o serviço falhar. Se a opção reiniciar na falha estiver
configurada para quaisquer serviços do DB2, ela deve ser desativada antes de
prosseguir.
3. Pare todas as sessões do processador de linha de comandos digitando o
seguinte comando em cada sessão que estava executando o processador de
linha de comandos.
db2 terminate
4. Desconectar todos os aplicativos e usuários. Para obter uma lista de todas as
conexões com o banco de dados para a instância atual, emita o comando LIST
APPLICATIONS. Se todos os aplicativos estiverem desconectados, este
comando retornará a seguinte mensagem:
db2 list applications
SQL1611W Nenhum dado foi retornado pelo Monitor de
Sistema do Banco de Dados.
SQLSTATE=00000
Para desconectar todos os aplicativos e usuários, utilize o comando FORCE
APPLICATION:
db2 force application all
5. Quando todos os aplicativos e usuários forem desconectados, pare cada
instância do gerenciador de banco de dados:
Capítulo 5. Tarefas de Pré-migração 49
db2stop
Tarefas Relacionadas:
v “Migrando um Servidor DB2 (Linux e UNIX)” na página 59
v “Migrando um Servidor DB2 (Windows)” na página 51
Referência Relacionada:
v “Tarefas de Pré-migração para Servidores DB2” na página 35
v “db2licm - Comando da Ferramenta de Gerenciamento de Licenças” em
Command Reference
v “db2stop - Comando para Parar o DB2” em Command Reference
v “Comando FORCE APPLICATION” em Command Reference
v “Comando LIST APPLICATIONS” em Command Reference
50 Guia de Migração
Capítulo 6. Migrando Servidores DB2 (Windows)
Este capítulo descreve como migrar seus servidores DB2 no Windows. Ele contém
as seguintes seções:
v “Migrando um Servidor DB2 (Windows)”
v “Migrando Instâncias” na página 53
v “Migrando o DAS (DB2 Administration Server)” na página 54
v “Migrando os Bancos de Dados” na página 56
Migrando um Servidor DB2 (Windows)
A migração é requerida se você tiver instâncias e bancos de dados em execução no
DB2 UDB Versão 8 que você deseja executar no DB2 Versão 9. Se optar por migrar
automaticamente sua cópia existente do DB2 UDB Versão 8 durante a instalação do
DB2 Versão 9, suas instâncias e o DAS (DB2 Administration Server) serão
migrados, mas ainda será necessário migrar seus bancos de dados após a
instalação. Se optar por instalar uma nova cópia do DB2 Versão 9, você deve
migrar manualmente suas instâncias, seu DAS e bancos de dados.
Essa tarefa de migração descreve as etapas para migração direta do DB2 UDB
Versão 8 para o DB2 Versão 9. Reveja “Migrando Ambientes com Características
Específicas” na página 67 e determine qual tarefa se aplica melhor ao seu
ambiente.
Pré-requisitos:
v Certifique-se de ter autoridade do Administrador Local.
v Reveja recomendações de migração e requisitos de espaço em disco.
v Execute tarefas de pré-migração.
Restrições:
v Esse procedimento aplica-se somente à migração do servidor DB2 de instâncias
de 32 bits para instâncias de 32 bits do DB2 Versão 9 ou de instâncias de 64 bits
para instâncias de 64 bits do DB2 Versão 9. No DB2 Versão 9, a instância é de 32
bits somente no Windows de 32 bits em x86 ou X64 (se você instalar um produto
do banco de dados do DB2 Versão 9 de 32 bits). A instância tem somente 64 bits
no Windows de 64 bits em X64.
v A migração é suportada somente a partir do DB2 UDB Versão 8.
v A migração direta não é suportada a partir do DB2 UDB Versão 7 ou anterior.
Você deve migrar primeiro para o DB2 UDB Versão 8.
v Restrições de migração adicionais se aplicam. Reveja a lista completa.
Procedimento:
Para migrar para o DB2 Versão 9:
1. Efetuar logon como Administrador Local.
2. Instale DB2 Versão 9 executando o comando setup.exe para ativar o assistente
de Configuração do DB2. Você tem duas opções:
© Direitos Autorais IBM Corp. 2006 51
v Selecione a opção Migrar no painel Instalar um Produto para migrar uma
cópia existente do DB2 UDB Versão 8. Sua cópia do DB2 UDB Versão 8 é
removida e todas as suas instâncias e seu DAS são migrados
automaticamente.
Você receberá um aviso que recomenda executar o comando db2ckmig se
você tiver bancos de dados locais. Se você tiver concluído as tarefas de
pré-migração, ignore este aviso e continue a migração. Caso contrário,
verifique se seus bancos de dados estão prontos para a migração do DB2
antes de continuar com a instalação.
v Selecione a opção Instalar Novo no painel Instalar um Produto. Essa opção
cria uma nova cópia do DB2 Versão 9 e você deve migrar suas instâncias
após a instalação.3. Opcional: Migre o DAS se quiser manter sua configuração existente e para
administrar suas instâncias do DB2 Versão 9 utilizando o Centro de Controle.
4. Migrar bancos de dados.
Após migrar o servidor DB2, desempenhe as tarefas de pós-migração
recomendadas, como reconfigurar o nível de erro do diagnóstico, ajustar o
tamanho do espaço do registro e religar pacotes. Além disso, verifique se a
migração do servidor DB2 foi bem-sucedida.
Conceitos Relacionados:
v “Migrando Ambientes com Características Específicas” na página 67
v “Recomendações de Migração para Servidores DB2” na página 24
v “Restrições de Migração para Servidores DB2” na página 21
v “Princípios de Migração para Servidores DB2” na página 19
v “System administration authority (SYSADM)” em Administration Guide:
Implementation
Tarefas Relacionadas:
v “Instalando os Servidores do DB2 (Windows)” em Iniciação Rápida para DB2
Servers
v “Verificando se Seus Bancos de Dados Estão Prontos para Migração” na página
37
v “Migrando Instâncias” na página 53
v “Migrando o DAS (DB2 Administration Server)” na página 54
v “Migrando os Bancos de Dados” na página 56
v “Verificando a Migração dos Servidores DB2” na página 105
v “Migrando Servidores DB2 de 32 Bits para Sistemas de 64 Bits (Windows)” na
página 68
v “Uma Visão Geral sobre a Instalação de seu Produto do DB2 (Windows)” em
Iniciação Rápida para DB2 Servers
Referência Relacionada:
v “Requisitos de Espaço em Disco para a Migração do Servidor DB2” na página 26
v “Tarefas de Pré-migração para Servidores DB2” na página 35
v “Tarefas de Pós-migração para Servidores DB2” na página 87
v “db2ckmig - Comando da Ferramenta de Pré-migração do Banco de Dados” em
Command Reference
v “Roteiro de várias Cópias do DB2” em Administration Guide: Implementation
52 Guia de Migração
Migrando Instâncias
Como parte do processo geral de migração do servidor DB2 UDB Versão 8 para o
DB2 Versão 9, você deve migrar suas instâncias. No Linux e UNIX, você deve
migrá-los manualmente. No Windows, você deve migrá-los manualmente se não
optar por migrar automaticamente sua cópia existente do DB2 UDB Versão 8
durante a instalação do DB2 Versão 9.
Para migrar manualmente suas instâncias do DB2 UDB Versão 8, utilize o comando
db2imigr.
Pré-requisitos:
v É necessário ter autoridade root nos sistemas operacionais Linux e UNIX ou
autoridade de Administrador Local no Windows.
v Antes de executar o comando db2imigr, recomenda-se que:
– No UNIX, assegure que haja 20 MB de espaço livre no diretório /tmp. O
arquivo de rastreio da migração da instância está gravado em /tmp.
– Verifique se os bancos de dados estão prontos para migração do DB2.
Restrições:
v A migração direta não é suportada a partir do DB2 UDB Versão 7 ou anterior.
Você deve migrar primeiro para o DB2 UDB Versão 8.
v Restrições de migração adicionais se aplicam. Revise a lista completa para
migração da instância.
Procedimento:
Para migrar uma instância:
1. Pare as instâncias do DB2 UDB Versão 8 executando o comando db2stop:
db2stop
2. Efetue logon como autoridade root nos sistemas operacionais Linux e UNIX ou
como autoridade de Administrador Local no Windows.
3. Migre as instâncias executando o comando db2imigr.
Em sistemas operacionais Linux e UNIX:
$DB2DIR/instance/db2imigr -u fencedID InstName
em que
DB2DIR
está configurado para o local especificado durante a instalação
do DB2 Versão 9. O caminho da instalação padrão para o UNIX
é /opt/IBM/db2/V9.1 e para o Linux é /opt/ibm/db2/V9.1.
-u fencedID
É o usuário sob o qual as UDFs (Funções Definidas pelo
Usuário) protegidas e os procedimentos armazenados serão
executados.
InstName
É o nome do login do proprietário da instância.
Em sistemas operacionais Windows:
"%DB2PATH%"\bin\db2imigr InstName /u:user,password
Capítulo 6. Migrando Servidores DB2 (Windows) 53
em que
DB2PATH
está configurado para o local especificado durante a instalação
do DB2 Versão 9. O caminho da instalação padrão para o
Windows é Program Files\IBM\SQLLIB.
/u: user,password
são o nome do usuário e a senha sob os quais o serviço DB2
será executado.
InstName
É o nome do login do proprietário da instância.O comando db2imigr chama implicitamente o comando db2ckmig, indicando
migration.log como o arquivo de registro no diretório home da instância para
Linux e UNIX ou no diretório atual, onde você está executando o comando
db2imigr para Windows. O db2imigr não é executado se o comando db2ckmig
relatar erros. Verifique o arquivo de registro caso encontre algum erro.
4. Efetue logon como o proprietário da instância.
5. Reinicie sua instância executando o comando db2start:
db2start
6. Verifique se sua instância está em execução no DB2 Versão 9 executando o
comando db2level:
db2level
Os tokens informativos devem incluir uma cadeia como ″DB2 v9.X.X.X″, em
que X é um número.
Conceitos Relacionados:
v “Restrições de Migração para Servidores DB2” na página 21
v “Princípios de Migração para Servidores DB2” na página 19
Tarefas Relacionadas:
v “Verificando se Seus Bancos de Dados Estão Prontos para Migração” na página
37
Referência Relacionada:
v “db2ckmig - Comando da Ferramenta de Pré-migração do Banco de Dados” em
Command Reference
v “db2icrt - Comando para Criar Instância” em Command Reference
v “db2imigr - Comando para Migrar a Instância” em Command Reference
Migrando o DAS (DB2 Administration Server)
Como parte do processo geral de migração para o DB2 Versão 9, você pode migrar
o DAS (DB2 Administration Server) para manter a configuração existente do DAS.
Caso contrário, você pode eliminar o DAS existente e criar um novo DAS no DB2
Versão 9. Você precisa de apenas um DAS em execução no DB2 Versão 9 para
utilizar o Centro de Controle para administração remota de instâncias,
gerenciamento de tarefa e planejamento de tarefa do DB2 Versão 9.
No Windows, se você optar por migrar automaticamente a instalação do DB2 UDB
Versão 8, o DAS também será migrado junto com as instâncias.
54 Guia de Migração
Após a instalação do DB2 Versão 9, você pode migrar manualmente o DAS
executando o comando dasmigr.
Pré-requisito:
v Certifique-se de ter autoridade root nos sistemas operacionais Linux e UNIX ou
autoridade de Administrador Local no sistema operacional Windows.
Restrições:
v A migração é suportada somente a partir do DB2 UDB Versão 8.
v Você pode ter somente um DAS por servidor DB2.
Procedimento:
Para migrar o DAS:
1. Nos sistemas operacionais Linux e UNIX, efetue logon como o proprietário do
DAS e pare o DAS utilizando o comando db2admin da seguinte forma:
db2admin stop
Em sistemas operacionais Windows, o comando dasmigr pára e inicia o DAS .
2. Efetue logon como root nos sistemas operacionais Linux e UNIX ou com
autoridade de Administrador Local no Windows.
3. Migre o DAS no DB2 UDB Versão 8 executando o comando dasmigr:
Nos sistemas operacionais Linux e UNIX:
$DB2DIR/instance/dasmigr
em que DB2DIR é o local especificado durante a instalação do DB2
Versão 9.
Em sistemas operacionais Windows:
%DB2PATH%\bin\dasmigr
em que DB2PATH é o local que você especificou durante a instalação
do DB2 Versão 9.
Agora você pode utilizar o Centro de Controle para administração remota de
instâncias do DB2 Versão 9, além de instâncias do DB2 UDB Versão 8.
4. Em sistemas operacionais Linux e UNIX, efetue logon como proprietário do
DAS e inicie o DAS utilizando o comando db2admin da seguinte forma:
db2admin start
Você pode verificar se o DAS foi migrado para o DB2 Versão 9 executando o
comando db2daslevel.
5. Se você criou um banco de dados de catálogo de ferramentas no sistema DB2
UDB Versão 8 e quiser utilizar scripts e planejamentos existentes no Centro de
Controle do DB2 Versão 9, existem duas opções:
v Se você migrou para o DB2 Versão 9, a instância que possui o banco de
dados do catálogo de ferramentas da Versão 8, será necessário migrar esse
banco de dados e verificar se o DAS está configurado para acessá-lo.
v Se você não migrou para o DB2 Versão 9, a instância que possui o banco de
dados do catálogo de ferramentas da Versão 8, apenas verifique se o DAS
está configurado para acessar o banco de dados.
Capítulo 6. Migrando Servidores DB2 (Windows) 55
Execute o comando GET ADMIN CFG para exibir as definições de configuração
atuais para o catálogo do banco de dados de ferramentas:
db2 get admin cfg
Configuração do Servidor de Administração ...
Banco de Dados do Catálogo de Ferramentas (TOOLSCAT_DB) = toolsdb
Instância do Banco de Dados do Catálogo de
Ferramentas (TOOLSCAT_INST) = db2inst1
Esquema do Banco de Dados do Catálogo de
Ferramentas (TOOLSCAT_SCHEMA) = cc
ID de Usuário do Planejador =
Você pode utilizar o comando UPDATE ADMIN CFG se precisar alterar
quaisquer definições de configuração para o catálogo do banco de dados de
ferramentas.
Conceitos Relacionados:
v “Princípios de Migração para Servidores DB2” na página 19
Tarefas Relacionadas:
v “Criando um DAS (DB2 Administration Server)” em Administration Guide:
Implementation
Referência Relacionada:
v “dasmigr - Comando para Migrar o DB2 Administration Server” em Command
Reference
Migrando os Bancos de Dados
Após ter migrado suas instâncias para o DB2 Versão 9, é necessário migrar cada
banco de dados sob cada instância.
Pré-requisitos:
v Certifique-se de que tenha autoridade SYSADM.
v Faça backup de seus bancos de dados utilizando o comando BACKUP
DATABASE antes de migrar a instância.
v Você deve ter o DB2 Versão 9 instalado e ter migrado uma instância para o DB2
Versão 9.
Restrições:
v A migração é suportada somente a partir do DB2 UDB Versão 8.
v Restrições de migração adicionais se aplicam. Revise a lista completa para
migração do banco de dados.
Procedimento:
Para migrar um banco de dados DB2:
1. Efetue logon como o proprietário da instância ou um usuário com autoridade
SYSADM.
2. Migre o banco de dados utilizando o comando MIGRATE DATABASE:
db2 MIGRATE DATABASE database-alias USER username USING password
56 Guia de Migração
em que database-alias é o nome ou o alias do banco de dados que deseja migrar
e o nome do usuário e a senha para autenticar um usuário com autoridade
SYSADM.
Você também pode migrar seus bancos de dados utilizando o comando
RESTORE DATABASE em vez de o comando MIGRATE DATABASE.
3.
Se a migração do banco de dados falhar e retornar a mensagem de erro
SQL1704N com um código de razão que descreve a causa da falha, Localize o
código de erro SQL na Referência de Mensagens para ler a lista de possíveis
soluções para cada código de razão. Uma das causas mais comuns de falha de
migração é o espaço do arquivo de registro não ser grande o suficiente, que,
nesse caso, o seguinte erro é retornado:
SQL1704N Falha na migração do banco de dados. Código de razão "3".
Você deve e executar novamente o comando MIGRATE DATABASE. Após a
migração do banco de dados ser concluída, reconfigure o valor dos parâmetros
de configuração do banco de dados logfilsiz, logprimary e logsecond.
Há códigos de erro adicionais que são retornados pelo comando MIGRATE
DATABASE para casos específicos não suportados pela migração do banco de
dados. Esses casos são descritos nas Restrições de Migração.
4. Se a migração do banco de dados retornar uma mensagem de aviso SQL1243W,
será necessário eliminar ou renomear a tabela SYSTOOLS.DB2LOOK_INFO.
Caso contrário, as instruções ALTER TABLE e COPY SCHEMA falharão na
execução.
Verifique se a tabela SYSTOOLS.DB2LOOK_INFO existe executando o seguinte
comando:
db2 "SELECT tabname, tabschema, definer FROM syscat.tables
WHERE tabschema = ’SYSTOOLS’ AND tabname= ’DB2LOOK_INFO’ "
Se tiver criado essa tabela, simplesmente renomeie-a executando a instrução
RENAME:
db2 RENAME SYSTOOLS.DB2LOOK_INFO TO new-table-name
Se não tiver criado essa tabela, simplesmente remova-a executando o comando
DROP:
db2 DROP TABLE SYSTOOLS.DB2LOOK_INFO
5. Compare as definições de configuração do banco de dados após a migração
com as definições de configuração anteriores à migração do banco de dados.
Verifique as seguintes configurações e informações de banco de dados que são
as mesmas:
v as definições do parâmetro de configuração do banco de dados
v informações de espaços de tabelas
v informações sobre pacotes apenas para aplicativos
Não é necessário verificar as informações sobre pacote para os pacotes gerados
por sistema. As informações sobre os pacotes gerados por sistema podem ser
alteradas após a migração.
6. Verifique se a migração do banco de dados foi bem-sucedida. Conecte aos
bancos de dados migrados e emita uma pequena consulta:
db2 connect to sample
Database Connection Information
Servidor de banco de dados = DB2/AIX64 9.1.0
Capítulo 6. Migrando Servidores DB2 (Windows) 57
ID de autorização do SQL = TESTDB2
Alias do banco de dados local = SAMPLE
db2 "select * from syscat.dbauth"
Como alternativa, se você tiver arquivos de amostra instalados, execute o script
testdata.db2:
cd samplefile-dir-clp
db2 connect to sample
db2 -tvf testdata.db2
em que samplefile-dir-clp é DB2DIR/samples/clp no Linux e no UNIX e
DB2DIR\samples\clp no Windows, DB2DIR representa o local especificado
durante a instalação do DB2 Versão 9 e sample é o nome do banco de dados.
Após migrar um banco de dados DB2, executar as tarefas pós-migração
recomendadas assegura uma migração de banco de dados bem-sucedida.
Conceitos Relacionados:
v “Restrições de Migração para Servidores DB2” na página 21
v “Princípios de Migração para Servidores DB2” na página 19
Tarefas Relacionadas:
v “Aumentando os Tamanhos de Espaço de Tabela e Arquivo de Registro Antes da
Migração” na página 42
v “Salvando Informações de Configuração” na página 39
v “Verificando a Migração dos Servidores DB2” na página 105
Referência Relacionada:
v “Tarefas de Pós-migração para Servidores DB2” na página 87
v “Alterações nas Variáveis de Registro do DB2, nos Parâmetros de Configuração e
nas Características de Design Físico do Banco de Dados” na página 91
v “Tarefas de Pré-migração para Servidores DB2” na página 35
v “Comando MIGRATE DATABASE” em Command Reference
v “Comando RESTORE DATABASE” em Command Reference
58 Guia de Migração
Capítulo 7. Migrando Servidores DB2 (Linux e UNIX)
Este capítulo descreve como migrar seus servidores DB2 no Linux e UNIX. Ele
contém as seguintes seções:
v “Migrando um Servidor DB2 (Linux e UNIX)”
v “Migrando Instâncias” na página 60
v “Migrando o DAS (DB2 Administration Server)” na página 62
v “Migrando os Bancos de Dados” na página 64
Migrando um Servidor DB2 (Linux e UNIX)
A migração é requerida se você tiver instâncias e bancos de dados em execução no
DB2 UDB Versão 8 que deseja executar no DB2 Versão 9. Você deve migrar
manualmente suas instâncias, seu DAS (DB2 Administration Server) e seus bancos
de dados após a instalação do DB2 Versão 9.
Essa tarefa de migração descreve as etapas para migração direta do DB2 UDB
Versão 8 para o DB2 Versão 9. Reveja “Migrando Ambientes com Características
Específicas” na página 67 e determine qual tarefa se aplica melhor ao seu
ambiente.
Pré-requisitos:
Antes de migrar o servidor DB2:
v Certifique-se de ter acesso root.
v Reveja a Página da Web de Requisitos do Sistema para a instalação do produto
do banco de dados DB2. Os pré-requisitos para os sistemas operacionais Linux e
UNIX foram alterados.
v Reveja recomendações de migração e requisitos de espaço em disco.
v Execute tarefas de pré-migração.
Restrições:
v Esse procedimento aplica-se somente à migração do servidor DB2 de instâncias
de 32 bits para instâncias de 32 bits do DB2 Versão 9 ou de instâncias de 64 bits
para instâncias de 64 bits do DB2 Versão 9. No DB2 Versão 9, a instância é
somente de 32 bits no Linux em x86-32 e a instância é de 64 bits em todos os
outros sistemas operacionais Linux e UNIX suportados.
v A migração é suportada somente a partir do DB2 UDB Versão 8.
v A migração direta não é suportada a partir do DB2 UDB Versão 7 ou anterior.
Você deve migrar primeiro para o DB2 UDB Versão 8.
v Restrições de migração adicionais se aplicam. Reveja a lista completa.
Procedimento:
Para migrar para o DB2 Versão 9:
1. Efetue logon como root.
2. Instale o DB2 Versão 9. Execute o comando db2setup e selecione Instalar Novo
no painel Instalar um produto para instalar uma nova cópia do DB2 Versão 9.
© Direitos Autorais IBM Corp. 2006 59
3. Migre instâncias do mesmo caminho de instalação que você indicou durante a
instalação do DB2 Versão 9.
4. Opcional: Migre o DB2 Administration Server se quiser manter a configuração
existente e para administrar as instâncias do DB2 Versão 9 utilizando o Centro
de Controle.
5. Migrar bancos de dados.
Após migrar o servidor DB2, desempenhe as tarefas de pós-migração
recomendadas, como reconfigurar o nível de erro do diagnóstico, ajustar o
tamanho do espaço do registro e religar pacotes. Além disso, verifique se a
migração do servidor DB2 foi bem-sucedida.
Conceitos Relacionados:
v “Migrando Ambientes com Características Específicas” na página 67
v “Recomendações de Migração para Servidores DB2” na página 24
v “Restrições de Migração para Servidores DB2” na página 21
v “Princípios de Migração para Servidores DB2” na página 19
v “System administration authority (SYSADM)” em Administration Guide:
Implementation
Tarefas Relacionadas:
v “Instalando Servidores do DB2 (Linux e UNIX)” em Iniciação Rápida para DB2
Servers
v “Migrando Instâncias” na página 53
v “Migrando o DAS (DB2 Administration Server)” na página 54
v “Migrando os Bancos de Dados” na página 56
v “Verificando a Migração dos Servidores DB2” na página 105
v “Migrando Servidores DB2 de 32 Bits para Sistemas de 64 Bits (Linux e UNIX)”
na página 69
v “Uma Visão Geral sobre a Instalação do Seu Produto DB2 (Linux e UNIX)” em
Iniciação Rápida para DB2 Servers
Referência Relacionada:
v “Requisitos de Espaço em Disco para a Migração do Servidor DB2” na página 26
v “Tarefas de Pré-migração para Servidores DB2” na página 35
v “Tarefas de Pós-migração para Servidores DB2” na página 87
Migrando Instâncias
Como parte do processo geral de migração do servidor DB2 UDB Versão 8 para o
DB2 Versão 9, você deve migrar suas instâncias. No Linux e UNIX, você deve
migrá-los manualmente. No Windows, você deve migrá-los manualmente se não
optar por migrar automaticamente sua cópia existente do DB2 UDB Versão 8
durante a instalação do DB2 Versão 9.
Para migrar manualmente suas instâncias do DB2 UDB Versão 8, utilize o comando
db2imigr.
Pré-requisitos:
v É necessário ter autoridade root nos sistemas operacionais Linux e UNIX ou
autoridade de Administrador Local no Windows.
60 Guia de Migração
v Antes de executar o comando db2imigr, recomenda-se que:
– No UNIX, assegure que haja 20 MB de espaço livre no diretório /tmp. O
arquivo de rastreio da migração da instância está gravado em /tmp.
– Verifique se os bancos de dados estão prontos para migração do DB2.
Restrições:
v A migração direta não é suportada a partir do DB2 UDB Versão 7 ou anterior.
Você deve migrar primeiro para o DB2 UDB Versão 8.
v Restrições de migração adicionais se aplicam. Revise a lista completa para
migração da instância.
Procedimento:
Para migrar uma instância:
1. Pare as instâncias do DB2 UDB Versão 8 executando o comando db2stop:
db2stop
2. Efetue logon como autoridade root nos sistemas operacionais Linux e UNIX ou
como autoridade de Administrador Local no Windows.
3. Migre as instâncias executando o comando db2imigr.
Em sistemas operacionais Linux e UNIX:
$DB2DIR/instance/db2imigr -u fencedID InstName
em que
DB2DIR
está configurado para o local especificado durante a instalação
do DB2 Versão 9. O caminho da instalação padrão para o UNIX
é /opt/IBM/db2/V9.1 e para o Linux é /opt/ibm/db2/V9.1.
-u fencedID
É o usuário sob o qual as UDFs (Funções Definidas pelo
Usuário) protegidas e os procedimentos armazenados serão
executados.
InstName
É o nome do login do proprietário da instância.
Em sistemas operacionais Windows:
"%DB2PATH%"\bin\db2imigr InstName /u:user,password
em que
DB2PATH
está configurado para o local especificado durante a instalação
do DB2 Versão 9. O caminho da instalação padrão para o
Windows é Program Files\IBM\SQLLIB.
/u: user,password
são o nome do usuário e a senha sob os quais o serviço DB2
será executado.
InstName
É o nome do login do proprietário da instância.O comando db2imigr chama implicitamente o comando db2ckmig, indicando
migration.log como o arquivo de registro no diretório home da instância para
Linux e UNIX ou no diretório atual, onde você está executando o comando
Capítulo 7. Migrando Servidores DB2 (Linux e UNIX) 61
db2imigr para Windows. O db2imigr não é executado se o comando db2ckmig
relatar erros. Verifique o arquivo de registro caso encontre algum erro.
4. Efetue logon como o proprietário da instância.
5. Reinicie sua instância executando o comando db2start:
db2start
6. Verifique se sua instância está em execução no DB2 Versão 9 executando o
comando db2level:
db2level
Os tokens informativos devem incluir uma cadeia como ″DB2 v9.X.X.X″, em
que X é um número.
Conceitos Relacionados:
v “Restrições de Migração para Servidores DB2” na página 21
v “Princípios de Migração para Servidores DB2” na página 19
Tarefas Relacionadas:
v “Verificando se Seus Bancos de Dados Estão Prontos para Migração” na página
37
Referência Relacionada:
v “db2ckmig - Comando da Ferramenta de Pré-migração do Banco de Dados” em
Command Reference
v “db2icrt - Comando para Criar Instância” em Command Reference
v “db2imigr - Comando para Migrar a Instância” em Command Reference
Migrando o DAS (DB2 Administration Server)
Como parte do processo geral de migração para o DB2 Versão 9, você pode migrar
o DAS (DB2 Administration Server) para manter a configuração existente do DAS.
Caso contrário, você pode eliminar o DAS existente e criar um novo DAS no DB2
Versão 9. Você precisa de apenas um DAS em execução no DB2 Versão 9 para
utilizar o Centro de Controle para administração remota de instâncias,
gerenciamento de tarefa e planejamento de tarefa do DB2 Versão 9.
No Windows, se você optar por migrar automaticamente a instalação do DB2 UDB
Versão 8, o DAS também será migrado junto com as instâncias.
Após a instalação do DB2 Versão 9, você pode migrar manualmente o DAS
executando o comando dasmigr.
Pré-requisito:
v Certifique-se de ter autoridade root nos sistemas operacionais Linux e UNIX ou
autoridade de Administrador Local no sistema operacional Windows.
Restrições:
v A migração é suportada somente a partir do DB2 UDB Versão 8.
v Você pode ter somente um DAS por servidor DB2.
Procedimento:
Para migrar o DAS:
62 Guia de Migração
1. Nos sistemas operacionais Linux e UNIX, efetue logon como o proprietário do
DAS e pare o DAS utilizando o comando db2admin da seguinte forma:
db2admin stop
Em sistemas operacionais Windows, o comando dasmigr pára e inicia o DAS .
2. Efetue logon como root nos sistemas operacionais Linux e UNIX ou com
autoridade de Administrador Local no Windows.
3. Migre o DAS no DB2 UDB Versão 8 executando o comando dasmigr:
Nos sistemas operacionais Linux e UNIX:
$DB2DIR/instance/dasmigr
em que DB2DIR é o local especificado durante a instalação do DB2
Versão 9.
Em sistemas operacionais Windows:
%DB2PATH%\bin\dasmigr
em que DB2PATH é o local que você especificou durante a instalação
do DB2 Versão 9.
Agora você pode utilizar o Centro de Controle para administração remota de
instâncias do DB2 Versão 9, além de instâncias do DB2 UDB Versão 8.
4. Em sistemas operacionais Linux e UNIX, efetue logon como proprietário do
DAS e inicie o DAS utilizando o comando db2admin da seguinte forma:
db2admin start
Você pode verificar se o DAS foi migrado para o DB2 Versão 9 executando o
comando db2daslevel.
5. Se você criou um banco de dados de catálogo de ferramentas no sistema DB2
UDB Versão 8 e quiser utilizar scripts e planejamentos existentes no Centro de
Controle do DB2 Versão 9, existem duas opções:
v Se você migrou para o DB2 Versão 9, a instância que possui o banco de
dados do catálogo de ferramentas da Versão 8, será necessário migrar esse
banco de dados e verificar se o DAS está configurado para acessá-lo.
v Se você não migrou para o DB2 Versão 9, a instância que possui o banco de
dados do catálogo de ferramentas da Versão 8, apenas verifique se o DAS
está configurado para acessar o banco de dados.
Execute o comando GET ADMIN CFG para exibir as definições de configuração
atuais para o catálogo do banco de dados de ferramentas:
db2 get admin cfg
Configuração do Servidor de Administração ...
Banco de Dados do Catálogo de Ferramentas (TOOLSCAT_DB) = toolsdb
Instância do Banco de Dados do Catálogo de
Ferramentas (TOOLSCAT_INST) = db2inst1
Esquema do Banco de Dados do Catálogo de
Ferramentas (TOOLSCAT_SCHEMA) = cc
ID de Usuário do Planejador =
Você pode utilizar o comando UPDATE ADMIN CFG se precisar alterar
quaisquer definições de configuração para o catálogo do banco de dados de
ferramentas.
Conceitos Relacionados:
Capítulo 7. Migrando Servidores DB2 (Linux e UNIX) 63
v “Princípios de Migração para Servidores DB2” na página 19
Tarefas Relacionadas:
v “Criando um DAS (DB2 Administration Server)” em Administration Guide:
Implementation
Referência Relacionada:
v “dasmigr - Comando para Migrar o DB2 Administration Server” em Command
Reference
Migrando os Bancos de Dados
Após ter migrado suas instâncias para o DB2 Versão 9, é necessário migrar cada
banco de dados sob cada instância.
Pré-requisitos:
v Certifique-se de que tenha autoridade SYSADM.
v Faça backup de seus bancos de dados utilizando o comando BACKUP
DATABASE antes de migrar a instância.
v Você deve ter o DB2 Versão 9 instalado e ter migrado uma instância para o DB2
Versão 9.
Restrições:
v A migração é suportada somente a partir do DB2 UDB Versão 8.
v Restrições de migração adicionais se aplicam. Revise a lista completa para
migração do banco de dados.
Procedimento:
Para migrar um banco de dados DB2:
1. Efetue logon como o proprietário da instância ou um usuário com autoridade
SYSADM.
2. Migre o banco de dados utilizando o comando MIGRATE DATABASE:
db2 MIGRATE DATABASE database-alias USER username USING password
em que database-alias é o nome ou o alias do banco de dados que deseja migrar
e o nome do usuário e a senha para autenticar um usuário com autoridade
SYSADM.
Você também pode migrar seus bancos de dados utilizando o comando
RESTORE DATABASE em vez de o comando MIGRATE DATABASE.
3.
Se a migração do banco de dados falhar e retornar a mensagem de erro
SQL1704N com um código de razão que descreve a causa da falha, Localize o
código de erro SQL na Referência de Mensagens para ler a lista de possíveis
soluções para cada código de razão. Uma das causas mais comuns de falha de
migração é o espaço do arquivo de registro não ser grande o suficiente, que,
nesse caso, o seguinte erro é retornado:
SQL1704N Falha na migração do banco de dados. Código de razão "3".
Você deve e executar novamente o comando MIGRATE DATABASE. Após a
migração do banco de dados ser concluída, reconfigure o valor dos parâmetros
de configuração do banco de dados logfilsiz, logprimary e logsecond.
64 Guia de Migração
Há códigos de erro adicionais que são retornados pelo comando MIGRATE
DATABASE para casos específicos não suportados pela migração do banco de
dados. Esses casos são descritos nas Restrições de Migração.
4. Se a migração do banco de dados retornar uma mensagem de aviso SQL1243W,
será necessário eliminar ou renomear a tabela SYSTOOLS.DB2LOOK_INFO.
Caso contrário, as instruções ALTER TABLE e COPY SCHEMA falharão na
execução.
Verifique se a tabela SYSTOOLS.DB2LOOK_INFO existe executando o seguinte
comando:
db2 "SELECT tabname, tabschema, definer FROM syscat.tables
WHERE tabschema = ’SYSTOOLS’ AND tabname= ’DB2LOOK_INFO’ "
Se tiver criado essa tabela, simplesmente renomeie-a executando a instrução
RENAME:
db2 RENAME SYSTOOLS.DB2LOOK_INFO TO new-table-name
Se não tiver criado essa tabela, simplesmente remova-a executando o comando
DROP:
db2 DROP TABLE SYSTOOLS.DB2LOOK_INFO
5. Compare as definições de configuração do banco de dados após a migração
com as definições de configuração anteriores à migração do banco de dados.
Verifique as seguintes configurações e informações de banco de dados que são
as mesmas:
v as definições do parâmetro de configuração do banco de dados
v informações de espaços de tabelas
v informações sobre pacotes apenas para aplicativos
Não é necessário verificar as informações sobre pacote para os pacotes gerados
por sistema. As informações sobre os pacotes gerados por sistema podem ser
alteradas após a migração.
6. Verifique se a migração do banco de dados foi bem-sucedida. Conecte aos
bancos de dados migrados e emita uma pequena consulta:
db2 connect to sample
Database Connection Information
Servidor de banco de dados = DB2/AIX64 9.1.0
ID de autorização do SQL = TESTDB2
Alias do banco de dados local = SAMPLE
db2 "select * from syscat.dbauth"
Como alternativa, se você tiver arquivos de amostra instalados, execute o script
testdata.db2:
cd samplefile-dir-clp
db2 connect to sample
db2 -tvf testdata.db2
em que samplefile-dir-clp é DB2DIR/samples/clp no Linux e no UNIX e
DB2DIR\samples\clp no Windows, DB2DIR representa o local especificado
durante a instalação do DB2 Versão 9 e sample é o nome do banco de dados.
Após migrar um banco de dados DB2, executar as tarefas pós-migração
recomendadas assegura uma migração de banco de dados bem-sucedida.
Conceitos Relacionados:
Capítulo 7. Migrando Servidores DB2 (Linux e UNIX) 65
v “Restrições de Migração para Servidores DB2” na página 21
v “Princípios de Migração para Servidores DB2” na página 19
Tarefas Relacionadas:
v “Aumentando os Tamanhos de Espaço de Tabela e Arquivo de Registro Antes da
Migração” na página 42
v “Salvando Informações de Configuração” na página 39
v “Verificando a Migração dos Servidores DB2” na página 105
Referência Relacionada:
v “Tarefas de Pós-migração para Servidores DB2” na página 87
v “Alterações nas Variáveis de Registro do DB2, nos Parâmetros de Configuração e
nas Características de Design Físico do Banco de Dados” na página 91
v “Tarefas de Pré-migração para Servidores DB2” na página 35
v “Comando MIGRATE DATABASE” em Command Reference
v “Comando RESTORE DATABASE” em Command Reference
66 Guia de Migração
Capítulo 8. Migrando Ambientes com Características
Específicas
Este capítulo descreve como migrar ambientes com características específicas. Ele
contém as seguintes seções:
v “Migrando Ambientes com Características Específicas”
v “Migrando Servidores DB2 de 32 Bits para Sistemas de 64 Bits (Windows)” na
página 68
v “Migrando Servidores DB2 de 32 Bits para Sistemas de 64 Bits (Linux e UNIX)”
na página 69
v “Migrando para um Novo Servidor DB2” na página 72
v “Migrando Ambientes de Bancos de Dados Particionados” na página 74
v “Migrando de um Sistema com Várias Cópias do DB2 (Linux e UNIX)” na
página 76
v “Migrando dos Servidores DB2 UDB Versão 7 (Windows)” na página 78
v “Migrando dos Servidores DB2 UDB Versão 7 (Linux e UNIX)” na página 79
v “Migrando Servidores DB2 nos Ambientes do Microsoft Cluster Server” na
página 79
v “Migrando Ambientes do DB2 Data Links Manager” na página 81
v “Migrando o XML Extender” na página 83
v “Migrando de Sistemas de Gerenciamento de Banco de Dados Relacional
Não-DB2” na página 84
Migrando Ambientes com Características Específicas
Há muitos fatores que podem afetar o processo geral de migração e a
complexidade de seu ambiente é um desses fatores. Se você instalou diversos
componentes do produto DB2, se você estiver migrando de um sistema operacional
de 32 bits para um sistema operacional de 64 bits ou se você estiver migrando de
um release do produto anterior à V8, será necessário executar tarefas de migração
que incluem etapas específicas desse ambiente em vez de executar a tarefa
migração básica do servidor DB2.
Determine quais das tarefas de migração a seguir aplicam-se a seu ambiente e
execute essa tarefa de migração:
v Migrando Servidores de 32 Bits para Sistemas de 64 Bits (Windows)
v Migrando Servidores de 32 Bits para Sistemas de 64 Bits (Linux e UNIX)
v Migrando para um Novo Servidor DB2
v Migrando Ambientes de Bancos de Dados Particionados
v Migrando de um Sistema com Várias Cópias do DB2 (Linux e UNIX)
v Migrando de Servidores DB2 UDB Versão 7 (Windows)
v Migrando de Servidores DB2 UDB Versão 7 (Linux and UNIX)
v Migrando Servidores DB2 em Ambientes Microsoft Cluster Server
v Migrando Ambientes do DB2 Data Links Manager
v Migrando do XML Extender
v Migrando de Sistemas de Gerenciamento de Banco de Dados Relacional não-DB2
© Direitos Autorais IBM Corp. 2006 67
Conceitos Relacionados:
v “Princípios de Migração para Servidores DB2” na página 19
Tarefas Relacionadas:
v “Migrando um Servidor DB2 (Linux e UNIX)” na página 59
v “Migrando um Servidor DB2 (Windows)” na página 51
Referência Relacionada:
v “Tarefas de Pré-migração para Servidores DB2” na página 35
v “Tarefas de Pós-migração para Servidores DB2” na página 87
Migrando Servidores DB2 de 32 Bits para Sistemas de 64 Bits
(Windows)
Nos sistemas operacionais Windows, existem duas maneiras de migrar seu
servidor DB2 UDB Versão 8 de 32 bits para um servidor DB2 Versão 9 de 64 bits.
Uma maneira é migrar o servidor DB2 UDB Versão 8 de 32 bits existente para o
servidor DB2 Versão 9 de 32 bits e, em seguida, instalar o servidor DB2 Versão 9
de 64 bits. Esse procedimento é coberto por essa tarefa e aplica-se somente ao
Windows em X64.
A outra maneira é migrar para um novo servidor DB2 onde o produto do banco de
dados DB2 Versão 9 de 64 bits está instalado.
Pré-requisitos:
v Certifique-se de ter autoridade do Administrador Local.
v Certifique-se de que o servidor DB2 esteja em execução no sistema operacional
Windows de 64 bits.
v Reveja recomendações de migração e requisitos de espaço em disco.
v Execute tarefas de pré-migração.
Restrições:
v A migração é suportada somente a partir do DB2 UDB Versão 8.
v A migração direta não é suportada a partir do DB2 UDB Versão 7 ou anterior.
Você deve migrar primeiro para o DB2 UDB Versão 8.
v Restrições de migração adicionais se aplicam. Reveja a lista completa.
Procedimento:
Para migrar um servidor DB2 UDB Versão 8 de 32 bits para um servidor DB2
Versão 9 de 64 bits:
1. Efetuar logon como Administrador Local.
2. Instale o produto de banco de dados DB2 Versão 9 de 32 bits e opte por migrar
sua cópia existente do DB2 UDB Versão 8. Todas as suas instâncias do DB2
UDB Versão 8 e o DAS (DB2 Administration Server) são automaticamente
migrados. Não instale cópias adicionais do DB2 Versão 9 de 32 bits.
Você receberá um aviso que recomenda executar o comando db2ckmig se você
tiver bancos de dados locais. Ignore esse aviso e continue a migração se tiver
concluído as tarefas pré-migração. Caso contrário, verifique se seus bancos de
dados estão prontos para a migração do DB2 antes de continuar com a
instalação.
68 Guia de Migração
3. Instale o produto do banco de dados DB2 Versão 9 de 64 bits e escolha migrar.
Esse procedimento remove o produto de banco de dados DB2 Versão 9 de 32
bits e atualiza suas instâncias existentes para instâncias de 64 bits.
4. Migrar bancos de dados.
Após migrar o servidor DB2, desempenhe as tarefas de pós-migração
recomendadas, como reconfigurar o nível de erro do diagnóstico, ajustar o
tamanho do espaço do registro e religar pacotes. Além disso, verifique se a
migração do servidor DB2 foi bem-sucedida.
Conceitos Relacionados:
v “Recomendações de Migração para Servidores DB2” na página 24
v “Restrições de Migração para Servidores DB2” na página 21
v “Migrando Ambientes com Características Específicas” na página 67
v “Princípios de Migração para Servidores DB2” na página 19
v “Alterações de Suporte para Servidores DB2 de 32 Bits e 64 Bits” na página 28
Tarefas Relacionadas:
v “Migrando para um Novo Servidor DB2” na página 72
v “Instalando os Servidores do DB2 (Windows)” em Iniciação Rápida para DB2
Servers
v “Verificando se Seus Bancos de Dados Estão Prontos para Migração” na página
37
v “Migrando os Bancos de Dados” na página 56
v “Verificando a Migração dos Servidores DB2” na página 105
v “Uma Visão Geral sobre a Instalação de seu Produto do DB2 (Windows)” em
Iniciação Rápida para DB2 Servers
v “Migrando um Servidor DB2 (Windows)” na página 51
Referência Relacionada:
v “Requisitos de Espaço em Disco para a Migração do Servidor DB2” na página 26
v “Tarefas de Pré-migração para Servidores DB2” na página 35
v “Tarefas de Pós-migração para Servidores DB2” na página 87
v “Alterações nas Variáveis de Registro do DB2, nos Parâmetros de Configuração e
nas Características de Design Físico do Banco de Dados” na página 91
v “db2ckmig - Comando da Ferramenta de Pré-migração do Banco de Dados” em
Command Reference
v “Roteiro de várias Cópias do DB2” em Administration Guide: Implementation
Migrando Servidores DB2 de 32 Bits para Sistemas de 64 Bits (Linux e
UNIX)
Existem algumas etapas adicionais para migrar seu banco de dados para o DB2
Versão 9 em sistemas operacionais de 64 bits caso você esteja migrando de uma
instância do DB2 UDB Versão 8 de 32 bits no AIX, HP-UX, Solaris, Linux no
zSeries, Linux no POWER e Linux no x86-64. É necessário instalar um kernel de 64
bits antes de prosseguir com a instalação do DB2 Versão 9 e a migração
subseqüente.
Capítulo 8. Migrando Ambientes com Características Específicas 69
Se você estiver migrando para o DB2 Versão 9 em um novo sistema de 64 bits, siga
o mesmo procedimento para migrar para um novo servidor DB2. Utilize o mesmo
procedimento quando desejar migrar para o DB2 Versão 9 no Linux de 64 bits, na
família de plataformas Itanium (IPF).
Pré-requisitos:
v Certifique-se de ter acesso root.
v Assegure que você tenha autoridade SYSADM, SYSCTRL ou SYSMAINT.
v Reveja a Página da Web de Requisitos do Sistema para a instalação do produto
do banco de dados DB2. Os pré-requisitos para os sistemas operacionais Linux e
UNIX foram alterados.
v Reveja recomendações de migração e requisitos de espaço em disco.
v Execute tarefas de pré-migração.
Restrições:
v A migração é suportada somente a partir do DB2 UDB Versão 8.
v A migração direta não é suportada a partir do DB2 UDB Versão 7 ou anterior.
Você deve migrar primeiro para o DB2 UDB Versão 8.
v Restrições de migração adicionais se aplicam. Reveja a lista completa.
Procedimento:
Para migrar a partir de um servidor DB2 UDB Versão 8 de 32 bits para um
servidor DB2 Versão 9 de 64 bits:
1. Efetue logon como root.
2. Opcional: Atualize quaisquer instâncias de 32 bits para instâncias de 64 bits em
sistemas com kernel de 64 bits (exceto Linux em x86). Utilize o comando
db2iupdt:
db2stop
$DB2DIR/instance/db2iupdt -w 64 instance_name
db2 start
em que DB2DIR está configurado para o caminho de instalação do DB2 UDB
Versão 8.
Esta etapa é recomendada somente se você também estiver migrando para
aplicativos de 64 bits. Após a migração para o DB2 Versão 9, todas as suas
instâncias são migradas para instâncias de 64 bits e $INSTHOME/sqllib/lib
aponta para bibliotecas compartilhadas de 64 bits. Você deve testar seus
aplicativos para assegurar a execução bem-sucedida. Se você não atualizar para
uma instância de 64 bits, $INSTHOME/sqllib/lib aponta para bibliotecas
compartilhadas de 32 bits.
As plataformas que fornecem instâncias de 64 bits e incluem bibliotecas
compartilhadas de 32 bits são AIX, HP-UX, Solaris, Linux no zSeries, Linux no
Power e Linux no x86-64.
3. Instale o DB2 Versão 9 em seu sistema de 64 bits. Execute o comando db2setup
e selecione Instalar Novo no painel Instalar um Produto para instalar uma nova
cópia do DB2 Versão 9.
4. Migre instâncias do mesmo caminho de instalação que você indicou durante a
instalação do DB2 Versão 9. Na instância migrada, $INSTHOME/sqllib/lib é um
link para bibliotecas compartilhadas de 32 bits.
70 Guia de Migração
5. Opcional: Migre o DB2 Administration Server se quiser manter a configuração
existente e para administrar as instâncias do DB2 Versão 9 utilizando o Centro
de Controle.
6. Migrar bancos de dados.
Após migrar o servidor DB2, desempenhe as tarefas de pós-migração
recomendadas, como reconfigurar o nível de erro do diagnóstico, ajustar o
tamanho do espaço do registro e religar pacotes. Além disso, verifique se a
migração do servidor DB2 foi bem-sucedida.
Se você tiver aplicativos de banco de dados ou rotinas de 32 bits que acessarão os
bancos de dados migrados para instâncias de 64 bits do DB2 Versão 9, será
necessário garantir que eles serão executados com êxito após a migração. Consulte
as seguintes tarefas para obter detalhes:
v Migrando Aplicativos de Banco de Dados
v Migrando Rotinas
Conceitos Relacionados:
v “Recomendações de Migração para Servidores DB2” na página 24
v “Restrições de Migração para Servidores DB2” na página 21
v “Alterações de Suporte para Servidores DB2 de 32 Bits e 64 Bits” na página 28
v “Migrando Ambientes com Características Específicas” na página 67
v “Princípios de Migração para Servidores DB2” na página 19
Tarefas Relacionadas:
v “Migrando para um Novo Servidor DB2” na página 72
v “Instalando Servidores do DB2 (Linux e UNIX)” em Iniciação Rápida para DB2
Servers
v “Migrando Instâncias” na página 53
v “Migrando o DAS (DB2 Administration Server)” na página 54
v “Migrando os Bancos de Dados” na página 56
v “Verificando a Migração dos Servidores DB2” na página 105
v “Migrando Aplicativos de Banco de Dados” na página 153
v “Migrando Rotinas” na página 167
v “Migrando um Servidor DB2 (Linux e UNIX)” na página 59
v “Uma Visão Geral sobre a Instalação do Seu Produto DB2 (Linux e UNIX)” em
Iniciação Rápida para DB2 Servers
Referência Relacionada:
v “Requisitos de Espaço em Disco para a Migração do Servidor DB2” na página 26
v “Tarefas de Pré-migração para Servidores DB2” na página 35
v “Tarefas de Pós-migração para Servidores DB2” na página 87
v “db2iupdt - Comando para Atualizar Instâncias” em Command Reference
v “db2setup - Instalar o Comando do DB2” em Command Reference
Capítulo 8. Migrando Ambientes com Características Específicas 71
Migrando para um Novo Servidor DB2
Caso queira migrar para um novo servidor DB2 Versão 9, você precisa recriar suas
instâncias e, em seguida, restaurar seus bancos de dados DB2 UDB Versão 8. Após
restaurar o banco de dados, o comando RESTORE DATABASE executa
automaticamente o comando MIGRATE DATABASE.
Pré-requisitos:
v Certifique-se de ter acesso root nos sistemas operacionais Linux e UNIX ou de
Administrador Local no Windows.
v Certifique-se de que tenha autoridade SYSADM.
v Reveja a Página da Web de Requisitos do Sistema para a instalação do produto
do banco de dados DB2. Os pré-requisitos para sistemas operacionais foram
alterados.
v Reveja recomendações de migração e requisitos de espaço em disco.
v Execute tarefas de pré-migração.
Restrições:
v A migração é suportada somente a partir do DB2 UDB Versão 8.
v A migração direta não é suportada a partir do DB2 UDB Versão 7 ou anterior.
Você deve migrar primeiro para o DB2 UDB Versão 8.
v Restrições de migração adicionais se aplicam. Reveja a lista completa.
Procedimento:
Para migrar para um novo servidor DB2 Versão 9:
1. Faça backup dos seus bancos de dados DB2 UDB Versão 8 utilizando
comando BACKUP DATABASE.
2. Efetue logon como root nos sistemas operacionais Linux e UNIX ou como
Administrador Local no Windows no novo servidor DB2.
3. Instale o DB2 Versão 9 no novo servidor DB2.
4. executando o comando db2icrt a partir da cópia do DB2 Versão 9 que você
instalou na etapa anterior. Em seguida, restaure os valores do parâmetro de
configuração do gerenciador de banco de dados para cada instância utilizando
o comando UPDATE DATABASE MANAGER CONFIGURATION e os valores
que você salvou nas tarefas de pré-migração.
5. Opcional: Crie um novo DAS (DB2 Administration Server) no DB2 Versão 9.
Você vai precisar de um DAS se quiser utilizar o Centro de Controle para
administrar suas instâncias do DB2 Versão 9, gerenciar tarefas e planejar
tarefas.
6. Transfira os arquivos de backup do DB2 UDB Versão 8 para todos os bancos
de dados que deseja migrar para o novo servidor DB2.
7. Efetue logon como o proprietário da instância.
8. Migre o banco de dados utilizando o comando RESTORE DATABASE.
db2 RESTORE DATABASE sample FROM /db2/backups
em que sample é o nome do banco de dados e /db2/backups é o diretório para
o arquivo de backup do banco de dados.
Em um ambiente de banco de dados particionado, você deve executar o
comando RESTORE DATABASE em todas as partições de banco de dados.
72 Guia de Migração
9. Quando o banco de dados foi restaurado, mas o banco de dados não foi
migrado, o comando RESTORE DATABASE retorna o seguinte erro e inclui a
mensagem de erro de migração com o código de razão:
SQL2519N O banco de dados foi restaurado mas não foi migrado
para o release atual. Foi retornado o erro "-1704" com "3" tokens.
SQLSTATE=57011
A mensagem de erro SQL1704N indica que a migração do banco de dados
falhou. Localize o código de erro SQL na Referência de Mensagens para ler a
lista de possíveis soluções para cada código de razão. No exemplo anterior,
tokens ″3″ significa código de razão 3, que indica que a migração falhou
porque os registros de banco de dados estão cheios. Se esse erro ocorrer,
execute as etapas a seguir para migrar o banco de dados:
a. Aumente o tamanho total para todos os arquivos de registro.
b. Migre o banco de dados utilizando o comando MIGRATE DATABASE.
c. Se o tamanho do arquivo de registro ainda não for grande o suficiente, o
seguinte erro é retornado:
SQL1704N Falha na migração do banco de dados. Código de razão "3".
Você deve aumentar o tamanho do arquivo de registro e tentar migrar o
banco de dados novamente.
d. Após a migração ser concluída, configure novamente o valor dos
parâmetros de configuração do banco de dados logfilsiz, logprimary e
logsecond.10. Compare as definições de configuração do banco de dados após a migração
com as definições de configuração anteriores à migração do banco de dados.
Verifique as seguintes configurações e informações de banco de dados que são
as mesmas:
v as definições do parâmetro de configuração do banco de dados
v informações de espaços de tabelas
v informações de pacotes11. Verifique se a migração do banco de dados foi bem-sucedida. Conecte aos
bancos de dados migrados e emita uma pequena consulta:
db2 connect to sample
Database Connection Information
Servidor de banco de dados = DB2/AIX64 9.1.0
ID de autorização do SQL = TESTDB2
Alias do banco de dados local = SAMPLE
db2 "select * from syscat.dbauth"
Após migrar o servidor DB2, execute as tarefas de pós-migração recomendadas,
como reconfigurar o nível de erro do diagnóstico, ajustar o tamanho do espaço do
registro e religar pacotes. Além disso, verifique se a migração do servidor DB2 foi
bem-sucedida.
Conceitos Relacionados:
v “Recomendações de Migração para Servidores DB2” na página 24
v “Restrições de Migração para Servidores DB2” na página 21
v “Operações de Backup e Restauração entre Diferentes Sistemas Operacionais e
Plataformas de Hardware” em Data Recovery and High Availability Guide and
Reference
Capítulo 8. Migrando Ambientes com Características Específicas 73
v “Migrando Ambientes com Características Específicas” na página 67
Tarefas Relacionadas:
v “Criando uma Instância Utilizando db2icrt” em Suplemento de Instalação e
Configuração
v “Criando um DAS (DB2 Administration Server)” em Administration Guide:
Implementation
v “Aumentando os Tamanhos de Espaço de Tabela e Arquivo de Registro Antes da
Migração” na página 42
v “Migrando os Bancos de Dados” na página 56
v “Verificando a Migração dos Servidores DB2” na página 105
v “Uma Visão Geral sobre a Instalação do Seu Produto DB2 (Linux e UNIX)” em
Iniciação Rápida para DB2 Servers
v “Uma Visão Geral sobre a Instalação de seu Produto do DB2 (Windows)” em
Iniciação Rápida para DB2 Servers
v “Migrando um Servidor DB2 (Linux e UNIX)” na página 59
v “Migrando um Servidor DB2 (Windows)” na página 51
Referência Relacionada:
v “Requisitos de Espaço em Disco para a Migração do Servidor DB2” na página 26
v “Tarefas de Pré-migração para Servidores DB2” na página 35
v “Tarefas de Pós-migração para Servidores DB2” na página 87
v “Alterações nas Variáveis de Registro do DB2, nos Parâmetros de Configuração e
nas Características de Design Físico do Banco de Dados” na página 91
v “Comando MIGRATE DATABASE” em Command Reference
Migrando Ambientes de Bancos de Dados Particionados
Os bancos de dados DB2 Versão 9 particionados podem ser migrados do servidor
de partição de banco de dados do catálogo ou de qualquer outro servidor de
partição de banco de dados. Caso o processo de migração falhe, você pode tentar a
migração novamente a partir do servidor de partição de banco de dados do
catálogo ou de qualquer outro servidor de partição de banco de dados.
Pré-requisitos:
v Certifique-se de ter acesso root nos sistemas operacionais Linux e UNIX ou de
Administrador Local no Windows.
v Certifique-se de que tenha autoridade SYSADM.
v Reveja a Página da Web de Requisitos do Sistema para a instalação do produto
do banco de dados DB2. Os pré-requisitos para sistemas operacionais foram
alterados.
v Reveja recomendações de migração e requisitos de espaço em disco.
v Execute tarefas de pré-migração.
Restrições:
v A migração é suportada somente a partir do DB2 UDB Versão 8.
v A migração direta não é suportada a partir do DB2 UDB Versão 7 ou anterior.
Você deve migrar primeiro para o DB2 UDB Versão 8.
v Restrições de migração adicionais se aplicam. Reveja a lista completa.
74 Guia de Migração
v O servidor de partição de banco de dados do catálogo deve estar ativado e em
execução.
Procedimento:
Para migrar servidores DB2 em um ambiente de banco de dados particionado:
1. Execute um backup off-line completo de todos os bancos de dados, verifique se
seus bancos de dados estão prontos para migração e quaisquer outras tarefas
de pré-migração que se apliquem.
2. Instale o DB2 Versão 9 em cada servidor de partição de banco de dados
participante e configure seu ambiente de banco de dados particionado.
3. Migre cada instância do servidor de partição do banco de dados que possui a
instância. Você pode ignorar essa etapa se tiver optado por migrar
automaticamente as instâncias durante a instalação do DB2 Versão 9 no
Windows.
4. Migre cada banco de dados do servidor de partição de banco de dados do
catálogo. Se um dos servidores de partição de banco de dados não do catálogo
não estiver disponível durante a migração, todas as partições de banco de
dados desse servidor não são migradas. No entanto, você pode executar o
comando MIGRATE DATABASE novamente para processar esse servidor de
partição de banco de dados específico posteriormente quando estiver ativado e
em execução.
5. Crie um novo DAS (DB2 Administration Server) em cada servidor de partição
de banco de dados. Caso precise manter as configurações existentes do DAS,
você pode migrar o DAS de cada servidor de partição de banco de dados
participante em vez de criar um novo DAS.
Após migrar o servidor DB2, desempenhe as tarefas de pós-migração
recomendadas, como reconfigurar o nível de erro do diagnóstico, ajustar o
tamanho do espaço do registro e religar pacotes. Além disso, verifique se a
migração do servidor DB2 foi bem-sucedida.
Conceitos Relacionados:
v “Recomendações de Migração para Servidores DB2” na página 24
v “Restrições de Migração para Servidores DB2” na página 21
v “Migrando Ambientes com Características Específicas” na página 67
Tarefas Relacionadas:
v “Migrando Instâncias” na página 53
v “Migrando os Bancos de Dados” na página 56
v “Criando um DAS (DB2 Administration Server)” em Administration Guide:
Implementation
v “Migrando o DAS (DB2 Administration Server)” na página 54
v “Verificando a Migração dos Servidores DB2” na página 105
v “Configurando um Ambiente de Banco de Dados Particionado” em Iniciação
Rápida para DB2 Servers
v “Migrando um Servidor DB2 (Linux e UNIX)” na página 59
v “Migrando um Servidor DB2 (Windows)” na página 51
Referência Relacionada:
v “Requisitos de Espaço em Disco para a Migração do Servidor DB2” na página 26
Capítulo 8. Migrando Ambientes com Características Específicas 75
v “Tarefas de Pré-migração para Servidores DB2” na página 35
v “Tarefas de Pós-migração para Servidores DB2” na página 87
v “Comando MIGRATE DATABASE” em Command Reference
v “dasmigr - Comando para Migrar o DB2 Administration Server” em Command
Reference
v “db2imigr - Comando para Migrar a Instância” em Command Reference
Migrando de um Sistema com Várias Cópias do DB2 (Linux e UNIX)
No Linux e UNIX, você pode migrar para o DB2 Versão 9 de um servidor DB2 que
possui várias cópias do DB2 Enterprise Server Edition (ESE) Versão 8. Caso tenha
instalado diversos fix packs substitutos como uma cópia completamente nova do
DB2 ESE, você pode ter diversas cópias do DB2 ESE no mesmo servidor DB2. É
necessário migrar manualmente quaisquer instâncias do DB2 UDB Versão 8 para
uma cópia do DB2 Versão 9 de sua escolha.
Você pode migrar manualmente uma instância do DB2 UDB Versão 8 em qualquer
nível de fix pack, executando o comando db2imigr da cópia de destino do DB2
Versão 9 de sua opção. Depois de migrar uma instância para uma cópia do a DB2
Versão 9, não será possível migrar para outra cópia do DB2 Versão 9. Além disso,
não é possível migrar para o DB2 UDB Versão 8. No entanto, é possível fazer
upgrade de uma instância entre diferentes cópias do DB2 do DB2 Versão 9
utilizando o comando db2iupdt.
Pré-requisitos:
v Certifique-se de ter acesso root.
v Reveja a Página da Web de Requisitos do Sistema para a instalação do produto
do banco de dados DB2. Os pré-requisitos para os sistemas operacionais Linux e
UNIX foram alterados.
v Reveja recomendações de migração e requisitos de espaço em disco.
v Execute tarefas de pré-migração.
Restrições:
v A migração é suportada somente a partir do DB2 UDB Versão 8.
v A migração direta não é suportada a partir do DB2 UDB Versão 7 ou anterior.
Você deve migrar primeiro para o DB2 UDB Versão 8.
v Restrições de migração adicionais se aplicam. Reveja a lista completa.
Procedimento:
Para migrar o servidor DB2:
1. Efetue logon como root.
2. Instale o DB2 Versão 9. Execute o comando db2setup e selecione Instalar Novo
no painel Instalar um produto para instalar uma nova cópia do DB2 Versão 9.
Você pode instalar várias cópias do DB2 Versão 9 se quiser migrar suas
instâncias do DB2 UDB Versão 8 em diferentes níveis para diferentes cópias do
DB2 Versão 9.
3. Migre cada instância utilizando o comando db2imigr a partir do caminho da
instalação da cópia do DB2 Versão 9 de sua opção.
Suponha que você tenha as seguintes cópias e instâncias do DB2 em um
servidor AIX:
76 Guia de Migração
Tabela 8. Exemplos de Diretório para Cópias do DB2.
Nível do DB2
instalado
Nome da
Instância Diretório de instalação para cada cópia do DB2
DB2 UDB Versão 8 db2inst1
db2inst2
/usr/opt/db2_08_01
/usr/opt/db2_08_FP7/
DB2 Versão 9 Nenhuma /opt/IBM/db2/V9.1
/home/db2/myV9.1
Você pode, então, executar os seguintes comandos para migrar com êxito suas
instâncias para o DB2 Versão 9:
Tabela 9. Exemplo de Comandos de Migração de Instâncias.
Migrar Instância Comandos
db2inst1 cd /opt/IBM/db2/V9.1/instance
db2imigr -u db2fenc1 db2inst1
db2inst2 cd /home/db2/myV9.1/instance
db2imigr -u db2fenc2 db2inst2
4. Opcional: Migre o DB2 Administration Server se quiser manter a configuração
existente e para administrar as instâncias do DB2 Versão 9 utilizando o Centro
de Controle.
5. Efetue logon como o proprietário da instância migrada.
6. Migrar bancos de dados.
Após migrar o servidor DB2, desempenhe as tarefas de pós-migração
recomendadas, como reconfigurar o nível de erro do diagnóstico, ajustar o
tamanho do espaço do registro e religar pacotes. Além disso, verifique se a
migração do servidor DB2 foi bem-sucedida.
Conceitos Relacionados:
v “Recomendações de Migração para Servidores DB2” na página 24
v “Restrições de Migração para Servidores DB2” na página 21
v “Migrando Ambientes com Características Específicas” na página 67
v “Princípios de Migração para Servidores DB2” na página 19
Tarefas Relacionadas:
v “Instalando Servidores do DB2 (Linux e UNIX)” em Iniciação Rápida para DB2
Servers
v “Migrando Instâncias” na página 53
v “Migrando o DAS (DB2 Administration Server)” na página 54
v “Migrando os Bancos de Dados” na página 56
v “Verificando a Migração dos Servidores DB2” na página 105
v “Migrando um Servidor DB2 (Linux e UNIX)” na página 59
v “Migrando um Servidor DB2 (Windows)” na página 51
v “Trabalhando com Cópias Existentes do DB2” em Iniciação Rápida para DB2
Servers
Referência Relacionada:
v “Requisitos de Espaço em Disco para a Migração do Servidor DB2” na página 26
v “Tarefas de Pré-migração para Servidores DB2” na página 35
v “Tarefas de Pós-migração para Servidores DB2” na página 87
Capítulo 8. Migrando Ambientes com Características Específicas 77
v “db2imigr - Comando para Migrar a Instância” em Command Reference
v “db2setup - Instalar o Comando do DB2” em Command Reference
v “Roteiro de várias Cópias do DB2” em Administration Guide: Implementation
Migrando dos Servidores DB2 UDB Versão 7 (Windows)
Não há nenhuma migração direta para o DB2 Versão 9 do DB2 UDB Versão 7. Você
deve migrar primeiro para o DB2 UDB Versão 8 e, em seguida, migrar para o DB2
Versão 9. Você deve migrar para o FixPak mais recente do DB2 UDB Versão 8.2
para tirar proveito de todas as correções que podem afetar a migração.
Pré-requisitos:
v Assegure que você tenha acesso de Administrador Local.
v Certifique-se de que tenha autoridade SYSADM.
Restrições:
v A migração para o DB2 Versão 9 é suportada somente a partir do DB2 UDB
Versão 8.
v A migração para o DB2 UDB Versão 8 é suportada a partir do DB2 UDB Versão
7.
v As alterações no suporte ao sistema operacional podem requerer que você faça
upgrade do nível de hardware e de sistema operacional antes de migrar para o
DB2 Versão 9.
Procedimento:
Para migrar um servidor DB2 UDB Versão 7 para o DB2 Versão 9:
1. Migração para o DB2 UDB Versão 8 do DB2 UDB Versão 7.
2. Religue os pacotes nos bancos de dados migrados.
3. Verifique se a migração para o DB2 UDB Versão 8 foi bem-sucedida.
4. Migre para o DB2 Versão 9 (Windows).
Conceitos Relacionados:
v “Migrando Ambientes com Características Específicas” na página 67
v “Princípios de Migração para Servidores DB2” na página 19
v Capítulo 3, “Visão Geral da Migração para Servidores DB2”, na página 17
Tarefas Relacionadas:
v “Migrando um Servidor DB2 (Windows)” na página 51
v “Uma Visão Geral sobre a Instalação de seu Produto do DB2 (Windows)” em
Iniciação Rápida para DB2 Servers
Referência Relacionada:
v “Comando MIGRATE DATABASE” em Command Reference
78 Guia de Migração
Migrando dos Servidores DB2 UDB Versão 7 (Linux e UNIX)
Não há nenhuma migração direta para o DB2 Versão 9 do DB2 UDB Versão 7. Você
deve migrar primeiro para o DB2 UDB Versão 8 e, em seguida, migrar para o DB2
Versão 9. Você deve migrar para o FixPak mais recente do DB2 UDB Versão 8.2
para tirar proveito de todas as correções que podem afetar a migração.
Pré-requisitos:
v Certifique-se de ter acesso root.
v A autoridade SYSADM é requerida.
Restrições:
v A migração para o DB2 Versão 9 é suportada somente a partir do DB2 UDB
Versão 8.
v A migração para o DB2 UDB Versão 8 é suportada a partir do DB2 UDB Versão
7.
v As alterações no suporte ao sistema operacional também podem requerer que
você faça upgrade do nível de hardware e do sistema operacional antes de
migrar para o DB2 Versão 9.
Procedimento:
Para migrar um servidor DB2 UDB Versão 7 para o DB2 Versão 9:
1. Migração para o DB2 UDB Versão 8 do DB2 UDB Versão 7.
2. Religue os pacotes nos bancos de dados migrados.
3. Verifique se a migração para o DB2 UDB Versão 8 foi bem-sucedida.
4. Migre para o DB2 Versão 9 (Linux e UNIX).
Conceitos Relacionados:
v “Migrando Ambientes com Características Específicas” na página 67
v “Princípios de Migração para Servidores DB2” na página 19
v Capítulo 3, “Visão Geral da Migração para Servidores DB2”, na página 17
Tarefas Relacionadas:
v “Migrando um Servidor DB2 (Linux e UNIX)” na página 59
Referência Relacionada:
v “db2imigr - Comando para Migrar a Instância” em Command Reference
v “Comando MIGRATE DATABASE” em Command Reference
Migrando Servidores DB2 nos Ambientes do Microsoft Cluster Server
O MSCS (Microsoft Cluster Server) fornece funções de Alta Disponibilidade para
usuários do Windows. Durante a configuração do suporte a failover do servidor
DB2 no MSCS, uma instância do servidor é transformada em uma instância do
MSCS. Ao migrar para o DB2 Versão 9, é necessário migrar sua instância do MSCS.
É possível executar o comando db2imigr para migrar sua instância do MSCS e
para migrar recursos existentes do MSCS do DB2 Versão 8 para recursos do MSCS
do DB2 do DB2 Versão 9.
Capítulo 8. Migrando Ambientes com Características Específicas 79
Pré-requisitos:
v Assegure que você tenha acesso de Administrador Local.
v A autoridade SYSADM é requerida.
v Reveja recomendações de migração e requisitos de espaço em disco.
v Execute tarefas de pré-migração.
Restrições:
v A migração é suportada somente a partir do DB2 UDB Versão 8.
v Esse procedimento refere-se à migração do servidor DB2 de instâncias de 32 bits
para instâncias de 32 bits ou de instâncias de 64 bits para instâncias de 64 bits.
v Restrições de migração adicionais se aplicam. Reveja a lista completa.
Procedimento:
Para migrar uma instância do MSCS:
1. Efetuar logon como Administrador Local.
2. Faça backup de seus bancos de dados.
3. Instale o DB2 Versão 9 em todos os nós no cluster MSCS. Execute o comando
setup.exe para ativar o assistente de Configuração do DB2 e selecione a opção
Instalar Novo no painel Instalar um Produto. Não escolha a opção migrar.
4. Deixe o recurso para a instância off-line utilizando o Administrador de Cluster.
O nome do recurso é o mesmo que o nome da instância. Assegure que todos os
recursos remanescentes do mesmo grupo que a instância estejam on-line.
5. Migre suas instâncias do MSCS executando o comando db2imigr. Esse
comando define um novo tipo de recurso chamado ″DB2 Server″ e atualiza
todos os recursos MSCS do DB2 para utilizar o novo tipo de recurso. Ter um
novo tipo de recurso durante a migração elimina o conflito com os recurso
MSCS existentes do DB2 UDB Versão 8.
$DB2DIR\bin\db2imigr /u:user,password MSCS-InstName
Você deve executar esse comando a partir do nó que possui todos os recursos
dependentes da instância.
6. Coloque on-line o grupo de recursos que contém a instância migrada utilizando
o Administrador do Cluster. Para obter informações adicionais sobre como
utilizar o Administrador do Cluster, consulte a documentação do MSCS.
7. Opcional: Caso queira administrar as instâncias do DB2 Versão 9 utilizando o
Centro de Controle e manter a configuração existente do ambiente MSCS, migre
o DAS (DB2 Administration Server). Se você optar por criar um novo DAS, será
necessário reconfigurar as configurações do DAS para o ambiente MSCS.
8. Migrar bancos de dados.
Após migrar o servidor DB2, desempenhe as tarefas de pós-migração
recomendadas, como reconfigurar o nível de erro do diagnóstico, ajustar o
tamanho do espaço do registro e religar pacotes. Além disso, verifique se a
migração do servidor DB2 foi bem-sucedida.
Conceitos Relacionados:
v “Recomendações de Migração para Servidores DB2” na página 24
v “Restrições de Migração para Servidores DB2” na página 21
v “Princípios de Migração para Servidores DB2” na página 19
v “Migrando Ambientes com Características Específicas” na página 67
80 Guia de Migração
v “Variáveis de Ambiente e o Registro de Perfil” em Administration Guide:
Implementation
v “Suporte ao Microsoft Cluster Server” em Data Recovery and High Availability
Guide and Reference
Tarefas Relacionadas:
v “Fazendo Backup dos Bancos de Dados antes da Migração” na página 38
v “Migrando o DAS (DB2 Administration Server)” na página 54
v “Criando um DAS (DB2 Administration Server)” em Administration Guide:
Implementation
v “Migrando os Bancos de Dados” na página 56
v “Verificando a Migração dos Servidores DB2” na página 105
v “Migrando Instâncias” na página 53
v “Migrando um Servidor DB2 (Windows)” na página 51
v “Migrando Servidores DB2 de 32 Bits para Sistemas de 64 Bits (Windows)” na
página 68
Referência Relacionada:
v “Requisitos de Espaço em Disco para a Migração do Servidor DB2” na página 26
v “Tarefas de Pré-migração para Servidores DB2” na página 35
v “Tarefas de Pós-migração para Servidores DB2” na página 87
v “db2imigr - Comando para Migrar a Instância” em Command Reference
Migrando Ambientes do DB2 Data Links Manager
A migração do DB2 UDB Versão 8 para o DB2 Versão 9 não é suportada em um
servidor DB2 onde o Data Links Manager está instalado ou onde a funcionalidade
do Data Links está ativada. No entanto, você pode migrar para o DB2 Versão 9 se
você remover a funcionalidade do Data Links Manager.
Pré-requisitos:
v Certifique-se de ter acesso root nos sistemas operacionais Linux e UNIX ou de
Administrador Local no Windows.
v Certifique-se de que tenha autoridade SYSADM.
v Reveja a Página da Web de Requisitos do Sistema para a instalação do produto
do banco de dados DB2. Os pré-requisitos para os sistemas operacionais Linux e
UNIX foram alterados.
v Reveja recomendações de migração e requisitos de espaço em disco.
v Execute tarefas de pré-migração.
Restrições:
v A migração é suportada somente a partir do DB2 UDB Versão 8.
v A migração direta não é suportada a partir do DB2 UDB Versão 7 ou anterior.
Você deve migrar primeiro para o DB2 UDB Versão 8.
v Restrições de migração adicionais se aplicam. Reveja a lista completa.
Procedimento:
Para migrar um servidor DB2 no ambiente Data Links para o DB2 Versão 9:
1. Remova o Data Links Manager de seus bancos de dados.
Capítulo 8. Migrando Ambientes com Características Específicas 81
2. Elimine todas as referências ao tipo de dados DATALINK das tabelas, tipos
estruturados, UDFs (User-Defined Functions), métodos e objetos dependentes.
3. Se tiver instalado o DB2 NSE (Net Search Extender), será necessário eliminar
as seguintes UDFs:
db2 DROP SPECIFIC FUNCTION DB2EXT.DATALINKCONTENT1;
db2 DROP SPECIFIC FUNCTION DB2EXT.DATALINKCONTENT2;
db2 DROP SPECIFIC FUNCTION DB2EXT.DATALINKCONTENT4;
db2 DROP SPECIFIC FUNCTION DB2EXT.DATALINKCONTENT3;
Essas UDFs são sempre criadas pelo NSE para suporte a Data Links,
independentemente da instalação do Data Links Manager. Portanto, é
necessário remover essas funções mesmo quando o Data Links Manager não
está instalado.
4. Desinstale o Data Links Manager no servidor DB2 que deseja migrar.
5. Atualize suas instâncias para eliminar o software Data Links Manager e
execute como um servidor DB2 apenas executando o comando db2iupdt:
db2iupdt instance-name
6. Opcional: Desative a funcionalidade do DB2 Data Links configurando o
parâmetro de configuração do gerenciador de banco de dados datalinks como
NO:
db2 UPDATE DBM CFG USING datalinks NO
Ao migrar a instância, o parâmetro datalinks é configurado para NO.
7. Instale o DB2 Versão 9 no servidor DB2. Prossiga para a etapa 9, se estiver
instalando o DB2 Versão 9 no Windows e tiver optado por migrar sua cópia
existente do DB2 UDB Versão 8.
8. Migre instâncias do mesmo caminho de instalação indicado na etapa 7.
9. Opcional: Migre o DB2 Administration Server se quiser manter a configuração
existente e para administrar as instâncias do DB2 Versão 9 utilizando o Centro
de Controle.
10. Migrar bancos de dados.
Após migrar o servidor DB2, desempenhe as tarefas de pós-migração
recomendadas, como reconfigurar o nível de erro do diagnóstico, ajustar o
tamanho do espaço do registro e religar pacotes. Além disso, verifique se a
migração do servidor DB2 foi bem-sucedida.
Conceitos Relacionados:
v “Recomendações de Migração para Servidores DB2” na página 24
v “O Que Há de Novo na V9.1: O Data Links Manager Não É Mais Suportado”
em O que Há de Novo
v “Funcionalidade Obsoleta ou Descontinuada em Produtos do Banco de Dados
DB2 que Afeta a Migração” na página 30
v “Migrando Ambientes com Características Específicas” na página 67
v “Princípios de Migração para Servidores DB2” na página 19
v “Restrições de Migração para Servidores DB2” na página 21
Tarefas Relacionadas:
v “Migrando Instâncias” na página 53
v “Migrando o DAS (DB2 Administration Server)” na página 54
v “Migrando os Bancos de Dados” na página 56
v “Verificando a Migração dos Servidores DB2” na página 105
82 Guia de Migração
Referência Relacionada:
v “Requisitos de Espaço em Disco para a Migração do Servidor DB2” na página 26
v “Tarefas de Pré-migração para Servidores DB2” na página 35
v “Tarefas de Pós-migração para Servidores DB2” na página 87
Migrando o XML Extender
O DB2 Versão 9 suporta o armazenamento XML nativo em um formato de árvore
anotada semelhante ao do XML DOM (Document Object Model). Esse suporte
inclui um novo tipo XML, índices XML e uma série de funções SQL/XML. Você
pode migrar seu aplicativo de banco de dados do XML Extender para utilizar o
armazenamento XML nativo no DB2 Versão 9.
Pré-requisito:
Um servidor DB2 UDB Versão 8 no qual o XML Extender está instalado.
Restrição:
A funcionalidade XML nativa é suportada somente em bancos de dados Unicode.
Caso tenha criado seus bancos de dados no DB2 UDB Versão 8 como um banco de
dados Unicode, você poderá migrar para o DB2 Versão 9 e começar a utilizar a
funcionalidade XML. Caso contrário, você deve primeiro converter seu banco de
dados para um banco de dados Unicode.
Procedimento:
Para migrar do XML Extender para o novo suporte de armazenamento XML
nativo:
1. Migre para o DB2 Versão 9 (Windows) ou Migre para oDB2 Versão 9 (Linux e
UNIX).
2. Converta seus bancos de dados em bancos de dados Unicode. Se tiver criado
seus bancos de dados no DB2 UDB Versão 8 como um banco de dados
Unicode, você pode começar a utilizar a funcionalidade XML com seu banco de
dados migrado. Caso contrário, você deve exportar seu banco de dados, criar
seu banco de dados novamente executando CREATE DATABASE com a
cláusula USING CODESET utf-8 TERRRITORY territory, e, em seguida, carregar
seus dados.
3. Inclua as colunas de tipo XML em suas tabelas. Utilize o comando ALTER
TABLE:
db2 ALTER TABLE table_name
ADD column_name XML [NOT NULL]
É necessário executar essa etapa somente se você armazenar de forma intacta
seus documentos XML em uma coluna de tipo de dados CLOB, VARCHAR,
XMLCLOB, XMLVARCHAR ou XMLFILE.
4. Registre os esquemas XML no XSR (XML Schema Repository). Se você tiver
DTDs (Document Type Definitions), você deve convertê-las para esquemas
XML e, em seguida, registrá-las no XSR. Você precisar executar essa etapa
somente se quiser validar seus documentos XML.
5. Importe os documentos XML para a tabela com a nova coluna de tipo de dados
XML.
Capítulo 8. Migrando Ambientes com Características Específicas 83
6. Converta seu aplicativo para utilizar a decomposição do esquema XML anotado
para armazenar o conteúdo de documentos XML nas colunas de tabela e as
novas funções SQL/XML para construir ou publicar XML utilizando o novo
tipo de dados XML.
Detalhes sobre todas essas etapas de migração e exemplo de migração de
aplicativo estão disponíveis em uma série de white papers no developerWorks
Information Management. Você pode fazer download dessa série de white papers a
partir do portal de migração do produto do banco de dados DB2 conforme ela é
disponibilizada.
Conceitos Relacionados:
v “O que Há de Novo na V9.1: Suporte a XML em Instruções SQL e Funções
SQL/XML” em O que Há de Novo
v “Migrando Ambientes com Características Específicas” na página 67
v “Princípios de Migração para Servidores DB2” na página 19
v Capítulo 3, “Visão Geral da Migração para Servidores DB2”, na página 17
v “Decomposição de Esquema XML Anotado” em Guia XML
v “Suporte à Linguagem de Programação de Aplicativos para XML” em Guia XML
v “Visão Geral do Armazenamento de Dados XML Nativo” em Guia XML
Tarefas Relacionadas:
v “Migrando um Servidor DB2 (Windows)” na página 51
v “Migrando um Servidor DB2 (Linux e UNIX)” na página 59
v “Convertendo Bancos de Dados não-Unicode em Unicode” em Administration
Guide: Planning
v “Registrando e Ativando Esquemas XML para Decomposição” em Guia XML
v “Decompondo Documentos XML com Esquemas XML Anotados” em Guia XML
Referência Relacionada:
v “Restrições para Armazenamento de Dados XML Nativos” em Guia XML
Migrando de Sistemas de Gerenciamento de Banco de Dados
Relacional Não-DB2
Migrar de um sistema de gerenciamento de banco de dados relacional não-DB2 é
um processo mais complexo do que migrar de um produto do banco de dados
DB2. Portanto, você deve determinar cuidadosamente o que o processo de
migração engloba e criar um plano de implementação.
O plano de implementação deve incluir tarefas, como converter os objetos de
banco de dados para criar os objetos de banco de dados equivalentes em um banco
de dados DB2, mover os dados em si para o novo banco de dados DB2 e
implementar seus aplicativos de banco de dados. A implementação de seus
aplicativos refere-se à conversão das instruções SQL, modificação das chamadas de
interface e conversão de qualquer código específico de banco de dados para
acessar bancos de dados DB2.
As abordagens mais comuns para converter um aplicativo de banco de dados são
conversão manual, tradução de chamada dinâmica e conversão automatizada. Em
geral, as ferramentas de conversão utilizam o código fonte como entrada e
traduzem as chamadas de gerenciamento de dados em chamadas SQL
84 Guia de Migração
equivalentes. Informações do banco de dados de origem e de destino, assim como
o código do programa, são utilizados para construir as novas instruções SQL.
O IBM MTK (Migration Toolkit) é uma ferramenta de conversão que foi projetada
para migrar dados e o idioma de consulta e procedimento dos sistemas de
gerenciamento de banco de dados de origem, como Informix Dynamic Server,
Informix XPS (Extended Parallel Server), Microsoft SQL Server, Oracle e Sybase
Enterprise, para produtos do banco de dados DB2. MTK é executado nos sistemas
operacionais AIX, Linux, Solaris e Windows. O único idioma suportado é inglês.
MTK está disponível como um download complementar a partir da página da Web
do IBM Migration Toolkit .
Os recursos mais importantes e freqüentemente acessados que a IBM oferece para
auxiliar em todos os aspectos de migração de sistemas de gerenciamento de banco
de dados relacional não-DB2 são os seguintes:
v O Web site de implementação do IBM DB2 pode ajudá-lo a localizar as
informações necessárias para implementar seu aplicativo e seus dados de outros
sistemas de gerenciamento de banco de dados. Esse Web site descreve as etapas
de migração comuns e fornece recursos, incluindo ferramentas e educação.
Recursos adicionais são fornecidos para clientes IBM e Parceiros de Negócios
IBM.
v O DB2 Enablement and Porting Workshop foi projetado para ISVs e Parceiros de
Negócios IBM que planejam vender ou implementar aplicativos em produtos do
bancos de dados DB2. Você pode levar seu aplicativo de banco de dados
existente ao workshop. Visite a página da Web do workshop para obter detalhes
e cronograma.
v O IBM VIC (Virtual Innovation Center) é um centro de conhecimento e ativação
on-line que fornece cursos educativos, acompanhamento ao vivo, suporte técnico
on-line, roteiros de soluções, simulações de clientes, respostas para Perguntas
Mais Freqüentes, casos de referência e fóruns de discussão.
v A oferta completa Migre o DB2 Agora! para Parceiros de Negócios IBM
estratégicos que inclui kits de ferramentas de migração, educação on-line
complementar, informações, equipes de vendas e outros recursos para auxiliá-lo
no planejamento e implementação de sua migração para os produtos DB2 a
partir do Oracle, Sybase e Microsoft SQL Server.
v O Web site developerWorks Information Management oferece recursos técnicos
para o software DB2 Information Management. Possui informações sobre
produtos, downloads, recursos de aprendizado, suporte e comunidades. Nesse
Web site, é possível localizar muitos artigos e tutoriais que podem ajudá-lo a
conhecer os recursos dos produtos do banco de dados DB2 e como utilizá-los em
seus aplicativos.
Conceitos Relacionados:
v “Bancos de Dados Relacionais” em SQL Reference, Volume 1
v “Migrando Ambientes com Características Específicas” na página 67
Capítulo 8. Migrando Ambientes com Características Específicas 85
86 Guia de Migração
Capítulo 9. Tarefas de Pós-migração
Este capítulo descreve as tarefas de pós-migração para servidores DB2. Ele contém
as seguintes seções:
v “Tarefas de Pós-migração para Servidores DB2”
v “Ajustando o Tamanho do Espaço de Registro em Bancos de Dados Migrados”
na página 89
v “Banco de Dados Ativado Após a Migração” na página 90
v “Alterações nas Variáveis de Registro do DB2, nos Parâmetros de Configuração e
nas Características de Design Físico do Banco de Dados” na página 91
v “Conversão dos Índices Tipo 1 em Bancos de Dados Migrados” na página 100
v “Alterações no Privilégio EXECUTE em PUBLIC para Rotinas Migradas” na
página 101
v “Religando Pacotes em Bancos de Dados Migrados” na página 102
v “Migrando Tabelas de Explicação” na página 103
v “Certificando-se de que os Tamanhos de Página dos Espaços de Tabelas
Temporários Atendem aos Requisitos” na página 104
v “Verificando a Migração dos Servidores DB2” na página 105
v “Inicialização de Replicação de HADR em Bancos de Dados Migrados” na
página 107
Tarefas de Pós-migração para Servidores DB2
Após migrar seus servidores DB2, você deve executar várias tarefas de
pós-migração para garantir que os servidores DB2 funcionem conforme esperado e
em seu melhor nível.
Execute as seguintes tarefas de pós-migração que se aplicam ao servidor DB2:
1. Se você configurar o parâmetro de configuração do gerenciador de banco de
dados diaglevel para 4 conforme recomendado nas tarefas de pré-migração
para servidores DB2, reconfigure esse parâmetro para o valor configurado
antes da migração.
2. Ajuste o tamanho do espaço de registro. Se você tiver alterado a configuração
do espaço de registro conforme recomendado nas tarefas de pré-migração
para servidores DB2, reconfigure os parâmetros de configuração de banco de
dados logfilsiz, logprimary, e logsecond para os valores anteriores à migração.
Certifique-se de que a quantidade de espaço de registro que você alocou seja
adequada para seu servidor DB2.
3. Ative seu banco de dados após a migração para inicializar seu banco de dados
e todos os serviços de banco de dados necessários.
4. Reveja as alterações nas variáveis de registro e nos parâmetros de
configuração do DB2. Existem novas variáveis de registro, novos parâmetros
de configuração e novos valores padrão para variáveis de registro e
parâmetros de configuração introduzidos no DB2 Versão 9 que podem afetar o
comportamento do seu aplicativo.Existem também alterações nas
características de design físico dos bancos de dados.
5. . As variáveis configuradas no nível de perfil global, utilizando o comando
db2set -g, não são migradas. As variáveis de perfil global aplicam-se a todas
© Direitos Autorais IBM Corp. 2006 87
as instâncias que pertencem a uma cópia específica do DB2 Versão 9. Portanto,
após a migração, utilize as informações de configuração que você salvou nas
tarefas de pré-migração para restaurar os valores das variáveis de registro de
perfil global para cada cópia do DB2 Versão 9.
6. Converta índices tipo 1 em índices tipo 2 nos bancos de dados migrados para
aproveitar os benefícios do índice tipo 2. Além disso, os índices tipo 1 estão
obsoletos no DB2 Versão 9, portanto, você deve convertê-los antes que eles
não sejam mais suportados.
7. Se você estiver utilizando extensões de índice ou índices espaciais e tiver
migrado de uma instância do DB2 UDB Versão 8 de 32 bits para uma
instância do DB2 Versão 9 de 64 bits, será necessário recriar suas extensões de
índice ou índices especiais. Se você for um usuário do Spatial Extender, leia
novamente a tarefa Migrando o Ambiente Spatial Extender, para obter
detalhes sobre como recriar seus índices especiais. O DB2 Spatial Extender and
Geodetic Extender User’s Guide and Reference está disponível clicando no
link de biblioteca na página da Web do DB2 Spatial Extender.
8. Revogue o privilégio EXECUTE de PUBLIC em funções e procedimentos para
manter o acesso seguro ao banco de dados.
9. Religue os pacotes nos bancos de dados migrados para validar pacotes e para
utilizar estatísticas atualizadas ou informações sobre o novo índice.
10. Migre as tabelas de explicação do DB2, caso precise reter informações da
tabela de explicação que foram reunidas anteriormente.
11. Certifique-se de atender aos requisitos de tamanhos de página de espaços de
tabelas temporários do sistema para acomodar o maior tamanho de linha nos
conjuntos de resultados de consultas ou atualizações posicionadas e crie um
espaço de tabelas temporário do sistema com um tamanho de página maior se
for necessário.
12. Se você obteve tabelas de conversão de página de códigos customizadas do
serviço de suporte do DB2, copie todos os arquivos para essas tabelas do
DB2OLD/conv no DB2DIR/conv, em que DB2OLD é o local da sua cópia do DB2
UDB Versão 8 e DB2DIR é o local da sua cópia do DB2 Versão 9. Não é
necessário copiar as tabelas de conversão de páginas de códigos padrão.
Se você migrou sua cópia existente do DB2 UDB Versão 8 nos sistemas
operacionais Windows, é possível restaurar as tabelas de conversão de página
de códigos customizadas, das quais foi feito backup, como parte das tarefas de
pré-migração para servidores DB2 para o diretório DB2PATH\conv, em que
DB2PATH é o local da cópia do DB2 Versão 9.
13. Verifique se a migração do servidor DB2 foi bem-sucedida. Teste seus
aplicativos e ferramentas para garantir que o servidor DB2 esteja trabalhando
de forma esperada.
14. Faça backup de seus bancos de dados após a migração ser concluída.
15. Se você migrar um servidor DB2 executando replicação HADR (recuperação
de desastre de alta disponibilidade), inicialize a replicação HADR.
16. Se o Query Patroller estiver instalado, configure o parâmetro de banco de
dados dyn_query_mgmt como ENABLE após concluir a migração para que o
Query Patroller intercepte e capture informações sobre suas consultas. A
ativação desse parâmetro é especificada como uma etapa de pós-instalação na
tarefa Verificando a Instalação do Servidor Query Patroller.
Quando o desempenho do servidor DB2 estiver estável, aproveite os
aprimoramentos do otimizador e colete estatísticas para novos recursos atualize
estatísticas para seus bancos de dados migrados. Durante a migração do banco de
dados para o DB2 Versão 9, as estatísticas coletadas das tabelas de catálogo do
88 Guia de Migração
banco de dados existentes retêm seus valores. As estatísticas para as novas
características nas tabelas e nos índices têm um valor de -1 para indicar que não há
nenhuma informação reunida. No entanto, você precisará dessas estatísticas
somente se estiver utilizando nova funcionalidade.
Após atualizar estatísticas para seus bancos de dados migrados, determine se a
reorganização do índice ou da tabela é necessária executando o comando
REORGCHK. A reorganização da tabela e do índice pode ajudar a aprimorar o
desempenho.
Nesse ponto, você deve retomar todas as atividades de manutenção, tais como
fazer backup dos bancos de dados e atualizar estatísticas. Você também deve
remover qualquer cópia do DB2 UDB Versão 8 que não seja mais necessária.
Conceitos Relacionados:
v “Diretrizes para Coleta e Atualização de Estatísticas” em Performance Guide
v “Migrando Ambientes com Características Específicas” na página 67
v “Princípios de Migração para Servidores DB2” na página 19
Tarefas Relacionadas:
v “Migrando um Servidor DB2 (Linux e UNIX)” na página 59
v “Migrando um Servidor DB2 (Windows)” na página 51
Ajustando o Tamanho do Espaço de Registro em Bancos de Dados
Migrados
É necessário configurar o tamanho apropriado para arquivos de registro, visto que
esse é um dos fatores importantes para ajustar o servidor DB2. Além disso, se você
aumentou os tamanhos dos arquivos de registro como uma tarefa de pré-migração,
é possível restaurar espaço livre adicional para o servidor DB2.
Pré-requisito:
Você deve ter autoridade SYSCTRL ou SYSADM para poder aumentar o tamanho
dos espaços de tabela e do espaço de registro.
Restrições:
Em um ambiente da banco de dados particionado, você precisa somente ajustar o
tamanho do espaço de registro no servidor de partição de banco de dados do
catálogo.
Procedimento:
1. Conecte ao banco de dados que você migrou:
db2 CONNECT TO sample
em que sample é o nome do banco de dados.
2. Restaure as configurações do tamanho do arquivo de registro para os valores
anteriores à migração:
db2 UPDATE DB CFG FOR sample using LOGPRIMARY previous-value
db2 UPDATE DB CFG FOR sample using LOGSECOND previous-value
Capítulo 9. Tarefas de Pós-migração 89
em que previous-value é a configuração salva antes da migração e sample é o
nome do banco de dados. Na tarefa de pré-migração, somente os parâmetros
logprimary e logsecond foram alterados. Caso altere a configuração do parâmetro
logfilsiz, você deve restaurar o valor anterior.
Se você ativou o registro ativo infinito, desative-o executando os seguintes
comandos:
db2 UPDATE DB CFG FOR sample using LOGARCHMETH1 previous-value
db2 UPDATE DB CFG FOR sample using LOGSECOND previous-value
em que previous-value é a configuração salva antes da migração e sample é o
nome do banco de dados.
3. Opcional: Aumente as configurações de tamanho de seu arquivo de registro. O
RID para os registros do registro aumentou em 2 bytes, dependendo do tipo de
registro do registro, isso pode representar um aumento de menos de 2% no
tamanho do registro do registro.
Em geral, sua configuração atual para o espaço de registro deve ser suficiente
para acomodar essa alteração. No entanto, se você tiver uma preocupação de
que a configuração do espaço de registro tem um tamanho menor do que o
necessário, monitore o uso do espaço de registro para saber o tamanho
apropriado. O exemplo a seguir aumenta o tamanho do arquivo de registro em
5% para acomodar o aumento de tamanho do registro de log:
db2 UPDATE DB CFG FOR sample using LOGFILSIZ previous-value*1.05
em que previous-value é a configuração salva antes da migração e sample é o
nome do banco de dados.
Conceitos Relacionados:
v “O que Há de Novo na V9.1: Aumento nos Requisitos de Registro, Espaço de
Tabela e de Memória Devido a Maiores RIDs (Record Identifiers)” em O que Há
de Novo
v “Requisitos de Espaço para Arquivos do Log” em Administration Guide: Planning
Referência Relacionada:
v “Registros de Log do DB2” em Administrative API Reference
v “Comando UPDATE DATABASE CONFIGURATION” em Command Reference
v “Parâmetros de Configuração para Registro do Banco de Dados” em Data
Recovery and High Availability Guide and Reference
v “Tarefas de Pós-migração para Servidores DB2” na página 87
Banco de Dados Ativado Após a Migração
Inicialize seu banco de dados e todos os serviços de banco de dados necessários
com o comando ACTIVATE DATABASE. Após a execução desse comando, seu
banco de dados estará disponível para conexões. No DB2 Versão 9, os arquivos do
diretório de banco de dados foram modificados para incluir informações adicionais
para novos recursos, como memória de auto-ajuste. Devido a essas modificações,
assegure que os conjuntos de buffers estejam ativados sem qualquer problema,
ativando seu banco de dados.
Você pode verificar se todos os serviços de banco de dados estão em execução de
forma apropriada e se todos os conjuntos de buffers estão ativos e abordar
quaisquer problemas que possam ocorrer durante a ativação do banco de dados.
90 Guia de Migração
Você também pode eliminar o código extra nos clientes DB2 que precisam esperar
até que o gerenciador de banco de dados inicialize o banco de dados para obter
uma conexão com esse banco de dados.
O exemplo a seguir ilustra a utilização desse comando para ativar o banco de
dados de amostra:
db2 ACTIVATE DATABASE sample
Lembre-se de que, um banco de dados ativado pelo comando ACTIVATE
DATABASE, é parado somente quando você emite o comando DEACTIVATE
DATABASE ou o comando db2stop. Se o banco de dados estiver ativado quando a
primeira conexão for estabelecida, então, o banco de dados é parado quando a
última conexão é fechada.
Conceitos Relacionados:
v “Dicas de início rápido para ajuste de Desempenho” em Performance Guide
Referência Relacionada:
v “Comando ACTIVATE DATABASE” em Command Reference
v “Tarefas de Pós-migração para Servidores DB2” na página 87
Alterações nas Variáveis de Registro do DB2, nos Parâmetros de
Configuração e nas Características de Design Físico do Banco de
Dados
No DB2 Versão 9, existem novas variáveis de registro, novos parâmetros de
configuração e novos valores padrão para variáveis de registro e parâmetros de
configuração, variáveis obsoletas e descontinuadas, parâmetros de configuração
obsoletos do gerenciador de banco de dados e parâmetros de configuração
descontinuados do banco de dados. Existem também características de design físico
de bancos de dados que foram alteradas e que podem afetar a migração.
Como uma regra geral, as variáveis de perfil de instância que você configurou no
registro de perfil do DB2 ou no seu ambiente do sistema retêm os valores após a
migração da instância. Algumas variáveis de registro de perfil globais são
configuradas pelo procedimento de instalação do DB2, tal como o DB2SYSTEM e
DB2PATH. No entanto, as variáveis de registro de perfil globais que você
configurou executando o comando db2set -g não são migradas. É necessário
defini-las após a migração.
Parâmetros de configuração existentes do banco de dados e do gerenciador de
banco de dados também retém seus valores após a migração. No entanto, para
novos parâmetros de configuração, o valor padrão designado pode afetar o
comportamento ou o desempenho do aplicativo.
Após a migração do servidor DB2, compare os valores das variáveis de registro e
dos parâmetros de configuração com os valores anteriores à migração. Se encontrar
alguma diferença, separe algum tempo para rever essas alterações, pois elas podem
alterar o comportamento ou o desempenho de seu aplicativo. No entanto,
considere cuidadosamente se algum novo recurso deve ser desativado por fornecer
alterações para os novos recursos necessários para o gerenciador de banco de
dados. Você deve desativar novos recursos somente no caso de um desempenho
negativo.
Capítulo 9. Tarefas de Pós-migração 91
As seções a seguir descrevem detalhadamente todas as alterações em variáveis,
parâmetros de configuração de banco de dados e de gerenciador de banco de
dados e características de design físico de bancos de dados:
v “Novas Variáveis de Registro”
v “Alterações em variáveis de registro existentes” na página 93
v “Variáveis Obsoletas e Descontinuadas” na página 94
v “Novos Parâmetros de Configuração do Gerenciador de Banco de Dados” na
página 94
v “Alterações de Parâmetros de Configuração Existentes do Gerenciador de Banco
de Dados” na página 95
v “Parâmetros de Configuração Obsoletos do Gerenciador de Banco de Dados” na
página 95
v “Novos Parâmetros de Configuração do Banco de Dados” na página 96
v “Alterações de Parâmetros de Configuração Existentes do Banco de Dados” na
página 96
v “Parâmetros Descontinuados da Configuração do Banco de Dados” na página 98
v “Alterações nas Características de Design Físico dos Bancos de Dados” na
página 98
Novas Variáveis de Registro
DB2_COPY_NAME (Windows)
Essa variável armazena o nome da cópia do DB2 atualmente em
utilização. O valor padrão é o nome da cópia padrão do DB2 em
sua máquina. Se for necessário alternar para uma cópia diferente
do DB2, execute o comando INSTALLPATH\bin\db2envars.bat para
alterar a cópia atualmente em utilização.
DB2_ENABLE_AUTOCONFIG_DEFAULT
Se você configurou o valor dessa variável dinâmica como YES, o
Configuration Advisor será executado automaticamente quando
você criar um banco de dados. Por padrão, essa variável não é
configurada e isso tem o mesmo efeito que configurar a variável
como YES. Configure essa variável como NO se não quiser
executar o Orientador de Configuração na criação do banco de
dados, o mesmo comportamento que no DB2 UDB Versão 8:
db2set DB2_ENABLE_AUTOCONFIG_DEFAULT = NO
Como alternativa, você pode optar explicitamente por não executar
o Orientador de Configuração ao utilizar o comando CREATE
DATABASE da seguinte forma:
db2 CREATE DB AUTOCONFIGURE APPLY NONE
Este recurso de computação autônoma aprimora significativamente
o desempenho de bancos de dados recém-criados ao mesmo tempo
que causa pouco código extra no sistema. Portanto, considere
cuidadosamente o impacto antes de decidir desativar esse recurso.
Reveja também as referências de parâmetro de configuração de
banco de dados self_tuning_mem e auto_runstats porque seus valores
padrão foram alterados.
DB2_MAX_LOB_BLOCK_SIZE
Essa variável de registro configura a quantidade máxima de dados
LOB ou XML a ser retornada em um bloco. Não é um limite
92 Guia de Migração
máximo rígido; se esse valor máximo for atingido no servidor
durante a recuperação de dados, o servidor termina de gravar a
linha atual antes de gerar uma resposta para o comando, como
FETCH, para o cliente. O valor padrão é 0 (sem limite).
DB2_OPT_MAX_TEMP_SIZE
Utilize essa variável para limitar a quantidade de espaço que as
consultas podem utilizar nos espaços de tabelas temporários.
Quando você migra um banco de dados, essa variável é
configurada como o valor padrão null, que indica sem limite. Se
você configurar essa variável, o otimizador poderá escolher um
plano mais caro para utilizar menos espaço nos espaços de tabelas
temporários, conforme mostrado no exemplo a seguir:
db2set DB2_OPT_MAX_TEMP_SIZE=10240 (size in MB)
DB2RCMD_LEGACY_MODE (Windows)
Quando essa variável é configurada como NO, OFF, FALSE, 0 ou
null (padrão), ela permite que o Serviço de Comando Remoto do
DB2 seja executado em um modo seguro, que estará disponível
somente se seu controlador de domínio estiver executando o
Windows 2000 ou posterior. Para executar sem segurança
aprimorada, configure DB2RCMD_LEGACY_MODE para YES, ON,
TRUE ou 1.
db2set DB2RCMD_LEGACY_MODE=YES
Alterações das Variáveis de Registro Existentes
DB2_LARGE_PAGE_MEM
Utilize esta variável para ativar o suporte à página grande,
aumentando assim o uso de memória do DB2. Ative o suporte à
página grande quando a região de memória compartilhada de seu
banco de dados for extremamente grande, quando houver uma
carga de trabalho fixa ou quando estiver configurando
configurações de avaliação de desempenho.
No DB2 Versão 9 em um sistema operacional AIX de 64 bits, se
você configurar essa variável como DB, não será possível ativar o
auto-ajuste de memória compartilhada do banco de dados
configurando o parâmetro de configuração database_memory como
AUTOMATIC.
DB2_MEM_TUNING_RANGE (AIX e Windows)
Essa variável de registro indica uma seqüência de porcentagens
para indicar as quantidades mínima (minfree) e máxima (maxfree)
de memória física que a instância do DB2 deixa livre, dependendo
da necessidade de memória para a instância, caso o auto-ajuste de
memória compartilhada do banco de dados esteja ativado. Por
padrão, essa variável não é configurada e o gerenciador de banco
de dados calculará os valores para minfree e maxfree com base na
quantidade de memória no servidor.
Você não deve configurar essa variável, a menos que esteja
executando o STMM (self-tuning memory manager), que tenha
configurado database_memory como AUTOMATIC e que esteja
enfrentando problemas relacionados a uma quantidade insuficiente
de memória física livre.
DB2_PINNED_BP (AIX, HP-UX, Linux)
Capítulo 9. Tarefas de Pós-migração 93
Essa variável é utilizada para especificar a memória global do
banco de dados (incluindo conjuntos de buffers) associados ao
banco de dados na memória principal. Essa configuração limita a
capacidade de aumentar de forma dinâmica a configuração geral
da memória compartilhada do banco de dados.
No DB2 Versão 9 no sistema operacional AIX, se você configurou
essa variável como ″YES″, o auto-ajuste para memória
compartilhada do banco de dados não poderá ser ativado
configurando o parâmetro de configuração database_memory como
AUTOMATIC. No DB2 Versão 9, essa variável também se aplica a
sistemas operacionais Linux. Além da configuração dessa variável
de registro como YES, a biblioteca libcap.so.1 também é requerida.
Variáveis Obsoletas de Descontinuadas
DB2_FORCE_FCM_BP (AIX)
A variável DB2_FORCE_FCM_BP está obsoleta no DB2 Versão 9
porque somente kernels de 64 bits de sistemas operacionais AIX
são suportados e não têm restrições de tamanho de segmento de
memória compartilhada. O padrão é ativar comunicações de
memória compartilhada entre nós lógicos para aprimorar o
desempenho e também para fornecer consistência com outras
plataformas.
Após a migração para o DB2 Versão 9, se essa variável estiver
configurada como NO e você não precisar utilizar comunicações de
soquete de domínio em vez de memória compartilhada, será
necessário configurá-la como YES executando o seguinte comando:
db2set DB2_FORCE_FCM_BP=YES
DB2_LGPAGE_BP
Essa variável de registro está obsoleta e poderá ser removida em
um futuro release. Ela foi substituída pela variável de registro
DB2_LARGE_PAGE_MEM. O equivalente a configurar
DB2_LGPAGE_BP para ON é configurar DB2_LARGE_PAGE_MEM
para DB:
db2set DB2_LARGE_PAGE_MEM=DB
DB2LINUXAIO
Essa variável está obsoleta e poderá ser removida em um futuro
release. Essa variável permite ativar o suporte a AIO (E/S
Assíncronas) no Linux. Em futuros releases, você não precisará
ativar esse recurso utilizando essa variável.
DB2_SCATTERED_IO
Essa variável não é mais suportada. Antes do DB2 Versão 9, se
você estava executando em um sistema que continha a correção do
kernel Linux de aprimoramento de desempenho de E/S bruta com
vetores, a configuração do valor dessa variável como ON permitia
que você aumentasse o desempenho ativando a E/S de dispersão.
No DB2 Versão 9, a variável não é mais requerida porque a E/S de
dispersão está sempre ativada.
Novos Parâmetros de Configuração do Gerenciador de Banco de Dados
fcm_num_channels
94 Guia de Migração
Um canal FCM (Fast Communication Manager) é utilizado para
transferir dados entre partições. Esse parâmetro especifica o
número de canais FCM para cada partição de banco de dados. O
comportamento do parâmetro fcm_num_channels é modelado após o
parâmetro fcm_num_rqb obsoleto e representa uma combinação
desse parâmetro com os parâmetros fcm_num_anchors e
fcm_num_connect, que também estão obsoletos.
Durante a migração, o valor do parâmetro fcm_num_channels é
calculado como o máximo dos valores dos parâmetros
fcm_num_rqb, fcm_num_anchors e fcm_num_connect para obter a
maior aproximação com a configuração do DB2 UDB Versão 8.
Alterações de Parâmetros de Configuração Existentes do Gerenciador de Banco
de Dados
fcm_num_buffers
Agora você pode configurar o parâmetro fcm_num_buffers como
AUTOMATIC, que é o valor padrão no DB2 Versão 9. Se isso for
feito, o FCM monitora o uso do recurso e libera recursos de forma
incremental se eles não forem utilizados dentro de 30 minutos. Se o
gerenciador de banco de dados não puder alocar o número de
recursos especificado quando uma instância for iniciada, ele
escalará de volta os valores de configuração de forma incremental
até que possa iniciar a instância.
Como o parâmetro fcm_num_buffers representa um valor para cada
partição no DB2 Versão 9 mas representava um valor
compartilhado entre todas as partições lógicas no DB2 UDB Versão
8, durante a migração, um novo valor é calculado através da
divisão do valor existente pelo número de partições para deixar
inalterado o número real de recursos alocados. Se a variável
DB2_FORCE_FCM_BP não for configurada ou se for configurada
como NO nos sistemas operacionais AIX, o valor do parâmetro
fcm_num_buffers continuará inalterado, independentemente do
número de partições de banco de dados, pois, nesse caso, ele
representa um valor para cada partição.
Considere configurar esse parâmetro como AUTOMATIC para tirar
proveito de um ajuste mais otimizado alavancando as
configurações autônomas que se adaptam a cargas de trabalho em
alteração. Além disso, essa configuração permite liberar recursos e
aumentar a memória disponível para o processamento de banco de
dados.
db2 UPDATE DATABASE MANAGER CONFIGURATION
USING fcm_num_buffers AUTOMATIC
Parâmetros de Configuração Obsoletos do Gerenciador de Banco de Dados
fcm_num_anchors, fcm_num_connect e fcm_num_rqb
Esses parâmetros estão obsoletos no DB2 Versão 9. Por questão de
compatibilidade, você ainda pode atualizar esses parâmetros
utilizando o comando UPDATE DATABASE CONFIGURATION,
portanto, quaisquer scripts de comando do CLP existentes do DB2
continuam a ser executados.
min_priv_mem e priv_mem_thresh
Capítulo 9. Tarefas de Pós-migração 95
Esses parâmetros estão obsoletos no DB2 Versão 9. Se você
configurar um valor para cada um desses parâmetros de
configuração, os valores serão ignorados. Utilize a variável de
registro DB2MEMMAXFREE em vez de especificar o número
máximo de bytes da memória privada não utilizada que é retido
pelos processos do sistema de banco de dados DB2 antes que a
memória não utilizada seja retornada para o sistema operacional.
Novos Parâmetros de Configuração do Banco de Dados
self_tuning_mem
Esse parâmetro é uma chave master para ativar ou desativar o
auto-ajuste de memória em um banco de dados. Quando a chave é
configurada como OFF, não ocorre nenhum auto-ajuste. Se a chave
for configurada como ON, o auto-ajuste poderá ocorrer
potencialmente se você configurar como AUTOMATIC quaisquer
parâmetros de configuração de banco de dados correspondentes,
tais como database_memory, sheapthres_shr, sortheap, pckcachesz, e
locklist.
Por padrão, o parâmetro self_tuning_mem é configurado como ON
para bancos de dados recém-criados. Quando você migra um
banco de dados para o DB2 Versão 9, esse parâmetro é configurado
como OFF. Você deve considerar a ativação desse recurso
autonômico para obter os benefícios de desempenho e
gerenciabilidade que ele fornece. Para ativar o auto-ajuste em seus
bancos de dados migrados, configure manualmente esse parâmetro
como ON:
db2 UPDATE DB CFG FOR database-name USING self_tuning_mem ON
Se ativar o auto-ajuste em seus bancos de dados migrados, você
deve estar ciente de que o ajustador de memória deve consumir
recursos adicionais para que seja executado automaticamente.
Talvez você precise aumentar o valor dos parâmetros maxappls e
max_connections em 2 para incluir os processos do ajustador de
memória se o número máximo de aplicativos ou o número de
aplicativos ativos estiver próximo do limite.
Alterações de Parâmetros de Configuração Existentes do Banco de Dados
auto_runstats
Esse parâmetro permite a coleta de estatísticas automatizada que
fornece ao otimizador as informações mais atualizadas para
determinar o plano mais eficiente para acessar seus dados. Esse
recurso de computação autônoma agora fica ativado por padrão no
DB2 Versão 9 em bancos de dados recém-criados.
Quando você migra seu banco de dados, esse parâmetro retém seu
valor anterior. Se esse valor for configurado como OFF, você deve
considerar a ativação desse recurso para aprimorar o desempenho.
Para ativar a coleta de estatísticas automatizada, configure esse
parâmetro como ON utilizando o seguinte comando:
db2 UPDATE DB CFG FOR database-name
USING auto_runstats ON auto_tbl_maint ON auto_maint ON
Você pode desativar esse recurso após criar um banco de dados
utilizando o seguinte comando:
db2 UPDATE DATABASE CONFIGURATION USING auto_runstats OFF
96 Guia de Migração
avg_appls
Esse parâmetro é utilizado pelo otimizador de SQL para ajudar a
estimar quanto do conjunto de buffer estará disponível no tempo
de execução para o plano de acesso escolhido. Por padrão, esse
parâmetro é configurado como AUTOMATIC para bancos de
dados que foram criados no IBM DB2 Versão 9, o que significa que
o otimizador determina o valor do parâmetro avg_appls.
Quando você migra seu banco de dados, esse parâmetro retém seu
valor anterior. Em um ambiente multiusuário, é muito importante
configurar esse parâmetro para o número estimado de aplicativos
de consulta complexa que geralmente são executados contra o
banco de dados.
database_memory
O valor COMPUTED é novo para esse parâmetro no DB2 Versão 9
e indica que o gerenciador de banco de dados calcula um valor
para esse parâmetro com base em outros parâmetros de
configuração de memória de banco de dados. Esse comportamento
é o mesmo que foi obtido com a configuração de database_memory
como AUTOMATIC no DB2 UDB Versão 8. O valor AUTOMATIC
ativa o novo recurso de gerenciamento de memória de auto-ajuste
somente nos sistemas operacionais AIX e Windows.
Ao migrar seu banco de dados com o parâmetro database_memory
configurado para AUTOMATIC, durante a migração, esse
parâmetro é alterado para COMPUTED. Você deve reconfigurar
esse parâmetro como AUTOMATIC nos sistemas operacionais AIX
e Windows se quiser ativar o auto-ajuste de memória.
dyn_query_mgmt
Se o valor desse parâmetro for ENABLE, o comando MIGRATE
DATABASE o configurará como DISABLE. Após você migrar seu
banco de dados e instalar o Query Patroller Versão 9, é necessário
reconfigurar o parâmetro dyn_query_mgmt como ENABLE para que
o Query Patroller capture informações sobre suas consultas.
db2 UPDATE DB CFG FOR database-name USING DYN_QUERY_MGMT ENABLE
Detalhes sobre quando ativar esse parâmetro estão disponíveis na
tarefa Verificando a Instalação do Query Patroller.
num_iocleaners e num_ioservers
Você sempre deve ajustar esses parâmetros. No entanto, é possível
especificar o novo valor padrão AUTOMATIC para calcular os
valores iniciais para esses parâmetros com base nas configurações
atuais do sistema.
Ao migrar seu banco de dados, esses parâmetros retém o mesmo
valor que eles tinham antes da migração do banco de dados. Se
quiser que o gerenciador de banco de dados calcule os valores
desses parâmetros, você precisará configurar manualmente esses
parâmetros como AUTOMATIC utilizando o seguinte comando:
db2 UPDATE DB CFG FOR database-name
USING NUM_IOCLEANERS AUTOMATIC
sheapthres_shr, sortheap, pckcachesz, locklist e maxlocks
Capítulo 9. Tarefas de Pós-migração 97
O novo valor AUTOMATIC para esses parâmetros ativa o
auto-ajuste de memória, contanto que o valor do parâmetro
self_tuning_mem seja ON. Outras condições se aplicam, dependendo
do parâmetro de configuração. Você pode localizar mais detalhes
na tarefa Ativando o Auto-ajuste de Memória.
Ao migrar seu banco de dados, esses parâmetros retém o mesmo
valor que eles tinham antes da migração do banco de dados. Caso
queira ativar o auto-ajuste para esses parâmetros, você precisa
configurá-los manualmente como AUTOMATIC, conforme
mostrado no exemplo a seguir:
db2 UPDATE DB CFG FOR database-name USING SORTHEAP AUTOMATIC
db2 UPDATE DB CFG FOR database-name USING SELF_TUNING_MEMORY ON
Você deve considerar a configuração de todos esses parâmetros
como AUTOMATIC porque os requisitos de memória aumentaram
no DB2 Versão 9.
applheapsz e stmtheap
Desde o DB2 UDB Versão 8.1 FixPak 9, esses parâmetros têm
valores padrão diferentes para os bancos de dados criados sob
instâncias de 64 bits. Se estiver migrando para uma instância de 64
bits do DB2 Versão 9 a partir de uma instância de 32 bits do DB2
UDB Versão 8.2 FixPak 8 ou anterior, talvez você precise aumentar
os valores desses parâmetros quando os valores forem menores do
que os padrões. O exemplo a seguir mostra como configurar esses
parâmetros como os valores padrão para um ambiente de banco de
dados de partição única:
db2 UPDATE DB CFG FOR database-name USING STMTHEAP 4096
db2 UPDATE DB CFG FOR database-name USING APPLHEAPSZ 256
Parâmetros Descontinuados da Configuração do Banco de Dados
estore_seg_sz e num_estore_segs
Esses parâmetros não estão mais disponíveis porque o
armazenamento estendido não é mais suportado. Essa alteração
afeta somente sistemas operacionais Windows de 32 bits, nos quais
você pode alocar conjuntos de buffers AWE (Address Windowing
Extensions) utilizando a variável de registro DB2_AWE em vez de
armazenamento estendido. Nos sistemas operacionais de 64 bits, o
armazenamento estendido não é necessário.
Alterações nas Características de Design Físico dos Bancos de Dados
Configurações OVERHEAD e TRANSFERRATE para Espaços de Tabelas
O valor padrão para OVERHEAD foi alterado de 12,67 ms para 7,5
ms e o valor padrão para TRANSFERRATE foi alterado de 0,18 ms
para 0,06 ms. Esses novos valores foram obtidos através da média
dos valores calculados para novos discos no mercado utilizando as
fórmulas descritas nos conceitos Impacto do Espaço de Tabelas na
Otimização de Consulta. Os novos valores padrão aplicam-se
somente aos bancos de dados criados no DB2 Versão 9.
Quando você migra seu banco de dados, OVERHEAD e
TRANSFERRATE retêm seus valores anteriores. Se você optar por
utilizar os novos valores padrão para seu banco de dados migrado,
lembre-se de alterar os valores para esses parâmetros em todos os
espaços de tabelas:
98 Guia de Migração
db2 ALTER TABLESPACE tablespace-name OVERHEAD 7.5
TRANSFERRATE 0.06
Você deve executar o utilitário RUNSTATS após alterar esses
valores para atualizar os planos de execução de consulta.
Memória de auto-ajuste do conjunto de buffers
Você pode ativar o auto-ajuste de memória em conjuntos de buffers
novos ou existentes configurando o tamanho do conjunto de buffer
como AUTOMATIC utilizando as instruções CREATE
BUFFERPOOL ou ALTER BUFFERPOOL.
db2 CREATE BUFFERPOOL bp1 SIZE AUTOMATIC PAGESIZE 8K
db2 ALTER BUFFERPOOL bp2 SIZE AUTOMATIC
Lembre-se de que você deve configurar o parâmetro
self_tuning_mem como ON e de que deve ativar pelo menos mais
um consumidor de memória para ativar o ajustador de memória,
além do auto-ajuste do conjunto de buffers.
Armazenamento automático ativado como padrão em CREATE
DATABASE
Quando você cria um banco de dados no DB2 Versão 9, o
armazenamento automático é ativado por padrão. Os bancos de
dados que são ativados para armazenamento automático têm um
conjunto de um ou mais caminhos de armazenamento e o
gerenciador de banco de dados designa contêineres nesses
caminhos de armazenamento para espaços de tabelas que são
definidos para utilizar o armazenamento automático.
Ao migrar seu banco de dados, o armazenamento automático
continua inalterado. Você pode ativar o armazenamento automático
somente quando criar primeiro um banco de dados e não puder
desativá-lo após criar um banco de dados de armazenamento
automático. É necessário especificar AUTOMATIC STORAGE NO
no comando CREATE DATABASE para ter o mesmo padrão que
no DB2 UDB Versão 8:
db2 CREATE DATABASE database-name AUTOMATIC STORAGE NO
A finalidade dessa alteração é fornecer uma vantagem de
desempenho para o banco de dados recém-criado simplificando o
gerenciamento de armazenamento.
Conceitos Relacionados:
v “Variáveis de Registro e de Ambiente do DB2” em Performance Guide
v “Sobre Manutenção Automática” em Administration Guide: Planning
v “Coleta de Estatísticas Automática” em Performance Guide
Tarefas Relacionadas:
v “Salvando Informações de Configuração” na página 39
v “Configurando DB2 com Parâmetros de Configuração” em Performance Guide
v “Declarando, Mostrando, Alterando, Reconfigurando e Excluindo Registro e
Variáveis de Ambiente” em Administration Guide: Implementation
Referência Relacionada:
v “Tarefas de Pós-migração para Servidores DB2” na página 87
Capítulo 9. Tarefas de Pós-migração 99
v “auto_maint - Parâmetro de Configuração de Manutenção Automática” em
Performance Guide
v “Comando AUTOCONFIGURE” em Command Reference
v “Resumo dos Parâmetros de Configuração” em Performance Guide
v “Comando UPDATE DATABASE CONFIGURATION” em Command Reference
v “self_tuning_mem- Parâmetro de Configuração de Memória Auto-ajustável” em
Performance Guide
v “Comando UPDATE DATABASE MANAGER CONFIGURATION” em Command
Reference
v “Instrução CREATE BUFFERPOOL” em SQL Reference, Volume 2
v “Instrução ALTER BUFFERPOOL” em SQL Reference, Volume 2
v “Instrução ALTER TABLESPACE” em SQL Reference, Volume 2
Conversão dos Índices Tipo 1 em Bancos de Dados Migrados
Você deve considerar a conversão de índices tipo 1 existentes em índices tipo 2
após a migração para aprimorar o desempenho e utilizar recursos de manutenção
automáticos.
Todos os novos índices criados no DB2 Versão 9 são índices tipo 2, exceto quando
você cria um índice em uma tabela que já teve índices tipo 1, em cujo caso o novo
índice também é tipo 1. Você pode ter índices tipo 1 somente em bancos de dados
que você migrou para o DB2 Versão 9 que foram criados no DB2 UDB Versão 7 ou
anterior.
As vantagens dos índices tipo 2 são aprimorar a simultaneidade, porque a
utilização de bloqueio da próxima chave é reduzido para um mínimo, e utilizar
colunas com comprimento maior do que 255 bytes como parte da chave de índice.
Uma tabela deve ter somente índices tipo 2 antes dos comando online table
REORG e online table LOAD poderem ser utilizados contra a tabela. Essa restrição
também se aplica ao DB2 Versão 9, além de outras restrições, como a
impossibilidade de incluir colunas do tipo XML em uma tabela com índices tipo 1.
Você pode converter facilmente seus índices utilizando o comando REORG
INDEXES/TABLE:
db2 REORG INDEXES ALL FOR TABLE employee CONVERT
Se você planeja reorganizar seus índices, é uma excelente oportunidade incluir a
opção de conversão, pois essa opção converte seus índices tipo 1 e não tem
nenhum efeito em seus índices tipo 2.
Se quiser verificar se você tem índices tipo 1, você pode utilizar a ferramenta de
inspeção:
db2 INSPECT CHECK DATABASE RESULTS KEEP sample.log
db2inspf $INSTHOME/sqllib/db2dump/sample.log sample.out
A saída formatada a partir do comando db2inspf no arquivo sample.out mostra o
tipo de índice para cada tabela:
...
Início da fase da tabela (ID Assinado: 83, Não Assinado: 83;
ID do Espaço de Tabelas: 0) :
Início da fase de dados. Objeto: 83 Espaço de tabelas: 0
O tipo de índice é 2 para esta tabela.
100 Guia de Migração
Resumo do Objeto DAT: Total de Páginas 1 - Páginas Utilizadas
0 - Espaço Livre 70 %
Encerramento da fase de dados.
Início da fase do índice. Objeto: 83 Espaço de tabelas: 0
Resumo do Objeto INX: Total de Páginas 3 - Páginas Utilizadas 3
Encerramento da fase do índice.Encerramento da fase da tabela. ...
Outra vantagem da conversão para índices tipo 2 utilizando o comando REORG
INDEXES/TABLE é que você também converterá índices exclusivos criados em seu
banco de dados antes do DB2 UDB Versão 5. Alternativamente, se você não estiver
convertendo os índices do tipo 1 com esse comando, será necessário executar o
comando db2uiddl para gerar as instruções CREATE UNIQUE INDEX em um
script. Conforme lhe convir, você pode executar esse script para converter esses
índices exclusivos para semânticas do DB2 Versão 9.
Conceitos Relacionados:
v “Estrutura de Índice” em Performance Guide
Referência Relacionada:
v “db2uiddl - Comando para Preparar Conversão de Índice Exclusivo para
Semânticas da V5” em Command Reference
v “Comando INSPECT” em Command Reference
v “Comando REORG INDEXES/TABLE” em Command Reference
v “Tarefas de Pós-migração para Servidores DB2” na página 87
Alterações no Privilégio EXECUTE em PUBLIC para Rotinas Migradas
Durante a migração do banco de dados para o DB2 UDB Versão 8, o privilégio
EXECUTE foi concedido a PUBLIC para todas as funções, métodos e
procedimentos armazenados externos existentes. Se quiser revogar esse privilégio
de PUBLIC para todas essas rotinas, é possível executar o comando db2undgp
para revogar o privilégio EXECUTE em todas essas rotinas:
db2undgp -d sample -o revoke.db2
Neste exemplo, a opção -o cria um arquivo que contém todas as instruções
REVOKE para remover o privilégio EXECUTE de PUBLIC. É possível rever ou
editar esse arquivo para remover quaisquer instruções específicas quando você
deseja manter o privilégio EXECUTE concedido a PUBLIC para qualquer rotina.
Alternativamente, após executar o comando db2undgp, você pode conceder o
privilégio EXECUTE a um usuário específico ou PUBLIC em objetos de banco de
dados específicos utilizando as seguintes instruções:
db2 GRANT EXECUTE ON FUNCTION schema-name.* to PUBLIC or
db2 GRANT EXECUTE ON FUNCTION schema-name.* to USERID
Se você executou o comando db2undgp após migrar para o DB2 UDB Versão 8,
não é necessário executar esse comando novamente após o banco de dados ser
migrado para o DB2 Versão 9. No entanto, se não executou esse comando após
migrar para o DB2 UDB Versão 8, você deverá executá-lo após o banco de dados
ser migrado para o DB2 Versão 9. O suporte para o comando db2undgp será
removido em um futuro release.
Conceitos Relacionados:
v “Privilégios de Rotinas” em Administration Guide: Implementation
Tarefas Relacionadas:
Capítulo 9. Tarefas de Pós-migração 101
v “Revogando Privilégios” em Administration Guide: Implementation
Referência Relacionada:
v “db2undgp - Comando para Revogar Privilégio de Execução” em Command
Reference
v “GRANT (Routine Privileges) statement” em SQL Reference, Volume 2
v “Tarefas de Pós-migração para Servidores DB2” na página 87
v “Instrução REVOKE (Privilégios de Rotina)” em SQL Reference, Volume 2
Religando Pacotes em Bancos de Dados Migrados
Durante a migração do banco de dados, todos os pacotes para aplicativos de
usuários e rotinas são marcados como inválidos. É necessário religar os pacotes
invalidados para tirar proveito das alterações no servidor DB2 e das novas
estatísticas. Os pacotes também são colocados em um estado inválido se forem
dependentes de um objeto de banco de dados que você eliminou, tal como tabelas,
visualizações, aliases, índices, acionadores, restrições de referência e restrições de
verificação de tabela. Se você eliminar uma UDF, seu pacote será colocado em um
estado inoperante.
Os pacotes serão religados implicitamente na primeira vez que um aplicativo
utilizá-los após a migração do seu banco de dados. Para eliminar esse código extra,
você pode religar pacotes inválidos executando o comando REBIND ou o
comando db2rbind após o processo de migração ser concluído. Você deve religar
explicitamente os pacotes inoperantes.
Pré-requisito:
Certifique-se de que tenha autoridade SYSADM.
Restrições:
Esse procedimento aplica-se somente a aplicativos de banco de dados de SQL
incorporado programados em C, C++, COBOL, FORTRAN e REXX.
Procedimento:
Para religar pacotes em bancos de dados migrados:
1. Efetue logon como o proprietário da instância.
2. Religue todos os pacotes inválidos em cada banco de dados executando o
comando db2rbind:
db2rbind database–name -l logfile all -u userid -p password
A cláusula all religa pacotes válidos e inválidos.
3. Teste seus aplicativos
Verifique a migração do servidor DB2 foi bem-sucedida. Teste seus aplicativos e
ferramentas para garantir que o servidor funcione conforme o esperado.
O arquivo LEIA-ME, que encontra-se nos arquivos de instalação, contém detalhes
sobre a religação de pacotes específicos para um nível específico do DB2 Versão 9.
Conceitos Relacionados:
102 Guia de Migração
v “Religando Pacotes Existentes com o Comando REBIND” em Desenvolvendo
Aplicativos SQL Incorporados
v “Ligação” em Administration Guide: Planning
Tarefas Relacionadas:
v “Verificando a Migração dos Servidores DB2” na página 105
v “Migrando um Servidor DB2 (Linux e UNIX)” na página 59
v “Migrando um Servidor DB2 (Windows)” na página 51
Referência Relacionada:
v “db2rbind - Comando para Religar Todos os Pacotes” em Command Reference
v “Tarefas de Pós-migração para Servidores DB2” na página 87
v “Comando REBIND” em Command Reference
Migrando Tabelas de Explicação
O comando MIGRATE DATABASE não migra tabelas de explicação. Caso precise
manter as informações sobre a tabela de explicação reunidas anteriormente no DB2
UDB Versão 8, você precisará migrar suas tabelas de explicação para o DB2 Versão
9.
Você pode migrar manualmente suas tabelas de explicação após migrar seu banco
de dados ou pode recriar posteriormente as tabelas de explicação e reunir novas
informações.
Pré-requisito:
Certifique-se de ter autoridade SYSADM ou DBADM.
Procedimento:
Para migrar as tabelas Explain, utilize o comando db2exmig:
db2exmig -d dbname -e explain_schema [-u userid password]
em que:
v dbname representa o nome do banco de dados. Este parâmetro é necessário.
v explain_schema representa o nome de esquema das tabelas Explain a serem
migradas. Este parâmetro é necessário.
v userid e password representam a ID do usuário e a senha em vigor no momento.
São parâmetros opcionais.
As tabelas de explicação que pertencem ao ID do usuário que está executando o
db2exmig ou que é utilizado para conexão com o banco de dados são migradas. A
ferramenta de migração das tabelas de explicação renomeia as tabelas de
explicação existentes, cria um novo conjunto de tabelas utilizando EXPLAIN.DDL e
copia o conteúdo das tabelas de explicação existentes nas novas tabelas. Por fim,
ela elimina as tabelas de explicação existentes. O comando db2exmig preserva
quaisquer colunas incluídas por usuário nas tabelas de explicação.
Conceitos Relacionados:
v “Ferramentas de Explicação” em Performance Guide
v “As Tabelas de Explicação e Organização das Informações de Explicação” em
Performance Guide
Capítulo 9. Tarefas de Pós-migração 103
Tarefas Relacionadas:
v “Migrando um Servidor DB2 (Linux e UNIX)” na página 59
v “Migrando um Servidor DB2 (Windows)” na página 51
v “Migrando os Bancos de Dados” na página 56
Referência Relacionada:
v “db2exmig - Migrar Comando de Tabelas de Explicação” em Command Reference
v “Tarefas de Pós-migração para Servidores DB2” na página 87
Certificando-se de que os Tamanhos de Página dos Espaços de
Tabelas Temporários Atendem aos Requisitos
A utilização de um RID (Record Identifier) maior aumenta o tamanho da linha nos
conjuntos de resultados das consultas ou atualizações posicionadas. Se o tamanho
da linha nos conjuntos de resultados estiver próximo do limite de comprimento
máximo da linha para os espaços de tabela temporários existentes do sistema,
talvez você precise criar um espaço de tabelas temporário do sistema com um
tamanho de página maior.
Pré-requisitos:
Certifique-se de ter autoridade SYSCTRL ou SYSADM para criar um espaço de
tabelas temporário do sistema, caso seja necessário.
Procedimento:
Para garantir que o tamanho máximo da página do espaço de tabelas temporário
do sistema seja grande o suficiente para suas consultas ou atualizações
posicionadas:
1. Determine o tamanho máximo da linha dos conjuntos de resultados a partir de
consultas ou atualizações posicionadas. Monitore suas consultas ou calcule o
tamanho máximo da linha utilizando a instrução DDL que você utilizou para
criar suas tabelas.
2. Liste seus espaços de tabela utilizando o comando LIST TABLESPACES,
conforme mostrado no exemplo a seguir:
db2 LIST TABLESPACES SHOW DETAIL
...
ID do Espaço de Tabelas = 1
Nome = TEMPSPACE1
Tipo = Espaço gerenciado por sistema
Conteúdo = Dados temporários do sistema
Estado = 0x0000
Explicação detalhada: Normal
Total de páginas = 10
Páginas utilizáveis = 10
Páginas utilizadas = 10
Páginas livres = Não aplicável
Limite máximo (páginas) = Não aplicável
Tamanho da página (bytes) = 4096
Tamanho da extensão (páginas) = 32
Tamanho da pré-busca (páginas) = 320
Número de contêineres = 10
...
Você pode identificar os espaços de tabelas temporários do sistema na saída
procurando os espaços de tabelas cujos campos Conteúdo têm o valor de dados
104 Guia de Migração
Temporários do Sistema. Observe o tamanho da página para cada um dos
espaços de tabela temporários do sistema e o tamanho da página dos espaços
de tabela onde as tabelas referidas nas consultas ou atualizações foram criadas.
3. Verifique se o tamanho da linha maior nos conjuntos de resultados se ajusta ao
tamanho da página do espaço de tabela temporário do sistema:
maximum_row_size > maximum_row_length - 8 bytes (código extra da estrutura
em partição única)
maximum_row_size > maximum_row_length - 16 bytes (código extra da estrutura
em DPF)
em que maximum_row_size é o tamanho máximo da linha para os conjuntos
de resultados e maximum_row_length é o comprimento máximo permitido com
base no maior tamanho de página de todos os espaços de tabela temporários
do sistema. Reveja os Limites Específicos do Tamanho de Página do
Gerenciador de Banco de Dados para determinar o comprimento máximo da
linha por tamanho de página do espaço de tabela.
Se o tamanho máximo da linha for menor que o valor calculado, suas consultas
serão executadas da mesma maneira que no DB2 UDB Versão 8 e você não
precisa continuar com essa tarefa.
4. Crie um espaço de tabela temporário do sistema que seja pelo menos uma
página maior que o tamanho da página do espaço de tabelas onde as tabelas
foram criadas, caso ainda não tenha uma tabela temporária do sistema com
esse tamanho de página. Por exemplo, nos sistemas operacionais Windows, se
você criou sua tabela em um espaço de tabela com um tamanho de página de 4
KB, crie o espaço de tabelas adicional temporário do sistema utilizando um
tamanho de página de 8 KB:
db2 CREATE SYSTEM TEMPORARY TABLESPACE tmp_tbsp
PAGESIZE 8K
MANAGED BY SYSTEM
USING (’d:\tmp_tbsp’,’e:\tmp_tbsp’)
Se o tamanho da página do espaço de tabelas for de 32 KB, você pode reduzir
as informações que estão sendo selecionadas nas consultas ou pode dividir as
consultas para que elas se encaixem na página do espaço de tabelas temporário
do sistema. Por exemplo, em vez de selecionar todas as colunas de uma tabela,
você pode selecionar somente aquelas que são realmente necessárias ou pode
selecionar uma subcadeia de determinadas colunas para não exceder a
limitação de tamanho de página.
Referência Relacionada:
v “Limites de SQL e XQuery” em SQL Reference, Volume 1
v “Comando LIST TABLESPACES” em Command Reference
v “Instrução CREATE TABLESPACE” em SQL Reference, Volume 2
v “Tarefas de Pós-migração para Servidores DB2” na página 87
Verificando a Migração dos Servidores DB2
Quando a migração do servidor DB2 for concluída, uma boa medida é executar
alguns testes no novo ambiente migrado para verificar se o servidor DB2 está
funcionando conforme esperado. Esses testes podem consistir em programas em
batch que normalmente você executa no servidor DB2 ou em quaisquer programas
ou scripts que você executa para avaliação de desempenho.
Capítulo 9. Tarefas de Pós-migração 105
Se você tiver scripts de comando do DB2 com instruções SQL, pode utilizar o
comando da ferramenta de avaliação de desempenho db2batch para executar as
instruções nesses scripts e reunir detalhes e estatísticas de informações de
desempenho, como tempo de CPU e tempo decorrido. Essa ferramenta pode
funcionar em um banco de dados de partição única e em um banco de dados de
várias partições.
Pré-requisito:
Assegure que você tenha o mesmo nível de autoridade que é requerido para
executar as instruções SQL em seu script.
Procedimento:
Para verificar se a migração do servidor DB2 foi bem-sucedida:
1. Efetue logon como um usuário com o mesmo nível de autoridade que é
requerido para executar as instruções SQL no script.
2. Prepare um script com instruções SQL executadas freqüentemente. Se tiver
instalado os arquivos de amostra, você também pode executar qualquer um dos
scripts do CLP de amostra.
3. Execute seu script utilizando o comando db2batch. O exemplo a seguir mostra
como executar essa ferramenta com o script de amostra testdata.db2:
cd samplefile-dir-clp
db2batch -d sample -f testdata.db2 -o r 0 p 3
em que samplefile-dir-clp é DB2DIR/samples/clp no Linux e no UNIX e
DB2DIR\samples\clp no Windows, DB2DIR representa o local para sua cópia
do DB2 Versão 9, sample é o nome do banco de dados e a opção -o r 0 p3
indica a impressão de 0 linhas buscadas para a saída e para o tempo decorrido
do relatório, tempo de CPU e resumo das informações sobre monitoramento
para cada instrução no script testdata.db2.
O texto a seguir é uma extração da saída da tabela de resumo gerada pelo
comando do exemplo anterior:
Tabela de Resumo:
Tipo Número Tempo Tot. Temp Mín Temp Máx Méd. Aritmético Méd. Geométrico
--------- ------ ---------- -------- -------- --------------- --------------
Instrução 1 0,281284 0,281284 0,281284 0,281284 0,281284
Instrução 2 0,073158 0,073158 0,073158 0,073158 0,073158
Instrução 3 0,000823 0,000823 0,000823 0,000823 0,000823
Instrução 4 0,155366 0,155366 0,155366 0,155366 0,155366
* Total de Entradas: 4
* Tempo Total: 0,510630 segundos
* Tempo Mínimo: 0,000823 segundos
* Tempo Máximo: 0,281284 segundos
* Tempo Médio Aritmético: 0,127658 segundos
* Tempo Médio Geométrico: 0,040271 segundos
Conceitos Relacionados:
v Capítulo 3, “Visão Geral da Migração para Servidores DB2”, na página 17
v “Teste de Benchmark” em Performance Guide
v “Exemplos de Testes de db2Batch” em Performance Guide
Tarefas Relacionadas:
v “Migrando um Servidor DB2 (Linux e UNIX)” na página 59
106 Guia de Migração
Referência Relacionada:
v “Tarefas de Pós-migração para Servidores DB2” na página 87
v “db2batch - Comando da Ferramenta de Avaliação de Desempenho” em
Command Reference
Inicialização de Replicação de HADR em Bancos de Dados Migrados
Durante a migração para o DB2 Versão 9 em um ambiente de replicação de HADR
(Recuperação de Desastre de Alta Disponibilidade), a função de um banco de
dados é alterada de primária para padrão. A migração de bancos de dados de
espera não é suportada, pois esses bancos de dados estão no estado pendente de
roll forward.
Antes de migrar, você deve parar HADR nos bancos de dados primário e de
espera, pois você pode somente migrar o banco de dados primário. Após a
migração, recrie seus bancos de dados de espera e inicialize novamente a HADR
nos bancos de dados de espera e primário.
Conceitos Relacionados:
v “Configuração de Banco de Dados para HADR (Recuperação de Desastre de
Alta Disponibilidade)” em Data Recovery and High Availability Guide and Reference
v “High availability disaster recovery overview” em Data Recovery and High
Availability Guide and Reference
Tarefas Relacionadas:
v “Inicializando HADR (Recuperação de Desastre de Alta Disponibilidade)” em
Data Recovery and High Availability Guide and Reference
v “Parando HADR (Recuperação de Desastre de Alta Disponibilidade)” em Data
Recovery and High Availability Guide and Reference
Referência Relacionada:
v “Tarefas de Pós-migração para Servidores DB2” na página 87
v “Comando START HADR” em Command Reference
v “Comando STOP HADR” em Command Reference
Capítulo 9. Tarefas de Pós-migração 107
108 Guia de Migração
Capítulo 10. Revertendo a Migração do Servidor DB2
Não há nenhum utilitário para reverter uma migração em um servidor DB2. Caso
queira reverter uma migração, será essencial criar um plano utilizando as etapas
neste procedimento. Executar uma migração em um ambiente de teste irá ajudá-lo
a identificar quaisquer problemas com o processo e evitar a necessidade de
reverter uma migração.
Esse procedimento inclui as etapas que você precisa executar para reverter a
migração.
Pré-requisitos:
v Certifique-se de ter autoridade SYSADM, além de root, nos sistemas
operacionais Linux e UNIX ou autoridade de Administrador Local nos sistemas
operacionais Windows.
v Execute as seguintes etapas antes de migrar seu servidor DB2:
– Reveja recomendações de migração e requisitos de espaço em disco.
– Faça um completo e off-line backup de todos os bancos de dados que serão
migrados.
– Salve todos os valores do parâmetro de configuração do gerenciador de banco
de dados para cada instância e todos os valores do parâmetro de configuração
do banco de dados para cada banco de dados.
– Execute outras tarefas de pré-migração que se aplicam ao seu ambiente.v Mantenha a cópia existente do DB2 UDB Versão 8 durante a migração do
servidor DB2. Para isso, selecione a opção Instalar Novo para criar uma nova
cópia ao instalar o DB2 Versão 9. Não selecione a opção Migrar em sistemas
operacionais Windows.
Restrições:
v Esse procedimento aplica-se somente à migração do servidor DB2. Não inclui
clientes DB2.
v Em ambientes de bancos de dados particionados, você deve executar esse
procedimento em todos os servidores de partições de bancos de dados
participantes. Se você tiver várias partições de bancos de dados em um servidor
de partição, execute as tarefas no nível do banco de dados, como backup e
restauração, em cada partição de banco de dados.
v Restrições de migração adicionais se aplicam. Reveja a lista completa.
Procedimento:
Para reverter uma migração, você precisa executar as seguintes etapas:
1. Efetue logon como o proprietário da instância do DB2 Versão 9.
2. Elimine todos os bancos de dados no DB2 Versão 9 executando o comando
DROP DATABASE.
3. Efetue logon como root nos sistemas operacionais Linux e UNIX ou como
Administrador Local nos sistemas operacionais Windows.
4. Elimine suas instâncias do DB2 Versão 9 executando o comando db2idrop. Esse
comando não remove arquivos de banco de dados; é necessário eliminar seus
bancos de dados antes de eliminar suas instâncias.
© Direitos Autorais IBM Corp. 2006 109
5. Se você migrou suas instâncias do DB2 UDB Versão 8 para o DB2 Versão 9,
recrie suas instâncias no DB2 UDB Versão 8 executando o comando db2icrt. Em
seguida, restaure os valores do parâmetro de configuração do gerenciador de
banco de dados para cada instância utilizando o comando UPDATE
DATABASE MANAGER CONFIGURATION.
6. Para cada instância do DB2 UDB Versão 8, efetue logon como o proprietário da
instância e recrie os bancos de dados executando o comando RESTORE
DATABASE na instância do DB2 UDB Versão 8. Você não pode migrar seus
bancos de dados do DB2 Versão 9 para o DB2 UDB Versão 8.
Conceitos Relacionados:
v “Recomendações de Migração para Servidores DB2” na página 24
v “Restrições de Migração para Servidores DB2” na página 21
Tarefas Relacionadas:
v “Fazendo Backup dos Bancos de Dados antes da Migração” na página 38
v “Salvando Informações de Configuração” na página 39
Referência Relacionada:
v “Requisitos de Espaço em Disco para a Migração do Servidor DB2” na página 26
v “Tarefas de Pré-migração para Servidores DB2” na página 35
v “db2cfexp - Comando da Ferramenta de Exportação da Configuração de
Conectividade” em Command Reference
v “db2cfimp - Comando da Ferramenta de Importação da Configuração de
Conectividade” em Command Reference
v “db2icrt - Comando para Criar Instância” em Command Reference
v “db2idrop - Comando para Remover Instância” em Command Reference
v “Comando DROP DATABASE” em Command Reference
v “Comando RESTORE DATABASE” em Command Reference
v “Comando UPDATE DATABASE MANAGER CONFIGURATION” em Command
Reference
110 Guia de Migração
Parte 3. Migrando Clientes DB2
Esta parte do manual contém os seguintes capítulos:
Capítulo 11, “Visão Geral da Migração para Clientes DB2”, na página 113
Capítulo 12, “Essenciais da Migração para Clientes DB2”, na página 115
Capítulo 13, “Tarefas de Pré-migração”, na página 119
Capítulo 14, “Migrando Clientes DB2 (Windows)”, na página 121
Capítulo 15, “Migrando Clientes DB2 (Linux e UNIX)”, na página 127
Capítulo 16, “Tarefas de Pós-migração”, na página 131
© Direitos Autorais IBM Corp. 2006 111
112 Guia de Migração
Capítulo 11. Visão Geral da Migração para Clientes DB2
Migrar um cliente DB2 envolve migrar da instância cliente e assegurar que é
possível conectar a todos os bancos de dados catalogados. Uma instância cliente
permite que você conecte seu aplicativo a um servidor DB2 e mantém as
informações sobre os nós e os bancos de dados catalogados.
O nível atual do cliente DB2 instalado determina a maneira de como proceder com
a migração para o DB2 Versão 9. É possível migrar diretamente para os clientes
DB2 V9 dos clientes DB2 V8. Se você tiver clientes DB2 V7 ou anterior, é necessário
migrar para qualquer cliente DB2 V8 primeiro.
No DB2 Versão 9, os clientes DB2 são o DB2 Client e o DB2 Runtime Client. O DB2
Client mescla a funcionalidade do DB2 Application Development Client e do DB2
Administration Client anteriores. O DB2 Runtime Client é um cliente de pequeno
porte que suporta somente protocolos TCP/IP e Canais Nomeados.
A migração para o DB2 Client V9 é suportada para os seguintes clientes DB2:
v DB2 Administration Client V8
v DB2 Application Development Client V8
Após instalar o DB2 Runtime Client V9 como uma nova cópia do cliente DB2, a
migração da instância cliente é suportada para os seguintes clientes DB2:
v DB2 Run-Time V8
v DB2 Run-Time Client Lite V8
Os detalhes sobre como migrar a instância cliente após a instalação são fornecidos
em Princípios de Migração para Clientes DB2.
Conceitos Relacionados:
v “Visão Geral sobre a Configuração do Cliente do DB2” em Iniciação Rápida para
DB2 Clients
v Capítulo 12, “Essenciais da Migração para Clientes DB2”, na página 115
Tarefas Relacionadas:
v “Migrando um Cliente DB2 (Windows)” na página 121
v “Migrando o DB2 Runtime Client (Windows)” na página 123
v “Migrando Clientes DB2 (Linux e UNIX)” na página 127
v “Migrando dos Clientes DB2 Versão 7 (Linux e UNIX)” na página 129
v “Migrando de Clientes DB2 Versão 7 (Windows)” na página 124
v “Planejando a Migração para Clientes DB2” na página 9
© Direitos Autorais IBM Corp. 2006 113
114 Guia de Migração
Capítulo 12. Essenciais da Migração para Clientes DB2
Se estiver migrando seus clientes DB2 para o DB2 Versão 9, será necessário
considerar como fazer a migração baseada nas opções e restrições de migração
para clientes DB2 V9. Você também precisa estar ciente do suporte disponível para
protocolos de comunicação e conectividade entre versões diferentes de clientes DB2
e servidores DB2. Por fim, avalia as recomendações de migração para planejar a
migração de seu cliente DB2.
Opções de Migração para Clientes DB2
As opções de migração variam conforme o tipo de cliente que você deseja
instalar. A tabela a seguir descreve as opções de migração para cada tipo
de clientes DB2 V9:
Tabela 10. Opções de Migração para Clientes DB2 V9
Migração de Migração para Detalhes do suporte de migração
DB2
Administration
Client V8 ou DB2
Application
Development
Client V8
(Windows)
DB2 Client V9
(Windows)
Você tem duas opções:
v Instale o DB2 Client V9 e escolha a opção migrar,
a instância cliente é migrada automaticamente.
v Instale uma nova cópia do cliente da V9 do DB2
e, em seguida, migre manualmente a instância
existente do cliente da V8 do DB2.
DB2 Run-Time
Client V8 e DB2
Run-Time Client
Lite V8
(Windows)
DB2 Runtime
Client Versão 9
(Windows)
v Instale o DB2 Runtime Client V9 como uma nova
cópia separada e, em seguida, migre
manualmente sua instância do DB2 Client V8.
Todos os DB2
Clients V8 (Linux
ou UNIX)
Todos os DB2
Clients V9 (Linux
ou UNIX)
v Instale uma nova cópia de qualquer cliente da V9
do DB2 e, em seguida, migre manualmente a
instância existente do cliente da V8 do DB2 após
a instalação.
Quando a instância cliente é criada, o tamanho de bit é determinado pelos
sistema operacionais onde o DB2 Client V9 foi instalado:
v Instâncias de 32 bits somente em kernels de 32 bits do Linux no x86,
Windows no x86 ou Windows no X64 utilizando produto de 32 bits do
DB2 Versão 9.
v Instâncias de 64 bits em kernel de 64 bits de AIX, HP-UX, Solaris, Linux
no zSeries, Linux no POWER, Linux no x86_64 e Linux no IPF (Itanium
Platform Family). Instâncias de 32 bits não são suportadas nesses
sistemas operacionais. No entanto, o suporte para clientes de 4=32 bits e
aplicativos de 32 bits é fornecido em todos os sistemas operacionais
UNIX, exceto Linux no IPF.
Restrições de Migração para Clientes DB2
Reveja as “Restrições de Migração para Servidores DB2” na página 21
relacionadas ao suporte à migração de instância e ao sistema operacional.
Essas restrições também se aplicam a clientes do DB2 e podem afetar a
migração dos clientes do DB2.
Se você instalou o cliente V8 DB2 e ele está localizado no mesmo sistema
que um servidor DB2 Versão 9, as conexões locais utilizando IPC
© Direitos Autorais IBM Corp. 2006 115
(Interprocess Communication) não serão suportadas. Você deve migrar o
servidor DB2 e o cliente DB2 para o DB2 Versão 9 para acessar bancos de
dados migrados utilizando o diretório de banco de dados local existente.
Se não migrar a V8 do cliente DB2, você poderá acessar somente os bancos
de dados migrados que foram catalogados como bancos de dados remotos.
É necessário recatalogar bancos de dados migrados utilizando IPC como
remota.
Suporte ao Protocolo de Comunicações
O DB2 Versão 9 suporta protocolos de comunicação TCP/IP e canais
nomeados, mas não suporta mais os protocolos NetBIOS e SNA. Após a
migração, você precisa catalogar seus nós e bancos de dados utilizando um
protocolo válido como TCP/IP. Se você tentar se conectar com quaisquer
bancos de dados catalogados em um nó utilizando o protocolo NetBIOS,
seu pedido de conexão também retornará um erro porque o protocolo é
inválido.
O DB2 Versão 9 também suporta IPv6 (Internet Protocol Versão 6). Após a
migração, os nós TCP/IP no diretório de nós continuará trabalhando e o
cliente V9 DB2 utilizará conexões IPv6 ou IPv4. Caso queira utilizar uma
determinada versão de IP, você precisa recatalogar seus nós utilizando o
comando CATALOG TCPIP4 NODE para especificar explicitamente o IPv4
ou o comando CATALOG TCPIP6 NODE para especificar explicitamente o
IPv6.
Suporte à Conectividade entre Clientes DB2 e Servidores DB2
No DB2 Versão 9, o seguinte suporte à conectividade está disponível:
Tabela 11. Suporte à Conectividade do DB2 Versão 9
Cliente DB2 Servidor DB2 Suporte à conectividade do cliente DB2
DB2 Versão 9 de
32 bits ou 64 bits
DB2 UDB Versão 8
de 32 bits ou 64 bits
Apenas a funcionalidade do DB2 UDB Versão 8
está disponível.
DB2 UDB Versão 8
de 32 bits ou 64
bits
DB2 Versão 9 de 32
bits ou 64 bits
Apenas a funcionalidade do DB2 UDB Versão 8
está disponível.
DB2 UDB Versão
71 de 32 bits
DB2 Versão 9 de 32
bits e 64 bits
2
Somente instruções SQL são suportadas.As
ferramentas de administração do DB2 não são
suportadas.
DB2 UDB Versão
71 de 64 bits
DB2 Versão 9 de 32
bits e 64 bits3
Somente instruções SQL são suportadas.As
ferramentas de administração do DB2 não são
suportadas.
Notas:
1. O suporte para clientes DB2 V7 será removido em releases futuros.
2. Os clientes DB2 V7 de 32 bits podem se conectar a servidores DB2
Versão 9 de 64 bits conectando-se primeiro a um servidor DB2 Versão 9
ou DB2 UDB Versão 8 de 32 bits.
3. Os clientes DB2 V7 de 64 bits podem se conectar a servidores DB2
Versão 9 de 32 bits conectando-se primeiro a um servidor DB2 Versão 9
ou DB2 UDB Versão 8 de 64 bits.
Recomendações de Migração para Clientes DB2
Em geral, a recomendação é migrar primeiro servidores DB2 e depois
clientes DB2. Clientes DB2 V8 podem se conectar a servidores DB2 V9. A
única restrição é que os recursos do DB2 Versão 9 não estão disponíveis
116 Guia de Migração
para clientes DB2 V8. No entanto, não é provável que você precise de
acesso a esses novos recursos, pois seus aplicativos existentes não os
utiliza.
Caso tenha um software que exige um cliente V8 DB2, você precisará
instalar um cliente V9 DB2 como uma nova cópia e manter o cliente V8
DB2 existente para satisfazer esse requisito. É necessário criar uma
instância do cliente da V9 e manter a instância do cliente da V8 existente
com essa configuração. Você pode selecionar a opção para criar uma nova
instância cliente durante a instalação ou pode criar manualmente a
instância após a instalação.
Se optar por migrar primeiro seus clientes DB2, você precisa estar ciente de
que há limitações conhecidas sobre o suporte para conectividade de um
cliente DB2 V9 para servidores DB2 UDB Versão 8. Verifique as
configurações de cliente Suportadas e Não Suportadas, veja se essas
limitações aplicam-se a seu aplicativo para executar as ações necessárias.
Execute as tarefas pré e pós-migração para assegurar uma migração
bem-sucedida.
Conceitos Relacionados:
v “Tarefas de Pós-migração para Clientes DB2” na página 131
v “Tarefas de Pré-migração para Clientes DB2” na página 119
v Capítulo 11, “Visão Geral da Migração para Clientes DB2”, na página 113
v “Incompatibilidades da Versão 9 com Releases Anteriores e Comportamentos
Alterados” em Administration Guide: Planning
Tarefas Relacionadas:
v “Planejando a Migração para Clientes DB2” na página 9
v “Migrando um Cliente DB2 (Windows)” na página 121
v “Migrando o DB2 Runtime Client (Windows)” na página 123
v “Migrando Clientes DB2 (Linux e UNIX)” na página 127
Referência Relacionada:
v “Combinações Suportadas de Versões de Clientes e Servidores” em Iniciação
Rápida para DB2 Clients
Capítulo 12. Essenciais da Migração para Clientes DB2 117
118 Guia de Migração
Capítulo 13. Tarefas de Pré-migração
Este capítulo descreve as tarefas de pré-migração para clientes DB2. Ele contém as
seguintes seções:
v “Tarefas de Pré-migração para Clientes DB2”
v “Salvando Informações sobre a Configuração do Cliente DB2”
Tarefas de Pré-migração para Clientes DB2
Antes de migrar seus clientes DB2, você deve concluir determinadas tarefas para
ajudar a garantir que a migração seja bem-sucedida.
Prepare-se para a migração dos clientes DB2 executando as seguintes tarefas:
1. Reveja os princípios de migração para clientes DB2 para determinar quais
fatores podem afetar a migração do cliente DB2.
2. Reveja as configurações do cliente suportadas e não-suportadas.
3. Planeje sua estratégia de migração. Por exemplo, talvez você precise migrar
primeiro seu servidor DB2 e, em seguida, os clientes DB2.
4. Opcional: Migre seus servidores DB2.
5. Salve as informações de configuração de seu cliente DB2.
Conceitos Relacionados:
v Capítulo 12, “Essenciais da Migração para Clientes DB2”, na página 115
Tarefas Relacionadas:
v “Migrando Clientes DB2 (Linux e UNIX)” na página 127
v “Migrando um Cliente DB2 (Windows)” na página 121
v “Migrando o DB2 Runtime Client (Windows)” na página 123
Salvando Informações sobre a Configuração do Cliente DB2
Antes de migrar, você deve salvar as configurações do parâmetro de configuração
do gerenciador de banco de dados da instância do cliente e os detalhes das
informações sobre todos os seus bancos de dados catalogados. Com essas
informações, você pode restaurar a configuração do cliente anterior e os bancos de
dados catalogados após a migração, caso seja necessário.
Pré-requisitos:
Certifique-se de ter autoridade suficiente para acessar o cliente DB2.
Restrições:
Este procedimento descreve como salvar as informações de configuração para
apenas um cliente DB2. Caso tenha diferentes definições de configuração em cada
cliente DB2, você precisa salvar as informações de configuração para cada cliente.
Procedimento:
© Direitos Autorais IBM Corp. 2006 119
Para salvar as informações sobre a configuração do cliente DB2:
1. Salve as configurações do parâmetro de configuração do gerenciador de banco
de dados utilizando o comando GET DATABASE MANAGER
CONFIGURATION para listar suas configurações para os parâmetros e
redirecionar a saída de comando para um arquivo conforme mostrado no
exemplo a seguir:
db2 GET DBM CFG > D:\migration\dbm_client.cfg
2. Salve as informações dos bancos de dados catalogados executando o comando
db2cfexp para criar um perfil de configuração:
db2cfexp cfg_profile BACKUP
O arquivo cfg_profile é um perfil de cliente que contém todas as informações
sobre a configuração da instância, incluindo a configuração do gerenciador de
banco de dados e as configurações do perfil de registro, pois a opção BACKUP
foi especificada. Você também pode utilizar o Assistente de Configuração do
DB2 para exportar o perfil de configuração.
Conceitos Relacionados:
v “Tarefas de Pré-migração para Clientes DB2” na página 119
Tarefas Relacionadas:
v “Criando um Perfil de Cliente Utilizando o Assistente para Configuração” em
Iniciação Rápida para DB2 Clients
Referência Relacionada:
v “db2cfexp - Comando da Ferramenta de Exportação da Configuração de
Conectividade” em Command Reference
v “db2cfimp - Comando da Ferramenta de Importação da Configuração de
Conectividade” em Command Reference
v “Comando GET DATABASE MANAGER CONFIGURATION” em Command
Reference
120 Guia de Migração
Capítulo 14. Migrando Clientes DB2 (Windows)
Este capítulo descreve como migrar seus clientes DB2 no Windows. Ele contém as
seguintes seções:
v “Migrando um Cliente DB2 (Windows)”
v “Migrando o DB2 Runtime Client (Windows)” na página 123
v “Migrando de Clientes DB2 Versão 7 (Windows)” na página 124
Migrando um Cliente DB2 (Windows)
Esse procedimento aplica-se à migração do DB2 Administration Client V8 e do
DB2 Application Development Client V8 para o DB2 Client V9. Migrando sua
instância cliente para um cliente DB2 V9 assegura que você pode conectar a todos
os bancos de dados catalogados anteriormente.
Ao instalar a V9 do DB2 Client, você pode optar por migrar automaticamente uma
cópia existente do DB2 Administration Client V8 ou uma cópia do DB2 Application
Development Client V8 para a cópia da V9 do DB2 Client. Sua instância cliente V8
existente é migrada para a cópia do DB2 Client V9 e a cópia do DB2 Client V8 é
removida. Você também pode optar por instalar uma nova cópia do DB2 Client V9
e, em seguida, migrar manualmente sua instância cliente.
Pré-requisitos:
v Assegure que tenha autoridade SYSADM, SYSCTRL ou SYSMAINT e autoridade
de Administrador Local para executar o db2imigr e os comandos db2icrt.
v Reveja a conectividade suportada entre clientes DB2 e servidores DB2 em
princípios de migração para clientes DB2.
v Execute tarefas pré-migração.
Restrições:
v A migração direta não é suportada de clientes DB2 V7 ou anterior para clientes
DB2 V9. Você deve migrar primeiro para um cliente DB2 V8.
v O tamanho de bit da instância cliente é determinado pelos sistemas operacionais
onde o cliente DB2 V9 está instalado. A instância é somente de 32 bits no
Windows em x86 ou X64 de 32 bits. A instância tem somente 64 bits no
Windows de 64 bits em X64.
Procedimento:
Para migrar para a V9 do DB2 Client no Windows:
1. Instale a V9 do DB2 Client executando o comando setup.exe para ativar o
assistente de Configuração do DB2. Você tem duas opções:
v Selecione a opção Migrar no painel Instalar um Produto. Você pode escolher
essa opção se tiver uma cópia existente do DB2 Administration Client Versão
8 ou do DB2 Application Development Client Versão 8. Sua cópia do cliente
DB2 V8 é removida e a instância do cliente é migrada. Prossiga para a etapa
5 na página 122.
© Direitos Autorais IBM Corp. 2006 121
v Selecione a opção Instalar Novo no painel Instalar um Produto. Você deve
escolher essa opção para criar uma nova cópia da V9 do DB2 Client e manter
a cópia existente da V8 do DB2 Client.2. Efetue logon como Administrador Local.
3. Migre a instância existente da V8 do DB2 Client. Para migrar manualmente sua
instância cliente, execute o comando db2imigr:
"%DB2PATH%"\bin\db2imigr InstName
em que DB2PATH é configurado como o local que você especificou durante a
instalação do cliente da V9 do DB2 e InstName é o nome da instância.
4. Opcional: Você pode criar uma nova instância cliente V9 em vez de migrar a
instância cliente V8 existente. Você só precisa criar uma nova instância do
cliente V9 quando quiser manter diversas cópias do DB2 em execução no
mesmo servidor DB2 ou criar um ambiente de teste. Para criar uma nova
instância cliente V9, execute o comando db2icrt com a opção -s:
"%DB2PATH%"\bin\db2icrt -s client InstName
Para criar o mesmo ambiente de conectividade do cliente que havia, incluindo
o parâmetro de configuração do gerenciador de banco de dados e as
configurações do registro de perfil do DB2, execute o comando db2cfimp com
o perfil de configuração que você salva nas tarefas de pré-migração.
5. Compare os valores dos parâmetros de configuração do gerenciador de banco
de dados migrado com os valores de pré-migração para garantir que os valores
alterados sejam compatíveis com seus aplicativos de banco de dados.
Após migrar o DB2 Client, execute as recomendadas tarefas de pós-migração para
clientes DB2, principalmente a verificação da migração para clientes DB2 para
garantir que a migração do cliente DB2 foi bem-sucedida.
Conceitos Relacionados:
v Capítulo 12, “Essenciais da Migração para Clientes DB2”, na página 115
v “Tarefas de Pré-migração para Clientes DB2” na página 119
v “Tarefas de Pós-migração para Clientes DB2” na página 131
Tarefas Relacionadas:
v “Verificando a Migração de Clientes DB2” na página 133
v “Definindo protocolos de Comunicação para uma Instância DB2” em Suplemento
de Instalação e Configuração
v “Instalando clientes do DB2 (Windows)” em Iniciação Rápida para DB2 Clients
Referência Relacionada:
v “db2cfexp - Comando da Ferramenta de Exportação da Configuração de
Conectividade” em Command Reference
v “db2cfimp - Comando da Ferramenta de Importação da Configuração de
Conectividade” em Command Reference
v “db2icrt - Comando para Criar Instância” em Command Reference
v “db2imigr - Comando para Migrar a Instância” em Command Reference
122 Guia de Migração
Migrando o DB2 Runtime Client (Windows)
Esse procedimento aplica-se à migração da V8 do DB2 Run-Time Client e da V8 do
DB2 Run-Time Client Lite para a V9 do DB2 Runtime Client. Após instalar a V9 do
DB2 Runtime Client, você pode migrar manualmente a instância cliente V8
existente de uma cópia da V8 do DB2 Run-Time ou da V8 do DB2 Run-Time Client
Lite. Migrando sua instância cliente para um cliente DB2 V9 assegura que você
pode conectar a todos os bancos de dados catalogados anteriormente.
Pré-requisitos:
v Assegure que tenha autoridade SYSADM, SYSCTRL ou SYSMAINT e autoridade
de Administrador Local para executar o db2imigr e os comandos db2icrt.
v Reveja a conectividade suportada entre clientes DB2 e servidores DB2 em
princípios de migração para clientes DB2.
v Execute tarefas pré-migração.
Restrições:
v A migração direta não é suportada de clientes DB2 V7 ou anterior para clientes
DB2 V9. Você deve migrar primeiro para um cliente DB2 V8.
v O tamanho de bit da instância cliente é determinado pelos sistemas operacionais
onde o cliente DB2 V9 está instalado. A instância é somente de 32 bits no
Windows em x86 ou X64 de 32 bits. A instância tem somente 64 bits no
Windows de 64 bits em X64.
Procedimento:
Para migrar para a V9 do DB2 Runtime Client no Windows:
1. Instale a V9 do DB2 Runtime Client. Execute o comando setup.exe para ativar
o assistente de Configuração do DB2 e selecione a opção Instalar Novo no
painel Instalar um Produto,
2. Efetue logon como Administrador Local.
3. Migre a instância cliente da V8 do DB2 existente executando o comando
db2imigr:
"%DB2PATH%"\bin\db2imigr InstName
em que DB2PATH é configurado como o local especificado durante a instalação
do cliente da V9 do DB2 e InstName é o nome da instância.
4. Opcional: Você pode criar uma nova instância cliente V9 em vez de migrar a
instância cliente V8 existente. Você só precisa criar uma nova instância do
cliente da V9 quando quiser manter várias cópias do DB2 em execução no
mesmo servidor DB2. Para criar uma nova instância cliente V9, execute o
comando db2icrt com a opção -s:
"%DB2PATH%"\bin\db2icrt -s client InstName
Para criar o mesmo ambiente de conectividade do cliente que havia, incluindo
o parâmetro de configuração do gerenciador de banco de dados e as
configurações do registro de perfil do DB2, execute o comando db2cfimp com
o perfil de configuração que você salva nas tarefas de pré-migração.
5. Compare os valores dos parâmetros de configuração do gerenciador de banco
de dados migrado com os valores de pré-migração para garantir que os valores
alterados sejam compatíveis com seus aplicativos de banco de dados.
Capítulo 14. Migrando Clientes DB2 (Windows) 123
Após migrar o DB2 Runtime Client, execute as tarefas de pós-migração para
clientes DB2 que são recomendadas, principalmente a verificação de migração para
clientes DB2 para garantir que a migração do cliente DB2 foi bem-sucedida.
Conceitos Relacionados:
v Capítulo 12, “Essenciais da Migração para Clientes DB2”, na página 115
v “Tarefas de Pré-migração para Clientes DB2” na página 119
v “Tarefas de Pós-migração para Clientes DB2” na página 131
Tarefas Relacionadas:
v “Verificando a Migração de Clientes DB2” na página 133
v “Instalando clientes do DB2 (Windows)” em Iniciação Rápida para DB2 Clients
v “Migrando um Cliente DB2 (Windows)” na página 121
v “Migrando de Clientes DB2 Versão 7 (Windows)” na página 124
Referência Relacionada:
v “db2cfexp - Comando da Ferramenta de Exportação da Configuração de
Conectividade” em Command Reference
v “db2cfimp - Comando da Ferramenta de Importação da Configuração de
Conectividade” em Command Reference
v “db2icrt - Comando para Criar Instância” em Command Reference
v “db2imigr - Comando para Migrar a Instância” em Command Reference
Migrando de Clientes DB2 Versão 7 (Windows)
Não há migração direta para o DB2 Versão 9 dos clientes DB2 V7. Você deve
migrar primeiro para um cliente DB2 V8 e, em seguida, migre para um cliente DB2
V9. Você deve migrar para o DB2 UDB Versão 8.2 FixPak mais recente para tirar
proveito de todas as correções que podem afetar a migração.
Pré-requisito:
v Revise a conectividade de cliente e servidor suportada em Princípios de
Migração para Clientes DB2.
Restrições:
v A migração para clientes DB2 V9 é suportada somente de clientes DB2 Versão 8:
– A migração para a V9 do DB2 Client é suportada a partir de uma instalação
existente da V8 do DB2 Administration Client ou da V8 do DB2 Application
Development Client.
– A migração para a V9 do DB2 Runtime Client a partir da V8 do DB2
Run-Time ou da V8 do DB2 Run-Time Client Litev A migração para clientes V8 DB2 é suportada a partir de clientes do DB2 Versão
7.
Procedimento:
Para migrar para um cliente DB2 V9 de um cliente DB2 V7:
1. Salve as definições de configuração e conectividade do cliente. Utilize a
ferramenta db2cfexp para criar um perfil de configuração:
db2cfexp client_profile backup
124 Guia de Migração
Esse perfil contém todas as informações de configuração de instância, incluindo
a configuração do gerenciador de banco de dados e o perfil de registro, pois a
opção backup é especificada. Você também pode utilizar o Assistente de
Configuração do DB2 para exportar o perfil de configuração.
2. Instale o cliente DB2 V8.2. Utilize o comando setup.exe para ativar o assistente
de Configuração do DB2. O cliente da V7 do DB2 existente e a instância cliente
são migrados automaticamente como parte da instalação.
3. Compare os valores dos parâmetros de configuração do gerenciador de banco
de dados migrado com valores de pré-migração. Assegure que quaisquer
alterações são compatíveis com seu aplicativo.
4. Teste conexões com todos os bancos de dados catalogados para confirmar que a
migração foi bem-sucedida:
db2 CONNECT TO DATABASE database-name
Como alternativa, é possível utilizar o Assistente de Configuração para testar
suas conexões. Você também pode importar seu perfil de cliente se encontrar
quaisquer problemas de conexão para seus bancos de dados catalogados.
Certifique-se de ter conectividade de rede para o servidor DB2 e de que o
servidor DB2 esteja ativo e em execução. Além disso, assegure que não haja
problemas de conectividade devido ao suporte de conexão de 32 bits e de 64
bits.
5. Migre para a V9 do DB2 Client no Windows ou Migre para a V9 do DB2
Run-Time Client no Windows.
Conceitos Relacionados:
v Capítulo 12, “Essenciais da Migração para Clientes DB2”, na página 115
Tarefas Relacionadas:
v “Migrando um Cliente DB2 (Windows)” na página 121
v “Instalando clientes do DB2 (Windows)” em Iniciação Rápida para DB2 Clients
Capítulo 14. Migrando Clientes DB2 (Windows) 125
126 Guia de Migração
Capítulo 15. Migrando Clientes DB2 (Linux e UNIX)
Este capítulo descreve como migrar seus clientes DB2 no Linux e UNIX. Ele
contém as seguintes seções:
v “Migrando Clientes DB2 (Linux e UNIX)”
v “Migrando dos Clientes DB2 Versão 7 (Linux e UNIX)” na página 129
Migrando Clientes DB2 (Linux e UNIX)
Esse procedimento aplica-se à migração do DB2 Administration Client V8 e do
DB2 Application Development Client V8 para o DB2 Client V9. Também se aplica à
migração do DB2 Run-Time Client V8 e do DB2 Run-Time Client Lite V8 para o
DB2 Runtime Client V9. Migrando sua instância cliente para um cliente DB2 V9
assegura que você pode conectar a todos os bancos de dados catalogados
anteriormente.
Após instalar um cliente DB2 V9 em um sistema onde um cliente DB2 V8 está
instalado, você precisa migrar manualmente sua instância cliente V8 existentes
para assegurar que possa conectar a todos os bancos de dados catalogados
anteriormente.
Pré-requisitos:
v Certifique-se de ter acesso root.
v Certifique-se de ter autoridade SYSADM, SYSCTRL ou SYSMAINT e acesso root
para executar os comandos db2imigr e db2icrt.
v Reveja a Página da Web de Requisitos do Sistema para a instalação do produto
do banco de dados DB2. Alguns sistemas operacionais requerem um kernel de
64 bits.
v Reveja a conectividade suportada entre clientes DB2 e servidores DB2 em
princípios de migração para clientes DB2.
v Execute tarefas pré-migração.
Restrições:
v A migração direta não é suportada de clientes DB2 V7 ou anterior para clientes
DB2 V9. Você deve migrar primeiro para um cliente DB2 V8.
v O tamanho de bit da instância cliente é determinado pelo sistema operacional
onde o cliente DB2 V9 está instalado. A instância cliente é somente de 32 bits em
Linux em x86 e de 64 bits em todos os outros sistemas operacionais suportados
Linux e UNIX.
Procedimento:
Para migrar um cliente DB2 V8 para um cliente DB2 V9:
1. Instale o DB2 Client V9 ou o DB2 Runtime Client V9.. Execute o comando
db2setup e selecione Instalar Novo no painel Instalar um Produto para instalar
uma nova cópia do DB2 Versão 9.
2. Efetue logon como root.
3. Migre suas instâncias clientes DB2 V8 existentes executando o comando
db2imigr:
© Direitos Autorais IBM Corp. 2006 127
$DB2DIR/instance/db2imigr InstName
em que
DB2DIR
é configurado para o local especificado durante a instalação do cliente
DB2 V9. O caminho da instalação padrão para UNIX é
/opt/IBM/db2/V9.1 e para Linux é /opt/ibm/db2/V9.1.
InstName
é o nome de login do proprietário da instância cliente.4. Opcional: Você também pode criar uma nova instância cliente V9 em vez de
migrar a instância cliente V8 existente. Você só precisa criar uma nova instância
do cliente da V9 quando quiser manter várias cópias do DB2 em execução no
mesmo servidor DB2. Para criar uma nova instância cliente V9, execute o
comando db2icrt com a opção -s:
$DB2DIR/instance/db2icrt -s client InstName
em que
DB2DIR
é configurado para o local especificado durante a instalação do cliente
DB2 V9.
InstName
É o nome do login do proprietário da instância.
Para criar o mesmo ambiente de conectividade do cliente que havia, incluindo
o parâmetro de configuração do gerenciador de banco de dados e as
configurações do registro de perfil do DB2, execute o comando db2cfimp com
o perfil de configuração que você salva nas tarefas de pré-migração.
5. Compare os valores dos parâmetros de configuração do gerenciador de banco
de dados migrado com os valores de pré-migração para garantir que os valores
alterados sejam compatíveis com seus aplicativos de banco de dados.
Após migrar qualquer cliente DB2, execute as recomendadas para clientes DB2,
especialmente verificando a migração para clientes DB2 para assegurar que a
migração do cliente DB2 foi bem-sucedida.
Conceitos Relacionados:
v “Tarefas de Pré-migração para Clientes DB2” na página 119
v “Tarefas de Pós-migração para Clientes DB2” na página 131
v Capítulo 12, “Essenciais da Migração para Clientes DB2”, na página 115
Tarefas Relacionadas:
v “Verificando a Migração de Clientes DB2” na página 133
v “Definindo protocolos de Comunicação para uma Instância DB2” em Suplemento
de Instalação e Configuração
v “Instalando Clientes do DB2 (UNIX e Linux)” em Iniciação Rápida para DB2
Clients
Referência Relacionada:
v “db2cfexp - Comando da Ferramenta de Exportação da Configuração de
Conectividade” em Command Reference
128 Guia de Migração
v “db2cfimp - Comando da Ferramenta de Importação da Configuração de
Conectividade” em Command Reference
v “db2imigr - Comando para Migrar a Instância” em Command Reference
Migrando dos Clientes DB2 Versão 7 (Linux e UNIX)
Não há migração direta para o DB2 Versão 9 dos clientes DB2 V7. Você deve
migrar primeiro para um cliente DB2 V8 e, em seguida, migre para um cliente DB2
V9. Você deve migrar para o DB2 UDB Versão 8.2 FixPak mais recente para tirar
proveito de todas as correções que podem afetar a migração.
Pré-requisitos:
v Certifique-se de ter autoridade root.
v Certifique-se de ter autoridade SYSADM, SYSCTRL ou SYSMAINT e autoridade
root para executar os comandos db2imigr e db2icrt.
v Revise a conectividade de cliente e servidor suportada em Princípios de
Migração para Clientes DB2.
Restrições:
v A migração para clientes DB2 V9 é suportada somente de clientes DB2 Versão 8:
– A migração para a V9 do DB2 Client é suportada a partir de uma instalação
existente da V8 do DB2 Administration Client ou da V8 do DB2 Application
Development Client.
– A migração para a V9 do DB2 Runtime Client a partir da V8 do DB2
Run-Time ou da V8 do DB2 Run-Time Client Lite.v A migração para clientes V8 DB2 é suportada a partir de clientes do DB2 Versão
7.
Procedimento:
Para migrar para um cliente DB2 V9 de um cliente DB2 V7:
1. Salve as definições de configuração e conectividade do cliente. Utilize a
ferramenta db2cfexp para criar um perfil de configuração:
db2cfexp client_profile backup
Esse perfil contém todas as informações de configuração de instância, incluindo
a configuração do gerenciador de banco de dados e o perfil de registro, pois a
opção backup é especificada. Você também pode utilizar o Assistente de
Configuração do DB2 para exportar o perfil de configuração.
2. Instale o cliente DB2 Versão 8.2.
3. Efetue logon como root.
4. Migre suas instâncias clientes DB2 V7 existentes. Utilize o comando db2imigr:
$DB2DIR/instance/db2imigr InstName
em que DB2DIR indica o local para a instalação do cliente DB2 V8 e InstName é
o nome de login do proprietário da instância. O caminha da instalação padrão
do cliente DB2 V8 é /usr/opt/db2_08_01 no AIX e /opt/IBM/db2/V8.1 em todos
os outros sistemas operacionais UNIX.
5. Compare os valores dos parâmetros de configuração do gerenciador de banco
de dados migrado com valores de pré-migração. Assegure que quaisquer
alterações são compatíveis com seu aplicativo.
Capítulo 15. Migrando Clientes DB2 (Linux e UNIX) 129
6. Teste conexões com todos os bancos de dados catalogados para confirmar que a
migração foi bem-sucedida:
db2 CONNECT TO DATABASE database-name
Como alternativa, é possível utilizar o Assistente de Configuração para testar
suas conexões. Você também pode importar seu perfil de cliente se encontrar
quaisquer problemas de conexão com seus bancos de dados catalogados.
Certifique-se de ter conectividade de rede para o servidor DB2 e de que o
servidor DB2 esteja ativo e em execução.
7. Migre para o cliente da V9 do DB2 no Linux e UNIX.
Conceitos Relacionados:
v Capítulo 12, “Essenciais da Migração para Clientes DB2”, na página 115
Tarefas Relacionadas:
v “Migrando Clientes DB2 (Linux e UNIX)” na página 127
v “Instalando Clientes do DB2 (UNIX e Linux)” em Iniciação Rápida para DB2
Clients
130 Guia de Migração
Capítulo 16. Tarefas de Pós-migração
Este capítulo descreve as tarefas de pós-migração para clientes DB2. Ele contém as
seguintes seções:
v “Tarefas de Pós-migração para Clientes DB2”
v “Recatalogando Nós e Bancos de Dados que Utilizam os Protocolos NetBIOS e
SNA”
v “Verificando a Migração de Clientes DB2” na página 133
Tarefas de Pós-migração para Clientes DB2
Após migrar os clientes DB2, você deve executar algumas etapas de pós-migração
para garantir que os clientes DB2 funcionem conforme o esperado e em seu melhor
nível.
Execute as seguintes tarefas pós-migração que se aplicam aos seus clientes do DB2:
1. Recatalogue nós e bancos de dados caso os tenha catalogado utilizando os
protocolos NetBIOS e SNA no DB2 UDB Versão 8. O DB2 Versão 9 não suporta
os protocolos NetBIOS e SNA.
2. Reveja alterações nas variáveis de registro e nos parâmetros de configuração do
DB2 para modificar suas configurações onde for necessário. Existem novas
variáveis de registro, novos parâmetros de configuração e novos valores padrão
para variáveis de registro e parâmetros de configuração introduzidos no DB2
Versão 9 que podem afetar o comportamento do seu aplicativo.
3. Verifique se a migração dos clientes DB2 foi bem-sucedida.
Tarefas Relacionadas:
v “Migrando Clientes DB2 (Linux e UNIX)” na página 127
v “Migrando um Cliente DB2 (Windows)” na página 121
v “Migrando o DB2 Runtime Client (Windows)” na página 123
Recatalogando Nós e Bancos de Dados que Utilizam os Protocolos
NetBIOS e SNA
O DB2 Versão 9 não suporta os protocolos NetBIOS e SNA. É necessário
recatalogar, utilizando um protocolo válido, quaisquer nós que foram catalogados
com os protocolos NetBIOS e SNA. Se você tentar se conectar a quaisquer bancos
de dados catalogados em um nó que utiliza o protocolo NetBIOS ou SNA, seu
pedido de conexão retorna um erro, pois esses protocolos são inválidos.
Esse procedimento descreve como recatalogar nós utilizando o protocolo TCP/IP.
Se você alterar o nome do nó, será necessário recatalogar os bancos de dados, bem
como utilizar o novo nome do nó.
Pré-requisitos:
v Assegure que você tenha autoridade SYSADM ou SYSCTRL.
v Certifique-se de ter conectividade de rede a partir do cliente DB2 para o servidor
DB2.
© Direitos Autorais IBM Corp. 2006 131
Restrições:
Os únicos protocolos disponíveis no DB2 Versão 9 são TCP/IP e Named Pipes.
Procedimento:
Para recatalogar nós e bancos de dados especificando o protocolo TCP/IP:
1. Determine quais nós utilizam o protocolo NetBIOS ou SNA emitindo o
comando LIST NODE DIRECTORY:
db2 LIST NODE DIRECTORY show detail > node_list.log
Redirecione a saída desse comando para um arquivo e mantenha-a, pois as
informações são úteis para recatalogar seus nós.
2. Remova todos os nós que utilizam o protocolo NetBIOS ou SNA do diretório
de nós emitindo o comando UNCATALOG NODE:
db2 UNCATALOG NODE node-name
3. Determine quais bancos de dados utilizam os nós que você catalogou
especificando o protocolo NetBIOS ou SNA emitindo o comando LIST
DATABASE DIRECTORY:
db2 LIST DATABASE DIRECTORY show detail > database_list.log
4. Se você for recatalogar seus nós utilizando um nome de nó diferente, remova
todos os bancos de dados que utilizam os nós emitindo o comando
UNCATALOG DATABASE:
db2 UNCATALOG DATABASE database-name
5. Recatalogue seus nós especificando TCP/IP como o protocolo. Se você utilizar
o nome do nó original, não será necessário recatalogar seus bancos de dados.
db2 CATALOG TCPIP NODE new-node REMOTE host-name
SERVER instance-svcename REMOTE_INSTANCE instance-name
Você pode determinar o valor de instance-svcename consultando o valor do
parâmetro de configuração do gerenciador de banco de dados svcename para
essa instância.
6. Caso não tenha recatalogado seus nós utilizando os nomes de nós originais,
recatalogue seus bancos de dados utilizando o novo nome de nó.
db2 CATALOG DATABASE db-name [AS alias-db-name]
AT NODE new-node
Conceitos Relacionados:
v “Tarefas de Pós-migração para Clientes DB2” na página 131
Tarefas Relacionadas:
v “Catalogando um Banco de Dados a partir de um Cliente Utilizando CLP” em
Iniciação Rápida para DB2 Clients
v “Catalogando um Nó TCP/IP a partir de um Cliente Utilizando CLP” em
Iniciação Rápida para DB2 Clients
Referência Relacionada:
v “Comando CATALOG DATABASE” em Command Reference
v “Comando CATALOG TCPIP/TCPIP4/TCPIP6 NODE” em Command Reference
v “Comando LIST DATABASE DIRECTORY” em Command Reference
v “Comando LIST NODE DIRECTORY” em Command Reference
v “Comando UNCATALOG DATABASE” em Command Reference
132 Guia de Migração
v “Comando UNCATALOG NODE” em Command Reference
Verificando a Migração de Clientes DB2
Quando a migração do cliente DB2 for concluída, uma boa prática será executar
alguns testes no novo ambiente migrado para verificar se seu cliente DB2 está
funcionando conforme o esperado. Esses testes podem consistir na execução de
programas em batch que se conectam a bancos de dados em um servidor DB2 ou
quaisquer programas ou scripts que você utiliza para avaliação de desempenho.
Pré-requisitos:
v Certifique-se de ter conectividade de rede a partir do cliente DB2 para o servidor
DB2.
v Certifique-se de que servidores e instâncias do DB2 estejam ativos e em
execução.
Procedimento:
Para verificar se a migração do cliente DB2 foi bem-sucedida:
1. Faça o teste conectando-se a todos os bancos de dados catalogados. O exemplo
a seguir testa uma conexão a um banco de dados remoto emitindo o comando
CONNECT:
db2 CONNECT TO DATABASE sample user mickey using mouse
Database Connection Information
Servidor de banco de dados = DB2/AIX64 9.1.0
ID de autorização do SQL = TESTDB2
Alias do banco de dados local = SAMPLE
É necessário especificar um ID de usuário e senha ao conectar-se a um banco
de dados remoto.
2. Se você tiver problemas para se conectar ao banco de dados catalogado, utilize
a ferramenta db2cfimp e o perfil de configuração que você salvou
desempenhando a tarefa de pré-migração salvando a configuração dos clientes
DB2 para recriar o mesmo ambiente de conectividade com o cliente que você
tinha antes da migração.
3. Execute seus aplicativos de banco de dados cliente ou scripts que se conectam
aos seus bancos de dados para garantir que eles estejam funcionando da forma
esperada.
Conceitos Relacionados:
v “Tarefas de Pós-migração para Clientes DB2” na página 131
Tarefas Relacionadas:
v “Salvando Informações sobre a Configuração do Cliente DB2” na página 119
Referência Relacionada:
v “Instrução CONNECT (Tipo 1)” em SQL Reference, Volume 2
Capítulo 16. Tarefas de Pós-migração 133
134 Guia de Migração
Parte 4. Migrando Aplicativos e Rotinas de Banco de Dados
Esta parte do manual contém os seguintes capítulos:
Capítulo 17, “Visão Geral da Migração para Aplicativos de Banco de Dados e
Rotinas”, na página 137
Capítulo 18, “Princípios de Migração para Aplicativos de Banco de Dados”, na
página 139
Capítulo 19, “Princípios de Migração para Rotinas”, na página 147
Capítulo 20, “Tarefas de Pré-migração para Aplicativos de Banco de Dados e
Rotinas”, na página 151
Capítulo 21, “Migrando Aplicativos de Banco de Dados”, na página 153
Capítulo 22, “Migrando Rotinas”, na página 167
Capítulo 23, “Tarefas de Pós-migração para Aplicativos de Banco de Dados e
Rotinas”, na página 181
© Direitos Autorais IBM Corp. 2006 135
136 Guia de Migração
Capítulo 17. Visão Geral da Migração para Aplicativos de
Banco de Dados e Rotinas
A migração dos servidores DB2 do DB2 UDB Versão 8 para o DB2 Versão 9 pode
exigir que você migre seus aplicativos de banco de dados e rotinas para execução
no DB2 Versão 9.
A migração de aplicativos e rotinas envolve as seguintes ações:
v Teste se seus aplicativos e rotinas estão executando conforme o esperado em um
ambiente de teste do DB2 Versão 9. Não é necessário migrar seus aplicativos e
rotinas se eles estiverem executando de forma bem-sucedida.
v Se seus aplicativos ou rotinas tiverem erros ao executar no DB2 Versão 9, você
deve:
– Rever os princípios de migração para aplicativos de banco de dados para
identificar quaisquer alterações no DB2 Versão 9 que podem afetar seus
aplicativos.
– Rever os princípios de migração para rotinas para identificar quaisquer
alterações no DB2 Versão 9 que podem afetar suas rotinas.
– Planejar como modificar seus aplicativos e rotinas para manipular essas
alterações. Determine quais etapas você precisa desempenhar revendo as
tarefas Migrando Aplicativos de Banco de Dados ou Migrando Rotinas.
– Modificar seus aplicativos e suas rotinas de acordo com seu plano.
– Testar seus aplicativos e rotinas no ambiente de testes do DB2 Versão 9.v Verifique se seus aplicativos e suas rotinas estão executando conforme o
esperado no ambiente de produção do DB2 Versão 9 antes de implementá-los.
Se seus aplicativos e suas rotinas utilizarem qualquer funcionalidade que esteja
obsoleta no DB2 Versão 9, você deve planejar como remover essa funcionalidade
do código do aplicativo futuramente.
Além disso, você deve considerar a utilização de novos recursos disponíveis no
DB2 Versão 9 para aumentar a funcionalidade e aprimorar o desempenho.
Conceitos Relacionados:
v “O que Há de Novo na V9.1: Resumo de Aprimoramentos em Desenvolvimento
de Aplicativos” em O que Há de Novo
v “O que Há de Novo na V9.1: Resumo de Funcionalidade Obsoleta” em O que Há
de Novo
v “Funcionalidade Obsoleta ou Descontinuada em Produtos do Banco de Dados
DB2 que Afeta a Migração” na página 30
Tarefas Relacionadas:
v “Migrando Aplicativos de Banco de Dados” na página 153
v “Migrando Rotinas” na página 167
v “Planejando a Migração para Aplicativos de Banco de Dados e Rotinas” na
página 11
© Direitos Autorais IBM Corp. 2006 137
138 Guia de Migração
Capítulo 18. Princípios de Migração para Aplicativos de
Banco de Dados
Os princípios de migração descrevem alterações no suporte ao desenvolvimento de
aplicativos, alterações para suportar novos recursos, recursos não-suportados e
recursos obsoletos que podem afetar os aplicativos de banco de dados, scripts e
ferramentas.
Alterações do Suporte ao Sistema Operacional
Certas versões dos sistemas operacionais UNIX, Linux e Windows não são
suportadas no DB2 Versão 9, tais como AIX Versão 4.3.3, Solaris 8 e
Windows NT. Uma lista completa dos sistemas operacionais suportados
está disponível na página da Web de requisitos do sistema DB2. Se a
versão atual do sistema operacional não for suportada, você deverá fazer
seu upgrade antes de instalar o DB2 Versão 9.
Nos sistemas operacionais UNIX, somente kernels de 64 bits são
suportados. Suas instâncias de 32 bits do DB2 UDB Versão 8 são migradas
para instâncias de 64 bits do DB2 Versão 9.
Se você fizer upgrade para a versão mais recente do seu sistema
operacional ou instalar um kernel de 64 bits, reconstrua todos os
aplicativos de bancos de dados e rotinas externas após migrar para o DB2
Versão 9 para que eles utilizem as novas bibliotecas de tempo de execução
no sistema operacional.
Alterações de Drivers de Aplicativos
No DB2 Versão 9, as origens de dados ODBC incluem o nome da
instalação. Após você migrar suas instâncias, os DSN (Nomes de Origens
de Dados) ODBC existentes são migrados para utilizar o novo nome do
driver ODBC IBM. Se seu aplicativo utilizar o gerenciador de Driver ODBC
para um criar um novo DSN você terá acesso somente a bancos de dados
sob as instâncias da cópia padrão.
O DB2 .NET Data Provider agora suporta o Microsoft .NET Framework,
Versão 2.0, e tem novos recursos adicionais, tais como o suporte para as
classes-base System.Data.Common, classes DB2Types, conjuntos de
resultados roláveis e atualizáveis, paginação de dados, cópia de dados em
massa e execução de instruções SQL como um batch. Modifique seus
aplicativos de banco de dados se quiser tirar proveito desses novos
recursos para aprimorar o desempenho do seu aplicativo.
O driver JDBC tipo 3 do DB2 não é suportado no DB2 Versão 9. Modifique
seus aplicativos e applets Java que utilizam esse driver para utilizar o IBM
DB2 Driver para JDBC e SQLJ com conexões do tipo 4.
Você deve estar ciente das seguintes diferenças de comportamento entre o
DB2 UDB Versão 8 e o DB2 Versão 9 do IBM DB2 Driver para JDBC e
SQLJ.
O método padrão de recuperação de dados LOB foi alterado
Por padrão, a recuperação de LOB é feita utilizando a execução de
fluxo progressivo em vez de utilizando localizadores de LOB nos
quais a execução de fluxo progressivo é suportada pelo servidor
DB2. O gerenciador de banco de dados determina dinamicamente
© Direitos Autorais IBM Corp. 2006 139
o método mais eficiente para retornar os dados de LOB com base
no tamanho do LOB e utilizará a execução de fluxo progressivo
sempre que possível.
Especificando um método para conversão do lado cliente dos tipos de
dados de entrada
Por padrão, os tipos de dados do aplicativo são convertidos em
tipos de dados de coluna quando as informações do tipo de dados
de coluna estão disponíveis. Agora você pode optar por desativar
essa conversão.
O método que utiliza operações UPDATE posicionadas do JDBC 1.0 está
obsoleto
O IBM DB2 Driver para JDBC e SQLJ suporta um método de
definição e utilização de ResultSets atualizáveis que seguem o
padrão JDBC 1.0. Esse método está obsoleto e não é recomendado.
O método JDBC 1.0 envolve a utilização do método
ResultSet.getCursorName para obter o nome do cursor para o
ResultSet e a definição de uma instrução UPDATE posicionada da
seguinte forma:
UPDATE table SET col1=value1,...coln=valueN
WHERE CURRENT OF cursorname
Se você utilizar o método JDBC 1.0 para atualizar dados em um
servidor de banco de dados que suporta BUSCA de várias linhas,
como DB2 para z/OS Versão 8 ou posterior, a instrução UPDATE
posicionada poderá atualizar diversas linhas quando você espera
que ela atualize uma única linha.
Alterações do Suporte ao Software de Desenvolvimento
O suporte ao software de desenvolvimento também foi alterado. Para
aprimorar o desempenho e evitar problemas de suporte técnico, reconstrua
seus aplicativos com a versão mais recente do software de
desenvolvimento. Reveja as alterações no suporte para o software de
desenvolvimento para obter uma lista específica do que não é mais
suportado.
O novo IBM Database Add-Ins para Microsoft Visual Studio 2005 fornece
ferramentas para o rápido desenvolvimento de aplicativos,
desenvolvimento de esquema de banco de dados e depuração nesse
ambiente de desenvolvimento.
Alterações de APIs do DB2 e Comandos do DB2
Os comandos do CLP (Processador de Linha de Comandos) e do sistema
DB2 foram alterados no DB2 Versão 9. Essas alterações incluem novas
opções e opções que não estão mais disponíveis. A tabela a seguir lista as
alterações que podem afetar aplicativos e scripts:
Tabela 12. Alterações nos Comandos do CLP e nos Comandos do Sistema DB2
Comando Resumo das alterações
CREATE
DATABASE
Existe uma nova cláusula AUTOMATIC STORAGE. Esse comando
executa automaticamente o comando AUTOCONFIGURE.
GET SNAPSHOT A saída de comando inclui novos campos e os valores para os
campos existentes foram alterados.
140 Guia de Migração
Tabela 12. Alterações nos Comandos do CLP e nos Comandos do Sistema
DB2 (continuação)
Comando Resumo das alterações
INSPECT Existe uma nova cláusula ROWCOMPESTIMATE para estimar a
efetividade da compactação de linha para uma tabela.
EXPORT Os modificadores de tipo de arquivo LOBSINFILE e CODEPAGE
podem ser especificados juntos. O nome do arquivo lob gerado anexa
a extensão .lob após o número de seqüência de 3 dígitos.
IMPORT Os modificadores de tipo de arquivo LOBSINFILE e CODEPAGE
podem ser especificados juntos. Uma linha é rejeitada se um arquivo
LOB não for localizado (O mesmo aplica-se ao comando LOAD).
LIST TABLESPACES O campo Conteúdo na saída de comando tem novos valores:
v Todos os dados permanentes. Espaço de tabela regular
v Todos os dados permanentes. Espaço de tabelas grande
RECOVER
DATABASE
A opção RESTART força o utilitário de recuperação a refazer a fase
de restauração e a ignorar qualquer operação de recuperação anterior
que tenha falhado na conclusão
REORG
INDEXES/TABLE
Novas opções disponíveis são RESETDICTIONARY e
KEEPDICTIONARY.
RESET DB CFG O comando reconfigura os parâmetros de configuração do banco de
dados para os valores de configuração pré-banco de dados. As
opções SELF_TUNING_MEMORY e AUTO_RUNSTATS serão
configuradas como ON.
RESTORE
DATABASE
A nova opção GENERATE SCRIPT gera um script de restauração
redirecionado a partir de uma imagem de backup existente.
ROLLFORWARD
DATABASE
A Hora Universal Coordenada (UTC) e a hora local são formatos de
entrada válidos. O formato do time stamp de saída é o mesmo que o
especificado no formato de entrada.
db2atld Esse comando não é mais suportado. Consulte para obter detalhes
sobre como utilizar o comando LOAD em seu lugar.
db2batch O comando é executado somente no modo CLI. As opções -p e -cli
foram removidas. Existem várias novas opções incluindo -iso para
especificar o nível de isolamento.
db2icrt e db2iupdt A opção -w não está mais disponível.
db2licm A opção -l tem uma nova cláusula SHOW DETAIL opcional. As
opções -c, -g e -x são novas.
db2look A nova opção -xs exporta todos os arquivos necessários para
registrar esquemas XML e DTDs no banco de dados de destino e
gera comandos apropriados para registrá-los.
db2pd As opções -stack e -dump são novas.
db2sampl As opções -path e -k não estão mais disponíveis. Existem novas
opções para especificar o diretório no qual criar os arquivos de banco
de dados, o nome do banco de dados de amostra e mais.
As chamadas de API do DB2 correspondentes aos comandos listados na
Tabela 12 na página 140 também foram alteradas. Reveja as alterações para
cada função de API do DB2 e modifique as chamadas de função
correspondentes em seus aplicativos de banco de dados.
Alterações da Sintaxe de Instruções SQL
A sintaxe de determinadas instruções SQL foi alterada. A tabela a seguir
lista as alterações de sintaxe para instruções SQL que podem afetar
Capítulo 18. Princípios de Migração para Aplicativos de Banco de Dados 141
aplicativos e scripts:
Tabela 13. Alterações de Sintaxe em Instruções SQL
Instrução SQL Resumo das alterações
ALTER TABLE v A nova cláusula DROP DISTRIBUTION substitui DROP
PARTITIONING KEY e a nova cláusula PARTITIONING KEY
ADD DISTRIBUTE BY HASH substitui ADD PARTITIONING KEY.
v Outras novas cláusulas são DROP COLUMN, ALTER COLUMN
SET DATA TYPE, SET NOT NULL e DROP NOT NULL.
CREATE INDEX Até 64 colunas podem ser especificadas como chave de índice. A
nova cláusula NOT PARTITIONED indica que deve ser criado um
único índice que estende todas as partições de dados definidas para
a tabela. Existem novas cláusulas para a especificação de índice XML.
SET INTEGRITY A cláusula FOR tem opções novas e alteradas. O processamento de
integridade on-line está disponível através da utilização das novas
opções ALLOW NO ACCESS, ALLOW READ ACCESS e ALLOW
WRITE ACCESS para definir o acesso à tabela enquanto ela está
sendo processada para integridade. Outras novas opções são
GENERATE IDENTITY e ALLOW QUERY OPTIMIZATION.
Alterações das Visualizações e Rotinas Administravas SQL e Visualizações de
Catálogo
Após a migração do banco de dados para o DB2 Versão 9, as visualizações
de catálogo sob o esquema SYSCAT continuam compatíveis com
visualizações de catálogo definidas no DB2 UDB Versão 8. No entanto, a
coluna COLNAMES em SYSIBM.INDEXES e SYSCAT.INDEXES está
obsoleta no DB2 Versão 9 e será removida em um futuro release. Para obter
as mesmas informações, consulte a tabela SYSCAT.INDEXCOLUSE. Além
disso, embora a estrutura de visualização SYSCAT.BUFFERPOOLS não
tenha sido alterada, o valor da coluna ESTORE está configurado como 'N'
durante a migração do banco de dados, pois o armazenamento estendido
para conjuntos de buffers não é mais suportado no DB2 Versão 9. A coluna
ESTORE foi removida de SYSIBM.SYSBUFFERPOOLS.
As rotinas Administrativas SQL incluem alterações, tais como novos
parâmetros, novas colunas retornadas e substituição pelas funções e
visualizações de tabela definidas pelo usuário. Além disso, todas as
funções de tabela definidas pelo sistema com nomes que começam com
SNAPSHOT_ estão obsoletas no DB2 Versão 9. Reveja a lista de Rotinas
administrativas SQL obsoletas e suas rotinas ou visualizações de
substituição para determinar as alterações que podem afetar seus
aplicativos.
Pacotes de Banco de Dados
Quando você migra um banco de dados, todos os pacotes para aplicativos
de usuários e rotinas são colocados em um estado inválido. Os pacotes
também são colocados em um estado inválido se forem dependentes de
um objeto de banco de dados que você eliminou, como tabelas,
visualizações, aliases, índices, acionadores, restrições de referência e
restrições de verificação de tabela. Se você eliminar uma UDF, seu pacote
será colocado em um estado inoperante.
Embora os pacotes inválidos sejam automaticamente religados pelo
gerenciador de banco de dados quando o otimizador precisa de acesso,
você deve religar seus pacotes de banco de dados para controlar a
ocorrência de religações.
142 Guia de Migração
Alterações do Suporte a 32 Bits e a 64 Bits
Nos sistemas operacionais Linux e UNIX, excluindo o Linux no x86, o DB2
Versão 9 suporta somente kernels de 64 bits e instâncias de 64 bits.
Portanto, quando você migra para o DB2 Versão 9, suas instâncias de 32
bits do DB2 UDB Versão 8 são migradas para instâncias de 64 bits.
As instâncias de 64 bits do DB2 Versão 9 nos sistemas operacionais Linux e
UNIX, exceto para o sistema operacional Linux em IPF (Itanium Platform
Family), incluem bibliotecas compartilhadas de 32 bits. As instâncias de 64
bits do DB2 Versão 9 no Linux no IPF incluem somente bibliotecas
compartilhadas de 64 bits. Se você tiver aplicativos de 32 bits que acessam
bancos de dados nessas instâncias de 64 bits, é necessário garantir a ligação
de seu aplicativo com o caminho de biblioteca compartilhada correto para
executar de forma bem-sucedida.
A tabela a seguir indica os aplicativos que serão executados após você
migrar para o DB2 Versão 9:
Tabela 14. Caminhos de Bibliotecas Compartilhadas Utilizados em Aplicativos de Bancos de
Dados DB2
Aplicativo Instância
Caminhos de biblioteca compartilhada
incorporados
32 bits 32 bits $INSTHOME/sqllib/lib
$INSTHOME/sqllib/lib32
32 bits 64 bits (exceto
Linux em IPF)
$INSTHOME/sqllib/lib1
$INSTHOME/sqllib/lib32
64-bit 64-bit $INSTHOME/sqllib/lib2
$INSTHOME/sqllib/lib64
Notas:
1. $INSTHOME/sqllib/lib é um link simbólico para $INSTHOME/sqllib/lib32
2. $INSTHOME/sqllib/lib é um link simbólico para $INSTHOME/sqllib/lib64
Em que INSTHOME é o diretório home da sua instância.
Durante a instalação do DB2 Versão 9, instruções são incluídas no arquivo
db2profile para configurar as variáveis de ambiente para o caminho da
procura da biblioteca. A tabela a seguir mostra as configurações das
variáveis de ambiente do caminho da biblioteca para cada sistema
operacional:
Tabela 15. Configurações de Variáveis de Ambiente para o Caminho da Procura da
Biblioteca
Variáveis de ambiente Aplicativo
Caminhos de
bibliotecas
compartilhadas
v LIBPATH (AIX)
v LD_LIBRARY_PATH (HP-UX, Linux e
Solaris)
v SHLIB_PATH (HP-UX no PA32)
32 bits INSTHOME1/sqllib/lib32
Capítulo 18. Princípios de Migração para Aplicativos de Banco de Dados 143
Tabela 15. Configurações de Variáveis de Ambiente para o Caminho da Procura da
Biblioteca (continuação)
Variáveis de ambiente Aplicativo
Caminhos de
bibliotecas
compartilhadas
v LIBPATH (AIX)
v LD_LIBRARY_PATH (HP-UX, Linux e
Solaris)
v SHLIB_PATH (HP-UX no PA32)
64 bits INSTHOME/sqllib/lib64
LIB (Windows) 32 bits em
instância de 64
bits
DB2PATH2\lib\Win32
LIB (Windows) 32 bits ou 64 bits DB2PATH\lib
Estas variáveis de ambiente especificam locais adicionais onde bibliotecas
compartilhadas do DB2 podem ser carregadas no tempo de execução do
aplicativo, permitindo que seu aplicativo seja executado após migrar para
o DB2 Versão 9, mas se você não tiver especificado o caminho correto de
biblioteca compartilhada.
Alterações no Comportamento do Servidor DB2
Existem novas variáveis de registro, novos parâmetros de configuração de
banco de dados e de gerenciador de banco de dados e novos valores
padrão para esses parâmetros e que poderiam afetar o comportamento ou
o desempenho do seu aplicativo. Reveja Alterações em variáveis de
registro, parâmetros de configuração e características de design físico do
banco de dados DB2 para avaliar esse impacto.
Após a migração do servidor DB2, você precisa comparar seus valores de
variável de registro e parâmetro de configuração com os valores anteriores
à migração.
Suporte à Conectividade de Clientes DB2
Seus aplicativos podem utilizar clientes DB2 Versão 8 para acessar bancos
de dados em servidores DB2 Versão 9. No entanto, somente a
funcionalidade do DB2 UDB Versão 8 está disponível para seu aplicativo.
Reveja os princípios de migração para clientes DB2 para obter detalhes
sobre a conectividade do cliente e para identificar as alterações no suporte
que podem afetar os clientes DB2.
Conceitos Relacionados:
v Capítulo 17, “Visão Geral da Migração para Aplicativos de Banco de Dados e
Rotinas”, na página 137
v Capítulo 23, “Tarefas de Pós-migração para Aplicativos de Banco de Dados e
Rotinas”, na página 181
v Capítulo 20, “Tarefas de Pré-migração para Aplicativos de Banco de Dados e
Rotinas”, na página 151
v “LOBs em Aplicativos JDBC com o IBM DB2 Driver para JDBC e SQLJ” em
Desenvolvendo Aplicativos Java
Tarefas Relacionadas:
v “Migrando Aplicativos de Banco de Dados” na página 153
v “Migrando Rotinas” na página 167
144 Guia de Migração
v “Planejando a Migração para Aplicativos de Banco de Dados e Rotinas” na
página 11
Referência Relacionada:
v “APIs e Estruturas de Dados Alteradas” em Administrative API Reference
Capítulo 18. Princípios de Migração para Aplicativos de Banco de Dados 145
146 Guia de Migração
Capítulo 19. Princípios de Migração para Rotinas
Os princípios de migração descrevem alterações no suporte ao desenvolvimento de
aplicativos, alterações para suportar novos recursos, recursos não-suportados e
recursos obsoletos que podem afetar suas rotinas. As alterações descritas nos
princípios de migração para aplicativos de banco de dados também podem afetar
suas rotinas.
Suporte ao software de desenvolvimento
As informações sobre o suporte ao software de desenvolvimento nos
princípios de migração para aplicativos de banco de dados aplicam-se aos
procedimentos armazenados externos e às UDFs (funções definidas pelo
usuário).
Procedimentos armazenados externos de 32 bits e UDFs
Os procedimentos armazenados externos não limitados de 32 bits e as
UDFs são suportados somente nas instâncias de 32 bits do DB2 Versão 9 e
não serão executados nas instâncias de 64 bits do DB2 Versão 9. Se você
migrou de uma instância de 32 bits do DB2 Versão 8 para uma instância de
64 bits do DB2 Versão 9, será necessário alterá-las para procedimentos
armazenados ou UDFs limitados ou reconstruí-las como bibliotecas de
rotina de 64 bits.
A implementação para localizadores de LOB depende do produto do banco
de dados DB2 instalado. Se você migrar de uma instância de 32 bits do
DB2 UDB Versão 8 para uma instância de 64 bits do DB2 Versão 9, será
necessário reconstruir rotinas externas de 32 bits que utilizem localizadores
de LOB como bibliotecas de rotina de 64 bits.
O suporte para pontos de entrada de função padrão em bibliotecas de
rotina externas está obsoleto no DB2 Versão 9. Caso tenha migrado de uma
instância de 32 bits do DB2 UDB Versão 8 nos sistemas operacionais AIX
ou Windows, você deverá especificar um ponto de entrada explícito para a
biblioteca de rotina.
Procedimentos armazenados SQL
Os procedimentos armazenados SQL que você criou no DB2 UDB Versão
8.1 serão executados no DB2 Versão 9 se você migrar de uma instância de
32 bits do DB2 UDB Versão 8 para uma instância de 32 bits do DB2 Versão
9, contanto que eles não façam referência a nenhum recurso suportado. O
mesmo se aplica se você migrar de uma instância de 64 bits do DB2 UDB
Versão 8 para uma instância de 64 bits do DB2 Versão 9. No entanto, se
você migrar de uma instância de 32 bits do DB2 UDB Versão 8 para uma
instância de 64 bits do DB2 Versão 9, seus procedimentos SQL não serão
executados porque as rotinas C externas declaradas não limitadas não são
mais suportadas no DB2 Versão 9 e o caminho da biblioteca compartilhada
aponta para bibliotecas de 32 bits. Você deve eliminar e recriar esses
procedimentos SQL.
Se você criou procedimentos armazenados SQL no DB2 UDB Versão 8.2 e
migrar seus bancos de dados para o DB2 Versão 9, os procedimentos
armazenados SQL serão migrados para o código executável do DB2 Versão
9 e funcionarão de forma bem-sucedida, desde que não façam referência a
© Direitos Autorais IBM Corp. 2006 147
nenhum recurso não-suportado. Se surgir algum problema após a
migração, você pode simplesmente eliminar e recriar esses procedimentos
armazenados.
Rotinas Externas Java
O DB2 Versão 9 instala uma JVM de 32 bits por padrão nos sistemas
operacionais Linux no x86 e Windows (quando o produto de 32 bits do
DB2 Versão 9 está instalado). Para todos os outros sistemas operacionais
suportados, o DB2 Versão 9 instala uma JVM de 64 bits. Nos sistemas
operacionais Linux e UNIX, essa JVM é ligada ao diretório
INSTHOME/sqllib/java/jdk32 para uma instância de 32 bits e ao diretório
INSTHOME/sqllib/java/jdk64 para uma instância de 64 bits, em que
INSTHOME é configurado para o diretório do proprietário home da
instância.
Se você migrar uma instância para o DB2 Versão 9, o parâmetro jdk_path é
configurado com o seguinte valor:
Tabela 16. jdk_path configuration parameter settings
Instância do DB2 Versão 9 Sistema Operacional valor de jdk_path
instância de 32 bits Linux e UNIX INSTHOME/sqllib/java/jdk32
instância de 64 bits Linux e UNIX INSTHOME/sqllib/java/jdk64
instância de 32 bits ou de 64
bits
Windows DB2PATH\java\jdk
Nas instâncias de 64 bits do DB2 Versão 9, as rotinas externas Java
requerem que o parâmetro jdk_path seja configurado para um caminho de
instalação JVM de 64 bits para ser executado com êxito. Os procedimentos
armazenados Java de 32 bits e as UDFs falharão em uma instância de 64
bits do DB2 Versão 9.
O Developer Workbench Substitui o Centro de Desenvolvimento
No DB2 Versão 9, o Developer Workbench substitui o Centro de
Desenvolvimento do DB2 UDB Versão 8. O Developer Workbench é uma
ferramenta baseada em Eclipse que inclui funcionalidade que é comparável
ao Centro de Desenvolvimento junto com recursos adicionais. O Developer
Workbench fornece um assistente para migrar projetos existentes do Centro
de Desenvolvimento no Developer Workbench.
Conceitos Relacionados:
v Capítulo 17, “Visão Geral da Migração para Aplicativos de Banco de Dados e
Rotinas”, na página 137
v Capítulo 23, “Tarefas de Pós-migração para Aplicativos de Banco de Dados e
Rotinas”, na página 181
v Capítulo 20, “Tarefas de Pré-migração para Aplicativos de Banco de Dados e
Rotinas”, na página 151
v “O Que Há de Novo na V9.1: O Developer Workbench Substitui o Development
Center” em O que Há de Novo
Tarefas Relacionadas:
v “Migrando Rotinas” na página 167
v “Planejando a Migração para Aplicativos de Banco de Dados e Rotinas” na
página 11
148 Guia de Migração
v “Religando Pacotes em Bancos de Dados Migrados” na página 102
Capítulo 19. Princípios de Migração para Rotinas 149
150 Guia de Migração
Capítulo 20. Tarefas de Pré-migração para Aplicativos de
Banco de Dados e Rotinas
Antes de migrar seus aplicativos de banco de dados e rotinas, você deve executar
determinadas tarefas para ajudar a garantir uma migração bem-sucedida.
Prepare-se para a migração dos aplicativos de banco de dados e rotinas executando
as seguintes tarefas:
1. Reveja os Capítulo 18, “Princípios de Migração para Aplicativos de Banco de
Dados” para determinar quais alterações podem afetar seus aplicativos de
banco de dados.
2. Reveja os Capítulo 19, “Princípios de Migração para Rotinas” para determinar
quais alterações podem afetar suas rotinas.
3. Planeje sua estratégia de migração.
4. Faça upgrade do sistema operacional para um nível suportado, se for
necessário.
5. Faça upgrade do nível suportado, se for necessário.
6. Opcional: Migre seu cliente DB2 ou instale um driver de aplicativo Versão 9,
caso seu aplicativo exija um. Embora o DB2 Versão 9 forneça suporte à
conectividade para clientes DB2 anteriores, a migração para um cliente da
Versão 9 do DB2 elimina quaisquer limitações e incompatibilidades entre
releases.
7. Teste seus aplicativos de banco de dados em um ambiente de teste do DB2
Versão 9. Se o teste for bem-sucedido, não será necessário migrar seus
aplicativos. No entanto, reveja a tarefa Migrando Aplicativos de Banco de
Dados e considere a execução de quaisquer etapas que possam ajudá-lo a
aprimorar o desempenho.
8. Teste suas rotinas em um ambiente de teste do DB2 Versão 9. Se o teste for
bem-sucedido, você não precisa migrar suas rotinas. No entanto, reveja a tarefa
Migrando Rotinas e considere a execução de quaisquer etapas que possam
ajudá-lo a aprimorar o desempenho.
Conceitos Relacionados:
v “Teste de Benchmark” em Performance Guide
v Capítulo 17, “Visão Geral da Migração para Aplicativos de Banco de Dados e
Rotinas”, na página 137
v “Arquivos de Amostra” nos Tópicos de Amostra
Tarefas Relacionadas:
v “Verificando a Migração dos Servidores DB2” na página 105
© Direitos Autorais IBM Corp. 2006 151
152 Guia de Migração
Capítulo 21. Migrando Aplicativos de Banco de Dados
Este capítulo descreve como migrar seus aplicativos de banco de dados. Ele
contém as seguintes seções:
v “Migrando Aplicativos de Banco de Dados”
v “Migrando Aplicativos SQL e CLI Incorporados” na página 155
v “Migrando Aplicativos Java que Utilizam IBM DB2 Driver para JDBC e SQLJ”
na página 157
v “Migrando Aplicativos Java que Utilizam Driver JDBC Tipo 2 ou Tipo 3 do DB2”
na página 159
v “Migrando Aplicativos ADO.NET” na página 160
v “Migrando Scripts” na página 162
v “Migrando Aplicativos de Banco de Dados de 32 Bits para Execução em
Instâncias de 64 Bits” na página 164
Migrando Aplicativos de Banco de Dados
Se você migrar seus servidores DB2 do DB2 UDB Versão 8 para o DB2 Versão 9,
talvez seja preciso migrar os aplicativos de banco de dados para suportar as
alterações no DB2 Versão 9. A migração dos seus aplicativos envolve a modificação
do código e a reconstrução dos aplicativos.
Teste seus aplicativos de banco de dados em um ambiente de testes do DB2 Versão
9. Se eles forem executados com êxito, não será necessário alterá-los. Você só
precisa modificar o código do aplicativo para remover a utilização de
funcionalidade obsoleta ou não-suportada no DB2 Versão 9 ou se quiser utilizar
novos recursos.
Pré-requisitos:
v Reveja os princípios de migração para aplicativos de banco de dados para
identificar quaisquer alterações que se aplicam a seus aplicativos.
v Certifique-se de ter acesso a um servidor DB2 Versão 9, incluindo instâncias e
bancos de dados. O servidor DB2 pode fazer parte de um ambiente de teste.
v Certifique-se de que o sistema operacional esteja em um nível de versão que seja
suportado pelos produtos do banco de dados do DB2.
v Certifique-se de que o software de desenvolvimento esteja em um nível de
versão que seja suportado pelos produtos do banco de dados do DB2.
v Execute as tarefas de pré-migração para aplicativos de banco de dados.
Restrições:
Esse procedimento aplica-se somente a aplicativos de banco de dados programados
nas linguagens C, C++, COBOL, FORTRAN, Java, Perl, PHP, REXX e .NET.
Procedimento:
Para migrar seus aplicativos de banco de dados para o DB2 Versão 9:
1. Se você identificou alterações no DB2 Versão 9 que afetam seus aplicativos,
edite o código do aplicativo ou scripts a serem modificados:
© Direitos Autorais IBM Corp. 2006 153
v Sintaxe de instruções SQL
v Instruções SQL que utilizam visualizações de catálogo e visualizações e
rotinas Administrativas de SQL
v Chamadas de API do DB2
v Chamadas da interface de programação de aplicativos, como JDBC, ODBC e
CLI2. Se você identificou alterações específicas do ambiente de desenvolvimento que
afetam seus aplicativos, modifique-os para suportar essas alterações. Migre:
v seus Aplicativos SQL incorporados
v seus aplicativos Java que utilizam o IBM DB2 Driver para JDBC e SQLJ ou
que utilizam o driver JDBC Tipo 2 ou Tipo 3 do DB2.
v seus aplicativos ADO e .NET.
v seus scripts que utilizam comandos CLP do DB2.
v seus aplicativos de banco de dados de 32 bits para execução em instâncias de
64 bits3. Reconstrua todos os aplicativos de banco de dados programados em C/C++,
COBOL, FORTRAN e REXX utilizando o arquivo de construção DB2
apropriado e especificando o caminho da biblioteca compartilhada DB2
apropriado, conforme mostrado na Tabela 15 na página 143.
4. Teste os aplicativos de banco de dados para garantir que eles sejam executados
conforme esperado utilizando o DB2 Versão 9.
Após a migração dos aplicativos de banco de dados, execute as tarefas de
pós-migração para aplicativos de banco de dados que são recomendadas para
garantir que sua migração foi bem-sucedida.
Conceitos Relacionados:
v Capítulo 18, “Princípios de Migração para Aplicativos de Banco de Dados”, na
página 139
v Capítulo 20, “Tarefas de Pré-migração para Aplicativos de Banco de Dados e
Rotinas”, na página 151
v “Introdução ao Desenvolvimento de Aplicativos de Bancos de Dados” em
Introdução ao Database Application Development
Tarefas Relacionadas:
v “Migrando Aplicativos SQL e CLI Incorporados” na página 155
v “Migrando Aplicativos Java que Utilizam IBM DB2 Driver para JDBC e SQLJ”
na página 157
v “Migrando Aplicativos Java que Utilizam Driver JDBC Tipo 2 ou Tipo 3 do DB2”
na página 159
v “Migrando Aplicativos ADO.NET” na página 160
v “Migrando Scripts” na página 162
v “Migrando Aplicativos de Banco de Dados de 32 Bits para Execução em
Instâncias de 64 Bits” na página 164
v “Configurando o Ambiente de Desenvolvimento de Aplicativos do UNIX” em
Introdução ao Database Application Development
v “Configurando o Ambiente de Desenvolvimento de Aplicativos do Windows”
em Introdução ao Database Application Development
Referência Relacionada:
154 Guia de Migração
v “Linguagens de Programação e Compiladores Suportados para Desenvolvimento
de Aplicativos de Bancos de Dados” em Introdução ao Database Application
Development
v “APIs e Estruturas de Dados Alteradas” em Administrative API Reference
Migrando Aplicativos SQL e CLI Incorporados
Para garantir que os aplicativos SQL e CLI incorporados que você construiu para o
DB2 UDB Versão 8 funcionem com o DB2 Versão 9, você deve migrar esses
aplicativos.
As etapas que devem ser executadas para migrar seus aplicativos dependem:
v Do sistema operacional
v Da largura do bit do aplicativo (32 bits ou 64 bits)
v Da largura do bit da instância do DB2 na qual os aplicativos serão
implementados (32 bits ou 64 bits)
Pré-requisitos:
v Reveja os princípios de migração para aplicativos para identificar
alterações-chave que podem ser aplicadas em suas rotinas.
v Certifique-se de ter acesso a um servidor DB2 Versão 9, incluindo instâncias e
bancos de dados. O servidor DB2 pode fazer parte de um ambiente de teste.
v Certifique-se de que o sistema operacional esteja em um nível de versão que seja
suportado pelos produtos do banco de dados do DB2.
v Certifique-se de que o software de desenvolvimento C, C++, COBOL, FORTRAN
ou REXX esteja em um nível de versão que seja suportado pelos produtos do
banco de dados DB2.
v Execute as tarefas de pré-migração para aplicativos de banco de dados.
Restrições:
Esse procedimento aplica-se somente a aplicativos de banco de dados programados
em C, C++, COBOL, FORTRAN e REXX.
Procedimento:
Para migrar seus aplicativos SQL e CLI incorporados para o DB2 Versão 9:
1. Se você modificou as variáveis de ambiente do caminho da biblioteca,
certifique-se de que essas variáveis incluam o caminho correto da biblioteca
compartilhada do DB2 para os aplicativos, conforme mostrado na Tabela 15 na
página 143. As variáveis de ambiente listadas nessa tabela especificam
caminhos adicionais para permitir que seus aplicativos localizem a biblioteca
compartilhada apropriada do DB2 no tempo de execução (na maioria dos
casos).
No sistema operacional Linux: se você ligar um aplicativo utilizando a opção
de link RPATH sem especificar também a opção de link RUNPATH, a variável
de ambiente LD_LIBRARY_PATH será ignorada no tempo de execução do
aplicativo, o que pode causar a falha do seu aplicativo.
2. Teste os aplicativos SQL incorporados em um ambiente de teste do DB2 Versão
9. Se o teste for bem-sucedido, não será necessário executar nenhuma etapa
adicional.
Capítulo 21. Migrando Aplicativos de Banco de Dados 155
3. Se você identificou alterações no DB2 Versão 9 que afetam seus aplicativos,
edite o código do aplicativo a ser modificado:
v Sintaxe de instruções SQL
v Instruções SQL que utilizam visualizações de catálogo e visualizações e
rotinas Administrativas de SQL
v Chamadas de API do DB2
v Chamadas da interface de programação de aplicativos, tais como ODBC e
CLI
Você pode executar o pré-compilador DB2 para verificar a sintaxe das
instruções SQL em seus aplicativos de banco de dados e determinar se será
necessário fazer alguma alteração.
4. Para especificar explicitamente o caminho correto da biblioteca compartilhada
do DB2 para seus aplicativos, faça o seguinte:
v Se o código fonte do aplicativo estiver disponível, reconstrua o aplicativo.
Especifique o caminho da biblioteca compartilhada requerida do DB2,
conforme mostrado na Tabela 15 na página 143. Essa é a melhor opção.
v Crie um script de wrapper para executar seu aplicativo. No script de
wrapper, configure explicitamente a variável de ambiente do caminho da
biblioteca para o caminho da biblioteca compartilhada requerida do DB2,
conforme mostrado na Tabela 15 na página 143.
v Caso não tenha o código fonte original disponível, execute o comando
db2chglibpath para atualizar o caminho da biblioteca de tempo de execução
incorporado no código binário do aplicativo. Esse comando é fornecido no
estado em que se encontra e, portanto, deve ser considerado como último
recurso.5. Para aplicativos que você não reconstruiu, mas modificou, religue os pacotes de
aplicativo SQL incorporado ao banco de dados DB2 de destino. Durante a
migração do banco de dados, os pacotes existentes para aplicativos SQL
incorporados são invalidados.
6. Teste os aplicativos SQL e CLI incorporados para garantir que eles sejam
executados conforme esperado utilizando o DB2 Versão 9.
Após migrar os aplicativos SQL e CLI incorporados, execute as tarefas de
pós-migração para aplicativos de banco de dados que são recomendadas.
Conceitos Relacionados:
v Capítulo 19, “Princípios de Migração para Rotinas”, na página 147
v Capítulo 20, “Tarefas de Pré-migração para Aplicativos de Banco de Dados e
Rotinas”, na página 151
v “Construindo Aplicativos SQL Incorporados” em Desenvolvendo Aplicativos SQL
Incorporados
v “Introdução ao CLI DB2 e ODBC” em Guia e Referência para Interface Call Level,
Volume 1
v “Introdução ao SQL Incorporado” em Desenvolvendo Aplicativos SQL Incorporados
v Capítulo 18, “Princípios de Migração para Aplicativos de Banco de Dados”, na
página 139
Tarefas Relacionadas:
v “Religando Pacotes em Bancos de Dados Migrados” na página 102
v “Construindo Aplicativos CLI no UNIX” em Guia e Referência para Interface Call
Level, Volume 1
156 Guia de Migração
v “Construindo Aplicativos CLI no Windows” em Guia e Referência para Interface
Call Level, Volume 1
v “Configurando o Ambiente CLI” em Guia e Referência para Interface Call Level,
Volume 1
v “Configurando o Ambiente de Desenvolvimento SQL Incorporado” em
Desenvolvendo Aplicativos SQL Incorporados
v “Migrando Rotinas C, C++ e COBOL” na página 169
Referência Relacionada:
v “Linguagens de Programação e Compiladores Suportados para Desenvolvimento
de Aplicativos de Bancos de Dados” em Introdução ao Database Application
Development
v “Suporte para CLI DB2 e API ODBC no Driver IBM DB2 para ODBC e CLI” em
Guia e Referência para Interface Call Level, Volume 1
Migrando Aplicativos Java que Utilizam IBM DB2 Driver para JDBC e
SQLJ
Para garantir que os aplicativos de banco de dados Java construídos para o DB2
UDB Versão 8 utilizando IBM DB2 Driver para JDBC e SQLJ funcionem de forma
bem-sucedida com o DB2 Versão 9, você deve migrá-los.
Pré-requisitos:
v Reveja os princípios de migração para aplicativos para identificar
alterações-chave que podem afetar seus aplicativos de banco de dados Java.
v Certifique-se de ter acesso a um servidor DB2 Versão 9, incluindo instâncias e
bancos de dados. O servidor DB2 pode fazer parte de um ambiente de teste.
v Certifique-se de que o sistema operacional esteja em um nível de versão que seja
suportado pelos produtos do banco de dados do DB2.
v Certifique-se de que o software de desenvolvimento do aplicativo Java esteja em
um nível de versão que seja suportado pelos produtos do banco de dados DB2.
v Execute as tarefas de pré-migração para aplicativos de banco de dados.
Restrições:
v O Java SDK mínimo suportado é o Java SDK 1.4.2.
v Esse procedimento aplica-se somente a aplicativos Java que utilizam o IBM DB2
Driver para JDBC e SQLJ.
Procedimento:
Para migrar seus aplicativos de banco de dados Java utilizando o IBM DB2 Driver
para JDBC e SQLJ para o DB2 Versão 9:
1. Se for requerido, atualize os aplicativos para gerenciar as seguintes diferenças
entre o DB2 UDB Versão 8 e o DB2 Versão 9. Você pode gerenciar algumas
dessas diferenças configurando as propriedades de objeto Connection ou
DataSource sem nenhuma modificação no código fonte do aplicativo:
v Para continuar utilizando localizadores de LOB em vez da recuperação de
LOB utilizando execução de fluxo progressivo, configure a propriedade
fullyMaterializeLobData como false e configure a propriedade
progressiveStreaming como:DB2BaseDataSource.NO no objeto Connection ou
DataSource.
Capítulo 21. Migrando Aplicativos de Banco de Dados 157
v Para manter o mesmo valor padrão, configure o valor sendDataAsIs como
false para que o IBM DB2 Driver para JDBC e SQLJ converta os valores do
parâmetro de entrada em tipos de dados da coluna de destino. Se você
configurar a propriedade sendDataAsIs como true, o IBM DB2 Driver para
JDBC e SQLJ não converterá os dados de entrada em tipos de dados da
coluna de destino, mesmo que as informações estejam disponíveis no objeto
Connection ou DataSource.
v Para remover a utilização da atualização posicionada do JDBC 1.0 antes de
ele se tornar não-suportado, você deve modificar seus aplicativos para
utilizar o método JDBC 2.02. Se você identificou alterações no DB2 Versão 9 que afetam seus aplicativos,
atualize o código do aplicativo a ser modificado:
v Sintaxe de instruções SQL
v Instruções SQL que utilizam visualizações de catálogo e visualizações e
rotinas Administrativas de SQL
v Chamadas JDBC3. Se você alterou o código fonte do aplicativo Java, reconstrua o aplicativo Java.
Consulte uma das tarefas a seguir para obter detalhes sobre como
reconstruí-los:
v Construindo aplicativos JDBC
v Construindo aplicativos SQLJ4. Teste seus aplicativos Java para garantir que eles sejam executados conforme o
esperado utilizando o DB2 Versão 9.
Diante da conclusão dessa tarefa, seu aplicativo Java deve funcionar de forma
bem-sucedida utilizando o DB2 Versão 9.
Após migrar seus aplicativos Java, execute as tarefas de pós-migração para
aplicativos de banco de dados que são recomendadas.
Conceitos Relacionados:
v Capítulo 19, “Princípios de Migração para Rotinas”, na página 147
v “Software de Desenvolvimento de Aplicativo Java Suportado” em Desenvolvendo
Aplicativos Java
v Capítulo 20, “Tarefas de Pré-migração para Aplicativos de Banco de Dados e
Rotinas”, na página 151
v “LOBs em Aplicativos JDBC com o IBM DB2 Driver para JDBC e SQLJ” em
Desenvolvendo Aplicativos Java
v “Introdução ao Desenvolvimento de Aplicativos Java para DB2” em
Desenvolvendo Aplicativos Java
v Capítulo 18, “Princípios de Migração para Aplicativos de Banco de Dados”, na
página 139
Tarefas Relacionadas:
v “Especificando Capacidades de Atualização, Rolagem e Retenção para ResultSets
em Aplicativos JDBC” em Desenvolvendo Aplicativos Java
v “Construindo Aplicativos JDBC” em Desenvolvendo Aplicativos Java
v “Construindo Programas SQLJ” em Desenvolvendo Aplicativos Java
v “Instalando o IBM DB2 Driver para JDBC e SQLJ” em Desenvolvendo Aplicativos
Java
158 Guia de Migração
Migrando Aplicativos Java que Utilizam Driver JDBC Tipo 2 ou Tipo 3
do DB2
O driver JDBC Tipo 3 do DB2, que estava obsoleto no DB2 Versão 8, não é mais
suportado e, portanto, não é fornecido com o DB2 Versão 9. Você deve migrar seus
aplicativos Java para o IBM DB2 Driver para JDBC e SQLJ.
O driver JDBC Tipo 2 do DB2 está obsoleto. Embora seus aplicativos Java que
utilizam o driver JDBC Tipo 2 do DB2 continuarão funcionando com êxito com o
DB2 Versão 9, a migração desses aplicativos para o IBM DB2 Driver para JDBC e
SQLJ o mais rápido possível ajudará você a evitar possíveis problemas de suporte
em futuros releases.
Pré-requisitos:
v Reveja os princípios de migração para aplicativos para identificar
alterações-chave que podem afetar seus aplicativos de banco de dados Java.
v Certifique-se de ter acesso a um servidor DB2 Versão 9, incluindo instâncias e
bancos de dados. O servidor DB2 pode fazer parte de um ambiente de teste.
v Certifique-se de que o sistema operacional esteja em um nível de versão que seja
suportado pelos produtos do banco de dados do DB2.
v Certifique-se de que o software de desenvolvimento do aplicativo Java esteja em
um nível de versão que seja suportado pelos produtos do banco de dados DB2.
v Execute as tarefas de pré-migração para aplicativos de banco de dados.
Restrição:
v O Java SDK mínimo suportado é o Java SDK 1.4.2.
Procedimento:
Para migrar seus aplicativos de banco de dados Java para o DB2 Versão 9:
1. Instale o IBM DB2 Driver para JDBC e SQLJ.
2. Atualize seus aplicativos Java para utilizar o IBM DB2 Driver para JDBC e
SQLJ.
3. Reveja as informações nos seguintes tópicos para identificar as diferenças de
comportamento entre drivers que podem afetar seu aplicativo Java:
v Suporte a driver para APIs JDBC
v Diferenças de JDBC entre o IBM DB2 Driver para JDBC e SQLJ e outros
drivers JDBC do DB2
v Diferenças de SQLJ entre o IBM DB2 Driver para JDBC e SQLJ e outros
drivers JDBC do DB24. Atualize seus aplicativos Java para resolver quaisquer problemas criados pelas
diferenças de comportamento que você identificou na etapa anterior. Essas
alterações podem incluir a modificação de chamadas de métodos existentes e a
remoção da utilização de recursos não-suportados no DB2 Versão 9.
5. Se você identificou alterações no DB2 Versão 9 que afetam seus aplicativos Java,
atualize o código de aplicativo a ser modificado:
v Sintaxe de instruções SQL
v Instruções SQL que utilizam visualizações de catálogo e visualizações e
rotinas Administrativas de SQL
Capítulo 21. Migrando Aplicativos de Banco de Dados 159
6. Se você alterou o código fonte do aplicativo Java em alguma das etapas
anteriores, reconstrua os aplicativos Java. Consulte uma das tarefas a seguir
para obter detalhes sobre como reconstruí-los:
v Construindo aplicativos JDBC
v Construindo aplicativos SQLJ7. Teste seus aplicativos Java para garantir que eles sejam executados conforme o
esperado utilizando o DB2 Versão 9.
Após migrar seus aplicativos Java, desempenhe as tarefas de pós-migração para
aplicativos de banco de dados recomendadas para garantir que a migração foi
bem-sucedida.
Conceitos Relacionados:
v Capítulo 19, “Princípios de Migração para Rotinas”, na página 147
v “Software de Desenvolvimento de Aplicativo Java Suportado” em Desenvolvendo
Aplicativos Java
v Capítulo 20, “Tarefas de Pré-migração para Aplicativos de Banco de Dados e
Rotinas”, na página 151
v “Introdução ao Desenvolvimento de Aplicativos Java para DB2” em
Desenvolvendo Aplicativos Java
v Capítulo 18, “Princípios de Migração para Aplicativos de Banco de Dados”, na
página 139
Tarefas Relacionadas:
v “Instalando o IBM DB2 Driver para JDBC e SQLJ” em Desenvolvendo Aplicativos
Java
v “Conectando à Origem de Dados Utilizando a Interface DriverManager com o
IBM DB2 Driver para JDBC e SQLJ” em Desenvolvendo Aplicativos Java
v “Construindo Aplicativos JDBC” em Desenvolvendo Aplicativos Java
v “Construindo Programas SQLJ” em Desenvolvendo Aplicativos Java
v “Migrando Aplicativos Java que Utilizam IBM DB2 Driver para JDBC e SQLJ”
na página 157
v “Migrando Rotinas Java” na página 171
Referência Relacionada:
v “Suporte ao Driver para APIs JDBC” em Desenvolvendo Aplicativos Java
v “Diferenças de JDBC entre o IBM DB2 Driver para JDBC e SQLJ e Outros
Drivers DB2 JDBC” em Desenvolvendo Aplicativos Java
v “Diferenças de SQLJ entre o IBM DB2 Driver para JDBC e SQLJ e Outros Drivers
DB2 JDBC” em Desenvolvendo Aplicativos Java
Migrando Aplicativos ADO.NET
Para garantir que os aplicativos ADO.NET que você construiu para o DB2 UDB
Versão 8 funcionem de forma bem-sucedida com o DB2 Versão 9, você precisa
migrá-los. A migração de seus aplicativos ADO.NET pode exigir que você os
reconstrua.
160 Guia de Migração
Não é necessário reconstruir aplicativos ADO.NET que utilizam o OLE DB .NET
Data Provider ou o ODBC .NET Data Provider para executar com o DB2 Versão 9.
No entanto, a migração desses aplicativos para o DB2 .NET Data Provider pode ser
benéfica pelas seguintes razões:
v O DB2 .NET Data Provider tem um conjunto de APIs muito mais extensivo que
os provedores de dados OLE DB e ODBC .NET.
v O acesso às ferramentas de produtividade de desenvolvimento do banco de
dados IBM é integrado com Visual Studio.
v A utilização do DB2 .NET Data Provider pode trazer aprimoramentos
significativos para o desempenho.
Pré-requisitos:
v Reveja os princípios de migração para aplicativos para identificar
alterações-chave que podem se aplicadas em aplicativos ADO.NET.
v Certifique-se de ter acesso a um servidor DB2 Versão 9, incluindo instâncias e
bancos de dados. O servidor DB2 pode fazer parte de um ambiente de teste.
v Certifique-se de que o sistema operacional esteja em um nível de versão que seja
suportado pelos produtos do banco de dados do DB2.
v Certifique-se de que uma versão suportada do software .NET Framework esteja
instalada no computador cliente do banco de dados DB2.
v Execute as tarefas de pré-migração para aplicativos de banco de dados.
Procedimento:
Para migrar seus aplicativos ADO.NET para o DB2 Versão 9:
1. Se você identificou alterações no DB2 Versão 9 que afetam seus aplicativos,
edite o código do aplicativo a ser modificado:
v Sintaxe de instruções SQL
v Instruções SQL que utilizam visualizações de catálogo e visualizações e
rotinas Administrativas de SQL2. Reconstrua seus aplicativos ADO.NET que utilizam o DB2 .NET Data Provider,
fazendo referência a um DB2 .NET Data Provider para DB2 Versão 9. O DB2
Versão 9 apresenta duas versões do DB2 .NET Data Provider:
v uma para o .NET Framework Versão 1.1
v uma para o .NET Framework Versão 2.0, que é o provedor de dados
altamente otimizado para o DB2 Versão 9 e que possui um conjunto super
estendido de recursos, caso você planeje desenvolver ainda mais seus
aplicativos.3. Teste seus aplicativos ADO.NET para garantir que eles sejam executados
conforme esperado utilizando o DB2 Versão 9.
Após migrar seus aplicativos ADO.NET, execute as tarefas de pós-migração para
aplicativos de banco de dados que são recomendadas.
Conceitos Relacionados:
v “Software de Desenvolvimento .NET Suportado” em Desenvolvendo Aplicativos
ADO.NET e OLE DB
v Capítulo 20, “Tarefas de Pré-migração para Aplicativos de Banco de Dados e
Rotinas”, na página 151
v Capítulo 18, “Princípios de Migração para Aplicativos de Banco de Dados”, na
página 139
Capítulo 21. Migrando Aplicativos de Banco de Dados 161
v “Desenvolvimento ADO.NET para Bancos de Dados do DB2” em Desenvolvendo
Aplicativos ADO.NET e OLE DB
v “DB2 .NET Data Provider” em Desenvolvendo Aplicativos ADO.NET e OLE DB
v “Integração com o DB2 no Visual Studio” em Desenvolvendo Aplicativos ADO.NET
e OLE DB
v “Limitações para Aplicativos ADO” em Desenvolvendo Aplicativos ADO.NET e
OLE DB
v “ODBC .NET Data Provider” em Desenvolvendo Aplicativos ADO.NET e OLE DB
v “OLE DB .NET Data Provider” em Desenvolvendo Aplicativos ADO.NET e OLE DB
Migrando Scripts
Talvez você precise migrar seus scripts que utilizam comandos do CLP
(processador de linha de comandos) DB2, comandos ou instruções SQL do sistema
DB2 devido a alterações no DB2 Versão 9 relacionadas a instruções SQL, comandos
do sistema e do CLP DB2, visualizações e rotinas Administrativas SQL e
visualizações de catálogo.
Pré-requisitos:
v Reveja os princípios de migração para aplicativos de banco de dados para
identificar quaisquer alterações que se aplicam a seus scripts.
v Certifique-se de ter acesso a um servidor DB2 Versão 9, incluindo instâncias e
bancos de dados.
v Assegure que um cliente DB2 Versão 9 esteja instalado.
v Certifique-se de que o sistema operacional esteja em um nível de versão que seja
suportado pelos produtos do banco de dados e software de desenvolvimento do
DB2.
v Certifique-se de que o software de desenvolvimento esteja em um nível de
versão que seja suportado pelos produtos do banco de dados do DB2.
v Execute as tarefas de pré-migração para aplicativos de banco de dados.
Restrições:
Esse procedimento aplica-se somente a scripts que utilizam comandos do CLP
DB2, comandos do sistema DB2 ou instruções SQL.
Procedimento:
Para migrar seus scripts com comandos CLP DB2 para o DB2 Versão 9:
1. Execute seus scripts para detectar quaisquer incompatibilidades com o DB2
Versão 9. Se seus scripts forem executados com êxito, não será necessário
executar nenhuma etapa adicional. No entanto, considere a execução das etapas
2 a 5 para remover recursos obsoletos do DB2 Versão 9 antes que eles não
sejam mais suportados ou para utilizar nova funcionalidade de comando.
2. Edite seus scripts e corrija a sintaxe para instruções SQL.
3. Edite seus scripts e corrija a sintaxe para os comandos do CLP e do sistema
DB2. Remova as opções de comando que não estão mais disponíveis. Utilize
novas opções, onde elas estiverem disponíveis, para obter novos detalhes na
saída de comando ou para acessar nova funcionalidade.
4. Se seus scripts lêem a partir da saída de comando, você precisará modificar
seus scripts para poder ler as alterações na saída. O texto da saída de comando
para os comandos GET SNAPSHOT e LIST TABLESPACES foi alterado. Reveja
162 Guia de Migração
os princípios de migração para aplicativos de banco de dados para obter
detalhes sobre as alterações de comando do DB2.
5. Se seus scripts executarem captura instantânea ou monitoramento de eventos,
você precisará modificar seus scripts para remover referências a elementos de
monitoramento não-suportados ou utilizar um novo nome quando eles forem
substituídos por um novo elemento de monitoramento.
6. Edite seus scripts para utilizar as novas visualizações e rotinas Administrativas
SQL no DB2 Versão 9. Embora as visualizações e rotinas Administrativas SQL
do DB2 Versão 8 estejam disponíveis para compatibilidade, você deve modificar
seus scripts para utilizar as novas visualizações e rotinas da Versão 9 antes que
as visualizações e rotinas da Versão 8 não sejam mais suportadas. A utilização
de novas visualizações e rotinas requer que você:
v Altere os nomes de visualização em suas consultas.
v Altere os nomes de coluna em suas consultas para colunas que foram
renomeadas na nova visualização ou rotina.
v Remova nomes de coluna de suas consultas para colunas que não estão
disponíveis na nova visualização.
v Substitua * em suas consultas por uma lista específica de nomes de coluna
que você deseja receber como um conjunto de resultados porque o conjunto
de resultados da nova visualização possui colunas adicionais.
v Altere nomes de rotinas e nomes de parâmetros e indique novos parâmetros
adicionais.
v Modifique seu script para processar colunas adicionais em um conjunto de
resultados ao chamar uma nova rotina ou ao consultar uma nova
visualização que retorna colunas adicionais.7. Teste seus scripts para garantir que eles sejam executados conforme esperado
utilizando o DB2 Versão 9.
Após migrar seus aplicativos de banco de dados, execute as tarefas de
pós-migração para aplicativos de banco de dados que são recomendadas.
Conceitos Relacionados:
v Capítulo 18, “Princípios de Migração para Aplicativos de Banco de Dados”, na
página 139
v Capítulo 20, “Tarefas de Pré-migração para Aplicativos de Banco de Dados e
Rotinas”, na página 151
Referência Relacionada:
v “Linguagens de Programação e Compiladores Suportados para Desenvolvimento
de Aplicativos de Bancos de Dados” em Introdução ao Database Application
Development
v “Opções do Processador da Linha de Comandos” em Command Reference
v “db2 - Comando de Chamada do Processador de Linha de Comandos” em
Command Reference
v “Amostras de CLP (Processador da Linha de Comandos)” nos Tópicos de Amostra
Capítulo 21. Migrando Aplicativos de Banco de Dados 163
Migrando Aplicativos de Banco de Dados de 32 Bits para Execução
em Instâncias de 64 Bits
Se você migrar de uma instância de 32 bits do DB2 Versão 8 para uma instância de
64 bits do DB2 Versão 9 que inclua bibliotecas compartilhadas de 32 bits, será
necessário garantir que seus aplicativos de banco de dados de 32 bits estejam
ligados ao caminho da biblioteca compartilhada apropriado para executá-los de
forma bem-sucedida.
Não é necessário modificar seus aplicativos de banco de dados de 32 bits caso eles
tenham sido ligados ao caminho da biblioteca compartilhada $INSTHOME/sqllib/lib32 no Linux e UNIX ou ao caminho da biblioteca compartilhada
DB2PATH\lib\Win32 no Windows, em que INSTHOME é o diretório home da
instância e DB2PATH é o local da cópia do DB2.
Pré-requisitos:
v Reveja os princípios de migração para aplicativos de banco de dados para
identificar quaisquer alterações que se aplicam a seus scripts.
v Assegure que você tenha acesso a uma instância do DB2 UDB Versão 8 de 32
bits que você migrou para uma instância do DB2 Versão 9 de 64 bits que inclui
bibliotecas compartilhadas de 32 bits.
v Certifique-se de que o sistema operacional esteja em um nível de versão que seja
suportado pelos produtos do banco de dados do DB2.
v Certifique-se de que o software de desenvolvimento esteja em um nível de
versão que seja suportado pelos produtos do banco de dados do DB2.
v Execute as tarefas de pré-migração para aplicativos de banco de dados.
Restrições:
v Esse procedimento aplica-se somente a aplicativos de banco de dados de 32 bits
programados em C/C++, COBOL, FORTRAN e REXX.
v Esse procedimento indica somente as alterações que são requeridas para
executar os aplicativos de banco de dados de 32 bits em uma instância de 64 bits
que inclui bibliotecas compartilhadas de 32 bits. Verifique os princípios de
migração para aplicativos de banco de dados para ver se é necessário aplicar
alterações adicionais em seus aplicativos.
Procedimento:
Para migrar aplicativos de banco de dados de 32 bits para executar em uma
instância de 64 bits do DB2 Versão 9:
1. Certifique-se de que as variáveis de ambiente do caminho da biblioteca incluam
o caminho da biblioteca compartilhada correto do DB2 para bibliotecas de 32
bits, conforme mostrado na Tabela 15 na página 143, para que a biblioteca
correta possa ser carregada no tempo de execução.
2. Teste seus aplicativos de 32 bits em um ambiente de teste do DB2 Versão 9. Se
o teste for bem-sucedido, não será necessário executar nenhuma etapa
adicional. No entanto, considere a execução da etapa 4 na página 165 ou 5 na
página 165, caso elas se apliquem aos seus aplicativos, para aprimorar seu
suporte utilizando o cliente e o caminho da biblioteca compartilhada corretos.
3. Se você identificou alterações no DB2 Versão 9 que afetam seus aplicativos de
32 bits, edite o código do aplicativo a ser modificado:
v Sintaxe de instruções SQL
164 Guia de Migração
v Instruções SQL que utilizam visualizações de catálogo e visualizações e
rotinas Administrativas de SQL
v Chamadas de API do DB2
v Chamadas da interface de programação de aplicativos, tais como ODBC e
CLI4. Especifique o caminho de biblioteca correto vinculando ou reconstruindo seus
aplicativos de 32 bits utilizando os caminhos de biblioteca compartilhada do
DB2 para bibliotecas de 32 bits mostradas na Tabela 15 na página 143.
5. Opcional: Se você não tiver mais o código fonte para reconstruir seus
aplicativos ou se a utilização de variáveis de ambiente não for mais possível,
você pode executar o comando db2chglibpath para alterar o caminho da
biblioteca compartilhada do DB2 para $INSTHOME/sqllib/lib32 no arquivo
binário do aplicativo, contanto que ele tenha um caminho de tempo de
execução incorporado. O caminho de tempo de execução incorporado pode ser
alterado para um novo caminho com o mesmo comprimento ou menor.
6. Teste seus aplicativos de 32 bits para garantir que eles sejam executados o
conforme esperado utilizando o DB2 Versão 9.
Após migrar seus aplicativos de banco de dados de 32 bits, execute as tarefas de
pós-migração para aplicativos de banco de dados que são recomendadas.
Conceitos Relacionados:
v Capítulo 18, “Princípios de Migração para Aplicativos de Banco de Dados”, na
página 139
v Capítulo 20, “Tarefas de Pré-migração para Aplicativos de Banco de Dados e
Rotinas”, na página 151
v “Alterações de Suporte para Servidores DB2 de 32 Bits e 64 Bits” na página 28
Referência Relacionada:
v “Linguagens de Programação e Compiladores Suportados para Desenvolvimento
de Aplicativos de Bancos de Dados” em Introdução ao Database Application
Development
v “db2chglibpath - Modificar o Comando do Caminho de Procura da Biblioteca de
Tempo de Execução Incorporada” em Command Reference
Capítulo 21. Migrando Aplicativos de Banco de Dados 165
166 Guia de Migração
Capítulo 22. Migrando Rotinas
Este capítulo descreve como migrar seus aplicativos de banco de dados. Ele
contém as seguintes seções:
v “Migrando Rotinas”
v “Migrando Rotinas C, C++ e COBOL” na página 169
v “Migrando Rotinas Java” na página 171
v “Migrando Rotinas .NET CLR” na página 174
v “Migrando Procedimentos SQL” na página 175
v “Migrando Rotinas Externas de 32 Bits para Execução em Instâncias de 64 Bits”
na página 177
Migrando Rotinas
Se você migrar seus bancos de dados do DB2 UDB Versão 8 para o DB2 Versão 9,
talvez seja preciso migrar suas rotinas para suportar as alterações no DB2 Versão 9.
A migração de rotinas envolve a modificação do código da rotina, a reconstrução
das rotinas externas, a recriação de rotinas externas no banco de dados e a
recriação de rotinas SQL.
Teste suas rotinas em um ambiente de testes do DB2 Versão 9. Se eles forem
executados com êxito, não será necessário alterá-los. Você só precisa modificar suas
rotinas para remover a utilização de funcionalidade obsoleta ou não-suportada no
DB2 Versão 9 ou se quiser utilizar novos recursos.
Pré-requisitos:
v Reveja os princípios de migração para rotinas para identificar quaisquer
alterações que se aplicam a suas rotinas.
v Assegure que você tenha acesso a bancos de dados DB2 Versão 9 migrados. Eles
podem ser bancos de dados de teste.
v Certifique-se de que o sistema operacional esteja em um nível de versão que seja
suportado pelos produtos do banco de dados do DB2.
v Certifique-se de que o software de desenvolvimento esteja em um nível de
versão que seja suportado pelos produtos do banco de dados do DB2.
v Execute as tarefas pré-migração para rotinas.
v Certifique-se de ter autoridade SYSADM ou DBADM para utilizar as seguintes
instruções SQL:
– ALTER FUNCTION
– ALTER PROCEDURE
Outras autorizações permitidas estão listadas no Command Reference.
Restrições:
Esse procedimento aplica-se apenas a rotinas SQL e rotinas externas programadas
em linguagens C/C++, COBOL (somente procedimentos), Java e .NET.
Procedimento:
© Direitos Autorais IBM Corp. 2006 167
Para migrar suas rotinas para bancos de dados DB2 Versão 9:
1. Se você identificou alterações no DB2 Versão 9 que afetam suas rotinas, edite o
código da rotina e modifique:
v sintaxe da instrução SQL
v instruções SQL utilizando visualizações e rotinas e visualizações de catálogo
Administrativas SQL
v Chamadas da interface de programação de aplicativos, tais como JDBC e CLI2. Se você identificou alterações específicas do ambiente de desenvolvimento que
afetam suas rotinas, modifique-as para suportar essas alterações. Migre:
v suas rotinas C, C++ e COBOL
v suas rotinas Java.
v suas rotinas .NET CLR.
v seus procedimentos SQL armazenados, caso tenha criado os procedimentos
SQL no DB2 Versão 8.1 e tenha migrado de uma instância de 32 bits do DB2
Versão 8 para uma instância de 64 bits do DB2 Versão 9.
v suas rotinas externas de 32 bits para execução em instâncias de 64 bits.3. Se você tiver migrado a partir de uma instância de 32 bits do DB2 Versão 8
para uma instância de 64 bits do DB2 Versão 9, altere os procedimentos
armazenados externos de 32 bits ou UDFs (User-defined Functions) de
desprotegidas para protegidas utilizando as instruções ALTER FUNCTION ou
ALTER PROCEDURE. Por exemplo, a instrução a seguir altera um
procedimento externo para limitado:
ALTER SPECIFIC PROCEDURE schema-name.specific-name FENCED
em que schema-name é o esquema que possui o procedimento externo e
specific-name é o nome específico que identifica exclusivamente um
procedimento que foi indicado ou designado por padrão na criação.
4. Se você migrou de uma instância de 32 bits do DB2 UDB Versão 8 para uma
instância de 64 bits do DB2 Versão 9, será necessário reconstruir rotinas
externas de 32 bits que utilizem localizadores de LOB como bibliotecas de
rotina de 64 bits.
5. Reconstrua todas as bibliotecas de rotina externa alteradas programadas em C e
COBOL utilizando o arquivo de construção apropriado do DB2 e especificando
o caminho da biblioteca compartilhada apropriado do DB2. Para rotinas de 32
bits, especifique $INSTHOME/sqllib/lib32 como o caminho da biblioteca
compartilhada, e para rotinas de 64 bits, especifique $INSTHOME/sqllib/lib64
como o caminho da biblioteca compartilhada, em que INSTHOME é o diretório
home da instância.
6. Teste suas rotinas para garantir que elas sejam executadas conforme esperado
utilizando o DB2 Versão 9.
Esse procedimento descreve as etapas requeridas para migrar suas rotinas em um
alto nível. Consulte as subtarefas de migração na etapa 2 para obter detalhes
adicionais.
Após migrar suas rotinas, execute as tarefas de pós-migração para rotinas que são
recomendadas.
Conceitos Relacionados:
v Capítulo 19, “Princípios de Migração para Rotinas”, na página 147
v Capítulo 20, “Tarefas de Pré-migração para Aplicativos de Banco de Dados e
Rotinas”, na página 151
168 Guia de Migração
v “Linguagens de Programação de Rotina Suportadas” em Developing SQL and
External Routines
Tarefas Relacionadas:
v “Migrando Rotinas C, C++ e COBOL” na página 169
v “Migrando Rotinas Java” na página 171
v “Migrando Rotinas .NET CLR” na página 174
v “Migrando Procedimentos SQL” na página 175
v “Migrando Rotinas Externas de 32 Bits para Execução em Instâncias de 64 Bits”
na página 177
v “Criando Rotinas de Automatização OLE” em Developing SQL and External
Routines
v “Desenvolvendo Rotinas” em Developing SQL and External Routines
Referência Relacionada:
v “Linguagens de Programação e Compiladores Suportados para Desenvolvimento
de Aplicativos de Bancos de Dados” em Introdução ao Database Application
Development
v “Instrução ALTER FUNCTION” em SQL Reference, Volume 2
v “Instrução ALTER PROCEDURE” em SQL Reference, Volume 2
v “DROP statement” em SQL Reference, Volume 2
Migrando Rotinas C, C++ e COBOL
Para garantir que as rotinas C, C++ ou COBOL que você criou antes do DB2
Versão 9 funcionem de forma bem-sucedida, você deve migrá-las.
Pré-requisitos:
v Reveja os princípios de migração para rotinas para identificar alterações-chave
que podem ser aplicadas em suas rotinas.
v Certifique-se de ter acesso a um servidor DB2 Versão 9, incluindo instâncias e
bancos de dados. O servidor DB2 pode fazer parte de um ambiente de teste.
v Certifique-se de que o sistema operacional esteja em um nível de versão que seja
suportado pelos produtos do banco de dados do DB2.
v Certifique-se de que o software de desenvolvimento de rotina C, C++ ou
COBOL esteja em um nível de versão que seja suportado pelos produtos do
banco de dados DB2 revisando os seguintes requisitos:
– Software de desenvolvimento da rotina C suportada
– Software de desenvolvimento da rotina C++ suportada
– Software de desenvolvimento da rotina COBOL suportadav Execute as tarefas pré-migração para rotinas.
v Certifique-se de ter autoridade SYSADM ou DBADM para utilizar as seguintes
instruções:
– ALTER FUNCTION
– ALTER PROCEDURE
Outras autorizações permitidas estão listadas no Command Reference.
Restrições:
Capítulo 22. Migrando Rotinas 169
Esse procedimento aplica-se somente às rotinas externas programadas em C/C++ e
COBOL (somente procedimentos).
Procedimento:
Para migrar uma rotina C, C++ ou COBOL para o DB2 Versão 9, faça o seguinte:
1. Se você identificar alterações no DB2 Versão 9 que afetam suas rotinas, edite o
código da rotina e modifique:
v sintaxe da instrução SQL
v instruções SQL utilizando visualizações e rotinas e visualizações de catálogo
Administrativas SQL2. Se você migrou para uma instância de 64 bits do DB2 Versão 9, altere as
bibliotecas da rotina ou as definições de rotina de acordo com a seguinte tabela:
Tabela 17. Migrando Rotinas C, C++ e COBOL para uma Instância de 64 Bits da Versão 9
Definição da Rotina Ação
biblioteca de rotina
de 32 bits
não-limitada
Proceda de uma das seguintes formas:
v Defina a rotina como limitada e não segura em encadeamento
utilizando a instrução ALTER PROCEDURE ou ALTER
FUNCTION com a cláusula FENCED e a cláusula NOT
THREADSAFE. Você não pode utilizar essa opção se os
localizadores de LOB forem referidos na rotina.
v Reconstrua o código fonte da rotina em uma biblioteca de 64 bits
utilizando o script bldrtn do DB2 Versão 9 e reimplemente a
biblioteca no servidor DB2. Se os localizadores de LOB forem
referidos na rotina, você deve utilizar essa opção. Uma vantagem
dessa abordagem é que a utilização de uma biblioteca de 64 bits
resulta no melhor desempenho do tempo de execução da rotina
do que a utilização de uma biblioteca de 32 bits.
biblioteca de rotina
de 32 bits limitada
Proceda de uma das seguintes formas:
v Defina a rotina como não segura em encadeamento utilizando a
instrução ALTER PROCEDURE ou ALTER FUNCTION com a
cláusula NOT THREADSAFE.
v Reconstrua o código fonte da rotina em uma biblioteca de 64 bits
utilizando scripts bldrtn do DB2 Versão 9 e reimplemente a
biblioteca para o servidor DB2.
migrada de uma
instância de 32 bits
do DB2 UDB Versão
8 (AIX e Windows)
Você deve especificar um ponto de entrada padrão para sua
biblioteca de rotina utilizando a instrução ALTER PROCEDURE ou
ALTER FUNCTION. Por exemplo, para especificar explicitamente o
ponto de entrada para um procedimento existente, utilize a instrução
a seguir:
ALTER SPECIFIC PROCEDURE schema-name.specific-name
EXTERNAL NAME ’library-name!function-name’
em que library-name é a biblioteca a ser carregada e function-name é o
ponto de entrada explícito para a função associada com a rotina.
Se nenhuma das situações mencionadas anteriormente se aplicarem, você não
precisa alterar as bibliotecas de rotina ou as definições de rotina.
3. Para rotinas que você não reconstruiu, mas modificou, religue os pacotes de
rotina ao banco de dados DB2 de destino. Durante a migração do banco de
dados, os pacotes existentes para rotinas são invalidados.
4. Teste suas rotinas para verificar suas alterações e para garantir que as rotinas
sejam executadas conforme esperado utilizando o DB2 Versão 9.
170 Guia de Migração
Após migrar suas rotinas, execute as tarefas de pós-migração para rotinas que são
recomendadas.
Conceitos Relacionados:
v Capítulo 19, “Princípios de Migração para Rotinas”, na página 147
v “Suporte para Desenvolvimento de Rotina Externa em C” em Developing SQL
and External Routines
v “Suporte para Desenvolvimento de Rotina Externa em C++” em Developing SQL
and External Routines
v Capítulo 20, “Tarefas de Pré-migração para Aplicativos de Banco de Dados e
Rotinas”, na página 151
v “Construindo Aplicativos e Rotinas Gravados em C e C++” em Desenvolvendo
Aplicativos SQL Incorporados
v “Construindo Aplicativos e Rotinas Gravados em COBOL” em Desenvolvendo
Aplicativos SQL Incorporados
v “Procedimentos COBOL” em Developing SQL and External Routines
Tarefas Relacionadas:
v “Religando Pacotes em Bancos de Dados Migrados” na página 102
v “Construindo Rotinas da CLI no UNIX” em Guia e Referência para Interface Call
Level, Volume 1
v “Construindo Rotinas da CLI no Windows” em Guia e Referência para Interface
Call Level, Volume 1
v “Configurando o Ambiente CLI” em Guia e Referência para Interface Call Level,
Volume 1
v “Configurando o Ambiente de Desenvolvimento SQL Incorporado” em
Desenvolvendo Aplicativos SQL Incorporados
v “Construindo Código de Rotina C e C++” em Developing SQL and External
Routines
Referência Relacionada:
v “Suporte para Desenvolvimento de Procedimentos Externos no COBOL” em
Developing SQL and External Routines
v “Instrução ALTER FUNCTION” em SQL Reference, Volume 2
v “Instrução ALTER PROCEDURE” em SQL Reference, Volume 2
Migrando Rotinas Java
Após você migrar seus bancos de dados, é necessário migrar as rotinas Java que
você criou antes do DB2 Versão 9 para garantir que elas funcionem conforme
esperado.
Pré-requisitos:
Os seguintes pré-requisitos devem ser atendidos para a execução dessa tarefa:
v Reveja os princípios de migração para rotinas para identificar as alterações-chave
que podem ser aplicadas em suas rotinas Java.
v Certifique-se de ter acesso a um servidor DB2 Versão 9, incluindo instâncias e
bancos de dados. O servidor DB2 pode ser um sistema de teste.
v Certifique-se de que o sistema operacional esteja em um nível de versão que seja
suportado pelos produtos do banco de dados do DB2.
Capítulo 22. Migrando Rotinas 171
v Certifique-se de que o software de desenvolvimento da rotina Java esteja em um
nível de versão que seja suportado pelos produtos do banco de dados DB2.
v Certifique-se de estar utilizando drivers DB2 para JDBC e APIs SQLJ suportados.
v Execute as tarefas pré-migração para rotinas.
v Certifique-se de ter autoridade SYSADM ou DBADM para utilizar as seguintes
instruções:
– ALTER FUNCTION
– ALTER PROCEDURE
Outras autorizações permitidas estão listadas no Command Reference.
Procedimento:
Para migrar suas rotinas Java:
1.
Certifique-se de que o parâmetro de configuração do gerenciador de banco de
dados jdk_path especifique a JVM correta para executar suas rotinas. Determine
o valor atual emitindo o seguinte comando:
db2 GET DBM CFG
Por padrão, o valor do parâmetro de configuração do gerenciador de banco de
dados jdk_path é configurado durante a migração da instância como os valores
mostrados em Tabela 16 na página 148. Caso queira utilizar uma JVM diferente
da instalada em sua cópia do DB2 Versão 9, você deve configurar esse
parâmetro de configuração para o caminho dessa JVM com a mesma largura de
bit que a instância do DB2 atualizando o parâmetro jdk_path:
db2 UPDATE DBM CFG USING jdk_path <JVM-path>
2. Determine e configure o driver Java para o suporte de tempo de execução da
rotina Java. Determine qual driver Java está sendo utilizado para rotinas Java
emitindo o seguinte comando:
db2set DB2_USE_DB2JCCT2_JROUTINE
Se o valor dessa variável de registro for:
v OFF ou não configurado, que é o padrão, suas rotinas Java estarão utilizando
o driver JDBC Tipo 2 do IBM DB2.
v ON, suas rotinas Java estarão utilizando o IBM DB2 Driver para JDBC e
SQLJ.
Utilize o IBM DB2 Driver para JDBC e SQLJ se quiser acessar recursos
particulares desse driver ou se espera utilizar parâmetros XML. Indique que
suas rotinas Java utilizarão esse driver emitindo o seguinte comando para
configurar a variável de registro DB2_USE_DB2JCCT2_JROUTINE como ON no
nível global:
db2set -g DB2_USE_DB2JCCT2_JROUTINE=ON
A opção -g indica que esse valor aplica-se a todas as instâncias em execução na
mesma cópia do DB2 Versão 9.
3. Teste suas rotinas Java no banco de dados DB2 Versão 9. Se o teste for
bem-sucedido e sua rotina Java for executada conforme esperado, você não
precisará executar nenhuma etapa adicional.
4. Se estiver utilizando o IBM DB2 Driver para JDBC e SQLJ e encontrar alguma
diferença no comportamento das rotinas Java, reveja a tarefa migrando
aplicativos Java para aprender como gerenciar essas diferenças.
172 Guia de Migração
5. Se você identificar alterações no DB2 Versão 9 que afetam suas rotinas Java,
edite o código da rotina e modifique:
v sintaxe da instrução SQL
v instruções SQL utilizando visualizações e rotinas e visualizações de catálogo
Administrativas SQL
v Chamadas JDBC6. Define explicitamente suas rotinas Java como limitadas utilizando a instrução
ALTER FUNCTION ou ALTER PROCEDURE com a cláusula FENCED. Todas
as rotinas Java são executadas como limitadas, independentemente de como
elas são definidas, mas a definição da rotina Java como limitada aprimora a
maneabilidade e a manutenção.
7. Opcional: Se a classe da rotina Java estiver incluída em um arquivo JAR que foi
instalado em uma instância do DB2 utilizando um ID de arquivo JAR
específico, certifique-se de que a classe Java seja resolvida o mais rápido
possível pelo gerenciador de banco de dados do DB2 e certifique-se de ter
especificado o ID do arquivo JAR como parte da cláusula EXTERNAL NAME
na definição de rotina. Utilize as instruções ALTER PROCEDURE ou ALTER
FUNCTION para atualizar a cláusula EXTERNAL NAME se for requerido.
8. Se você criou projetos no Centro de Desenvolvimento para desenvolver suas
rotinas Java, migre todos os projetos existentes para o Developer Workbench
utilizando o assistente de migração.
9. Teste suas rotinas Java para garantir que elas sejam executadas conforme
esperado com o DB2 Versão 9.
Após migrar suas rotinas Java, execute as tarefas de pós-migração para rotinas que
são recomendadas.
Conceitos Relacionados:
v Capítulo 19, “Princípios de Migração para Rotinas”, na página 147
v “Software Suportado para Desenvolvimento de Rotinas Java” em Developing SQL
and External Routines
v “Drivers Suportados para JDBC e SQLJ” em Desenvolvendo Aplicativos Java
v Capítulo 20, “Tarefas de Pré-migração para Aplicativos de Banco de Dados e
Rotinas”, na página 151
v “Rotinas Java” em Developing SQL and External Routines
v “Utilizando SQLJ e JDBC no mesmo Aplicativo” em Desenvolvendo Aplicativos
Java
v “O Que Há de Novo na V9.1: Aprimoramentos do Carregador de Classe de
Rotina Java” em O que Há de Novo
Tarefas Relacionadas:
v “Construindo Rotinas JDBC” em Desenvolvendo Aplicativos Java
v “Construindo Rotinas SQLJ” em Desenvolvendo Aplicativos Java
v “Migrando Aplicativos Java que Utilizam Driver JDBC Tipo 2 ou Tipo 3 do DB2”
na página 159
v “Migrando Aplicativos Java que Utilizam IBM DB2 Driver para JDBC e SQLJ”
na página 157
Referência Relacionada:
v “Instrução ALTER FUNCTION” em SQL Reference, Volume 2
v “Instrução ALTER PROCEDURE” em SQL Reference, Volume 2
Capítulo 22. Migrando Rotinas 173
Migrando Rotinas .NET CLR
Após migrar uma instância e bancos de dados DB2 para o DB2 Versão 9, você deve
migrar suas rotinas .NET CLR que foram criadas antes da Versão 9 para garantir
que elas continuem funcionando de forma bem-sucedida e sejam executadas
conforme esperado.
Pré-requisitos:
v Reveja os princípios de migração para rotinas para identificar alterações-chave
que podem ser aplicadas nas rotinas .NET CLR.
v Certifique-se de ter acesso a um servidor DB2 Versão 9, incluindo instâncias e
bancos de dados. O servidor DB2 pode fazer parte de um ambiente de teste.
v Certifique-se de que o sistema operacional esteja em um nível de versão que seja
suportado pelos produtos do banco de dados do DB2.
v Certifique-se de que uma versão suportada do software .NET Framework seja
instalada no servidor DB2.
v Execute as tarefas pré-migração para rotinas.
Procedimento:
Para migrar suas rotinas .NET CLR para o DB2 Versão 9:
1. Se você identificou alterações no DB2 Versão 9 que afetam suas rotinas, edite o
código da rotina e modifique:
v sintaxe da instrução SQL
v instruções SQL utilizando visualizações e rotinas e visualizações de catálogo
Administrativas SQL2. Conecte-se ao banco de dados DB2 Versão 9 no qual você definiu a .NET CLR.
3. Reconstrua o código fonte da rotina .NET CLR utilizando as opções de
compilação e link especificadas no bldrtn.bat, o script de amostra do DB2 para
construção de rotinas .NET CLR.
4. Implemente a montagem da rotina no servidor DB2 no mesmo local
especificado pela cláusula EXTERNAL na definição de rotina.
5. Teste as rotinas .NET CLR. As rotinas devem funcionar com êxito, sem
diferenças de comportamento entre o DB2 UDB Versão 8 e o DB2 Versão 9.
Após migrar suas rotinas .NET CLR, execute as tarefas de pós-migração para
rotinas que são recomendadas.
Conceitos Relacionados:
v Capítulo 19, “Princípios de Migração para Rotinas”, na página 147
v “Software de Desenvolvimento .NET Suportado” em Desenvolvendo Aplicativos
ADO.NET e OLE DB
v Capítulo 20, “Tarefas de Pré-migração para Aplicativos de Banco de Dados e
Rotinas”, na página 151
v “Requisitos do Sistema de Banco de Dados do DB2 .NET Data Provider” em
Desenvolvendo Aplicativos ADO.NET e OLE DB
v “Projetando Rotinas .NET CLR” em Developing SQL and External Routines
v “ODBC .NET Data Provider” em Desenvolvendo Aplicativos ADO.NET e OLE DB
v “DB2 .NET Data Provider” em Desenvolvendo Aplicativos ADO.NET e OLE DB
Tarefas Relacionadas:
174 Guia de Migração
v “Construindo Código de Rotina .NET CLR” em Developing SQL and External
Routines
Referência Relacionada:
v “Opções de Compilação e de Link de Rotinas CLR .NET” em Desenvolvendo
Aplicativos ADO.NET e OLE DB
Migrando Procedimentos SQL
Se você criou seus procedimentos SQL no DB2 UDB Versão 8.2, esses
procedimentos SQL serão migrados quando você migrar seus bancos de dados.
Se você migrou de uma instância do DB2 UDB Versão 8 para uma instância do
DB2 Versão 9 com a mesma largura de bit, suas rotinas serão executadas com êxito
no DB2 Versão 9. No entanto, se você criou seus procedimentos SQL no DB2 UDB
Versão 8.1 e migrou de uma instância de 32 bits do DB2 UDB Versão 8 para uma
instância de 64 bits do DB2 Versão 9, será necessário eliminar e recriar esses
procedimentos SQL.
Pré-requisitos:
v Reveja os princípios de migração para rotinas para identificar alterações-chave
que podem ser aplicadas em seus procedimentos SQL.
v Assegure que você tenha acesso a seu banco de dados migrado no DB2 Versão 9.
v Certifique-se de ter as autorizações e os privilégios necessários para utilizar as
instruções CREATE PROCEDURE e DROP PROCEDURE. É possível localizar a
lista completa de autorizações e privilégios requeridos no SQL Reference.
v Execute as tarefas pré-migração para rotinas.
Restrição:
Esse procedimento aplica-se somente aos procedimentos SQL que foram criados no
DB2 UDB Versão 8.1 anterior ao FixPak 7 ou à Versão 8.2.
Procedimento:
Para migrar seus procedimentos SQL para o DB2 Versão 9:
1. Conecte ao banco de dados migrado.
2. Execute a seguinte consulta para identificar os procedimentos SQL que
precisam ser recriados:
SELECT procschema, specificname
FROM syscat.procedures
WHERE language = ’SQL’and fenced = ’N’AND
substr(IMPLEMENTATION, 10,6) = ’pgsjmp’
Anote o esquema e os valores de nome específicos retornados por essa
consulta, pois você precisará dessas informações para executar etapas
subseqüentes.
3. Execute a ferramenta db2look para gerar um script DDL para todos os objetos
de banco de dados.
db2look -d sample -e -o db2look.sql
Capítulo 22. Migrando Rotinas 175
em que sample é o nome do banco de dados, -e gera instruções DDL para
objetos de banco de dados e -o db2look.sql indica o arquivo de saída que
conterá as instruções DDL.
Edite o arquivo db2look.sql para manter somente as instruções DDL
necessárias para criar os procedimentos SQL que você identificou na etapa 2 na
página 175.
4. Para cada procedimento armazenado SQL que você identificou na etapa 2 na
página 175, utilize a instrução DROP PROCEDURE indicando o nome do
esquema e o nome específico para identificar exclusivamente cada
procedimento:
DROP SPECIFIC PROCEDURE <schema-name>.<specific-name>
Alternativamente, se você tiver um script DDL que elimina e recria seus
procedimentos SQL, edite-o para eliminar e recriar somente os procedimentos
SQL identificados na etapa 2 na página 175 e execute-o. Em seguida, continue
na etapa 6.
5. Recrie os procedimentos SQL identificados na etapa 2 na página 175 utilizando
a instrução CREATE PROCEDURE. Alternativamente, você pode executar seu
próprio script DDL ou o arquivo db2look.sql que você criou na etapa 3 na
página 175.
6. Teste seus procedimentos SQL para garantir que eles sejam executados
conforme esperado no DB2 Versão 9. Você pode utilizar o Developer
Workbench ou a interface do CLP (Processador de Linha de Comandos) para
testá-los. O exemplo a seguir ilustra como chamar um procedimento SQL
utilizando o CLP :
CONNECT TO amostra
Database Connection Information
Servidor de banco de dados = DB2/AIX64 9.1.0
ID de autorização do SQL = TESTDB2
Alias do banco de dados local = SAMPLE
CALL <schema-name>.<procedure-name> ( [<parameter-list>] )
7. Se você criou projetos no Centro de Desenvolvimento para desenvolver seus
procedimentos SQL, migre quaisquer projetos existentes para o Developer
Workbench utilizando o assistente de migração.
Após migrar seus procedimentos SQL, execute as tarefas de pós-migração para
rotinas para garantir que sua migração foi bem-sucedida.
Conceitos Relacionados:
v Capítulo 20, “Tarefas de Pré-migração para Aplicativos de Banco de Dados e
Rotinas”, na página 151
v Capítulo 18, “Princípios de Migração para Aplicativos de Banco de Dados”, na
página 139
v Capítulo 19, “Princípios de Migração para Rotinas”, na página 147
v “Considerações sobre Design de Procedimento SQL” em Developing SQL and
External Routines
v “Desenvolvimento de Rotina SQL no DB2 Developer Workbench” em Developing
SQL and External Routines
v “Rotinas SQL” em Developing SQL and External Routines
Tarefas Relacionadas:
v “Criando Procedimentos SQL” em Developing SQL and External Routines
176 Guia de Migração
v “Migrando Rotinas” na página 167
Referência Relacionada:
v “db2 - Comando de Chamada do Processador de Linha de Comandos” em
Command Reference
v “db2look - Comando da Ferramenta de Estatísticas do DB2 e Extração de DDL”
em Command Reference
v “Instrução CREATE PROCEDURE (SQL)” em SQL Reference, Volume 2
v “DROP statement” em SQL Reference, Volume 2
Migrando Rotinas Externas de 32 Bits para Execução em Instâncias de
64 Bits
Se você migrar de uma instância de 32 bits do DB2 Versão 8 para uma instância de
64 bits do DB2 Versão 9 que inclui bibliotecas compartilhadas de 32 bits, será
necessário garantir que suas rotinas externas de 32 bits estejam vinculadas ao
caminho da biblioteca compartilhada apropriado para uma execução bem-sucedida.
Não é necessário modificar suas rotinas externas de 32 bits caso elas tenham sido
vinculadas ao caminho de biblioteca $INSTHOME/sqllib/lib32 no Linux e no UNIX
ou ao caminho de biblioteca DB2PATH\lib\Win32 no Windows, em que INSTHOME
é o diretório home da instância e DB2PATH é local da cópia do DB2.
Pré-requisitos:
v Reveja os princípios de migração para rotinas para identificar as alterações-chave
que podem ser aplicadas em suas rotinas externas de 32 bits.
v Assegure que você tenha acesso a uma instância do DB2 UDB Versão 8 de 32
bits que você migrou para uma instância do DB2 Versão 9 de 64 bits que inclui
bibliotecas compartilhadas de 32 bits.
v Certifique-se de que o sistema operacional esteja em um nível de versão que seja
suportado pelos produtos do banco de dados do DB2.
v Certifique-se de que o software de desenvolvimento esteja em um nível de
versão que seja suportado pelos produtos do banco de dados do DB2.
v Execute as tarefas pré-migração para rotinas.
v Certifique-se de ter autoridade SYSADM ou DBADM para utilizar as seguintes
instruções SQL:
– ALTER FUNCTION
– ALTER PROCEDURE
Outras autorizações permitidas estão listadas no Command Reference.
Restrições:
v Esse procedimento aplica-se somente a rotinas externas de 32 bits programas em
C e COBOL.
v Esse procedimento indica somente as alterações requeridas para executar as
rotinas externas de 32 bits em uma instância de 64 bits que inclui bibliotecas
compartilhadas de 32 bits.
Procedimento:
Para migrar rotinas externas de 32 bits para executar em uma instância de 64 bits
do DB2 Versão 9:
Capítulo 22. Migrando Rotinas 177
1. Certifique-se de que as variáveis de ambiente do caminho da biblioteca incluam
o caminho da biblioteca compartilhada correto do DB2 para bibliotecas de 32
bits, conforme mostrado na Tabela 15 na página 143, para que a biblioteca
correta possa ser carregada no tempo de execução.
2. Teste suas rotinas em um ambiente de testes do DB2 Versão 9. Se o teste for
bem-sucedido, não será necessário executar nenhuma etapa adicional. No
entanto, considere a execução das etapas 4 a 6 se elas se aplicarem a sua rotina
para um melhor suporte utilizando o caminho de biblioteca e o software de
desenvolvimento corretos.
3. Se as alterações no DB2 Versão 9 afetarem seus aplicativos, edite o código do
aplicativo a ser modificado:
v Sintaxe de instruções SQL
v Instruções SQL que utilizam visualizações de catálogo e visualizações e
rotinas Administrativas de SQL4. Especifique o caminho de biblioteca correto vinculando ou reconstruindo suas
rotinas externas de 32 bits através dos caminhos de biblioteca compartilhada do
DB2 para as bibliotecas de 32 bits mostradas na Tabela 15 na página 143. Se
você migrou de uma instância de 32 bits do DB2 UDB Versão 8 para uma
instância de 64 bits do DB2 Versão 9, será necessário reconstruir rotinas
externas de 32 bits que utilizem localizadores de LOB como bibliotecas de
rotina de 64 bits.
5. Opcional: Se você não tiver mais o código fonte para reconstruir sua biblioteca
de rotina ou para utilizar variáveis de ambiente, é possível utilizar o comando
db2chglibpath para alterar o caminho da biblioteca compartilhada do DB2 para
$INSTHOME/sqllib/lib32 no seu arquivo binário de rotina, contanto que ele
tenha um caminho de tempo de execução incorporado. O caminho de tempo de
execução incorporado pode ser alterado para um novo caminho com o mesmo
comprimento ou menor.
6. Se você migrou de uma instância de 32 bits do DB2 Versão 8 para uma
instância de 64 bits do DB2 Versão 9, altere os procedimentos armazenados
externos de 32 bits ou as UDFs (funções definidas pelo usuário) não limitadas
para limitadas utilizando as instruções ALTER FUNCTION ou ALTER
PROCEDURE. Por exemplo, a instrução a seguir altera um procedimento
externo para limitado:
ALTER SPECIFIC PROCEDURE <schema-name>.<specific-name> FENCED
em que <schema-name> é o esquema que possui o procedimento externo e
<specific-name> é o nome específico que identifica exclusivamente um
procedimento indicado ou designado por padrão na criação.
7. Teste suas rotinas externas de 32 bits. O exemplo a seguir ilustra como executar
um procedimento externo utilizando a interface do processador de linha de
comandos:
CONNECT TO amostra
Database Connection Information
Servidor de banco de dados = DB2/AIX64 9.1.0
ID de autorização do SQL = TESTDB2
Alias do banco de dados local = SAMPLE
CALL schema-name.procedure-name ( [parameter-list] )
Após migrar suas rotinas externas de 32 bits, execute as tarefas de pós-migração
para rotinas que são recomendadas.
Conceitos Relacionados:
178 Guia de Migração
v Capítulo 19, “Princípios de Migração para Rotinas”, na página 147
v Capítulo 20, “Tarefas de Pré-migração para Aplicativos de Banco de Dados e
Rotinas”, na página 151
v “Suporte para Desenvolvimento de Rotina Externa em C++” em Developing SQL
and External Routines
v Capítulo 18, “Princípios de Migração para Aplicativos de Banco de Dados”, na
página 139
v “Alterações de Suporte para Servidores DB2 de 32 Bits e 64 Bits” na página 28
v “Procedimentos COBOL” em Developing SQL and External Routines
v “Suporte para Desenvolvimento de Rotina Externa em C” em Developing SQL
and External Routines
Tarefas Relacionadas:
v “Construindo Código de Rotina C e C++ Utilizando Scripts bldrtn de Amostra”
em Developing SQL and External Routines
Referência Relacionada:
v “Linguagens de Programação e Compiladores Suportados para Desenvolvimento
de Aplicativos de Bancos de Dados” em Introdução ao Database Application
Development
v “db2chglibpath - Modificar o Comando do Caminho de Procura da Biblioteca de
Tempo de Execução Incorporada” em Command Reference
v “Suporte para Desenvolvimento de Procedimentos Externos no COBOL” em
Developing SQL and External Routines
Capítulo 22. Migrando Rotinas 179
180 Guia de Migração
Capítulo 23. Tarefas de Pós-migração para Aplicativos de
Banco de Dados e Rotinas
Após migrar seus aplicativos de banco de dados e rotinas, você deve desempenhar
algumas tarefas de pós-migração para garantir que os aplicativos de banco de
dados e as rotinas desempenhem conforme o esperado e em seus melhores níveis.
Desempenhe as seguintes tarefas de pós-migração que se aplicam aos aplicativos
de banco de dados e às rotinas:
1. Ajuste seus aplicativos de banco de dados. Reveja orientações importantes
relacionadas a:
v Conversão de caractere
v Classe de otimização
v Especificação de nível de isolamento
v Bloqueios e simultaneidade
v Processamento paralelo para aplicativos
v Ajuste de consulta
Consulte o Guia de Administração: Desempenho para obter detalhes completos
sobre como ajustar aplicativos.
2. Ajuste suas rotinas. Reveja orientações importantes relacionadas a:
v Procedimentos armazenados
v Procedimentos SQL
Além disso, reveja orientações sobre o aprimoramento do desempenho de
aplicativos de banco de dados que também se aplicam a rotinas, tais como
orientações sobre classes de otimização, bloqueios, simultaneidade e ajuste de
consulta.
3. Remova dependências de recursos que estão obsoletos no DB2 Versão 9 em
seus aplicativos de banco de dados e rotinas antes que esses recursos não sejam
mais suportados.
4. Comece a utilizar novos recursos no DB2 Versão 9 para desenvolvimento de
aplicativo onde for apropriado para aprimorar o desempenho. Verifique os
arquivos de Amostra para entender como funcionam os novos recursos.
Conceitos Relacionados:
v “Desempenho de Rotinas” em Developing SQL and External Routines
v “Desempenho de Aplicativos SQL Incorporados” em Desenvolvendo Aplicativos
SQL Incorporados
v “Teste de Benchmark” em Performance Guide
v “Dicas de início rápido para ajuste de Desempenho” em Performance Guide
v “Arquivos de Amostra” nos Tópicos de Amostra
Tarefas Relacionadas:
v “Migrando Aplicativos de Banco de Dados” na página 153
v “Migrando Rotinas” na página 167
© Direitos Autorais IBM Corp. 2006 181
182 Guia de Migração
Apêndices
Esta parte do manual contém os seguintes apêndices:
Apêndice A, “DB2 Information Center Versão 9”, na página 185
Apêndice B, “Referências Importantes”, na página 187
Apêndice C, “Informações Técnicas sobre o Banco de Dados DB2”, na página 189
Apêndice D, “Avisos”, na página 201
© Direitos Autorais IBM Corp. 2006 183
184 Guia de Migração
Apêndice A. DB2 Information Center Versão 9
Não é possível migrar uma cópia do DB2 Information Center Versão 8 para o DB2
Versão 9. Entretanto, uma cópia do DB2 Information Center Versão 8 pode coexistir
com uma cópia do DB2 Information Center Versão 9, desde que você especifique
um local diferente ao instalar a cópia da Versão 9.
Considere as seguintes informações ao instalar uma cópia do DB2 Information
Center Versão 9:
v Se você possuir uma cópia do DB2 Information Center Versão 8, ela permanece
intacta ao instalar uma cópia do DB2 Information Center Versão 9. Você deverá
desinstalar a cópia da Versão 8 caso não precise mais dela ou deseje instalar uma
cópia da Versão 9 no mesmo local que o da cópia da Versão 8.
v Caso possua uma cópia do DB2 Information Center Versão 8 instalada no
diretório padrão, é necessário especificar um local e um número de porta
diferentes ao instalar uma cópia do DB2 Information Center Versão 9. O
assistente de configuração do DB2 solicita um local alternativo e indica o
próximo número de porta disponível.
v Você pode instalar apenas uma cópia do DB2 Information Center Versão 9 em
um determinado sistema.
A tabela a seguir mostra a URL para versões específicas do DB2 Information
Center:
Tabela 18. URLs para DB2 Information Centers On-line
Versão do DB2 Information Center URL
Versão 8.2 http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp
Versão 9 http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp
Versão liberada mais recentemente http://publib.boulder.ibm.com/infocenter/db2help/index.jsp
© Direitos Autorais IBM Corp. 2006 185
186 Guia de Migração
Apêndice B. Referências Importantes
A seguinte lista de referências pode ajudá-lo com a migração do seu ambiente DB2:
Página da Web de requisitos do sistema operacional DB2
Os requisitos de sistema operacional e hardware para o DB2 Versão 9 estão
disponíveis no endereço http://www.ibm.com/software/data/db2/udb/sysreqs.html.
Portal de migração do DB2
O portal de migração do DB2 no endereço http://www.ibm.com/support/docview.wss?rs=73&uid=swg21200005 fornece um local único para acesso a
informações atualizadas sobre o processo de migração e recursos
adicionais, conforme disponibilizados.
DB2 Information Center
Você pode localizar as informações neste manual no DB2 Information
Center on-line, no endereço http://publib.boulder.ibm.com/infocenter/db2help/index.jsp sob o tópico Migrando. O título Migrando para o DB2
Versão 9, sob Sistemas de Banco de Dados, é o tópico de nível superior. O
DB2 Information Center on-line também contém informações sobre tópicos
relacionados à migração, tais como a instalação do produto de banco de
dados DB2.
Manuais do DB2 Versão 9 em formato PDF
Os manuais do DB2 Versão 9 em formato PDF estão disponíveis para
download complementar no endereço http://www.ibm.com/software/data/db2/udb/support/manualsv9.html, hospedado pelo Web site de
Suporte Técnico do DB2.
Educação sobre o produto de banco de dados DB2
Revise a lista de cursos auto-didáticos sobre o produto de banco de dados
DB2 complementares que podem ajudá-lo a desenvolver habilidades em
seu próprio ritmo no endereço http://www.ibm.com/software/data/education/selfstudy.html. O Web site Information Management Training
Web, no endereço http://www.ibm.com/software/data/education/,
oferece uma ampla variedade de opções de treinamento e a lista de
recursos de habilidades e comunidades para ajudá-lo a localizar os
recursos educacionais adequados a você.
Web site developerWorks Information Management
O Web site developerWorks Information Management, no endereço
http://www.ibm.com/developerworks/db2, oferece recursos técnicos para
o software DB2 Information Management. Ele apresenta informações sobre
o produto, downloads, recursos de aprendizado, suporte, fóruns e
newsletters. Neste Web site, é possível localizar diversos artigos e tutoriais
que podem ajudá-lo a aprender sobre novos recursos dos produtos de
banco de dados DB2 e como utilizá-los em seus aplicativos.
Este Web site também faz referência a portais de recursos de aprendizado,
tais como New to DB2, Migrate to DB2 e DBA Central. Siga o link Migrate
to DB2 para acessar recursos que podem ajudá-lo a migrar do Microsoft
SQL Server, Oracle, Sybase e outras plataformas de banco de dados para o
DB2
© Direitos Autorais IBM Corp. 2006 187
Fóruns do DB2
O fóruns do DB2, hospedados pelo developerWorks no endereço
http://www.ibm.com/developerworks/forums/db2_forums.jsp, são locais
para trocar idéias e compartilhar soluções com seus colegas na comunidade
do produto IBM DB2. Além disso, os fóruns do DB2 incluem fóruns que
são espelhos para os newsgroups do DB2, tais como os newsgroups
ibm.software.db2.udb e ibm.software.db2.udb.beta.
188 Guia de Migração
Apêndice C. Informações Técnicas sobre o Banco de Dados
DB2
Visão Geral das Informações Técnicas do DB2
As informações técnicas do DB2 estão disponíveis através das seguintes
ferramentas e métodos:
v DB2 Information Center
– Tópicos
– Ajuda para as ferramentas do DB2
– Programas de amostra
– Tutoriaisv Manuais do DB2
– Arquivos PDF (para download)
– Arquivos PDF (a partir do CD de PDFs do DB2)
– Manuais impressosv Ajuda da linha de comandos
– Ajuda do Comando
– Ajuda da Mensagemv Programas de Amostra
A IBM disponibiliza atualizações para suas documentações periodicamente. Se você
acessar a versão on-line do DB2 Information Center no site ibm.com, não será
necessário instalar as atualizações da documentação, uma vez que esta versão
sempre é atualizada pela IBM. Caso tenha instalado o DB2 Information Center,
recomenda-se que você instale as atualizações das documentações. As atualizações
das documentações permitem que você atualize as informações instaladas a partir
do CD do DB2 Information Center ou que foram transferidas por download a partir
do Passport Advantage, conforme novas informações forem disponibilizadas.
Nota: Os tópicos do DB2 Information Center são atualizados com maior freqüência
do que os PDFs ou os manuais impressos. Para obter as informações mais
atualizadas, instale as atualizações das documentações conforme forem
disponibilizadas ou consulte o DB2 Information Center no site ibm.com.
Você poderá acessar informações técnicas adicionais on-line do DB2 como
technotes, white papers e Redbooks, no Web site ibm.com. Acesse o Web site da
biblioteca de software do DB2 Information Management no endereço
http://www.ibm.com/software/data/sw-library/.
Feedback das Documentações
Seu feedback a respeito da documentação do DB2 é importante para nós. Caso
tenha sugestões sobre como podemos aprimorar a documentação do DB2, envie
um e-mail (em inglês) para [email protected]. A equipe de documentação do
DB2 lê todos os feedbacks enviados, mas não poderão responder diretamente a
você. Forneça exemplos específicos sempre que possível, para que melhor
possamos compreender suas preocupações. Caso esteja enviando feedback sobre
um tópico ou arquivo de ajuda específicos, inclua o título do tópico e a URL.
© Direitos Autorais IBM Corp. 2006 189
Não utilize este endereço de e-mail para entrar em contato com o Suporte ao
Cliente doDB2. Caso tenha um problema técnico com o DB2 que não possa ser
resolvido com as informações disponíveis na documentação, entre em contato com
seu centro de serviços IBM local para obter ajuda.
Conceitos Relacionados:
v “Recursos do Information Center do DB2” no Centro de Informação On-line do
DB2
v “Arquivos de Amostra” nos Tópicos de Amostra
Tarefas Relacionadas:
v “Chamado a Ajuda do Comando a partir do Processador da Linha de
Comandos” em Command Reference
v “Chamando a Ajuda da Mensagem a partir do Processador da Linha de
Comandos” em Command Reference
v “Atualizando o Centro de Informações do DB2 Instalado em seu Computador ou
em um Servidor de Intranet” na página 195
Referência Relacionada:
v “Biblioteca Técnica do DB2 em Formato PDF” na página 190
Biblioteca Técnica do DB2 em Formato PDF
As tabelas a seguir descrevem a biblioteca do DB2 disponível a partir do IBM
Publications Center, no endereço www.ibm.com/shop/publications/order.
Embora as tabelas identifiquem os manuais disponíveis em cópia impressa, é
possível que não estejam disponíveis em seu país.
As informações nestes manuais são fundamentais para todos os usuários do DB2;
estas informações podem ser úteis, seja você um programador, administrador de
banco de dados ou alguém que trabalhe com o DB2 Connect ou outros produtos
do DB2.
Tabela 19. Informações Técnicas do DB2
Nome Número do Formulário
Disponível em Cópia
Impressa
Administration Guide:
Implementation
SC10-4221 Sim
Administration Guide: Planning SC10-4223 Sim
Administrative API Reference SC10-4231 Sim
Administrative SQL Routines and
Views
SC10-4293 Não
Call Level Interface Guide and
Reference, Volume 1
SC10-4224 Sim
Call Level Interface Guide and
Reference, Volume 2
SC10-4225 Sim
Command Reference SC10-4226 Não
Data Movement Utilities Guide
and Reference
SC10-4227 Sim
190 Guia de Migração
Tabela 19. Informações Técnicas do DB2 (continuação)
Nome Número do Formulário
Disponível em Cópia
Impressa
Data Recovery and High
Availability Guide and Reference
SC10-4228 Sim
Developing ADO.NET and OLE
DB Applications
SC10-4230 Sim
Developing Embedded SQL
Applications
SC10-4232 Sim
Developing SQL and External
Routines
SC10-4373 Não
Developing Java Applications SC10-4233 Sim
Developing Perl and PHP
Applications
SC10-4234 Não
Getting Started with Database
Application Development
SC10-4252 Sim
Getting started with DB2
installation and administration on
Linux and Windows
GC10-4247 Sim
Message Reference Volume 1 SC10-4238 Não
Message Reference Volume 2 SC10-4239 Não
Migration Guide GC10-4237 Sim
Net Search Extender
Administration and User’s Guide
Nota: Os arquivos HTML
deste documento não serão
instalados a partir do CD de
documentação em HTML.
SH12-6842 Sim
Performance Guide SC10-4222 Sim
Query Patroller Administration
and User’s Guide
GC10-4241 Sim
Quick Beginnings for DB2
Clients
GC10-4242 Não
Quick Beginnings for DB2
Servers
GC10-4246 Sim
Spatial Extender and Geodetic
Data Management Feature User’s
Guide and Reference
SC18-9749 Sim
SQL Guide SC10-4248 Sim
SQL Reference, Volume 1 SC10-4249 Sim
SQL Reference, Volume 2 SC10-4250 Sim
System Monitor Guide and
Reference
SC10-4251 Sim
Troubleshooting Guide GC10-4240 Não
Visual Explain Tutorial SC10-4319 Não
What’s New SC10-4253 Sim
XML Extender Administration
and Programming
SC18-9750 Sim
Apêndice C. Informações Técnicas sobre o Banco de Dados DB2 191
Tabela 19. Informações Técnicas do DB2 (continuação)
Nome Número do Formulário
Disponível em Cópia
Impressa
XML Guide SC10-4254 Sim
XQuery Reference SC18-9796 Sim
Tabela 20. Informações Técnicas Específicas ao DB2 Connect
Nome Número do Formulário
Disponível em Cópia
Impressa
DB2 Connect User’s Guide SC10-4229 Sim
Quick Beginnings for DB2
Connect Personal Edition
GC10-4244 Sim
Quick Beginnings for DB2
Connect Servers
GC10-4243 Sim
Tabela 21. Informações Técnicas sobre o WebSphere Information Integration
Nome Número do Formulário
Disponível em Cópia
Impressa
WebSphere Information
Integration: Administration Guide
for Federated Systems
SC19-1020 Sim
WebSphere Information
Integration: ASNCLP Program
Reference for Replication and
Event Publishing
SC19-1018 Sim
WebSphere Information
Integration: Configuration Guide
for Federated Data Sources
SC19-1034 Não
WebSphere Information
Integration: SQL Replication
Guide and Reference
SC19-1030 Sim
Nota: AS Notas Sobre o Release do DB2 oferecem informações adicionais
específicas aos níveis de release e fix pack do seu produto. Para obter mais
informações, consulte os links relacionados.
Conceitos Relacionados:
v “Visão Geral das Informações Técnicas do DB2” na página 189
v “Sobre as Notas sobre o Release” nas Notas sobre o Release
Tarefas Relacionadas:
v “Solicitando Manuais Impressos do DB2” na página 193
192 Guia de Migração
Solicitando Manuais Impressos do DB2
Os manuais impressos do DB2 não estão disponíveis para compra em todos os
países. Você sempre poderá solicitar manuais impressos do DB2 a partir de seu
representante IBM local. Tenha em mente que alguns manuais em versão eletrônica
no CD de Documentação em PDF do DB2 não estão disponíveis em cópia impressa.
Por exemplo, nenhum volume da publicação DB2 Message Reference está disponível
em meio impresso.
Versões impressas de muitos dos manuais do DB2 disponíveis no CD de
Documentações em PDF do DB2 podem ser solicitados, mediante o pagamento de
uma taxa, junto à IBM. Dependendo do local a partir de onde está solicitando as
publicações, você poderá adquiri-las on-line a partir do IBM Publications Center.
Se a solicitação de manuais através do método on-line não estiver disponível em
seu país ou região, você tem a opção de adquirir manuais impressos do DB2 junto
ao seu representante IBM local. Observe que nem todos os manuais do CD de
Documentações em PDF do DB2 estão disponíveis em meio impresso.
Nota: As documentações mais atualizadas e completas do DB2 são mantidas no
DB2 Information Center, localizado no endereço http://publib.boulder.ibm.com/infocenter/db2help/.
Procedimento:
Para solicitar manuais impressos do DB2:
v Para descobrir se você pode solicitar manuais impressos do DB2 on-line em seu
país ou região, consulte o IBM Publications Center no endereço
http://www.ibm.com/shop/publications/order. Você deve selecionar um país,
uma região ou um idioma para acessar as informações sobre solicitação de
publicação e, em seguida, seguir as instruções de pedido para o seu local.
v Para solicitar manuais impressos do DB2 junto ao seu representante IBM local:
– Localize as informações de contato para seu representante local a partir de
um dos seguintes Web sites:
- O diretório mundial de contatos da IBM, no endereço www.ibm.com/planetwide
- O Web site de Publicações da IBM, no endereço http://www.ibm.com/shop/publications/order. Será necessário selecionar seu país, região ou
idioma para acessar as home pages de publicações voltada para o seu país.
A partir desta página, siga o link ″Sobre este Site″.– Ao ligar, especifique que você deseja solicitar uma publicação do DB2.
– Forneça ao seu representante os títulos e números de formulário dos manuais
que deseja solicitar .
Conceitos Relacionados:
v “Visão Geral das Informações Técnicas do DB2” na página 189
Referência Relacionada:
v “Biblioteca Técnica do DB2 em Formato PDF” na página 190
Apêndice C. Informações Técnicas sobre o Banco de Dados DB2 193
Exibindo Ajuda de Estado SQL a partir do Processador de Linha de
Comandos
O DB2 retorna um valor SQLSTATE para condições que poderiam ser resultantes
de uma instrução SQL. A ajuda de SQLSTATE explica os significados de estados de
SQL e de códigos de classe de estado de SQL.
Procedimento:
Para chamar a ajuda de estado de SQL, abra o processador da linha de comandos e
insira:
? sqlstate ou ? class code
, em que sqlstate representa um estado SQL válido de cinco dígitos e class code
representa os primeiros dois dígitos do estado SQL.
Por exemplo, ? 08003 exibe a ajuda para o estado de SQL 08003 e ? 08 exibe o
auxílio para o código de classe 08.
Tarefas Relacionadas:
v “Chamado a Ajuda do Comando a partir do Processador da Linha de
Comandos” em Command Reference
v “Chamando a Ajuda da Mensagem a partir do Processador da Linha de
Comandos” em Command Reference
Acessando Diferentes Versões do DB2 Information Center
Para os tópicos do DB2 Versão 9, a URL do DB2 Information Center é
http://publib.boulder.ibm.com/infocenter/db2luw/v9/.
Para os tópicos do DB2 Versão 8, acesse a URL do Information Center da Versão 8
no endereço: http://publib.boulder.ibm.com/infocenter/db2luw/v8/.
Tarefas Relacionadas:
v “Configurando Acesso à Ajuda Contextual e Documentação do DB2” em
Administration Guide: Implementation
Exibindo Tópicos em Seu Idioma Preferido no Centro de Informações
do DB2
O DB2 Information Center tenta exibir tópicos no idioma especificados em suas
preferências de navegador. Se um tópico não estiver traduzido para o idioma de
sua preferência, o DB2 Information Center exibirá o tópico em inglês.
Procedimento:
Para exibir tópicos em seu idioma preferido no navegador Internet Explorer:
1. No Internet Explorer, clique em Ferramentas —> Opções da Internet —> botão
Idiomas.... É aberta a janela Preferências de Idioma.
2. Certifique-se de que seu idioma preferido esteja especificado como a primeira
entrada na lista de idiomas.
194 Guia de Migração
v Para incluir um novo idioma na lista, clique no botão Incluir...
Nota: Incluir um idioma não garante que o computador tenha as fontes
requeridas para exibir os tópicos no idioma preferido.
v Para mover um idioma para o início da lista, selecione o idioma e clique no
botão Mover para Cima até que o idioma seja o primeiro na lista de idiomas.3. Limpe a cache do navegador e em seguida atualize a página para exibir o DB2
Information Center no idioma de sua preferência.
Para exibir tópicos no idioma de sua escolha, em um navegador Firefox ou
Mozilla:
1. Selecione o botão Ferramentas —> Opções —> Idiomas. O painel Idiomas é
exibido na janela Preferências.
2. Certifique-se de que seu idioma preferido esteja especificado como a primeira
entrada na lista de idiomas.
v Para incluir um novo idioma na lista, clique no botão Incluir... para
selecionar um idioma a partir da janela Incluir Idiomas.
v Para mover um idioma para o início da lista, selecione o idioma e clique no
botão Mover para Cima até que o idioma seja o primeiro na lista de idiomas.3. Limpe a cache do navegador e em seguida atualize a página para exibir o DB2
Information Center no idioma de sua preferência.
Em algumas combinações de navegadores e sistemas operacionais, pode ser
necessário alterar as configurações regionais de seu sistema operacional para o
código de idioma e idioma de sua escolha.
Conceitos Relacionados:
v “Visão Geral das Informações Técnicas do DB2” na página 189
Atualizando o Centro de Informações do DB2 Instalado em seu
Computador ou em um Servidor de Intranet
Caso tenha um DB2 Information Center instalado localmente, tópicos atualizados
poderão ser disponibilizados para download. O valor 'Última Atualização'
localizado na parte inferior da maioria dos tópicos indica o nível atual do tópico.
Para determinar se existe uma atualização disponível para todo o DB2 Information
Center, procure pelo valor de 'Última Atualização' na home page do Information
Center. Compare o valor em sua home page instalada localmente com a data da
atualização mais recente disponível para download no endereço
http://www.ibm.com/software/data/db2/udb/support/icupdate.html. Em
seguida, você poderá atualizar seu Information Center instalado localmente caso
uma atualização mais recente esteja disponível para download.
A atualização de seu DB2 Information Center instalado localmente requer que
você:
1. Pare o DB2 Information Center em seu computador e reinicie o Information
Center no modo independente. A execução do Information Center no modo
independente evita que outros usuários em sua rede acessem o Information
Center, além de permitir que você faça downloads e aplique as atualizações.
2. Utilize o recurso Atualização para determinar se pacotes de atualização estão
disponíveis junto à IBM.
Apêndice C. Informações Técnicas sobre o Banco de Dados DB2 195
Nota: Atualizações também estão disponíveis em CD. Para obter detalhes sobre
como configurar seu Information Center para instalar atualizações a
partir do CD, consulte os links relacionados.Se algum pacote de atualização estiver disponível, utilize o recurso Atualização
para fazer o download dos pacotes. (O recurso Atualização está disponível
apenas no modo independente.)
3. Pare o Information Center independente e reinicie o serviço DB2 Information
Center em seu computador.
Procedimento:
Para atualizar o DB2 Information Center instalado em seu computador ou servidor
intranet:
1. Pare o serviço DB2 Information Center.
v No Windows, clique em Iniciar → Painel de Controle → Ferramentas
Administrativas → Serviços. Em seguida, clique com o botão direito no
serviço DB2 Information Center e selecione Parar.
v No Linux, digite o seguinte comando:
/etc/init.d/db2icdv9 stop
2. Inicie o Information Center no modo independente.
v No Windows:
a. Abra uma janela de comandos.
b. Navegue até o caminho onde o Information Center está instalado. Por
padrão, o DB2 Information Center é instalado no diretório C:\Arquivos
de Programa\IBM\DB2 Information Center\Version 9.
c. Execute o arquivo help_start.bat utilizando o caminho completo do DB2
Information Center:
<dir do DB2 Information Center>\doc\bin\help_start.bat
v No Linux:
a. Navegue até o caminho onde o Information Center está instalado. Por
padrão, o DB2 Information Center é instalado no diretório
/opt/ibm/db2ic/V9.
b. Execute o script help_start utilizando o caminho completo do DB2
Information Center:
<dir DB2 Information Center>/doc/bin/help_start
O navegador da Web padrão do sistema será ativado para exibir o Information
Center independente.
3. Clique no botão Atualizar (
). No lado direito do painel do Information
Center, clique em Localizar Atualizações. Será exibida uma lista com
atualizações para a documentação existente.
4. Para iniciar o processo de download, verifique as seleções das quais deseja
fazer download e, em seguida, clique em Instalar Atualizações.
5. Após a conclusão dos processos de download e instalação, clique em Concluir.
6. Pare o Information Center independente.
v No Windows, execute o arquivo help_end.bat utilizando o caminho
completo do DB2 Information Center:
<dir DB2 Information Center>\doc\bin\help_end.bat
196 Guia de Migração
Nota: O arquivo em lote help_end contém os comandos necessários para
encerrar com segurança os processos iniciados com o arquivo em lote
help_start. Não utilize Ctrl-C ou qualquer outro método para encerrar
help_start.bat.
v No Linux, execute o script help_end utilizando o caminho completo do DB2
Information Center:
<dir do DB2 Information Center>/doc/bin/help_end
Nota: O script help_end contém os comandos necessários para encerrar com
segurança os processos iniciados com o script help_start. Não utilize
nenhum outro método para encerrar o script help_start.7. Reinicie o serviço DB2 Information Center.
v No Windows, clique em Iniciar → Painel de Controle → Ferramentas
Administrativas → Serviços. Em seguida, clique com o botão direito no
serviço DB2 Information Center e selecione Iniciar.
v No Linux, digite o seguinte comando:
/etc/init.d/db2icdv9 start
O DB2 Information Center atualizado exibirá os tópicos novos e atualizados.
Conceitos Relacionados:
v “Opções de Instalação do Information Center do DB2” em Iniciação Rápida para
DB2 Servers
Tarefas Relacionadas:
v “Instalando o Information Center do DB2 Utilizando o Assistente de
Configuração do DB2 (Linux)” em Iniciação Rápida para DB2 Servers
v “Instalando o Information Center do DB2 Utilizando o Assistente do DB2 Setup
(Windows)” em Iniciação Rápida para DB2 Servers
Tutoriais do DB2
Os tutoriais do DB2 oferecem informações sobre vários aspectos dos produtos DB2.
As lições oferecem instruções passo a passo.
Antes de Iniciar:
Você poderá visualizar a versão em XHTML do tutorial no Information Center,
através do endereço http://publib.boulder.ibm.com/infocenter/db2help/.
Algumas lições utilizam dados ou código de amostra. Consulte o tutorial para
obter uma descrição dos pré-requisitos para suas tarefas específicas.
Tutoriais do DB2:
Para visualizar o tutorial, clique no título.
Armazém de Dados XML Nativo
Configure um banco de dados DB2 para armazenar dados XML e para
realizar as operações básicas com o armazém de dados XML nativo.
Tutorial do Visual Explain
Analisa, otimiza e ajusta instruções SQL para um melhor desempenho
utilizando o Visual Explain.
Apêndice C. Informações Técnicas sobre o Banco de Dados DB2 197
Conceitos Relacionados:
v “Visão Geral do Visual Explain” em Administration Guide: Implementation
Informações sobre Resolução de Problemas do DB2
Uma grande variedade de informações de resolução e determinação de problemas
estão disponíveis para ajudá-lo a utilizar o produto DB2.
Documentação do DB2
As informações para resolução de problemas podem ser encontradas na
publicação DB2 Troubleshooting Guide ou na seção Support and
Troubleshooting do DB2 Information Center. No Information Center você
encontrará informações sobre como isolar e identificar problemas com os
utilitários e ferramentas de diagnóstico do DB2, soluções para alguns dos
problemas mais comuns e outros avisos sobre como resolver problemas
que possam ser encontrados com seus produtos DB2.
Web site de Suporte Técnico do DB2
Consulte o Web site de Suporte Técnico do DB2 caso esteja tendo
problemas e deseje obter ajuda com a localização das possíveis causas e
soluções. O site de Suporte Técnico possui links para as publicações mais
recentes do DB2, TechNotes, APARs (Authorized Program Analysis Reports
ou correções de erros), fix packs e outros recursos. Você pode pesquisar
essa base de conhecimento para localizar as possíveis soluções para seus
problemas.
Acesse o Web site de Suporte Técnico do DB2, no endereço
http://www.ibm.com/software/data/db2/udb/support.html
Conceitos Relacionados:
v “Introdução à Determinação de Problemas” em Troubleshooting Guide
v “Visão Geral das Informações Técnicas do DB2” na página 189
Termos e Condições
As permissões para uso destas publicações são concedidas sujeitas aos seguintes
termos e condições.
Uso Pessoal: Você poderá reproduzir estas Publicações apenas para uso pessoal e
não comercial, contanto que todos os avisos do proprietário sejam preservados. O
Cliente não deve distribuir, exibir ou criar trabalhos derivativos destas Publicações
ou de qualquer parte delas, sem o consentimento expresso da IBM.
Uso Comercial O Cliente poderá reproduzir, distribuir e exibir essas Publicações
somente dentro da empresa do Cliente, contanto que todos os avisos do
proprietário sejam preservados. O Cliente você não poderá criar trabalhos
derivativos destas Publicações ou reproduzir, distribuir ou exibir estas Publicações
ou qualquer parte delas fora de sua empresa, sem o consentimento expresso da
IBM.
Exceto quando concedido expressamente nesta permissão, não são conhecidas
outras permissões, licenças ou direitos, sejam expressos ou implícitos, em relação
às Publicações ou quaisquer informações, dados, software ou qualquer outra
propriedade intelectual nelas contidas.
198 Guia de Migração
A IBM se reserva no direito de retirar as permissões aqui concedidas sempre que,
de acordo com seus critérios, o uso das Publicações foi prejudicial aos seus
interesses ou, conforme determinado pela IBM, as instruções acima não sejam
seguidas.
O Cliente não poderá fazer download, exportar ou re-exportar estas informações
exceto quando em conformidade total com todas as leis e regulamentações
aplicáveis, incluindo todas as leis e regulamentações de exportação dos Estados
Unidos.
A IBM NÃO FAZ QUALQUER TIPO DE GARANTIA QUANTO AO CONTEÚDO
DESTAS PUBLICAÇÕES. AS PUBLICAÇÕES SÃO FORNECIDAS ″NO ESTADO
EM QUE SE ENCONTRAM″, SEM GARANTIA DE NENHUM TIPO, SEJA
EXPRESSA OU IMPLÍCITA, INCLUINDO, MAS NÃO SE LIMITANDO ÀS
GARANTIAS IMPLÍCITAS (OU CONDIÇÕES) DE NÃO-INFRAÇÃO,
COMERCIALIZAÇÃO OU ADEQUAÇÃO A UM DETERMINADO PROPÓSITO.
Apêndice C. Informações Técnicas sobre o Banco de Dados DB2 199
200 Guia de Migração
Apêndice D. Avisos
É possível que a IBM não ofereça os produtos, serviços ou recursos discutidos
nesta publicação em outros países. Consulte um representante IBM local para obter
informações sobre produtos e serviços disponíveis atualmente em sua área.
Qualquer referência a produtos, programas ou serviços IBM não significa que
apenas produtos, programas ou serviços IBM possam ser utilizados. Qualquer
produto, programa ou serviço funcionalmente equivalente, que não infrinja
nenhum direito de propriedade intelectual da IBM (ou quaisquer outros direitos da
IBM), poderá ser utilizado em substituição a este produto, programa ou serviço.
Entretanto a avaliação e verificação da operação de qualquer produto, programa ou
serviço não-IBM são de responsabilidade do Cliente.
A IBM pode ter patentes ou solicitações de patentes pendentes relativas a assuntos
tratados nesta publicação. O fornecimento desta publicação não garante ao Cliente
nenhum direito sobre tais patentes. Pedidos de licença devem ser enviados, por
escrito, para:
Gerência de Relações Comerciais e Industriais da IBM Brasil
Av. Pasteur 138-146
Botafogo
Rio de Janeiro - RJ
CEP 22290-240
Para pedidos de licença relacionados a informações de DBCS (Conjunto de
Caracteres de Byte Duplo), entre em contato com o Departamento de Propriedade
Intelectual da IBM em seu país ou envie pedidos de licença, por escrito, para:
IBM World Trade Asia Corporation
Licensing
2-31 Roppongi 3-chome, Minato-ku
Tokyo 106, Japan
O parágrafo a seguir não se aplica a nenhum país em que tais disposições não
estejam de acordo com a legislação local: A INTERNATIONAL BUSINESS
MACHINES CORPORATION FORNECE ESTA PUBLICAÇÃO “NO ESTADO EM
QUE SE ENCONTRA” SEM GARANTIA DE NENHUM TIPO, SEJA EXPRESSA
OU IMPLÍCITA, INCLUINDO, MAS NÃO SE LIMITANDO ÀS GARANTIAS
IMPLÍCITAS DE NÃO-VIOLAÇÃO, MERCADO OU ADEQUAÇÃO A UM
DETERMINADO PROPÓSITO. Alguns países não permitem a exclusão de
garantias expressas ou implícitas em certas transações; portanto, esta disposição
pode não se aplicar ao Cliente.
Esta publicação pode incluir imprecisões técnicas ou erros tipográficos.
Periodicamente, são feitas alterações nas informações aqui contidas; tais alterações
serão incorporadas em futuras edições desta publicação. A IBM pode, a qualquer
momento, aperfeiçoar e/ou alterar os produtos e/ou programas descritos nesta
publicação, sem aviso prévio.
Referências nestas informações a Web sites não-IBM são fornecidas apenas por
conveniência e não representam de forma alguma um endosso a estes Web sites.
Os materiais contidos nesses Web sites não fazem parte dos materiais desse
produto IBM e a utilização desses Web sites é de inteira responsabilidade do
Cliente.
© Direitos Autorais IBM Corp. 2006 201
A IBM pode utilizar ou distribuir as informações fornecidas da forma que julgar
apropriada sem incorrer em qualquer obrigação para com o Cliente.
Licenciados deste programa que desejam obter informações sobre este assunto com
objetivo de permitir: (i) a troca de informações entre programas criados
independentemente e outros programas (incluindo este), e (ii) a utilização mútua
das informações trocadas, devem entrar em contato com:
Gerência de Relações Comerciais e Industriais da IBM Brasil
Av. Pasteur, 138-146
Botafogo
Rio de Janeiro, RJ
CEP: 22290-240
Tais informações podem estar disponíveis, sujeitas a termos e condições
apropriadas, incluindo em alguns casos o pagamento de uma taxa.
O programa licenciado descrito nesta publicação e todo o material licenciado
disponível são fornecidos pela IBM sob os termos do Contrato com o Cliente IBM,
do Contrato de Licença de Programa Internacional IBM ou de qualquer outro
contrato equivalente.
Todos os dados de desempenho aqui contidos foram determinados em um
ambiente controlado. Portanto, os resultados obtidos em outros ambientes
operacionais podem variar significativamente. Algumas medidas podem ter sido
tomadas em sistemas de nível de desenvolvimento e não há garantia de que tais
medidas serão iguais em sistemas geralmente disponíveis. Além disso, algumas
medidas podem ter sido estimadas por extrapolação. Os resultados reais podem
variar. Os usuários deste documento devem verificar os dados aplicáveis para o
seu ambiente específico.
As informações relativas a produtos não-IBM foram obtidas junto aos fornecedores
dos produtos, de seus anúncios publicados ou de outras fontes disponíveis
publicamente. A IBM não testou estes produtos e não pode confirmar a precisão de
seu desempenho, compatibilidade nem qualquer outra reivindicação relacionada a
produtos não-IBM. Dúvidas sobre a capacidade de produtos não-IBM devem ser
encaminhadas diretamente a seus fornecedores.
Todas as declarações relacionadas aos objetivos e intenções futuras da IBM estão
sujeitas a alterações ou cancelamento sem aviso prévio e representam apenas metas
e objetivos.
Estas informações podem conter exemplos de dados e relatórios utilizados nas
operações diárias de negócios. Para ilustrá-lo da forma mais completa possível, os
exemplos podem incluir nomes de indivíduos, empresas, marcas e produtos. Todos
os nomes são fictícios e qualquer semelhança com nomes e endereços utilizados
por uma empresa real é mera coincidência.
LICENÇA DE COPYRIGHT:
Estas informações podem conter programas aplicativos de exemplo na linguagem
fonte, que ilustram as técnicas de programação em diversas plataformas
operacionais. O Cliente pode copiar, modificar e distribuir estes programas de
exemplo sem a necessidade de pagar à IBM, com objetivos de desenvolvimento,
utilização, marketing ou distribuição de programas aplicativos em conformidade
com a interface de programação de aplicativo para a plataforma operacional para a
qual os programas de exemplo são criados. Estes exemplos não foram testados
202 Guia de Migração
completamente em todas as condições. Portanto, a IBM não pode garantir ou
implicar a confiabilidade, manutenção ou função destes programas.
Cada cópia ou parte deste exemplo de programa ou qualquer trabalho derivado
deve incluir um aviso de copyright com os dizeres:
© (nome da sua empresa) (ano). Partes deste código são derivadas dos Programas de
Exemplo da IBM Corp. © Direitos Autorais IBM Corp. _digite o ano ou anos_. Todos
os direitos reservados.
Marcas Comerciais
Os nomes de empresas, produtos ou serviços identificados nos documentos da
biblioteca de documentações do DB2 Versão 9 podem ser marcas registradas ou
marcas de serviços da International Business Machines Corporation ou de terceiros.
As informações sobre marcas registradas da IBM Corporation nos Estados Unidos
e/ou em outros países estão localizadas no endereço http://www.ibm.com/legal/copytrade.shtml.
Os termos a seguir são marcas ou marcas registradas de terceiros e foram
utilizados em pelo menos um dos documentos da biblioteca de documentação da
DB2:
Microsoft, Windows, Windows NT e o logotipo Windows são marcas registradas
da Microsoft Corporation nos Estados Unidos e/ou em outros países.
Intel, Itanium, Pentium e Xeon são marcas registradas da Intel Corporation nos
Estados Unidos e/ou em outros países.
Java e todas as marcas e baseadas em Java são marcas registradas da Sun
Microsystems, Inc. nos Estados Unidos e/ou em outros países.
UNIX é uma marca registrada do The Open Group nos Estados Unidos e/ou em
outros países.
Linux é uma marca registrada de Linus Torvalds nos Estados Unidos e/ou em
outros países.
Outros nomes de empresas, produtos ou serviços podem ser marcas registradas ou
marcas de serviço de terceiros.
Apêndice D. Avisos 203
204 Guia de Migração
Índice Remissivo
AADO .NET
migrandoaplicativos 160
ajudapara instruções SQL 194
visualizando 194
ajustando aplicativos e rotinastarefas pós-migração
aplicativos e rotinas 181
ajustando o espaço de registroRID maior 89
alterando dispositivos brutos para
dispositivos de bloqueiotarefas pré-migração
DB2 Servers 44
ambiente de testemigrando 46
ambientes complexosmigrando
DB2 Servers 67
ambientes DB2planejando a migração 5
ambientes de banco de dados
particionadomigrando 74
ambientes de replicação SQLmigrando 24
aplicativosmigrando 3, 137, 139, 153
planejando a migração 11
suporte à migração 139
tarefas de pré-migração 151
fazendo upgrade do sistema
operacional e do software de
desenvolvimento 151
migrando clientes do DB2 151
testando 151
tarefas pós-migração 181
ajustando aplicativos e
rotinas 181
aplicativos CLImigrando 155
Aplicativos de 32 bitsmigrando 164
aplicativos FORTRANmigrando 155
aplicativos REXXmigrando 155
aplicativos SQL incorporadosmigrando 155
armazenamento estendidomigrando 30
assegurando tamanhos suficientemente
grandes para páginas de espaços de
tabela temporárias do sistemaRID maior 104
atualizaçõesCentro de Informações 195
DB2 Information Center 195
aumentando o espaço de registromigrando servidores do DB2 42
avisos 201
Bbanco de dados principal
migrando 107
bancos de dadosmigrando 56, 64
CC, C++ e COBOL
migrandoaplicativos 155
rotinas 169
características físicas do banco de dadosmigrando 91
cenáriosmigrando
DB2 Servers 67
Centro de Informaçõesatualizando 195
versões 194
visualizando em diferentes
idiomas 194
clientes DB2migrando 3, 113, 115
Linux e UNIX 127
Windows 121, 123
planejando a migração 9
suporte à migração 115
suporte a versões anteriores 32
tarefas pós-migração 131
recatalogando nós 131
revisando parâmetros de
configuração e variáveis de
registro 131
verificando a migração 133
tarefas pré-migração 119
fazendo o backup da
configuração 119
migrando servidores do DB2 119
revisando itens essenciais para
migração 119
clientes DB2 Versão 7migrando
Linux e UNIX 129
Windows 124
CLP DB2 e scripts de comandos do
sistemamigrando 162
comando ACTIVATE DATABASEativando o banco de dados e
serviços 90
comando BACKUP DATABASEtarefas pré-migração 38
comando dasmigrmigrando o DAS 54, 62
comando db2batchtestando aplicativos e scripts 105
comando db2ckmigverificando bancos de dados prontos
para migração 37
comando db2iupdtatualizando para instâncias de 64
bits 69
comando db2rbindreligando pacotes 102
comando db2supportsalvando a configuração 39
comando db2uiddlconvertendo índices exclusivos 100
comando MIGRATE DATABASE 20, 56,
64
comando REBINDreligando pacotes 102
comando REORG INDEXESreorganizando índices para uma
tabela 100
comando REORG TABLEreorganizando tabela 100
comando RESTORE DATABASE 72
comandosACTIVATE DATABASE 90
BACKUP DATABASE 38
dasmigr 54, 62
db2batch 105
db2ckmig 37
db2exmig 103
db2imigr 20, 21, 53, 60
db2iupdt 69
db2rbind 102
db2support 39
db2uiddl 100
MIGRATE DATABASE 20, 21, 56, 64
REBIND 102
REORG INDEXES/TABLE 100
RESTORE DATABASE 72
configurando o nível de erros de
diagnósticotarefas pré-migração
DB2 Servers 47
DDAS (DB2 Administration Server)
migrando 54, 62
Data Linksmigrando 81
Data Warehouse Managermigrando 30
DataLinksmigrando 30
DB2 Clientmigrando
Windows 121
DB2 Information Centeratualizando 195
versões 194
© Direitos Autorais IBM Corp. 2006 205
DB2 Information Center (continuação)visualizando em diferentes
idiomas 194
DB2 NSE (Net Search Extender)migrando 81
DB2 Runtime Clientmigrando
Windows 123
DB2 Serversmigração reversa 109
migrando 3, 17, 19, 24, 49
ambientes de banco de dados
particionado 74
bancos de dados 56, 64
DAS (DB2 Administration
Server) 54, 62
HADR 107
instalações alternativas de
fixpack 76
instâncias 53, 60
Linux e UNIX 59
Linux e UNIX de 32 a 64 bits 69
múltiplas cópias do DB2 76
nova máquina 72
religando pacotes 102
verificando a migração 105
Windows 51
Windows de 32 a 64 bits 68
planejando a migração 7
suporte a migração 19
tarefas pós-migração 87
ajustando o espaço de registro 89
assegurando tamanhos
suficientemente grandes para
páginas de espaços de tabela
temporárias do sistema 104
ativando o banco de dados e
serviços 90
convertendo índices type-1 para
índices type-2 100
religando pacotes 102
revogando o privilégio EXECUTE
em PUBLIC 101
tabelas de explicação de
migração 103
verificando a migração 105
verificando parâmetros de
configuração, variáveis de
registro e características
físicas 91
tarefas pré-migração 35
alterando dispositivos brutos para
dispositivos de bloqueio 44
aumentando espaço de registro e
espaço de tabela 42
configurando o nível de erros de
diagnóstico 47
fazendo backup dos bancos de
dados 38
fazendo o backup da
configuração 39
migrando em ambientes de
teste 46
tornando os servidores off-line 49
verificando bancos de dados
prontos para migração 37
DB2 Spatial Extendermigrando 24
DB2_USE_DB2JCCT2_JROUTINEvariáveis de registro 171
DB2 Versão 9funcionalidade descontinuada e
obsoleta 30
migrando 3
protocolos NetBIOS e SNA
não-suportados 131
db2exmigtabelas de explicação de
migração 103
db2imigr command 20
migrando instâncias 53, 60
suporte 21
deixando servidores off-linetarefas pré-migração 49
diaglevelconfigurando o nível de erros de
diagnóstico 47
diagpathparâmetro de configuração do
gerenciador de banco de dados 47
documentação 189, 190
termos e condições de uso 198
driver JDBC tipo 3migrando 30
driver JDBC tipo 3 do DB2migrando 30
Driver JDBC tipo 3 ou 2migrando 159
Driver JDBC tipo 3 ou 2 do DB2migrando 159
EE/S de bruto
migrandoLinux 44
E/S diretomigrando
Linux 44
entrando em contato com a IBM 207
espaço do arquivo de logmigrando servidores do DB2 26
espaço em discomigrando
DB2 Servers 26
Ffazendo backup dos bancos de dados
tarefas pré-migração 38
fazendo o backup da configuraçãoclientes DB2 119
DB2 Serverstarefas pré-migração 39
fazendo upgrade do sistema operacionaltarefas de pré-migração
aplicativos e rotinas 151
fazendo upgrade do software de
desenvolvimentotarefas de pré-migração
aplicativos e rotinas 151
funcionalidade descontinuadaDB2 Versão 9 30
funcionalidade obsoletaDB2 Versão 9 30
funções definidas pelo usuáriomigrando 147, 167
HHADR
migrando 24
migrando servidores do DB2 107
IIBM DB2 Driver para JDBC e SQLJ
migrando 157
identificação de problemainformações on-line 198
tutoriais 198
implementando recursos da Versão 9tarefas pós-migração
aplicativos e rotinas 181
instânciasmigrando 53, 60
suporte a 32 bits e a 64 bits 28
instâncias de 64 bitsmigrando
Aplicativos de 32 bits 164
Instâncias de 64 bitsmigrando
rotinas externas de 32 bits 177
instrução CREATE TABLESPACE 104
instrução REVOKErevogando o privilégio EXECUTE em
PUBLIC 101
instruçõesCREATE TABLESPACE 104
REVOKE 101
Instruções SQLexibindo ajuda 194
migrando 162
JJava
migrandoaplicativos 157, 159
rotinas 171
jdk_pathparâmetro de configuração do
gerenciador de banco de dados 171
LLinux
migrandoclientes DB2 127
clientes DB2 Versão 7 129
DB2 Servers 59
dispositivos brutos 44
Linux e UNIXmigrando
Servidores DB2 Versão 7 79
206 Guia de Migração
Linux e UNIX de 32 a 64 bitsmigrando servidores do DB2 69
logs brutosmigrando 30
Mmanuais impressos
pedidos 193
Microsoft Cluster Serversmigrando 79
migração reversaDB2 Servers 109
migrandoambiente de teste 46
ambientes de réplica 21
ambientes de replicação SQL 24
aplicativosADO .NET 160
C, C++, COBOL, Fortran ou
REXX 155
Java utilizando Driver JDBC tipo 3
ou 2 do DB2 159
Java utilizando o IBM DB2 Driver
para JDBC e SQLJ 157
SQL e CLI integrados 155
Aplicativos de 32 bits 164
aplicativos e rotinas 3, 137, 139
planejamento 11
tarefas de pré-migração 151
aplicativos e scripts 153
ativandorecursos de computação
autonômica 24
banco de dados principal 107
bancos de dados 56, 64
clientes DB2 3, 113
Linux e UNIX 127
planejamento 9
tarefas pós-migração 131
tarefas pré-migração 119
clientes DB2 Versão 7Linux e UNIX 129
Windows 124
comandos 20
DAS (DB2 Administration Server) 54,
62
Data Links 81
DB2 ClientWindows 121
DB2 Runtime ClientWindows 123
DB2 Servers 3, 17, 19, 24
ajustando o espaço de registro 89
ambientes complexos 67
ambientes de banco de dados
particionado 74
cenários 67
deixando servidores off-line 49
HADR 107
instalações alternativas de
fixpack 76
Linux e UNIX 59
Linux e UNIX de 32 a 64 bits 69
migração reversa 109
múltiplas cópias do DB2 76
nova máquina 72
migrando (continuação)DB2 Servers (continuação)
parâmetros de configuração,
variáveis de registro e
características físicas 91
planejamento 7
recursos obsoletos 21
requisitos de espaço de registro e
espaço de tabelas 26
restrições 21
tarefas pós-migração 87
tarefas pré-migração 35
Windows 51
Windows de 32 a 64 bits 68
DB2 Spatial Extender 24
DB2 Versão 9 3
desempenho do servidor DB2 24
extensões de índice 21
HADR 21, 24
instâncias 53, 60
Javarotinas 171
Linuxdispositivos brutos 44
MSCS 79
NSE 81
Oracle 84
planejamento 5
procedimentos armazenados 175
procedimentos sql 175
Query Patroller 21
rotinas 147, 167
C, C++ e COBOL 169
revogando o privilégio EXECUTE
em PUBLIC 101
rotinas CLR .NET 174
rotinas externas de 32 bits 177
scripts 139, 162
servidor Microsoft SQL 84
Servidores DB2 Versão 7Linux e UNIX 79
Windows 78
suporte a 32 bits e a 64 bits 21
instâncias 28
Sybase 84
tabelas Explain 103
tipo XML 83
XML Extender 83
migrando para o DB2recursos 84
MSCSmigrando 79
múltiplas cópias do DB2migrando servidores do DB2 76
NNós NetBIOS
migrando 30, 131
Nós SNAmigrando 30, 131
nova máquinamigrando servidores do DB2 72
OO_DIRECT
migrandoLinux 44
Oraclemigrando 84
Pparâmetros de configuração
migrando 91
salvando configuraçõestarefas pré-migração 39
pedindo manuais do DB2 193
planejamentomigrando 5
planejando a migraçãoambientes DB2 5
aplicativos e rotinas 11
clientes DB2 9
DB2 Servers 7
procedimentos armazenadosmigrando 147, 167, 175
procedimentos SQLmigrando 175
Produtos do DB2migrando 30
Rrecatalogando nós
protocolo NetBIOS e SNAtarefas pós-migração 131
religando pacotesmigrando servidores do DB2 102
removendo recursos obsoletos da Versão
9tarefas pós-migração
aplicativos e rotinas 181
requisitos de espaços de tabelamigrando
DB2 Servers 26
resolução de problemasinformações on-line 198
tutoriais 198
revisando itens essenciais para migraçãotarefas pós-migração
aplicativos e rotinas 151
revisando parâmetros de configuração e
variáveis de registrotarefas pós-migração
clientes DB2 131
revogando o privilégio EXECUTE em
PUBLICtarefas pós-migração 101
RID maiorajustando o espaço de registro 89
assegurando tamanhos
suficientemente grandes para
páginas de espaços de tabela
temporárias do sistema 104
rotinasmigrando 3, 137, 139, 147, 167
C, C++ e COBOL 169
revogando o privilégio EXECUTE
em PUBLIC 101
Índice Remissivo 207
rotinas (continuação)planejando a migração 11
suporte a migração 147
tarefas de pré-migração 151
fazendo upgrade do sistema
operacional e do software de
desenvolvimento 151
migrando clientes do DB2 151
testando 151
tarefas pós-migração 181
ajustando aplicativos e
rotinas 181
implementando recursos da Versão
9 181
removendo recursos obsoletos da
Versão 9 181
rotinas CLR .NETmigrando 174
Rotinas e visualizações administrativas
SQLmigrando 30
rotins externas de 32 bitsmigrando 177
Sscripts
migrando 139, 153, 162
servidor Microsoft SQLmigrando 84
Servidores DB2 Versão 7migrando
Linux e UNIX 79
windows 78
sites na WebdeveloperWorks Information
Management 84
IBM Virtual Innovation Center 84
portal de migração 17
Web site DB2 Migrate 84
suporte a 32 bits e a 64 bitsmigrando 28
suporte a migraçãoDB2 Servers 19
rotinas 147
suporte à migraçãoaplicativos e rotinas 139
clientes DB2 115
suporte a versões anterioresclientes DB2 32
Sybasemigrando 84
Ttabelas Explain
migrando 103
tarefas de pré-migraçãoaplicativos e rotinas 151
fazendo upgrade do sistema
operacional e do software de
desenvolvimento 151
migrando clientes do DB2 151
revisando itens essenciais para
migração 151
testando 151
tarefas pós-migraçãoaplicativos e rotinas 181
ajustando aplicativos e
rotinas 181
implementando recursos da Versão
9 181
removendo recursos obsoletos da
Versão 9 181
clientes DB2 131
recatalogando nós 131
revisando parâmetros de
configuração e variáveis de
registro 131
verificando a migração 133
DB2 Servers 87
ajustando o espaço de registro 89
assegurando tamanhos
suficientemente grandes para
páginas de espaços de tabela
temporárias do sistema 104
ativando o banco de dados e
serviços 90
convertendo índices type-1 para
índices type-2 100
religando pacotes 102
revogando o privilégio EXECUTE
em PUBLIC 101
tabelas de explicação de
migração 103
verificando a migração 105
verificando parâmetros de
configuração, variáveis de
registro e características
físicas 91
tarefas pré-migraçãoclientes DB2 119
fazendo o backup da
configuração 119
migrando servidores do DB2 119
revisando itens essenciais para
migração 119
DB2 Servers 35
alterando dispositivos brutos para
dispositivos de bloqueio 44
aumentando o espaço de
registro 42
configurando o nível de erros de
diagnóstico 47
deixando servidores off-line 49
fazendo backup dos bancos de
dados 38
fazendo o backup da
configuração 39
migrando em ambientes de
teste 46
verificando bancos de dados
prontos para migração 37
termos e condiçõesuso de publicações 198
tipo XMLmigrando 83
tutoriaisresolução de problemas e
determinação de problemas 198
Visual Explain 197
UUNIX
migrandoclientes DB2 127
clientes DB2 Versão 7 129
DB2 Servers 59
Vvariáveis de registro
migrando 91
salvando configuraçõestarefas pré-migração 39
verificando a migraçãotarefas pós-migração
clientes DB2 133
DB2 Servers 105
verificando bancos de dados prontos para
migraçãotarefas pré-migração
DB2 Servers 37
versões anterioresclientes DB2 32
Visual Explaintutorial 197
visualizações e rotinas administrativas
SQLmigrando 162
WWindows
migrandoclientes DB2 Versão 7 124
DB2 Client 121
DB2 Runtime Client 123
servidor DB2 51
servidores DB2 versão 7 78
Windows de 32 a 64 bitsmigrando servidores do DB2 68
XXML Extender
migrando 83
208 Guia de Migração
Entrando em Contato com a IBM
Para entrar em contato com a IBM em seu país ou região, verifique o Diretório
Mundial de Contatos da IBM, no endereço http://www.ibm.com/planetwide
Para saber mais sobre os produtos DB2, acesse
http://www.ibm.com/software/data/db2/.
© Direitos Autorais IBM Corp. 2006 209
210 Guia de Migração
���
Impresso nos EUA
G517-8410-00
Spine information:
IBM
DB
2 DB
2 Ve
rsão
9
Guia
de
M
igra
ção
��
�