Voce também poderia utilizar o RMAN a partir de um backupset para gerar o Transport Tablespace (O que não comprometeria a disponibilidade do banco de produção). Isso também ajudaria, se for o seu caso, a contornar o erro ORA-29308. Abraços Alessandro Guimaraes
--- Em oracle_br@yahoogrupos.com.br, "jlchiappa" <jlchia...@...> escreveu > > > Mas chiappa, surgiu uma dúvida... > > vamos lá ... > > > > Com relação ao Transport Tablespace...preciso criar o dump e fazer a > > importação para o novo banco + a copia dos dbf para o novo servidor... > > é, e não esquecendo que esse dump não é de dados, mas sim METADADOS, ie, só > INSERTs nas tabelas internas do bd Oracle informando-o sobre a nova > tablespace... > > > logo, a copia precisa ser fria para a consistencia ne...ou seja...algum > > tempo do banco fora do ar...ou posso dar um off line nas tablespaces que > > serão copiadas, fazendo a copia via SO e deixar o banco no ar ??!! > > na verdade não só pode como DEVE deixar o banco online MAS com as tablespaces > em questão indisponíveis (read-only, se é só leitura já basta pra ele saber > que não terá mudanças nos metadados) : afinal, se vc baixar o banco, > Obviamente o exp.exe ** não ** vai ter acesso às tabelas internas para buscar > o metadado que deve ser copiado... > > []s > > Chiappa > > OBS : again de novo, em msgs anteriores eu Avisei sobre as várias restrições > do tablespace Transport, tais como a necessidade de que os objetos estejam > auto-contidos na mesma tablepace, > http://www.oracle-base.com/articles/9i/TransportableTablespaces9i.php dá uma > mostrada na API que a Oracle disponibiliza para vc ver se a tablespace que vc > quer é Transportável ou não... > > > > > --- Em oracle_br@yahoogrupos.com.br, "jlchiappa" <jlchiappa@> escreveu > > > > > > Ah, e detalhe importante : só pra dar uma noção do que eu falei sobre > > > tempos de transferência (que pega não só na questão de transport, MAS > > > também para transferir os .DMPs de uma máquina pra outra se chegar a > > > isso), veja > > > http://www.macseven.com/files/20070503_external_hard_drive_transfer_speeds.html > > > , é uma comparação com resultados mais próximos ao que se espera : no > > > pior dos piores casos, que é o USB-2, levou pouco menos de 300 segundos > > > pra transferir 3.83 Gb, ou seja, levaria coisa de pouco menos de 15k > > > segundos , ie, 4h e pouco, pra transferir os 190 Gb que falamos - ok, > > > garantido, flutuações ocorrem, mas quando vc fala que em 6 horas ainda > > > não tinha avançado grande coisa só se pode concluir que a tua > > > performance aí está fedorenta... > > > > > > []s > > > > > > Chiappa > > > > > > > > > --- Em oracle_br@yahoogrupos.com.br, "jlchiappa" <jlchiappa@> escreveu > > > > > > > > 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 > > > > > > > > > >
