Artigos Banco de Dados Particionamento no Oracle
Demais posts desta série:
Particionamento no Oracle – Parte 2
Artigo no estilo: Curso

De que se trata o artigo?

Este artigo apresenta 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 menos em ambientes menores, mas que se beneficiam da estrutura do particionamento.

Em que situação o tema é útil?

O particionamento de dados se mostra uma funcionalidade muito atraente e bem aceita em situações em que se precisem armazenar grandes volumes de dados em uma mesma tabela ou se deseje gerenciar o ciclo de vida de determinadas informações. Assim, o tema discutido neste artigo é útil em situações onde é necessário dividir grandes volumes de dados ou mesmo prover um gerenciamento descentralizado das informações, separando as informações armazenadas no banco de dados de uma maneira mais eficiente e performática.

Resumo DevMan

O barateamento de dispositivos de armazenamento aliados a questões legais (no sentido de regulamentações) e também a crescente necessidade de armazenamento de arquivos binários, como planilhas, documentos de texto, fotos, vídeos, etc., tem sobrecarregado a cada dia os bandos de dados das corporações. Esta demanda força as empresas que desenvolvem Sistemas de Gerenciamento de Bancos de Dados a implementarem soluções que atendam as necessidades de armazenamento, porém oferecendo ótimo desempenho na consulta a esses dados.

Pensando justamente nesta necessidade a Oracle oferece, já há bastante tempo, uma solução realmente muito boa, que atende a exatamente todas essas necessidades. Trata-se do particionamento de objetos.

Através desta funcionalidade o DBA poderá prover à aplicação uma solução de baixíssimo custo (já é uma funcionalidade presente na versão Enterprise Edition do banco de dados Oracle sem custo adicional), sem a necessidade de alterações de código e que oferece um desempenho realmente impressionante.

A versatilidade oferecida pela solução realmente impressiona, permitindo que partições sejam criadas com base em um intervalo de dados (que podem ser valores numéricos ou mesmo datas) ou uma lista de valores (estados da federação, por exemplo) ou ainda através de um algoritmo de particionamento e, como se não bastasse, até mesmo baseado na combinação destas estratégias.

O melhor de tudo é que toda essa implementação é totalmente transparente para a camada de aplicação e os ganhos de desempenho são realmente consideráveis.

É importante destacar que esta funcionalidade não está limitada apenas a situações onde existam tabelas gigantescas (como ambientes de Data Warehouse, por exemplo), mas se adaptam perfeitamente a situações em que seja necessário gerenciar o ciclo de vida das informações ou até mesmo “organizar” melhor a forma em que os dados estejam armazenados nas tabelas.

Sem a menor sombra de dúvidas o particionamento (tanto de tabelas quanto de índices) é uma solução muito inteligente para auxiliar no ganho de performance geral das aplicações que acessam o banco de dados.

O particionamento permite decompor tabelas muito grandes e índices em partes menores e mais gerenciáveis que chamamos simplesmente de partições. Cada partição é um objeto independente, com seu próprio nome e, opcionalmente, as suas características próprias de armazenamento.

Para uma analogia que ilustra o particionamento, suponha que um gerente de RH tenha uma grande caixa que contém pastas de funcionários. Cada pasta lista a data de contratação do empregado. As consultas são feitas frequentemente para os funcionários contratados em um determinado mês. Uma maneira para satisfazer este tipo de consulta é o de criar um índice na coluna “data de contratação” do funcionário que especifica os locais das pastas espalhadas por toda a caixa. Em contrapartida, uma estratégia de particionamento usa muitas caixas menores, com cada caixa contendo pastas para os empregados admitidos em um determinado mês.

Utilizar caixas menores nos traz várias vantagens. Quando precisamos das pastas dos empregados contratados em junho, o gerente de RH pode pegar apenas a caixa de junho. Além disso, se qualquer uma das caixas menores estiver temporariamente danificada, as outras caixas menores continuam disponíveis. Mudanças no escritório também se tornam mais fáceis, porque em vez de mover uma única caixa enorme e pesada, o gerente pode mover várias caixas pequenas.

Do ponto de vista de uma aplicação, haverá apenas um único objeto no esquema para ser consultado. Não há necessidade alguma de mudança no código da aplicação ou nas consultas DML (ver Nota do DevMan 1) para acessar as tabelas particionadas.

Nota do DevMan 1: DML - Data Manipulation Language

Uma linguagem de manipulação de dados (DML – Data Manipulation Language) é uma família de elementos de sintaxe semelhantes a uma linguagem de programação de computador utilizado para inserir, excluir e atualizar dados em um banco de dados. A linguagem de manipulação de dados mais conhecida é a SQL - Structured Query Language, que é usada para recuperar e manipular dados em um banco de dados relacional.

DML são os comandos SQL de alteração de dados, que modificam os dados armazenados mas não alteram os esquemas ou objetos do banco de dados. Manipulação de objetos persistentes do banco de dados como, por exemplo, tabelas ou procedimentos armazenados (stored procedures), através de comandos SQL, é considerada como sendo parte de linguagem de definição de dados ou DDL (Data Definition Language). Na SQL estas duas categorias são similares em sua sintaxe, tipos de dados, expressões, etc, mas distintas em sua função.

Linguagens de manipulação de dados têm sua funcionalidade organizada pela palavra inicial do comando, que é quase sempre um verbo. No caso de SQL, estes verbos são:

SELECT ... FROM ... WHERE ...
   INSERT INTO ... VALUES ...
   UPDATE ... SET ... WHERE ...
   DELETE FROM ... WHERE ...

Uma consulta SELECT é classificada como "SQL-data" (conforme o padrão ANSI SQL 92, em sua seção 4.22.2) e por isso é considerada como padrão de saída de DML. A instrução SELECT ... INTO é considerada DML porque manipula (modifica) os dados. Na prática, no entanto, esta distinção não é feita e a instrução SELECT é amplamente considerada como parte da DML.

A maioria dos Sistemas de Gerenciamento de Banco de Dados Relacionais implementa uma extensão da linguagem SQL através de programação imperativa, ou seja, linguagens procedurais. Exemplos desta implementação são o PLSQL do Oracle, o SQL PL do DB2 ou ainda o Transact-SQL do SQL Server.

DMLs tendem a ter várias capacidades, conforme o fornecedor de banco de dados. Existe um grande esforço para estabelecer normas de padronização através do padrão SQL ANSI, mas os fornecedores de SGBDRs ainda oferecem suas próprias extensões para o padrão.

As DMLs são divididas em dois tipos: programação procedural e programação declarativa. Cada instrução SQL DML é um comando declarativo. As instruções SQL individuais são declarativas, em oposição ao imperativo (procedural), pelo fato de que descrevem a finalidade do programa em vez de descrever o procedimento para realizar determinada tarefa.

O particionamento se mostra muito útil para os mais variados tipos de aplicações, em especial as que administram grandes volumes de dados.

Podemos listar como principais benefícios:

· Aumento da disponibilidade: A indisponibilidade de uma partição não implica a indisponibilidade de todo o objeto. O otimizador de consulta (query optimizer – ver Nota do DevMan 2) automaticamente remove do plano de execução (execution plan – ver Nota do DevMan 3) as partições sem referência e, com isso, as consultas não são afetadas quando as partições não estão disponíveis;

Nota do DevMan 2: Otimizador de Consultas – Query Optimizer

O otimizador de consulta é o componente de um Sistema de Gerenciamento de Banco de Dados (SGBD) que tenta determinar a forma mais eficiente de executar uma consulta. O otimizador considera os planos de consulta possíveis para uma determinada consulta e tenta determinar qual desses planos será o mais eficiente.

Otimizadores de consulta baseados em custos (cost based optimizer) atribuem um "custo" estimado para cada plano de consulta possível, e escolhe o plano com o menor custo. Os custos são utilizados para estimar o custo de tempo de execução para retornar uma consulta em termos do número de operações de I/O (Input/Output – Entrada/Saída) necessários, os requisitos de CPU e de outros factores determinados a partir do dicionário de dados. O conjunto de planos de consulta examinados é formado através da análise dos possíveis caminhos de acesso (Access Path) (por exemplo, utilização de índice ou varredura sequencial – Full Table Scan) e ainda algoritmos de junção (por exemplo sort-merge join, hash join, loop aninhado). O tempo de busca pode se tornar muito grande, dependendo da complexidade da consulta SQL.

...

Quer ler esse conteúdo completo? Tenha acesso completo