Seguinte : para fazer um downgrade da Enterprise Edition para uma versão 
menor/mais barata de RDBMS Oracle (que, sendo um ambiente Profissional, COM 
CERTEZA não seria a Express Edition : ela é grátis Mas não tem Nunca 
Absolutamente Nenhum Suporte por parte da Oracle)... Assim,  temos que :  a) 
normalmente, não-especialistas em bancos de dados tema ** ILUSÃO ** que, se não 
usarem nenhuma feature mais avançada e mantiverem os SQLs "simples", a 
performance será a mesma em Qualquer banco de dados/em qualquer edição do RDBMS 
Oracle : isso está LONGE de ser 100% verdadeiro, é absolutamente FÁCIL vc 
encontrar bugs, decisões diferentes do otimizador, implementações diferentes de 
algoritmos de JOIns, etc, etc, etc, que levem a performances às vezes 
RADICALMENTE diferentes do mesmo texto SQL entre dois databases diferentes.... 
Dá uma googlada por SAME SQL DIFFERENTE PERFORMARCE que vc acha n+1! exemplos 
(e claro, bastaria UM!!) mostrando casos do tipo....  b) por mais que o SQL em 
si seja padrão, ÓBVIO que o comitê não pode (nem se dispôs a) padronizar 
Rigorosamente tudo : então , não é só porque te falaram que "ah, nós só usamos 
o básico" que vc não vá encontrar diferenças entre os SQLs usados no Oracle x 
SQLs de outro database, como por exemplo Postgre.... Então, NÂO CAIA na 
auto-ilusão de achar que é só migrar os dados que blz : vc PODE SIM ter que 
re-escrever alguns de seus SQLs para rodarem no novo database, okdoc ?  c) ok 
que te falaram que "a gente só usa procedures e coisas assim", mas na real : vc 
tem Certeza que essas procedures não usam algum comando que Não Existe fora do 
Enterprise Edition ??? E outra, vc tem certeza que na hora de criar o database 
fisicamente não foram usadas features que exigem Licenciamento e/ou não estão 
disponíveis fora da Enterprise Edition e/ou no outro database, como (por 
exemplo, digamos) Particionamento, Compactação avançada, etc ??? Vc ** TEM ** 
que chamar algum especialista que vai confirmar essas coisas  d) vc tem certeza 
que os seus clientes não usam nenhuma tool de Administração e Segurança (por 
exemplo, AWR/ASH, Auditoria avançada/datavault, etc, etc) que não existe na 
outra edição do Oracle e/ou no outro database ??? Isso ** TEM ** que ficar 
Claro, tem que ser checado....  e) hardware : imagino que, já que hoje roda 
bem, o Cliente quer manter o mesmo hardware que já tem - é por sua conta 
VERIFICAR se esse hardware é aceitável para a nova edição do RDBMS Oracle e/ou 
o novo database : diversas Edições e/ou fornecedores LIMITAM o máximo de 
processadores, memória, etc, que as versões mais baixas/baratas podem usar no 
máximo...  ===> Para vc ter garantia de todos os pontos acima, Além do 
relatório de um especialista, vc DEVERIA fazer um ambiente de Homologação com o 
novo database/nova edição do RDBMS Oracle, yep ?? E veja que estou falando aqui 
de uma Homologação *** DECENTE *** e HONESTA : se vc acha que é passar a mão no 
micro da secretária, instalar o sistema e cadastrar meia dúzia de linhas, vc tá 
redondamente enganado , é ULULANTEMENTE ÓBVIO que qualquer banco roda bem 
assim.... Estou recomendando uma homologação SÉRIA, certo ? []s    Chiappa
  • ... Mario Rodrigues marioirodrig...@gmail.com [oracle_br]
    • ... Alessandro Lúcio Cordeiro da Silva alecordeirosi...@yahoo.com.br [oracle_br]
      • ... Mario Rodrigues marioirodrig...@gmail.com [oracle_br]
    • ... jlchia...@yahoo.com.br [oracle_br]
      • ... Mario Rodrigues marioirodrig...@gmail.com [oracle_br]
        • ... jlchia...@yahoo.com.br [oracle_br]

Responder a