Segue :
> estou migrando para um novo servidor (uma lamina Blade) onde todos os paths
> estarão diferentes do que o original.
a idéia do transport era mais adequada se vc quisesse manter a mesma máquina,
aí os arquivos em si não mudariam, só os metadados apontando pros paths seriam
transferidos do origem pro destino....
>> ..na ultima vez que tentei fazer isso (mover 160 GB), demorei cerca de 6
>> horas e nem tinha chegado ainda na metade da copia...ou seja, se tornou
>> inviável...
colega, 160 Gb ** não ** é hoje em dia um volume ultra-absurdo de jeito
nenhum... Isso caberia num disco fast SCSI transportável , vc não tem um aí, ou
possibilidade de adquirir um, se o seu servidor tiver uma porta rápida (SATA-2
externa ou Firewire ?? Diacho, até uma porta USB-2 ligada numa gaveta de disco
com um disco de 7200 rpm ou acima penso que deveria dar conta de transportar
menos de 200 Gb em poucas horas.....
Ou ainda, não tem como o seu pessoal de rede te montar uma rede **** PRIVADA
***, full Gigabit, entre os dois servidores ? Porque performance tão ralé do
tipo de mais de 6h pra nem 200 Gb não me parece boa, parece indicar que vc
estava na rede pública comum, CONCORRENDO com o resto das pessoas, não é isso ?
> - Segundo documentação os SO precisariam ser iguais...e neste caso não
> são...estou utilizando SUSE X RED HAT..
Sim, há uma razão específica pra vc além de mudar de versão (que já é uma
pauleira, já pode dar incompatibilidade) mudar também de SO ? Se houver sim, aí
a idéia de transport fica em geladeira - eu não disse "proibida" pois na
prática, se ambas as distros forem de kernel muito próximo, mesmo bitsize, e
hardware origem/destino semelhantes ao máximo, até deve funcionar transport
entre distros diferentes - recomendo, testa aí com uma ou duas tablespaces
escolhidas, em funcionando veja com o teu pessoal de hardware o que eles podem
fazer pra melhorar o tempo de cópia, se adquirir um disco externo rápido, se
montar uma rede privada direta entre as máquinas, o que der...
> - E objetos de replicação não seriam incluidos neste proesso. Tudo bem que
> poderiams ser recriados mas...
sim, mas são poucos imagino, deve dar pra fazer manualmente...
>
> Por estes motivos, pensei em fazer via tradiconal .DMP mesmo mas precisaria
> alterar todos os paths...no servidor atual, tudo esta concentado em //ORADATA
> (datafiles, indices, redo multiplexados, controlfile multiplex..) e agora,
> seguindo a recomendação OFA, indices em uma unidade chamada /u03, dados em
> uma outra chamada /u02 e assim por diante...
se REALMENTE vc quer/precisa mudar os mountpoints/paths vai dar mais trabalho,
mas é possível : ** SE ** vc conseguiu um modo de copiar os arqs rapidamente
pro destino e o transport funcionou entre as distros diferentes, vc poderia num
primeiro momento ter os datafiles no mesmo path original, depois via ALTER
DATABASE RENAME 'pathedatafile' TO 'novopathedatafile' simplesmente os RENOMEAR
para o novo path, mudar de fs/path/mount-point no mesmo disco/volume/servidor
via de regra é bem rápido...
Já se vc não puder fazer o TS e dumps forem a alternativa, se eu fosse vc
faria mesmo o dump via exp e extrairia os scripts de DDL com o DDL Wizard,
creio que é o mais ´'fácil' a fazer... Sei que o pump tem opções para na hora
da importação vc especificar que a tablespace nnnorigem deve ser 'renomeada'
para nnnDESTINO, fazendo o objeto a ser importado ir pra tablespace nnndestino
independente de como estava no bd origem, mas não usei muito, conslte as docs e
veja se vc consegue os resultados desejados....
[]s
Chiappa
