Seguinte : a) quando vc tá na situação de uma base absolutamente descontrolada, onde qquer um (do faxineiro à secretária) criava o que queria SEM documentar nada (o que parece ser o caso), pra quase todos os objetos (dblink inclusive) o banco só mantém normalmente uma lista de usuários/dependetes interna, na DBA_DEPENDENCIES : por "interno" eu quero dizer uso "dentro" do banco de dados, por elementos internos como (por exemplo) procedures/triggers/functions PL/SQL, e coisas assim... Então vc até consegue saber por parte do banco de dados os programas/usuários que usam os dblinks, PORÉM se tem dblinks que são usados por programas externos, aí neca.... Só mesmo implementando algum tipo de auditoria, seja via AUDIT, seja via TRIGGER, seja FGA (Fine-Grained Audit), seja armazenando e depois consultando os SQLs executados pra ver se tem @nomedodblink no meio, OU (se é exigido o menor overhead possível no banco/servidor E não é exigida a maior precisão/menor taxa de perda possível) vc pode simplesmente ter um job que a cada 5 minutos checa quais objetos estão em uso ... b) que fique Claro : - Auditoria ** NÃO ** vai ter dar a resposta de bate-pronto, vc Vai Ter que ficar uns tantos muitos dias coletando a informação - uso de Auditoria para este tipo de resposta (usage check) ** NÃO ** é 100% garantida : absolutamente NADA impede que vc tenha ficado, sei lá, 3 semanas auditando , do dia 01 ao dia 21 do mês, Mas aí vc não sabia que no dia 31 roda um hiper-mega-boga importante programa mensal de fechamento que usa o raio do dblink .... Quanto maior o período de coleta, menor a chance de vc ter perdas do tipo, mas Zero de perda não tem como garantir Isto posto : afaik não há no AUDIT um comando pra auditar SQLs que usem dblink (o AUDIT só pega SELECT em geral, DDLs e DMLs), E não há trigger que dispare quando vc faz um SELECT, ENTÃO imho ** NENHUMA ** das suas opções serviria, penso que vc teria que usar umas das outras que citei, ie : - FGA guardando o texto (veja a Documentação da DBMS_FGA para refs/exemplos simples) e/ou - armazenamento automático do texto dos SQLs (via ativação do trace de SQL no banco) - NEM preciso dizer que esse cara vai ter dar uma taxa de perda baixa MAS vai comer um espaço em disco e causar um overhead sensível e/ou - consulta periódica de quem tá usando dblinks : http://jkstill.blogspot.com/2010/03/whos-using-database-link.html tem um exemplo possível de consulta, que vc programaria num job, imagino, OU vc pode consultar a V$SQL e ver quem tem @nomedolink no texto []s Chiappa
--- Em oracle_br@yahoogrupos.com.br, José Carlos Guerrieri <guerrieri.jc@...> escreveu > > Bom dia. > > Estou com o seguinte problema: > > Atendendo à necessidade de um cliente cujo legado é a existência de inúmeros > dblinks públicos criados com usuário e senha, preciso saber qual usuário da > base faz uso destes dblinks para chegar à(s) outra(s) instância(s). > A possível solução seria uma trigger ou "ligar" o audit ? > > Agradeço a quem possa ajudar. > > José Carlos > > > [As partes desta mensagem que não continham texto foram removidas] >
