Eu há muuuito tempo aprendi que esse pessoal : a. só entende NÚMEROS e b. só leva em consideração o que tá escrito e assinado Assim, enquanto técnicos a nossa Obrigação é produzir um documento que mostre a (normalmente alta!) chance de um equipamento falhar, que liste o TEMPO necessário para se comprar outra máquina e reinstalar tudo/voltar backup após um crash (DIAS, pelo menos), o CUSTO para o negócio da indisponibilidade do database em questão (exemplo, multa NFs não emitidas, vendas não concretizadas , processos judiciais abertos por pacientes, enfim) versus o CUSTO de uma mínima infra de disponibilidade (se não tem $$ para RAC nem para disaster recover, ao menos um segundo servidor e um segundo storage), e demandar assinatura de ciência de quem de direito....Só isso : com esse doc na mão Ninguém pode alegar ignorância de custos , é isso.... O que é uma posição Arriscada é vc não fazer nada, não tem nada em mãos, aí quando acontecer um crash (não é SE, mas QUANDO) neguim vim te cobrar milagre, sim ?
Inclusive, cabe uma outra obs : é verdade que ninguém pode te assegurar que a nova versão de database (ou que um eventual patch/patchset) não vai causar problemas com a Aplicação, mas é JUSTAMENTE PARA ISSO que existe o ambiente de Homologação - simplesmente se testa, testa E RETESTA o patch/patchset/upgrade na máquina homologação, que é IGUALZINHA à Prod, contra um servidor homologação da aplicação, é isso... E esse servidor standby/disponibilidade que citei acima Tranquilamente poderia serveir Também como ambiente de Homologação, yes ?? E esse servidor servirá tambpem para vc TESTAR efetivamente a sua política de backup/restore de prod... []s Chiappa
