Re: [oracle_br] Troca de idéias: Alguém par ou de usar AWR e passou a usar STATSPACK em 1 0g/11g ?

2014-05-07 Por tôpico Fabio Prado 
Pessoal,

Só para complementar o que o Chiappa escreveu, alguns Advisors (como
por exemplo o SQL Access Advisor e o SQL Tuning Advisor) necessitam de
licença também da option Tuning Pack. Para mais informações dessas options
no 11G, consultem os links abaixo:

http://www.oracle.com/us/products/enterprise-manager/diagnostic-pack-11g-ds-068465.pdf
http://www.oracle.com/us/products/enterprise-manager/tuning-pack-11g-ds-068467.pdf

   Eu particularmente acho ruim usar o Statspack para analisar performance
se você puder pagar para usar o AWR. Só para termos uma idéia de como isso
pode ser ruim... no Oracle 10G existiam 398 visões de performance dinâmicas
(V$), no 12c existem 645 (ver artigo
http://www.fabioprado.net/2014/04/visoes-de-performance-dinamicas.html) e
no 9i devia existir menos de 300, portanto, como o Statspack está
desatualizado (parou no 9i), se vc instalá-lo em um 12c, por exemplo, vc
não conseguirá analisar informações úteis das novas V$ desta versão, o que
poderia nos ajudar em um diagnóstico muito melhor e mais rápido.

[]s


*Fábio Prado*

www.fabioprado.net
"Compartilhando conhecimentos e treinando profissionais em Bancos de Dados
Oracle"



Em 7 de maio de 2014 16:56, Roland Martins  escreveu:

>
>
> Chiappa, obrigado pelas informações e insigths. Vimos que perderemos muito
> com isso, e faremos de tal modo que fique evidente para quem manda no
> pedaço os drawbacks da retirada do mesmo.
>   Em Terça-feira, 6 de Maio de 2014 13:07, "jlchia...@yahoo.com.br" <
> jlchia...@yahoo.com.br> escreveu:
>
>   Roland, a minha experiência em substituir o AWR (e seus amigos, como
> ASH e Advisors) pelo statspack está um tanto defasada (já há alguns anos eu
> não mexo com ele, então pode ser que algumas das obs que vou fazer mudaram)
> , mas foi bem diferente do que vc fala : existem Sim diferenças gritantes
> entre AWR/ASH x Statspack... O busílis é que PODE SER que vc não esteja
> usando as features/recursos/tools que o AWR/ASH dão e o statspack não dá
> (aó Óbvio que a transição vai ser suave) mas se estiver fique sabendo que
> VAI SIM haver problemas, e que provavelmente vc (ou o DBA do cliente,
> enfim, alguém) ** VAI ** ter que escrever algo para satisfazer, esteja
> certo de contabilizar esse tempo/esforço
>   De modo geral :
>
>  a) o statspack não é habilitado por default, nem tem as coletas agendadas
> automaticamente, requerendo ação do DBA para setup E para agendar as coletas
>
>  b) statspack não armazena históricos, é por sua conta criar uma rotina de
> arquivamento de históricos, no estilo de
> http://www.oraclerealworld.com/ash-masters/ : isso implica também que sem
> essa customização adicional, análises do tipo "comparar planos de execução
> anteriores com boa performance versus plano atual que piorou", ou "impacto
> no database depois da nova versão x da aplicação" não são viáveis...
>
>  c) statspack só faz coletas ONLINE e não sobrevive a reboots/restarts do
> banco, Exigindo que o banco absolutamente não tenha sido parado no
> intervalo entre dois snapshots
>
>  d) afaik statspack basicamente *** parou no tempo *** na versão 9ir2, a
> esmagadora maioria das novas estatísticas de performance introduzidas no
> 10g (como por exemplo a informação de I/Os extraída do SO, o plano de
> xecução Extendido - ie, colas A-ROWs e E-ROWS, por exemplo -, as
> estatísticas de SQl adicionadas ás views relacionadas à V$SQL, etc), e das
> novas técnicas de análise (como TIME MODEL, por exemplo) NÂO SÃO SUPORTADAS
> no statspack... Deixo sem comentar as capacidades do 11gr2 que o statspack
> não suporta, já que não tive a chance de comprovar num banco 11g , mas
> certamente imagino que devem ser basicamente todas
>
>  e) statspack basicamente desconsidera as estatísticas de
> performance/waits referentes a RAC, e é single-instance : em caso de RAC é
> por sua conta rodar um report de statspack em cada nó
>
>  f) afaik o statspack não permite análise a nível de SQL, ao contrário do
> AWR que o permite via  e o mais impactante : ao não licenciar o diag pack,
> além de perder o AWR/ASH vc perder também os ADVISORS : ok que nem sempre
> eles te salvam a cara mas algumas vezes dão sim recomendações eventualmente
> úteis, e coisas que vc não tinha pensado Neste último caso, aí não há
> outra solução que não implementar manualmente a expertise do DBA nalguma
> rotina escrita por vc (ou pelo DBA do cliente, enfim) que Simule ações do
> tipo das que os Advisors fazem...
>
>   []s
>
>Chiappa
>
>
>
>

Re: [oracle_br] Troca de idéias: Alguém par ou de usar AWR e passou a usar STATSPACK em 1 0g/11g ?

2014-05-07 Por tôpico Roland Martins 
Chiappa, obrigado pelas informações e insigths. Vimos que perderemos muito com 
isso, e faremos de tal modo que fique evidente para quem manda no pedaço os 
drawbacks da retirada do mesmo.
Em Terça-feira, 6 de Maio de 2014 13:07, "jlchia...@yahoo.com.br" 
 escreveu:
 
  
 Roland, a minha experiência em substituir o AWR (e seus amigos, como ASH e 
Advisors) pelo statspack está um tanto defasada (já há alguns anos eu não mexo 
com ele, então pode ser que algumas das obs que vou fazer mudaram) , mas foi 
bem diferente do que vc fala : existem Sim diferenças gritantes entre AWR/ASH x 
Statspack... O busílis é que PODE SER que vc não esteja usando as 
features/recursos/tools que o AWR/ASH dão e o statspack não dá (aó Óbvio que a 
transição vai ser suave) mas se estiver fique sabendo que VAI SIM haver 
problemas, e que provavelmente vc (ou o DBA do cliente, enfim, alguém) ** VAI 
** ter que escrever algo para satisfazer, esteja certo de contabilizar esse 
tempo/esforço 
  De modo geral :

 a) o statspack não é habilitado por default, nem tem as coletas agendadas 
automaticamente, requerendo ação do DBA para setup E para agendar as coletas

 b) statspack não armazena históricos, é por sua conta criar uma rotina de 
arquivamento de históricos, no estilo de 
http://www.oraclerealworld.com/ash-masters/ : isso implica também que sem essa 
customização adicional, análises do tipo "comparar planos de execução 
anteriores com boa performance versus plano atual que piorou", ou "impacto no 
database depois da nova versão x da aplicação" não são viáveis...

 c) statspack só faz coletas ONLINE e não sobrevive a reboots/restarts do 
banco, Exigindo que o banco absolutamente não tenha sido parado no intervalo 
entre dois snapshots

 d) afaik statspack basicamente *** parou no tempo *** na versão 9ir2, a 
esmagadora maioria das novas estatísticas de performance introduzidas no 10g 
(como por exemplo a informação de I/Os extraída do SO, o plano de xecução 
Extendido - ie, colas A-ROWs e E-ROWS, por exemplo -, as estatísticas de SQl 
adicionadas ás views relacionadas à V$SQL, etc), e das novas técnicas de 
análise (como TIME MODEL, por exemplo) NÂO SÃO SUPORTADAS no statspack... Deixo 
sem comentar as capacidades do 11gr2 que o statspack não suporta, já que não 
tive a chance de comprovar num banco 11g , mas certamente imagino que devem ser 
basicamente todas

 e) statspack basicamente desconsidera as estatísticas de performance/waits 
referentes a RAC, e é single-instance : em caso de RAC é por sua conta rodar um 
report de statspack em cada nó

 f) afaik o statspack não permite análise a nível de SQL, ao contrário do AWR 
que o permite via  e o mais impactante : ao não licenciar o diag pack, além de 
perder o AWR/ASH vc perder também os ADVISORS : ok que nem sempre eles te 
salvam a cara mas algumas vezes dão sim recomendações eventualmente úteis, e 
coisas que vc não tinha pensado Neste último caso, aí não há outra solução 
que não implementar manualmente a expertise do DBA nalguma rotina escrita por 
vc (ou pelo DBA do cliente, enfim) que Simule ações do tipo das que os Advisors 
fazem...

  []s

   Chiappa

[oracle_br] Re: enq: HW - contention

2014-05-07 Por tôpico jlchiappa 
Bom, eu acho que vc tem duas questões diferentes em mãos - causalmente 
aconteceram no mesmo timeframe, mas pode muito bem ser que não estejam 
relacionadas com causa e efeito, ie : que o ORA-600 foi foi causado por eventos 
disparados pelo UPDATE é certo, mas Não É certo que seja o ORA-600 que está 
causando o enqueue, okdoc ?? Vamos tratar separadamente, então...
 Começando com o ORA-600 : não tenho outro conselho que não seja o default, ie 
: usar a tool de lookup de ORA-600 no metalink *** E ***, mais importante de 
tudo, abrir um Chamado no Suporte Oracle  
 Sobre enqueue em LOBs , meu conselho principal é que vc analise com carinho a 
possibilidade de usar SECUREFILES para as tablespaces que contém os LOBs, elas 
via de regra são Muito mais eficientes em manutenção/alocação de extents do que 
BASICFILES Em segundo lugar, vc VAI abrir um Chamado no Suporte para 
comprovar que os bugs já conhecidos (e em princípio já sanados) comuns em LOBs 
não estão re-surgindo no seu ambiente (principalmente os bugs 4450406, 5636728 
e o 5565887, entre outros : não é comum bugs tão antigos resurgirem (após um 
PSU, após alguma alteração de ambiente) mas é o Suporte que vai confirmar ou 
negar isso... 
 
 Como WORK-AROUND, vc pode experimentar deixar alguns tantos muitos extents já 
pré-alocados (com muitas execuções de ALLOCATE EXTENT), alterar params de 
storage / controle de alocação nos blocos (e eventualmente adicionar 
FREELISTS), experimentar inverter o tipo de controle de extents da tablespace 
(ie, se hoje é ASSM mudar para manual/MSSMN, se hoje é manual mudar para 
ASSM)
 Vc também pode aproveitar esse mesmo Chamado vc aproveita para pedir 
Autorização para implementar coisas como o param _bump_highwater_mark_count , 
ás vezes ajuda, mas Nem em Sonhos Pense em fazer isso em prod sem Autorização, 
que a Oracle corta o teu Suporte sem dó nem pena se descobrir...
 
  []s
  
Chiappa

[oracle_br] Problema view materializada

2014-05-07 Por tôpico Roger Camatini 
Boa tarde Galera,

Venho novamente em busca de sanar uma duvida na criação de views
materializadas.

Vamos ao problema: Estou tentando criar uma mview denominada
"MV_PRODIST_PRI_TRECHO_PRIM" só que esse create demora muito(isso quer
dizer mais de horas), o interessante é que se eu executo o mesmo comando
apenas alterando o nome da mview para "MV_PRODIST_PRI_TRECHO_PRIM_TST" roda
de boa e bem rápido.

Achei isso muito estranho. Alguem já viu algo parecido?

Atenciosamente,
Rogério Camatini.

[oracle_br] Problema view materializada

2014-05-07 Por tôpico Roger Camatini 
Boa tarde Galera,

Venho novamente em busca de sanar uma duvida na criação de views
materializadas.

Vamos ao problema: Estou tentando criar uma mview denominada
"MV_PRODIST_PRI_TRECHO_PRIM" só que esse create demora muito(isso quer
dizer mais de horas), o interessante é que se eu executo o mesmo comando
apenas alterando o nome da mview para "MV_PRODIST_PRI_TRECHO_PRIM_TST" roda
de boa e bem rápido.

Achei isso muito estranho. Alguem já viu algo parecido?

Atenciosamente,
Rogério Camatini.

[oracle_br] enq: HW - contention

2014-05-07 Por tôpico Rafael Mendonca 
Senhores, bom dia.
 
dados:
 
SQL> select * from v$version;
BANNER

Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
PL/SQL Release 11.2.0.3.0 - Production
CORE    11.2.0.3.0  Production
TNS for IBM/AIX RISC System/6000: Version 11.2.0.3.0 - Production
NLSRTL Version 11.2.0.3.0 - Production
 
SQL> select * from dba_registry_history
5 PSU
PSU 11.2.0.3.5
 
Senhores, ao ver a HOME de desempenho do grid control, me deparei com o gráfico 
topado no marrom e no vermelho, então comecei a fazer uma análise.
 
No alert.log me deparei com vários erros ORA-600
 
ORA-00600: c㨧o de erro interno, argumentos: [ktspgfb-1], [], [], [], [], [], 
[], [], [], [], [], []
 
= Dump for incident 588872 (ORA 600 [ktspgfb-1]) 
*** 2014-05-07 11:53:32.391
dbkedDefDump(): Starting incident default dumps (flags=0x2, level=3, mask=0x0)
- Current SQL Statement for this session (sql_id=au8354m4z1ssk) -
UPDATE TABELA_XUXA
   SET DTEXP    = :DTEXP
 , DTIMP    = :DTIMP
 , INDEXP   = :INDEXP
 , INDIMP   = :INDIMP
 , TXT  = :TXT
 , TXTWORD  = :TXTWORD
 , TXTPDF   = :TXTPDF
 WHERE CODDOC   = :CODDOC
   AND NUMSEQ   = :NUMSEQ
   AND CODLOCALRESP = :CODLOCALRESP
 
 
Eu sabia que essa tabela possuia alguns campos do tipo LOB, então fui analisar 
junto ao seguinte tópico:

http://askdba.org/weblog/2008/03/hw-enqueue-contention-with-lob/
 
 
 
 
select DBMS_UTILITY.DATA_BLOCK_ADDRESS_FILE(ID2) FILE#,
DBMS_UTILITY.DATA_BLOCK_ADDRESS_BLOCK(ID2) BLOCK#
from v$lock
where type = 'HW';

Apareceram 21 linhas com o FILE_ID 71 e o número de bloco 25218 que estava 
ocorrendo a contenção da HW.
 
Então o segmento encontrado bate com o alert.log que mostra o UPDATE na 
tabela_XUXA
 
isso se trata de um ambiente de produção e preciso de algumas soluções, pois as 
soluções dadas até agora vistas por mim, não sei o tipo de impacto que pode 
causar e algumas vi que não eram válidas para um ambiente de produção. Vi 
também que isso é um bug da versao 10, mas como vemos, estou já na versao 
11.2.0.3.5.
 
Alguém pode ajudar numa solução?