Colega, se vc ** realmente ** vai ter databases e instâncias COMPLETAMENTE SEPARADOS, aí NÂO TEM MÁGICA : esse 'ponto central' teria que ter acesso por rede a TODOS os diferentes databases, e CADA pesquisa nele vai ter que ser refeita em cada um dos databases até encontrar aquele onde a informação existe - imho isso é COMPLETAMENTE INVIÁVEL, já pensou ter que repetir E repetir E repetir uma consulta até encontrar os dados, E ainda por cima com o agravante que cada database está sendo acessado remotamente, com delay de rede (e de internet, se não for rede privada/dedicada) ainda por cima ?? Simplesmente não funciona..... Pra mim vc só tem duas alternativas : 1) se houver um link de rede dedicado E de alta-performance, 100% confiável, entre as instâncias todas, vc pode ter OU um extended RAC (ie, o database fica num local central e todas as instâncias estão na verdade lendo/acessando via rede esse único database - http://www.oracle.com/technetwork/products/clustering/overview/extendedracversion11-435972.pdf é um paper que conceitua) OU vc pode ter distributed databases, ie : os diferentes databases estão interligados por rede e corretamente setados/configurados, aí cada alteração feita numa tabela é REPLICADA para os outros databases.... Notar que esta última opção (distributed) é COMPLEXA, pois Além do link de rede 100% confiável e performante (o que é exigência ABSOLUTA pro RAc também, claro), entre outras coisas a Aplicação tem que controlar os CONFLITOS, tipo : o database A manda um UPDATE e ao mesmo tempo um database B manda um DELETE, quem tem prioridade ?? Como resolver esse tipo de conflito ?? Dá uma lida no manual Oracle Database Administrator's Guide nos itens Distributed Database Architecture e Distributed Database Concepts, mas não é nada simples que se faça sem muuuuto planejamento... ou 2) para evitar o (considerável!!) overhead do ponto central ter que repetir a mesma consula em N databasesdiferentes, a Aplicação é alterada/remodelada para que, após cadastrar um paciente num dado database, um REGISTRO que o paciente tal está no database tal é feito nesse 'ponto central' que mais tarde precisará consultar essa informação.... Esse 'ponto central' provavelmente seria um database Oracle de menor porte, e o 'local de registro' seria uma pequena tabela que relaciona paciente com instância onde os dados residem... Obviamente, nesse cenário além do ponto entral ter acesso aos N databases TAMBÉM os N databases tem que ter acesso ao 'ponto central' pra fazer o registro - mas como isso é algo que não é feito toda hora E vai estar sob controle da Aplicação, Acredito que é possível ter a APlicação controlando esses acessos, os repetindo se a operação não foi bem-sucedida por erro pontual de rede ou coisa assim, etc... []s Chiappa
[oracle_br] Re: Pesquisa de registros transparente
jlchia...@yahoo.com.br [oracle_br] Sat, 11 Aug 2018 01:40:21 -0700
- [oracle_br] Pesquisa de registros tr... Neto pr neto...@gmail.com [oracle_br]
- [oracle_br] Re: Pesquisa de reg... jlchia...@yahoo.com.br [oracle_br]
- [oracle_br] Re: Pesquisa de reg... jlchia...@yahoo.com.br [oracle_br]