Tags:

Oracle

Oracle Segment Shrink

Uma melhoria solicitada há muito tempo e que foi introduzida no Oracle 10g é a possibilidade de “encolhermos” tabelas e índices (em inglês, shrink). Essa feature irá ajudar os DBAs a gerenciar melhor o espaço na base de dados.

Mas como exatamente ela funciona ?

Ao realizarmos a operação de shrink, comprimimos os blocos da tabela ou índice e opcionalmente movemos a HWM (High Water Mark) do segmento para baixo, deixando assim o espaço não utilizado disponível para outros segmentos na tablespace. Para ser um candidato a esse tipo de operação, o segmento deve estar em uma tablespace configurada com o ASSM (Automatic Segment Space Management).

Executando o comando ALTER TABLE  …  SHRINK SPACE, as linhas da tabela em questão sofrem o processo de compressão e a HWM é reduzida. Se for especificada a opção SHRINK SPACE COMPACT, o segmento sofre o encolhimento, mas a HWM é mantida na posição. A opção SPACE CASCADE faz a redução do segmento e dos objetos dependentes (índices da tabela, por exemplo).

Os segmentos que podem sofrer o shrink são os seguintes:

  • tabelas normais
  • índices (b-tree e bitmap)
  • segmentos que contenham LOBs
  • materialized views

O shrink é restrito para:

  • objetos clusterizados
  • tabelas com colunas LONG
  • segmentos LOB compartilhados
  • segmentos temporários e de UNDO

Durante o shrink de uma tabela, o ROWID pode mudar para uma das linhas quando ela é movida entre os blocos. Assim sendo, segmentos que são baseados em ROWIDs (como por exemplo ROWID materialized views) não podem ser encolhidos.

Os índices são alvo de atenção especial durante o processo de shrink. Eles não ficarão em um estado UNUSABLE depois que o processo terminar. O encolhimento é atualmente implementado através de pares INSERT/DELETE. O processo é todo online, possibilitando assim a disponibilidade do objeto para  uso mesmo durante essa operação. Como durante o processo os dados serão movidos como parte da compactação, locks acontecerão nas linhas individuais ou em blocos que contenham os dados. Quando a HWM é ajustada, o segmento sofre lock em em modo exclusivo até que o ajuste termine.

Essa feature sem dúvida se mostrará muito útil também em ocasiões pontuais, como por exemplo após a deleção de dados históricos de determinadas tabelas, possibilitando o encolhimento desses objetos sem a necessidade de paradas para reorganizações mais complexas.

Há também um benefício em termos de performance, pois algum processo que precise necessariamente realizar FULL TABLE SCAN em determinada tabela após o shrink terá menos blocos a percorrer – o terá menos blocos a percorrer – o Oracle considera a HWM como a referência para os blocos a serem lidos durante um FULL TABLE SCAN.

Por MÁRCIO NUNES JARDIM

Postado em: 26 de outubro de 2010

Confira outros artigos do nosso blog

REST não é JSON

21 de agosto de 2017

Bruno Sofiato

[Webinar] Profile de aplicações Java com Oracle Mission Control e Flight Recorder

24 de julho de 2017

Danival Calegari

Criando Mocks de serviços REST com SoapUI

27 de junho de 2017

Monise Costa

JavaScript 6: diferença entre var, let e const

09 de maio de 2017

Otávio Felipe do Prado

Deixe seu comentário