Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login

Desfragmentação de banco de dados Oracle

Este artigo aborda o uso do Shrink, um poderoso recurso disponível no Oracle que tem como objetivo liberar espaços dentro da tablespace que não estão sendo utilizados pelas tabelas ou índices.

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (5)  (0)

Fique por dentro
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

" [...]

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

Carregando
 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Ajude-nos a evoluir: você gostou do post?  (5)  (0)
Confirmar voto
Compartilhe:
Ficou com alguma dúvida?