ODA - Oracle Database Appliance

Muito bom dia a todos!

Hoje vou fazer um breve comentário sobre a “tecnologia” da Oracle conhecida como ODA.

Para dar início, gostaria de informar que não trabalho com ODA, mas tenho estudado bastante sobre o sistema e o acho bastante interessante.

Bom...

ODA é a abreviação de Oracle Database Appliance, que segundo definição Oracle é um sistema projetado que consiste em hardware e software que economiza tempo e custo para os clientes, simplificando a implantação, manutenção e o suporte de soluções de banco de dados de alta disponibilidade.

Com essa tecnologia, a Oracle proporciona um sistema totalmente integrado de software, servidores, storage, e conectado à rede em um único equipamento que oferece serviços de alta disponibilidade em banco de dados, aplicável tanto para serviços operacionais (OLTP) quanto para aplicações gerenciais em data warehouse (OLAP). A figura 1 exibe a parte da frente de uma ODA.

Figura 1 - Frente da ODA. (Fonte: Oracle Corporation)

No vídeo abaixo é possível ter uma visão melhor do que é a ODA.

Falando um pouco dos recursos de uma ODA:

✔ Equipamento de banco de dados completamente integrado em um equipamento único
✔ Componentes com redundância e hot-swap: servidor, armazenamento, placa de rede, fonte e ventilador
✔ Sistema Operacional Oracle Linux
✔ Dois Servidores de banco de dados
✔ 24 núcleos de processadores
✔ 192 GB de memória
✔ 12 TB de armazenamento com triple-mirror (espelhamento triplo), oferecendo 4 TB de armazenamento em RAID-1
✔ 292 GB de armazenamento em drive de estado sólido
✔ Oracle Database, Enterprise Edition 11g

✔ Oracle Real Application Clusters ou Oracle Real Application Clusters One Node

✔ Oracle Automatic Storage Management (ASM)
✔ Oracle Enterprise Manager

Abaixo é possível conferir uma apresentação de Renato Martins sobre ODA.

O valor estimado para um sistema desse, segundo a 4Partner,  está a partir de R$ 260.000,00.

Para concluir, indico que assistam esse vídeo abaixo que trás uma explicação sobre a ODA com um toque de humor. É muito bom!

Bom pessoal, por hoje é só!

Espero ter ajudado.

Até a próxima

Fonte:

4Partner - Oracle Database Appliance. Fácil. Confiável. Acessível. Disponível em: http://oracledatabaseappliance.com.br/oracle/hardware/oracle-database-appliance/solucao-completa-de-hardware-e-software.html. Acessado em: 22/04/2013.

Oracle Corporation - About Oracle Database Appliance. Disponível em: http://docs.oracle.com/cd/E22693_01/doc.21/e22692/abtoda.htm. Acessado em: 22/04/2013.

Felipe do Carmo - Oracle Database Appliance. Disponível em: http://felipedocarmo.blogspot.com.br/2011/12/oracle-database-appliance.html. Acessado em: 2504/2013.

Leia mais...

Documentos úteis para um DBA

Olá a todos!

Hoje quero falar um pouco sobre algo que li recentemente em um artigo publicado em 2007 e achei bastante interessante. O artigo fala sobre alguns documentos que um DBA deve lidar. Esses documentos são úteis para organizar e gerenciar atividades do DBA, além do mais, um documento também serve de registro técnico sobre algo.

Bom...

Para começar queria deixar claro uma coisa... documentar é um trabalho muito chato!! Hehehe

Brincadeiras a parte, a documentação é algo de extrema importância, e temos que ter sempre em mente que criar ou atualizar um documento não é apenas um trabalho desnecessário que consome tempo e torna uma demanda mais lenta. Documentação é um item necessário e obrigatório em qualquer projeto, servindo a vários propósitos.  As metodologias estão aí para isso, e logicamente, devido à maturidade dos processos, agregam muito valor ao serviço.

É bastante normal na T.I. (vou corrigir isso, pois normal não é!!)... É bastante frequente na T.I. encontrar profissionais que não gostam de documentar, seja esse documento de qualquer natureza. Talvez seja uma cultura que trazemos da escola ou faculdade, mas que devemos mudar!

Li certa vez (não me recordo onde), que em termos de documentação nos serviços de T.I., as mulheres são muito mais comprometidas e responsáveis que os homens. E levando em consideração minha experiência profissional, eu concordo plenamente com isso! Não podemos generalizar, mas em uma visão superficial pode-se notar que mulheres são mais organizadas e dedicadas em trabalhos de documentação (obviamente existem exceções).

Segundo Pichiliani, “em geral, é difícil encontrar profissionais, em particular DBAs, que trabalhem com muita documentação. Isso se deve tanto à questão cultural como a questão que envolve a disponibilidade de tempo para criar e manter a documentação atualizada.”

A seguir é apresentada uma lista de documentos elencadas por Pichiliani, úteis tanto para quem trabalha tanto como DBA como analista ou desenvolvedor.

1) MER (Modelo Entidade Relacionamento)

O MER, chamado também de modelo de dados ou diagrama de entidade-relacionamento, é a principal documentação de um banco de dados.  Nesse documento deve constar todas as entidades (com seus atributos, tipos de dados e restrições) do banco e seus relacionamentos. O MER pode ser de três tipos: conceitual, lógico e físico, e cada um desses têm uma particularidade. Não entrarei no detalhe, mas recomendo a leitura do artigo de Adail Faleiro, que aborda de forma objetiva o assunto.

2) Documento de Padrões de Variáveis

Utilizar nomes de fácil entendimento em classes, métodos, atributos, etc, é cada vez mais frequente como pré-requisito para quem trabalha com desenvolvimento. Sendo assim, utilizar padrões é sempre uma boa prática de desenvolvimento. Com foco em banco de dados, possuir um padrão de nomes para tabelas, colunas, restrições, procedimentos, funções e demais objetos de dados é muito importante. Segundo Pichiliani, a idéia é possuir um padrão eficaz que seja fácil de ser utilizado, além de fazer sentido no contexto de banco de dados. Para formalizar a adoção do padrão, Pichiliani recomenda criar um documento explicando os detalhes deste padrão tais como: se os nomes devem ser em português, se as palavras devem estar no plural ou se há um limite no tamanho da coluna.

3) Plano de Capacidade

Fiz um post recentemente sobre as tarefas de um DBA, e das atividades que cito (conforme orientação da própria Oracle) é a de “avaliar o hardware do servidor de banco de dados”, e de acordo com Pichiliani, além de economizar recursos, dimensionar os recursos necessários mostra que existe um controle não apenas para o ambiente atual, mas também para os recursos que podem ser necessários no futuro. Para que esse dimensionamento seja registrado (podendo evitar possíveis problemas), o DBA deve elaborar um documento de Plano de Capacidade. Neste documento, informações sobre espaço de armazenamento e crescimento médio dos ambientes, utilização de CPU, utilização de memória e outros requisitos técnicos; devem estar contidos para exibir o funcionamento do servidor atual e até embasar aquisição de novos recursos (hardware ou software).

4) Dicionário de dados

O dicionário de dados é um documento onde deve constar uma coleção de metadados que contém definições e representações de elementos de dados. Ele pode ser considerado um documento complementar ao MER. No documento deve conter algumas das seguintes informações definição sobre os objetos, perfis de usuários, papéis e privilégios, restrições de integridade, valores possíveis para um campo, quantidade típica de valores armazenados, etc. Vale lembrar que este documento deve sempre estar atualizado com a base de dados atual, para evitar desgastes e problemas.

5) Política de segurança

De acordo com Pichiliani, um documento que informa a política de segurança é um objeto não necessariamente técnico que envolve os procedimentos, responsabilidades e atribuições relacionadas à segurança das informações e disponibilização delas. Geralmente documentos dessa natureza contêm regras de usuários e senhas, tais como: nível de dificuldade da senha, atualização periódica dela, bloquei após repetidas tentativas mal sucedidas.

6)  Acordo de nível de serviço (ANS) ou SLA (Service Level Agreement)

O SLA é um acordo firmado entre a área de T.I. e seu cliente, que descreve o serviço, suas metas de nível de serviço, além dos papéis e responsabilidades das partes envolvidas no acordo. Este acordo deve deixar claro quais serviços estão sendo oferecidos (serviços específicos) e o nível de cada serviço (horas de funcionamento, downtime, horário do suporte, etc). Segundo Pichiliani, e com foco em banco de dados, pode-se utilizar um SLA interno, onde o DBA se compromete a dar algum tipo de retorno (feedback) ao solicitante, nem que seja apenas a informação de que está ciente  da solicitação (mesmo que ainda não tenha uma solução para a situação). Acordo de nível de serviço é algo que está muito em alta no mercado de T.I., por isso sugiro a leitura da biblioteca ITIL V3.

7) Diagrama de arquitetura

Geralmente as organizações possuem diversos ambientes de banco de dados, que podem ser separados de acordo com sua utilidade, como por exemplo:

 - ambiente de desenvolvimento – banco utilizado por desenvolvedores e analistas de sistemas para criação de aplicativos;

 - ambiente de homologação – banco utilizado para realização de validações de usuários antes de implantação de um aplicativo;

 - ambiente de produção – onde os usuários finais trabalham com os dados reais dos sistemas.

O DBA deve elaborar um diagrama de arquitetura para facilitar o gerenciamento desses ambientes, onde deverá apresentar de forma gráfica, quais servidores pertencem ao ambiente de desenvolvimento, homologação e produção. Este tipo de diagrama contém informações relacionadas à estrutura arquitetural dos ambientes e é extremamente útil para quem não conhece a organização física e lógica dos componentes da rede e dos servidores.

8) Estratégia de Backup

Mais uma das tarefas de todo DBA que postei num artigo passado é a de “Realizar backup, restaurar e recuperar o banco de dados”. Todo DBA deve possuir uma estratégia de backup adequada que deve ser criada de acordo com as necessidades de recuperação e disponibilidade do sistema, ou seja, vai depender do quanto de downtime e tempo de recuperação é aceitável de acordado com os SLA’s. Esse tipo de documentação é importante para registro oficial sobre o que pode ser recuperado e em quais circunstâncias.

É isso aí, pessoal...

Obviamente existem vários outros documentos importantes para um DBA, mais esses são alguns dos mais interessantes, e que todo DBA deve manter.

Espero ter ajudado!

Até a próxima.

Referências:

Pichiliani, Mauro - Documentação do DBA – 11/06/2007. Disponível em: http://imasters.com.br/artigo/6392/sql-server/documentacao-do-dba/ . Acessado em: 18/04/2013

Faleiro, Adail Tiago Lima - Modelo Entidade Relacionamento (MER). Disponível em: http://www.devmedia.com.br/modelo-entidade-relacionamento-mer/19821. Acessado em: 19/04/2013.

Leia mais...

Vídeo sobre recuperação de desastre

Olá a todos!

Estava procurando um documento em minha máquina, quando me deparei com anotações que tinha realizado enquanto cursava minha especialização em banco de dados. As anotações eram da disciplina  “Contingência e Alta Disponibilidade”. Me lembrei de um vídeo muito interessante que o professor tinha exibido para a turma. O vídeo era sobre um teste de recuperação de desastre com uma solução da HP.

Foi então que comecei a procurar o vídeo e achei!

Confiram e tirem suas conclusões.

Esse vídeo está no youtube, mas seu endereço original está no site da HP.

Em breve, quando estiver com um tempinho a mais extra, falarei sobre algumas coisas que aprendi sobre contingência e alta disponibilidade, focando mais para a área de banco de dados.

Até a próxima!

Leia mais...

Tarefas de um administrador de banco de dados Oracle

Olá a todos!

Tenho andado bastante sobrecarregado no trabalho e em outras atividades, o que tem resultado em pouco tempo de dedicação a posts aqui no blog.

Mas vou superar isso! hehehe

Bom... Hoje vou falar sobre algo bem básico que são as tarefas de um Administrador de Banco de Dados.

Identificar um DBA não é uma tarefa fácil, mesmo porque “tudo sempre é culpa do DBA”. Se ocorre um crash no banco no banco, chamam o DBA, até aí tudo bem, mas o DBA também pode ser chamado se a rede falhar, se os servidores derem uma pane ou se ocorrer um erro na aplicação, se a impressora está sem tinta ou se o telefone está com defeito...hehe (esses últimos acredito que qualquer profissional de T.I. está sujeito). Brincadeiras a parte, imaginasse que algumas dessas situações estão relacionadas às funções do DBA porque praticamente qualquer falha no ambiente de T.I. impede que os usuários finais acessem o banco de dados, logo faz do DBA o primeiro ponto de contato natural.

Abstraindo essas expectativas excessivas , seguindo as orientações da Oracle, que inclusive é cobrado no exame (1Z0-052 na versão 11G) para a certificação OCA, as tarefas de um DBA se resumem, segundo John Watson, basicamente nas seguintes:

Avaliar o hardware do servidor de banco de dados

Este item diz respeito à realização de previsões precisas relacionadas  à quantidade de memória, espaço em disco e CPU. O DBA deverá saber dimensionar os recursos necessáriaos para garantir que as aplicações serão bem executadas sem demandar recursos desnecessários, mantendo assim um desempenho bom sem extrapolar o orçamento disponível.

Instalar e manter o software Oracle

A instalação de um banco de dados Oracle e a criação de instâncias, é algo básico para um DBA, mas é de fundamental importância que este saiba também realizar instalações de patches críticos e patches de manutenção. Obviamente que antes de se implantar uma atualização em ambiente de produção, os patches devem ser adequadamente testados, uma vez que o DBA é o responsável pelo bom funcionamento do ambiente de banco de dados.

Planejar o banco de dados

Configurar o armazenamento físico de um banco de dados podem impactar na performance dos sistemas e seu gerenciamento. O DBA deve também estar ciente do impacto de diferentes estruturas de armazenamento nos dispositivos, como sistemas de discos e fitas.

Monitorar e ajustar o desempenho do banco de dados

Essa é uma atividade que deve ser contínua e frequente para os sistemas de banco de dados. Um bom DBA será capaz de antecipar os problemas de desempenho e corrigi-los antes que surjam, sempre trabalhando de forma proativa através, por exemplo, da realização de tuning (de configuração e de queries).

Auxiliar os desenvolvedores nos projetos de aplicações e ajustes de SQL

Alguns DBAs gastam muito tempo ajustando SQL, porém há quem diga (e particularmente concordo) que essa tarefa é função dos programadores. Onde o DBA pode participar, é ajudando a identificar as áreas com problemas para que eles (os desenvolvedores possam) resolver, e evitar problemas futuros.

Manter contato com fornecedores, usuários finais, desenvolvedores, gerentes e outros grupos de suporte

Como técnico com enfoque mais completo do ambiente, o DBA deve ter um papel de “liderança” na coordenação de planejamentos e ações de todos os grupos envolvidos no ambiente de T.I.

Realizar backup, restaurar e recuperar o banco de dados

Possivelmente a tarefa mais importante de um DBA é essa. O DBA deve criar rotinas que deverão garantir a disponibilidade do ambiente de banco de dados, preferencialmente combinando o mais próximo possível de 100% de tempo de atividade e 0% de perda de dados.

Não há certo ou errado, apenas a conformidade (ou a falha dela) aos objetivos combinados, e para garantir que a tarefa será bem sucedida, testes frequentes devem ser realizados.

Gerenciar os usuários do sistema e manter a segurança do banco de dados

Essa é outra parte crítica do trabalho do DBA. Como na tarefa de manter a disponibilidade do ambiente, para a atividade de segurança também não há certo e errado, apenas a conformidade com os acordos realizados. O DBA deve configurar os procedimentos que garantirão a conformidade e monitorar a seu funcionamento.

Bom pessoal...

Era isso que tinha para falar por hoje, o que obviamente não define a função de um DBA, mas trás características e funções interessantes. Vale lembrar que o amplo escopo da função de um DBA requer estudo contínuo e desenvolvimento pessoal, estudo do banco de dados Oracle e tecnologias relacionadas. Também requer vocação para educar e disseminar o conhecimento, talvez a parte mais gratificante do trabalho, por isso que escrevo e publico esses artigos aqui no blog.

Espero ter ajudado!

Até a próxima!

Referência:

WATSON, JOHN – OCA Oracle Database 11g – Administração I – Guia do Exame 1z0-052. Editora: BOOKMAN.

Leia mais...

Recuperar uma instância Oracle após a exclusão acidental de um datafile

Muito boa noite a todos!!

Hoje vou compartilhar com vocês mais um problema que passei, e realmente fiquei preocupado até achar a solução. Foi algo muito interessante e acho que muitos já devem ter passado por problemas parecidos (ao menos em nível de stress).

A história é mais ou menos a seguinte...

Estou realizando um trabalho de padronização de TABLESPACES em todas as bases de dados Oracle da organização onde trabalho. Esse trabalho consiste basicamente em criar as “N” tablespaces, divididas por tamanhos de extents distintos, como por exemplo: TBS50MB, TBS100MB, TBS500MB, etc.

Para alocar as tabelas e índices em uma tablespaces compatível com o tamanho do objeto, foi realizado um cálculo (que não vem ao caso) para que a tabela “residisse” em uma tablespace compatível com seu tamanho. Essa alteração é importante para muitas coisas, inclusive para facilitar o gerenciamento e melhorar performance dos scripts contra esses objetos.

O procedimento que estava realizando, e ainda estou pois são muitas bases, era o seguinte:

        1- Criação das tablespaces “corretas”;

        2- Realização da movimentação das tabelas e índices das tablespaces “antigas” para as novas através dos scripts abaixo:

a.     ALTER TABLE OWNER.TBL_TABELA MOVE TABLESPACE TBS50MB;

b.    ALTER INDEX IDX_TBL_01 REBUILD TABLESPACE TBS50MB;

        3- Após mover todos os objetos da tablespace, realizava o drop da tablespace antiga com o comando:

a.       DROP TABLESPACE TBSOLD INCLUDING CONTENTS AND DATAFILES;

        4- Depois de dropar a tablespace, acessava o servidor da base em questão e realizava a exclusão física do datafile (pois às vezes não eram excluídos pelo comando acima) e às vezes tinha que “derrubar” e iniciar a instância para conseguir excluir o datafile. Fazia isso para liberar espaço em disco gasto desnecessariamente, uma vez que os datafiles não seriam mais utilizados.

Basicamente foi isso que estava fazendo (mas pode acreditar, não é tão simples quanto parece).

Foi então que em uma das execuções, acabei interrompendo o trabalho para fazer alguma outra coisa, e quando retornei para essa atividade, executei o descrito no passo 4 antes do passo 3, ou seja, excluí o datafile antigo (e vazio) fisicamente antes de dropar a tablespace. Resultado, quando tentei “levantar” a instância, não consegui, pois quanto realizei o startup, foi solicitado o datafile excluído acidentalmente.

Na hora que dei conta de que tinha feito uma besteira, fui logo verificar como estava o backup, pois seria o pior dos casos realizar o recovery da base. Obviamente comecei essa tarefa de padronização das tablespaces pelas bases de teste e desenvolvimento, o que me fez respirar mais tranquilo para manter a “estabilidade emocional” (hehe).

Conversei com um colega também DBA sobre o que tinha acontecido e começamos a ver as possibilidades de solução que tínhamos para a situação. Procurei na internet sobre o assunto, foi então que encontrei, em um blog, um artigo com a seguinte chamada: How Drop Tablespace and Recover Oracle Database When Accidentally Delete Datafile.

Pessoal, isso foi um “achado”! (hehehe)

O autor expos uma situação muito parecida com a que vivi e descrevi acima, e a solução que ele apresentou foi mais ou menos a seguinte:

       1- Conectar no SQL*Plus como SYSDBA

a.       SQLPLUS /NOLOG

b.      CONNECT / AS SYSDBA

       2- O banco de dados deve estar no estado mount para conseguirmos executar o comando, então montemos o banco:

a.       STARTUP MOUNT;

        3- Em seguida, o comando que tornará o datafile off-line, e nos permitirá iniciar a instância (abrir o banco):

a.       ALTER DATABASE DATAFILE ' /opt/oracle/oradata/workspace/TBSOLD01.dbf' OFFLINE DROP;

        4- Agora vamos abrir o banco:

a.       ALTER DATABASE OPEN;

        5- Agora sim! Com a instância iniciada pude finalmente eliminar a tablespace do banco com o comando:

a.       DROP TABLESPACE TBSOLD INCLUDING CONTENTS AND DATAFILES;

É isso aí pessoal!

Realmente foi um susto o que ocorreu, um problema que pode acontecer com qualquer um (ou não... hehehe), mas felizmente foi tudo resolvido de forma tranquila.

Foi um ótimo aprendizado mas espero que vocês não passem por isso, porém caso ocorra, já sabem com solucionar, ok?!?!

Por hoje é só e até a próxima!

Referência:

MY DIGITAL LIFE - How Drop Tablespace and Recover Oracle Database When Accidentally Delete Datafile. Disponível em: http://www.mydigitallife.info/how-drop-tablespace-and-recover-oracle-database-when-accidentally-delete-datafile/. Acessado em: 04/04/2013.

Leia mais...

Particionamento de dados no banco de dados Oracle

Olá a todos!

Hoje vou falar sobre particionamento de tabelas e índices no banco de dados Oracle, mas precisamente sobre uma situação que passei recentemente no trabalho.

Para entender a situação que passei, é necessário um conhecimento básico sobre particionamento de tabelas e índices no banco de dados Oracle. Particionamento é alvo de muitos artigos e documentos oficiais da Oracle, portanto não quero entrar nesse mérito, mas recomendo a leitura de Borovina e Legatti que explicam de forma clara e objetiva as definições e conceitos envolvidos. Também tem uma vasta documentação da Oracle disponível em vários artigos, um deles fala sobre: Particionamento no Banco de Dados Oracle 11g. Os links para esses artigos são citados nas referências desse post.

Agora vou apresentar de fato a situação que vivi:

Em uma instância Oracle 10g (na versão 10.2.0.3) tenho uma tabela particionada por lista.

A estrutura da tabela é mais ou menos a seguinte:

CREATE TABLE TBL_TABELA

(

COD NUMBER(9) NOT NULL,

CADASTRO NUMBER(9) NOT NULL,

MES NUMBER(2),

ANO NUMBER(4)

)

TABLESPACE TBS_DEFAULT

PARTITION BY LIST (ANO)

(

PARTITION P_2008 VALUES (2008) TABLESPACE TBS_P_2008,

PARTITION P_2009 VALUES (2009) TABLESPACE TBS_P_2009,

PARTITION P_2010 VALUES (2010) TABLESPACE TBS_P_2010,

PARTITION P_2011 VALUES (2011) TABLESPACE TBS_P_2011,

PARTITION P_DEFAULT VALUES (DEFAULT) TABLESPACE TBS_DEFAULT

);

Meu problema é que os dados dos anos diferentes de 2008,2009,2010 e 2011 cairão, obviamente, na partição default.

O que tenho que fazer, é criar partições para os anos de 2012 e 2013, porém a presença da partição DEFAULT me impede de fazer isso.

É importante saber que a partição default está com muitos dados (2012 e 2013) e não posso simplesmente dropar ela.

Essa era a minha situação problemática, que inclusive tentei ajuda no fórum de Rodrigo Almeida.

No início dessa semana, pesquisando sobre o assunto, achei uma técnica interessante para resolver o assunto.

Para inserir uma nova partição, com a presença de uma partição default, inicialmente criei as tablespaces para os anos de 2012 e 2013, conforme exemplo abaixo:

CREATE TABLESPACE TBS_2012 DATAFILE

  '/opt/oracle/oradata/workspace/tbs_2012.dbf' SIZE 2048M AUTOEXTEND OFF

NOLOGGING

ONLINE

EXTENT MANAGEMENT LOCAL UNIFORM SIZE 100M

BLOCKSIZE 8K

SEGMENT SPACE MANAGEMENT AUTO

FLASHBACK ON;

Em seguida utilizei o comando SPLIT PARTITION para realizer a divisão de uma partição, esse é o ponto crucial da solução do problema.

A sintaxe que utilizei foi mais ou menos a seguinte (para o ano de 2012):

ALTER TABLE TBL_TABELA

   SPLIT PARTITION P_DEFAULT  VALUES (2012)

   INTO  ( PARTITION P_2012 TABLESPACE    TBS_2012,PARTITION P_DEFAULT);

O resultado após a execução desse comando é uma partição P_2012 (que estará na tablespace TBS_2012) contendo os dados da tabela do ano de 2012 e os dados dos outros anos ficarão na partição P_DEFAULT (exceto para os anos que existem partições referentes), no meu caso apenas os dados de 2013.

Depois fiz a mesma coisa para a partição do ano de 2013, e pronto. Resolvida a situação!

Bom pessoal, por enquanto é isso.

Grande abraço e até a próxima!

Referências:

LEGATTI, EDUARDO - Oracle Blog - Um pouco sobre índices particionados no Oracle. Disponível em: http://eduardolegatti.blogspot.com.br/2011/12/um-pouco-sobre-indices-particionados-no.html. Acessado em: 02/04/2013.

BOROVINA, JOÃO MARCELO - Particionamento de Dados: Uma introdução aos conceitos e aplicação. Disponível em: http://www.devmedia.com.br/particionamento-de-dados-uma-introducao-aos-conceitos-e-aplicacao/7299. Acessado em 02/04/2013.

ALMEIDA, RODRIGO - Fórum: Problema com tabela particionada no Oracle 10g. Disponível em: http://www.rodrigoalmeida.net/forum/viewtopic.php?f=3&t=891&sid=2642261a63b71d2453109f92000e0a96 Acessado em: 01/04/2013.

Oracle Corporation - Particionamento no Banco de Dados Oracle 11g -Um artigo técnico da Oracle. Junho de 2007. Disponível em: http://www.oracle.com/technetwork/pt/database/enterprise-edition/documentation/particionamento-banco-de-dados-11g-432098-ptb.pdf. Acessado em: 31/03/2013.

Oracle Corporation - Maintaining Partitions. Disponível em: http://docs.oracle.com/cd/E11882_01/server.112/e25523/part_admin002.htm. Acessado em: 01/04/2013.

Leia mais...