Olá Wilson,
Dá uma olhada no log do listener e também no alert.log para
ver se descobrimos alguma pista do que estava acontecendo.
Jonathan
----- Original Message -----
From: "jlchiappa" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, July 07, 2005 8:18 AM
Subject: [oracle_br] Re: Para de Base de Dados
Esse 0 a 3% , e esse 40 a 60% imagino que é consumo de CPU, certo ?
Se realmente não há leaking de sessões, então é mesmo OU banco mal-
configurado OU limite de hardware que está fazendo sessão falhar na
conexão. Penso que é fazer o procedimento que citei, pra saber quanto
de RAM (no banco e no SO) realmente é consumida pelo startup do
banco, por si só, quanto uma sessão consome, quanto dez consomem,
quanto consome-se no pico.... Com essa info aí sim vc fazer um ajuste
decente, então ANTES de sair mexendo no param x, y ou z é saber
EXATAMENTE como está a situação : trabalho ** TÍPICO ** de DBA. Então
NÂO, eu ** NÃO ** estou recomendando vc aumentar ou diminuir
max_sessions, eu estou recomendando que vc (ou o DBA do banco) faça
um procedimento mais ou menos tipo o que eu citei pra CONHECER e
ENTENDER o ambiente, aí sim mexer nos params se for o caso.
[]s
Chiappa
--- Em [email protected], Wilson Dutra <[EMAIL PROTECTED]>
escreveu
> Olá caro amigo!
>
> A performance da máquina está em torno de 0 a 3% de processamento
por
> quase todos os dias e de 40 a 60% nos horários de pico, quero dizer
na
> saída e retorno do almoço pois quase todos saem e voltam ao mesmo
tempo
> acessando a aplicação web de nossa intranet. No correr do dia, para
uma
> média de 90 funcionários apenas 30% destes trabalham diretamente no
> Oracle e as muitas vezes nem chega a tanto. As aplicações Web Ou
Lan
> utilizadas por todos os testes que realizei verioficando na
V$SESSION
> abrem e fecham as sessões sem nenhum problema. O problema mesmo
ocorreu
> ontem na minha ausência quando um amigo me passou a informação de
que
> um usuário tentava se conectar ao aisstema e recebia mensagens do
IIS
> dizendo que ele era o 17º tentando acessar o Oracle e este meu
amigo
> disse tentou se conectar via SQLPlus e viu que também não
conseguia.
> Como ele estava com o PL/SQLDeveloper aberto em sua máquina fez um
> teste, fechando o PLSQLDev. e depóis tentando se conectar pelo
SQLPlus e
> conseguiu então efetuar a conexão. Ele fez um select na V$SESSION e
> disse que fizera um select agrupado e o total de registros
retornados
> foram pouco mais de 100 registros, ou seja pouco mais de 100
sessões
> abertas. Tirando este problema de muitas pessoas se conectarem ao
mesmo
> tempo a máquina está perfeita e o fato de eu colocar o número de
> sessions para 400 foi apenas por segurança, mas se vc aconselha que
este
> valor seja menor em relação ao hardware que possuo, tranquilo,
voltarei
> atrás, porém, com esta informação que passei será que temos outra
visão
> do problema?
>
> Wilson
>
> jlchiappa escreveu:
>
> >Bom :
> >
> >quanto à sessões : a sua máquina ** TEM ** potência de hardware
para
> >aguentar 400 sessões (imagino que conexões diretas) ??? Pois CADA
> >nova sessão direta implica em abrir um NOVO processo no servidor,
o
> >que gasta mais um pouquinho de CPU, de RAM, de I/O, de banda de
> >rede... A hora que chegar no limite da capacidade de qquer um dos
> >hardwares envolvidos, simplesmente a máquina senta, vc pode
colocar o
> >parâmetro de sessões pra 400 que se o limite físico do hardware é
X,
> >quando chegar em X cabou.... Eu diria que seria o caso de um DBA
> >habilitado, junto com o administrador/root user desse servidor,
fazer
> >o trabalho grosso" de tunning, ou seja :
> >
> >a) shutdown do banco, monitorar pelo SO quanto está gastando de
RAM,
> >CPU, I/O, rede : isso tem que ser o mínimo, coisa de 5% ou menos
até,
> >se não for pode haver serviços desnecessários em ação, programas
> >extras, a idéia enfim é ter a máquina o mais LIVRE possível pro
> >Oracle
> >
> >b) starta-se o banco, ainda sem usuários, sem listener, e monitora-
se
> >mais uma vez, durante um dado intervalo, pelo SO consumo de I/O,
> >CPU, RAM : o ideal é que haja pouquíssima CPU, I/O e rede usada, e
> >que RAM esteja com PELO MENOS uns 50% ou pouco mais livres. Se não
> >ocorrer isso, verificar params do banco, JOBs que possam estar
> >disparando, etc.
> >
> >c) sobe listener, e (ainda monitorando também pelo SO), conecta no
> >banco pela aplicação, faz alguns pequenos trabalhos, veja consumo
de
> >RAM/CPU pelas V$, desconecta-se , veja se a sessão saiu da
V$SESSION.
> >reserve o número do consumo
> >
> >d) deixa cerca de uma dezena de usuários se conectarem e
trabalharem,
> >calcular o consumo, comparar com o número anterior de banco e de
SO,
> >é proporcional ?
> >
> >e) aí sim deixar todo mundo entrar, ir monitorando (SO e banco)
cfrme
> >as sessões forem crescendo, se quando for chegando perto de 100 a
> >memória estiver quase esgotada, ou o consumo de CPU e/ou I/O forem
> >crescendo muito, é limite do hardware, é por aí. Nesse caso, pode-
se
> >pensar no caso de conexões MTS, se o sistema for OLTP e permitir.
> >
> >
> >quanto à entradas na V$SESSION : o banco faz EXATAMENTE o que a
> >aplicação manda, se a aplicação abre uma conexão e não a encerra,
o
> >banco não faz nada, quem manda é o aplicativo. Há aplicativos que
> >montam o que se chama POOL de conexão, ie : a primeira vez que o
> >aplicativo entra ele já abre um monte de conexões duma vez só, e
daí
> >pra frente conforme os usuários forem precisando ele vai reusando
> >essas conexões : isso é normal, aceitável, será que é isso ? O que
> >não é aceitável é que :
> >
> > - se há pool, a cada vez que um usuário final entre no aplicativo
> >uma nova sessão (uma nova entrada na v$session) for criada, não
> >reaproveitando as antigas
> >
> > OU
> >
> > - se cada sessão for uma conexão nova, ao término da sessão a
> >conexão seja mantida aberta.
> >
> >
> > em QUALQUER dos casos, é pau sério, leaking de conexões, o
> >aplicativo tem que ser alterado, num caso desses não há setting
que
> >dê jeito, desperdício é terrível - em teoria vc até poderia talvez
ir
> >matando as conexões em leaking, mas isso é remendo pra bug que não
é
> >de banco, o certo e necessário é alterar o aplicativo.
> >
> > []s
> >
> > Chiappa
> >
> >
> >--- Em [email protected], Wilson Dutra <[EMAIL PROTECTED]>
> >escreveu
> >
> >
> >>Olá pessoal!
> >>
> >>Meu servidor Oracle 9i sofreu uma migraçao de máquina servidora.
> >>
> >>
> >Até
> >
> >
> >>tudo tranquilo. Antes eu tinha 4 Schemas no antigo servidor o que
> >>
> >>
> >estava
> >
> >
> >>impactando em uma super lentidao da base de dados então segui os
> >>conselhor dos amigos do grupos de portar todos para um único
Schema
> >>
> >>
> >e
> >
> >
> >>assim liberando automaticamente mais processos. Tudo ótimo até
> >>
> >>
> >então.
> >
> >
> >>Realmente melhorou e muito a performance do servidor. Aproveitei
a
> >>migração para unir estes Schemas. O que ocorre agora: Notei na
nova
> >>
> >>
> >base
> >
> >
> >>que o número de sessões a serem abertas estava no default de 150
e
> >>
> >>
> >como
> >
> >
> >>sei que precisaria de mais alterei para 400 sessões. Ontem meu
> >>
> >>
> >servidor
> >
> >
> >>em um determinado momento só deixou trabalhar nele quem já estava
> >>conectado e nimguém mais conseguia se conactar a ele. Tinha na
> >>
> >>
> >V$SESSION
> >
> >
> >>um total de 100 conexões ativas. Alguém poderia me ajudar em
> >>
> >>
> >enxergar no
> >
> >
> >>que mais terei de fazer para que não ocorra mais isto?
> >>
> >>Outra coisa que eu não consigo entender também e se puderem me
> >>
> >>
> >explicar
> >
> >
> >>seria de grande ajuda: Sempre que verifico a V$SESSION existem
> >>
> >>
> >sessões
> >
> >
> >>abertas pelo mesmo usuário, em um mesmo terminal, em um mesmo
> >>
> >>
> >programa
> >
> >
> >>emm quantidades diferentes. Alguns com 4 sessões abertas, outros
> >>
> >>
> >com 3,
> >
> >
> >>ou com 1 apenas e assim vai. Por que esta diferença? Não deveria
> >>
> >>
> >ser
> >
> >
> >>apenas uma sessão por conexão?
> >>
> >>Atenciosamente
> >>Wilson Dutra
> >>
> >>
> >
> >
> >
> >
> >
>
>_____________________________________________________________________
_
> >
> >Cancelar assinatura...: [EMAIL PROTECTED]
> >Moderadores da lista....:Dorian Anderson Soutto [EMAIL PROTECTED]
> >Fernanda Damous [EMAIL PROTECTED]
> >Alisson Aguiar [EMAIL PROTECTED]
>
>_____________________________________________________________________
_
> >http://br.groups.yahoo.com/group/oracle_br/
>
>_____________________________________________________________________
_
> >
> >Sair da Lista...: [EMAIL PROTECTED]
> >Links do Yahoo! Grupos
> >
> >
> >
> >
> >
> >
> >
> >
> >
______________________________________________________________________
Cancelar assinatura...: [EMAIL PROTECTED]
Moderadores da lista....:Dorian Anderson Soutto [EMAIL PROTECTED]
Fernanda Damous [EMAIL PROTECTED]
Alisson Aguiar [EMAIL PROTECTED]
______________________________________________________________________
http://br.groups.yahoo.com/group/oracle_br/
______________________________________________________________________
Sair da Lista...: [EMAIL PROTECTED]
Links do Yahoo! Grupos
______________________________________________________________________
Cancelar assinatura...: [EMAIL PROTECTED]
Moderadores da lista....:Dorian Anderson Soutto [EMAIL PROTECTED]
Fernanda Damous [EMAIL PROTECTED]
Alisson Aguiar [EMAIL PROTECTED]
______________________________________________________________________
http://br.groups.yahoo.com/group/oracle_br/
______________________________________________________________________
Sair da Lista...: [EMAIL PROTECTED]
Links do Yahoo! Grupos
<*> Para visitar o site do seu grupo na web, acesse:
http://br.groups.yahoo.com/group/oracle_br/
<*> Para sair deste grupo, envie um e-mail para:
[EMAIL PROTECTED]
<*> O uso que você faz do Yahoo! Grupos está sujeito aos:
http://br.yahoo.com/info/utos.html
