Eu ja tratei com o pessoal de infra para dar uma olhadinha nisso...ja sugeri inclusive ligarmos la um cabo cross e fazermos esta copia...
Mas chiappa, surgiu uma dúvida... 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...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 ??!! --- Em oracle_br@yahoogrupos.com.br, "jlchiappa" <jlchia...@...> 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 > > >
