Blz ? Bem, antes de responder eu quero deixar ** escrupulosamente Claro ** que
é Total e Completamente Contra-Recomendado vc depender só de exports como
rotina de backup : como eu e n outros especialistas já disseram
(http://www.fabioprado.net/2011/03/serie-rman-parte-1-entendendo-o-rman.html é
só UM dos muitos artigos), export NÃO copia os dados internos do banco (se vc
crashar servidor ou tiver coisa do tipo, vc TEM que criar um banco vazio NA MÃO
pra obter dados internos, pra só depois poder fazer o import), NÃO permite
backups incrementais multilevel, NÃO permite paralelismo completo - enfim, NÂO
DÁ PRA CONFIAR só nele, falando bem francamente... Pra mim backup REAL é com
RMAN, "backup" com export (seja datapump seja exp tradicional!!) só mesmo como
um COMPLEMENTO ao backup principal, feito com RMAN... Okdoc ??
Isso posto, aí vem a sua resposta :
a) é Muitíssimo Possível um export de LOBs ser mais lento do que o RMAN, pois
enquanto o RMAN só copia os blocos das tablespaces e pronto, o export FUNCIONA
COM SELECTs, e um SELECT que referencia um LOb ** tem ** que abrir o LOB pra
obter um file handle (com DBMS_LOB.OPEN), tem que ir lendo um fluxo de bytes
via DBMS_LOB.READ ( e se esse fluxo estiver uma parte num bloco e outra parte
noutro bloco, ambos os blocos tem que ser LOCALIZADOS via pesquisa no
dicionário de dados), o que consome TEMPO e esforço também... Não dá pra
comparar com a lógica do RMAN que é ir pro início do datafile e simplesmente ir
lendo pedações de blocos contíguos, SEM lógica NENHUMA envolvida
Então, se teus LOBs são longos e complexos, Analise Com Carinho a
possibilidade de os backupear com RMAN - nem que seja via TRANSPORTABLE
TABLESPACES, backupeando apenas as tablespaces aonde residem os LOBs em
questão, se elas são SEPARADAS das tablespaces de dados (o que deveriam ser)
b) SE por qquer motivo vc for TIVER que continuar fazendo export desses LOBs,
analise COM MUITO CUIDADO a nota metalink , em especial os pontos sobre CURSOR
SHARING, Paralelismo (seja Parallel SQL, seja'paralelismo manual', com
múltiplas sessões cada uma fazendo export de uma parte dos dados, etc) e Bugs
como o 13609098 : este bug já foi fechado em versão anterior ao 12c que vc
disse estar usando, mas Cheque com o Suporte a possibilidade de ser uma volta
dele aí no seu ambiente
Igualmente, use os recursos indicados na nota em questão E na documentação
Oracle (tais como o parâmetro STATUS, um LOGFILE, pesquisa nas V$ joineadas com
dba_datapump_sessions enquanto o expdp tá rodando, params de TRACE e/ou Metrics
cfrme mostrado em
https://juliandontcheff.wordpress.com/2011/12/20/on-4-undocumented-datapump-parameters/
- estes com a Apoio do Suporte Oracle -, etc) para tentar IDENTIFICAR o ponto
causador de lentidão...
c) Ainda pensando em 'debug' do expdp, experimente criar duas tablespaces o
melhor ajustadas possível (uma pra tabela E outra pro LOB segment), crie uma
tabela contendo um LOB nessas tablespaces (com o CHUNK SIZE mais apropriado
possível, etc) e insira dados num volume similar ao LOB que apresenta demora :
se um export da nova tabela for significativamente mais rápido, fica Comprovada
alguma issue física na tablepace ou no LOB original - talvez algum tipo de
fragmentação, talvez um chunk size muito grande ou muito pequeno, algum tipo de
Concorrência forte de outras sessões Tente lá e veja o que vc consegue
nesse sentido...
[]s
Chiappa
