Menu de navegação

[airoospParticipante]

Boa tarde,

Estou começando a utilizar o datapump, para a fazer a importação de 22057 objetos que foram exportados do schema A da base A.
A importação será feita para o schema B na base B, sendo que a tablespace do schema B é diferente a tablespace do schema A.

Verificando as informações durante o processo de importação, vi que as tabelas do schema A, foram importadas para o schema B respeitando a nova tablespace. Só que os índices que são mais de 17 mil não foram importados para a tablespace do schema B.

A minha pergunta é, como fazer para que os índices sejam importados para a tablespace informada através do parâmetro REMAP_TABLESPACE?

Outra coisa, a importação é lenta mesmo? O arquivo dump tem 8.3GB.

Os dois bancos de dados são 10g em Windows.

Obrigado.

Airton

[José Laurindo ChiappaModerador]

Começando pela questão do REMAP : note que, quando vc diz “a tablespace do schema B é diferente a tablespace do schema A” isso ** NÃO COMPUTA ** : absolutamente ** não é verdade ** que uma tablespace seja DESIGNADA/RELACIONADA com um schema, não : um usuário qualquer vai ter o seu schema, e esse schema pode ser composto por UMA, DUAS, OU 500 TABLESPACES, sim sim ???? No máximo o que existe é a TABLESPACE DEFAULT do usuário/schema, que é aquela que será usada se NENHUMA TABLESPACE for informada, mas só – REPITO, “tablespace DO SCHEMA” não faz sentido….
Para vc fazer o REMAP sim, basta vc icnluir o parâmetro, mas POR FAVOR NOTE que vc ** TEM ** que indicar TODAS as tablespaces a remapear : se um dado schema tiver objetos criados naS tablespaces A, B e C (digamos), e vc quer que o import os recrie nas tablespaces X, Y e Z vc ** TEM ** que indicar REMAP_TABLESPACE=A:X,B:Y,C:Z , sem faltar NENHUMA…. E para mudar de SCHEMA vc precisa do REMAP_SCHEMA….
Veja http://oraclejunior.blogspot.com.br/2011/05/data-pump-com-remapschema-e.html para um exemplo de ambos que (ao que entendo) é o seu caso….

E alguns detalhes ** IMPORTANTES **, absolutamente ** CRÍTICOS mesmo nesse cenário que vc descreve :

=> o import de um schema ** NÂO VAI CRIAR PARA VOCÊ ** as tablespaces, ele assume que as tablespaces TODINHAS já estão criadas no banco de destino

=> da mesma maneira, o IMPORT *** não ** vai aumentar de tamanho as tablespaces, é por sua conta CONFIRMAR que as tablespaces a remapear além de criadas estão com um TAMANHO / ESPAÇO LIVRE adequado e suficiente

=> como vc vai MUDAR DE DONO os objetos e ainda por cima de tablespace, o usuário que está fazendo o IMPORT ** TEM ** que ter Quota ilimitada (ou ao menos grande o suficiente) nas tablespaces a se usar, TEM que ter privilégios de criar qualquer tabela em qualquer schema … Via de regra se esse usuário que está fazendo o import receber as roles de CONNECT, RESOURCE, EXP_FULL_DATABASE e FLASHBACK ANY TABLE isso já é suficiente, ele Não Precisa (nem deve) receber SYSDBA, ** a não ser ** que (contra a norma geral) tenha sido usado um usuário com poder de SYSDBA pra fazer o export

E eu acho **** Extremamente recomendável **** que vc, ANTES de fazer o import dos dados, gere um ARQUIVO-TEXTO com os CREATE TABLE/CREATE INDEX que serão efetivados pelo import de dados, Justamente para conferir que os REMAPs todos foram OK, e ** SEM ** ler os dados (só nos interessa nesta verificação os CREATEs)… Para isso, vc usaria algo do tipo :

impdp usuário/senha CONTENT=METADATA_ONLY DIRECTORY=nomedodiretório dumpfile=nomedodumpfile.dmp logfile=nomedologdecomandos.log sqlfile=nomedoarquivotexto.sql remap_schema=SCHEMAORIGEM:SCHEMADESTINO remap_tablespace=tablespaceorigem:tablespacedestino,outratablespaceorigem:outratablespacedestino, aindaoutratablespaceorigem:aindaoutratablespacedestino…quantas tablespaces forem necessárias…

Isso feito (sem precisar ler & importar os dados isso não deve demorar muito demais), aí vc abre o arquivotexto.sql num editor de texto e vê se foi tudo certinho…

Sobre a performance, a ** PRIMEIRA COISA ** que vc tem que fazer é se ASSEGURAR que vc está com o último patchset/pacote de correções de BUGs da sua versão : diversos BUGs existiram que podiam/podem atrapalhar a performance, como o Bug 19520061 – impdp extremely slow import for a partioned table, o BUG:18843775 – PARALLEL IMPDP SLOW AT PARTITIONED TABLES WHEN NLS CONVERSION FINDS PLACE e uns tantos outros… CONSULTE no Suporte Oracle a documentação e detalhes desses e de outros bugs relacionados com import…

Uma vez que vc se assegurou disso, os principais pontos que interferem na Performance do impdp são :

a. settings de database OU de sessão diferentes no destino em relação à origem) : principalmente se o CHARACTERSET for diferente, uma CONVERSÃO vai ter que ser feita, e isso pode causar demora – não faça isso, se Assegure que os settings de sessão E do database-destino são Rigorosamente os Mesmos

b. ausência de uma tablespace TEMPORÁRIA e de uma tablespace de UNDO ** gigantescas ** : principalmente na criação de índices o Oracle usa muito espaço temporário, E a presença de tablespace de UNDO com generoso espaço livre pode ajudar na performance em geral

c. serialização : por default um único processo de exportação vai gerar um um arquivo sequencial, com um CREATE TABLE A, depois dele um CREATE INDEX A1, depois um create index A2, um por vez – nesse cenário, só depois que o CREATE TABLE A é que o banco recebe e começa a executar o CREATE INDEX A1, só depois que A1 acabar ele passa para a próxima linha do dumpfile e começa a criar A2….
TIPICAMENTE, um servidor de Produção tem TOTAL CAPACIDADE para executar em paralelo múltiplos DDLs ao mesmo tempo…

d. validação das constraints : se as tabelas tiverem constraints (normalmente tem), para CADA registro inserido o RDBMS ** tem ** que varrer a tabela para ver se o registro está violando constraints… ORA, nesse cenário em particular vc NÂO ESTÁ INSERINDO dados manualmente no banco-destino, mas sim Importando dados que (Logicamente) já tinham sido validados na origem – nessa situação, esse Esforço do import em validar o que já foi validado na origem é PURO DESPERDÍCIO de cliclos de CPU e de I/O

e. PGA setada para um valor baixo : principalmente na questão da ORDENAÇÃO que um índice necessita, o mais que vc possa dar pro import de área de memória é melhor, é mais chance de ele conseguir fazer ao menos parte das suas Ordenações em memória

f. não uso de Parallel DDL na criação de índices : por questão de economia de recursos normalmente o impdp Não Faz paralelismo nos CREATE INDEX

A recomendação então para a melhor performance , evitando os pontos acima seria portanto :

1. fazer a importação num momento em que o uso do database esteja ** BAIXO ** (para que sobrem recursos de hardware pra sua importação)

2. se ASSEGURAR que os settings que não controlam nem RAM nem CPU (tanto de banco quanto das sessões que for abrir) estão idênticos à Produção

3. ter o máximo possível de espaço livre na temp e na undo tablespace no banco destino, E que ambas tablespaces estejam no maior tamanho possível

4. DESLIGAR no banco-destino qualquer tipo de Replicação, JOB de banco, enfim, qualquer tarefa não-essencial, para sobrar recursos pros imports – PREFERENCIALMENTE, remover o acesso dos usuários finais ao banco onde será feito o import

5. na exportação, gerar múltiplos dumpfiles separados, cada um com parte das tabelas (SOMENTE DADOS das tabelas, sem índices nem constraints), para que depois vc os possa importar simultaneamente, abrindo várias janelas/prompts de comando, cada um deles importando um dos dumpfiles de dados

6. UMA VEZ que as importações dos dados todos acabou, extrair (com o uso do SQLFILE) os CREATE INDEX e ADD CONSTRAINTS todos

7. alterar os CREATE INDEX para que eles incluam uma cláusula PARALLEL nnn e uma cláusula NOLOGGING. nnn é a quantidade de parallel slaves, vai depender da capacidade do seu hardware

8. salve os CREATE INDEX em múltiplos arquivos texto com a extensão .SQL,

9. alterar os DDLs de constraints para que as criem com ENABLE NOVALIDATE, de modo que os dados que vieram do banco-origem e já foram inseridos corretamente NÂO SEJAM validados, poupando o esforço

10. salve os ADD CONSTRAINTS em outros arquivos-texto .SQL

11. abra múltiplas janelas, em cada uma delas abrindo uma sessão sqlplus

12. em cada sessão de sqlplus, sete o gerenciamento de memória de trabalho para controle manual via ALTER SESSION SET WORKAREA_SIZE_POLICY = MANUAL; sete o espaço para SORTs e HASHes o maior possível que seja viável (via ALTER SESSION SET SORT_AREA_SIZE = xxx; e ALTER SESSION SET HASH_AREA_SIZE = dobrodeXXX; , e também Habilite parallel SQL com ALTER SESSION ENABLE PARALLEL DDL; ALTER SESSION ENABLE PARALLEL DML; ALTER SESSION ENABLE PARALLEL QUERY;

13. em cada sqplus execute um dos arquivos .SQL com os CREATE INDEX

14. em cada janela sqlplus execute um dos arquivos .SQL com os comandos de constraints

E é isso, este é o procedimento com topo de eficiência : para uma idéia de performance, usando os pontos todos acima tenho visto a importação de um dumpfile com alguns GBs levar por volta de uma hora, então esperaria o seu dumpfile de 8 GB que vc cita levar coisa de uma hora e meia…. è + ou – esse tipo de Performance que vc pode esperar do impdp…
DEPENDENDO (Óbvio) da capacidade do teu hardware isso pode cair um pouco mais ou pouco menos….

[]s

Chiappa

[Autor]

Posts