DB2 UDB for z/OS Versão 8
Rompendo Limites
Jelson Carvalho
Objetivos
 Apresentar algumas melhorias do DB2 for
OS/390 Versão 8 em relação a versões
anteriores
 Introduzir conceitos utilizados na nova
versão
 Formar base de conhecimento para as
demais apresentações do evento
 Orientação principal para aspectos da
administração de banco de dados
Principais aspectos
 Escalabilidade
 Disponibilidade
 Desempenho
 Funcionalidade
 Instalação e migração
 Conclusões
Escalabilidade
Escalabilidade
 Removendo inibidores de crescimento
 Explorando arquitetura de 64 bits
 Mais partições
 Mais arquivos log
 Aumentando limites no SQL
Removendo inibidores de crescimento
Limites do DB2 for z/OS :






Memória Virtual
Logs Ativas
Logs Arquivadas
Partições
Tamanho do SQL
Tabelas no join
V7
231
31
1000
254
32 KB
15
V8
264
93
10,000
4096
2 MB
225
Explorando arquitetura de 64 bits
Memória
Expandida
Memória Central
Memória Central
S/370 24-bit
XA/ESA 31-bit
Memória
Central
z/Architecture 64-bit
Memória Virtual
Memória Virtual
Memória Virtual
Arquitetura
Antiga S/370
Arquitetura
Atual ESA
Suporte para endereçamento real fornecido pela z/Architecture do OS/390 V2R10
 Sistema Operacional suportando aplicações de 24-bit, 31-bit e 64-bit
 128GB (64GB máximo atual no z900) de memória central
 Registradores de 64 bits, etc...
Evolução de 64 bit
 Suporte de hardware para 64 bit zSeries,
z/Architecture (z800, z900, z990)
 Suporte do sistema operacional
 Suporte de 64 bit para Memória Real (OS/390 V2R10
ESAME mode +)
 Grandes quantidades de memória real (para performance)
 Melhoria em todas as versões do DB2
 Vantagens do data space na V6 (melhor que hiperpool)
 Suporte de 64 bit para Memória Virtual (z/OS V1.2 +)
 Explorado pelo DB2 V8 (requer z/OS 1.3)
 Move grandes áreas de memória para acima da barra
 Explorado pelo IRLM V2.2 (parte do DB2 V8)
 Bloqueios sempre na memória privada acima da barra
 Melhora escalabilidade, disponibilidade e facilidade
 Não necessita mais de hiperpool ou data space
Utilização de 64 bit pelo DB2 movimentação acima da barra
16 EB
DBM1
Buffer pool
EDM pool
(DSC+DBD)
RID lists
Sort pool
Compression
dictionary
Barra
2 GB
16 M
0
Suporte para 4096 partitions
 Número máximo de partições aumentado de 254 para 4096
 Table spaces e índices
 Table space usa DSSIZE para ir além de 254 partições
 ALTER TS ADD PARTITION acrescenta partições ao final
 Tamanho máximo da tabela continua 16 TB para páginas de 4 KB
 Convenção para nomes de arquivos expandida





'A001‘ - 'A999' partições 1-999
'B000' - 'B999' partições 1000-1999
'C000' - 'C999' partições 2000-2999
'D000' - 'D999' partições 3000-3999
'E000' - 'E096' partições 4000-4096
 Número máximo de partições permitidas depende do tamanho da
página e do DSSIZE
 Páginas de 4 KB, DSSIZE=1 GB => 4096 partições, 4 TB tamanho
máximo da tabela
 Páginas de 4 KB, DSSIZE=64 GB => 256 partições, 16 TB tamanho
máximo da tabela
Suporte para mais arquivos log
 Aumento no número de logs ativas de 31 para




93
Aumento no número de logs arquivadas que
podem ser registradas no BSDS de 1000 para
10000
Ambos requerem conversão prévia do BSDS
para acomodar informação adicional
Executar job DSNJCNVB para converter o
BSDS
Tem que estar em Modo de Novas Funções
antes que a conversão seja permitida
Aumentando limites no SQL
Limites do DB2 for z/OS :
V7
V8
 Nome da tabela(*)
18
128
 Nome da coluna
18
30
 Chave de índice
255
2000
 Literais em caráter
255
32704
 Tamanho de predicados 55
32704
 Tamanho do SQL
32 KB
2MB
 Tabelas no join
15
225
(*) Idem views, alias, índices, triggers, sinônimos
Disponibilidade
Disponibilidade
 Evolução online de esquema
 ALTER ao invés de DROP / CREATE
 Data Partitioned Secondary Indexes
(DPSI)
 Recuperação a nível de sistema para um
ponto no tempo
 Alteração online de mais parâmetros do
DSNZPARM
Evolução online de esquema
 Mudança de partições
 Adicionar uma partição ao final da tabela
 Rodar partições
 Redistribuir partições
 Desvinculação entre particionamento e clustering
 Possibilidade de fazer drop do partitioning index
 Data Partitioned Secondary Indexes
 Possibilidade de alterar o índice clustering
 Aplicável também a tabelas não particionadas
 Alteração de índices
 Adicionar colunas a índices
 Alteração de tabelas
 Possibilidade de alterar tipos de dados e tamanhos (aumentos)
 Inclui tipos de dados de colunas referenciadas em views
 Inclui alteração de colunas usadas em índices
Adição de partição ao final da tabela
 ALTER TABLE ... ADD PARTITION ENDING AT ("31-12-2003");
ts
Partição 1
1999
1999 Jan
Jan
Partição 2
1999
1999 Fev
Feb
Partição 58
2003
2003 Out
Oct
Partição 59
2003
2003 Nov
Nov
Partição 60
2003
2003 Dez
Dec
pi
npsi
dpsi
Rotação de partições (1)
ts
Part 1
1999
1999 Jan
Jan
Part 2
1999
1999 Fev
Feb
Part 59
2003
2003 Nov
Nov
Part 60
2003
2003 Dez
Dec
pi
npi
Rotação de partições (2)
 ALTER TABLE ... ROTATE FIRST TO LAST
ENDING AT ("31-01-2004") RESET;
ts
1999
1999 Jan
Jan
Part 2
1999
1999 Fev
Feb
Part 59
2003
2003 Nov
Nov
Part 60
2003
2003 Dez
Dec
Part 1
pi
npi
Particionamento controlado pela tabela
CREATE TABLE CUSTOMER (
ACCOUNT_NUM
INTEGER,
CUST_LAST_NM
CHAR(30),
...
LAST_ACTIVITY_DT
DATE,
STATE_CD
CHAR(2))
PARTITION BY ( ACCOUNT_NUM ASC )
( PARTITION 1 ENDING AT (199),
PARTITION 2 ENDING AT (299),
PARTITION 3 ENDING AT (399),
PARTITION 4 ENDING AT (499) ) ;
Tabela particionada
401
402
403
404
405
406
301
302
303
304
305
306
201
202
203
204
205
206
TB
101
102
103
104
105
106
Não necessita índices para particionamento !!!
Classificação dos índices na Versão 8
 Um índice pode estar ou não correlacionado às
colunas de particionamento de uma tabela
 Partitioning index (PI)
 Secondary index
 Um índice pode ser ou não fisicamente
particionado
 Partitioned
 Non-partitioned
 Índice clustering :
 Qualquer índice pode ser o clustering
 O índice clustering pode ser de chave não única
Partitioned index and non-partitioned
index
Índice particionado - 1 partição por partição de dados
Tabela particionada
IX
Índice não particionado
401
402
403
404
405
406
301
302
303
304
305
306
201
202
203
204
205
206
TB
101
102
103
104
105
106
IX
401,AM
402,PI
403,RO
404,PB
405,MS
406,MA
301,PR
302,MT
303,PA
304,SE
305,TO
306,AC
401,FEV,AM
402,MAR,PI
403,JUN,RO
404,SET,PB
405,OUT,MS
406,NOV,MA
301,ABR,PR
302,MAI,MT
303,JUN,PA
304,JUL,SE
305,SET,TO
306,NOV,AC
201,JAN,SP
202,FEV,RN
203,JUL,CE
204,AGO,RJ
205,OUT,PE
206,DEZ,SC
101,JAN,MG
102,FEV,AL
103,MAR,RS
104,ABR,ES
105,NOV,GO
106,DEZ,BA
Tabela
particionada
201,SP
202,RN
203,CE
204,RJ
205,PE
206,SC
101,MG
102,AL
103,RS
104,ES
105,GO
106,BA
401
402
403
404
405
406
301
302
303
304
305
306
201
202
203
204
205
206
101
102
103
104
105
106
Partitioning indexes (Partitioned and
Non-Partitioned)
Partitioned Partitioning index - part_ix_1
Non-partitioned Partitioning index - part_ix_2
AC
AL
AM
BA
CE
ES
GO
MA
MG
MS
MT
PA
PB
PE
PI
PR
RJ
RN
RO
RS
SC
SE
SP
TO
JAN
FEV
MAR
ABR
NOV
DEZ
JAN
FEV
JUL
AGO
OUT
DEZ
ABR
MAI
JUN
JUL
SET
NOV
FEV
MAR
JUN
SET
OUT
NOV
205,JAN,PE
206,FEV,SC
201,JUL,SP
202,AGO,RN
203,OUT,CE
204,DEZ,RJ
304,ABR,SE
303,MAI,PA
306,JUN,AC
302,JUL,MT
305,SET,TO
301,NOV,PR
404,FEV,PB
403,MAR,RO
405,JUN,MS
401,SET,AM
406,OUT,MA
402,NOV,PI
Tabela
particionada
106,JAN,BA
101,FEV,MG
102,MAR,AL
105,ABR,GO
104,NOV,ES
103,DEZ,RS
Secondary indexes (Partitioned and NonPartitioned)
Data Partitioned Secondary Index (DPSI) - data_part_si_1
Non-Partitioned Secondary Index (NPSI) - non_part_si_2
Benefícios do DPSI
 Online REORG
 Não executa a fase de BUILD2 com DPSI’s
 Carga de partições (LOAD PART)
 Sem páginas compartilhadas
 Remove contenção de páginas e problemas de sobrecarga do GPB
 Permite uso de estratégia mais eficiente para extensão de tabelas
(APPEND)
 Operações mais fáceis a nível de partição
 Tornam mais fácil e eficiente a inclusão e exclusão de novas partições
 Falha de armazenamento
 Recuperação a nível de partição
 Sobrecarga em data sharing
 Designação por afinidade membro   partição é efetiva no DPSI
 Permite paralelismo de query
Outras melhorias de índices
 ALTER INDEX ADD COLUMN
 ALTER INDEX PADDED / NOT PADDED
 Chaves de índices com tamanhos variáveis (NOT
PADDED)
 ALTER clustering index
 Para tabelas particionadas e não particionadas
 Efetivo imediatamente
 REORG necessário para reordenar todas as linhas
existentes na sequência do novo índice clustering
 Outras melhorias na área de desempenho
ALTER TABLE data types suportados na
V8
FROM
TYPE
DO
TIPODATA
DE DADO
TO DATA
PARA
TIPOTYPE
DE DADO
smallint
smallint
smallint
smallint
smallint
smallint
smallint
smallint
integer
integer
integer
integer
float(1-21)
float(1-21)or
orreal
real
<=decimal(7,s)
<=decimal(7,s)
<=decimal(15,s)
<=decimal(15,s)
decimal(p,s)
decimal(p,s)
char(n)
char(n)
char(n)
char(n)
varchar(n)
varchar(n)
varchar(n)
varchar(n)
graphic(n)
graphic(n)
graphic(n)
graphic(n)
vargraphic(n)
vargraphic(n)
vargraphic(n)
vargraphic(n)
integer
integer
float(1-21)
float(1-21)or
orreal
real
float(22-53)
float(22-53)or
ordouble
double
>=>=decimal(5,0)
decimal(5,0)
float(22-53)
float(22-53)or
ordouble
double
>=decimal(10,0)
>=decimal(10,0)
float(22-53)
float(22-53)or
ordouble
double
float(1-21)
float(1-21)or
orreal
real
float(22-53)
float(22-53)or
ordouble
double
decimal(p+a,s+b)
decimal(p+a,s+b)
char(n+x)
char(n+x)
varchar(n+x)
varchar(n+x)
char(n+x)
char(n+x)
varchar(n+x)
varchar(n+x)
graphic(n+x)
graphic(n+x)
vargraphic(n+x)
vargraphic(n+x)
vargraphic(n+x)
vargraphic(n+x)
graphic(n+x)
graphic(n+x)
 Dentro do mesmo tipo de
grupo de dados
(caráter ou numérico)
 Tamanho menor  maior
 ALTER TABLE tab1
ALTER COLUMN cola
SET DATA TYPE
CHAR(20);
 Para tipos de dados decimais,
“a” mais “b” tem que ser maior
do que zero ou não ocorre
mudança
 Para tipos de dados caráter,
“x” tem que ser maior ou igual
a zero
Que acontece à tabela e aos dados
 Tabela
 Nova definição registrada no catálogo e no diretório
 Máximo de 255 ALTERS por table space antes que o REORG seja
requerido
 Table space é colocado em “advisory reorg-pending” (AREO)
 Planos, packages e solicitações de SQL dinâmico guardadas na
memória que referenciem a coluna alterada são invalidados
 Valores do RUNSTATS para as colunas são invalidados e tratados
como se fossem -1 (mesmo tratamento dado no aumento de colunas
varchar na Versão 7)
 Dados




Dados existentes permanecem inalterados
No SELECT, os dados são materializados no novo formato
INSERT e UPDATE alteram a linha inteira para o formato mais recente
REORG altera todas as linhas para a versão atual (mais recente) e
melhora a performance (em muitos casos o REORG online pode ser
usado)
Recuperação a nível de sistema para um
ponto no tempo
 Mais fácil, flexível e permitindo recuperação
mais rápida
 Manuseia grande número de table spaces e
índices (na V8 só suporta o subsistema DB2
inteiro ou o data sharing group)
 Dois novos utilitários criados
 BACKUP SYSTEM: Cópia rápida por volume
 DB2 databases (e logs)
 Escopo de data sharing group
 z/OS V1R5 requerido (DFSMShsm, DFSMSdss, DFSMS)
 DASD que suporte o Flashcopy API
 RESTORE SYSTEM
 Para um ponto arbitrário no tempo
 Manuseia eventos de creates, drops, LOG NO
Parâmetros de sistema já existentes na
V7, alteráveis online na V8
Parameter
CHGDC
EDPROP
SYSADM
SYSADM2
SYSOPR1
SYSOPR2
CACHEDYN
SRTPOOL
XLKUPDLT
MAXKEEPD
PARTKEYU
RESYNC
IDTHTOIN
MAXTYPE1
POOLINAC
TCPKPALV
TCPALVER
Panel
DSNTIPO
DSNTIPO
DSNTIPP
DSNTIPP
DSNTIPP
DSNTIPP
DSNTIP4
DSNTIPC
DSNTIPI
DSNTIPE
DSNTIP4
DSNTIPR
DSNTIPR
DSNTIPR
DSNTIP5
DSNTIP5
DSNTIP5
Panel Field
DPROP Support
DPROP Support
System Admin 1
System Admin 2
System Operator 1
System Operator 2
Cache Dynamic SQL
Sort Pool Size
X Lock for Searched U/D
Max Kept Dyn Stmts
Update Part Key Cols
Resync Interval
Idle Thread Timeout
Max Inactive DBAT’s
Pool Thread Timeout
TCP/IP Keepalive
TCP/IP Already Verified
Desempenho
Desempenho
 Habilidade de usar índices mais frequentemente
 Mais predicados indexáveis
 Varredura reversa de índices (backward scan)
 Índices NOT PADDED (acesso IX-only para dados
tipo VARCHAR)




Materialized Query Tables
Suporte para tabelas voláteis
Melhoria no EXPLAIN
Visual Explain inteligente
Predicados estágio 1 indexáveis com
tipos de dados diferentes
 DB2 foi melhorado para permitir acesso via índice quando a variável
de programa e a coluna da tabela não têm o mesmo tipo de dados
ou tamanho
 Atende linguagens de programação que não suportam todo o
conjunto de tipos de dados do DB2
 C/C++ não possui tipo de dados DECIMAL
 Java não tem tipo de dados CHAR de tamanho fixo
 Alguns exemplos:
 Coluna é decimal; variável de programa é float
 Coluna é char(3); Literal ou variável de programa é char(4)
 Melhoria significante de performance para muitas aplicações
 Pode ser usado com “transitive closure”
 Existem ainda algumas restrições para estágio 1, indexável
 Simplifica tarefas do programador de aplicações e do DBA
Predicado estágio 1 na Versão 8 exemplos
salary
hv_float
dec (12,2)
floating
SELECT FROM employee
WHERE salary > :hv_float;
Antes da V8
 Predicado estágio 2
 Table space scan
V8
 Predicado estágio 1
 Pode usar índice
pela coluna salário
Exemplo de Transitive Closure
CHAR(4)
SELECT DEPT.NAME, EMP.NAME
FROM EMP, DEPT
WHERE EMP.DEPTID = ? AND
EMP.DEPTID = DEPT.ID
CHAR(3)
AND
Gerado
DEPT.ID = ? ;
Antes da V8
 Predicado estágio 2
 Varredura do table space
A partir da V8
 Predicado estágio 1
 Pode usar índice pela
coluna DEPTID
Materialized Query Tables (MQT)
 Previamente conhecida como "Automatic
Summary Tables"
 Otimizador é capaz de reescrever a solicitação
para acessar a MQT em lugar da tabela ou view
(se MQT for habilitada para otimização da
query)
 Melhoria significante de performance
 Dois tipos de MQT’s
 Mantida pelo sistema (através da solicitação SQL
REFRESH)
 Mantida pelo usuário (através de triggers,
atualizações batch, LOAD, etc.)
Sem Materialized Query Tables
Cada query é recomputado !
Q11, Q12, ...
Q21, Q22, ...
CLIENTE
PRODUTO
VENDA
LOCAL
TEMPO
Com Materialized Query Tables
Q11, Q12, ...
MQT
Reusa muitas vezes
Pré-computa uma vez
Armazena na MQT
CLIENTE
PRODUTO
VENDA
LOCAL
TEMPO
MQT
Q21, Q22, ...
Melhorias em índices
 Índice de real tamanho variável
 Acesso IX-only
 Redução de espaço para o índice
 ALTER INDEX PADDED / NOT PADDED + REBUILD
 Tamanho máximo da chave aumentado de 255 para 2000 bytes
 Chaves em Unicode podem se tornar maiores
 DB2 em plataformas de LUW pode ter chaves > 255
 Suporte para varredura reversa do índice
 Usada por “scrollable cursors”
 Pode definir apenas um índice quando necessita ordem ASC e DESC
para as mesmas colunas
 Otimizador usa a varredura para frente se ambos os índices estiverem
disponíveis (varredura reversa do índice só pode ser usada com
“dynamic prefetch”
Varredura reversa de índice
 DB2 pode selecionar um índice ascendente e usar a
varredura reversa para evitar um sort em ordem
descendente
 Para ser capaz de usar um índice para varredura
reversa:
 O índice tem que ser definido sobre as mesmas colunas usadas
no ORDER BY e
 A ordenação tem que ser exatamente oposta à requerida no
ORDER BY
 Se o índice for definido como DATE DESC, TIME ASC, pode fazer:
 Varredura direta para ORDER BY DATE DESC, TIME ASC
 Varredura reversa para ORDER BY DATE ASC, TIME DESC
 Mas tem que usar o sort para:
 ORDER BY DATE ASC, TIME ASC ou
 ORDER BY DATE DESC, TIME DESC
Suporte para tabelas voláteis
 Tabelas cujo conteúdo pode variar de vazio a
muito grande em tempo de execução
 Favorece o acesso através de índice para
tabelas que possuem cardinalidade imprevisível
 Melhoria significativa de performance para
algumas aplicações SAP (cluster tables)
 Pode evitar conflitos de bloqueio causados por
caminhos de acesso diferentes para consultas
diversas, acessando a mesma tabela
CREATE TABLE T1 ..... VOLATILE
Melhoria no EXPLAIN
 Melhorias na solicitação EXPLAIN permitem obter
informação de EXPLAIN para entradas no “DB2 global
statement cache”
 Visual Explain melhorado para explorar esta nova
função
EXPLAIN
STMTCACHE
STMTID
id-host-variable
integer-constant
STMTTOKEN
token-host-variable
string-constant
Visual Explain inteligente
Melhorias significativas
na ferramenta de
Visual Explain:
 Informação muito
mais detalhada sobre
o caminho de acesso
 Estatísticas mais
detalhadas para cada
nó no gráfico
 Documento XML
descrevendo o
caminho de acesso
escolhido para a
query
 Mais fácil para
coletar informações
para análise
Funcionalidade
Funcionalidade
 Entrada e saída delimitadas no LOAD e





no UNLOAD
Melhorias no RUNSTATS
Redistribuição de partições
Melhorias no Online REORG
Mudanças para suportar DPSI’s
Novos padrões para melhoria de
performance
Entrada e saída delimitadas no LOAD e
no UNLOAD
 Utilitários LOAD / UNLOAD aceitam / produzem
arquivos delimitados
 Benefícios:
 Facilita a importação / exportação de (grandes quantidades
de) dados do DB2 for z/OS para sistemas operacionais em
outras plataformas e vice versa
 Elimina necessidade de escrever programas para converter
dados de plataforma não z/OS no formato posicional para
usar o utilitário LOAD do DB2 for z/OS ou para inclusão
utilizando o INSERT
 Descarregar / exportar dados de outro DBMS no formato
delimitado e carregá-los no DB2 for z/OS
Melhorias no RUNSTATS
 Coleta de estatísticas de distribuição não uniforme
para colunas não indexadas
 Técnica na V7 é usar programa separado - DSTATS
 RUNSTATS da V8 permite coletar frequências e estatísticas
de distribuição não uniforme para colunas ou grupo de
colunas que não fazem parte de um índice
 Usadas pelo otimizador e podem conduzir a melhoria
significativa de performance de certas consultas
 Não é suportada para estatísticas em linha
 Pode também coletar os valores menos frequentes
(LEAST)
 RUNSTATS com UPDATE NONE REPORT NO
 Invalida comandos existentes no “Dynamic Statements
Cache” que referenciam objeto especificado
 RUNSTATS com UPDATE NONE HISTORY ALL só
atualiza as tabelas HISTORY
Redistribuição de partições
Antes do REORG TABLESPACE
Part 1
Part 2
Part 1
Part 2
Part 3
Part 4
Partitioning
Index
Part 4
Data
Partitions
Part 3
LK='50000'
LK='80000'
Depois do REORG TABLESPACE ... REBALANCE
Part 1
Part 1
Part 2
Part 2
Part 3
Part 3
LK='30000' LK='80000'
Part 4
Partitioning
Index
Part 4
Data
Partitions
Etapas da redistribuição
 Faz unload das linhas do table space ou de uma faixa
de partições
 Classifica as linhas pela(s) coluna(s) de particionamento
e distribui pelo número de partições
 A divisão não é perfeita se existirem muitas duplicatas de
chaves
 Recarrega os dados
 Atualiza o valor da chave limite de cada partição no
catálogo
 Invalida planos, packages e o “dynamic statement
cache”
 Quando a ordem de clustering não casa com a chave de
particionamento rodar o REORG duas vezes:
 Na primeira para mover as linhas para a partição correta
 Na segunda para classificar na sequência de clustering
Melhorias no Online REORG
 Não possui a fase de BUILD2 no REORG PART
quando usando DPSI’s
 Suporte para processo de DISCARD com Online
REORG SHRLEVEL CHANGE
 Suporte para fazer Online REORG SHRLEVEL
REFERENCE de todas as tabelas do catálogo
(incluindo as que possuem links)
 Permite especificar SCOPE PENDING para
reorganizar somente as partições que estiverem em
estado de reorg pending (REORP) ou em estado de
advisory reorg pending (AREO) para um table space
específico ou faixa de partições
Mudanças para suportar DPSI’s
 CHECK INDEX
 Permite usar a opção PART para especificar a
partição do DPSI a ser verificada
 COPY
 DSNUM pode especificar uma partição do DPSI
 LISTDEF
 PARTLEVEL permite especificar granularidade
para DPSI’s
 TEMPLATE
 Templates criadas para DPSI’s podem fazer uso
da variável &PA
Novos padrões para melhoria de
performance
 RESTART é o novo padrão para Utilitários
 SORTKEYS para LOAD, REORG e REBUILD
 SORTDATA para REORG
 SORTDATA agora permitido para registros de 32k
 REORG usa índice clustering implícito
 Se não tem índice clustering, usa o primeiro
índice definido
 Se o table space não possui índices, SORTDATA
funciona como nas versões anteriores à V8
Instalação e migração
Instalação e migração
 Características gerais
 Caminhos para migração
 Migração para a versão 8
 Modos de operação
 Processo de migração
 Verificação da instalação (IVP)
 Mudanças no catálogo
Características gerais
 DB2 e IRLM são exclusivamente 64-bit
 Pré-requisitos básicos:
 zSeries z800, z900 ou posterior
 z/OS V1R3 ou posterior (algumas funções necessitam a
V1R4 ou V1R5)
 Principais mudanças no catálogo:
 Nomes longos
 Unicode
 Processo de migração:
 Somente partindo da Versão 7
 Processo em várias etapas
 Suporta coexistência das versões 7 e 8 em data sharing
somente no modo de compatibilidade
Caminhos para migração
Suspenso em 30/06/2002
V.5




V.6
V.7
V.8
Migrar para o DB2 for z/OS V7
Migrar para o z/OS V1R3 ou posterior
Requer WLM em goal mode
Migrar para o IBM COBOL V2 or V3
 Sem suporte para OS/VS COBOL or VS COBOL II
 Pode continuar a executar módulos antigos de COBOL sob LE,
mas sem garantia
 IMS V7, CICS TS V1.3 ou V2.2, IRLM 2.2
Migração para a versão 8
DB2 Versão 7
V8 Modo de Compatibilidade (CM)
Coexistência das
Versões 7 e 8
em data sharing
Retorno possível
com sucesso
do CATMAINT
Habilitação do Modo de Novas Funções (ENFM)
V8 Modo de Novas Funções (NFM)
Sem retorno para
V7 ou CM depois
de passar para
ENFM ou NFM
Modos de operação
V7
Módulos
- Módulos
da V7
- Funções
da V7
- Fallback SPE
DSNTIJTC
- Atualização do
CATMAINT
DSNTIJNE
- Início do
CATENFM
V8 CM
V8 ENFM
V8 NFM
- Módulos
da V8
- Algumas
funções
da V8
- Módulos
da V8
- Módulos
da V8
- Algumas
funções
da V8
Restaurar módulos V7
Catálogo
e
diretório
- Catálogo
e diretório
da V7
Catálogo V8
-EBCDIC
-nomes curtos
-padded IXs
DSNTIJNF
- Fim do
CATENFM
- Funções
da V8
DSNTIJNE
Catálogo V8
Catálogo V8
- EBCDIC/
- Unicode
Unicode
- nomes longos
- nomes
curtos/longos - not-padded
IXs (C/D)
- mixed IXs
Processo de migração (1)
 Aplicar fallback SPE (PQ48486) a todos os
membros
 Existência da PTF é mandatória
 Iniciar todos os membros no mesmo nível de SPE
 Migrar para o código da nova versão sem novas
funções (modo de compatibilidade)
 Usar CATMAINT para migrar o catálogo e diretório
 Esteja atento para sobrecargas
 Testar ambiente com novo código
Processo de migração (2)
 Habilitar modo de novas funções
 Todos os membros do data sharing group devem
estar em V8 CM
 Executar conversão das tabelas do catálogo para
nomes longos e Unicode
 Um table space de cada vez numa ordem obrigatória
 Usando online REORG com SHRLEVEL CHANGE
 Pode ser interrompido e reiniciado a qualquer tempo
 Depois da conversão de todos os objetos do
catálogo mudar para modo de novas funções
Verificação da instalação (IVP)
 Importante – não é possível executar os jobs de IVP
da Versão 8 até que o DB2 esteja no Modo de Novas
Funções da Versão 8
 Executar jobs da IVP da Versão 7 para verificar o
sucesso da migração para a Versão 8 Modo de
Compatibilidade
 Na migração é recomendado executar partes das
aplicações exemplo da Versão 7 no Modo de Novas
Funções da Versão 8
 Verificar a migração
 Garantir que os jobs antigos funcionam no Modo de Novas
Funções da Versão 8
 Os jobs da IVP da Versão 8 são criados pela CLIST
de instalação como parte da Habilitação do Modo de
Novas Funções no processo de migração
Mudanças no catálogo
 Nomes longos (128 byte varchar Unicode)




Table, view and alias
Column (30)
Schema
UDF, stored procedures, triggers, packages
 Alguns tamanhos de página maiores do que 4 KB
 Páginas de 4K, 8K, 16K, 32K no catálogo do DB2
 DB2 cria buffer pools para estes novos tamanhos de página
 Quando usando data sharing, o usuário tem que criar os GBP’s
para estes buffer pools
 Índices maiores do que 255 bytes
 Contem dados em Unicode
Conclusões
Vantagens da Versão 8
 Permite uso mais eficiente dos recursos
de hardware e software disponíveis
 Voltado para ambientes com grandes
volumes de acessos
 OLTP
 E-Business
 Queries
 OLAP
 Data Mining