Proposta de Análise Sobre a Fragmentação em um Banco de
Dados Oracle
Rodrigo Euzebio Ferreira, Luciane de Fátima Silva
Instituto de Informática – Centro Universitário do Triângulo (UNITRI) - Caixa Postal 309 – 38.411-106 – Uberlândia – MG – Brasil
xeonbrasil@r7.com, prof.lucianesilva@gmail.com
Resumo. Este artigo apresenta uma abordagem relacionada ao banco de
dados Oracle, sua estrutura física e lógica, as cláusulas de armazenamento e a questão de área envolvendo o redimensionamento do arquivo de dados. O estudo apresenta questões sobre a gestão interna dos espaços livres e as possíveis causas, impactos e soluções sobre a fragmentação da tablespace e sua relação com o tempo de resposta em consultas realizadas em tabelas.
1. Introdução
Segundo [Burlesson Consulting, 2014], em 1980 os discos custavam $ 200.000 por
megabytes (MB). Hoje, dependendo da cotação do dólar, conseguimos comprar 1 MB
por menos de R$ 0,07. Somado a isso, Guilherme Barros escreveu para o site IG com título “Cresce a Preocupação de Empresas com Gestão de Banco de Dados”, nos Estados
Unidos, o registro de falta de qualidade nos dados causou nas empresas um prejuízo de 620 bilhões de dólares, [Guilherme Barros, 2010].
Neste cenário, com o aumento cada vez mais intenso dos volumes de dados, a dificuldade tem se estabelecido em como conseguir manipular essa quantidade de informações de maneira hábil e eficiente, sem deixar o servidor com todos os recursos voltados exclusivamente para um banco de dados específico, poupando o consumo exagerado de um hard disk (HD) ou storage disk e minimizando os gastos com aquisições de terabytes.
Para pequenas empresas, pode não parecer um gasto muito acentuado, já que poucos gigabytes, comportam uma quantidade enorme de registros. Mas a questão vai além de se comprar ou alugar área ou ainda colocar mais processador e memória, pois é preciso lembrar da importância de se guardar a informação e de sua possível recuperação. Outra preocupação é a necessidade de adquirir dispositivos e softwares para cumprir com o processo de armazenagem e resgate desses dados. Desta maneira, para as empresas de médio e grande porte, os gastos passam a ser maiores e precisarão contabilizar esse considerável investimento em seu orçamento, para garantir assim, a qualidade e confiabilidade de todo o aparato indispensável para manter a vida útil desses arquivos quando sua reutilização for novamente necessária.
Para auxiliar nessa questão, muitos bancos de dados contam com uma série de recursos que os fabricantes fornecem em seus SGBD (Sistema de Gerenciamento de Banco de Dados) com soluções muito agradáveis para que o seu administrador possa gerenciar os dados de forma mais confiável. A Oracle nesse quesito, trabalha com opções de gerenciamentos relacionadas a parte lógica e física do seu database.
Algumas preocupações passam a ser relevantes quanto a questão dos dados ou arquivos, por exemplo:
Gastos com compra ou alocação de discos de armazenamentos (HD ou storage) devido à fragmentação e tamanho dos arquivos de dados;
Utilização dos recursos do banco de dados para realização de backups, essas ferramentas são preparadas para reorganizar os espaços dentro dos arquivos, deixando-os mais compactos, gerando assim maior segurança e um consumo menor de fitas de backup;
Demora no retorno de respostas nas ações realizadas no banco de dados devido ao tipo de fragmentação existente;
Consumo de recursos do servidor enquanto o backup está em andamento;
Longa janelas para manutenção e reorganização dos dados, visando melhorar a performance do banco de dados;
A preocupação com os dados, passa a ser uma questão importante para qualquer corporação, desde o início do projeto até a manutenção e integridade do banco de dados. Um dos motivos que levam muitas pessoas ligadas ao mundo de T.I, criar alguns mitos a respeito de assuntos voltados à fragmentação ou realizarem determinadas ações que não são benéficas na tentativa de resolvê-las. Segundo Craig A. em publicação ao site OraPub com o artigo “All About Oracle Database Fragmentation”, há muitos tipos de fragmentações e nem todas são prejudiciais ou afetarão o desempenho, mas sim, a forma de administração do banco de dados, [OraPub, 2001].
2. Estrutura Física e Lógica
A Oracle, uma das maiores empresas no segmento de SGBD (Sistema de Gerenciamento de Banco de Dados) tem sua própria arquitetura. Buscando vantagens competitivas, a Oracle desenvolveu um banco de dados com escalabilidade em servidores com diversos sistemas operacionais como Unix, Linux e Windows, sendo assim, em sua concepção mais básica o banco de dados Oracle divide-se em duas partes, a física composta pelos datafiles e lógica composta por memória e estruturas lógicas.
De acordo com [Oracle Blog, 2008], “um banco de dados Oracle consiste em uma ou mais unidades de armazenamento lógicas denominadas tablespaces, que armazenam coletivamente todos os dados do banco de dados. Cada tablespace em um banco de dados Oracle consiste em um ou mais arquivos denominados arquivos de dados (datafiles), que são estruturas físicas compatíveis com o sistema operacional no qual o Oracle é executado. Os dados de um banco de dados são armazenados coletivamente nos arquivos de dados que constituem cada tablespace do banco de dados”.
O DBA (Database Administrator) é responsável por cuidar, gerenciar, organizar e melhorar o banco de dados e deve estar ciente do relacionamento entre o armazenamento lógico e físico. Os dados são armazenados logicamente em segments e fisicamente em datafiles. A entidade tablespace é responsável por abstrair as duas partes. Administrar essas estruturas é uma das tarefas do trabalho do DBA, [OCA Oracle
Database 11g, 2010]. A Oracle disponibiliza meios de otimizar a relação dos segments
acessar a informação. A Figura 1, nos mostra um diagrama de entidade-relacionamento do modelo de armazenamento do banco de dados Oracle em visões física e lógica.
Figura 1 - The Oracle Storage Model [Jerry Wang, 2012]
A tablespace, como entidade, tem um relacionamento de um para muitos-para-muitos com os segmentos e arquivos de dados, ou seja, uma tablespace poderá ter muitos segments e ser constituído por vários datafiles. Em resumo, um segments pode se estender por muitos datafiles e este datafile poderá englobar uma parte ou várias partes de muitos segments, [Oracle 11g For Dummies, 2009]. O impacto causado em bancos de dados mais antigos era exatamente por este motivo, pois o tamanho da tabela (segment) ficava limitado ao tamanho do datafile, a tabela não poderia aumentar seu espaço ou este espaço ficaria desperdiçado por não ocupar todo o segmento reservado.
O banco de dados é formado por tablespaces, as mais conhecidas são a
System, Temp, Users, Undo, SysAux que geralmente constituem a formação básica de
um banco de dados Oracle, recém criado. A tablespace é composta de segments que são as tabelas que constituem um conjunto de extents formado por um grupo de blocks. Os
extents ou extensões, são uma série de blocos numerados consecutivamente dentro dos
arquivos de dados. Os blocks ou blocos é onde estará guardado a informação, constituindo assim o arquivo físico conhecido como datafile, compondo a estrutura geral física e lógica de um database Oracle [OCA Oracle Database 11g, 2010], conforme mostra a Figura 2.
Para uma melhor performance a Oracle recomenda que os blocos dos arquivos de dados sejam do tamanho dos blocos do sistema operacional, mas nada impede que sejam de tamanhos diferentes, mas preferencialmente que sejam maiores. Blocos grandes para leitura são mais performáticos, porém para questões relacionadas a instruções DML (insert, delete e update) serão mais lentas, [OCA Oracle Database 11g, 2010]. Uma análise do DBA será útil para verificar qual o melhor cenário de uso do tamanho do bloco e a necessidade exigida pela aplicação que fará uso do banco de dados.
Figura 2 - Oracle Database XE Administration [DevShed, 2010] 3. O Gerenciamento Automático no Banco de Dados
A fragmentação envolve a parte física e lógica de um database Oracle, o gerenciamento de espaço ocorre no espaço atribuído à tablespace configurando o tamanho dos arquivos de dados, depois o espaço dentro da tablespace é atribuído aos segmentos alocando extensões. Já a estes segmentos são atribuídos linhas que são mantidos pelos bitmaps que controlam o espaço livre em cada bloco, [OCA Oracle Database 11g, 2010]. A Oracle conseguiu melhorar ao longo de suas versões a forma de gerenciamento do seu banco de dados. Visando englobar as atualizações mais recentes foi utilizado o Oracle
Database 11g Enterprise Edition Release 11.2.0.4.0 como referência para este artigo.
Sobre as cláusulas de gerenciamento automático no armazenamento vale ressaltar: LMT (Locally Managed Tablespace): Faz uso da cláusula EXTENT
MANAGEMENT LOCAL “configurado por tablespace e se aplica a todos os segmentos no tablespace. Faz uso de bitmaps armazenados em cada arquivo de dados, cada bit no bitmap abrange uma faixa de blocos e quando o espaço é alocado os bits apropriados são alterados de zero para um”, aglutinando os
espaços livres automaticamente, tornando assim mais eficiente o mecanismo, comparado a gestão feita pelo dicionário de dados em versões mais antigas [OCA Oracle Database 11g, 2010].
ASSM (Automatic Segment Space Management): Faz uso da cláusula SEGMENT
SPACE MANAGEMENT AUTO “configurado por tablespace e se aplica à todos os segmentos no tablespace. Cada segmento criado em um tablespace de gerenciamento automático tem um conjunto de bitmaps que descreve até que ponto o bloco está cheio”. Quando uma inserção é realizada, há uma consulta
para ver qual bloco tem espaço para receber a linha. A Oracle entende que por melhores práticas, o gerenciamento manual deve ser evitado, [OCA Oracle Database 11g, 2010], mas o seu uso dispensa a configuração nos itens pctused,
freelists e grupos freelist. A tabela 1, mostra que mesmo não informando as
cláusulas no comando de criação de uma tablespace, por padrão, os parâmetros de armazenamentos já são criados.
Comando criado implicitamente pela Oracle:
Tabela 1 – TOAD for Oracle [Script para Criação da Tablespace]
Existem cláusulas de atributos físicos para a criação de tabelas que tem relação com a fragmentação, como mostra a tabela 2:
PCTFREE: é um parâmetro de armazenamento físico do bloco de dados, usado para marcar a quantidade máxima de insert’s que pode ser realizado, ou seja, é responsável por especificar o espaço livre que será deixado no bloco para que os futuros "updates" possam ser realizados. Se o pctfree for configurado para 10%, as inserções chegarão a 90% do total do bloco, [Orafaq, 2013].
PCTUSED: O Oracle volta a usar o bloco, somente quando este atinge um percentual definido de esvaziamento. Quando isso ocorre, o bloco entra em uma
freelist, ou seja, uma lista de blocos avaliados como disponíveis que o banco de
dados gerencia. O Oracle só irá inserir novas linhas em blocos que já estejam enfileirados na freelist. Se o pctused estiver configurado para 40%, a Oracle não irá adicionar novas linhas ao bloco até que o espaço interno do bloco esteja abaixo de 40% do seu uso. Este parâmetro é ignorado ou autogerenciado em objetos criados em tablespaces com ASSM definido como auto; [Orafaq, 2011].
Comando digitado:
Comando criado implicitamente pela Oracle:
3.1. Tipos de Fragmentação
Sobre os tipos de fragmentação do Banco de Dados Oracle, pode-se relacionar a fragmentação do segmento, do bloco de dados, do bloco da folha de índices, a de linha e a fragmentação de espaço livre da tablespace detalhada neste artigo.
3.1.1. Fragmentação de Espaço Livre da Tablespace
Sobre a Tablespace Freespace Fragmentation (TFF) ou Fragmentação de Espaço Livre da Tablespace é a fragmentação que deixa pedaços disponíveis para o crescimento das tabelas através das extensões ou os espaços criados quando uma tabela é excluída usando-se o comando truncate ou drop. Serão analisados abaixo, as questões para esse tipo de fragmentação:
Como ocorre?
Há duas situações que podem fazer a fragmentação de espaço livre da
tablespace. A primeira, seria na criação de um objeto que se estende, ou seja, um
objeto que necessite de um conjunto de extents de um determinado tamanho, ao qual não é todo utilizado. A outra situação, seria a exclusão de um objeto, onde é deixado um espaço vazio, que forma um tipo de fragmentação honeycomb (favo de mel) com espaços adjacentes ou a do tipo buble (bolha) dispersas pelos segmentos da tablespace, [OraPub, 2001].
Possíveis impactos?
Impactos negativos no tamanho da área ocupada em disco. Tempo de indisponibilidade do banco de dados para realização da reorganização. Exigência de espaço em disco proporcional ao tamanho dos objetos que serão movidos ou exportados da tablespace.
Como resolver?
A solução está na gestão dos parâmetros de armazenamento, uma das opções seria criar extensões menores com tamanho padrão gerenciando-se manualmente as cláusulas de armazenamento. Pode-se usar também o comando truncate ao excluir um objeto para limpar a marca d’água (HWM – High Water Mark) que é o espaço já ocupado por um segmento, ou fazer uso do comando drop com a cláusula cascade constraints purge, para que todas as dependências sejam excluídas e expurgadas da lixeira do Oracle. Usando um comando ou outro a Oracle trabalhará com as novas inserções de forma a preencher esses espaços não utilizados, nem sempre ocupando de maneira sequencial todos os espaços livres. A outra solução parte para o princípio de reconstrução do banco de dados usando o comando “alter table move tablespace” ou export/import, tudo dependerá de um estudo do ambiente, levando em conta o tipo de coluna, área em disco, o tempo de conclusão e o método adotado.
4. Estudo de Caso
A realização desse estudo de caso tem como objetivo abordar a fragmentação no banco de dados Oracle. Este artigo propõe a realização de algumas simulações, a fim de evidenciar situações já abordadas. Para realizações dos testes, o ambiente utilizado foi
um notebook HP com processador Intel(R) Core(TM) i7-3630QM CPU 2.4GHz com 8
GB de memória RAM e um HD Western Digital Scorpio Black WD7500BPKT 750GB 7200 RPM 16MB Cache SATA 3.0Gb/s 2.5" Internal.
4.1. Criando o Cenário para Testes da TFF
Foi criada 100 tabelas para realização de testes no intuito de mostrar que as exclusões de algumas dessas tabelas acarretariam na Tablespace Freespace Fragmentation (TFF). As 100 tabelas são de diferentes quantidades de linhas variando entre 10, 100, 1.000 e 10.000 linhas. Os comprimentos de linha usam “varchar2(1000)”, com inserções que variavam de 10, 100, 1000 caracteres. Foi utilizado como referência a Figura 3, onde temos o script para criação da tablespace, usuário, tabelas e os insert’s na linguagem SQL.
Figura 3 – TOAD for Oracle [Scripts Oracle]
Para a coleta de informação da tablespace foi utilizado o script da Figura 4 e Figura 5. O script traz um resumo completo da situação da tablespace abordando o nível de aglutinação das alterações causadas pelas exclusões na tablespace e informações sobre tamanho, espaço livre e porcentagens relacionadas.
Figura 4 – TOAD for Oracle [Scripts Oracle]
Figura 5 – Scripts Tablespace Space Utilization [TOAD World, 2013] 4.2. Analisando a TFF
Na Figura 6, temos o mapa de extensões com a tabela50 selecionada, mostrando que apesar das tabelas terem sido criadas em sequência, o Oracle as organiza internamente tentando aproveitar de melhor forma possível o tamanho das extensões.
Figura 6 – Mapa de Extensões do Oracle Enteprise Manager 11g, Desfragmentada Como demonstração para a fragmentação do espaço livre da tablespace, foram feitas exclusões das tabelas (tabela01, tabela05, tabela17, tabela25, tabela45, tabela50 tabela65, tabela83, tabela85, tabela100) com o comando drop, conforme
scripts da Figura 3, o resultado da fragmentação na tablespace, causado pelas exclusões,
está apresentado na Figura 7. “O comando Drop remove tanto o objeto quanto sua definição do dicionário de dados. A expressão “cascade constraints” força a eliminação da tabela mesmo havendo relacionamentos associados a ela, [Oracle 9i,
2002]. Já a clausula “purge”, não leva os dados para a lixeira, ou seja, são excluídos imediatamente.
Figura 7 – Mapa de Extensões do Oracle Enteprise Manager 11g, Fragmentada Para a Tabela 3, foi utilizado o scritp da Figura 5 para coletar as informações e também a confeccionar a Tabela 5. Na tabela 3, é informado os resultados das três ações realizadas na tablespace. A tablespace “criada” contém seus valores originais pós inserções e depois de sofrer as ações de exclusão “dropada”. Numericamente não são percebidas alterações de volumetria entre as informações de linha “dropada” e “importada” na Tabela 3, mas a nível de redimensionamento, ou seja, liberação física de espaço em disco e solução da fragmentação da tablespace, as alterações são bastante expressivas. É através do Gráfico 1, que se percebe o ganho real em megabytes da ação de reorganização concluída na tablespace.
Tabela 3 – Ações Realizadas na Tablespace, Coleta de Informações
As informações obtidas para o Gráfico 1, são através de análise feita na visão “dba_free_space”. Essa view mostra até onde as extensões ocuparam o bloco, então depois de subtrair o bloco final do bloco inicial, multiplicamos o resultado pelo tamanho de um único bloco (8k), dividindo por 1024 kb e 1024 mb. Segue a fórmula como exemplo: ((10879-6416)*8192)/1024/1024 = 34,87 (em megabytes).
A Oracle não fornece opções ao DBA na maneira de como as tabelas serão gravadas dentro do datafile, já na questão dos espaços internos, novas formas de melhorar a organização interna dos espaços livres entre os segmentos vem sendo praticada. A fragmentação do tipo “bolha” ou “favo de mel” são gerenciadas de maneira mais eficiente nas versões mais recentes, conforme mostrado na view (sys.dba_free_space_coalesced) na Tabela 4, onde é visto na linha “dropado” que 24 extensões foram aglutinadas e que a ação foi trabalhada em 100% dos espaços blocos.
Tabela 4 – Ações Realizadas na Tablespace, Aglutinação Gerenciada
Não foi necessário esforço do DBA para corrigir a fragmentação, automaticamente o próprio SGBD trata de aglutinar as extensões livres à medida que a fragmentação vai aparecendo, porém o espaço como um todo, passa a ser outra questão.
Seguindo sobre a questão do espaço livre, foi feita uma coleta de estatísticas na tabela 5, relacionado ao ganho de área sobre as exclusões das tabelas. O ganho de área é real em 41.03%, ou seja, mesmo o espaço sendo imediatamente liberado para o datafile ser redimensionado para ficar menor, esta ação não é possível, devido a fragmentação de espaço livre da tablespace.
Tabela 5 – Resumo de Informações da Ação de Exclusão dos Objetos
Apesar da aglutinação corrigida automaticamente pelo Oracle, as tabelas não são movimentadas para o início do datafile a fim de liberar o espaço final do arquivo para o seu re-size. Como exemplo, a Figura 8 mostra que não é possível diminuir fisicamente o arquivo de dados, apesar de seu espaço interno ocupado ser de 50
megabytes.
Para deixar a tablespace desfragmentada, podemos reconstruir os seus objetos. Dentre as opções fornecidas pela Oracle, pode ser usado o expdp/impdp ou o “alter table move tablespace”. Será adotado para este artigo o utilitário do Oracle Data Pump, que contém os comandos de exportação e importação do banco de dados Oracle. 4.2.1. O comando export: expdp
O comando expdp/impdp, é uma solução quanto a reorganização de uma tablespace na reconstrução dos objetos. Na Figura 9, segue comando de exportação da tablespace.
Figura 9 – Export via prompt de comando
A solução da fragmentação vem da exportação de todo conteúdo da tablespace para um arquivo de extensão *.dmp, onde todos os objetos são reconstruidos de forma organizada (sem espaços livres), tornando a tablespace desfragmentada.
Depois da exportação da tablespace, a importação é feita trocando-se o nome de
expdp por impdp, neste exemplo, foi renomeada a tablespace UNITRI_TFF1 para
UNITRI_TFF1_NEW criada com o comando import, seguindo o script da Figura 3. O resultado mostrado na Tabela 5, evidencia que fisicamente seria possível diminuir o tamanho do datafile, economizando área em disco. Agora como as extensões finais do arquivo estão livres é permitindo o redimensionamento, exemplificado na Figura 8. Na Figura 10 é visto que não existe mais a fragmentação de espaço livre da tablespace.
4.2.2. Desfragmentação em Varreduras “full scan”
Grande parte das fragmentações existentes no banco de dados Oracle, tem relação direta com as consultas do tipo “full scan” realizadas nas tabelas. No estudo realizado neste artigo e sobre o assunto abordado por Craig A. em publicação para o site OraPub com o artigo “All About Oracle Database Fragmentation”, a relação da Tablespace Freespace
Fragmentation (TFF) com a leitura de tabelas, não tem relação com o tempo gasto ou
sua localização no datafile. Para testes a tablespace “UNITRI_TFF1” foi mantida sem alterações. Foram reinseridas as tabelas 1, 50 e 100, respeitando a ordem que foram inseridas e excluídas para que sejam realizadas consultas a fim de verificar a veracidade ou mito que se estende sobre o assunto.
Selecionamos a tabela50 no mapeamento de extensões para analisarmos o efeito causado ao realizar uma listagem completa de todo o seu conteúdo. A Oracle, tenta minimizar o efeito da fragmentação preenchendo os espaços livres com as novas inserções causando um outro tipo de fragmentação, à fragmentação de segmento, onde as extensões livres não comportam a quantidade de blocos da tabela, segmentando-o nos espaços livres da tablespace. Dependendo do tamanho do segmento, a Oracle pode pegar uma nova extensão deixando “buracos” para traz e isso volta a causar a fragmentação de espaço livre da tablespace. Foi realizado um “select * from” nas tabela01, tabela50 e tabela100 para ser medido a influência da fragmentação de espaço livre da tablespace na leitura em tabelas. Para o teste duas tablespaces novas foram criadas. Ambas tablespaces foram criadas conforme script usado na confecção da
tablespace UNITRI_TFF1, na Figura 3.
A diferença é que a tablespace X teve 10 tabelas excluídas e dessas 10 tabelas, três são as tabelas 01, 50 e 100 inseridas em meio a fragmentação. Depois todo o restante das tabelas foi excluído na tablespace X deixando somente as 3 tabelas fragmentadas na tablespace. Já para a tabela Y, foram excluídas todas as tabelas da
tablespace e inseridas nos blocos iniciais do datafile, foi realizado o export/import para
eliminar qualquer fragmentação e realizado a varredura completa nas tabelas, coletando o tempo de execução. Para a coleta do tempo, foram feitos 10 vezes o comando “select” para cada tabela, sendo que 5 deles usando o comando “alter system flush
buffer_cache;” antes e os outros 5 fazendo uso do database buffer cache. O database buffer cache tem os dados que vem dos arquivos do disco, como o acesso ao disco é
mais lento, o Oracle faz uma reserva em memória das informações lidas a fim de agilizar a resposta da consulta, [Oracle 11g For Dummies, 2009].
O resultado final obtido é visto na Figura 12. Apesar dos vários processos que podem estar consumindo processador e memória, a porcentagem de diferença entre a leitura das tabelas em uma tablespace fragmentada para uma desfragmentada é irrelevante chegando a milésimos de segundos, ou seja, a fragmentação do espaço livre da tablespace não pode ser responsabilizada pelo aumento no tempo de leitura de uma tabela, prova disso é que “todos os segmentos de armazenamento que contêm os dados
são constituídos por blocos. Quanto você solicita dados do disco, o Oracle lê um bloco”, [Oracle 11g For Dummies, 2009]. Então, a fragmentação de espaço livre da tablespace não tem influência direta no tempo total de leitura da tabela, porque o Oracle
não lê a extensão ou o segmento fragmentado, mas sim o bloco. Obviamente quanto mais blocos ele tiver que percorrer para achar o bloco especifico da consulta solicitada,
maior será o tempo gasto para encontra-lo, mas isso não significa que os “buracos” no meio da tablespace irão influenciar nesse tempo de resposta. Existe sim, outros tipos de fragmentação como a de bloco ou índices que poderiam causar aumento do tempo de leitura da tabela ou pela quantidade de blocos lidos ou pela não relação com o dado.
Figura 12 – Resultado do “Select Full Scan” 4.3. Análise da Solução
Nesta proposta de análise sobre a fragmentação em um banco de dados Oracle ficou evidenciado que a fragmentação de espaço livre da tablespace tem influência direta no consumo de área, onde a desfragmentação gerou um ganho contíguo maior que três vezes a área livre atual. Foi visto que o Oracle tenta organizar os espaços livres internos a fim de minimizar o impacto causado pela fragmentação aglutinando em 100% os espaços dos blocos automaticamente.
Referente à questão do redimensionamento do arquivo, o motivo estava ligado a fragmentação e a solução partiria de uma reorganização do banco de dados usando a ferramenta da Oracle de exportação e importação.
Na fragmentação de espaço livre da tablespace como causa do aumento do tempo de uma consulta do tipo “full scan” para as tabelas, foi visto que diferença na leitura de uma tabela fragmentada para uma desfragmentada não chegou a metade de meio segundo.
5. Conclusão
A fragmentação é algo inerente ao banco de dados e muitas empresas precisam em algum momento fazer o “reorg” de seu database. É um assunto que gera muita discussão em fóruns na internet fazendo com que muitos sites sejam criados explicando as formas de elimina-la ou diminuí-la, causando até certa confusão sobre a fragmentação ao tentar entender qual tipo está sendo abordado.
Esse artigo mostrou a estrutura física e lógica do banco de dados com seus relacionamentos, os parâmetros de gerenciamentos automáticos, o não redimensionamento físico de um arquivo de dados, o utilitário Oracle Data Pump utilizado na reorganização do banco de dados, o tempo de leitura de uma tabela e sua relação com a fragmentação.
Como sugestão para trabalhos futuros, fica a utilização do comando “alter table
mais detalhada de outros tipos de fragmentação do banco de dados Oracle, como por exemplo, a de índices, blocos, linhas e segmentos e suas respectivas correções e soluções para este assunto.
Referências
Burleson Consulting. Reclaiming Oracle Disk Space, 2014. Disponível em: <http:// http://www.dba-oracle.com/t_reclaiming_disk_space.htm >. Acessado em: 21 Mar 2015. Database SQL Reference. Physical Attributes Clause. Disponível em:
<http://docs.oracle.com/cd/B19306_01/server.102/b14200/clauses007.htm>. Acessado em: 05 Abr 2015.
Devshed. Oracle Database XE Administration, 2010. Disponível em: <http://www.devshed.com/c/a/oracle/oracle-database-xe-administration>. Acessado em: 05 Abr 2015.
Fernandes, L.; Oracle 9i para Desenvolvedores Curso Completo. ed. Rio de Janeiro: Axcel Boooks do Brasil Editora, 2002. p.215.
Guilherme Barros. Cresce a Preocupação de Empresas com Gestão de Banco de Dados. Disponível em: <http://guilhermebarros.ig.com.br/2010/03/21/cresce-a-preocupacao-de-empresas-com-gestao-de-banco-de-dados>. Acessado em: 21 Mar 2015.
Jerry Wang. Introdução ao conceito de Tablespaces no Oracle, 2008. Disponível em: <http://www.jerrywang.me/the-oracle-storage-model/>. Acessado em: 04 Abr 2015. Oracle Blog. Introdução ao conceito de Tablespaces no Oracle, 2008. Disponível em:
<http://eduardolegatti.blogspot.com.br/2008/03/introduo-ao-conceito-de-tablespaces.html>. Acessado em: 22 Mar 2015.
Orafaq. PCTFREE, 2013. Disponível em: <http://www.orafaq.com/wiki/PCTFREE>. Acessado em: 09 Mai 2015.
Orafaq. PCTUSED, 2011. Disponível em: < http://www.orafaq.com/wiki/PCTUSED>. Acessado em: 02 Mai 2015.
OraPub. All About Oracle Database Fragmentation. Disponível em: <http://resources.orapub.com/All_About_Oracle_Database_Fragmentation_p/dbfrag. htm>. Acessado em: 25 Abr 2015.
TOAD World. Script Tablespace Space Utilization. Disponível em: <
http://www.toadworld.com/platforms/oracle/w/wiki/4887.script-to-report-tablespacedatafile-space-utilization.aspx>. Acessado em: 06 Jul 2015.
Watson, J.; OCA Oracle Database 11g: Administração I. ed. São Paulo: Bookman, 2010. p.89-275.
Zeis, C.; Ruel, C.; Wessler, M.; Oracle 11g FOR DUMMIES. Indiana: Wiley Publishing, Inc, 2009. p.18-38.
