Chiappa, acho q to indo no caminho certo então rsrsrsrs
Tudo isso (uso de comandos exclusivos nos objetos, hardware(q é nosso, não é do cliente), homologação pesada (testa testa testa ate ficar careca rsrsrs etc ) colocamos como prioridade antes de qualquer atitude ... tudo q foi escrito em todos os emails foram transcritos e serão lidos com atenção q merecem... Chiappa muito obrigado pela resposta e tempo que dedicaste a ajudar ... vlw mesmo!!! Em 13 de agosto de 2014 13:09, jlchia...@yahoo.com.br [oracle_br] < oracle_br@yahoogrupos.com.br> escreveu: > > > 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 > >
