Blz ? Então, só ficou a resposta sobre a Rede, no item :
"
Tem muitos DDLs, alteração de estruturas de tabelas e/ou recriação de stored
PL/SQLs nesse banco origem ? O link de rede entre as duas máquinas é permanente
, seguro e Confiável ?
>> So producao sera contingenciada.
"
Isso porque, Obviamente, para vc poder enviar as alterações para o site remoto
(e isso SSEJA QUAL FOR A SOLUÇÃO !!) é Claro que vc precisa de um LINK DE REDE
ativo, bom, estável, performático e Confiável - já cansei de ver casos em que o
pessoal se esquece disso aí contrata um link de rede fuleiro qquer de 10 Mbps
(e ainda por cima compartilhado com os usuários finais) , aí na hora que o
banco primary começa a trabalhar pesado a rede não consegue acompanhar, o
contingência começa a ficar mais e mais atrasado, até fazer Bum...
SE esse Questinamento sobre a rede resultar que OK, o link é Confiável e
performático, dado que vc está no Enterprise Edition e o banco já tá em
Archive-mode, aí não tem o que pensar , o DATAGUARD Físico é a melhor solução,
pois :
a. os Conceitos tecnológicos que ela usa (geração e aplicação de archived redo
logs) são antigos, já estabelecidos há muito e Extremamente bem conhecidos e
testados no mundo do banco de dados Oracle
b. a Oracle garante que funciona com QUALQUER aplicação rodando sob qualquer
Storage, é Fisico... Uma decorrência PROVEITOSA disso é que datatypes
"especiais (exemplo, os que precisam de file handles, como LOBs) ou datatypes
não-escalares acabam sendo Transparentes pro DG/standby físico : como ele
replica bytes de log, ele nem fica Sabendo, é Irrelevante pra ele absolutamente
qualquer atributo lógico...
c. ele é uma solução Flexível, vc a pode configurar para zero data loss OU para
maximum performance facilmente, sem a necessidade de instalar nada
d. não tem Custo, é uma solução já embutida no valor da licença do Enterprise
Edition - só se vc quiser mais tarde usar o banco standby como ambiente de
relatórios (a feature do Active Data Guard) é que vc precisará de Licença
adicional
Aí, os esclarecimentos adicionais :
=> com "datatypes escalares" eu me refiro aos datatypes que guardam mais de
um valor (exemplo, colunas XML), dá um look no manual "Database SQL Language
Reference" item Data Types para mais refs.... Esses caras apresentam diversos
impedimentos para a replicação de dados ou para o standby lógico, MAS como vc
pretende ir pro standby físico com DG, essse impedimentos não se aplicam nesse
caso... ,
=> é Óbvio que dá pra fazer disaster recover sem dataguard, e é Óbvio que a
IBM, sendo a fornecedora do Storage, vai tentar pressionar por uma solução
baseada no Storage, OU então (já que fornece o SO) pode pressionar por uma
solução a nível de SO, externa, como o HACMP citado...
A questão é que, além dessas soluções NÂO apresentar as vantagens acima no
que se refere à Oracle, elas PODE ter algum custo a mais e vais e saber se a
IBM realmente, positivamente, garante que todas elas Suportam sim, mesmo, o
RDBMS Oracle.... Eu SEMPRE fico com um pé atrás em usar uma tecnologia
não-Oracle com um RDBMS Oracle... SE vc chegar a penssar nisso, EXIJA POR
ESCRITO todas as garantias que puder...
[]s
Chiappa
