public.dhe.ibm.compublic.dhe.ibm.com/ps/products/db2/info/vr9/pdf/letter/nlv/pt_BR/db2... · Índice Sobre Este Manual . . . . . Migração. .. . . vii Quem Deve Utilizar Este Manual

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.

http://www.ibm.com/shop/publications/order

http://www.ibm.com/planetwide


Í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


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


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


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


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



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:


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:


página 11




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

http://www.ibm.com/software/data/db2/udb/sysreqs.html

Tabela 1. Detalhes do Plano de Migração para Servidores DB2. (continuação)


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


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.



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




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


página 11


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:


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.





migração para clientes DB2 incluindo conectividade de cliente e

servidor.


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


v Instalar o cliente da V9 do DB2

v Migrar a instância cliente


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


componentes, tais como clientes DB2, aplicativos de banco de dados e rotinas

para criar um plano de migração geral.



v Capítulo 3, “Visão Geral da Migração para Servidores DB2”, na página 17



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



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


página 11





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.




v atender aos novos requisitos de software de desenvolvimento.


migração para aplicativos de banco de dados durante a

migração.


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



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



Tabela 3. Detalhes do Plano de Migração para Aplicativos de Banco de

Dados. (continuação)



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.




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.


migração, principalmente obter autorização requerida para o

DB2.



Tabela 4. Detalhes do Plano de Migração para Rotinas. (continuação)


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



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


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


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


componentes, tais como clientes DB2 e servidores DB2 para criar um plano de

migração geral.


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


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




v “O que Há de Novo na V9.1: Resumo de Aprimoramentos em Desenvolvimento

de Aplicativos” em O que Há de Novo




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




Parte 2. Migrando Servidores DB2


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



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


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.


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 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



http://www.ibm.com/support/docview.wss?rs=73&uid=swg21200005

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 “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




página 139











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











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 é



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.





v Capítulo 17, “Visão Geral da Migração para Aplicativos de Banco de Dados e




v “Incompatibilidades da Versão 9 com Releases Anteriores e Comportamentos

Alterados” em Administration Guide: Planning


v “Migrando Ambientes de Bancos de Dados Particionados” na página 74


v “Recursos Obsoletos e Descontinuados” em Administration Guide: Planning

v “Version 8 incompatibilities with previous releases” em Administration Guide:

Planning


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


http://www.ibm.com/software/data/db2/udb/support/manualsv9.html

http://publib.boulder.ibm.com/infocenter/db2luw/v9/topic/com.ibm.db2.udb.spatial.doc/db2sb26.html

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.



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.


v “Teste de Benchmark” em Performance Guide

v “Ferramentas de Explicação” em Performance Guide






que Há de Novo













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.


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á


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.


v “Modificando Contêineres em uma Área de Tabela do DMS” em Administration

Guide: Implementation






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


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.



página 139




v “Suporte a 32 Bits e 64 Bits para Aplicativos SQL Incorporados” em

Desenvolvendo Aplicativos SQL Incorporados





na página 177


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



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


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


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.




v “O que Há de Novo na V9.1: Resumo de Funcionalidade Obsoleta” em O que Há

de Novo


que Há de Novo



v “Drivers Suportados para JDBC e SQLJ” em Desenvolvendo Aplicativos Java

v “Diretório do nó” em Administration Guide: Implementation


v “Migrando Ambientes do DB2 Data Links Manager” na página 81


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


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.






v “Combinações Suportadas de Versões de Clientes e Servidores” em Iniciação

Rápida para DB2 Clients




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”


37





v “Alterando Dispositivos Brutos para Bloquear Dispositivos (Linux)” na página

44


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;




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ê


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.







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 MANAGER CONFIGURATION” em Command

Reference


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.


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.








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:


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.



v “System administration authority (SYSADM)” em Administration Guide:

Implementation





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


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 .


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.


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


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


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.



v “Parâmetros de Configuração” em Performance Guide





v “Comando LIST PACKAGES/TABLES” em Command Reference

v “Comando LIST TABLESPACES” em Command Reference





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



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


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


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.


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





v “Parâmetros de Configuração para Registro do Banco de Dados” em Data

Recovery and High Availability Guide and Reference






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.


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 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 UNQUIESCE DATABASE


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.


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


v “Configurando um Dispositivo de Acesso Direto ao Disco no Linux” em


v “Conectando um Dispositivo de Acesso Direto ao Disco” em Administration

Guide: Implementation





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:


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.





que Há de Novo







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




v “Criando um Banco de Dados” em Administration Guide: Implementation

v “Criando Instâncias Adicionais” em Administration Guide: Implementation



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


ú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:


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.


v “Informações sobre Primeira Captura de Dados de Falha” em Troubleshooting

Guide






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



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:


db2stop






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


Capítulo 6. Migrando Servidores DB2 (Windows)

Este capítulo descreve como migrar seus servidores DB2 no Windows. Ele contém


v “Migrando um Servidor DB2 (Windows)”




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:


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.


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.







Implementation


v “Instalando os Servidores do DB2 (Windows)” em Iniciação Rápida para DB2

Servers


37






página 68








Command Reference

v “Roteiro de várias Cópias do DB2” em Administration Guide: Implementation


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 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


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.


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.






37



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


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 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


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.


%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.




v “Criando um DAS (DB2 Administration Server)” em Administration Guide:

Implementation


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:



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.

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 -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.














v “Comando MIGRATE DATABASE” em Command Reference

v “Comando RESTORE DATABASE” em Command Reference


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)”




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.



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.





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.



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.












Implementation


v “Instalando Servidores do DB2 (Linux e UNIX)” em Iniciação Rápida para DB2

Servers






na página 69







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



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:




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


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



"%DB2PATH%"\bin\db2imigr InstName /u:user,password

em que

DB2PATH


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.


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.






37



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


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 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


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.


%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.






Implementation



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 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:



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:


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



as mesmas:



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








Como alternativa, se você tiver arquivos de amostra instalados, execute o script

testdata.db2:



db2 -tvf testdata.db2


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.


















Capítulo 8. Migrando Ambientes com Características

Específicas

Este capítulo descreve como migrar ambientes com características específicas. Ele


v “Migrando Ambientes com Características Específicas”


página 68


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










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.



Restrições:





Procedimento:

Para migrar um servidor DB2 UDB Versão 8 de 32 bits para um servidor DB2

Versão 9 de 64 bits:


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.


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.














v “Instalando os Servidores do DB2 (Windows)” em Iniciação Rápida para DB2

Servers


37













Command Reference


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 Assegure que você tenha autoridade SYSADM, SYSCTRL ou SYSMAINT.






Restrições:





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:


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.





de Controle.






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










Servers





v “Migrando Aplicativos de Banco de Dados” na página 153

v “Migrando Rotinas” na página 167








v “db2iupdt - Comando para Atualizar Instâncias” em Command Reference

v “db2setup - Instalar o Comando do DB2” em Command Reference


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.



do banco de dados DB2. Os pré-requisitos para sistemas operacionais foram

alterados.



Restrições:





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.


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.



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:


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



as mesmas:



v informações de pacotes11. Verifique se a migração do banco de dados foi bem-sucedida. Conecte aos








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.




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




v “Criando uma Instância Utilizando db2icrt” em Suplemento de Instalação e

Configuração


Implementation


















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:





do banco de dados DB2. Os pré-requisitos para sistemas operacionais foram

alterados.



Restrições:







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.













Implementation



v “Configurando um Ambiente de Banco de Dados Particionado” em Iniciação

Rápida para DB2 Servers










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:







Restrições:





Procedimento:

Para migrar o servidor DB2:


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:



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



de Controle.

5. Efetue logon como o proprietário da instância migrada.













Servers







v “Trabalhando com Cópias Existentes do DB2” em Iniciação Rápida para DB2

Servers







v “db2setup - Instalar o Comando do DB2” em Command Reference


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.


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).












http://publib.boulder.ibm.com/infocenter/db2luw/v8/topic/com.ibm.db2.udb.doc/start/t0007199.htm

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 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).










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.


http://publib.boulder.ibm.com/infocenter/db2luw/v8//topic/com.ibm.db2.udb.doc/start/t0007200.htm

Pré-requisitos:

v Assegure que você tenha acesso de Administrador Local.

v A autoridade SYSADM é requerida.



Restrições:


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.


Procedimento:

Para migrar uma instância do MSCS:


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.












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





Implementation






página 68






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:









Restrições:





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.



http://publib.boulder.ibm.com/infocenter/db2luw/v8/topic/com.ibm.db2.udb.doc/opt/tz0wrk18.htm

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:





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.



de Controle.








v “O Que Há de Novo na V9.1: O Data Links Manager Não É Mais Suportado”

em O que Há de Novo












http://publib.boulder.ibm.com/infocenter/db2luw/v8/topic/com.ibm.db2.udb.doc/start/t0011841.htm





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.


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.


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 “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




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


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



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.


v “Bancos de Dados Relacionais” em SQL Reference, Volume 1



http://www.ibm.com/software/data/db2/migration/mtk/

http://www.ibm.com/developerworks/db2/zones/porting/

https://www.developer.ibm.com/isv/spc/events/db2_en.html

http://www.developer.ibm.com/welcome/vic.html

http://www.ibm.com/software/data/db2/migration/

http://www.ibm.com/developerworks/db2



Este capítulo descreve as tarefas de pós-migração para servidores DB2. Ele contém


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 “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 “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 “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


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


http://publib.boulder.ibm.com/infocenter/db2luw/v9/topic/com.ibm.db2.udb.spatial.doc/db2sb26.html

http://www.ibm.com/software/data/spatial/

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.


v “Diretrizes para Coleta e Atualização de Estatísticas” em Performance Guide






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:


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


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


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


nome do banco de dados.


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


v “Registros de Log do DB2” em Administrative API Reference


v “Parâmetros de Configuração para Registro do Banco de Dados” em Data



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.


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.


v “Dicas de início rápido para ajuste de Desempenho” em Performance Guide


v “Comando ACTIVATE DATABASE” em Command Reference


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.


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


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)


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


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


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


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


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:


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.


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



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




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 “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


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.


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.


v “Estrutura de Índice” em Performance Guide


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


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.


v “Privilégios de Rotinas” em Administration Guide: Implementation



v “Revogando Privilégios” em Administration Guide: Implementation


v “db2undgp - Comando para Revogar Privilégio de Execução” em Command

Reference

v “GRANT (Routine Privileges) statement” em SQL Reference, Volume 2


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:


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:


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.



v “Religando Pacotes Existentes com o Comando REBIND” em Desenvolvendo

Aplicativos SQL Incorporados

v “Ligação” em Administration Guide: Planning






v “db2rbind - Comando para Religar Todos os Pacotes” em Command Reference


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.


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







v “db2exmig - Migrar Comando de Tabelas de Explicação” em Command Reference


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


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.


v “Limites de SQL e XQuery” em SQL Reference, Volume 1


v “Instrução CREATE TABLESPACE” em SQL Reference, Volume 2


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.


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:


db2batch -d sample -f testdata.db2 -o r 0 p 3


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




v “Exemplos de Testes de db2Batch” em Performance Guide






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.


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


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




v “Comando START HADR” em Command Reference

v “Comando STOP HADR” em Command Reference



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.


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.


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.










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



v “db2idrop - Comando para Remover Instância” em Command Reference

v “Comando DROP DATABASE” em Command Reference


v “Comando UPDATE DATABASE MANAGER CONFIGURATION” em Command

Reference


Parte 3. Migrando Clientes DB2


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



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.


v “Visão Geral sobre a Configuração do Cliente do DB2” em Iniciação Rápida para

DB2 Clients











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


(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


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.


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 “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



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.







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:


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.




v “Criando um Perfil de Cliente Utilizando o Assistente para Configuração” em

Iniciação Rápida para DB2 Clients







Reference


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)”



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.


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.







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









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.




Restrições:



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








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.

















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


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.


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.






Capítulo 14. Migrando Clientes DB2 (Windows) 125


Capítulo 15. Migrando Clientes DB2 (Linux e UNIX)

Este capítulo descreve como migrar seus clientes DB2 no Linux e UNIX. Ele


v “Migrando Clientes DB2 (Linux e UNIX)”


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 autoridade SYSADM, SYSCTRL ou SYSMAINT e acesso root

para executar os comandos db2imigr e db2icrt.


do banco de dados DB2. Alguns sistemas operacionais requerem um kernel de

64 bits.




Restrições:



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.


3. Migre suas instâncias clientes DB2 V8 existentes executando o comando

db2imigr:



$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









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.







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








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.


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.


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.





v “Instalando Clientes do DB2 (UNIX e Linux)” em Iniciação Rápida para DB2

Clients



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”


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.





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.


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




v “Catalogando um Banco de Dados a partir de um Cliente Utilizando CLP” em


v “Catalogando um Nó TCP/IP a partir de um Cliente Utilizando CLP” em



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


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





É 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.




v “Salvando Informações sobre a Configuração do Cliente DB2” na página 119


v “Instrução CONNECT (Tipo 1)” em SQL Reference, Volume 2



Parte 4. Migrando Aplicativos e Rotinas de Banco de Dados


Capítulo 17, “Visão Geral da Migração para Aplicativos de Banco de Dados e


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


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




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.


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







página 11



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



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.


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.


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)



64-bit 64-bit $INSTHOME/sqllib/lib2


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


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.




v Capítulo 23, “Tarefas de Pós-migração para Aplicativos de Banco de Dados e




v “LOBs em Aplicativos JDBC com o IBM DB2 Driver para JDBC e SQLJ” em

Desenvolvendo Aplicativos Java






página 11


v “APIs e Estruturas de Dados Alteradas” em Administrative API Reference



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


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.




v Capítulo 23, “Tarefas de Pós-migração para Aplicativos de Banco de Dados e




v “O Que Há de Novo na V9.1: O Developer Workbench Substitui o Development

Center” em O que Há de Novo




página 11



Capítulo 19. Princípios de Migração para Rotinas 149


Capítulo 20. Tarefas de Pré-migração para Aplicativos de


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.





v “Arquivos de Amostra” nos Tópicos de Amostra






Capítulo 21. Migrando Aplicativos de Banco de Dados

Este capítulo descreve como migrar seus aplicativos de banco de dados. Ele


v “Migrando Aplicativos de Banco de Dados”



na página 157


na página 159





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:



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.



página 139



v “Introdução ao Desenvolvimento de Aplicativos de Bancos de Dados” em

Introdução ao Database Application Development




na página 157


na página 159





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



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 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.


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



edite o código do aplicativo a ser modificado:





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.





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


página 139



v “Construindo Aplicativos CLI no UNIX” em Guia e Referência para Interface Call

Level, Volume 1


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






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:


alterações-chave que podem afetar seus aplicativos de banco de dados Java.





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.


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.



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 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.



v “Software de Desenvolvimento de Aplicativo Java Suportado” em Desenvolvendo

Aplicativos Java



v “LOBs em Aplicativos JDBC com o IBM DB2 Driver para JDBC e SQLJ” em


v “Introdução ao Desenvolvimento de Aplicativos Java para DB2” em



página 139


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


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:


alterações-chave que podem afetar seus aplicativos de banco de dados Java.





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.


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:






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.



v “Software de Desenvolvimento de Aplicativo Java Suportado” em Desenvolvendo

Aplicativos Java



v “Introdução ao Desenvolvimento de Aplicativos Java para DB2” em



página 139


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


na página 157



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.


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:


alterações-chave que podem se aplicadas em aplicativos ADO.NET.





v Certifique-se de que uma versão suportada do software .NET Framework esteja

instalada no computador cliente do banco de dados DB2.


Procedimento:

Para migrar seus aplicativos ADO.NET para o DB2 Versão 9:


edite o código do aplicativo a ser modificado:



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


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.


v “Software de Desenvolvimento .NET Suportado” em Desenvolvendo Aplicativos

ADO.NET e OLE DB




página 139



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:


identificar quaisquer alterações que se aplicam a seus scripts.


bancos de dados.

v Assegure que um cliente DB2 Versão 9 esteja instalado.


suportado pelos produtos do banco de dados e software de desenvolvimento do

DB2.




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



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ágina 139






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


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:


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.






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 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


Após migrar seus aplicativos de banco de dados de 32 bits, execute as tarefas de




página 139







Development

v “db2chglibpath - Modificar o Comando do Caminho de Procura da Biblioteca de

Tempo de Execução Incorporada” em Command Reference



Capítulo 22. Migrando Rotinas

Este capítulo descreve como migrar seus aplicativos de banco de dados. Ele


v “Migrando Rotinas”






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 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:



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.






v “Linguagens de Programação de Rotina Suportadas” em Developing SQL and

External Routines







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




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 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.


instruções:

– ALTER FUNCTION

– ALTER PROCEDURE


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




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.


Após migrar suas rotinas, execute as tarefas de pós-migração para rotinas que são

recomendadas.



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




v “Construindo Aplicativos e Rotinas Gravados em C e C++” em Desenvolvendo


v “Construindo Aplicativos e Rotinas Gravados em COBOL” em Desenvolvendo


v “Procedimentos COBOL” em Developing SQL and External Routines



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


v “Construindo Código de Rotina C e C++” em Developing SQL and External

Routines


v “Suporte para Desenvolvimento de Procedimentos Externos no COBOL” em

Developing SQL and External Routines



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.


bancos de dados. O servidor DB2 pode ser um sistema de teste.





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.



instruções:

– ALTER FUNCTION

– ALTER PROCEDURE


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.


5. Se você identificar alterações no DB2 Versão 9 que afetam suas rotinas Java,

edite o código da rotina e modifique:



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.



v “Software Suportado para Desenvolvimento de Rotinas Java” em Developing SQL


v “Drivers Suportados para JDBC e SQLJ” em Desenvolvendo Aplicativos Java



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


v “Construindo Rotinas JDBC” em Desenvolvendo Aplicativos Java

v “Construindo Rotinas SQLJ” em Desenvolvendo Aplicativos Java


na página 159


na página 157





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:


que podem ser aplicadas nas rotinas .NET CLR.





v Certifique-se de que uma versão suportada do software .NET Framework seja

instalada no servidor DB2.


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




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.



v “Software de Desenvolvimento .NET Suportado” em Desenvolvendo Aplicativos

ADO.NET e OLE DB



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




v “Construindo Código de Rotina .NET CLR” em Developing SQL and External

Routines


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:


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.


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


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





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.





página 139


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


v “Criando Procedimentos SQL” em Developing SQL and External Routines




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.







instruções SQL:

– ALTER FUNCTION

– ALTER PROCEDURE


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:



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:



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





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.






v “Suporte para Desenvolvimento de Rotina Externa em C++” em Developing SQL



página 139


v “Procedimentos COBOL” em Developing SQL and External Routines

v “Suporte para Desenvolvimento de Rotina Externa em C” em Developing SQL



v “Construindo Código de Rotina C e C++ Utilizando Scripts bldrtn de Amostra”

em Developing SQL and External Routines




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 23. Tarefas de Pós-migração para Aplicativos de


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.


v “Desempenho de Rotinas” em Developing SQL and External Routines

v “Desempenho de Aplicativos SQL Incorporados” em Desenvolvendo Aplicativos

SQL Incorporados


v “Dicas de início rápido para ajuste de Desempenho” em Performance Guide







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



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


http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp




http://publib.boulder.ibm.com/infocenter/db2help/index.jsp

http://publib.boulder.ibm.com/infocenter/db2help/index.jsp


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






http://publib.boulder.ibm.com/infocenter/db2luw/v9/




http://www.ibm.com/software/data/db2/udb/support.html

http://www.ibm.com/software/data/education/selfstudy.html

http://www.ibm.com/software/data/education/selfstudy.html

http://www.ibm.com/software/data/education/

http://www.ibm.com/developerworks/db2

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.


http://www.ibm.com/developerworks/forums/db2_forums.jsp

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.


http://www.ibm.com/software/data/sw-library/

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.


v “Recursos do Information Center do DB2” no Centro de Informação On-line do

DB2



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


v “Atualizando o Centro de Informações do DB2 Instalado em seu Computador ou

em um Servidor de Intranet” na página 195


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



Tabela 19. Informações Técnicas do DB2 (continuação)



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


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)



Impressa

XML Guide SC10-4254 Sim

XQuery Reference SC18-9796 Sim

Tabela 20. Informações Técnicas Específicas ao DB2 Connect



Impressa

DB2 Connect User’s Guide SC10-4229 Sim


Connect Personal Edition

GC10-4244 Sim


Connect Servers

GC10-4243 Sim

Tabela 21. Informações Técnicas sobre o WebSphere Information Integration



Impressa

WebSphere Information

Integration: Administration Guide

for Federated Systems

SC19-1020 Sim


Integration: ASNCLP Program

Reference for Replication and

Event Publishing

SC19-1018 Sim


Integration: Configuration Guide

for Federated Data Sources

SC19-1034 Não


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.


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


v “Solicitando Manuais Impressos do DB2” na página 193


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 .




v “Biblioteca Técnica do DB2 em Formato PDF” na página 190


http://publib.boulder.ibm.com/infocenter/db2help/







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.


v “Chamado a Ajuda do Comando a partir do Processador da Linha de


v “Chamando a Ajuda da Mensagem a partir do Processador da Linha de


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/.


v “Configurando Acesso à Ajuda Contextual e Documentação do DB2” em


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.




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.



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.


http://www.ibm.com/software/data/db2/udb/support/icupdate.html

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


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.


v “Opções de Instalação do Information Center do DB2” em Iniciação Rápida para

DB2 Servers


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.




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



v “Introdução à Determinação de Problemas” em Troubleshooting Guide


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.



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 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.


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


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

http://www.ibm.com/legal/copytrade.shtml

http://www.ibm.com/legal/copytrade.shtml


Í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


suporte à migração 115

suporte a versões anteriores 32


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


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


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


Windows 51

Windows de 32 a 64 bits 68


suporte a migração 19


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


revogando o privilégio EXECUTE

em PUBLIC 101

tabelas de explicação de

migração 103


verificando parâmetros de

configuração, variáveis de

registro e características

físicas 91



dispositivos de bloqueio 44

aumentando espaço de registro e

espaço de tabela 42


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


fazendo o backup da configuraçãoclientes DB2 119

DB2 Serverstarefas pré-migração 39

fazendo upgrade do sistema operacionaltarefas de pré-migração


fazendo upgrade do software de

desenvolvimentotarefas de pré-migração


funcionalidade descontinuadaDB2 Versão 9 30

funcionalidade obsoletaDB2 Versão 9 30

funções definidas pelo usuáriomigrando 147, 167

HHADR

migrando 24


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


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


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


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



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


ambientes complexos 67


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



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


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


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


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


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





rotinasmigrando 3, 137, 139, 147, 167

C, C++ e COBOL 169


em PUBLIC 101

Índice Remissivo 207

rotinas (continuação)planejando a migração 11

suporte a migração 147




desenvolvimento 151


testando 151



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



desenvolvimento 151



migração 151

testando 151

tarefas pós-migraçãoaplicativos e rotinas 181


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


DB2 Servers 87






ativando o banco de dados e

serviços 90

convertendo índices type-1 para

índices type-2 100



em PUBLIC 101

tabelas de explicação de

migração 103


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



migração 119

DB2 Servers 35


dispositivos de bloqueio 44

aumentando o espaço de

registro 42


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


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/.



http://www.ibm.com/software/data/db2/udb/


��

Impresso nos EUA

G517-8410-00

Spine information:

IBM

DB

2 DB

2 Ve

rsão

9

Guia

de

M

igra

ção

��

�

Documents

public.dhe.ibm.compublic.dhe.ibm.com/ps/products/db2/info/vr9/pdf/letter/nlv/pt_BR/db2... · Índice Sobre Este Manual . . . . . Migração. .. . . vii Quem Deve Utilizar Este Manual