[oracle_br] Re: Sqlloader

2008-04-14 Por tôpico ja_ura
Além dessas opções, você tem também o UTL_FILE, que pode ser utilizado
dentro de um pl/sql para carregar esses arquivos textos.


Adriano

--- Em oracle_br@yahoogrupos.com.br, "francisco porfirio"
<[EMAIL PROTECTED]> escreveu
>
> Essa minha dúvida surgiu, porque eu pensei em realizar uma procedure
que eu
> apenas informasse o arquivo que seria carregado, e a procedure ficaria
> encarregada em chamar operações do sqlloader.
> 
> Sendo assim, acredito que com um script shell dentro da pl/sql funciona.
> 
> Ireie realizar alguns testes ainda com o EXTERNAL TABLE, conforme
citado por
> Chiappa.
> 
> Agradeço a resposta de todos.
> 
> 
> -- 
> Atenciosamente
> Francisco Porfirio Ribeiro Neto
> 
> 
> [As partes desta mensagem que não continham texto foram removidas]
>




[oracle_br] Re: Revogar Alter table

2007-08-28 Por tôpico ja_ura
Carlito,

A alternativa para revogar o alter table, drop table mesmo o usuário 
não possuindo esses privilégios, seria você fazer uma trigger por 
schema.
ex:

CREATE OR REPLACE TRIGGER drop_trigger 
   BEFORE DROP ON hr.SCHEMA 
   BEGIN
  RAISE_APPLICATION_ERROR (
 num => -2,
 msg => 'Cannot drop object');
   END;

att,

Adriano

--- Em oracle_br@yahoogrupos.com.br, "Carlos" <[EMAIL PROTECTED]> 
escreveu
>
> Pessoal,
> 
> Estamos precisando controlar nosso ambiente de desenvolvimento,
> revogando alguns privilégios dos desenvolvedores.
> O primeiro que pensamos foi o create table. Ao removermos esse
> privilégio de sistema, esperávamos que o usuário owner também não
> conseguisse alterar e muito menos dropar a tabela, o que não se
> confirma na prática.
> 
> Qual a melhor forma de controlar essa questão? Não queremos que os
> desenvolvedores criem tabelas, muito menos as altere ou drop.
> Algum de vocês, caso já tenha se deparado com esse problema, como
> conseguiram implementar uma solução eficaz?
> 
> Muito grato
> 
> Carlos
>




[oracle_br] Re: Problemas com a view user_tab_privs

2007-05-21 Por tôpico ja_ura
Carlos,

O que pode estar acontecendo é que o usuário que você está 
acessando, não tem privilegio para identificar se o usuário que está 
na USER_TAB_PRIVS é na verdade uma ROLE. Você não mencionou, mas 
imagino que esse usuário tem somente os privilegios de connect e 
resource.
Se você der um select na view all_users, você verá que não existe o 
tal usuário que está na user_Tab_privs, confirmando que se trata 
realmente de uma ROLE e não usuário de banco.Tente conectar com um 
usuario que possui o privilegio de DBA ou que tem acesso de consulta 
na view DBA_ROLES e dê um select nela.

att,


Adriano


--- Em oracle_br@yahoogrupos.com.br, "Igor Laguardia" <[EMAIL PROTECTED]> 
escreveu
>
> utilize a opção no imp GRANTS=N.
> 
> Em 15/05/07, jlchiappa <[EMAIL PROTECTED]> escreveu:
> >
> >   Colega, alguma coisa está *** muito *** estranha aí : pra 
início de
> > conversa, "acesso por synonym" absolutamente NÃO EXISTE, o 
sinônimo é
> > apenas UM ATALHO de digitação para que vc não tenha que usar a
> > referência completa, o privilégio de acesso é feito SEMPRE via
> > grants, seja grant pra role, seja grant direto.
> > Segundo, a user_tab_privs TEM QUE ser atualizada automaticamente
> > após um DML, isso é funcionamento básico de banco, se isso não 
está
> > acontecendo vc tem em mão um BUG ENORME, corra pro Suporte...
> > ===>>> O que eu chutaria porém que acontece aí é que na verdade o
> > privilégio NÂO FOI DADO pro fulano2, e sim para o PUBLIC, E/OU os
> > sinônimos são públicos, aí (óbvio) quando vc dropa (aqui se
> > vc "deletou" significa que vc ** dropou ** o usuário fulano1, 
como o
> > priv e/ou o sinonym foi pro PUBLIC, nada é alterado OU 
ainda, vc
> > fez o drop *** DEPOIS  de ter gerado o .dmp com o export, aí
> > obviamente QUANDO o export foi feito o privs e o usuário existia,
> > lógico, então eles foram pro .dmp...
> >
> > SE vc deu diretamente o grant pro usuário,E os privs não são
> > públicos, a view USER_TAB_PRIVS é SIM alterada após o drop, 
exemplo :
> >
> > ==> crio os caras
> >
> > [EMAIL PROTECTED]:SQL>create user fulano1 identified by fulano1;
> >
> > Usuário criado.
> >
> > [EMAIL PROTECTED]:SQL>grant create session, create procedure to 
fulano1;
> >
> > Concessão bem-sucedida.
> >
> > [EMAIL PROTECTED]:SQL>grant create table to fulano1;
> >
> > Concessão bem-sucedida.
> >
> > [EMAIL PROTECTED]:SQL>create user fulano2 identified by fulano2;
> >
> > Usuário criado.
> >
> > [EMAIL PROTECTED]:SQL>grant create session, create synonym to fulano2;
> >
> > Concessão bem-sucedida.
> >
> > [EMAIL PROTECTED]:SQL>alter user fulano1 default tablespace USERS;
> >
> > Usuário alterado.
> >
> > [EMAIL PROTECTED]:SQL>alter user fulano1 quota unlimited on users;
> >
> > Usuário alterado.
> >
> > ==> conecto e crio objs
> >
> > [EMAIL PROTECTED]:SQL>create table TAB_A (c1 number, c2 date);
> >
> > Tabela criada.
> >
> > [EMAIL PROTECTED]:SQL>create table TAB_B(c3 char, c4 number);
> >
> > Tabela criada.
> >
> > [EMAIL PROTECTED]:SQL>create procedure PROC_1 is BEGIN null; END;
> > 2 /
> >
> > Procedimento criado.
> >
> > [EMAIL PROTECTED]:SQL>create procedure PROC_2 is BEGIN null; END;
> > 2 /
> >
> > Procedimento criado.
> >
> > => dou os grants diretos :
> >
> > [EMAIL PROTECTED]:SQL>grant select on TAB_A TO fulano2;
> >
> > Concessão bem-sucedida.
> >
> > [EMAIL PROTECTED]:SQL>grant select on TAB_B TO fulano2;
> >
> > Concessão bem-sucedida.
> >
> > [EMAIL PROTECTED]:SQL>grant execute on PROC_1 to fulano2;
> >
> > Concessão bem-sucedida.
> >
> > [EMAIL PROTECTED]:SQL>grant execute on PROC_2 to fulano2;
> >
> > Concessão bem-sucedida.
> >
> > ==> olha só o que a user_tab_privs do usuário criador e 
fornecedor de
> > privilégios mostra, ele é GRANTOR, ie, ele que forneceu o priv :
> >
> > [EMAIL PROTECTED]:SQL>select * from user_tab_privs;
> >
> > GRANTEE OWNER
> > TABLE_NAME GRANTOR
> > PRIVILEGE GRA HIE
> > --  -
-
> >  -- -
-
> > -- --- ---
> > FULANO2 FULANO1
> > TAB_A FULANO1
> > SELECT NO NO
> > FULANO2 FULANO1
> > TAB_B FULANO1
> > SELECT NO NO
> > FULANO2 FULANO1
> > PROC_1 FULANO1
> > EXECUTE NO NO
> > FULANO2 FULANO1
> > PROC_2 FULANO1
> > EXECUTE NO NO
> >
> > ==> agora vamos pro outro cara :
> >
> > Conectado a:
> > Oracle9i Enterprise Edition Release 9.2.0.5.0 - 64bit Production
> > With the Partitioning option
> > JServer Release 9.2.0.5.0 - Production
> >
> > [EMAIL PROTECTED]:SQL>select * from user_tab_privs;
> >
> > GRANTEE OWNER
> > TABLE_NAME GRANTOR
> > PRIVILEGE GRA HIE
> > --  -
-
> >  -- -
-
> > -- --- ---
> > FULANO2 FULANO1
> > TAB_A FULANO1
> > SELECT NO NO
> > FULANO2 FULANO1
> > TAB_B FULANO1
> > SELECT NO NO
> > FULANO2 FULANO1
> > PROC_1 FULANO1
> > EXECUTE NO NO
> > FULANO2 FULANO1
> > PROC_2