Introduo ao conceito de Tablespaces

Qual a relao entre tablespaces e arquivos de dados? O Oracle armazena

dados logicamente em tablespaces e fisicamente em arquivos de dados
(datafiles). Os arquivos de dados e os tablespaces esto muito interrelacionados, mas tm diferenas importantes:
Um banco de dados Oracle consiste em uma ou mais unidades de
armazenamento
lgicas
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 so
estruturas fsicas compatveis com o sistema operacional no qual o
Oracle executado.

Os dados de um banco de dados so 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 proteo de um
objeto de banco de dados chamado tablespace. Antes de poder inserir dados
em um banco de dados Oracle, primeiro necessrio criar um tablespace e
depois uma tabela dentro desse tablespace que conter os dados. Podemos
observar que na criao de um banco de dados utilizando o DBCA, o Oracle
como padro sempre cria um tablespace de dados chamado USERS. Ao criar uma
tabela necessrio incluir todas as informaes sobre o tipo de dados que
deseja manter. O cdigo abaixo para criar a tabela CLIENTE ilustra como o
Oracle armazena informaes 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
----------------------------COD_CLIENTE
NOME
ENDERECO
TELEFONE
DATA_CADASTRO

Nulo?
-------NOT NULL
NOT NULL
NOT NULL

Tipo
-------------------NUMBER
VARCHAR2(60)
VARCHAR2(100)
NUMBER
DATE

SQL> select table_name,tablespace_name

2 from user_tables
3 where table_name='CLIENTE';
TABLE_NAME
TABLESPACE_NAME
------------------------------ -----------------------------CLIENTE
USERS
Na instruo 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
so armazenados aleatoriamente no tablespace e o DBA tem pouco controle
sobre a localizao das linhas dos blocos de uma tabela. Por falar nisso,

o que um segmento? Os segmentos so objetos que ocupam espao em um

banco de dados. Existem vrios tipos de segmentos como tabelas, ndices,
de undo, temporrios, LOB, entre outros. J uma extenso (extent), um
espao 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 criao do tablespace. Ento a estrutura lgica de um banco
de dados Oracle se resume em tablespaces que contm segmentos que contm
extenses que contm blocos. A figura abaixo ilustra esta estrutura
lgica:

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

SEGMENT_TYPE
-----------TABLE

TABLESPACE_NAME
---------------USERS

BYTES

BLOCKS

-------65536

------8

Vale a pena salientar que eu inclu o nome do tablespace USERS no comando

de criao da tabela apenas para exemplificar, j que uma tabela sempre
ser criada no tablespace padro do usurio definido na sua criao
(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 fichrio. Imagine um
banco de dados como um fichrio: as gavetas dentro do fichrio so os
tablespaces; as pastas nessas gavetas so os arquivos de dados; os papis

em cada pasta so as tabelas; a informao escrita no papel de cada pasta

so os dados. Em resumo, o tablespace um modo de agrupar arquivos de
dados.
aconselhvel no misturar dados de aplicativos no mesmo tablespace.
Ento, 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, aplicao separada corresponde a
tablespace separado.
O que o tablespace USERS?
Como demonstrado anteriormente, este geralmente o tablespace padro para
os usurios. Se um usurio criar um objeto, tal como uma tabela ou um
ndice, sem especificar o tablespace, o Oracle o cria no tablespace padro
do usurio, isso se o tablespace padro do usurio foi definido para
utilizar o tablespace USERS.
O que o tablespace SYSTEM?
O tablespace SYSTEM (tablespace de sistema) uma parte obrigatria de
todo banco de dados Oracle. onde o Oracle armazena todas as informaes
necessrias para o seu prprio gerenciamento. Em resumo, SYSTEM o
tablespace mais crtico do banco de dados porque ele contm o dicionrio
de dados. Se por algum motivo ele se tornar indisponvel, a instncia do
Oracle abortar. Por esse motivo, o tablespace SYSTEM nunca pode ser
colocado offline, ao contrrio de um tablespace comum como, por exemplo, o
tablespace USERS.
O que o tablespace TEMP?
O tablespace TEMP (tablespace temporrio) onde o Oracle armazena todas
as suas tabelas temporrias. o quadro branco ou papel de rascunho do
banco de dados. Assim como s vezes precisamos de um lugar para anotar
alguns nmeros para pode som-los, o Oracle tambm precisa de algum espao
em disco temporrio. O Oracle geralmente utiliza o tablespace temporrio
para
armazenar
objetos
transitrios
durante
as
classificaes
e
agrupamentos de dados durante a execuo de uma SQL contendo as clusulas
ORDER BY e GROUP BY. importante dizer tambm que os dados de sesso das
tabelas temporrias globais (Global Temporary Tables) tambm ficam no
tablespace TEMP. Assim como o tablespace SYSTEM o tablespace mais
crtico do banco dados, o tablespace TEMP o menos crtico do banco de
dados exatamente porque armazena apenas os segmentos temporrios durante
as operaes de classificao 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
informaes a desfazer. O que isso significa? Esse tablespace que contm
seus segmentos de reconstruo em verses anteriores ao Oracle 9i chamado
de RBS (tablespace de rollback), possui a capacidade de recuperar
transaes 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 localizao dos dados e tambm os dados da forma
como se encontravam antes da modificao. Basicamente, os objetivos dos
segmentos de undo so:
Rollback de transao: Quando uma transao modifica uma linha de
uma tabela, a imagem original das colunas modificadas salvas no
segmento de undo, e se for feito o rollback da transao, o servidor
Oracle restaurar os valores originais gravando os valores do
segmento de undo novamente na linha.

Recuperao de Transao: Se ocorrer uma falha de instncia enquanto

houver transaes em andamento, o servidor Oracle precisar desfazer
as alteraes no submetidas commit quando o banco de dados for
aberto novamente. Esse rollback faz parte da recuperao da
transao. A recuperao s possvel porque as alteraes feitas
no segmento de undo tambm so protegidas pelos arquivos de redo log
online.

Consistncia de Leitura: Enquanto houver transaes em andamento,

outros usurios do banco de dados no devero ver as alteraes no
submetidas commit feitas nessas transaes. Alm disso, uma
instruo no dever ver as alteraes submetidas commit aps o
incio da execuo dessa instruo. Os valores antidos (dados de
undo) dos segmentos de undo tambm so usados para oferecer aos
leitores uma imagem consistente de uma instruo especfica.

O que o tablespace SYSAUX?

Este tablespace auxiliar no existe nas verses anteriores ao Oracle 10g e
foi criado especialmente para aliviar o tablespace SYSTEM de segmentos
associados a algumas aplicaes do prprio 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
criao desse tablespace, alguns gargalos de I/O freqentemente associados
ao tablespace SYSTEM foram reduzidos ou eliminados. Vale a pena salientar,
que o tablespace SYSAUX tambm no pode se colocado offline e parte
integrante obrigatrio em todos os bancos de dados a partir do Oracle 10g.
Existe uma view de dicionrio de dados que mostra os ocupantes neste
tablespace:

SQL> select occupant_name, schema_name, space_usage_kbytes

2 from v$sysaux_occupants;
OCCUPANT_NAME
--------------LOGMNR
LOGSTDBY
STREAMS
AO
XSOQHIST
SM/AWR
SM/ADVISOR
SM/OPTSTAT
SM/OTHER
STATSPACK
ODM
SDO
WM
ORDIM
ORDIM/PLUGINS
ORDIM/SQLMM
EM
TEXT
ULTRASEARCH
JOB_SCHEDULER

SCHEMA_NAME
SPACE_USAGE_KBYTES
-------------------- -----------------SYSTEM
7488
SYSTEM
0
SYS
192
SYS
960
SYS
960
SYS
68352
SYS
7360
SYS
21120
SYS
3328
PERFSTAT
0
DMSYS
5504
MDSYS
6080
WMSYS
6656
ORDSYS
512
ORDPLUGINS
0
SI_INFORMTN_SCHEMA
0
SYSMAN
61632
CTXSYS
4736
WKSYS
7296
SYS
256

Uma outra informao 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 Espao em Tablespaces

Os tablespaces alocam espao em extenses (extents). Eles podem ser
criados para usar um dos dois mtodos de controle de espao livre e
utilizado:
Tablespaces gerenciados localmente: As extenses so gerenciadas no
tablespace por bitmaps. Cada bitmap corresponde a um bloco ou a um
grupo de blocos. Quando uma extenso alocada ou liberada para
reutilizao, o servidor Oracle altera os valores do bitmap para
mostrar o novo status dos blocos. A partir do Oracle 9i este
gerenciamento local o padro.

Tablespaces gerenciados por dicionrio: As extenses so gerenciadas

pelo dicionrio de dados. O servidor atualiza as tabelas apropriadas
no dicionrio de dados sempre que uma extenso alocada ou
desalocada.

Nas verses anteriores ao Oracle 8i, os extents de todos os tablespaces

eram gerenciados centralmente por meio das tabelas do dicionrio de dados,
quando os extents so alocados ou desalocados em qualquer lugar do banco
de dados, o Oracle atualiza as tabelas do dicionrio 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
dicionrio de dados. Como dito anteriormente, o Oracle mantm um bitmap em
cada arquivo de dados de um tablespace gerenciado localmente. Para se
criar um tablespace gerenciado localmente, necessrio usar a clusula
EXTENT MANAGEMENT LOCAL como o comando create tablespace. Comparando com
os tablespaces gerenciados por dicionrio, os tablespaces gerenciados
localmente tm um modo completamente diferente de dimensionar os extents.
Os parmetros de armazenamento NEXT, PCTINCREASE, MINEXTENTS, MAXEXTENTS e
DEFAULT_STORAGE no so vlidos nos casos dos tablespaces gerenciados
localmente. Em vez disso, existe a opo 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
subseqentes.
Os
extents
uniformes
ou
dimensionados
automaticamente podem ser selecionados especificando as opes 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 espao eliminando a necessidade de vrias gravaes nas
tabelas do dicionrio de dados ou nos segmentos de rollback, o que ocorre
necessariamente quando o espao gerenciado centralmente por meio do
dicionrio de dados. Segundo a Oracle, os tablespaces gerenciados por
dicionrio no sero mais suportados nas futuras verses 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 dictionarymanaged tablespaces is scheduled for desupport."
Outra informao importante que um tablespace gerenciado por dicionrio
no 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: No possvel criar um tablespace gerenciado por
dicionrio
SQL> select extent_management
2 from dba_tablespaces
3 where tablespace_name='SYSTEM';
EXTENT_MANAGEMENT
----------------LOCAL
Postado por Eduardo Legatti s 08:37

12 comentrios:
Reginaldo Marcilon disse...
Ol, Eduardo. Eis mais um artigo bem escrito. Tenhos duas
dvidas sobre esse post:
1: Quantos segmentos so criados por grupo de dados? Ou
seja, por exemplo, quantos segmentos existem para tabelas?
Esse um nmero que varia de acordo com o que?
2: Acredito que houve um engano na nota de observao
quando, na ltima frase, voc escreveu: "Segundo a Oracle, os
tablespaces gerenciados localmente no sero mais suportados
nas futuras verses do Oracle". Acredito que o que no ser
mais suportado pela Oracle sero os tablespaces gerenciados
por dicionrio, no isso?
Grato pelo artigo.
12 de Maro de 2008 10:51

Eduardo Legatti disse...

Ol Reginaldo,
Muito obrigado por notar a minha falta de ateno ao
transcrever a nota da Oracle. O mesmo j foi corrigido no
artigo. J com relao a sua dvida, a no ser que uma tabela
seja particionada, ou seja, cada partio criada ter um
segmento correspondente, sempre uma tabela no particionada
ter apenas um nico segmento correspondente.

At mais.
12 de Maro de 2008 11:20

Annimo disse...
Eduardo, estou te fazendo uma pergunta que no tem nada a
ver com o tpico. Admiro seus posts e a clareza que explica os
cases. Estou estudando para a prova OCA e no estou
conseguindo colocar em prtica o que aprendi. Fao meus
backups hots pelo Rman e meu banco est no modo Arquivelog.
Imagine que minha partio /u02 onde estavam meus dados
deu crash. Meus backups esto armazenados em /u03. Como
fao com o restore e recover no rman? Se puder me dar uma
dica de uma fonte de estudo para me aprofundar mais nesta
ferramenta eu te agradeo. Depois que voc ler o coment e
fizer a gentileza de me ajudar, pode exclu-la para no sujar seu
blog, pois est no lugar errado...
Desde j agradeo.
Leandro.
13 de Maro de 2008 01:27

Eduardo Legatti disse...

Ol Leandro,
Se voc est estudando para obter a certificao OCA, ento
acho que neste momento voc no precisa se preocupar com
procedimentos de backup e recovery utilizando o RMAN, j que
o mesmo ser pedido nos exames para obteno da certificao
OCP. Se interessar, eu escrevi um artigo sobre certificao
Oracle no link Outubro/2007. Voc tambm pode acessar a
pgina da Oracle no link http://education.oracle.com e clicar no
link certificaes para maiores informaes. No mais, o RMAN
automatiza o procedimento de restaurao de arquivos. Quando
voc executa o comando RESTORE, o RMAN utiliza uma sesso
do servidor para restaurar as cpias e os backups corretos. Em
resumo. o RMAN utilizado para selecionar o melhor conjunto
de backup ou as melhores cpias-imagens a serem utilizadas
na restaurao. No sei se o seu caso, mas se por algum
motivo a unidade u02 est danificada, voc poder restaurar os
arquivos de dados em uma nova localizao usando o comando
SET NEWNAME em conjunto com o comando SWITCH. Por
padro, o comando RESTORE ir restaurar os arquivos em suas

localizaes padres. Quanto a informaes sobre o uso do

RMAN, voc sempre pode acessar o site de documentao da
Oracle http://tahiti.oracle.com/ e pesquisar no Google tambm
uma boa dica porque h centenas de artigos relacionados ao
uso dessa ferramenta.
At mais e obrigado pelos comentrios.
14 de Maro de 2008 02:07

Rina disse...
Caro Eduardo, procurando assunto sobre tablespaces encontrei
o Oracle Blog que por sinal muito bom. Gostaria, se possvel,
que vc me esclarecesse uma dvida. Exportei um usurio e
seus objetos do oracle 9i com tablespace default USERS. Estou
tentando importar agora para um novo banco 10g para
tablespace com outro nome e no consigo. A exportao foi
feita utilizando o usurio system com direitos de DBA.
18 de Maro de 2008 15:20

Eduardo Legatti disse...

Ol Rina,
Por padro, o Oracle sempre tentar importar os objetos para o
tablespace especificado no arquivo de exportao se o mesmo
existir no banco de dados de destino, seno ele importar para
o tablespace padro do usurio. Bom, como voc no reportou
nenhum erro, eu aconselho a voc remover o privilgio
UNLIMITED TABLESPACE para o usurio de destino (no Oracle
10g), revogar o privilgio para este usurio no tablespace
USERS com o comando ALTER USER [USER_10G] QUOTA 0 ON
USERS e conceder espao de cota neste tablespace que voc
criou para o usurio com o comando ALTER USER [USER_10g]
QUOTA UNLIMITED ON [NOVO_TABLESPACE]. No esquea de
definir este tablespace como o tablespace default para este
usurio. Aps isso, realize a importao com o comando
abaixo:
imp system/pass fromuser=[user_9i] touser=[user_10g]
At mais.
19 de Maro de 2008 01:56

Rina disse...

Ol Eduardo, sua dica sobre a importao de dados para uma

tablespace com outro nome para outro BD funcionou lindo.
Obrigado, e parabns pela competncia, seriedade e contedo
deste Blog.
Abrao
Rina
24 de Maro de 2008 14:59

Annimo disse...
OI, Muito Bom o Artigo! Gostaria de saber se posso ter
problemas uma vez que criei um datafile no aix com coluna
branca no nome. O banco muito Grande e o datafile j est
sendo usado ...
25 de Agosto de 2008 17:00

Eduardo Legatti disse...

Ol,
Se voc no teve problemas at agora, acredito que no ter
no futuro, mas realmente um arquivo "sem nome" ou "com
nome em branco" no legvel, bem estranho e foge a
qualquer regra e padro. No mais, no vejo problema se voc
renomear este arquivo. Se for o caso, faa um backup full antes
de qualquer alterao.
No mais, veja o exemplo abaixo:
Abaixo, irei adicionar um datafile com "nome em branco" ao
tablespace USERS.
SQL> alter tablespace users
2 add datafile '/u01/oradata/BD01/ '
3 size 1m;
Tablespace altered.
SQL> select file_name from
2 dba_data_files
3 where tablespace_name='USERS';
FILE_NAME
------------------------------------/u01/oradata/BD01/users01.dbf

/u01/oradata/BD01/
O resultado acima mostra um datafile "sem nome".
oracle@linux:\> ls -l
1056768 2008-08-26 10:14
31465472 2008-08-26 10:11 users01.dbf
Acima podemos ver que existe um arquivo "sem nome" com
tamanho de 1056768 bytes.
Abaixo irei renomear este arquivo de dados "sem nome" para
um nome legvel como por exemplo users02.dbf.
SQL> alter tablespace users offline;
Tablespace altered.
oracle@linux:/> cp -a ' ' users02.dbf
SQL> alter tablespace users
2 rename datafile
3 '/u01/oradata/BD01/ '
4 to
5 '/u01/oradata/BD01/users02.dbf';
Tablespace altered.
SQL> alter tablespace users online;
Tablespace altered.
Para finalizar, irei remover o arquivo "sem nome".
oracle@linux:/> rm ' '
SQL> select file_name from
2 dba_data_files
3 where tablespace_name='USERS';
FILE_NAME
------------------------------------/u01/oradata/BD01/users01.dbf
/u01/oradata/BD01/users02.dbf

At mais ...
26 de Agosto de 2008 08:41

Valter disse...
Muito Bom seu Artigo e seu Blog
Parabens !!!!
30 de Outubro de 2008 10:19

Rafael Yera Barchi disse...

Boa tarde, Eduardo.
Os seus artigos so muito bem redigidos, e apontam com
clareza e conciso todas as idias transmitidas. Parabns!
Sou novato em Oracle e gostaria de esclarecer uma dvida.
As tablespaces, como objetos lgicos de armazenamento,
possuem um tamanho diferente do tamanho real dos dados
nelas armazenados?
Pergunto isso porque tenho uma tablepace que est crescendo
vertiginosamente, sem que exista massa de dados que
justifique esse crescimento.
E, outra pergunta: caso o espao usado de uma tablespace v
se aproximando de 100% de seu tamanho, a nica alternativa
que tenho aumentar seu tamanho?
Grato pela ateno.
19 de Novembro de 2008 13:31

Eduardo Legatti disse...

Ol Rafael,
Primeiramente, obrigado pelo comentrio. Bom saber que voc
entendeu que o objetivo do tablespace agrupar os segmentos
de dados de forma coletiva. Agora com relao a resposta sua
pergunta, isso ir depender do que voc quer dizer com
"tamanho real" dos dados. Isso realmente depende, porque
imagine se criarmos um tablespace de 1 MB de tamanho (ou
seja, esse tablespace pode estar associado a apenas 1 arquivo
de dados de 1 MB ou 2 arquivos de dados cada um com 512
KB, etc ...) Agora imagine se criarmos uma tabela com uma

extenso inicial de 900 KB. Isso significaria alocar praticamente

todo o espao disponvel no tablespace para uma tabela que
nem sequer contm um nico registro. Portanto, neste caso,
acredito que a resposta para sua pergunta seria SIM.
Tem tambm o caso na qual poderamos deletar todos os
registros de uma tabela (por exemplo 1.000.000 de registros) e
ainda assim o espao utilizado no seria desalocado pelo fato
da HWM (High Water Mark) no ter sido resetada. Neste caso, o
espao seria desalocado se tivssemos truncado a tabela
(TRUNCATE TABLE ...), ou dropado a tabela (DROP TABLE ...),
ou at mesmo compactado a tabela (a partir do Oracle 10g com
o comando ALTER TABLE ... SHRINK SPACE), entre outras
opes.
Com relao sua segunda pergunta, voc tem vrias
alternativas:
1) Redimensionar o tamanho do arquivo de dados pertencente
ao tablespace
2) Adicionar mais arquivos de dados ao tablespace
3) Configurar a opo AUTOEXTEND do arquivo de dados para
que no seja necessrio redimension-lo manualmente
4) Organizar o tablespace
Com relao alternativa 4 e em geral sua dvida, eu
recomendo que voc leia tambm o artigo Reorganizando o
Tablespace de Junho de 2008.