Lançado o Oracle SQL Developer Data Modeling ...

Olá,

Acabei de fazer o download do OSDM para ver como o mesmo funciona. Para quem ainda não o conhece, recentemente a Oracle lançou o Oracle SQL Developer Data Modeling (OSDM) que é uma ferramenta gráfica para modelagem de dados. Essa ferramenta utiliza a mesma interface do já conhecido Oracle SQL Developer. Segundo a equipe que desenvolveu a ferramenta, a idéia por trás da mesma é a de facilitar e melhorar a comunicação entre arquitetos e administradores de dados, DBAs, desenvolvedores de aplicações e usuários, de forma a simplificar o processo de modelagem de dados como um todo.

Pelo que estou vendo, além de realizar engenharia reversa de base de dados Oracle (versão 9.2.0.1 e posteriores), o mesmo oferece suporte para bancos de dados IBM DB2, IBM UDB, Microsoft SQL Server e suporte para drivers JDBC e ODBC. Existe também a opção de realizar importação de arquivos SQL que contenham comandos DDL de criação dos objetos.

O OSDM compreende três camadas que podem trabalhar de forma sincronizada: um modelo lógico, um modelo relacional, e um modelos físico. Bem, acho que vale a pena conferir ...

No mais, para poder baixar o software, será necessário responder a um pequeno questionário.

* Demonstração online - Engenharia Reversa

Coluna do tipo auto-incremento no Oracle? Abordando o uso de sequências no Oracle...

Olá,

Realmente, o Oracle não possui um tipo de dado "auto-incremento" como podemos ver em alguns outros bancos de dados. Por exemplo, no caso do PostgreSQL existe um tipo de dado SERIAL que, na verdade, implementa números seqüenciais através de um objeto SEQUENCE. A diferença é que o PostgreSQL permite definir esta seqüência (sequence) utilizando a cláusula DEFAULT da coluna em questão. Já no Oracle, infelizmente "ainda" o mesmo não permite definir um objeto seqüência na cláusula DEFAULT da coluna como demonstrado abaixo:

SCOTT> create sequence seq_teste nocache;

Seqüência criada.

SCOTT> desc minha_tabela
 Nome                                      Nulo?    Tipo
 ----------------------------------------- -------- ----------------------------
 ID                                        NOT NULL NUMBER
 DESCRICAO                                 NOT NULL VARCHAR2(100)

SCOTT> alter table minha_tabela modify id default seq_teste.nextval;
alter table emp modify id default seq_emp_id.nextval
*
ERRO na linha 1:
ORA-00984: coluna não permitida aqui 

Neste caso teremos que criar uma trigger de banco de dados para realizar esta operação. Portanto, neste artigo irei fazer uma breve introdução sobre o objeto SEQUENCE, além de demonstrar através de um exemplo prático como poderemos criar um campo do tipo "auto-incremento" utilizando seqüências de banco de dados.

Antes de começar a falar sobre o objeto SEQUENCE, irei demonstrar como gerar valores seqüenciais sem a necessidade de ter que criar uma SEQUENCE de banco de dados.

-- Irei criar uma tabela para teste
SCOTT> create table emp (
  2    id number constraint pk_emp primary key,
  3    nome varchar2(60) not null);

Tabela criada.

SCOTT> insert into emp (id,nome) select nvl(max(id),0)+1,'MARIA' from emp;

1 linha criada.

SCOTT> select * from emp;

        ID NOME
---------- ------------------------------------------------------------
         1 MARIA

SCOTT> insert into emp (id,nome) select nvl(max(id),0)+1,'REGINA' from emp;

1 linha criada.

SCOTT> select * from emp;

        ID NOME
---------- ------------------------------------------------------------
         1 MARIA
         2 REGINA

Podemos ver acima, que é simples gerar dados seqüências através de um comando INSERT, mas este método funcionaria perfeitamente apenas para sistemas monousuários. Se o sistema for para acesso multiusuário, aí este método não é recomendável. Bem, como eu ainda não finalizei a transação acima com (COMMIT ou ROLLBACK), o que acontecerá se eu abrir uma nova seção de banco de dados e executar o mesmo comando INSERT?

SESSÃO 2

SCOTT> insert into emp (id,nome) select nvl(max(id),0)+1,'EDUARDO' from emp;
[Aguardando...]

Podemos perceber que a sessão acima está aguardando a finalização da transação iniciada pela SESSAO 1, já que o registro na tabela EMP foi locado pela mesma. Abaixo irei retornar para a SESSAO 1 e finalizar a transação com COMMIT:

SESSÃO 1

SCOTT> commit;

Commit concluído.

Ao retornar para a SESSAO 2 mostrada abaixo, podemos perceber que houve uma violação de chave primária na tabela EMP.

SESSÃO 2

SCOTT> insert into emp (id,nome) select nvl(max(id),0)+1,'EDUARDO' from emp;
insert into emp (id,nome) select nvl(max(id),0)+1,'EDUARDO' from emp
*
ERRO na linha 1: 
ORA-00001: restrição exclusiva (SCOTT.PK_EMP) violada 

Isto aconteceu pelo fato de a SESSAO 2 não ter conhecimento da transação concorrente iniciada pela SESSAO 1. Isto se refere à propriedade I (ISOLAMENTO) de um termo conhecido como ACID, na qual todos os bancos de dados relacionais devem atender:

* ATOMICIDADE - Tudo (commit) ou nada (rollback)
* CONSISTÊNCIA - Sem violação de restrições de integridade
* ISOLAMENTO - Alterações concorrentes invisíveis
* DURABILIDADE - Persistência das atualizações confirmadas

Embora diversas transações possam ser executadas de forma concorrente, o sistema gerenciador de banco de dados deve garantir a consistência de leitura. É aí que entram em ação os segmentos de rollback ou UNDO...

-- Limpando a tabela EMP
SCOTT> truncate table emp;

Tabela truncada.

Após a demonstração acima, irei realizar abaixo uma introdução breve sobre uso do objeto SEQUENCE disponível no banco de dados Oracle.

Então, o que é um objeto seqüência? Uma seqüência (sequence) é um objeto de banco de dados criado pelo usuário que pode ser compartilhado por vários usuários para gerar números inteiros exclusivos de acordo com regras especificadas no momento que a seqüência é criada. A seqüência é gerada e incrementada (ou diminuída) por uma rotina interna do Oracle. Normalmente, as seqüências são usadas para criar um valor de chave primária que deve ser exclusivo para cada linha de uma tabela.

Vale a pena salientar que os números de seqüências são armazenados e gerados de modo independente das tabelas. Portanto, o mesmo objeto seqüência pode ser usado por várias tabelas e inclusive por vários usuários de banco de dados caso necessário. Geralmente, convém atribuir à seqüência um nome de acordo com o uso a que se destina; no entanto, ela poderá ser utilizada em qualquer lugar, independente do nome.

No mais, se você só precisa da chave para garantir a singularidade não se importando em criar uma chave com nome sem muito sentido, então é perfeitamente apropriado fazê-lo se utilizando de seqüências. As seqüências são criadas com o comando CREATE SEQUENCE ... na qual poderemos nos utilizar de algumas cláusulas durante a sua criação.

As cláusulas mais importantes são:

• start with n - Permite especificar o primeiro valor a ser gerado pela seqüência. Uma vez criada, a seqüência irá gerar o valor especificado por start with na primeira vez que a coluna virtual NEXTVAL da seqüência for referenciada. Se nenhum valor start with for especificado, então a seqüência assumirá o valor padrão 1.
  

• increment by n - Define o número a ser incrementado cada vez que a coluna virtual NEXTVAL for referenciada. O valor padrão para esta coluna é 1, se não for explicitamente especificado. Você pode definir (n) com um valor positivo para seqüências crescentes, ou com um valor negativo para seqüências decrescentes de forma a gerar valores regressivos.
  

• minvalue n - Define o valor mínimo que pode ser produzido pela seqüência. Se nenhum valor mínimo for especificado, o Oracle irá assumir o padrão nominvalue 1 para uma seqüência crescente e (10^27) para uma seqüência decrescente.
  

• maxvalue n - Define o valor máximo que pode ser produzido pela seqüência. Se nenhum valor máximo for especificado, o Oracle irá assumir o padrão nomaxvalue (10^27) para uma seqüência crescente e 1 para uma seqüência decrescente.
  

• cycle - Especifica se a seqüência continuará a gerar valores após alcançar seu valor máximo ou mínimo. Se esta cláusula não for especificada explicitamente, o Oracle irá assumir o valor padrão nocycle. Você não pode especificar cycle em conjunto com nomaxvalue ou nominvalue. Se você quiser que sua seqüência use um ciclo, você deverá especificar maxvalue para seqüências crescentes, ou minvalue para seqüências decrescentes.
  

• cache n - Especifica quantos valores o servidor Oracle alocará previamente na memória (SGA). O uso desta cláusula permite à seqüência gerar antecipadamente um número especificado de valores, usando um cache para melhorar o desempenho. Se o cache não for especificado explicitamente, o Oracle irá assumir o padrão, que é de gerar um cache de 20 valores.
  

Obs: Não use a opção CYCLE se a seqüência for utilizada para gerar valores de chave primária, a menos que você tenha um mecanismo confiável que expurgue linhas mais rapidamente que os ciclos da seqüência.

Considere agora um exemplo de definição de seqüências. Como dito anteriormente, os números inteiros que podem ser especificados para seqüências, podem ser tanto negativos quanto positivos. O exemplo abaixo usa uma seqüência decrescente onde o número inteiro de start with é positivo, mas o número inteiro de increment by é negativo, o que na prática diz à seqüência para decrescer, ao invés de crescer. Quando o valor zero for atingido, a seqüência começará novamente a contagem.

SCOTT> create sequence seq_decrescente_5
  2  start with 5
  3  increment by -1
  4  maxvalue 5
  5  minvalue 0
  6  nocache
  7  cycle;

Seqüência criada.

Uma vez criada a seqüência, ela poderá ser utilizada usando-se como referência as pseudo-colunas CURRVAL e NEXTVAL. Os usuários do banco de dados podem visualizar o valor atual da seqüência usando um comando SELECT. Da mesma forma, o próximo valor da seqüência pode ser gerado com um comando SELECT. Podemos ver abaixo como a seqüência SEQ_DECRESCENTE_5 faz um ciclo quando o valor de minvalue é atingido:

SCOTT> select seq_decrescente_5.nextval from dual;

   NEXTVAL
----------
         5

SCOTT> /

   NEXTVAL
----------
         4

SCOTT> /

   NEXTVAL
----------
         3

SCOTT> /

   NEXTVAL
----------
         2

SCOTT> /

   NEXTVAL
----------
         1

SCOTT> /

   NEXTVAL
----------
         0

SCOTT> /

   NEXTVAL
----------
         5

Uma vez referenciada a pseudo-coluna NEXTVAL, o valor em CURRVAL é atualizado para bater com o valor de NEXTVAL, e o valor anterior em CURRVAL é descartado:

SCOTT> select seq_decrescente_5.currval from dual;

   CURRVAL
----------
         5

SCOTT> select seq_decrescente_5.nextval from dual;

   NEXTVAL
----------
         4

SCOTT> select seq_decrescente_5.currval from dual;

   CURRVAL
----------
         4

SCOTT> exit
Desconectado de Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production

Podemos perceber então que a pseudo-coluna NEXTVAL é usada para extrair números sucessivos de uma seqüência especificada. Será sempre necessário qualificar NEXTVAL com o nome da seqüência. Quando fazemos referência à NEXTVAL, um novo número de seqüência é gerado e o número de seqüência atual é colocado em CURRVAL. Vale a pena salientar que a pseudo-coluna CURRVAL é usada para fazer referência a um número de seqüência que a sessão do usuário atual acabou de gerar. Portanto, NEXTVAL deve ser usada para gerar um número de seqüência na sessão do usuário atual antes que seja feita referência a CURRVAL, caso contrário, o erro abaixo será emitido:

C:\>sqlplus scott/tiger

SQL*Plus: Release 10.2.0.1.0 - Production on Seg Nov 3 15:39:28 2008

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

Conectado a:
Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production

SCOTT> select seq_decrescente.currval from dual;
select seq_decrescente.currval from dual
*
ERRO na linha 1:
ORA-08002: a seqüência SEQ_DECRESCENTE.CURRVAL ainda não foi definido nesta sessão 

Quer dizer que se quisermos verificar o último valor de seqüência gerado, sempre teremos que inicializar a seqüência incrementado seu valor através da paseudo-coluna NEXTVAL? Não necessariamente. Caso tenhamos criado uma seqüência com a opção NOCACHE, poderemos verificar de forma precisa, qual foi o último valor de seqüência gerado e qual será o próximo valor a ser gerado, verificando o valor da coluna LAST_NUMBER nas views de dicionário de dados DBA/ALL/USER_SEQUENCES. Uma vez criada, a seqüência é documentada no dicionário de dados. Já que uma seqüência é um objeto de banco de dados, poderemos identificá-la nas views de dicionário de dados DBA/ALL/USER_OBJETCS, como também ver as definições da mesma nas views DBA/ALL/USER_SEQUENCES. O exemplo abaixo demonstra a diferença de utilizar a opção CACHE e NOCACHE:

SCOTT> create sequence seq_cache;

Seqüência criada.

SCOTT> create sequence seq_nocache nocache;

Seqüência criada.

SCOTT> select seq_cache.nextval from dual;

   NEXTVAL
----------
         1

SCOTT> /

   NEXTVAL
----------
         2

SCOTT> select seq_nocache.nextval from dual;

   NEXTVAL
----------
         1

SCOTT> /

   NEXTVAL
----------
         2

SCOTT> select * from user_sequences;

SEQUENCE_NAME            MIN_VALUE  MAX_VALUE INCREMENT_BY C O CACHE_SIZE LAST_NUMBER
----------------------- ---------- ---------- ------------ - - ---------- -----------
SEQ_CACHE                        1 1,0000E+27            1 N N         20          21
SEQ_NOCACHE                      1 1,0000E+27            1 N N          0           3

Consultado a view de dicionário de dados USER_SEQUENCES, podemos ver acima que a seqüência SEQ_CACHE não nos mostra de forma precisa através da coluna LAST_NUMBER qual foi o último valor de seqüência gerado pela mesma, pelo fato destes valores estarem em uma cache de memória na SGA (System Global Area). Na verdade, o cache é preenchido na primeira vez que fazemos referência à seqüência. Cada solicitação de próximo valor é recuperada da seqüência neste cache. Depois que o último valor é usado, a próxima solicitação da seqüência armazena outro cache de seqüências na memória.

Já a seqüência SEQ_NOCACHE nos mostra de forma precisa através da coluna LAST_NUMBER que o próximo valor de seqüência a ser gerado será 3, nos indicando que o último valor gerado foi 2. Portanto, a coluna LAST_NUMBER exibirá o próximo número de seqüência disponível apenas se NOCACHE for especificado durante a criação de uma seqüência.

Embora os geradores se seqüência emitam números de seqüência sem intervalos, essa ação ocorre independente de um COMMIT ou ROLLBACK. Portanto, se nós fizermos o rollback de uma instrução que contenha uma seqüência, o número será perdido. Outro evento que pode causar intervalos na seqüência é uma falha no sistema. Se a seqüência colocar valores no cache de memória, esses valores serão perdidos em caso de falha do sistema.

Irei abaixo criar uma seqüência de modo a demonstrar como podemos utilizá-la em um comando SQL.

SCOTT> create sequence seq_emp_id nocache;

Seqüência criada.

SCOTT> insert into emp values (seq_emp_id.nextval,'ROBERTO');

1 linha criada.

SCOTT> insert into emp values (seq_emp_id.nextval,'LAURA');

1 linha criada.

SCOTT> insert into emp values (seq_emp_id.nextval,'GUSTAVO');

1 linha criada.

SCOTT> select * from emp;

        ID NOME
---------- ------------------------------------------------------------
         1 ROBERTO
         2 LAURA
         3 GUSTAVO

-- Verificando o valor de LAST_NUMBER
SCOTT> select * from user_sequences;

SEQUENCE_NAME           MIN_VALUE  MAX_VALUE INCREMENT_BY C O CACHE_SIZE LAST_NUMBER
---------------------- ---------- ---------- ------------ - - ---------- -----------
SEQ_EMP_ID                      1 1,0000E+27            1 N N          0           4

Após toda essa demonstração, irei agora criar uma trigger de banco de dados (Before Insert) na tabela EMP de forma que a coluna ID tenha seus valores gerados de forma automática (simulando um tipo de dado auto-incremento) ao inserir dados na mesma.

-- Criando a trigger de banco de dados
SCOTT> create or replace trigger gera_emp_id
  2  before insert on emp
  3  for each row
  4  begin
  5   select seq_emp_id.nextval into :new.id from dual;
  6  end;
  7  /

Gatilho criado.

Irei abaixo realizar algumas inserções na tabela EMP sem referenciar a coluna ID.

SCOTT> insert into emp (nome) values ('RENATA');

1 linha criada.

SCOTT> insert into emp (nome) values ('CARLOS');

1 linha criada.

SCOTT> select * from emp;

        ID NOME
---------- ------------------------------------------------------------
         1 ROBERTO
         2 LAURA
         3 GUSTAVO
         4 RENATA
         5 CARLOS

-- Verificando o valor de LAST_NUMBER
SCOTT> select * from user_sequences;

SEQUENCE_NAME           MIN_VALUE  MAX_VALUE INCREMENT_BY C O CACHE_SIZE LAST_NUMBER
---------------------- ---------- ---------- ------------ - - ---------- -----------
SEQ_EMP_ID                      1 1,0000E+27            1 N N          0           6

E se quisermos alterar o valor atual da seqüência? Vale a pena salientar que esta ação somente será possível se a seqüência for dropada e recriada, pois não é possível alterar a propriedade START WITH com o comando ALTER SEQUENCE ...:

SCOTT> alter sequence seq_emp_id start with 1;
alter sequence seq_emp_id start with 1
*
ERRO na linha 1:
ORA-02283: não é possível alterar o número inicial da seqüência 

Para quem interessar, foi disponibilizada uma stored procedure criada por Trevor Fairhurst que pode facilitar muito este trabalho. Abaixo, irei demonstrar como utilizá-la:

-- Criando a stored procedure SET_SEQUENCE
SCOTT> create or replace procedure set_sequence
  2  (seqname in varchar2, newnumber in integer) as
  3     curr_val integer;
  4     curr_inc integer;
  5     curr_min integer;
  6  begin
  7     select increment_by, min_value into curr_inc, curr_min from user_sequences
  8     where sequence_name = seqname;
  9     execute immediate
 10       'alter sequence '||seqname||' minvalue '||least((newnumber-curr_inc-1),curr_min);
 11     execute immediate 'select '||seqname ||'.nextval from dual' into curr_val;
 12     if (newnumber - curr_val - curr_inc) != 0 then
 13       execute immediate
 14         'alter sequence '||seqname||' increment by '||(newnumber-curr_val-curr_inc);
 15     end if;
 16     execute immediate 'select ' ||seqname ||'.nextval from dual' into curr_val;
 17     execute immediate 'alter sequence ' ||seqname||' increment by ' || curr_inc;
 18  end set_sequence;
 19  /

Procedimento criado.

-- Alterando o valor atual para 1
SCOTT> exec set_sequence('SEQ_EMP_ID',1);

Procedimento PL/SQL concluído com sucesso.

SCOTT> select sequence_name,last_value from user_sequences;

SEQUENCE_NAME                  LAST_NUMBER
------------------------------ -----------
SEQ_EMP_ID                               1

-- Alterando o valor atual para 10
SCOTT> exec set_sequence('SEQ_EMP_ID',10);

Procedimento PL/SQL concluído com sucesso.

SCOTT> select sequence_name,last_value from user_sequences;

SEQUENCE_NAME                  LAST_NUMBER
------------------------------ -----------
SEQ_EMP_ID                              10

-- Alterando o valor atual para 20
SCOTT> exec set_sequence('SEQ_EMP_ID',20);

Procedimento PL/SQL concluído com sucesso.

SCOTT> select sequence_name,last_value from user_sequences;

SEQUENCE_NAME                  LAST_NUMBER
------------------------------ -----------
SEQ_EMP_ID                              20

Por fim, se quisermos dropar a seqüência, basta apenas emitirmos comando DROP SEQUENCE ... como mostrado abaixo:

SCOTT> drop sequence seq_emp_id;

Seqüência eliminada.

A propósito, para quem ainda não conhece, vale a pena salientar que o Oracle possui uma função interna chamada SYS_GUID (globally unique identifier) que gera e retorna valores únicos de 32 caracteres em uma representação hexadecimal. Caso alguém queira garantir alguma unicidade...

-- Gerando 10 valores únicos
SCOTT> select sys_guid() from dual connect by level <=10;

SYS_GUID()
--------------------------------
5AC83A4AF1E1B4CBE040EEC868FB0EE8
5AC83A4AF1E2B4CBE040EEC868FB0EE8
5AC83A4AF1E3B4CBE040EEC868FB0EE8
5AC83A4AF1E4B4CBE040EEC868FB0EE8
5AC83A4AF1E5B4CBE040EEC868FB0EE8
5AC83A4AF1E6B4CBE040EEC868FB0EE8
5AC83A4AF1E7B4CBE040EEC868FB0EE8
5AC83A4AF1E8B4CBE040EEC868FB0EE8
5AC83A4AF1E9B4CBE040EEC868FB0EE8
5AC83A4AF1EAB4CBE040EEC868FB0EE8

10 linhas selecionadas.

Por que após ter realizado uma importação, minhas tabelas não foram para o tablespace padrão do usuário?

Olá,

Esta é uma das questões mais comuns de qualquer desenvolvedor ou de qualquer pessoa que está iniciando no banco de dados Oracle. A resposta dependerá de alguns fatores que tentarei demonstrar com exemplos práticos mais abaixo. Normalmente isto acontece quando se utiliza os tradicionais utilitários de exportação e importação (exp/imp), já que os utilitários Data Pump expdp e impdp fornecidos à partir do Oracle 10g, praticamente eliminaram esse tipo de "problema". Acredito que os tradicionais utilitários de exportação e importação (exp e imp) são umas das ferramentas mais usadas fornecidas com o software Oracle. Todos os DBAs, iniciantes ou veteranos, com certeza já se utilizaram delas. Como dito anteriormente, mesmo com o advento dos novos utilitários Data Pump Export (expdp) e Data Pump Import (impdp) fornecidos à partir do Oracle 10g, realmente eles trouxeram importantes e incríveis inovações, mas mesmo assim, acredito que eles não ofuscaram totalmente os velhos e tradicionais utilitários (exp/imp). Dentre os mais variados recursos que o Data Pump apresentou, além de incluir aprimoramentos arquitetônicos e funcionais significativos (dump baseado no formato XML) em relação aos tradicionais Export e Import, o mesmo permite parar e reiniciar jobs, ver o status dos jobs em execução e restringir de forma bastante parametrizável os dados que são exportados e importados, como a de permitir alterar valores de armazenamento (STORAGE) dos segmentos a serem importados.

Apesar de os tradicionais utilitários exp/imp ainda terem sido disponibilizados na recente versão Oracle 11g release 1, acredito que a estratégia da Oracle será de ir eliminando gradativamente o suporte aos mesmos nas futuras releases do Oracle, em virtude dos utilitários Data Pump (expdp/impdp). Na verdade, nós usuários dos tradicionais utilitários exp/imp, estamos sendo encorajados a substituirmos o seu uso pelos utilitários Data pump Export e Data Pump Import desde o lançamento do Oracle 10g release 1.

Antes de abordarmos alguns exemplos práticos sobre exportação e importação de dados, vamos recapitular algumas funcionalidades dos tradicionais exp e imp de modo a fornecer uma visão geral.

Como todos nós já sabemos, a exportação e a importação permitem aos DBAs e aos desenvolvedores de aplicativos, fazerem cópias fidedignas e rápidas de dados de um banco Oracle. A exportação (usando-se o comando exp) faz uma cópia dos dados e das estruturas de dados em um arquivo de sistema operacional. A importação (usando-se o comando imp) lê os arquivos criados pela exportação e coloca os dados e as estruturas de dados nos arquivos do banco de dados. Dentre os modos disponíveis, temos tabela, usuário e exportação e importação completa de banco de dados. Ao usar a exportação de modo tabela, você diz ao Oracle os nomes de uma ou mais tabelas a serem exportadas. Na exportação de modo usuário, o Oracle exporta todos os objetos de um usuário, incluindo views, concessões do proprietário, triggers, índices, sinônimos, stored procedures, database links, tabelas, constraints e o que tiver mais dentro do schema do usuário. Na exportação completa de banco de dados, os objetos e dados de todos os usuários (exceto aqueles contidos no schema SYS), mais as declarações de criação de alguns arquivos de banco da dados também são exportadas. O Oracle 8i introduziu um parâmetro de exportação chamado QUERY que possibilitou a exportação de conjuntos de linhas baseadas em uma consulta. Isso facilitou muito a vida dos DBAs por ter dado um controle mais fino sobre os dados a serem manipulados por meio de exportação e importação. A partir do Oracle 8i, foi possível também exportar e importar as estatísticas pré-calculadas do otimizador. Outro recurso que foi incorporado na versão 8i, foram os tablespaces transportáveis na qual tornou possível a movimentação de um conjunto de tablespaces de um banco de dados Oracle para outro banco de dados Oracle (de mesma versão e O/S). Este método envolve a cópia dos arquivos de dados de um banco de dados para outro usando ao mesmo tempo os utilitários de exportação e importação para transportar os metadados do dicionário de dados associados ao tablespace.

Vale a pena salientar que o utilitário de exportação não pode ser considerado como uma ferramenta para criação de um método efetivo de backup. Eu diria que ele possibilita um backup lógico, pelo fato de que não é possível aplicar um histórico de redo log nos objetos importados provenientes de um arquivo de exportação. Um backup lógico de um banco de dados envolve a leitura de um conjunto de registros do banco de dados e a gravação destes em um arquivo. Esses registros são lidos independentes das suas localizações físicas. Acredito que uma estratégia robusta de backup possa incluir tanto backups físicos como lógicos. Em geral, bancos de dados de produção contam com backups físicos como seu principal método de backup e backups lógicos servem como um método secundário. Por outro lado, para bancos de dados de desenvolvimento e para pequenos processamentos de movimentação de dados, os backups lógicos podem ser uma solução aceitável e viável.

Portanto, os arquivos dumps gerados pelo utilitário de exportação podem ser utilizados como um recurso complementar ao backup físico de banco de dados para proteção contra erros de usuário. Por exemplo, um backup lógico pode ser útil quando um usuário elimina ou trunca uma tabela acidentalmente ou quando o DBA precisa restaurar uma tabela que apresente erros lógicos, ou uma operação qualquer que tenha afetado somente um subconjunto do banco de dados. Neste caso, um dump de exportação atualizado seria uma alternativa mais rápida e menos traumática do que realizar uma recuperação incompleta de banco de dados, seja ela gerenciada pelo usuário ou através do recovery manager (RMAN). Em todo caso, e dependendo do cenário, isso dependerá muito da versão Oracle utilizada pelo fato de a partir do Oracle 10g, nós já termos a proteção da lixeria (recyclebin) para segmentos que foram dropados e inclusive recursos da tecnologia flashback.

Não podemos esquecer que, além da exportação pelo caminho convencional, um outro recurso chamado de caminho direto (DIRECT=Y), pode ser utilizado para extrair dados muito mais rapidamente pelo fato de o utilitário de exportação fazer a leitura diretamente em uma camada de dados, em vez de passar pela camada de processamento de dados SQL. Neste caso, os dados já estarão em um formato esperado pelo utilitário de exportação, evitando assim a conversão desnecessária de dados.

Durante uma importação, os dados são processados da seguinte forma:

* Novas tabelas são criadas
* Dados são importados
* Índices são construídos
* Triggers, restrições, stored procedures, views entre outros objetos são importados
* Restrições de integridade são ativadas nas novas tabelas
* Índices funcionais e de bitmaps e/ou de domínios são construídos

Na verdade, essa seqüência impede que os dados sejam rejeitados devido à ordem em que as tabelas são importadas. Ela também impede que as triggers sejam acionadas durante a importação.

Como regra, para mover dados entre bancos de dados Oracle de versões/releases diferentes, deve-se utilizar a premissa abaixo:

• Para mover dados de uma versão inferior de banco de dados para uma versão superior de banco de dados Oracle, é necessário usar a versão nativa do utilitário de exportação referente à versão inferior e usar o utilitário de importação da versão referente à versão superior.
  

• Para mover dados de uma versão superior de banco de dados para uma versão inferior de banco de dados Oracle, é necessário usar a versão nativa do utilitário de exportação referente à versão inferior e usar o utilitário de importação também referente à versão inferior.
  

A tabelas abaixo mostram esta interoperabilidade de movimentação de dados entre o Oracle 10g e outras versões:

Exportando dados do Oracle 10.2 e Importando-os em versões anteriores
------------------------------------------------------------------------------
Exportar de       Importar para       Use Export versão    Use Import versão
------------------------------------------------------------------------------
Release 10.2      Release 10.2        Release 10.2         Release 10.2
------------------------------------------------------------------------------
Release 10.2      Release 10.1        Release 10.1         Release 10.1
------------------------------------------------------------------------------
Release 10.2      Release 9.2         Release 9.2          Release 9.2
------------------------------------------------------------------------------
Release 10.2      Release 9.0.1       Release 9.0.1        Release 9.0.1
------------------------------------------------------------------------------
Release 10.2      Release 8.1.7       Release 8.1.7        Release 8.1.7
------------------------------------------------------------------------------
Release 10.2      Release 8.0.6       Release 8.0.6        Release 8.0.6
------------------------------------------------------------------------------


Exportando dados de versões anteriores ao 10.2 e Importando-os no Oracle 10.2
------------------------------------------------------------------------------
Exportar de       Importar para       Use Export versão    Use Import versão
------------------------------------------------------------------------------
Release 10.1      Release 10.2        Release 10.1         Release 10.2
------------------------------------------------------------------------------
Release 9.2       Release 10.2        Release 9.2          Release 10.2
------------------------------------------------------------------------------
Release 8.1.7     Release 10.2        Release 8.1.7        Release 10.2
------------------------------------------------------------------------------
Release 8.0.6     Release 10.2        Release 8.0.6        Release 10.2
------------------------------------------------------------------------------
Release 7.3.4     Release 10.2        Release 7.3.4        Release 10.2
------------------------------------------------------------------------------

A tabela abaixo mostra de forma geral, as versões de utilitários a serem usadas para cada caso.

Usando diferentes versões dos utilitários Export and Import
------------------------------------------------------------------
Export de -> Importar para  Use Export versão  Use Import versão
------------------------------------------------------------------
8.1.6  --->  8.1.6          Release 8.1.6      Release 8.1.6
------------------------------------------------------------------
8.1.5  --->  8.0.6          Release 8.0.6      Release 8.0.6
------------------------------------------------------------------
8.1.7  --->  8.1.6          Release 8.1.6      Release 8.1.6
------------------------------------------------------------------
9.0.1  --->  8.1.6          Release 8.1.6      Release 8.1.6
------------------------------------------------------------------
9.0.1  --->  9.2.0          Release 9.0.1      Release 9.2.0
------------------------------------------------------------------
9.2.0  --->  10.2.0         Release 9.2.0      Release 10.2.0
------------------------------------------------------------------
9.2.0  --->  11.1.0         Release 9.2.0      Release 11.1.0
------------------------------------------------------------------
10.2.0 --->  9.2.0          Release 9.2.0      Release 9.2.0
------------------------------------------------------------------
10.2.0 --->  11.1.0         Release 10.2.0     Release 11.1.0
------------------------------------------------------------------
11.1.0 --->  9.2.0          Release 9.2.0      Release 9.2.0
------------------------------------------------------------------
11.1.0 --->  10.2.0         Release 10.2.0     Release 10.2.0
------------------------------------------------------------------

Voltando à questão que originou este artigo, demonstrarei abaixo alguns cenários práticos na qual poderemos transferir (exportar e importar) dados em um mesmo banco de dados Oracle de forma que os segmentos criados no schema de destino sejam criados no tablespace padrão do mesmo. Vale a pena salientar que no caso do utilitário de importação tradicional (imp), ao importar dados de um arquivo dump gerado pelo utilitário de exportação (exp), o Oracle sempre tentará importar os segmentos para o tablespace especificado no arquivo de exportação se o mesmo existir no banco de dados de destino, senão, os segmnentos serão importados para o tablespace padrão (default) do usuário. Outra coisa é que os atributos de storage (INITIAL EXTENT) das tabelas provenientes do schema original, também são exportadas pelo utilitário de exportação.

Bem, após esta longa introdução, vamos então a alguns exemplos práticos.

C:\>sqlplus / as sysdba

SQL*Plus: Release 10.1.0.2.0 - Production on Sex Out 10 07:32:30 2008

Copyright (c) 1982, 2004, Oracle.  All rights reserved.

Conectado a:
Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production

-- Criação de um tablespace TBS_A
SYS> create tablespace tbs_a
  2   logging
  3   datafile 'C:\oraclexe\oradata\XE\a.dbf' size 5m
  4   extent management local
  5   segment space management auto;

Tablespace criado.

-- Criação de um tablespace TBS_B
SYS> create tablespace tbs_b
  2   logging
  3   datafile 'C:\oraclexe\oradata\XE\b.dbf' size 5m
  4   extent management local
  5   segment space management auto;

Tablespace criado.

-- Criação dos schemas USUARIO_A e USUARIO_B
SYS> create user usuario_a identified by senha default tablespace tbs_a;

Usuário criado.

SYS> create user usuario_b identified by senha default tablespace tbs_b;

Usuário criado.

-- Concedendo roles pré-definidas para ambos os usuários
SYS> grant connect,resource to usuario_a,usuario_b;

Concessão bem-sucedida.

-- Criação da tabela EMP no schema USUARIO_A
SYS> connect usuario_a/senha
Conectado.

-- Confirmando o tablespace padrão
USUARIO_A> select default_tablespace from user_users;

DEFAULT_TABLESPACE
------------------------------
TBS_A

-- Criando a tabela EMP com tamanho incial de extent de 3MB
USUARIO_A> create table emp (id number) storage (initial 3m);

Tabela criada.

USUARIO_A> exit
Desconectado de Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production

-- Realizando a exportação do schema USUARIO_A
C:\>exp usuario_a/senha file=usuario_a statistics=none

Export: Release 10.1.0.2.0 - Production on Sex Out 10 07:36:09 2008

Copyright (c) 1982, 2004, Oracle.  All rights reserved.


Conectado a: Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production
Exportação executada no conjunto de caracteres de WE8PC850  e no conjunto de caracteres
de AL16UTF16 NCHAR o servidor usa WE8MSWIN1252 conjunto de caracteres
. exportando objetos e ações procedurais anteriores ao esquema
. exportando os nomes da biblioteca de função externa para usuário USUARIO_A
. exportando sinônimos do tipo PÚBLICO
. exportando sinônimos do tipo privado
. exportando definições de tipos de objeto para usuário USUARIO_A
Sobre exportar objetos de USUARIO_A ...
. exportando vínculos de banco de dados
. exportando números de seqüência
. exportando definições de cluster
. sobre exportar tabelas de USUARIO_A ... via Caminho Convencional ...
. . exportando tabela                            EMP          0 linhas exportadas
. exportando sinônimos
. exportando views
. exportando procedimentos armazenados
. exportando operadores
. exportando restrições referenciais de integridade
. exportando gatilhos
. exportando tipos de índices
. exportando índices funcionais, extensíveis e de bitmap
. exportando ações contabilizáveis
. exportando views materializadas
. exportando logs de snapshot
. exportando filas de serviço
. exportando filhos e grupos de renovação
. exportando dimensões
. exportando objetos e ações procedurais posteriores ao esquema
. exportando estatística
Exportação encerrada com sucesso, sem advertências.


-- Realizando a importação do dump para o USUARIO_B
C:\>imp usuario_b/senha file=usuario_a full=y

Import: Release 10.1.0.2.0 - Production on Sex Out 10 07:40:02 2008

Copyright (c) 1982, 2004, Oracle.  All rights reserved.

Conectado a: Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production

Arquivo de exportação criado por EXPORT:V10.01.00 via caminho convencional

Advertência: os objetos foram exportados por USUARIO_A; não por você

importação realizada nos conjuntos de caracteres WE8PC850 e NCHAR AL16UTF16
o servidor de importação usa o conjunto de caracteres WE8MSWIN1252
. importando objetos de USUARIO_A para USUARIO_B
. . importando table                          "EMP"          0 linhas importadas
Importação encerrada com sucesso, sem advertências.


-- Realizando conexão com usuário DBA
C:\>sqlplus / as sysdba

SQL*Plus: Release 10.1.0.2.0 - Production on Sex Out 10 07:41:51 2008

Copyright (c) 1982, 2004, Oracle.  All rights reserved.

Conectado a:
Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production

-- Executando query para verificar a localização das tabelas
SYS> select owner,table_name,initial_extent,tablespace_name
  2  from dba_tables
  3  where owner in ('USUARIO_A','USUARIO_B');

OWNER                  TABLE_NAME            INITIAL_EXTENT TABLESPACE_NAME
---------------------- --------------------- -------------- ------------------------
USUARIO_A              EMP                          3145728 TBS_A
USUARIO_B              EMP                          3145728 TBS_A

Podemos verificar acima que tabela EMP foi importada para o schema USUARIO_B no tablespace TBS_A, mesmo o schema USUARIO_B tendo o seu tablespace padrão sido definido como TBS_B. Como dito anteriormente, o Oracle sempre tentará importar os segmentos para o tablespace especificado no arquivo de exportação se o mesmo existir no banco de dados de destino, senão, os segmentos serão importados para o tablespace padrão (default) do usuário. Como o banco de origem e de destino é o mesmo, então a tabela foi importada para o tablespace TBS_A.

Abaixo, podemos ver no conteúdo do arquivo de exportação, que o tablespace TBS_A é o tablespace de origem definido para a tabela EMP. A propósito, podemos verificar também, que o atributo de storage (INITIAL) definido para a tabela EMP no schema de origem (USUARIO_A), também foi exportado para o arquivo de dump. Dependendo do caso, talvez seja interessante alterar este valor de storage nas tabelas do schema de origem, ou até mesmo, gerar os comandos DDL de criação das tabelas utilizando a cláusula INDEXFILE do comando imp para então editar o valor INITIAL da clásula storage com um valor menor. Se realmente for o caso, então porque não alterar também o tablespace? Após a criação das tabelas, seria necessário apenas utilizar a cláusula IGNORE=Y ao executar com comando imp para realizar a importação.

-- Verificando o conteúdo do arquivo de dump de exportação
C:\>imp usuario_b/senha file=usuario_a.dmp show=y

Import: Release 10.1.0.2.0 - Production on Sex Out 10 08:15:43 2008

Copyright (c) 1982, 2004, Oracle.  All rights reserved.

Conectado a: Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production

Arquivo de exportação criado por EXPORT:V10.01.00 via caminho convencional
importação realizada nos conjuntos de caracteres WE8PC850 e NCHAR AL16UTF16
o servidor de importação usa o conjunto de caracteres WE8MSWIN1252
. importando objetos de USUARIO_A para USUARIO_B
 "BEGIN  "
 "sys.dbms_logrep_imp.instantiate_schema(schema_name=>SYS_CONTEXT('USERENV','"
 "CURRENT_SCHEMA'), export_db_name=>'XE', inst_scn=>'431135');"
 "COMMIT; END;"
 "CREATE TABLE "EMP" ("ID" NUMBER)  PCTFREE 10 PCTUSED 40 INITRANS 1" 
 "MAXTRANS 255 STORAGE(INITIAL 3145728 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL"
 "DEFAULT) TABLESPACE "TBS_A" LOGGING NOCOMPRESS"
. . saltando a tabela "EMP"

Importação encerrada com sucesso, sem advertências.

-- Após conectar com o USUARIO_B, podemos verificar que realmente foram alocados
-- 3 extensões (extents) para o segmento EMP do schema USUARIO_B
USUARIO_B> select extent_id,bytes,blocks
  2  from user_extents
  3  where segment_name='EMP';

 EXTENT_ID      BYTES     BLOCKS
---------- ---------- ----------
         0    1048576        128
         1    1048576        128
         2    1048576        128

-- Alterando o valor INITIAL para o menor possível que é 64K
USUARIO_B> alter table emp move storage(initial 1);

Tabela alterada.

USUARIO_B> select extent_id,bytes,blocks
  2  from user_extents
  3  where segment_name='EMP';

 EXTENT_ID      BYTES     BLOCKS
---------- ---------- ----------
         0      65536          8

Voltando à questão inicial, como os dados já foram importados para o schema de destino, e se quisermos que a tabela fique alocada no tablespace padrão (TBS_B) do schema, teremos apenas que movê-la utilizando o comando ALTER TABLE MOVE ... como mostrado abaixo:

-- Movendo a tabela EMP para o tablespace TBS_B
SYS> alter table usuario_b.emp move tablespace tbs_b;

Tabela alterada.

-- Verificando a localização da tabela EMP após a movimentação da tabela EMP
SYS> select owner,table_name,tablespace_name
  2  from dba_tables
  3  where owner in ('USUARIO_A','USUARIO_B');

OWNER                    TABLE_NAME               TABLESPACE_NAME
------------------------ ------------------------ -----------------------------
USUARIO_A                EMP                      TBS_A
USUARIO_B                EMP                      TBS_B

Após a movimentação da tabela EMP, podemos ver acima que o mesmo foi alocado no tablespace TBS_B. Vale a pena salientar que após qualquer movimentação de tabelas utilizando o comando ALTER TABLE MOVE ... será necessário que os índices porventura existentes e associados às tabelas movidas, sejam reconstruídos com o comando ALTER INDEX ... REBUILD.

Agora a pergunta que não quer calar: É possível fazer com que a tabela seja importada para o tablespace padrão do usuário de destino? Sim, é possível. Podemos ver na sáida do comando SQL abaixo, que quando criamos o usuário USUARIO_B e concedemos a role pré-definida RESOURCE, automaticamente o privilégio de sistema UNLIMITED TABLESPACE também foi concedido:

SYS> select * from dba_sys_privs where grantee='USUARIO_B';

GRANTEE                  PRIVILEGE                                ADM
------------------------ ---------------------------------------- ---
USUARIO_B                UNLIMITED TABLESPACE                     NO

Apesar do privilégio de sistema UNLIMITED TABLESPACE não fazer parte da role RESOURCE como mostrado no resultado logo abaixo, o Oracle automaticamente e de forma explícita, concede este privilégio de sistema para todo usuário que tiver a concessão da role RESOURCE diretamente, mas não porque ela faz parte da role, e sim porque este privilégio é concedido ao usuário sempre que a role também for concedida. Bem, neste caso, porque não conceder os privilégios separadamente? Apenas para reflexão ...

Vale a pena salientar que, uma vez que o privilégio de sistema UNLIMITED TABLESPACE seja concedido à um usuário, todas as cotas de espaço de tablespace porventura concedidas a este usuário, serão explicitamente desprezadas.

-- O resultado abaixo, nos mostra que privilégio de sistema UNLIMITED TABLESPACE não
-- está presente na role RESOURCE
SYS> select privilege from  role_sys_privs where role='RESOURCE';

PRIVILEGE
----------------------------------------
CREATE SEQUENCE
CREATE TRIGGER
CREATE CLUSTER
CREATE PROCEDURE
CREATE TYPE
CREATE OPERATOR
CREATE TABLE
CREATE INDEXTYPE

8 linhas selecionadas.

Portanto, irei abaixo revogar o privilégio de sistema UNLIMITED TABLESPACE do usuário USUARIO_B, conceder cota de espaço ilimitada ao tablespace TBS_B para o usuário USUARIO_B e realizar a importação novamente:

-- Revogando o privilégio de sistema UNLIMITED TABLESPACE
SYS> revoke unlimited tablespace from usuario_b;

Revogação bem-sucedida.

-- Concedendo cota ilimitada no tablespace TBS_B para o USUARIO_B
SYS> alter user usuario_b quota unlimited on tbs_b;

Usuário alterado.

-- Dropando a tabela EMP de forma a realizar a importação novamente
SYS> drop table usuario_b.emp purge;

Tabela eliminada.

SYS> exit
Desconectado de Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production


-- Realizando a importação novamente
C:\>imp usuario_b/senha file=usuario_a full=y

Import: Release 10.1.0.2.0 - Production on Sex Out 10 08:20:38 2008

Copyright (c) 1982, 2004, Oracle.  All rights reserved.

Conectado a: Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production

Arquivo de exportação criado por EXPORT:V10.01.00 via caminho convencional

Advertência: os objetos foram exportados por USUARIO_A; não por você

importação realizada nos conjuntos de caracteres WE8PC850 e NCHAR AL16UTF16
o servidor de importação usa o conjunto de caracteres WE8MSWIN1252
. importando objetos de USUARIO_A para USUARIO_B
. . importando table                          "EMP"          0 linhas importadas
Importação encerrada com sucesso, sem advertências.


-- Realizando conexão com usuário DBA
C:\>sqlplus / as sysdba

SQL*Plus: Release 10.1.0.2.0 - Production on Sex Out 10 08:40:12 2008

Copyright (c) 1982, 2004, Oracle.  All rights reserved.

Conectado a:
Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production

-- Verificando a localização da tabela EMP após a importação
SYS> select owner,table_name,tablespace_name
  2  from dba_tables
  3  where owner in ('USUARIO_A','USUARIO_B');

OWNER                    TABLE_NAME               TABLESPACE_NAME
------------------------ ------------------------ ---------------------------
USUARIO_A                 EMP                      TBS_A
USUARIO_B                 EMP                      TBS_B

Podemos ver no resultado acima que a tabela EMP foi importada diretamente para o tablespace padrão do usuário USUARIO_B. Neste caso, podemos concluir que uma tabela não será importada para o tablespace definido no arquivo dump de exportação se o usuário de destino não tiver cota de tablespace no mesmo.

Irei agora realizar um exemplo prático utilizando os utilitários Data Pump Export/Import (expdp/impdp) disponíveis à partir do Oracle 10g. Para isso, irei dropar o usuário USUARIO_B e criá-lo novamente. Irei também gerar um novo arquivo de dump utilizando o utilitário expdp.

SYS> drop user usuario_b cascade;

Usuário eliminado.

SYS> create user usuario_b identified by senha default tablespace tbs_b;

Usuário criado.

SYS> grant connect,resource to usuario_b;

Concessão bem-sucedida.

-- Verificando o caminho para onde os arquivos dump serão gerados
SYS> select * from dba_directories;

OWNER        DIRECTORY_NAME        DIRECTORY_PATH
------------ --------------------- ---------------------------------------
SYS          DATA_PUMP_DIR         C:\oraclexe\app\oracle\admin\XE\dpdump\

-- Realizando a exportação do usuário USUARIO_A
C:\>expdp system/manager DIRECTORY=DATA_PUMP_DIR DUMPFILE=usuario_a.dp SCHEMAS=usuario_a

Export: Release 10.2.0.1.0 - Production on Sexta-Feira, 10 Outubro, 2008 08:45:12

Copyright (c) 2003, 2005, Oracle.  All rights reserved.

Conectado a: Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production
Iniciando "SYSTEM"."SYS_EXPORT_SCHEMA_01":  system/******** DIRECTORY=DATA_PUMP_DIR 
DUMPFILE=usuario_a.dp SCHEMAS=usuario_a
Estimativa em andamento com o método BLOCKS...
Processando o tipo de objeto SCHEMA_EXPORT/TABLE/TABLE_DATA
Estimativa total usando o método de BLOCKS: 0 KB
Processando o tipo de objeto SCHEMA_EXPORT/USER
Processando o tipo de objeto SCHEMA_EXPORT/SYSTEM_GRANT
Processando o tipo de objeto SCHEMA_EXPORT/ROLE_GRANT
Processando o tipo de objeto SCHEMA_EXPORT/DEFAULT_ROLE
Processando o tipo de objeto SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
Processando o tipo de objeto SCHEMA_EXPORT/TABLE/TABLE
. . exportou "USUARIO_A"."EMP"                               0 KB       0 linhas
Tabela-mestre "SYSTEM"."SYS_EXPORT_SCHEMA_01" carregada/descarregada com sucesso
******************************************************************************
Conjunto de arquivos de dump para SYSTEM.SYS_EXPORT_SCHEMA_01 é:
  C:\ORACLEXE\APP\ORACLE\ADMIN\XE\DPDUMP\USUARIO_A.DP
O job "SYSTEM"."SYS_EXPORT_SCHEMA_01" foi concluído com sucesso em 08:45:17

Após a geração do arquivo de dump, irei abaixo usar o utilitário impdp para realizar a importação do mesmo para o usuário de destino USUARIO_B utilizando as cláusulas REMAP_SCHEMA e REMAP_TABLESPACE:

-- Realizando a importação do dump de exportação
C:\>impdp system/manager DIRECTORY=DATA_PUMP_DIR DUMPFILE=usuario_a.dp 
    remap_schema=USUARIO_A:USUARIO_B
    remap_tablespace=TBS_A:TBS_B

Import: Release 10.2.0.1.0 - Production on Sexta-Feira, 10 Outubro, 2008 08:49:03

Copyright (c) 2003, 2005, Oracle.  All rights reserved.

Conectado a: Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production
Tabela-mestre "SYSTEM"."SYS_IMPORT_FULL_02" carregada/descarregada com sucesso
Iniciando "SYSTEM"."SYS_IMPORT_FULL_02":  system/******** DIRECTORY=DATA_PUMP_DIR
DUMPFILE=usuario_a.dp remap_schema=USUARIO_A:USUARIO_B remap_tablespace=TBS_A:TBS_B
Processando o tipo de objeto SCHEMA_EXPORT/USER
ORA-31684: O tipo de objeto USER:"USUARIO_B" já existe
Processando o tipo de objeto SCHEMA_EXPORT/SYSTEM_GRANT
Processando o tipo de objeto SCHEMA_EXPORT/ROLE_GRANT
Processando o tipo de objeto SCHEMA_EXPORT/DEFAULT_ROLE
Processando o tipo de objeto SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
Processando o tipo de objeto SCHEMA_EXPORT/TABLE/TABLE
Processando o tipo de objeto SCHEMA_EXPORT/TABLE/TABLE_DATA
. . importou "USUARIO_B"."EMP"                               0 KB       0 linhas
O job "SYSTEM"."SYS_IMPORT_FULL_02" foi concluído com 1 erro(s) em 15:17:06


-- Realizando conexão com usuário DBA
C:\>sqlplus / as sysdba

SQL*Plus: Release 10.1.0.2.0 - Production on Sex Out 10 08:55:02 2008

Copyright (c) 1982, 2004, Oracle.  All rights reserved.

Conectado a:
Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production

-- Verificando a localização da tabela EMP após a importação
SYS> select owner,table_name,tablespace_name
  2  from dba_tables
  3  where owner in ('USUARIO_A','USUARIO_B');

OWNER                    TABLE_NAME               TABLESPACE_NAME
------------------------ ------------------------ ------------------------
USUARIO_A                EMP                      TBS_A
USUARIO_B                EMP                      TBS_B

Podemos perceber pelo resultado acima, que apesar de o privilégio de sistema UNLIMITED TABLESPACE ter sido concedido implicitamente através da role RESOURCE como dito anteriormente, a tabela foi importada para o tablespace padrão do usuário USUARIO_B simplesmente pelo fato de no comando de importação eu explicitamente ter especificado a cláusula REMAP_TABLESPACE.

OBS: Vale a pena salientar que o parâmetro TRANSFORM do utilitário impdp na qual pode ter o valor SEGMENT_ATTRIBUTES ou STORAGE, também pode ser utilizado para fazer com que as tabelas também sejam criadas no tablespace padrão do usuário de destino. O valor STORAGE (transform=storage:N:table) remove a cláusula de armaz