Re: RES: RES: RES: [oracle_br] Re: delete

[jlchia...@yahoo.com.br [oracle_br]]

E é claro, um detalhe a mais, que com certeza não deve ser a Causa mas tá 
errado de qquer jeito : ** se ** essa coluna DAT_SALDO é mesmo do tipo DATE, 
está Completamente Errado, é absolutamente Contra-recomendado vc fazer :


and dat_saldo >= '06/09/2016';

ie, comparar DATE com uma string : com isso vc está CONFIANDO que o RDBMS vai 
conseguir fazer a conversão implícita de datatypes , o que NEM SEMPRE é 
possível/viável, ALÉM DE (possivelmente) PERDER o uso de eventual índice 
presente , yes ??

PLEASE no lugar use , se a coluna é DATE :



and dat_saldo >= TO_DATE('06/09/2016', 'DD/MM/');

pk ?

 []s

  Chiappa

Re: RES: RES: RES: [oracle_br] Re: delete

[jlchia...@yahoo.com.br [oracle_br]]

Opa , estamos chegando em algum lugar : em especial, essa info de 
"sessão. em Library Cache Load Lock" é ABSOLUTAMENTE, COMPLETAMENTE, 
TOTALMENTE DIFERENTE da info de "Não  gera nenhum bloqueio, ..." que vc tinha 
dado em outra msg anterior, né não ? 
 Muito bem, agora SIM estamos chegando em algum lugar ;)
 
 okdoc : o fato que vc consegue compilar com sucesso no banco-destino outros 
stored PL/SQLs que usam esse dblink mas (ao que entendo) acessam OUTRAS tabelas 
lá no banco-origem CLARAMENTE INDICA que é uma issue com essa tabela - como eu 
disse lá na segunda resposta, pode ser uma Transação aberta nessa tabela, pode 
ser espera por LOCK causado por algum outro DDL concorrendo com a 
criação/compilação da package, E o procedimento é mesmo consultar as views e 
tabelas internas de WAITs, de LOCKS, de TRANSAÇÕES e de execução de PL/SQL (e 
isso nos DOIS BANCOS !!!) e ver quem/qual sessão tá acessando/mexendo/tem 
locks/tá usando PL/SQL que referencia a tal tabela
 
 Seguem abaixo FYR alguns scripts-exemplo que posso indicar, todos (repito) 
devendo ser executados TANTO no banco origem da informação QUANTO no 
banco-destino que possui o dblink - só AVISO que :
 
 a. como não tenho um banco 9iR2 aqui facilmente disponível, CONFIRA na doc que 
realmente todas as colunas que referencio estão presentes no 9i
 
 b. todas as consultas devem ser executadas nos dois bancos com um usuário 
Administrador/DBA
 
 c. afaik vc não disse mas SUPONHO que esse 9iR2 EE é single-instance ou RAC : 
se for RAC acesse as GV$ ao invés das V$
 
 d. as views/tabelas internas DBA_xxx e (G)V$xxx via de regra já são 
permissionadas para qualquer usuário Administrador - já as X$ normalmente não, 
então se vc for executar os scripts com outro user que não o SYS , 
permissione-o adequadamente
 
 e. os scripts que são apenas um SELECT e nada mais podem ser executados 
diretamente no prompt do sql*plus (ou da sua GUI preferida), ao passo que os 
que possuem outros comandos (como COLUMN, ou outros) aí necessariamente 
precisam ser salvos num arquivo .SQL e executados via @nomedoarquivo.sql dentro 
do sql*plus
 
 
 A idéia é executar (nos DOIS BANCOS, repito!) várias vezes cada scripts numa 
** outra ** janela/sessão, ao mesmo tempo em que a sessão no banco-origem que 
está tentando criar a packahe tá 'congelada'... 
 
 Seguem :

==> consulta de Transações abertas
SELECT a.sid, a.saddr, b.ses_addr, a.username, b.xidusn, b.used_urec, 
b.used_ublk
FROM   v$session a, v$transaction b
WHERE  a.saddr = b.ses_addr;

==> consulta de Waits de banco (a view DBA_WAITERS não era default no 9iR2 
iirc, se vc não a tem iirc vc deve rodar scripts do SYS em 
$ORACLE_HOME/rdbms/admin) :
SELECT * from dba_waiters;

==> script para consultar sessões e seus WAITs (dê ENTER nos itens de filtro 
para usar o default, que lista Todas as linhas)

SET PAGES 999
column sid_serialformat A10
column seq#   format 9
column event  format a29 heading "Wait Event" trunc
column state  format a15 heading "Wait State" trunc
column secs   format 999 heading "Waited so|far (sec)"
column wt format 999 heading "Waited|Seconds"
column P1TEXT format a38
column P2TEXT format a38
column P3TEXT format a38
prompt
prompt Sessões esperando por sql*net message estão aguardando
prompt   por resposta do usuário.
prompt Sessões com wait_time <> 0 => consomem CPU
prompt
prompt Atenção à Coluna State, se ela for :
prompt Waiting => ignore Waited Secs, Waited So Far=tempo até agora
prompt Wait.Short Time => menos q um tick de CPU, ignorar
prompt Wait. Know Time => Waited Secs=tempo total esperado, ignore Wait So Far
prompt
prompt Colunas que podem ser Especificadas como Condição, na Ordem:
prompt
prompt => tabela session_wait, prefixar com A. , colunas : SID/SEQ#, WAIT_TIME 
, 
prompt EVENT, SECONDS_IN_WAIT,  STATE, 
prompt 
prompt => tabela sess_io, prefixar com B. , colunas : BLOCK_GETS,
prompt CONSISTENT_GETS, PHYSICAL_READS, BLOCK_CHANGES, CONSISTENT_CHANGES,
prompt PnTEXT, Pn (com n 1 a 3)
prompt
prompt => tabela v$session, prefixar com C. , usar nome da coluna na v$session
prompt
accept v_cond_wait DEFAULT 'a.event is not null' prompt "Condições a Aplicar 
(opcional):"
accept sid_listDEFAULT a.sid prompt "Lista de SIDs (opcional):"
accept v_orderby   DEFAULT 'a.sid, a.wait_time, a.event' prompt "Order by:"
SELECT c.sid || ',' || c.serial# SID_SERIAL, a.seq#, a.wait_time wt , a.event, 
a.seconds_in_wait secs, a.state,
   b.block_gets, b.consistent_gets, b.physical_reads, b.block_changes, 
b.consistent_changes,
   a.P1TEXT, a.P1,
   a.P2TEXT, a.P2,
   a.P3TEXT, a.P3,
   c.LOGON_TIME, 
   c.LAST_CALL_ET,
   c.ROW_WAIT_OBJ#,  
   c.ROW_WAIT_FILE#, 
   c.ROW_WAIT_BLOCK#,
   c.ROW_WAIT_ROW#,  
   c.LOCKWAIT,   
   c.CLIENT_IDENTIFIER,
   c.MODULE,
   c.PROGRAM,
   c.USERNAME,
   c.OSUSER,
   c.CLIENT_INFO
  FROM 

Re: RES: RES: [oracle_br] Re: delete

[Andre Santos andre.psantos...@gmail.com [oracle_br]]

Ednilson

Estranho que a instrução SELECT está incorreta no bloco PL/SQL, pois
deveria ter a clásula INTO para atribuir à uma variável.

[ ]'s

André


Em 15 de setembro de 2016 16:53, 'Ednilson Silva' ednilson.si...@jbs.com.br
[oracle_br]  escreveu:

>
>
> Chiappa,
>
> Sim, um SELECT COUNT(*) no banco origem nesta tabela retorna mais de 3
> milhões de registro, é uma tabela com sinônimo e o sinônimo esta apontando
> para tabela.
>
> Outra coisa, no banco origem existe uma tabela e um sinônimo iguais ao
> destino, mas esta tabela foi criada em 2012 e no destino 2013.
>
> A sessão na origem fica em Library Cache Load Lock.
>
> Outra rotinas que utilizam este DB Link recompilei com sucesso.
>
> SQL> select count(*) from producao.ind_saldo_estoque_
> diario@prd.fr_lins.gr_bertin
>
> 2 where cod_empresa = 40
>
> 3 and cod_filial = 3
>
> 4 and dat_saldo >= '06/09/2016';
>
> COUNT(*)
>
> --
>
> 0
>
> Abaixo não executa…
>
> SQL> begin
>
> 2 select count(*) from producao.ind_saldo_estoque_
> diario@prd.fr_lins.gr_bertin
>
> 3 where cod_empresa = 40
>
> 4 and cod_filial = 3
>
> 5 and dat_saldo >= '06/09/2016';
>
> 6 end;
>
> 7 /
>
> Grato,
>
> Ednilson Silva
>
> De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br]
> Enviada em: quinta-feira, 15 de setembro de 2016 16:20
> Para: oracle_br@yahoogrupos.com.br
> Assunto: Re: RES: RES: [oracle_br] Re: delete
>
> Então : vc fez *** realmente *** toda a análise que falei lá no
> banco-origem, confirmou que a conexão realmente vai sem prob, que a qtdade
> de linhas na V$SESSIOn lá na origem nunca tá nem perto do limite, descobriu
> qual o objeto que é IND_SALDO_ESTOQUE_DIARIO, se ele é uma view ou um
> sinônimo Confirmou *** MESMO *** que os objetos dependentes estão presentes
> E acessíveis (SEM ROLEs envolvidas!) ao usuário do CONNECT no dblink,
> Realmente mesmo ???
>
> Se Realmente sim (e veja que é um ponto ** SUCULENTO **, é bastante coisa
> a se fazer) , aí descarta-se a opção de alguma falta de privilégio, sobra
> alguma opção de lock/espera por dicionário de dados e similares Faça
> por partes, como eu indiquei : PRIMEIRO para verificar que o acesso ao
> dicionário no banco-destino onde está criado o dblink tá ok, cria nesse
> banco-destino um stored PL/SQL (preferencialmente Package, já que é package
> que vc está tentando usar sem sucesso) que NÂO usa o dblink, tudo ok aí
> cria uma package que USA o dblink mas faz um select super-simples (talvez
> com DUAL@dblink)... Se o teste de acesso ao dicionário aí no
> banco-destino foi OK, tente o repetir (pelo mesno o inicial, simples) no
> banco-origem...
>
> Indo tudo OK na criação de stored PL/SQL, só sobra como Possibilidade
> algum WAIT nesse objeto : pra vc identificar qual pode ser, ** TANTO ** no
> banco-origem QUANTO no banco-destino execute consultas nas views/tabelas
> internas de WAITs, de TRANSAÇÔES e de LOCKS que vc deve encontrar o
> culpado, ok ?
>
> []s
>
> Chiappa
>
> OBS : se vc não dispuser de scripts apropriados, dá um toque que posso te
> enviar alguns que costumo usar...
>
> [As partes desta mensagem que não continham texto foram removidas]
>
> 
>

RES: RES: RES: [oracle_br] Re: delete

['Ednilson Silva' ednilson.si...@jbs.com.br [oracle_br]]

Chiappa,

Sim, um SELECT COUNT(*) no banco origem nesta tabela retorna mais de 3 milhões 
de registro, é uma tabela com sinônimo e o sinônimo esta apontando para tabela.

Outra coisa, no banco origem existe uma tabela e um sinônimo iguais ao destino, 
mas esta tabela foi criada em 2012 e no destino 2013.

 

A sessão na origem fica em Library Cache Load Lock.

 

Outra rotinas que utilizam este DB Link recompilei com sucesso.

 

SQL>   select count(*) from 
producao.ind_saldo_estoque_diario@prd.fr_lins.gr_bertin

  2   where cod_empresa = 40

  3 and cod_filial  = 3

  4 and dat_saldo   >= '06/09/2016';

  

  COUNT(*)

--

 0

 

Abaixo não executa…

 

SQL> begin

  2select count(*) from 
producao.ind_saldo_estoque_diario@prd.fr_lins.gr_bertin

  3   where cod_empresa = 40

  4 and cod_filial  = 3

  5 and dat_saldo   >= '06/09/2016';

  6  end;

  7  /

 

Grato,

Ednilson Silva

 

De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] 
Enviada em: quinta-feira, 15 de setembro de 2016 16:20
Para: oracle_br@yahoogrupos.com.br
Assunto: Re: RES: RES: [oracle_br] Re: delete

 

  

Então : vc fez *** realmente *** toda a análise que falei lá no banco-origem, 
confirmou que a conexão realmente vai sem prob, que a qtdade de linhas na 
V$SESSIOn lá na origem nunca tá nem perto do limite, descobriu qual o objeto 
que é IND_SALDO_ESTOQUE_DIARIO, se ele é uma view ou um sinônimo Confirmou *** 
MESMO *** que os objetos dependentes estão presentes E acessíveis (SEM ROLEs 
envolvidas!) ao usuário do CONNECT no dblink, Realmente mesmo ???

 Se Realmente sim (e veja que é um ponto ** SUCULENTO **, é bastante coisa a se 
fazer) , aí descarta-se a opção de alguma falta de privilégio, sobra alguma 
opção de lock/espera por dicionário de dados e similares Faça por partes, 
como eu indiquei : PRIMEIRO para verificar que o acesso ao dicionário no 
banco-destino onde está criado o dblink tá ok, cria nesse banco-destino um 
stored PL/SQL (preferencialmente Package, já que é package que vc está tentando 
usar sem sucesso) que NÂO usa o dblink, tudo ok aí cria uma package que USA o 
dblink mas faz um select super-simples (talvez com DUAL@dblink)...   Se o teste 
de acesso ao dicionário aí no banco-destino foi OK, tente o repetir (pelo mesno 
o inicial, simples) no banco-origem...
 
 Indo tudo OK na criação de stored PL/SQL, só sobra como Possibilidade algum 
WAIT nesse objeto : pra vc identificar qual pode ser, ** TANTO ** no 
banco-origem QUANTO no banco-destino execute consultas nas views/tabelas 
internas de WAITs, de TRANSAÇÔES e de LOCKS que vc deve encontrar o culpado, ok 
?
 
 []s
 
   Chiappa
   
   OBS : se vc não dispuser de scripts apropriados, dá um toque que posso te 
enviar alguns que costumo usar...





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

Re: RES: RES: [oracle_br] Re: delete

[jlchia...@yahoo.com.br [oracle_br]]

Então : vc fez *** realmente *** toda a análise que falei lá no banco-origem, 
confirmou que a conexão realmente vai sem prob, que a qtdade de linhas na 
V$SESSIOn lá na origem nunca tá nem perto do limite, descobriu qual o objeto 
que é IND_SALDO_ESTOQUE_DIARIO, se ele é uma view ou um sinônimo Confirmou *** 
MESMO *** que os objetos dependentes estão presentes E acessíveis (SEM ROLEs 
envolvidas!) ao usuário do CONNECT no dblink, Realmente mesmo ???

 Se Realmente sim (e veja que é um ponto ** SUCULENTO **, é bastante coisa a se 
fazer) , aí descarta-se a opção de alguma falta de privilégio, sobra alguma 
opção de lock/espera por dicionário de dados e similares Faça por partes, 
como eu indiquei : PRIMEIRO para verificar que o acesso ao dicionário no 
banco-destino onde está criado o dblink tá ok, cria nesse banco-destino um 
stored PL/SQL (preferencialmente Package, já que é package que vc está tentando 
usar sem sucesso) que NÂO usa o dblink, tudo ok aí cria uma package que USA o 
dblink mas faz um select super-simples (talvez com DUAL@dblink)...   Se o teste 
de acesso ao dicionário aí no banco-destino foi OK, tente o repetir (pelo mesno 
o inicial, simples) no banco-origem...
 
 Indo tudo OK na criação de stored PL/SQL, só sobra como Possibilidade algum 
WAIT nesse objeto : pra vc identificar qual pode ser, ** TANTO ** no 
banco-origem QUANTO no banco-destino execute consultas nas views/tabelas 
internas de WAITs, de TRANSAÇÔES e de LOCKS que vc deve encontrar o culpado, ok 
?
 
 []s
 
   Chiappa
   
   OBS : se vc não dispuser de scripts apropriados, dá um toque que posso te 
enviar alguns que costumo usar...

[oracle_br] Re: Envio de alertas

[jlchia...@yahoo.com.br [oracle_br]]

Bom, primeiro entendo que como vc bem claramente diz "de dentro do database", 
soluções de fora do database (como jobs de SO, ou pooling no ADR do Oracle) tão 
descartadas... 
  Muito bem, se vc quer executar alguma rotina dentro do database, vc vai ter 
que PROGRAMAR algo - as suas opções de linguagem de programação são Java (** se 
** vc tiver instalado o JVM, que é opcional) OU então PL/SQL, que tem a 
vantagem de ser uma opção default e (até por isso) muito mais conhecida, que 
dispõe de muito mais refs 
 Continuando, vc quer que esse "algo" que vc programou dentro do banco seja 
executado quando alguma linha contendo alert crítico seja gravada no alert.log 
: afaik ** não ** há um trigger Específico para isso que dispare 
automaticamente, então creio que vc vai ter que executar (por um dos mecanismos 
de job schedulers do Oracle, seja o interfaceado via DBMS_JOB seja o mais 
recente DBMS_SCHEDULER) um "algo" programado a cada x minutos que consulta o 
alert.log (via EXTRENAL TABLE, por exemplo) e vê se existe algum alerta 
crítico, se existir manda o email
 
 Aí o ponto final : pra vc mandar email pelo PL/SQL de dentro do banco, vc TEM 
que ter acesso a um servidor de emails a partir do servidor de banco de dados, 
vai criar um ACL para permitir essa conexão de rede, aí vai escrever um PL/SQL 
que crie e envie o email, provavelmente via UTL_SMTP...

Exemplos para todas as tarefas abundam na internet, dá uma googlada por ORACLE 
11G SEND EMAIL, por ORACLE ALERT.LOG EXTERNAL TABLE e por ORACLE JOB que vc 
acha exemplos de tudo...

 []s

  Chiappa

RES: RES: [oracle_br] Re: delete

['Ednilson Silva' ednilson.si...@jbs.com.br [oracle_br]]

Chiappa,

Todos os testes que você comentou já fiz, inclusive no DB Link, coloquei o 
usuário/senha donos da tabela no destino.

Criei uma tabela simples no destino e tentei fazer um insert e delete com 
BEGIN/END e foi com sucesso.

Procurei por triggers que esteja travando isso e não encontrei nada

 

Não  gera nenhum bloqueio, alias não chega nem na base de destino a sessão, 
fazendo nesta tabela mas neste que criei vai sem problemas.

 

Grato,

Ednilson Silva

 

De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] 
Enviada em: quinta-feira, 15 de setembro de 2016 15:32
Para: oracle_br@yahoogrupos.com.br
Assunto: Re: RES: [oracle_br] Re: delete

 

  

Comigo tudo de boa... Então, por uma questão de método, antes de tentarmos 
analisar esse 'congelamento' que vc diz haver quando tenta criar a package , 
antes de mais nada vamos avançar um pouco pela questão de permissões e 
privilégios - não dá pra indicar neste momento se é isso que está te barrando 
(talvez nem seja isso), mas vamos começar por esse ângulo...
 Muito bem : para deixar escrupulosamente claro -  quando vc cria um database 
link no banco-destino, aquele que vai buscar a informação, vc usa a sintaxe :

CREATE [PUBLIC] DATABASE LINK nomedodatabaselink CONNECT ON 
nomedousuariodobancoorigem IDENTIFIED BY senhadousuáriodobancoorigem USING 
'stringdeconexãoapontandoprobanco-origemdainformação':

Assim, quando vc usar um @nomedodatabaselink em um SQL qualquer no 
banco-destino onde vc criou o dblink, o que vai acontecer é que o Oracle client 
contido na ORACLE_HOME desse banco vai tentar criar uma conexão lá no 
banco-origem identificado pela hoststring da cláusula USING, enviando o 
username e a senha indicados nas cláusulas CONNECT ON e IDENTIFIED  ok ? 
Assim sendo, a primeira coisa é que, LÀ NO BANCO ORIGEM, esse usuário indicado 
no CONNECT ON tenha recbido (diretamente, não por ROLE!!) o privilégio de 
CREATE SESSION, para que possa ser efetuada a conexão Óbvio , esse usuário 
TEM que estar com a senha indicada no IDENTIFIED, não pode estar BLOQUEADO, o 
banco-origem ** TEM ** que ter slots de conexão disponíveis, NÂO PODE haver 
trigger de logon barrando, ie : enfim, além dos privilégios a conexão TEM que 
ser possível
 ESSA é a primeira verificação que vc vai fazer, ie : vc vai conectar no 
banco-origem da informação (e NÂO no banco-destino onde vc criou o dblink) como 
um usuário privilegiado e vai CONFIRMAR que a conexão é possível, vai confirmar 
que a senha é EXATAMENTE a mesma indicada na criação do dblink, vai confirmar 
que a hosstring tá correta Isso se faz Primeiro conectando no banco-origem 
com um usuário administrativo e consultando por triggers de logon, PROFILEs ou 
quetauis que possam influenciar na conexão, e depois conectando no banco-origem 
com o client do banco-destino, usando no prompt de comando (a partir do 
servidor onde roda o banco-destino que tem o dblink) um :
 
 sqlplus usuario/senha@hoststringqueapontaprobancoorigem 
 
 CONFIRMADO que a conexão ao banco-origem da informação a partir do HOME do 
banco-destino é possível, aí o próximo passo é Confirmar que esse usuário 
conectado na origem da informação TEM os privs necessários pra esse objeto 
IND_SALDO_ESTOQUE_DIARIO... 
 Para poder confirmar isso, primeira coisa vc tem que ** IDENTIFICAR ** o que é 
esse objeto IND_SALDO_ESTOQUE_DIARIO, ie, se ele é um sinônimo, uma tabela, ou 
o que, E também identificar a quem pertence/para qual objeto real ele aponta se 
for sinônimo... Para isso, conectado lá no banco-origem dos dados com um 
usuário administrativo, faça um :
 
 SELECT OWNER, OBJECT_TYPE, OBJECT_NAME, STATUS, CREATED FROM DBA_OBJECTS WHERE 
OBJECT_NAME='IND_SALDO_ESTOQUE_DIARIO';
 
 se ele for um Sinônimo, aí faça um :
 
 SELECT * FROM DBA_SYNONYMS WHERE SYNONYM_NAME='IND_SALDO_ESTOQUE_DIARIO';
 
 e veja quais são os objetos reais referenciados pelo sinônimo... 
 
 Já se esse IND_SALDO_ESTOQUE_DIARIO for na verdade uma VIEW, vc ** TEM ** que 
se assegurar que o usuário da conexão feita pelo dblink tenha GRANT (** direto 
**, sem ROLEs) em ** TODOS ** os objetos reais referenciados no SQL da view - 
vc pode obter esse texto de SQL consultando a DBA_VIEWS e então olhar a que ele 
se refere, OU pode consultar a DBA_DEPENDENCIES indicando WHERE 
NAME='IND_SALDO_ESTOQUE_DIARIO'

==> UMA VEZ descobertos os objetos/tabelas Reais a que o usuário precisa ter 
acesso, é se certificar que ele recebeu GRANT de DELETE direto para todos - se 
vc não tem um script para verificar isso lá no banco-origem, vc pode usar este :

-- script de check de privs
col granted_role form a20
col owner form a15
col table_name form a33
col privilege form a33
ACCEPT username  prompt 'Enter Username : '
PROMPT Roles granted to user
SELECT granted_role,admin_option,default_role
FROM dba_role_privs
WHERE grantee=UPPER('')
ORDER BY 1;
PROMPT Table Privileges granted to a user through roles
SELECT granted_role, owner, table_name, privilege
FROM ( 

Re: [oracle_br] Envio de alertas

[Rodrigo Mufalani rodr...@mufalani.com.br [oracle_br]]

Boa tarde,

Isso vai ser mais fácil em shell script. Bom, eu ainda prefiro trabalhar 
com arquivos de SO via shell do que via PL/SQL, mas no oracle 11g tem uma view 
X$ acessivel com SYS que te mostra o conteudo do alert dentro do BD ( 
X$DBGALERTEXT ).

Att
Mufalani
Get Outlook for iOS


From: oracle_br@yahoogrupos.com.br  on behalf of 
Rafael Mendonca raffaell.t...@yahoo.com [oracle_br] 

Sent: Thursday, September 15, 2016 3:40:13 PM
To: Yahoo! Brazil
Subject: [oracle_br] Envio de alertas



Oracle 11.2.0.4.16 EE AIX 6.1 ASM single instance.

Senhores, boa tarde.

Estou precisando implementar uma tarefa que toda vez que apareça algum alerta 
crítico no alert.log, esse alerta seja enviado por e-mail. Gostaria de 
implementar via PL/SQL sem uso do Cloud control ou do Enterprise Manager.

Alguém poderia ajudar?

[oracle_br] Envio de alertas

[Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]]

Oracle 11.2.0.4.16 EE AIX 6.1 ASM single instance.
Senhores, boa tarde.
Estou precisando implementar uma tarefa que toda vez que apareça algum alerta 
crítico no alert.log, esse alerta seja enviado por e-mail. Gostaria de 
implementar via PL/SQL sem uso do Cloud control ou do Enterprise Manager. 

Alguém poderia ajudar?

Re: RES: [oracle_br] Re: delete

[jlchia...@yahoo.com.br [oracle_br]]

Comigo tudo de boa... Então, por uma questão de método, antes de tentarmos 
analisar esse 'congelamento' que vc diz haver quando tenta criar a package , 
antes de mais nada vamos avançar um pouco pela questão de permissões e 
privilégios - não dá pra indicar neste momento se é isso que está te barrando 
(talvez nem seja isso), mas vamos começar por esse ângulo...
 Muito bem : para deixar escrupulosamente claro -  quando vc cria um database 
link no banco-destino, aquele que vai buscar a informação, vc usa a sintaxe :

CREATE [PUBLIC] DATABASE LINK nomedodatabaselink CONNECT ON 
nomedousuariodobancoorigem IDENTIFIED BY senhadousuáriodobancoorigem USING 
'stringdeconexãoapontandoprobanco-origemdainformação':

Assim, quando vc usar um @nomedodatabaselink em um SQL qualquer no 
banco-destino onde vc criou o dblink, o que vai acontecer é que o Oracle client 
contido na ORACLE_HOME desse banco vai tentar criar uma conexão lá no 
banco-origem identificado pela hoststring da cláusula USING, enviando o 
username e a senha indicados nas cláusulas CONNECT ON e IDENTIFIED  ok ? 
Assim sendo, a primeira coisa é que, LÀ NO BANCO ORIGEM, esse usuário indicado 
no CONNECT ON tenha recbido (diretamente, não por ROLE!!) o privilégio de 
CREATE SESSION, para que possa ser efetuada a conexão Óbvio , esse usuário 
TEM que estar com a senha indicada no IDENTIFIED, não pode estar BLOQUEADO, o 
banco-origem ** TEM ** que ter slots de conexão disponíveis, NÂO PODE haver 
trigger de logon barrando, ie : enfim, além dos privilégios a conexão TEM que 
ser possível
 ESSA é a primeira verificação que vc vai fazer, ie : vc vai conectar no 
banco-origem da informação (e NÂO no banco-destino onde vc criou o dblink) como 
um usuário privilegiado e vai CONFIRMAR que a conexão é possível, vai confirmar 
que a senha é EXATAMENTE a mesma indicada na criação do dblink, vai confirmar 
que a hosstring tá correta Isso se faz Primeiro conectando no banco-origem 
com um usuário administrativo e consultando por triggers de logon, PROFILEs ou 
quetauis que possam influenciar na conexão, e depois conectando no banco-origem 
com o client do banco-destino, usando no prompt de comando (a partir do 
servidor onde roda o banco-destino que tem o dblink) um :
 
 sqlplus usuario/senha@hoststringqueapontaprobancoorigem 
 
 CONFIRMADO que a conexão ao banco-origem da informação a partir do HOME do 
banco-destino é possível, aí o próximo passo é Confirmar que esse usuário 
conectado na origem da informação TEM os privs necessários pra esse objeto 
IND_SALDO_ESTOQUE_DIARIO... 
 Para poder confirmar isso, primeira coisa vc tem que ** IDENTIFICAR ** o que é 
esse objeto IND_SALDO_ESTOQUE_DIARIO, ie, se ele é um sinônimo, uma tabela, ou 
o que, E também identificar a quem pertence/para qual objeto real ele aponta se 
for sinônimo... Para isso, conectado lá no banco-origem dos dados com um 
usuário administrativo, faça um :
 
 SELECT OWNER, OBJECT_TYPE, OBJECT_NAME, STATUS, CREATED FROM DBA_OBJECTS WHERE 
OBJECT_NAME='IND_SALDO_ESTOQUE_DIARIO';
 
 se ele for um Sinônimo, aí faça um :
 
 SELECT * FROM DBA_SYNONYMS WHERE SYNONYM_NAME='IND_SALDO_ESTOQUE_DIARIO';
 
 e veja quais são os objetos reais referenciados pelo sinônimo... 
 
 Já se esse IND_SALDO_ESTOQUE_DIARIO for na verdade uma VIEW, vc ** TEM ** que 
se assegurar que o usuário da conexão feita pelo dblink tenha GRANT (** direto 
**, sem ROLEs) em ** TODOS ** os objetos reais referenciados no SQL da view - 
vc pode obter esse texto de SQL consultando a DBA_VIEWS e então olhar a que ele 
se refere, OU pode consultar a DBA_DEPENDENCIES indicando WHERE 
NAME='IND_SALDO_ESTOQUE_DIARIO'

==> UMA VEZ descobertos os objetos/tabelas Reais a que o usuário precisa ter 
acesso, é se certificar que ele recebeu GRANT de DELETE direto para todos - se 
vc não tem um script para verificar isso lá no banco-origem, vc pode usar este :

-- script de check de privs
col granted_role form a20
col owner form a15
col table_name form a33
col privilege form a33
ACCEPT username  prompt 'Enter Username : '
PROMPT Roles granted to user
SELECT granted_role,admin_option,default_role
FROM dba_role_privs
WHERE grantee=UPPER('')
ORDER BY 1;
PROMPT Table Privileges granted to a user through roles
SELECT granted_role, owner, table_name, privilege
FROM ( SELECT granted_role
FROM dba_role_privs WHERE grantee=UPPER('')
   UNION
   SELECT granted_role
FROM role_role_privs
WHERE role in (SELECT granted_role
 FROM dba_role_privs WHERE grantee=UPPER('')
)
   ) roles, dba_tab_privs
WHERE granted_role=grantee
ORder by 1,2,3,4;
PROMPT System Privileges assigned to a user through roles
SELECT granted_role, privilege
FROM ( SELECT granted_role
FROM dba_role_privs WHERE grantee=UPPER('')
   UNION
   SELECT granted_role
FROM role_role_privs
WHERE role in (SELECT granted_role
 FROM dba_role_privs WHERE grantee=UPPER('')
)
   ) roles, dba_sys_privs
WHERE 

RES: [oracle_br] Re: delete

['Ednilson Silva' ednilson.si...@jbs.com.br [oracle_br]]

Tudo joia Chiappa, e com você?

Tem alguma outra coisa a verificar?

O usuário do DB Link DB_LINK_MATRIZ que é o usuário DBLINK21 já dei GRANT de 
DELETE,INSERT e UPDATE

Diz o analista que esta rotina funcionava e de uns tempos para cá parou, mas 
nada foi alterado no banco.

 

Grato,

Ednilson Silva

 

De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] 
Enviada em: quinta-feira, 15 de setembro de 2016 10:39
Para: oracle_br@yahoogrupos.com.br
Assunto: [oracle_br] Re: delete

 

  

Tudo jóia ? Então, como nós sabemos uma das diferenças ** PRINCIPAIS ** de vc 
encapsular um SQL num stored PL/SQL (Proc, Function, package, etc) é que por 
default as ROLES são desativadas , okdoc ?? Então a Primeira Suposição é que o 
usuário em questão só recebeu permissões para acessar a tal tabela remota via 
ROLE, aí não vai funcionar MESMO, por Definição...
 Acione o DBA e peça para ele dar os GRANTs necessários DIRETAMENTE PARA O 
USUÁRIO em questão, que aí deve ir de boa...
 
 []s
 
   Chiappa

[oracle_br] Re: delete

[jlchia...@yahoo.com.br [oracle_br]]

Tudo jóia ? Então, como nós sabemos uma das diferenças ** PRINCIPAIS ** de vc 
encapsular um SQL num stored PL/SQL (Proc, Function, package, etc) é que por 
default as ROLES são desativadas , okdoc ?? Então a Primeira Suposição é que o 
usuário em questão só recebeu permissões para acessar a tal tabela remota via 
ROLE, aí não vai funcionar MESMO, por Definição...
 Acione o DBA e peça para ele dar os GRANTs necessários DIRETAMENTE PARA O 
USUÁRIO em questão, que aí deve ir de boa...
 
 []s
 
   Chiappa

[oracle_br] delete

['Ednilson Silva' ednilson.si...@jbs.com.br [oracle_br]]

Pessoal,

Estou com um DELETE com DB Link, que sem BEGIN e END executa.

Ai o analista precisa colocar isso numa package com BEGIN e END e não
compila a package, fica travada sem nenhum cursor.

Já olhei lock, já tirei o banco do ar...

 

Oracle Enterprise Database 9i – 9.2.0.8

 

delete ind_saldo_estoque_diario@db_link_matriz

where cod_empresa = 40

   and cod_filial = 3

   and dat_saldo >= '06/09/2016';

 

BEGIN

delete ind_saldo_estoque_diario@db_link_matriz

where cod_empresa = 40

   and cod_filial = 3

   and dat_saldo >= '06/09/2016';

END;

 

Grato,

Ednilson Silva