Re: [oracle_br] Re: Oralce 11g express com c# - visual studio 2015 community

[afonso moreira afonso_jalmore...@yahoo.com [oracle_br]]

Grande Chioappa, sempre gentil  prestativo. Vou fawr um resumao de tudo e posto 
aqui
muito Obrigado Abraços Afonso Jose Moreira 

On Wednesday, September 21, 2016 4:00 PM, "jlchia...@yahoo.com.br 
[oracle_br]"  wrote:
 

     Bom, eu não uso isso mas antes de mais nada os detalhes please : se vc 
está usando o Visual Studio, vc baixou e instalou o "Oracle developer Tools" 
para ele cfrme 
http://www.oracle.com/technetwork/topics/dotnet/downloads/odacmsidownload-2745497.html
 ? Vc tá usando EXATAMENTE O QUE para conectar no banco, Oracle Data Provider ? 
Se sim, checou os cursos/artigos sobre ele em 
https://apexapps.oracle.com/pls/apex/f?p=44785:24:0::NO:24:P24_CONTENT_ID:13260 
, e EM ESPECIAL o "Getting Started with Oracle Data Provider for .NET (C# 
Version)" ? 
 E importante : iirc esses coisos aí de ODAC são *** absolutamente incapazes 
*** de conectar no banco Oracle por si sós, eles PRECISAM montar em cima do 
Oracle client , que TEM QUE ESTAR instalado e configurado Vc TEm o client 
Oracle instalado direitinho aí, né ? Vc consegue conectar no banco Oracle pelo 
Oracle client ???
 
 Se nenhuma destas refs te ajudar, manda numa próxima mensagem os ** detalhes 
** todos do banco (principalmente se ele é 32 ou 64 bits, e a versão EXATA dele 
- só 'Express Edition' é insuficiente, creio) E do client Oracle 
(principalmente, se ele é 32 ou 64 bits, eu já vi uns probs de 
incompatibilidade de client 32-bits conectando em database 64-bits num SO de 64 
bits), bem como uns printscreens (sobe eles num serviço de compartilhamento e 
manda os links) mostrando como vc configurou o VS, que quem usar a ferramenta 
pode tentar te ajudar mais...
 
 []s
 
   Chiappa
    #yiv8330244727 #yiv8330244727 -- #yiv8330244727ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv8330244727 
#yiv8330244727ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv8330244727 
#yiv8330244727ygrp-mkp #yiv8330244727hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv8330244727 #yiv8330244727ygrp-mkp #yiv8330244727ads 
{margin-bottom:10px;}#yiv8330244727 #yiv8330244727ygrp-mkp .yiv8330244727ad 
{padding:0 0;}#yiv8330244727 #yiv8330244727ygrp-mkp .yiv8330244727ad p 
{margin:0;}#yiv8330244727 #yiv8330244727ygrp-mkp .yiv8330244727ad a 
{color:#ff;text-decoration:none;}#yiv8330244727 #yiv8330244727ygrp-sponsor 
#yiv8330244727ygrp-lc {font-family:Arial;}#yiv8330244727 
#yiv8330244727ygrp-sponsor #yiv8330244727ygrp-lc #yiv8330244727hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv8330244727 
#yiv8330244727ygrp-sponsor #yiv8330244727ygrp-lc .yiv8330244727ad 
{margin-bottom:10px;padding:0 0;}#yiv8330244727 #yiv8330244727actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv8330244727 
#yiv8330244727activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv8330244727
 #yiv8330244727activity span {font-weight:700;}#yiv8330244727 
#yiv8330244727activity span:first-child 
{text-transform:uppercase;}#yiv8330244727 #yiv8330244727activity span a 
{color:#5085b6;text-decoration:none;}#yiv8330244727 #yiv8330244727activity span 
span {color:#ff7900;}#yiv8330244727 #yiv8330244727activity span 
.yiv8330244727underline {text-decoration:underline;}#yiv8330244727 
.yiv8330244727attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv8330244727 .yiv8330244727attach div a 
{text-decoration:none;}#yiv8330244727 .yiv8330244727attach img 
{border:none;padding-right:5px;}#yiv8330244727 .yiv8330244727attach label 
{display:block;margin-bottom:5px;}#yiv8330244727 .yiv8330244727attach label a 
{text-decoration:none;}#yiv8330244727 blockquote {margin:0 0 0 
4px;}#yiv8330244727 .yiv8330244727bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv8330244727 
.yiv8330244727bold a {text-decoration:none;}#yiv8330244727 dd.yiv8330244727last 
p a {font-family:Verdana;font-weight:700;}#yiv8330244727 dd.yiv8330244727last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv8330244727 
dd.yiv8330244727last p span.yiv8330244727yshortcuts 
{margin-right:0;}#yiv8330244727 div.yiv8330244727attach-table div div a 
{text-decoration:none;}#yiv8330244727 div.yiv8330244727attach-table 
{width:400px;}#yiv8330244727 div.yiv8330244727file-title a, #yiv8330244727 
div.yiv8330244727file-title a:active, #yiv8330244727 
div.yiv8330244727file-title a:hover, #yiv8330244727 div.yiv8330244727file-title 
a:visited {text-decoration:none;}#yiv8330244727 div.yiv8330244727photo-title a, 
#yiv8330244727 div.yiv8330244727photo-title a:active, #yiv8330244727 
div.yiv8330244727photo-title a:hover, #yiv8330244727 
div.yiv8330244727photo-title a:visited {text-decoration:none;}#yiv8330244727 
div#yiv8330244727ygrp-mlmsg #yiv8330244727ygrp-msg p a 
span.yiv8330244727yshortcuts 
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv8330244727 
.yiv8330244727green 

Re: [oracle_br] Migração

[Sérgio Luiz Rodrigues Chaves sergio.cha...@elumini.com.br [oracle_br]]

Rafael,




Você realmente precisa saber o downtime, para definir qual a melhor solução 
para você.
Mas também é importante saber quanto eles querem gastar.
Recentemente passei por situações semelhantes:


  1.  Migração de HP(9i) para ORACLE EXADATA (11R2);
  2.  E De IBM AIX(11gR2)  para ORACLE EXADATA( 11R2);










Na primeira situação utilizamos duas estratégias: Na primeira utilizam o Golden 
Gate, sem downtime, a base tinha mais ou menos o 2.5 TB;


Na segunda utilizamos data dump bases menores.






Na segunda utilizamos Export / Import.






Mas tudo isso vai depender dos servidores de destino, como não sabemos  
fica difícil informar qual a melhor solução. Ainda podemos estudar a utilização 
do RMAN.










Boa sorte.






Sérgio.





De: oracle_br@yahoogrupos.com.br  em nome de 
Rafael Mendonca raffaell.t...@yahoo.com [oracle_br] 

Enviado: quarta-feira, 21 de setembro de 2016 14:24:00
Para: oracle_br@yahoogrupos.com.br
Assunto: Re: [oracle_br] Migração






Ontem por algum motivo não estava sendo possível o envio de email para o grupo, 
portanto foram enviados dois e-mails, favor desconsiderar o outro email, vamos 
usar este aqui e ignorar o outro.




Em Quarta-feira, 21 de Setembro de 2016 14:16, "Rafael Mendonca 
raffaell.t...@yahoo.com [oracle_br]"  escreveu:






Senhores, boa tarde.


Gostaria da ajuda de vocês para o seguinte cenário:


Um cliente solicitou que um SGBD Oracle EE 11.2.0.4.16 ASM standalone em um 
ambiente de produção em um sistema operacional AIX 6.1 64 bits ( que também 
possui dois DATAGUARDS Físicos com a mesma configuração) fosse migrado para um 
outro servidor LInux Redhat 6.x ou 7.0 64 bits. O tamanho da base é de 2,4 TB.



Gostaria de saber de vocês qual seria o melhor modo de se fazer essa migração.


Obs1: O tempo de downtime não foi informado, mas acho que o cliente teria um 
dia do final de semana livre para realizar essa tarefa.


Alguém poderia ajudar?

Re: [oracle_br] Migração

[jlchia...@yahoo.com.br [oracle_br]]

Bom, antes de mais nada o cliente tá Sabendo que esses dataguards ** vão ter 
que ser refeitos ** em servidores Linux pra alinhar com esse novo Linux prod, 
né ? de acordo com a nota "Data Guard Support for Heterogeneous Primary and 
Physical Standbys in Same Data Guard Configuration" (Doc ID 413484.1) mesmo 
sendo rigorosamente a mesma versão de software RDBMS (é o mínimo que se pede 
numa Migração) não é suportado DG físico entre AIX e Linux Isso também ** 
ELIMINA ** a Possibilidade de ter o Linux como uma réplica a mais, remover o 
AIX e depois promover o Linux para Primary

 Muito bem : a sua resposta só pode ser DEPENDE, pois :
 
 ==> certamente o database deve residor num STORAGE : é tecnicamente possível 
vc fazer o novo servidor Linux reconhecer/acessar esse storage ? Se sim, talvez 
vc poderia simplesmente baixar a instância e fechar o banco no AIX, e uma vez 
que o Linux tiver uma instãncia e conseguir acessar os datafiles, vc 
simplesmente os CONVERTE para o formato Linux, provavelmente via RMAN com 
comando CONVERT - isso seria Excelente pois vc pouparia o tempo de enviar pela 
rede os dados e/ou os datafiles pro novo servidor Linux, potencialmente 
cortando MUITO tempo do cronograma Outra opção nesse sentido caso o novo 
servidor vá usar outras LUNs no mesmo stirage seria vc copiar/transferir os 
datafiles via utilitários do storage, depois fazendo a Conversão necessária... 
 
 ==> vc diz que a base é de 2.4 Tb : tá bem, mas a maior parte desse volume 
está em relativamente poucas tabelas ? Há link de rede RÁPIDO entre os dois 
servidores ? Ambos os servidores possuem múltiplas CPUs e ampla capacidade  de 
I/O ? 
  Se a resposta for SIM para todas as questões, vc poderia ter algumas tantas 
sessões fazendo INSERT /*+ APPEND */ into tabela@databaselink com o maior grau 
de paralelismo possível, o resto vc exporta/importa os dados (apenas dados!!) e 
extrai os DDLs para recriar índices em paralelo e constraints em NOVALIDATE...
  
 ==> se o volume não tiver a distribuição acima mas o link de rede rápido e 
confiável existir, outra opção (para minimizar o tempo de downtime mas 
provavelmente Aumentar o tempo total do procedimento) seria replicar os dados 
da origem pra um banco-destino que vc criaria - se vc tiver a Licença isso pode 
ser feito via Goldengate, se não vc poderia (SE as restrições de datatype e 
quetais não interferirem) usar Streams
 
 ==> as opções anteriores não sendo viáveis, aí caímos nos procedimentos de 
migração mesmo, ie, vc vai transferir (alguns ou todos) datafiles da origem pro 
destino e lá os converter para o formato Linux   SE fossem SOs com o mesmo 
endian order vc teria a opção de usar os comandos de CONVERT DATABASE do RMAN, 
ou mesmo simplesmete RESTAURAR um backup da origem e o converter no destino -  
vide nota metalink "RMAN DUPLICATE/RESTORE/RECOVER Mixed Platform Support" (Doc 
ID 1079563.1) e os manuais Oracle (especialmente o manual "Database Backup and 
Recovery User's Guide" no cap. 25 Transporting Data Across Platforms) mas como 
AIX e Linux tem endian order diferentes, nada feito, só sobra o TRANSPORTABLE 
TABLESPACE...
  
  Veja a nota metalink "11G - Reduce Transportable Tablespace Downtime using 
Cross Platform Incremental Backup" (Doc ID 1389592.1) para refs e algumas 
melhorias havidas (como os backups incrementais para transporte), e 
http://www.dside-software.com/tech-news/cross-platform-oracle-migration-with-rman-convert-and-transportable-tablespaces/
 tem um exemplinho...
  
  []s

  Chiappa
  
OBS : 

1. iirc a restrição de conversão/restore de database cross platform mudou 
no 12c mas no 11G que vc tem e (ao que entendo) vai continuar a usar ainda é 
tal como eu falei acima

2. há outras opções de standby (como por exemplo o Shareplex) que vc pode 
investigar - não sei como está hoje em dia o Suporte delas pra standby 
cross-platform mas veja lá...

[oracle_br] Re: Oralce 11g express com c# - visual studio 2015 community

[jlchia...@yahoo.com.br [oracle_br]]

Bom, eu não uso isso mas antes de mais nada os detalhes please : se vc está 
usando o Visual Studio, vc baixou e instalou o "Oracle developer Tools" para 
ele cfrme 
http://www.oracle.com/technetwork/topics/dotnet/downloads/odacmsidownload-2745497.html
 ? Vc tá usando EXATAMENTE O QUE para conectar no banco, Oracle Data Provider ? 
Se sim, checou os cursos/artigos sobre ele em 
https://apexapps.oracle.com/pls/apex/f?p=44785:24:0::NO:24:P24_CONTENT_ID:13260 
, e EM ESPECIAL o "Getting Started with Oracle Data Provider for .NET (C# 
Version)" ? 
 E importante : iirc esses coisos aí de ODAC são *** absolutamente incapazes 
*** de conectar no banco Oracle por si sós, eles PRECISAM montar em cima do 
Oracle client , que TEM QUE ESTAR instalado e configurado Vc TEm o client 
Oracle instalado direitinho aí, né ? Vc consegue conectar no banco Oracle pelo 
Oracle client ???
 
 Se nenhuma destas refs te ajudar, manda numa próxima mensagem os ** detalhes 
** todos do banco (principalmente se ele é 32 ou 64 bits, e a versão EXATA dele 
- só 'Express Edition' é insuficiente, creio) E do client Oracle 
(principalmente, se ele é 32 ou 64 bits, eu já vi uns probs de 
incompatibilidade de client 32-bits conectando em database 64-bits num SO de 64 
bits), bem como uns printscreens (sobe eles num serviço de compartilhamento e 
manda os links) mostrando como vc configurou o VS, que quem usar a ferramenta 
pode tentar te ajudar mais...
 
 []s
 
   Chiappa
  

[oracle_br] Oralce 11g express com c# - visual studio 2015 community

[afonso_jalmore...@yahoo.com [oracle_br]]

Ola boa tarde amigos
 

 Estou tentando acessar o bando de dados orcle 11g expresso através do c# porem 
estou tendo problemas na conexão, faco igual a exemplos porem não funciona, e 
sei que tenho que instal o odp.net, porem mesmo com isso instalado o c# 
estranha os comandos que dou particulares do oracle. Alguem tem um passo a 
passo e alguma dica pra dar sobre ser ou não problemas de versão .
 

 abraços
 afonso
 A j Moreira informática
 dell inspiron 14 2330 64 bits 8 gb ram
 Windows 7 enterprise

Re: [oracle_br] Migração

[Fabricio Pedroso Jorge fpjb...@gmail.com [oracle_br]]

Se tiver licença do Goldengate, essa seria a melhor opção, sem downtime.

Via RMAN, como você está usando "endian formats" (AIX -> Linux) diferentes,
teria que realizar o CONVERT dos datafiles, o que aumentaria o tempo de
migração.

Em 21 de setembro de 2016 14:16, Rafael Mendonca raffaell.t...@yahoo.com
[oracle_br]  escreveu:

>
>
> Senhores, boa tarde.
>
> Gostaria da ajuda de vocês para o seguinte cenário:
>
> Um cliente solicitou que um SGBD Oracle EE 11.2.0.4.16 ASM standalone em
> um ambiente de produção em um sistema operacional AIX 6.1 64 bits ( que
> também possui dois DATAGUARDS Físicos com a mesma configuração) fosse
> migrado para um outro servidor LInux Redhat 6.x ou 7.0 64 bits. O tamanho
> da base é de 2,4 TB.
>
> Gostaria de saber de vocês qual seria o melhor modo de se fazer essa
> migração.
>
> Obs1: O tempo de downtime não foi informado, mas acho que o cliente teria
> um dia do final de semana livre para realizar essa tarefa.
>
> Alguém poderia ajudar?
>
> 
>



-- 
*Fabrício Pedroso Jorge.*

Administrador de Banco de Dados

certificacaobd.com.br 

*Resumo Profissional:*
http://br.linkedin.com/in/fabriciojorge

*Contatos:*
+ 55 91 988991116
skype: fabricio.pedroso.jorge
fpjb...@gmail.com

Re: [oracle_br] Migração

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Ontem por algum motivo não estava sendo possível o envio de email para o grupo, 
portanto foram enviados dois e-mails, favor desconsiderar o outro email, vamos 
usar este aqui e ignorar o outro.
 

Em Quarta-feira, 21 de Setembro de 2016 14:16, "Rafael Mendonca 
raffaell.t...@yahoo.com [oracle_br]"  escreveu:
 

     Senhores, boa tarde. 

Gostaria da ajuda de vocês para o seguinte cenário:
Um cliente solicitou que um SGBD Oracle EE 11.2.0.4.16 ASM standalone em um 
ambiente de produção em um sistema operacional AIX 6.1 64 bits ( que também 
possui dois DATAGUARDS Físicos com a mesma configuração) fosse migrado para um 
outro servidor LInux Redhat 6.x ou 7.0 64 bits. O tamanho da base é de 2,4 TB. 

Gostaria de saber de vocês qual seria o melhor modo de se fazer essa migração.
Obs1: O tempo de downtime não foi informado, mas acho que o cliente teria um 
dia do final de semana livre para realizar essa tarefa.
Alguém poderia ajudar?

  #yiv3603839272 #yiv3603839272 -- #yiv3603839272ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv3603839272 
#yiv3603839272ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv3603839272 
#yiv3603839272ygrp-mkp #yiv3603839272hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv3603839272 #yiv3603839272ygrp-mkp #yiv3603839272ads 
{margin-bottom:10px;}#yiv3603839272 #yiv3603839272ygrp-mkp .yiv3603839272ad 
{padding:0 0;}#yiv3603839272 #yiv3603839272ygrp-mkp .yiv3603839272ad p 
{margin:0;}#yiv3603839272 #yiv3603839272ygrp-mkp .yiv3603839272ad a 
{color:#ff;text-decoration:none;}#yiv3603839272 #yiv3603839272ygrp-sponsor 
#yiv3603839272ygrp-lc {font-family:Arial;}#yiv3603839272 
#yiv3603839272ygrp-sponsor #yiv3603839272ygrp-lc #yiv3603839272hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv3603839272 
#yiv3603839272ygrp-sponsor #yiv3603839272ygrp-lc .yiv3603839272ad 
{margin-bottom:10px;padding:0 0;}#yiv3603839272 #yiv3603839272actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv3603839272 
#yiv3603839272activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv3603839272
 #yiv3603839272activity span {font-weight:700;}#yiv3603839272 
#yiv3603839272activity span:first-child 
{text-transform:uppercase;}#yiv3603839272 #yiv3603839272activity span a 
{color:#5085b6;text-decoration:none;}#yiv3603839272 #yiv3603839272activity span 
span {color:#ff7900;}#yiv3603839272 #yiv3603839272activity span 
.yiv3603839272underline {text-decoration:underline;}#yiv3603839272 
.yiv3603839272attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv3603839272 .yiv3603839272attach div a 
{text-decoration:none;}#yiv3603839272 .yiv3603839272attach img 
{border:none;padding-right:5px;}#yiv3603839272 .yiv3603839272attach label 
{display:block;margin-bottom:5px;}#yiv3603839272 .yiv3603839272attach label a 
{text-decoration:none;}#yiv3603839272 blockquote {margin:0 0 0 
4px;}#yiv3603839272 .yiv3603839272bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv3603839272 
.yiv3603839272bold a {text-decoration:none;}#yiv3603839272 dd.yiv3603839272last 
p a {font-family:Verdana;font-weight:700;}#yiv3603839272 dd.yiv3603839272last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv3603839272 
dd.yiv3603839272last p span.yiv3603839272yshortcuts 
{margin-right:0;}#yiv3603839272 div.yiv3603839272attach-table div div a 
{text-decoration:none;}#yiv3603839272 div.yiv3603839272attach-table 
{width:400px;}#yiv3603839272 div.yiv3603839272file-title a, #yiv3603839272 
div.yiv3603839272file-title a:active, #yiv3603839272 
div.yiv3603839272file-title a:hover, #yiv3603839272 div.yiv3603839272file-title 
a:visited {text-decoration:none;}#yiv3603839272 div.yiv3603839272photo-title a, 
#yiv3603839272 div.yiv3603839272photo-title a:active, #yiv3603839272 
div.yiv3603839272photo-title a:hover, #yiv3603839272 
div.yiv3603839272photo-title a:visited {text-decoration:none;}#yiv3603839272 
div#yiv3603839272ygrp-mlmsg #yiv3603839272ygrp-msg p a 
span.yiv3603839272yshortcuts 
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv3603839272 
.yiv3603839272green {color:#628c2a;}#yiv3603839272 .yiv3603839272MsoNormal 
{margin:0 0 0 0;}#yiv3603839272 o {font-size:0;}#yiv3603839272 
#yiv3603839272photos div {float:left;width:72px;}#yiv3603839272 
#yiv3603839272photos div div {border:1px solid 
#66;min-height:62px;overflow:hidden;width:62px;}#yiv3603839272 
#yiv3603839272photos div label 
{color:#66;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv3603839272
 #yiv3603839272reco-category {font-size:77%;}#yiv3603839272 
#yiv3603839272reco-desc {font-size:77%;}#yiv3603839272 .yiv3603839272replbq 
{margin:4px;}#yiv3603839272 #yiv3603839272ygrp-actbar div a:first-child 
{margin-right:2px;padding-right:5px;}#yiv3603839272 #yiv3603839272ygrp-mlmsg 

[oracle_br] Migração

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

 blockquote, div.yahoo_quoted { margin-left: 0 !important; border-left:1px 
#715FFA solid !important; padding-left:1ex !important; background-color:white 
!important; }  Senhores, boa tarde.Um cliente solicitou a migração de uma base 
Oracle enterprise edition 11.2.0.4.16 ASM stand alone em um SO AIX 6.1 64 bits 
pra um Linux redhat 7 ou 6 64 bits. A base tem um tamanho de 2,3 TB. Gostaria 
de saber de vocês qual seria o melhor procedimento para realizar essa tarefa.
Obs: em relação ao downtime, o cliente ainda não forneceu informações a 
respeito (estou no aguardo), porém acho que um dia no final de semana de 
indisponibilidade não seria problema, infelizmente não tenho certeza do tempo. 


Enviado do Yahoo Mail para iPhone
 

[oracle_br] Migração

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Senhores, boa tarde. 

Gostaria da ajuda de vocês para o seguinte cenário:
Um cliente solicitou que um SGBD Oracle EE 11.2.0.4.16 ASM standalone em um 
ambiente de produção em um sistema operacional AIX 6.1 64 bits ( que também 
possui dois DATAGUARDS Físicos com a mesma configuração) fosse migrado para um 
outro servidor LInux Redhat 6.x ou 7.0 64 bits. O tamanho da base é de 2,4 TB. 

Gostaria de saber de vocês qual seria o melhor modo de se fazer essa migração.
Obs1: O tempo de downtime não foi informado, mas acho que o cliente teria um 
dia do final de semana livre para realizar essa tarefa.
Alguém poderia ajudar?