Pular para o conteúdo

10 dicas para gerenciar tablespaces em Bancos de Dados Oracle

Boas práticas para gerenciar tablespaces

Introdução

Como sempre observo em fóruns questões relacionadas ao gerenciamento de tablespaces e também ouvi questões semelhantes até mesmo no famoso evento GUOB TECH DAY (em uma das palestras em que estive presente este ano), vou apresentar neste artigo 10 dicas, que podem ser consideradas como boas práticas para gerenciar tablespaces em Bancos de Dados Oracle, com uma breve justificativa sobre o porquê de implementá-las. É importante ressaltar, que algumas restrições em seu ambiente podem impedir o uso dessas dicas, portanto, antes de implementá-las pesquise mais sobre o assunto. Se você é leigo no assunto e deseja entender melhor o que é um tablespace, sugiro a leitura do artigo Introdução ao conceito de Tablespaces.

Dicas para gerenciar tablespaces

 1- Crie tablespaces separados para cada aplicação

Separar o armazenamento de dados de cada aplicação do BD em tablespaces diferentes permite isolar os dados de forma que isso facilite manutenções futuras, possibilite melhores configurações de otimização e segurança, e possibilite também, recuperações mais rápidas e simples.

Se por exemplo, você tem 2 aplicações em um BD, onde uma delas tem a característica principal de ter muitas consultas e a outra tem muitas atualizações; visando otimizar a performance destas aplicações, você pode criar o primeiro tablespace com um tamanho de bloco maior que o padrão (Ex. 32k), e o segundo com o tamanho de bloco padrão (8k) e configurações de armazenamento customizadas, tais como: NOLOGGING e INITRANS, com valor correspondente à quantidade de transações médias concorrentes etc. Visando otimizar o I/O, você pode também criar os tablespaces em discos ou conjuntos de discos separados. Outro benefício: Se uma das aplicações efetuar uma operação indevida e você precisar restaurar os dados para um estado prévio, você pode isso no nível do tablespace de uma aplicação, sem afetar a outra.

2 – Separe dados e índices em tablespaces distintos

Pelo mesmo motivo da dica anterior, você também pode separar dados e índices das aplicações em tablespaces diferentes. Aqui, uma dica que eu dou em meus treinamentos de tuning visando otimizar a manutenção de índices, é configurar o tablespace deles para não gerar log, desde que você tenha armazenado em algum lugar os scripts de criação dos índices. Índices não contém dados críticos, portanto, se por exemplo, o seu datafile corromper e você tiver os scripts de criação deles, muitas vezes é mais rápido e fácil, recriar o datafile e os índices, do que recuperar o datafile de um backup (essa recuperação sem perdas, exigiria a geração de log). Em ambientes com Data Guard, isso não se aplica, pois nos BDs destes ambientes é necessário forçar a geração de logs para garantir a replicação efetiva dos dados. 

Para aqueles que desejam mais informações sobre o assunto, sugiro a leitura do artigo: Performance de consultas em Tablespaces separados para Dados e Índices.

3 – Crie tablespaces gerenciados localmente

Crie tablespaces gerenciados localmente (TGLs) se você estiver usando Oracle Database 10G. No 11G não há mais opção de criar tablespaces gerenciados por dicionário, portanto, os TGLs são a única opção disponível. TGLs causam, em geral, menor contenção de dados, e por isso são mais rápidos em ambientes com alta carga de trabalho.

4 – Crie BIGFILE Tablespaces

Até o 10G você tinha bons motivos para não criar Bigfile Tablespaces, como por exemplo, o tamanho das peças de backup e o seu desempenho do backup de um grande tablespace, que não podia ser melhorado com o uso de paralelismo. No 11G, podemos dividir o datafile de um Bigfile Tablespace em partes menores (seções) e esse foi um grande avanço desta versão, portanto, agora você já pode criar Bigfile Tablespaces sem maiores preocupações!

Bigfile Tablespaces oferecem os seguintes benefícios:

  • Simplificam o gerenciamento de datafiles;
  • Permitem criar BDs 1024 X maiores do que com SmallFile Tablespaces;
  • Melhoram a performance da abertura do BD, dos processos de checkpoint e dos processos DBWR.

5 – Minimize a quantidade de datafiles em um tablespace

Menos datafiles implicam em melhor performance na abertura do BD, nos processos de checkpoint e nos processos DBWRs. Se você não usa Bigfile Tablespaces, crie somente a quantidade de datafiles necessária para cada tablespace. Uma forma de minimizar a quantidade de datafiles é criar o tablespace com tamanhos de blocos maiores, como por exemplo, blocos de 32k. Tablespaces com blocos de 32k podem conter datafiles com tamanho 4 X maiores que um datafile de um tablespace com bloco de 8k, portanto, ao invés de criar 4 datafiles você poderia criar apenas 1. Porém, tenha CUIDADO! Blocos maiores são muito bons para operações de leitura, mas normalmente prejudicam as atualizações. Comento sobre isso em mais detalhes nos treinamentos de SQL Tuning e Performance Tuning for Oracle DBAs.

6 – Crie tablespaces com gerenciamento de segmentos automático

A partir do Oracle 10G, crie tablespaces com o Gerenciamento de Espaço de Segmentos Automático (ASSM), ao invés de gerenciar PCTUSED, freelists e freelists groups. ASSM otimiza a maior parte das aplicações OLTP e é recomendado até mesmo para ambientes RAC. Somente em casos específicos, tais como aplicações que possuem tabelas com alto nível de concorrência realizando FTS e alto volume de INSERTs, avalie o uso do gerenciamento de segmentos manual.

7- Planeje o tamanho máximo dos tablespaces

Faça um bom planejamento do tamanho máximo de cada tablespace do Banco de Dados, de modo que eles comportem os dados de todas as aplicações, no espaço de armazenamento total que você tem disponível. Configurar o tamanho máximo evita que um determinado tablespace utilize desnecessariamente o espaço que poderia ser utilizado, por exemplo, para um novo tablespace, de uma nova aplicação.

8 – Cuidado com o auto-incremento dos tablespaces

Se você configurou o auto-incremento (AUTOEXTEND) nos tablespaces, especifique um tamanho de auto-incremento apropriado para que o novo tamanho comporte mais dados por um período que não seja muito curto. O ideal é que este auto-incremento ocorra com a menor frequência possível, pois há um custo considerável para aumentar o tamanho do tablespace, que influencia negativamente na performance das aplicações quando ocorrem atualizações em seus objetos. Já vi uma aplicação com sérios problemas de performance em uma empresa em que trabalhei, por causa da configuração inadequada deste auto-incremento. Demonstro isso em mais detalhes no treinamento Performance Tuning for Oracle DBAs.

9- Separe LOBs em tablespaces exclusivos

Para otimizar performance (principalmente consultas FTS que não envolvem a coluna LOB) e evitar fragmentação de linhas, armazene as colunas LOB em um tablespace separado da tabela, preferencialmente com tamanho de bloco maior. Existem mais dicas e cuidados que devemos ter com colunas do tipo LOB, mas essas eu deixo para explicar no treinamento Performance Tuning for Oracle DBAs.

10 – Gerencie o tamanho dos tablespaces de sistema

Cuidado com o tamanho e fragmentação do tablespace SYS. Uma boa forma de minimizar o risco dele crescer muito e evitar fragmentação, é não criar objetos neste tablespace e mudar a configuração da tabela AUD$ para que ela armazene seus dados em um tablespace diferente do SYS. Pesquise também boas práticas para gerenciar o tablespace TEMP e o UNDO. Para gerenciar o tablespace de UNDO, leia o artigo Configurando o UNDO Tablespace.

Artigo original: http://www.fabioprado.net/2013/11/boas-praticas-para-gerenciar-tablespaces.html

Quão útil foi este post ?

Clique em uma estrela para classificar o post

nota média 5 / 5. Contagem de votos: 24

Sem votos ! Seja o primeiro a classificar !

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

plugins premium WordPress