DB2 COMMANDS sem Mistérios: do Primeiro -DISPLAY ao JCL de Manutenção

 

Bellacosa Mainframe e o db2 commands

☕ Um Café no Bellacosa Mainframe

DB2 COMMANDS sem Mistérios: do Primeiro -DISPLAY ao JCL de Manutenção

Imagine a cena, jovem Padawan do COBOL.

São 2h17 da madrugada. O processamento batch que atualiza milhões de registros de clientes está parado. O operador informa que o programa terminou com SQLCODE -904. O desenvolvedor revisa o SELECT, procura vírgula fora do lugar, confere as host variables, examina a SQLCA e recompila o programa.

Nada parece errado.

Nesse momento, o DBA abre o DB2I, entra no painel DB2 COMMANDS e executa:

-DIS DB(DSN00122) SPACENAM(ALUNOST1) RESTRICT

A resposta revela:

STATUS = COPY

O programa COBOL não estava com defeito. O table space estava em uma condição restritiva.

Essa é uma das primeiras grandes lições do universo Db2 for z/OS:

Nem todo erro recebido pelo programa nasceu dentro do programa.

O COBOL é apenas um dos viajantes dessa galáxia. Para alcançar uma linha armazenada no Db2, ele depende de uma longa cadeia:

Programa COBOL
      ↓
Instrução SQL
      ↓
DBRM
      ↓
Package
      ↓
Plan ou Package List
      ↓
Thread Db2
      ↓
Tabela
      ↓
Table Space
      ↓
Buffer Pool
      ↓
Data Set VSAM
      ↓
DASD

A tela apresentada mostra justamente uma das portas usadas para observar essa infraestrutura: o painel DB2 COMMANDS, acessível pelo DB2I dentro do TSO/ISPF.

Prepare a caneca, ajuste os óculos e vamos atravessar esse painel linha por linha.

---

Bellacosa Mainframe e o painel db2 commands

1. O que é o painel DB2 COMMANDS?

DB2I significa Db2 Interactive. Trata-se de um conjunto clássico de painéis ISPF que permite executar diversas atividades relacionadas ao Db2 for z/OS, como:

• rodar SQL pelo SPUFI;

• gerar DCLGEN;

• preparar programas;

• realizar BIND;

• executar utilitários;

• emitir comandos administrativos;

• acessar funções de ajuda e diagnóstico.

O painel da imagem apresenta no alto:

DB2 COMMANDS                       SSID: DB9G

A expressão DB2 COMMANDS identifica a função atual. Já SSID: DB9G informa para qual subsistema Db2 os comandos serão enviados.

A IBM documenta que comandos como -DISPLAY DATABASE e -DISPLAY BUFFERPOOL podem ser emitidos pelo console do z/OS, por uma sessão DSN no TSO, pelo painel DB2 COMMANDS, por terminais IMS ou CICS e por programas que usem a Instrumentation Facility Interface. (IBM)

Isso significa que o painel DB2I não é o único caminho. Ele é, porém, um dos mais didáticos para quem está começando.

---

2. SSID: o nome do reino Db2

Na imagem aparece:

SSID: DB9G

SSID significa Subsystem Identifier, ou identificador do subsistema.

Em um mesmo ambiente z/OS podem existir vários subsistemas Db2:

DB2D  → desenvolvimento
DB2T  → testes
DB2H  → homologação
DB2P  → produção
DB9G  → treinamento ou laboratório

Esses nomes são apenas exemplos. Cada empresa define seu próprio padrão.

O SSID é uma informação crítica porque um comando emitido para o subsistema errado pode causar um incidente. Veja a diferença:

-DIS DB(DSN00122)

Esse comando apenas consulta informações.

Já:

-STOP DB(DSN00122)

pode tornar o database ou seus espaços indisponíveis, dependendo dos parâmetros e do contexto.

O primeiro hábito de um bom DBA Padawan deve ser:

1. Confirmar o ambiente.
2. Confirmar o SSID.
3. Confirmar o objeto.
4. Confirmar se o comando é consultivo ou modificador.
5. Somente então pressionar ENTER.

No mainframe, a tecla ENTER não é apenas uma tecla. Algumas vezes, ela é um pequeno botão vermelho com o poder de acordar três gerentes, dois sysprogs e um diretor.

---

3. Por que os comandos começam com hífen?

Os comandos do subsistema Db2 geralmente começam com um hífen:

-DISPLAY DATABASE
-START DATABASE
-STOP DATABASE
-DISPLAY BUFFERPOOL
-DISPLAY THREAD
-DISPLAY LOG

O hífen ajuda o ambiente a reconhecer que a linha contém um comando Db2.

Compare:

SELECT NOME
  FROM ALUNOS
 WHERE MATRICULA = 1001;

Isso é uma instrução SQL.

-DIS DB(DSN00122)

Isso é um comando administrativo do subsistema Db2.

TSO LISTCAT

Isso é um comando TSO.

F ALUNOS,APPL=DISPLAY

Isso poderia ser um comando direcionado a uma started task ou aplicação pelo console, dependendo da instalação.

O hífen é, portanto, uma pequena placa dizendo:

“Esta mensagem pertence ao reino do Db2.”

---

4. A primeira linha: -DIS DATABASE(DSN00122)

Na tela encontramos:

-DIS DATABASE(DSN00122)

A forma completa é:

-DISPLAY DATABASE(DSN00122)

A abreviação documentada é:

-DIS DB(DSN00122)

O comando DISPLAY DATABASE apresenta informações sobre o estado de databases, table spaces, index spaces, partições e outros objetos relacionados. (IBM)

O que é um database no Db2 for z/OS?

Aqui existe uma armadilha conceitual.

Em produtos distribuídos, a palavra “database” frequentemente representa uma instância lógica ampla que contém schemas, tabelas, índices e outros objetos. No Db2 for z/OS, um database é principalmente um agrupador lógico e administrativo de espaços.

Considere:

DATABASE DSN00122
   |
   +-- TABLESPACE ALUNOST1
   |      |
   |      +-- TABLE ESCOLA.ALUNOS
   |
   +-- TABLESPACE CURSOST1
   |      |
   |      +-- TABLE ESCOLA.CURSOS
   |
   +-- INDEXSPACE ALUNOSX1
          |
          +-- INDEX ESCOLA.IXALUNO

O database ajuda a organizar, administrar, iniciar, parar e consultar grupos de objetos.

Ao executar:

-DIS DB(DSN00122)

você está perguntando:

“Db2, qual é o estado administrativo do database DSN00122?”

Uma resposta simplificada poderia apresentar:

DATABASE = DSN00122
STATUS   = RW

RW normalmente representa Read/Write, indicando disponibilidade para leitura e gravação.

Entretanto, aqui existe um detalhe importante: o database pode estar normal enquanto um de seus table spaces está restrito. O inverso também merece atenção: um espaço pode aparecer em modo RW, mas continuar inacessível se o database que o contém estiver em condição restritiva.

Por isso, a IBM orienta que uma investigação completa de estados restritivos pode exigir dois comandos: um para o database e outro usando SPACENAM para seus espaços. (IBM)

Exemplo:

-DIS DB(DSN00122) RESTRICT

Depois:

-DIS DB(DSN00122) SPACENAM(*) RESTRICT

O primeiro procura restrições no nível do database.

O segundo procura table spaces e index spaces em estados restritivos.

---

5. A segunda linha: procurando ALUNOST1

A imagem apresenta:

-DIS DATABASE (*) SPACENAM(ALUNOST1)

Uma escrita padronizada seria:

-DIS DB(*) SPACENAM(ALUNOST1)

ou, se soubermos o database:

-DIS DB(DSN00122) SPACENAM(ALUNOST1)

O que significa o asterisco?

O asterisco funciona como um curinga:

DATABASE(*)

significa:

“Considere todos os databases aplicáveis.”

Assim, o comando procura um espaço chamado ALUNOST1, mesmo que o operador não saiba em qual database ele está.

Isso pode ser muito útil em um laboratório, mas em produção é preferível ser específico sempre que possível:

-DIS DB(DSN00122) SPACENAM(ALUNOST1)

Quanto mais preciso o comando, menor a quantidade de saída, menor a chance de confusão e mais rápida a análise.

O que é SPACENAM?

SPACENAM significa space name.

Ele restringe a consulta a um table space ou index space específico:

SPACENAM(ALUNOST1)

Pergunta ao Db2:

“Qual é o estado do espaço chamado ALUNOST1?”

Uma resposta hipotética poderia ser:

DATABASE = DSN00122
SPACENAM = ALUNOST1
TYPE     = TS
STATUS   = RW

Onde:

TYPE = TS

indica um table space.

---

6. Table space: a casa física da tabela

Uma tabela Db2 não paira magicamente sobre o catálogo. Seus dados residem em um table space.

Considere:

CREATE TABLE ESCOLA.ALUNOS
(
    MATRICULA INTEGER       NOT NULL,
    NOME      VARCHAR(100)  NOT NULL,
    CURSO     CHAR(10),
    NOTA      DECIMAL(5,2),
    PRIMARY KEY (MATRICULA)
)
IN DSN00122.ALUNOST1;

A cláusula:

IN DSN00122.ALUNOST1

indica o database e o table space associados.

A relação simplificada é:

ESCOLA.ALUNOS
      ↓
DSN00122.ALUNOST1
      ↓
Data sets administrados pelo Db2
      ↓
Volumes DASD

Nos ambientes modernos, são comuns os Universal Table Spaces, incluindo:

• partition-by-growth, ou PBG;

• partition-by-range, ou PBR.

Em um PBG, o Db2 pode adicionar partições automaticamente à medida que o espaço cresce; ele mantém uma única tabela e utiliza características de gerenciamento segmentado. (IBM)

O programador COBOL não precisa administrar essas estruturas diariamente, mas deve compreender que seu SELECT depende delas.

---

7. O poderoso parâmetro RESTRICT

Um dos comandos mais úteis para diagnóstico é:

-DIS DB(DSN00122) SPACENAM(*) RESTRICT

A opção RESTRICT reduz a saída aos objetos que estão em estado restritivo. (IBM)

Sem RESTRICT, você pode receber dezenas ou centenas de linhas.

Com RESTRICT, a pergunta fica mais objetiva:

“Mostre somente aquilo que pode estar impedindo o funcionamento normal.”

Um comando ainda mais amplo seria:

-DIS DB(*) SPACENAM(*) RESTRICT

A própria IBM apresenta essa forma como maneira de descobrir espaços em condição restritiva, inclusive após determinadas operações de LOAD. (IBM)

Entretanto, em grandes ambientes, usar curingas amplos pode gerar muita saída. No dia a dia, prefira:

-DIS DB(DSN00122) SPACENAM(ALUNOST1) RESTRICT

---

8. Estados que o Padawan precisa reconhecer

Os códigos podem variar de acordo com o objeto, versão, comando e contexto, mas alguns conceitos aparecem frequentemente.

RW — Read/Write

O objeto aceita leitura e gravação.

STATUS = RW

Esse é normalmente o cenário desejado para objetos transacionais.

RO — Read Only

O objeto está disponível apenas para leitura.

Um comando como:

SELECT NOME
  FROM ESCOLA.ALUNOS;

pode funcionar.

Porém:

UPDATE ESCOLA.ALUNOS
   SET NOTA = 9.50
 WHERE MATRICULA = 1001;

pode falhar porque exige gravação.

STOP

O objeto foi parado ou está indisponível.

Após analisar a situação, um administrador autorizado poderia utilizar:

-START DB(DSN00122) SPACENAM(ALUNOST1)

A IBM define -START DATABASE como o comando que torna o database ou objetos especificados disponíveis para uso, conforme as opções escolhidas. (IBM)

Não se deve executar START automaticamente sem entender por que o objeto estava parado. Ele pode ter sido interrompido propositalmente para manutenção.

COPY-pending

Indica que o Db2 requer uma image copy ou que existe uma condição relacionada à proteção para recuperação.

A solução pode envolver o utilitário COPY, mas é preciso examinar:

• qual operação criou o estado;

• se a cópia deve ser full ou incremental;

• se haverá cópia local e de recovery site;

• qual política de retenção existe;

• se o objeto está participando de outro utilitário;

• qual nível de concorrência é necessário.

REORG-pending

Indica necessidade de materializar alguma alteração ou reorganizar o objeto, conforme o estado específico.

O utilitário REORG TABLESPACE pode reorganizar um table space, partição ou intervalo de partições, recuperar espaço fragmentado, melhorar o acesso e materializar alterações de definição pendentes. (IBM)

Mas atenção:

Nem toda estatística ligeiramente ruim exige REORG.

A IBM recomenda considerar diversos fatores e executar a reorganização quando houver indicação real de necessidade, não apenas por hábito. (IBM)

RECOVER-pending

O objeto precisa de recuperação antes de retornar ao uso normal.

Essa situação pode exigir o utilitário RECOVER, image copies e registros de log. É um procedimento de alta responsabilidade.

CHECK-pending

Pode indicar que a consistência entre dados, restrições ou objetos relacionados precisa ser validada.

Dependendo da situação, o procedimento pode utilizar CHECK DATA ou outra ação administrativa apropriada.

PRO — Persistent Read Only

O estado PRO permite acesso de leitura por SQL ou utilitários, mas bloqueia atualizações na partição afetada. Tentativas de gravação podem receber erro de recurso indisponível. (IBM)

---

9. A terceira linha: buffer pools

A tela mostra:

-DIS BUFFERPOOL(*)

A forma completa é:

-DISPLAY BUFFERPOOL(*)

A abreviação oficial documentada pela IBM é:

-DIS BPOOL(*)

O comando apresenta o estado atual de um ou mais buffer pools ativos ou inativos. (IBM)

Eu recomendaria padronizar a linha como:

-DIS BPOOL(*)

ou escrever tudo por extenso:

-DISPLAY BUFFERPOOL(*)

Evite misturar uma abreviação do verbo com uma forma não padronizada do restante do comando em procedimentos operacionais. Padronização reduz erros.

---

10. O que é um buffer pool?

Imagine que o DASD seja uma gigantesca biblioteca subterrânea.

As páginas das tabelas e índices estão armazenadas nessa biblioteca. Sempre que um programa precisa ler um registro, o Db2 precisa encontrar a página correspondente.

Buscar tudo diretamente no disco seria mais lento. Por isso, o Db2 mantém páginas utilizadas em áreas de memória chamadas buffer pools.

A IBM define buffer pools como áreas de armazenamento virtual usadas para atender às necessidades de buffering de table spaces e índices. Em versões atuais do Db2 for z/OS, essas estruturas ficam acima da “barra” de 2 GB. (IBM)

O fluxo simplificado é:

Programa solicita uma linha
          ↓
Db2 identifica a página
          ↓
Página já está no buffer pool?
      /                     \
    Sim                     Não
     ↓                       ↓
Leitura lógica       Leitura física no DASD
     ↓                       ↓
Entrega os dados      Carrega a página no pool
                              ↓
                       Entrega os dados

Alguns nomes comuns:

BP0
BP1
BP2
BP8K0
BP16K0
BP32K

A nomenclatura pode indicar o tamanho de página suportado:

BP0      → normalmente 4 KB
BP8K0    → 8 KB
BP16K0   → 16 KB
BP32K    → 32 KB

A configuração real deve ser confirmada no ambiente.

Consultando todos

-DIS BPOOL(*)

Consultando os ativos

-DIS BPOOL(ACTIVE)

Consultando um específico

-DIS BPOOL(BP0)

Solicitando detalhes

-DIS BPOOL(BP0) DETAIL

A IBM informa que o monitoramento pode fornecer relatório resumido ou detalhado. (IBM)

---

11. O hit ratio e a armadilha dos números bonitos

Uma ideia bastante usada em análises de buffer pool é o buffer pool hit ratio.

Uma fórmula didática simplificada é:

Hit Ratio =
  (Getpages - Leituras físicas)
  ----------------------------- × 100
             Getpages

Suponha:

Getpages          = 1.000.000
Leituras físicas  =    80.000

Então:

Hit Ratio = (1.000.000 - 80.000) / 1.000.000 × 100
Hit Ratio = 92%

Isso sugere que grande parte das solicitações foi atendida sem nova leitura física.

Mas um hit ratio alto não é automaticamente sinal de perfeição.

Pode existir:

• I/O síncrono justamente nas páginas críticas;

• buffer pool superdimensionado;

• disputa por memória real;

• mistura inadequada de workloads;

• prefetch pouco eficiente;

• páginas sem utilidade permanecendo na memória;

• desempenho ruim causado por SQL, não pelo cache.

O Easter egg técnico aqui é:

Um número verde no painel pode esconder um dragão vermelho no subterrâneo.

Analise sempre o contexto, a evolução ao longo do tempo, o tipo de aplicação e as métricas SMF ou de uma ferramenta de monitoramento.

---

12. Ligando a SQLCA aos comandos Db2

Considere um programa COBOL:

       EXEC SQL
           SELECT NOME,
                  NOTA
             INTO :WS-NOME,
                  :WS-NOTA
             FROM ESCOLA.ALUNOS
            WHERE MATRICULA = :WS-MATRICULA
       END-EXEC.

Depois da instrução, o programa verifica:

       EVALUATE SQLCODE
           WHEN 0
               DISPLAY 'ALUNO ENCONTRADO'
           WHEN 100
               DISPLAY 'ALUNO NAO ENCONTRADO'
           WHEN -904
               DISPLAY 'RECURSO INDISPONIVEL'
           WHEN OTHER
               DISPLAY 'ERRO SQL: ' SQLCODE
       END-EVALUATE.

Se SQLCODE for -904, o programa recebeu um erro de recurso indisponível. O próximo passo não deve ser imediatamente alterar o SQL.

Uma investigação responsável inclui:

1. Ler SQLCODE e SQLSTATE.
2. Examinar SQLERRMC na SQLCA.
3. Identificar o recurso indicado.
4. Descobrir database e table space.
5. Consultar o estado pelo DISPLAY DATABASE.
6. Verificar locks, claims ou utilitários.
7. Corrigir a causa.
8. Validar novamente.

Exemplo:

-DIS DB(DSN00122)

Depois:

-DIS DB(DSN00122) SPACENAM(ALUNOST1) RESTRICT

Se houver suspeita de bloqueio:

-DIS BLOCKERS

O comando DISPLAY BLOCKERS apresenta locks e claims mantidos por threads ativas contra databases, tabelas, índices ou espaços especificados. Sua abreviação é -DIS BL. (IBM)

---

13. JCL para executar uma image copy

Quando um table space está em COPY-pending e o procedimento aprovado determina a criação de uma image copy, um job semelhante ao seguinte pode ser usado.

Este é um modelo educacional. Procedures, nomes de DDs, unidades, classes, templates e políticas variam entre instalações.

//BCSCOPY  JOB (ACCT),'COPY ALUNOS',
//             CLASS=A,
//             MSGCLASS=X,
//             MSGLEVEL=(1,1),
//             NOTIFY=&SYSUID
//*
//COPYTS   EXEC DSNUPROC,
//             SYSTEM=DB9G,
//             UID='CPYALU01'
//*
//DSNUPROC.SYSIN DD *
  COPY TABLESPACE DSN00122.ALUNOST1
       FULL YES
       SHRLEVEL CHANGE
/*
//

Explicação detalhada da JOB statement

//BCSCOPY JOB (ACCT),'COPY ALUNOS',

BCSCOPY é o nome do job.

Ele deve seguir os padrões da instalação. Alguns ambientes usam identificação do usuário, aplicação e função:

VAGCOPY
PRDCOPY
DB2CPY01

JOB informa ao JES que uma nova unidade de trabalho está começando.

(ACCT)

É a informação contábil. Ela pode representar centro de custo, projeto ou código de cobrança. O formato depende da empresa.

'COPY ALUNOS'

É a descrição do job. Ela aparece em ferramentas como SDSF e ajuda a identificar sua finalidade.

CLASS

CLASS=A

Define a classe de execução.

A classe pode influenciar:

• prioridade;

• iniciador;

• limites;

• ambiente;

• horário;

• recursos disponíveis.

Não presuma que CLASS=A seja correta em sua empresa.

MSGCLASS

MSGCLASS=X

Define a classe de saída do spool.

Ela determina para onde irão mensagens JES, listagens e relatórios do job.

MSGLEVEL

MSGLEVEL=(1,1)

O primeiro valor controla a impressão das instruções JCL.

O segundo controla mensagens de alocação e desalocação.

Em termos didáticos, (1,1) solicita boa visibilidade para diagnóstico, mas o padrão corporativo pode ser diferente.

NOTIFY

NOTIFY=&SYSUID

Solicita que o usuário que submeteu o job seja notificado ao término.

&SYSUID é uma variável simbólica que representa o usuário logado.

---

14. Explicando o passo EXEC

//COPYTS EXEC DSNUPROC,

COPYTS é o nome do step.

EXEC informa que o step executará um programa ou procedure.

DSNUPROC representa uma procedure para execução de utilitários Db2. O nome real pode ser:

DSNUPROC
DSNUTIL
DB2UTIL
DSNUPR13

Isso depende da instalação.

SYSTEM=DB9G

Passa à procedure o subsistema Db2 de destino.

Esse parâmetro precisa corresponder ao ambiente correto.

UID='CPYALU01'

Define um identificador para a execução do utilitário.

O UID ajuda a distinguir jobs e pode aparecer em mensagens, registros e controles internos. Seu tamanho e padrão precisam obedecer às regras da procedure utilizada.

---

15. Explicando o SYSIN

//DSNUPROC.SYSIN DD *

Essa linha fornece as instruções de controle do utilitário.

DD significa Data Definition.

O asterisco indica que os dados estão escritos diretamente no JCL, logo abaixo da linha.

Dependendo de como a procedure foi criada, a referência pode ser:

//SYSIN DD *

ou:

//DSNUPROC.SYSIN DD *

Quando existe uma procedure catalogada, o formato qualificado pode substituir o DD interno do step da procedure.

Agora vem a instrução:

COPY TABLESPACE DSN00122.ALUNOST1

Ela solicita uma cópia do table space ALUNOST1, pertencente ao database DSN00122.

FULL YES

Solicita uma image copy completa, em vez de uma cópia incremental baseada em alterações.

SHRLEVEL CHANGE

Permite determinado nível de concorrência com aplicações durante a cópia. A compatibilidade exata depende do tipo do objeto e das operações concorrentes; existem claims, drains e restrições específicas que devem ser verificadas. (IBM)

A IBM também permite definir data sets de cópia local e de recovery site por opções como COPYDDN e RECOVERYDDN. (IBM)

O delimitador:

/*

encerra os dados instream de SYSIN.

---

16. Versão com TEMPLATE

Em ambientes modernos, é comum utilizar TEMPLATE para gerar dinamicamente nomes dos data sets de cópia.

Exemplo educacional:

//BCSCOPY  JOB (ACCT),'COPY ALUNOS',
//             CLASS=A,MSGCLASS=X,NOTIFY=&SYSUID
//COPYTS   EXEC DSNUPROC,
//             SYSTEM=DB9G,
//             UID='CPYALU02'
//DSNUPROC.SYSIN DD *
  TEMPLATE CPYDS
       DSN 'BCS.DB2.&DB..&TS..D&DATE..T&TIME.'
       UNIT SYSALLDA
       DISP (NEW,CATLG,DELETE)

  COPY TABLESPACE DSN00122.ALUNOST1
       COPYDDN(CPYDS)
       FULL YES
       SHRLEVEL CHANGE
/*
//

TEMPLATE

TEMPLATE CPYDS

Cria um template chamado CPYDS.

DSN 'BCS.DB2.&DB..&TS..D&DATE..T&TIME.'

Define o padrão do nome do data set.

As variáveis simbólicas do utilitário podem inserir informações como database, table space, data e hora, conforme as opções suportadas.

Um nome resultante poderia ser semelhante a:

BCS.DB2.DSN00122.ALUNOST1.D20260714.T021700

UNIT SYSALLDA

Solicita alocação em uma unidade de disco elegível no grupo SYSALLDA.

DISP (NEW,CATLG,DELETE)

Significa:

• NEW: o data set será criado;

• CATLG: se o step terminar normalmente, será catalogado;

• DELETE: se falhar, será excluído.

A IBM fornece exemplos de uso de TEMPLATE e COPYDDN para image copies. (IBM)

---

17. JCL de REORG TABLESPACE

Quando a análise demonstra necessidade real de reorganização, um modelo poderia ser:

//BCSREORG JOB (ACCT),'REORG ALUNOS',
//             CLASS=A,
//             MSGCLASS=X,
//             MSGLEVEL=(1,1),
//             NOTIFY=&SYSUID
//*
//REORGTS  EXEC DSNUPROC,
//             SYSTEM=DB9G,
//             UID='RGOALU01'
//*
//DSNUPROC.SYSIN DD *
  REORG TABLESPACE DSN00122.ALUNOST1
        SHRLEVEL CHANGE
        SORTDATA
        STATISTICS
        TABLE ALL
        INDEX ALL
/*
//

REORG TABLESPACE

REORG TABLESPACE DSN00122.ALUNOST1

Solicita a reorganização do table space.

O utilitário pode recuperar espaço fragmentado, reorganizar registros e materializar certas mudanças de definição pendentes. (IBM)

SHRLEVEL CHANGE

Permite que aplicações continuem realizando leituras e gravações durante grande parte do processo.

Em uma reorganização online, o Db2 pode trabalhar com uma shadow copy, registrar mudanças no log, aplicar essas alterações à cópia e realizar uma fase de troca. (IBM)

Isso não significa “zero impacto”. Ainda podem existir:

• drains;

• fases críticas;

• espera por aplicações;

• aumento de logging;

• necessidade de espaço;

• impacto de CPU e I/O;

• timeout na troca final.

SORTDATA

Solicita ordenação dos dados, normalmente de acordo com a chave de clustering aplicável.

Nos exemplos documentados, SORTDATA é o padrão em cenários tradicionais e pode ser omitido, mas escrevê-lo ajuda didaticamente a deixar a intenção clara. (IBM)

STATISTICS

Solicita a coleta de estatísticas durante o REORG.

Essas informações podem atualizar o catálogo e auxiliar o otimizador na escolha de access paths.

TABLE ALL

Solicita estatísticas para todas as tabelas aplicáveis do table space.

INDEX ALL

Inclui estatísticas dos índices associados, conforme as regras do utilitário e do objeto.

Em produção, as opções devem seguir a estratégia da empresa. Coletar estatísticas indiscriminadamente pode causar alterações de access path após um novo BIND ou REBIND.

---

18. JCL de RUNSTATS separado

Nem sempre você precisa reorganizar para atualizar estatísticas.

Um job de RUNSTATS poderia ser:

//BCSRSTAT JOB (ACCT),'RUNSTATS ALUNOS',
//             CLASS=A,
//             MSGCLASS=X,
//             NOTIFY=&SYSUID
//RSTAT    EXEC DSNUPROC,
//             SYSTEM=DB9G,
//             UID='RSTALU01'
//DSNUPROC.SYSIN DD *
  RUNSTATS TABLESPACE DSN00122.ALUNOST1
           TABLE(ALL)
           INDEX(ALL)
           SHRLEVEL CHANGE
           REPORT YES
           UPDATE ALL
/*
//

RUNSTATS TABLESPACE

Define o objeto cujas estatísticas serão coletadas.

TABLE(ALL)

Inclui todas as tabelas aplicáveis.

INDEX(ALL)

Inclui os índices associados.

SHRLEVEL CHANGE

Busca permitir concorrência com aplicações, observadas as regras da versão e do objeto.

REPORT YES

Produz relatório com informações coletadas.

UPDATE ALL

Solicita atualização das estatísticas aplicáveis no catálogo.

O cuidado Jedi é não tratar RUNSTATS como uma rotina sem consequências. Estatísticas alteradas podem influenciar o otimizador. Após REBIND, um programa pode escolher outro índice, usar outro método de join ou abandonar um access path antigo.

---

19. Um fluxo completo de diagnóstico

Considere o incidente:

PROGRAMA  : CADP001
TABELA    : ESCOLA.ALUNOS
SQLCODE   : -904
SQLSTATE  : 57011

Passo 1 — Ler toda a SQLCA

Não olhe apenas para SQLCODE.

Verifique também:

SQLSTATE
SQLERRMC
SQLERRD
SQLWARN

SQLERRMC pode conter identificadores úteis sobre o recurso indisponível.

Passo 2 — Localizar o objeto físico

Uma consulta ao catálogo pode ajudar:

SELECT DBNAME,
       TSNAME
  FROM SYSIBM.SYSTABLES
 WHERE CREATOR = 'ESCOLA'
   AND NAME    = 'ALUNOS';

Resultado hipotético:

DBNAME    TSNAME
--------  ---------
DSN00122  ALUNOST1

Passo 3 — Consultar o database

-DIS DB(DSN00122) RESTRICT

Passo 4 — Consultar o espaço

-DIS DB(DSN00122) SPACENAM(ALUNOST1) RESTRICT

Passo 5 — Verificar utilitários

Dependendo da situação e das autorizações:

-DIS UTIL(*)

Isso ajuda a descobrir se COPY, LOAD, REORG, RECOVER ou outro utilitário está em execução.

Passo 6 — Verificar bloqueadores

-DIS BL

ou uma forma mais específica, conforme a sintaxe e o objeto investigado.

Passo 7 — Escolher a ação

Possibilidades:

COPY-pending    → avaliar e executar COPY
REORG-pending   → planejar REORG
RECOVER-pending → seguir procedimento de RECOVER
STOP            → descobrir a causa antes de START
LOCK/CLAIM      → analisar thread e aplicação

Passo 8 — Validar

Depois da ação:

-DIS DB(DSN00122) SPACENAM(ALUNOST1) RESTRICT

Se nenhuma restrição for mostrada, execute também uma validação funcional controlada.

---

20. Biblioteca de comandos para o painel

As linhas disponíveis no painel podem guardar uma pequena coleção:

Cmd 1 ===> -DIS DB(DSN00122)

Cmd 2 ===> -DIS DB(DSN00122) SPACENAM(ALUNOST1)

Cmd 3 ===> -DIS DB(DSN00122) SPACENAM(*) RESTRICT

Cmd 4 ===> -DIS BPOOL(ACTIVE)

Cmd 5 ===> -DIS BPOOL(BP0) DETAIL

Cmd 6 ===> -DIS THD(*)

Cmd 7 ===> -DIS LOG

O comando é executado posicionando o cursor em sua linha e pressionando ENTER.

Isso permite montar uma pequena “maleta de primeiros socorros” para o DBA Padawan.

---

21. Curiosidades e Easter eggs do templo Db2

O prefixo DSN

Muitos componentes, programas, procedures e mensagens do Db2 usam o prefixo DSN:

DSN
DSNUTILB
DSNUPROC
DSNTIAUL
DSNTEP2
DSNTEP4
DSN9022I

O prefixo funciona quase como a assinatura arqueológica do produto.

Ao encontrar algo iniciado por DSN, existe uma boa chance de você estar diante de um artefato relacionado ao Db2 for z/OS.

NORMAL COMPLETION não significa objeto saudável

Uma mensagem como:

DSN9022I ... NORMAL COMPLETION

significa que o comando foi processado normalmente.

Ela não significa que o objeto consultado esteja normal.

O comando pode terminar com sucesso e mostrar:

STATUS = COPY

É como um exame médico: a coleta foi bem-sucedida, mas o resultado pode apontar um problema.

O programa COBOL enxerga a consequência

O desenvolvedor recebe:

SQLCODE -904

O DBA enxerga:

COPY-pending

O operador enxerga:

job terminado com RC 12

O storage administrator pode enxergar:

problema de volume ou data set

Todos observam o mesmo incidente por janelas diferentes.

O profissional completo aprende a juntar essas janelas.

---

Conclusão: o SELECT é apenas a superfície

A tela DB2 COMMANDS parece simples: fundo preto, letras em ciano e algumas linhas de comando.

Mas por trás dela existe uma arquitetura capaz de sustentar bancos, seguradoras, governos, indústrias, companhias aéreas e sistemas que movimentam valores gigantescos.

Os três comandos da imagem percorrem três níveis fundamentais:

-DIS DB(DSN00122)

Observa o agrupamento administrativo.

-DIS DB(DSN00122) SPACENAM(ALUNOST1)

Observa o espaço que armazena os dados.

-DIS BPOOL(*)

Observa a memória que mantém páginas desses objetos.

Para o programador COBOL Padawan, compreender esses níveis transforma a maneira de diagnosticar problemas. Em vez de concluir que todo SQLCODE nasceu de um erro de programação, ele começa a pensar em camadas:

Código
  ↓
SQL
  ↓
Package
  ↓
Autorização
  ↓
Thread
  ↓
Lock ou claim
  ↓
Estado do objeto
  ↓
Buffer pool
  ↓
Data set
  ↓
Storage
  ↓
Log e recuperação

Essa é a passagem de aprendiz para profissional de verdade.

O Padawan pergunta:

“Por que meu SELECT falhou?”

O Jedi do mainframe pergunta:

“Qual componente da cadeia deixou de cumprir sua parte?”

E, muitas vezes, a resposta começa com uma linha curta, digitada em uma tela 3270:

-DIS DB(DSN00122) SPACENAM(ALUNOST1) RESTRICT

Apenas alguns caracteres.

Mas, no universo IBM Z, alguns caracteres podem revelar todo um império escondido atrás do programa COBOL.