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


sábado, 1 de maio de 2010

Algumas implicações do uso da cláusula COMPRESS [Y/N] disponível no utilitário de exportação tradicional (exp)

Por Eduardo Legatti

Olá,

Recentemente, me deparei com uma absurda lentidão na importação das estruturas de tabelas e índices contidas em um arquivo dump de exportação (exportado com a cláusula full=y rows=n) gerado por um cliente através do já obsoleto, mas ainda, muito usado, utilitário de exportação tradicional (exp).

A idéia era manter a mesma estrutura lógica de tablespaces do banco de dados de origem, então, iniciei a extração dos comandos DDL de criação das tablespaces à partir do arquivo dump de exportação. A única coisa que eu aproveitei foi o nome das tablespaces, ou seja, o tamanho e o caminho de destino dos arquivos de dados foram alterados, pois não faria sentido utilizar o tamanho dos arquivos de dados de origem (que eram de muitos gigabytes), apenas para armazenar estruturas de tabelas e índices. No entanto, foi esse o motivo da lentidão, pois eu criei os arquivos de dados com um tamanho inicial de 200 MB e com extensão automática habilitada de 50 MB. Está Curioso? Então preste atenção nos exemplos abaixo, pois neste artigo eu irei falar sobre a cláusula COMPRESS disponível no utilitário de exportação (exp).

Sabemos que um segmento de banco de dados, tal como uma tabela ou índice, consiste na extensões (extents) que são alocadas a ele. A figura abaixo mostra as estruturas lógicas de armazenamento de um banco de dados Oracle.



Bom, à medida que uma tabela ou índice cresce, e os extents existentes são preenchidos, cada vez mais extents são alocados a ela. Eventualmente, a tabela pode crescer em um número grande de extents como demonstrado no exemplo abaixo, na qual irei criar uma tabela com 10 milhões de registros.

C:\>sqlplus scott/tiger

SQL*Plus: Release 10.2.0.1.0 - Production on Sáb Mai 1 16:46:34 2010

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

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

SQL> create table t1 as select level id from dual
  2  connect by level <=10000000;

Tabela criada.

SQL> select segment_name,bytes,extents,initial_extent from user_segments;

SEGMENT_NAME                        BYTES    EXTENTS INITIAL_EXTENT
------------------------------ ---------- ---------- --------------
T1                              134217728         87          65536


Após a criação da tabela T1 com os 10 milhões de registros, podemos perceber acima que a mesma alocou 134217728 bytes (128 MB) de tamanho em 87 extents, e que o tamanho do extent inicial INITIAL_EXTENT foi de 65 KB.

Abaixo poderemos perceber que a soma da coluna BYTES da view de dicionário de dados USER_EXTENTS dá exatamente o valor de 128 MB, que é o tamanho do segmento T1.

SQL> break on report
SQL> compute sum of bytes on report
SQL> select segment_name,extent_id,bytes,blocks from user_extents;

SEGMENT_NAME                    EXTENT_ID      BYTES     BLOCKS
------------------------------ ---------- ---------- ----------
T1                                      0      65536          8
T1                                      1      65536          8
T1                                      2      65536          8
T1                                      3      65536          8
T1                                      4      65536          8
T1                                      5      65536          8
T1                                      6      65536          8
T1                                      7      65536          8
T1                                      8      65536          8
T1                                      9      65536          8
T1                                     10      65536          8
T1                                     11      65536          8
T1                                     12      65536          8
T1                                     13      65536          8
T1                                     14      65536          8
T1                                     15      65536          8
T1                                     16    1048576        128
T1                                     17    1048576        128
T1                                     18    1048576        128
T1                                     19    1048576        128
T1                                     20    1048576        128
T1                                     21    1048576        128
T1                                     22    1048576        128
T1                                     23    1048576        128
T1                                     24    1048576        128
T1                                     25    1048576        128
T1                                     26    1048576        128
T1                                     27    1048576        128
T1                                     28    1048576        128
T1                                     29    1048576        128
T1                                     30    1048576        128
T1                                     31    1048576        128
T1                                     32    1048576        128
T1                                     33    1048576        128
T1                                     34    1048576        128
T1                                     35    1048576        128
T1                                     36    1048576        128
T1                                     37    1048576        128
T1                                     38    1048576        128
T1                                     39    1048576        128
T1                                     40    1048576        128
T1                                     41    1048576        128
T1                                     42    1048576        128
T1                                     43    1048576        128
T1                                     44    1048576        128
T1                                     45    1048576        128
T1                                     46    1048576        128
T1                                     47    1048576        128
T1                                     48    1048576        128
T1                                     49    1048576        128
T1                                     50    1048576        128
T1                                     51    1048576        128
T1                                     52    1048576        128
T1                                     53    1048576        128
T1                                     54    1048576        128
T1                                     55    1048576        128
T1                                     56    1048576        128
T1                                     57    1048576        128
T1                                     58    1048576        128
T1                                     59    1048576        128
T1                                     60    1048576        128
T1                                     61    1048576        128
T1                                     62    1048576        128
T1                                     63    1048576        128
T1                                     64    1048576        128
T1                                     65    1048576        128
T1                                     66    1048576        128
T1                                     67    1048576        128
T1                                     68    1048576        128
T1                                     69    1048576        128
T1                                     70    1048576        128
T1                                     71    1048576        128
T1                                     72    1048576        128
T1                                     73    1048576        128
T1                                     74    1048576        128
T1                                     75    1048576        128
T1                                     76    1048576        128
T1                                     77    1048576        128
T1                                     78    1048576        128
T1                                     79    8388608       1024
T1                                     80    8388608       1024
T1                                     81    8388608       1024
T1                                     82    8388608       1024
T1                                     83    8388608       1024
T1                                     84    8388608       1024
T1                                     85    8388608       1024
T1                                     86    8388608       1024
                                          ----------
sum                                        134217728


Agora vem a questão. Se nós exportarmos apenas a estrutura desta tabela, qual será o valor de INITIAL_EXTENT no comando DDL de criação da tabela dentro do arquivo dump de exportação? Veja o exemplo abaixo:

C:\>exp scott/tiger file=t1_compress.dmp tables=t1 rows=n

Export: Release 10.2.0.1.0 - Production on Sáb Mai 1 16:49:13 2010

Copyright (c) 1982, 2005, 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 WE8MSWIN1252 e no conjunto de
caracteres de AL16UTF16 NCHAR OBS: dados (linhas) da tabela não serão exportados

Sobre exportar tabelas especificadas ... via Caminho Convencional ...
. . exportando tabela                             T1
Exportação encerrada com sucesso, sem advertências.

C:\>findstr /C:"STORAGE" T1_COMPRESS.DMP
CREATE TABLE "T1" ("ID" NUMBER)  PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255
STORAGE(INITIAL 134217728 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "USERS" LOGGING NOCOMPRESS


Como esperado, o valor é exatamente o tamanho do segmento, ou seja 134217728 bytes (128 MB). Sabemos que a cláusula COMPRESS do utilitário de exportação tem como padrão o valor "Y", ou seja, sua função é a de acumular a soma do tamanho de todos os extents do segmento de forma que na importação através do utilitário (imp), o mesmo possa criar o segmento em um único extent grande, quando for possível.

Agora imagine o seguinte cenário. Foi criada uma tablespace contendo um datafile de 200 MB com a opção de extensão automática habilitada de 50 MB. O DBA está aguardando um arquivo dump de exportação contendo apenas as estruturas de tabelas e índices de todos os schemas de um banco de dados imenso. Agora imagine que o DBA (do cliente) que gerou o arquivo dump de exportação tenha utilizado o valor padrão COMPRESS=Y. Agora vamos supor que a maioria dos segmentos contidos no arquivo dump de exportação tenha o valor da cláusula STORAGE (INITIAL) com o tamanho de 50 GB. Já imaginou? Isso quer dizer que ao importar uma única tabela, o meu tablespace que foi criado com um valor inicial de 200 MB, teria que se auto estender 250 vezes (de 50 em 50 megabytes) até conseguir acomodar o segmento de 50 GB!! Isso ainda, se houver espaço em disco disponível! Isso com certeza iria demorar um bocado de tempo ...

Portanto, realizando a exportação utilizando a cláusula COMPRESS setada para "N" resolveríamos o problema. Veja o exemplo abaixo.

C:\>exp scott/tiger file=t1_nocompress.dmp tables=t1 rows=n compress=n
Export: Release 10.2.0.1.0 - Production on Sáb Mai 1 16:55:32 2010

Copyright (c) 1982, 2005, 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 WE8MSWIN1252 e no conjunto de
caracteres de AL16UTF16 NCHAR OBS: dados (linhas) da tabela não serão exportados

Sobre exportar tabelas especificadas ... via Caminho Convencional ...
. . exportando tabela                             T1
Exportação encerrada com sucesso, sem advertências.

C:\>findstr /C:"STORAGE" T1_NOCOPRESS.DMP
CREATE TABLE "T1" ("ID" NUMBER)  PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255
STORAGE(INITIAL 65536 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "USERS" LOGGING NOCOMPRESS


Podemos perceber que o valor de STORAGE (INITIAL) não é mais 134217728 bytes (128 MB), e sim 65536 (65 KB) que é valor padrão.

Abaixo, ao realizar a importação utilizando o primeiro dump gerado (T1_COMPRESS.DMP), podemos perceber que o segmento foi criado com uma alocação de 128 MB sem nem mesmo conter um único registro na tabela.

C:\>imp scott/tiger file=t1_compress.dmp full=y

Import: Release 10.2.0.1.0 - Production on Sáb Mai 1 16:58:25 2010

Copyright (c) 1982, 2005, 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.02.01 via caminho convencional
importação realizada nos conjuntos de caracteres WE8MSWIN1252 e NCHAR AL16UTF16
. importando objetos de SCOTT para SCOTT
. importando objetos de SCOTT para SCOTT
Importação encerrada com sucesso, sem advertências.

C:\>sqlplus scott/tiger

SQL*Plus: Release 10.2.0.1.0 - Production on Sáb Mai 1 17:02:07 2010

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

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

SQL> select segment_name,bytes,extents,initial_extent from user_segments;

SEGMENT_NAME                        BYTES    EXTENTS INITIAL_EXTENT
------------------------------ ---------- ---------- --------------
T1                              134217728         16      134217728


Abaixo, poderemos perceber que não foi possível alocar um único extent, mas 16 para acomodar o segmento T1 na tablespace padrão do usuário SCOTT.

SQL> break on report
SQL> compute sum of bytes on report
SQL> select segment_name,extent_id,bytes,blocks from user_extents;

SEGMENT_NAME                    EXTENT_ID      BYTES     BLOCKS
------------------------------ ---------- ---------- ----------
T1                                      0    8388608       1024
T1                                      1    8388608       1024
T1                                      2    8388608       1024
T1                                      3    8388608       1024
T1                                      4    8388608       1024
T1                                      5    8388608       1024
T1                                      6    8388608       1024
T1                                      7    8388608       1024
T1                                      8    8388608       1024
T1                                      9    8388608       1024
T1                                     10    8388608       1024
T1                                     11    8388608       1024
T1                                     12    8388608       1024
T1                                     13    8388608       1024
T1                                     14    8388608       1024
T1                                     15    8388608       1024
                                          ----------
sum                                        134217728

16 linhas selecionadas.


Após a importação, qual seria a alternativa para desalocar este espaço não utilizado? Poderíamos mover o segmento através do comando ALTER TABLE MOVE ... ou utilizar o comando TRUNCATE TABLE. Neste caso, ambos teriam o mesmo efeito.

SQL> alter table t1 move storage (initial 1);

Tabela alterada.

SQL> select segment_name,bytes,extents,initial_extent from user_segments;

SEGMENT_NAME                        BYTES    EXTENTS INITIAL_EXTENT
------------------------------ ---------- ---------- --------------
T1                                  65536          1          16384


No caso acima, o valor de INITIAL EXTENT caiu de 128 MB para apenas 16 KB. Agora, vem uma outra questão. E se a tabela contiver registros? Veja o exemplo abaixo. Bom, após realizar a criação da tabela T1 novamente com as 10 milhões de linhas e exportar a mesma ... (Lembrando de que COMPRESS=Y é o default)

C:\>exp scott/tiger file=t1.dmp tables=t1

Export: Release 10.2.0.1.0 - Production on Sáb Mai 1 17:18:31 2010

Copyright (c) 1982, 2005, 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 WE8MSWIN1252 e no conjunto de
caracteres de AL16UTF16 NCHAR

Sobre exportar tabelas especificadas ... via Caminho Convencional ...
. . exportando tabela                             T1   10000000 linhas exportadas
Exportação encerrada com sucesso, sem advertências.
 
Após dropar a tabela T1, irei importar o arquivo dump de exportação gerado.

C:\>imp scott/tiger file=t1.dmp full=y

Import: Release 10.2.0.1.0 - Production on Sáb Mai 1 17:20:10 2010

Copyright (c) 1982, 2005, 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.02.01 via caminho convencional
importação realizada nos conjuntos de caracteres WE8MSWIN1252 e NCHAR AL16UTF16
. importando objetos de SCOTT para SCOTT
. importando objetos de SCOTT para SCOTT
. . importando table                           "T1"   10000000 linhas importadas
Importação encerrada com sucesso, sem advertências.

C:\>sqlplus scott/tiger

SQL*Plus: Release 10.2.0.1.0 - Production on Sáb Mai 1 17:23:19 2010

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

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

SQL> select segment_name,bytes,extents,initial_extent from user_segments;

SEGMENT_NAME                        BYTES    EXTENTS INITIAL_EXTENT
------------------------------ ---------- ---------- --------------
T1                              134217728         16      134217728
 
Pronto. Agora irei reinicializar o valor de STORAGE (INITIAL) com o menor valor possível.

SQL> alter table t1 move storage (initial 1);

Tabela alterada.


Atenção! É bom lembrar de que, dependendo do tamanho do segmento, o armazenamento existente da tabela não será dropado até que a tabela seja totalmente realocada (movida) e, para isso, será necessário um espaço livre no tablespace do tamanho da tabela que está sendo movida. Se não houver este espaço livre, então o erro ORA-01652 será emitido pelo Oracle.


SQL> select segment_name,bytes,extents,initial_extent from user_segments;

SEGMENT_NAME                        BYTES    EXTENTS INITIAL_EXTENT
------------------------------ ---------- ---------- --------------
T1                              134217728         87          16384


Bom, após uma nova exportação, o valor de INITIAL EXTENT a ser armazenado no arquivo dump de exportação para o segmento T1 será de 16384 (16 KB) e não mais 128 MB. Vale a pena salientar que após a realocação do segmento, o número de extents mudou de 16 para 87.

É importante lembrar também de que sempre após a execução do comando ALTER TABLE MOVE, sempre será necessário reconstruir os índices porventura existentes e dependentes da tabela em questão.

Por fim, eu não poderia deixar de comentar de que o uso do utilitário de exportação Export Data Pump (expdp) possui cláusulas que resetam qualquer tipo de configuração STORAGE dos segmentos, ou seja, eliminaria qualquer tipo de "problema" envolvendo alocação de espaço, etc... durante uma importação. Isto porque o parâmetro TRANSFORM do utilitário Import Data Pump (impdp) na qual pode ter o valor SEGMENT_ATTRIBUTES ou STORAGE, além de ser utilizado para fazer com que as tabelas também sejam criadas em um outro tablespace de destino, também permite que o valor STORAGE (transform=storage:N:table) remova a cláusula de armazenamento (STORAGE) dos comandos DDL (Data Definition Language) embutidas nos comandos de criação dos segmentos.

Google+

20 comentários:

Daniel Previatti disse...

Boa noite Eduardo! Parabens pelo blog! muito informativo! estou estudando para a cerficação OCP e sempre acompanho seus artigos! abraço!

Eduardo Legatti disse...

Olá Daniel,

Obrigado pelo seu comentário e bons estudos!!

Abraços e até mais ...

David Ricardo disse...

Muito bom Eduardo, já passei por isso também quando trabalhei em uma fábrica de softwares e vivia precisando de estruturas de tabelasd atualizadas. Depois de apanhar algumas vezes para contornar esse problema, eu aprendi que outra maneira além dessa convencional, utilizando o EXP sem a clausula COMPRESS é você utilizar ( se puder e tiver) algum utilitário que extraia o DDL e lhe de a opção de retirar as STORAGE CLAUSULES, ou redefinilas caso sejam importantes para testes. Parabéns pelo Post!!!..Formidável.

Eduardo Legatti disse...

Olá David,

É por isso que o Oracle Datapump é uma mão na roda!!

Abraços e até mais ...

Rodrigo Santana disse...

Olá Eduardo, parabéns por este post. testei o que você abordou e me ajudou a entender melhor como o utilitário de exportação e importação funciona.
Um abraço.

Eduardo Legatti disse...

Olá Rodrigo,

Obrigado pelo comentário e parabéns pelo seu blog ;-)

Abraços e até mais ...

ADMMAN Informática disse...

Olá, Eduardo,

Eu já tinha estado por aqui, mas aproveitei para retornar e lhe agradecer pelos detalhes que demonstrou por aqui. O detalhe é que muitos esquecem de alterar o parâmetro COMPRESS=N (pois o padrão é Y) durante o dump export e com isto durante o processo de dump IMPORT aparecem alguns problemas para importar as tabelas, mesmo quando "há espaço" no tablespace...

Abraços,
Sven

Eduardo Legatti disse...

Olá Sven,

Vamos encontrar ainda muitos Bancos 8i e 9i por aí, na qual a única forma de fazer um dump é via o utilitário Export tradicional (exp). O que me deixa um pouco abismado, é que, mesmo em bases 10g, muitos DBAs continuam insistindo em usar o exp/imp em vez do Datapump Export/Import que é muito mais flexível e poderoso.

Abraços e até mais ...

Priscila Ferreira disse...

Boa Tarde Legatti, ótimo artigo, está de parabéns!
Uma duvida: Qual é a diferença do hash group by e sort group by, qual é o melhor em questão de performance?

Muito obrigada!
Priscila.

Priscila Ferreira disse...

Olá Legatti,
Realmente o Datapump Export/Import é bem melhor do que o exp/imp, porém já ouvi falar que o datapump expdp/impdp só pode ser realizado dentro do servidor que está a base de dados, mas se fizer em outro servidor, tem que fazer o exp/imp independente da versão do Oracle, mesmo as versões 10g e 11g, seria isso mesmo?

Eduardo Legatti disse...

Olá Priscila,

No caso do Datapump Export/Import, o dump é gerado no servidor do banco de dados, ou seja, no local onde o objeto DIRECTORY está apontando (DATA_PUMP_DIR, por exemplo). No entanto, os utilitários do DataPump (expdp/impdp) podem ser executados de qualquer lugar (próprio servidor ou outra máquina).

Se quiser importar um dump que foi gerado em um servidor e importar em outro servidor, é só copiar o dump para o diretório apropriado.

Abraços

Legatti

Eduardo Legatti disse...

Olá Priscila,

Agora você misturou os assuntos ;-) Olha, o HASH GROUP BY é uma operação de agregação baseado no cálculo de valores hash provenientes da colunas que participam de um GROUP BY. O SORT GROUP BY também realiza uma operação de agregação, mas o mesmo realiza operações de ordenação (SORT). Se me lembro bem, até o Oracle 9i existia apenas o SORT GROUP BY. Até o Oracle 9i não era necessário colocar a cláusula ORDER BY após o GROUP BY, pois, por si só, o GROUP BY já fazia a ordenação pelas colunas do GROUP BY. A partir do Oracle 10g R2 o HASH GROUP BY se tornou a operação DEFAULT. Enfim, alguns testes demonstram que o o algoritmo HASH GROUP BY é mais eficiente do que o algoritmo de SORT GROUP BY.

Abraços e até mais ...

Legatti

Priscila Ferreira disse...

Olá Legatti, muito obrigada pelas as respostas, nossa tenho que estudar muito ainda, pois confundi mesmo :(,
Pensei que era assim, com o comando group by, O Oracle tinha a opção de escolher o HASH GROUP BY ou o SORT GROUP BY, pois existe o hint /*+ NO_USE_HASH_AGGREGATION */, para não usar o HASH GROUP BY, com este hint, eu testei, e o Oracle usa o SORT GROUP BY, e sem o hint, o Oracle usa o HASH GROUP BY.
Muito Obrigada desde de já!
Priscila.

Eduardo Legatti disse...

Olá Priscila,

É isso mesmo. Dependendo da função utilizada para realizar a agregação dos dados na instrução SQL, o otimizador pode usar um ou outro algorítimo. Dependendo da versão do Oracle em uso (9i, 10g R1, 10g R2, 11g, 12c) a escolha do algoritmo pelo otimizador pode também ser diferente.

Abraços,

Legatti

Anônimo disse...

Olá Legatti, parabéns pelo o seu artigo.
Uma duvida: A partir do Oracle 11g, o ideal é excluir o parâmetro NEXT da definição da criação de uma tabela ou índice, assim o Oracle o define automaticamente, como faço para excluir este parâmetro ao fazer o exp/imp ou até mesmo expdp/impdp? Para que não precise criar um arquivo .sql para altera-lo manualmente.

Eduardo Legatti disse...

Olá anônimo,

Você encontrou alguma documentação do Oracle 11g que diz que isso seria o ideal? Apenas curiosidade ;-) Bom, se você quer alterar a cláusula NEXT, você pode fazer um ALTER TABLE após importar as tabelas. No caso do exp/imp eu não vejo uma opção. No caso do expdp/impdp, eu falo no final do artigo que o (expdp) possui cláusulas que resetam qualquer tipo de configuração STORAGE dos segmentos, ou seja, eliminaria qualquer tipo de "problema" envolvendo alocação de espaço, etc... durante uma importação. Isto porque o parâmetro TRANSFORM do utilitário Import Data Pump (impdp) na qual pode ter o valor SEGMENT_ATTRIBUTES ou STORAGE, além de ser utilizado para fazer com que as tabelas também sejam criadas em um outro tablespace de destino, também permite que o valor STORAGE (transform=storage:N:table) remova a cláusula de armazenamento (STORAGE) dos comandos DDL (Data Definition Language) embutidas nos comandos de criação dos segmentos.

Então você pode tentar utilizar o parâmetro TRANSFORM.

exemplos:

transform=segment_attributes:n:tables
transform=SEGMENT_ATTRIBUTES:n:table,STORAGE:N:table

Você pode dar uma pesquisada sobre isso ;-)

Abraços,

Legatti

Anônimo disse...

Não pesquisei na documentação da Oracle referente ao parâmetro Next, aqui na empresa há um DBA senior, e ele decidiu que todos os comandos de criação de tabelas e indices sejam excluidos a clausula NEXT, a partir do Oracle 11g, pois o Oracle define automaticamente o que será melhor para ele, então estamos fazendo assim aqui na empresa, a partir do Oracle 11g, todos os comandos de criação são retirados o NEXT, e nos dumps também...
Vou pesquisar na Oracle o que diz a respeito.
Muito obrigado! Você tem me ajudado muito!

Eduardo Legatti disse...

Olá Anônimo,

Favor verificar, pois para tablespaces gerenciados localmente, esse parâmetro é ignorado. Talvez vocês estejam fazendo isso sem necessidade.

"NEXT is ignored with LMT (locally managed tablespaces) because the database automatically manages extents."

Abraços,

Legatti

Anônimo disse...

Então sempre ao criar tabelas e índices, nós excluímos o parâmetro NEXT, para que o Oracle gerencie automaticamente, porém ao visualizar o DDL desses objetos, o parâmetro NEXT sempre aparece com o valor default de 1MB, e ao fazer o dump, sempre aparece este parâmetro, e então temos a necessidade de ficar excluindo este parâmetro manualmente.
Outra duvida: Nesta mesma situação: Ao criar uma constraint e índice único, PK, por exemplo, sempre colocamos USING INDEX no comando add constraint, porém ao visualizar o DDL, o using index não aparece...
Sei que a Oracle recomenda a não criar índice único, que ela mesmo cria automaticamente, porém se tiver algum índice parecido, o índice único não será criado, o Oracle aproveitará um índice, então nós criamos o índice, para que evite ocorrer de Oracle utilizar um índice não único e assim fará um range scan, ao invés de unique scan.
A situação é parecida, ou seja, excluo o parametro NEXT e sempre aparece, e o outro incluo USING INDEX e não aparece esta clausula.
Acho que tem algo estranho...
Muito obrigado!!!
Agradeço desde de já!

Eduardo Legatti disse...

Olá Anônimo,

No caso da PK, durante uma importação, o Oracle irá primeiro criar o índice para depois criar a constraint primary key. Esse comportamento vale tanto para o imp quanto para o impdp.

Neste caso, eu entendo que você não precisa ficar se preocupando com a cláusula USING INDEX depois que a PK já foi criada. ;-)

Dá uma lida no artigo de Novembro/2011 que você vai entender.

http://eduardolegatti.blogspot.com.br/2011/11/desvendando-o-erro-ora-00955-durante.html

Abraços

Legatti

Postagens populares