Re: [oracle_br] Sessões ficando "Presas" workaround please
Bom dia, Segue o código: https://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:226613885088 Atenciosamente, [RED] Rodrigo Mufalani - Dir. Técnico rodr...@mufalani.com.br +55 21 988 994 817 Mufalani +55 21 3193 0326 Rua Almirante Grenfall, 405, Bloco 3, Sala 310 Centro Empresarial Washington Luiz Duque de Caxias - RJ CEP 25085-009 www.mufalani.com.br<http://www.mufalani.com.br/> [id:image002.png@01D2F4C6.8E6B3BE0] De: <oracle_br@yahoogrupos.com.br> em nome de "Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]" <oracle_br@yahoogrupos.com.br> Responder para: "oracle_br@yahoogrupos.com.br" <oracle_br@yahoogrupos.com.br> Data: segunda-feira, 4 de dezembro de 2017 08:40 Para: "oracle_br@yahoogrupos.com.br" <oracle_br@yahoogrupos.com.br> Assunto: Re: [oracle_br] Sessões ficando "Presas" workaround please Alguém pode me ajudar a criar essa procedure? Em Sexta-feira, 1 de Dezembro de 2017 18:18, "Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]" <oracle_br@yahoogrupos.com.br> escreveu: Vinicius: Realizei o purge da recyclebin e matei todas as seções porém o problema voltou a acontecer. Mulafani: Cara, muito esquisito, quando eu fazer o trace da sessão do usuário, SOMENTE DESSE USUÁRIO, do nagios, minha sessão fica travada e não consigo realizar o trace, se eu pego qualquer outro usuário consigo gerar o trace normalmente. SQL> oradebug setospid 23658516; oradebug tracefile_name; oradebug unlimit; oradebug event 10046 trace name context forever, level 12;Oracle pid: 462, Unix process pid: 23658516, image: oracle@ e o cursor do SQL fica preso e a minha sessão fica travada, com qualquer usuário do NAGIOS, com outros usuários o trace é gerado normamente. Em Sexta-feira, 1 de Dezembro de 2017 16:55, "Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]" <oracle_br@yahoogrupos.com.br> escreveu: Obrigado a todos pelo rápido retorno. Vinicius, irei fazer o procedimento e darei um retorno. Mulafani, irei realizar um trace e postarei aqui o conteudo do trace Angelo, acho que não é bug, pois o monitoramento do NAGIOS acontece em vários servidores desse cliente e somente esse database está com esse tipo de problema. Em Sexta-feira, 1 de Dezembro de 2017 16:44, "'Vn @ Startup' vinicius...@gmail.com [oracle_br]" <oracle_br@yahoogrupos.com.br> escreveu: Rafael isso eh muito comum quando se tem recyclebin ativado e muitos objetos para purgar. Tente liberar a Bin com: SQL> purge dba_recyclebin; E veja se o problema eh resolvido. O select de tablespace Free do Nagios leva em conta segmentos na lixeira. Quanto maior o número maior a lentidão. Abrs. Em 1 de dez de 2017 3:56 PM, "angelo angelolis...@gmail.com<mailto:angelolis...@gmail.com> [oracle_br]" <oracle_br@yahoogrupos.com.br<mailto:oracle_br@yahoogrupos.com.br>> escreveu: É verdade que o nagios tem agente para monitorar BD oracle, mas Eu acredito que o software deva estar bugado, porque o agente de monitoramento não deveria causar transtornos no ambiente do usuário, pelo menos em tese.. quanto mais "transparente" melhor Criar uma procedure seria um paliativo, mas já tentou falar com o responsavel pelo software pra ver se existe alguma atualizacao dessa aplicação? Porque isso não vai parar... a nao ser que desabilite o monitoramento de BD []s 2017-12-01 15:23 GMT-02:00 Rafael Mendonca raffaell.t...@yahoo.com<mailto:raffaell.t...@yahoo.com> [oracle_br] <oracle_br@yahoogrupos.com.br<mailto:oracle_br@yahoogrupos.com.br>> : Oracle EE 11.2.0.4 - Standalone (sem grid) Senhores, em um determinado ambiente, está recorrente a abertura de chamado em relação a lentidão, e o que percebi consultando a v$session + v$process +session_event é que existe um usuário chamado XXXNAGIOS (USERNAME) que conecta por um server remoto (MACHINE ) utilizando o SQLPLUS (MODULE SQLPLUS) todas as suas sessões ficam com status ACTIVE, todas elas estão tomando a WAIT SQL*NET message from client e não existe nenhum sql sendo executado no momento. Após matar essas sessões, o ambiente volta a normalizar. Esse é um usuário que conecta no database para realizar operações de monitoramento. Abri chamado com a Oracle para poder ajudar no que pode está ocorrendo, as sessões simplismente não desconectam e após os SQLs serem executados, continuam consumindo recurso da máquina e tomando a WAIT acima. Enquanto a Oracle não me dá uma solução definitiva, estava pensando em realizar um workaround em relação a isso. Seria criar um job que executasse uma PROCEDURE para matar essas sessões de tempos em tempos, gostaria da ajuda de vocês para montar a procedure já que faz muitos anos que trabalhei com pl/sql. O cursor para carregar os dados seria mais ou menos dessa forma: SELECT s.sid, s.serial# FROM v$session s, v$process p
Re: [oracle_br] Sessões ficando "Presas" workaround please
Alguém pode me ajudar a criar essa procedure? Em Sexta-feira, 1 de Dezembro de 2017 18:18, "Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]"escreveu: Vinicius: Realizei o purge da recyclebin e matei todas as seções porém o problema voltou a acontecer. Mulafani: Cara, muito esquisito, quando eu fazer o trace da sessão do usuário, SOMENTE DESSE USUÁRIO, do nagios, minha sessão fica travada e não consigo realizar o trace, se eu pego qualquer outro usuário consigo gerar o trace normalmente. SQL> oradebug setospid 23658516;oradebug tracefile_name;oradebug unlimit;oradebug event 10046 trace name context forever, level 12;Oracle pid: 462, Unix process pid: 23658516, image: oracle@ e o cursor do SQL fica preso e a minha sessão fica travada, com qualquer usuário do NAGIOS, com outros usuários o trace é gerado normamente. Em Sexta-feira, 1 de Dezembro de 2017 16:55, "Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]" escreveu: Obrigado a todos pelo rápido retorno. Vinicius, irei fazer o procedimento e darei um retorno.Mulafani, irei realizar um trace e postarei aqui o conteudo do traceAngelo, acho que não é bug, pois o monitoramento do NAGIOS acontece em vários servidores desse cliente e somente esse database está com esse tipo de problema. Em Sexta-feira, 1 de Dezembro de 2017 16:44, "'Vn @ Startup' vinicius...@gmail.com [oracle_br]" escreveu: Rafael isso eh muito comum quando se tem recyclebin ativado e muitos objetos para purgar. Tente liberar a Bin com: SQL> purge dba_recyclebin; E veja se o problema eh resolvido. O select de tablespace Free do Nagios leva em conta segmentos na lixeira. Quanto maior o número maior a lentidão. Abrs. Em 1 de dez de 2017 3:56 PM, "angelo angelolis...@gmail.com [oracle_br]" escreveu: É verdade que o nagios tem agente para monitorar BD oracle, mas Eu acredito que o software deva estar bugado, porque o agente de monitoramento não deveria causar transtornos no ambiente do usuário, pelo menos em tese.. quanto mais "transparente" melhor Criar uma procedure seria um paliativo, mas já tentou falar com o responsavel pelo software pra ver se existe alguma atualizacao dessa aplicação? Porque isso não vai parar... a nao ser que desabilite o monitoramento de BD []s 2017-12-01 15:23 GMT-02:00 Rafael Mendonca raffaell.t...@yahoo.com [oracle_br] : Oracle EE 11.2.0.4 - Standalone (sem grid) Senhores, em um determinado ambiente, está recorrente a abertura de chamado em relação a lentidão, e o que percebi consultando a v$session + v$process +session_event é que existe um usuário chamado XXXNAGIOS (USERNAME) que conecta por um server remoto (MACHINE ) utilizando o SQLPLUS (MODULE SQLPLUS) todas as suas sessões ficam com status ACTIVE, todas elas estão tomando a WAIT SQL*NET message from client e não existe nenhum sql sendo executado no momento. Após matar essas sessões, o ambiente volta a normalizar. Esse é um usuário que conecta no database para realizar operações de monitoramento. Abri chamado com a Oracle para poder ajudar no que pode está ocorrendo, as sessões simplismente não desconectam e após os SQLs serem executados, continuam consumindo recurso da máquina e tomando a WAIT acima. Enquanto a Oracle não me dá uma solução definitiva, estava pensando em realizar um workaround em relação a isso.Seria criar um job que executasse uma PROCEDURE para matar essas sessões de tempos em tempos, gostaria da ajuda de vocês para montar a procedure já que faz muitos anos que trabalhei com pl/sql. O cursor para carregar os dados seria mais ou menos dessa forma: SELECT s.sid, s.serial# FROM v$session s, v$process p WHERE s.paddr = p.addr AND s.username = 'XXXNAGIOS' AND s.status = 'ACTIVE' AND s.module = 'SQL*PLUS' and s.machine = 'MMM' and s.last_call_et > 400; e em um loop realizar o execute immediate ('alter system kill session ''vsid'', ''vserial'' immediate'); Alguém pode me ajudar a montar esse procedure? Lembrando que isso é somente uma ação paleativa enquanto não identificamos o que está causando esse comportamento no ambiente. #yiv6561204037 #yiv6561204037 -- #yiv6561204037ygrp-mkp {border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv6561204037 #yiv6561204037ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv6561204037 #yiv6561204037ygrp-mkp #yiv6561204037hd {color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 0;}#yiv6561204037 #yiv6561204037ygrp-mkp #yiv6561204037ads {margin-bottom:10px;}#yiv6561204037 #yiv6561204037ygrp-mkp .yiv6561204037ad {padding:0 0;}#yiv6561204037 #yiv6561204037ygrp-mkp .yiv6561204037ad p {margin:0;}#yiv6561204037 #yiv6561204037ygrp-mkp .yiv6561204037ad a
Re: [oracle_br] Sessões ficando "Presas" workaround please
Vinicius: Realizei o purge da recyclebin e matei todas as seções porém o problema voltou a acontecer. Mulafani: Cara, muito esquisito, quando eu fazer o trace da sessão do usuário, SOMENTE DESSE USUÁRIO, do nagios, minha sessão fica travada e não consigo realizar o trace, se eu pego qualquer outro usuário consigo gerar o trace normalmente. SQL> oradebug setospid 23658516;oradebug tracefile_name;oradebug unlimit;oradebug event 10046 trace name context forever, level 12;Oracle pid: 462, Unix process pid: 23658516, image: oracle@ e o cursor do SQL fica preso e a minha sessão fica travada, com qualquer usuário do NAGIOS, com outros usuários o trace é gerado normamente. Em Sexta-feira, 1 de Dezembro de 2017 16:55, "Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]"escreveu: Obrigado a todos pelo rápido retorno. Vinicius, irei fazer o procedimento e darei um retorno.Mulafani, irei realizar um trace e postarei aqui o conteudo do traceAngelo, acho que não é bug, pois o monitoramento do NAGIOS acontece em vários servidores desse cliente e somente esse database está com esse tipo de problema. Em Sexta-feira, 1 de Dezembro de 2017 16:44, "'Vn @ Startup' vinicius...@gmail.com [oracle_br]" escreveu: Rafael isso eh muito comum quando se tem recyclebin ativado e muitos objetos para purgar. Tente liberar a Bin com: SQL> purge dba_recyclebin; E veja se o problema eh resolvido. O select de tablespace Free do Nagios leva em conta segmentos na lixeira. Quanto maior o número maior a lentidão. Abrs. Em 1 de dez de 2017 3:56 PM, "angelo angelolis...@gmail.com [oracle_br]" escreveu: É verdade que o nagios tem agente para monitorar BD oracle, mas Eu acredito que o software deva estar bugado, porque o agente de monitoramento não deveria causar transtornos no ambiente do usuário, pelo menos em tese.. quanto mais "transparente" melhor Criar uma procedure seria um paliativo, mas já tentou falar com o responsavel pelo software pra ver se existe alguma atualizacao dessa aplicação? Porque isso não vai parar... a nao ser que desabilite o monitoramento de BD []s 2017-12-01 15:23 GMT-02:00 Rafael Mendonca raffaell.t...@yahoo.com [oracle_br] : Oracle EE 11.2.0.4 - Standalone (sem grid) Senhores, em um determinado ambiente, está recorrente a abertura de chamado em relação a lentidão, e o que percebi consultando a v$session + v$process +session_event é que existe um usuário chamado XXXNAGIOS (USERNAME) que conecta por um server remoto (MACHINE ) utilizando o SQLPLUS (MODULE SQLPLUS) todas as suas sessões ficam com status ACTIVE, todas elas estão tomando a WAIT SQL*NET message from client e não existe nenhum sql sendo executado no momento. Após matar essas sessões, o ambiente volta a normalizar. Esse é um usuário que conecta no database para realizar operações de monitoramento. Abri chamado com a Oracle para poder ajudar no que pode está ocorrendo, as sessões simplismente não desconectam e após os SQLs serem executados, continuam consumindo recurso da máquina e tomando a WAIT acima. Enquanto a Oracle não me dá uma solução definitiva, estava pensando em realizar um workaround em relação a isso.Seria criar um job que executasse uma PROCEDURE para matar essas sessões de tempos em tempos, gostaria da ajuda de vocês para montar a procedure já que faz muitos anos que trabalhei com pl/sql. O cursor para carregar os dados seria mais ou menos dessa forma: SELECT s.sid, s.serial# FROM v$session s, v$process p WHERE s.paddr = p.addr AND s.username = 'XXXNAGIOS' AND s.status = 'ACTIVE' AND s.module = 'SQL*PLUS' and s.machine = 'MMM' and s.last_call_et > 400; e em um loop realizar o execute immediate ('alter system kill session ''vsid'', ''vserial'' immediate'); Alguém pode me ajudar a montar esse procedure? Lembrando que isso é somente uma ação paleativa enquanto não identificamos o que está causando esse comportamento no ambiente. #yiv9079454453 #yiv9079454453 -- #yiv9079454453ygrp-mkp {border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv9079454453 #yiv9079454453ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv9079454453 #yiv9079454453ygrp-mkp #yiv9079454453hd {color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 0;}#yiv9079454453 #yiv9079454453ygrp-mkp #yiv9079454453ads {margin-bottom:10px;}#yiv9079454453 #yiv9079454453ygrp-mkp .yiv9079454453ad {padding:0 0;}#yiv9079454453 #yiv9079454453ygrp-mkp .yiv9079454453ad p {margin:0;}#yiv9079454453 #yiv9079454453ygrp-mkp .yiv9079454453ad a {color:#ff;text-decoration:none;}#yiv9079454453 #yiv9079454453ygrp-sponsor #yiv9079454453ygrp-lc {font-family:Arial;}#yiv9079454453 #yiv9079454453ygrp-sponsor #yiv9079454453ygrp-lc #yiv9079454453hd {margin:10px
Re: [oracle_br] Sessões ficando "Presas" workaround please
Obrigado a todos pelo rápido retorno. Vinicius, irei fazer o procedimento e darei um retorno.Mulafani, irei realizar um trace e postarei aqui o conteudo do traceAngelo, acho que não é bug, pois o monitoramento do NAGIOS acontece em vários servidores desse cliente e somente esse database está com esse tipo de problema. Em Sexta-feira, 1 de Dezembro de 2017 16:44, "'Vn @ Startup' vinicius...@gmail.com [oracle_br]"escreveu: Rafael isso eh muito comum quando se tem recyclebin ativado e muitos objetos para purgar. Tente liberar a Bin com: SQL> purge dba_recyclebin; E veja se o problema eh resolvido. O select de tablespace Free do Nagios leva em conta segmentos na lixeira. Quanto maior o número maior a lentidão. Abrs. Em 1 de dez de 2017 3:56 PM, "angelo angelolis...@gmail.com [oracle_br]" escreveu: É verdade que o nagios tem agente para monitorar BD oracle, mas Eu acredito que o software deva estar bugado, porque o agente de monitoramento não deveria causar transtornos no ambiente do usuário, pelo menos em tese.. quanto mais "transparente" melhor Criar uma procedure seria um paliativo, mas já tentou falar com o responsavel pelo software pra ver se existe alguma atualizacao dessa aplicação? Porque isso não vai parar... a nao ser que desabilite o monitoramento de BD []s 2017-12-01 15:23 GMT-02:00 Rafael Mendonca raffaell.t...@yahoo.com [oracle_br] : Oracle EE 11.2.0.4 - Standalone (sem grid) Senhores, em um determinado ambiente, está recorrente a abertura de chamado em relação a lentidão, e o que percebi consultando a v$session + v$process +session_event é que existe um usuário chamado XXXNAGIOS (USERNAME) que conecta por um server remoto (MACHINE ) utilizando o SQLPLUS (MODULE SQLPLUS) todas as suas sessões ficam com status ACTIVE, todas elas estão tomando a WAIT SQL*NET message from client e não existe nenhum sql sendo executado no momento. Após matar essas sessões, o ambiente volta a normalizar. Esse é um usuário que conecta no database para realizar operações de monitoramento. Abri chamado com a Oracle para poder ajudar no que pode está ocorrendo, as sessões simplismente não desconectam e após os SQLs serem executados, continuam consumindo recurso da máquina e tomando a WAIT acima. Enquanto a Oracle não me dá uma solução definitiva, estava pensando em realizar um workaround em relação a isso.Seria criar um job que executasse uma PROCEDURE para matar essas sessões de tempos em tempos, gostaria da ajuda de vocês para montar a procedure já que faz muitos anos que trabalhei com pl/sql. O cursor para carregar os dados seria mais ou menos dessa forma: SELECT s.sid, s.serial# FROM v$session s, v$process p WHERE s.paddr = p.addr AND s.username = 'XXXNAGIOS' AND s.status = 'ACTIVE' AND s.module = 'SQL*PLUS' and s.machine = 'MMM' and s.last_call_et > 400; e em um loop realizar o execute immediate ('alter system kill session ''vsid'', ''vserial'' immediate'); Alguém pode me ajudar a montar esse procedure? Lembrando que isso é somente uma ação paleativa enquanto não identificamos o que está causando esse comportamento no ambiente. #yiv4808968869 #yiv4808968869 -- #yiv4808968869ygrp-mkp {border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv4808968869 #yiv4808968869ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv4808968869 #yiv4808968869ygrp-mkp #yiv4808968869hd {color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 0;}#yiv4808968869 #yiv4808968869ygrp-mkp #yiv4808968869ads {margin-bottom:10px;}#yiv4808968869 #yiv4808968869ygrp-mkp .yiv4808968869ad {padding:0 0;}#yiv4808968869 #yiv4808968869ygrp-mkp .yiv4808968869ad p {margin:0;}#yiv4808968869 #yiv4808968869ygrp-mkp .yiv4808968869ad a {color:#ff;text-decoration:none;}#yiv4808968869 #yiv4808968869ygrp-sponsor #yiv4808968869ygrp-lc {font-family:Arial;}#yiv4808968869 #yiv4808968869ygrp-sponsor #yiv4808968869ygrp-lc #yiv4808968869hd {margin:10px 0px;font-weight:700;font-size:78%;line-height:122%;}#yiv4808968869 #yiv4808968869ygrp-sponsor #yiv4808968869ygrp-lc .yiv4808968869ad {margin-bottom:10px;padding:0 0;}#yiv4808968869 #yiv4808968869actions {font-family:Verdana;font-size:11px;padding:10px 0;}#yiv4808968869 #yiv4808968869activity {background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv4808968869 #yiv4808968869activity span {font-weight:700;}#yiv4808968869 #yiv4808968869activity span:first-child {text-transform:uppercase;}#yiv4808968869 #yiv4808968869activity span a {color:#5085b6;text-decoration:none;}#yiv4808968869 #yiv4808968869activity span span {color:#ff7900;}#yiv4808968869 #yiv4808968869activity span .yiv4808968869underline {text-decoration:underline;}#yiv4808968869 .yiv4808968869attach
Re: [oracle_br] Sessões ficando "Presas" workaround please
Rafael isso eh muito comum quando se tem recyclebin ativado e muitos objetos para purgar. Tente liberar a Bin com: SQL> purge dba_recyclebin; E veja se o problema eh resolvido. O select de tablespace Free do Nagios leva em conta segmentos na lixeira. Quanto maior o número maior a lentidão. Abrs. Em 1 de dez de 2017 3:56 PM, "angelo angelolis...@gmail.com [oracle_br]" < oracle_br@yahoogrupos.com.br> escreveu: > > > É verdade que o nagios tem agente para monitorar BD oracle, mas > > Eu acredito que o software deva estar bugado, porque o agente de > monitoramento não deveria causar transtornos no ambiente do usuário, pelo > menos em tese.. quanto mais "transparente" melhor > > Criar uma procedure seria um paliativo, mas já tentou falar com o > responsavel pelo software pra ver se existe alguma atualizacao dessa > aplicação? Porque isso não vai parar... a nao ser que desabilite o > monitoramento de BD > > []s > > > 2017-12-01 15:23 GMT-02:00 Rafael Mendonca raffaell.t...@yahoo.com > [oracle_br]: > >> >> >> Oracle EE 11.2.0.4 - Standalone (sem grid) >> >> >> Senhores, em um determinado ambiente, está recorrente a abertura de >> chamado em relação a lentidão, e o que percebi consultando a v$session + >> v$process +session_event é que existe um usuário chamado XXXNAGIOS >> (USERNAME) que conecta por um server remoto (MACHINE ) utilizando o >> SQLPLUS (MODULE SQLPLUS) todas as suas sessões ficam com status ACTIVE, >> todas elas estão tomando a WAIT SQL*NET message from client e não existe >> nenhum sql sendo executado no momento. >> >> Após matar essas sessões, o ambiente volta a normalizar. Esse é um >> usuário que conecta no database para realizar operações de monitoramento. >> >> Abri chamado com a Oracle para poder ajudar no que pode está ocorrendo, >> as sessões simplismente não desconectam e após os SQLs serem executados, >> continuam consumindo recurso da máquina e tomando a WAIT acima. >> >> Enquanto a Oracle não me dá uma solução definitiva, estava pensando em >> realizar um workaround em relação a isso. >> Seria criar um job que executasse uma PROCEDURE para matar essas sessões >> de tempos em tempos, gostaria da ajuda de vocês para montar a procedure já >> que faz muitos anos que trabalhei com pl/sql. >> >> O cursor para carregar os dados seria mais ou menos dessa forma: >> >> SELECT s.sid, >> s.serial# >> FROM v$session s, >> v$process p >>WHERE s.paddr = p.addr >> AND s.username = 'XXXNAGIOS' >> AND s.status = 'ACTIVE' >> AND s.module = 'SQL*PLUS' >> and s.machine = 'MMM' >> and s.last_call_et > 400; >> >> >> e em um loop realizar o execute immediate ('alter system kill session >> ''vsid'', ''vserial'' immediate'); >> >> Alguém pode me ajudar a montar esse procedure? >> >> Lembrando que isso é somente uma ação paleativa enquanto não >> identificamos o que está causando esse comportamento no ambiente. >> >> >> >> > >
Re: [oracle_br] Sessões ficando "Presas" workaround please
É verdade que o nagios tem agente para monitorar BD oracle, mas Eu acredito que o software deva estar bugado, porque o agente de monitoramento não deveria causar transtornos no ambiente do usuário, pelo menos em tese.. quanto mais "transparente" melhor Criar uma procedure seria um paliativo, mas já tentou falar com o responsavel pelo software pra ver se existe alguma atualizacao dessa aplicação? Porque isso não vai parar... a nao ser que desabilite o monitoramento de BD []s 2017-12-01 15:23 GMT-02:00 Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]: > > > Oracle EE 11.2.0.4 - Standalone (sem grid) > > > Senhores, em um determinado ambiente, está recorrente a abertura de > chamado em relação a lentidão, e o que percebi consultando a v$session + > v$process +session_event é que existe um usuário chamado XXXNAGIOS > (USERNAME) que conecta por um server remoto (MACHINE ) utilizando o > SQLPLUS (MODULE SQLPLUS) todas as suas sessões ficam com status ACTIVE, > todas elas estão tomando a WAIT SQL*NET message from client e não existe > nenhum sql sendo executado no momento. > > Após matar essas sessões, o ambiente volta a normalizar. Esse é um usuário > que conecta no database para realizar operações de monitoramento. > > Abri chamado com a Oracle para poder ajudar no que pode está ocorrendo, as > sessões simplismente não desconectam e após os SQLs serem executados, > continuam consumindo recurso da máquina e tomando a WAIT acima. > > Enquanto a Oracle não me dá uma solução definitiva, estava pensando em > realizar um workaround em relação a isso. > Seria criar um job que executasse uma PROCEDURE para matar essas sessões > de tempos em tempos, gostaria da ajuda de vocês para montar a procedure já > que faz muitos anos que trabalhei com pl/sql. > > O cursor para carregar os dados seria mais ou menos dessa forma: > > SELECT s.sid, > s.serial# > FROM v$session s, > v$process p >WHERE s.paddr = p.addr > AND s.username = 'XXXNAGIOS' > AND s.status = 'ACTIVE' > AND s.module = 'SQL*PLUS' > and s.machine = 'MMM' > and s.last_call_et > 400; > > > e em um loop realizar o execute immediate ('alter system kill session > ''vsid'', ''vserial'' immediate'); > > Alguém pode me ajudar a montar esse procedure? > > Lembrando que isso é somente uma ação paleativa enquanto não identificamos > o que está causando esse comportamento no ambiente. > > > > >
Re: [oracle_br] Sessões ficando "Presas" workaround please
Boa tarde, Porque você não faz um trace dessas sessões para descobrir o que elas estão realmente fazendo. Geralmente esses softwares de monitoramento tem uns plug-ins de monitoramentos do Oracle que fazem umas queries bem toscas, tem que ver se não é isso. Quando você diz que elas estão com wait: SQL*NET message from client, isso significa que o Oracle está esperando algum comando por parte do cliente, ou seja, a sessão está IDLE. USERNAME PROGRAM STATUS STATE EVENT COUNT(1) -- --- -- MYAPP w3wp.exe INACTIVE WAITING SQL*Net message from client 1 MYAPP2 SQL Developer INACTIVE WAITING SQL*Net message from client 1 MYAPP3 plsqldev.exe INACTIVE WAITING SQL*Net message from client 4 MYAPP4 SQL Developer INACTIVE WAITING SQL*Net message from client 2 MYAPP5 plsqldev.exe INACTIVE WAITING SQL*Net message from client 6 Obs.: O Oracle as vezes demora um tempinho para atualizar as informações na v$session, combine a STATUS e STATE para uma melhor visão do ambiente. Mas pode ser que no seu caso, a lentidão seja ocasionada por algo como “excesso de conexões simultâneas”, o que vale investigar. Atenciosamente, [RED] Rodrigo Mufalani - Dir. Técnico rodr...@mufalani.com.br +55 21 988 994 817 Mufalani +55 21 3193 0326 Rua Almirante Grenfall, 405, Bloco 3, Sala 310 Centro Empresarial Washington Luiz Duque de Caxias - RJ CEP 25085-009 www.mufalani.com.br<http://www.mufalani.com.br/> [id:image002.png@01D2F4C6.8E6B3BE0] De: <oracle_br@yahoogrupos.com.br> em nome de "Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]" <oracle_br@yahoogrupos.com.br> Responder para: "oracle_br@yahoogrupos.com.br" <oracle_br@yahoogrupos.com.br> Data: sexta-feira, 1 de dezembro de 2017 15:23 Para: Yahoo! Brazil <oracle_br@yahoogrupos.com.br> Assunto: [oracle_br] Sessões ficando "Presas" workaround please Oracle EE 11.2.0.4 - Standalone (sem grid) Senhores, em um determinado ambiente, está recorrente a abertura de chamado em relação a lentidão, e o que percebi consultando a v$session + v$process +session_event é que existe um usuário chamado XXXNAGIOS (USERNAME) que conecta por um server remoto (MACHINE ) utilizando o SQLPLUS (MODULE SQLPLUS) todas as suas sessões ficam com status ACTIVE, todas elas estão tomando a WAIT SQL*NET message from client e não existe nenhum sql sendo executado no momento. Após matar essas sessões, o ambiente volta a normalizar. Esse é um usuário que conecta no database para realizar operações de monitoramento. Abri chamado com a Oracle para poder ajudar no que pode está ocorrendo, as sessões simplismente não desconectam e após os SQLs serem executados, continuam consumindo recurso da máquina e tomando a WAIT acima. Enquanto a Oracle não me dá uma solução definitiva, estava pensando em realizar um workaround em relação a isso. Seria criar um job que executasse uma PROCEDURE para matar essas sessões de tempos em tempos, gostaria da ajuda de vocês para montar a procedure já que faz muitos anos que trabalhei com pl/sql. O cursor para carregar os dados seria mais ou menos dessa forma: SELECT s.sid, s.serial# FROM v$session s, v$process p WHERE s.paddr = p.addr AND s.username = 'XXXNAGIOS' AND s.status = 'ACTIVE' AND s.module = 'SQL*PLUS' and s.machine = 'MMM' and s.last_call_et > 400; e em um loop realizar o execute immediate ('alter system kill session ''vsid'', ''vserial'' immediate'); Alguém pode me ajudar a montar esse procedure? Lembrando que isso é somente uma ação paleativa enquanto não identificamos o que está causando esse comportamento no ambiente. [As partes desta mensagem que não continham texto foram removidas]
[oracle_br] Sessões ficando "Presas" workaround please
Oracle EE 11.2.0.4 - Standalone (sem grid) Senhores, em um determinado ambiente, está recorrente a abertura de chamado em relação a lentidão, e o que percebi consultando a v$session + v$process +session_event é que existe um usuário chamado XXXNAGIOS (USERNAME) que conecta por um server remoto (MACHINE ) utilizando o SQLPLUS (MODULE SQLPLUS) todas as suas sessões ficam com status ACTIVE, todas elas estão tomando a WAIT SQL*NET message from client e não existe nenhum sql sendo executado no momento. Após matar essas sessões, o ambiente volta a normalizar. Esse é um usuário que conecta no database para realizar operações de monitoramento. Abri chamado com a Oracle para poder ajudar no que pode está ocorrendo, as sessões simplismente não desconectam e após os SQLs serem executados, continuam consumindo recurso da máquina e tomando a WAIT acima. Enquanto a Oracle não me dá uma solução definitiva, estava pensando em realizar um workaround em relação a isso.Seria criar um job que executasse uma PROCEDURE para matar essas sessões de tempos em tempos, gostaria da ajuda de vocês para montar a procedure já que faz muitos anos que trabalhei com pl/sql. O cursor para carregar os dados seria mais ou menos dessa forma: SELECT s.sid, s.serial# FROM v$session s, v$process p WHERE s.paddr = p.addr AND s.username = 'XXXNAGIOS' AND s.status = 'ACTIVE' AND s.module = 'SQL*PLUS' and s.machine = 'MMM' and s.last_call_et > 400; e em um loop realizar o execute immediate ('alter system kill session ''vsid'', ''vserial'' immediate'); Alguém pode me ajudar a montar esse procedure? Lembrando que isso é somente uma ação paleativa enquanto não identificamos o que está causando esse comportamento no ambiente.