[oracle_br] Re: Monitoring Index

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

Opa : então, primeiro vou assumir aqui que vc não está detectando alto-consumo 
de CPu baseado em Uma Só medida, que na verdade vc fez *** MUITAS E DIVERSAS ** 
medidas, em diversas ocasiões/horas de vários dias (e isso tanto com tools de 
banco quanto com tools do Sistema Operacional) e CONSISTENTEMENTE vc encontrou 
sintomas de grande uso de CPU
 Pois bem,  é bom que vc já tenha dito que encontrar índices não-usados é *** 
UM *** dos trabalhos , pois gasto de CPU pode vir de atualização de índices 
(principalmente por causa da Ordenação do índice, que potencialmente pode ter 
que ser refeita a cada DML) ** MAS ** via de regra  de forma Alguma esse é o 
principal Culpado do consumo de CPU : coisas como SQLs fazendo muitos PARSES, 
uso frequente e em grandes volumes de REGEXP expressions nos SQLs, SQLs 
chamando funções PL/SQL frequentemente e em grandes volumes (por causa do 
context switch) e quetais costumam ser MUITO MAIS CULPADOS do que a Atualização 
de índices, então EM PARALELO a esse trabalho vc VAI ESTAR checando SQLs que 
gastam mais CPU, SQLs que fazem mais parses, usos de PL/SQL nos seus SQLs, 
Planos de Execução impróprios (que estejam fazendo muito sorting, digamos, ou 
que esteja fazendo conversão de b-tree para bitmap ou vice-versa nos acessos 
via índice, etc) : vc pode Inclusive obter info desse tipo nos Planos de 
Execução que ficam nas v$ do banco, ou pegar pelo AWR/ASH, ou implementar 
alguma monitoria custom sua E vc VAI ESTAR TAMBÉM (onde/como for viável, 
principalmente se não tem pool de conexões na parada) utilizando as opções do 
sistema operacional para detectar os processos que mais consomem CPU e 
relacionar esses processos com as sessões do banco, para encontrar quais SQLs 
tais sessões tão executando rotineiramente
 
 Sobre a sua pergunta, especificamente :
 
 a) antes de qualquer coisa vc ** TEM ** que fazer esse Cliente implementar 
algum tipo de Controle na produção dele, onde antes de neguim sair criando 
índices, alterando tabelas, etc, é feito um ** ESTUDO APROPRIADO ** : eu 
DUVIDEODÓ que um ambiente com vinte mil índices tá sendo Minimamente 
Organizado/controlado, pra chegar num número assim tá meio Evidente que é casa 
da mãe joana onde qquer um sai criando índices, ou criando tabela, ou alterando 
programas à lá volonté, sem nem testar o Custo pra isso nem documentar a Causa 
da criação
 
 b) até pensando no que falei acima, imagino que seja ALTA a possibilidade de 
índices Redundantes, ie, com as mesmas colunas em ordem diferente e/ou com 
diferença apenas em alguma colunas secundária... Pode valer a pena umas 
consultinhas na DBA_INDEXES procurando por casos assim - o ponto só é que se 
TEM que testar o efeito que a Remoção desse tipo de índice pode causar... Por 
exemplo : se vc tiver um índice A criado pelas col1, col2 e col3 e um outro 
índice B criado por col1 e col2, dropando o índice A a consulta que tinha WHERE 
col1 AND col2 AND col3 pode ser atendida blz pelo índice B ** mas ** o plano 
pode mudar de índice acess por rowid para index scan - não dá pra dizer se essa 
mudança vai ser Significativa ou não sem Testes...
 
 c) antes de se falar em INDEX MONITORING, uma ** outra ** opção pra vc ver se 
o índice tá sendo usado em consultas ou não é vc LEVANTAR OS PLANOS DE EXECUÇÃO 
dos SQLs e ver quais índices nunca estão presentes em nenhum plano de execução 
: NOVAMENTE, quando se fala de planos de Execução, vc pode obter isso com um 
script de monitoração/consulta de execução frequente seu, customizado, OU pode 
(SE tiver a Licença necessária) obter do AWR/ASH , OU pode tracejar as 
principais rotinas de importância
 
 d) seja via INDEX MONITORING, seja via obtenção de planos, o ponto Crítico 
para se evitar(ou ao menos Diminuir) a chance de falsos negativos é vc ter uma 
amostra ** grande **, de pelo menos um mês : senão, como vc garante que aquele 
índice X que não apareceu em lugar nenhum nas primeiras semanas não vai ser 
CRÍTICO pra aquela rotina de Fechamento de mês que vc não foi avisado mas era o 
Coração da Empresa ??? 
  Esse é o ponto, ÓBVIO que o cliente quer resultado o mais rápido possível, 
pra Ontem se desse, mas quanto MENOR a tua massa de coleta MAIOR A CHANCE de vc 
deixar escapar algo, né não ??? NÃO TEM MILAGRE, vira pro teu cliente e manda a 
real, escolhendo entre Maior Precisão x maior Rapidez - não somos carpinteiros 
barbudos pra providenciar milagre...
  
 e) A monitoração tipicamente gasta *** muito pouco ** de CPU, pois o que ela 
faz é pequenos UPDATEs em tabelas internas que contém metadados sobre o índice 
: quase NADA de Ordenação nem de cálculo ocorre provocado por ele...
 O que eu diria pra vc fazer (no ambiente de HOMOLOGAÇÃO, que Obviamente o 
Cliente Possui ** e ** é bem similar á Produção, né :9 ,  é Ativar o Monitoring 
em, digamos, 1/5 dos índices, acompanhar o aumento/gasto de CPU (que deve ser 
minúsculo, SE existir), depois ativar o Monitoring em 1/3, depois em 3/4 dos 
índices, tipo assim...

[]s

 

Re: [oracle_br] Monitoring Index

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

Se essa máquina tivesse 2 processadores certamente faria diferença




2016-07-06 11:35 GMT-03:00 Rosivaldo Ramalho rosiva...@gmail.com
[oracle_br] :

>
>
> Rafael,
>
> Olha como está a quantidade de parses das consultas (a não utilização de
> bind variables), acredito ser um ponto melhor a atacar ao invés de ir para
> os índices, até porque você terá que fazer isso índice a índice.
>
> Se for para a monitoria de índice mesmo, dá para automatizar o ON/OFF da
> monitoria e o uso deles, mas o que eu me preocuparia é o tempo de
> amostragem de uso, um mês pode não ser suficiente.
>
> Atenciosamente
> --
> Rosivaldo Ramalho 
> Diretor na RLXE - http://www.rlxe.com.br
> 
>
> OCP DB 10g | OCP DB 11g | OCE RAC 11g | OCE PT 11g
> OCP OAS 10g | OCE WLS 10g
>
> http://about.me/rosivaldo
>
> 2016-07-06 11:28 GMT-03:00 Rafael Mendonca raffaell.t...@yahoo.com
> [oracle_br] :
>
>>
>>
>> Oracle 11.2.0.4 - Grid standalone - AIX 64 bits
>>
>> Senhores, bom dia.
>>
>> Em um determinado cliente, existe um servidor físico com 1 processador de
>> 4 cores, onde existem dois servidores virtuais (dois ambientes de produção)
>> compartilhando o recurso da máquina.
>>
>>
>> Os dois servidores estão sempre trabalhando no seu limite de CPU. Estamos
>> fazendo um trabalho para tentar tentar diminuir esse trabalho. Evitando que
>> a CPU trabalhe sem necessidade.
>>
>> **Um dos trabalhos** é a exclusão de índices (se gasta CPU sem
>> necessidade atualizando índices que não estão sendo utilizados pela
>> aplicação) que não estão sendo utilizados, acontece que existem em torno de
>> 20 mil índices criados em uma das bases e gostaria de saber o quanto é que
>> esse monitoramento de índice vai nos custar de CPU, tenho receio de
>> habilitar o monitoramento de índices e acabar prejudicando mais ainda o
>> pouco de CPU disponível que o cliente possui. Estava pensando em aplicar a
>> auditoria de índices em um determinado schema e assim por diante, o
>> problema é que o cliente tem pressa e deixar o monitoramento por 1 mes em
>> cada schema isso iria demorar muito, sei que o processo correto a se fazer
>> seria esse, porém o cliente tem pressa.
>>
>>
>>
>>
>>
>>
> 
>

Re: [oracle_br] Monitoring Index

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

Bom dia,

   Eu concordo com você em parte dessa afirmação, nessa vida de Oracle tudo 
depende… (resposta padrão)… 

   Se eu fosse pesar na balança, um índice mesmo não sendo utilizado a menos 
que fossem tipo todas as colunas da tabela indexadas, sem necessidade, na sua 
tabela mais atualizada, ainda acho que ele gastaria mais storage do que de fato 
CPU para atualização do índice. 

  No seu caso, primeiro eu atacaria o que fato está impactando o seu sistema, 
se ele está consumindo CPU em quase 100%, verifique o que está ocorrendo dentro 
de suas instances, veja suas esperas, faça trace de algumas aplicações e vá 
ajustando as queries mais pesadas e lentas.

Obs.: Não é que discordo da força tarefa nos índices, apenas, como sugestão eu 
alteraria a ordem dessa atividade deixando-a mais para frente.
Atenciosamente,
  
 Rodrigo Mufalani - Diretor Técnico | 
rodr...@mufalani.com.br  | +55 21 988 994 817
Mufalani - +55 21 3193 0326 | Rua Alm Grenfall, 405, Bl 3, Sl 310, Centro 
Empresarial
Wasginton Luiz, Duque de Caxias, RJ | CEP 25085-009 | www.mufalani.com.br 

  
   
> Em 6 de jul de 2016, à(s) 11:28, Rafael Mendonca raffaell.t...@yahoo.com 
> [oracle_br]  escreveu:
> 
> 
> Oracle 11.2.0.4 - Grid standalone - AIX 64 bits
> 
> Senhores, bom dia.
> 
> Em um determinado cliente, existe um servidor físico com 1 processador de 4 
> cores, onde existem dois servidores virtuais (dois ambientes de produção) 
> compartilhando o recurso da máquina.
> 
> 
> Os dois servidores estão sempre trabalhando no seu limite de CPU. Estamos 
> fazendo um trabalho para tentar tentar diminuir esse trabalho. Evitando que a 
> CPU trabalhe sem necessidade.
> 
> **Um dos trabalhos** é a exclusão de índices (se gasta CPU sem necessidade 
> atualizando índices que não estão sendo utilizados pela aplicação) que não 
> estão sendo utilizados, acontece que existem em torno de 20 mil índices 
> criados em uma das bases e gostaria de saber o quanto é que esse 
> monitoramento de índice vai nos custar de CPU, tenho receio de habilitar o 
> monitoramento de índices e acabar prejudicando mais ainda o pouco de CPU 
> disponível que o cliente possui. Estava pensando em aplicar a auditoria de 
> índices em um determinado schema e assim por diante, o problema é que o 
> cliente tem pressa e deixar o monitoramento por 1 mes em cada schema isso 
> iria demorar muito, sei que o processo correto a se fazer seria esse, porém o 
> cliente tem pressa.
> 
> 
> 
> 
> 

Re: [oracle_br] Monitoring Index

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

Obrigado Rosivaldo. Essa questão de consultas realizando hard parses já estamos 
trabalhando fortemente, já encontramos algumas consultas que estavam 
prejudicando em muito a concorrência na shared pool como também a quantidade de 
uso de CPU.
 

Em Quarta-feira, 6 de Julho de 2016 11:35, "Rosivaldo Ramalho 
rosiva...@gmail.com [oracle_br]"  escreveu:
 

     Rafael,
Olha como está a quantidade de parses das consultas (a não utilização de bind 
variables), acredito ser um ponto melhor a atacar ao invés de ir para os 
índices, até porque você terá que fazer isso índice a índice.
Se for para a monitoria de índice mesmo, dá para automatizar o ON/OFF da 
monitoria e o uso deles, mas o que eu me preocuparia é o tempo de amostragem de 
uso, um mês pode não ser suficiente.
Atenciosamente--Rosivaldo Ramalho Diretor na RLXE - 
http://www.rlxe.com.br
OCP DB 10g | OCP DB 11g | OCE RAC 11g | OCE PT 11gOCP OAS 10g | OCE WLS 10g
http://about.me/rosivaldo
2016-07-06 11:28 GMT-03:00 Rafael Mendonca raffaell.t...@yahoo.com [oracle_br] 
:

 

Oracle 11.2.0.4 - Grid standalone - AIX 64 bits

Senhores, bom dia.
Em um determinado cliente, existe um servidor físico com 1 processador de 4 
cores, onde existem dois servidores virtuais (dois ambientes de produção) 
compartilhando o recurso da máquina.


Os dois servidores estão sempre trabalhando no seu limite de CPU. Estamos 
fazendo um trabalho para tentar tentar diminuir esse trabalho. Evitando que a 
CPU trabalhe sem necessidade.
**Um dos trabalhos** é a exclusão de índices (se gasta CPU sem necessidade 
atualizando índices que não estão sendo utilizados pela aplicação) que não 
estão sendo utilizados, acontece que existem em torno de 20 mil índices criados 
em uma das bases e gostaria de saber o quanto é que esse monitoramento de 
índice vai nos custar de CPU, tenho receio de habilitar o monitoramento de 
índices e acabar prejudicando mais ainda o pouco de CPU disponível que o 
cliente possui. Estava pensando em aplicar a auditoria de índices em um 
determinado schema e assim por diante, o problema é que o cliente tem pressa e 
deixar o monitoramento por 1 mes em cada schema isso iria demorar muito, sei 
que o processo correto a se fazer seria esse, porém o cliente tem pressa.






  #yiv8276107571 #yiv8276107571 -- #yiv8276107571ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv8276107571 
#yiv8276107571ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv8276107571 
#yiv8276107571ygrp-mkp #yiv8276107571hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv8276107571 #yiv8276107571ygrp-mkp #yiv8276107571ads 
{margin-bottom:10px;}#yiv8276107571 #yiv8276107571ygrp-mkp .yiv8276107571ad 
{padding:0 0;}#yiv8276107571 #yiv8276107571ygrp-mkp .yiv8276107571ad p 
{margin:0;}#yiv8276107571 #yiv8276107571ygrp-mkp .yiv8276107571ad a 
{color:#ff;text-decoration:none;}#yiv8276107571 #yiv8276107571ygrp-sponsor 
#yiv8276107571ygrp-lc {font-family:Arial;}#yiv8276107571 
#yiv8276107571ygrp-sponsor #yiv8276107571ygrp-lc #yiv8276107571hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv8276107571 
#yiv8276107571ygrp-sponsor #yiv8276107571ygrp-lc .yiv8276107571ad 
{margin-bottom:10px;padding:0 0;}#yiv8276107571 #yiv8276107571actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv8276107571 
#yiv8276107571activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv8276107571
 #yiv8276107571activity span {font-weight:700;}#yiv8276107571 
#yiv8276107571activity span:first-child 
{text-transform:uppercase;}#yiv8276107571 #yiv8276107571activity span a 
{color:#5085b6;text-decoration:none;}#yiv8276107571 #yiv8276107571activity span 
span {color:#ff7900;}#yiv8276107571 #yiv8276107571activity span 
.yiv8276107571underline {text-decoration:underline;}#yiv8276107571 
.yiv8276107571attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv8276107571 .yiv8276107571attach div a 
{text-decoration:none;}#yiv8276107571 .yiv8276107571attach img 
{border:none;padding-right:5px;}#yiv8276107571 .yiv8276107571attach label 
{display:block;margin-bottom:5px;}#yiv8276107571 .yiv8276107571attach label a 
{text-decoration:none;}#yiv8276107571 blockquote {margin:0 0 0 
4px;}#yiv8276107571 .yiv8276107571bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv8276107571 
.yiv8276107571bold a {text-decoration:none;}#yiv8276107571 dd.yiv8276107571last 
p a {font-family:Verdana;font-weight:700;}#yiv8276107571 dd.yiv8276107571last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv8276107571 
dd.yiv8276107571last p span.yiv8276107571yshortcuts 
{margin-right:0;}#yiv8276107571 div.yiv8276107571attach-table div div a 
{text-decoration:none;}#yiv8276107571 div.yiv8276107571attach-table 
{width:400px;}#yiv8276107571 div.yiv8276107571file-title a, 

Re: [oracle_br] Monitoring Index

[Rosivaldo Ramalho rosiva...@gmail.com [oracle_br]]

Rafael,

Olha como está a quantidade de parses das consultas (a não utilização de
bind variables), acredito ser um ponto melhor a atacar ao invés de ir para
os índices, até porque você terá que fazer isso índice a índice.

Se for para a monitoria de índice mesmo, dá para automatizar o ON/OFF da
monitoria e o uso deles, mas o que eu me preocuparia é o tempo de
amostragem de uso, um mês pode não ser suficiente.

Atenciosamente
--
Rosivaldo Ramalho 
Diretor na RLXE - http://www.rlxe.com.br


OCP DB 10g | OCP DB 11g | OCE RAC 11g | OCE PT 11g
OCP OAS 10g | OCE WLS 10g

http://about.me/rosivaldo

2016-07-06 11:28 GMT-03:00 Rafael Mendonca raffaell.t...@yahoo.com
[oracle_br] :

>
>
> Oracle 11.2.0.4 - Grid standalone - AIX 64 bits
>
> Senhores, bom dia.
>
> Em um determinado cliente, existe um servidor físico com 1 processador de
> 4 cores, onde existem dois servidores virtuais (dois ambientes de produção)
> compartilhando o recurso da máquina.
>
>
> Os dois servidores estão sempre trabalhando no seu limite de CPU. Estamos
> fazendo um trabalho para tentar tentar diminuir esse trabalho. Evitando que
> a CPU trabalhe sem necessidade.
>
> **Um dos trabalhos** é a exclusão de índices (se gasta CPU sem necessidade
> atualizando índices que não estão sendo utilizados pela aplicação) que não
> estão sendo utilizados, acontece que existem em torno de 20 mil índices
> criados em uma das bases e gostaria de saber o quanto é que esse
> monitoramento de índice vai nos custar de CPU, tenho receio de habilitar o
> monitoramento de índices e acabar prejudicando mais ainda o pouco de CPU
> disponível que o cliente possui. Estava pensando em aplicar a auditoria de
> índices em um determinado schema e assim por diante, o problema é que o
> cliente tem pressa e deixar o monitoramento por 1 mes em cada schema isso
> iria demorar muito, sei que o processo correto a se fazer seria esse, porém
> o cliente tem pressa.
>
>
>
>
>
> 
>

[oracle_br] Monitoring Index

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

Oracle 11.2.0.4 - Grid standalone - AIX 64 bits

Senhores, bom dia.
Em um determinado cliente, existe um servidor físico com 1 processador de 4 
cores, onde existem dois servidores virtuais (dois ambientes de produção) 
compartilhando o recurso da máquina.


Os dois servidores estão sempre trabalhando no seu limite de CPU. Estamos 
fazendo um trabalho para tentar tentar diminuir esse trabalho. Evitando que a 
CPU trabalhe sem necessidade.
**Um dos trabalhos** é a exclusão de índices (se gasta CPU sem necessidade 
atualizando índices que não estão sendo utilizados pela aplicação) que não 
estão sendo utilizados, acontece que existem em torno de 20 mil índices criados 
em uma das bases e gostaria de saber o quanto é que esse monitoramento de 
índice vai nos custar de CPU, tenho receio de habilitar o monitoramento de 
índices e acabar prejudicando mais ainda o pouco de CPU disponível que o 
cliente possui. Estava pensando em aplicar a auditoria de índices em um 
determinado schema e assim por diante, o problema é que o cliente tem pressa e 
deixar o monitoramento por 1 mes em cada schema isso iria demorar muito, sei 
que o processo correto a se fazer seria esse, porém o cliente tem pressa.