Particionamento no Oracle – Parte 5 - Revista SQL Magazine 109

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
 (0)  (0)

O artigo trata especificamente das funcionalidades de utilização de particionamento em Index-Organized Tables e tabelas aninhadas e também algumas restrições ao utilizar-se tablespaces com múltiplos tamanhos de blocos.


Particionamento no Oracle – Parte 5: Trabalhando com index organized tables
O artigo trata de técnicas de particionamento de objetos no banco de dados para garantir melhor performance e gerenciamento de informações em ambientes que apresentam tabelas gigantescas ou mesmos em ambientes menores, mas que se beneficiam da estrutura do particionamento, ressaltando casos específicos em que se trabalhar com index organized tables e tabelas aninhadas são essenciais.

Especificamente serão vistas as funcionalidades de utilização de particionamento em Index-Organized Tables e tabelas aninhadas e também algumas restrições ao utilizar-se tablespaces com múltiplos tamanhos de blocos.


Em que situação o tema é útil

O tema discutido neste artigo é útil em situações em que as funcionalidade básicas de particionamento não oferecem toda a robustez necessária para a aplicação, algumas das funcionalidades adicionais aqui apresentadas contribuirão para alcançar o objetivo proposto.

Há situações em que necessitamos utilizar Index-Organized Tables (IOT) para obtermos um maior ganho de performance geral do banco de dados, porém o volume de dados se torna um fator limitante e a necessidade de particionamento desta IOT se faz necessária.

Outra situação em que o tema se faz útil é quando se necessita utilizar tabelas aninhadas e, mais uma vez, o volume de dados é fator limitante. Efetuar o particionamento de tabelas aninhadas se mostra crucial.

Um objeto bastante interessante no banco de dados Oracle é a famosa Index-Organized Table, ou simplesmente IOT. Este objeto é realmente bastante interessante quando existe o comportamento da impossibilidade de alteração dos valores da chave primária desta tabela. Quando nos deparamos com esta situação, a utilização das IOTs se mostra muito interessante, pois não haverá a necessidade de criação de um índice para a chave primária e todas as linhas inseridas já estarão automaticamente ordenadas, porém o volume de dados pode ser um fator que afete diretamente a performance geral das consultas efetuadas nesta tabela. Como proceder neste caso? É simples, pois a Oracle também disponibiliza a funcionalidade de particionamento para este tipo de objeto e, desta forma, serão aliadas as tecnologias de IOT e particionamento, contribuindo muito para o ganho de performance.

Chegamos também a outro objeto que contribui bastante para o projeto da aplicação. Há situações em que é necessário (e algo muito comum nos dias de hoje) armazenar tabelas dentro de tabelas, onde uma (ou mais) colunas da tabela são de um tipo que armazenam uma outra tabela. Este é o caso de tabelas aninhadas e essas tabelas aninhadas podem ser construídas tanto em tabelas convencionais quanto em XMLType. Ótimo, muito bom. Mais uma funcionalidade interessante, mas que também pode ser comprometida em função do volume de dados (o crescimento do volume de dados nas empresas se dá de forma exponencial). Tudo bem, pois a Oracle também disponibiliza a funcionalidade de particionamento neste tipo de objeto, o que pode solucionar sem grandes dificuldades eventuais problemas de desempenho.

OK, mas nem tudo é possível. Apesar deste grande leque de funcionalidades, efetuar o particionamento de objetos quando temos um cenário onde diferentes tablespaces possuem diferentes tamanhos de blocos pode ser um problema.

Há limitações quanto a utilização de particionamento em tablespaces com múltiplos tamanhos de blocos, mas basta estar ciente destas limitações para projetar um ambiente que não “sofra” com o problema. E vamos ser bem sinceros: são poucos os sistemas em que é necessário trabalhar com tamanhos de blocos diferentes. Mas é sempre bom considerar que é uma hipótese válida e que o DBA poderá se deparar com isso.

"

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

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?