Entendendo os tipos de tablespace no Oracle 11g

Definir critérios para a divisão de um banco de dados Oracle em tablespaces é sempre uma questão importante para os DBAs na organização do armazenamento. Um pré-requisito para configurar de maneira competente os tablespaces em seu banco de dados é entender os diferentes tipos existentes e como eles podem ser utilizados no servidor de bancos de dados Oracle para melhor atender à demanda do nível externo e otimizar quanto ao espaço que é requisitado, tabelas mais acessadas e qual é a melhor maneira de gerenciar como um dos tipos existentes.

Os tablespaces se apresentam nas seguintes categorias:

• Tablespace SYSTEM:

  O tablespace SYSTEM é considerado um tablespace permanente, além disso, todos os segmentos que precisam ser mantidos por um usuário ou uma aplicação além dos limites de uma sessão ou transação devem ser armazenados em um tablespace permanente.

  Os segmentos de um usuário nunca devem residir neste tablespace. A partir do Oracle 10g, é possível especificar um tablespace permanente padrão além do recurso de especificar um temporário padrão no Oracle 9i. Também a partir do Oracle 10g, o este tablespace é gerenciado localmente por padrão, ou seja, toda a utilização de espaço é gerenciada por um *segmento de bitmap na primeira parte do primeiro arquivo de dados do tablespace. Usar tablespace gerenciados localmente remove parte da disputa ou concorrência que pode ser gerada neste tablespace porque operações de alocação e desalocação de espaço não precisam usar tabelas de dicionário de dados.

  Para verificar se o tablespace SYSTEM é gerenciado localmente ou não, entre com a seguinte consulta e verifique a coluna EXTENT_MANAGEMENT:

  O tablespace SYSTEM é responsável por armazenar o dicionário de dados e seus respectivos objetos (metadados). Quantos mais objetos forem criados nos bancos de dados de uma instância Oracle, maior será este tablespace.

• Tablespace SYSAUX:

  Como o tablespace anterior, o SYSTEM, este não deve ter segmentos de usuários. O conteúdo deste tablespace são membros de processos realmente auxiliares, por isso, caso haja algum processo que esteja ocupando muito espaço neste tablespace, interessante pensar em trocá-lo de lugar. O monitoramento poderá ser realizado através do EM Database Control.

  Este tablespace auxiliar não existe nas versões anteriores ao Oracle 10g e foi criado especialmente para aliviar o tablespace SYSTEM de segmentos associados a algumas aplicações do próprio banco de dados como o Oracle ultra search, Oracle Text e até mesmo segmentos relacionados ao funcionamento do Oracle Enterprise Manager entre outros.

  Como resultado da criação do tablespace SYSAUX, alguns dos gargalos de I/O freqüentemente associados ao tablespace SYSTEM foram reduzidos ou eliminados. Vale salientar, que o este tablespace não pode se colocado em modo offline e é parte integrante obrigatória em todos os bancos de dados a partir do Oracle 10g. Existe uma visão no dicionário de dados que exibe os dados relacionados com os ocupantes atuais neste tablespace:

• Tablespace temporários:

  Segundo Rodrigo Almeida, uma das atuais autoridades em Oracle, a tablespace temporária, ou como nós conhecemos por TEMP, é utilizada para armazenar informações de ordenação (SORT) ou para armazenar dados de tabelas temporárias (CREATE TEMPORARY TABLE). A principio, a Tablespace Temporária tem seu lugar físico reservado no servidor, determinado pelo DBA, porém, sua principal função no banco de dados é auxiliar a memória do Oracle (SGA), em seu principal componente, o SORT_AREA_SIZE.

  É possível ter mais de um tablespace temporário ativo e online no banco de dados, mas até o Oracle 10g, várias sessões do mesmo usuário usariam o mesmo tablespace temporário, pois, apenas um tablespace temporário padrão poderia ser atribuído a um usuário. Para resolver esse possível problema de gargalo, podemos na versão 11g, utilizar grupos de tablespace temporários. Um grupo de tablespaces temporários deve consistir em ao menos um tablespace temporário e ele não pode ser vazio. Uma vez que um grupo de tablespaces temporários não tenha membros, ou seja, não tenha nenhum tablespace, ele deixará de existir.

  Ao invés de se atribuir a um usuário apenas um tablespace, podemos atribuir um grupo deles. Interessante observar que um grupo com três tablespaces poderá ceder espaço para organização dos dados de uma consulta A (esta que poderá utilizar ORDER BY, GROUP BY, DISTINCT, UNION, INTERSECT e/ou MINUS) e os outros tablespaces continuarão disponíveis para realizar o mesmo trabalho, de forma paralela, para outras consultas deste mesmo usuário.

  A criação de um grupo de tablespaces temporários é muito simples. Após criarmos os tablespaces, aqui neste exemplo chamaremos de TMP_1, TMP_2 e TMP_3, alteramos os mesmo para adicionar ao grupo TMP_GROUP:

  Neste momento, o grupo de tablespaces temporários, chamado de TMP_GROUP contém três membros. Para eliminar um grupo de tablespaces, primeiramente teremos que eliminar os seus membros; a eliminação dos membros de um grupo de tablespaces poderá ser realizada atribuindo uma string vazia ao seu grupo:

  Como um grupo de tablespaces temporários somente existirá se tiver pelo menos um tablespace, neste momento ele já não mais existe. Para checarmos os grupos de tablespaces temporários que existem em servidor de bancos de dados Oracle:

• Tablespace de UNDO:

  Esse tablespace que contém seus segmentos de reconstrução em versões anteriores ao Oracle 9i chamado de RBS (tablespace de rollback), possui a capacidade de recuperar transações incompletas ou abortadas. Um segmento de undo é usado para salvar o valor antigo qparcialuando um processo altera dados de um banco de dados. Ele armazena a localização dos dados e também os dados da forma como se encontravam antes da modificação.

  Embora um banco de dados possa ter mais de um tablespace de UNDO, apenas um poderá estar ativo em um dado momento. Caso este necessite de mais espaço a AUTOEXTEND não estiver ativado, um novo arquivo de dados poderá ser adicionado.

• Tablespace BIGFILE:

  Um tablespace BIGFILE facilita a administração do banco de dados porque consiste em apenas um arquivo de dados. Um único arquivo deste tipo de tablespace poderá chegar até 128TB de tamanho se o tamanho de bloco do tablespace for 32K.

  Problemas relacionados:

  • Mais tempo para efetuar backup;
  • Menos gerenciamento físico;
  • Mais fácil de corromper;
  • Backup parcial não é permitido.