segunda-feira, 28 de setembro de 2009

REORGANIZANDO MEU BANCO DE DADOS



Olá, como vão todos?
Desculpem a demora para postar, é que estava pensando em assuntos interessantes e que me agradem é óbvio, e cheguei a conclusão que deveria dedicar um post a uma tarefa que ainda perdura em alguns ambientes, seja por conta de uma má administração, ou até mesmo por conta de um leve desleixo.


Esse post será sobre REORGANIZAÇÃO DE BANCO DE DADOS, uma arrumada na casa pra ser mais preciso.


Naturalmente tendemos a deixar de lado questões importantes em nossas bases de dados para podermos dar prioridade a algumas outras implementações, ou até mesmo para atender aos caprichos de alguns ( Aqui pra nós vocês sabem bem do que estou falando.) e esquecemos de arrumar a casa, fazer o popular “REORG”, uma atividade que pode ter um nível de complexidade muito alto se o seu ambiente for muito volumoso e possuir uma grande quantidade de objetos, visto que você terá de manipula-los para poder reorganizar seu banco de dados.


Vejamos então como poderíamos realizar essa tarefa. Espero que apreciem, obrigado a todos que visitam o BLOG.


REORGANIZANDO MEU BANCO DE DADOS


Bem, a primeira pergunta e a mais interessante neste assunto é QUANDO E PORQUE DEVO REORGANIZAR?


Questionamentos sutis, mais que nos levam a um raciocínio lógico muito preciso, em uma analogia simples basta que lembremos da necessidade de se “arrumar a casa”, não apenas para que fique com aspecto limpo, mas para podermos também nos sentirmos mais seguros quanto ao visual e quanto a organização dos objetos que compõem nossa casa, porque se você deixar tudo de maneira desordenada com certeza tropeçara em algo esquecido por você no meio do caminho, e conseqüentemente lhe trará algumas dores de cabeça.


Poderiam me perguntar também , MAIS É SÓ PARA ISSO QUE SERVER O REORG?
Não, também podemos utiliza-lo para alterar a estruturação do nosso banco de Dados, pois há detalhes que só podem ser realizados reorganizando, e quando fazemos isso abrem-se algumas possibilidades, se caso precisarmos alterar a Blocagem do nosso Banco de Dados não há como fazer isso Online, portanto uma Reorganização do Tipo Infra-estrutura concordam? Se fosse uma mera movimentação de dados poderíamos fazer com a Base de Dados parcialmente Disponível. PARCIALMENTE DISPONIVEL? COMO ASSIM?


Não podemos reorganizar os dados de um Baco de Dados por menor que ele seja, ou por mais tranqüilo que ele seja , com sessões que concorram em acessos a objetos no meio do nosso processo, correto? Então para isso podemos utilizarmos de algumas artimanhas que o Oracle nos oferece, como por exemplo colocar o Banco de Dados em modo Restrito, vejam como fazer :


HABILITANDO RESTIÇÃO
Alter system enable restricted session;


Nota: Com este comando apenas os usuários que tiverem GRANT ( permissão) de RESTRICT SESSION ou de DBA poderão logar na sua base de dados, impossibilitando assim a concorrência a objetos enquanto você realiza sua reorganização.


DESABILITANDO RESTRIÇÃO


Alter system disable restricted session;


Bom , feito isso podemos dar sequencia as nossas atividades de Reorganização, que afetaram tanto tabelas quanto índices, visto que esses são nossos alvos para minimizar os problemas causados pela “bagunça” em que nosso banco de dados possa estar sofrendo.


QUAIS AS VANTAGENS DE SE REORGANIZAR UM BANCO DE DADOS?


Eu vejo inúmeras delas, mais posso citar algumas que considero mais importantes :


- Diminuição na Fragmentação dos Índices e tabelas
- Ganho em espaço em Disco ( em caso de Tabelas superdimensionadas )
- Ganho de performance em query’s e conseqüentemente no Aplicativo Front-End.
- Organização e padronização de Estrutura de Dados


Enfim podemos obter inúmeros ganhos , desde coisas que ninguém percebe pois só DBAS tem acesso até coisas perceptíveis no dia a dia de sua empresa.


Vejamos então como proceder para fazer uma Reorganização em tabelas. Até as versões 9i o mais comum era usarmos o MOVE TABLE e o COALESCE, mas com o avanço no gerenciamento de Tablespace e com a chegada do ASSM as coisas tomaram outra forma, pois para tablespace gerenciadas LOCALMENTE e com AUTOALLOCATE vocês poderam perceber facilmente que o COALESCE não surte lá grandes efeitos em aglutinar os blocos free encontrados nos datafiles.


Já o comando MOVE TABLE é muito eficiente em bancos 8i e 9i, o único detalhe pertinente a esse comando é que se você pretende reorganizar uma base de grande porte, deve ter uma boa janela para tal tarefa, e deve também ter uma boa quantidade de DISCO, visto que se você precisar criar uma nova TABLESPACE essa terá que concorrer em espaço com sua atual TABLESPACE dentro de seu STORAGE e na hora do MOVE TABLE ambas devem estar disponíveis pois ambas compõem ORIGEM e DESTINO dos dados. Vocês podem optar também por usar a ferramenta IMPORT / EXPORT da Oracle, cada um deve fazer como se sentir melhor para atingir o objetivo final. Uma boa prática também para quem usa o MOVE TABLE é paralelizar o processo ( isso serve apenas para aqueles servidores com mais de uma CPU) vejam o comando para criar THREAD’s do seu processo de MOVE :


HABILITANDO O PARALLEL


Alter session force parallel dml parallel 6;


Nota : com essa syntax seu processo terá 6 pequenos thread’s no banco de dados para realizar o seu MOVE TABLE, o que nos assegurará muito mais performance.


No 10g ganhamos uma arma eficaz e simplesmente fantástica para nossas tarefas de REORGANIZAÇÃO, essa maravilha se chama SHRINK SPACE, para quem trabalhou com segmentos de ROLLBACK “RBS”, a palavra SHRINK não é novidade, este comando vai compactar todo o espaço fragmentado em sua tabela, para usa-lo devemos antes de mais nada realizar a ativação da MOVIMENTAÇÃO DE LINHAS, como fazer ? veja:


HABILITANDO MOVIMENTAÇÃO DE LINHAS


Alter table enable rown movement;


Alter table xxx Shrink Space cascade;


Nota: a palavra Cascade no commando fará com que todas as dependências do objeto , como índices por exemplo sejam também submetidas a compactação.


Uma observação Importante , quando estamos realizando um MOVE TABLE há uma necessidade maior de área de TEMP, pois é um porcesso que gera uma certa quantidade de SORT.


Agora podemos falar um pouquinho de Índices acredito eu, esses objetos que podem ser nossa salvação ou nossa derrota, pois um índice ineficaz só aumenta ainda mais nosso problema com query’s pesadas , pois ele precisa ser analisado e receber os novos dados indexados por ele, mesmo ele sendo denecessário, há diversas ferramentas que podem ser usadas para determinados casos como o SPATIAL da Oracle, eu gosto muito de habilitar o audit em cima de índices para ver se realmente estão sendo utilizados ou não, pois só com essa margem de estatísticas é possível propor uma remoção dos índices que possivelmente possam estar atrapalhando em algum ponto.


Para índices é muito comuns utilizarmos o REBUILD INDEX ( vale apenas para os índices B-TREE se o seu índice é BITMAP é necessário um DROP e CREATE do mesmo), com um REBUILD as “folhas” ( leaf’s) que compõem seus índices serão reagrupadas em níveis menores ( BLEVEL’s), fazendo com que sempre que você necessitar de um dado ele esteja disponível nos primeiros níveis de pesquisa em sua estrutura em árvore.


Os segmentos de índice também sofrem com a fragmentação das tabelas, portanto é sempre de bom tom quando for realizar um REORG em sua base de dados , também aproveitar para recriar os seus índices através do comando REBUILD, as recriações podem ser feitas ONLINE ou não, isso é uma questão de disponiblidade , pois em Rebuild’s Online seu objeto ainda fica disponível para transações diferentes a sua, já o Rebuild Offline fará um LOCK EXCLUSIVO no objeto, impossibilitando que demais sessões utilizem, podendo causar uma boa dor de cabeça se isso for feito durante o expediente, portanto tenha sempre em mente que tarefas de manutenção como o REORG devem ser feitos com janelas pré agendadas e aprovadas pos sua gerencia.


RECONSTRUINDO INDICES


Alter index i_xxx rebuild [online] tablespace xxx_idx;


Nota: Procure sempre obedecer as padronizações da Oracle como o OFA por exemplo, separe seus segmentos por tablespace para evitar as possíveis concorrências conforme sua base de dados irá crescendo.


Vale também lembrar que devemos sempre analisar com cautela e reunir o máximo de informações para que possamos fazer nosso REORG com sucesso e sem maiores problemas.


Bem, por enquanto é só , trarei mais Post sobre esse assunto de reorganização de Base da dados, de acordo com as necessidades que cada ambiente pede.


Obrigado aos que apreciam meu BLOG.


Abraço á todos.