Artigos Banco de Dados Desfragmentação de banco de dados Oracle

Por que eu devo ler este artigo:Em constantes operações DML realizadas em tabelas ou índices (Insert, Update e Delete), o tamanho das tablespaces tende a um crescimento descontrolado. Esse crescimento nem sempre é causado pelo aumento da volumetria de dados, mas sim pela fragmentação de espaços em branco, que acabam se acumulando com decorrer do tempo. Este artigo aborda o uso do Shrink, um poderoso recurso disponível no Oracle a partir da versão 10, que tem como objetivo liberar espaços dentro da tablespace que não estão sendo utilizados pelas tabelas ou índices. Além de desfragmentar as tabelas e reduzir os espaços utilizados sem perda de dados, o desempenho nas consultas (select) que realizam FULL SCAN será otimizado, bem como as operações DML.

O crescimento descontrolado do banco de dados é uma grande dor de cabeça que o DBA enfrenta em seu dia a dia. Se tratando ainda de uma base de produção, onde existe uma grande volumetria de dados, a fragmentação é um problema muito comum. Esse é um dos itens que vem à cabeça quando o DBA trabalha para melhorar a organização das tablespaces (subdivisão lógica de um banco para organizar estruturas lógicas que são relacionadas).

As constantes operações DML (Data Manipulation Language – operações de leitura e escrita de dados) sofridas nas tabelas e índices de um banco de dados proporcionam um crescimento do espaço utilizado por eles. Porém, muitas vezes esse crescimento não se apresenta por conta da alta volumetria de dados, mas sim pelo surgimento de fragmentação dos espaços que não são utilizados pelos dados das tabelas. Com isso, a área das populares “marcas d’água” ou “high water mark” vai aumentando.

A marca d’água é o último bloco onde o objeto termina dentro da tablespace e é uma área que tende a ter a mesma quantidade de informações do objeto. Quando uma tabela, um índice ou um range de dados sofre um delete, os segmentos de dados ficam cheios de blocos vazios que são reutilizados apenas depois de um insert ou update, ou às vezes nem são reutilizados. Se a tabela/índice sofre muitas dessas operações DML, os números desses blocos vazios e inutilizados se acumulam com o decorrer do tempo, aumentando a área de dados fragmentados.

Isso pode acarretar no desempenho negativo em queries de selects (Full Table Scan), pois a consulta deverá percorrer uma área maior de blocos para retornar o valor desejado. Operações de alter table também são prejudicadas, pois a movimentação entre os blocos tende a ficar mais lenta. Além disso, inserts e updates ficam mais lentos na execução, pois buscam preencher os blocos vazios. Por fim, o índice pode sofrer um desbalanceamento, o que prejudica seu uso e faz com que o espaço físico utilizado por ele seja perdido.

Neste contexto, o Shrink é utilizado para fazer a reorganização desses objetos, liberando o espaço inutilizado, diminuindo o tamanho de blocos vazios e desfragmentando os dados. Entre suas vantagens, podemos destacar:

· Pode ser executado com os serviços de banco de dados em estado open e com usuários conectados. Assim, não há a necessidade de fazer shutdown ou desconexão de usuários para executar essa tarefa;

· Em outras técnicas de desfragmentação de dados, como o MOVE TABLESPACE ou DBMS_REDEFINITION, existe a necessidade de espaço físico extra em disco para executar as operações. Porém, isso não se aplica ao Shrink.

Apesar de muito útil, o Shrink possui algumas limitações:

· Não funciona em Cluster tables, tabelas que contenham colunas do tipo long, tabelas e índices baseados em funções e com características IOT;

· A tabela deverá estar com o recurso de Row movement habilitado. Essa propriedade permite a reorganização de linhas da tabela. Por default, a mesma vem desabilitada quando efetuado o Create Table;

· Não funciona em tablespaces configuradas para gerenciamento manual de espaço;

· Quando executado, o Shrink faz lock no objeto referido, sendo aplicado para tabelas ou índices. Ou seja, a tabela associada fica bloqueada para sofrer qualquer alteração DDL ou DML.

Desfragmentando tabelas na prática

Para demonstrar o uso do Shrink, iremos criar uma tabela de teste para melhor exemplificar a visão da compactação, como pode ser visto na Listagem 1.

Listagem 1. Create table da tabela TESTESHRINK


  1 SQL> CREATE TABLE TESTESHRINK
  2  (
  3     ID      NUMBER NOT NULL,
  4     VALOR   NUMBER (10, 2) NOT NULL ENABLE,
  5     data    DATE NOT NULL ENABLE,
  6     NOME    VARCHAR2 (50) NOT NULL ENABLE,
  7     CONSTRAINT TESTE_SH PRIMARY KEY (id)
  8  );
  9 
  10 Table created

Os campos são nomes genéricos e foram criados apenas para uma melhor simulação de uma tabela de pr ...

Quer ler esse conteúdo completo? Tenha acesso completo