- Este tópico contém 18 respostas, 5 vozes e foi atualizado pela última vez 15 anos, 4 meses atrás por
juliano_sf.
-
AutorPosts
-
28 de julho de 2010 às 9:52 pm #95280
Evloki
ParticipanteBoa tarde,
Estou tendo um problema de lentidão no banco (10g) e dando uma olhada vi que tinha muitos usuários que fazem conexão com o banco de dados que continuam logados com status de Inativo, isso pode causar um degradação da performance ? Se sim, como posso resolver esse problema?E outra que eu resolvi olhar foi a volumétria das tablespaces que é essa
[url=http://img697.imageshack.us/i/usagetablespace.jpg/:3q5aq3uh][url=http://img814.imageshack.us/i/vlog.png/:3q5aq3uh]
Se alguem puder dar algumas dicas com relação as essas questões fique a vontade 😉
E outra como saber (sem ser pelo jeito obvio, que é vendo se está menos lento 🙄 ) que a performance realmente melhorou ?
28 de julho de 2010 às 10:18 pm #95281Regis Araujo
ParticipanteOla amigo.. boa tarde..!
Bom.. vamos la.. a sua volumetria de dados é muito pequena.. isto talvez não seja o seu problema..
Comece a verificar os seus parametros de memoria.. SGA e PGA.. quanto de memoria RAM tem este servidor.. é 32 ou 64bits.. é Windows ou é Linux? Qual a versão do Linux?
Suas instruções SQL estão bem escritas ?
Suas instruções SQL usam literal ou bind ?
Quanto de PGA tem? Quanto de SGA tem?
As suas tabelas tem indices?
As instruções SQL estão usando estes indices?
Os indices foram criados baseados nas instruções SQL?Existem N coisas que vc pode verificar para melhorar a performance.. rode statisticas das tabelas.. pois as vezes o plano de execução é antigo e houve uma alteração razoavel dos seus dados, onde o plano que existe não condiz mais com a realidade..!
Bom.. poste mais algumas informações que poderemos lhe ajudar..!!
Abraços..!
28 de julho de 2010 às 10:21 pm #95282Regis Araujo
ParticipanteAhh..!
O Fato de existirem sessões INATIVAS pode não interferir em nada na performance do banco.. a unica coisa que vai interferir é se existirem MUITAS sessões conectadas no seu banco e áreas de SGA e PGA pequenas..
Pois cada sessão conectada aloca um espaço na SGA mesmo que esteja inativa..e quando seu banco precisa alocar algo em memoria.. ele acaba não tendo espaço e a transação fica em wait.. gerando lentidão no processo e ate mesmo gerando lentidão no banco..
Abraços..!
28 de julho de 2010 às 11:41 pm #95285Evloki
ParticipanteEntão eu já estou programando um manutenção no banco.
Vou colocar os indices nas tablespaces certas, desfragmentar, aumentar o tamanho do Redo.log que está so com 30 megas, passar para archivelog etc….
Mas queria ver outra possibilidades também.
Uso win server 2003
Os indices foram criados por quem desenvolveu todo PL/SQL que é de outra unidade que é so responsável por isso, eu andei monitorando os indices para ver se estavam sendo usados com o Alter index usage…. e estava tudo ok.
Com relação ao que vc comentou sobre os processo estarem em Waiting é isso ?
Está tudo com Waiting.Nesse banco tem muitas inserções por dia.
[url=http://img80.imageshack.us/i/vlog.png/:27yqggl9]
SGA
SQL> show sga;
Total System Global Area 935329792 bytes
Fixed Size 791640 bytes
Variable Size 476310440 bytes
Database Buffers 457179136 bytes
Redo Buffers 1048576 bytes
sga_target=934281216
pga_aggregate_target=311427072
sort_area_size=65536
SELECT * from v$pgastat;
[url=http://img413.imageshack.us/i/imagembcr.png/:27yqggl9]
29 de julho de 2010 às 12:48 am #95287Sousa04
ParticipanteOlá
estude a possibilidade de aumentar sua SGA. Está muito baixa.
29 de julho de 2010 às 12:58 am #95288Regis Araujo
ParticipanteOpa..!
Vamos la..!
Com relação as suas sessões em WAIT.. este WAITING quer dizer que a sessão esta aguardando algum comando, o campo anterior.. seconds_in_wait é o tempo desde a ultima execução de algum comando por aquela sessão…
Bom.. um dos pontos primordiais é sua SGA.. ela esta pequena.. 900MB? Tipo.. vamos tentar mudar isto.. se houver a possibilidade.. é claro..
Qual o tamanho total da memoria deste servidor?
Só tem 1 banco rodando nesta máquina?
Esta máquina é exclusiva do banco ORACLE?Alguns pontos… aumentar os redos é uma otima escolha.. pois vc vai ter mais tempo entre a troca de membros e nao vai ter wait por escrita em redo.. o fato de mudar os indices para outra tablespace só vai lhe ajudar se esta tablespace estiver em outro disco e que seja rapido tanto quanto a tablespace de dados.. pois se estiverem no mesmo disco.. não faz diferença..!
Ja o DEFRAG.. não aconselho que faça isto.. pois quando se faz o defrag o Windows “reorganiza” os dados dentro do disco.. e isto vai fazer o oracle perder a referencia do BLOCO de cada dado.. tornando seu select muito mais lento…Outra coisa.. rode um plano dos selects mais lentos e verifique se existem FULL SCAN, FULL INDEX SCAN, tente transformar isto em UNIQUE SCAN.. acrescentando indices ou ate mesmo melhorando a escrita do SQL..
Pelo q entendi a pessoa q desenvolve o sistema faz parte de sua empresa mas é de outra filial, bom.. se possivel.. faça o que te falei.. rode um plano dos selects mais executados no banco e tente criar indices.. se não resolver.. peça ao desenvolvedor para melhorar a instrução SQL.. pois querendo ou não.. se o banco ficar lento.. ninguem vai querer saber q a lentidão é devido ao cara q desenvolveu fez algo errado.. irão cair em cima da pessoa q administra o banco..Então mostre por A + B que se não melhorarem as instruções SQL.. o banco vai continuar lento.. mas não esqueça de fazer tudo oq estiver ao seu alcance na parte de melhorias no banco com aumento de SGA/PGA redo logs.. geração de estatisticas de todas as tabelas.. pois quando alguem falar q a culpa é sua.. vc vai mostrar q não importa o que vc faça.. se não houver uma melhora na escrita das instruções SQL o banco vai ficar lento..!!
Abraços..!
29 de julho de 2010 às 3:28 pm #95294Evloki
ParticipanteMuito obrigado pelas dicas! 😀
Comecei como DBA agora (2 meses) e ainda estou apanhando bastante …
Então, o servidor tem 3.5GB de RAM ele é dedicado só p o Oracle, o problema maior é o HD, que só tem 1 e está tudo junto, Windows e Oracle, na mesma partição…. e esta em varios clientes devido ao processo de implantação aqui na empresa que era feito de qualquer jeito… Agora fiz a proposta de me passarem a parte de banco durante a implantação.. vamos ver se vai da certo.
O sistema roda em uma mineradora que tem grande atividade de inserções e funciona 24/7, quanto acha que deve ser a minha SGA e PGA nesse caso?
Uns 2GB ?
E outra coisa com relação aos Redos.. tinha 3 grupos com 30 megas cada eu adicionei mais 3 grupos de 500 M, já que não dava para parar o sistema, mas na manutenção que estou tentando marcar la quero tirar esses 3 de 30 e deixar somente os de 500 M.
Vc acha que esses 3 grupos de 500M já esta ok ou precisa ter mais grupos (ou arquivos maiores) ?
OBS.: O HD tem 30GB livres29 de julho de 2010 às 6:05 pm #95297Regis Araujo
ParticipanteOpa..!
Então.. melhor deixar só os 3 grupos.. pois seu HD é bem pequeno.. e outra coisa.. se vc colocar o seu banco em archivelog.. vai precisar de muito mais espaço doq tem livre.. e um conselho.. sempre tenha seu banco em archivelog.. isto pode te salvar de muitos problemas em caso de recovery.. Mas é como falei.. para deixar em archive vc vai precisar ter mais espaço.. pois dependendo do tanto de alterações q vc tem no seu banco, vai crescer rapido a área de archive..
Vamos falar da sua SGA/PGA.. bom.. windows é complicado.. pois usa muito mais memória doq linux.. então 2gb de SGA pode ser uma boa escolha.. e para PGA coloque uns 30 ou 40% dos 2GB.. ou seja.. 60 ou 70% de 2GB para SGA e 30 ou 40% de 2GB para PGA…
Só q para mudar a SGA vc vai precisar baixar e subir o banco..Mas lhe aconselho a montar um plano de melhoria deste servidor.. ou de aquisição de outro.. pois como vc mesmo disse.. este banco é 24/7 então não pode ser qualquer máquina para rodar e tem que ter uma politica de backup recover bem descrita..
Creio que com os redos maiores vc ja teve um ganho em performance.. vc vai notar uma melhora tbm quando aumentar sua SGA e PGA.. mas mesmo assim seria melhor ter um servidor com mais memória e também com mais espaço de HD para vc colocar o banco em archivelog e criar rotinas de backup via RMAN…
Qualquer coisa.. posta ai..!!
Abraços..!
29 de julho de 2010 às 7:00 pm #95300Evloki
ParticipanteMuito obrigado Regis!
Pois é, eu mandei uma proposta para eles, dizem que vão trocar tudo em futuro próximo,
Parece que vão comprar um servidor bacana, com pelo menos 8 GB de RAM 3 HDs e tudo mais… mas isso é só vendo mesmo, la o pessoal gosta das coisas no limite! 🙄
Vou marcar hoje para reiniciar o serviço do banco la!
Valeu!29 de julho de 2010 às 7:06 pm #95301vieri
ParticipanteEstou vendo muito troubleshoting nesse tunning,
aonde estão as evidências dos problemas de performance?Cade o insert pesado rodando?!? Qual Wait’s esses insert’s pesados recebem?
Quanto temos de SGA livre ? Está usando SGA_TARGET ?
Porque aumentar os redos? Temos wait’s para ele, ou mensagens no alert que gerem indícios para isso?!
As tabelas que recebem insert macivos, possuem triggers e indices em excesso?
Tente responder essas perguntas.
Continue com a “melhoria” que está fazendo, mas tente me responder essas questões, se não souber onde buscar eu passo os scripts…
De inicio poder rodar essas query no momento de lentidão nos insert’s
para pegarmos qual wait está deixando ele lento.😉
29 de julho de 2010 às 7:07 pm #95302vieri
Participanteessa query:
SET LINESIZE 200
SET PAGESIZE 1000COLUMN username FORMAT A20
COLUMN event FORMAT A30
COLUMN wait_class FORMAT A15SELECT s.inst_id,
NVL(s.username, '(oracle)') AS username,
s.sid,
s.serial#,
sw.event,
sw.wait_class,
sw.wait_time,
sw.seconds_in_wait,
sw.state
FROM gv$session_wait sw,
gv$session s
WHERE s.sid = sw.sid
AND s.inst_id = sw.inst_id and sw.event not in ('SQL*Net message from client')
ORDER BY sw.seconds_in_wait asc;29 de julho de 2010 às 7:46 pm #95303Evloki
ParticipanteAgora está no horário de troca de turno que tem baixa atividade no banco
então peguei o resultado só p vc ver se já acha algo ou se está normal.[url=http://img697.imageshack.us/i/testelr.jpg/:1z4k3gkr]
Agora o PGA ta assim
pga_aggregate_target=311427072SGA
sga_target=934281216
Com relação ao Redo, eu tinha visto no blog do Portilho sobre isso no aler.log aparecia a msg desse tipo
Wed Jan 14 20:59:35 2009
Thread 1 cannot allocate new log, sequence 18
Checkpoint not complete
Current log# 2 seq# 17 mem# 0: C:ORACLEORADATATESTE11GR1REDO02.LOGPor isso resolvi criar grupos maiores.
29 de julho de 2010 às 9:35 pm #95306vieri
ParticipanteTem que rodar no momento de lentidão.
se rodar com a base “flat”,
não tem como encontrar nada.Roda query quando alguem tiver processando as cargas.
Com relação ao redo está correto.
já aumentou? sumiu as msgs?Eu também aumentária o SGA_TARGET para 2Gb.
E acompanharia o comportamento do Gerênciamento automático de memôria na view v$SGA_DYNAMIC_COMPONENTS.
29 de julho de 2010 às 9:51 pm #95307vieri
ParticipanteOu então use statspack,awr,ash, addm para verificar a performance passada da instância… e até bom vc ter um relatório antes e depois das alteração no Oracle. As pessoa gostam de números(“indicadores”)….
29 de julho de 2010 às 10:28 pm #95310Evloki
ParticipanteAinda não alterei o tamanho porque tem que marcar com o cliente para reiniciar o Oracle.
Vou fazer isso que vc falou para ver como fica.
Muito Obrigado. -
AutorPosts
- Você deve fazer login para responder a este tópico.




