 |
| Bellacosa Mainframe e o db2 utilies sem misterios |
☕ Um Café no Bellacosa Mainframe
DB2 Utilities sem Mistérios
O Guia do Programador COBOL Padawan para Entender REBUILD, REORG, COPY, RUNSTATS e o JCL por Trás da Tela Verde
Imagine a seguinte cena.
Você está diante de um terminal 3270. A tela preta parece silenciosa, quase imóvel. No alto aparece a inscrição:
DB2 UTILITIES
À direita, surge o nome do subsistema:
SSID: DB9G
No centro da tela, alguns campos aparentemente simples:
FUNCTION ==> EDITJCL
JOB ID ==> TEMP
UTILITY ==> REBUILD
RESTART ==> NO
LISTDEF ==> NO
TEMPLATE ==> NO
Para um programador COBOL Padawan, essa tela pode parecer apenas mais um formulário antigo do ISPF. Talvez algo criado em uma era na qual os monitores eram pesados, os teclados faziam barulho e os programadores carregavam manuais do tamanho de listas telefônicas.
Mas não se deixe enganar pela simplicidade visual.
Essa tela é como o painel de controle de uma enorme estação orbital. Por trás de poucos campos existe um conjunto de programas capazes de copiar, reorganizar, validar, reconstruir, descarregar e recuperar bancos de dados que podem armazenar bilhões de registros.
É aqui que o Db2 deixa de ser apenas o lugar onde seu programa COBOL executa um SELECT ou um UPDATE e revela sua verdadeira natureza: um sistema vivo que precisa de manutenção, estatísticas, cópias de segurança, reorganização e monitoramento constante.
Hoje vamos abrir esse painel, desmontar seus componentes e entender a engenharia escondida por trás de cada opção.
 |
| Bellacosa Mainframe e a tela do db2 para comandos de administracao |
1. A tela não executa a mágica: ela gera as ordens
O primeiro conceito importante é compreender que o painel do Db2 Utilities não é, por si só, o utilitário.
Ele funciona como uma interface de preparação.
O fluxo normalmente é:
Usuário
|
v
Painel ISPF
|
v
Parâmetros informados
|
v
Geração de JCL
|
v
Submissão ao JES2
|
v
Execução do utilitário Db2
|
v
Mensagens no spool
O painel pergunta:
Qual utilitário deseja executar?
Qual subsistema Db2 será utilizado?
Onde estão os comandos do utilitário?
Deseja apenas editar o JCL ou submetê-lo?
A execução será nova ou continuará uma execução anterior?
Serão utilizadas listas automáticas?
Serão utilizados templates para datasets?
Com essas respostas, ele monta o JCL necessário.
Essa filosofia é muito comum no mainframe: a interface não tenta esconder completamente o que está acontecendo. Ela ajuda, orienta e gera o material operacional, mas o profissional ainda consegue examinar o JCL, alterar parâmetros e analisar o resultado.
2. SSID: escolhendo o universo Db2 correto
Na imagem temos:
SSID: DB9G
SSID significa:
Subsystem Identifier
É o identificador do subsistema Db2.
Uma instalação z/OS pode executar vários subsistemas Db2. Cada um representa um ambiente independente, com seu próprio catálogo, logs, buffer pools, planos, packages e objetos.
Exemplos:
DB2D - Desenvolvimento
DB2T - Testes
DB2H - Homologação
DB2P - Produção
DB9G - Ambiente de laboratório ou treinamento
O nome não possui uma regra universal. Cada organização define seu padrão.
Essa escolha é crítica.
Executar um REBUILD INDEX em desenvolvimento é uma coisa.
Executar no subsistema de produção, durante o horário de pico, é outra completamente diferente.
Um erro no SSID pode transformar uma atividade rotineira em um incidente.
Easter egg operacional
Muitos profissionais experientes confirmam o SSID várias vezes antes de submeter um utilitário. Não é paranoia. É memória histórica.
Um DBA pode ter duas sessões abertas:
Sessão 1: DB2D
Sessão 2: DB2P
As telas são praticamente idênticas.
Um comando correto no ambiente errado continua sendo um comando errado.
3. FUNCTION: o que fazer com o JCL
Na tela aparece:
FUNCTION ==> EDITJCL
Esse campo define o destino da operação.
As opções normalmente incluem:
SUBMIT
EDITJCL
DISPLAY
TERMINATE
3.1 EDITJCL
A opção EDITJCL gera o JCL e abre o resultado no editor ISPF.
É uma das opções mais seguras, pois permite revisar tudo antes da execução.
Você pode conferir:
Fluxo:
Painel
|
v
Geração do JCL
|
v
ISPF Edit
|
v
Revisão humana
|
v
SUBMIT
Para produção, essa revisão é importantíssima.
3.2 SUBMIT
A opção SUBMIT gera o JCL e o envia diretamente ao JES2.
É prática e rápida, mas elimina a oportunidade de revisão manual.
Pode ser adequada em ambientes controlados, especialmente quando:
o procedimento já foi testado;
o JCL segue um padrão;
os datasets são gerados por template;
o objeto já foi validado;
o usuário conhece o impacto da operação.
Para um Padawan, EDITJCL é a escolha mais educativa.
3.3 DISPLAY
DISPLAY permite consultar utilitários em execução ou pendentes.
Um utilitário Db2 mantém informações sobre seu estado.
Por exemplo:
UTILID = REORGP01
PHASE = RELOAD
STATUS = ACTIVE
Isso permite saber:
qual utilitário está executando;
qual objeto está sendo processado;
em qual fase está;
se está parado;
se aguarda algum recurso;
se pode ser reiniciado.
3.4 TERMINATE
TERMINATE encerra o estado registrado de uma utility.
Mas cuidado: terminar uma utility não significa simplesmente “cancelar um job”.
Existe uma diferença entre:
CANCEL do job no JES2
e:
TERM UTILITY no Db2
Quando um job é cancelado, o Db2 pode manter informações de restart.
A utility continua registrada como incompleta.
O comando de término informa ao Db2 que aquela execução não será retomada.
Essa operação deve ser feita com conhecimento, porque pode eliminar a possibilidade de restart daquela utility.
4. JOB ID: identificando a missão
Na imagem:
JOB ID ==> TEMP
Esse campo serve como identificador para a geração ou para a execução.
Dependendo do painel e do modelo utilizado, ele pode participar da criação de:
JOBNAME;
utility ID;
nomes temporários;
membros;
datasets de trabalho.
Exemplos mais descritivos:
REBLIDX
REORGCAD
COPYFIN
RUNSTPRD
LOADCLI
Em produção, nomes claros ajudam muito.
Compare:
TEMP
com:
RBCUST01
O segundo nome já sugere:
RB = Rebuild
CUST = Customer
01 = Execução ou partição
Quando dezenas de jobs aparecem no SDSF, uma boa nomenclatura reduz confusão.
5. UTILITY: escolhendo a ferramenta certa
Na imagem, a opção selecionada é:
UTILITY ==> REBUILD
O painel lista vários utilitários:
CHECK DATA
CHECK INDEX
CHECK LOB
COPY
DIAGNOSE
LOAD
MERGE
MODIFY
QUIESCE
REBUILD
RECOVER
REORG INDEX
REORG LOB
REORG TABLESPACE
REPORT
REPAIR
RUNSTATS
STOSPACE
UNLOAD
Cada um resolve um problema diferente.
Vamos entender os principais.
6. REBUILD INDEX: reconstruindo a árvore
Um índice Db2 normalmente utiliza uma estrutura semelhante a uma árvore B+.
Ele permite localizar rapidamente linhas sem ler toda a tabela.
Imagine uma tabela:
TB_CLIENTE
com as colunas:
ID_CLIENTE
CPF
NOME
CIDADE
SALDO
E um índice:
IX_CLIENTE_CPF
Ao executar:
SELECT NOME
FROM TB_CLIENTE
WHERE CPF = '12345678900';
o Db2 pode consultar o índice e localizar diretamente a página correspondente.
Com o tempo, porém, o índice sofre alterações:
O REBUILD INDEX recria a estrutura.
Fluxo conceitual
Leitura dos dados ou das chaves
|
v
Ordenação das chaves
|
v
Criação de nova estrutura
|
v
Gravação das páginas do índice
|
v
Validação e disponibilização
Exemplo de comando Db2
REBUILD INDEX
(DBFIN.IXCLIENT)
SHRLEVEL REFERENCE
SORTDEVT SYSDA
SORTNUM 8
STATISTICS
Explicando cada linha
REBUILD INDEX
Solicita a reconstrução de um índice.
(DBFIN.IXCLIENT)
Identifica o indexspace ou objeto que será reconstruído. A sintaxe exata pode variar conforme o tipo de objeto e a convenção utilizada.
SHRLEVEL REFERENCE
Permite determinado nível de acesso concorrente, geralmente leitura, enquanto restringe alterações durante partes da execução.
SORTDEVT SYSDA
Indica o tipo genérico de dispositivo a ser utilizado para arquivos temporários de sort.
SORTNUM 8
Solicita uma quantidade de datasets de trabalho para ordenação.
STATISTICS
Pede a coleta de estatísticas durante ou após o processo, quando suportado pela utility e configuração.
7. Exemplo completo de JCL para REBUILD INDEX
//RBIDX01 JOB (ACCT),'REBUILD INDEX',
// CLASS=A,
// MSGCLASS=X,
// NOTIFY=&SYSUID
//*
//STEP01 EXEC PGM=DSNUTILB,
// REGION=0M,
// PARM='DB9G,RBIDX01'
//STEPLIB DD DISP=SHR,DSN=DB2.V13.SDSNLOAD
//SYSPRINT DD SYSOUT=*
//UTPRINT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//SORTDEVT DD DUMMY
//SYSIN DD *
REBUILD INDEX
(DBFIN.IXCLIENT)
SHRLEVEL REFERENCE
SORTDEVT SYSDA
SORTNUM 8
/*
//
Agora vamos desmontar esse JCL como um engenheiro desmontaria um processador antigo.
7.1 JOB statement
//RBIDX01 JOB (ACCT),'REBUILD INDEX',
O nome do job é:
RBIDX01
Ele será exibido no JES2 e no SDSF.
(ACCT)
Representa informações contábeis ou administrativas. O formato depende da instalação.
'REBUILD INDEX'
É uma descrição humana da execução.
7.2 CLASS
// CLASS=A,
A classe determina como o JES2 tratará o job.
Pode influenciar:
prioridade;
initiator;
ambiente de execução;
limite de recursos;
janela operacional.
Cada empresa configura suas classes.
7.3 MSGCLASS
// MSGCLASS=X,
Define onde as mensagens e listagens do job serão direcionadas.
Normalmente controla a classe de saída no spool.
7.4 NOTIFY
// NOTIFY=&SYSUID
Pede que o usuário seja notificado quando o job terminar.
&SYSUID é uma variável simbólica que representa o usuário que submeteu o job.
7.5 EXEC PGM=DSNUTILB
//STEP01 EXEC PGM=DSNUTILB,
Aqui está o programa que executa a utility.
DSNUTILB é o batch utility program do Db2 for z/OS.
Ele recebe os comandos, conversa com o subsistema Db2 e coordena a operação.
7.6 REGION=0M
// REGION=0M,
Solicita que o step utilize a quantidade de memória permitida pelas políticas do sistema, sem um limite artificial pequeno definido no JCL.
Isso não significa memória infinita.
O z/OS, o WLM e as configurações de instalação continuam impondo limites.
7.7 PARM
// PARM='DB9G,RBIDX01'
O primeiro parâmetro identifica o subsistema Db2:
DB9G
O segundo funciona como utility ID:
RBIDX01
A utility ID precisa ser administrada com cuidado.
Se uma utility falhar e permanecer registrada, uma nova execução com a mesma ID pode encontrar conflito ou tentar continuar uma execução anterior, dependendo dos parâmetros.
7.8 STEPLIB
//STEPLIB DD DISP=SHR,DSN=DB2.V13.SDSNLOAD
Aponta para a biblioteca onde se encontram os módulos executáveis do Db2.
DISP=SHR
Permite compartilhar a biblioteca com outros jobs.
Em algumas instalações, a biblioteca já está no LINKLIST ou definida em um procedimento catalogado. Nesse caso, o STEPLIB pode não ser necessário.
7.9 SYSPRINT
//SYSPRINT DD SYSOUT=*
Recebe as mensagens principais da utility.
É um dos primeiros lugares que você deve consultar no spool.
Ali podem aparecer:
parâmetros reconhecidos;
objetos processados;
fases executadas;
mensagens de erro;
return code;
estatísticas;
tempos de execução.
7.10 UTPRINT
//UTPRINT DD SYSOUT=*
Recebe mensagens relacionadas ao processamento da utility.
Dependendo do utilitário e da versão, pode conter informações adicionais importantes.
7.11 SYSUDUMP
//SYSUDUMP DD SYSOUT=*
Solicita um dump caso ocorra uma falha anormal.
Esse dump pode ser enorme, mas é muito útil para diagnóstico técnico.
Em ambientes de produção, dumps podem ser direcionados a datasets específicos ou sistemas de gerenciamento de dumps.
7.12 SYSIN
//SYSIN DD *
Aqui começam os comandos da utility.
O asterisco indica que os dados estão embutidos no próprio JCL.
REBUILD INDEX
(DBFIN.IXCLIENT)
O conteúdo termina com:
/*
Também seria possível armazenar os comandos em um membro de PDS:
//SYSIN DD DISP=SHR,
// DSN=IBMUSER.WORKBOOK.DB2.ERG(ERGREBL)
Esse formato corresponde ao campo mostrado na imagem:
STATEMENT DATA SET
IBMUSER.WORKBOOK.DB2.ERG(ERGREBL)
8. STATEMENT DATA SET: separando o JCL do comando
Na tela aparece um dataset semelhante a:
IBMUSER.WORKBOOK.DB2.ERG(ERGREBL)
Esse é um membro de uma biblioteca particionada.
Podemos dividir o nome assim:
IBMUSER
WORKBOOK
DB2
ERG
ERGREBL
O trecho entre parênteses é o membro:
ERGREBL
Dentro dele provavelmente existe algo semelhante a:
REBUILD INDEX
(DBFIN.IXCLIENT)
SHRLEVEL REFERENCE
SORTDEVT SYSDA
SORTNUM 8
A vantagem de armazenar o comando separadamente é a reutilização.
O mesmo JCL pode apontar para comandos diferentes:
ERGREBL - REBUILD
ERGREOG - REORG
ERGRUNS - RUNSTATS
ERGCOPY - COPY
Isso também melhora o controle de mudanças.
9. RESTART: começando de novo ou retomando a jornada
Na imagem:
RESTART ==> NO
Utilitários Db2 podem ser longos.
Um REORG de um tablespace gigantesco pode durar horas. Durante esse tempo, podem ocorrer:
Para evitar que todo o trabalho seja perdido, algumas utilities mantêm pontos de controle.
As opções apresentadas incluem:
NO
CURRENT
PHASE
PREVIEW
NO
RESTART = NO
Indica uma nova execução.
Não deseja retomar uma execução anterior.
CURRENT
Tenta continuar a utility a partir do ponto atual registrado.
PHASE
Permite reiniciar a partir de uma fase específica suportada.
PREVIEW
Permite visualizar ou avaliar informações da execução sem realizar todo o processamento normal, dependendo da utility e do contexto.
Exemplo conceitual
Uma utility REORG pode passar por fases como:
UTILINIT
UNLOAD
RELOAD
SORT
BUILD
LOG
SWITCH
UTILTERM
Se houver falha durante BUILD, o restart pode evitar a repetição completa das fases anteriores.
Cuidado
Nunca altere parâmetros de restart aleatoriamente.
O estado registrado no Db2 precisa corresponder ao comando informado. Alterações incompatíveis podem impedir a retomada ou gerar resultados inesperados.
10. RUNSTATS: ensinando o otimizador a enxergar
Agora vamos falar de uma utility indispensável.
O otimizador do Db2 escolhe caminhos de acesso com base em estatísticas.
Ele precisa saber:
quantidade de linhas;
número de páginas;
cardinalidade das colunas;
distribuição dos valores;
quantidade de valores distintos;
organização dos dados;
níveis do índice;
clustering;
frequência de determinados valores.
Sem estatísticas atualizadas, o otimizador toma decisões com informações antigas.
Imagine que uma tabela possuía 10 mil registros quando o último RUNSTATS foi executado.
Hoje ela possui 500 milhões.
O catálogo ainda diz:
CARDF = 10000
O otimizador pode escolher um caminho de acesso adequado para uma pequena tabela, mas desastroso para uma tabela gigantesca.
Exemplo de JCL para RUNSTATS
//RUNST01 JOB (ACCT),'RUNSTATS',
// CLASS=A,
// MSGCLASS=X,
// NOTIFY=&SYSUID
//STEP01 EXEC PGM=DSNUTILB,
// REGION=0M,
// PARM='DB9G,RUNST01'
//STEPLIB DD DISP=SHR,DSN=DB2.V13.SDSNLOAD
//SYSPRINT DD SYSOUT=*
//UTPRINT DD SYSOUT=*
//SYSIN DD *
RUNSTATS TABLESPACE DBFIN.TSCLIENT
TABLE(ALL)
INDEX(ALL)
SHRLEVEL CHANGE
UPDATE ALL
REPORT YES
/*
//
Explicação
RUNSTATS TABLESPACE DBFIN.TSCLIENT
Solicita estatísticas do tablespace.
TABLE(ALL)
Processa todas as tabelas relevantes existentes naquele tablespace.
INDEX(ALL)
Coleta estatísticas de todos os índices associados.
SHRLEVEL CHANGE
Permite que aplicações continuem alterando os dados, dentro das regras e limitações da utility.
UPDATE ALL
Atualiza as estatísticas correspondentes no catálogo.
REPORT YES
Solicita relatório das informações coletadas.
11. COPY: criando uma linha do tempo para recuperação
A utility COPY cria uma image copy de um tablespace ou indexspace.
Não pense nela apenas como um “backup de arquivo”.
Ela faz parte da estratégia de recuperação do Db2.
Fluxo simplificado:
Image Copy
+
Active Logs
+
Archive Logs
=
Recuperação até um ponto desejado
Exemplo
//COPY01 JOB (ACCT),'COPY TABLESPACE',
// CLASS=A,
// MSGCLASS=X,
// NOTIFY=&SYSUID
//STEP01 EXEC PGM=DSNUTILB,
// REGION=0M,
// PARM='DB9G,COPY01'
//STEPLIB DD DISP=SHR,DSN=DB2.V13.SDSNLOAD
//SYSPRINT DD SYSOUT=*
//UTPRINT DD SYSOUT=*
//SYSIN DD *
COPY TABLESPACE DBFIN.TSCLIENT
FULL YES
SHRLEVEL CHANGE
COPYDDN COPYDD
/*
//COPYDD DD DSN=BACKUP.DBFIN.TSCLIENT.D20260713,
// DISP=(NEW,CATLG,DELETE),
// UNIT=SYSDA,
// SPACE=(CYL,(500,100),RLSE),
// DCB=(RECFM=FB,LRECL=4096,BLKSIZE=0)
//
FULL YES
Cria uma cópia completa.
SHRLEVEL CHANGE
Permite alterações concorrentes durante grande parte do processo.
COPYDDN COPYDD
Liga o comando Db2 ao DD statement chamado COPYDD.
DISP
DISP=(NEW,CATLG,DELETE)
Significa:
NEW - o dataset será criado;
CATLG - se o step terminar normalmente, será catalogado;
DELETE - se o step falhar, será excluído.
SPACE
SPACE=(CYL,(500,100),RLSE)
Solicita:
Unidade de alocação: cilindros
Primária: 500
Secundária: 100
RLSE: liberar espaço não utilizado
12. REORG TABLESPACE: colocando a casa em ordem
Com o tempo, os dados podem perder a organização física ideal.
Isso ocorre por:
inserts fora da sequência;
deletes;
updates que aumentam o tamanho da linha;
page splits;
crescimento irregular;
espaços vazios;
registros deslocados;
baixa correlação com o índice de clustering.
O REORG TABLESPACE reorganiza os dados.
Exemplo
//REORG01 JOB (ACCT),'REORG TABLESPACE',
// CLASS=A,
// MSGCLASS=X,
// NOTIFY=&SYSUID
//STEP01 EXEC PGM=DSNUTILB,
// REGION=0M,
// PARM='DB9G,REORG01'
//STEPLIB DD DISP=SHR,DSN=DB2.V13.SDSNLOAD
//SYSPRINT DD SYSOUT=*
//UTPRINT DD SYSOUT=*
//SYSIN DD *
REORG TABLESPACE DBFIN.TSCLIENT
LOG YES
SHRLEVEL CHANGE
SORTDEVT SYSDA
SORTNUM 12
STATISTICS
TABLE(ALL)
INDEX(ALL)
/*
//
LOG YES
Registra as alterações necessárias nos logs conforme as regras do utilitário.
SHRLEVEL CHANGE
Busca manter o objeto disponível para leitura e alteração durante boa parte da execução.
Isso não significa ausência absoluta de impacto.
Pode existir uma fase curta de troca ou sincronização na qual bloqueios são necessários.
SORTNUM 12
Solicita até doze datasets de sort.
Mais datasets não significam automaticamente mais desempenho. É necessário considerar:
13. LISTDEF: selecionando objetos por regras
Na imagem:
LISTDEF? ==> NO
LISTDEF permite definir uma lista de objetos de forma lógica.
Sem LISTDEF:
REORG TABLESPACE DB01.TS001
REORG TABLESPACE DB01.TS002
REORG TABLESPACE DB01.TS003
REORG TABLESPACE DB01.TS004
Com LISTDEF, você pode criar uma regra:
LISTDEF LISTFIN
INCLUDE TABLESPACE DBFIN.*
Depois:
RUNSTATS LIST LISTFIN
ou, conforme a utility e sintaxe suportada:
COPY LIST LISTFIN
O grande benefício aparece em ambientes com centenas ou milhares de objetos.
Exemplo conceitual
LISTDEF LISTAPPL
INCLUDE TABLESPACE DBAPP.*
EXCLUDE TABLESPACE DBAPP.TSTEMP*
A lista inclui todos os tablespaces do banco DBAPP, exceto os temporários.
Isso permite automação sem manter uma lista manual interminável.
14. TEMPLATE: fabricando nomes de datasets automaticamente
Na imagem:
TEMPLATE? ==> NO
O TEMPLATE permite definir padrões para datasets utilizados pelas utilities.
Sem TEMPLATE, cada COPY precisa de um DD statement:
//COPY01 DD DSN=BACKUP.DB1.TS1...
//COPY02 DD DSN=BACKUP.DB1.TS2...
//COPY03 DD DSN=BACKUP.DB1.TS3...
Com TEMPLATE, o Db2 pode gerar os nomes dinamicamente.
Exemplo conceitual:
TEMPLATE COPYTMP
DSN 'BACKUP.&DB..&TS..D&DATE..T&TIME.'
UNIT SYSDA
DISP (NEW,CATLG,DELETE)
SPACE CYL
PCTPRIME 20
Depois:
COPY LIST LISTFIN
COPYDDN COPYTMP
Os símbolos podem representar elementos como:
database;
tablespace;
data;
hora;
partição;
utility ID;
sequência.
O resultado pode ser:
BACKUP.DBFIN.TSCLIENT.D20260713.T231500
Isso reduz drasticamente o tamanho do JCL.
15. CHECK INDEX e CHECK DATA: o exame médico do banco
CHECK INDEX verifica a consistência entre o índice e os dados.
Ele procura situações como:
Exemplo:
//CHKIDX01 JOB (ACCT),'CHECK INDEX',
// CLASS=A,
// MSGCLASS=X
//STEP01 EXEC PGM=DSNUTILB,
// REGION=0M,
// PARM='DB9G,CHKIDX01'
//STEPLIB DD DISP=SHR,DSN=DB2.V13.SDSNLOAD
//SYSPRINT DD SYSOUT=*
//UTPRINT DD SYSOUT=*
//SYSIN DD *
CHECK INDEX
(DBFIN.IXCLIENT)
/*
//
CHECK DATA verifica relacionamentos e consistência de dados, especialmente em situações envolvendo constraints e dependências.
Esses utilitários não devem ser confundidos com consultas SQL de validação funcional.
Eles atuam no nível estrutural e operacional do Db2.
16. LOAD e UNLOAD: a doca de carga do Db2
UNLOAD
Extrai dados de uma tabela ou tablespace para um dataset sequencial.
Exemplo conceitual:
UNLOAD TABLESPACE DBFIN.TSCLIENT
FROM TABLE FINANCEIRO.CLIENTE
UNLDDN SYSREC
JCL:
//SYSREC DD DSN=EXPORT.CLIENTE.D20260713,
// DISP=(NEW,CATLG,DELETE),
// UNIT=SYSDA,
// SPACE=(CYL,(100,50),RLSE),
// DCB=(RECFM=VB,LRECL=32756,BLKSIZE=0)
LOAD
Carrega grandes volumes de dados.
Exemplo:
LOAD DATA
INDDN SYSREC
INTO TABLE FINANCEIRO.CLIENTE
A utility LOAD é muito mais eficiente que executar milhões de comandos INSERT individualmente.
Mas ela exige planejamento.
Dependendo das opções utilizadas, pode:
17. RECOVER: quando o treinamento vira batalha real
RECOVER restaura um objeto usando image copies e logs.
Imagine que alguém executou:
DELETE FROM FINANCEIRO.CLIENTE;
COMMIT;
O ROLLBACK já não pode ajudar porque houve COMMIT.
Uma estratégia de recuperação pode utilizar:
Image Copy anterior
+
Logs posteriores
+
Ponto no tempo antes do erro
Exemplo conceitual:
RECOVER TABLESPACE DBFIN.TSCLIENT
TORBA X'00000000123456789012'
ou outra opção de point-in-time recovery suportada no ambiente.
Essa não é uma operação improvisada.
Antes de recuperar, a equipe precisa responder:
Qual foi o horário do erro?
Há image copy válida?
Os archive logs estão disponíveis?
Existem objetos relacionados?
Há integridade referencial?
Outros tablespaces precisam voltar ao mesmo ponto?
Quais aplicações devem ser interrompidas?
Como os dados posteriores serão reconciliados?
Um recovery tecnicamente bem-sucedido pode ainda produzir inconsistência de negócio se objetos relacionados forem recuperados para momentos diferentes.
18. Como acompanhar o job no SDSF
Depois de submeter o JCL, você normalmente abre o SDSF.
Comandos comuns:
ST
Mostra jobs ativos e concluídos conforme seus filtros.
Localize:
RBIDX01
Abra o job com S.
Você verá DDs como:
JESMSGLG
JESJCL
JESYSMSG
SYSPRINT
UTPRINT
SYSUDUMP
JESMSGLG
Contém mensagens do JES e informações gerais da execução.
JESJCL
Mostra o JCL expandido.
É especialmente útil quando foram utilizados:
procedures catalogadas;
símbolos;
includes;
overrides.
JESYSMSG
Contém mensagens do sistema, alocações e término dos steps.
SYSPRINT
Normalmente contém a narrativa principal da utility Db2.
19. Return codes: nem todo zero conta a história completa
Os códigos de retorno mais comuns são:
RC=0000
RC=0004
RC=0008
RC=0012
RC=0016
RC 0000
Execução normal.
Mesmo assim, leia as mensagens.
RC 0004
Aviso.
A utility pode ter terminado, mas algo merece atenção.
RC 0008
Erro relevante.
Parte do processamento pode não ter ocorrido.
RC 0012 ou superior
Erro grave.
A operação provavelmente falhou ou foi interrompida.
Nunca analise apenas o número final.
Procure mensagens Db2 com prefixos como:
DSNU
DSN
IEC
IGD
ICE
ICH
Cada família pode indicar uma origem diferente:
Db2 utility;
sistema;
dataset;
SMS;
sort;
segurança.
20. Passo a passo seguro para o Padawan
Antes de executar uma utility, siga uma sequência disciplinada.
Passo 1 — Confirme o ambiente
Verifique:
SSID
LPAR
Usuário
Qualificador dos datasets
Banco
Tablespace
Índice
Passo 2 — Entenda o motivo
Não execute REORG apenas porque “sempre executamos”.
Pergunte:
Há fragmentação?
As estatísticas indicam necessidade?
Existe impacto de desempenho?
O objeto está em estado pendente?
Houve LOAD?
O índice está inconsistente?
Existe recomendação de manutenção?
Passo 3 — Estime o impacto
Considere:
tamanho do objeto;
duração;
CPU;
I/O;
espaço de sort;
logs;
concorrência;
bloqueios;
janela de manutenção.
Passo 4 — Confira a recuperação
Antes de uma operação destrutiva ou de grande impacto, confirme:
Passo 5 — Use EDITJCL
Revise o JCL gerado.
Passo 6 — Valide o SYSIN
Um pequeno erro no objeto muda tudo.
Compare:
DBFIN.TSCLIENT
com:
DBFIM.TSCLIENT
Uma letra pode apontar para outro banco ou causar falha.
Passo 7 — Submeta e acompanhe
Não envie o job e abandone a sessão.
Observe:
início;
consumo;
mensagens;
fases;
locks;
tempo;
espaço;
término.
Passo 8 — Valide o resultado
Depois da utility:
confira o return code;
leia o SYSPRINT;
valide estados pendentes;
confirme disponibilidade;
execute consultas funcionais;
atualize documentação;
registre duração e consumo.
21. Curiosidades e easter eggs do mundo Db2
A tela simples esconde um sistema distribuído de responsabilidades
O painel ISPF coleta parâmetros.
O JES2 agenda o job.
O z/OS gerencia memória e recursos.
O Db2 controla catálogo, logs e objetos.
O DFSORT pode ordenar dados.
O SMS aloca datasets.
O RACF valida autorizações.
O WLM decide prioridades.
Uma única execução de REORG pode envolver quase todo o ecossistema do mainframe.
DSNUTILB parece apenas um programa, mas é um maestro
Ele não “faz tudo sozinho”.
Ele coordena serviços do Db2, acessa objetos, solicita sort, gerencia fases e registra estados de restart.
O nome da utility ID é mais importante do que parece
Uma utility ID não é apenas uma etiqueta estética.
Ela pode estar associada ao controle de execução e restart.
Reutilizar IDs sem compreender o estado anterior pode gerar confusão.
REORG não é um ritual religioso
Em algumas empresas, utilities são executadas em calendários fixos herdados de décadas anteriores.
Por exemplo:
Todo sábado: REORG em tudo.
Isso pode ser desnecessário e caro.
A abordagem moderna deve considerar indicadores reais e políticas inteligentes.
RUNSTATS pode melhorar ou piorar um plano
Estatísticas novas ajudam o otimizador, mas também podem provocar mudança de access path.
Por isso ambientes críticos costumam combinar RUNSTATS com:
análise de EXPLAIN;
gerenciamento de packages;
avaliação de regressão;
controles de estabilidade;
monitoramento pós-implantação.
Conclusão: a Utility é a oficina do Db2
Para o programador COBOL Padawan, o Db2 começa com comandos como:
SELECT
INSERT
UPDATE
DELETE
Mas o banco de dados não sobrevive apenas de SQL.
Ele precisa de manutenção.
Precisa saber como os dados estão distribuídos.
Precisa reorganizar estruturas.
Precisa reconstruir índices.
Precisa criar cópias.
Precisa recuperar informações.
Precisa validar sua própria integridade.
É exatamente isso que as Db2 Utilities oferecem.
A tela mostrada parece modesta:
FUNCTION ==> EDITJCL
UTILITY ==> REBUILD
Entretanto, por trás dela existe uma cadeia poderosa:
ISPF
|
v
JCL
|
v
JES2
|
v
DSNUTILB
|
v
Db2
|
v
Catálogo + Logs + Tablespaces + Índices
O grande aprendizado não é simplesmente decorar que REBUILD reconstrói um índice ou que RUNSTATS atualiza estatísticas.
O verdadeiro aprendizado é entender que cada utility participa de uma estratégia maior de disponibilidade, desempenho, integridade e recuperação.
No mainframe, a tela verde raramente conta toda a história.
Ela mostra apenas a porta.
Atrás dela existe uma engenharia construída durante décadas, refinada por milhões de execuções e responsável por manter sistemas bancários, governamentais, industriais e corporativos funcionando enquanto o restante do mundo dorme.
E quando o Padawan finalmente entende o JCL, as mensagens do spool, as fases da utility e o motivo de cada parâmetro, aquela velha tela deixa de parecer antiga.
Ela passa a parecer exatamente o que sempre foi:
um console de manutenção de uma das plataformas de dados mais resilientes do planeta.
