Para melhor visualização, recomendo resolução de no mínimo 1280 x 800 e navegador Mozilla Firefox


segunda-feira, 10 de março de 2008

Introdução ao conceito de Tablespaces no Oracle

Por Eduardo Legatti

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
 



35 comentários:

Reginaldo Marcilon disse...

Olá, Eduardo. Eis mais um artigo bem escrito. Tenhos duas dúvidas sobre esse post:

1: Quantos segmentos são criados por grupo de dados? Ou seja, por exemplo, quantos segmentos existem para tabelas? Esse é um número que varia de acordo com o que?

2: Acredito que houve um engano na nota de observação quando, na última frase, você escreveu: "Segundo a Oracle, os tablespaces gerenciados localmente não serão mais suportados nas futuras versões do Oracle". Acredito que o que não será mais suportado pela Oracle serão os tablespaces gerenciados por dicionário, não é isso?

Grato pelo artigo.

Eduardo Legatti disse...

Olá Reginaldo,

Muito obrigado por notar a minha falta de atenção ao transcrever a nota da Oracle. O mesmo já foi corrigido no artigo. Já com relação a sua dúvida, a não ser que uma tabela seja particionada, ou seja, cada partição criada terá um segmento correspondente, sempre uma tabela não particionada terá apenas um único segmento correspondente.

Até mais.

Anônimo disse...

Eduardo, estou te fazendo uma pergunta que não tem nada a ver com o tópico. Admiro seus posts e a clareza que explica os cases. Estou estudando para a prova OCA e não estou conseguindo colocar em prática o que aprendi. Faço meus backups hots pelo Rman e meu banco está no modo Arquivelog. Imagine que minha partição /u02 onde estavam meus dados deu crash. Meus backups estão armazenados em /u03. Como faço 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 agradeço. Depois que você ler o coment e fizer a gentileza de me ajudar, pode excluí-la para não sujar seu blog, pois está no lugar errado...

Desde já agradeço.

Leandro.

Eduardo Legatti disse...

Olá Leandro,

Se você está estudando para obter a certificação OCA, então acho que neste momento você não precisa se preocupar com procedimentos de backup e recovery utilizando o RMAN, já que o mesmo será pedido nos exames para obtenção da certificação OCP. Se interessar, eu escrevi um artigo sobre certificação Oracle no link Outubro/2007. Você também pode acessar a página da Oracle no link http://education.oracle.com e clicar no link certificações para maiores informações. No mais, o RMAN automatiza o procedimento de restauração de arquivos. Quando você executa o comando RESTORE, o RMAN utiliza uma sessão do servidor para restaurar as cópias e os backups corretos. Em resumo. o RMAN é utilizado para selecionar o melhor conjunto de backup ou as melhores cópias-imagens a serem utilizadas na restauração. Não 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 localização usando o comando SET NEWNAME em conjunto com o comando SWITCH. Por padrão, o comando RESTORE irá restaurar os arquivos em suas localizações padrões. Quanto a informações sobre o uso do RMAN, você sempre pode acessar o site de documentação da Oracle http://tahiti.oracle.com/ e pesquisar no Google também é uma boa dica porque há centenas de artigos relacionados ao uso dessa ferramenta.

Até mais e obrigado pelos comentários.

Sistema de Gestão ERP disse...

Caro Eduardo, procurando assunto sobre tablespaces encontrei o Oracle Blog que por sinal é muito bom. Gostaria, se possível, que vc me esclarecesse uma dúvida. Exportei um usuário 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 não consigo. A exportação foi feita utilizando o usuário system com direitos de DBA.

Eduardo Legatti disse...

Olá Rina,

Por padrão, o Oracle sempre tentará importar os objetos para o tablespace especificado no arquivo de exportação se o mesmo existir no banco de dados de destino, senão ele importará para o tablespace padrão do usuário. Bom, como você não reportou nenhum erro, eu aconselho a você remover o privilégio UNLIMITED TABLESPACE para o usuário de destino (no Oracle 10g), revogar o privilégio para este usuário no tablespace USERS com o comando ALTER USER [USER_10G] QUOTA 0 ON USERS e conceder espaço de cota neste tablespace que você criou para o usuário com o comando ALTER USER [USER_10g] QUOTA UNLIMITED ON [NOVO_TABLESPACE]. Não esqueça de definir este tablespace como o tablespace default para este usuário. Após isso, realize a importação com o comando abaixo:

imp system/pass fromuser=[user_9i] touser=[user_10g]

Até mais.

Sistema de Gestão ERP disse...

Olá Eduardo, sua dica sobre a importação de dados para uma tablespace com outro nome para outro BD funcionou lindo. Obrigado, e parabéns pela competência, seriedade e conteúdo deste Blog.
Abraço

Rina

Anônimo 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 ...

Eduardo Legatti disse...

Olá,

Se você não teve problemas até agora, acredito que não terá no futuro, mas realmente um arquivo "sem nome" ou "com nome em branco" não é legível, é bem estranho e foge a qualquer regra e padrão. No mais, não vejo problema se você renomear este arquivo. Se for o caso, faça um backup full antes de qualquer alteração.

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 legível 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 ...

Unknown disse...

Muito Bom seu Artigo e seu Blog

Parabens !!!!

Rafael Yera Barchi disse...

Boa tarde, Eduardo.

Os seus artigos são muito bem redigidos, e apontam com clareza e concisão todas as idéias transmitidas. Parabéns!

Sou novato em Oracle e gostaria de esclarecer uma dúvida.
As tablespaces, como objetos lógicos 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 espaço usado de uma tablespace vá se aproximando de 100% de seu tamanho, a única alternativa que tenho é aumentar seu tamanho?

Grato pela atenção.

Eduardo Legatti disse...

Olá Rafael,

Primeiramente, obrigado pelo comentário. Bom saber que você entendeu que o objetivo do tablespace é agrupar os segmentos de dados de forma coletiva. Agora com relação 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 extensão inicial de 900 KB. Isso significaria alocar praticamente todo o espaço disponível no tablespace para uma tabela que nem sequer contém um único registro. Portanto, neste caso, acredito que a resposta para sua pergunta seria SIM.

Tem também o caso na qual poderíamos deletar todos os registros de uma tabela (por exemplo 1.000.000 de registros) e ainda assim o espaço utilizado não seria desalocado pelo fato da HWM (High Water Mark) não ter sido resetada. Neste caso, o espaço seria desalocado se tivéssemos 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 opções.

Com relação à sua segunda pergunta, você tem várias alternativas:

1) Redimensionar o tamanho do arquivo de dados pertencente ao tablespace
2) Adicionar mais arquivos de dados ao tablespace
3) Configurar a opção AUTOEXTEND do arquivo de dados para que não seja necessário redimensioná-lo manualmente
4) Organizar o tablespace

Com relação à alternativa 4 e em geral à sua dúvida, eu recomendo que você leia também o artigo Reorganizando o Tablespace de Junho de 2008.

Até mais ...

Unknown disse...

Excelente artigo, muito bem escrito !!!!
Parabéns Eduardo

Roberto disse...

Parabéns pelo artigo.

Unknown disse...

Olá, Eduardo.

Bom estou com uma duvida, quando apago dados das tabelas de uma tablespace o percentual de uso da tablespace vai diminuir ou continua o mesmo?

Eduardo Legatti disse...

Olá Carlos,

Defina "apagar" neste contexto. Os blocos utilizados pelas linhas deletadas (através do comando DELETE) não são desalocados, isso porque que a HWM (High Water Mark) não é ajustada por comandos DML. Portanto, os blocos ainda fazem parte das extensões pertencentes aos segmentos (tabelas) em questão. Já os comandos DDL (DROP e TRUNCATE) irão desalocar este espaço e por conseqüência irão afetar o percentual de uso na tablespace. Se ainda estiver com dúvidas, recomendo a você dar uma lida no artigo Reorganizando o Tablespace ...

Abraços e até mais ...

Reiner disse...

Boa Noite Eduardo!
Essa postagem para explicação de tablespace ficou show de bola!!!
Mas eu tava estudando aqui e vi que no meu máteria mencionou sobre uma tablespace EXAMPLE....
Essa tablespace não é muito usada, por isso vc não fez comentário sobre ela?
PS: Estou consultando também o seu blog para preparação da prova de OCA.
Obrigado.

Eduardo Legatti disse...

Olá Reiner,

De fato, essa tablespace contém schemas de exemplo, normalmente utilizados em cursos oficiais da Oracle, mas ela não é uma tablespace essencial, daí o fato de eu não ter mencionado ela no artigo ;-)

Abraços, bons estudos e sucesso no seu exame ...

Anônimo disse...

Thanks Eduardo Legatti for your blog. I find your blog very useful; you have a great ability to explain your large knowledge.
However, about this article, I have a question. You say that SYSAUX tablespace can't be taken offline.But I have installed Oracle Database 10g Enterprise Edition version 10.2.0.3.0 , and I have been able to take SYSAUX tablespace offline.So, wasn't it a typo when you wrote that SYSAUX tablespace can't be taken offline?
Thanks.

Eduardo Legatti disse...

Hello Anonymous,

Yes. you right. In fact, we cannot drop/rename SYSAUX tablespace, but we can take it offline. I will correct this information. But remember that if you make the SYSAUX tablespace offline, then you will not be able to use some features that uses this tablespace because the SYSAUX tablespace is an auxiliary tablespace of the SYSTEM tablespace. In other words, your database maybe will not work properly with SYSAUX tablespace offline. The documentation says: If the SYSAUX tablespace is unavailable, such as due to a media failure, then some database features might fail.

Thank you for the information.

Sidney França disse...

Parabéns pelo blog Eduardo, muito bem escrito e muito didáticos seus exemplos. Estou começando a estudar Oracle e seu artigo me ajudou bastante a entender melhor esse assunto. Obrigado e Parabéns!

Eduardo Legatti disse...

Olá Sidney,

Obrigado pela visita e bons estudos

Abraços e até mais ...

Fábio Prado disse...

Eduardo, ótimo artigo, vou compartilhar com meus alunos!

[]s
Fábio Prado
www.fabioprado.net

Juliano Ramalho disse...

Olá Eduardo. Parabéns, seu blog é fantástico assim como sua didática. Sou novato na área de DB (somente na área (rs), estou "migrando" da de infraestrutura de redes) e realmente posso afirmar que seus posts estão ajudando-me muito nos estudos para certificação OCA. Caso tenha oportunidade de visitar e opinar o blog (http://julianoramalho.blospot.com.br)que criei recentemente, como forma de fixar os assuntos estudados, seria uma honra. Grande abraço. juliano Ramalho.

Eduardo Legatti disse...

Olá Juliano,

Obrigado pela visita, parabéns pelo seu blog e sucesso nessa sua nova empreitada! ;-)

Abraços

Legatti

Anônimo disse...

Olá Eduardo td bem? Gostaria de saber se há integridade referencial entre 2 tabelas armazendas em tablespaces diferentes, dese já obrigado

Eduardo Legatti disse...

Olá Anônimo,

Se eu entendi bem, você que saber se é possível criar integridades referenciais (Fks) entre tabelas que estão em tablespaces diferentes? Atenção! Não há qualquer relação entre integridades referenciais (foreign keys) e tablespaces. Lembre-se que as Fks são dependentes de tabelas, e não das tablespaces em que as tabelas estão armazenadas.

Abraços e até mais...

Legatti

Mr. Gonçalves disse...

Ola, Eduardo!
Parabéns pelo seus artigo, está me ajudando muito nessa estrada...

Gostaria de pedir umas dicas. Estou criando meu primeiro cenário para um projeto. Já modelei o DER e já foi aceito. A aplicação será feita em java.
Antes percebia que tudo era feito usando os padrões do Oracle e agora quero fazer algo mais organizado, portanto estes são os passos corretos:
1)Criar tablespace;
2)Criar user para essa tablespace;
3)Dai que crio as tabelas;
4)E gero as permissões e crio os sinônimos.
É mais ou menos assim?

Os objetos funções e procedures eu também devo associar a uma determinada tablespace?

Obrigado desde já.

Eduardo Legatti disse...

Olá Gonçalves,

A tablespace você cria para armazenar segmentos como tabelas e índices. Objetos PL/SQL como funções, procedures e triggers ficam armazenados em outros locais, especificamente em tabelas do dicionários de dados do Oracle. Não se preocupe com esse objetos. Lembre-se que a tablespace é apenas um repositório para as suas tabelas. Você está falando em permissões (grants) e criação de sinônimos. Isso só fará sentido se a sua aplicação acessar o banco de de dados por um usuário que não é o usuário owner (dono) dos objetos (tabelas, procedures, funções, etc...) veja o exemplo abaixo:

Por padrão, já existe no Oracle uma tablespace chamada USERS. Imagine que você crie um usuário chamado SISTEMA que tem como tablespace default a tablespace USERS. Então, quando você criar uma tabela, ela automaticamente será criada na tablespace USERS.

exemplo:

create table SISTEMA.T1 (ID NUMBER);

O seu aplicativo poderá se conectar diretamente com o usuário SISTEMA. Caso você não queira que o seu aplicativo acesse diretamente o usuário SISTEMA, então você poderá criar um outro usuário, como por exemplo SISTEMA_ACESSO na qual ele terá os privilégios necessários para acessar os objetos do usuário SISTEMA.

exemplo:

grant select,insert,delete,update on SISTEMA.T1 to SISTEMA_ACESSO

Como o usuário SISTEMA_ACESSO não é o dono da tabela T1, se você tentar executar SELECT * FROM T1 você vai receber um erro de que a tabela não existe. Nesse caso será necessário qualificar o objeto com o owner (dono) do mesmo: SELECT * FROM SISTEMA.T1 Para evitar essa qualificação, você poderá criar um objeto sinônimo para a tabela T1 no usuário SISTEMA_ACESSO como abaixo:

create synonym SISTEMA_ACESSO.T1 for SISTEMA.T1

Abraços e até mais ...

Legatti

Unknown disse...

Olá Eduardo tudo bem, primeiramente quero elogiar o seu blog por que tem dicas essênciais para vida dos DBAs.
Gostaria de saber se você pode me esclarecer uma duvida?
Seria correto criar tabelas, utilizando o tablespace padrão da Oracle que é o "USER"?

Eduardo Legatti disse...

Olá Brunno,

Depende do que cada DBA define como correto ou não. A tablespace USERS existe e pode ser definida como tablespace padrão de um usuário ou não. Tudo depende do DBA que está administrando o banco de dados. Independente da tablespace USERS, particularmente, não me agrada ter uma tablespace compartilhada entre várias tabelas de aplicações diferentes. Se você ler o artigo

http://eduardolegatti.blogspot.com.br/2010/03/database-point-in-time-recovery-dbpitr.html

irá entender o que eu estou falando ;-)

Abraços e até mais

Legatti

Unknown disse...

Olá Eduardo, tudo bem?

Primeiramente parabéns pelo blog, seus artigos são excelentes e eles tem me ajudado bastante na minha carreira como DBA.

Estou começando um blog sobre Oracle para registrar meu aprendizado, evolução e compartilhar conhecimento com outros usuários.

Um dos meus primeiros posts será sobre tablespace e datafile (introdução, gerenciamento e boas práticas) e vendo seu artigo gostei bastante de alguns trechos, como por exemplo, sua descrição sobre as tablespaces básicas criadas na instalação do Oracle.

Gostaria de saber se eu poderia reproduzir algumas das suas explicações no meu blog? Colocarei suas referências no final do meu post.

Meu blog é britodba.wordpress.com caso queira verificar depois o post.

Parabéns pelo seu blog novamente.

Abs,

Philipe Brito

Eduardo Legatti disse...

Olá Philipe,

Colocando as referências, sem problemas. ;-)

Abraços,

Legatti

Carlos_Magno disse...

Oi Legatti,
Você acha que ocorre degradação (queda de performance) ao usar big tablespace com opção de autoextend ?ou Seria mais performático usar tablespace padrão sem autoextend  neste caso criando vários datafiles de 32GB e o gerenciamento do crescimento ficando por conta do DBA ?



Obrigado pela atenção.
att.
Carlos Magno

Eduardo Legatti disse...

Olá Carlos,

A degradação pode ocorrer quando o autoextend é acionado a todo momento em um curto espaço de tempo. O ideal é configurar o autoextend de acordo com o crescimento da tablespace em questão. Por exemplo, estender 500MB em vez de 50MB. Vai depender de cada tablespace. Quanto às Big tablespaces, não sou muito fã delas porque elas só podem conter um datafile, ou seja, não conseguimos escalar em outros discos caso necessário. Por isso prefiro tablespace padrão mesmo com o autoextend de cada datafile configurado de acordo com o histórico de crescimento dos mesmos: um valor não muito baixo e nem muito alto. Vai depender.

Postagens populares