Re: [oracle_br] dbms_scheduler.

[Marcio Portes]

Um exemplo.
http://mportes.blogspot.com/search?q=dbms_scheduler

On 5/24/07, José Aristides <[EMAIL PROTECTED]> wrote:
>
>
> Boa Tarde !!!
>
> Tenho um script (inicio.sh) para gerar backup que quando executo
> manualmente "sql>@inicio.sh" no prompt do sqlplus funciona normalmente.
> Assim, resolvi criar o job (abaixo) porém, ao executar pelo "exec
> dbms_scheduler.run_job('BACKUP')" exibe o seguinte erro:
>
> *ERRO na linha 1:ORA-27475: "SYS.BACKUP" deve ser um jobORA-06512: em "
> SYS.DBMS_ISCHED", line 150ORA-06512: em "SYS.DBMS_SCHEDULER", line
> 441ORA-06512: em line 1
>
>
> BEGIN dbms_scheduler.create_job( job_name => 'BACKUP', job_type =>
> 'EXECUTABLE', job_action => '/home/oracle/backuporacle/gerar/inicio.sh',
> start_date => sysdate, repeat_interval => 'FREQ=MINUTELY;INTERVAL=2',
> enabled => TRUE, comments => 'Demo for doing backup');END;/
>
>
> obrigado,
>
> Aristides
> __
> Procure em qualquer página Web com protecção eficaz. Obtenha já o Windows
> Live Toolbar GRATUITO!
> http://www.toolbar.live.com
>
> [As partes desta mensagem que não continham texto foram removidas]
>
>  
>



-- 
Marcio Portes
Material Tecnico em Portugues - http://mportes.blogspot.com
Practical Learning Oracle -
http://mportes.blogspot.com/2006/02/practical-learning-oracle.html


[As partes desta mensagem que não continham texto foram removidas]

Res: Res: [oracle_br] Segurança

[Bia Fitzgerald]

A intenção é proteger os dados. Que eles não sejam alterados via aplicativos, 
somente pelo executável do próprio sistema. O usuário X, só poderá fazer acesso 
ao BD via sistema e não pelos aplicativos de acesso ao Oracle.
Obrigada pela ajuda,
Bia.


- Mensagem original 
De: jlchiappa <[EMAIL PROTECTED]>
Para: oracle_br@yahoogrupos.com.br
Enviadas: Quinta-feira, 24 de Maio de 2007 10:13:35
Assunto: Re: Res: [oracle_br] Segurança

Bia, ainda sobre esse ponto, deixe-me adicionar alguns itens : no bd 
Oracle uma conexão é uma conexão, absolutamente NÂO IMPORTA quem está 
conectando, não há MESMO nenhum código no kernel que tente 
identificar. ... Isso faz TODO o sentido inclusive, já que informações 
do cliente estão FORA DO CONTROLE do banco, e podem ser falsificadas 
de modo MUITO Fácil - por exemplo, se vc seguir o conselho dos 
colegas e tentar capturar o nome do programa numa trigger, E SE 
alguém fizer um rename sqlplus.exe to nomepermitido. exe, por 
exemplo  Acho muito muito ** frágil ** essa lógica
Segundo item : idealmente, as regras de negócio estão NO BANCO DE 
DADOS, via triggers, constraints, relacionamentos, views, etc, assim 
NÂO IMPORTA com qual tool a pessoa conecta, as primary keys estão lá, 
os grants estão lá, as views estão lá, e cada usuário final do 
sistema tem o seu usuário de banco, o qual só ele sabe a senha, então 
o usuário final *** só vai enxergar *** o que pode, ** só vai fazer 
** o que tem direito, independente da tool, ok ? Normalmente quem 
tenta fazer restrição desse tipo baseado no aplicativo é porque tem 
regras de negócio NO APLICATIVO, aí as coisas realmente podem quebrar 
se a pessoa conectar com outra coisa que não o aplicativo... .. Sem 
sombra de dúvida, isso deixa a Empresa absolutamente "ENGESSADA", ela 
NUNCA vai poder aposentar esse aplicativo sem perda de dados, NUNCA 
vai poder usar tools de query/busioness intelligence sem extensa 
customização  Afora o desenvolvedor do aplicativo (que tem 
serviço garantido), acho que NINGUÉM fica feliz com isso.

==> o meu ponto asim é : SE realmente vc tiver que fazer esse enrome 
contra-senso, conheça os pontos fracos, ok ? 

[]s

Chiappa

--- Em [EMAIL PROTECTED] os.com.br, Bia Fitzgerald  
escreveu
>
> ahhh, sim.. Muito obrigada.
> :)
> 
> 
> - Mensagem original 
> De: Gustavo Venturini de Lima 
> Para: [EMAIL PROTECTED] os.com.br
> Enviadas: Quarta-feira, 23 de Maio de 2007 18:34:19
> Assunto: Re: [oracle_br] Segurança
> 
> Na verdade a trigger não fica ligada a ninguém... Ela fica 
escutando o
> "banco todo" no geral...
> Se "algo" satisfazer a condição da trigger, ela será ativada...
> No caso, utilize uma "AFTER LOGON ON DATABASE"
> Parecido com isso:
> 
> CREATE OR REPLACE TRIGGER SomenteSistema AFTER LOGON ON DATABASE
> BEGIN
> .
> {suas condições e ações}
> .
> END;
> 
> Em 23/05/07, Bia Fitzgerald  escreveu:
> >
> > Oi, Gustavo. Imaginei algo assim. Um job, talvez. Que rode o tempo
> > inteiro.
> > Mas uma Trigger ficaria ligada a quem??
> > Obrigada.
> >
> > - Mensagem original 
> > De: Gustavo Venturini de Lima 
> > >
> > Para: [EMAIL PROTECTED] os.com.br 
> > Enviadas: Quarta-feira, 23 de Maio de 2007 16:55:21
> > Assunto: Re: [oracle_br] Segurança
> >
> > Bia, para o Oracle a conexão será a mesma (independente do método
> > utilizado).
> > Porém, podes fazer uma trigger que consulte o campo "program" da
> > v$session..
> > Lá aparecerá o Toad.exe por exemplo, e aí sim vc escolhe para 
desconectar
> > o
> > usuário...
> > Ou então colocar que se for <> de NOME_DA_SUA_ APP ele desconecta 
o
> > cara...
> >
> > Em 23/05/07, Bia Fitzgerald  escreveu:
> > >
> > > Olá pessoal...
> > >
> > > Alguém sabe como impedir que um determinado usuário acesse o BD 
via
> > > aplicativos como sqlplus e TOAD e somente acesse via sistema?
> > > Obrigada,
> > > Bia.
> > >
> > >  _ _ _ _ __
> > > Fale com seus amigos de graça com o novo Yahoo! Messenger
> > > http://br.messenger .yahoo.com/
> > >
> > > [As partes desta mensagem que não continham texto foram 
removidas]
> > >
> > >
> > >
> >
> > [As partes desta mensagem que não continham texto foram removidas]
> >
> >  _ _ _ _ __
> > Fale com seus amigos de graça com o novo Yahoo! Messenger
> > http://br.messenger .yahoo.com/
> >
> > [As partes desta mensagem que não continham texto foram removidas]
> >
> > 
> >
> 
> [As partes desta mensagem que não continham texto foram removidas]
> 
> 
> 
> 
>  _ _ _ _ __
> Fale com seus amigos de graça com o novo Yahoo! Messenger 
> http://br.messenger .yahoo.com/ 
> 
> [As partes desta mensagem que não continham texto foram removidas]
>




__
Fale com seus amigos  de graça com o novo Yahoo! Messenger 
http://br.messenger.yahoo.com/ 

[As partes desta mensagem que não continham texto foram removidas]

[oracle_br] [Web] - [contato-oraclebr] Oracle PL/SQL Cursores

[-]

Esta mensagem foi enviada via Web por Alexandre
A. Arakaki Endereço de resposta: [EMAIL PROTECTED]Olá,

Preciso do parecer de um consultor Oracle para me
responder a seguinte questão:


Posso afirmar que cursores explicitos são
utilizados APENAS para consultas
que retornam mais de uma linha?

ou

Posso dizer que cursores explícitos podem ser
utilizados para consultas que
retornam zero, uma ou mais linhas?

-- 
Atenciosamente,

Alexandre A. Arakaki
Analista de Tecnologia da Informação
UGSI - SGI - SEFAZ
Governo do Estado de Mato Grosso do Sul



[As partes desta mensagem que não continham texto foram removidas]

Res: Res: Res: Res: [oracle_br] Segurança

[Bia Fitzgerald]

Ótima idéia. Agradeço a ti e a todos pelas sugestões.
Obrigada!
Bia.


- Mensagem original 
De: jlchiappa <[EMAIL PROTECTED]>
Para: oracle_br@yahoogrupos.com.br
Enviadas: Quinta-feira, 24 de Maio de 2007 16:27:34
Assunto: Re: Res: Res: Res: [oracle_br] Segurança

argh, várias pessoas usando o mesmo account Oracle ** E ** regras de 
negócio e integridade fora do banco, negocinho triste, horroroso, mas 
já dei minha opinião sobre isso em outras msgs, todos já a conhecem 
imagino 
Bom, o que vc pode fazer na sua situação, além de lamentar muito a 
arquitetura desse sistema, seria :

a) alterar o sistema, de modo que haja um usuário "público", que 
todo mundo sabe a senha, mas usuário esse que não tem acesso NENHUM 
aos dados de Prod, como o usuário com o qual a tela inicial do 
sistema se conecta, só depois do usuário do sistema passou ok da tela 
inicial, aí sim o sistema fecha a conexão com o usuário "público" e 
abre (numa rotina CRIPTOGRAFADA, sem o usuário final enxergar") 
conexão com o usuário real

ou

b) o sistema conecta no banco com um usuário "secreto" que os 
operadores não sabem qual é, na tela inicial do sistema, de modo 
ESCONDIDO o sistema "guarda" alguma informação num local acessível ao 
banco (num arquivo-texto via utl_file, por exemplo) e depois conecta 
no usuário atual. Para esse usuário atual há uma ** trigger de logon 
** que tenta buscar a informação "guardada", logicamente se o usuário 
conectou fora do sistema a tela inicial não guardou a informação, o 
trigger de logon não a acha e rejeita a conexão

ou derivadas disso, como o já sugerido (mais de uma vez) trigger de 
logon que procura o nome do programa na V$SESSION. Repito, isso está 
*** LONGE *** de ser uma segurança inquebrável, apresenta o enorme 
problema de possuir uma chave (a tal informação, ou o nome do 
usuário, ou a coluna PROGRAM) residindo no banco, ficando portanto 
por sua conta "protegê-la" - key management é mesmo um caso sério, 
imho a melhor coisa ainda é NÂO TER CHAVE alguma no banco...

[]s

Chiappa

--- Em [EMAIL PROTECTED] os.com.br, Bia Fitzgerald  
escreveu
>
> Pessoal,
> 
> Há um usuário de conexão que tem grants de update, select, insert 
e delete nas tabelas do sistema e mais resource e connect.
> Os operadores só tem acesso ao sistema via este usuário. Mas 
estavam conectando via TOAD e SQLPLUS e alterando dados. Quero que 
este usuário só sirva para conectar via meu sistema .
> Há regras de negócio no sistema..
> 
> Obrigada,
> Bia.
> 
> - Mensagem original 
> De: jlchiappa <[EMAIL PROTECTED] ...>
> Para: [EMAIL PROTECTED] os.com.br
> Enviadas: Quinta-feira, 24 de Maio de 2007 15:03:43
> Assunto: Re: Res: Res: [oracle_br] Segurança
> 
> repito : os dados JÁ DEVIAM estar sendo protegidos diretamente pelo 
> banco, via constraints, GRANTs, views, triggers, etc, caso esse em 
> que seria *** ABSOLUTAMENTE INDIFERENTE *** se está se fazendo 
acesso 
> e/ou alterando-os via sistema ou via plus ou via o que for, ok ??
> SE isso não é indiferente, vc NÂO ESTÁ usando esse método mais 
> recomendado - provavelmente como eu disse deve estar tendo 
> integridade/ regras de negócio sendo efetuadas FORA DO BANCO, pelo 
> aplicativo somente, o que não só engessa os dados como disse mas 
> também EXIGE alguma codificação especializada e complexa, e NÂO É 
> GARANTIDO, certo ? Se esse é o seu caso, é ir pra trigger de logon 
> mesmo provavelmente , MAS SABENDO que não está fazendo o correto e 
> idela, há FRAQUEZA inerente à essa lógica, sim ?
> 
> []s
> 
> Chiappa
> --- Em [EMAIL PROTECTED] os.com.br, Bia Fitzgerald 
 
> escreveu
> >
> > A intenção é proteger os dados. Que eles não sejam alterados via 
> aplicativos, somente pelo executável do próprio sistema. O usuário 
X, 
> só poderá fazer acesso ao BD via sistema e não pelos aplicativos de 
> acesso ao Oracle.
> > Obrigada pela ajuda,
> > Bia.
> > 
> > 
> > - Mensagem original 
> > De: jlchiappa 
> > Para: [EMAIL PROTECTED] os.com.br
> > Enviadas: Quinta-feira, 24 de Maio de 2007 10:13:35
> > Assunto: Re: Res: [oracle_br] Segurança
> > 
> > Bia, ainda sobre esse ponto, deixe-me adicionar alguns itens : no 
> bd 
> > Oracle uma conexão é uma conexão, absolutamente NÂO IMPORTA quem 
> está 
> > conectando, não há MESMO nenhum código no kernel que tente 
> > identificar. ... Isso faz TODO o sentido inclusive, já que 
> informações 
> > do cliente estão FORA DO CONTROLE do banco, e podem ser 
> falsificadas 
> > de modo MUITO Fácil - por exemplo, se vc seguir o conselho dos 
> > colegas e tentar capturar o nome do programa numa trigger, E SE 
> > alguém fizer um rename sqlplus.exe to nomepermitido. exe, por 
> > exemplo  Acho muito muito ** frágil ** essa lógica
> > Segundo item : idealmente, as regras de negócio estão NO BANCO DE 
> > DADOS, via triggers, constraints, relacionamentos, views, etc, 
> assim 
> > NÂO IMPORTA com qual tool a pessoa conecta, as primary keys estão 
> lá, 
> > os grants estão lá, as views estão lá, e 

Re: Res: Res: Res: [oracle_br] Segurança

[jlchiappa]

argh, várias pessoas usando o mesmo account Oracle ** E ** regras de 
negócio e integridade fora do banco, negocinho triste, horroroso, mas 
já dei minha opinião sobre isso em outras msgs, todos já a conhecem 
imagino 
 Bom, o que vc pode fazer na sua situação, além de lamentar muito a 
arquitetura desse sistema, seria :
 
 a) alterar o sistema, de modo que haja um usuário "público", que 
todo mundo sabe a senha, mas usuário esse que não tem acesso NENHUM 
aos dados de Prod, como o usuário com o qual a tela inicial do 
sistema se conecta, só depois do usuário do sistema passou ok da tela 
inicial, aí sim o sistema fecha a conexão com o usuário "público" e 
abre (numa rotina CRIPTOGRAFADA, sem o usuário final enxergar") 
conexão com o usuário real
 
 ou
 
 b) o sistema conecta no banco com um usuário "secreto" que os 
operadores não sabem qual é, na tela inicial do sistema, de modo 
ESCONDIDO o sistema "guarda" alguma informação num local acessível ao 
banco (num arquivo-texto via utl_file, por exemplo) e depois conecta 
no usuário atual. Para esse usuário atual há uma ** trigger de logon 
** que tenta buscar a informação "guardada", logicamente se o usuário 
conectou fora do sistema a tela inicial não guardou a informação, o 
trigger de logon não a acha e rejeita a conexão
 
 ou derivadas disso, como o já sugerido (mais de uma vez) trigger de 
logon que procura o nome do programa na V$SESSION. Repito, isso está 
*** LONGE *** de ser uma segurança inquebrável, apresenta o enorme 
problema de possuir uma chave (a tal informação, ou o nome do 
usuário, ou a coluna PROGRAM) residindo no banco, ficando portanto 
por sua conta "protegê-la" - key management é mesmo um caso sério, 
imho a melhor coisa ainda é NÂO TER CHAVE alguma no banco...
 
 []s
 
  Chiappa
  
--- Em oracle_br@yahoogrupos.com.br, Bia Fitzgerald <[EMAIL PROTECTED]> 
escreveu
>
> Pessoal,
> 
> Há um  usuário de conexão que tem grants de update, select, insert 
e delete nas tabelas do sistema e mais resource e connect.
> Os operadores só tem acesso ao sistema via este usuário. Mas 
estavam conectando via TOAD e SQLPLUS e alterando dados. Quero que 
este usuário só sirva para conectar via meu sistema .
> Há regras de negócio no sistema..
> 
> Obrigada,
> Bia.
> 
> - Mensagem original 
> De: jlchiappa <[EMAIL PROTECTED]>
> Para: oracle_br@yahoogrupos.com.br
> Enviadas: Quinta-feira, 24 de Maio de 2007 15:03:43
> Assunto: Re: Res: Res: [oracle_br] Segurança
> 
> repito : os dados JÁ DEVIAM estar sendo protegidos diretamente pelo 
> banco, via constraints, GRANTs, views, triggers, etc, caso esse em 
> que seria *** ABSOLUTAMENTE INDIFERENTE *** se está se fazendo 
acesso 
> e/ou alterando-os via sistema ou via plus ou via o que for, ok ??
> SE isso não é indiferente, vc NÂO ESTÁ usando esse método mais 
> recomendado - provavelmente como eu disse deve estar tendo 
> integridade/ regras de negócio sendo efetuadas FORA DO BANCO, pelo 
> aplicativo somente, o que não só engessa os dados como disse mas 
> também EXIGE alguma codificação especializada e complexa, e NÂO É 
> GARANTIDO, certo ? Se esse é o seu caso, é ir pra trigger de logon 
> mesmo provavelmente , MAS SABENDO que não está fazendo o correto e 
> idela, há FRAQUEZA inerente à essa lógica, sim ?
> 
> []s
> 
> Chiappa
> --- Em [EMAIL PROTECTED] os.com.br, Bia Fitzgerald 
 
> escreveu
> >
> > A intenção é proteger os dados. Que eles não sejam alterados via 
> aplicativos, somente pelo executável do próprio sistema. O usuário 
X, 
> só poderá fazer acesso ao BD via sistema e não pelos aplicativos de 
> acesso ao Oracle.
> > Obrigada pela ajuda,
> > Bia.
> > 
> > 
> > - Mensagem original 
> > De: jlchiappa 
> > Para: [EMAIL PROTECTED] os.com.br
> > Enviadas: Quinta-feira, 24 de Maio de 2007 10:13:35
> > Assunto: Re: Res: [oracle_br] Segurança
> > 
> > Bia, ainda sobre esse ponto, deixe-me adicionar alguns itens : no 
> bd 
> > Oracle uma conexão é uma conexão, absolutamente NÂO IMPORTA quem 
> está 
> > conectando, não há MESMO nenhum código no kernel que tente 
> > identificar. ... Isso faz TODO o sentido inclusive, já que 
> informações 
> > do cliente estão FORA DO CONTROLE do banco, e podem ser 
> falsificadas 
> > de modo MUITO Fácil - por exemplo, se vc seguir o conselho dos 
> > colegas e tentar capturar o nome do programa numa trigger, E SE 
> > alguém fizer um rename sqlplus.exe to nomepermitido. exe, por 
> > exemplo  Acho muito muito ** frágil ** essa lógica
> > Segundo item : idealmente, as regras de negócio estão NO BANCO DE 
> > DADOS, via triggers, constraints, relacionamentos, views, etc, 
> assim 
> > NÂO IMPORTA com qual tool a pessoa conecta, as primary keys estão 
> lá, 
> > os grants estão lá, as views estão lá, e cada usuário final do 
> > sistema tem o seu usuário de banco, o qual só ele sabe a senha, 
> então 
> > o usuário final *** só vai enxergar *** o que pode, ** só vai 
fazer 
> > ** o que tem direito, independente da tool, ok ? Normalment

RES: Res: Res: [oracle_br] Segurança

[Fabio Santos]

Porque voce não cria uma senha específica para esse usuário do oracle e
coloque dentro do seu sistema sem que ninguém tenha acesso?
Qual a plataforma do sistema?
Se for windows/WEB pode criar por exemplo um arquivo UDL com a senha
gravada (fica exposto porque não criptografa) mas aí vc tira as
permissões do diretório e só deixa o administrador e o IUSR ter acesso a
ele.
 
Se for desktop, coloque dentro do sistema. O problema é que terá que
recompila-lo em caso de alteração de senha.
 
 
Depois disso, o pessoal terá que entrar no sistema para mexer no banco
visto que ninguém mais saberá a senha.
 
abraços
 
 

-Mensagem original-
De: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED]
Em nome de Bia Fitzgerald
Enviada em: quinta-feira, 24 de maio de 2007 15:31
Para: oracle_br@yahoogrupos.com.br
Assunto: Res: Res: Res: [oracle_br] Segurança



Pessoal,

Há um usuário de conexão que tem grants de update, select, insert e
delete nas tabelas do sistema e mais resource e connect.
Os operadores só tem acesso ao sistema via este usuário. Mas estavam
conectando via TOAD e SQLPLUS e alterando dados. Quero que este usuário
só sirva para conectar via meu sistema .
Há regras de negócio no sistema..

Obrigada,
Bia.

- Mensagem original 
De: jlchiappa <[EMAIL PROTECTED] 
com.br>
Para: [EMAIL PROTECTED] 
os.com.br
Enviadas: Quinta-feira, 24 de Maio de 2007 15:03:43
Assunto: Re: Res: Res: [oracle_br] Segurança

repito : os dados JÁ DEVIAM estar sendo protegidos diretamente pelo 
banco, via constraints, GRANTs, views, triggers, etc, caso esse em 
que seria *** ABSOLUTAMENTE INDIFERENTE *** se está se fazendo acesso 
e/ou alterando-os via sistema ou via plus ou via o que for, ok ??
SE isso não é indiferente, vc NÂO ESTÁ usando esse método mais 
recomendado - provavelmente como eu disse deve estar tendo 
integridade/ regras de negócio sendo efetuadas FORA DO BANCO, pelo 
aplicativo somente, o que não só engessa os dados como disse mas 
também EXIGE alguma codificação especializada e complexa, e NÂO É 
GARANTIDO, certo ? Se esse é o seu caso, é ir pra trigger de logon 
mesmo provavelmente , MAS SABENDO que não está fazendo o correto e 
idela, há FRAQUEZA inerente à essa lógica, sim ?

[]s

Chiappa
--- Em [EMAIL PROTECTED] os.com.br, Bia Fitzgerald  
escreveu
>
> A intenção é proteger os dados. Que eles não sejam alterados via 
aplicativos, somente pelo executável do próprio sistema. O usuário X, 
só poderá fazer acesso ao BD via sistema e não pelos aplicativos de 
acesso ao Oracle.
> Obrigada pela ajuda,
> Bia.
> 
> 
> - Mensagem original 
> De: jlchiappa <[EMAIL PROTECTED] ..>
> Para: [EMAIL PROTECTED] os.com.br
> Enviadas: Quinta-feira, 24 de Maio de 2007 10:13:35
> Assunto: Re: Res: [oracle_br] Segurança
> 
> Bia, ainda sobre esse ponto, deixe-me adicionar alguns itens : no 
bd 
> Oracle uma conexão é uma conexão, absolutamente NÂO IMPORTA quem 
está 
> conectando, não há MESMO nenhum código no kernel que tente 
> identificar. ... Isso faz TODO o sentido inclusive, já que 
informações 
> do cliente estão FORA DO CONTROLE do banco, e podem ser 
falsificadas 
> de modo MUITO Fácil - por exemplo, se vc seguir o conselho dos 
> colegas e tentar capturar o nome do programa numa trigger, E SE 
> alguém fizer um rename sqlplus.exe to nomepermitido. exe, por 
> exemplo  Acho muito muito ** frágil ** essa lógica
> Segundo item : idealmente, as regras de negócio estão NO BANCO DE 
> DADOS, via triggers, constraints, relacionamentos, views, etc, 
assim 
> NÂO IMPORTA com qual tool a pessoa conecta, as primary keys estão 
lá, 
> os grants estão lá, as views estão lá, e cada usuário final do 
> sistema tem o seu usuário de banco, o qual só ele sabe a senha, 
então 
> o usuário final *** só vai enxergar *** o que pode, ** só vai fazer 
> ** o que tem direito, independente da tool, ok ? Normalmente quem 
> tenta fazer restrição desse tipo baseado no aplicativo é porque tem 
> regras de negócio NO APLICATIVO, aí as coisas realmente podem 
quebrar 
> se a pessoa conectar com outra coisa que não o aplicativo.. . .. Sem 
> sombra de dúvida, isso deixa a Empresa absolutamente "ENGESSADA", 
ela 
> NUNCA vai poder aposentar esse aplicativo sem perda de dados, NUNCA 
> vai poder usar tools de query/busioness intelligence sem extensa 
> customização  Afora o desenvolvedor do aplicativo (que tem 
> serviço garantido), acho que NINGUÉM fica feliz com isso.
> 
> ==> o meu ponto asim é : SE realmente vc tiver que fazer esse 
enrome 
> contra-senso, conheça os pontos fracos, ok ? 
> 
> []s
> 
> Chiappa
> 
> --- Em [EMAIL PROTECTED] os.com.br, Bia Fitzgerald 
 
> escreveu
> >
> > ahhh, sim.. Muito obrigada.
> > :)
> > 
> > 
> > - Mensagem original 
> > De: Gustavo Venturini de Lima 
> > Para: [EMAIL PROTECTED] os.com.br
> > Enviadas: Quarta-feira, 23 de Maio de 2007 18:34:19
> > Assunto: Re: [oracle_br] Segurança
> > 
> > Na verdade a t

Res: Res: Res: [oracle_br] Segurança

[Bia Fitzgerald]

Pessoal,

Há um  usuário de conexão que tem grants de update, select, insert e delete nas 
tabelas do sistema e mais resource e connect.
Os operadores só tem acesso ao sistema via este usuário. Mas estavam conectando 
via TOAD e SQLPLUS e alterando dados. Quero que este usuário só sirva para 
conectar via meu sistema .
Há regras de negócio no sistema..

Obrigada,
Bia.

- Mensagem original 
De: jlchiappa <[EMAIL PROTECTED]>
Para: oracle_br@yahoogrupos.com.br
Enviadas: Quinta-feira, 24 de Maio de 2007 15:03:43
Assunto: Re: Res: Res: [oracle_br] Segurança

repito : os dados JÁ DEVIAM estar sendo protegidos diretamente pelo 
banco, via constraints, GRANTs, views, triggers, etc, caso esse em 
que seria *** ABSOLUTAMENTE INDIFERENTE *** se está se fazendo acesso 
e/ou alterando-os via sistema ou via plus ou via o que for, ok ??
SE isso não é indiferente, vc NÂO ESTÁ usando esse método mais 
recomendado - provavelmente como eu disse deve estar tendo 
integridade/ regras de negócio sendo efetuadas FORA DO BANCO, pelo 
aplicativo somente, o que não só engessa os dados como disse mas 
também EXIGE alguma codificação especializada e complexa, e NÂO É 
GARANTIDO, certo ? Se esse é o seu caso, é ir pra trigger de logon 
mesmo provavelmente , MAS SABENDO que não está fazendo o correto e 
idela, há FRAQUEZA inerente à essa lógica, sim ?

[]s

Chiappa
--- Em [EMAIL PROTECTED] os.com.br, Bia Fitzgerald  
escreveu
>
> A intenção é proteger os dados. Que eles não sejam alterados via 
aplicativos, somente pelo executável do próprio sistema. O usuário X, 
só poderá fazer acesso ao BD via sistema e não pelos aplicativos de 
acesso ao Oracle.
> Obrigada pela ajuda,
> Bia.
> 
> 
> - Mensagem original 
> De: jlchiappa <[EMAIL PROTECTED] ..>
> Para: [EMAIL PROTECTED] os.com.br
> Enviadas: Quinta-feira, 24 de Maio de 2007 10:13:35
> Assunto: Re: Res: [oracle_br] Segurança
> 
> Bia, ainda sobre esse ponto, deixe-me adicionar alguns itens : no 
bd 
> Oracle uma conexão é uma conexão, absolutamente NÂO IMPORTA quem 
está 
> conectando, não há MESMO nenhum código no kernel que tente 
> identificar. ... Isso faz TODO o sentido inclusive, já que 
informações 
> do cliente estão FORA DO CONTROLE do banco, e podem ser 
falsificadas 
> de modo MUITO Fácil - por exemplo, se vc seguir o conselho dos 
> colegas e tentar capturar o nome do programa numa trigger, E SE 
> alguém fizer um rename sqlplus.exe to nomepermitido. exe, por 
> exemplo  Acho muito muito ** frágil ** essa lógica
> Segundo item : idealmente, as regras de negócio estão NO BANCO DE 
> DADOS, via triggers, constraints, relacionamentos, views, etc, 
assim 
> NÂO IMPORTA com qual tool a pessoa conecta, as primary keys estão 
lá, 
> os grants estão lá, as views estão lá, e cada usuário final do 
> sistema tem o seu usuário de banco, o qual só ele sabe a senha, 
então 
> o usuário final *** só vai enxergar *** o que pode, ** só vai fazer 
> ** o que tem direito, independente da tool, ok ? Normalmente quem 
> tenta fazer restrição desse tipo baseado no aplicativo é porque tem 
> regras de negócio NO APLICATIVO, aí as coisas realmente podem 
quebrar 
> se a pessoa conectar com outra coisa que não o aplicativo.. . .. Sem 
> sombra de dúvida, isso deixa a Empresa absolutamente "ENGESSADA", 
ela 
> NUNCA vai poder aposentar esse aplicativo sem perda de dados, NUNCA 
> vai poder usar tools de query/busioness intelligence sem extensa 
> customização  Afora o desenvolvedor do aplicativo (que tem 
> serviço garantido), acho que NINGUÉM fica feliz com isso.
> 
> ==> o meu ponto asim é : SE realmente vc tiver que fazer esse 
enrome 
> contra-senso, conheça os pontos fracos, ok ? 
> 
> []s
> 
> Chiappa
> 
> --- Em [EMAIL PROTECTED] os.com.br, Bia Fitzgerald 
 
> escreveu
> >
> > ahhh, sim.. Muito obrigada.
> > :)
> > 
> > 
> > - Mensagem original 
> > De: Gustavo Venturini de Lima 
> > Para: [EMAIL PROTECTED] os.com.br
> > Enviadas: Quarta-feira, 23 de Maio de 2007 18:34:19
> > Assunto: Re: [oracle_br] Segurança
> > 
> > Na verdade a trigger não fica ligada a ninguém... Ela fica 
> escutando o
> > "banco todo" no geral...
> > Se "algo" satisfazer a condição da trigger, ela será ativada...
> > No caso, utilize uma "AFTER LOGON ON DATABASE"
> > Parecido com isso:
> > 
> > CREATE OR REPLACE TRIGGER SomenteSistema AFTER LOGON ON DATABASE
> > BEGIN
> > .
> > {suas condições e ações}
> > .
> > END;
> > 
> > Em 23/05/07, Bia Fitzgerald  escreveu:
> > >
> > > Oi, Gustavo. Imaginei algo assim. Um job, talvez. Que rode o 
tempo
> > > inteiro.
> > > Mas uma Trigger ficaria ligada a quem??
> > > Obrigada.
> > >
> > > - Mensagem original 
> > > De: Gustavo Venturini de Lima  40gmail.com>
> > > >
> > > Para: [EMAIL PROTECTED] os.com.br  rupos..com. br>
> > > Enviadas: Quarta-feira, 23 de Maio de 2007 16:55:21
> > > Assunto: Re: [oracle_br] Segurança
> > >
> > > Bia, para o Oracle a conexão será a mesma (independente do 
método
> > > utilizado).
> > > Porém, podes 

RES: [oracle_br] Re: Opinião para melhorar desempenho

[Carlos A.M. Menezes]

Colega,

Comecei a ler sua mensagem e confesso que me perdi um pouco, por 
isso, vou comentar apenas sobre suas dúvidas sobre ASM, que me parecem serem 
muitas:

1-   O ASM é exclusivo para arquivos do database Oracle, logo, não dá para 
usar ASM como file system genérico, como você parecer ter apenas 4 discos, 
então vai ter que dedicar um ou mais disco para o file system;

2-   Mesmo os 4 discos totalmente dedicados para o ASM, ainda assim 
considero muito poucos discos para se perceber alguma diferença em relação a 
utilizar file system, principalmente em questões de desempenho;

3-   O ASM consegue fazer redundância própria ou utilizar a redundância 
externa (RAID), ou ambos se desejar, o overhead da redundância implementada por 
software é maior que a implementada por hardware.

 

Eu utilizo ASM em ambiente RAC, uma obrigação para quem trabalha com versões 
Standard do Oracle, utiliza 10 discos em RAID10 e no ASM eu utilizo a 
redundância externa, ou seja, a implementada pelo meu storage. A performance é 
muito boa, mas poderia ser melhor se tivesse mais discos.

 

Cordialmente,

 

Carlos Alfredo

 

 

-Mensagem original-
De: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] Em nome de Heber 
Goncalves
Enviada em: quinta-feira, 24 de maio de 2007 14:32
Para: oracle_br@yahoogrupos.com.br
Assunto: RES: [oracle_br] Re: Opinião para melhorar desempenho

 


Primeiramente gostaria de agradecer a todos pelas respostas.

Em segundo lugar, gostaria de comentar sua mensagem, Chiappa.

Concordo com vc que podemos fazer muito pouco sem termos um DBA para
levantar todas as análises que vc sugeriu, mas já estou no olho do furacão,
fui escalado pra tentar resolver esse problema e uso da minha posição pra
fazer o possível, mas a minha grande dificuldade tem sido ter uma idéia do
que seria melhor para o Oracle em teremos de Storage, se usar Raid 5, 10,
0+1, ou se deveria usar ASM. Ambos aplicam a metodologia SAME, certo?

Enfim, fui convencido pelo BAARF que RAID 5 não seria o ideal para esse caso
já que nosso problema tem sido desempenho, e como ele traz um overhead de
escrita, descartamos essa hipótese. 

Trabalho agora com a hipótese de utilizar os 4 discos em Raid 10 (ou 0+1)
com todos os arquivos do SO, mais os datafiles sendo distribuídos pelos
discos, ainda com ganho de segurança pelo mirroring. Outra hipótese seria
utilizar um disco para SO + aplicação e os outros 3 deixar para o Oracle
gerenciar com ASM.

Não tenho experiência com ASM e isso me dificulta a decidir qual seria mais
viável. Chiappa ou alguém da lista, poderia me dar uma sugestão do que fazer
nesse caso? O gargalo principal é desempenho, mas a vantagem de redundância
do RAID 10 também conta como um ponto importante. O ASM me permite alguma
forma de redundância? Há algum acréscimo considerável de performance?

Chiappa, quanto aos outros pontos que vc levantou:

1) Tenho certeza que eles não fizeram "todo o tunning SQL possível", com uma
análise bem rasa tenho achado indicadores importantes, como gravações
excessivas em arquivos de índices, etc, mas isso é o que a equipe de
desenvolvimento me passou. Como disse, não sou DBA e não tenho a obrigação
de encontrar todos esses erros, tenho apenas que fazer o possível para
melhor o desempenho do Oracle em termos de I/O, o que encontrar de errado
quanto às queries já é lucro pra eles...

2) Quando disse que gostaria de utilizar LVM para evitar problemas com
partição lotada por escrita indiscriminada da aplicação, eu estava me
referindo a aplicação que solicita o I/O, não o Oracle. A aplicação nesse
caso coleta informações de elementos externos e faz uso intensivo de escrita
em períodos pré-determinados, somando-se a isso o cliente gera relatórios
que fazem muita leitura em alguns períodos do dia, muitas vezes essas
tarefas são realizadas ao mesmo tempo, por isso tenho um tempo de resposta
muito lento. Fiz a pergunta quanto ao LVM pois já vi gente falando que isso
pode gerar uma complexidade desnecessária dependendo do layout de storage
adotado. Se eu tiver os 4 discos em Raid, tenho que tipo de implicações
usando LVM? Nesse caso seria melhor eu esquecer do LVM e fazer uma grande
partição com todos os datafiles (que seriam distribuídos por todos os discos
em stripping)?

3) Passei esses dias analisando o desempenho da máquina e notei que o backup
está sendo feito pelo cliente durante o dia, na verdade eles começam de
noite, mas há troca de fita e é finalizado perto da hora do almoço. Um dos
indicadores negativos que o ADDM me aponta é escrita excessiva em arquivo de
log, essa pode ser uma das causas? Quanto de perda de performance pode ser
devida a essa estratégia de backup? Devo argumentar isso com o cliente?

Pessoal, realmente muito obrigado pela ajuda.

Abraços

Heber Blain Gonçalves

_ 

De: [EMAIL PROTECTED]  os.com.br 
[mailto:[EMAIL PROTECTED]  os.com.br] Em
nome de jlchiappa

[oracle_br] Oracle Warehouse Builder

[mateusmelhado]

Senhores,

Alguem podeia me ajudar, estou utilizando o Oracle Warehouse Builder 
10, e preciso acessar uma base SQL Server, como faço isso?

Obrigado

Re: Res: Res: [oracle_br] Segurança

[jlchiappa]

repito : os dados JÁ DEVIAM estar sendo protegidos diretamente pelo 
banco, via constraints, GRANTs, views, triggers, etc, caso esse em 
que seria *** ABSOLUTAMENTE INDIFERENTE *** se está se fazendo acesso 
e/ou alterando-os  via sistema ou via plus ou via o que for, ok ??
  SE isso não é indiferente, vc NÂO ESTÁ usando esse método mais 
recomendado - provavelmente como eu disse deve estar tendo 
integridade/regras de negócio sendo efetuadas FORA DO BANCO, pelo 
aplicativo somente, o que não só engessa os dados como disse mas 
também EXIGE alguma codificação especializada e complexa, e NÂO É 
GARANTIDO, certo ? Se esse é o seu caso, é ir pra trigger de logon 
mesmo provavelmente , MAS SABENDO que não está fazendo o correto e 
idela, há FRAQUEZA inerente à essa lógica, sim ?

[]s

 Chiappa
--- Em oracle_br@yahoogrupos.com.br, Bia Fitzgerald <[EMAIL PROTECTED]> 
escreveu
>
> A intenção é proteger os dados. Que eles não sejam alterados via 
aplicativos, somente pelo executável do próprio sistema. O usuário X, 
só poderá fazer acesso ao BD via sistema e não pelos aplicativos de 
acesso ao Oracle.
> Obrigada pela ajuda,
> Bia.
> 
> 
> - Mensagem original 
> De: jlchiappa <[EMAIL PROTECTED]>
> Para: oracle_br@yahoogrupos.com.br
> Enviadas: Quinta-feira, 24 de Maio de 2007 10:13:35
> Assunto: Re: Res: [oracle_br] Segurança
> 
> Bia, ainda sobre esse ponto, deixe-me adicionar alguns itens : no 
bd 
> Oracle uma conexão é uma conexão, absolutamente NÂO IMPORTA quem 
está 
> conectando, não há MESMO nenhum código no kernel que tente 
> identificar. ... Isso faz TODO o sentido inclusive, já que 
informações 
> do cliente estão FORA DO CONTROLE do banco, e podem ser 
falsificadas 
> de modo MUITO Fácil - por exemplo, se vc seguir o conselho dos 
> colegas e tentar capturar o nome do programa numa trigger, E SE 
> alguém fizer um rename sqlplus.exe to nomepermitido. exe, por 
> exemplo  Acho muito muito ** frágil ** essa lógica
> Segundo item : idealmente, as regras de negócio estão NO BANCO DE 
> DADOS, via triggers, constraints, relacionamentos, views, etc, 
assim 
> NÂO IMPORTA com qual tool a pessoa conecta, as primary keys estão 
lá, 
> os grants estão lá, as views estão lá, e cada usuário final do 
> sistema tem o seu usuário de banco, o qual só ele sabe a senha, 
então 
> o usuário final *** só vai enxergar *** o que pode, ** só vai fazer 
> ** o que tem direito, independente da tool, ok ? Normalmente quem 
> tenta fazer restrição desse tipo baseado no aplicativo é porque tem 
> regras de negócio NO APLICATIVO, aí as coisas realmente podem 
quebrar 
> se a pessoa conectar com outra coisa que não o aplicativo... .. Sem 
> sombra de dúvida, isso deixa a Empresa absolutamente "ENGESSADA", 
ela 
> NUNCA vai poder aposentar esse aplicativo sem perda de dados, NUNCA 
> vai poder usar tools de query/busioness intelligence sem extensa 
> customização  Afora o desenvolvedor do aplicativo (que tem 
> serviço garantido), acho que NINGUÉM fica feliz com isso.
> 
> ==> o meu ponto asim é : SE realmente vc tiver que fazer esse 
enrome 
> contra-senso, conheça os pontos fracos, ok ? 
> 
> []s
> 
> Chiappa
> 
> --- Em [EMAIL PROTECTED] os.com.br, Bia Fitzgerald 
 
> escreveu
> >
> > ahhh, sim.. Muito obrigada.
> > :)
> > 
> > 
> > - Mensagem original 
> > De: Gustavo Venturini de Lima 
> > Para: [EMAIL PROTECTED] os.com.br
> > Enviadas: Quarta-feira, 23 de Maio de 2007 18:34:19
> > Assunto: Re: [oracle_br] Segurança
> > 
> > Na verdade a trigger não fica ligada a ninguém... Ela fica 
> escutando o
> > "banco todo" no geral...
> > Se "algo" satisfazer a condição da trigger, ela será ativada...
> > No caso, utilize uma "AFTER LOGON ON DATABASE"
> > Parecido com isso:
> > 
> > CREATE OR REPLACE TRIGGER SomenteSistema AFTER LOGON ON DATABASE
> > BEGIN
> > .
> > {suas condições e ações}
> > .
> > END;
> > 
> > Em 23/05/07, Bia Fitzgerald  escreveu:
> > >
> > > Oi, Gustavo. Imaginei algo assim. Um job, talvez. Que rode o 
tempo
> > > inteiro.
> > > Mas uma Trigger ficaria ligada a quem??
> > > Obrigada.
> > >
> > > - Mensagem original 
> > > De: Gustavo Venturini de Lima  40gmail.com>
> > > >
> > > Para: [EMAIL PROTECTED] os.com.br  rupos.com. br>
> > > Enviadas: Quarta-feira, 23 de Maio de 2007 16:55:21
> > > Assunto: Re: [oracle_br] Segurança
> > >
> > > Bia, para o Oracle a conexão será a mesma (independente do 
método
> > > utilizado).
> > > Porém, podes fazer uma trigger que consulte o campo "program" da
> > > v$session..
> > > Lá aparecerá o Toad.exe por exemplo, e aí sim vc escolhe para 
> desconectar
> > > o
> > > usuário...
> > > Ou então colocar que se for <> de NOME_DA_SUA_ APP ele 
desconecta 
> o
> > > cara...
> > >
> > > Em 23/05/07, Bia Fitzgerald  
escreveu:
> > > >
> > > > Olá pessoal...
> > > >
> > > > Alguém sabe como impedir que um determinado usuário acesse o 
BD 
> via
> > > > aplicativos como sqlplus e TOAD e somente acesse via sistema?
> > > > Obrigada,
> > > > Bia.
> > > >

[oracle_br] dbms_scheduler.

[José Aristides]

Boa Tarde !!!
 
Tenho um script (inicio.sh) para gerar backup que quando executo manualmente 
"sql>@inicio.sh" no prompt do sqlplus funciona normalmente.
Assim, resolvi criar o job (abaixo) porém, ao executar pelo "exec 
dbms_scheduler.run_job('BACKUP')" exibe o seguinte erro:
 
*ERRO na linha 1:ORA-27475: "SYS.BACKUP" deve ser um jobORA-06512: em 
"SYS.DBMS_ISCHED", line 150ORA-06512: em "SYS.DBMS_SCHEDULER", line 
441ORA-06512: em line 1
 
 
BEGIN  dbms_scheduler.create_job(  job_name   => 'BACKUP',  job_type   => 
'EXECUTABLE',  job_action => '/home/oracle/backuporacle/gerar/inicio.sh',  
start_date => sysdate,  repeat_interval=> 'FREQ=MINUTELY;INTERVAL=2',  
enabled=> TRUE,  comments   => 'Demo for doing backup');END;/
 
 
obrigado,
 
Aristides
_
Procure em qualquer página Web com protecção eficaz. Obtenha já o Windows Live 
Toolbar GRATUITO!
http://www.toolbar.live.com

[As partes desta mensagem que não continham texto foram removidas]

RES: [oracle_br] Re: Opinião para melhorar desempe nho

[Heber Goncalves]

Primeiramente gostaria de agradecer a todos pelas respostas.

 

Em segundo lugar, gostaria de comentar sua mensagem, Chiappa.

 

Concordo com vc que podemos fazer muito pouco sem termos um DBA para
levantar todas as análises que vc sugeriu, mas já estou no olho do furacão,
fui escalado pra tentar resolver esse problema e uso da minha posição pra
fazer o possível, mas a minha grande dificuldade tem sido ter uma idéia do
que seria melhor para o Oracle em teremos de Storage, se usar Raid 5, 10,
0+1, ou se deveria usar ASM. Ambos aplicam a metodologia SAME, certo?

 

Enfim, fui convencido pelo BAARF que RAID 5 não seria o ideal para esse caso
já que nosso problema tem sido desempenho, e como ele traz um overhead de
escrita, descartamos essa hipótese. 

 

Trabalho agora com a hipótese de utilizar os 4 discos em Raid 10 (ou 0+1)
com todos os arquivos do SO, mais os datafiles sendo distribuídos pelos
discos, ainda com ganho de segurança pelo mirroring. Outra hipótese seria
utilizar um disco para SO + aplicação e os outros 3 deixar para o Oracle
gerenciar com ASM.

 

Não tenho experiência com ASM e isso me dificulta a decidir qual seria mais
viável. Chiappa ou alguém da lista, poderia me dar uma sugestão do que fazer
nesse caso? O gargalo principal é desempenho, mas a vantagem de redundância
do RAID 10 também conta como um ponto importante. O ASM me permite alguma
forma de redundância? Há algum acréscimo considerável de performance?

 

Chiappa, quanto aos outros pontos que vc levantou:

 

1) Tenho certeza que eles não fizeram “todo o tunning SQL possível”, com uma
análise bem rasa tenho achado indicadores importantes, como gravações
excessivas em arquivos de índices, etc, mas isso é o que a equipe de
desenvolvimento me passou. Como disse, não sou DBA e não tenho a obrigação
de encontrar todos esses erros, tenho apenas que fazer o possível para
melhor o desempenho do Oracle em termos de I/O, o que encontrar de errado
quanto às queries já é lucro pra eles...

 

2) Quando disse que gostaria de utilizar LVM para evitar problemas com
partição lotada por escrita indiscriminada da aplicação, eu estava me
referindo a aplicação que solicita o I/O, não o Oracle. A aplicação nesse
caso coleta informações de elementos externos e faz uso intensivo de escrita
em períodos pré-determinados, somando-se a isso o cliente gera relatórios
que fazem muita leitura em alguns períodos do dia, muitas vezes essas
tarefas são realizadas ao mesmo tempo, por isso tenho um tempo de resposta
muito lento. Fiz a pergunta quanto ao LVM pois já vi gente falando que isso
pode gerar uma complexidade desnecessária dependendo do layout de storage
adotado. Se eu tiver os 4 discos em Raid, tenho que tipo de implicações
usando LVM? Nesse caso seria melhor eu esquecer do LVM e fazer uma grande
partição com todos os datafiles (que seriam distribuídos por todos os discos
em stripping)?

 

3) Passei esses dias analisando o desempenho da máquina e notei que o backup
está sendo feito pelo cliente durante o dia, na verdade eles começam de
noite, mas há troca de fita e é finalizado perto da hora do almoço. Um dos
indicadores negativos que o ADDM me aponta é escrita excessiva em arquivo de
log, essa pode ser uma das causas? Quanto de perda de performance pode ser
devida a essa estratégia de backup? Devo argumentar isso com o cliente?

 

Pessoal, realmente muito obrigado pela ajuda.

 

Abraços

 

Heber Blain Gonçalves

  _  

De: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] Em
nome de jlchiappa
Enviada em: terça-feira, 22 de maio de 2007 13:10
Para: oracle_br@yahoogrupos.com.br
Assunto: [oracle_br] Re: Opinião para melhorar desempenho

 

Colega, alguns comentários : 

a) sem um DBA experiente presente, vc vai poder fazer MUITO, mas 
MUITO POUCO mesmo, tunning e quetais simplesmente DEMANDAM que um 
profissional do tipo esteja trabalhando junto com os desenvolvedores, 
sem isso fica DISTANTE a sua chance de sucesso (não só pela 
dificulade de analisar e descobrir os melhores ajustes do banco, MAS 
também o DBA é o elemento que introduz as "novas" tecnologias de 
banco aos desenvolvedores : assim, um DBA experiente não deixaria de 
mostrar aos desenvolvedores tabelas GTTs, índices bitmap e de função, 
funções analíticas, sintaxes extendidas de SELECT (como WITH cluase 
por exemplo) e muitos mais, que aí sim seriam avaliadas pelos 
desenvolvedores e se cabíveis implementadas Aqui no cliente é um 
sistema DW, os programadores fizeram algumas queries caírem de 10 
horas para meia hora usando GTTs, por exemplo, mas óbvio, primeiro eu 
tive que explicar pra eles o que é, como usa, não se foge disso

b) "o pessoal de desenvolvimento já fez todo o tuning sql possível" : 
cara, dica geral e genérica : confie DESCONFIANDO quando o pessoal 
diz que já fez todo o tunning possível, de modo geral isso NÂO é a 
exata representação da verdade Pra vc ter uma idéia do nível de 
tunning que foi feito, peça pro analista :

1. mostrar o TKPROF (ou 

RES: Res: [oracle_br] Segurança

[Fabio Santos]

Bia,
 
Caso ainda precise de ajuda quanto a sua segurança, recomendo que você
detalhe melhor, mas detalhe mesmo, como funciona atualmente e o que você
está querendo fazer. Se não, as dicas serão muito superficiais e podem
não servir diretamente ao que deseja. 
 
Vou te dar um exemplo. Do jeito que você está pedindo parece que os
usuários tem acesso pelo sistema, também tem o login ao banco de dados.
Ou seja, eles não tem um acesso de login no sistema e o sistema acessa o
banco com outro usuário. É acesso direto. Mas, você não disse isso.
Agente é que teve que pressupor. Aí de repente damos dicas que não tem
fundamento com o você quer.
 
Então, tente passar em detalhes o funcionamento, o problema atual  e o
que você deseja para resolver.
 
Abraços
 
 
 

-Mensagem original-
De: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED]
Em nome de Bia Fitzgerald
Enviada em: quinta-feira, 24 de maio de 2007 14:16
Para: oracle_br@yahoogrupos.com.br
Assunto: Res: Res: [oracle_br] Segurança



A intenção é proteger os dados. Que eles não sejam alterados via
aplicativos, somente pelo executável do próprio sistema. O usuário X, só
poderá fazer acesso ao BD via sistema e não pelos aplicativos de acesso
ao Oracle.
Obrigada pela ajuda,
Bia.

- Mensagem original 
De: jlchiappa <[EMAIL PROTECTED] 
com.br>
Para: [EMAIL PROTECTED] 
os.com.br
Enviadas: Quinta-feira, 24 de Maio de 2007 10:13:35
Assunto: Re: Res: [oracle_br] Segurança

Bia, ainda sobre esse ponto, deixe-me adicionar alguns itens : no bd 
Oracle uma conexão é uma conexão, absolutamente NÂO IMPORTA quem está 
conectando, não há MESMO nenhum código no kernel que tente 
identificar. ... Isso faz TODO o sentido inclusive, já que informações 
do cliente estão FORA DO CONTROLE do banco, e podem ser falsificadas 
de modo MUITO Fácil - por exemplo, se vc seguir o conselho dos 
colegas e tentar capturar o nome do programa numa trigger, E SE 
alguém fizer um rename sqlplus.exe to nomepermitido. exe, por 
exemplo  Acho muito muito ** frágil ** essa lógica
Segundo item : idealmente, as regras de negócio estão NO BANCO DE 
DADOS, via triggers, constraints, relacionamentos, views, etc, assim 
NÂO IMPORTA com qual tool a pessoa conecta, as primary keys estão lá, 
os grants estão lá, as views estão lá, e cada usuário final do 
sistema tem o seu usuário de banco, o qual só ele sabe a senha, então 
o usuário final *** só vai enxergar *** o que pode, ** só vai fazer 
** o que tem direito, independente da tool, ok ? Normalmente quem 
tenta fazer restrição desse tipo baseado no aplicativo é porque tem 
regras de negócio NO APLICATIVO, aí as coisas realmente podem quebrar 
se a pessoa conectar com outra coisa que não o aplicativo... .. Sem 
sombra de dúvida, isso deixa a Empresa absolutamente "ENGESSADA", ela 
NUNCA vai poder aposentar esse aplicativo sem perda de dados, NUNCA 
vai poder usar tools de query/busioness intelligence sem extensa 
customização  Afora o desenvolvedor do aplicativo (que tem 
serviço garantido), acho que NINGUÉM fica feliz com isso.

==> o meu ponto asim é : SE realmente vc tiver que fazer esse enrome 
contra-senso, conheça os pontos fracos, ok ? 

[]s

Chiappa

--- Em [EMAIL PROTECTED] os.com.br, Bia Fitzgerald  
escreveu
>
> ahhh, sim.. Muito obrigada.
> :)
> 
> 
> - Mensagem original 
> De: Gustavo Venturini de Lima 
> Para: [EMAIL PROTECTED] os.com.br
> Enviadas: Quarta-feira, 23 de Maio de 2007 18:34:19
> Assunto: Re: [oracle_br] Segurança
> 
> Na verdade a trigger não fica ligada a ninguém... Ela fica 
escutando o
> "banco todo" no geral...
> Se "algo" satisfazer a condição da trigger, ela será ativada...
> No caso, utilize uma "AFTER LOGON ON DATABASE"
> Parecido com isso:
> 
> CREATE OR REPLACE TRIGGER SomenteSistema AFTER LOGON ON DATABASE
> BEGIN
> .
> {suas condições e ações}
> .
> END;
> 
> Em 23/05/07, Bia Fitzgerald  escreveu:
> >
> > Oi, Gustavo. Imaginei algo assim. Um job, talvez. Que rode o tempo
> > inteiro.
> > Mas uma Trigger ficaria ligada a quem??
> > Obrigada.
> >
> > - Mensagem original 
> > De: Gustavo Venturini de Lima 
> > >
> > Para: [EMAIL PROTECTED] os.com.br 
> > Enviadas: Quarta-feira, 23 de Maio de 2007 16:55:21
> > Assunto: Re: [oracle_br] Segurança
> >
> > Bia, para o Oracle a conexão será a mesma (independente do método
> > utilizado).
> > Porém, podes fazer uma trigger que consulte o campo "program" da
> > v$session..
> > Lá aparecerá o Toad.exe por exemplo, e aí sim vc escolhe para 
desconectar
> > o
> > usuário...
> > Ou então colocar que se for <> de NOME_DA_SUA_ APP ele desconecta 
o
> > cara...
> >
> > Em 23/05/07, Bia Fitzgerald  escreveu:
> > >
> > > Olá pessoal...
> > >
> > > Alguém sabe como impedir que um determinado usuário acesse o BD 
via
> > > aplicativos como sqlplus e TOAD e somente acesse via sistema?
> > > Obrigada,
> > > Bia.
> > >
> > >  _ _ _ 

Res: [oracle_br] Segurança

[Bia Fitzgerald]

Vou testar. Muito obrigada, Vitor.
:)
[]s,
Bia


- Mensagem original 
De: Vitor Hugo Campos <[EMAIL PROTECTED]>
Para: oracle_br@yahoogrupos.com.br
Enviadas: Quinta-feira, 24 de Maio de 2007 13:26:43
Assunto: Re: [oracle_br] Segurança

Bia, impedir que o usuário acesse o banco através do seu executável não
adianta de nada porque o usuário pode simplesmente renomear o sqlplus
para seuprograma.. exe e rodar normalmente. Uma idéia do que você pode
fazer para atrapalhar a vida de algum engraçadinho que tente entrar via
SQLPlus seria você deixar o usuário só com acesso de CONNECT e criar uma
ROLE identificada por senha que conteria os acessos às tabelas dos seus
sistemas. Então, logo depois de entrar no sistema, a aplicação deve
executar o comando:

SET ROLE  IDENTIFIED BY ;

Para poder ter acesso ao resto dos dados.

A parte chata é definir onde vai ficar essa senha: ou você deixa no
próprio executável (daí a pessoa teria que usar um disassembler para
poder descobrir) ou você coloca em uma tabela em que os usuários
"normais" teriam acesso (mas qualquer curioso que fosse olhar as tabelas
que ele tem direito em ALL_TABLES poderia descobrir essa tabela e
identificar a senha). A partir dessas opções você pode escolher como
impedir que o usuário descubra essa senha (normalmente usando
criptografia, mas isso não tornaria impossível que a pessoa descubra, só
tornaria bem mais complicado, mas para a maioria dos casos já seria
suficiente).

O correto mesmo é não dar ao usuário mais acesso do que deveria ter (ex:
não dar qualquer grant do tipo ANY, como SELECT ANY TABLE, para os
usuários), e colocar auditoria nas tabelas importantes para descobrir
quem fez o que com seus dados. Daí, mesmo se alguém entrar com o
sqlplus, não conseguirá fazer muita coisa a mais do que faria através do
sistema.

Bia Fitzgerald escreveu:
>
> Olá pessoal...
>
> Alguém sabe como impedir que um determinado usuário acesse o BD via
> aplicativos como sqlplus e TOAD e somente acesse via sistema?
> Obrigada,
> Bia.
>
>  _ _ _ _ __
> Fale com seus amigos de graça com o novo Yahoo! Messenger
> http://br.messenger .yahoo.com/ 
>
> [As partes desta mensagem que não continham texto foram removidas]
>
> 

-- 
Vitor Hugo Campos

Desenvolvimento - Informática
Autoglass - Especialista em Vidro Automotivo
+55 (27) 2121-5531
http://www.autoglas s.com.br/




__
Fale com seus amigos  de graça com o novo Yahoo! Messenger 
http://br.messenger.yahoo.com/ 

[As partes desta mensagem que não continham texto foram removidas]

Re: [oracle_br] Segurança

[Vitor Hugo Campos]

Bia, impedir que o usuário acesse o banco através do seu executável não
adianta de nada porque o usuário pode simplesmente renomear o sqlplus
para seuprograma.exe e rodar normalmente. Uma idéia do que você pode
fazer para atrapalhar a vida de algum engraçadinho que tente entrar via
SQLPlus seria você deixar o usuário só com acesso de CONNECT e criar uma
ROLE identificada por senha que conteria os acessos às tabelas dos seus
sistemas. Então, logo depois de entrar no sistema, a aplicação deve
executar o comando:

SET ROLE  IDENTIFIED BY ;

Para poder ter acesso ao resto dos dados.

A parte chata é definir onde vai ficar essa senha: ou você deixa no
próprio executável (daí a pessoa teria que usar um disassembler para
poder descobrir) ou você coloca em uma tabela em que os usuários
"normais" teriam acesso (mas qualquer curioso que fosse olhar as tabelas
que ele tem direito em ALL_TABLES poderia descobrir essa tabela e
identificar a senha). A partir dessas opções você pode escolher como
impedir que o usuário descubra essa senha (normalmente usando
criptografia, mas isso não tornaria impossível que a pessoa descubra, só
tornaria bem mais complicado, mas para a maioria dos casos já seria
suficiente).

O correto mesmo é não dar ao usuário mais acesso do que deveria ter (ex:
não dar qualquer grant do tipo ANY, como SELECT ANY TABLE, para os
usuários), e colocar auditoria nas tabelas importantes para descobrir
quem fez o que com seus dados. Daí, mesmo se alguém entrar com o
sqlplus, não conseguirá fazer muita coisa a mais do que faria através do
sistema.

Bia Fitzgerald escreveu:
>
> Olá pessoal...
>
> Alguém sabe como impedir que um determinado usuário acesse o BD via
> aplicativos como sqlplus e TOAD e somente acesse via sistema?
> Obrigada,
> Bia.
>
> __
> Fale com seus amigos de graça com o novo Yahoo! Messenger
> http://br.messenger.yahoo.com/ 
>
> [As partes desta mensagem que não continham texto foram removidas]
>
>  


-- 
Vitor Hugo Campos

Desenvolvimento - Informática
Autoglass - Especialista em Vidro Automotivo
+55 (27) 2121-5531
http://www.autoglass.com.br/

[oracle_br] Re: Problemas com o uso do index!

[jlchiappa]

Renata, primeira coisa : * de onde * vc tirou a idéia de que, 
no CBO (que vc não diz, mas IMAGINO é o que está usando) , um access 
path só pode acessar um único índice por vez  Há muito tempo o 
CBO (desde a versão 8i, iirc) permite SIM vc combinar vários índices 
num só acesso, há inclusive o hint index_combine pra "incentivar" 
isso, cfrme mostrado em http://asktom.oracle.com/pls/asktom/f?
p=100:11:0P11_QUESTION_ID:3083446555294#3189823990102 e em 
http://jonathanlewis.wordpress.com/2007/02/08/index-combine/ , ok ?? 
Mande o plano de execução COMPLETO pra nós (substituindo os espaços 
em branco à esquerda por "." , para que a indentação não se perca) , 
mas provavelmente deve ser isso que deve estar acontecendo E 
lógico, isso parece indicar que os diversos índices nessa tabela 
possam ser recriados num índice só, composto Inclusive, 11 é um 
número normalmente considerado ** MONSTRUOSAMENTE ENORME ** de 
índices pra uma tabela só, é coisa de analista meia-boca que ouviu 
falar que "indíce = bom , sem índice = mau", preto no branco,  alguém 
FEZ uma análise pra ver se quais  índices podem ser removidos, quais 
podem ser concatenados num índice composto ?

[]s

 Chiappa
 
--- Em oracle_br@yahoogrupos.com.br, "Renata de Oliveira" 
<[EMAIL PROTECTED]> escreveu
>
> Olá pessoal, bom dia à todos!
> 
> Gostaria de expor um problema que estou tendo aqui para verificar o 
> que pode estar acontecendo:
> 
> Tenho a tabela X com 11 indexes, onde dois deles tem a coluna 
> DT_DISCONTINUE em comum:
> 
> IX_1  ==> dt_discontinue, fk_b_cod_cliente
> IX_11 ==> dt_efetivar, dt_discontinue
> 
> Tenho uma query assim:
> 
> SELECT CAMPO1, 
>CAMPO2, 
>CAMPO3
> FROM X
> WHERE ( DT_EFETIVAR <= SYSDATE AND DT_DISCONTINUE >= SYSDATE)
>OR ( DT_EFETIVAR >  SYSDATE AND DT_DISCONTINUE >  SYSDATE)
> 
> O Plano de execução desta query me mostra, que o acesso está sendo 
> feito através do index(TABLE ACCESS BY INDEX ROWID), porém, mostra 
os 
> dois indexes: IX_1 e IX_11, quando deveria fazer o acesso só pelo 
> IX_11, alguém saberia me explicar pq ele está usando os dois 
> indexes?!
> Aqui uso o Oracle 9i.
> 
> Desde já, agradeço qq dica!
> 
> Obrigada, 
> 
> Renata Oliveira
>

RE: [oracle_br] Problemas com o uso do index!

[FERNANDES Marco A SOFTTEK]

Renata,
quais as opções (parametros e configs) de uso de índices no seu banco ?
 
Me parece que isso é análise de custo que o banco fez.
Utilizou os índices pq considerou menor o custo do que usar apenas 1 deles.
 
abraço,
Marco.



From: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] On Behalf Of PUB: 
Renata de Oliveira
Sent: quinta-feira, 24 de maio de 2007 10:07
To: oracle_br@yahoogrupos.com.br
Subject: [oracle_br] Problemas com o uso do index!



Olá pessoal, bom dia à todos!

Gostaria de expor um problema que estou tendo aqui para verificar o 
que pode estar acontecendo:

Tenho a tabela X com 11 indexes, onde dois deles tem a coluna 
DT_DISCONTINUE em comum:

IX_1 ==> dt_discontinue, fk_b_cod_cliente
IX_11 ==> dt_efetivar, dt_discontinue

Tenho uma query assim:

SELECT CAMPO1, 
CAMPO2, 
CAMPO3
FROM X
WHERE ( DT_EFETIVAR <= SYSDATE AND DT_DISCONTINUE >= SYSDATE)
OR ( DT_EFETIVAR > SYSDATE AND DT_DISCONTINUE > SYSDATE)

O Plano de execução desta query me mostra, que o acesso está sendo 
feito através do index(TABLE ACCESS BY INDEX ROWID), porém, mostra os 
dois indexes: IX_1 e IX_11, quando deveria fazer o acesso só pelo 
IX_11, alguém saberia me explicar pq ele está usando os dois 
indexes?!
Aqui uso o Oracle 9i.

Desde já, agradeço qq dica!

Obrigada, 

Renata Oliveira 



 


[As partes desta mensagem que não continham texto foram removidas]

RE: Res: [oracle_br] Segurança

[FERNANDES Marco A SOFTTEK]

Olá Bia, Chiappa, amigos.
 
Não tem como dicordar do Chiappa... é bem por aí.
O problema não é o programa que está acessando e sim o usuário
que está acessando e seus direitos de acesso !
 
Se vc quer segurança no banco a primeira coisa a fazer é gerenciar
os usuários ! ou seja, DBA faz serviço de DBA e só ele poderá
alterar alguma coisa (estrutura, etc).
Ao desenvolvedor cabe apenas desenvolver em banco de teste e QA
e enviar para AD e DBA validar e aplicar.
E pro resto do universo de usuários, só acessar via aplicação com usuário
de aplicação e senha de aplicação (poderia ser usuário de rede por ex).
Se for o caso de usar usuário nomeado do banco, usar de forma que o
usuário não saiba a senha do banco e sim uma outra senha... poderia
até no pior caso ser um usuário ou uma senha concatenada (gambi) com
algum carater extra (por exemplo, usuário MARCO na aplicação mas no
banco ficaria UB_MARCO... ou algo do tipo usuario e senha criptografados)
mas ainda é melhor que dar a senha pro cara conectar via AnyThing.exe 
e ver o banco todo (estrutura, objetos, etc) !
Usuário comum tem que ter restrição e daquelas Hard mesmo... só
consulta de dados e pra alguns casos atualização de dados, e via aplicação
desenvolvida pra tal.
 
Abraço,
Marco.



From: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] On Behalf Of PUB: 
jlchiappa
Sent: quinta-feira, 24 de maio de 2007 10:14
To: oracle_br@yahoogrupos.com.br
Subject: Re: Res: [oracle_br] Segurança



Bia, ainda sobre esse ponto, deixe-me adicionar alguns itens : no bd 
Oracle uma conexão é uma conexão, absolutamente NÂO IMPORTA quem está 
conectando, não há MESMO nenhum código no kernel que tente 
identificar Isso faz TODO o sentido inclusive, já que informações 
do cliente estão FORA DO CONTROLE do banco, e podem ser falsificadas 
de modo MUITO Fácil - por exemplo, se vc seguir o conselho dos 
colegas e tentar capturar o nome do programa numa trigger, E SE 
alguém fizer um rename sqlplus.exe to nomepermitido.exe, por 
exemplo  Acho muito muito ** frágil ** essa lógica
Segundo item : idealmente, as regras de negócio estão NO BANCO DE 
DADOS, via triggers, constraints, relacionamentos, views, etc, assim 
NÂO IMPORTA com qual tool a pessoa conecta, as primary keys estão lá, 
os grants estão lá, as views estão lá, e cada usuário final do 
sistema tem o seu usuário de banco, o qual só ele sabe a senha, então 
o usuário final *** só vai enxergar *** o que pode, ** só vai fazer 
** o que tem direito, independente da tool, ok ? Normalmente quem 
tenta fazer restrição desse tipo baseado no aplicativo é porque tem 
regras de negócio NO APLICATIVO, aí as coisas realmente podem quebrar 
se a pessoa conectar com outra coisa que não o aplicativo Sem 
sombra de dúvida, isso deixa a Empresa absolutamente "ENGESSADA", ela 
NUNCA vai poder aposentar esse aplicativo sem perda de dados, NUNCA 
vai poder usar tools de query/busioness intelligence sem extensa 
customização  Afora o desenvolvedor do aplicativo (que tem 
serviço garantido), acho que NINGUÉM fica feliz com isso.

==> o meu ponto asim é : SE realmente vc tiver que fazer esse enrome 
contra-senso, conheça os pontos fracos, ok ? 

[]s

Chiappa

--- Em oracle_br@yahoogrupos.com.br  , 
Bia Fitzgerald <[EMAIL PROTECTED]> 
escreveu
>
> ahhh, sim.. Muito obrigada.
> :)
> 
> 
> - Mensagem original 
> De: Gustavo Venturini de Lima <[EMAIL PROTECTED]>
> Para: oracle_br@yahoogrupos.com.br  
> Enviadas: Quarta-feira, 23 de Maio de 2007 18:34:19
> Assunto: Re: [oracle_br] Segurança
> 
> Na verdade a trigger não fica ligada a ninguém... Ela fica 
escutando o
> "banco todo" no geral...
> Se "algo" satisfazer a condição da trigger, ela será ativada...
> No caso, utilize uma "AFTER LOGON ON DATABASE"
> Parecido com isso:
> 
> CREATE OR REPLACE TRIGGER SomenteSistema AFTER LOGON ON DATABASE
> BEGIN
> .
> {suas condições e ações}
> .
> END;
> 
> Em 23/05/07, Bia Fitzgerald  escreveu:
> >
> > Oi, Gustavo. Imaginei algo assim. Um job, talvez. Que rode o tempo
> > inteiro.
> > Mas uma Trigger ficaria ligada a quem??
> > Obrigada.
> >
> > - Mensagem original 
> > De: Gustavo Venturini de Lima <[EMAIL PROTECTED] com
> > >
> > Para: [EMAIL PROTECTED] os.com.br 
> > Enviadas: Quarta-feira, 23 de Maio de 2007 16:55:21
> > Assunto: Re: [oracle_br] Segurança
> >
> > Bia, para o Oracle a conexão será a mesma (independente do método
> > utilizado).
> > Porém, podes fazer uma trigger que consulte o campo "program" da
> > v$session..
> > Lá aparecerá o Toad.exe por exemplo, e aí sim vc escolhe para 
desconectar
> > o
> > usuário...
> > Ou então colocar que se for <> de NOME_DA_SUA_ APP ele desconecta 
o
> > cara...
> >
> > Em 23/05/07, Bia Fitzgerald  escreveu:
> > >
> > > Olá pessoal...
> > >
> > > Alguém sabe como impedir que um determinado usuário acesse o BD 
via
> > > aplicativos como sqlplus e TOAD e some

Re: Res: [oracle_br] Segurança

[jlchiappa]

Bia, ainda sobre esse ponto, deixe-me adicionar alguns itens : no bd 
Oracle uma conexão é uma conexão, absolutamente NÂO IMPORTA quem está 
conectando, não há MESMO nenhum código no kernel que tente 
identificar Isso faz TODO o sentido inclusive, já que informações 
do cliente estão FORA DO CONTROLE do banco, e podem ser falsificadas 
de modo MUITO Fácil - por exemplo, se vc seguir o conselho dos 
colegas e tentar capturar o nome do programa numa trigger, E SE 
alguém fizer um rename sqlplus.exe to nomepermitido.exe, por 
exemplo  Acho muito muito **  frágil ** essa lógica
 Segundo item : idealmente, as regras de negócio estão NO BANCO DE 
DADOS, via triggers, constraints, relacionamentos, views, etc, assim 
NÂO IMPORTA com qual tool a pessoa conecta, as primary keys estão lá, 
os grants estão lá, as views estão lá, e cada usuário final  do 
sistema tem o seu usuário de banco, o qual só ele sabe a senha, então 
o usuário final  *** só vai enxergar *** o que pode, ** só vai fazer 
** o que tem direito, independente da tool, ok ?  Normalmente quem 
tenta fazer restrição desse tipo baseado no aplicativo é porque tem 
regras de negócio NO APLICATIVO, aí as coisas realmente podem quebrar 
se a pessoa conectar com outra coisa que não o aplicativo Sem 
sombra de dúvida, isso deixa a Empresa absolutamente "ENGESSADA", ela 
NUNCA vai poder aposentar esse aplicativo sem perda de dados, NUNCA 
vai poder usar tools de query/busioness intelligence sem extensa 
customização  Afora o desenvolvedor do aplicativo (que tem 
serviço garantido), acho que NINGUÉM fica feliz com isso.
 
 ==> o meu ponto asim é : SE realmente vc tiver que fazer esse enrome 
contra-senso, conheça os pontos fracos, ok ? 
 
 []s
 
  Chiappa
  
--- Em oracle_br@yahoogrupos.com.br, Bia Fitzgerald <[EMAIL PROTECTED]> 
escreveu
>
> ahhh, sim.. Muito obrigada.
> :)
> 
> 
> - Mensagem original 
> De: Gustavo Venturini de Lima <[EMAIL PROTECTED]>
> Para: oracle_br@yahoogrupos.com.br
> Enviadas: Quarta-feira, 23 de Maio de 2007 18:34:19
> Assunto: Re: [oracle_br] Segurança
> 
> Na verdade a trigger não fica ligada a ninguém... Ela fica 
escutando o
> "banco todo" no geral...
> Se "algo" satisfazer a condição da trigger, ela será ativada...
> No caso, utilize uma "AFTER LOGON ON DATABASE"
> Parecido com isso:
> 
> CREATE OR REPLACE TRIGGER SomenteSistema AFTER LOGON ON DATABASE
> BEGIN
> .
> {suas condições e ações}
> .
> END;
> 
> Em 23/05/07, Bia Fitzgerald  escreveu:
> >
> > Oi, Gustavo. Imaginei algo assim. Um job, talvez. Que rode o tempo
> > inteiro.
> > Mas uma Trigger ficaria ligada a quem??
> > Obrigada.
> >
> > - Mensagem original 
> > De: Gustavo Venturini de Lima <[EMAIL PROTECTED] com
> > >
> > Para: [EMAIL PROTECTED] os.com.br 
> > Enviadas: Quarta-feira, 23 de Maio de 2007 16:55:21
> > Assunto: Re: [oracle_br] Segurança
> >
> > Bia, para o Oracle a conexão será a mesma (independente do método
> > utilizado).
> > Porém, podes fazer uma trigger que consulte o campo "program" da
> > v$session..
> > Lá aparecerá o Toad.exe por exemplo, e aí sim vc escolhe para 
desconectar
> > o
> > usuário...
> > Ou então colocar que se for <> de NOME_DA_SUA_ APP ele desconecta 
o
> > cara...
> >
> > Em 23/05/07, Bia Fitzgerald  escreveu:
> > >
> > > Olá pessoal...
> > >
> > > Alguém sabe como impedir que um determinado usuário acesse o BD 
via
> > > aplicativos como sqlplus e TOAD e somente acesse via sistema?
> > > Obrigada,
> > > Bia.
> > >
> > >  _ _ _ _ __
> > > Fale com seus amigos de graça com o novo Yahoo! Messenger
> > > http://br.messenger .yahoo.com/
> > >
> > > [As partes desta mensagem que não continham texto foram 
removidas]
> > >
> > >
> > >
> >
> > [As partes desta mensagem que não continham texto foram removidas]
> >
> >  _ _ _ _ __
> > Fale com seus amigos de graça com o novo Yahoo! Messenger
> > http://br.messenger .yahoo.com/
> >
> > [As partes desta mensagem que não continham texto foram removidas]
> >
> > 
> >
> 
> [As partes desta mensagem que não continham texto foram removidas]
> 
> 
> 
> 
> __
> Fale com seus amigos  de graça com o novo Yahoo! Messenger 
> http://br.messenger.yahoo.com/ 
> 
> [As partes desta mensagem que não continham texto foram removidas]
>

[oracle_br] Problemas com o uso do index!

[Renata de Oliveira]

Olá pessoal, bom dia à todos!

Gostaria de expor um problema que estou tendo aqui para verificar o 
que pode estar acontecendo:

Tenho a tabela X com 11 indexes, onde dois deles tem a coluna 
DT_DISCONTINUE em comum:

IX_1  ==> dt_discontinue, fk_b_cod_cliente
IX_11 ==> dt_efetivar, dt_discontinue

Tenho uma query assim:

SELECT CAMPO1, 
   CAMPO2, 
   CAMPO3
FROM X
WHERE ( DT_EFETIVAR <= SYSDATE AND DT_DISCONTINUE >= SYSDATE)
   OR ( DT_EFETIVAR >  SYSDATE AND DT_DISCONTINUE >  SYSDATE)

O Plano de execução desta query me mostra, que o acesso está sendo 
feito através do index(TABLE ACCESS BY INDEX ROWID), porém, mostra os 
dois indexes: IX_1 e IX_11, quando deveria fazer o acesso só pelo 
IX_11, alguém saberia me explicar pq ele está usando os dois 
indexes?!
Aqui uso o Oracle 9i.

Desde já, agradeço qq dica!

Obrigada, 

Renata Oliveira 








 




 

Res: [oracle_br] Segurança

[Bia Fitzgerald]

ahhh, sim.. Muito obrigada.
:)


- Mensagem original 
De: Gustavo Venturini de Lima <[EMAIL PROTECTED]>
Para: oracle_br@yahoogrupos.com.br
Enviadas: Quarta-feira, 23 de Maio de 2007 18:34:19
Assunto: Re: [oracle_br] Segurança

Na verdade a trigger não fica ligada a ninguém... Ela fica escutando o
"banco todo" no geral...
Se "algo" satisfazer a condição da trigger, ela será ativada...
No caso, utilize uma "AFTER LOGON ON DATABASE"
Parecido com isso:

CREATE OR REPLACE TRIGGER SomenteSistema AFTER LOGON ON DATABASE
BEGIN
.
{suas condições e ações}
.
END;

Em 23/05/07, Bia Fitzgerald  escreveu:
>
> Oi, Gustavo. Imaginei algo assim. Um job, talvez. Que rode o tempo
> inteiro.
> Mas uma Trigger ficaria ligada a quem??
> Obrigada.
>
> - Mensagem original 
> De: Gustavo Venturini de Lima <[EMAIL PROTECTED] com
> >
> Para: [EMAIL PROTECTED] os.com.br 
> Enviadas: Quarta-feira, 23 de Maio de 2007 16:55:21
> Assunto: Re: [oracle_br] Segurança
>
> Bia, para o Oracle a conexão será a mesma (independente do método
> utilizado).
> Porém, podes fazer uma trigger que consulte o campo "program" da
> v$session..
> Lá aparecerá o Toad.exe por exemplo, e aí sim vc escolhe para desconectar
> o
> usuário...
> Ou então colocar que se for <> de NOME_DA_SUA_ APP ele desconecta o
> cara...
>
> Em 23/05/07, Bia Fitzgerald  escreveu:
> >
> > Olá pessoal...
> >
> > Alguém sabe como impedir que um determinado usuário acesse o BD via
> > aplicativos como sqlplus e TOAD e somente acesse via sistema?
> > Obrigada,
> > Bia.
> >
> >  _ _ _ _ __
> > Fale com seus amigos de graça com o novo Yahoo! Messenger
> > http://br.messenger .yahoo.com/
> >
> > [As partes desta mensagem que não continham texto foram removidas]
> >
> >
> >
>
> [As partes desta mensagem que não continham texto foram removidas]
>
>  _ _ _ _ __
> Fale com seus amigos de graça com o novo Yahoo! Messenger
> http://br.messenger .yahoo.com/
>
> [As partes desta mensagem que não continham texto foram removidas]
>
> 
>

[As partes desta mensagem que não continham texto foram removidas]




__
Fale com seus amigos  de graça com o novo Yahoo! Messenger 
http://br.messenger.yahoo.com/ 

[As partes desta mensagem que não continham texto foram removidas]

[oracle_br] Error 25228 ORA-25228: timeout or end-of-fetch during message dequeue from SYS.SYS$SERVICE_METRICS

[Vanberto Alessandro de Souza Zuim - FOR]

Bom dia Pessoal ,Gostaria que vocês me tirassem um duvida,Ontem eu estava 
olhando algumas coisa no banco, bom de primeiro encontrei a execução de alguns 
módulos [EMAIL PROTECTED] (TNS V1-V3) , com um numero de BUFFER_GETS muito 
elevado e com um numero de READS também muito elevado, realmente não sei se 
isso é normal, Fui olha no metalink e encontrei alguma coisa falando para olhar 
 imon_BJMP.log e o imonBJMP.log , quando estava olhando o log me reparei com o 
erro abaixo
 
 
2007-05-24 08:28:19.895: [RACG][206862544] 
[7514][206862544][ora.BJMP.BJMP1.inst]: clsrrlbgthr: Error 25228 ORA-25228: 
timeout or end-of-fetch during message dequeue from SYS.SYS$SERVICE_METRICS
 - OCIAQDeqArray
 
2007-05-24 08:28:30.786: [RACG][206862544] 
[7514][206862544][ora.BJMP.BJMP1.inst]: clsrrlbgthr: Error 25228 ORA-25228: 
timeout or end-of-fetch during message dequeue from SYS.SYS$SERVICE_METRICS
 - OCIAQDeqArray
 
2007-05-24 08:28:40.790: [RACG][206862544] 
[7514][206862544][ora.BJMP.BJMP1.inst]: clsrrlbgthr: Error 25228 ORA-25228: 
timeout or end-of-fetch during message dequeue from SYS.SYS$SERVICE_METRICS
 - OCIAQDeqArray
 
2007-05-24 08:28:59.896: [RACG][206862544] 
[7514][206862544][ora.BJMP.BJMP1.inst]: clsrrlbgthr: Error 25228 ORA-25228: 
timeout or end-of-fetch during message dequeue from SYS.SYS$SERVICE_METRICS
 - OCIAQDeqArray
 
Apos fui  procura algumas informações no metalink mais apenas  encontrei 
informações de timeout relativo a outras coisas, alguém tem alguma idéia ?
 
Utilizo RAC Release 10.2.0.1.0  3 Nos
CRS : 
Linux red hat 3 Up 5
 
 
Att..
 
Vanberto Zuim
Administrador de Banco de Dados
Tecnologia da Informação
 


[As partes desta mensagem que não continham texto foram removidas]

[oracle_br] [OFF-TOPIC] Emails da comunidade caindo no Spam do Gmail

[Rogério Lacerda]

Bom dia pessoa,

Alguns emails do grupo estão caindo da pasta de Spam do Gmail, fiquem
espertos.

Desculpem o OT.

Abraços

-- 
Att,
Rogério Freisleben Lacerda


[As partes desta mensagem que não continham texto foram removidas]

RES: [oracle_br] ERP

[Danilo Azevedo]

Trabalho com ERP Microsiga há mais de 3 anos. Tem um custo de implantação e
manutenção relativamente baixo e possui boas ferramentas (portais, acesso
100% via web, DW, integração com ferramentas externas...). Além disso,
trabalha com os principais BD do mercado (Oracle, DB2, MSSQL, entre
outros...). Um dos principais pontos que acho vantagem é que o sistema é
também um ambiente de desenvolvimento, onde voce pode customizar sem muita
dificuldade e adaptar praticamente tudo de acordo com sua necessidade. Não
sei qual é a área de atuação da sua empresa, mas se quiser conversar em pvt,
estou a disposição para maiores detalhes.
 




Atenciosamente, 

Danilo Azevedo 
DI - UniFOA
  [EMAIL PROTECTED]

 


  _  

De: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] Em
nome de ojp22001
Enviada em: terça-feira, 22 de maio de 2007 22:21
Para: oracle_br@yahoogrupos.com.br
Assunto: [Possível SPAM] - [oracle_br] ERP - Number of numbers in MIME From
exceeds maximum threshold



Ola, meus Gurus...
Estamos trabalhando em um levantamento de qual ERP adotar na empresa 
(medio porte), após muita pesquisa e analise de custo x beneficio, 
sobraram dois pacotes: 
1 - ERP SAP c/ bd SQL SERVER 2005 
2 - ERP SAP c/ bd Oracle
2 - ERP Oracle (bd Oracle) 
Qual a opinião/experiência de vcs sobre o assunto ?

obrigado,
Olavo



 

  --

Esta mensagem e seus anexos podem conter informações confidenciais ou 
privilegiadas. Caso não seja o destinatário dos mesmos você não está autorizado 
a utilizar o material para qualquer fim. Solicitamos que apague a mensagem e 
avise imediatamente o remetente. O conteúdo desta mensagem e seus anexos não 
representam necessariamente a opinião e a intenção da empresa, não implicando 
em qualquer obrigação ou responsabilidade da parte da mesma.


[As partes desta mensagem que não continham texto foram removidas]

Re: [oracle_br] REGRAS ORACLE EXPRESS

[Ademir Roque Maneira]

Taí.

http://download-east.oracle.com/docs/cd/B25329_01/doc/install.102/b25143/toc.htm#BABIECJA


Em 24/05/07, Francisco_Departamento_Informatica <[EMAIL PROTECTED]>
escreveu:
>
>   Bom dia.
>
> Pessoal alguem poderia me informar sobre as regras do 10g Express ate onde
> e livre
>
> Quantos conexoes
> memoria
> processador
> hd
>
> Desde ja agradeco
>
> Chico
>
> [As partes desta mensagem que não continham texto foram removidas]
>
> 
>


[As partes desta mensagem que não continham texto foram removidas]

Re: [oracle_br] REGRAS ORACLE EXPRESS

[Francisco_Departamento_Informatica]

Bom dia.

Pessoal alguem poderia me informar sobre as regras do 10g Express ate onde e 
livre

Quantos conexoes
memoria 
processador
hd

Desde ja agradeco

Chico

[As partes desta mensagem que não continham texto foram removidas]