Introdução ao conceito de Tablespaces no Oracle

Olá,

Começarei este artigo fazendo a seguinte pergunta: Qual é a relação entre tablespaces e arquivos de dados? Bom, para responder esta pergunta, primeiro precisamos entender como os dados são armazenados no banco de dados Oracle. Para começar, o Oracle armazena dados logicamente em tablespaces e fisicamente em arquivos de dados (datafiles). Apesar dos arquivos de dados e os tablespaces estarem muito "inter-relacionados", os mesmos possuem diferenças importantes:

• Um banco de dados Oracle consiste em uma ou mais unidades de armazenamento lógicas denominadas tablespaces, que armazenam coletivamente todos os dados do banco de dados.

• Cada tablespace em um banco de dados Oracle consiste em um ou mais arquivos denominados arquivos de dados (datafiles), que são estruturas físicas compatíveis com o sistema operacional no qual o Oracle é executado.

• Os dados de um banco de dados são armazenados coletivamente nos arquivos de dados que constituem cada tablespace do banco de dados.

Como um banco de dados é um conjunto de arquivos de dados, é muito importante que entendamos como um banco de dados Oracle agrupa esses arquivos. Como dito anteriormente, o Oracle faz isso sob a proteção de um objeto de banco de dados chamado tablespace. Antes de poder inserir dados em um banco de dados Oracle, primeiro é necessário criar um tablespace e depois uma tabela dentro desse tablespace que conterá os dados. Podemos observar que na criação de um banco de dados utilizando o DBCA, o Oracle como padrão sempre cria um tablespace de dados chamado USERS. Ao criar uma tabela é necessário incluir todas as informações sobre o tipo de dados que deseja manter. O código abaixo, gerado para criar a tabela CLIENTE, ilustra como o Oracle armazena informações sobre o tipo de dado que irá registrar:

SQL> create table cliente
 2  (cod_cliente   number constraint pk_cliente primary key,
 3   nome          varchar2(60)  not null,
 4   endereco      varchar2(100) not null,
 5   telefone      number,
 6   data_cadastro date)
 7  tablespace users;

Tabela criada.

SQL> desc cliente
Nome                          Nulo?    Tipo
----------------------------- -------- --------------------
COD_CLIENTE                   NOT NULL NUMBER
NOME                          NOT NULL VARCHAR2(60)
ENDERECO                      NOT NULL VARCHAR2(100)
TELEFONE                               NUMBER
DATA_CADASTRO                          DATE

SQL> select table_name,tablespace_name
  2    from user_tables
  3   where table_name='CLIENTE';

TABLE_NAME                     TABLESPACE_NAME
------------------------------ ------------------------------
CLIENTE                        USERS

Na instrução acima, foi criada uma tabela que é o meio mais comum de armazenar dados em um banco de dados. Os dados de um segmento de tabela são armazenados aleatoriamente no tablespace e o DBA tem pouco controle sobre a localização das linhas dos blocos de uma tabela. Por falar nisso, o que é um segmento? Os segmentos são objetos que ocupam espaço em um banco de dados. Existem vários tipos de segmentos como tabelas, índices, de undo, temporários, LOB, entre outros. Já uma extensão (extent), é um espaço usado por um segmento em um tablespace. Para terminar, um bloco Oracle consiste em um ou mais blocos do sistema operacional e seu tamanho é definido na criação do tablespace. Então a estrutura lógica de um banco de dados Oracle se resume em tablespaces que contém segmentos que contém extensões que contém blocos. A figura abaixo ilustra esta estrutura lógica:
 

SQL> select segment_name, segment_type, tablespace_name, bytes,blocks, extents
  2    from user_segments
  3   where segment_name = 'CLIENTE';


SEGMENT_NAME   SEGMENT_TYPE TABLESPACE_NAME  BYTES     BLOCKS   EXTENTS
-------------- ------------ ---------------- -------- ------- ---------
CLIENTE        TABLE        USERS               65536       8         1

Vale a pena salientar que eu incluí o nome do tablespace USERS no comando de criação da tabela apenas para exemplificar, já que uma tabela sempre será criada no tablespace padrão do usuário definido na sua criação (create user).

SQL> select default_tablespace from user_users;

DEFAULT_TABLESPACE
------------------------------
USERS

Agora que você entende porque isso se chama tablespace, vamos tentar compreender porque precisamos de tablespaces para agrupar arquivos de dados. A melhor analogia para se explicar banco de dados, tablespace, arquivo de dados, tabelas e dados é a imagem de um fichário. Imagine um banco de dados como um fichário: as gavetas dentro do fichário são os tablespaces; as pastas nessas gavetas são os arquivos de dados; os papéis em cada pasta são as tabelas; a informação escrita no papel de cada pasta são os dados. Em resumo, o tablespace é um modo de agrupar arquivos de dados.

É aconselhável não misturar dados de aplicativos no mesmo tablespace. Então, ao criar tablespaces para seus aplicativos, dê a eles um nome descritivo (por exemplo, dados de um sistema de RH podem ser mantidos no tablespace RECURSOS_HUMANOS). Em resumo, aplicação separada corresponde a tablespace separado.

O que é o tablespace USERS?

Como demonstrado anteriormente, este geralmente é o tablespace padrão para os usuários. Se um usuário criar um objeto, tal como uma tabela ou um índice, sem especificar o tablespace, o Oracle o cria no tablespace padrão do usuário, isso se o tablespace padrão do usuário foi definido para utilizar o tablespace USERS.

O que é o tablespace SYSTEM?

O tablespace SYSTEM (tablespace de sistema) é uma parte obrigatória de todo banco de dados Oracle. É onde o Oracle armazena todas as informações necessárias para o seu próprio gerenciamento. Em resumo, SYSTEM é o tablespace mais crítico do banco de dados porque ele contém o dicionário de dados. Se por algum motivo ele se tornar indisponível, a instância do Oracle abortará. Por esse motivo, o tablespace SYSTEM nunca pode ser colocado offline, ao contrário de um tablespace comum como, por exemplo, o tablespace USERS.

O que é o tablespace TEMP?

O tablespace TEMP (tablespace temporário) é onde o Oracle armazena todas as suas tabelas temporárias. É o quadro branco ou papel de rascunho do banco de dados. Assim como às vezes precisamos de um lugar para anotar alguns números para pode somá-los, o Oracle também precisa de algum espaço em disco temporário. O Oracle geralmente utiliza o tablespace temporário para armazenar objetos transitórios durante as classificações e agrupamentos de dados durante a execução de uma SQL contendo as cláusulas ORDER BY e GROUP BY, entre outras. É importante dizer também que os dados de sessão das tabelas temporárias globais (Global Temporary Tables) também ficam no tablespace TEMP. Assim como o tablespace SYSTEM é o tablespace mais crítico do banco dados, o tablespace TEMP é o menos crítico do banco de dados exatamente porque armazena apenas os segmentos temporários durante as operações de classificação de dados e, como tal, no caso de uma falha, ele pode simplesmente ser dropado e recriado, em vez de ser restaurado e recuperado.

O que é o tablespace UNDO?

Todos os bancos de dados Oracle precisam de um local para armazenar informações a desfazer. O que isso significa? 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 quando 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. Basicamente, os objetivos dos segmentos de undo são:

• Rollback de transação: Quando uma transação modifica uma linha de uma tabela, a imagem original das colunas modificadas é salvas no segmento de UNDO, e se for feito o rollback da transação, o servidor Oracle restaurará os valores originais gravando os valores do segmento de UNDO novamente na linha.

• Recuperação de Transação: Se ocorrer uma falha de instância enquanto houver transações em andamento, o servidor Oracle precisará desfazer as alterações não submetidas à commit quando o banco de dados for aberto novamente. Esse rollback faz parte da recuperação da transação. Portanto, a recuperação só é possível porque as alterações feitas no segmento de UNDO também são protegidas pelos arquivos de redo log online.

• Consistência de Leitura: Enquanto houver transações em andamento, outros usuários do banco de dados não deverão ver as alterações não submetidas à commit feitas nessas transações. Além disso, uma instrução não deverá ver as alterações submetidas à commit após o início da execução dessa instrução. Os valores antigos (dados de undo) dos segmentos de UNDO também são usados para oferecer aos leitores uma imagem consistente de uma instrução específica.

O que é o tablespace SYSAUX?

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 desse tablespace, alguns gargalos de I/O freqüentemente associados ao tablespace SYSTEM foram reduzidos ou eliminados. Vale a pena salientar que não é bom que o tablespace SYSAUX seja colocado no modo offline, pelo fato de correr o risco do banco de dados não funcionar corretamente. Portanto, podemos dizer que o mesmo é parte integrante e obrigatório em todos os bancos de dados à partir do Oracle 10g. Existe uma view de dicionário de dados que mostra os ocupantes neste tablespace:

  
SQL> select occupant_name, schema_name, space_usage_kbytes
  2    from v$sysaux_occupants;

OCCUPANT_NAME   SCHEMA_NAME          SPACE_USAGE_KBYTES
--------------- -------------------- ------------------
LOGMNR          SYSTEM                             7488
LOGSTDBY        SYSTEM                                0
STREAMS         SYS                                 192
AO              SYS                                 960
XSOQHIST        SYS                                 960
SM/AWR          SYS                               68352
SM/ADVISOR      SYS                                7360
SM/OPTSTAT      SYS                               21120
SM/OTHER        SYS                                3328
STATSPACK       PERFSTAT                              0
ODM             DMSYS                              5504
SDO             MDSYS                              6080
WM              WMSYS                              6656
ORDIM           ORDSYS                              512
ORDIM/PLUGINS   ORDPLUGINS                            0
ORDIM/SQLMM     SI_INFORMTN_SCHEMA                    0
EM              SYSMAN                            61632
TEXT            CTXSYS                             4736
ULTRASEARCH     WKSYS                              7296
JOB_SCHEDULER   SYS                                 256
 

Uma outra informação bastante útil que esta view oferece é o nome de uma procedure que o DBA pode utilizar para mover dados de um ocupante para um outro tablespace:

SQL> select occupant_name, move_procedure
  2  from v$sysaux_occupants where occupant_name = 'LOGMNR';

OCCUPANT_NAME   MOVE_PROCEDURE
--------------- ---------------------------------------
LOGMNR          SYS.DBMS_LOGMNR_D.SET_TABLESPACE
  

Gerenciamento de Espaço em Tablespaces

Os tablespaces alocam espaço em extensões (extents). Eles podem ser criados para usar um dos dois métodos de controle de espaço livre e utilizado:

• Tablespaces gerenciados localmente: As extensões são gerenciadas no tablespace por bitmaps. Cada bitmap corresponde a um bloco ou a um grupo de blocos. Quando uma extensão é alocada ou liberada para reutilização, o servidor Oracle altera os valores do bitmap para mostrar o novo status dos blocos. A partir do Oracle 9i este gerenciamento local é o padrão.

• Tablespaces gerenciados por dicionário: As extensões são gerenciadas pelo dicionário de dados. O servidor atualiza as tabelas apropriadas no dicionário de dados sempre que uma extensão é alocada ou desalocada.

Nas versões anteriores ao Oracle 8i, os extents de todos os tablespaces eram gerenciados centralmente por meio das tabelas do dicionário de dados, quando os extents são alocados ou desalocados em qualquer lugar do banco de dados, o Oracle atualiza as tabelas do dicionário de dados para registrar o novo mapa de armazenamento. A partir do Oracle 8i um novo recurso possibilitando o gerenciamento local dos extents dentro de um tablespace praticamente decretou a morte do tablespace gerenciado por dicionário de dados.

Como dito anteriormente, o Oracle mantém um bitmap em cada arquivo de dados de um tablespace gerenciado localmente. Para se criar um tablespace gerenciado localmente, é necessário usar a cláusula EXTENT MANAGEMENT LOCAL como o comando create tablespace. Comparando com os tablespaces gerenciados por dicionário, os tablespaces gerenciados localmente têm um modo completamente diferente de dimensionar os extents. Os parâmetros de armazenamento NEXT, PCTINCREASE, MINEXTENTS, MAXEXTENTS e DEFAULT_STORAGE não são válidos nos casos dos tablespaces gerenciados localmente. Em vez disso, existe a opção de especificar um tamanho uniforme para todos os extents ou especificar apenas o tamanho do extent inicial e deixar que o Oracle determine automaticamente o tamanho de todos os extents subseqüentes. Os extents uniformes ou dimensionados automaticamente podem ser selecionados especificando as opções UNIFORM ou AUTOALLOCATE, respectivamente, ao criar um tablespace gerenciado localmente com o comando CREATE TABLESPACE.

OBS: Os tablespaces gerenciados localmente ajudam a reduzir a overhead de gerenciamento de espaço eliminando a necessidade de várias gravações nas tabelas do dicionário de dados ou nos segmentos de rollback, o que ocorre necessariamente quando o espaço é gerenciado centralmente por meio do dicionário de dados. Segundo a Oracle, os tablespaces gerenciados por dicionário não serão mais suportados nas futuras versões do Oracle:

"Oracle strongly recommends that you create only locally managed tablespaces. Locally managed tablespaces are much more efficiently managed than dictionary-managed tablespaces. The creation of new dictionary-managed tablespaces is scheduled for desupport."

Outra informação importante é que um tablespace gerenciado por dicionário não pode ser criado caso o tablespace SYSTEM seja gerenciado localmente:

SQL> create tablespace tbs_test
  2  logging
  3  datafile /u01/oradata/BD01/test01.dbf' size 5m
  4  extent management dictionary;
create tablespace tbs_test
*
ERRO na linha 1:
ORA-12913: Não é possível criar um tablespace gerenciado por dicionário

SQL> select extent_management
  2    from dba_tablespaces
  3   where tablespace_name = 'SYSTEM';

EXTENT_MANAGEMENT
-----------------
LOCAL