[DB2 LUW] Tarefas de Manutenção – REORG, RUNSTATS, BIND/REBIND

Bem, dando continuidade a nossa série de posts para a certificação Associate do DB2 LUW, falaremos um pouco sobre Tarefas de Manutenção.
Este conteúdo pode ser consultado também no e-book Getting Started with DB2 Express-C (possui versão em português), capítulo 12, inclusive possui ao final do capítulo exercícios de fixação.

Este capítulo discute algumas das tarefas necessárias para uma boa manutenção do banco de dados. A direção geral no DB2 é automatizar a maioria dessas tarefas. Todas as edições do DB2 LUW, incluem recursos para automatizar as tarefas de manutenção. Esta capacidade de auto-gerenciamento é um enorme benefício para pequenas e médias empresas que não podem contratar um DBA em tempo integral para gerenciar o servidor de dados. Por outro lado, se for contratado um DBA, ele terá mais tempo livre para executar atividades avançadas que agregam valor aos resultados da empresa.

REORG, RUNSTATS, BIND/REBIND

Há três tarefas de manutenção principais no DB2 LUW, o REORG, o RUNSTATS e o BIND/REBIND.

Utilitário REORG

Com o tempo, ao executar operações INSERT, UPDATE e DELETE no banco de dados, os dados começam a ficar cada vez mais fragmentados nas páginas do banco de dados. O comando REORG recupera o espaço desperdiçado e reorganiza os dados para tornar a recuperação mais eficiente. As tabelas modificadas com frequência são as mais beneficiadas com o comando REORG.
Você pode usar o REORG também em índices, e um REORG pode ser executado on-line ou off-line. O REORG off-line é mais rápido e eficiente, mas não permite o acesso à tabela, enquanto o REORG on-line permite acesso à tabela mas pode consumir muitos recursos do sistema; ele funciona melhor com tabelas pequenas.
O comando REORGCHK pode ser usado antes de um REORG para determinar se uma tabela ou índice necessita de correção.

Exemplo de um comando de REORG simples:

Para saber mais sobre o utilitário de REORG acesse o INFOCENTER.
Para saber mais sobre o utilitário REORGCHK acesse o INFOCENTER.

Utilitário RUNSTATS

O otimizador é o “cérebro” do DB2. Ele encontra os caminhos de acesso mais eficientes para localizar e recuperar os dados. O otimizador é um sistema consciente dos custos, e utiliza estatísticas dos objetos de banco de dados armazenados nas tabelas de catálogo para maximizar o desempenho do banco de dados. Por exemplo, as tabelas de catálogo possuem estatísticas sobre quantas colunas estão presentes em uma tabela, quantas linhas existem, quantos e que tipo de índices estão disponíveis para uma tabela, e assim por diante.
As informações de estatística não são atualizadas dinamicamente. Isto é proposital, pois não é desejável que o DB2 atualize as estatísticas constantemente, para cada operação realizada no banco de dados. Isto teria um efeito negativo sobre o desempenho do banco de dados inteiro. Em vez disso, o DB2 fornece o comando RUNSTATS para atualizar tais estatísticas. Ele é essencial para manter atualizadas as estatísticas do banco de dados. O otimizador do DB2 pode fazer alterações radicais no caminho de acesso, se achar que uma tabela possui 1 linha em vez de 1 milhão de linhas. Quando as estatísticas do banco de dados estão atualizadas, o DB2 pode escolher um plano de acesso melhor. A frequência da coleta de estatísticas deve ser determinada pela frequência com que os dados são alterados na tabela.

Exemplo de um comando de RUNSTATS simples:

Para saber mais sobre o utilitário de RUNSTATS acesse o INFOCENTER.

Utilitário BIND/REBIND

Após executar com sucesso um comando RUNSTATS, nem todas as consultas usarão as estatísticas mais recentes. Os planos de acesso de SQLs estáticos são determinados ao executar pela primeira vez o comando BIND (associar); portanto, as estatísticas usadas nesse momento podem não ser iguais às atuais.
Associar (BIND) equivale a compilar as instruções SQL, onde o melhor plano de acesso é determinado com base nas estatísticas disponíveis no momento; em seguida, elas são armazenadas como pacotes no catálogo do banco de dados.
Agora, o que ocorre se forem inseridas 1 milhão de linhas em uma tabela usada no SQL deste pacote? Após a inserção, se for executado um RUNSTATS, as estatísticas serão atualizadas. Entretanto, o pacote não será atualizado automaticamente para recalcular o caminho de acesso com base nas estatísticas mais recentes. O comando db2rbind pode ser usado para associar  novamente os pacotes existentes, e assim levar as últimas estatísticas em consideração.

Exemplo de um comando de BIND/REBIND para atualizar estatistiscas de pacotes:

Para saber mais sobre o utilitário DB2RBIND acesse o INFOCENTER.

Opções de manutenção

Há três maneiras de realizar tarefas de manutenção:

• Manutenção manual : As atividades de manutenção são realizadas manualmente, quando surge a necessidade.
• Criar scripts para realizar manutenção: Você pode criar scripts com os comandos de manutenção e programá-los para serem executados regularmente.
• Manutenção automatizada: O DB2 cuida automaticamente da manutenção para você.

A manutenção automática consiste em:

• O usuário define uma janela de manutenção na qual as tarefas podem ser executadas com um mínimo de interrupções. Por exemplo, se o sistema tem sua menor atividade nos domingos de 2:00 às 4:00 da manhã, este horário funcionaria como janela de manutenção.
• Há duas janelas de manutenção: uma para operações on-line e outra para operações off-line.
• O DB2 executa automaticamente as operações de manutenção somente quanto necessário, durante as janelas de manutenção.

Assim terminamos mais um capítulo dos resumos para a certificação Associate DB2 LUW. Agora é hora de praticarmos. Para isso faça os exercícios deste capítulo e nos informe qualquer dúvida ou sugestão.
Obrigado e bons estudos!!!