Reorganizações do banco de dados:  Por que eles são importantes e a diferença entre on-line e off-line

As reorganizações do banco de dados são realizadas para economizar espaço de dados e melhorar a eficiência e o desempenho do banco de dados. Este artigo explica o porquê. O próximo artigo mostra como reorganizar várias tabelas e bancos de dados no Eclipse.

Os dados em grandes tabelas RDBMS eventualmente se tornam fragmentados. O tamanho das tabelas e índices aumenta à medida que os registros são distribuídos em mais páginas de dados. Mais leituras de página e linhas em ordem de não junção durante a execução da consulta tornam as respostas de consulta lentas. Para recuperar o espaço desperdiçado, melhorar o tempo de atividade do banco de dados e acelerar o acesso aos dados (respostas de consulta), considere uma estratégia para reorganizar seus objetos de banco de dados.

As reorganizações de banco de dados consistem em dois tipos para esses objetos de tabela, índice e tablespace:on-line (no local) e off-line (clássico).

Banco de dados on-line as reorganizações funcionam de forma incremental movendo linhas dentro da tabela existente para restabelecer o clustering, recuperar espaço livre e eliminar linhas de estouro. Os objetos ficam indisponíveis apenas por um curto período de tempo próximo ao final, não durante as fases de recarregamento e reconstrução, que podem ser prolongadas para objetos grandes. Eles permitem que os aplicativos se conectem ao banco de dados, mas geralmente diminuem seu desempenho e podem criar esperas de bloqueio nesse momento.

Banco de dados off-line reorgs são mais rápidos, mas podem deixar o banco de dados off-line (se o utilitário de reorganização de banco de dados for usado). Com este método, os dados são exportados do banco de dados para um arquivo de despejo (descarregar). Os objetos de banco de dados são configurados com base na extração, normalmente reordenada (classificação). Eles são então retornados ao mesmo tablespace (load), onde os índices são restaurados implicitamente (rebuild).

Os DBAs preocupados com o desempenho usam o IRI FACT (Fast Extract) para o descarregamento, que cria um arquivo simples portátil que pode ser classificado (com IRI CoSort) na chave de índice primária da tabela reorganizada. Com essa abordagem, outras operações de transformação e geração de relatórios podem ocorrer e o banco de dados permanece on-line. Os carregamentos de caminho direto pré-ordenados também ignoram a classificação (sobrecarga) do carregador de banco de dados. Todas essas operações são automatizadas no assistente de reorganização offline do IRI Workbench.

Manter uma cópia “sombra” dos dados no sistema de arquivos para cada tabela não deve ser excessivamente oneroso porque, uma vez que o arquivo simples é classificado e recarregado, ele pode ser excluído. Ao mesmo tempo, ter os dados de reorganização externalizados e disponíveis para o CoSort também permite a possibilidade de outros usos dos dados, incluindo arquivamento, relatórios, proteção e migração para outro banco de dados, ferramenta de BI e destinos de aplicativos.

A ressalva, claro, é que durante o descarregamento, outros usuários do sistema podem ler e atualizar o espaço de tabela, portanto, quaisquer atualizações durante esse período podem perder o recarregamento e criar inconsistências no destino. Portanto, é recomendado que as reorganizações off-line sejam executadas quando as atualizações não estiverem ocorrendo.

A IRI oferece uma solução de reorganização off-line, descrita e mostrada aqui.