Introduo ao conceito de Tablespaces

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 inter-relacionados, 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 clienteNome Nulo? Tipo----------------------------- -------- --------------------COD_CLIENTE NOT NULL NUMBERNOME NOT NULL VARCHAR2(60)ENDERECO NOT NULL VARCHAR2(100)TELEFONE NUMBERDATA_CADASTRO 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 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 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 SCHEMA_NAME SPACE_USAGE_KBYTES--------------- -------------------- ------------------LOGMNR SYSTEM 7488LOGSTDBY SYSTEM 0STREAMS SYS 192AO SYS 960XSOQHIST SYS 960SM/AWR SYS 68352SM/ADVISOR SYS 7360SM/OPTSTAT SYS 21120SM/OTHER SYS 3328STATSPACK PERFSTAT 0ODM DMSYS 5504SDO MDSYS 6080WM WMSYS 6656ORDIM ORDSYS 512ORDIM/PLUGINS ORDPLUGINS 0ORDIM/SQLMM SI_INFORMTN_SCHEMA 0EM SYSMAN 61632TEXT CTXSYS 4736ULTRASEARCH WKSYS 7296JOB_SCHEDULER 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 TablespacesOs 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 dictionary-managed 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 users2 add datafile '/u01/oradata/BD01/ '3 size 1m;

Tablespace altered.

SQL> select file_name from2 dba_data_files3 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:1431465472 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 users2 rename datafile3 '/u01/oradata/BD01/ '4 to5 '/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 from2 dba_data_files3 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 tablespace2) Adicionar mais arquivos de dados ao tablespace3) Configurar a opo AUTOEXTEND do arquivo de dados para que no seja necessrio redimension-lo manualmente4) 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.