Sorry, mas vc ainda não deu as infos pedidas de forma suficiente : por exemplo, quando eu perguntei mostra qual é o usuário dono do dblink, a razão é : SE o dblink (que certamente está no banco local) foi criado por/pertence ao MESMO usuário de banco/schema com que a aplicação conecta no banco local , vc Não consegue criar um sinônimo (apontando pra outro schema/dblink novo) com o mesmo nome do dblink atual - aí não teria jeito, ou se cia outro usuário e faz a ppp conectar com ele, ou se drpar e recria mesmo o dblink.. Já SE o dblink está em outro schema que não aquele com o qual a app conecta, COM CERTEZA para que a aplicação possa fazer select nn FROM tab...@nomedblink, certamente OU há um sinônimo já presente, ou a app faz um ALTER SESSION SET CURRENT_SCHEMA ou algo assim... Precisamos saber essas coisas em detalhes...
Outra coisa, não entend o seu ponto de "50000 objetos" : o dblink NÃO É criado pra cada objeto, é uma CONEXÃO, uma vez criada/aberta vc com ela pode acessar TODOS os n+1! objetos contidos /acessáveis, o que que tem a ver o umero de objetos com a questão de dblinks ??? Quanto ao número de instâncias, SE são várias instâncias por servidor, nada impede de vc automatizar seja qual for a solução via script , talvez um shell script que encontra as instâncias via ps | grep -i pmon em cada servidor e chama um outro scrpt sqlplus que monta a solução pracada instância.... Não é automático mas é automatizável , penso eu... --- Em [email protected], "Raul Francisco Costa F. de Andrade, DBA" <raulf...@...> escreveu > > Chiappa, os dblinks são todos os owner que preciso trocar a senha. > > Através destes dblinks são criadas views assim: > > create view nome_view select * from tab...@dblink; > > Depois disso são criados alguns sinônimos públicos para as views. > > Porém estamos falando de mais de 200 dblinks entre mais de 80 instâncias > para uma média de 50000 objetos.... > > > > > > > > Em 12 de fevereiro de 2010 09:21, José Laurindo > <jlchia...@...>escreveu: > > > > > > > Isso ** SE ** a aplicação já não usa sinônimos, ** SE ** a aplicação não > > faz referência nos programas como OWNER.nomedoobjeto ou coisas assim, num > > caso (por exemplo) da aplicação pedir SELECT nn FROM owner.nomedodblink (por > > exemplo), não tem jeito, o sinônimo local será solenemente IGNORADO... > > > > Eu diria então pro Raul : nos mostre ** EXATAMENTE ** como a aplicação > > acessa o dblink, mostra qual é o usuário dono do dblink, mostra a conexão, > > diga onde/como ele está criado, se há sinônimos (lá ou cá), como eles estão > > criados... DEPENDENDO DO CASO, talvez se possa "tapear" a aplicação com > > sinônimos, mas issso DEPENDE da situação - se não for possível, repito : uma > > indisponibilidade ** MÍNIMA ** , de minutos MAS notável, vai ser > > inescapável... > > > > []s > > > > Chiappa > > > > --- Em [email protected] <oracle_br%40yahoogrupos.com.br>, > > "Rodrigo Mufalani" <mufalani@> escreveu > > > > > > > > > > > Isso se resolve fácil > > > > > > Sinônimo privado: > > > > > > create synonym view1.novo_schema for view1.orig_schema; > > > > > > Grant de select, insert, update e delete (ao seu gosto). > > > > > > Obs.: Nesse caso o "novo_schema" acessará o objeto que pertence ao > > > "orig_schema" sem ter que qualificar. > > > > > > Atenciosamente, > > > > > > Rodrigo Mufalani > > > DBA - OCP 10g & 11g +RAC > > > Oracle ACE Member > > > tel.: (21) 8851-4817 > > > www.mrdba.com.br/mufalani/ > > > mufalani@ > > > > > > > > > > > > > > Pois é Rodrigo, mas tem um probleminha... o owner da conexão o que eu > > > tenho > > > que alterar a senha tem algumas views que são acessadas pelos > > programas... > > > daí ferrou se criar outro owner a aplicação pára. > > > > > > > > > Att. > > > > > > Raul > > > > > > Em 11 de fevereiro de 2010 15:45, Rodrigo Mufalani > > > <mufalani@>escreveu: > > > > > > > > > > > > > > > > > Francisco, > > > > > > > > Eu concordo totalmente com a dica do nosso colega te deu. > > > > > > > > 1). Crie um usuário no banco que os databases acessam (1 para cada > > > > acesso) > > > > com todas as permissões desse user que acessa hoje; > > > > > > > > 2). Recrie os database link de banco por banco (com o mesmo nome para > > > > não > > > > ter que mexer em apps) banco por banco apontando para esses usuários > > > > novos > > > > no teu banco de produção; > > > > > > > > 3). Bloqueie esse usuário, mude a senha ou drope ele; > > > > > > > > Com essas medidas o seu tempo de indisponibilidade será ridículo, e > > > > talvez o seu usuário nem perceba. > > > > > > > > Obs.: garanta que esses usuários tenham as mesmas permissões que o > > > > antigo. > > > > > > > > Atenciosamente, > > > > > > > > Rodrigo Mufalani > > > > DBA - OCP 10g & 11g +RAC > > > > Oracle ACE Member > > > > tel.: (21) 8851-4817 > > > > www.mrdba.com.br/mufalani/ > > > > mufalani@ <mufalani%40mrdba.com.br> > > > > > > > > > > > > > > Mas não existe alter database link... > > > > > > > > :( > > > > > > > > Em 11 de fevereiro de 2010 12:57, Fabio Martinez > > > > <mtzfabio@ <mtzfabio%40gmail.com>>escreveu: > > > > > > > > > > > Vixi, Não consigo ver uma maneira de alterar a senha sem causar > > > > > indisponibilidade no sistema, já que são 2 bancos diferentes e terá > > um > > > > > delay > > > > > entre a alteração da senha do usuário e do database link.. > > > > > > > > > > Poderia tentar fazer o seguinte.....hoje os database links estão > > > > > apontando > > > > > para o usuário XXXXX, poderia alterar os database links para apontar > > > > > para > > > > > outro usuário (yyyy) com as mesmas permissões que já possui hoje > > > > > (XXXXX), > > > > > alterar a senha do usuário(XXXXX) e voltar a apontar os database > > links > > > > > para > > > > > o usuário(XXXX) cujo a senha foi alterada. > > > > > > > > > > []s > > > > > > > > > > Em 11 de fevereiro de 2010 09:31, Raul Francisco Costa F. de Andrade, > > > > > DBA < > > > > > raulfdba@ <raulfdba%40gmail.com>> escreveu: > > > > > > > > > > > > > > > > > > > > > > > > > Versão: Oracle 10.2.0.4, 9i e 8i. > > > > > > > > > > > > Pessoal tive um problema e preciso alterar a senha de um usuário > > que > > > > é > > > > > > utilizado para acessa várias bases nossas através de dblink. > > > > > > é muito complicado recriar todos os dblinks de novo pois causaria > > > > > > indisponibilidade no sistema. > > > > > > > > > > > > Então o que eu precisaria com urgência seria alterar a senha e > > > > também > > > > > no > > > > > > dblink automaticamente. > > > > > > > > > > > > Por favor me ajudem... Tenho urgência. > > > > > > > > > > > > Att. > > > > > > > > > > > > Raul > > > > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > > > > > > > > > > > > > ------------------------------------ > > > > > > > > > > > > > > > ---------------------------------------------------------- > > > > > >Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de > > > > > inteira responsabilidade de seus remetentes. > > > > > Acesse: http://www.mail-archive.com/[email protected]/ > > > > > > > > > > ---------------------------------------------------------- > > > > > >Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package » > > > > > Procedure > > > > > » Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! > > > > > VISITE: > > > > > http://www.oraclebr.com.br/ > > > > > ---------------------------------------------------------- > > > > > Links do Yahoo! Grupos > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > ---------------------------------------------------------- > > > > Raul Francisco da Costa Ferreira de Andrade > > > > DBA - OCA - Oracle Certified Associate > > > > Fone: (41)8855-8874 Brt > > > > email: raulfdba@ <raulfdba%40gmail.com> > > > > > > "Deus não dá prova superior às forças daquele que a pede; > > > > só permite as que podem ser cumpridas. > > > > Se tal não sucede, não é que falte possibilidade, falta vontade." > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > > > > > > > > > > > > > > > > > -- > > > ---------------------------------------------------------- > > > Raul Francisco da Costa Ferreira de Andrade > > > DBA - OCA - Oracle Certified Associate > > > Fone: (41)8855-8874 Brt > > > email: raulfdba@ > > > > > "Deus não dá prova superior às forças daquele que a pede; > > > só permite as que podem ser cumpridas. > > > Se tal não sucede, não é que falte possibilidade, falta vontade." > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > > > > > ------------------------------------ > > > > > > ---------------------------------------------------------- > > > >Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de > > > > inteira responsabilidade de seus remetentes. > > > Acesse: http://www.mail-archive.com/[email protected]/ > > > ---------------------------------------------------------- > > > >Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package » > > > > Procedure » Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO > > > > ESPAÇO! VISITE: http://www.oraclebr.com.br/ > > > ---------------------------------------------------------- > > > Links do Yahoo! Grupos > > > > > > > > > > > > > -- > ----------------------------------------------------------- > Raul Francisco da Costa Ferreira de Andrade > DBA - OCA - Oracle Certified Associate > Fone: (41)8855-8874 Brt > email: raulf...@... > "Deus não dá prova superior às forças daquele que a pede; > só permite as que podem ser cumpridas. > Se tal não sucede, não é que falte possibilidade, falta vontade." > > > [As partes desta mensagem que não continham texto foram removidas] >
