Início / dba / Perguntas / 1295
Accepted
ScottCher
Asked: 2011-02-18 08:17:51 +0800 CST

Como permitir que os usuários vejam concessões, visualizem definições, PL/SQL, etc em um banco de dados sem conceder acesso para alterar esses objetos

  • 772

Como desenvolvedor, preciso ser capaz de acessar o design dos objetos de banco de dados/banco de dados da produção para garantir que estou trabalhando com a versão mais recente e melhor dos objetos para os quais estou desenvolvendo alterações (ajuda a evitar problemas imprevistos na implantação).

Além disso, como desenvolvedor, não devo ter acesso para modificar, executar, atualizar, excluir, etc, esses objetos - esse é o trabalho da equipe de implantação de produção.

Como um DBA, como posso fornecer acesso ao design do banco de dados para que os desenvolvedores possam validar as alterações nas quais estão trabalhando sem também conceder a eles acesso carta branca aos objetos do banco de dados?

Como um exemplo específico, nossos DBAs bloquearam suficientemente o ambiente de produção para que, dentro do TOAD, eu não possa ver o corpo PL/SQL de um pacote, não posso ver todas as concessões que fornecem acesso a um objeto, etc. A conta de usuário que está sendo usada tem acesso limitado para usar alguns dos objetos, mas não pode visualizar os detalhes estendidos que um desenvolvedor precisaria para desenvolver alterações.

Eu adoraria ter as coisas configuradas para que tivéssemos acesso de visão de dicionário que nos permitisse ver todas as concessões, os scripts de visão, os corpos dos pacotes PL/SQL, definições de tabela, etc, sem também nos dar mais acesso do que deveríamos ter em produção (ou seja, não devemos ser capazes de mudar nenhuma dessas coisas)

Existe um papel que forneça esse acesso, um privilégio ou uma série de privilégios que precisaríamos? Se não houver, qual é um bom método alternativo para obter esse tipo de informação?

oracle

2 respostas

  1. Best Answer

    O privilégio SELECT ANY DICTIONARY (ou, em versões anteriores, a função SELECT_CATALOG_ROLE) concede ao usuário privilégios para selecionar qualquer tabela de dicionário de dados.

    O privilégio SELECT ANY DICTIONARY daria a um desenvolvedor privilégios para escrever quaisquer consultas que eles quisessem em DBA_SOURCE para ver a fonte de qualquer objeto, DBA_VIEWS para ver definições de exibição etc. Mas não há garantia de que um front-end específico realmente aproveite esses privilégios corretamente. Muitas GUIs simplesmente selecionam nas tabelas de dicionário de dados ALL_* para exibir os objetos nos quais um usuário tem privilégios de objeto, em vez de reconhecer que o usuário tem permissão para selecionar nas tabelas de dicionário de dados DBA_*. Pessoalmente, fico mais do que feliz em consultar a visualização DBA_SOURCE (ou usar o pacote DBMS_METADATA) quando quero examinar a origem do objeto em um banco de dados de produção, mas muitas pessoas ficam impacientes sem o navegador de esquema da GUI.

    • 10

  2. Como um pequeno aparte... Eu queria que meu script sql*plus escolhesse as "melhores" visualizações para uma consulta.

    ou seja, dba_xxx se disponível ou all_xxx se não

    Então eu fiz algo assim no topo do meu script (ou em um subscrito se você preferir)

    column get_access_type  NEW_VALUE access_type

SELECT MAX(access_type) get_access_type
FROM ( --11g
SELECT 'DBA' access_type FROM user_sys_privs WHERE privilege= 'SELECT ANY DICTIONARY'
UNION --before 11g
SELECT 'DBA' access_type FROM user_role_privs WHERE granted_role = 'SELECT_CATALOG_ROLE'
UNION --default
SELECT 'ALL' access_type FROM dual)
;

    e então eu usei da seguinte forma.

    prompt &access_type._OBJECTS
SELECT object_name
      ,subobject_name
      ,owner
      ,object_type
      ,status
FROM &access_type._objects  ao
WHERE object_name LIKER UPPER('%&object_like%')
ORDER BY 1,3;

    talvez possa ser útil para alguém..

    • 0

relate perguntas