Re: [oracle_br] Re: AJuda script shell

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

Obrigado Angelo, isso mesmo.k, com ajuda dos amigos acima, consegui fazer 
esse RTA :) 

Em Quinta-feira, 14 de Dezembro de 2017 11:40, "angelo 
angelolis...@gmail.com [oracle_br]"  escreveu:
 

     Esse seu workaround..   isso também poderia ser chamado de "RTA - Recurso 
Tecnico Alternativo"  um nome mais pomposo para a gambi,  afinal fica feio 
falar pro cliente que fez uma "gambiarra"...   Kkkk
mas as vezes a gente tem que lançar mão dessas tecnicas mesmo.. Ta lembrando o 
caso do outro thread do problema que tava rolando com o Nagios, que o colega 
estava reclamando que de vez em quando travava o banco.

O que nos conforta é que é tudo nessa vida é codigo,  e código sempre tem bug.. 

tomara que a Oracle responda isso rapido, se é que o problema está lá, siga com 
sua pesquisa enquanto isso




2017-12-12 18:20 GMT-02:00 Rafael Mendonca raffaell.t...@yahoo.com [oracle_br] 
:

     Chiappa, no ponto 1 eu concordo com tudo que voce disse. Isso eh um 
workaround vulgo gambiarra para poder sanar o problema do cliente enquanto nao 
se descobri a causa raiz, um chamado com a Oracle ja foi aberto para suporte.
Em relacao ao item 2 a minha consulta funciona sim, esse pid eh o mesmo pid do 
SO, tanto que ela existe na v$process, e nao na v$session. Tanto que funcionou!
Essa questao do alter system disconnect session eu vou testar tambem, obrigado 
pela dica.  

Em Terça-feira, 12 de Dezembro de 2017 14:25, "jlchia...@yahoo.com.br 
[oracle_br]"  escreveu:
 

     Bom, antes de responder algumas obs importantes :

1. absolutamente NÃO É NORMAL que vc tenha que ficar matando sessão manualmente 
: necessariamente ALGUMA COISA está causando a sessão ficar 'pendurada' , e vc 
DEVERIA MESMO encontrar e solucionar esse 'alguma coisa'... Há muitas 
possibilidades, que vão desde falha na infra de rede fazendo a comunicação com 
o banco ser perdida, até bugs em middleware, ou mesmo aplicação porquinha que 
sai criando conexões novas sem desativar anteriores, coisas assim Em ALGUNS 
CASOS inclusive pode ser possível como work-around vc solicitar que o banco 
mesmo elimine sessões inativas por x minutos aplicando o DCD e um profile de 
máximo de conexão, mas normalmente o mais correto é encontrar a Causa raiz 
antes de tudo...

2. SE vc for obrigado a por qquer motivo matar a sessão, a sessão normalmente 
fica com status de KILLED apenas se vc usou (incorretamente, imho) o KILL 
SESSIOn ao invés do DISCONNECT SESSION, via de regra muito mais efetivo : 
http://www.fabioprado.net/ 2014/05/matando-sessoes-no- oracle-database.html é 
uma das refs pra ele

3. Tudo que vou falar na resposta é baseado em conexões DEDICADAS e 
PERMANENTES, e criadas quando a sessão pede conexão : EVIDENTEMENTE não se 
aplica se a sua app está usando qualquer tipo de POOLS DE CONEXÃO, ou se seu 
banco tá usando MTS/SHARED SESSIONs

Isso posto, a resposta : como eu não uso quase nunca KILL SESSION não tenho 
aqui um ambiente a testar, mas de acordo com a nota metalink "How To Find The 
Process Identifier (pid, spid) After The Corresponding Session Is Killed?" (Doc 
ID 387077.1) é possível que o ponteiro em memória do processo que atendia à 
sessão não fique mais registrado na coluna PADDR da V$SESSION, pois o processo 
de eliminação já começou no banco mas não chegou ainda a ser solicitada remoção 
no SO (seja qual for o motivo - banco intensamente concorrente, rollback sendo 
executado ainda, o que for)... Veja lá se é esse o seu caso, SE FOR ISSO 
obviamente teu JOIN :

SELECT  p.spid
    FROM v$session s,
 v$process p
   WHERE s.paddr   = p.addr
   
NÂO VAI FUNCIONAR, sim sim ?? Se for isso aplique um dos work-arounds indicados 
para encontrar o SPID (system pid, o id da task no Sistema Operacional) na 
V$PROCESS a partir da linha da V$SESSION que está com STATUS de KILLED, 
provavelmente (já que seu banco é 11g) deve ser :

select spid from v$process where addr=(select creator_addr from v$session where 
STATUS='KILLED');

Ou alguma variação muito próxima

Aí a segunda parte da resposta : uma vez que vc conseguiu uma query que extraia 
os SPIDs vc TANTO pode escrever um shell script que acione o sqlplus  via 
script e retorne o valor de cada SPID desejado QUANTO pode fazer o contrário, 
ie, dentro do sqlplus gerar um shell script com os comandos necessários - sim, 
um shell script NADA MAIS É do que um arquivo-texto, é Bico gerar um 
arquivo-texto com o output de uma query no sqlplus... Seria algo mais ou menos 
tipo :

==> vc tem um script sqlplus chamado gera_kills.sql contendo :

set term off feedback off verify off pages 0 lines 500 trimspool on head off
spool /tmp/kill_sessions.sh
select 'kill -9 ' || spid from v$process where addr=(select creator_addr from 
v$session where STATUS='KILLED')
/
select 'exit' || chr(10) from dual
/
spool off
exit


Aí teu shell script principal seria tipo :

#!/bin/sh
sqlplus 

Re: [oracle_br] Re: AJuda script shell

[angelo angelolis...@gmail.com [oracle_br]]

Esse seu workaround..   isso também poderia ser chamado de "RTA - Recurso
Tecnico Alternativo"  um nome mais pomposo para a gambi,  afinal fica feio
falar pro cliente que fez uma "gambiarra"...   Kkkk

mas as vezes a gente tem que lançar mão dessas tecnicas mesmo.. Ta
lembrando o caso do outro thread do problema que tava rolando com o Nagios,
que o colega estava reclamando que de vez em quando travava o banco.

O que nos conforta é que é tudo nessa vida é codigo,  e código sempre tem
bug..

tomara que a Oracle responda isso rapido, se é que o problema está lá, siga
com sua pesquisa enquanto isso




2017-12-12 18:20 GMT-02:00 Rafael Mendonca raffaell.t...@yahoo.com
[oracle_br] :

>
>
> Chiappa, no ponto 1 eu concordo com tudo que voce disse. Isso eh um
> workaround vulgo gambiarra para poder sanar o problema do cliente enquanto
> nao se descobri a causa raiz, um chamado com a Oracle ja foi aberto para
> suporte.
>
> Em relacao ao item 2 a minha consulta funciona sim, esse pid eh o mesmo
> pid do SO, tanto que ela existe na v$process, e nao na v$session. Tanto que
> funcionou!
>
> Essa questao do alter system disconnect session eu vou testar tambem,
> obrigado pela dica.
>
>
> Em Terça-feira, 12 de Dezembro de 2017 14:25, "jlchia...@yahoo.com.br
> [oracle_br]"  escreveu:
>
>
>
> Bom, antes de responder algumas obs importantes :
>
> 1. absolutamente NÃO É NORMAL que vc tenha que ficar matando sessão
> manualmente : necessariamente ALGUMA COISA está causando a sessão ficar
> 'pendurada' , e vc DEVERIA MESMO encontrar e solucionar esse 'alguma
> coisa'... Há muitas possibilidades, que vão desde falha na infra de rede
> fazendo a comunicação com o banco ser perdida, até bugs em middleware, ou
> mesmo aplicação porquinha que sai criando conexões novas sem desativar
> anteriores, coisas assim Em ALGUNS CASOS inclusive pode ser possível
> como work-around vc solicitar que o banco mesmo elimine sessões inativas
> por x minutos aplicando o DCD e um profile de máximo de conexão, mas
> normalmente o mais correto é encontrar a Causa raiz antes de tudo...
>
> 2. SE vc for obrigado a por qquer motivo matar a sessão, a sessão
> normalmente fica com status de KILLED apenas se vc usou (incorretamente,
> imho) o KILL SESSIOn ao invés do DISCONNECT SESSION, via de regra muito
> mais efetivo : http://www.fabioprado.net/2014/05/matando-sessoes-no-
> oracle-database.html é uma das refs pra ele
>
> 3. Tudo que vou falar na resposta é baseado em conexões DEDICADAS e
> PERMANENTES, e criadas quando a sessão pede conexão : EVIDENTEMENTE não se
> aplica se a sua app está usando qualquer tipo de POOLS DE CONEXÃO, ou se
> seu banco tá usando MTS/SHARED SESSIONs
>
> Isso posto, a resposta : como eu não uso quase nunca KILL SESSION não
> tenho aqui um ambiente a testar, mas de acordo com a nota metalink "How To
> Find The Process Identifier (pid, spid) After The Corresponding Session Is
> Killed?" (Doc ID 387077.1) é possível que o ponteiro em memória do processo
> que atendia à sessão não fique mais registrado na coluna PADDR da
> V$SESSION, pois o processo de eliminação já começou no banco mas não chegou
> ainda a ser solicitada remoção no SO (seja qual for o motivo - banco
> intensamente concorrente, rollback sendo executado ainda, o que for)...
> Veja lá se é esse o seu caso, SE FOR ISSO obviamente teu JOIN :
>
> SELECT  p.spid
> FROM v$session s,
>  v$process p
>WHERE s.paddr   = p.addr
>
> NÂO VAI FUNCIONAR, sim sim ?? Se for isso aplique um dos work-arounds
> indicados para encontrar o SPID (system pid, o id da task no Sistema
> Operacional) na V$PROCESS a partir da linha da V$SESSION que está com
> STATUS de KILLED, provavelmente (já que seu banco é 11g) deve ser :
>
> select spid from v$process where addr=(select creator_addr from v$session
> where STATUS='KILLED');
>
> Ou alguma variação muito próxima
>
> Aí a segunda parte da resposta : uma vez que vc conseguiu uma query que
> extraia os SPIDs vc TANTO pode escrever um shell script que acione o
> sqlplus  via script e retorne o valor de cada SPID desejado QUANTO pode
> fazer o contrário, ie, dentro do sqlplus gerar um shell script com os
> comandos necessários - sim, um shell script NADA MAIS É do que um
> arquivo-texto, é Bico gerar um arquivo-texto com o output de uma query no
> sqlplus... Seria algo mais ou menos tipo :
>
> ==> vc tem um script sqlplus chamado gera_kills.sql contendo :
>
> set term off feedback off verify off pages 0 lines 500 trimspool on head
> off
> spool /tmp/kill_sessions.sh
> select 'kill -9 ' || spid from v$process where addr=(select creator_addr
> from v$session where STATUS='KILLED')
> /
> select 'exit' || chr(10) from dual
> /
> spool off
> exit
>
>
> Aí teu shell script principal seria tipo :
>
> #!/bin/sh
> sqlplus system/senhadele @gera_kills.sql
> /tmp/kill_sessions.sh
> exit
>
>
>
> ===> ok ? imho é MUUUITO mais simples vc gerar shell script a 

Re: [oracle_br] Re: AJuda script shell

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

Seguem obs :

"Chiappa, no ponto 1 eu concordo com tudo que voce disse. Isso eh um workaround 
vulgo gambiarra para poder sanar o problema do cliente enquanto nao se descobri 
a causa raiz, um chamado com a Oracle ja foi aberto para suporte."

ok : apenas não esqueça que como eu falei NÂO NECESSARIAMENTE é a Oracle que 
vai solucionar - como eu disse, NADA IMPEDE por exemplo de ser um prob na rede 
digamos, que causa perda de comunicação com o banco, OU bug/falha no middleware 
(ODBC é useiro e vezeiro em coisas do tipo), pode ser app porquinha que abre a 
conexão e não a encerra no final do trabalho Blz ???
 E nem preciso dizer, vc vai implementar o work-around de sair matando as 
sessões MAS NÂO PODE deixar de perseguir até encontrar a causa raiz e a 
consertar, senão vc fica eternamente "correndo atrás do rabo", "enxugando 
gelo", como se diz... E não deixe de Analisar/testar/validar a possibilidade de 
implementar DCD+profile com timeout, para que a eventual sessão deixada aberto 
sem uso seja removida pelo próprio RDBMS...

"Em relacao ao item 2 a minha consulta funciona sim, esse pid eh o mesmo pid do 
SO, tanto que ela existe na v$process, e nao na v$session. Tanto que funcionou!"

Repito : o caso Não É ausência de dados na V$PROCESS e sim a coluna ADDR na 
V$SESSION que como Documentado na nota metalink que indiquei Em Alguns Casos de 
sessão killed fica nula, Não permitindo Portanto o JOIN de V$SESSION com 
V$PROCESS por essa coluna, como vc indicou 
 SE no seu caso isso não ocorreu ótimo, vc pode usar o mesmo JOIN que indicou 
sem probs, não precisa usar o work-around indicado na nota metalink A query 
do script sqlplus (se vc for Adotar a minha Recomendação de gerar o shell 
script pelo sqlplus, que repito imho é muito mais simples/fácil de se usar)  
portanto ficaria tipo :
 

set term off feedback off verify off pages 0 lines 500 trimspool on head off
spool /tmp/kill_sessions.sh
SELECT  'kill -9 ' || p.spid
FROM v$session s,
 v$process p
   WHERE s.paddr   = p.addr
 AND s.usernameIS NOT NULL
 AND s.status  = 'KILLED'
/
select 'exit' || chr(10) from dual
/
spool off
exit

okdoc ?? 
 
"Essa questao do alter system disconnect session eu vou testar tambem, obrigado 
pela dica. "

Blz, como eu disse a minha Recomendação é sempre pelo DISCONNECT, na minha 
experiência ele é mais efetivo do que KILL SESSION Mas testa aí direitinho, 
num cenário onde vc tem sessão que fica "eternamente" em KILLED talvez nem 
mesmo o DISCONNECT IMMEDIATE seja tão efetivo, aí talvez vc tenha mesmo que 
apelar pro KILL -9 do processo diretamente...

[]s

  Chiappa
  
OBS :

  o ponto MAIS CRÍTICO do assunto eu REPITO aqui, para ficar Bem Claro : vc só 
deve usar alguma opção de matar a sessão (seja via KILL, seja via DISCONNECT 
IMMEDIATE, seja via KILL -9 direto) SE, e APENAS SE, as suas sessões são 
DEDICATED e SE vc não tem nenhum tipo de POOL DE CONEXÃO ativo, ou MTS/Shared 
Sessions no database... Matar uma sessão que está sendo compartilhada com 
outras via POOL DE CONEXÃO ou via MTS/Shared Server pode ser DESASTROSO, pois 
vc pode acabar matando outras conexões que compartilham essa tal sessão

Re: [oracle_br] Re: AJuda script shell

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

Chiappa, no ponto 1 eu concordo com tudo que voce disse. Isso eh um workaround 
vulgo gambiarra para poder sanar o problema do cliente enquanto nao se descobri 
a causa raiz, um chamado com a Oracle ja foi aberto para suporte.
Em relacao ao item 2 a minha consulta funciona sim, esse pid eh o mesmo pid do 
SO, tanto que ela existe na v$process, e nao na v$session. Tanto que funcionou!
Essa questao do alter system disconnect session eu vou testar tambem, obrigado 
pela dica.  

Em Terça-feira, 12 de Dezembro de 2017 14:25, "jlchia...@yahoo.com.br 
[oracle_br]"  escreveu:
 

     Bom, antes de responder algumas obs importantes :

1. absolutamente NÃO É NORMAL que vc tenha que ficar matando sessão manualmente 
: necessariamente ALGUMA COISA está causando a sessão ficar 'pendurada' , e vc 
DEVERIA MESMO encontrar e solucionar esse 'alguma coisa'... Há muitas 
possibilidades, que vão desde falha na infra de rede fazendo a comunicação com 
o banco ser perdida, até bugs em middleware, ou mesmo aplicação porquinha que 
sai criando conexões novas sem desativar anteriores, coisas assim Em ALGUNS 
CASOS inclusive pode ser possível como work-around vc solicitar que o banco 
mesmo elimine sessões inativas por x minutos aplicando o DCD e um profile de 
máximo de conexão, mas normalmente o mais correto é encontrar a Causa raiz 
antes de tudo...

2. SE vc for obrigado a por qquer motivo matar a sessão, a sessão normalmente 
fica com status de KILLED apenas se vc usou (incorretamente, imho) o KILL 
SESSIOn ao invés do DISCONNECT SESSION, via de regra muito mais efetivo : 
http://www.fabioprado.net/2014/05/matando-sessoes-no-oracle-database.html é uma 
das refs pra ele

3. Tudo que vou falar na resposta é baseado em conexões DEDICADAS e 
PERMANENTES, e criadas quando a sessão pede conexão : EVIDENTEMENTE não se 
aplica se a sua app está usando qualquer tipo de POOLS DE CONEXÃO, ou se seu 
banco tá usando MTS/SHARED SESSIONs

Isso posto, a resposta : como eu não uso quase nunca KILL SESSION não tenho 
aqui um ambiente a testar, mas de acordo com a nota metalink "How To Find The 
Process Identifier (pid, spid) After The Corresponding Session Is Killed?" (Doc 
ID 387077.1) é possível que o ponteiro em memória do processo que atendia à 
sessão não fique mais registrado na coluna PADDR da V$SESSION, pois o processo 
de eliminação já começou no banco mas não chegou ainda a ser solicitada remoção 
no SO (seja qual for o motivo - banco intensamente concorrente, rollback sendo 
executado ainda, o que for)... Veja lá se é esse o seu caso, SE FOR ISSO 
obviamente teu JOIN :

SELECT  p.spid
    FROM v$session s,
 v$process p
   WHERE s.paddr   = p.addr
   
NÂO VAI FUNCIONAR, sim sim ?? Se for isso aplique um dos work-arounds indicados 
para encontrar o SPID (system pid, o id da task no Sistema Operacional) na 
V$PROCESS a partir da linha da V$SESSION que está com STATUS de KILLED, 
provavelmente (já que seu banco é 11g) deve ser :

select spid from v$process where addr=(select creator_addr from v$session where 
STATUS='KILLED');

Ou alguma variação muito próxima

Aí a segunda parte da resposta : uma vez que vc conseguiu uma query que extraia 
os SPIDs vc TANTO pode escrever um shell script que acione o sqlplus  via 
script e retorne o valor de cada SPID desejado QUANTO pode fazer o contrário, 
ie, dentro do sqlplus gerar um shell script com os comandos necessários - sim, 
um shell script NADA MAIS É do que um arquivo-texto, é Bico gerar um 
arquivo-texto com o output de uma query no sqlplus... Seria algo mais ou menos 
tipo :

==> vc tem um script sqlplus chamado gera_kills.sql contendo :

set term off feedback off verify off pages 0 lines 500 trimspool on head off
spool /tmp/kill_sessions.sh
select 'kill -9 ' || spid from v$process where addr=(select creator_addr from 
v$session where STATUS='KILLED')
/
select 'exit' || chr(10) from dual
/
spool off
exit


Aí teu shell script principal seria tipo :

#!/bin/sh
sqlplus system/senhadele @gera_kills.sql
/tmp/kill_sessions.sh
exit



===> ok ? imho é MUUUITO mais simples vc gerar shell script a partir do sqlplus 
do que fazer o sqlplus se comunicar/retornar valores pro SOMas se por qquer 
motivo for isso que vc quer ok, é mais chatinho de fazer mas também é possivel, 
veja 
https://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:430819636473 
ou 
https://stackoverflow.com/questions/4953842/how-to-store-result-from-sqlplus-to-a-shell-variable
 para exemplos

[]s

  Chiappa  #yiv4054497711 #yiv4054497711 -- #yiv4054497711ygrp-mkp {border:1px 
solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv4054497711 
#yiv4054497711ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv4054497711 
#yiv4054497711ygrp-mkp #yiv4054497711hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv4054497711 #yiv4054497711ygrp-mkp #yiv4054497711ads 
{margin-bottom:10px;}#yiv4054497711 

[oracle_br] Re: AJuda script shell

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

Bom, antes de responder algumas obs importantes :

1. absolutamente NÃO É NORMAL que vc tenha que ficar matando sessão manualmente 
: necessariamente ALGUMA COISA está causando a sessão ficar 'pendurada' , e vc 
DEVERIA MESMO encontrar e solucionar esse 'alguma coisa'... Há muitas 
possibilidades, que vão desde falha na infra de rede fazendo a comunicação com 
o banco ser perdida, até bugs em middleware, ou mesmo aplicação porquinha que 
sai criando conexões novas sem desativar anteriores, coisas assim Em ALGUNS 
CASOS inclusive pode ser possível como work-around vc solicitar que o banco 
mesmo elimine sessões inativas por x minutos aplicando o DCD e um profile de 
máximo de conexão, mas normalmente o mais correto é encontrar a Causa raiz 
antes de tudo...

2. SE vc for obrigado a por qquer motivo matar a sessão, a sessão normalmente 
fica com status de KILLED apenas se vc usou (incorretamente, imho) o KILL 
SESSIOn ao invés do DISCONNECT SESSION, via de regra muito mais efetivo : 
http://www.fabioprado.net/2014/05/matando-sessoes-no-oracle-database.html é uma 
das refs pra ele

3. Tudo que vou falar na resposta é baseado em conexões DEDICADAS e 
PERMANENTES, e criadas quando a sessão pede conexão : EVIDENTEMENTE não se 
aplica se a sua app está usando qualquer tipo de POOLS DE CONEXÃO, ou se seu 
banco tá usando MTS/SHARED SESSIONs

Isso posto, a resposta : como eu não uso quase nunca KILL SESSION não tenho 
aqui um ambiente a testar, mas de acordo com a nota metalink "How To Find The 
Process Identifier (pid, spid) After The Corresponding Session Is Killed?" (Doc 
ID 387077.1) é possível que o ponteiro em memória do processo que atendia à 
sessão não fique mais registrado na coluna PADDR da V$SESSION, pois o processo 
de eliminação já começou no banco mas não chegou ainda a ser solicitada remoção 
no SO (seja qual for o motivo - banco intensamente concorrente, rollback sendo 
executado ainda, o que for)... Veja lá se é esse o seu caso, SE FOR ISSO 
obviamente teu JOIN :

SELECT  p.spid
FROM v$session s,
 v$process p
   WHERE s.paddr   = p.addr
   
NÂO VAI FUNCIONAR, sim sim ?? Se for isso aplique um dos work-arounds indicados 
para encontrar o SPID (system pid, o id da task no Sistema Operacional) na 
V$PROCESS a partir da linha da V$SESSION que está com STATUS de KILLED, 
provavelmente (já que seu banco é 11g) deve ser :

select spid from v$process where addr=(select creator_addr from v$session where 
STATUS='KILLED');

Ou alguma variação muito próxima

Aí a segunda parte da resposta : uma vez que vc conseguiu uma query que extraia 
os SPIDs vc TANTO pode escrever um shell script que acione o sqlplus  via 
script e retorne o valor de cada SPID desejado QUANTO pode fazer o contrário, 
ie, dentro do sqlplus gerar um shell script com os comandos necessários - sim, 
um shell script NADA MAIS É do que um arquivo-texto, é Bico gerar um 
arquivo-texto com o output de uma query no sqlplus... Seria algo mais ou menos 
tipo :

==> vc tem um script sqlplus chamado gera_kills.sql contendo :

set term off feedback off verify off pages 0 lines 500 trimspool on head off
spool /tmp/kill_sessions.sh
select 'kill -9 ' || spid from v$process where addr=(select creator_addr from 
v$session where STATUS='KILLED')
/
select 'exit' || chr(10) from dual
/
spool off
exit


Aí teu shell script principal seria tipo :

#!/bin/sh
sqlplus system/senhadele @gera_kills.sql
/tmp/kill_sessions.sh
exit



===> ok ? imho é MUUUITO mais simples vc gerar shell script a partir do sqlplus 
do que fazer o sqlplus se comunicar/retornar valores pro SOMas se por qquer 
motivo for isso que vc quer ok, é mais chatinho de fazer mas também é possivel, 
veja 
https://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:430819636473 
ou 
https://stackoverflow.com/questions/4953842/how-to-store-result-from-sqlplus-to-a-shell-variable
 para exemplos

[]s

  Chiappa