Utilitários DB2 — RUNSTATS, REORG, COPY e RECOVER

Os utilitários do DB2 são jobs JCL que cuidam da saúde do banco de dados — coletam estatísticas, reorganizam dados fragmentados, fazem backup e recuperam tablespaces corrompidos. Em ambientes bancários rodam toda noite na janela batch. Saber o que cada um faz, em que ordem executar e qual opção de disponibilidade usar é conhecimento obrigatório para qualquer profissional de mainframe.

1. Como os utilitários são executados

Todos os utilitários DB2 rodam como jobs JCL que chamam o programa DSNUTILB. O PARM identifica o subsistema DB2 e o nome do utilitário. O controle fica no DD SYSIN.

JCLEstrutura básica de um job de utilitário DB2

//DBUTL    JOB (CONTA),'DB2 UTIL',CLASS=A,MSGCLASS=X
//UTIL     EXEC PGM=DSNUTILB,
//              PARM='DB2P,NOMEUTL'   ← subsistema,nome-único-do-job
//STEPLIB  DD DSN=DB2.SDSNLOAD,DISP=SHR
//SYSPRINT DD SYSOUT=*
//UTPRINT  DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//SYSIN    DD *
  /* instrução do utilitário aqui */
/*

✅ O segundo parâmetro do PARM (NOMEUTL) é o UID do utilitário — deve ser único por subsistema DB2. Se um job de utilitário falhar e você tentar rodar de novo com o mesmo UID, o DB2 vai recusar. Use TERM UTILITY(NOMEUTL) para liberar antes de re-executar.

2. SHRLEVEL — disponibilidade durante o utilitário

A maioria dos utilitários suporta o parâmetro SHRLEVEL, que controla o nível de acesso concorrente ao tablespace durante a execução.

SHRLEVEL	Permite durante execução	Impacto
`NONE`	Nenhum acesso — tablespace drenado completamente	Máximo desempenho do utilitário, zero disponibilidade
`REFERENCE`	Somente leitura (SELECT)	Bom desempenho, sem escritas concorrentes
`CHANGE`	Leitura e escrita concorrentes	Menor desempenho, máxima disponibilidade

🦕 Analogia: SHRLEVEL NONE é como fechar uma rua para obras — ninguém passa. REFERENCE é como fechar uma faixa — só ônibus (leitura) passa. CHANGE é fazer a obra com o trânsito fluindo — mais devagar, mas a cidade não para.

3. RUNSTATS — coletando estatísticas

O RUNSTATS examina o conteúdo físico do tablespace e dos índices e grava estatísticas no catálogo DB2 (SYSIBM.SYSTABLESTATS, SYSIBM.SYSINDEXSTATS). O otimizador usa essas estatísticas para montar planos de acesso.

JCL/SYSINRUNSTATS — variações principais

-- Estatísticas de tabela e todos os índices
  RUNSTATS TABLESPACE SCHEMA1.TSCONTAS
    TABLE(ALL)
    INDEX(ALL)
    SHRLEVEL REFERENCE

-- Apenas índices (mais rápido — sem varrer os dados)
  RUNSTATS TABLESPACE SCHEMA1.TSCONTAS
    INDEX(ALL)
    SHRLEVEL REFERENCE

-- Com histograma de distribuição de valores (para colunas com skew)
  RUNSTATS TABLESPACE SCHEMA1.TSCONTAS
    TABLE(SCHEMA1.CONTAS
      COLUMN(STATUS, COD_AGENCIA)
      NUMCOLS 2)
    INDEX(ALL)
    SHRLEVEL REFERENCE

🟣 NUMCOLS e histograma: por padrão, o RUNSTATS coleta apenas cardinalidade (número de valores distintos). Com NUMCOLS, ele coleta histograma de distribuição — essencial para colunas com data skew, onde alguns valores aparecem em 90% das linhas e outros em 0,1%. Sem histograma, o otimizador assume distribuição uniforme e pode escolher um plano errado para predicados em colunas desbalanceadas.

Quando executar RUNSTATS

Após carga massiva de dados (LOAD)
Após REORG (obrigatório — o REORG invalida estatísticas antigas)
Após criar ou dropar índices
Quando queries antes rápidas começam a degradar sem motivo aparente
Periodicamente em tabelas com alto volume de INSERT/DELETE

4. REORG — reorganizando dados e índices

Com o tempo, INSERTs fora de ordem e DELETEs criam fragmentação no tablespace — o cluster ratio cai e o prefetch sequencial perde eficiência. O REORG TABLESPACE reconstrói o tablespace fisicamente, restaurando a ordem do clustering index e liberando espaço de páginas deletadas.

JCL/SYSINREORG TABLESPACE — opções mais comuns

-- REORG completo com tablespace indisponível
  REORG TABLESPACE SCHEMA1.TSCONTAS
    UNLOAD CONTINUE
    SHRLEVEL NONE
    DRAIN_WAIT 30
    RETRY 3

-- REORG online (permite leitura durante execução)
  REORG TABLESPACE SCHEMA1.TSCONTAS
    UNLOAD CONTINUE
    SHRLEVEL REFERENCE
    DRAIN_WAIT 60

-- REORG online com escrita concorrente (SHRLEVEL CHANGE)
-- Mais lento, mas sem impacto em sistemas 24x7
  REORG TABLESPACE SCHEMA1.TSCONTAS
    SHRLEVEL CHANGE
    DRAIN_WAIT 30
    RETRY 5
    RETRY_DELAY 10

Parâmetro	O que faz
`UNLOAD CONTINUE`	Descarrega dados para arquivo temporário antes de reorganizar
`UNLOAD PAUSE`	Para após o unload e aguarda comando para continuar
`DRAIN_WAIT n`	Segundos aguardando que transações ativas terminem antes de drenar
`RETRY n`	Tentativas de drenar o tablespace se DRAIN_WAIT expirar
`RETRY_DELAY n`	Segundos entre tentativas de drain

REORG INDEX

Reorganiza apenas a estrutura B-tree do índice, sem tocar nos dados da tabela. Mais rápido que o REORG TABLESPACE quando só o índice está fragmentado.

JCL/SYSIN

  REORG INDEX SCHEMA1.XCONTA01
    SHRLEVEL REFERENCE

-- Ou todos os índices de um tablespace de uma vez
  REORG TABLESPACE SCHEMA1.TSCONTAS
    INDEX(ALL)
    SHRLEVEL REFERENCE

⚠️ Sempre RUNSTATS depois do REORG. O REORG altera a estrutura física dos dados — as estatísticas antigas deixam de representar a realidade. Sem RUNSTATS pós-REORG, o otimizador continua usando estatísticas desatualizadas e pode escolher planos ruins. A sequência correta é: COPY → REORG → RUNSTATS → REBIND.

5. COPY — backup de tablespaces

O utilitário COPY faz uma image copy — uma cópia física das páginas do tablespace — que é usada pelo RECOVER para restaurar em caso de falha. É o equivalente do backup de banco de dados no mundo mainframe.

JCL/SYSINCOPY — full e incremental

-- Full image copy — copia todas as páginas
  COPY TABLESPACE SCHEMA1.TSCONTAS
    SHRLEVEL REFERENCE
    FULL YES
    DSNUM ALL

-- Incremental image copy — só páginas alteradas desde o último COPY
-- Mais rápido, mas a recovery precisa do full + todos os incrementais
  COPY TABLESPACE SCHEMA1.TSCONTAS
    SHRLEVEL REFERENCE
    FULL NO

-- Copy com duas saídas (cópia local + remota para DR)
  COPY TABLESPACE SCHEMA1.TSCONTAS
    SHRLEVEL REFERENCE
    FULL YES
    COPYDDN (SYSUT1, SYSUT2)

✅ COPY é obrigatório antes de REORG e LOAD. Se o REORG ou LOAD falhar no meio, o tablespace fica em estado inconsistente (COPY-PENDING). Sem uma image copy recente, a única saída é restaurar de um backup anterior — potencialmente perdendo horas de dados.

Estados do tablespace relacionados ao COPY

Estado	O que significa	Como resolver
`COPY PENDING (COPY)`	Tablespace modificado mas sem image copy atualizada	Executar COPY
`RECOVER PENDING (RECP)`	Tablespace corrompido — leitura e escrita bloqueadas	Executar RECOVER
`REBUILD PENDING (RBDP)`	Índice precisa ser reconstruído	Executar REBUILD INDEX
`CHECK PENDING (CHKP)`	Integridade referencial não validada	Executar CHECK DATA

6. RECOVER — restaurando tablespaces

O RECOVER restaura um tablespace a partir da image copy mais recente e aplica o log do DB2 (active log e archive logs) para trazer o tablespace ao estado mais atual possível ou até um ponto específico no tempo.

JCL/SYSINRECOVER — variações

-- Recover completo — restaura ao estado mais recente
  RECOVER TABLESPACE SCHEMA1.TSCONTAS

-- Recover até um ponto no tempo (para desfazer um erro humano)
  RECOVER TABLESPACE SCHEMA1.TSCONTAS
    TORBA X'000001234567'     ← RBA (log position) — pega no log

  RECOVER TABLESPACE SCHEMA1.TSCONTAS
    TOLOGPOINT X'000001234567'

-- Recover de um índice específico
  RECOVER INDEX SCHEMA1.XCONTA01

-- REBUILD INDEX — reconstrói índice a partir dos dados da tabela
-- (mais rápido que RECOVER INDEX quando os dados estão íntegros)
  REBUILD INDEX (SCHEMA1.XCONTA01)

🟣 RECOVER vs REBUILD INDEX: o RECOVER restaura o índice a partir de image copies e logs — útil quando a tabela também foi corrompida. O REBUILD INDEX reconstrói o índice varrendo os dados atuais da tabela — muito mais rápido quando os dados estão íntegros e só o índice foi perdido (ex: após um LOAD com REPLACE).

7. CHECK DATA e CHECK INDEX

Após LOAD ou RECOVER, o tablespace pode entrar em estado CHECK PENDING, indicando que a integridade referencial não foi validada. O CHECK DATA verifica se as chaves estrangeiras estão íntegras e se as restrições de check estão satisfeitas.

JCL/SYSIN

-- Verificar integridade referencial
  CHECK DATA TABLESPACE SCHEMA1.TSCONTAS
    SCOPE PENDING

-- CHECK INDEX — verifica consistência entre índice e tabela
  CHECK INDEX (ALL) TABLESPACE SCHEMA1.TSCONTAS

-- Para limpar o estado CHECK PENDING sem verificar (CUIDADO!)
-- Só use quando tiver certeza da integridade
  REPAIR SET TABLESPACE SCHEMA1.TSCONTAS
    NOCHECKPEND

8. LOAD — carga massiva de dados

O LOAD insere dados em um tablespace diretamente nas páginas, sem passar pelo log de transações linha a linha — por isso é muito mais rápido que INSERTs convencionais para grandes volumes.

JCL/SYSINLOAD básico a partir de arquivo sequencial

//LOAD     EXEC PGM=DSNUTILB,PARM='DB2P,LOADCONT'
//STEPLIB  DD DSN=DB2.SDSNLOAD,DISP=SHR
//SYSPRINT DD SYSOUT=*
//SYSREC00 DD DSN=SCHEMA1.CONTAS.INPUT,DISP=SHR  ← arquivo de entrada
//SYSERR   DD DSN=SCHEMA1.CONTAS.ERRORS,          ← linhas rejeitadas
//             DISP=(NEW,CATLG),SPACE=(CYL,(5,1))
//SYSIN    DD *
  LOAD DATA INDDN SYSREC00
    INTO TABLE SCHEMA1.CONTAS
    (COD_CONTA     POSITION(1:10)   CHAR,
     NOME_TITULAR  POSITION(11:60)  CHAR,
     SALDO         POSITION(61:76)  DECIMAL EXTERNAL,
     DT_ABERTURA   POSITION(77:84)  DATE EXTERNAL)
    RESUME YES               ← adiciona aos dados existentes
    ENFORCE NO               ← não valida FK durante LOAD
    LOG NO                   ← sem log de transações (mais rápido)
/*

Parâmetro	Opções	Efeito
`RESUME`	YES / NO	YES=adiciona; NO=substitui os dados (REPLACE)
`LOG`	YES / NO	NO=sem log individual por linha (muito mais rápido, mas exige COPY após)
`ENFORCE`	YES / NO	NO=não valida FK — tablespace entra em CHECK PENDING
`SORTKEYS`	YES / NO	YES=ordena chaves antes de inserir no índice (clustering mais eficiente)

⚠️ LOAD com LOG NO exige COPY imediatamente após. Como os dados não foram gravados no log, o DB2 marca o tablespace como COPY-PENDING — sem um backup, não é possível fazer RECOVER em caso de falha. A sequência obrigatória é: LOAD → COPY → RUNSTATS → CHECK DATA (se ENFORCE NO) → REBIND.

9. Ordem típica de execução

Em uma janela batch noturna de manutenção, os utilitários seguem uma ordem lógica para garantir consistência e recuperabilidade:

FluxoManutenção noturna típica

  1. COPY (full)          ← backup antes de qualquer mudança
       │
  2. REORG TABLESPACE     ← reorganiza dados e restaura cluster ratio
       │
  3. RUNSTATS             ← coleta estatísticas do estado reorganizado
       │
  4. COPY (full)          ← backup do tablespace reorganizado
       │
  5. REBIND               ← atualiza planos de acesso com novas estatísticas
       │
  6. (opcional) CHECK DATA   ← valida integridade se houve LOAD anterior

✅ COPY antes e depois do REORG: o COPY antes garante um ponto de recuperação caso o REORG falhe. O COPY depois garante que o estado reorganizado pode ser recuperado. Em produção sempre existe o COPY pré-REORG.

10. Monitorando utilitários

Utilitários podem demorar horas em tabelas grandes. Durante a execução, é possível monitorar o progresso via comandos DB2 no console z/OS ou no SDSF.

DB2 CommandsComandos de operação de utilitários

-- Exibir utilitários em execução
-DB2P DISPLAY UTILITY(*)

-- Exibir utilitário específico
-DB2P DISPLAY UTILITY(NOMEUTL)

-- Terminar utilitário (libera UID para re-execução)
-DB2P TERM UTILITY(NOMEUTL)

-- Ver tablespaces em estados de restrição (COPY PENDING, RECP...)
-DB2P DISPLAY DATABASE(SCHEMA1) RESTRICT

SQLConsultando estados de tablespaces no catálogo

-- Tablespaces com alguma restrição de acesso
SELECT DBNAME, TSNAME, STATUS, COPYPPEND, RECOVERYPEND,
       RBDPEND, CHECKPEND
  FROM SYSIBM.SYSTABLESPACESTATS
 WHERE DBNAME = 'SCHEMA1'
   AND (COPYPPEND   = 'Y'
    OR  RECOVERYPEND = 'Y'
    OR  RBDPEND      = 'Y'
    OR  CHECKPEND    = 'Y');

-- Histórico de image copies disponíveis para recovery
SELECT DBNAME, TSNAME, DSNAME, ICTYPE, ICDATE, ICTIME,
       DSVOLSER, START_RBA, STOP_RBA
  FROM SYSIBM.SYSCOPY
 WHERE DBNAME = 'SCHEMA1'
   AND TSNAME = 'TSCONTAS'
 ORDER BY ICDATE DESC, ICTIME DESC;

🟣 SYSCOPY é o registro de auditoria do RECOVER. Toda image copy executada com sucesso gera uma linha em SYSIBM.SYSCOPY. O utilitário RECOVER consulta essa tabela para saber quais datasets usar na restauração. Se uma imagem copy for deletada do catálogo (DELETE FROM SYSIBM.SYSCOPY) sem deletar o dataset — ou vice-versa — o RECOVER vai falhar. O utilitário MERGECOPY consolida incrementais em uma full copy e limpa entradas antigas do SYSCOPY.