[oracle_br] Re: Performance do ODA virtualizado

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

Blz ? Então , duas coisas aí : primeiro, antes de tudo, acredito que vc Saiba 
que vc pode fazer hard-partitioning de qulquer um dos muitos hardwares 
suportados pelo Oracle VM Server, não só com ODA, ok ?? A vantagem do ODA é que 
ele é um hardware bastante parrudo que já vem montado e pronto pra usar, 
excelente para Empresas que não possuem um departamento de TI experiente em 
hardware server-class, MAS sempre existe a possibilidade de montar um hardware 
tão bom quanto ou talvez até melhor se vc adquirir no mercado os componentes, 
de outros fornecedores que não a Oracle.
A segunda coisa é a sua resposta : colega, é ABSOLUTAMENTE IMPOSSÍVEL para nós, 
daqui de fora, que NÃO CONHECEMOS a sua Aplicação, NÃO CONHECEMOS as suas 
exigências de SLA, NÃO CONHECEMOS detalhes operacionais como tipificação da 
aplicação (se é BATCH ou Online), NÃO CONHECEMOS coisas como volume de dados, 
qualidade dos SQLs da aplicação e tantas mais, dizermos qualquer coisa que não 
seja CHUTE, sim sim sim 

==> A única maneira precisa para vc determinar se um hardware (ODA ou não) 
atende às suas exigências é fazer um BENCHMARK dele, ie, um teste o mais 
PRECISO possível, preferencialmente com uma instalação de testes da aplicação 
rodando dados fictícios mas Parecidos com os dados reais, e num volume e com 
uma qtdade de usuários não trivial, é isso... SE isso (que é a única maneira 
Exata e Precisa de prever performance) não for possível/viável por qquer 
motivo, aí teu plano B seria usar um software de benchmark / testes (como 
HammerORA em https://hammerora.soft112.com/, SLOB em 
https://kevinclosson.net/slob/, SwingBench em 
http://www.dominicgiles.com/swingbench.html, entre N outros) tanto no novo 
hardware quanto no hardware velho já existente e COMPARAR, ok ? E em alguns 
casos dá também pra CAPTURAR o processamento no banco velho rodando no hardware 
velho e depois RE-EXECUTAR eles no banco novo do hardware novo pra poder 
comparar as performances alcançadas, isso se faz com o Oracle Real Application 
Test, veja 
https://www.oracle.com/technetwork/database/options/real-application-testing-option-2355173.html
 para ref...

Blz ? Torno a repetir, seum algum TESTE real, vc e eu estaríamos CHUTANDO aqui, 
pode ser que acerte mas pode ser que não - isso Não É a maneira profissional e 
correta de avaliar um Sistema, creio

 []s
 
  Chiappa

[oracle_br] Re: Performance Oracle 9i

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

Opa, blz ? Então, imho é *** rigorosamente Impossível *** vc "pegar problemas 
de performance com query" - o que é possível é vc identificar SQLs 'caros', 
SQls custosos, que podem ou não ser foco de má performance, mas NÃO HÁ COMO vc 
identificar de maneira automática (seja via query ou qual for a maneira) se 
esses SQLs estão apresentando performance abaixo do possível ou se o gasto (de 
I/O, de CPU ou o que for) é normal para a tarefa... Pra ficar mais claro, tome 
o exemplo de um SQL que leia, sei lá, 10 mil blocos pra retornar meia dúzia de 
linhas : normalmente num caso desses neguim já ia sair gritando "tem problema! 
tem problema" mas suponha que é um SELECT com algum tipo de Agrupamento e que 
retorne as vendas todas do ano que estão na tabela - não adianta querer indexar 
(pois NECESSARIAMENTE a tabela toda tem que ser lida, e índice é eficiente 
quando se necessita ler MENOS que a totalidade dos dados) , não adianta 
particionar por mês/dia (já que queremos/precisamos TODOS os dados) aí não tem 
jeito, se a tabela tem 10 mil blocos o RDBMS  *** TEM ***  que ler todos eles 
pra atender à tarefa tal como proposta... Neste exemplo, por mais que esse SQL 
seja apontado na listagem não há RIGOROSAMENTE NADA que se possa fazer no SQL 
em si , para este caso a melhoria de performance passaria por estruturas 
físicas diferentes (views materializada que já faça o agrupamento num período 
fora de pico, talves) e/ou alteração da solicitação (digamos, alterar o 
relatório para MENSAL ao invés de ANUAL, com os relatórios dos meses anteriores 
(ou seus dados) sendo armazenados talvez fora do banco, coisas assim

  Assim sendo : nunca esquecendo essa ENORME RESSALVA acima exposta, ie, que o 
que vc vai obter são SUSPEITOS, que PODEM ou NÃO ser causa de problemas de 
performance, a resposta é : vc encontra as estatísticas de SQLs na V$SQL e na 
V$SQLAREA, vc vai fazer simples consultas nelas ordenando pelos |TOP-N 
(tipicamente se indica uns 25) resultados... 
 Um exemplinho rastaquera,indicando os top-25 SQLs mais demorados (em termos de 
tempo total) :

SELECT * FROM
(SELECT
sql_fulltext,
sql_id,
elapsed_time,
child_number,
disk_reads,
executions,
first_load_time,
last_load_time
   FROM v$sql
ORDER BY elapsed_time DESC)
WHERE ROWNUM < 26;


Com essa mesma lógica, vc pode encontrar os TOP-N SQLs que mais I/Os fizeram, 
os TOP-N SQLs que mais gastaram CPU, os TOP-N SQLs mais usados/executados no 
database... Bico...Dá um look na doc 9i para ver EXATAMENTE quais colunas vc 
tem na V$SQL e na V$SQLAREA e é isso...

Apenas aviso que :

 a. as V$ são TOTALMENTE APAGADAS após um reboot do database : se vc pára o 
banco para backups frios ou coisa assim, esteja preparado para isso, SALVANDO 
de alguma forma os conteúdos . SE fosse banco 10g vc já tem isso automático (na 
figura do AWR/ASH) mas no banco 9i não tem, no 9i ou vc pode usa o STATSPACK 
para fazer as consultas (quie aí ele já tem um local pra salva dos dados 
extraídos das V$) ou então vc cria uma rotina sua : 
http://datavirtualizer.com/ash-masters/33-2/ é um exemplo mas talvez no seu 
caso vc queira escrever uma rotina mais simples que só salve as V$SQLxxx, ao 
invés dos WAITs

 b. as V$SQLxxx refletem o CACHE de SQLs, ie, elas mostram APENAS e TÃO SOMENTE 
os SQLs que estão atualmente no cache : para que vc não perca aqueles SQLs 
infrequentes mas importantes  pro negócio e/ou pra análise de performance, vc 
TEM que repetir as consultas nelas  várias e várias vezes , com intervalos ente 
cada consulta, por dias e dias (ou mesmo semanas) a fio... 

[]s


  Chiappa

RES: RES: [oracle_br] Re: performance em função

['Grupos' marcio_...@yahoo.com.br [oracle_br]]

Chiappa,

 

Segundo o fornecedor a consulta é simples, sem ordenação, sem where e sem join, 
é o que tenho de detalhes sobre a sua utilização. Gerei um trace de uma sessão 
agora, e me chamou a atenção o evento MUTEX X:

 

call count   cpuelapsed   disk  querycurrentrows

--- --   -- -- -- --  --

Parse0  0.00   0.00  0  0  0   0

Execute 256680 21.98  80.68  0  0  0   0

Fetch   256679  7.01 271.58  0  0  0  256679

--- --   -- -- -- --  --

total   513359 28.99 352.27  0  0  0  256679

 

Misses in library cache during parse: 0

Optimizer mode: ALL_ROWS

Parsing user id: 27 (recursive depth: 1)

 

Elapsed times include waiting on following events:

  Event waited on Times   Max. Wait  Total Waited

     Waited  --  

  library cache: mutex X   27403.97470.98

  cursor: pin S  421.44  7.58

  latch free  10.00  0.00

 

 

 



 

OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS

 

call count   cpuelapsed   disk  querycurrentrows

--- --   -- -- -- --  --

Parse0  0.00   0.00  0  0  0   0

Execute  0  0.00   0.00  0  0  0   0

Fetch0  0.00   0.00  0  0  0   0

--- --   -- -- -- --  --

total0  0.00   0.00  0  0  0   0

 

Misses in library cache during parse: 0

 

Elapsed times include waiting on following events:

  Event waited on Times   Max. Wait  Total Waited

     Waited  --  

  asynch descriptor resize 19700.00  0.00

  latch: row cache objects  1110.54  5.11

  buffer busy waits  240.65  1.55

  latch: cache buffers chains   1290.65 10.11

  latch free  40.35  0.63

  wait list latch free20.03  0.04

 

 

OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS

 

call count   cpuelapsed   disk  querycurrentrows

--- --   -- -- -- --  --

Parse0  0.00   0.00  0  0  0   0

Execute 256680 21.98  80.68  0  0  0   0

Fetch   256679  7.01 271.58  0  0  0  256679

--- --   -- -- -- --  --

total   513359 28.99 352.27  0  0  0  256679

 

Misses in library cache during parse: 0

 

Elapsed times include waiting on following events:

 Event waited on Times   Max. Wait  Total Waited

     Waited  --  

  library cache: mutex X   27403.97470.98

  cursor: pin S  421.44  7.58

  latch free  10.00  0.00

 

 

Não tenho muitos detalhes do funcionamento interno dessa função na aplicação, 
resumidamente foi o que te passei, passa-se uns parâmetros e ele retorna uma 
string, não tem consulta a nenhuma tabela dentro da função.

 

De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] 
Enviada em: terça-feira, 23 de dezembro de 2014 15:12
Para: oracle_br@yahoogrupos.com.br
Assunto: Re: RES: [oracle_br] Re: performance em função

 

  

Colega, vc ** não respondeu ** o que eu perguntei : a função é usada no SELECT, 
no WHERE, no ORDER BY, em QUAL lugar ?? o Plano de execução sem a dita-cuja é 
diferente ?? A tal "validação" usa regexp, XML ou quetais ?? PO estar 
acontecendo o caso de que a função em si roda em menos de um segundo mas está 
sendo aplicada em não-sei-quantas centenas de milhares de linhas e assim 
PORTANTO está levando DEZENAS de milhares de segundos na soma total ?? Vc FEZ 
um teste da query fazendo a tal "validação de strings" em SQL puro, assim 
EVITANDO context-switch e cia bela ?? Pl

Re: RES: [oracle_br] Re: performance em função

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

Colega, vc ** não respondeu ** o que eu perguntei : a função é usada no SELECT, 
no WHERE, no ORDER BY, em QUAL lugar ?? o Plano de execução sem a dita-cuja é 
diferente ?? A tal "validação" usa regexp, XML ou quetais ?? PO estar 
acontecendo o caso de que a função em si roda em menos de um segundo mas está 
sendo aplicada em não-sei-quantas centenas de milhares de linhas e assim 
PORTANTO está levando DEZENAS de milhares de segundos na soma total ?? Vc FEZ 
um teste da query fazendo a tal "validação de strings" em SQL puro, assim 
EVITANDO context-switch e cia bela ?? Plz detalhes

 []s
 
   Chiappa

RES: [oracle_br] Re: performance em função

['Grupos' marcio_...@yahoo.com.br [oracle_br]]

A função não faz consulta a dados nenhum, são passados alguns parâmetros e de 
acordo ele retorna o resultado, dentro da função é apenas algumas validações de 
strings.

 

Já eu executando essa função direto no banco, SQL Developer, o retorno é em 
milissegundos.

 

A consulta está vindo de uma aplicação Web criada em cima de um IIS.

 

De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] 
Enviada em: terça-feira, 23 de dezembro de 2014 14:17
Para: oracle_br@yahoogrupos.com.br
Assunto: [oracle_br] Re: performance em função

 

  

Opa, pra começo de conversa PL/SQL sendo chamado de dentro de um comando SQL é 
quase sempre uma  Péssima *** idéia : pesquisa em asktom.oracle.com que vc 
vai encontrar artigos faklando sobre as issues que vc pode/vai encontrar, como 
por exemplo context switch (já que isso força o RDBMS a ficar "pulando" entre 
os engibes de SQL e de PL/SQL, o que consome SIM cpu : 
https://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:5173758137186#20839207575486
 é um dos exemplos que vc vai encontrar), OU então o fato Inescapável de que se 
vc está passando valores presentes em linhas de uma tabela pra rotina PL/SQL, 
vc LOGICAMENTE vai ter que executar a rotina PL/SQL uma vez para cada valor 
possível diferente. Essa última questão pode ser mitigada no banco 11g com 
o CACHE DE RESULTADOS (veja 
oracle-base.com/articles/misc/efficient-function-calls-from-sql.php e 
http://www.oracle.com/technetwork/issue-archive/2011/11-sep/o51asktom-453438.html
 para exemplos), mas o IDEAL é fugir desses custos...

Isso posto, se vc REALMENTE, ABSOLUTAMENTE, TEM QUE chamar a rotina PL/SQL de 
dentro do SQL,  pra gente poder responder melhor plz nos diga :

 a) a função está sendo usada só na cláusula de SELECT da query, ** OU ** está 
sendo referenciada no WHERE, no ORDER BY e/ou em outros pontos ?? Se não é só 
no SELECT, vc tem *** ENORMES *** chances da função estar causando mudanças 
negativas no Plano de Execução : por exemplo, a função está alterando uma 
coluna indexada, ou - já que OBVIAMENTE o CBO não consegue saber qual valor a 
função retorna, então não tem como usar nem Histogramas nem as estatísticas de 
que ele dispõe - o CBO não consegue Otimizar o plano, por aí...
 
 b) a função que vc está chamando tem a ver com as built-ins de XML ? Se sim, 
CONFIRA as correções presents nos patchsets 11.2.0.3 e 11.2.0.4, pois bugs como 
o 9919654 tipicamente tendem a se fazxer presentes com funções XML, que por 
natureza são complexas (tendem a fazer montes de SUBSTR/INSTR) e recursivas
 
 c) a tal função faz processamento ** pesado ** de strings, tipo expressões 
regulares ?? Se sim, cfrme 
https://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:6071446400346871004#608340346455747
 alerta, vc VAI SIM encontrar um overhead ao utilizar as built-ins de regex ao 
invés das funções primitivas de string do PL/SQL
 
 ==> Sobre debug : o primeiro e óbvio passo é testar a tal query ** SEM ** a 
função, depois testar com uma função dummy (ie, que só faça um comando simples, 
tipo um NOP, ou uma adição se o valor for numérico, ou seja, alguma coisa 
mínima, só pra testar) 
   SE os testes acima retornaram o mesmo plano de execução mas consumiram muito 
menos CPU, vc já Provou que é a rotina em si que não está Otimizada ao máximo, 
é partir pro TUNING dela, ou então (o Melhor, como dito no início) substituir a 
rotina PL/SQL por built-ins SQL...
   
[]s

   Chiappa

[oracle_br] Re: performance em função

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

Opa, pra começo de conversa PL/SQL sendo chamado de dentro de um comando SQL é 
quase sempre uma  Péssima *** idéia : pesquisa em asktom.oracle.com que vc 
vai encontrar artigos faklando sobre as issues que vc pode/vai encontrar, como 
por exemplo context switch (já que isso força o RDBMS a ficar "pulando" entre 
os engibes de SQL e de PL/SQL, o que consome SIM cpu : 
https://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:5173758137186#20839207575486
 é um dos exemplos que vc vai encontrar), OU então o fato Inescapável de que se 
vc está passando valores presentes em linhas de uma tabela pra rotina PL/SQL, 
vc LOGICAMENTE vai ter que executar a rotina PL/SQL uma vez para cada valor 
possível diferente. Essa última questão pode ser mitigada no banco 11g com 
o CACHE DE RESULTADOS (veja 
oracle-base.com/articles/misc/efficient-function-calls-from-sql.php e 
http://www.oracle.com/technetwork/issue-archive/2011/11-sep/o51asktom-453438.html
 para exemplos), mas o IDEAL é fugir desses custos...

Isso posto, se vc REALMENTE, ABSOLUTAMENTE, TEM QUE chamar a rotina PL/SQL de 
dentro do SQL,  pra gente poder responder melhor plz nos diga :

 a) a função está sendo usada só na cláusula de SELECT da query, ** OU ** está 
sendo referenciada no WHERE, no ORDER BY e/ou em outros pontos ?? Se não é só 
no SELECT, vc tem *** ENORMES *** chances da função estar causando mudanças 
negativas no Plano de Execução : por exemplo, a função está alterando uma 
coluna indexada, ou - já que OBVIAMENTE o CBO não consegue saber qual valor a 
função retorna, então não tem como usar nem Histogramas nem as estatísticas de 
que ele dispõe - o CBO não consegue Otimizar o plano, por aí...
 
 b) a função que vc está chamando tem a ver com as built-ins de XML ? Se sim, 
CONFIRA as correções presents nos patchsets 11.2.0.3 e 11.2.0.4, pois bugs como 
o 9919654 tipicamente tendem a se fazxer presentes com funções XML, que por 
natureza são complexas (tendem a fazer montes de SUBSTR/INSTR) e recursivas
 
 c) a tal função faz processamento ** pesado ** de strings, tipo expressões 
regulares ?? Se sim, cfrme 
https://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:6071446400346871004#608340346455747
 alerta, vc VAI SIM encontrar um overhead ao utilizar as built-ins de regex ao 
invés das funções primitivas de string do PL/SQL
 
 ==> Sobre debug : o primeiro e óbvio passo é testar a tal query ** SEM ** a 
função, depois testar com uma função dummy (ie, que só faça um comando simples, 
tipo um NOP, ou uma adição se o valor for numérico, ou seja, alguma coisa 
mínima, só pra testar) 
   SE os testes acima retornaram o mesmo plano de execução mas consumiram muito 
menos CPU, vc já Provou que é a rotina em si que não está Otimizada ao máximo, 
é partir pro TUNING dela, ou então (o Melhor, como dito no início) substituir a 
rotina PL/SQL por built-ins SQL...
   
[]s

   Chiappa

[oracle_br] Re: Performance pacotes dbms ????

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

Bom, primeiro observo que o seu títyulo foi Bem ruinzinho : performance pacote 
dbms parece indicar que é um problerma de performance na execução de algum 
pacote DBMS, o que não é o caso...
 Mas de qquer maneira : primeiro coisa, ** ao invés ** de sair disparando feito 
um louco pra todo o lado, coletando estatísticas, alterando armazenamento 
físico e n outras coisas de uma vez só como vc fez, o que se recomenda num 
processo de tuning é primeiro tentar IDENTIFICAR o problema (via trace, 
debug/instrumentação, detecção de alteração nos planos de execução, consulta de 
WAITS - de repente não é NADA disso o seu problema, pode ser talvez wait for 
locks, sei lá), e só DEPOIS de identificado , aí sim tentar fazer UMA COISA por 
vez, e sempre comprovando que essa uma única coisa foi efetiva (obtendo os 
planos, as métricas de I/O, o que for) de ANTES e de DEPOIS da alteração... Sim 
??? Senão acontece que nem no seu caso, será que foi a coleta de estatísticas 
OU foi o SHRINK que tinha melhorado a performance ??? Vc Não segui a 
metodologia, então QUEM SABE ? Sacou ???

 Segundo ponto : supondo que mudança de planos de execução/estatísticas ruins 
fossem o problema (a gente não sabe, mas supondo que) absolutamente não entendi 
o que vc fez com as estatísticas, pois SE vc já tinha coletado as estatísticas 
das tabelas via DBMS_STATS.GATHER_TABLE_STATS, por que RAIOS vc ainda por cima 
executou um DBMS_STATS.GATHER_SCHEMA_STATS  Fez 2x a mesma coisa ??? Não 
entendi

 Adicionalmente, SE vc obtiver alguma prova de que é o armazenamento físico o 
culpado :

  a. analise e descubra a EXATA e REAL causa do problema : ao invés de usar a 
palavra guarda-chuva FRAGMENTAÇÃO, que engloba tudo mas não diz nada, plz 
Descubra se o problema é por causa de extent size enormemente grande e vazio, 
espaço na HWM não sendo reaproveitado por causa de INSERT /*+ APPEND */, 
white-space (ie, espaço não reaproveitado no momento) dentro do bloco (seja por 
cláusulas de storage inapropriadas ou o que for) , enfim, o REAL aí

  b. saiba que SHRINK serve para ** temporariamente **, neste exato momento 
apenas, desalocar armazenamento que está alocado para um segmento : ele *** NÃO 
 garante que poucas horas depois da sua execução já houveram mais cargas de 
dados que (por uma das causas que vc detectou em a), acima) fizeram o sgmento 
ficar com um armazenamento "ruim", yep ??

  ==> Então a minha Resposta é essa : plz vc (ou alguém Habilitado, se vc não 
tiver o conhecimento para tal) deve Analisar, levantar exatamente os números da 
"lentidão", Descobrir exatamente qual a Causa para aí sim poder Atuar sem ser 
via chute, via DPTLEVSACF 
(disparar-para-todo-lado-e-ver-se-alguma-coisa-funciona )...

  []s

   Chiappa

Re: [oracle_br] Re: Performance

[Andre Santos andre.psantos...@gmail.com [oracle_br]]

Gustavo

Para investigar o que ocorre na aplicação, num determinado processo, gosto
de usar "trace/tkprof" mesmo.
O Chiappa indicou duas referências muito boas!
Só enfatizo que, ao gerar o trace, é muito útil colocar as opções de
WAITS=true.
Desse modo você terá detalhes dos eventos de espera (tempos) dos processo.

[ ]'s

André Santos


Em 15 de outubro de 2014 11:20, jlchia...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
>   Tudo jóia ? Então, o certo seria a Aplicação dispor de INSTRUMENTAÇÃO,
> isto é, de um modo de debug que vc ativaria e aí obteria um report de cada
> passo que está sendo executado e quanto está demorando, JUSTAMENTE para vc
> poder identificar aonde que está a demora Não preciso dizer, porém, que
> em 99,999% das Aplicações (em nome da "agilidade", dizem alguns) são feitas
> é nas coxas mesmo, de qquer jeito e sem planejamento, visando mesmo é o
> menor custo e o mais curto prazo de entrega, assim as primeiras coisas
> cortadas são justamente as impreteríveis , ie, a DOCUMENTAÇÃO e a
> INSTRUMENTAÇÃO...
>  Não havendo instrumentação nativa : caso a aplicação seja desenvolvida
> in-house e vc tenha os fontes e a possibilidade de a alterar, a
> Recomendação seria vc implementar uma instrumentação, nem que seja algo
> muito simples, tipo :
>
> imprimir mensagem ('Vou fazer o select das NFs em' || data e hora);
> SELECT .
> imprimir mensagem ('Feito SELECT em ' || data e hora);
> ...
>
> negócio bem básico e rastaquera, mas que já te daria a info...
>
>  CASO não seja possível implementar nada de nada, aí o recurso seria vc
> ativar o TRACE no banco de dados : isso vai te gerar um arquivo de trace
> com a relação completa  dos comandos executados e o tempo gasto (bem como o
> Plano de Execução dos SQLs), aí com isso vc saberá se o culpado é algum SQL
> ruim, se é latch (ie, muitas pessoas acessando as mesmas tabelas ao mesmo
> tempo tendo que esperarem pela liberação do latch de acesso), espera por
> LOCK (já vi sistemas doidos aonde assim que o usuário inicia uma sessão de
> uso no sistema o aplicativo insere/updateia registros em tabelas de
> controles, aí se por qquer motivo múltiplas pessoas iniciarem ao mesmo
> tempo há espera por lock), se é a rede que está sobrecarregada ao
> transmitir os dados para o cliente (às vezes o banco em si está perfeito
> mas a rede é que tá enfrentando pico de uso - vc ** NÂO ** pode dizer de
> bate-pronto que a lentidão está sendo causada por seu banco), ou o que
> for...  Dá um look na Documentação, e para mais refs vc pode usar
> http://www.oracle-base.com/articles/misc/sql-trace-10046-trcsess-and-tkprof.php
> para trace de sessão dedicada, e
> http://www.dbspecialists.com/files/presentations/tracing_ind_sessions.html
> para os casos mais difíceis aonde a conexão ao banco não seja direta,
> havendo algum tipo de pool de conexões em que uma sessão no banco atende N
> solicitações diferentes de usuários diferentes...
>
>   []s
>
> Chiappa
>  
>

[oracle_br] Re: Performance

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

  Tudo jóia ? Então, o certo seria a Aplicação dispor de INSTRUMENTAÇÃO, isto 
é, de um modo de debug que vc ativaria e aí obteria um report de cada passo que 
está sendo executado e quanto está demorando, JUSTAMENTE para vc poder 
identificar aonde que está a demora Não preciso dizer, porém, que em 
99,999% das Aplicações (em nome da "agilidade", dizem alguns) são feitas é nas 
coxas mesmo, de qquer jeito e sem planejamento, visando mesmo é o menor custo e 
o mais curto prazo de entrega, assim as primeiras coisas cortadas são 
justamente as impreteríveis , ie, a DOCUMENTAÇÃO e a INSTRUMENTAÇÃO...
 Não havendo instrumentação nativa : caso a aplicação seja desenvolvida 
in-house e vc tenha os fontes e a possibilidade de a alterar, a Recomendação 
seria vc implementar uma instrumentação, nem que seja algo muito simples, tipo :

imprimir mensagem ('Vou fazer o select das NFs em' || data e hora);
SELECT .
imprimir mensagem ('Feito SELECT em ' || data e hora);
...

negócio bem básico e rastaquera, mas que já te daria a info...

 CASO não seja possível implementar nada de nada, aí o recurso seria vc ativar 
o TRACE no banco de dados : isso vai te gerar um arquivo de trace com a relação 
completa  dos comandos executados e o tempo gasto (bem como o Plano de Execução 
dos SQLs), aí com isso vc saberá se o culpado é algum SQL ruim, se é latch (ie, 
muitas pessoas acessando as mesmas tabelas ao mesmo tempo tendo que esperarem 
pela liberação do latch de acesso), espera por LOCK (já vi sistemas doidos 
aonde assim que o usuário inicia uma sessão de uso no sistema o aplicativo 
insere/updateia registros em tabelas de controles, aí se por qquer motivo 
múltiplas pessoas iniciarem ao mesmo tempo há espera por lock), se é a rede que 
está sobrecarregada ao transmitir os dados para o cliente (às vezes o banco em 
si está perfeito mas a rede é que tá enfrentando pico de uso - vc ** NÂO ** 
pode dizer de bate-pronto que a lentidão está sendo causada por seu banco), ou 
o que for...  Dá um look na Documentação, e para mais refs vc pode usar 
http://www.oracle-base.com/articles/misc/sql-trace-10046-trcsess-and-tkprof.php 
para trace de sessão dedicada, e 
http://www.dbspecialists.com/files/presentations/tracing_ind_sessions.html para 
os casos mais difíceis aonde a conexão ao banco não seja direta, havendo algum 
tipo de pool de conexões em que uma sessão no banco atende N solicitações 
diferentes de usuários diferentes...

  []s

Chiappa

Re: [oracle_br] Re: Performance da maquina irá depender do tamanho do datafile ?

[Rafael Stoever]

Obrigado Milton e Chiappa, ótimas explicações e bem compreendido !

Att
Rafael Stoever

abs
Rafael Stoever / @rstoever
DBA Oracle OCP/OCE/OPN Specialist 10g/11g
skype: rstoever



Em 26 de agosto de 2013 17:44, J. Laurindo Chiappa
escreveu:

> **
>
>
> E é claro , isso que eu disse da comparação de performance entre um
> arquivo gigante de tamanho X gigabytes ou N arquivinhos de tamanho menor
> que somem X gigabytes no total ser indiferente só vale ** SE ** estamos
> comparando ambos os casos sendo servidos pelo mesmo exato hardware de I/O -
> é CLARO que se vc tiver um arquivo A residente num único disco versus os n
> arquivinhos espalhados em vários discos, aí É CLARO que daria diferença
>
> []s
>
> Chiappa
>
> --- Em oracle_br@yahoogrupos.com.br, "J. Laurindo Chiappa" 
> escreveu
>
> >
> > Tudo jóia, Rafael ?? Então, na verdade NÂO É o fato de vc abrir o
> arquivão grandão que degrada, MAS SIM quando vc abre E LÊ / CARREGA PARA A
> MEMÓRIA o arquivo, sim ??? Abrir apenas absolutamente ** Não ** gasta
> recursos apreciáveis, é só um file handle que foi usado, não se consumiu
> RAM, CPU, I/O ou rede quase nenhum... Faça uma experiência : crie um
> arquivo gigantesco na sua máquina de testes, meça a performance da máquina
> com os utilitários de So que vc tenha, depois faça um programinha numa
> linguagem de programação que domine e permita abrir arquivos (pode ser
> Java, C, .NET, VB, a que quiser e conhecer) que abra esse arquivo (SEM o
> ler, apenas o abra) e fique em pausa , aí noutra janela meça de novo a
> performance da máquina, vc vai ver que está praticamente IDÊNTICA...
> > É justamente esse o ponto aonde a sua analogia cai pela base , é que o
> RDBMS Oracle  nunca  lê um datafile inteiro, do começo ao fim,
> okdoc ? Por que ?? Vamos ver...
> >
> > ==> Primeiramente, ESSA é a principal diferença do RDBMS para o editor
> de texto : enquanto o editor de texto é Obrigado a ler o arquivo inteiro
> (ou uma porção considerável dele), o RDBMS é um pouquinho mais esperto :
> ele divide o datafile em pequenos pedaços de mesmo tamanho (o chamado
> BLOCO), e em cada linha de cada tabela ele registra em qual bloco a linha
> está armazenada - assim, se ele precisar recuperar a linha X que está,
> digamos, no bloco 5000 do datafile, ele *** NÂO VAI ** ler do bloco 1 até o
> 5000 - como ele SABE o tamanho do bloco (digamos que seja bloco de 8kb), se
> a informação está no bloco 5000 ele faz uma continha de 5000 * 8 kb =
> 4096, aí ele pede para ler apenas essa posição do arquivo, yep ??? Esse
> tipo de operação, posicionando o leitor numa dada posição do arquivo e
> assim evitando varredura a partir do início se chama FILE SEEK
> (frequentemente abreviada por FSEEK, ou similares), e existe em
> praticamente todas as linguagens de programação modernas, mas
> principalmente existe na linguagem C, na qual o RDBMS Oracle foi escrito...
> >
> > E quando não sabemos qual linha contém a informação desejada (ou então
> queremos agrupar/processar MÚLTIPLAS linhas da tabela), e portanto não
> sabemos quais blocos são necessários, o que livra o RDBMS de ler o arquivo
> todo, bloco a bloco ??? O seguinte conceito : quando o RDBMS precisa de
> espaço para gravar dados, ele não aloca um só bloco, mas sim TODO um
> conjunto de blocos (de tamanho variável) chamado EXTENT, e o bloco de
> início de cada extent fica armazenado no database - assim, para a tabela X
> o RDBMS *** SABE *** que o primeiro extent começo no bloco tal, PORTANTO
> obviamente os n blocos anteriores Não precisam ser lidos, a partir do
> incício do arquvi, sim  Esquece isso, esse negócio de ler arquivo do
> início é coisa para editor de texto, não para RDBMS 
> >
> > Jóia ?? OBVIAMENTE por questão de didática eu falei aqui de modo geral,
> há DIVERSOS detalhes importantes que vc VAi captar no manual de Concepts do
> database, mas creio que o que eu falei já dá pra ter uma noção de porque o
> tamanho do arquivo em si é irrelevante para a performance... Até se vc
> pensar friamente um pouco a respeito, outras posições equivocadas sobre
> performance (como por exemplo separar tabelas x índices em datafiles
> diferentes) com os conceitos que expus caem por terra : SE o RDBMS ** nunca
> ** lê um datafile do início ao fim, sempre "pulando" para o bloco desejado
> OU no mínimo para o bloco aonde o extent se inicia, que diferença para a
> performance pode haver se os índices estão no mesmo arquivo/datafile que os
> dados (num único enorme arquivão gigante) ??? Bem pouca, Né ?
> >
> > []s
> >
> > Chiappa
> >
> > OBS : só para constar, o tamanho do arquivo pode ser ** crucial ** por
> questões Administrativas, não para performance - por exemplo, em caso de
> crash, quanto maior o arquivo mais tempo ele leva para ser voltado do
> backup, né ?? Ou ainda , os eventuais limites : de repente o teu hardware,
> ou qquer componente do teu software relaionado a discos (ou mesmo o teu SO,
> porque não ?) TEm um limite de X gigabytes para um único arquivo

[oracle_br] Re: Performance da maquina irá depender do tamanho do datafile ?

[J. Laurindo Chiappa]

   E é claro , isso que eu disse da comparação de performance entre um arquivo 
gigante de tamanho X gigabytes ou N arquivinhos de tamanho menor que somem X 
gigabytes no total ser indiferente só vale ** SE ** estamos comparando ambos os 
casos sendo servidos pelo mesmo exato hardware de I/O - é CLARO que se vc tiver 
um arquivo A residente num único disco versus os n arquivinhos espalhados em 
vários discos, aí É CLARO que daria diferença

  []s

   Chiappa

--- Em oracle_br@yahoogrupos.com.br, "J. Laurindo Chiappa"  
escreveu
>
>   Tudo jóia, Rafael ?? Então, na verdade NÂO É o fato de vc abrir o arquivão 
> grandão que degrada, MAS SIM quando vc abre E LÊ / CARREGA PARA A MEMÓRIA o 
> arquivo, sim ??? Abrir apenas absolutamente ** Não ** gasta recursos 
> apreciáveis, é só um file handle que foi usado, não se consumiu RAM, CPU, I/O 
> ou rede quase nenhum... Faça uma experiência : crie um arquivo gigantesco na 
> sua máquina de testes, meça a performance da máquina com os utilitários de So 
> que vc tenha, depois faça um programinha numa linguagem de programação que 
> domine e permita abrir arquivos (pode ser Java, C, .NET, VB, a que quiser e 
> conhecer) que abra esse arquivo (SEM o ler, apenas o abra) e fique em pausa , 
> aí noutra janela meça de novo a performance da máquina, vc vai ver que está 
> praticamente IDÊNTICA...
>   É justamente esse o ponto aonde a sua analogia cai pela base , é que o 
> RDBMS Oracle  nunca  lê um datafile inteiro, do começo ao fim, okdoc 
> ? Por que ?? Vamos ver... 
> 
>  ==> Primeiramente, ESSA é a principal diferença do RDBMS para o editor de 
> texto : enquanto o editor de texto é Obrigado a ler o arquivo inteiro (ou uma 
> porção considerável dele), o RDBMS é um pouquinho mais esperto : ele divide o 
> datafile em pequenos pedaços de mesmo tamanho (o chamado BLOCO), e em cada 
> linha de cada tabela ele registra em qual bloco a linha está armazenada - 
> assim, se ele precisar recuperar a linha X que está, digamos, no bloco 5000 
> do datafile, ele *** NÂO VAI ** ler do bloco 1 até o 5000 - como ele SABE o 
> tamanho do bloco (digamos que seja bloco de 8kb), se a informação está no 
> bloco 5000 ele faz uma continha de 5000 * 8 kb = 4096, aí ele pede para 
> ler apenas essa posição do arquivo, yep ??? Esse tipo de operação, 
> posicionando o leitor numa dada posição do arquivo e assim evitando varredura 
> a partir do início se chama FILE SEEK (frequentemente abreviada por FSEEK, ou 
> similares), e existe em praticamente todas as linguagens de programação 
> modernas, mas principalmente existe na linguagem C, na qual o RDBMS Oracle 
> foi escrito... 
> 
>   E quando não sabemos qual linha contém a informação desejada (ou então 
> queremos agrupar/processar MÚLTIPLAS linhas da tabela), e portanto não 
> sabemos quais blocos são necessários, o que livra o RDBMS de ler o arquivo 
> todo, bloco a bloco ??? O seguinte conceito : quando o RDBMS precisa de 
> espaço para gravar dados, ele não aloca um só bloco, mas sim TODO um conjunto 
> de blocos (de tamanho variável) chamado EXTENT, e o bloco de início de cada 
> extent fica armazenado no database - assim, para a tabela X o RDBMS  *** SABE 
> *** que o primeiro extent começo no bloco tal, PORTANTO obviamente os n 
> blocos anteriores Não precisam ser lidos, a partir do incício do arquvi, sim 
>  Esquece isso, esse negócio de ler arquivo do início é coisa para editor 
> de texto, não para RDBMS 
> 
>   Jóia ??  OBVIAMENTE por questão de didática eu falei aqui de modo geral, há 
> DIVERSOS detalhes importantes que vc VAi captar no manual de Concepts do 
> database, mas creio que o que eu falei já dá pra ter uma noção de porque o 
> tamanho do arquivo em si é irrelevante para a performance... Até se vc pensar 
> friamente um pouco a respeito, outras posições equivocadas sobre performance 
> (como por exemplo separar tabelas x índices em datafiles diferentes) com os 
> conceitos que expus caem por terra : SE o RDBMS ** nunca ** lê um datafile do 
> início ao fim, sempre "pulando" para o bloco desejado OU no mínimo para o 
> bloco aonde o extent se inicia, que diferença para a performance pode haver 
> se os índices estão no mesmo arquivo/datafile que os dados (num único enorme 
> arquivão gigante) ??? Bem pouca, Né ?
> 
>[]s
> 
> Chiappa
> 
>  OBS : só para constar, o tamanho do arquivo pode ser ** crucial ** por 
> questões Administrativas, não para performance - por exemplo, em caso de 
> crash, quanto maior o arquivo mais tempo ele leva para ser voltado do backup, 
> né ?? Ou ainda , os eventuais limites  : de repente o teu hardware, ou qquer 
> componente do teu software relaionado a discos (ou mesmo o teu SO, porque não 
> ?) TEm um limite de X gigabytes para um único arquivo, de repente vc pode 
> acabar com corrupção/erros se deixar o datafile chegar nesse ponto... 
>Coisas assim, ADMINISTRATIVAS,  são aonde o tamanho do datafile importa...
> 
> --- Em oracle_br@yahoogrupos.com.

[oracle_br] Re: Performance da maquina irá depender do tamanho do datafile ?

[J. Laurindo Chiappa]

  Tudo jóia, Rafael ?? Então, na verdade NÂO É o fato de vc abrir o arquivão 
grandão que degrada, MAS SIM quando vc abre E LÊ / CARREGA PARA A MEMÓRIA o 
arquivo, sim ??? Abrir apenas absolutamente ** Não ** gasta recursos 
apreciáveis, é só um file handle que foi usado, não se consumiu RAM, CPU, I/O 
ou rede quase nenhum... Faça uma experiência : crie um arquivo gigantesco na 
sua máquina de testes, meça a performance da máquina com os utilitários de So 
que vc tenha, depois faça um programinha numa linguagem de programação que 
domine e permita abrir arquivos (pode ser Java, C, .NET, VB, a que quiser e 
conhecer) que abra esse arquivo (SEM o ler, apenas o abra) e fique em pausa , 
aí noutra janela meça de novo a performance da máquina, vc vai ver que está 
praticamente IDÊNTICA...
  É justamente esse o ponto aonde a sua analogia cai pela base , é que o RDBMS 
Oracle  nunca  lê um datafile inteiro, do começo ao fim, okdoc ? Por 
que ?? Vamos ver... 

 ==> Primeiramente, ESSA é a principal diferença do RDBMS para o editor de 
texto : enquanto o editor de texto é Obrigado a ler o arquivo inteiro (ou uma 
porção considerável dele), o RDBMS é um pouquinho mais esperto : ele divide o 
datafile em pequenos pedaços de mesmo tamanho (o chamado BLOCO), e em cada 
linha de cada tabela ele registra em qual bloco a linha está armazenada - 
assim, se ele precisar recuperar a linha X que está, digamos, no bloco 5000 do 
datafile, ele *** NÂO VAI ** ler do bloco 1 até o 5000 - como ele SABE o 
tamanho do bloco (digamos que seja bloco de 8kb), se a informação está no bloco 
5000 ele faz uma continha de 5000 * 8 kb = 4096, aí ele pede para ler 
apenas essa posição do arquivo, yep ??? Esse tipo de operação, posicionando o 
leitor numa dada posição do arquivo e assim evitando varredura a partir do 
início se chama FILE SEEK (frequentemente abreviada por FSEEK, ou similares), e 
existe em praticamente todas as linguagens de programação modernas, mas 
principalmente existe na linguagem C, na qual o RDBMS Oracle foi escrito... 

  E quando não sabemos qual linha contém a informação desejada (ou então 
queremos agrupar/processar MÚLTIPLAS linhas da tabela), e portanto não sabemos 
quais blocos são necessários, o que livra o RDBMS de ler o arquivo todo, bloco 
a bloco ??? O seguinte conceito : quando o RDBMS precisa de espaço para gravar 
dados, ele não aloca um só bloco, mas sim TODO um conjunto de blocos (de 
tamanho variável) chamado EXTENT, e o bloco de início de cada extent fica 
armazenado no database - assim, para a tabela X o RDBMS  *** SABE *** que o 
primeiro extent começo no bloco tal, PORTANTO obviamente os n blocos anteriores 
Não precisam ser lidos, a partir do incício do arquvi, sim  Esquece isso, 
esse negócio de ler arquivo do início é coisa para editor de texto, não para 
RDBMS 

  Jóia ??  OBVIAMENTE por questão de didática eu falei aqui de modo geral, há 
DIVERSOS detalhes importantes que vc VAi captar no manual de Concepts do 
database, mas creio que o que eu falei já dá pra ter uma noção de porque o 
tamanho do arquivo em si é irrelevante para a performance... Até se vc pensar 
friamente um pouco a respeito, outras posições equivocadas sobre performance 
(como por exemplo separar tabelas x índices em datafiles diferentes) com os 
conceitos que expus caem por terra : SE o RDBMS ** nunca ** lê um datafile do 
início ao fim, sempre "pulando" para o bloco desejado OU no mínimo para o bloco 
aonde o extent se inicia, que diferença para a performance pode haver se os 
índices estão no mesmo arquivo/datafile que os dados (num único enorme arquivão 
gigante) ??? Bem pouca, Né ?

   []s

Chiappa

 OBS : só para constar, o tamanho do arquivo pode ser ** crucial ** por 
questões Administrativas, não para performance - por exemplo, em caso de crash, 
quanto maior o arquivo mais tempo ele leva para ser voltado do backup, né ?? Ou 
ainda , os eventuais limites  : de repente o teu hardware, ou qquer componente 
do teu software relaionado a discos (ou mesmo o teu SO, porque não ?) TEm um 
limite de X gigabytes para um único arquivo, de repente vc pode acabar com 
corrupção/erros se deixar o datafile chegar nesse ponto... 
   Coisas assim, ADMINISTRATIVAS,  são aonde o tamanho do datafile importa...

--- Em oracle_br@yahoogrupos.com.br, Rafael Stoever  escreveu
>
> Boa tarde a todos,
> 
>  Irei fazer uma analogia sobre um arquivo texto de 10GB e um datafile
> de 10GB e um de 32GB.
>  Se efetuarmos a abertura do arquivo de 10GB no sistema operacional
> teremos um problema grande de memoria, podendo ate travar o sistema
> operacional.
> 
> Agora a questão são os datafiles grandes 32GB quando abertos pelo
> Oracle para efetuar uma busca muito massiva de dados, ou mesmo somente
> abrir-los, ele poderá ocasionar um problema de performance da mesma forma
> que o editor de texto ?
> Pois ao checar os arquivos abertos pelo Oracle ele fica com o alguns
> datafiles abertos.
> 
> Pergunta: O tamanh

Re: [oracle_br] Re: Performance índice PK String x Number

[Daniel Mello]

Muito obrigado Chiappa, realmente pelo que pesquisei se houver diferença será 
irrisória. Apesar de todos os "prós" que citou que há sobre o type number, pra 
esse caso não teremos pra onde correr. :)

Agradeço mais uma vez.
 

Daniel





 De: J. Laurindo Chiappa 
Para: oracle_br@yahoogrupos.com.br 
Enviadas: Terça-feira, 16 de Abril de 2013 17:01
Assunto: [oracle_br] Re: Performance índice PK String x Number
 

  No caso específico do RDBMS Oracle (que é aquele sobre o qual posso falar 
melhor), como http://www.ixora.com.au/notes/number_representation.htm e como o 
manual de reference nos dizem,  NUMBERs são gravados internamente em formato 
exponencial, então realmente em alguns casos podem consumir alguns bytes a 
menos,  o que em casos Extremos pode talvez chegar a fazer alguma diferença 
palpável em termos tamanho da chave e tamanho geral do índice e assim levar a 
alguma diferença de performance, mas via de regra se espera que essa diff seja 
** MUITO PEQUENA **, okdoc ? Não é o fato de vc poupar um ou dois bytes por 
registro que vai fazer a sua performance "voar", ser Enormemente diferente, sim 
?? 
  As razões pelas quais eu  sempre Recomendo dar preferência a chaves numéricas 
se elas existem são muito mais de ordem prática, ie :
  
   - não há como se armazenar espaços em brancos, zeros á esquerda, 
maiúsculas/minúsculas, etc, em colunas NUMBERs, então TUDO que se refere à 
pesquisas insensitive e/ou transformação nos argumentos de pesquisa basicamente 
não é necessário quando a chave é numérica... Idem rotinas tipo SOUNDEX para 
de-duplicação de chaves parecidas (tipo LUIS, LUIZ, etc) , nada disso existe 
para NUMBERs 
  
   - NUMBERs são imunes a detalhes/settings de NLS, como 
acentuação/codificação, PRINCIPALMENTE se a programação está sendo feita em 
PL/SQL, aonde vc representa um valor numérico com os dígitos e um ponto decimal 
e acabou
  
   - colunas NUMBER já possuem validação de dados automática, que não permite 
entrar nenhum caracter não-numérico, ao contrário de uma coluna string, aonde 
vc TERÁ que criar/manter constraints de CHECK para manter o domínio dos dados, 
se a chave tiver regra de formação
  
    - as chaves numéricas podem ser FACILMENTE auto-alimentadas via SEQUENCE, 
enquanto as strings demanda alguma conversão em cima da sequence
    
    e coisas do tipo...
    
    []s
    
      Chiappa

--- Em oracle_br@yahoogrupos.com.br, Daniel Mello  escreveu
>
> Boa tarde.
> 
>      Estou pesquisando maiores informações sobre a performance em se utilizar 
> os tipos Varchar2 e Number para criação de índices, como o Oracle (e outros 
> bancos) se comporta com uma e com outra. Tenho um caso específico onde 
> teremos que implementar uma PK de uma das principais tabelas do sistema em 
> varchar2, meu receio é com o passar do tempo e crescimento de todas as 
> tabelas envolvidas, meu desempenho seja prejudicado por conta disso. Alguém 
> já teve experiencia parecida?
> 
> Tenho bancos Oracle (11g), SQL Server (2012) e MySql(5.6.x) envolvidos nesse 
> item.
> 
> Obrigado.
> Daniel.
> 
> [As partes desta mensagem que não continham texto foram removidas]
>






--
>Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de inteira 
>responsabilidade de seus remetentes.
Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ 
--
>Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package » Procedure » 
>Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE: 
>http://www.oraclebr.com.br/  

 Links do Yahoo! Grupos

[As partes desta mensagem que não continham texto foram removidas]

[oracle_br] Re: Performance índice PK String x Number

[J. Laurindo Chiappa]

  No caso específico do RDBMS Oracle (que é aquele sobre o qual posso falar 
melhor), como http://www.ixora.com.au/notes/number_representation.htm e como o 
manual de reference nos dizem,  NUMBERs são gravados internamente em formato 
exponencial, então realmente em alguns casos podem consumir alguns bytes a 
menos,  o que em casos Extremos pode talvez chegar a fazer alguma diferença 
palpável em termos tamanho da chave e tamanho geral do índice e assim levar a 
alguma diferença de performance, mas via de regra se espera que essa diff seja 
** MUITO PEQUENA **, okdoc ? Não é o fato de vc poupar um ou dois bytes por 
registro que vai fazer a sua performance "voar", ser Enormemente diferente, sim 
?? 
  As razões pelas quais eu  sempre Recomendo dar preferência a chaves numéricas 
se elas existem são muito mais de ordem prática, ie :
  
   - não há como se armazenar espaços em brancos, zeros á esquerda, 
maiúsculas/minúsculas, etc, em colunas NUMBERs, então TUDO que se refere à 
pesquisas insensitive e/ou transformação nos argumentos de pesquisa basicamente 
não é necessário quando a chave é numérica... Idem rotinas tipo SOUNDEX para 
de-duplicação de chaves parecidas (tipo LUIS, LUIZ, etc) , nada disso existe 
para NUMBERs 
   
   - NUMBERs são imunes a detalhes/settings de NLS, como 
acentuação/codificação, PRINCIPALMENTE se a programação está sendo feita em 
PL/SQL, aonde vc representa um valor numérico com os dígitos e um ponto decimal 
e acabou
   
   - colunas NUMBER já possuem validação de dados automática, que não permite 
entrar nenhum caracter não-numérico, ao contrário de uma coluna string, aonde 
vc TERÁ que criar/manter constraints de CHECK para manter o domínio dos dados, 
se a chave tiver regra de formação
   
- as chaves numéricas podem ser FACILMENTE auto-alimentadas via SEQUENCE, 
enquanto as strings demanda alguma conversão em cima da sequence

e coisas do tipo...

[]s

  Chiappa

--- Em oracle_br@yahoogrupos.com.br, Daniel Mello  escreveu
>
> Boa tarde.
> 
>      Estou pesquisando maiores informações sobre a performance em se utilizar 
> os tipos Varchar2 e Number para criação de índices, como o Oracle (e outros 
> bancos) se comporta com uma e com outra. Tenho um caso específico onde 
> teremos que implementar uma PK de uma das principais tabelas do sistema em 
> varchar2, meu receio é com o passar do tempo e crescimento de todas as 
> tabelas envolvidas, meu desempenho seja prejudicado por conta disso. Alguém 
> já teve experiencia parecida?
> 
> Tenho bancos Oracle (11g), SQL Server (2012) e MySql(5.6.x) envolvidos nesse 
> item.
> 
> Obrigado.
> Daniel.
> 
> [As partes desta mensagem que não continham texto foram removidas]
>

[oracle_br] Re: Performance RMAN

[J. Laurindo Chiappa]

  Tudo joinha, Neto ? Vou fazer alguns comentários :
  
  - sobre a sua situação, seguinte : pelo jeito o pessoal lá do cliente não tem 
lá muita expertise, então mesmo vc não tendo sido contratado especificamente 
para melhoria do ambiente atual, penso que vale MUITO a pena vc Recomendar a 
melhor prática aonde vc a ver... Claro, vc não vai poder Implementar mas 
cumpriu a sua parte, explorou o teu conhecimento técnico, tentou transferir um 
pouquinho de tecnologia para o cliente, okdoc ...
Assim, sobre o AC por exemplo, não basta só indicar a Documentação : no 
link mesmo que te passei há alguns números, e na Oracle procurando no technet 
vc acha diversos cases de utilização, vc Tem que passar também esse material 
para o Cliente (e Não apenas para os técnicos, mas Também para o pessoal 
decisório) e anexar junto com a sua Recomendação por escrito ... NÂO ESQUEÇA de 
deixar bem CLARO para eles o quanto vai ser poupado de STORAGE com a 
compactação, sim ? Esse pessoal é CUSTo versus BENEFÍCIO, números são o que 
eles entendem...

   - sobre a performance do backup, a idéia de usar ao mesmo tempo, em 
paralelo, dois (ou mesmo três) nós é principalmente para aumentar o poder de 
CPU disponível para o backup, além de poder ter algum Paralelismo na execução - 
isso no backup FULL, claro, que imagino é o mais demorado, né ? Inclusive, já 
que ele roda de madrugada no domingo, certamente ter múltiplos nós trabalhando 
no backup imagino que não deve causar transtornos, deve ser uma janela meio 
morta - mas NEM preciso dizer, isso tem que ser Testado ...
E sim, quando me perguntam como fazer um tuning, como melhorar a 
performance de um processamento qualquer, a minha Resposta ** sempre ** é : vc 
está fazendo algo inútil, repetitivo, que pode ser descartado ? Se sim, DEIXE 
de o fazer e pronto, lucro instantâneo SEM investimento - é + ou - que nem 
aquela história do sujeito que vai ao médico e diz "Dr, dói muito quando eu 
dobro o braço assim e assim", a resposta do médico só pode ser "Ok, deixe de 
dobrar o braço assim e assim" ... 
 Então, sabendo disso e sabendo da (tipicamente)  baixíssima taxa de 
atualização de documentos governamentais, não backupear a cada vez dados que vc 
sabe que não mudou é o mínimo - isso pode ser feito colocando as tablespaces 
referentes em read-only, pode se ter uma Lista de Exclusão de datafiles, não 
importa muito o "como", desde que o objetivo de só backupear o que precisa seja 
alcançado. LÓGICO, esse tipo de política torna AINDA MAIS PREMENTE o ** teste 
de restore ** frequente e real - não basta vc ter anotado que a informação X 
que não mudou foi backupeada as 3 vezes de praxe em 3 mídias diferentes, antes 
de pode as excluir do backup vc ABSOLUTAMENTE Precisa que tenham sido feitos 
testes de RESTORE, só assim vc tem CONFIABILIDADE... Idem para o RODÍZIO DE 
MÍDIA : mídias sofrem deterioração com o tempo (é em certa medida Inevitável, 
sejam mídias de tecnologia óptica ou magnética), então de tanto em tanto vc TEM 
passar esse backup para uma nova mídia, RETESTAR e liberar a mídia anterior...
   
   - sobre securefiles, sim : não se entende a utilização de LOBs em grandes 
volumes no 11gr2 sem eles... Fontes como 
http://www.oracle.com/technetwork/database/perf-087187.html alegam melhorias de 
até 10x na ingestão de dados - nem sempre na prática se chega perto disso,é 
Claro,  mas que em tese há vantagens para eles sobre os tradicionais basic 
files, é inegável. Bata FORTE nisso, insista, faça uma POC se preciso...
   
 []s
 
   Chiappa

--- Em oracle_br@yahoogrupos.com.br, "netodba"  escreveu
>
> Fala Chiappa bom dia, vlw pela resposta.
> 
> Deixa eu explicar a situação. 
> Não sou DBA fixo dessa empresa, a empresa que eu trabalho foi contratada pra 
> fazer a criação do novo RAC e a migração dos dados.
> 
> Bem, eles nao tem a licença do Advanced Comprassion, ja falei das vantagens 
> do AC e já passei a documentação pra eles.
> Os LOB's não são gravados em Securefiles, mas esta na mesma situação do AC, 
> entretanto o securefiles vai ser implementado.
> 
> Nesse RAC existem 2 bases de dados, uma de 2.5Tb e outra de 1Tb, não coloquei 
> mas explicado nos posts anteriores pra nao expor o cliente, mas nao tem 
> problema. Faço o backup rman da base maior no server 1(instancia1) e o bkp da 
> 2° base no server 3(instancia 3).
> 
> Achei super interessante sua abordagem sobre colocar os LOB's em tablespaces 
> dedicadas e coloca-las em READ ONLY, os LOB's já estão em TB separadas, mas 
> nao estao em Read only. Tb irei comentar essa ideia.
> 
> 
> 
> 
> --- Em oracle_br@yahoogrupos.com.br, "J. Laurindo Chiappa"  
> escreveu
> >
> >  Neto, alguns comentários/obs :
> >  
> >  a) se vc está no 11gr2 E usa intensamente LOBs, eles estão gravados em 
> > Securefiles ? Vc tem licenciado a Advanced Compression ?? Se sim, 
> > http://www.oracle.com/us/products/database/db-advanced-compression-option-1525064.pdf
> >  nos alerta que nesse c

[oracle_br] Re: Performance RMAN

[netodba]

Fala Chiappa bom dia, vlw pela resposta.

Deixa eu explicar a situação. 
Não sou DBA fixo dessa empresa, a empresa que eu trabalho foi contratada pra 
fazer a criação do novo RAC e a migração dos dados.

Bem, eles nao tem a licença do Advanced Comprassion, ja falei das vantagens do 
AC e já passei a documentação pra eles.
Os LOB's não são gravados em Securefiles, mas esta na mesma situação do AC, 
entretanto o securefiles vai ser implementado.

Nesse RAC existem 2 bases de dados, uma de 2.5Tb e outra de 1Tb, não coloquei 
mas explicado nos posts anteriores pra nao expor o cliente, mas nao tem 
problema. Faço o backup rman da base maior no server 1(instancia1) e o bkp da 
2° base no server 3(instancia 3).

Achei super interessante sua abordagem sobre colocar os LOB's em tablespaces 
dedicadas e coloca-las em READ ONLY, os LOB's já estão em TB separadas, mas nao 
estao em Read only. Tb irei comentar essa ideia.




--- Em oracle_br@yahoogrupos.com.br, "J. Laurindo Chiappa"  
escreveu
>
>  Neto, alguns comentários/obs :
>  
>  a) se vc está no 11gr2 E usa intensamente LOBs, eles estão gravados em 
> Securefiles ? Vc tem licenciado a Advanced Compression ?? Se sim, 
> http://www.oracle.com/us/products/database/db-advanced-compression-option-1525064.pdf
>  nos alerta que nesse cenário vc não só consegue compressão como 
> DEDUPLICAÇÃO, o que deve encaixar como um luva se os seus LOBS são texto e 
> gravados como CLOB,coisas via de regra bastante compressíveis e com bastante 
> duplicação de strings, tipicamente...
>  
>  b) quando se fala de documentos governamentais (editais, licitações, 
> julgados, atas, etc) , é COMUM que grande parte desses documentos não sofra 
> alteração após a criação : considere SERIAMENTE a possibilidade de os ter em 
> tablespaces dedicadas que vc coloque em READ ONLY e use a opção de SKIP 
> READONLY no seu backup full O que Não Faz Sentido é vc backupear full 
> várias e várias vezes informação que não mudou/não muda, sim ??
>  
>   c) iirc vc está usando só um nó para o backup full - já Considerou ter mais 
> de um como Preferred para o RMAN ?
>   
>   []s
>   
> Chiappa
> 
> --- Em oracle_br@yahoogrupos.com.br, "netodba"  escreveu
> >
> > Vlw pessoal
> > 
> > ja mudei a compressão pra BASIC, aparentemente esta mas rapido mesmo.
> > Vlw
> > 
> > 
> > --- Em oracle_br@yahoogrupos.com.br, Wadson Ramon  escreveu
> > >
> > > Você pode mudar para assim.
> > > CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE
> > > FOR LOAD TRUE ;
> > > 
> > > blz
> > > 
> > > 
> > > Em 16 de fevereiro de 2013 15:48, Vitor Junior escreveu:
> > > 
> > > > Experimentou usar compressed?
> > > > Em 16/02/2013 14:09, "netodba"  escreveu:
> > > >
> > > > > **
> > > > >
> > > > >
> > > > > Fala Pessoal,
> > > > >
> > > > > migrei uma base de dados 2.5 TB 10G pro 11.2.0.3, o meu problema é 
> > > > > que o
> > > > > backup rman ta demorando de mais.
> > > > >
> > > > > Ambiente:
> > > > > S.O: RH 6.3
> > > > > RAC 4 nós Oracle 11.2.0.3 em ASM
> > > > > Tamanho da base: 2.5 Tb
> > > > > Local onde é armazenado o backup é em acfs compartilhado com os 4 nós.
> > > > > O backup é executado apenas na instancia 1.
> > > > >
> > > > > política de backup:
> > > > > Domingo 1:00 da manhã roda um full.
> > > > > Segunda a sabado as 1:00 roda o incremental.
> > > > > Todo dia de 8:00 as 18:00 roda o de archivelog.
> > > > >
> > > > > compigurações do rman:
> > > > >
> > > > > CONFIGURE RETENTION POLICY TO REDUNDANCY 7;
> > > > > CONFIGURE BACKUP OPTIMIZATION ON;
> > > > > CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
> > > > > CONFIGURE CONTROLFILE AUTOBACKUP ON;
> > > > > CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; 
> > > > > #
> > > > > default
> > > > > CONFIGURE DEVICE TYPE DISK PARALLELISM 4 BACKUP TYPE TO COMPRESSED
> > > > > BACKUPSET;
> > > > > CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
> > > > > CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # 
> > > > > default
> > > > > CONFIGURE MAXSETSIZE TO UNLIMITED; # default
> > > > > CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
> > > > > CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
> > > > > CONFIGURE COMPRESSION ALGORITHM 'HIGH' OPTIMIZE FOR LOAD TRUE AS OF
> > > > > RELEASE 'DEFAULT';
> > > > > CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
> > > > > CONFIGURE SNAPSHOT CONTROLFILE NAME TO '+DG02_R6/snapcf_PRODDB.f';
> > > > >
> > > > > script de backup full:
> > > > >
> > > > > run {
> > > > > ALLOCATE CHANNEL ch00 TYPE disk ;
> > > > > ALLOCATE CHANNEL ch01 TYPE disk ;
> > > > > ALLOCATE CHANNEL ch02 TYPE disk ;
> > > > > ALLOCATE CHANNEL ch03 TYPE disk ;
> > > > > backup incremental level 0 tag = bkpL0_proddb
> > > > > format
> > > > >
> > > > '/u01/app/acfsmounts/fradg_orabkplv/bkp/proddb/rman/backup/bkp_%d_%T_%s_%p_%U'
> > > > > database;
> > > > > sql 'alter system archive log current';
> > > > > RELEASE CHANNEL ch00;
> > > > > RELEASE CHANNEL 

[oracle_br] Re: Performance RMAN

[J. Laurindo Chiappa]

 Neto, alguns comentários/obs :
 
 a) se vc está no 11gr2 E usa intensamente LOBs, eles estão gravados em 
Securefiles ? Vc tem licenciado a Advanced Compression ?? Se sim, 
http://www.oracle.com/us/products/database/db-advanced-compression-option-1525064.pdf
 nos alerta que nesse cenário vc não só consegue compressão como DEDUPLICAÇÃO, 
o que deve encaixar como um luva se os seus LOBS são texto e gravados como 
CLOB,coisas via de regra bastante compressíveis e com bastante duplicação de 
strings, tipicamente...
 
 b) quando se fala de documentos governamentais (editais, licitações, julgados, 
atas, etc) , é COMUM que grande parte desses documentos não sofra alteração 
após a criação : considere SERIAMENTE a possibilidade de os ter em tablespaces 
dedicadas que vc coloque em READ ONLY e use a opção de SKIP READONLY no seu 
backup full O que Não Faz Sentido é vc backupear full várias e várias vezes 
informação que não mudou/não muda, sim ??
 
  c) iirc vc está usando só um nó para o backup full - já Considerou ter mais 
de um como Preferred para o RMAN ?
  
  []s
  
Chiappa

--- Em oracle_br@yahoogrupos.com.br, "netodba"  escreveu
>
> Vlw pessoal
> 
> ja mudei a compressão pra BASIC, aparentemente esta mas rapido mesmo.
> Vlw
> 
> 
> --- Em oracle_br@yahoogrupos.com.br, Wadson Ramon  escreveu
> >
> > Você pode mudar para assim.
> > CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE
> > FOR LOAD TRUE ;
> > 
> > blz
> > 
> > 
> > Em 16 de fevereiro de 2013 15:48, Vitor Junior escreveu:
> > 
> > > Experimentou usar compressed?
> > > Em 16/02/2013 14:09, "netodba"  escreveu:
> > >
> > > > **
> > > >
> > > >
> > > > Fala Pessoal,
> > > >
> > > > migrei uma base de dados 2.5 TB 10G pro 11.2.0.3, o meu problema é que o
> > > > backup rman ta demorando de mais.
> > > >
> > > > Ambiente:
> > > > S.O: RH 6.3
> > > > RAC 4 nós Oracle 11.2.0.3 em ASM
> > > > Tamanho da base: 2.5 Tb
> > > > Local onde é armazenado o backup é em acfs compartilhado com os 4 nós.
> > > > O backup é executado apenas na instancia 1.
> > > >
> > > > política de backup:
> > > > Domingo 1:00 da manhã roda um full.
> > > > Segunda a sabado as 1:00 roda o incremental.
> > > > Todo dia de 8:00 as 18:00 roda o de archivelog.
> > > >
> > > > compigurações do rman:
> > > >
> > > > CONFIGURE RETENTION POLICY TO REDUNDANCY 7;
> > > > CONFIGURE BACKUP OPTIMIZATION ON;
> > > > CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
> > > > CONFIGURE CONTROLFILE AUTOBACKUP ON;
> > > > CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; #
> > > > default
> > > > CONFIGURE DEVICE TYPE DISK PARALLELISM 4 BACKUP TYPE TO COMPRESSED
> > > > BACKUPSET;
> > > > CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
> > > > CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
> > > > CONFIGURE MAXSETSIZE TO UNLIMITED; # default
> > > > CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
> > > > CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
> > > > CONFIGURE COMPRESSION ALGORITHM 'HIGH' OPTIMIZE FOR LOAD TRUE AS OF
> > > > RELEASE 'DEFAULT';
> > > > CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
> > > > CONFIGURE SNAPSHOT CONTROLFILE NAME TO '+DG02_R6/snapcf_PRODDB.f';
> > > >
> > > > script de backup full:
> > > >
> > > > run {
> > > > ALLOCATE CHANNEL ch00 TYPE disk ;
> > > > ALLOCATE CHANNEL ch01 TYPE disk ;
> > > > ALLOCATE CHANNEL ch02 TYPE disk ;
> > > > ALLOCATE CHANNEL ch03 TYPE disk ;
> > > > backup incremental level 0 tag = bkpL0_proddb
> > > > format
> > > >
> > > '/u01/app/acfsmounts/fradg_orabkplv/bkp/proddb/rman/backup/bkp_%d_%T_%s_%p_%U'
> > > > database;
> > > > sql 'alter system archive log current';
> > > > RELEASE CHANNEL ch00;
> > > > RELEASE CHANNEL ch01;
> > > > RELEASE CHANNEL ch02;
> > > > RELEASE CHANNEL ch03;
> > > >
> > > > ALLOCATE CHANNEL ch00 TYPE disk;
> > > > backup tag = contf_prodb
> > > > format
> > > >
> > > '/u01/app/acfsmounts/fradg_orabkplv/bkp/proddb/rman/backup/contf_%d_%T_%s_%p_%U'
> > > > current controlfile;
> > > > RELEASE CHANNEL ch00;
> > > >
> > > > ALLOCATE CHANNEL ch00 TYPE disk;
> > > > ALLOCATE CHANNEL ch01 TYPE disk;
> > > > backup tag = arch_prodb
> > > > format
> > > >
> > > '/u01/app/acfsmounts/fradg_orabkplv/bkp/proddb/rman/archive/arc_%d_%T_%s_%p_%U'
> > > > check logical archivelog all delete input;
> > > > RELEASE CHANNEL ch00;
> > > > RELEASE CHANNEL ch01;
> > > > }
> > > >
> > > > script backup incremental:
> > > >
> > > > run {
> > > > ALLOCATE CHANNEL ch00 TYPE disk ;
> > > > ALLOCATE CHANNEL ch01 TYPE disk ;
> > > > backup incremental level 1 tag = bkpL1_proddb
> > > > format
> > > >
> > > '/u01/app/acfsmounts/fradg_orabkplv/bkp/proddb/rman/backup/bkp_%d_%T_%s_%p_%U'
> > > > database;
> > > > sql 'alter system archive log current';
> > > > RELEASE CHANNEL ch00;
> > > > RELEASE CHANNEL ch01;
> > > >
> > > > ALLOCATE CHANNEL ch00 TYPE disk;
> > > > backup tag = contf_prodb
> > > > format
> > > >
> > > '/u01/app/acfsmou

[oracle_br] Re: Performance RMAN

[netodba]

Hmm blzz
pensava que era no maximo 2 com 1 processador.

Vlw =)



--- Em oracle_br@yahoogrupos.com.br, Ivan Ricardo Schuster  
escreveu
>
> Ederson,
> 
> AFAIK, o Block Change Tracking serve somente para, ao realizar o
> *BACKUP* incremental, o RMAN ir direto ao ponto, ou seja, não precisar
> percorrer todos os blocos dos datafiles em busca de alteração, um mapa
> do tesouro, digamos assim.
> 
> Não entendo a relação deste arquivo BCT com o *RECOVER*, que ao meu
> ver é independente de ter ou não habilitada esta funcionalidade, ou
> seja, este arquivo não é necessário para a recuperação do banco.
> Portanto, teoricamente, a perda deste arquivo causará a necessidade de
> leitura de todos os blocos do banco de dados no próximo backup
> incremental, ou a necessidade de um backup full para reorganizar a
> casa. Nada muito preocupante para um banco de 2,5T ao meu ver.
> Por favor, corrijam-me se eu estiver errado, não me baseei em nenhuma
> documentação para chegar a esta conclusão..
> 
> Outra coisa, não li em lugar algum que este banco é Enterprise. Se não
> for, esqueça BCT e paralelismo de backup.
> 
> 
> 2013/2/18 ederson2001br :
> > Bom dia Neto,
> >
> > Mudar o algoritmo de compressão ajuda pois será uma tarefa a menos. No caso 
> > de algoritmos, MEDIUM, ZLIB e BZIP2 são as outras opções, mas algumas vem 
> > somente na versão Enterprise (Advanced Compressed).
> >
> > Bem, já que vc está na versão Enterprise, verifique a opção de habilitar o 
> > BLOCK CHANGE TRACKING. Será gravado um arquivo bct.cf e este arquivo 
> > controlará os blocos que sofreram modificação. Com BACKUP OPTIMIZATION ON, 
> > o seu backup incremental vai gravar somente o que foi modificado (vai ficar 
> > uma cópia bem pequena). Como vc colocou redundância 7, haverá uma boa 
> > redundância dos arquivos, mas o BCT vai controlar a cópia e você poderá 
> > colocar incremental diário, sem precisar retirar a cópia do archivelog (que 
> > será mais uma redundância).
> >
> > Note que o arquivo BCT será um ponto de falha, ele também precisará estar 
> > em local seguro, com backup pelo S.O. (então melhor ficar fora do ASM). Se 
> > perder o arquivo BCT, o backup que volta é somente o FULL, ou restore 
> > incomplete, veja bem esta informação.
> >
> > É uma mudança grande, representa um paradigma, vc deve testar bem em 
> > homologação e estar tranquilo com o novo ambiente, antes de implementar em 
> > produção.
> >
> > Para habilitar:
> > SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE '/u01/bct.cf';
> >
> > Para desabilitar:
> > SQL> ALTER DATABASE DISABLE BLOCK CHANGE TRANCKING;
> >
> > Convém colocar o CATALOG (dicionário do RMAN) do seu banco em outro 
> > servidor, não vi vc relatando como está esta configuração. Sem criar o 
> > CATALOG, vc estará usando o TARGET / (dicionário na própria base). Em 
> > alguns casos de desastres, o retorno somente se dá com sucesso se o 
> > catálogo estiver em outro servidor. Veja isto também.
> >
> > Creio que este tópico vai render uma boa discussão, pois cada um tem seu 
> > próprio conceito e seu nível de garantias (leia-se paranóia).
> >
> >
> > Ederson Elias
> > DBA Oracle
> > http://br.linkedin.com/pub/ederson-elias/24/8b/8b0
> >
> >
> > --- Em oracle_br@yahoogrupos.com.br, "netodba"  escreveu
> >>
> >> Vlw pessoal
> >>
> >> ja mudei a compressão pra BASIC, aparentemente esta mas rapido mesmo.
> >> Vlw
> >>
> >>
> >> --- Em oracle_br@yahoogrupos.com.br, Wadson Ramon  escreveu
> >> >
> >> > Você pode mudar para assim.
> >> > CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE
> >> > FOR LOAD TRUE ;
> >> >
> >> > blz
> >> >
> >> >
> >> > Em 16 de fevereiro de 2013 15:48, Vitor Junior escreveu:
> >> >
> >> > > Experimentou usar compressed?
> >> > > Em 16/02/2013 14:09, "netodba"  escreveu:
> >> > >
> >> > > > **
> >> > > >
> >> > > >
> >> > > > Fala Pessoal,
> >> > > >
> >> > > > migrei uma base de dados 2.5 TB 10G pro 11.2.0.3, o meu problema é 
> >> > > > que o
> >> > > > backup rman ta demorando de mais.
> >> > > >
> >> > > > Ambiente:
> >> > > > S.O: RH 6.3
> >> > > > RAC 4 nós Oracle 11.2.0.3 em ASM
> >> > > > Tamanho da base: 2.5 Tb
> >> > > > Local onde é armazenado o backup é em acfs compartilhado com os 4 
> >> > > > nós.
> >> > > > O backup é executado apenas na instancia 1.
> >> > > >
> >> > > > política de backup:
> >> > > > Domingo 1:00 da manhã roda um full.
> >> > > > Segunda a sabado as 1:00 roda o incremental.
> >> > > > Todo dia de 8:00 as 18:00 roda o de archivelog.
> >> > > >
> >> > > > compigurações do rman:
> >> > > >
> >> > > > CONFIGURE RETENTION POLICY TO REDUNDANCY 7;
> >> > > > CONFIGURE BACKUP OPTIMIZATION ON;
> >> > > > CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
> >> > > > CONFIGURE CONTROLFILE AUTOBACKUP ON;
> >> > > > CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 
> >> > > > '%F'; #
> >> > > > default
> >> > > > CONFIGURE DEVICE TYPE DISK PARALLELISM 4 BACKUP TYPE TO COMPRESSED
> >> > > > BACKUPSET;
> >>

RES: [oracle_br] Re: Performance RMAN

[Vitor Jr.]

Bingo... era o que eu ia mandar... rsrsrsrs

 

​

Att,/Regards,


Vitor Jr.
Infraestrutura / Infrastructure Team
Oracle 11g DBA Certified Professional - OCP

Oracle Certified Expert, Oracle Real Application Clusters 11g and Grid 
Infrastructure Administrator - OCE
Oracle Database 11g Performance Tuning Certified Expert - OCE
Oracle Exadata 11g Certified Implementation Specialist
Oracle Certified Associate, MySQL 5
mail, gtalk e msn:  <mailto:vitorj...@gmail.com> vitorj...@gmail.com
 <http://certificacaobd.com.br/> http://certificacaobd.com.br/
skype: vjunior1981

 

 

De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em nome 
de Ivan Ricardo Schuster
Enviada em: segunda-feira, 18 de fevereiro de 2013 11:15
Para: oracle_br@yahoogrupos.com.br
Assunto: Re: [oracle_br] Re: Performance RMAN

 

  

Não necessariamente, SE também pode ter 4 nós, desde que cada nó tenha
1 processador.

2013/2/18 netodba neto.lon...@gmail.com <mailto:neto.longhi%40gmail.com> >:
> Bom dia Ivan,
>
> como eu coloquei na mensagem original
> ORACLE RAC 4 nós, fica subentendido que o Banco é Enterprise.
>
> Mas vai ai
>
> INST_ID BANNER
> -- --
> 1 Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
> 1 PL/SQL Release 11.2.0.3.0 - Production
> 1 CORE 11.2.0.3.0 Production
> 1 TNS for Linux: Version 11.2.0.3.0 - Production
> 1 NLSRTL Version 11.2.0.3.0 - Production
> 4 Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
> 4 PL/SQL Release 11.2.0.3.0 - Production
> 4 CORE 11.2.0.3.0 Production
> 4 TNS for Linux: Version 11.2.0.3.0 - Production
> 4 NLSRTL Version 11.2.0.3.0 - Production
> 3 Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
> 3 PL/SQL Release 11.2.0.3.0 - Production
> 3 CORE 11.2.0.3.0 Production
> 3 TNS for Linux: Version 11.2.0.3.0 - Production
> 3 NLSRTL Version 11.2.0.3.0 - Production
> 2 Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
> 2 PL/SQL Release 11.2.0.3.0 - Production
> 2 CORE 11.2.0.3.0 Production
> 2 TNS for Linux: Version 11.2.0.3.0 - Production
> 2 NLSRTL Version 11.2.0.3.0 - Production
>
>
>
> --- Em oracle_br@yahoogrupos.com.br <mailto:oracle_br%40yahoogrupos.com.br> , 
> Ivan Ricardo Schuster escreveu
>>
>> Ederson,
>>
>> AFAIK, o Block Change Tracking serve somente para, ao realizar o
>> *BACKUP* incremental, o RMAN ir direto ao ponto, ou seja, não precisar
>> percorrer todos os blocos dos datafiles em busca de alteração, um mapa
>> do tesouro, digamos assim.
>>
>> Não entendo a relação deste arquivo BCT com o *RECOVER*, que ao meu
>> ver é independente de ter ou não habilitada esta funcionalidade, ou
>> seja, este arquivo não é necessário para a recuperação do banco.
>> Portanto, teoricamente, a perda deste arquivo causará a necessidade de
>> leitura de todos os blocos do banco de dados no próximo backup
>> incremental, ou a necessidade de um backup full para reorganizar a
>> casa. Nada muito preocupante para um banco de 2,5T ao meu ver.
>> Por favor, corrijam-me se eu estiver errado, não me baseei em nenhuma
>> documentação para chegar a esta conclusão..
>>
>> Outra coisa, não li em lugar algum que este banco é Enterprise. Se não
>> for, esqueça BCT e paralelismo de backup.
>>
>>
>> 2013/2/18 ederson2001br :
>> > Bom dia Neto,
>> >
>> > Mudar o algoritmo de compressão ajuda pois será uma tarefa a menos. No 
>> > caso de algoritmos, MEDIUM, ZLIB e BZIP2 são as outras opções, mas algumas 
>> > vem somente na versão Enterprise (Advanced Compressed).
>> >
>> > Bem, já que vc está na versão Enterprise, verifique a opção de habilitar o 
>> > BLOCK CHANGE TRACKING. Será gravado um arquivo bct.cf e este arquivo 
>> > controlará os blocos que sofreram modificação. Com BACKUP OPTIMIZATION ON, 
>> > o seu backup incremental vai gravar somente o que foi modificado (vai 
>> > ficar uma cópia bem pequena). Como vc colocou redundância 7, haverá uma 
>> > boa redundância dos arquivos, mas o BCT vai controlar a cópia e você 
>> > poderá colocar incremental diário, sem precisar retirar a cópia do 
>> > archivelog (que será mais uma redundância).
>> >
>> > Note que o arquivo BCT será um ponto de falha, ele também precisará estar 
>> > em local seguro, com backup pelo S.O. (então melhor ficar fora do ASM). Se 
>> > perder o arquivo BCT, o backup que volta é somente o FULL, ou restore 
>> > incomplete, veja bem esta informação.
>> >
>> > É uma mudança grande, representa um paradi

[oracle_br] Re: Performance RMAN

[netodba]

Bom dia Ivan,

como eu coloquei na mensagem original
ORACLE RAC 4 nós, fica subentendido que o Banco é Enterprise.

Mas vai ai

   INST_ID BANNER
-- 

 1 Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit 
Production
 1 PL/SQL Release 11.2.0.3.0 - Production
 1 CORE 11.2.0.3.0  Production
 1 TNS for Linux: Version 11.2.0.3.0 - Production
 1 NLSRTL Version 11.2.0.3.0 - Production
 4 Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit 
Production
 4 PL/SQL Release 11.2.0.3.0 - Production
 4 CORE 11.2.0.3.0  Production
 4 TNS for Linux: Version 11.2.0.3.0 - Production
 4 NLSRTL Version 11.2.0.3.0 - Production
 3 Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit 
Production
 3 PL/SQL Release 11.2.0.3.0 - Production
 3 CORE 11.2.0.3.0  Production
 3 TNS for Linux: Version 11.2.0.3.0 - Production
 3 NLSRTL Version 11.2.0.3.0 - Production
 2 Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit 
Production
 2 PL/SQL Release 11.2.0.3.0 - Production
 2 CORE 11.2.0.3.0  Production
 2 TNS for Linux: Version 11.2.0.3.0 - Production
 2 NLSRTL Version 11.2.0.3.0 - Production



--- Em oracle_br@yahoogrupos.com.br, Ivan Ricardo Schuster  
escreveu
>
> Ederson,
> 
> AFAIK, o Block Change Tracking serve somente para, ao realizar o
> *BACKUP* incremental, o RMAN ir direto ao ponto, ou seja, não precisar
> percorrer todos os blocos dos datafiles em busca de alteração, um mapa
> do tesouro, digamos assim.
> 
> Não entendo a relação deste arquivo BCT com o *RECOVER*, que ao meu
> ver é independente de ter ou não habilitada esta funcionalidade, ou
> seja, este arquivo não é necessário para a recuperação do banco.
> Portanto, teoricamente, a perda deste arquivo causará a necessidade de
> leitura de todos os blocos do banco de dados no próximo backup
> incremental, ou a necessidade de um backup full para reorganizar a
> casa. Nada muito preocupante para um banco de 2,5T ao meu ver.
> Por favor, corrijam-me se eu estiver errado, não me baseei em nenhuma
> documentação para chegar a esta conclusão..
> 
> Outra coisa, não li em lugar algum que este banco é Enterprise. Se não
> for, esqueça BCT e paralelismo de backup.
> 
> 
> 2013/2/18 ederson2001br :
> > Bom dia Neto,
> >
> > Mudar o algoritmo de compressão ajuda pois será uma tarefa a menos. No caso 
> > de algoritmos, MEDIUM, ZLIB e BZIP2 são as outras opções, mas algumas vem 
> > somente na versão Enterprise (Advanced Compressed).
> >
> > Bem, já que vc está na versão Enterprise, verifique a opção de habilitar o 
> > BLOCK CHANGE TRACKING. Será gravado um arquivo bct.cf e este arquivo 
> > controlará os blocos que sofreram modificação. Com BACKUP OPTIMIZATION ON, 
> > o seu backup incremental vai gravar somente o que foi modificado (vai ficar 
> > uma cópia bem pequena). Como vc colocou redundância 7, haverá uma boa 
> > redundância dos arquivos, mas o BCT vai controlar a cópia e você poderá 
> > colocar incremental diário, sem precisar retirar a cópia do archivelog (que 
> > será mais uma redundância).
> >
> > Note que o arquivo BCT será um ponto de falha, ele também precisará estar 
> > em local seguro, com backup pelo S.O. (então melhor ficar fora do ASM). Se 
> > perder o arquivo BCT, o backup que volta é somente o FULL, ou restore 
> > incomplete, veja bem esta informação.
> >
> > É uma mudança grande, representa um paradigma, vc deve testar bem em 
> > homologação e estar tranquilo com o novo ambiente, antes de implementar em 
> > produção.
> >
> > Para habilitar:
> > SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE '/u01/bct.cf';
> >
> > Para desabilitar:
> > SQL> ALTER DATABASE DISABLE BLOCK CHANGE TRANCKING;
> >
> > Convém colocar o CATALOG (dicionário do RMAN) do seu banco em outro 
> > servidor, não vi vc relatando como está esta configuração. Sem criar o 
> > CATALOG, vc estará usando o TARGET / (dicionário na própria base). Em 
> > alguns casos de desastres, o retorno somente se dá com sucesso se o 
> > catálogo estiver em outro servidor. Veja isto também.
> >
> > Creio que este tópico vai render uma boa discussão, pois cada um tem seu 
> > próprio conceito e seu nível de garantias (leia-se paranóia).
> >
> >
> > Ederson Elias
> > DBA Oracle
> > http://br.linkedin.com/pub/ederson-elias/24/8b/8b0
> >
> >
> > --- Em oracle_br@yahoogrupos.com.br, "netodba"  escreveu
> >>
> >> Vlw pessoal
> >>
> >> ja mudei a compressão pra BASIC, aparentemente esta mas rapido mesmo.
> >> Vlw
> >>
> >>
> >> --- Em oracle_br@yahoogrupos.com.br, Wadson Ramon  escreveu
> >> >
> >> > Você pode mudar para assim.
> >> > CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE
> >> > FOR LOAD TRUE ;
> >> >
> >> > blz
> >> >
> >> >
> >> > Em 16 de fever

Re: [oracle_br] Re: Performance RMAN

[Ivan Ricardo Schuster]

Ederson,

AFAIK, o Block Change Tracking serve somente para, ao realizar o
*BACKUP* incremental, o RMAN ir direto ao ponto, ou seja, não precisar
percorrer todos os blocos dos datafiles em busca de alteração, um mapa
do tesouro, digamos assim.

Não entendo a relação deste arquivo BCT com o *RECOVER*, que ao meu
ver é independente de ter ou não habilitada esta funcionalidade, ou
seja, este arquivo não é necessário para a recuperação do banco.
Portanto, teoricamente, a perda deste arquivo causará a necessidade de
leitura de todos os blocos do banco de dados no próximo backup
incremental, ou a necessidade de um backup full para reorganizar a
casa. Nada muito preocupante para um banco de 2,5T ao meu ver.
Por favor, corrijam-me se eu estiver errado, não me baseei em nenhuma
documentação para chegar a esta conclusão..

Outra coisa, não li em lugar algum que este banco é Enterprise. Se não
for, esqueça BCT e paralelismo de backup.


2013/2/18 ederson2001br :
> Bom dia Neto,
>
> Mudar o algoritmo de compressão ajuda pois será uma tarefa a menos. No caso 
> de algoritmos, MEDIUM, ZLIB e BZIP2 são as outras opções, mas algumas vem 
> somente na versão Enterprise (Advanced Compressed).
>
> Bem, já que vc está na versão Enterprise, verifique a opção de habilitar o 
> BLOCK CHANGE TRACKING. Será gravado um arquivo bct.cf e este arquivo 
> controlará os blocos que sofreram modificação. Com BACKUP OPTIMIZATION ON, o 
> seu backup incremental vai gravar somente o que foi modificado (vai ficar uma 
> cópia bem pequena). Como vc colocou redundância 7, haverá uma boa redundância 
> dos arquivos, mas o BCT vai controlar a cópia e você poderá colocar 
> incremental diário, sem precisar retirar a cópia do archivelog (que será mais 
> uma redundância).
>
> Note que o arquivo BCT será um ponto de falha, ele também precisará estar em 
> local seguro, com backup pelo S.O. (então melhor ficar fora do ASM). Se 
> perder o arquivo BCT, o backup que volta é somente o FULL, ou restore 
> incomplete, veja bem esta informação.
>
> É uma mudança grande, representa um paradigma, vc deve testar bem em 
> homologação e estar tranquilo com o novo ambiente, antes de implementar em 
> produção.
>
> Para habilitar:
> SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE '/u01/bct.cf';
>
> Para desabilitar:
> SQL> ALTER DATABASE DISABLE BLOCK CHANGE TRANCKING;
>
> Convém colocar o CATALOG (dicionário do RMAN) do seu banco em outro servidor, 
> não vi vc relatando como está esta configuração. Sem criar o CATALOG, vc 
> estará usando o TARGET / (dicionário na própria base). Em alguns casos de 
> desastres, o retorno somente se dá com sucesso se o catálogo estiver em outro 
> servidor. Veja isto também.
>
> Creio que este tópico vai render uma boa discussão, pois cada um tem seu 
> próprio conceito e seu nível de garantias (leia-se paranóia).
>
>
> Ederson Elias
> DBA Oracle
> http://br.linkedin.com/pub/ederson-elias/24/8b/8b0
>
>
> --- Em oracle_br@yahoogrupos.com.br, "netodba"  escreveu
>>
>> Vlw pessoal
>>
>> ja mudei a compressão pra BASIC, aparentemente esta mas rapido mesmo.
>> Vlw
>>
>>
>> --- Em oracle_br@yahoogrupos.com.br, Wadson Ramon  escreveu
>> >
>> > Você pode mudar para assim.
>> > CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE
>> > FOR LOAD TRUE ;
>> >
>> > blz
>> >
>> >
>> > Em 16 de fevereiro de 2013 15:48, Vitor Junior escreveu:
>> >
>> > > Experimentou usar compressed?
>> > > Em 16/02/2013 14:09, "netodba"  escreveu:
>> > >
>> > > > **
>> > > >
>> > > >
>> > > > Fala Pessoal,
>> > > >
>> > > > migrei uma base de dados 2.5 TB 10G pro 11.2.0.3, o meu problema é que 
>> > > > o
>> > > > backup rman ta demorando de mais.
>> > > >
>> > > > Ambiente:
>> > > > S.O: RH 6.3
>> > > > RAC 4 nós Oracle 11.2.0.3 em ASM
>> > > > Tamanho da base: 2.5 Tb
>> > > > Local onde é armazenado o backup é em acfs compartilhado com os 4 nós.
>> > > > O backup é executado apenas na instancia 1.
>> > > >
>> > > > política de backup:
>> > > > Domingo 1:00 da manhã roda um full.
>> > > > Segunda a sabado as 1:00 roda o incremental.
>> > > > Todo dia de 8:00 as 18:00 roda o de archivelog.
>> > > >
>> > > > compigurações do rman:
>> > > >
>> > > > CONFIGURE RETENTION POLICY TO REDUNDANCY 7;
>> > > > CONFIGURE BACKUP OPTIMIZATION ON;
>> > > > CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
>> > > > CONFIGURE CONTROLFILE AUTOBACKUP ON;
>> > > > CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; #
>> > > > default
>> > > > CONFIGURE DEVICE TYPE DISK PARALLELISM 4 BACKUP TYPE TO COMPRESSED
>> > > > BACKUPSET;
>> > > > CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
>> > > > CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
>> > > > CONFIGURE MAXSETSIZE TO UNLIMITED; # default
>> > > > CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
>> > > > CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
>> > > > CONFIGURE COMPRESSION ALGORITHM 'HIGH' OPTIMIZE FOR LOAD TRUE AS OF
>>

[oracle_br] Re: Performance RMAN

[netodba]

Bom dia pessoal,

descobri qual era o problema do RMAN.
Como o meu cliente é uma instituição do Governo Legislativo, na base de dados 
há extrema utilização de LOB's, só pra vcs terem uma ideia existe uma tabela 
com LOB de 1.2T. 
O problema era causado na hora de fazer a compressão desses LOBS, li em artigos 
e blogs, que o RMAN tem uma baixa performance com compressão de LOB's, com isso 
mudei a compressão de HIGH pra BASIC, e de fato achei o problema. Depois da 
mudança consegui uma taxa de 10G por minuto e isso é bom, consegui deixar o 
backup do RMAN ajustado pro horario de backup.

Ederson, obrigado pela resposta.
Utilizo sim um catalog do rman em outro banco, apenas nao coloquei no tópico. 
Vou disponiblizar a solução do BLOCK CHANGE TRACKING com o chefe do setor, 
obrigado pela dica.

Então pessoal fica a dica, compressão HIGH do rman envolvendo LOB's não é boa.

abraço


--- Em oracle_br@yahoogrupos.com.br, "ederson2001br"  
escreveu
>
> Bom dia Neto,
> 
> Mudar o algoritmo de compressão ajuda pois será uma tarefa a menos. No caso 
> de algoritmos, MEDIUM, ZLIB e BZIP2 são as outras opções, mas algumas vem 
> somente na versão Enterprise (Advanced Compressed).
> 
> Bem, já que vc está na versão Enterprise, verifique a opção de habilitar o 
> BLOCK CHANGE TRACKING. Será gravado um arquivo bct.cf e este arquivo 
> controlará os blocos que sofreram modificação. Com BACKUP OPTIMIZATION ON, o 
> seu backup incremental vai gravar somente o que foi modificado (vai ficar uma 
> cópia bem pequena). Como vc colocou redundância 7, haverá uma boa redundância 
> dos arquivos, mas o BCT vai controlar a cópia e você poderá colocar 
> incremental diário, sem precisar retirar a cópia do archivelog (que será mais 
> uma redundância).
> 
> Note que o arquivo BCT será um ponto de falha, ele também precisará estar em 
> local seguro, com backup pelo S.O. (então melhor ficar fora do ASM). Se 
> perder o arquivo BCT, o backup que volta é somente o FULL, ou restore 
> incomplete, veja bem esta informação.
> 
> É uma mudança grande, representa um paradigma, vc deve testar bem em 
> homologação e estar tranquilo com o novo ambiente, antes de implementar em 
> produção.
> 
> Para habilitar:
> SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE '/u01/bct.cf';
> 
> Para desabilitar:
> SQL> ALTER DATABASE DISABLE BLOCK CHANGE TRANCKING;
> 
> Convém colocar o CATALOG (dicionário do RMAN) do seu banco em outro servidor, 
> não vi vc relatando como está esta configuração. Sem criar o CATALOG, vc 
> estará usando o TARGET / (dicionário na própria base). Em alguns casos de 
> desastres, o retorno somente se dá com sucesso se o catálogo estiver em outro 
> servidor. Veja isto também.
> 
> Creio que este tópico vai render uma boa discussão, pois cada um tem seu 
> próprio conceito e seu nível de garantias (leia-se paranóia).
> 
> 
> Ederson Elias
> DBA Oracle
> http://br.linkedin.com/pub/ederson-elias/24/8b/8b0
> 
> 
> --- Em oracle_br@yahoogrupos.com.br, "netodba"  escreveu
> >
> > Vlw pessoal
> > 
> > ja mudei a compressão pra BASIC, aparentemente esta mas rapido mesmo.
> > Vlw
> > 
> > 
> > --- Em oracle_br@yahoogrupos.com.br, Wadson Ramon  escreveu
> > >
> > > Você pode mudar para assim.
> > > CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE
> > > FOR LOAD TRUE ;
> > > 
> > > blz
> > > 
> > > 
> > > Em 16 de fevereiro de 2013 15:48, Vitor Junior escreveu:
> > > 
> > > > Experimentou usar compressed?
> > > > Em 16/02/2013 14:09, "netodba"  escreveu:
> > > >
> > > > > **
> > > > >
> > > > >
> > > > > Fala Pessoal,
> > > > >
> > > > > migrei uma base de dados 2.5 TB 10G pro 11.2.0.3, o meu problema é 
> > > > > que o
> > > > > backup rman ta demorando de mais.
> > > > >
> > > > > Ambiente:
> > > > > S.O: RH 6.3
> > > > > RAC 4 nós Oracle 11.2.0.3 em ASM
> > > > > Tamanho da base: 2.5 Tb
> > > > > Local onde é armazenado o backup é em acfs compartilhado com os 4 nós.
> > > > > O backup é executado apenas na instancia 1.
> > > > >
> > > > > política de backup:
> > > > > Domingo 1:00 da manhã roda um full.
> > > > > Segunda a sabado as 1:00 roda o incremental.
> > > > > Todo dia de 8:00 as 18:00 roda o de archivelog.
> > > > >
> > > > > compigurações do rman:
> > > > >
> > > > > CONFIGURE RETENTION POLICY TO REDUNDANCY 7;
> > > > > CONFIGURE BACKUP OPTIMIZATION ON;
> > > > > CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
> > > > > CONFIGURE CONTROLFILE AUTOBACKUP ON;
> > > > > CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; 
> > > > > #
> > > > > default
> > > > > CONFIGURE DEVICE TYPE DISK PARALLELISM 4 BACKUP TYPE TO COMPRESSED
> > > > > BACKUPSET;
> > > > > CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
> > > > > CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # 
> > > > > default
> > > > > CONFIGURE MAXSETSIZE TO UNLIMITED; # default
> > > > > CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
> > > > > CONFIGURE ENCRYPTION ALGORITHM 'AES128'

[oracle_br] Re: Performance RMAN

[ederson2001br]

Bom dia Neto,

Mudar o algoritmo de compressão ajuda pois será uma tarefa a menos. No caso de 
algoritmos, MEDIUM, ZLIB e BZIP2 são as outras opções, mas algumas vem somente 
na versão Enterprise (Advanced Compressed).

Bem, já que vc está na versão Enterprise, verifique a opção de habilitar o 
BLOCK CHANGE TRACKING. Será gravado um arquivo bct.cf e este arquivo controlará 
os blocos que sofreram modificação. Com BACKUP OPTIMIZATION ON, o seu backup 
incremental vai gravar somente o que foi modificado (vai ficar uma cópia bem 
pequena). Como vc colocou redundância 7, haverá uma boa redundância dos 
arquivos, mas o BCT vai controlar a cópia e você poderá colocar incremental 
diário, sem precisar retirar a cópia do archivelog (que será mais uma 
redundância).

Note que o arquivo BCT será um ponto de falha, ele também precisará estar em 
local seguro, com backup pelo S.O. (então melhor ficar fora do ASM). Se perder 
o arquivo BCT, o backup que volta é somente o FULL, ou restore incomplete, veja 
bem esta informação.

É uma mudança grande, representa um paradigma, vc deve testar bem em 
homologação e estar tranquilo com o novo ambiente, antes de implementar em 
produção.

Para habilitar:
SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE '/u01/bct.cf';

Para desabilitar:
SQL> ALTER DATABASE DISABLE BLOCK CHANGE TRANCKING;

Convém colocar o CATALOG (dicionário do RMAN) do seu banco em outro servidor, 
não vi vc relatando como está esta configuração. Sem criar o CATALOG, vc estará 
usando o TARGET / (dicionário na própria base). Em alguns casos de desastres, o 
retorno somente se dá com sucesso se o catálogo estiver em outro servidor. Veja 
isto também.

Creio que este tópico vai render uma boa discussão, pois cada um tem seu 
próprio conceito e seu nível de garantias (leia-se paranóia).


Ederson Elias
DBA Oracle
http://br.linkedin.com/pub/ederson-elias/24/8b/8b0


--- Em oracle_br@yahoogrupos.com.br, "netodba"  escreveu
>
> Vlw pessoal
> 
> ja mudei a compressão pra BASIC, aparentemente esta mas rapido mesmo.
> Vlw
> 
> 
> --- Em oracle_br@yahoogrupos.com.br, Wadson Ramon  escreveu
> >
> > Você pode mudar para assim.
> > CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE
> > FOR LOAD TRUE ;
> > 
> > blz
> > 
> > 
> > Em 16 de fevereiro de 2013 15:48, Vitor Junior escreveu:
> > 
> > > Experimentou usar compressed?
> > > Em 16/02/2013 14:09, "netodba"  escreveu:
> > >
> > > > **
> > > >
> > > >
> > > > Fala Pessoal,
> > > >
> > > > migrei uma base de dados 2.5 TB 10G pro 11.2.0.3, o meu problema é que o
> > > > backup rman ta demorando de mais.
> > > >
> > > > Ambiente:
> > > > S.O: RH 6.3
> > > > RAC 4 nós Oracle 11.2.0.3 em ASM
> > > > Tamanho da base: 2.5 Tb
> > > > Local onde é armazenado o backup é em acfs compartilhado com os 4 nós.
> > > > O backup é executado apenas na instancia 1.
> > > >
> > > > política de backup:
> > > > Domingo 1:00 da manhã roda um full.
> > > > Segunda a sabado as 1:00 roda o incremental.
> > > > Todo dia de 8:00 as 18:00 roda o de archivelog.
> > > >
> > > > compigurações do rman:
> > > >
> > > > CONFIGURE RETENTION POLICY TO REDUNDANCY 7;
> > > > CONFIGURE BACKUP OPTIMIZATION ON;
> > > > CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
> > > > CONFIGURE CONTROLFILE AUTOBACKUP ON;
> > > > CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; #
> > > > default
> > > > CONFIGURE DEVICE TYPE DISK PARALLELISM 4 BACKUP TYPE TO COMPRESSED
> > > > BACKUPSET;
> > > > CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
> > > > CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
> > > > CONFIGURE MAXSETSIZE TO UNLIMITED; # default
> > > > CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
> > > > CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
> > > > CONFIGURE COMPRESSION ALGORITHM 'HIGH' OPTIMIZE FOR LOAD TRUE AS OF
> > > > RELEASE 'DEFAULT';
> > > > CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
> > > > CONFIGURE SNAPSHOT CONTROLFILE NAME TO '+DG02_R6/snapcf_PRODDB.f';
> > > >
> > > > script de backup full:
> > > >
> > > > run {
> > > > ALLOCATE CHANNEL ch00 TYPE disk ;
> > > > ALLOCATE CHANNEL ch01 TYPE disk ;
> > > > ALLOCATE CHANNEL ch02 TYPE disk ;
> > > > ALLOCATE CHANNEL ch03 TYPE disk ;
> > > > backup incremental level 0 tag = bkpL0_proddb
> > > > format
> > > >
> > > '/u01/app/acfsmounts/fradg_orabkplv/bkp/proddb/rman/backup/bkp_%d_%T_%s_%p_%U'
> > > > database;
> > > > sql 'alter system archive log current';
> > > > RELEASE CHANNEL ch00;
> > > > RELEASE CHANNEL ch01;
> > > > RELEASE CHANNEL ch02;
> > > > RELEASE CHANNEL ch03;
> > > >
> > > > ALLOCATE CHANNEL ch00 TYPE disk;
> > > > backup tag = contf_prodb
> > > > format
> > > >
> > > '/u01/app/acfsmounts/fradg_orabkplv/bkp/proddb/rman/backup/contf_%d_%T_%s_%p_%U'
> > > > current controlfile;
> > > > RELEASE CHANNEL ch00;
> > > >
> > > > ALLOCATE CHANNEL ch00 TYPE disk;
> > > > ALLOCATE CHANNEL ch01 TYPE disk;
> > > > backup tag = arc

[oracle_br] Re: Performance RMAN

[netodba]

Vlw pessoal

ja mudei a compressão pra BASIC, aparentemente esta mas rapido mesmo.
Vlw


--- Em oracle_br@yahoogrupos.com.br, Wadson Ramon  escreveu
>
> Você pode mudar para assim.
> CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE
> FOR LOAD TRUE ;
> 
> blz
> 
> 
> Em 16 de fevereiro de 2013 15:48, Vitor Junior escreveu:
> 
> > Experimentou usar compressed?
> > Em 16/02/2013 14:09, "netodba"  escreveu:
> >
> > > **
> > >
> > >
> > > Fala Pessoal,
> > >
> > > migrei uma base de dados 2.5 TB 10G pro 11.2.0.3, o meu problema é que o
> > > backup rman ta demorando de mais.
> > >
> > > Ambiente:
> > > S.O: RH 6.3
> > > RAC 4 nós Oracle 11.2.0.3 em ASM
> > > Tamanho da base: 2.5 Tb
> > > Local onde é armazenado o backup é em acfs compartilhado com os 4 nós.
> > > O backup é executado apenas na instancia 1.
> > >
> > > política de backup:
> > > Domingo 1:00 da manhã roda um full.
> > > Segunda a sabado as 1:00 roda o incremental.
> > > Todo dia de 8:00 as 18:00 roda o de archivelog.
> > >
> > > compigurações do rman:
> > >
> > > CONFIGURE RETENTION POLICY TO REDUNDANCY 7;
> > > CONFIGURE BACKUP OPTIMIZATION ON;
> > > CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
> > > CONFIGURE CONTROLFILE AUTOBACKUP ON;
> > > CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; #
> > > default
> > > CONFIGURE DEVICE TYPE DISK PARALLELISM 4 BACKUP TYPE TO COMPRESSED
> > > BACKUPSET;
> > > CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
> > > CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
> > > CONFIGURE MAXSETSIZE TO UNLIMITED; # default
> > > CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
> > > CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
> > > CONFIGURE COMPRESSION ALGORITHM 'HIGH' OPTIMIZE FOR LOAD TRUE AS OF
> > > RELEASE 'DEFAULT';
> > > CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
> > > CONFIGURE SNAPSHOT CONTROLFILE NAME TO '+DG02_R6/snapcf_PRODDB.f';
> > >
> > > script de backup full:
> > >
> > > run {
> > > ALLOCATE CHANNEL ch00 TYPE disk ;
> > > ALLOCATE CHANNEL ch01 TYPE disk ;
> > > ALLOCATE CHANNEL ch02 TYPE disk ;
> > > ALLOCATE CHANNEL ch03 TYPE disk ;
> > > backup incremental level 0 tag = bkpL0_proddb
> > > format
> > >
> > '/u01/app/acfsmounts/fradg_orabkplv/bkp/proddb/rman/backup/bkp_%d_%T_%s_%p_%U'
> > > database;
> > > sql 'alter system archive log current';
> > > RELEASE CHANNEL ch00;
> > > RELEASE CHANNEL ch01;
> > > RELEASE CHANNEL ch02;
> > > RELEASE CHANNEL ch03;
> > >
> > > ALLOCATE CHANNEL ch00 TYPE disk;
> > > backup tag = contf_prodb
> > > format
> > >
> > '/u01/app/acfsmounts/fradg_orabkplv/bkp/proddb/rman/backup/contf_%d_%T_%s_%p_%U'
> > > current controlfile;
> > > RELEASE CHANNEL ch00;
> > >
> > > ALLOCATE CHANNEL ch00 TYPE disk;
> > > ALLOCATE CHANNEL ch01 TYPE disk;
> > > backup tag = arch_prodb
> > > format
> > >
> > '/u01/app/acfsmounts/fradg_orabkplv/bkp/proddb/rman/archive/arc_%d_%T_%s_%p_%U'
> > > check logical archivelog all delete input;
> > > RELEASE CHANNEL ch00;
> > > RELEASE CHANNEL ch01;
> > > }
> > >
> > > script backup incremental:
> > >
> > > run {
> > > ALLOCATE CHANNEL ch00 TYPE disk ;
> > > ALLOCATE CHANNEL ch01 TYPE disk ;
> > > backup incremental level 1 tag = bkpL1_proddb
> > > format
> > >
> > '/u01/app/acfsmounts/fradg_orabkplv/bkp/proddb/rman/backup/bkp_%d_%T_%s_%p_%U'
> > > database;
> > > sql 'alter system archive log current';
> > > RELEASE CHANNEL ch00;
> > > RELEASE CHANNEL ch01;
> > >
> > > ALLOCATE CHANNEL ch00 TYPE disk;
> > > backup tag = contf_prodb
> > > format
> > >
> > '/u01/app/acfsmounts/fradg_orabkplv/bkp/proddb/rman/backup/contf_%d_%T_%s_%p_%U'
> > > current controlfile;
> > > RELEASE CHANNEL ch00;
> > >
> > > ALLOCATE CHANNEL ch00 TYPE disk;
> > > ALLOCATE CHANNEL ch01 TYPE disk;
> > > backup tag = arch_prodb
> > > format
> > >
> > '/u01/app/acfsmounts/fradg_orabkplv/bkp/proddb/rman/archive/arc_%d_%T_%s_%p_%U'
> > > check logical archivelog all delete input;
> > > RELEASE CHANNEL ch00;
> > > RELEASE CHANNEL ch01;
> > >
> > > vcs podem me ajudar??
> > > perguntem o que quiserem, mandei select's na view pra eu executar.
> > >
> > >
> > >
> >
> >
> > [As partes desta mensagem que não continham texto foram removidas]
> >
> >
> >
> > 
> >
> >
> > --
> > >Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de
> > inteira responsabilidade de seus remetentes.
> > Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/
> >
> > --
> > >Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package »
> > Procedure » Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO!
> > VISITE: http://www.oraclebr.com.br/
> > 

[oracle_br] Re: Performance RMAN

[netodba]

Opa Wadson vlw pela resposta.

qual seria o parametro pra mudar?

--- Em oracle_br@yahoogrupos.com.br, Wadson Ramon  escreveu
>
> Neto vc precisa utilizar a compactação HIGH  de cara eu já te falo se vc
> não usa-la o tempo de backup já vai cair sensivelmente .
> Vc pode alocar mais canais e fazer um teste para ver se melhora em alguns
> casos sim.
> 
> vlw.
> 
> 
> 2013/2/16 netodba 
> 
> > **
> >
> >
> > Fala Pessoal,
> >
> > migrei uma base de dados 2.5 TB 10G pro 11.2.0.3, o meu problema é que o
> > backup rman ta demorando de mais.
> >
> > Ambiente:
> > S.O: RH 6.3
> > RAC 4 nós Oracle 11.2.0.3 em ASM
> > Tamanho da base: 2.5 Tb
> > Local onde é armazenado o backup é em acfs compartilhado com os 4 nós.
> > O backup é executado apenas na instancia 1.
> >
> > política de backup:
> > Domingo 1:00 da manhã roda um full.
> > Segunda a sabado as 1:00 roda o incremental.
> > Todo dia de 8:00 as 18:00 roda o de archivelog.
> >
> > compigurações do rman:
> >
> > CONFIGURE RETENTION POLICY TO REDUNDANCY 7;
> > CONFIGURE BACKUP OPTIMIZATION ON;
> > CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
> > CONFIGURE CONTROLFILE AUTOBACKUP ON;
> > CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; #
> > default
> > CONFIGURE DEVICE TYPE DISK PARALLELISM 4 BACKUP TYPE TO COMPRESSED
> > BACKUPSET;
> > CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
> > CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
> > CONFIGURE MAXSETSIZE TO UNLIMITED; # default
> > CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
> > CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
> > CONFIGURE COMPRESSION ALGORITHM 'HIGH' OPTIMIZE FOR LOAD TRUE AS OF
> > RELEASE 'DEFAULT';
> > CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
> > CONFIGURE SNAPSHOT CONTROLFILE NAME TO '+DG02_R6/snapcf_PRODDB.f';
> >
> > script de backup full:
> >
> > run {
> > ALLOCATE CHANNEL ch00 TYPE disk ;
> > ALLOCATE CHANNEL ch01 TYPE disk ;
> > ALLOCATE CHANNEL ch02 TYPE disk ;
> > ALLOCATE CHANNEL ch03 TYPE disk ;
> > backup incremental level 0 tag = bkpL0_proddb
> > format
> > '/u01/app/acfsmounts/fradg_orabkplv/bkp/proddb/rman/backup/bkp_%d_%T_%s_%p_%U'
> > database;
> > sql 'alter system archive log current';
> > RELEASE CHANNEL ch00;
> > RELEASE CHANNEL ch01;
> > RELEASE CHANNEL ch02;
> > RELEASE CHANNEL ch03;
> >
> > ALLOCATE CHANNEL ch00 TYPE disk;
> > backup tag = contf_prodb
> > format
> > '/u01/app/acfsmounts/fradg_orabkplv/bkp/proddb/rman/backup/contf_%d_%T_%s_%p_%U'
> > current controlfile;
> > RELEASE CHANNEL ch00;
> >
> > ALLOCATE CHANNEL ch00 TYPE disk;
> > ALLOCATE CHANNEL ch01 TYPE disk;
> > backup tag = arch_prodb
> > format
> > '/u01/app/acfsmounts/fradg_orabkplv/bkp/proddb/rman/archive/arc_%d_%T_%s_%p_%U'
> > check logical archivelog all delete input;
> > RELEASE CHANNEL ch00;
> > RELEASE CHANNEL ch01;
> > }
> >
> > script backup incremental:
> >
> > run {
> > ALLOCATE CHANNEL ch00 TYPE disk ;
> > ALLOCATE CHANNEL ch01 TYPE disk ;
> > backup incremental level 1 tag = bkpL1_proddb
> > format
> > '/u01/app/acfsmounts/fradg_orabkplv/bkp/proddb/rman/backup/bkp_%d_%T_%s_%p_%U'
> > database;
> > sql 'alter system archive log current';
> > RELEASE CHANNEL ch00;
> > RELEASE CHANNEL ch01;
> >
> > ALLOCATE CHANNEL ch00 TYPE disk;
> > backup tag = contf_prodb
> > format
> > '/u01/app/acfsmounts/fradg_orabkplv/bkp/proddb/rman/backup/contf_%d_%T_%s_%p_%U'
> > current controlfile;
> > RELEASE CHANNEL ch00;
> >
> > ALLOCATE CHANNEL ch00 TYPE disk;
> > ALLOCATE CHANNEL ch01 TYPE disk;
> > backup tag = arch_prodb
> > format
> > '/u01/app/acfsmounts/fradg_orabkplv/bkp/proddb/rman/archive/arc_%d_%T_%s_%p_%U'
> > check logical archivelog all delete input;
> > RELEASE CHANNEL ch00;
> > RELEASE CHANNEL ch01;
> >
> > vcs podem me ajudar??
> > perguntem o que quiserem, mandei select's na view pra eu executar.
> >
> >  
> >
> 
> 
> [As partes desta mensagem que não continham texto foram removidas]
>

[oracle_br] Re: performance query

[José Laurindo]

Bem, não sei se realmente é só esse o SQL em questão (até porque há um 
parêntesis a mais na query que vc nos mostra), mas se REALMENTE é esse mesmo, e 
se realmente é uma tabela o objeto que vc tem e não uma view nem nada assim, ** 
DE FORMA ALGUMA ** é aceitável uma hora como tempo de resposta : veja no 
exemplo abaixo que no meu hardware de casa (win7 Professional de 32 bits, com 
um processador só (dual-core mas um só), com discos SATA, levou cerca de 7 
minutos ok que provavelmente o teu servidor deve estar sendo usado pra 
caramba, tem n outros usuários pra atender, mas tamos falando de um equipamento 
profissional (imagino), com discos SCSI rápidos (talvez até num array RAID, 
provavelmente) e multi-processadores, por mais concorrência que haja eu 
aceitaria no máximo uns 15 ou 20 minutos como tempo de resposta...
 Eu diria pra vc : primeiro, faça um teste como eu fiz, no sqlplus, SEM conexão 
de rede (processando local), E com paralelismo ativado - se não obter tempo na 
casa de 15 a 20 minutos, ou um pouco mais, pra mim tá claro que vc tem um 
problema local aí, talvez extent size inapropriado, talvez hardware não dando 
conta da concorrência,  talvez subsistema de I/O com problemas, talvez algum 
SQL profile ou hints "forçando" o uso de índice quando o que vc quer é o que eu 
obtive, ie, um suculento table scan com multiblock, ou bug/problema no 
middleware, a ver... Se o teste não retornar algo similar ao que eu obtive, é 
caso pra acionar o DBA do ambiente,m sim, pois algum problema Claro vc teria 
nesse caso...

O meu exemplo, em Oracle 10.2.0.5 EE :


SQL> set arraysize 500
SQL> set pages 
SQL> set autotrace on
sql> SET TIMING ON
SQL> SELECT * FROM tab_teste_big D
WHERE D.last_DDL_TIME >= ADD_MONTHS(SYSDATE, -6 );

...


SYS
WRH$_LATCH_MISSES_SUMMARY_PK
WRH$_LATCH__1284328844_56   55592  55592 INDEX PARTITION
09/01/12 09/01/12 2012-01-09:20:53:39 VALID   N N N

SYS
WRH$_DB_CACHE_ADVICE_PK
WRH$_DB_CAC_1284328844_56   55596  55596 INDEX PARTITION
09/01/12 09/01/12 2012-01-09:20:53:39 VALID   N N N

SYS
WRH$_ROWCACHE_SUMMARY_PK
WRH$_ROWCAC_1284328844_56   55600  55600 INDEX PARTITION
09/01/12 09/01/12 2012-01-09:20:53:39 VALID   N N N

SYS
WRH$_SGASTAT_U
WRH$_SGASTA_1284328844_56   55604  55604 INDEX PARTITION
09/01/12 09/01/12 2012-01-09:20:53:39 VALID   N N N

SYS
WRH$_SYSSTAT_PK
WRH$_SYSSTA_1284328844_56   55608  55608 INDEX PARTITION
09/01/12 09/01/12 2012-01-09:20:53:39 VALID   N N N

SYS
WRH$_PARAMETER_PK
WRH$_PARAME_1284328844_56   55612  55612 INDEX PARTITION
09/01/12 09/01/12 2012-01-09:20:53:39 VALID   N N N

SYS
WRH$_SEG_STAT_PK
WRH$_SEG_ST_1284328844_56   55616  55616 INDEX PARTITION
09/01/12 09/01/12 2012-01-09:20:53:39 VALID   N N N

SYS
WRH$_SERVICE_STAT_PK
WRH$_SERVIC_1284328844_56   55620  55620 INDEX PARTITION
09/01/12 09/01/12 2012-01-09:20:53:40 VALID   N N N

SYS
WRH$_ACTIVE_SESSION_HISTORY_PK
WRH$_ACTIVE_1284328844_56   55624  55624 INDEX PARTITION
09/01/12 09/01/12 2012-01-09:20:53:40 VALID   N N N

SYS
WRH$_TABLESPACE_STAT_PK
WRH$_TABLES_1284328844_56   55628  55628 INDEX PARTITION
09/01/12 09/01/12 2012-01-09:20:53:40 VALID   N N N

SYS
WRH$_OSSTAT_PK
WRH$_OSSTAT_1284328844_56   55632  55632 INDEX PARTITION
09/01/12 09/01/12 2012-01-09:20:53:40 VALID   N N N

SYS
WRH$_SERVICE_WAIT_CLASS
WRH$_SERVIC_1284328844_56   55638  55638 TABLE PARTITION
09/01/12 09/01/12 2012-01-09:20:53:40 VALID   N N N

SYSTEM
TAB_TESTE_BIG
55641  55641 TABLE
09/01/12 09/01/12 2012-01-09:22:35:30 VALID   N N N


67914 linhas selecionadas.

Decorrido: 00:07:53.67

Plano de ExecuþÒo
--
Plan hash value: 2548191689


---

| Id  | Operation| Name  | Rows  | Bytes | Cost (%CPU)| Time
 |TQ  |IN-OUT| PQ Distrib |


---

|   0 | SELECT STATEMENT |   |19M|  1693M| 30947   (2)| 00:0
6:12 ||  ||

|   1 |  PX COORDINATOR  |   |   |   ||
 ||  ||

|   2 |   PX SEND QC (RANDOM)| :TQ1  |19M|  1693M| 30947   (2)| 00:0
6:12 |  Q1,00 | P->S | QC (RAND)  |

|   3 |PX BLOCK ITERATOR |   |19M|  1693M| 30947   (2)| 00:0
6:12 |  Q1,00 | PCWC ||

|*  4 | TABLE ACCESS FULL| TAB_TESTE_BIG |19M|  1693M| 30947   (2)| 00:0
6:12 |  Q1,00 | PCWP ||


---


Predicate Information (identified by operation id):
-

[oracle_br] Re: Performance inconsistente utilizando o DBLINK

[José Laurindo]

 Ah, detalhe importantíssimo - se o passo zero é saber pelo que o banco está 
procurando, o passo 1 na sequência é obter info dos SQLs mais importantes, 
sendo principalmente :

 - o plano de execução ** REAL ** dos SQLs mais importantes da rotina (tirados 
da V$SQL_PLAN e correlatas)

 - as estatísticas de execução dos SQLs (tal como tempo gasto, linhas linhas , 
etc), que vc obtém na V$SQL

 Comparando essas infos de uma execução "ruim" com uma eventual execução "boa" 
certamente deve ser esclarecedor...

 []s

   Chiappa

--- Em oracle_br@yahoogrupos.com.br, José Laurindo  escreveu
>
>   Colega, absolutamente ** não tem mágica ** quando se fala de performance 
> degradada : o passo ZERO, inicial, é saber exatamente pelo que o processo 
> está esperando, não tem por onde - a tool básica para isso é trace+tkprof, e 
> ver quais waits vc está tendo...
>  Outra boa possibilidade no OWB seria, já que ele pode gerar um stored PL/SQL 
> com a rotina (procedure, normalmente) ,  vc introduzir alguma INSTRUMENTAÇÃO, 
> nem que seja coisas simples como adicionar chamadas à 
> DBMS_APPLICATION.SET_CLIENT_INFO, tipo :
> 
> 
>  .
>  dbms_application_info.set_client_info('vou entrar loop em:' 
>|| to_char(sysdate, 'hh24:mi:ss')); 
>for r in (select colunachace, outras colunas from tabelas)
>loop
>   dbms_application_info.set_client_info('loop1 key#' 
>  || r.colunachave 
>  || to_char(sysdate, 'hh24:mi:ss'));
>   for i in outrocursorbuscandodetalhes do acima 
> loop
>  dbms_application_info.set_client_info('loop2 key#' 
>  || r.colunachave 
>  || to_char(sysdate, 'hh24:mi:ss'));
> .
> 
> 
>  Aí numa outra sessão vc vai consultando a coluna CLIENT_INFO da sessão que 
> está executando o PL/SQL
>  Outro procedimento muito muito muito aconselhável é vc, no instante que der 
> a demora, diversas vezes ir consultando na V$SESSION as colunas de wait, e 
> consultar as views de waits, de locks e de estatísticas do sistema, E também 
> rodar alguma tool que mostre de modo geral o status do banco 
> (statspack/awr/ash, o que vc tiver licenciado na sua versão de banco), que vc 
> deve ter umas pistas da causa 
>  Eu digo pistas porque há ** DIVERSAS ** causas possíveis para um cenário tal 
> qual vc descreve, que vão desde esperas por locks ou latches até simplesmente 
> banco temporariamente sobrecarregado , ou até mesmo picos temporários de rede 
> ...
> 
>  []s
> 
>   Chiappa
> 
> --- Em oracle_br@yahoogrupos.com.br, "lrmaross"  escreveu
> >
> > Amigos preciso de um auxílio.
> > 
> > Tenho um processo de ETL entre dois servidores regionalmente separados 
> > trocando informações via DBLINK. Este cenário eu já tenho a mais de 5 meses 
> > e até então não vinha tendo problemas de performance. Há alguns dias, meu 
> > processo de ETL passou a apresentar grandes problemas de performance e de 
> > forma intermitente - o mesmo processo fica excessivamente lento e, quando o 
> > re-inicio, tudo volta ao normal. Alguns dias nem temos problemas de 
> > performance. 
> > Já cheguei a deixar um processo executando durante mais de 5 horas e ele 
> > não finalizou e, ao executa-lo novamente ele transcorre naturalmente como e 
> > nada ocorresse. Acrescento também que o problema não ocorre sempre no mesmo 
> > ponto, ele alterna as tabelas do meu processo de ETL.
> > Já coletei estatistica, solicitei uma análise da rede (que esta muito boa), 
> > verifiquei indices, alterei parâmetros ARREYSIZE, executei a query criada 
> > pelo OWB via SQLPLUS, via TOAD, e a lentidão se manteve igual. Abri um 
> > chamado na ORACLE e a resposta que obtive foi de que deveria ser problema 
> > de rede. Analisando a parte FISICA da rede não identificamos nada que 
> > pudesse estar comprometendo a performance, na realidade a rede esta bem 
> > tranquila no momento que os processos executam. 
> > 
> > O que pode estar acontecendo?
> > 
> > Obrigado.
> > 
> > Luis R.
> >
>

[oracle_br] Re: Performance inconsistente utilizando o DBLINK

[José Laurindo]

  Colega, absolutamente ** não tem mágica ** quando se fala de performance 
degradada : o passo ZERO, inicial, é saber exatamente pelo que o processo está 
esperando, não tem por onde - a tool básica para isso é trace+tkprof, e ver 
quais waits vc está tendo...
 Outra boa possibilidade no OWB seria, já que ele pode gerar um stored PL/SQL 
com a rotina (procedure, normalmente) ,  vc introduzir alguma INSTRUMENTAÇÃO, 
nem que seja coisas simples como adicionar chamadas à 
DBMS_APPLICATION.SET_CLIENT_INFO, tipo :


 .
 dbms_application_info.set_client_info('vou entrar loop em:' 
   || to_char(sysdate, 'hh24:mi:ss')); 
   for r in (select colunachace, outras colunas from tabelas)
   loop
  dbms_application_info.set_client_info('loop1 key#' 
 || r.colunachave 
 || to_char(sysdate, 'hh24:mi:ss'));
  for i in outrocursorbuscandodetalhes do acima 
loop
 dbms_application_info.set_client_info('loop2 key#' 
 || r.colunachave 
 || to_char(sysdate, 'hh24:mi:ss'));
.


 Aí numa outra sessão vc vai consultando a coluna CLIENT_INFO da sessão que 
está executando o PL/SQL
 Outro procedimento muito muito muito aconselhável é vc, no instante que der a 
demora, diversas vezes ir consultando na V$SESSION as colunas de wait, e 
consultar as views de waits, de locks e de estatísticas do sistema, E também 
rodar alguma tool que mostre de modo geral o status do banco 
(statspack/awr/ash, o que vc tiver licenciado na sua versão de banco), que vc 
deve ter umas pistas da causa 
 Eu digo pistas porque há ** DIVERSAS ** causas possíveis para um cenário tal 
qual vc descreve, que vão desde esperas por locks ou latches até simplesmente 
banco temporariamente sobrecarregado , ou até mesmo picos temporários de rede 
...

 []s

  Chiappa

--- Em oracle_br@yahoogrupos.com.br, "lrmaross"  escreveu
>
> Amigos preciso de um auxílio.
> 
> Tenho um processo de ETL entre dois servidores regionalmente separados 
> trocando informações via DBLINK. Este cenário eu já tenho a mais de 5 meses e 
> até então não vinha tendo problemas de performance. Há alguns dias, meu 
> processo de ETL passou a apresentar grandes problemas de performance e de 
> forma intermitente - o mesmo processo fica excessivamente lento e, quando o 
> re-inicio, tudo volta ao normal. Alguns dias nem temos problemas de 
> performance. 
> Já cheguei a deixar um processo executando durante mais de 5 horas e ele não 
> finalizou e, ao executa-lo novamente ele transcorre naturalmente como e nada 
> ocorresse. Acrescento também que o problema não ocorre sempre no mesmo ponto, 
> ele alterna as tabelas do meu processo de ETL.
> Já coletei estatistica, solicitei uma análise da rede (que esta muito boa), 
> verifiquei indices, alterei parâmetros ARREYSIZE, executei a query criada 
> pelo OWB via SQLPLUS, via TOAD, e a lentidão se manteve igual. Abri um 
> chamado na ORACLE e a resposta que obtive foi de que deveria ser problema de 
> rede. Analisando a parte FISICA da rede não identificamos nada que pudesse 
> estar comprometendo a performance, na realidade a rede esta bem tranquila no 
> momento que os processos executam. 
> 
> O que pode estar acontecendo?
> 
> Obrigado.
> 
> Luis R.
>

RE: [oracle_br] Re: Performance IS NULL

[Teixeira, Gabriel]

Muito interessante as dicas!! 
 
Obrigado!



From: oracle_br@yahoogrupos.com.br [mailto:oracle...@yahoogrupos.com.br] On 
Behalf Of jlchiappa
Sent: quinta-feira, 26 de novembro de 2009 18:16
To: oracle_br@yahoogrupos.com.br
Subject: [oracle_br] Re: Performance IS NULL


  

Bem, na verdade não sei se pode se chamar de gambiarra, já que o fato do índice 
b*tree no bd Oracle não indexar valores nulos é padrão, é uma característica 
técnica documentada e sempre presente, não é nem de longe bug que precise de 
work-around nem nada assim... Bom, quanto ao problema em questão, acho que 
antes de sair indexando a pessoa TEM que :

1. saber a cardinalidade,ie, QUANTOS registros tem esse cara nulo e quantos não

e

2. extrair o plano de execução real 9e estatísticas de execução, I/Os, tempos, 
etc) dos SQLs com e sem o and coluna is null

Digo isso porque (já que o colega lá optou por Não nos dar a query nem a 
estrutura) de repente pode ser que já haja um índice excelente, e talvez a 
query estava sendo satisfeita só com acesso ao índice, MAS com a adição da 
coluna a mais (que o otimizador ** sabe ** que jamais vai estar no índice por 
ser nula) passou a ser necessária uma visita aos blocos da tabela, o que antes 
não aconteciaNum caso desses, Pode Ser que o novo índice de função seja 
menos eficiente que o índice ideal que já tínhamos antes... E Mais, tanto Pode 
Ser que os nulls sejam poucos (aí realmente valeria a pena indexar quem é 
nulo), Quanto pode ser que os nulls sejam muitos muitos, aí talvez valha mais a 
pena indexar quem NÃO é nulo (via índice de função que retorna valor só pros 
não nulos), ou até optar por um table scan ... vareia, ok ? Só o colega que 
formulou a pergunta tem os dados TODOS na mão, é mais ou menos como eu falei na 
minha apresentação de CBO - a pessoa TEM que conhecer os dados dela, o ambiente 
dela, pra só aí poder usar o Otimizador na eficiência máxima...

[]s

Chiappa

--- Em oracle_br@yahoogrupos.com.br <mailto:oracle_br%40yahoogrupos.com.br> , 
Rosivaldo Ramalho  escreveu
>
> Em geral se cria um índice baseado em função (usando nvl), e no select
> se utilza a função que você utilizou no índice (where nvl(coluna)..).
> 
> Se você já tem um índice na coluna, você pode atualizar os valores
> nulos para um valor que esteja fora da regra do teu negócio, algo no
> ano de 1800/1700, dá um rebuild no índice e pode continuar com o
> select normal, só passando agora essa nova data no lugar do IS NULL.
> 
> Essas duas formas são meio que gambiarras, mas eu desconheço outras.
> 
> 2009/11/26 francisco porfirio :
> > Boa Tarde Pessoal.
> >
> > Tenho uma consulta que está demorando devido a utilização do IS NULL.(Segue
> > parte da consulta)
> >
> > ...
> > and campo_timestamp is null
> > ...
> > Sei que quando isso é feito não adianta criar um índice para o campo
> > testado.
> > Alguem sabe uma outra forma de capturar os campos que são nulos sem perder
> > tanto a performance?
> >
> >
> > Versão do Oracle: 10.2.0.4.0
> > --
> > Atenciosamente
> > Francisco Porfirio Ribeiro Neto
> >
> >
> > [As partes desta mensagem que não continham texto foram removidas]
> >
> >
> >
> > 
> >
> > --
> >>Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de inteira 
> >>responsabilidade de seus remetentes.
> > Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ 
> > <http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/> 
> > --
> >>Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package » Procedure 
> >>» Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE: 
> >>http://www.oraclebr.com.br/ <http://www.oraclebr.com.br/> 
> > -- Links do Yahoo! 
> > Grupos
> >
> >
> >
> 
> 
> 
> -- 
> Rosivaldo Azevedo Ramalho
> Consultor Oracle Database / Application Server
> mail/msn: rosiva...@...
> mobile: +55 83 8893 8281
> Oracle Database 10g Certified Professional
> Oracle Application Server 10g Certified Professional
>






[As partes desta mensagem que não continham texto foram removidas]

[oracle_br] Re: Performance IS NULL

[jlchiappa]

Bem, na verdade não sei se pode se chamar de gambiarra, já que o fato do índice 
b*tree no bd Oracle não indexar valores nulos é padrão, é uma característica 
técnica documentada e sempre presente, não é nem de longe bug que precise de 
work-around nem nada assim... Bom, quanto ao problema em questão, acho que 
antes de sair indexando a pessoa TEM que :

1. saber a cardinalidade,ie, QUANTOS registros tem esse cara nulo e quantos não

e

2. extrair o plano de execução real 9e estatísticas de execução, I/Os, tempos, 
etc) dos SQLs com e sem o and coluna is null

Digo isso porque (já que o colega lá optou por Não nos dar a query nem a 
estrutura) de repente pode ser que já haja um índice excelente, e talvez a 
query estava sendo satisfeita só com acesso ao índice, MAS com a adição da 
coluna a mais (que o otimizador ** sabe ** que jamais vai estar no índice por 
ser nula) passou a ser necessária uma visita aos blocos da tabela, o que antes 
não aconteciaNum caso desses, Pode Ser que o novo índice de função seja 
menos eficiente que o índice ideal que já tínhamos antes...  E Mais, tanto Pode 
Ser que os nulls sejam poucos (aí realmente valeria a pena indexar quem é 
nulo), Quanto pode ser que os nulls sejam muitos muitos, aí talvez valha mais a 
pena indexar quem NÃO é nulo (via índice de função que retorna valor só pros 
não nulos), ou até optar por um table scan ... vareia, ok ? Só o colega que 
formulou a pergunta tem os dados TODOS na mão, é mais ou menos como eu falei na 
minha apresentação de CBO - a pessoa TEM que conhecer os dados dela, o ambiente 
dela, pra só aí poder usar o Otimizador na eficiência máxima...

 []s

  Chiappa

--- Em oracle_br@yahoogrupos.com.br, Rosivaldo Ramalho  escreveu
>
> Em geral se cria um índice baseado em função (usando nvl), e no select
> se utilza a função que você utilizou no índice (where nvl(coluna)..).
> 
> Se você já tem um índice na coluna, você pode atualizar os valores
> nulos para um valor que esteja fora da regra do teu negócio, algo no
> ano de 1800/1700, dá um rebuild no índice e pode continuar com o
> select normal, só passando agora essa nova data no lugar do IS NULL.
> 
> Essas duas formas são meio que gambiarras, mas eu desconheço outras.
> 
> 2009/11/26 francisco porfirio :
> > Boa Tarde Pessoal.
> >
> > Tenho uma consulta que está demorando devido a utilização do IS NULL.(Segue
> > parte da consulta)
> >
> > ...
> > and campo_timestamp is null
> > ...
> > Sei que quando isso é feito não adianta criar um índice para o campo
> > testado.
> > Alguem sabe uma outra forma de capturar os campos que são nulos sem perder
> > tanto a performance?
> >
> >
> > Versão do Oracle: 10.2.0.4.0
> > --
> > Atenciosamente
> > Francisco Porfirio Ribeiro Neto
> >
> >
> > [As partes desta mensagem que não continham texto foram removidas]
> >
> >
> >
> > 
> >
> > --
> >>Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de inteira 
> >>responsabilidade de seus remetentes.
> > Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/
> > --
> >>Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package » Procedure 
> >>» Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE: 
> >>http://www.oraclebr.com.br/
> > 
> >  Links do Yahoo! Grupos
> >
> >
> >
> 
> 
> 
> -- 
> Rosivaldo Azevedo Ramalho
> Consultor Oracle Database / Application Server
> mail/msn: rosiva...@...
> mobile: +55 83 8893 8281
> Oracle Database 10g Certified Professional
> Oracle Application Server 10g Certified Professional
>

[oracle_br] Re: Performance com Synonym Privados

[jlchiappa]

Mais um aqui a favor de PRIVATE SYNONYMS, se tiver que ser usados sinônimos... 
Em 
http://asktom.oracle.com/pls/asktom/f?p=100:11:0P11_QUESTION_ID:7555433442177
 o autor fala sobre eles, discutindo algumas das suas vantagens em performance, 
mas o mal maior dos objetos e/ou grants públicos é conceitual na segurança : o 
bd Oracle Não Tem o conceito de DENY ou de EXCEPTION de um privilégio, se vc 
fizer GRANT qquer TO PUBLIC, ou CREATE PUBLIC qquercoisa, absolutamente 
QUALQUER UM, por mais ralé e xumbrega que seja, vai obter o grant, vai acessar 
o objeto criado, NÂO TEM COMO dizer 'ah, o zezinho e o toizinho são exceções ao 
PUBLIC', não Não acho de forma NENHUMA minimamente saudável pra segurança 
ter seja o que for acessável por qquer zémané mixuruca do banco... 

 []s
 
  Chiappa
  

--- Em oracle_br@yahoogrupos.com.br, Marcos Fontana  
escreveu
>
> Funciona muito bem,
> 
> Temos isso aqui em 80 instâncias de produção sem nenhum problema.
> 
> Atenciosamente,
> 
> Marcos Fontana
> DBA Oracle
> 
> 2009/10/20 francisco porfirio 
> 
> >
> >
> > Bom Dia Pessoal,
> >
> > Estou querendo colocar minha aplicação em um schema que possui apenas
> > synonyms privados com permissão de insert, delete, update e select, com o
> > objetivo de esconder totalmente a senha do schema principal.
> >
> > Alguém sabe informar sobre a performance deste tipo de synonyms em ambiente
> > de produção, onde a aplicação manipula dados através dele?
> > E em ambiente RAC ele funciona normalmente?
> >
> > Versão do oracle 10.2.4.0.
> >
> > --
> > Atenciosamente
> > Francisco Porfirio Ribeiro Neto
> >
> > [As partes desta mensagem que não continham texto foram removidas]
> >
> >  
> >
> 
> 
> [As partes desta mensagem que não continham texto foram removidas]
>

[oracle_br] Re: Performance X case-sensitive

[gibajr]

--- Em oracle_br@yahoogrupos.com.br, "gibajr"  escreveu
>
> Colegas,
> 
> Preciso desabilitar o case-sensitive, ou criar indice CONTEXT, em 
> campos de algumas tabelas na minha base. A dúvida é se isso terá 
> impacto no desempenho das consultas realizadas nesta tabela.
> 
> Grato,
> 
> Gilberto
>


Bem,

Desculpem não ter informado qual é o banco.
Oracle Enterprise 10.2.1 rodando numa máquina com 3 processadores e 8 
GB de memória, linux RedHat e com storage de dados.

Mais detalhes do Problema:
Recebi o pedido do gerente de desenvolvimento querendo que toda a 
base fosse case-insensitive. Assim em qualquer campo em qulquer 
tabela pudesse fazer uma busca sem se preocupar se existe um índice 
case-insensitive.

A Base: 
Nesta base as chaves primárias das tabelas são geradas pela função 
SYS_GUID do Oracle, que gera um valor em formato string de 16 bytes 
aleatórios e único.

Minha dúvida: 
Se existir uma forma de "desabilitar" o case-sensitive do banco, será 
que vou ter uma perda de performance na base toda? Compo todas as 
chaves são CHAR(36) eles também serão case-insensitive e isso pode 
prejudicar o desempenho dos índices? É uma boa prática, se possível, 
desabilitar o case-sensitive da base?

Obrigado a todos,
Gilberto 

[oracle_br] Re: Performance X case-sensitive

[jlchiappa]

Colega, isso TOTALMENTE DEPENDE da versão EXATA de banco que vc tem E
dos detalhes da estratégia que vc vai adotar, mas como ambos os pontos
vc só pra variar não nos dá, o que podemos dizer é :

 a) SE for banco 10g, vc tem a opção de usar characterset CI (case
insensitive), em termos de performance a penalidade deve ser muito
leve, apenas uma pequena porção de CPU a mais sendo usada para a
conversão de characterset, já que certamente não deve ser CI o default
usado pelo seu cliente

 b) em qquer versão de banco que suporte, índice de contexto ** não **
faz muito sentido, creio, pois ele serve mais para pesquisas com
operadores especiais tipo CONTAINS, imagino que vc adotaria como
estratégia uma função "comum" como UPPER nos seus SQLs, aí o índice a
ser adotada deve ser um COM A FUNÇÃO ESCOLHIDA (função UPPER no meu
exemplo), seria um índice b*tree DE FUNÇÃO portanto. A interferência
de índices b*tree é primeiro que eles tem que ser atualizados a cada
DML (o que PODE ser significativo se a sua máquina já estiver
"atolada", quaisquer processos extras induzem a mais concorrência) , e
segundo o fato de que outros SQLs podem talvez vir a adotar esse
índice em detrimento de outros, o que PODE causar um plano diferente

 c) as opções de case-insentive que se adotava antigamente a nível de
banco , antes do 10g com CI e antes do índice de função (ie, trigger
 que alimentava uma coluna não-acessível ao usuário que continha o
UPPER da coluna normal), tem impacto diretamente relativo e
proporcional à quantidade de colunas a manter 

 d) a possibilidade de se ter o CI feito pela aplicação (propriedade
Case-restriction num item dum bloco Forms, por exemplo, para
aplicaçãoes desenvolvidas em Oracle Forms, mas diversas outras
tools/linguagens tem opções do tipo) é a que traz o menor impacto no
banco em si, o impacto pass a ser na camada extra-banco do aplicativo

[]s

 Chiappa
--- Em oracle_br@yahoogrupos.com.br, "gibajr"  escreveu
>
> Colegas,
> 
> Preciso desabilitar o case-sensitive, ou criar indice CONTEXT, em 
> campos de algumas tabelas na minha base. A dúvida é se isso terá 
> impacto no desempenho das consultas realizadas nesta tabela.
> 
> Grato,
> 
> Gilberto
>

Re: [oracle_br] Re: Performance e Tunning

[Yahoo_Jefferson]

Boa tarde,

Só de ter dado essas referências vc já ajudou sim!!

Muito Obrigado e Boas Festas de Fim de Ano

Att,

Jefferson Sela


*De:* "rei_do_delphi" 
*Data:* 12/12/2008 1:04:07 PM -0300
*Para:* oracle_br@yahoogrupos.com.br
*Assunto:* [oracle_br] Re: Performance e Tunning

> Jefferson, boa tarde!
>
> Acredito, que o melhor caminho seria você se basear no Manual
> Concepts e no de Tunning da própria Oracle.
>
> Mas, existem livros muito bons também, onde mostram isso sendo
> aplicado de verdade! Entre eles, posso te dar como referência:
>
> Expert Oracle Database Architecture - Apress - Thyomas Kyte
>
> Oracle Wait Interface - A Pratical Guide for Performance and Tuning -
> Oracle Press - O autor é o Gopalash ( ou algo assim)
>
> e o famoso Optimizing Oracle Performance do Milsap - O´Reilley.
>
> Estes dois de baixo você encontra no site:
>
> www.pdfchm.com ==> só se registrar, quando achar o link do livro que
> deseja, não clique em cima foto. Procure logo abaixo, bem pequeno um
> link para fazer login.
>
> Espero ter ajudado. Abraços,
>
> --- Em oracle_br@yahoogrupos.com.br 
> <mailto:oracle_br%40yahoogrupos.com.br>, Yahoo_Jefferson
>  escreveu
> >
> > Bom dia à todos,
> >
> > Estou finalizando minha pós graduação em Banco de Dados na Fesp-
> Pr, em
> > Curitiba, e comecei o meu projeto final que vai ser sobre
> performance e
> > tunning no sistema onde trabalho.
> >
> > Gostaria de saber se o pessoal do grupo poderia me indicar alguns
> > livros, sites, etc, para que eu possa estar desenvolvendo a
> > fundamentação teórica da minha monografia.
> >
> > Agradeço desde já.
> >
> > Jefferson Sela.
> >
>
>  

[oracle_br] Re: Performance e Tunning

[rei_do_delphi]

Jefferson, boa tarde! 

Acredito, que o melhor caminho seria você se basear no Manual 
Concepts e no de Tunning da própria Oracle.

Mas, existem livros muito bons também, onde mostram isso sendo 
aplicado de verdade! Entre eles, posso te dar como referência:

Expert Oracle Database Architecture - Apress - Thyomas Kyte

Oracle Wait Interface - A Pratical Guide for Performance and Tuning -
 Oracle Press - O autor é o Gopalash ( ou algo assim)

e o famoso Optimizing Oracle Performance do Milsap - O´Reilley.

Estes dois de baixo você encontra no site:

www.pdfchm.com ==> só se registrar, quando achar o link do livro que 
deseja, não clique em cima foto. Procure logo abaixo, bem pequeno um 
link para fazer login.

Espero ter ajudado. Abraços,



--- Em oracle_br@yahoogrupos.com.br, Yahoo_Jefferson 
 escreveu
>
> Bom dia à todos,
> 
> Estou finalizando minha pós graduação em Banco de Dados na Fesp-
Pr, em 
> Curitiba, e comecei o meu projeto final que vai ser sobre 
performance e 
> tunning no sistema onde trabalho.
> 
> Gostaria de saber se o pessoal do grupo poderia me indicar alguns 
> livros, sites, etc, para que eu possa estar desenvolvendo a 
> fundamentação teórica da minha monografia.
> 
> Agradeço desde já.
> 
> Jefferson Sela.
>

Re: [oracle_br] Re: Performance dos relatorios-ajuda

[Kenia Milene]

Olha ... acho que a questao hardware tb é consideravel viu ...
Muitas vezes voce tem um banco com uma carga muito alta de acesso com um
hardware precario 

Kenia

2008/10/27 Ricardo Portilho Proni <[EMAIL PROTECTED]>

>   Este alter session está restrito a esta sessão apenas.
> Se vc colocar no Report, todo mundo vai gerar trace, então é melhor
> gerar só com voce no sistema.
>
> Com poucos usuários no banco, a performance será melhor, mas vc ainda
> verá o problema raiz, pode acreditar.
>
>
> Ricardo Portilho Proni
> Coordenador de Bancos de Dados - Solvo S/A
> - Oracle Database 10g Administrator Certified Professional (OCP)
> - Microsoft Certified Professional (MCP)
> - Microsoft Certified Technologt Specialist: SQL Server 2005 (MCTS)
>
> Em Seg, 2008-10-27 às 21:25 +, urubullino escreveu:
>
> > Caro Ricardo,
> > antes de tudo obrigado.
> > Nao seria interessante colocar o trace no
> > na trigger 'before report' do Reports?
> > Poderia ficar assim?
> > srw.do_sql('ALTER SESSION SET TRACEFILE_IDENTIFIER =
> > "RelatorioLentoQueSoEle"' );
> > srw.do_sql('ALTER SESSION SET TIMED_STATISTICS = TRUE');
> > srw.do_sql('ALTER SESSION SET EVENTS "10046 trace name context
> > forever, level 12");
> >
> > alguma coisa no 'after report' ?
> >
> > Uma pergunta...Esse alter session está restrito ao usuario solicitante
> > do relatorio? Pq nao adiantaria tanto se tiver outros usuarios tambem
> > fazendo consultas no banco.
> >
> > Falando em acessos, suponho que poucos usuarios acessando o banco, a
> > performance seria melhor; enquanto se muitos usuarios estiverem
> > acessando , seria pior . Como analisar isso? Eu teria que fazer o
> > trace depois do horario de expediente, quando ninguem estaria usando o
> > sistema? E depois, como avaliar se a quantidade de acessos estaria
> > compromentando a performance. E mais tarde, como melhorar isso, caso
> > seja comprovado esse problema?
> >
> > Obrigado mais uma vez e desculpe por tantas duvidas
> >
> > --- Em oracle_br@yahoogrupos.com.br ,
> Ricardo Portilho Proni
> > <[EMAIL PROTECTED]> escreveu
> > >
> > > Oi.
> > >
> > > Como um colega já disse aqui, antes de solucionar o problema de
> > > performance, você precisa ter certeza onde o TEMPO deste relatório
> > está
> > > sendo gasto.
> > >
> > > Você consegue rodar este relatório com trace?
> > > Para isso, uma das formas é colocar isso antes do SELECT que faz
> > este
> > > relatório:
> > >
> > > ALTER SESSION SET TRACEFILE_IDENTIFIER = 'RelatorioLentoQueSoEle';
> > > ALTER SESSION SET TIMED_STATISTICS = TRUE;
> > > ALTER SESSION SET EVENTS '10046 trace name context forever, level
> > 12';
> > >
> > > Depois que ele terminar, procure pelo arquivo com
> > RelatorioLentoQueSoEle
> > > no nome, e execute:
> > >
> > > tkprof arquivo
> > >
> > > E coloque o resultado aqui pra gente.
> > >
> > >
> > >
> > > Ricardo Portilho Proni
> > > Coordenador de Bancos de Dados - Solvo S/A
> > > - Oracle Database 10g Administrator Certified Professional (OCP)
> > > - Microsoft Certified Professional (MCP)
> > > - Microsoft Certified Technologt Specialist: SQL Server 2005 (MCTS)
> > >
> > >
> > >
> > >
> > > Em Sáb, 2008-10-25 às 16:30 +, urubullino escreveu:
> > > > Oi pra todos.
> > > > não conheco muita coisa de oracle mas aqui vai um problema que
> > nunca
> > > > deixou o sistema em que trabalho...
> > > > Temos uma aplicacao com inumeras tabelas e muuuiitos registros.
> > Usamos
> > > > o Oracle Reports e em muitos casos os relatórios demoram uma
> > > > eternidade para serem executados, em torno de HORAS...
> > > > Por pesquisa cheguei a conclusao que uma view materializada
> > poderia
> > > > resolver o assunto , o Report iria acessar essa view . Mas o
> > usuario
> > > > quer ver essa informacao quase que instantaneamente quando a mesma
> > é
> > > > inserida ou modificada. A view materialized seria mesmo a melhor
> > opcao
> > > > ou teria outra, mesmo com ferramentas de terceiros ?
> > > > Para dar uma acelerada ainda maior , também estou estudando outros
> > > > geradores de relatorios que possam executar a tarefa mais rapido
> > que o
> > > > Oracle Reports... Alguma dica?
> > > >
> > > > Obrigado a todos.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > > [As partes desta mensagem que não continham texto foram removidas]
> > >
> >
> >
> >
> >
> >
> >
>
> [As partes desta mensagem que não continham texto foram removidas]
>
>  
>



-- 
Kenia Milene C. Galiego
DataBase Administrator
Oracle / PostgreSQL / MySql / SQL Server
Email: [EMAIL PROTECTED]
Blog: http://keniamilene.wordpress.com


[As partes desta mensagem que não continham texto foram removidas]

Re: [oracle_br] Re: Performance dos relatorios-ajuda

[Ricardo Portilho Proni]

Este alter session está restrito a esta sessão apenas.
Se vc colocar no Report, todo mundo vai gerar trace, então é melhor
gerar só com voce no sistema.

Com poucos usuários no banco, a performance será melhor, mas vc ainda
verá o problema raiz, pode acreditar.


Ricardo Portilho Proni
Coordenador de Bancos de Dados - Solvo S/A
- Oracle Database 10g Administrator Certified Professional (OCP)
- Microsoft Certified Professional (MCP)
- Microsoft Certified Technologt Specialist: SQL Server 2005 (MCTS)




Em Seg, 2008-10-27 às 21:25 +, urubullino escreveu:
> Caro Ricardo,
> antes de tudo obrigado.
> Nao seria interessante colocar o trace no 
> na trigger 'before report' do Reports?
> Poderia ficar assim?
> srw.do_sql('ALTER SESSION SET TRACEFILE_IDENTIFIER =
> "RelatorioLentoQueSoEle"' );
> srw.do_sql('ALTER SESSION SET TIMED_STATISTICS = TRUE');
> srw.do_sql('ALTER SESSION SET EVENTS "10046 trace name context
> forever, level 12");
> 
> alguma coisa no 'after report' ?
> 
> Uma pergunta...Esse alter session está restrito ao usuario solicitante
> do relatorio? Pq nao adiantaria tanto se tiver outros usuarios tambem
> fazendo consultas no banco.
> 
> Falando em acessos, suponho que poucos usuarios acessando o banco, a
> performance seria melhor; enquanto se muitos usuarios estiverem
> acessando , seria pior . Como analisar isso? Eu teria que fazer o
> trace depois do horario de expediente, quando ninguem estaria usando o
> sistema? E depois, como avaliar se a quantidade de acessos estaria
> compromentando a performance. E mais tarde, como melhorar isso, caso
> seja comprovado esse problema?
> 
> Obrigado mais uma vez e desculpe por tantas duvidas
> 
> --- Em oracle_br@yahoogrupos.com.br, Ricardo Portilho Proni
> <[EMAIL PROTECTED]> escreveu
> >
> > Oi.
> > 
> > Como um colega já disse aqui, antes de solucionar o problema de
> > performance, você precisa ter certeza onde o TEMPO deste relatório
> está
> > sendo gasto.
> > 
> > Você consegue rodar este relatório com trace?
> > Para isso, uma das formas é colocar isso antes do SELECT que faz
> este
> > relatório:
> > 
> > ALTER SESSION SET TRACEFILE_IDENTIFIER = 'RelatorioLentoQueSoEle';
> > ALTER SESSION SET TIMED_STATISTICS = TRUE;
> > ALTER SESSION SET EVENTS '10046 trace name context forever, level
> 12';
> > 
> > Depois que ele terminar, procure pelo arquivo com
> RelatorioLentoQueSoEle
> > no nome, e execute:
> > 
> > tkprof arquivo
> > 
> > E coloque o resultado aqui pra gente.
> > 
> > 
> > 
> > Ricardo Portilho Proni
> > Coordenador de Bancos de Dados - Solvo S/A
> > - Oracle Database 10g Administrator Certified Professional (OCP)
> > - Microsoft Certified Professional (MCP)
> > - Microsoft Certified Technologt Specialist: SQL Server 2005 (MCTS)
> > 
> > 
> > 
> > 
> > Em Sáb, 2008-10-25 às 16:30 +, urubullino escreveu:
> > > Oi pra todos.
> > > não conheco muita coisa de oracle mas aqui vai um problema que
> nunca
> > > deixou o sistema em que trabalho...
> > > Temos uma aplicacao com inumeras tabelas e muuuiitos registros.
> Usamos
> > > o Oracle Reports e em muitos casos os relatórios demoram uma
> > > eternidade para serem executados, em torno de HORAS...
> > > Por pesquisa cheguei a conclusao que uma view materializada
> poderia
> > > resolver o assunto , o Report iria acessar essa view . Mas o
> usuario
> > > quer ver essa informacao quase que instantaneamente quando a mesma
> é
> > > inserida ou modificada. A view materialized seria mesmo a melhor
> opcao
> > > ou teria outra, mesmo com ferramentas de terceiros ?
> > > Para dar uma acelerada ainda maior , também estou estudando outros
> > > geradores de relatorios que possam executar a tarefa mais rapido
> que o
> > > Oracle Reports... Alguma dica?
> > > 
> > > Obrigado a todos. 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > 
> > 
> > [As partes desta mensagem que não continham texto foram removidas]
> >
> 
> 
> 
> 
> 
>  


[As partes desta mensagem que não continham texto foram removidas]

Re: [oracle_br] Re: Performance dos relatorios-ajuda

[Ricardo Portilho Proni]

O trace irá te dizer se o problema é na rede também.

Ricardo Portilho Proni
Coordenador de Bancos de Dados - Solvo S/A
- Oracle Database 10g Administrator Certified Professional (OCP)
- Microsoft Certified Professional (MCP)
- Microsoft Certified Technologt Specialist: SQL Server 2005 (MCTS)




Em Seg, 2008-10-27 às 21:55 +, urubullino escreveu:
> Opa, esqueci de mais uma:
> E como fica a avaliacao de outros quesitos como: rede, maquina,..., na
> execução do report? Nao adianta ter tudo perfeito com um servidor
> lento ou uma rede horrivel .
> 
> Obrigado
> 
> --- Em oracle_br@yahoogrupos.com.br, Ricardo Portilho Proni
> <[EMAIL PROTECTED]> escreveu
> >
> > Oi.
> > 
> > Como um colega já disse aqui, antes de solucionar o problema de
> > performance, você precisa ter certeza onde o TEMPO deste relatório
> está
> > sendo gasto.
> > 
> > Você consegue rodar este relatório com trace?
> > Para isso, uma das formas é colocar isso antes do SELECT que faz
> este
> > relatório:
> > 
> > ALTER SESSION SET TRACEFILE_IDENTIFIER = 'RelatorioLentoQueSoEle';
> > ALTER SESSION SET TIMED_STATISTICS = TRUE;
> > ALTER SESSION SET EVENTS '10046 trace name context forever, level
> 12';
> > 
> > Depois que ele terminar, procure pelo arquivo com
> RelatorioLentoQueSoEle
> > no nome, e execute:
> > 
> > tkprof arquivo
> > 
> > E coloque o resultado aqui pra gente.
> > 
> > 
> > 
> > Ricardo Portilho Proni
> > Coordenador de Bancos de Dados - Solvo S/A
> > - Oracle Database 10g Administrator Certified Professional (OCP)
> > - Microsoft Certified Professional (MCP)
> > - Microsoft Certified Technologt Specialist: SQL Server 2005 (MCTS)
> > 
> > 
> > 
> > 
> > Em Sáb, 2008-10-25 às 16:30 +, urubullino escreveu:
> > > Oi pra todos.
> > > não conheco muita coisa de oracle mas aqui vai um problema que
> nunca
> > > deixou o sistema em que trabalho...
> > > Temos uma aplicacao com inumeras tabelas e muuuiitos registros.
> Usamos
> > > o Oracle Reports e em muitos casos os relatórios demoram uma
> > > eternidade para serem executados, em torno de HORAS...
> > > Por pesquisa cheguei a conclusao que uma view materializada
> poderia
> > > resolver o assunto , o Report iria acessar essa view . Mas o
> usuario
> > > quer ver essa informacao quase que instantaneamente quando a mesma
> é
> > > inserida ou modificada. A view materialized seria mesmo a melhor
> opcao
> > > ou teria outra, mesmo com ferramentas de terceiros ?
> > > Para dar uma acelerada ainda maior , também estou estudando outros
> > > geradores de relatorios que possam executar a tarefa mais rapido
> que o
> > > Oracle Reports... Alguma dica?
> > > 
> > > Obrigado a todos. 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > 
> > 
> > [As partes desta mensagem que não continham texto foram removidas]
> >
> 
> 
> 
> 
> 
>  


[As partes desta mensagem que não continham texto foram removidas]

[oracle_br] Re: Performance dos relatorios-ajuda

[urubullino]

Opa, esqueci de mais uma:
E como fica a avaliacao de outros quesitos como: rede, maquina,..., na
execução do report? Nao adianta ter tudo perfeito com um servidor
lento ou uma rede horrivel .

Obrigado



--- Em oracle_br@yahoogrupos.com.br, Ricardo Portilho Proni
<[EMAIL PROTECTED]> escreveu
>
> Oi.
> 
> Como um colega já disse aqui, antes de solucionar o problema de
> performance, você precisa ter certeza onde o TEMPO deste relatório está
> sendo gasto.
> 
> Você consegue rodar este relatório com trace?
> Para isso, uma das formas é colocar isso antes do SELECT que faz este
> relatório:
> 
> ALTER SESSION SET TRACEFILE_IDENTIFIER = 'RelatorioLentoQueSoEle';
> ALTER SESSION SET TIMED_STATISTICS = TRUE;
> ALTER SESSION SET EVENTS '10046 trace name context forever, level 12';
> 
> Depois que ele terminar, procure pelo arquivo com RelatorioLentoQueSoEle
> no nome, e execute:
> 
> tkprof arquivo
> 
> E coloque o resultado aqui pra gente.
> 
> 
> 
> Ricardo Portilho Proni
> Coordenador de Bancos de Dados - Solvo S/A
> - Oracle Database 10g Administrator Certified Professional (OCP)
> - Microsoft Certified Professional (MCP)
> - Microsoft Certified Technologt Specialist: SQL Server 2005 (MCTS)
> 
> 
> 
> 
> Em Sáb, 2008-10-25 às 16:30 +, urubullino escreveu:
> > Oi pra todos.
> > não conheco muita coisa de oracle mas aqui vai um problema que nunca
> > deixou o sistema em que trabalho...
> > Temos uma aplicacao com inumeras tabelas e muuuiitos registros. Usamos
> > o Oracle Reports e em muitos casos os relatórios demoram uma
> > eternidade para serem executados, em torno de HORAS...
> > Por pesquisa cheguei a conclusao que uma view materializada poderia
> > resolver o assunto , o Report iria acessar essa view . Mas o usuario
> > quer ver essa informacao quase que instantaneamente quando a mesma é
> > inserida ou modificada. A view materialized seria mesmo a melhor opcao
> > ou teria outra, mesmo com ferramentas de terceiros ?
> > Para dar uma acelerada ainda maior , também estou estudando outros
> > geradores de relatorios que possam executar a tarefa mais rapido que o
> > Oracle Reports... Alguma dica?
> > 
> > Obrigado a todos. 
> > 
> > 
> > 
> > 
> > 
> >  
> 
> 
> [As partes desta mensagem que não continham texto foram removidas]
>

[oracle_br] Re: Performance dos relatorios-ajuda

[urubullino]

Caro Ricardo,
antes de tudo obrigado.
Nao seria interessante colocar o trace no 
na trigger 'before report' do Reports?
Poderia ficar assim?
srw.do_sql('ALTER SESSION SET TRACEFILE_IDENTIFIER =
"RelatorioLentoQueSoEle"' );
srw.do_sql('ALTER SESSION SET TIMED_STATISTICS = TRUE');
srw.do_sql('ALTER SESSION SET EVENTS "10046 trace name context
forever, level 12");

alguma coisa no 'after report' ?

Uma pergunta...Esse alter session está restrito ao usuario solicitante
do relatorio? Pq nao adiantaria tanto se tiver outros usuarios tambem
fazendo consultas no banco.

Falando em acessos, suponho que poucos usuarios acessando o banco, a
performance seria melhor; enquanto se muitos usuarios estiverem
acessando , seria pior . Como analisar isso? Eu teria que fazer o
trace depois do horario de expediente, quando ninguem estaria usando o
sistema? E depois, como avaliar se a quantidade de acessos estaria
compromentando a performance. E mais tarde, como melhorar isso, caso
seja comprovado esse problema?

Obrigado mais uma vez e desculpe por tantas duvidas




--- Em oracle_br@yahoogrupos.com.br, Ricardo Portilho Proni
<[EMAIL PROTECTED]> escreveu
>
> Oi.
> 
> Como um colega já disse aqui, antes de solucionar o problema de
> performance, você precisa ter certeza onde o TEMPO deste relatório está
> sendo gasto.
> 
> Você consegue rodar este relatório com trace?
> Para isso, uma das formas é colocar isso antes do SELECT que faz este
> relatório:
> 
> ALTER SESSION SET TRACEFILE_IDENTIFIER = 'RelatorioLentoQueSoEle';
> ALTER SESSION SET TIMED_STATISTICS = TRUE;
> ALTER SESSION SET EVENTS '10046 trace name context forever, level 12';
> 
> Depois que ele terminar, procure pelo arquivo com RelatorioLentoQueSoEle
> no nome, e execute:
> 
> tkprof arquivo
> 
> E coloque o resultado aqui pra gente.
> 
> 
> 
> Ricardo Portilho Proni
> Coordenador de Bancos de Dados - Solvo S/A
> - Oracle Database 10g Administrator Certified Professional (OCP)
> - Microsoft Certified Professional (MCP)
> - Microsoft Certified Technologt Specialist: SQL Server 2005 (MCTS)
> 
> 
> 
> 
> Em Sáb, 2008-10-25 às 16:30 +, urubullino escreveu:
> > Oi pra todos.
> > não conheco muita coisa de oracle mas aqui vai um problema que nunca
> > deixou o sistema em que trabalho...
> > Temos uma aplicacao com inumeras tabelas e muuuiitos registros. Usamos
> > o Oracle Reports e em muitos casos os relatórios demoram uma
> > eternidade para serem executados, em torno de HORAS...
> > Por pesquisa cheguei a conclusao que uma view materializada poderia
> > resolver o assunto , o Report iria acessar essa view . Mas o usuario
> > quer ver essa informacao quase que instantaneamente quando a mesma é
> > inserida ou modificada. A view materialized seria mesmo a melhor opcao
> > ou teria outra, mesmo com ferramentas de terceiros ?
> > Para dar uma acelerada ainda maior , também estou estudando outros
> > geradores de relatorios que possam executar a tarefa mais rapido que o
> > Oracle Reports... Alguma dica?
> > 
> > Obrigado a todos. 
> > 
> > 
> > 
> > 
> > 
> >  
> 
> 
> [As partes desta mensagem que não continham texto foram removidas]
>

[oracle_br] Re: Performance dos relatorios-ajuda

[urubullino]

Caro Eduardo , como vc pode ter visto as mensagens foram mandadas em
horarios diferentes. Estava mandando a mensagem e ela nao aparecia na
listagem. Hoje é  aprimeira vez que a vi aqui.
De qq forma desculpe o transtorno .

Falando sobre o assunto, o Reports que uso é antigo , vesao 3 se nao
me engano, mas acho que vamos mudar para 9. Perguntei sobre a troca de
ferramenta porque tinha um consultor que aqui na empresa e falava que
o Reports perde um certo tempo construindo o layout. Já o Discoverer
(exemplo dado por ele) executa isso muito mais rapido, porém essa
ferramenta é muito limitada nessa parte de layout.
Teria como me enviar alguma pagina que dê dicas de como realizar o
trace. Como disse sou leigo em Oracle.

Muito obrigado pela ajuda.





--- Em oracle_br@yahoogrupos.com.br, "Claro, Eduardo"
<[EMAIL PROTECTED]> escreveu
>
> Amigo,
> 
> Acho que uma primeira dica seria mandar apenas um e-mail, e não três
com o mesmo conteúdo e títulos diferentes como você fez. Isso acaba
poluindo as mensagens do grupo, que já são muitas, ok? ;-)
> 
> Se os seus relatórios estão com esta performance tão ruim, é muito
provável que recaia em um ou mais dos seguintes itens:
> 
> 1. Queries mal-escritas dentro dos relatórios. Podem ser consultas
que evitam o uso de índices (modo de escrita da query), ou lêem mais
do que o necessário (falta de restrições), etc, etc.
> 
> 2. Falta de objetos de performance no banco de dados (especialmente
índices, mas também entram aqui as Views Materializadas).
> 
> 3. Falta de estatísticas dos objetos, ou estatísticas obsoletas.
> 
> Seria interessante gerar trace de algum destes relatórios, formatar
o trace com o tkprof e analisar o resultado. Assim, talvez possamos
ajudar melhor.
> 
> Quanto à troca de ferramenta, a princípio não acredito ser o caso. O
Reports é uma ferramenta que te permite escrever as queries dos
relatórios, e portanto a performance será ditada pelo que você
escrever, e não pela ferramenta em si.
> 
> []s
> 
> --
> Eduardo Claro
> 
> -Original Message-
> From: oracle_br@yahoogrupos.com.br
[mailto:[EMAIL PROTECTED] On Behalf Of urubullino
> Sent: sábado, 25 de outubro de 2008 14:30
> To: oracle_br@yahoogrupos.com.br
> Subject: [oracle_br] Performance dos relatorios-ajuda
> 
> Oi pra todos.
> não conheco muita coisa de oracle mas aqui vai um problema que nunca
> deixou o sistema em que trabalho...
> Temos uma aplicacao com inumeras tabelas e muuuiitos registros. Usamos
> o Oracle Reports e em muitos casos os relatórios demoram uma
> eternidade para serem executados, em torno de HORAS...
> Por pesquisa cheguei a conclusao que uma view materializada poderia
> resolver o assunto , o Report iria acessar essa view . Mas o usuario
> quer ver essa informacao quase que instantaneamente quando a mesma é
> inserida ou modificada. A view materialized seria mesmo a melhor opcao
> ou teria outra, mesmo com ferramentas de terceiros ?
> Para dar uma acelerada ainda maior , também estou estudando outros
> geradores de relatorios que possam executar a tarefa mais rapido que o
> Oracle Reports... Alguma dica?
> 
> Obrigado a todos. 
> 
> 
> 
> 
>
--
> >Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de
inteira responsabilidade de seus remetentes.
> Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ 
>
--
> >Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package »
Procedure » Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO
ESPAÇO! VISITE: http://www.oraclebr.com.br/  
>

Links do Yahoo! Grupos
>

Res: [oracle_br] Re: Performance COBOL x ORACLE 10G

[Anderson Santiago]

Tá usando OCI certo, já tentou fazer algum tunning específico sobre esse tipo 
de conexão?
Outra coisa...tudo fica lento ou selects?? insert , update é normal?
Já tentou fazer um trace dessa sessão que demora muito?
Qual o comportamento do servidor quando fica lento?? muito IO ou muito 
processamento?
Att.
Anderson


- Mensagem original 
De: Osmar Junqueira <[EMAIL PROTECTED]>
Para: oracle_br@yahoogrupos.com.br
Enviadas: Sexta-feira, 13 de Junho de 2008 21:05:06
Assunto: [oracle_br] Re: Performance COBOL x ORACLE 10G


Oi Marcos, obrigado por ter atendido,

então é o seguinte o COBOL é microfocus rodando em um servidor unix 
solaris e estamos rodando estes programas cobol no proprio servidor, 
eles sao precompilados com os drives do oracle em um outro servidor 
de desenvolvimento com a mesma caracteristicas de ORACLE, apenas não 
é ambiente RAC. Segundo o pessoal aqui disseram que estes programas 
estão realmente lentos por conta da fragmentação de memoria, causada 
pelos aplicativos externos (on-line), o fato é que quando aplicamos 
um flush no oracle, ele até roda mais rapido e vai caindo o 
processamento a medida que executamos os programas em sequencia, mas 
não acredito que este pode ser a causa raiz destes problemas de 
lentidão, te digo isto porque a mesma query que rodamos no cobol 
rodamos ela manualmente no SQLPLUS, ela roda muito rapido retornando 
os resultados.

Você acha que isto pode ser um problema de fragmentação de memoria? 
ou alguma parametrização especifica para utilização do COBOL com o 
ORACLE10G.

Grato,

--- Em [EMAIL PROTECTED] os.com.br, Marco Souza <[EMAIL PROTECTED] .> 
escreveu
>
> Osmar,
> 
> Segundo informações deles, estes programas executavam rapidamente 
usando oracle ?
> Qual tipo de conexão que o cobol usa pra acessar o oracle ? Ele 
roda no servidor  ou no cliente ?
> Pela sua mensagem, suponho que a conexão com o banco não é feita 
pelo oracle client, certo ?
> 
> Grande abraço.
> 
> 
> --- Em ter, 10/6/08, Osmar Junqueira [EMAIL PROTECTED] escreveu:
> De: Osmar Junqueira [EMAIL PROTECTED]
> Assunto: [oracle_br] Performance COBOL x ORACLE 10G
> Para: [EMAIL PROTECTED] os.com.br
> Data: Terça-feira, 10 de Junho de 2008, 20:36
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Pessoal,
> 
> 
> 
> Estou com serios problemas performance de execução de programas em 
> 
> COBOL com o ORACLE10G RAC, estes programas são de terceiros e 
segundo 
> 
> informações deles os mesmos programas são executados rapidos em 
outro 
> 
> ambiente UNIX. Gostaria de saber se alguem tem problemas com 
programas 
> 
> cobol utilizando banco de dados em UNIX solaris, e se existem 
> 
> configurações especificas para este tipo de software
> 
> 
> 
> Grato,
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Abra sua conta no Yahoo! Mail, o único sem limite de espaço 
para armazenamento!
> http://br.mail. yahoo.com/
> 
> [As partes desta mensagem que não continham texto foram removidas]
>

 


  Abra sua conta no Yahoo! Mail, o único sem limite de espaço para 
armazenamento!
http://br.mail.yahoo.com/

[As partes desta mensagem que não continham texto foram removidas]

[oracle_br] Re: Performance COBOL x ORACLE 10G

[Osmar Junqueira]

Oi Marcos, obrigado por ter atendido,

então é o seguinte o COBOL é microfocus  rodando em um servidor unix 
solaris e estamos rodando estes programas cobol no proprio servidor, 
eles sao precompilados com os drives do oracle em um outro servidor 
de desenvolvimento com a mesma caracteristicas de ORACLE, apenas não 
é ambiente RAC. Segundo o pessoal aqui disseram que estes programas 
estão realmente lentos por conta da fragmentação de memoria, causada 
pelos aplicativos externos (on-line), o fato é que quando aplicamos 
um flush no oracle, ele até roda mais rapido e vai caindo o 
processamento a medida que executamos os programas em sequencia, mas 
não acredito que este pode ser a causa raiz destes problemas de 
lentidão, te digo isto porque a mesma query que rodamos no cobol 
rodamos ela manualmente no SQLPLUS, ela roda muito rapido retornando 
os resultados.

Você acha que isto pode ser um problema de fragmentação de memoria? 
ou alguma parametrização especifica para utilização do COBOL com o 
ORACLE10G.

Grato,

--- Em oracle_br@yahoogrupos.com.br, Marco Souza <[EMAIL PROTECTED]> 
escreveu
>
> Osmar,
> 
> Segundo informações deles, estes programas executavam rapidamente 
usando oracle ?
> Qual tipo de conexão que o cobol usa pra acessar o oracle ? Ele 
roda no servidor  ou no cliente ?
> Pela sua mensagem, suponho que a conexão com o banco não é feita 
pelo oracle client, certo ?
> 
> Grande abraço.
> 
> 
> --- Em ter, 10/6/08, Osmar Junqueira [EMAIL PROTECTED] escreveu:
> De: Osmar Junqueira [EMAIL PROTECTED]
> Assunto: [oracle_br] Performance COBOL x ORACLE 10G
> Para: oracle_br@yahoogrupos.com.br
> Data: Terça-feira, 10 de Junho de 2008, 20:36
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Pessoal,
> 
> 
> 
> Estou com serios problemas performance de execução de programas em 
> 
> COBOL com o ORACLE10G RAC, estes programas são de terceiros e 
segundo 
> 
> informações deles os mesmos programas são executados rapidos em 
outro 
> 
> ambiente UNIX. Gostaria de saber se alguem tem problemas com 
programas 
> 
> cobol utilizando banco de dados em UNIX solaris, e se existem 
> 
> configurações especificas para este tipo de software
> 
> 
> 
> Grato,
> 
> 
> 
> 
>   
> 
> 
> 
>   
>
>   
>   
> 
> 
> 
> 
> 
> 
> 
> 
>   
> 
> 
>   
>   
> 
> 
>   Abra sua conta no Yahoo! Mail, o único sem limite de espaço 
para armazenamento!
> http://br.mail.yahoo.com/
> 
> [As partes desta mensagem que não continham texto foram removidas]
>

[oracle_br] Re: :: Performance Oracle 10g

[Fernando]

Conforme dito, tem q identificar o problema primeiramente (gargalo).
Ver do que os usuários estão reclamando, se eh baixo throughput, baixo
tempo de resposta, tolerância falhas. Questoes de performance variam
muito. Também questão relevante é sobre tipo de banco de dados (OLTP,
data warehouse...) a aplicação de tecnicas variam muito.

Algumas dicas , acho q seguir os princípios listados em SHASHA(2003):

CINCO PRINCÍPIOS BÁSICOS
1. Pensar globalmente; corrigir (agir) localmente;
2. Particionar para resolver gargalos;
3. Inicialização tem um custo alto, execução não;
4. Coloque no servidor apenas o que diz respeito ao servidor
5. Esteja pronto para trade-offs ("conflito de escolhas");

Menor custo pra melhorar performance está em mexer nas configuraçoes
de instalação (um bom começo). Outras questões dependem de onde está o
problema e do se deseja alcançar (os objetivos).

--- Em oracle_br@yahoogrupos.com.br, "Alexsandro Haag"
<[EMAIL PROTECTED]> escreveu
>
> Acho que para ajudar é preciso saber onde está o(s) gargalo(s).
> Já identificou?
> 
> Att.
> Alex
> 
> --- Em oracle_br@yahoogrupos.com.br, Marcos Pereira - Confederação
> SICREDI  escreveu
> >
> > Bom Dia senhores,
> > 
> >  
> > 
> > Possuímos um BD instalado em uma maquina virtual Linux , porém por
> mais que
> > a maquina seja boa , os usuários reclamam de performance no banco ,
> existe
> > alguma sugestão dos senhores para que possamos melhorar a
performance do
> > mesmo?
> > 
> >  
> > 
> > Atenciosamente.
> > 
> >  
> > 
> > Marcos V. B. Pereira
> > 
> > Adm. Dados & Objetos / Gestão de Configuração
> > 
> > Desenvolvimento de Software
> > 
> >  
> > 
> > 
> > As informacoes contidas neste e-mail e nos arquivos anexados podem
> ser informacoes confidenciais ou privilegiadas. Caso voce nao seja o
> destinatario correto, apague o conteudo desta mensagem e notifique o
> remetente imediatamente.
> > 
> > 
> > [As partes desta mensagem que não continham texto foram removidas]
> >
>

[oracle_br] Re: :: Performance Oracle 10g

[Anderson]

Marcos,

podem ser milhares de coisas

se fosse você começava habilitando o statspack e monitorando a base.

Se for um usuário mais básico, pode apelar pra alguma dessas 
ferramentas de monitoração tipo o Spotlight.

Esse tipo de coisa, realmente as vezes dá trabalho aos mais 
experientes, não sei o seu tipo de conhecimento, não parece ser muito 
grande em Administração de banco, por isso, talvez seja melhor se 
informar mais sobre o assunto lendo os manuais ou procurar ajuda 
especializada.

Att.

Anderson Santiago
DBA Sr.
www.ruevers.webs.com

--- Em oracle_br@yahoogrupos.com.br, "Alexsandro Haag" 
<[EMAIL PROTECTED]> escreveu
>
> Acho que para ajudar é preciso saber onde está o(s) gargalo(s).
> Já identificou?
> 
> Att.
> Alex
> 
> --- Em oracle_br@yahoogrupos.com.br, Marcos Pereira - Confederação
> SICREDI  escreveu
> >
> > Bom Dia senhores,
> > 
> >  
> > 
> > Possuímos um BD instalado em uma maquina virtual Linux , porém por
> mais que
> > a maquina seja boa , os usuários reclamam de performance no 
banco ,
> existe
> > alguma sugestão dos senhores para que possamos melhorar a 
performance do
> > mesmo?
> > 
> >  
> > 
> > Atenciosamente.
> > 
> >  
> > 
> > Marcos V. B. Pereira
> > 
> > Adm. Dados & Objetos / Gestão de Configuração
> > 
> > Desenvolvimento de Software
> > 
> >  
> > 
> > 
> > As informacoes contidas neste e-mail e nos arquivos anexados podem
> ser informacoes confidenciais ou privilegiadas. Caso voce nao seja o
> destinatario correto, apague o conteudo desta mensagem e notifique o
> remetente imediatamente.
> > 
> > 
> > [As partes desta mensagem que não continham texto foram removidas]
> >
>

[oracle_br] Re: :: Performance Oracle 10g

[Alexsandro Haag]

Acho que para ajudar é preciso saber onde está o(s) gargalo(s).
Já identificou?

Att.
Alex

--- Em oracle_br@yahoogrupos.com.br, Marcos Pereira - Confederação
SICREDI <[EMAIL PROTECTED]> escreveu
>
> Bom Dia senhores,
> 
>  
> 
> Possuímos um BD instalado em uma maquina virtual Linux , porém por
mais que
> a maquina seja boa , os usuários reclamam de performance no banco ,
existe
> alguma sugestão dos senhores para que possamos melhorar a performance do
> mesmo?
> 
>  
> 
> Atenciosamente.
> 
>  
> 
> Marcos V. B. Pereira
> 
> Adm. Dados & Objetos / Gestão de Configuração
> 
> Desenvolvimento de Software
> 
>  
> 
> 
> As informacoes contidas neste e-mail e nos arquivos anexados podem
ser informacoes confidenciais ou privilegiadas. Caso voce nao seja o
destinatario correto, apague o conteudo desta mensagem e notifique o
remetente imediatamente.
> 
> 
> [As partes desta mensagem que não continham texto foram removidas]
>

RE: [oracle_br] Re: Performance ( Insert Select via dblink)

[Adriano Cavalcanti]

Entao Chiappa, 

com o cursor eu quero garantir que os registros entrem na tabela, pois se der 
algum problema durante a leitura ou no banco , eu consigo inserir apartir do 
ultimo, e não inicio tudo novamente. 



Como resolvo isso ?




To: oracle_br@yahoogrupos.com.br
From: [EMAIL PROTECTED]
Date: Tue, 27 May 2008 22:15:48 +
Subject: [oracle_br] Re: Performance ( Insert Select via dblink)




















Colega, não acompanhei a thread toda, mas de cara já digo : COMMIT

frequente, a cada x registros, * NÃO É *, NUNCA foi e NUNCA

SERÁ a maneira melhor e mais performática de se processar um SQL, em

especial INSERTs,

http://asktom.oracle.com/pls/asktom/f?p=100:11:0P11_QUESTION_ID:4951966319022#4955604534852

 mostra exatamente isso E em sendo um único INSERT só com a query,

se a tabela-destino estiver como NOLOGGING, se durante o INSERT vc  vc

desligar as triggers, desativar os índices (NÂO é dropar!!), desativar

(ou ao menos ter as constraints validadas só no commit se der) E usar

um INSERT /*+ APPEND */, aposto um picolé de limão que a performance

assim vai ** HUMILHAR ** , *** ESMAGAR ***, * TRITURAR  a

performance da versão usando CURSOR e COMITs frequentes. No

workshop eu dei um exemplo simples, pequeno, aonde isso era

demonstrado, mas em ambiente de Produção o ganho (em não sendo gerado

quase nenhum redo log, nem undo) via de regra é fenomenalmente maior...



[]s



Chiappa



--- Em oracle_br@yahoogrupos.com.br, Adriano Cavalcanti <[EMAIL PROTECTED]>

escreveu

>

> é Isso eu tinha pensado. 

> Achei que tivesse algo mais performatico. 

> 

> como tenho 315 mil registro, acho melhor então fazer sempre uma

conta para pegar um quarto de registro  por commit. 

> 

> Mas valeu

> 

> 

> 

> To: oracle_br@yahoogrupos.com.br

> From: [EMAIL PROTECTED]

> Date: Tue, 27 May 2008 08:18:24 -0300

> Subject: Re: [oracle_br] Performance ( Insert Select via dblink)

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> 

> Adriano, você pode ter um contador dentro do loop do

cursor e quando o contador chegar a 50, você dá o commit e zera o

contador novamente. É isso que você precisa?

> 

> Márcio Ricardo Alves da Silva

> 

> Programador Pleno

> 

> Oracle Certified Associate 9i

> 

> * [EMAIL PROTECTED]

> 

> 

> 

> Config Informática Ltda

> 

> & Av. Eng. Luis Carlos Berrini, 801 - 7º andar

> 

> & 04571-010 - Brooklin Novo - São Paulo - SP

> 

> ( Fone (11) 5501-8300

> 

> ( Fax (11) 5501-8302

> 

> 8 www.config.com.br - Original Message - 

> 

> 

> 

> From: Adriano Cavalcanti 

> 

>   To: oracle_br@yahoogrupos.com.br 

> 

>   Sent: Monday, May 26, 2008 8:06 PM

> 

>   Subject: RE: [oracle_br] Performance ( Insert Select via dblink)

> 

> 

> 

> Mácio não entendi muito bem. 

> 

> 

> 

> Meu senário é o seguinte. 

> 

> 

> 

> Este select ai retorna (depois de quase uma hora) 315 mil registros. 

> 

> 

> 

> Como faço para inserir e dar commit a cada 50 registros? 

> 

> 

> 

> To: oracle_br@yahoogrupos.com.br

> 

>   From: [EMAIL PROTECTED]

> 

>   Date: Mon, 19 May 2008 15:46:51 -0300

> 

>   Subject: Re: [oracle_br] Performance ( Insert Select via dblink)

> 

> 

> 

> Adriano no meu caso eu fiz um cursor do que eu precisava e depois

fui fazendo o insert dentro de um while. Eu acho que você poderia

fazer um cursor e atualizar dentro do while... pegar as condições

where tua e colocar no cursor e no insert ficaria somente o select,

claro com poucos parametros... Creio que deve ser as suas condições

que esteja demorando... Tente transformar no cursor e depois faça o teste.

> 

> 

> 

> Márcio Ricardo Alves da Silva

> 

> 

> 

> Programador Pleno

> 

> 

> 

> Oracle Certified Associate 9i

> 

> 

> 

> * [EMAIL PROTECTED]

> 

> 

> 

> Config Informática Ltda

> 

> 

> 

> & Av. Eng. Luis Carlos Berrini, 801 - 7º andar

> 

> 

> 

> & 04571-010 - Brooklin Novo - São Paulo - SP

> 

> 

> 

> ( Fone (11) 5501-8300

> 

> 

> 

> ( Fax (11) 5501-8302

> 

> 

> 

> 8 www.config.com.br - Original Message - 

> 

> 

> 

> From: Adriano Cavalcanti 

> 

> 

> 

> To: oracle_br@yahoogrupos.com.br 

> 

> 

> 

> Sent: Monday, May 19, 2008 3:38 PM

> 

> 

> 

> Subject: RE: [oracle_br] Performance ( Insert Select via dblink)

> 

> 

> 

> Marcio, não sei ainda como fazer isso. 

> 

> 

> 

> Mas acredite 3 horas de ins

[oracle_br] Re: Performance ( Insert Select via dblink)

[jlchiappa]

Colega, não acompanhei a thread toda, mas de cara já digo : COMMIT
frequente, a cada x registros, * NÃO É *, NUNCA foi e NUNCA
SERÁ a maneira melhor e mais performática de se processar um SQL, em
especial INSERTs,
http://asktom.oracle.com/pls/asktom/f?p=100:11:0P11_QUESTION_ID:4951966319022#4955604534852
 mostra exatamente isso E em sendo um único INSERT só com a query,
se a tabela-destino estiver como NOLOGGING, se durante o INSERT vc  vc
desligar as triggers, desativar os índices (NÂO é dropar!!), desativar
(ou ao menos ter as constraints validadas só no commit se der) E usar
um INSERT /*+ APPEND */, aposto um picolé de limão que a performance
assim vai ** HUMILHAR ** , *** ESMAGAR ***, * TRITURAR  a
performance da versão usando CURSOR e COMITs frequentes. No
workshop eu dei um exemplo simples, pequeno, aonde isso era
demonstrado, mas em ambiente de Produção o ganho (em não sendo gerado
quase nenhum redo log, nem undo) via de regra é fenomenalmente maior...

[]s

 Chiappa

--- Em oracle_br@yahoogrupos.com.br, Adriano Cavalcanti <[EMAIL PROTECTED]>
escreveu
>
> é Isso eu tinha pensado. 
> Achei que tivesse algo mais performatico. 
> 
> como tenho 315 mil registro, acho melhor então fazer sempre uma
conta para pegar um quarto de registro  por commit. 
> 
> Mas valeu
> 
> 
> 
> To: oracle_br@yahoogrupos.com.br
> From: [EMAIL PROTECTED]
> Date: Tue, 27 May 2008 08:18:24 -0300
> Subject: Re: [oracle_br] Performance ( Insert Select via dblink)
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Adriano, você pode ter um contador dentro do loop do
cursor e quando o contador chegar a 50, você dá o commit e zera o
contador novamente. É isso que você precisa?
> 
> Márcio Ricardo Alves da Silva
> 
> Programador Pleno
> 
> Oracle Certified Associate 9i
> 
> * [EMAIL PROTECTED]
> 
> 
> 
> Config Informática Ltda
> 
> & Av. Eng. Luis Carlos Berrini, 801 - 7º andar
> 
> & 04571-010 - Brooklin Novo - São Paulo - SP
> 
> ( Fone (11) 5501-8300
> 
> ( Fax (11) 5501-8302
> 
> 8 www.config.com.br - Original Message - 
> 
> 
> 
> From: Adriano Cavalcanti 
> 
>   To: oracle_br@yahoogrupos.com.br 
> 
>   Sent: Monday, May 26, 2008 8:06 PM
> 
>   Subject: RE: [oracle_br] Performance ( Insert Select via dblink)
> 
> 
> 
> Mácio não entendi muito bem. 
> 
> 
> 
> Meu senário é o seguinte. 
> 
> 
> 
> Este select ai retorna (depois de quase uma hora) 315 mil registros. 
> 
> 
> 
> Como faço para inserir e dar commit a cada 50 registros? 
> 
> 
> 
> To: oracle_br@yahoogrupos.com.br
> 
>   From: [EMAIL PROTECTED]
> 
>   Date: Mon, 19 May 2008 15:46:51 -0300
> 
>   Subject: Re: [oracle_br] Performance ( Insert Select via dblink)
> 
> 
> 
> Adriano no meu caso eu fiz um cursor do que eu precisava e depois
fui fazendo o insert dentro de um while. Eu acho que você poderia
fazer um cursor e atualizar dentro do while... pegar as condições
where tua e colocar no cursor e no insert ficaria somente o select,
claro com poucos parametros... Creio que deve ser as suas condições
que esteja demorando... Tente transformar no cursor e depois faça o teste.
> 
> 
> 
> Márcio Ricardo Alves da Silva
> 
> 
> 
> Programador Pleno
> 
> 
> 
> Oracle Certified Associate 9i
> 
> 
> 
> * [EMAIL PROTECTED]
> 
> 
> 
> Config Informática Ltda
> 
> 
> 
> & Av. Eng. Luis Carlos Berrini, 801 - 7º andar
> 
> 
> 
> & 04571-010 - Brooklin Novo - São Paulo - SP
> 
> 
> 
> ( Fone (11) 5501-8300
> 
> 
> 
> ( Fax (11) 5501-8302
> 
> 
> 
> 8 www.config.com.br - Original Message - 
> 
> 
> 
> From: Adriano Cavalcanti 
> 
> 
> 
> To: oracle_br@yahoogrupos.com.br 
> 
> 
> 
> Sent: Monday, May 19, 2008 3:38 PM
> 
> 
> 
> Subject: RE: [oracle_br] Performance ( Insert Select via dblink)
> 
> 
> 
> Marcio, não sei ainda como fazer isso. 
> 
> 
> 
> Mas acredite 3 horas de insert não é mole não. 
> 
> 
> 
> Segue insert.
> 
> 
> 
> INSERT INTO TB_BILHETAGEM_LOGICA_FORNEC -- LOGICO
> 
> 
> 
> (
> 
> 
> 
> INT_ID_BILHETAGEM_LOGICA,
> 
> 
> 
> INT_ID_FORNEC_BILHETAGEM,
> 
> 
> 
> INT_ID_PROJETO,
> 
> 
> 
> INT_ID_IMPRESSORA,
> 
> 
> 
> INT_ID_IMPRESSAO,
> 
> 
> 
> INT_ID_DISPOSITIVO_IMPRESSORA,
> 
> 
> 
> STR_IP_IMPRESSORA,
> 
> 
> 
> STR_SERIAL_IMPRESSORA,
> 
> 
> 
> STR_NOME_IMPRESSORA,
> 
> 
> 
> STR_DESCRICAO_IMPRESSORA,
> 
> 
> 
> STR_VERSAO_APP,
> 
> 
> 
> STR_MAC_IMPRESSORA,
> 
> 
> 
> INT_QTD_PAGINAS,
> 
> 
> 
> INT_QTD_PAGINAS_COLORIDAS,
> 
> 
> 
> INT_QTD_PAGINAS_MONO,
> 
> 
> 
> INT_QTD_FOLHAS,
> 
> 
> 
> STR_DESCRICAO_QUALIDADE,
> 
> 
> 
> INT_ID_QUALIDADE_IMPRESSAO,
> 
> 
> 
> STR_NOME_TIPO_IMPRESSAO,
> 
> 
> 
> INT_ID_TIPO_IMPRESSAO,
> 
> 
> 
> STR_DESCRICAO_PAPEL,
> 
> 
> 
> BT_ISDUPLEX,
> 
> 
> 
> STR_NOME_FILA_IMPRESSAO,
> 
> 
> 
> STR_NOME_SERVIDOR,
> 
> 
> 
> STR_MAC_SERVIDOR,
> 
> 
> 
> STR_IP_SERVIDOR,
> 
> 
> 
> STR_SUB_NET_ENDERECO,
> 
> 
> 
> STR_MASCARA_SERVIDOR,
> 
> 
> 
> STR_NOME_USUARIO,
> 
> 
> 
> STR_ET_NOME,
> 
> 
> 
> FLT_SPOOLSIZE,
> 
> 
> 
> INT_CODIGO_COR,
> 
> 
> 
> INT_ID_TAMANH

[oracle_br] Re: Performance ( Insert Select via dblink)

[jlchiappa]

Leonardo, acho que a recomendação mais diretamente seria "descobrir
AONDE está o gargalo", e não "descobrir em qual banco", pois pode ser
que seja problema de rede, de trigger disparando, de I/O em geral (por
exemplo, outras transações intensas usando os mesmos caras n+1!
possibilidades... Então minha sugestão é :

 a) provavelmente o mesmo banco que tem as tabelas deve também ter os
índices e quetais necessários para a query ser executada lá, conirmar
que lá roda bem executando a query, medindo o tempo, pegando o plano
de execução e checando-o diteitinho 

 b) o que via de regra a pessoa NUNCA há de querer é INSERT remoto,
ie, onde os registros (normalmente LEENTAMENTE, um por vez, linha a
linha, slow by slow) vão fluindo pela rede , o que é eficiente é o
INSERT ser feito LOCAL, bo banco-destino mesmo (em APPEND-MODE e em
paralelo, se for Oracle o banco e o hardware permitir), ** MAS ** com
o cuidado de que o select que traz os dados seja ENVIADO PARA O BANCO
REMOTO E RESOLVIDO LÁ , se o banco local cismar de querer executar o
SQL local, cada linhas das tabelas será "puxada" pra cá via rede pra
se fazer o join aqui, o que por si já é ruim, e ainda por cima teria o
agravante de que os índices estão lá, se o select for resolvido aqui
no banco lpcal normalmente não há como usar tais índices

 c) nem se precisa dizer que CURSOR *** naturalmente ** é Muito Menos
eficiente do que um SQL puro e direto, principalmente por causa dos
context switches e cia bela 

  No cliente atual a gente faz esse tipo de trabalho com alguma rotina
(pois o DW, que é o banco-destino, é em Oracle), e várias vezes o
pessoal teve problema desse tipo, realmente as soluções eficientes
foram, dependendo do caso  :

 a) hint de DRIVING_SITE no select, para que o SQL seja resolvido lá
na fonte 
 e/ou
 b) executar diretamente lá no SQL Server o select desejado, fazendo
todos os joins necessários lá, usando os recursos e opções todas do SS
(aí tínhamos um programador SS experiente escrebendo tal SQL) e lá
gravando uma tabela temporária, de trabalho, que depois o Oracle traz
pra cá via select * : no noso caso o cara que administra o SS fez uma
rotina java no Oracle que permite enviar SQLs pro SS, não sei se isso
é mesmo necessário ou há outras formas de enviar SQLs pro SS
  e/ou
 c) em alguns casos mais encruados, onde nada podia ser alterado no
SS, a solução foi ter o SS gerando um arquivo-texto com o joinzão
todo, arquivo esse que é enviado via ftp pro servidor Oracle e é lido
via EXTERNAL TABLE, poupando um passo de carga desse arquivo texto

 []s

  Chiappa
--- Em oracle_br@yahoogrupos.com.br, Leonardo Rezende <[EMAIL PROTECTED]> 
escreveu
>
> Acho que interessante seria em primeiro lugar descobrir em qual banco 
> está o gargalo... Faça o select separado para ver se ele demora
muito... 
> Se ele demorar, o gargalo provavelmente é no select do banco remoto, 
> caso contrário o gargalo deve ser no banco que você está fazendo o
insert!
> 
> A partir daí você coloca suas forças para tentar otimizar!
> 
> Adriano Cavalcanti escreveu:
> > 
> > 
> > 
> > 
> > Marcio, não sei ainda como fazer isso.
> > 
> > Mas acredite 3 horas de insert não é mole não.
> > 
> > Segue insert.
> > 
> > INSERT INTO TB_BILHETAGEM_LOGICA_FORNEC -- LOGICO
> > (
> > INT_ID_BILHETAGEM_LOGICA,
> > INT_ID_FORNEC_BILHETAGEM,
> > INT_ID_PROJETO,
> > INT_ID_IMPRESSORA,
> > INT_ID_IMPRESSAO,
> > INT_ID_DISPOSITIVO_IMPRESSORA,
> > STR_IP_IMPRESSORA,
> > STR_SERIAL_IMPRESSORA,
> > STR_NOME_IMPRESSORA,
> > STR_DESCRICAO_IMPRESSORA,
> > STR_VERSAO_APP,
> > STR_MAC_IMPRESSORA,
> > INT_QTD_PAGINAS,
> > INT_QTD_PAGINAS_COLORIDAS,
> > INT_QTD_PAGINAS_MONO,
> > INT_QTD_FOLHAS,
> > STR_DESCRICAO_QUALIDADE,
> > INT_ID_QUALIDADE_IMPRESSAO,
> > STR_NOME_TIPO_IMPRESSAO,
> > INT_ID_TIPO_IMPRESSAO,
> > STR_DESCRICAO_PAPEL,
> > BT_ISDUPLEX,
> > STR_NOME_FILA_IMPRESSAO,
> > STR_NOME_SERVIDOR,
> > STR_MAC_SERVIDOR,
> > STR_IP_SERVIDOR,
> > STR_SUB_NET_ENDERECO,
> > STR_MASCARA_SERVIDOR,
> > STR_NOME_USUARIO,
> > STR_ET_NOME,
> > FLT_SPOOLSIZE,
> > INT_CODIGO_COR,
> > INT_ID_TAMANHO_PAPEL,
> > STR_NOME_DOCUMENTO,
> > STR_NOME_APLICATIVO,
> > STR_TITULO_DOCUMENTO,
> > STR_ORIGEM_IMPRESSAO,
> > STR_DESCRI_TAMANHO_IMPRESSAO,
> > DT_DATA_REF,
> > DT_IMPRESSAO,
> > DT_CADASTRO,
> > DT_BILHETAGEM
> > )
> > SELECT
> > SQ_ID_BILHETAGEM_LOGICA_FORNEC.NEXTVAL,
> > 1,
> > 2,
> > "pr"."IDPrinter",
> > "pj"."ID_JOBS",
> > NULL,
> > FC_TRATA_IP("pr"."JetDirectName") "ip",
> > NULL,
> > "pr"."PrinterName",
> > NULL,
> > NULL,
> > NULL,
> > "pj"."Pages",
> > NULL,
> > NULL,
> > NULL,
> > NULL,
> > NULL,
> > NULL,
> > NULL,
> > NULL,
> > "pj"."Duplex",
> > NULL,
> > "pss"."PrintServerName",
> > NULL,
> > "pss"."IP",
> > "ss"."SubNetwork",
> > "pss"."Mask",
> > "ac"."Name",
> > NULL,
> > NULL,
> > "pj"."IDPAPrintColor",
> > "pj"."IDPAPaperSize",
> > "pj"."Document",
> > "pa"."AppName",
> > NULL,
> > NULL,
> > "ps"."Description",
> > NULL,
> > "pj"."Date",
> > NULL,
> > sysdate
> > FROM
> > [EMAIL PRO

[oracle_br] Re: Performance Oracle 9i - Podem me ajudar?

[jlchiappa]

Colega, só pra variar vc NÂO diz o principal, ie, se é hardware e SO
de 32 bits - como imagino que vc sabia, nos 32 bits vc tem LIMITES pra
quanto de RAM vc pode alocar pra um executável (como o executável do
banco e outros), SE for 32 bits até pode ser esses seus settings
estejam um pouco altos e ultrapassando o limite (e portanto forçando
alguma Paginação) - não é provável, mas pode ser. Outra coisa que vc
não diz é ** SE ** vc está usando conexões MTS/shared server e/ou
Paralelismo, no banco 9i ambos os recursos NÂO se utilizam da PGA
automática e confiam no sort_area_size e no hash_area_size, que pra
esse caso realmente estão minúsculos, aumente-os se isso é verdadeiro.
  O que parece mais provável, porém, não é config do banco em geral,
mas estruturas (por exemplo, tablespaces mal-feitas, com extent size
inadequado, não-LMT, etc) e/ou config do CBO e/ou tuning de SQL, e/ou
servidor sub-dimensionado ou intensamente usado : o exemplo de
lentidão que vc dá parece nos levar à essa conclusão, uma busca numa
tabela de poucos milhares de itens levar 5 segundos é GLACIALMENTE
lenta, quase congelada mesmo, olha só no meu banco XE, SEM RAID algum,
vagalzão :
  
[EMAIL PROTECTED]:SQL>set timing on
[EMAIL PROTECTED]:SQL>select * from TAB_NOCOMPRESS;


02/2006 22:14:36 07/02/2006 22:14:36 2006-02-07:22:14:36 VALID   N N N
SYS  DBMS_SPACE
02/2006 22:14:37 07/02/2006 22:14:37 2006-02-07:22:14:37 VALID   N N N

7310 linhas selecionadas.

Decorrido: 00:00:04.25

OK, óbvio que não há concorrência na minha máquina, mas
NECESSARIAMENTE mesmo assim um servidor de Produção, com RAID, com um
cachezão, certamente com discos SCSI nesse RAID, não podia de modo
algum ser mais lento... Então o seu procedimento será :

 a) checar COMO está a utilização desse servidor quanto à I/O, CPU,
RAM e rede, ver se não há outras sessões afora essa do LOV fazendo
alguma coisa bizarra, ver o consumo geral de recursos, ver se o
cenário de paging por limitação dos 32 bits está ocorrendo... No
linux/unix vc teria nativo top, vmstat, iostat, netstat, glance,
trace, etc, no windows iirc não tem muita coisa boa nativa,
principalmente quanto à RAM que ele mostra por processo E não por
thread, provavelmente vc terá que baixar utilitários de terceiros para
isso
 
 b) fazer um TRACE 10046 level 12 da sessão "lenta" (executando um SQL
que seja, o do LOV talvez) , passar o TKPROF nele pra checar o plano
de execução real usado e os waits, localizar no arquivo de trace os
passos com maiores elapsed e reads...
 
 Essa análise é que vai te dar subsídio para diagnosticar I/O
excessivo (poucas linhas exigindo leitura de muitos blocos, apontando
para estruturas físicas ruins, concorrência, hot spots, etc) e/ou
lentidão de hardware (I/Os ou transporte de redes demorando muito mais
que o esperado no seu hardware e na sua taxa de utiliação), e/ou
simplesmente palno de execução ruim (caso em que vc teria que
recoletar estatísticas, talvez incluindo histogramas maiores, e/ou
alterar parãmetros de CBO), é por aí...
 
 []s
 
   Chiappa
   
--- Em oracle_br@yahoogrupos.com.br, "cegoncalvesvr"
<[EMAIL PROTECTED]> escreveu
>
> Ola amigos,
> 
> Servidor DELL
> Oracle 9i 9.2.0.7   
> Processador de 1.6 Ghz Intel XEON
> 04 Gb de RAM
> 06 Discos SAS de 146 GB (Com RAID 10)
> Windows 2000 Server
> O meu sistema em alguns processos acho que ele demora.
> O sistema é em PL/SQL Oracle
> 
> Exemplo: Quando aciono a LOV de produtos (onde tenho aproximadamente 
> 7700 itens), demora uns 05 a 07 segundos para lista de produtos 
> aparecer.
> Será que tem algum parâmetro baixo?
> 
> Estou colocando abaixo os principais comandos com a quantidade de 
> memória.
> 
> sort_area_retained_size   1048576
> sort_area_size1048576
> shared_pool_reserved_size 5000
> shared_pool_size  520093696
> pga_aggregate_target  51200
> workarea_size_policy  AUTO
> log_buffer20500480
> java_pool_size16777216
> large_pool_size   83886080
> hash_area_size15452000
> enqueue_resources 80240
> dml_locks 20020
> db_cache_size 704643072
> 
> Alguem poderia me dar uma ajuda?
> 
> Abraços.
>

Re: [oracle_br] Re: Performance em Query - Evento de Espera - PX Deq: Execute Reply

[Rodrigo Telles]

Obrigado Chiappa,
vou estudar os docs que me passou.

Abs


On 3/21/08, jlchiappa <[EMAIL PROTECTED]> wrote:
>
>   Colega, o documento que vc quer é a nota 280939.1, Subject:Checklist
> for Performance Problems with Parallel Execution , lá vc verá que até
> há algumas coisinhas que vc pode verificar, mas ela mesma (e as notas
> para as quais há link dentro dela), outras notas relacionadas como a
> 203238.1 Subject:Using Parallel Execution, a documentação mesmo
> (manuais oficiais Oracle do banco, nos itens inicados pela nota
> 184417.1 Subject: Where to find Information about Parallel Execution
> in the Oracle Documentation, todas dizem o mesmo basicamente :
>
> 1. cada um dos parallel Slaves fazem um pedaço da leitura que o SQL
> da sessão master lhe pediu, então ** SE ** a o SQL em si na sessão
> master está ruim, está acessando muitas coisas que não precisa, está
> usando um método de join ineficiente, etc, os slaves vão fazer
> TONELADAS de trabalho inútil, o primeiro passo sempre, SEMPRE, **
> SEMPRE **, é tunning do SQL, para que ele faça o menor número possível
> de LIOs, ok ?
>
> 2. já que os parallel slaves fazem I/O numa parcela do total, opções
> que segreguem parte do todo (como PARTICIONAMENTO) são absolutamente
> críticas para a performance deles. Da mesma forma o é o ajuste do I/O
> (tanto dentro do banco, com params de multiblock_read e de
> filesystem_options) quanto FORA do banco, no servior, setando onde
> possível I/O asíncrono, I/O direto, params de I/O (** vitais no
> unix/linux).
>
> ==> então a minha recomendação é : se não o fez ainda, *** PRIMEIRO
> *** vá pro tunning do SQL, melhorias das estruturas de dados (com
> paralelismo, índices seletivos, global temporary tables, modo
> nologging aonde/se possível, etc), e pra verificação de I/O no banco
> e no servidor, apenas ** SE ** não obter nada significativo aí sim vá
> pro micro-tunning como é o caso de params de parallel... Isso porque,
> tal como as notas metlink citadas falam, esses ajuste são CUSTOSOS,
> baseados muito em tentativa e erro, e ao final talvez não tragam nada
> de significativo
>
> []s
>
> Chiappa
>
> ===
> Participe do ENPO - Encontro de Profissionais Oracle 2008 !
> Informações e inscrições em http://www.enpo-br.org
> José Laurindo Chiappa, Palestrante ENPO-2008
> ===
>
> --- Em oracle_br@yahoogrupos.com.br ,
> "Rodrigo Telles"
> <[EMAIL PROTECTED]> escreveu
> >
> > Pessoal,
> > estou com uma query que , em seus eventos de espera, tenho o evento
> *PX Deq:
> > Execute Reply* como o maior.
> >
> > Evento
> > Total_Waits
> > Total_TimeOuts
> > Time_Waited
> >
> >
> >
> >
> > SQL*Net more data from client
> > 1
> > 0
> > 0
> > PX Deq: Join ACK
> > 4
> > 0
> > 0
> > PX Deq: Parse Reply
> > 4
> > 0
> > 2
> > SQL*Net message to client
> > 15
> > 0
> > 0
> > SQL*Net message from client
> > 15
> > 0
> > 31
> > latch free
> > 17
> > 14
> > 8
> > PX Deq Credit: send blkd
> > 1738
> > 0
> > 175
> > PX Deq: Execute Reply
> > 1954
> > 1597
> > 316325
> > PX Deq Credit: need buffer
> > 9029
> > 0
> > 338
> > db file scattered read
> > 14892
> > 0
> > 18049
> > db file sequential read
> > 19486
> > 0
> > 15048
> >
> > Em doc da Oracle esse evento é visto como idle event. Porém se o
> tempo dele
> > for muito grande com relação aos outros devemos investigar os processos
> > paralelos escravos. Olhando cada um, que são 4, verifiquei que o maior
> > evento em espera são:*PX Deq Credit: send blkd e PX Deq: Table Q Normal*
> > Aqui temos um ambiente de DW e o Oracle é o 9.2.0.5
> >
> > Alguém ja passou por essa situação e conseguiu diminuir esses eventos de
> > espera? Além disso, a Oracle fala muito em investigar os processos
> paralelos
> > escravos? Existe algum lugar que mostre como investigar isso a fundo
> > verificando se eles estão ou não trabalhando com boa performance?
> >
> > Sds
> >
> > Rodrigo
> >
> >
> > [As partes desta mensagem que não continham texto foram removidas]
> >
>
> 
>


[As partes desta mensagem que não continham texto foram removidas]

[oracle_br] Re: Performance em Query - Evento de Espera - PX Deq: Execute Reply

[jlchiappa]

Colega, o documento que vc quer é a nota 280939.1, Subject:Checklist
for Performance Problems with Parallel Execution , lá vc verá que até
há algumas coisinhas que vc pode verificar,  mas ela mesma (e as notas
para as quais há link dentro dela), outras notas relacionadas como a
203238.1 Subject:Using Parallel Execution, a documentação mesmo
(manuais oficiais Oracle do banco, nos itens inicados pela nota
184417.1 Subject: Where to find Information about Parallel Execution
in the Oracle Documentation, todas dizem o mesmo basicamente : 

 1. cada um dos parallel Slaves fazem um pedaço da leitura que o SQL
da sessão master lhe pediu, então ** SE ** a o SQL em si na sessão
master está ruim, está acessando muitas coisas que não precisa, está
usando um método de join ineficiente, etc, os slaves vão fazer
TONELADAS de trabalho inútil, o primeiro passo sempre, SEMPRE, **
SEMPRE **, é tunning do SQL, para que ele faça o menor número possível
de LIOs, ok ? 
 
 2. já que os parallel slaves fazem I/O numa parcela do total, opções
que segreguem parte do todo (como PARTICIONAMENTO) são absolutamente
críticas para a performance deles. Da mesma forma o é o ajuste do I/O
(tanto dentro do banco, com params de multiblock_read e de
filesystem_options) quanto FORA do banco, no servior, setando onde
possível I/O asíncrono, I/O direto, params de I/O (** vitais no
unix/linux).
 
 ==> então a minha recomendação é : se não o fez ainda, *** PRIMEIRO
*** vá pro tunning do SQL, melhorias das estruturas de dados (com
paralelismo, índices seletivos, global temporary tables, modo
nologging aonde/se possível, etc),  e pra verificação de I/O no banco
e no servidor, apenas ** SE ** não obter nada significativo aí sim vá
pro micro-tunning como é o caso de params de parallel... Isso porque,
tal como as notas metlink citadas falam, esses ajuste são CUSTOSOS,
baseados muito em tentativa e erro, e ao final talvez não tragam nada
de significativo
 
 []s
  
   Chiappa
   
 ===
 Participe do ENPO - Encontro de Profissionais Oracle 2008 !
 Informações e inscrições em http://www.enpo-br.org
 José Laurindo Chiappa, Palestrante ENPO-2008
===

--- Em oracle_br@yahoogrupos.com.br, "Rodrigo Telles"
<[EMAIL PROTECTED]> escreveu
>
> Pessoal,
> estou com uma query que , em seus eventos de espera, tenho o evento
*PX Deq:
> Execute Reply* como o maior.
> 
>  Evento
>  Total_Waits
>  Total_TimeOuts
>  Time_Waited
> 
> 
> 
> 
>  SQL*Net more data from client
>  1
>  0
>  0
>  PX Deq: Join ACK
>  4
>  0
>  0
>  PX Deq: Parse Reply
>  4
>  0
>  2
>  SQL*Net message to client
>  15
>  0
>  0
>  SQL*Net message from client
>  15
>  0
>  31
>  latch free
>  17
>  14
>  8
>  PX Deq Credit: send blkd
>  1738
>  0
>  175
>  PX Deq: Execute Reply
>  1954
>  1597
>  316325
>  PX Deq Credit: need buffer
>  9029
>  0
>  338
>  db file scattered read
>  14892
>  0
>  18049
>  db file sequential read
>  19486
>  0
>  15048
> 
> Em doc da Oracle esse evento é visto como idle event. Porém se o
tempo dele
> for muito grande com relação aos outros devemos investigar os processos
> paralelos escravos. Olhando cada um, que são 4, verifiquei que o maior
> evento em espera são:*PX Deq Credit: send blkd e PX Deq: Table Q Normal*
> Aqui temos um ambiente de DW e o Oracle é o 9.2.0.5
> 
> Alguém ja passou por essa situação e conseguiu diminuir esses eventos de
> espera? Além disso, a Oracle fala muito em investigar os processos
paralelos
> escravos? Existe algum lugar que mostre como investigar isso a fundo
> verificando se eles estão ou não trabalhando com boa performance?
> 
> Sds
> 
> Rodrigo
> 
> 
> [As partes desta mensagem que não continham texto foram removidas]
>

[oracle_br] Re: Performance View

[alx_haag]

  A view materializada difere da View comum porque "materializa" os
resultados da query da view dentro dela própria,enquanto que a view
comum somente exibe os dados no momento em que é solicitada.

  Um uso possível de view materializada seria para replicar
informações por exemplo entre matriz e filial através de uma vpn ou
conexão comum de internet. Na matriz existiria a tabela e na filial
uma view materializada da mesma tabela. Quando fosse inserido um novo
registro na tabela este seria replicado pelo Oracle, de acordo com os
parâmetros de criação da view, para as views materializadas das filiais.

  Eu utilizo View materializadas para casos mais específicos, como
este exemplo citado acima. Para casos de simples consultas geralmente
utilizo views comuns.

Att.
Alexsandro Haag

--- Em oracle_br@yahoogrupos.com.br, Vitor Hugo <[EMAIL PROTECTED]> escreveu
>
> Bom dia a todos,
> 
> Entre Materialized View e uma simples view qual é o que possui a melhor 
> performance deduzindo que os dois efetuem a mesma consulta. E qual é a 
> diferença entre uma e outra.
> 
> Obrigado pela ajuda.
> 
> Vitor Hugo
> Analista Desenvolvedor Java
>

Re: [oracle_br] Re: Performance no Oracle com SQL ANSI

[Andre Santos]

Mestre Chiappa

Eu não tenho acesso ao Metalink... mas no trecho que você transcreveu (pode
ter passado algo despercebido para mim) está:
   This issue is fixed in
* 10.2.0.4 (Server Patch Set)
* 11g (Future version)

Ou seja, "Este problema está corrigido em"... e ainda cita a versão 11g como
"futura" (dando a idéia que essa nota era antiga). Por isso é que conclui
que já havia sido corrigida.

Porém como você disse que o patch 10.2.0.4 ainda não foi lançado --- e sei
que você não costuma falar sem fundamento  ;^)  --- pesquisei um pouco pelo
Google e vi que realmente este a liberação deste patch estava prevista para
o final de 2007 ou início de 2008.

Obrigado pelo esclarecimento !!!

[ ]

André


Em 21/11/07, jlchiappa <[EMAIL PROTECTED]> escreveu:

>   A frase é "PROVAVELMENTE ESTARÃO CORRIGIDOS", e não "estão", pois como
> a nota mesmo diz o patch 10.2.0.4 é futuro ainda, não existe ainda...
>
> []s
>
> Chiappa
>
> --- Em oracle_br@yahoogrupos.com.br ,
> "Andre Santos"
> <[EMAIL PROTECTED]> escreveu
> >
> > Chiappa
> >
> > Muito obrigado pela informação! É sempre bom ter em mente que,
> dependendo da
> > versão/release, podem haver bugs.
> >
> > Mas, esses específicos que você citou, estão corrigidos a partir da
> versão
> > 10.2.0.4, certo? (pelo menos, foi o que a nota menciona).
> >
> > Valeu!
> >
> > [ ]
> >
> > André
> >
> >
> > Em 21/11/07, jlchiappa <[EMAIL PROTECTED]> escreveu:
> > >
> > > Só acrescento que :
> > >
> > > a) a recomendação do manual ** não é ** por causa de performance, veja
> > > lá que nas razões, são citadas a melhor legibilidade da sintaxe ANSI,
> > > features que são mais difíceis de imitar na sintaxe tradicional (como
> > > FULL OUTER JOINs, OUTER JOIN da mesma tabela com várias outras, etc)
> > >
> > > e
> > >
> > > b) a pessoa ** TEM QUE VER ** se dá pra se usar a sintaxe ANSI no caso
> > > dela : por ser mais nova, ainda há mais de um bug sendo resolvido pra
> > > elas. Falando de 10g, de cara temos os seguintes bugs abertos (nota
> > > 401436.1 Subject: 10.2.0.4 Patch Set - List of Bug Fixes by Problem
> > > Type) :
> > >
> > > ANSI Joins
> > > 4204383 Dump [kkqtnlocbk] optimizing ANSI OUTER JOINs with subqueries
> > > 4702830 OERI[kkoljt1] when using star transformation with an ANSI
> > > outer join
> > > 4901291 Wrong results with left outer joins on view with a function
> > > 5188321 wrong results (no rows) from ANSI outer join
> > > 5590396 Dump or Wrong Results with ANSI JOINS and CONNECT BY
> > > 5765958 OERI[qcscpqbTxt] / OERI[qcsfbdnp:1] from ANSI query in PLSQL
> > > 5964193 OERI[kkqsRewriteCorrCols-1] during query rewrite with ANSI
> joins
> > > 5988085 Dump [kkodsel] from STAR transformation with ANSI view
> > >
> > > ==> o bug 5188321, por exemplo, é explícito :
> > >
> > > Bug 5188321 wrong results (no rows) from ANSI outer join
> > >
> > > This note gives a brief overview of bug 5188321.
> > > Affects:
> > >
> > > Product (Component) Oracle Server (Rdbms)
> > > Range of versions believed to be affected Versions < 11
> > > Versions confirmed as being affected
> > >
> > > * 9.2.0.7
> > > * 9.2.0.8
> > > * 10.1.0.5
> > >
> > > Platforms affected Generic (all / most platforms affected)
> > >
> > > Fixed:
> > >
> > > This issue is fixed in
> > >
> > > * 10.2.0.4 (Server Patch Set)
> > > * 11g (Future version)
> > >
> > > Symptoms:
> > >
> > > Related To:
> > >
> > > * Wrong Results
> > > * ANSI Joins
> > >
> > > Description
> > >
> > > Wrong results can be returned with a query involving a very large
> > > select
> > > list count when ANSI OUTER JOIN syntax is used.
> > >
> > > Workaround:
> > > Use native oracle outer join syntax
> > > or
> > > reduce the select list count.
> > >
> > > ==> ou seja, não há patch e o workaround é usar a boa e velha sintaxe
> > > nativa Então pra mim, que manipulo sempre grandes volumes, vcs
> > > podem imaginar ser seguríssimo apostar um picolé de limão que ** VAI
> > > ** demorar um pouquinho pra eu começar a me preocupar com sintaxe
> ANSI...
> > >
> > > []s
> > >
> > > Chiappa
> > >
> > > --- Em oracle_br@yahoogrupos.com.br 
> > > ,
> > > "Andre Santos"
> > >  escreveu
> > > >
> > > > Alisson
> > > >
> > > > Foi na documentação do Oracle9i Database:
> > > > - SQL Reference
> > > > - Joins
> > > > <
> > > >
> > >
> > >
>
> http://download.oracle.com/docs/cd/B10501_01/server.920/a96540/queries7.htm#2054014
> > > > >
> > > >
> > > > Mas a recomendação permanece na documentação da versão mais
> atual (11g):
> > > > <
> > > >
> > >
> > >
>
> http://download.oracle.com/docs/cd/B28359_01/server.111/b28286/queries006.htm#sthref3238
> > > > >
> > > >
> > > > [ ]
> > > >
> > > > André
> > > >
> > > >
> > > > Em 16/11/07, Alisson Aguiar  escreveu:
> > > > >
> > > > > Beleza, André. Obrigado pela informação.
> > > > >
> > > > > Só para complementar, você tem o link da fonte essa
> informação? É o
> > > > > manual,
> > > > > White Paper, etc. ? Gostaria de apresentar essa informação
> (Oracle),
> > > > > juntamente com outra

[oracle_br] Re: Performance no Oracle com SQL ANSI

[jlchiappa]

A frase é "PROVAVELMENTE ESTARÃO CORRIGIDOS", e não "estão", pois como
a nota mesmo diz o patch 10.2.0.4 é futuro ainda, não existe ainda...

[]s

 Chiappa

--- Em oracle_br@yahoogrupos.com.br, "Andre Santos"
<[EMAIL PROTECTED]> escreveu
>
> Chiappa
> 
> Muito obrigado pela informação! É sempre bom ter em mente que,
dependendo da
> versão/release, podem haver bugs.
> 
> Mas, esses específicos que você citou, estão corrigidos a partir da
versão
> 10.2.0.4, certo? (pelo menos, foi o que a nota menciona).
> 
> Valeu!
> 
> [ ]
> 
> André
> 
> 
> Em 21/11/07, jlchiappa <[EMAIL PROTECTED]> escreveu:
> >
> >   Só acrescento que :
> >
> > a) a recomendação do manual ** não é ** por causa de performance, veja
> > lá que nas razões, são citadas a melhor legibilidade da sintaxe ANSI,
> > features que são mais difíceis de imitar na sintaxe tradicional (como
> > FULL OUTER JOINs, OUTER JOIN da mesma tabela com várias outras, etc)
> >
> > e
> >
> > b) a pessoa ** TEM QUE VER ** se dá pra se usar a sintaxe ANSI no caso
> > dela : por ser mais nova, ainda há mais de um bug sendo resolvido pra
> > elas. Falando de 10g, de cara temos os seguintes bugs abertos (nota
> > 401436.1 Subject: 10.2.0.4 Patch Set - List of Bug Fixes by Problem
> > Type) :
> >
> > ANSI Joins
> > 4204383 Dump [kkqtnlocbk] optimizing ANSI OUTER JOINs with subqueries
> > 4702830 OERI[kkoljt1] when using star transformation with an ANSI
> > outer join
> > 4901291 Wrong results with left outer joins on view with a function
> > 5188321 wrong results (no rows) from ANSI outer join
> > 5590396 Dump or Wrong Results with ANSI JOINS and CONNECT BY
> > 5765958 OERI[qcscpqbTxt] / OERI[qcsfbdnp:1] from ANSI query in PLSQL
> > 5964193 OERI[kkqsRewriteCorrCols-1] during query rewrite with ANSI
joins
> > 5988085 Dump [kkodsel] from STAR transformation with ANSI view
> >
> > ==> o bug 5188321, por exemplo, é explícito :
> >
> > Bug 5188321 wrong results (no rows) from ANSI outer join
> >
> > This note gives a brief overview of bug 5188321.
> > Affects:
> >
> > Product (Component) Oracle Server (Rdbms)
> > Range of versions believed to be affected Versions < 11
> > Versions confirmed as being affected
> >
> > * 9.2.0.7
> > * 9.2.0.8
> > * 10.1.0.5
> >
> > Platforms affected Generic (all / most platforms affected)
> >
> > Fixed:
> >
> > This issue is fixed in
> >
> > * 10.2.0.4 (Server Patch Set)
> > * 11g (Future version)
> >
> > Symptoms:
> >
> > Related To:
> >
> > * Wrong Results
> > * ANSI Joins
> >
> > Description
> >
> > Wrong results can be returned with a query involving a very large
> > select
> > list count when ANSI OUTER JOIN syntax is used.
> >
> > Workaround:
> > Use native oracle outer join syntax
> > or
> > reduce the select list count.
> >
> > ==> ou seja, não há patch e o workaround é usar a boa e velha sintaxe
> > nativa Então pra mim, que manipulo sempre grandes volumes, vcs
> > podem imaginar ser seguríssimo apostar um picolé de limão que ** VAI
> > ** demorar um pouquinho pra eu começar a me preocupar com sintaxe
ANSI...
> >
> > []s
> >
> > Chiappa
> >
> > --- Em oracle_br@yahoogrupos.com.br ,
> > "Andre Santos"
> >  escreveu
> > >
> > > Alisson
> > >
> > > Foi na documentação do Oracle9i Database:
> > > - SQL Reference
> > > - Joins
> > > <
> > >
> >
> >
http://download.oracle.com/docs/cd/B10501_01/server.920/a96540/queries7.htm#2054014
> > > >
> > >
> > > Mas a recomendação permanece na documentação da versão mais
atual (11g):
> > > <
> > >
> >
> >
http://download.oracle.com/docs/cd/B28359_01/server.111/b28286/queries006.htm#sthref3238
> > > >
> > >
> > > [ ]
> > >
> > > André
> > >
> > >
> > > Em 16/11/07, Alisson Aguiar  escreveu:
> > > >
> > > > Beleza, André. Obrigado pela informação.
> > > >
> > > > Só para complementar, você tem o link da fonte essa
informação? É o
> > > > manual,
> > > > White Paper, etc. ? Gostaria de apresentar essa informação
(Oracle),
> > > > juntamente com outras que coletei.
> > > >
> > > > Abraço,
> > > > Alisson
> > > >
> > > > Em 16/11/07, Andre Santos
> > >
> > > > escreveu:
> > > > >
> > > > > Alisson
> > > > >
> > > > > A própria Oracle recomenda que se use a sintaxe mais moderna
(atual
> > > > padrão
> > > > > ANSI), em vez do antigo operador (+):
> > > > > 
> > > > > Oracle Corporation recommends that you use the FROM clause OUTER
> > JOIN
> > > > > syntax
> > > > > rather than the Oracle join operator. Outer join queries that
> > use the
> > > > > Oracle
> > > > > join operator (+) are subject to the following rules and
> > restrictions,
> > > > > which
> > > > > do not apply to the FROM clause join syntax:
> > > > > (...)
> > > > > 
> > > > >
> > > > > Poderia citar umas boas razões para adotar a sintaxe atualizada,
> > mas a
> > > > > questão é sobre performance... no momento, vou no palpite. :^)
> > > > > Algumas vezes, quando fiz um outer join na sintaxe "antiga"
e depois
> > > > refiz
> > > > > na sintaxe "atual", notei que a ordenação do conjunto de
linhas foi
> > > > > diferente... daí 

Re: [oracle_br] Re: Performance no Oracle com SQL ANSI

[Andre Santos]

Chiappa

Muito obrigado pela informação! É sempre bom ter em mente que, dependendo da
versão/release, podem haver bugs.

Mas, esses específicos que você citou, estão corrigidos a partir da versão
10.2.0.4, certo? (pelo menos, foi o que a nota menciona).

Valeu!

[ ]

André


Em 21/11/07, jlchiappa <[EMAIL PROTECTED]> escreveu:
>
>   Só acrescento que :
>
> a) a recomendação do manual ** não é ** por causa de performance, veja
> lá que nas razões, são citadas a melhor legibilidade da sintaxe ANSI,
> features que são mais difíceis de imitar na sintaxe tradicional (como
> FULL OUTER JOINs, OUTER JOIN da mesma tabela com várias outras, etc)
>
> e
>
> b) a pessoa ** TEM QUE VER ** se dá pra se usar a sintaxe ANSI no caso
> dela : por ser mais nova, ainda há mais de um bug sendo resolvido pra
> elas. Falando de 10g, de cara temos os seguintes bugs abertos (nota
> 401436.1 Subject: 10.2.0.4 Patch Set - List of Bug Fixes by Problem
> Type) :
>
> ANSI Joins
> 4204383 Dump [kkqtnlocbk] optimizing ANSI OUTER JOINs with subqueries
> 4702830 OERI[kkoljt1] when using star transformation with an ANSI
> outer join
> 4901291 Wrong results with left outer joins on view with a function
> 5188321 wrong results (no rows) from ANSI outer join
> 5590396 Dump or Wrong Results with ANSI JOINS and CONNECT BY
> 5765958 OERI[qcscpqbTxt] / OERI[qcsfbdnp:1] from ANSI query in PLSQL
> 5964193 OERI[kkqsRewriteCorrCols-1] during query rewrite with ANSI joins
> 5988085 Dump [kkodsel] from STAR transformation with ANSI view
>
> ==> o bug 5188321, por exemplo, é explícito :
>
> Bug 5188321 wrong results (no rows) from ANSI outer join
>
> This note gives a brief overview of bug 5188321.
> Affects:
>
> Product (Component) Oracle Server (Rdbms)
> Range of versions believed to be affected Versions < 11
> Versions confirmed as being affected
>
> * 9.2.0.7
> * 9.2.0.8
> * 10.1.0.5
>
> Platforms affected Generic (all / most platforms affected)
>
> Fixed:
>
> This issue is fixed in
>
> * 10.2.0.4 (Server Patch Set)
> * 11g (Future version)
>
> Symptoms:
>
> Related To:
>
> * Wrong Results
> * ANSI Joins
>
> Description
>
> Wrong results can be returned with a query involving a very large
> select
> list count when ANSI OUTER JOIN syntax is used.
>
> Workaround:
> Use native oracle outer join syntax
> or
> reduce the select list count.
>
> ==> ou seja, não há patch e o workaround é usar a boa e velha sintaxe
> nativa Então pra mim, que manipulo sempre grandes volumes, vcs
> podem imaginar ser seguríssimo apostar um picolé de limão que ** VAI
> ** demorar um pouquinho pra eu começar a me preocupar com sintaxe ANSI...
>
> []s
>
> Chiappa
>
> --- Em oracle_br@yahoogrupos.com.br ,
> "Andre Santos"
> <[EMAIL PROTECTED]> escreveu
> >
> > Alisson
> >
> > Foi na documentação do Oracle9i Database:
> > - SQL Reference
> > - Joins
> > <
> >
>
> http://download.oracle.com/docs/cd/B10501_01/server.920/a96540/queries7.htm#2054014
> > >
> >
> > Mas a recomendação permanece na documentação da versão mais atual (11g):
> > <
> >
>
> http://download.oracle.com/docs/cd/B28359_01/server.111/b28286/queries006.htm#sthref3238
> > >
> >
> > [ ]
> >
> > André
> >
> >
> > Em 16/11/07, Alisson Aguiar <[EMAIL PROTECTED]> escreveu:
> > >
> > > Beleza, André. Obrigado pela informação.
> > >
> > > Só para complementar, você tem o link da fonte essa informação? É o
> > > manual,
> > > White Paper, etc. ? Gostaria de apresentar essa informação (Oracle),
> > > juntamente com outras que coletei.
> > >
> > > Abraço,
> > > Alisson
> > >
> > > Em 16/11/07, Andre Santos
> <[EMAIL PROTECTED]>
> > > escreveu:
> > > >
> > > > Alisson
> > > >
> > > > A própria Oracle recomenda que se use a sintaxe mais moderna (atual
> > > padrão
> > > > ANSI), em vez do antigo operador (+):
> > > > 
> > > > Oracle Corporation recommends that you use the FROM clause OUTER
> JOIN
> > > > syntax
> > > > rather than the Oracle join operator. Outer join queries that
> use the
> > > > Oracle
> > > > join operator (+) are subject to the following rules and
> restrictions,
> > > > which
> > > > do not apply to the FROM clause join syntax:
> > > > (...)
> > > > 
> > > >
> > > > Poderia citar umas boas razões para adotar a sintaxe atualizada,
> mas a
> > > > questão é sobre performance... no momento, vou no palpite. :^)
> > > > Algumas vezes, quando fiz um outer join na sintaxe "antiga" e depois
> > > refiz
> > > > na sintaxe "atual", notei que a ordenação do conjunto de linhas foi
> > > > diferente... daí suponho que o "plano de execução" deve ter sido um
> > > pouco
> > > > diferente também.
> > > > Já que a Oracle recomenda a sintaxe mais moderna, suponho que a
> > > > "tendência"
> > > > seja que o otimizador seja cada vez mais voltado a isso.
> > > >
> > > > Mas, para tirar qualquer dúvida, seria bom montar um teste (não
> trivial,
> > > > com
> > > > tabelas grandes) e verificar os tempos de resposta e os planos
> de acesso
> > > > gerados.
> > > >
> > > > [ ]
> > > >
> > > > André
> > > >
> > > > Em 

[oracle_br] Re: Performance no Oracle com SQL ANSI

[jlchiappa]

Só acrescento que :

a) a recomendação do manual ** não é ** por causa de performance, veja
lá que nas razões, são citadas a melhor legibilidade da sintaxe ANSI,
features que são mais difíceis de imitar na sintaxe tradicional (como
FULL OUTER JOINs, OUTER JOIN da mesma tabela com várias outras, etc)

e

b) a pessoa ** TEM QUE VER ** se dá pra se usar a sintaxe ANSI no caso
dela : por ser mais nova, ainda há mais de um bug sendo resolvido pra
elas. Falando de 10g, de cara temos os seguintes bugs abertos (nota
401436.1 Subject:   10.2.0.4 Patch Set - List of Bug Fixes by Problem
Type) :

ANSI Joins
4204383 Dump [kkqtnlocbk] optimizing ANSI OUTER JOINs with subqueries
4702830 OERI[kkoljt1] when using star transformation with an ANSI
outer join
4901291 Wrong results with left outer joins on view with a function
5188321 wrong results (no rows) from ANSI outer join
5590396 Dump or Wrong Results with ANSI JOINS and CONNECT BY
5765958 OERI[qcscpqbTxt] / OERI[qcsfbdnp:1] from ANSI query in PLSQL
5964193 OERI[kkqsRewriteCorrCols-1] during query rewrite with ANSI joins
5988085 Dump [kkodsel] from STAR transformation with ANSI view

==> o bug 5188321, por exemplo, é explícito :

Bug 5188321  wrong results (no rows) from ANSI outer join

This note gives a brief overview of bug 5188321.
Affects:

Product (Component) Oracle Server (Rdbms)
Range of versions believed to be affected   Versions < 11
Versions confirmed as being affected

* 9.2.0.7
* 9.2.0.8
* 10.1.0.5 

Platforms affected  Generic (all / most platforms affected)

Fixed:

This issue is fixed in  

* 10.2.0.4 (Server Patch Set)
* 11g (Future version) 

Symptoms:

Related To:

* Wrong Results 
* ANSI Joins 

Description

Wrong results can be returned with a query involving a very large
select 
list count when ANSI OUTER JOIN syntax is used.


Workaround: 
  Use native oracle outer join syntax 
 or 
  reduce the select list count.

==> ou seja, não há patch e o workaround é usar a boa e velha sintaxe
nativa Então pra mim, que manipulo sempre grandes volumes, vcs
podem imaginar ser seguríssimo apostar um picolé de limão que ** VAI
** demorar um pouquinho pra eu começar a me preocupar com sintaxe ANSI...

[]s

 Chiappa
 
--- Em oracle_br@yahoogrupos.com.br, "Andre Santos"
<[EMAIL PROTECTED]> escreveu
>
> Alisson
> 
> Foi na documentação do Oracle9i Database:
> - SQL Reference
>- Joins
> <
>
http://download.oracle.com/docs/cd/B10501_01/server.920/a96540/queries7.htm#2054014
> >
> 
> Mas a recomendação permanece na documentação da versão mais atual (11g):
> <
>
http://download.oracle.com/docs/cd/B28359_01/server.111/b28286/queries006.htm#sthref3238
> >
> 
> [ ]
> 
> André
> 
> 
> Em 16/11/07, Alisson Aguiar <[EMAIL PROTECTED]> escreveu:
> >
> >   Beleza, André. Obrigado pela informação.
> >
> > Só para complementar, você tem o link da fonte essa informação? É o
> > manual,
> > White Paper, etc. ? Gostaria de apresentar essa informação (Oracle),
> > juntamente com outras que coletei.
> >
> > Abraço,
> > Alisson
> >
> > Em 16/11/07, Andre Santos
<[EMAIL PROTECTED]>
> > escreveu:
> > >
> > > Alisson
> > >
> > > A própria Oracle recomenda que se use a sintaxe mais moderna (atual
> > padrão
> > > ANSI), em vez do antigo operador (+):
> > > 
> > > Oracle Corporation recommends that you use the FROM clause OUTER
JOIN
> > > syntax
> > > rather than the Oracle join operator. Outer join queries that
use the
> > > Oracle
> > > join operator (+) are subject to the following rules and
restrictions,
> > > which
> > > do not apply to the FROM clause join syntax:
> > > (...)
> > > 
> > >
> > > Poderia citar umas boas razões para adotar a sintaxe atualizada,
mas a
> > > questão é sobre performance... no momento, vou no palpite. :^)
> > > Algumas vezes, quando fiz um outer join na sintaxe "antiga" e depois
> > refiz
> > > na sintaxe "atual", notei que a ordenação do conjunto de linhas foi
> > > diferente... daí suponho que o "plano de execução" deve ter sido um
> > pouco
> > > diferente também.
> > > Já que a Oracle recomenda a sintaxe mais moderna, suponho que a
> > > "tendência"
> > > seja que o otimizador seja cada vez mais voltado a isso.
> > >
> > > Mas, para tirar qualquer dúvida, seria bom montar um teste (não
trivial,
> > > com
> > > tabelas grandes) e verificar os tempos de resposta e os planos
de acesso
> > > gerados.
> > >
> > > [ ]
> > >
> > > André
> > >
> > > Em 16/11/07, Alisson Aguiar <[EMAIL PROTECTED]
>
> > > escreveu:
> > > >
> > > > Pessoal,
> > > >
> > > > Existe diferença de performance ao utilizar a sintaxe
proprietária do
> > > > Oracle
> > > > e o padrão ANSI 92/99 no que diz respeito ao OUTER JOIN? Fui
> > questionado
> > > > sobre essa diferença e nunca medi para ver se existe.
> > > >
> > > > Alguém aqui já chegou ver se realmente existe diferença na
performance
> 

[oracle_br] Re: Performance do banco de dados!

[jlchiappa]

Vou responder em ordem inversa : primeiro, vc compara é a proporção 
de LIOs x linhas efetivamente retornadas - por exemplo, digamos que 
vc vá fazer um acesso via índice direto, vc vai fazer um I/O do bloco 
de header do índice, depois ao menos um I/O de bloco branch 
(tipicamente na verdade em produção ao menos 2 blocos branch, em 
produção com tabs grandes é comum vc ter índices "altos") ,depois 
outro I/O do bloco leaf, que aí sim aponta pro bloco desejado com o 
registro na tabela, bloco esse que será lido também - assim, ao menos 
5 I/Os pra se obter uma linha via índice é um mínimo comum. Assim, no 
seu exemplo, se esses 1000 LIOs  trouxeram (digamos) , cento e tantas 
linhas, perfeito, fez uma média próxima disso de I/O por linha, é uma 
boa indicação de eficiência. Agora, imagine que esses mesmos 1000 
LIOs trouxeram apenas meia dúzia de linhas, isso está muito muito 
longe do ideal, algo está TERRIVELMENTE errado aí, talvez um HWM 
alto, talvez um plano ineficiente, algo não tá bem..
 =>> EVIDENTE, esse tipo de análise não é aplicável sempre, 
por exemplo se vc tem algum tipo de agrupação, como um COUNT, óbvio 
que agrupação significa ler largas porções da tabela fazendo 
trocentos I/Os pra te trazer só uma linha que é o resultado da 
contagem, óbvio que a relação entre LIOs x resultado estará 
NATURALMENTE distorcida aqui. Casos deste tipo aí sim, é mesmo 
empírico, é vc testar vários planos, re-escrever o SQL (com 
analytics, com o que puder) e ir comparando pra ver qual faz menos 
LIOs
 Quanto ao nested loops, ele NÃO é sempre bom, e nem (pra citar o 
caso típico) o full table scan é sempre ruim, tudo SEMPRE SEMPRE 
depende do caso, depende doseu objetivo Sabendo-se a teoria por 
trás do método (que no caso de nested loop basicamente é : escolhe-se 
uma tabela drive que será lida até o fim, pra cada linha lida busca-
se os detalhes na outra tab do join), fica claro que isso é ultra-
eficiente quando a tabela drive é ** pequena **, ou no caso em que a 
tab drive é grande MAS vc quer obter as primeiras linhas mais 
rapidamente (por exemplo, aquelas queries de paginação, onde vc 
mostra os primeiros 10 regs, depois que o usuário aperta 1 botão 
mostra mais 10). Claro que se o seu objetivo é processar tudo o mais 
rapidamente E a tabela não é de tamanho trivial, é via de regra *** 
muito mais *** eficiente vc processar múltiplas linhas por vez, ao 
invés de uma por uma que é o que o NL faz...  No "Effective Oracle by 
Design" o Tom Kyte discute isso com exemplinhos muito bons, eu *** 
RECOMENDO ENFATICAMENTE *** que vc o adquira e o use, pra Ontem
 
 []s
 
  Chiappa
  
--- Em oracle_br@yahoogrupos.com.br, Thiago Lazzarotto 
<[EMAIL PROTECTED]> escreveu
>
> Bom dia Lista!
> 
> Como sempre Chiappa, boas explicações.
> É verdade que em meu sistema tenho muitas querys com nested loop. 
Muitas 
> mesmo.
> Mas isso não é bom? Ou nem sempre é bom?
> 
> Como o meu número de logical reads é muito maior que o physical 
reads, 
> vou começar a investigar
> pelos consumidores de logical reads.
> 
> Existe algum valor aceitável para logical reads por query? Por 
exemplo, 
> como vou saber se 1000 logical reads é muito ou pouco?
> Só testando?
> 
> Valeu amigos.
> Thiago.
> 
> 
> jlchiappa escreveu:
> 
> > --- Em oracle_br@yahoogrupos.com.br 
> > , Thiago Lazzarotto
> >  escreveu
> > >
> > > Pelo SO tem como ver qual o processo que está fazendo mais
> > > I/O?
> > > Ou somente pelo banco?
> >
> > Até tem, mas como disse a análise pelo SO normalmente tem dois
> > problemas : o SO não te mostra o histórico , só te mostra os top
> > processos , E só se estiverem fazendo o I/O exatamente na hora 
que vc
> > está analisando... Até existem ferramentas à parte do SO 
normalmente
> > que permitem vc acompanhar o histórico de I/O dum processo, que 
dizem
> > pra cada processo quantos % de I/O consumiu (tipo, existiam x
> > processos na máquina, foram feitos n I/Os no sistema no total, 
assim
> > se um dado processo fez y I/Os isso representa tantos % do I/O
> > servido)mas normalmente isso não é parte integrante do SO...
> > Então, se omo a maioria dos sistemas o seu basicamente processe o 
que
> > veio do banco, I/O do banco está sempre envolvido, recomendaria
> > começar olhando no banco, mesmo.
> >
> >
> > >
> > > > O que notei analisando os statspack é que o número de waits 
não
> > aumentou
> > > > muito, mas o tempo de wait, esse sim aumentou bastante nas 
últimas
> > > > semanas...
> >
> > Ou seja, teve sim processos/programas/alguma coisa nova que entrou
> > (senão nada mudaria), e na média o tempo que os I/Os levam pra ser
> > completados aumentou... Tranquilamente pode ser que o(s)
> > programa(s)/processos mal-comportados estejam (por exemplo) 
fazendo
> > nested loop, aí ele só faz I/Os curtos (PORTANTO não aperecriam em
> > TOPs e coisas do tipo), mas são I/Os constantes, cabou um I/O 
pequeno
> > imediatamente ele pede outro e logo em seguida o

[oracle_br] Re: Performance do banco de dados!

[hribeiro01]

 Thiago,

  Intrometendo na conversa, como esta configurado as Lun's dentro da
Storage EMC? Vc usa multiplexação de FC? Qual eh a Capacidade de Block
Size da Lun? Q tipo de Storage vc usa? Symetrix ou Clariion? A Lun's
estão em TressPass?

--- Em oracle_br@yahoogrupos.com.br, Thiago Lazzarotto
<[EMAIL PROTECTED]> escreveu
>
> Bom dia Lista!
> 
> Como sempre Chiappa, boas explicações.
> É verdade que em meu sistema tenho muitas querys com nested loop.
Muitas 
> mesmo.
> Mas isso não é bom? Ou nem sempre é bom?
> 
> Como o meu número de logical reads é muito maior que o physical reads, 
> vou começar a investigar
> pelos consumidores de logical reads.
> 
> Existe algum valor aceitável para logical reads por query? Por exemplo, 
> como vou saber se 1000 logical reads é muito ou pouco?
> Só testando?
> 
> Valeu amigos.
> Thiago.
> 
> 
> jlchiappa escreveu:
> 
> > --- Em oracle_br@yahoogrupos.com.br 
> > , Thiago Lazzarotto
> >  escreveu
> > >
> > > Pelo SO tem como ver qual o processo que está fazendo mais
> > > I/O?
> > > Ou somente pelo banco?
> >
> > Até tem, mas como disse a análise pelo SO normalmente tem dois
> > problemas : o SO não te mostra o histórico , só te mostra os top
> > processos , E só se estiverem fazendo o I/O exatamente na hora que vc
> > está analisando... Até existem ferramentas à parte do SO normalmente
> > que permitem vc acompanhar o histórico de I/O dum processo, que dizem
> > pra cada processo quantos % de I/O consumiu (tipo, existiam x
> > processos na máquina, foram feitos n I/Os no sistema no total, assim
> > se um dado processo fez y I/Os isso representa tantos % do I/O
> > servido)mas normalmente isso não é parte integrante do SO...
> > Então, se omo a maioria dos sistemas o seu basicamente processe o que
> > veio do banco, I/O do banco está sempre envolvido, recomendaria
> > começar olhando no banco, mesmo.
> >
> >
> > >
> > > > O que notei analisando os statspack é que o número de waits não
> > aumentou
> > > > muito, mas o tempo de wait, esse sim aumentou bastante nas últimas
> > > > semanas...
> >
> > Ou seja, teve sim processos/programas/alguma coisa nova que entrou
> > (senão nada mudaria), e na média o tempo que os I/Os levam pra ser
> > completados aumentou... Tranquilamente pode ser que o(s)
> > programa(s)/processos mal-comportados estejam (por exemplo) fazendo
> > nested loop, aí ele só faz I/Os curtos (PORTANTO não aperecriam em
> > TOPs e coisas do tipo), mas são I/Os constantes, cabou um I/O pequeno
> > imediatamente ele pede outro e logo em seguida outro e logo em
> > seguida outro, ou seja, não tem um think time pra dar chance pro banco
> > servir outro processo Um cara desse vc só pega NO HISTÓRICO,
> > anaálise com vmstat/top/glance/similares é um instantãneo, não
serviria.
> > É como eu disse, análise de processo como um todo E analisar os
> > principais processos Acho que seria MUITO muito interessante aí
> > tentar se confirmar a performance do sub-sistema de disco per se, tipo
> > : com o banco e aplicação parados vc faz uma medida, sobe o banco e
> > ainda sem usuários faz outra, aí cfrme os usuários vão entrando vc vai
> > fazendo novas medidas, E finalmente quando em modo normal de processo
> > faz mais uma... http://www.acnc.com/benchmarks.html 
> >  tem algumas tools
> > free pra isso, das que ele cita quando eu precisei uma vez eu usei o
> > iozone. Mas isso é informação complementar, pra mim o pono aí AINDA é
> > processo fazendo LIOs feito doido.
> > E só complementando : não só eu como o resto do pessoal que tá
> > conversando com vc, estamos todos focando em I/O - de repente
> > tranquilamente PODE ser que hajam outras questões aí... Eu sugiro que
> > vc passe o teu trace 10046 dos principais processos também pela
> > ferramenta ORASRP, ele monta um relatóriozinho mais detalhado do que o
> > tkprof, de repente outras coisas podem aparecer. Tem uma versão nova
> > dela em http://oracledba.ru/orasrp/ 
> >
> > []s
> >
> > Chiappa
> >
> >  
> 
> 
> 
> [As partes desta mensagem que não continham texto foram removidas]
>

Re: [oracle_br] Re: Performance do banco de dados!

[Thiago Lazzarotto]

Bom dia Lista!

Como sempre Chiappa, boas explicações.
É verdade que em meu sistema tenho muitas querys com nested loop. Muitas 
mesmo.
Mas isso não é bom? Ou nem sempre é bom?

Como o meu número de logical reads é muito maior que o physical reads, 
vou começar a investigar
pelos consumidores de logical reads.

Existe algum valor aceitável para logical reads por query? Por exemplo, 
como vou saber se 1000 logical reads é muito ou pouco?
Só testando?

Valeu amigos.
Thiago.


jlchiappa escreveu:

> --- Em oracle_br@yahoogrupos.com.br 
> , Thiago Lazzarotto
> <[EMAIL PROTECTED]> escreveu
> >
> > Pelo SO tem como ver qual o processo que está fazendo mais
> > I/O?
> > Ou somente pelo banco?
>
> Até tem, mas como disse a análise pelo SO normalmente tem dois
> problemas : o SO não te mostra o histórico , só te mostra os top
> processos , E só se estiverem fazendo o I/O exatamente na hora que vc
> está analisando... Até existem ferramentas à parte do SO normalmente
> que permitem vc acompanhar o histórico de I/O dum processo, que dizem
> pra cada processo quantos % de I/O consumiu (tipo, existiam x
> processos na máquina, foram feitos n I/Os no sistema no total, assim
> se um dado processo fez y I/Os isso representa tantos % do I/O
> servido)mas normalmente isso não é parte integrante do SO...
> Então, se omo a maioria dos sistemas o seu basicamente processe o que
> veio do banco, I/O do banco está sempre envolvido, recomendaria
> começar olhando no banco, mesmo.
>
>
> >
> > > O que notei analisando os statspack é que o número de waits não
> aumentou
> > > muito, mas o tempo de wait, esse sim aumentou bastante nas últimas
> > > semanas...
>
> Ou seja, teve sim processos/programas/alguma coisa nova que entrou
> (senão nada mudaria), e na média o tempo que os I/Os levam pra ser
> completados aumentou... Tranquilamente pode ser que o(s)
> programa(s)/processos mal-comportados estejam (por exemplo) fazendo
> nested loop, aí ele só faz I/Os curtos (PORTANTO não aperecriam em
> TOPs e coisas do tipo), mas são I/Os constantes, cabou um I/O pequeno
> imediatamente ele pede outro e logo em seguida outro e logo em
> seguida outro, ou seja, não tem um think time pra dar chance pro banco
> servir outro processo Um cara desse vc só pega NO HISTÓRICO,
> anaálise com vmstat/top/glance/similares é um instantãneo, não serviria.
> É como eu disse, análise de processo como um todo E analisar os
> principais processos Acho que seria MUITO muito interessante aí
> tentar se confirmar a performance do sub-sistema de disco per se, tipo
> : com o banco e aplicação parados vc faz uma medida, sobe o banco e
> ainda sem usuários faz outra, aí cfrme os usuários vão entrando vc vai
> fazendo novas medidas, E finalmente quando em modo normal de processo
> faz mais uma... http://www.acnc.com/benchmarks.html 
>  tem algumas tools
> free pra isso, das que ele cita quando eu precisei uma vez eu usei o
> iozone. Mas isso é informação complementar, pra mim o pono aí AINDA é
> processo fazendo LIOs feito doido.
> E só complementando : não só eu como o resto do pessoal que tá
> conversando com vc, estamos todos focando em I/O - de repente
> tranquilamente PODE ser que hajam outras questões aí... Eu sugiro que
> vc passe o teu trace 10046 dos principais processos também pela
> ferramenta ORASRP, ele monta um relatóriozinho mais detalhado do que o
> tkprof, de repente outras coisas podem aparecer. Tem uma versão nova
> dela em http://oracledba.ru/orasrp/ 
>
> []s
>
> Chiappa
>
>  



[As partes desta mensagem que não continham texto foram removidas]

[oracle_br] Re: Performance do banco de dados!

[jlchiappa]

--- Em oracle_br@yahoogrupos.com.br, Thiago Lazzarotto
<[EMAIL PROTECTED]> escreveu
>
> Pelo SO tem como ver qual o processo que está fazendo mais 
> I/O?
> Ou somente pelo banco?

Até tem, mas como disse a análise pelo SO normalmente tem dois
problemas : o SO não te mostra o histórico , só te mostra os top
processos , E só se estiverem fazendo o I/O exatamente na hora que vc
está analisando... Até existem ferramentas à parte do SO normalmente
que permitem vc acompanhar o histórico de I/O dum processo, que dizem
pra cada processo quantos % de I/O consumiu (tipo, existiam x
processos na máquina, foram feitos n I/Os no sistema no total, assim
se um dado processo fez y I/Os isso representa tantos % do I/O
servido)mas normalmente isso não é parte integrante do SO...
 Então, se omo a maioria dos sistemas o seu basicamente processe o que
veio do banco, I/O do banco está sempre envolvido, recomendaria
começar olhando no banco, mesmo.
 


> 
> > O que notei analisando os statspack é que o número de waits não
aumentou
> > muito, mas o tempo de wait, esse sim aumentou bastante nas últimas
> > semanas...

Ou seja, teve sim processos/programas/alguma coisa nova que entrou
(senão nada mudaria), e na média o tempo que os I/Os levam pra ser
completados aumentou... Tranquilamente pode ser que o(s)
programa(s)/processos mal-comportados estejam (por exemplo) fazendo
nested loop, aí ele só faz I/Os curtos (PORTANTO não aperecriam em
TOPs e coisas do tipo), mas são I/Os constantes, cabou um  I/O pequeno
 imediatamente ele pede outro e logo em seguida outro e logo em
seguida outro, ou seja, não tem um think time pra dar chance pro banco
servir outro processo Um cara desse vc só pega NO HISTÓRICO,
anaálise com vmstat/top/glance/similares é um instantãneo, não serviria.
 É como eu disse, análise de processo como um todo E analisar os
principais processos Acho que seria MUITO muito interessante aí
tentar se confirmar a performance do sub-sistema de disco per se, tipo
: com o banco e aplicação parados vc faz uma medida, sobe o banco e
ainda sem usuários faz outra, aí cfrme os usuários vão entrando vc vai
fazendo novas medidas, E finalmente quando em modo normal de processo
faz mais uma...  http://www.acnc.com/benchmarks.html tem algumas tools
free pra isso, das que ele cita quando eu precisei uma vez eu usei o
iozone.  Mas isso é informação complementar, pra mim o pono aí AINDA é
 processo fazendo LIOs feito doido.
 E só complementando : não só eu como o resto do pessoal que tá
conversando com vc, estamos todos focando em I/O - de repente
tranquilamente PODE ser que hajam outras questões aí... Eu sugiro que
vc passe o teu trace 10046 dos principais processos também pela
ferramenta ORASRP, ele monta um relatóriozinho mais detalhado do que o
tkprof, de repente outras coisas podem aparecer. Tem uma versão nova
dela em http://oracledba.ru/orasrp/

[]s

 Chiappa

Re: [oracle_br] Re: Performance do banco de dados!

[Thiago Lazzarotto]

Uma pergunta? Pelo SO tem como ver qual o processo que está fazendo mais 
I/O?
Ou somente pelo banco?

Obrigado
Thiago.

Thiago Lazzarotto escreveu:

> O que notei analisando os statspack é que o número de waits não aumentou
> muito, mas o tempo de wait, esse sim aumentou bastante nas últimas
> semanas...
>
> Vou ver o que descubro e mando pro grupo.
>
> Valeu.
>
> jlchiappa escreveu:
>
> > Bem, análise de performance é um trabalho que tem que ser feito
> > LOCALMENTE, e que consome tempo pra se fazer, sem dúvida nenhuma um e-
> > mail curto E escrito à distância não vai te dar solução, mas seguem
> > alguns comentários que podem ter ajudar - a maioria deles são tópicos
> > que pretendo abordar no Workshop de SQL que a gente citou no ENPO,
> > que está em progresso, mas é o seguinte : veja vc, o uso de
> > statspack e tools gerais, que te dão visão geral do banco como um
> > todo, é limitado, se a análise rápida e rasteira não te indicou nada
> > óbvio nos SQLs top, isso por si só é uma indicação de que vc OU tem
> > alguns ** poucos ** processos ruins que bagunçam geral o I/O mas
> > são "escondidos" na análise de top pelos outros muitos bons ou
> > neutros, OU que realmente o hardware não está dando conta. Pra vc
> > poder concluir o hardware, vc ** TEM QUER SE TER ASSEGURADO ** que
> > não há nenhum processo importante que esteja desperdiçando I/O, é
> > isso. É aquela história, se vc tiver processos fazendo MONTES e
> > MONTES de I/O desnecessários feito loucos, vc pode ter o hardware de
> > I/O mais poderoso que quiser que provavelmente ele não dará
> > conta. Como normalmente (a não ser nos casos mais raros e fáceis)
> > não é o sistema como um todo que está ruim, então NÃO HÁ "análise que
> > pode ser feita pelo banco para identificar isso"... NÃO TEM JEITO, vc
> > terá que identificar todos os processos importantes e comuns (veja,
> > NÂO ESTOU falando de SQLs , mas sim de PROCESSOS DE NEGÓCIO) e ver
> > pra cada um deles se está bem de I/O, se não está fazendo mais I/Os
> > que o mínimo necessário... Uma das tools que vc pode usar pra isso
> > para os processos que fundamentalmente processem dados vindos dum bd
> > Oracle é gerar um trace+tkprof e ver como é a proporção de LIOs x
> > linhas efetivamente recuperadas, ** se ** houver algo absolutamente
> > desproporcional (tipo, poucas centenas de linhas resultando de
> > centenas de milhares de LIOs) esse cara é suspeito de poder ser
> > melhorado (seja com alteração nas estruturas físicas, como
> > particionamento ou GTTs, resetando um eventual HWM muito alto, seja
> > mesmo re-escrevendo o SQL de modo que faça menos LIOs - por exemplo,
> > usando Analytics, usando alguma feature que elimine sub-queries por
> > exemplo, seja mudando o plano via stats melhores, seja mesmo via
> > hints em ** último caso **). De referência, recomendaria o estudo do
> > paper "Why You Should Focus on LIOs Instead of PIOs" no site
> > hotsos.com
> > >>> UMA VEZ realmente feito um esforço ** SÉRIO ** e completo
> > pra reduzir I/O e realmente não tendo sido possível, aí sim vc pode
> > concluir não há desperdício, e que o subsistema de I/O não está
> > adendendo à demanda . E note que pelos motivos citados no paper, o
> > alvo é diminuir o total de I/Os Oracle, os LIOs, SE os PIOs estão
> > baixos (por causa do cache do storage, por exemplo), ** MAS ** a mal-
> > comportada da aplicação faz montes de LIOs isso FATALMENTE causa
> > waits e FATALMENBET não aparecerá nas tools de SO, talvez dai
> > o "pelas ferramentas da EMC,vejo que o Storage está sobrando" que vc
> > diz...
> >
> > []s
> >
> > Chiappa
> >
> > --- Em oracle_br@yahoogrupos.com.br 
> 
> > , Thiago Lazzarotto
> > <[EMAIL PROTECTED]> escreveu
> > >
> > > Olá pessoal! Tudo bem?
> > >
> > > Gostaria que vocês me ajudassem.
> > > Estamos com problemas de performance no banco de dados. Versao 91R2
> > > Enterprise com RAC
> > > As 2 máquinas são 2xIntel Xeon Dual Core com 12 gb de memória.
> > > O meu problema está relacionado com I/O.
> > > Quase todas as sessões ficam fazendo db file sequential read (70%
> > do
> > > total de wait).
> > > Vendo pelo top no Linux (RH4.0 U3), percebo que o % de cpu
> > aguardando
> > > I/O está muito alto (em torno de 40%).
> > > E ainda tenho cpu idle (mais de 30%)
> > >
> > > Não tenho problemas com latches nem locks.
> > >
> > > A dúvida é onde está o problema, porque a máquina está esperando
> > por I/O
> > > e tem CPU sobrando...
> > > Há alguma análise que pode ser feita pelo banco para identificar
> > isso?
> > > Vcs acham que pode ser problema no Storage? Pelas ferramentas da
> > EMC,
> > > vejo que o Storage está sobrando...
> > >
> > > Agradeço qualquer dica!!!
> > >
> > > Obrigado.
> > > Thiago.
> > >
> > >
> > > [As partes desta mensagem que não continham texto foram removidas]
> > >
> >
> >
>
> [As partes desta mensagem que não continham texto foram removidas]
>
>  



[As partes 

Re: [oracle_br] Re: Performance do banco de dados!

[Thiago Lazzarotto]

O que notei analisando os statspack é que o número de waits não aumentou 
muito, mas o tempo de wait, esse sim aumentou bastante nas últimas 
semanas...

Vou ver o que descubro e mando pro grupo.

Valeu.

jlchiappa escreveu:

> Bem, análise de performance é um trabalho que tem que ser feito
> LOCALMENTE, e que consome tempo pra se fazer, sem dúvida nenhuma um e-
> mail curto E escrito à distância não vai te dar solução, mas seguem
> alguns comentários que podem ter ajudar - a maioria deles são tópicos
> que pretendo abordar no Workshop de SQL que a gente citou no ENPO,
> que está em progresso, mas é o seguinte : veja vc, o uso de
> statspack e tools gerais, que te dão visão geral do banco como um
> todo, é limitado, se a análise rápida e rasteira não te indicou nada
> óbvio nos SQLs top, isso por si só é uma indicação de que vc OU tem
> alguns ** poucos ** processos ruins que bagunçam geral o I/O mas
> são "escondidos" na análise de top pelos outros muitos bons ou
> neutros, OU que realmente o hardware não está dando conta. Pra vc
> poder concluir o hardware, vc ** TEM QUER SE TER ASSEGURADO ** que
> não há nenhum processo importante que esteja desperdiçando I/O, é
> isso. É aquela história, se vc tiver processos fazendo MONTES e
> MONTES de I/O desnecessários feito loucos, vc pode ter o hardware de
> I/O mais poderoso que quiser que provavelmente ele não dará
> conta. Como normalmente (a não ser nos casos mais raros e fáceis)
> não é o sistema como um todo que está ruim, então NÃO HÁ "análise que
> pode ser feita pelo banco para identificar isso"... NÃO TEM JEITO, vc
> terá que identificar todos os processos importantes e comuns (veja,
> NÂO ESTOU falando de SQLs , mas sim de PROCESSOS DE NEGÓCIO) e ver
> pra cada um deles se está bem de I/O, se não está fazendo mais I/Os
> que o mínimo necessário... Uma das tools que vc pode usar pra isso
> para os processos que fundamentalmente processem dados vindos dum bd
> Oracle é gerar um trace+tkprof e ver como é a proporção de LIOs x
> linhas efetivamente recuperadas, ** se ** houver algo absolutamente
> desproporcional (tipo, poucas centenas de linhas resultando de
> centenas de milhares de LIOs) esse cara é suspeito de poder ser
> melhorado (seja com alteração nas estruturas físicas, como
> particionamento ou GTTs, resetando um eventual HWM muito alto, seja
> mesmo re-escrevendo o SQL de modo que faça menos LIOs - por exemplo,
> usando Analytics, usando alguma feature que elimine sub-queries por
> exemplo, seja mudando o plano via stats melhores, seja mesmo via
> hints em ** último caso **). De referência, recomendaria o estudo do
> paper "Why You Should Focus on LIOs Instead of PIOs" no site
> hotsos.com
> >>> UMA VEZ realmente feito um esforço ** SÉRIO ** e completo
> pra reduzir I/O e realmente não tendo sido possível, aí sim vc pode
> concluir não há desperdício, e que o subsistema de I/O não está
> adendendo à demanda . E note que pelos motivos citados no paper, o
> alvo é diminuir o total de I/Os Oracle, os LIOs, SE os PIOs estão
> baixos (por causa do cache do storage, por exemplo), ** MAS ** a mal-
> comportada da aplicação faz montes de LIOs isso FATALMENTE causa
> waits e FATALMENBET não aparecerá nas tools de SO, talvez dai
> o "pelas ferramentas da EMC,vejo que o Storage está sobrando" que vc
> diz...
>
> []s
>
> Chiappa
>
> --- Em oracle_br@yahoogrupos.com.br 
> , Thiago Lazzarotto
> <[EMAIL PROTECTED]> escreveu
> >
> > Olá pessoal! Tudo bem?
> >
> > Gostaria que vocês me ajudassem.
> > Estamos com problemas de performance no banco de dados. Versao 91R2
> > Enterprise com RAC
> > As 2 máquinas são 2xIntel Xeon Dual Core com 12 gb de memória.
> > O meu problema está relacionado com I/O.
> > Quase todas as sessões ficam fazendo db file sequential read (70%
> do
> > total de wait).
> > Vendo pelo top no Linux (RH4.0 U3), percebo que o % de cpu
> aguardando
> > I/O está muito alto (em torno de 40%).
> > E ainda tenho cpu idle (mais de 30%)
> >
> > Não tenho problemas com latches nem locks.
> >
> > A dúvida é onde está o problema, porque a máquina está esperando
> por I/O
> > e tem CPU sobrando...
> > Há alguma análise que pode ser feita pelo banco para identificar
> isso?
> > Vcs acham que pode ser problema no Storage? Pelas ferramentas da
> EMC,
> > vejo que o Storage está sobrando...
> >
> > Agradeço qualquer dica!!!
> >
> > Obrigado.
> > Thiago.
> >
> >
> > [As partes desta mensagem que não continham texto foram removidas]
> >
>
>  



[As partes desta mensagem que não continham texto foram removidas]

[oracle_br] Re: Performance do banco de dados!

[jlchiappa]

Bem, análise de performance é um trabalho que tem que ser feito 
LOCALMENTE, e que consome tempo pra se fazer, sem dúvida nenhuma um e-
mail curto E escrito à distância não vai te dar solução, mas seguem 
alguns comentários que podem ter ajudar - a maioria deles são tópicos 
que pretendo abordar no Workshop de SQL que a gente citou no ENPO, 
que está em progresso, mas é o seguinte  : veja vc, o uso de 
statspack e tools gerais, que te dão visão geral do banco como um 
todo, é limitado, se a análise rápida e rasteira não te indicou nada 
óbvio nos SQLs top, isso por si só é uma indicação de que vc OU tem 
alguns ** poucos ** processos ruins que bagunçam geral o I/O mas 
são "escondidos" na análise de top pelos outros muitos bons ou 
neutros, OU que realmente o hardware não está dando conta. Pra vc 
poder concluir o hardware, vc ** TEM QUER SE TER ASSEGURADO ** que 
não há nenhum processo importante que esteja desperdiçando I/O, é 
isso. É aquela história, se vc tiver processos fazendo MONTES e 
MONTES de I/O desnecessários feito loucos, vc pode ter o hardware de 
I/O mais poderoso que quiser que provavelmente ele não dará 
conta. Como normalmente (a não ser nos casos mais raros e fáceis) 
não é o sistema como um todo que está ruim, então NÃO HÁ "análise que 
pode ser feita pelo banco para identificar isso"... NÃO TEM JEITO, vc 
terá que identificar todos os processos importantes e comuns (veja, 
NÂO ESTOU falando de SQLs , mas sim de PROCESSOS DE NEGÓCIO) e ver 
pra cada um deles se está bem de I/O, se não está fazendo mais I/Os 
que o mínimo necessário... Uma das tools que vc pode usar pra isso 
para os processos que fundamentalmente processem dados vindos dum bd 
Oracle é gerar um trace+tkprof e ver como é a proporção de LIOs x 
linhas efetivamente recuperadas, ** se ** houver algo absolutamente 
desproporcional (tipo, poucas centenas de linhas resultando de 
centenas de milhares de LIOs) esse cara é suspeito de poder ser 
melhorado (seja com alteração nas estruturas físicas, como 
particionamento ou GTTs, resetando  um eventual HWM muito alto, seja 
mesmo re-escrevendo o SQL de modo que faça menos LIOs - por exemplo, 
usando Analytics, usando alguma feature que elimine sub-queries por 
exemplo, seja mudando o plano via stats melhores, seja mesmo via 
hints em ** último caso **). De referência, recomendaria o estudo do 
paper "Why You Should Focus on LIOs Instead of PIOs" no site 
hotsos.com 
 >>> UMA VEZ realmente feito um esforço ** SÉRIO ** e completo 
pra reduzir I/O e realmente não tendo sido possível, aí sim vc pode 
concluir não há desperdício, e que o subsistema de I/O não está 
adendendo à demanda . E note que pelos motivos citados no paper, o 
alvo é diminuir o total de I/Os Oracle, os LIOs, SE os PIOs estão 
baixos (por causa do cache do storage, por exemplo), ** MAS ** a mal-
comportada da aplicação faz montes de LIOs isso FATALMENTE causa 
waits e FATALMENBET não aparecerá nas tools de SO, talvez dai 
o "pelas ferramentas da EMC,vejo que o Storage está sobrando" que vc 
diz...
 
 []s
 
   Chiappa
   
--- Em oracle_br@yahoogrupos.com.br, Thiago Lazzarotto 
<[EMAIL PROTECTED]> escreveu
>
> Olá pessoal! Tudo bem?
> 
> Gostaria que vocês me ajudassem.
> Estamos com problemas de performance no banco de dados. Versao 91R2 
> Enterprise com RAC
> As 2 máquinas são 2xIntel Xeon Dual Core com 12 gb de memória.
> O meu problema está relacionado com I/O.
> Quase todas as sessões ficam fazendo db file sequential read (70% 
do 
> total de wait).
> Vendo pelo top no Linux (RH4.0 U3), percebo que o % de cpu 
aguardando 
> I/O está muito alto (em torno de 40%).
> E ainda tenho cpu idle (mais de 30%)
> 
> Não tenho problemas com latches nem locks.
> 
> A dúvida é onde está o problema, porque a máquina está esperando 
por I/O 
> e tem CPU sobrando...
> Há alguma análise que pode ser feita pelo banco para identificar 
isso?
> Vcs acham que pode ser problema no Storage? Pelas ferramentas da 
EMC, 
> vejo que o Storage está sobrando...
> 
> Agradeço qualquer dica!!!
> 
> Obrigado.
> Thiago.
> 
> 
> [As partes desta mensagem que não continham texto foram removidas]
>

[oracle_br] Re: Performance do banco de dados!

[mcampo132001]

Thiago,

Incremente o parametro "db_cache_size" para utilizar mais memória


Marcos Campos

[oracle_br] Re: Performance do Banco

[hribeiro01]

 Glauber,

   Analisando superficialmente, o parametro
"_allow_resetlogs_corruption" esta habilitado.. 
   Dê uma procurada no metalink sobre esse parametro...

 Abs

--- Em oracle_br@yahoogrupos.com.br, Glauber Moisés Garcia
<[EMAIL PROTECTED]> escreveu
>
> Pessoal,
> 
> sou novo aqui no grupo e já vou encher o saco da turma !!!
> 
> Sei pra que realizar tunning de um banco não existe receita...
> Algum tempo atrás eu tinha conseguido uns script´s e com eles umas
> explicações de como analisar os indicadores gerados pelos scripts.
> Com eles fiz alterações nos parametros de SGA e melhoraram muito !.
> Só q perdi esses selects. E agora não consigo encontrar.(Não com as
dicas de análise)
> Se alguém tiver algum material (em portugues) ou possa me auxiliar.
> 
> Tenho um oracle 9i rodando em um HP-ux com 1Gb de memória. 
> O servidor não é dedicado. O sistema utilizado não realiza inserção
maciça 
> de dados. Porém, faz muita consulta ao banco.
> Coloquei os parametros do banco. Se tiver alguém q possa me ajudar !
> 
>  tracefile_identifier 
>  
>   processes 200 
>   sessions 550 
>   timed_statistics TRUE 
>   timed_os_statistics 0 
>   resource_limit FALSE 
>   license_max_sessions 0 
>   license_sessions_warning 0 
>   cpu_count 1 
>   instance_groups 
>  
>   event 
>  
>   shared_pool_size 637534208 
>   sga_max_size 848260384 
>   shared_pool_reserved_size 5242880 
>   large_pool_size 67108864 
>   java_pool_size 16777216 
>   java_soft_sessionspace_limit 0 
>   java_max_sessionspace_size 0 
>   pre_page_sga FALSE 
>   shared_memory_address 0 
>   hi_shared_memory_address 0 
>   use_indirect_data_buffers FALSE 
>   lock_sga FALSE 
>   spfile 
>  
>   lock_name_space 
>  
>   enqueue_resources 1200 
>   trace_enabled TRUE 
>   nls_language AMERICAN 
>   nls_territory AMERICA 
>   nls_sort 
>  
>   nls_date_language 
>  
>   nls_date_format 
>  
>   nls_currency 
>  
>   nls_numeric_characters 
>  
>   nls_iso_currency 
>  
>   nls_calendar 
>  
>   nls_time_format 
>  
>   nls_timestamp_format 
>  
>   nls_time_tz_format 
>  
>   nls_timestamp_tz_format 
>  
>   nls_dual_currency 
>  
>   nls_comp 
>  
>   nls_length_semantics BYTE 
>   nls_nchar_conv_excp FALSE 
>   filesystemio_options asynch 
>   disk_asynch_io FALSE 
>   tape_asynch_io FALSE 
>   dbwr_io_slaves 0 
>   backup_tape_io_slaves FALSE 
>   resource_manager_plan 
>  
>   cluster_interconnects 
>  
>   file_mapping FALSE 
>   active_instance_count 
>  
>   control_files /bdoracle/TASY/ct3/control04.ctl 
>   db_file_name_convert 
>  
>   log_file_name_convert 
>  
>   db_block_buffers 0 
>   db_block_checksum TRUE 
>   db_block_size 8192 
>   db_writer_processes 1 
>   db_keep_cache_size 0 
>   db_recycle_cache_size 0 
>   db_2k_cache_size 0 
>   db_4k_cache_size 0 
>   db_8k_cache_size 0 
>   db_16k_cache_size 0 
>   db_32k_cache_size 0 
>   db_cache_size 16777216 
>   buffer_pool_keep 
>  
>   buffer_pool_recycle 
>  
>   db_cache_advice ON 
>   max_commit_propagation_delay 700 
>   compatible 9.2.0.0.0 
>   remote_archive_enable true 
>   log_archive_start TRUE 
>   log_archive_dest /bdoracle/TASY/arc 
>   log_archive_duplex_dest 
>  
>   log_archive_dest_1 
>  
>   log_archive_dest_2 
>  
>   log_archive_dest_3 
>  
>   log_archive_dest_4 
>  
>   log_archive_dest_5 
>  
>   log_archive_dest_6 
>  
>   log_archive_dest_7 
>  
>   log_archive_dest_8 
>  
>   log_archive_dest_9 
>  
>   log_archive_dest_10 
>  
>   log_archive_dest_state_1 enable 
>   log_archive_dest_state_2 enable 
>   log_archive_dest_state_3 enable 
>   log_archive_dest_state_4 enable 
>   log_archive_dest_state_5 enable 
>   log_archive_dest_state_6 enable 
>   log_archive_dest_state_7 enable 
>   log_archive_dest_state_8 enable 
>   log_archive_dest_state_9 enable 
>   log_archive_dest_state_10 enable 
>   log_archive_max_processes 2 
>   log_archive_min_succeed_dest 1 
>   standby_archive_dest ?/dbs/arch 
>   log_archive_trace 0 
>   fal_server 
>  
>   fal_client 
>  
>   log_archive_format arch_%S.log 
>   log_buffer 75497472 
>   log_checkpoint_interval 6144 
>   log_checkpoint_timeout 1800 
>   archive_lag_target 0 
>   log_parallelism 1 
>   db_files 500 
>   db_file_multiblock_read_count 32 
>   read_only_open_delayed FALSE 
>   cluster_database FALSE 
>   parallel_server FALSE 
>   parallel_server_instances 1 
>   cluster_database_instances 1 
>   db_cr

[oracle_br] Re: Performance em Insert

[jlchiappa]

Não, freeware não, todos que já ouvi falar eram comerciais, ou no 
mínimo shareware. Experimente dar uma caçada no sourceforge e em 
similares, talvez ache algo.

[]s

 Chiappa

> Boa tarde Chiappa vc conhece algum conversor de bancos freeware 
MYSQL para Oracle.
> 
> at
> 
> Wagner Netto
> Dimper Comercial Ltda
> Sagra Produtos Farmaceuticos Ltda
> 16 2101 9195
>   - Original Message -
>   From: jlchiappa
>   To: oracle_br@yahoogrupos.com.br
>   Sent: Friday, December 01, 2006 2:19 PM
>   Subject: [oracle_br] Re: Performance em Insert
> 
> 
> ***
> Sua mensagem foi verificada pelo InterScan MSS.
> ***-***
> 
>   
>   Seguinte : sim, por DEFINIÇÃO quando vc cria um índice vc em 
muitos
>   casos GANHA performance nas consultas, mas isso TEM A OUTRA FACE 
de
>   implicar em diminuição de performance dos DMLs, já que a CADA DML
>   feito o índice tem que ser atualizado (e índices são estruturas
>   COMPLEXAS, que obrigatoriamente TEM QUE estarem fisicamente
>   ordenados, é custoso atualizar índices) - isso está claramente
>   exposto no manual "Oracle Concepts", que recomendo o estudo.
>   Muito bem, continuando : no caso em questão vc está querendo
>   introduzir um GRANDE volume de dados, PORTANTO isso é uma CARGA DE
>   DADOS, uma rotina onde (claro) vc quer ter a maior performance
>   possível em DMLs para que ela termine o quanto antes, pois NINGUÉM
>   tem acesso aos dados antes deles carregarem... Em rotinas do tipo,
>   SIM, é COMUM e RECOMENDADO vc desabilitar índices e constraints,
>   justamente para EVITAR de "pagar o preço" do overhead a cada DML 
(ao
>   final da rotina vc rebuilda os índices - em paralelo e nologging 
se
>   possível -, desta menaira "pagando o preço" duma vez só, á vista 
tem
>   desconto :_) , isso se deve PRINCIPALMENTE ao fato de que, SEM
>   índices presentes, vc tem acesso ao modo NOLOGGING, que muitas 
vezes
>   representa um ABSURDAMENTE ENORME ganho em performance, é técnica
>   PADRÂO em bancos DW/batch, pesquise em http://asktom.oracle.com 
que
>   vc acha diversos artigos e testes demonstrando isso.
> 
>   ==> Afora esse ponto, que vc DEVERÀ SIM implementar se minimamente
>   possível, observo que :
> 
>   - a técnica de
> 
>   insert into tabela values ...
>   exception when dup_val_on_index
>   update tabela set
> 
>   ==> é a PIOR DAS PIORES possíveis, pois vc FAZ o insert, gerando 
redo
>   e undo, que se for duplicação VAI ser desfeito, gerando mais redo 
e
>   tendo que ler o undo, ALTOS I/Os aí... Sem sombra de dúvida, se a 
sua
>   versão de banco já tem e aceita, o comando SQL de MERGE seria 
ULTRA
>   mais eficiente
> 
>   - preferencialmente faz essa carga com uma ferramenta que gere 
SQL e
>   envie diretamente esse SQL pro banco, em PL/SQL a cada SQL enviado
>   pro banco vc PAGA UM PREÇO na forma de context switch, pra uns
>   poucoas registros isso não é nada, MAS pra um grande volume
>   rapidamente isso se torna HORRÍVEL, SQL direto é a melhor 
solução :
>   se a carga é de um aqruivo-texto (tipicamente é) no banco 9i em
>   diante vc tem INCLUSIVE a chance de usar o arquivo-texto como se
>   fosse uma tabela, com a opção de EXTERNAL TABLE, aí o MERGE seria
>   ainda mais eficiente...
> 
>   e finalmente : SE realmente for (por qquer motivo) absolutamente,
>   completamente, inequivocadamente impossível vc fazer em SQL 
apenas e
>   tiver que usar PL/SQL, que AO MENOS vc use array processing e bulk
>   collect, é isso.
> 
>   []s
> 
>   Chiappa
> 
>   --- Em oracle_br@yahoogrupos.com.br, "rbr72"  escreveu
>   >
>   > Pessoal, tava analisando um problema num cliente, e percebi que 
o
>   > processo mais demorado era um insert executado várias vezes numa
>   > tabela. A lógica era mais ou menos essa abaixo, se já existia um
>   > dado na tabela, era feito um update de valores.
>   >
>   > insert into tabela values ...
>   > exception when dup_val_on_index
>   > update tabela set ...
>   >
>   > No trace gerado pelo cliente, ele tentou executar 56000 inserts,
>   > foram gravados somente 56 linhas, o resto foi tudo pro update. O
>   > problema que pra executar os 56000 inserts demorou 300 
segundos, os
>   > updates foram bem rápidos.
>   >
>   > Fazendo os testes, o problema era a primary key, eu desabilitei
>   ela,
>   > criei um indice normal, e fiz a verificacao se o registro 
existe,
>   > faco update, senão, insert. Desse modo ficou bem rápido também.
>   >
>   > O que eu gostaria de saber é a explicação pra isso, sei que, 
com a
>   > primary key, é necessário a

Re: [oracle_br] Re: Performance em Insert

[Wagner Netto]

***
Sua mensagem foi verificada pelo InterScan MSS.
***-***


Boa tarde Chiappa vc conhece algum conversor de bancos freeware MYSQL para 
Oracle.

at

Wagner Netto
Dimper Comercial Ltda
Sagra Produtos Farmaceuticos Ltda
16 2101 9195
  - Original Message -
  From: jlchiappa
  To: oracle_br@yahoogrupos.com.br
  Sent: Friday, December 01, 2006 2:19 PM
  Subject: [oracle_br] Re: Performance em Insert


***
Sua mensagem foi verificada pelo InterScan MSS.
***-***

  
  Seguinte : sim, por DEFINIÇÃO quando vc cria um índice vc em muitos
  casos GANHA performance nas consultas, mas isso TEM A OUTRA FACE de
  implicar em diminuição de performance dos DMLs, já que a CADA DML
  feito o índice tem que ser atualizado (e índices são estruturas
  COMPLEXAS, que obrigatoriamente TEM QUE estarem fisicamente
  ordenados, é custoso atualizar índices) - isso está claramente
  exposto no manual "Oracle Concepts", que recomendo o estudo.
  Muito bem, continuando : no caso em questão vc está querendo
  introduzir um GRANDE volume de dados, PORTANTO isso é uma CARGA DE
  DADOS, uma rotina onde (claro) vc quer ter a maior performance
  possível em DMLs para que ela termine o quanto antes, pois NINGUÉM
  tem acesso aos dados antes deles carregarem... Em rotinas do tipo,
  SIM, é COMUM e RECOMENDADO vc desabilitar índices e constraints,
  justamente para EVITAR de "pagar o preço" do overhead a cada DML (ao
  final da rotina vc rebuilda os índices - em paralelo e nologging se
  possível -, desta menaira "pagando o preço" duma vez só, á vista tem
  desconto :_) , isso se deve PRINCIPALMENTE ao fato de que, SEM
  índices presentes, vc tem acesso ao modo NOLOGGING, que muitas vezes
  representa um ABSURDAMENTE ENORME ganho em performance, é técnica
  PADRÂO em bancos DW/batch, pesquise em http://asktom.oracle.com que
  vc acha diversos artigos e testes demonstrando isso.

  ==> Afora esse ponto, que vc DEVERÀ SIM implementar se minimamente
  possível, observo que :

  - a técnica de

  insert into tabela values ...
  exception when dup_val_on_index
  update tabela set

  ==> é a PIOR DAS PIORES possíveis, pois vc FAZ o insert, gerando redo
  e undo, que se for duplicação VAI ser desfeito, gerando mais redo e
  tendo que ler o undo, ALTOS I/Os aí... Sem sombra de dúvida, se a sua
  versão de banco já tem e aceita, o comando SQL de MERGE seria ULTRA
  mais eficiente

  - preferencialmente faz essa carga com uma ferramenta que gere SQL e
  envie diretamente esse SQL pro banco, em PL/SQL a cada SQL enviado
  pro banco vc PAGA UM PREÇO na forma de context switch, pra uns
  poucoas registros isso não é nada, MAS pra um grande volume
  rapidamente isso se torna HORRÍVEL, SQL direto é a melhor solução :
  se a carga é de um aqruivo-texto (tipicamente é) no banco 9i em
  diante vc tem INCLUSIVE a chance de usar o arquivo-texto como se
  fosse uma tabela, com a opção de EXTERNAL TABLE, aí o MERGE seria
  ainda mais eficiente...

  e finalmente : SE realmente for (por qquer motivo) absolutamente,
  completamente, inequivocadamente impossível vc fazer em SQL apenas e
  tiver que usar PL/SQL, que AO MENOS vc use array processing e bulk
  collect, é isso.

  []s

  Chiappa

  --- Em oracle_br@yahoogrupos.com.br, "rbr72" <[EMAIL PROTECTED]> escreveu
  >
  > Pessoal, tava analisando um problema num cliente, e percebi que o
  > processo mais demorado era um insert executado várias vezes numa
  > tabela. A lógica era mais ou menos essa abaixo, se já existia um
  > dado na tabela, era feito um update de valores.
  >
  > insert into tabela values ...
  > exception when dup_val_on_index
  > update tabela set ...
  >
  > No trace gerado pelo cliente, ele tentou executar 56000 inserts,
  > foram gravados somente 56 linhas, o resto foi tudo pro update. O
  > problema que pra executar os 56000 inserts demorou 300 segundos, os
  > updates foram bem rápidos.
  >
  > Fazendo os testes, o problema era a primary key, eu desabilitei
  ela,
  > criei um indice normal, e fiz a verificacao se o registro existe,
  > faco update, senão, insert. Desse modo ficou bem rápido também.
  >
  > O que eu gostaria de saber é a explicação pra isso, sei que, com a
  > primary key, é necessário atualizar o arquivo de indice a cada
  > insert. Mas no cliente só gravou 56 inserts, então conclui que o
  > problema em alguma verificação que a primary key força o oracle a
  > fazer. Alguém sabe o que o Oracle realiza nos inserts, e o porque
  da
  > demora? Outra coisa, tem como fazer o insert ficar mais rápido ou
  > uma solução melhor do que desabilitiar a pk? Se alguém tiver idéia
  > melhor ajuda, porque vou ter que alterar um monte de procedures. :-)
  >
  > Obrigado
  >



  


[As partes desta mensagem que não continham texto foram removidas]

[oracle_br] Re: Performance em Insert

[jlchiappa]

Seguinte : sim, por DEFINIÇÃO quando vc cria um índice vc em muitos 
casos GANHA performance nas consultas, mas isso TEM A OUTRA FACE de 
implicar em diminuição de performance dos DMLs, já que a CADA DML 
feito o índice tem que ser atualizado (e índices são estruturas 
COMPLEXAS, que obrigatoriamente TEM QUE estarem fisicamente 
ordenados, é custoso atualizar índices) - isso está claramente 
exposto no manual "Oracle Concepts", que recomendo o estudo.
 Muito bem, continuando : no caso em questão vc está querendo 
introduzir um GRANDE volume de dados, PORTANTO isso é uma CARGA DE 
DADOS, uma rotina onde (claro) vc quer ter a maior performance 
possível em DMLs para que ela termine o quanto antes, pois NINGUÉM 
tem acesso aos dados antes deles carregarem... Em rotinas do tipo, 
SIM, é COMUM e RECOMENDADO vc desabilitar índices e constraints, 
justamente para EVITAR de "pagar o preço" do overhead a cada DML (ao 
final da rotina vc rebuilda os índices - em paralelo e nologging se 
possível -, desta menaira "pagando o preço" duma vez só, á vista tem 
desconto :_) , isso se deve PRINCIPALMENTE ao fato de que, SEM 
índices presentes, vc tem acesso ao modo NOLOGGING, que muitas vezes 
representa um ABSURDAMENTE ENORME ganho em performance, é técnica 
PADRÂO em bancos DW/batch, pesquise em http://asktom.oracle.com que 
vc acha diversos artigos e testes demonstrando isso.
 
==> Afora esse ponto, que vc DEVERÀ SIM implementar se minimamente 
possível, observo que  :

- a técnica de 

insert into tabela values ...
exception when dup_val_on_index
update tabela set 

==> é a PIOR DAS PIORES possíveis, pois vc FAZ o insert, gerando redo 
e undo, que se for duplicação VAI ser desfeito, gerando mais redo e 
tendo que ler o undo, ALTOS I/Os aí... Sem sombra de dúvida, se a sua 
versão de banco já tem e aceita, o comando SQL de MERGE seria ULTRA 
mais eficiente

- preferencialmente faz essa carga com uma ferramenta que gere SQL e 
envie diretamente esse SQL pro banco, em PL/SQL a cada SQL enviado 
pro banco vc PAGA UM PREÇO na forma de context switch, pra uns 
poucoas registros isso não é nada, MAS pra um grande volume 
rapidamente isso se torna HORRÍVEL, SQL direto é a melhor solução : 
se a carga é de um aqruivo-texto (tipicamente é) no banco 9i em 
diante vc tem INCLUSIVE a chance de usar o arquivo-texto como se 
fosse uma tabela, com a opção de EXTERNAL TABLE, aí o MERGE seria 
ainda mais eficiente...

e finalmente : SE realmente for (por qquer motivo) absolutamente, 
completamente, inequivocadamente impossível vc fazer em SQL apenas e 
tiver que usar PL/SQL, que AO MENOS vc use array processing e bulk 
collect, é isso.


[]s

 Chiappa
 
--- Em oracle_br@yahoogrupos.com.br, "rbr72" <[EMAIL PROTECTED]> escreveu
>
> Pessoal, tava analisando um problema num cliente, e percebi que o 
> processo mais demorado era um insert executado várias vezes numa 
> tabela. A lógica era mais ou menos essa abaixo, se já existia um 
> dado na tabela, era feito um update de valores.
> 
> insert into tabela values ...
> exception when dup_val_on_index
> update tabela set ...
> 
> No trace gerado pelo cliente, ele tentou executar 56000 inserts, 
> foram gravados somente 56 linhas, o resto foi tudo pro update. O 
> problema que pra executar os 56000 inserts demorou 300 segundos, os 
> updates foram bem rápidos.
> 
> Fazendo os testes, o problema era a primary key, eu desabilitei 
ela, 
> criei um indice normal, e fiz a verificacao se o registro existe, 
> faco update, senão, insert. Desse modo ficou bem rápido também.
> 
> O que eu gostaria de saber é a explicação pra isso, sei que, com a 
> primary key, é necessário atualizar o arquivo de indice a cada 
> insert. Mas no cliente só gravou 56 inserts, então conclui que o 
> problema em alguma verificação que a primary key força o oracle a 
> fazer. Alguém sabe o que o Oracle realiza nos inserts, e o porque 
da 
> demora? Outra coisa, tem como fazer o insert ficar mais rápido ou 
> uma solução melhor do que desabilitiar a pk? Se alguém tiver idéia 
> melhor ajuda, porque vou ter que alterar um monte de procedures. :-)
> 
> Obrigado
>

Re: [oracle_br] Re: Performance de máquina

[Rodrigo Rocha]

Valeu pelo bizú!!

Rocha






jlchiappa escreveu:

> Não dá pra adivinhar assim à distância, vc terá que monitorar pela
> v$sesstat e/ou pelas tools do SO (iirc top ou similar no aix), mas
> algumas possibilidades :
>
> >> 9.2.0.1
>
> houve LOTES e LOTES de bugs no release inicial do 9i e do 10g, e essa
> versão 9.2.0.1 indica que vc NÂO aplicou nenhum patch, acione o
> Suporte, verifique a aplicabilidade  e providencie isso pra quanto
> antes. Essa é uma grande possibilidade.
>
>
> >> .. e 4Gb de memória. ...>> Estou com 3Gb de max SGA "
>
>
> ==. stop aí colega : via de regra sempre se sugere que a SGA seja no
> máximo coisa de uns 30% ou 40% (ou em casos raros 50%) da RAM total,
> JUSTAMENTE para que SOBRE bastante RAM a ser alocada no momento da
> conexão dedicada (que vc não diz, mas IMAGINO que deve ser o caso) :
> como vc sabe, nesse caso a RAM alocada em cada conexão NÂO vem da
> SGA, e sim da RAM viva do sistema. Em sendo assim, algo está
> QUESTIONÁVEL no mínimo, 3 Gb de um total de 4 Gb dão 75% ... Será que
> de repente esse banco não está bem mal configurado que até as tarefas
> rotineiras que o banco faz (como geração de undo/rollback, controle
> de transações, de storage, etc) estão se arrastando e consumindo
> muita CPU e talvez até I/O ??
>
> []s
>
> Chiappa
> --- Em oracle_br@yahoogrupos.com.br, "rocharolr" <[EMAIL PROTECTED]>
> escreveu
> >
> > Srs,
> >
> > Estou com o banco 9.2.0.1 instalado numa máquina AIX4.3.3 com dois
> processadores de 450MHz e 4Gb de memória.
> >
> > Estou com 3Gb de max SGA e 17G de swap disponível.
> >
> > Para minha surpresa, estou com o consumo de CPU a 100% mesmo com
> poucos usuários conectados (150 inativos e 20 ativos).
> >
> > Alguém pode dar uma luz sobre o pq desse consumo de CPU?
> >
> > Grato.
> >
> > Rocha
> >
> >
> > [As partes desta mensagem que não continham texto foram removidas]
> >
>
>
>
>
>
> 
>
>
>
>No virus found in this incoming message.
>Checked by AVG Free Edition.
>Version: 7.1.405 / Virus Database: 268.11.6/428 - Release Date: 25/8/2006
>  
>



--
Atenção! As mensagens deste grupo são de acesso público e de inteira 
responsabilidade de seus remetentes.
Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ 
--__

OPORTUNIDADES DE TRABALHO, VAGAS, EMPREGOS PARA PROFISSIONAIS ORACLE VISITE: 
http://www.oraclebr.com.br/
__
Este Grupo recebe o apoio da SQL Magazine - www.devmedia.com.br/sqlmagazine  
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

 

Re: [oracle_br] Re: Performance de Query

[Marcio Portes]

Voce tentou as dicas que eu passei? Rodar a query com a subquery, a criacao
do indice e a coleta do histograma?

On 8/24/06, jorgedonato2001 <[EMAIL PROTECTED]> wrote:
>
> Valeu Chiappa, vou estudar e estar as suas sugestões.
>
> Obrigado,
> Jorge Donato
>
> --- Em oracle_br@yahoogrupos.com.br, "jlchiappa" <[EMAIL PROTECTED]> escreveu
>
> >
> > pesquisa com %nnn% o melhor que vc pode obter normalmente é um range
> > scan mesmo, não tem muito jeito , e o range vai ser BEM largo, vc TEM
> > que procurar praticamente no índice todo , já que o % inicial
> > significa qquer coisa antes do argumento... Será que REALMENTE não dá
> > pra especificar sem o % inicial ?? Se realmente tiver que, pra um
> > caso desses ou vc usa o CONTAINS num índice text, ou tem um índice de
> > função que indexa só os caras que contém a chave de pesquisa, como
> > mostrado em http://asktom.oracle.com/pls/ask/f?
> > p=4950:8:F4950_P8_DISPLAYID:37336026927381 . Uma outra opção, se
> > a pesquisa tiver que ser repetida várias vezes na mesma sessão, pode
> > ser ao invés de se ter o sub-conjunto menor dos regs que atendem à
> > chave de pesquisa indexados num índice de função, talvez possa ser te-
> > los numa GTT populada pelo programa, se o custo pra resolver
> > BOP_RG.ID_RG = BOP_RG_FONEMA.ID_RG não for tão alto...
> >
> > []s
> >
> >  Chiappa
> > --- Em oracle_br@yahoogrupos.com.br, "jorgedonato2001" <[EMAIL PROTECTED]>
> > escreveu
> > >
> > > Tenho a seguinte situacão:
> > >
> > > SQL> VARIABLE b1 number;
> > > SQL> VARIABLE b2 varchar2(85);
> > > SQL> VARIABLE b3 number;
> > > SQL> VARIABLE b4 number;
> > > SQL>
> > > SQL> EXECUTE :b1 := 9;
> > >
> > > PL/SQL procedure successfully completed.
> > >
> > > Elapsed: 00:00:00.01
> > > SQL> EXECUTE :b2 := 'MR';
> > >
> > > PL/SQL procedure successfully completed.
> > >
> > > Elapsed: 00:00:00.00
> > > SQL> EXECUTE :b3 := 999;
> > >
> > > PL/SQL procedure successfully completed.
> > >
> > > Elapsed: 00:00:00.00
> > > SQL> EXECUTE :b4 := 1;
> > >
> > > PL/SQL procedure successfully completed.
> > >
> > > Elapsed: 00:00:00.01
> > > SQL>
> > > SQL> SELECT BOP_RG_FONEMA.ID_RG,
> > >   2   BOP_RG_FONEMA.FONEMA,
> > >   3   BOP_RG.NM_NOME,
> > >   4   BOP_RG.NM_MAE,
> > >   5   BOP_RG.DT_NASCIMENTO
> > >   6  FROM BOP_RG_FONEMA,
> > >   7  BOP_RG
> > >   8WHERE BOP_RG_FONEMA.FONEMA LIKE '%'||:b2 ||'%'
> > >   9   AND BOP_RG.ID_RG = BOP_RG_FONEMA.ID_RG;
> > >
> > > 577757 rows selected.
> > >
> > > Elapsed: 00:05:19.83
> > >
> > > Execution Plan
> > > --
> > >0  SELECT STATEMENT Optimizer=CHOOSE (Cost=12848 Card=112467
> > By
> > >   tes=22718334)
> > >
> > >10   HASH JOIN (Cost=12848 Card=112467 Bytes=22718334)
> > >21 INDEX (RANGE SCAN) OF 'IDX2_BOP_RG_FONEMA' (NON-
> > UNIQUE)
> > >   (Cost=88 Card=112467 Bytes=2024406)
> > >
> > >31 INDEX (FAST FULL SCAN) OF 'IDX5_BOP_RG' (NON-UNIQUE)
> > (Co
> > >   st=6010 Card=2249333 Bytes=413877272)
> > >
> > >
> > >
> > >
> > >
> > > Statistics
> > > --
> > >   0  recursive calls
> > >   0  db block gets
> > >   72271  consistent gets
> > >   98716  physical reads
> > >   0  redo size
> > >   118090042  bytes sent via SQL*Net to client
> > >  269853  bytes received via SQL*Net from client
> > >   38519  SQL*Net roundtrips to/from client
> > >   0  sorts (memory)
> > >   0  sorts (disk)
> > >  577757  rows processed
> > >
> > >
> > > Tenho os seguintes índices
> > >
> > > CREATE INDEX EBOP.IDX5_BOP_RG ON EBOP.BOP_RG
> > > (NM_NOME, ID_RG, NM_MAE, DT_NASCIMENTO)
> > > Distinct Keys:2249329
> > >
> > > CREATE INDEX EBOP.IDX2_BOP_RG_FONEMA ON EBOP.BOP_RG_FONEMA
> > > (FONEMA, ID_RG)
> > > Distinct Keys:2249330
> > >
> > > Tabela BOP_RG:
> > > 2249333 Linhas
> > >
> > > Tabela BOP_RG_FONEMA:
> > > 2249330 Linhas
> > >
> > >
> > > O tempo esta muito alto, alguma ídeia para melhorar essa query?
> > >
> > > Att,
> > > Jorge Donato
> > >
> >
>
>
>
>
> 
>



-- 
Marcio Portes
Material Tecnico em Portugues - http://mportes.blogspot.com
Practical Learning Oracle -
http://mportes.blogspot.com/2006/02/practical-learning-oracle.html


[As partes desta mensagem que não continham texto foram removidas]



--
Atenção! As mensagens deste grupo são de acesso público e de inteira 
responsabilidade de seus remetentes.
Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ 
--__

OPORTUNIDADES DE TRABALHO, VAGAS, EMPREGOS PARA PROFISSIONAIS ORACLE VISITE: 
http://www.oraclebr.com.br/

[oracle_br] Re: Performance de Query

[jorgedonato2001]

Gabriel, 

estão sim.

Att,
Jorge Donato

--- Em oracle_br@yahoogrupos.com.br, "Teixeira, Gabriel (WMI, Brazil -
Sao Paulo)" <[EMAIL PROTECTED]> escreveu
>
> As estatísticas estão atualizadas?
> 
>   _  
> 
> From: jorgedonato2001 [mailto:[EMAIL PROTECTED] 
> Sent: quarta-feira, 23 de agosto de 2006 15:01
> To: oracle_br@yahoogrupos.com.br
> Subject: [oracle_br] Performance de Query
> 
> 
> Tenho a seguinte situacão:
> 
> SQL> VARIABLE b1 number;
> SQL> VARIABLE b2 varchar2(85);
> SQL> VARIABLE b3 number;
> SQL> VARIABLE b4 number;
> SQL> 
> SQL> EXECUTE :b1 := 9;
> 
> PL/SQL procedure successfully completed.
> 
> Elapsed: 00:00:00.01
> SQL> EXECUTE :b2 := 'MR';
> 
> PL/SQL procedure successfully completed.
> 
> Elapsed: 00:00:00.00
> SQL> EXECUTE :b3 := 999;
> 
> PL/SQL procedure successfully completed.
> 
> Elapsed: 00:00:00.00
> SQL> EXECUTE :b4 := 1;
> 
> PL/SQL procedure successfully completed.
> 
> Elapsed: 00:00:00.01
> SQL> 
> SQL> SELECT BOP_RG_FONEMA.ID_RG,
>   2   BOP_RG_FONEMA.FONEMA,
>   3   BOP_RG.NM_NOME,
>   4   BOP_RG.NM_MAE,
>   5   BOP_RG.DT_NASCIMENTO
>   6  FROM BOP_RG_FONEMA,
>   7  BOP_RG
>   8WHERE BOP_RG_FONEMA.FONEMA LIKE '%'||:b2 ||'%'
>   9   AND BOP_RG.ID_RG = BOP_RG_FONEMA.ID_RG;
> 
> 577757 rows selected.
> 
> Elapsed: 00:05:19.83
> 
> Execution Plan
> --
>0  SELECT STATEMENT Optimizer=CHOOSE (Cost=12848 Card=112467 By
>   tes=22718334)
> 
>10   HASH JOIN (Cost=12848 Card=112467 Bytes=22718334)
>21 INDEX (RANGE SCAN) OF 'IDX2_BOP_RG_FONEMA' (NON-UNIQUE)
>   (Cost=88 Card=112467 Bytes=2024406)
> 
>31 INDEX (FAST FULL SCAN) OF 'IDX5_BOP_RG' (NON-UNIQUE) (Co
>   st=6010 Card=2249333 Bytes=413877272)
> 
> 
> 
> 
> 
> Statistics
> --
>   0  recursive calls
>   0  db block gets
>   72271  consistent gets
>   98716  physical reads
>   0  redo size
>   118090042  bytes sent via SQL*Net to client
>  269853  bytes received via SQL*Net from client
>   38519  SQL*Net roundtrips to/from client
>   0  sorts (memory)
>   0  sorts (disk)
>  577757  rows processed
> 
> 
> Tenho os seguintes índices
> 
> CREATE INDEX EBOP.IDX5_BOP_RG ON EBOP.BOP_RG
> (NM_NOME, ID_RG, NM_MAE, DT_NASCIMENTO)
> Distinct Keys:2249329
> 
> CREATE INDEX EBOP.IDX2_BOP_RG_FONEMA ON EBOP.BOP_RG_FONEMA
> (FONEMA, ID_RG)
> Distinct Keys:2249330
> 
> Tabela BOP_RG:
> 2249333 Linhas
> 
> Tabela BOP_RG_FONEMA:
> 2249330 Linhas
> 
> 
> O tempo esta muito alto, alguma ídeia para melhorar essa query?
> 
> Att,
> Jorge Donato
> 
> 
> 
> 
> 
> 
>  
> 
> 
> [As partes desta mensagem que não continham texto foram removidas]
>






--
Atenção! As mensagens deste grupo são de acesso público e de inteira 
responsabilidade de seus remetentes.
Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ 
--__

OPORTUNIDADES DE TRABALHO, VAGAS, EMPREGOS PARA PROFISSIONAIS ORACLE VISITE: 
http://www.oraclebr.com.br/
__
Este Grupo recebe o apoio da SQL Magazine - www.devmedia.com.br/sqlmagazine  
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

 

[oracle_br] Re: Performance de Query

[jorgedonato2001]

Valeu Chiappa, vou estudar e estar as suas sugestões.

Obrigado,
Jorge Donato

--- Em oracle_br@yahoogrupos.com.br, "jlchiappa" <[EMAIL PROTECTED]> escreveu
>
> pesquisa com %nnn% o melhor que vc pode obter normalmente é um range 
> scan mesmo, não tem muito jeito , e o range vai ser BEM largo, vc TEM 
> que procurar praticamente no índice todo , já que o % inicial 
> significa qquer coisa antes do argumento... Será que REALMENTE não dá 
> pra especificar sem o % inicial ?? Se realmente tiver que, pra um 
> caso desses ou vc usa o CONTAINS num índice text, ou tem um índice de 
> função que indexa só os caras que contém a chave de pesquisa, como 
> mostrado em http://asktom.oracle.com/pls/ask/f?
> p=4950:8:F4950_P8_DISPLAYID:37336026927381 . Uma outra opção, se 
> a pesquisa tiver que ser repetida várias vezes na mesma sessão, pode 
> ser ao invés de se ter o sub-conjunto menor dos regs que atendem à 
> chave de pesquisa indexados num índice de função, talvez possa ser te-
> los numa GTT populada pelo programa, se o custo pra resolver 
> BOP_RG.ID_RG = BOP_RG_FONEMA.ID_RG não for tão alto...
> 
> []s
> 
>  Chiappa
> --- Em oracle_br@yahoogrupos.com.br, "jorgedonato2001" <[EMAIL PROTECTED]> 
> escreveu
> >
> > Tenho a seguinte situacão:
> > 
> > SQL> VARIABLE b1 number;
> > SQL> VARIABLE b2 varchar2(85);
> > SQL> VARIABLE b3 number;
> > SQL> VARIABLE b4 number;
> > SQL> 
> > SQL> EXECUTE :b1 := 9;
> > 
> > PL/SQL procedure successfully completed.
> > 
> > Elapsed: 00:00:00.01
> > SQL> EXECUTE :b2 := 'MR';
> > 
> > PL/SQL procedure successfully completed.
> > 
> > Elapsed: 00:00:00.00
> > SQL> EXECUTE :b3 := 999;
> > 
> > PL/SQL procedure successfully completed.
> > 
> > Elapsed: 00:00:00.00
> > SQL> EXECUTE :b4 := 1;
> > 
> > PL/SQL procedure successfully completed.
> > 
> > Elapsed: 00:00:00.01
> > SQL> 
> > SQL> SELECT BOP_RG_FONEMA.ID_RG,
> >   2   BOP_RG_FONEMA.FONEMA,
> >   3   BOP_RG.NM_NOME,
> >   4   BOP_RG.NM_MAE,
> >   5   BOP_RG.DT_NASCIMENTO
> >   6  FROM BOP_RG_FONEMA,
> >   7  BOP_RG
> >   8WHERE BOP_RG_FONEMA.FONEMA LIKE '%'||:b2 ||'%'
> >   9   AND BOP_RG.ID_RG = BOP_RG_FONEMA.ID_RG;
> > 
> > 577757 rows selected.
> > 
> > Elapsed: 00:05:19.83
> > 
> > Execution Plan
> > --
> >0  SELECT STATEMENT Optimizer=CHOOSE (Cost=12848 Card=112467 
> By
> >   tes=22718334)
> > 
> >10   HASH JOIN (Cost=12848 Card=112467 Bytes=22718334)
> >21 INDEX (RANGE SCAN) OF 'IDX2_BOP_RG_FONEMA' (NON-
> UNIQUE)
> >   (Cost=88 Card=112467 Bytes=2024406)
> > 
> >31 INDEX (FAST FULL SCAN) OF 'IDX5_BOP_RG' (NON-UNIQUE) 
> (Co
> >   st=6010 Card=2249333 Bytes=413877272)
> > 
> > 
> > 
> > 
> > 
> > Statistics
> > --
> >   0  recursive calls
> >   0  db block gets
> >   72271  consistent gets
> >   98716  physical reads
> >   0  redo size
> >   118090042  bytes sent via SQL*Net to client
> >  269853  bytes received via SQL*Net from client
> >   38519  SQL*Net roundtrips to/from client
> >   0  sorts (memory)
> >   0  sorts (disk)
> >  577757  rows processed
> > 
> > 
> > Tenho os seguintes índices
> > 
> > CREATE INDEX EBOP.IDX5_BOP_RG ON EBOP.BOP_RG
> > (NM_NOME, ID_RG, NM_MAE, DT_NASCIMENTO)
> > Distinct Keys:2249329
> > 
> > CREATE INDEX EBOP.IDX2_BOP_RG_FONEMA ON EBOP.BOP_RG_FONEMA
> > (FONEMA, ID_RG)
> > Distinct Keys:2249330
> > 
> > Tabela BOP_RG:
> > 2249333 Linhas
> > 
> > Tabela BOP_RG_FONEMA:
> > 2249330 Linhas
> > 
> > 
> > O tempo esta muito alto, alguma ídeia para melhorar essa query?
> > 
> > Att,
> > Jorge Donato
> >
>






--
Atenção! As mensagens deste grupo são de acesso público e de inteira 
responsabilidade de seus remetentes.
Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ 
--__

OPORTUNIDADES DE TRABALHO, VAGAS, EMPREGOS PARA PROFISSIONAIS ORACLE VISITE: 
http://www.oraclebr.com.br/
__
Este Grupo recebe o apoio da SQL Magazine - www.devmedia.com.br/sqlmagazine  
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

 

[oracle_br] Re: Performance de Query

[jorgedonato2001]

Marcio,

segue o Tkprof:


###

SELECT BOP_RG_FONEMA.ID_RG,
 BOP_RG_FONEMA.FONEMA,
 BOP_RG.NM_NOME,
 BOP_RG.NM_MAE,
 BOP_RG.DT_NASCIMENTO
FROM BOP_RG_FONEMA,
BOP_RG
  WHERE BOP_RG_FONEMA.FONEMA LIKE '%'||:b2 ||'%'
 AND BOP_RG.ID_RG = BOP_RG_FONEMA.ID_RG

call count   cpuelapsed   disk  querycurrent 
  rows
--- --   -- -- -- -- 
--
Parse1  0.00   0.00  0  0  0 
 0
Execute  1  0.00   0.00  0  0  0 
 0
Fetch38519 29.74 181.03 122399  72271  0 
577757
--- --   -- -- -- -- 
--
total38521 29.74 181.03 122399  72271  0 
577757

Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 5  (SYSTEM)

Rows Row Source Operation
---  ---
 577757  HASH JOIN
 577757   INDEX RANGE SCAN IDX2_BOP_RG_FONEMA (object id 48230)
2249333   INDEX FAST FULL SCAN IDX5_BOP_RG (object id 48158)


Rows Execution Plan
---  ---
  0  SELECT STATEMENT   GOAL: CHOOSE
 577757   HASH JOIN
 577757INDEX   GOAL: ANALYZED (RANGE SCAN) OF 'IDX2_BOP_RG_FONEMA'
   (NON-UNIQUE)
2249333INDEX   GOAL: ANALYZED (FAST FULL SCAN) OF 'IDX5_BOP_RG'
   (NON-UNIQUE)

##

Att,
Jorge Donato

--- Em oracle_br@yahoogrupos.com.br, "Marcio Portes"
<[EMAIL PROTECTED]> escreveu
>
> Queria ver o tkprof dessa query.
> bom, 3 sugestões.
> 
> Atualiza as estatísticas com histogramas nas colunas indexadas.
> 
> select fonema.id_rg,
>fonema.fonema,
>rg.nm_nome,
>rg.nm_mae,
>rg.dt_nascimento
>   from (
> select id_rg,
>fonema,
>   from bop_rg_fonema
>  where fonema like '%'||:b2 ||'%'
>) fonema,
>bop_rg rg
>  where rg.id_rg = fonema.id_rg
> /
> 
> e criar um índice em bop_rg(id_rg), para tentar conter o range scan de 2
> milhões de linhas na bop_rg.
> 
> 
> On 8/23/06, jorgedonato2001 <[EMAIL PROTECTED]> wrote:
> >
> > Tenho a seguinte situacão:
> >
> > SQL> VARIABLE b1 number;
> > SQL> VARIABLE b2 varchar2(85);
> > SQL> VARIABLE b3 number;
> > SQL> VARIABLE b4 number;
> > SQL>
> > SQL> EXECUTE :b1 := 9;
> >
> > PL/SQL procedure successfully completed.
> >
> > Elapsed: 00:00:00.01
> > SQL> EXECUTE :b2 := 'MR';
> >
> > PL/SQL procedure successfully completed.
> >
> > Elapsed: 00:00:00.00
> > SQL> EXECUTE :b3 := 999;
> >
> > PL/SQL procedure successfully completed.
> >
> > Elapsed: 00:00:00.00
> > SQL> EXECUTE :b4 := 1;
> >
> > PL/SQL procedure successfully completed.
> >
> > Elapsed: 00:00:00.01
> > SQL>
> > SQL> SELECT BOP_RG_FONEMA.ID_RG,
> >   2   BOP_RG_FONEMA.FONEMA,
> >   3   BOP_RG.NM_NOME,
> >   4   BOP_RG.NM_MAE,
> >   5   BOP_RG.DT_NASCIMENTO
> >   6  FROM BOP_RG_FONEMA,
> >   7  BOP_RG
> >   8WHERE BOP_RG_FONEMA.FONEMA LIKE '%'||:b2 ||'%'
> >   9   AND BOP_RG.ID_RG = BOP_RG_FONEMA.ID_RG;
> >
> > 577757 rows selected.
> >
> > Elapsed: 00:05:19.83
> >
> > Execution Plan
> > --
> >0  SELECT STATEMENT Optimizer=CHOOSE (Cost=12848 Card=112467 By
> >   tes=22718334)
> >
> >10   HASH JOIN (Cost=12848 Card=112467 Bytes=22718334)
> >21 INDEX (RANGE SCAN) OF 'IDX2_BOP_RG_FONEMA' (NON-UNIQUE)
> >   (Cost=88 Card=112467 Bytes=2024406)
> >
> >31 INDEX (FAST FULL SCAN) OF 'IDX5_BOP_RG' (NON-UNIQUE) (Co
> >   st=6010 Card=2249333 Bytes=413877272)
> >
> >
> >
> >
> >
> > Statistics
> > --
> >   0  recursive calls
> >   0  db block gets
> >   72271  consistent gets
> >   98716  physical reads
> >   0  redo size
> >   118090042  bytes sent via SQL*Net to client
> >  269853  bytes received via SQL*Net from client
> >   38519  SQL*Net roundtrips to/from client
> >   0  sorts (memory)
> >   0  sorts (disk)
> >  577757  rows processed
> >
> >
> > Tenho os seguintes índices
> >
> > CREATE INDEX EBOP.IDX5_BOP_RG ON EBOP.BOP_RG
> > (NM_NOME, ID_RG, NM_MAE, DT_NASCIMENTO)
> > Distinct Keys:2249329
> >
> > CREATE INDEX EBOP.IDX2_BOP_RG_FONEMA ON EBOP.BOP_RG_FONEMA
> > (FONEMA, ID_RG)
> > Distinct Keys:2249330
> >
> > Tabela BOP_RG:
> > 2249333 Linhas
> >
> > Tabela BOP_RG_FONEMA:
> > 2249330 Linhas
> >
> >
> > O tempo esta muito alto, alguma ídeia para melhorar essa query?
> >
> > Att,
> > Jorge Donato
> >
> >
> >
> >
> >
> >
> > 
> >
> 
> 
> 
> -- 
> Marcio Portes
> Material Tecnico em Portugues - http://mportes.blogspot.com
> Practical Learning Oracle -
> http://mportes.blogspot.com/20

[oracle_br] Re: Performance de Query

[jlchiappa]

pesquisa com %nnn% o melhor que vc pode obter normalmente é um range 
scan mesmo, não tem muito jeito , e o range vai ser BEM largo, vc TEM 
que procurar praticamente no índice todo , já que o % inicial 
significa qquer coisa antes do argumento... Será que REALMENTE não dá 
pra especificar sem o % inicial ?? Se realmente tiver que, pra um 
caso desses ou vc usa o CONTAINS num índice text, ou tem um índice de 
função que indexa só os caras que contém a chave de pesquisa, como 
mostrado em http://asktom.oracle.com/pls/ask/f?
p=4950:8:F4950_P8_DISPLAYID:37336026927381 . Uma outra opção, se 
a pesquisa tiver que ser repetida várias vezes na mesma sessão, pode 
ser ao invés de se ter o sub-conjunto menor dos regs que atendem à 
chave de pesquisa indexados num índice de função, talvez possa ser te-
los numa GTT populada pelo programa, se o custo pra resolver 
BOP_RG.ID_RG = BOP_RG_FONEMA.ID_RG não for tão alto...

[]s

 Chiappa
--- Em oracle_br@yahoogrupos.com.br, "jorgedonato2001" <[EMAIL PROTECTED]> 
escreveu
>
> Tenho a seguinte situacão:
> 
> SQL> VARIABLE b1 number;
> SQL> VARIABLE b2 varchar2(85);
> SQL> VARIABLE b3 number;
> SQL> VARIABLE b4 number;
> SQL> 
> SQL> EXECUTE :b1 := 9;
> 
> PL/SQL procedure successfully completed.
> 
> Elapsed: 00:00:00.01
> SQL> EXECUTE :b2 := 'MR';
> 
> PL/SQL procedure successfully completed.
> 
> Elapsed: 00:00:00.00
> SQL> EXECUTE :b3 := 999;
> 
> PL/SQL procedure successfully completed.
> 
> Elapsed: 00:00:00.00
> SQL> EXECUTE :b4 := 1;
> 
> PL/SQL procedure successfully completed.
> 
> Elapsed: 00:00:00.01
> SQL> 
> SQL> SELECT BOP_RG_FONEMA.ID_RG,
>   2   BOP_RG_FONEMA.FONEMA,
>   3   BOP_RG.NM_NOME,
>   4   BOP_RG.NM_MAE,
>   5   BOP_RG.DT_NASCIMENTO
>   6  FROM BOP_RG_FONEMA,
>   7  BOP_RG
>   8WHERE BOP_RG_FONEMA.FONEMA LIKE '%'||:b2 ||'%'
>   9   AND BOP_RG.ID_RG = BOP_RG_FONEMA.ID_RG;
> 
> 577757 rows selected.
> 
> Elapsed: 00:05:19.83
> 
> Execution Plan
> --
>0  SELECT STATEMENT Optimizer=CHOOSE (Cost=12848 Card=112467 
By
>   tes=22718334)
> 
>10   HASH JOIN (Cost=12848 Card=112467 Bytes=22718334)
>21 INDEX (RANGE SCAN) OF 'IDX2_BOP_RG_FONEMA' (NON-
UNIQUE)
>   (Cost=88 Card=112467 Bytes=2024406)
> 
>31 INDEX (FAST FULL SCAN) OF 'IDX5_BOP_RG' (NON-UNIQUE) 
(Co
>   st=6010 Card=2249333 Bytes=413877272)
> 
> 
> 
> 
> 
> Statistics
> --
>   0  recursive calls
>   0  db block gets
>   72271  consistent gets
>   98716  physical reads
>   0  redo size
>   118090042  bytes sent via SQL*Net to client
>  269853  bytes received via SQL*Net from client
>   38519  SQL*Net roundtrips to/from client
>   0  sorts (memory)
>   0  sorts (disk)
>  577757  rows processed
> 
> 
> Tenho os seguintes índices
> 
> CREATE INDEX EBOP.IDX5_BOP_RG ON EBOP.BOP_RG
> (NM_NOME, ID_RG, NM_MAE, DT_NASCIMENTO)
> Distinct Keys:2249329
> 
> CREATE INDEX EBOP.IDX2_BOP_RG_FONEMA ON EBOP.BOP_RG_FONEMA
> (FONEMA, ID_RG)
> Distinct Keys:2249330
> 
> Tabela BOP_RG:
> 2249333 Linhas
> 
> Tabela BOP_RG_FONEMA:
> 2249330 Linhas
> 
> 
> O tempo esta muito alto, alguma ídeia para melhorar essa query?
> 
> Att,
> Jorge Donato
>






--
Atenção! As mensagens deste grupo são de acesso público e de inteira 
responsabilidade de seus remetentes.
Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ 
--__

OPORTUNIDADES DE TRABALHO, VAGAS, EMPREGOS PARA PROFISSIONAIS ORACLE VISITE: 
http://www.oraclebr.com.br/
__
Este Grupo recebe o apoio da SQL Magazine - www.devmedia.com.br/sqlmagazine  
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

 

Re: [oracle_br] Re: Performance de máquina

[Luis Claudio Arruda Figueiredo]

Amigo chutando alto...bem alto ok?!

Serial legal vc colocar mais algumas informações na
próxima vez. Porque este problema é "meio abranjente".

Tipo ...:

1) Como anda a coleta de estatística da sua base?
2) É uma base OLTP um DW ?
3) Versao Standard ou Enterprise ?
4) Os sql's que estão rodando foram checados ?
5) Tablespaces LTM ?
6) Temporary Tablespaces com Tempfiles ?
7) Sort_area_size ou PGA ?
8) É um ambiente MTS ou Dedicado ?
9) Base esta em um Storage ?
10) Qual a config dos filesystem ?
11) Firmware esta atualizada ?
12) O Async esta habilitado ou foi feito um stripe ?
13) RAID ?
14) Um topas,svmon,iostat no seu caso ia bem.

Agora supondo que vc já verificou tudo isso e nada... 

Tive alguns problemas em um DW com unix AIX 4.2 e não
sabia mais o que alterar na parte de Database.
Resolvi ir para o S.O.

Verifique os parametros do seu S.O

/usr/sbin/vmo -a

Os parametros MINPERM%, MAXPERM% e MAXCLIENT% são
responsáveis por alguns problemas de performance em
ambientes com SGBDs, se sua configuração for default
(eu acho que 80%) ou seja ele alocaria 80% da sua
memória física para o buffer (uma espécie de SGA )
tornando redundante já que o Oracle tem sua área de
cache (SGA).

Segue um exemplo abaixo.

 # vmo -a
 memory_frames = 1572864
 pinnable_frames = 1431781
 maxfree = 1088
 minfree = 960
 minperm% = 20
 minperm = 294356
 maxperm% = 80
 maxperm = 1177427
 strict_maxperm = 0
 maxpin% = 80
 maxpin = 1258292
 maxclient% = 80
 lrubucket = 131072

Estes parametros MINPERM%, MAXPERM% e MAXCLIENT% podem
ser alterados para 20% ou 30% (alguns são dinamicos e
outros só após o boot). 
É provavel que se voce abrir um chamado na IBM por
causa do aix eles irão indicar até algumas alterações
de algoritimos de LRU que o S.O também possui.
De uma olhada no man vmo do seu s.o e encontrará
algumas infos legais e até a sintax para alterar os
parametros que desejar.
Metalink Note:282806.1
Mas seria legal vc passar esta base para 9.2.0.7 e
baixar a sua SGA para uns 2Gb pelo menos né?!
abs,

Luis Figueiredo.






--- jlchiappa <[EMAIL PROTECTED]> escreveu:

> Não dá pra adivinhar assim à distância, vc terá que
> monitorar pela 
> v$sesstat e/ou pelas tools do SO (iirc top ou
> similar no aix), mas 
> algumas possibilidades :
> 
> >> 9.2.0.1 
> 
> houve LOTES e LOTES de bugs no release inicial do 9i
> e do 10g, e essa 
> versão 9.2.0.1 indica que vc NÂO aplicou nenhum
> patch, acione o 
> Suporte, verifique a aplicabilidade  e providencie
> isso pra quanto 
> antes. Essa é uma grande possibilidade.
> 
> 
> >> .. e 4Gb de memória. ...>> Estou com 3Gb de max
> SGA "
> 
> 
> ==. stop aí colega : via de regra sempre se sugere
> que a SGA seja no 
> máximo coisa de uns 30% ou 40% (ou em casos raros
> 50%) da RAM total, 
> JUSTAMENTE para que SOBRE bastante RAM a ser alocada
> no momento da 
> conexão dedicada (que vc não diz, mas IMAGINO que
> deve ser o caso) : 
> como vc sabe, nesse caso a RAM alocada em cada
> conexão NÂO vem da 
> SGA, e sim da RAM viva do sistema. Em sendo assim,
> algo está 
> QUESTIONÁVEL no mínimo, 3 Gb de um total de 4 Gb dão
> 75% ... Será que 
> de repente esse banco não está bem mal configurado
> que até as tarefas 
> rotineiras que o banco faz (como geração de
> undo/rollback, controle 
> de transações, de storage, etc) estão se arrastando
> e consumindo 
> muita CPU e talvez até I/O ??
> 
> []s
> 
>  Chiappa
> --- Em oracle_br@yahoogrupos.com.br, "rocharolr"
> <[EMAIL PROTECTED]> 
> escreveu
> >
> > Srs,
> > 
> > Estou com o banco 9.2.0.1 instalado numa máquina
> AIX4.3.3 com dois 
> processadores de 450MHz e 4Gb de memória.
> > 
> > Estou com 3Gb de max SGA e 17G de swap disponível.
> > 
> > Para minha surpresa, estou com o consumo de CPU a
> 100% mesmo com 
> poucos usuários conectados (150 inativos e 20
> ativos).
> > 
> > Alguém pode dar uma luz sobre o pq desse consumo
> de CPU?
> > 
> > Grato.
> > 
> > Rocha
> > 
> > 
> > [As partes desta mensagem que não continham texto
> foram removidas]
> >
> 
> 
> 
> 
> 
> 




___ 
Novidade no Yahoo! Mail: receba alertas de novas mensagens no seu celular. 
Registre seu aparelho agora! 
http://br.mobile.yahoo.com/mailalertas/ 
 



--
Atenção! As mensagens deste grupo são de acesso público e de inteira 
responsabilidade de seus remetentes.
Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ 
--__

OPORTUNIDADES DE TRABALHO, VAGAS, EMPREGOS PARA PROFISSIONAIS ORACLE VISITE: 
http://www.oraclebr.com.br/
__
Este Grupo recebe o apoio da SQL Magazine - www.devmedia.com.br/sqlmagazine  
Links do Yahoo! Grupos

<*>

[oracle_br] Re: Performance de máquina

[jlchiappa]

Não dá pra adivinhar assim à distância, vc terá que monitorar pela 
v$sesstat e/ou pelas tools do SO (iirc top ou similar no aix), mas 
algumas possibilidades :

>> 9.2.0.1 

houve LOTES e LOTES de bugs no release inicial do 9i e do 10g, e essa 
versão 9.2.0.1 indica que vc NÂO aplicou nenhum patch, acione o 
Suporte, verifique a aplicabilidade  e providencie isso pra quanto 
antes. Essa é uma grande possibilidade.


>> .. e 4Gb de memória. ...>> Estou com 3Gb de max SGA "


==. stop aí colega : via de regra sempre se sugere que a SGA seja no 
máximo coisa de uns 30% ou 40% (ou em casos raros 50%) da RAM total, 
JUSTAMENTE para que SOBRE bastante RAM a ser alocada no momento da 
conexão dedicada (que vc não diz, mas IMAGINO que deve ser o caso) : 
como vc sabe, nesse caso a RAM alocada em cada conexão NÂO vem da 
SGA, e sim da RAM viva do sistema. Em sendo assim, algo está 
QUESTIONÁVEL no mínimo, 3 Gb de um total de 4 Gb dão 75% ... Será que 
de repente esse banco não está bem mal configurado que até as tarefas 
rotineiras que o banco faz (como geração de undo/rollback, controle 
de transações, de storage, etc) estão se arrastando e consumindo 
muita CPU e talvez até I/O ??

[]s

 Chiappa
--- Em oracle_br@yahoogrupos.com.br, "rocharolr" <[EMAIL PROTECTED]> 
escreveu
>
> Srs,
> 
> Estou com o banco 9.2.0.1 instalado numa máquina AIX4.3.3 com dois 
processadores de 450MHz e 4Gb de memória.
> 
> Estou com 3Gb de max SGA e 17G de swap disponível.
> 
> Para minha surpresa, estou com o consumo de CPU a 100% mesmo com 
poucos usuários conectados (150 inativos e 20 ativos).
> 
> Alguém pode dar uma luz sobre o pq desse consumo de CPU?
> 
> Grato.
> 
> Rocha
> 
> 
> [As partes desta mensagem que não continham texto foram removidas]
>







--
Atenção! As mensagens deste grupo são de acesso público e de inteira 
responsabilidade de seus remetentes.
Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ 
--__

OPORTUNIDADES DE TRABALHO, VAGAS, EMPREGOS PARA PROFISSIONAIS ORACLE VISITE: 
http://www.oraclebr.com.br/
__
Este Grupo recebe o apoio da SQL Magazine - www.devmedia.com.br/sqlmagazine  
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

 

[oracle_br] Re: performance pks com tamanhos diferentes

[jlchiappa]

Se for *** MESMO *** , realmente, o mesmo datatype, só diferenciando 
em tamanho (por exemplo, um é varchar2(40) e outro é VARCHAR2(80), 
digamos), em princípio vc não deverá ter conversão implícita, que é o 
que pode dar alteração de performance, então afaik de performance 
propriamente dita vc não deverá ter probs.

[]s

 Chiappa
 
--- Em oracle_br@yahoogrupos.com.br, "Marcelo Cauduro" 
<[EMAIL PROTECTED]> escreveu
>
> Pessoal, Uma dúvida :
> 
> Se eu tiver FK's com o mesmo tipo de dados... mas com o tamanho 
diferente...
> isso pode me gerar problema d performance?
> OBS --> eh logico q isso eh uma pessima modelagem... mas levando em
> consideracao apenas questoes performaticas
> 
> Obrigado.
> 
> 
> [As partes desta mensagem que não continham texto foram removidas]
>











--
Atenção! As mensagens deste grupo são de acesso público e de inteira responsabilidade de seus remetentes.
Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ 
--__

Este Grupo recebe o apoio da SQL Magazine - www.devmedia.com.br/sqlmagazine 
__
O grupo Oracle_br não aceita anexos. Quando oferecer algum arquivo, tenha o link do mesmo para evitar trafego(pedidos) desnecessário.





  




  
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 Termos do Serviço do Yahoo!.

[oracle_br] Re: Performance Horrivel

[Jemerson Dutra]

Phael e Sharif, tentei o comando abaixo e so funcionou quando 
coloquei o parametro de maxclients. 
Segue o comando abaixo
- vmtune -p15 -P30 -t30

Minha maquina melhorou bastante a performance. 
Ja nao esta mais tento pontos de travamento. 
Estarei fazendo as alterações que o Chiappa me comentou para que eu 
consiga o maximo de performance.
Obrigado

como parametro tinha um processo que rodava em 4 horas estou rodando 
em 50minutos sem que outros usuarios sintam o processamento.

--- Em oracle_br@yahoogrupos.com.br, "Phael" <[EMAIL PROTECTED]> escreveu
>
> Jemerson,
> Voce colocou no /etc/inittab
> 
> vmtune:2:once:/usr/samples/kernel/vmtune -p5 -P10 -r8 -R16 -f128 -
F144
> 
> essa linha... note q a primeira vez q passei o caminho estava 
errado.
> 
> ... estranho era para dar certo!
> 
> 
> tente mudar ele dinamicamente.
> 
> # cd /usr/samples/kernel
> # vmtune -p5 -P10
> 
> atc.
> 
> Raphael
> 
> 
> - Original Message - 
> From: "Jemerson Dutra" <[EMAIL PROTECTED]>
> To: 
> Sent: Tuesday, April 11, 2006 1:51 PM
> Subject: [oracle_br] Re: Performance Horrivel
> 
> 
> Phael, fiz as alterações que vc disse mas segundo os exemplos do
> SHARIF o AIX nao pegou a configuracao, ele continua com os 
parametros
> defaults.
> 
> # vmo -a
> memory_frames = 1572864
>   pinnable_frames = 1432380
>   maxfree = 144
>   minfree = 128
>  minperm% = 20 <---
>   minperm = 290532
>  maxperm% = 80 <---
>   maxperm = 1162131
>strict_maxperm = 0
>   maxpin% = 80
>maxpin = 1258292
>maxclient% = 80 <---
> lrubucket = 131072
> 
> 
> --- Em oracle_br@yahoogrupos.com.br, "Sharif G Raduan"
> <[EMAIL PROTECTED]> escreveu
> >
> > no metalink vc pode encontrar notas de tunning no AIX, mas o
> minperm /
> > maxparm é a quantidade de memória para cache de file systens,
> quando vc está
> > utilizando oracle não precisa dessas quantidades grandes que são
> default.
> >
> >   Subject:  AIX: Database performance gets slower the longer
> the
> > database is running
> > Doc ID:  Note:316533.1 Type:  PROBLEM
> > Last Revision Date:  24-MAR-2006 Status:  PUBLISHED
> >
> > In this Document
> >   Symptoms
> >   Cause
> >   Solution
> >   References
> >
> >
> >
> > --
--
> 
> >
> >
> >
> > Applies to:
> > Oracle Server - Enterprise Edition - Version:
> > AIX5L Based Systems (64-bit)
> > AIX Based Systems (32-bit)
> > Bull Escala RL AIX (64-bit)
> > AIX 4.3 Based Systems (64-bit)
> > Oracle databases running on AIX based systems.
> > Symptoms
> > Database performance continues to get slower and slower the longer
> the
> > database is left running.  You may also notice a continuing
> increase in the
> > amount of paging space usage the longer the database is left
> running.
> > However, database performance returns to normal after rebooting 
the
> system,
> > or shutting down and restarting the database.
> > Cause
> > It is likely that you have not tuned the AIX Virtual Memory 
Manager
> (VMM).
> > The default values for the AIX VMM are generally not appropriate
> for use
> > with relational databases.  The default values for the AIX VMM 
will
> > gradually allow up to 80% of physical memory to be used to buffer
> file I/O.
> > Since Oracle is already buffering file I/O in the SGA, the same
> data is
> > unnecessarily being buffered twice, and leaves only 20% of 
physical
> memory
> > to run the Oracle database(s) and all other programs.  This causes
> the
> > majority of the Oracle database to be pushed out of physical 
memory
> to
> > paging space, thus greatly impacting database performance.
> >
> > The information in this article does not apply, or the impact will
> be much
> > less, if you are using one or more of the following storage types
> for the
> > database datafiles, because AIX does not buffer file I/O for these
> types:
> >
> > Raw logical volumes, filesystems using the Concurrent I/O (CIO)
> option,
> > filesystems using the Direct I/O (DIO) option
> >
> > Note that there is no "built-in" support for CIO or DIO in Oracle
> Database
> > 9iR2 (9.2.0) or lower, though you can force the use of CIO (JFS2)
> or DIO
> > (JFS) with filesystem mount 

[oracle_br] Re: Performance Horrivel

[jlchiappa]

Seguem alguns coments e adendos :

--- Em oracle_br@yahoogrupos.com.br, "Jemerson Dutra" <[EMAIL PROTECTED]> 
escreveu
> 
> 5 DISCOS 
> SCSI 1OK RPM

ok, 10k RPMs é o padrãozão em hds SCSI, normal . Só tinha perguntado 
porque já vi uns hds com menos (7500, tipicamente) serem oferecidos, 
e não era disco refurbished, era novo mesmo! Blz.

> Independentes

Como eu disse, talvez um array ajudasse, mas já que é uma opção cara 
e que implica em re-feitura de ambiente, em princípio vamos deixá-la 
pra uma próxima, se mais nada ajudar.

> 1 controladora SCSI

Esse ponto pode pegar, por melhor que seja a controladora, não é 
certo que ela consiga atender  simultaneamente e eficientemente os 
vários "pedidos" dos vários discos, que provavelmente devem ser 
simultâneos ou quase. Bem, os testes que vc vai fazer vão dar dicas a 
respeito, se o select em tabelas independentes do sistema demorar 
demais, a gente pensa mesmo é em subsistema de I/O afogado, de 
repente os discos ficm "esperando" disponibilidade da controladora, 
mas antes de palpitar vamos ver no que resultam os testes...
 Já que vc vai fazer mesmo, seria legal vc fazer uma vez com o banco 
startado mas sem sistema rodando, uma vez com o sistema ativo mas com 
poucos (ou nenhum) usuários conectados, e finalmente uma outra vez em 
uso normal. Lembre também que o que nos interessa aqui é 
tentar "validar" a hipótese de hardware de I/O com probs (talvez de 
dimensionamento), então a idéia é tentar minimizar a influência de 
outras fatores, como caches e rede, assim o teste deveria ser 
executado DIRETAMENTE no sqlplus do servidor Oracle, conectando como 
sqlplus userdonodastabelas/senha (sem o @string, queremos conexão 
local), , peça um SET TIME ON TIMING ON no sqlplus, e antes de cada 
execução manda um ALTER TABLESPACE nomedatablespaceondeestãoastabs  
OFFLINE e um ALTER TABLESPACE nomedatablespaceondeestãoastabs  
ONLINE , pra  que seja feito basicamente só PIO (não estamos  zerando 
utilização de caches, óbvio, já que forçosamente cada bloco após lido 
por um SELECT ** tem que ** ir pro cache e cada bloco tem n 
registros), mas estamos diminuindo a "participação" do cache nesse 
timing.
 
> 
> MULTIBLOCK_READ ??? (chiappa, novamente onde vejo exatamente qual o 
> maximo permitido pelo meu servidor?)

Existem outras maneiras, mas como normalmente isso é uma quantidade 
de blocos que totaliza 1Mb, ou coisa do tipo, pra vc saber é testar, 
vc cria uma tablespace LMT uniform size de 10Mb, cria nela uma tabela 
qquer com PCTFREE 1 PCTUSED 99 e com várias centenas de milhares de 
linhas, e faz um trace 10046 level 12 de uma sessão fazendo 
SELECT /*+ FULL */ * from nomedatabela, isso resulta num 
arquivo .TRC  que entre muitas outras vai ter linhas do tipo :

WAIT #3: nam='db file scattered read' ela= 249287 p1=41 p2=4234 p3=nnn

nnn é a quantidade de blocos que ele pôde ler duma vez, 
db_file_multiblock_read_count deve ter o maior dos nnn que vc achar 
no arquivo.

> 
> 
> TABLESPACE LMT system-allocated

Imagino que sejam TODAS as tablespaces (dados, índices, etc) lmt 
system-alloc, certo ? ok, isso já elimina de cara a chance de 
fragmentação , então . Para explicar uma eventual ineficiência em I/O 
resta a possibilidade de high-water  muito alto, ou PCTFREE/PCTUSED 
incorretos, mas vamos por partes , vamos ver os testes antes de 
avançar por aí.

> 
> LOGS:
> 6 REDOLOGS DE 50MB NESSE DISCO 5 (O MAIS ACESSADO)

essa info é importante, os log files estão no disco que está sendo 
mais acessado, hmmm. Será que não são eles que estão causando esse 
acesso todo ? Além do log_checkpoint_interval (que iirc vc já disse 
que estava com 1, e eu sugeri aumentar isso), como estão os 
demais (ie, log_checkpoints_to_alert e log_checkpoint_timeout) ?? 
Será que está havendo troca de log files constantemente ? Normalmente 
isso fica registrado no alert_nn.log do servidor, veja lá...
 A idéia normalmente é vc ter um arquivo de log bem grande (se hoje 
vc está com 50 Mb, tente recriá-los com 200 Mb), e ter um 
log_checkpoint_interval muito grande e log_checkpoint_timeout como 
zero, para tentar influenciar a qtdade de redo, o manual "Oracle9i 
Database Performance Tuning Guide and Reference" no cap. 17 - 
Configuring Instance Recovery Performance no link "Reducing 
Checkpoint Frequency to Optimize Runtime Performance"  fala um pouco 
disso...


> 
> TEMP:
> 2 DATAFILES DE 500MB NESSE DISCO 5 ( O MAIS ACESSADO)

datafiles ou tempfiles ? DEVERIA ser tempfiles, deveria ser 
tablespace lmt (suponho que seja), e tira isso desse disco mais 
acessado, bota num outro menos, talvez no que tem o SO...

> 
> select * from v$sga;
> NAME  VALUE
>  --
> Fixed Size   741816
> Variable Size 536870912
> Database Buffers   50331648
> Redo Buffers2191360

Como tinha dito em outra msg, sobe aí o block buffer pra coisa da 
centena de Mbs. 
> 
> vou colar mais tarde o resultado do teste das tabelas.
> 
>

Re: [oracle_br] Re: Performance Horrivel

[Sharif G Raduan]

Nesse artigo vc tem exemplos de como mudar os valores

http://www.dbis.informatik.uni-goettingen.de/Teaching/oracle-doc/admin-guide/appa_aix.htm

[]´s

Sharif

- Original Message - 
From: "Jemerson Dutra" <[EMAIL PROTECTED]>
To: 
Sent: Tuesday, April 11, 2006 1:51 PM
Subject: [oracle_br] Re: Performance Horrivel


Phael, fiz as alterações que vc disse mas segundo os exemplos do
SHARIF o AIX nao pegou a configuracao, ele continua com os parametros
defaults.

# vmo -a
memory_frames = 1572864
  pinnable_frames = 1432380
  maxfree = 144
  minfree = 128
 minperm% = 20 <---
  minperm = 290532
 maxperm% = 80 <---
  maxperm = 1162131
   strict_maxperm = 0
  maxpin% = 80
   maxpin = 1258292
   maxclient% = 80 <---
lrubucket = 131072


--- Em oracle_br@yahoogrupos.com.br, "Sharif G Raduan"
<[EMAIL PROTECTED]> escreveu
>
> no metalink vc pode encontrar notas de tunning no AIX, mas o
minperm /
> maxparm é a quantidade de memória para cache de file systens,
quando vc está
> utilizando oracle não precisa dessas quantidades grandes que são
default.
>
>   Subject:  AIX: Database performance gets slower the longer
the
> database is running
> Doc ID:  Note:316533.1 Type:  PROBLEM
> Last Revision Date:  24-MAR-2006 Status:  PUBLISHED
>
> In this Document
>   Symptoms
>   Cause
>   Solution
>   References
>
>
>
> 

>
>
>
> Applies to:
> Oracle Server - Enterprise Edition - Version:
> AIX5L Based Systems (64-bit)
> AIX Based Systems (32-bit)
> Bull Escala RL AIX (64-bit)
> AIX 4.3 Based Systems (64-bit)
> Oracle databases running on AIX based systems.
> Symptoms
> Database performance continues to get slower and slower the longer
the
> database is left running.  You may also notice a continuing
increase in the
> amount of paging space usage the longer the database is left
running.
> However, database performance returns to normal after rebooting the
system,
> or shutting down and restarting the database.
> Cause
> It is likely that you have not tuned the AIX Virtual Memory Manager
(VMM).
> The default values for the AIX VMM are generally not appropriate
for use
> with relational databases.  The default values for the AIX VMM will
> gradually allow up to 80% of physical memory to be used to buffer
file I/O.
> Since Oracle is already buffering file I/O in the SGA, the same
data is
> unnecessarily being buffered twice, and leaves only 20% of physical
memory
> to run the Oracle database(s) and all other programs.  This causes
the
> majority of the Oracle database to be pushed out of physical memory
to
> paging space, thus greatly impacting database performance.
>
> The information in this article does not apply, or the impact will
be much
> less, if you are using one or more of the following storage types
for the
> database datafiles, because AIX does not buffer file I/O for these
types:
>
> Raw logical volumes, filesystems using the Concurrent I/O (CIO)
option,
> filesystems using the Direct I/O (DIO) option
>
> Note that there is no "built-in" support for CIO or DIO in Oracle
Database
> 9iR2 (9.2.0) or lower, though you can force the use of CIO (JFS2)
or DIO
> (JFS) with filesystem mount options.
>
> Also note that tuning the AIX VMM is outside the scope of Oracle
Support.
> If you need help with checking, setting, or tuning the AIX VMM
beyond what
> is covered in this article, you must contact your AIX systems
administrator
> and/or IBM Support for further assistance.
>
> Solution
> To check whether your system is using the untuned default values
for the AIX
> VMM, run the command:
>
> /usr/sbin/vmo -a
>
> If you do not have the /usr/sbin/vmo file you will need to have
your AIX
> systems administrator load the AIX fileset "bos.perf.tune".  The
vmo command
> will list out all of the VMM parameters and their current values.
The
> parameters you want to examine are:
>
> MINPERM%, MAXPERM%, and MAXCLIENT%
>
> Here is an example of the vmo report:
>
> # vmo -a
> memory_frames = 1572864
> pinnable_frames = 1431781
> maxfree = 1088
> minfree = 960
> minperm% = 20
> minperm = 294356
> maxperm% = 80
> maxperm = 1177427
> strict_maxperm = 0
> maxpin% = 80
> maxpin = 1258292
> maxclient% = 80
> lrubucket = 131072
> .
> The untuned default settings are MINPERM%=20%, MAXPERM%=80%, and
> MAXCLIENT%=80%.  There is no "correct" value for these parameters
and only
> extensive testing will reveal the optimal values.  T

Re: [oracle_br] Re: Performance Horrivel

[Phael]

Jemerson,
Voce colocou no /etc/inittab

vmtune:2:once:/usr/samples/kernel/vmtune -p5 -P10 -r8 -R16 -f128 -F144

essa linha... note q a primeira vez q passei o caminho estava errado.

... estranho era para dar certo!


tente mudar ele dinamicamente.

# cd /usr/samples/kernel
# vmtune -p5 -P10

atc.

Raphael


- Original Message - 
From: "Jemerson Dutra" <[EMAIL PROTECTED]>
To: 
Sent: Tuesday, April 11, 2006 1:51 PM
Subject: [oracle_br] Re: Performance Horrivel


Phael, fiz as alterações que vc disse mas segundo os exemplos do
SHARIF o AIX nao pegou a configuracao, ele continua com os parametros
defaults.

# vmo -a
memory_frames = 1572864
  pinnable_frames = 1432380
  maxfree = 144
  minfree = 128
 minperm% = 20 <---
  minperm = 290532
 maxperm% = 80 <---
  maxperm = 1162131
   strict_maxperm = 0
  maxpin% = 80
   maxpin = 1258292
   maxclient% = 80 <---
lrubucket = 131072


--- Em oracle_br@yahoogrupos.com.br, "Sharif G Raduan"
<[EMAIL PROTECTED]> escreveu
>
> no metalink vc pode encontrar notas de tunning no AIX, mas o
minperm /
> maxparm é a quantidade de memória para cache de file systens,
quando vc está
> utilizando oracle não precisa dessas quantidades grandes que são
default.
>
>   Subject:  AIX: Database performance gets slower the longer
the
> database is running
> Doc ID:  Note:316533.1 Type:  PROBLEM
> Last Revision Date:  24-MAR-2006 Status:  PUBLISHED
>
> In this Document
>   Symptoms
>   Cause
>   Solution
>   References
>
>
>
> 

>
>
>
> Applies to:
> Oracle Server - Enterprise Edition - Version:
> AIX5L Based Systems (64-bit)
> AIX Based Systems (32-bit)
> Bull Escala RL AIX (64-bit)
> AIX 4.3 Based Systems (64-bit)
> Oracle databases running on AIX based systems.
> Symptoms
> Database performance continues to get slower and slower the longer
the
> database is left running.  You may also notice a continuing
increase in the
> amount of paging space usage the longer the database is left
running.
> However, database performance returns to normal after rebooting the
system,
> or shutting down and restarting the database.
> Cause
> It is likely that you have not tuned the AIX Virtual Memory Manager
(VMM).
> The default values for the AIX VMM are generally not appropriate
for use
> with relational databases.  The default values for the AIX VMM will
> gradually allow up to 80% of physical memory to be used to buffer
file I/O.
> Since Oracle is already buffering file I/O in the SGA, the same
data is
> unnecessarily being buffered twice, and leaves only 20% of physical
memory
> to run the Oracle database(s) and all other programs.  This causes
the
> majority of the Oracle database to be pushed out of physical memory
to
> paging space, thus greatly impacting database performance.
>
> The information in this article does not apply, or the impact will
be much
> less, if you are using one or more of the following storage types
for the
> database datafiles, because AIX does not buffer file I/O for these
types:
>
> Raw logical volumes, filesystems using the Concurrent I/O (CIO)
option,
> filesystems using the Direct I/O (DIO) option
>
> Note that there is no "built-in" support for CIO or DIO in Oracle
Database
> 9iR2 (9.2.0) or lower, though you can force the use of CIO (JFS2)
or DIO
> (JFS) with filesystem mount options.
>
> Also note that tuning the AIX VMM is outside the scope of Oracle
Support.
> If you need help with checking, setting, or tuning the AIX VMM
beyond what
> is covered in this article, you must contact your AIX systems
administrator
> and/or IBM Support for further assistance.
>
> Solution
> To check whether your system is using the untuned default values
for the AIX
> VMM, run the command:
>
> /usr/sbin/vmo -a
>
> If you do not have the /usr/sbin/vmo file you will need to have
your AIX
> systems administrator load the AIX fileset "bos.perf.tune".  The
vmo command
> will list out all of the VMM parameters and their current values.
The
> parameters you want to examine are:
>
> MINPERM%, MAXPERM%, and MAXCLIENT%
>
> Here is an example of the vmo report:
>
> # vmo -a
> memory_frames = 1572864
> pinnable_frames = 1431781
> maxfree = 1088
> minfree = 960
> minperm% = 20
> minperm = 294356
> maxperm% = 80
> maxperm = 1177427
> strict_maxperm = 0
> maxpin% = 80
> maxpin = 1258292
> maxclient% = 80
> lrubucket = 131072
> .
> The untuned default settings are MINPERM%=20%, MAXPERM%=80%, and
&

[oracle_br] Re: Performance Horrivel

[Jemerson Dutra]

 
> e 
> > > uma 
> > > > tabela "grande", faz alguns SQLs diretamente em cima delas, 
se 
> > nem 
> > > > isso ir bem a gente suspeita de configs de So e banco e de 
> > hardware 
> > > > sub-dimensionado...
> > > > 
> > > > []s
> > > > 
> > > >   Chiappa
> > > > 
> > > > --- Em oracle_br@yahoogrupos.com.br, "Jemerson Dutra" 
> > > <[EMAIL PROTECTED]> 
> > > > escreveu
> > > > >
> > > > > Meu banco de dados continua horrivel, melhorou cerca de uns 
> > 10%. 
> > > > > porem acho que nao esta como eu gostaria.
> > > > > 
> > > > > --- Em oracle_br@yahoogrupos.com.br, "jkdutra" 
<[EMAIL PROTECTED]> 
> > > > > escreveu
> > > > > >
> > > > > > Srs Meu banco é 9i creio que o awrrpt.sql é somente do 
10g 
> ne?
> > > > > > Chiappa, O pessoal do E.R.P tinha um init.ora basico e eu 
> > > acabei 
> > > > > > fazendo algumas poucas alteracoes, porem minha 
experiencia 
> 7 
> > > anos 
> > > > > é 
> > > > > > toda no 8i. e lendo algumas coisas acabei alterando 
alguns 
> > > > > > parametros, tenho autonomia para alterar o que quiser 
desde 
> > que 
> > > > > nao 
> > > > > > altere as tabelas.
> > > > > > Vou estar respondendo os senhores amanha da empresa com 
> calma 
> > > > > desde 
> > > > > > ja agradeco a colaboração e espero poder contar com os 
> > > senhores. 
> > > > > > Chiappa, Sergio e Raphael Abraços.
> > > > > > 
> > > > > > --- Em oracle_br@yahoogrupos.com.br, Sergio Leandro 
> Ghellere 
> > > > > > <[EMAIL PROTECTED]> escreveu
> > > > > > >
> > > > > > > Ola Jemerson,
> > > > > > > 
> > > > > > >é difícil achar encontrar um problema assim...
> > > > > > >só pra termos uma idéia, cola o resultado do AWR...
> > > > > > >executa no sqlplus.
> > > > > > >@$ORACLE_HOME/rdbms/admin/awrrpt.sql
> > > > > > > 
> > > > > > > pega aí um intervalo de algumas horas... normalmente o 
> AWR 
> > > > colhe 
> > > > > > estatísticas a cada 
> > > > > > > 60min..
> > > > > > > 
> > > > > > >cola as primeiras 100 linhas só pra termos uma idéia.
> > > > > > > 
> > > > > > > 
> > > > > > > Grande abraço.
> > > > > > > 
> > > > > > > 
> > > > > > > Sergio Leandro Ghellere
> > > > > > > DBA Oracle
> > > > > > > +55 (41) 9906-4813
> > > > > > > 
> > > > > > > On Thu Apr  6 15:19 , 'Phael' <[EMAIL PROTECTED]> sent:
> > > > > > > 
> > > > > > > >Ola Jemerson,
> > > > > > > >
> > > > > > > >Ja tive problemas com performance com AIX.
> > > > > > > >No meu caso o problema era com um parametro do SO.
> > > > > > > >Distrubuição da memória cache.
> > > > > > > >
> > > > > > > >executa esse arquivo ai:
> > > > > > > >
> > > > > > > ># /usjr/samples/kernel/vmtune
> > > > > > > >
> > > > > > > >colo o resultado ai.
> > > > > > > >
> > > > > > > >Raphael
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >- Original Message - 
> > > > > > > >From: "Jemerson Dutra" [EMAIL PROTECTED]>
> > > > > > > >To: oracle_br@yahoogrupos.com.br>
> > > > > > > >Sent: Thursday, April 06, 2006 2:35 PM
> > > > > > > >Subject: [oracle_br] Re: Performance Horrivel
> > > > > > > >
> > > > > > > >
> > > > > > > >Ae chiappa, da uma ajuda ai.
> > > > > > > >Jemerson
> > > > > > > >--- Em oracle_br@yahoogrupos.com.br, "Jemerson Dutra" 
> &g

[oracle_br] Re: Performance Horrivel

[Jemerson Dutra]

alues which work best for all of 
the 
> databases you will be running on the system.  Use the following 
values as a 
> starting point:
> 
> MINPERM% = 10-15%, MAXPERM% = 20-30%, MAXCLIENT% = MAXPERM%
> 
> To get a snapshot of how much physical memory is being used by AIX 
to buffer 
> file I/O, run the command:
> 
> /usr/bin/svmon -G
> 
> The svmon command is part of the same AIX fileset "bos.perf.tune" 
that vmo 
> belongs to.  The last line of the svmon output should be "in use".  
Add the 
> values for "in use / pers" and "in use / clnt".  Now divide the sum 
by the 
> value for "memory / size".  For best database performance, this 
value should 
> generally not be higher than 30% (0.30).
> 
> Here is an example of the svmon output:
> 
> # svmon -G
> 
>  size   inuse freepin 
virtual
> memory  131072   129432   1640   11704   50091
> pg space 262144   100913
> 
> work   pers  clnt  lpage
> pin  11704   0 0 0
> in use  47062   76126   6244 0
> 
> In this example, (in use / pers) 76126 plus (in use / clnt) 6244 
equals 
> 82370.  82370 divided by (memory / size) 131072 equals 0.628 or 
> approximately 63% of physical memory being used by AIX to buffer 
file I/O. 
> This indicates the AIX VMM needs to be tuned to allow more physical 
memory 
> to be used by Oracle and other processes, and less physical memory 
to be 
> used to buffer file I/O.
> 
> Remember that although AIX associates this memory with the Oracle 
processes 
> (because Oracle requested the file I/O), all of the memory used to 
buffer 
> file I/O is completely allocated and controlled by AIX, not 
Oracle.  If you 
> need help checking, setting, or tuning the AIX VMM, contact your 
AIX systems 
> administrator and/or IBM Support.  You may also want to review the 
AIX 
> "Performance Management Guide" by IBM linked in the References 
section 
> below.
> 
> UPDATE: After this article was originally written, IBM has 
introduced a new 
> VMM parameter which is also very helpful with this issue. The 
parameter 
> is...
> 
> 
> lru_file_repage
> The default value is "1", but it is recommended to set this to "0". 
This 
> setting hints to the VMM to only steal file pages (from the AIX 
file buffer 
> cache) and leave the computational pages (from the SGA) alone.
> 
> This new lru_file_repage parameter is only available on AIX 5.2 
ML04+ and 
> AIX 5.3 ML01+
> 
> 
> 
> 
> []´s
> 
> Sharif
> 
> - Original Message - 
> From: "Phael" <[EMAIL PROTECTED]>
> To: 
> Sent: Monday, April 10, 2006 11:10 AM
> Subject: Re: [oracle_br] Re: Performance Horrivel
> 
> 
> > Jemerson,
> >
> > Também não sou nenhum especialista em AIX.
> > Na verdade quando tive problemas de performance no AIX
> > fiz varios tunings na base e se esgotaram as
> > tentativas de melhoras, tendo pouco sucesso. Chamei um
> > tecnico para otimizar o AIX e ele me disse que esse parametro
> > controla a distribuição da memória Cache da máquina sendo que
> > por default ele libera 80% do recurso para o SO e 20% para
> > demais softwares... vai entende isso???...se estiver falando 
besteira
> > alguem me corrija por facor.enfim  mudei esse parametro!!!
> > Como estavam tendo bastante paginação e swap a mudança
> > dessa configuração pra 10% e 5% foi otima acabando com
> > os problemas de paginações e swap.
> > Esse procedimento foi feito em um AIX 4.3.3 mas acho que
> > serve para o AIX 5.2.
> > Não custa tentar, caso não der certo é só remover a linha e
> > entrar em contato com algum especialista em AIX para
> > entender melhor esses reajuste.
> >
> > atc
> >
> > Raphael
> >
> >
> > - Original Message - 
> > From: "Jemerson Dutra" <[EMAIL PROTECTED]>
> > To: 
> > Sent: Monday, April 10, 2006 10:45 AM
> > Subject: [oracle_br] Re: Performance Horrivel
> >
> >
> > Raphael, desculpe minha ignorancia mas o que esses parametros
> > controlam? e o que eles farao??
> > Jemerson
> >
> > --- Em oracle_br@yahoogrupos.com.br, "Phael" <[EMAIL PROTECTED]> 
escreveu
> >>
> >> aff...
> >> errei o caminho.
> >> /usj.... troque para  /usr...
> >>
> >> vmtune:2:once:/usr/samples/kernel/vmtune -p5 -P10 -r8 -R16 -
f128 -
> > F144
> >>
> >> Raphael
> >>
> >> - Original Message - 
> >> From: "Phael" <[EMAIL PROTECTE

Re: [oracle_br] Re: Performance Horrivel

[Porteno, André]

gt; > 
> > > > > --- Em oracle_br@yahoogrupos.com.br, Sergio Leandro 
Ghellere 
> > > > > <[EMAIL PROTECTED]> escreveu
> > > > > >
> > > > > > Ola Jemerson,
> > > > > > 
> > > > > >é difícil achar encontrar um problema assim...
> > > > > >só pra termos uma idéia, cola o resultado do AWR...
> > > > > >executa no sqlplus.
> > > > > >@$ORACLE_HOME/rdbms/admin/awrrpt.sql
> > > > > > 
> > > > > > pega aí um intervalo de algumas horas... normalmente o 
AWR 
> > > colhe 
> > > > > estatísticas a cada 
> > > > > > 60min..
> > > > > > 
> > > > > >cola as primeiras 100 linhas só pra termos uma idéia.
> > > > > > 
> > > > > > 
> > > > > > Grande abraço.
> > > > > > 
> > > > > > 
> > > > > > Sergio Leandro Ghellere
> > > > > > DBA Oracle
> > > > > > +55 (41) 9906-4813
> > > > > > 
> > > > > > On Thu Apr  6 15:19 , 'Phael' <[EMAIL PROTECTED]> sent:
> > > > > > 
> > > > > > >Ola Jemerson,
> > > > > > >
> > > > > > >Ja tive problemas com performance com AIX.
> > > > > > >No meu caso o problema era com um parametro do SO.
> > > > > > >Distrubuição da memória cache.
> > > > > > >
> > > > > > >executa esse arquivo ai:
> > > > > > >
> > > > > > ># /usjr/samples/kernel/vmtune
> > > > > > >
> > > > > > >colo o resultado ai.
> > > > > > >
> > > > > > >Raphael
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >- Original Message - 
> > > > > > >From: "Jemerson Dutra" [EMAIL PROTECTED]>
> > > > > > >To: oracle_br@yahoogrupos.com.br>
> > > > > > >Sent: Thursday, April 06, 2006 2:35 PM
> > > > > > >Subject: [oracle_br] Re: Performance Horrivel
> > > > > > >
> > > > > > >
> > > > > > >Ae chiappa, da uma ajuda ai.
> > > > > > >Jemerson
> > > > > > >--- Em oracle_br@yahoogrupos.com.br, "Jemerson Dutra" 
> > > > > > >escreveu
> > > > > > >>
> > > > > > >> Senhores, estamos com um servidor em producao que foi 
> > criado 
> > > > com
> > > > > > >> alguns parametros default por causa de um ERP. Nos 
> > deparamos 
> > > > > apos
> > > > > > >35
> > > > > > >> dias, que o servidor esta com uma performance 
horrivel. 
> > > > > Gostaria da
> > > > > > >> ajuda dos senhores, comentando/incluindo e ou 
alterando 
> meu
> > > > > > >init.ora.
> > > > > > >> Servidor IBM AIX 5.2
> > > > > > >> 4GB RAM
> > > > > > >> 4GB SWAP
> > > > > > >> 2 CPUS DE 1.2GHZ
> > > > > > >> ORACLE 10GB DE BANCO
> > > > > > >> CRIADO BLOCK_SIZE 4096KB
> > > > > > >> # initMFGPRO.ora - oracle instance parameter file
> > > > > > >> # include database configuration parameters
> > > > > > >> ifile = /Hdados2/admin/MFGPRO/config.MFGPRO
> > > > > > >> open_cursors = 512
> > > > > > >> # NLS Parameters
> > > > > > >>   NLS_LANGUAGE = "AMERICAN"
> > > > > > >>   NLS_TERRITORY = "AMERICA"
> > > > > > >>   NLS_NUMERIC_CHARACTERS = ".,"
> > > > > > >> # tuning parameters
> > > > > > >>   db_files = 200
> > > > > > >>   db_file_multiblock_read_count = 32   # 
> LARGE
> > > > > > >> # --- Autor : Jemerson - Data: 20/02/2006
> > > > > > >> # 
> > > > > > >>   shared_pool_size = 3  ## 4
> > > > > > >> # 
> > > > > &g

[oracle_br] Re: Performance Horrivel

[Jemerson Dutra]

gt; 1) S.O 
> > 2) Software Oracle + RBS
> > 3) ERP  + Dados1
> > 4) Indices + dic + Dados 2
> > 5) Dados 3 (esse é o disco mais pesado) 
> > rollback segments:
> > tenho 5 rollback segs de 
> > 
> > A aplicação roda no proprio servidor e os usuarios(cerca de 130 
> > usuarios) acessam via telnet, consumindo cerca de 20mb cada.
> > Coloquei cerca de 10 usuarios em MTS
> > 
> > Segue os parametros alterados.
> > obs: Ainda não estou utilizando os parametros sga_max_size e 
> > workarea_size_policy(nao tenho detalhes de como usar).
> > 
> > # Sort_area_size 
> > # session_cached_cursors
> > # timed_statistics
> > # log_checkpoint_interval
> > ===
> > Db_cache_size 
> >   Aumentei o Db_cache_size de 17825792 para 5000
> >DB_CACHE_SIZE = 5000 #17825792 06/04/2006
> > ===
> >  session_cached_cursors
> >  aumentei o session_cached_cursors de 100 para 300
> >  
> > 
> > # Sort_area_size 
> > Aumentei o Sort_area_size de 262144 para 1048576
> >   sort_area_size = 1048576 #262144 
> >   sort_area_retained_size = 1048576 #262144 
> > 
> > 
> > tenho um servidor IBM AIX 5.2L
> > COM 2 CPUs 1.2GHZ 
> > TOPAS 
> > S.O 
> >   KERNEL 10 
> >   USER   13
> >   WAIT   75
> >   IDLE2
> > 
> > Memory 
> > real,Mb  4096
> > % comp 71 
> > % nocomp   29.9 
> > 
> > paging space 
> > Size,MB 4096
> > % used53
> > % free46
> > 
> > 
> > --- Em oracle_br@yahoogrupos.com.br, "jlchiappa" <[EMAIL PROTECTED]> 
> > escreveu
> > >
> > > Colega, SE isto ainda é importante pra vc, releia aí a minha 
msg 
> > > anterior e manda a info que é pedida nela (ie, valor dos 
params, 
> > > workarea_size_policy, sga_max_size), diga EXATAMENTE o que vc 
> mudou 
> > > que obteve aí esses tais 10% de melhoria, e como pedido manda a 
> > > config de rollback/undo e do seu , a distribuição de I/O de 
modo 
> > > geral, especs do hardware de I/O,  e ajunta com mais info de SO 
e 
> > > hardware (ie, RAM livre e usada , CPU usada, taxa de uso de 
> swap), 
> > > que a gente pode tentar te ajudar.
> > >  Também seria legal vc fazer e mandar pra lista um testes fora 
da 
> > > aplicação, tipo : cria uma tabela "pequena", uma tabela "média" 
e 
> > uma 
> > > tabela "grande", faz alguns SQLs diretamente em cima delas, se 
> nem 
> > > isso ir bem a gente suspeita de configs de So e banco e de 
> hardware 
> > > sub-dimensionado...
> > > 
> > > []s
> > > 
> > >   Chiappa
> > > 
> > > --- Em oracle_br@yahoogrupos.com.br, "Jemerson Dutra" 
> > <[EMAIL PROTECTED]> 
> > > escreveu
> > > >
> > > > Meu banco de dados continua horrivel, melhorou cerca de uns 
> 10%. 
> > > > porem acho que nao esta como eu gostaria.
> > > > 
> > > > --- Em oracle_br@yahoogrupos.com.br, "jkdutra" <[EMAIL PROTECTED]> 
> > > > escreveu
> > > > >
> > > > > Srs Meu banco é 9i creio que o awrrpt.sql é somente do 10g 
ne?
> > > > > Chiappa, O pessoal do E.R.P tinha um init.ora basico e eu 
> > acabei 
> > > > > fazendo algumas poucas alteracoes, porem minha experiencia 
7 
> > anos 
> > > > é 
> > > > > toda no 8i. e lendo algumas coisas acabei alterando alguns 
> > > > > parametros, tenho autonomia para alterar o que quiser desde 
> que 
> > > > nao 
> > > > > altere as tabelas.
> > > > > Vou estar respondendo os senhores amanha da empresa com 
calma 
> > > > desde 
> > > > > ja agradeco a colaboração e espero poder contar com os 
> > senhores. 
> > > > > Chiappa, Sergio e Raphael Abraços.
> > > > > 
> > > > > --- Em oracle_br@yahoogrupos.com.br, Sergio Leandro 
Ghellere 
> > > > > <[EMAIL PROTECTED]> escreveu
> > > > > >
> > > > > > Ola Jemerson,
> > > > > > 
> > > > > >é difícil achar encontrar um problema assim...
> > > > > >só pra termos uma idéia, cola o resultado do AWR...
> > > > > >executa no sqlplus.
> > > > > >@$ORACLE_HOME/rdbms/admin/awrrpt.sql
> > > > > > 
> > > > > >

Re: [oracle_br] Re: Performance Horrivel

[Sharif G Raduan]

ed by Oracle and other processes, and less physical memory to be 
used to buffer file I/O.

Remember that although AIX associates this memory with the Oracle processes 
(because Oracle requested the file I/O), all of the memory used to buffer 
file I/O is completely allocated and controlled by AIX, not Oracle.  If you 
need help checking, setting, or tuning the AIX VMM, contact your AIX systems 
administrator and/or IBM Support.  You may also want to review the AIX 
"Performance Management Guide" by IBM linked in the References section 
below.

UPDATE: After this article was originally written, IBM has introduced a new 
VMM parameter which is also very helpful with this issue. The parameter 
is...


lru_file_repage
The default value is "1", but it is recommended to set this to "0". This 
setting hints to the VMM to only steal file pages (from the AIX file buffer 
cache) and leave the computational pages (from the SGA) alone.

This new lru_file_repage parameter is only available on AIX 5.2 ML04+ and 
AIX 5.3 ML01+




[]´s

Sharif

- Original Message ----- 
From: "Phael" <[EMAIL PROTECTED]>
To: 
Sent: Monday, April 10, 2006 11:10 AM
Subject: Re: [oracle_br] Re: Performance Horrivel


> Jemerson,
>
> Também não sou nenhum especialista em AIX.
> Na verdade quando tive problemas de performance no AIX
> fiz varios tunings na base e se esgotaram as
> tentativas de melhoras, tendo pouco sucesso. Chamei um
> tecnico para otimizar o AIX e ele me disse que esse parametro
> controla a distribuição da memória Cache da máquina sendo que
> por default ele libera 80% do recurso para o SO e 20% para
> demais softwares... vai entende isso???...se estiver falando besteira
> alguem me corrija por facor.enfim  mudei esse parametro!!!
> Como estavam tendo bastante paginação e swap a mudança
> dessa configuração pra 10% e 5% foi otima acabando com
> os problemas de paginações e swap.
> Esse procedimento foi feito em um AIX 4.3.3 mas acho que
> serve para o AIX 5.2.
> Não custa tentar, caso não der certo é só remover a linha e
> entrar em contato com algum especialista em AIX para
> entender melhor esses reajuste.
>
> atc
>
> Raphael
>
>
> - Original Message - 
> From: "Jemerson Dutra" <[EMAIL PROTECTED]>
> To: 
> Sent: Monday, April 10, 2006 10:45 AM
> Subject: [oracle_br] Re: Performance Horrivel
>
>
> Raphael, desculpe minha ignorancia mas o que esses parametros
> controlam? e o que eles farao??
> Jemerson
>
> --- Em oracle_br@yahoogrupos.com.br, "Phael" <[EMAIL PROTECTED]> escreveu
>>
>> aff...
>> errei o caminho.
>> /usj troque para  /usr...
>>
>> vmtune:2:once:/usr/samples/kernel/vmtune -p5 -P10 -r8 -R16 -f128 -
> F144
>>
>> Raphael
>>
>> - Original Message - 
>> From: "Phael" <[EMAIL PROTECTED]>
>> To: 
>> Sent: Monday, April 10, 2006 8:48 AM
>> Subject: Re: [oracle_br] Re: Performance Horrivel
>>
>>
>> > Jemerson,
>> >
>> > Adicione esssa linha no seu arquivo /etc/inittab
>> >
>> > vmtune:2:once:/usj/samples/kernel/vmtune -p5 -P10 -r8 -R16 -f128 -
> F144
>> >
>> > reinicie a maquina!
>> >
>> > E rode de novo o vmtune para ver se as alterações foram feitas:
>> > esses parametros deverão ser reajustados...
>> > minperm% = 20   para 5
>> > maxperm% = 80  para 10
>> >
>> > Atc
>> >
>> > Raphael
>> >
>> >
>> > - Original Message - 
>> > From: "Jemerson Dutra" <[EMAIL PROTECTED]>
>> > To: 
>> > Sent: Friday, April 07, 2006 7:57 AM
>> > Subject: [oracle_br] Re: Performance Horrivel
>> >
>> >
>> > Raphael, segue o resultado do vmtune
>> >
>> > memory_frames = 1048576
>> > pinnable_frames = 940632
>> > maxfree = 128
>> > minfree = 120
>> > minperm% = 20
>> > minperm = 19
>> > maxperm% = 80
>> > maxperm = 773332
>> > strict_maxperm = 0
>> > maxpin% = 80
>> > maxpin = 838861
>> > maxclient% = 80
>> > lrubucket = 131072
>> > defps = 1
>> > nokilluid = 0
>> > numpsblks = 1081344
>> > npskill = 8448
>> > npswarn = 33792
>> > v_pinshm = 0
>> > pta_balance_threshold = 0
>> > pagecoloring = 0
>> > framesets = 2
>> > mempools = 1
>> > lgpg_size = 0
>> > lgpg_regions = 0
>> > num_spec_dataseg = 0
>> > spec_dataseg_int = 512
>> > memory_affinity = 1
>> > htabscale = -1
>> > fo

[oracle_br] Re: Performance Horrivel

[jlchiappa]

 53
> % free46
> 
> 
> --- Em oracle_br@yahoogrupos.com.br, "jlchiappa" <[EMAIL PROTECTED]> 
> escreveu
> >
> > Colega, SE isto ainda é importante pra vc, releia aí a minha msg 
> > anterior e manda a info que é pedida nela (ie, valor dos params, 
> > workarea_size_policy, sga_max_size), diga EXATAMENTE o que vc 
mudou 
> > que obteve aí esses tais 10% de melhoria, e como pedido manda a 
> > config de rollback/undo e do seu , a distribuição de I/O de modo 
> > geral, especs do hardware de I/O,  e ajunta com mais info de SO e 
> > hardware (ie, RAM livre e usada , CPU usada, taxa de uso de 
swap), 
> > que a gente pode tentar te ajudar.
> >  Também seria legal vc fazer e mandar pra lista um testes fora da 
> > aplicação, tipo : cria uma tabela "pequena", uma tabela "média" e 
> uma 
> > tabela "grande", faz alguns SQLs diretamente em cima delas, se 
nem 
> > isso ir bem a gente suspeita de configs de So e banco e de 
hardware 
> > sub-dimensionado...
> > 
> > []s
> > 
> >   Chiappa
> > 
> > --- Em oracle_br@yahoogrupos.com.br, "Jemerson Dutra" 
> <[EMAIL PROTECTED]> 
> > escreveu
> > >
> > > Meu banco de dados continua horrivel, melhorou cerca de uns 
10%. 
> > > porem acho que nao esta como eu gostaria.
> > > 
> > > --- Em oracle_br@yahoogrupos.com.br, "jkdutra" <[EMAIL PROTECTED]> 
> > > escreveu
> > > >
> > > > Srs Meu banco é 9i creio que o awrrpt.sql é somente do 10g ne?
> > > > Chiappa, O pessoal do E.R.P tinha um init.ora basico e eu 
> acabei 
> > > > fazendo algumas poucas alteracoes, porem minha experiencia 7 
> anos 
> > > é 
> > > > toda no 8i. e lendo algumas coisas acabei alterando alguns 
> > > > parametros, tenho autonomia para alterar o que quiser desde 
que 
> > > nao 
> > > > altere as tabelas.
> > > > Vou estar respondendo os senhores amanha da empresa com calma 
> > > desde 
> > > > ja agradeco a colaboração e espero poder contar com os 
> senhores. 
> > > > Chiappa, Sergio e Raphael Abraços.
> > > > 
> > > > --- Em oracle_br@yahoogrupos.com.br, Sergio Leandro Ghellere 
> > > > <[EMAIL PROTECTED]> escreveu
> > > > >
> > > > > Ola Jemerson,
> > > > > 
> > > > >é difícil achar encontrar um problema assim...
> > > > >só pra termos uma idéia, cola o resultado do AWR...
> > > > >executa no sqlplus.
> > > > >@$ORACLE_HOME/rdbms/admin/awrrpt.sql
> > > > > 
> > > > > pega aí um intervalo de algumas horas... normalmente o AWR 
> > colhe 
> > > > estatísticas a cada 
> > > > > 60min..
> > > > > 
> > > > >cola as primeiras 100 linhas só pra termos uma idéia.
> > > > > 
> > > > > 
> > > > > Grande abraço.
> > > > > 
> > > > > 
> > > > > Sergio Leandro Ghellere
> > > > > DBA Oracle
> > > > > +55 (41) 9906-4813
> > > > > 
> > > > > On Thu Apr  6 15:19 , 'Phael' <[EMAIL PROTECTED]> sent:
> > > > > 
> > > > > >Ola Jemerson,
> > > > > >
> > > > > >Ja tive problemas com performance com AIX.
> > > > > >No meu caso o problema era com um parametro do SO.
> > > > > >Distrubuição da memória cache.
> > > > > >
> > > > > >executa esse arquivo ai:
> > > > > >
> > > > > ># /usjr/samples/kernel/vmtune
> > > > > >
> > > > > >colo o resultado ai.
> > > > > >
> > > > > >Raphael
> > > > > >
> > > > > >
> > > > > >
> > > > > >- Original Message - 
> > > > > >From: "Jemerson Dutra" [EMAIL PROTECTED]>
> > > > > >To: oracle_br@yahoogrupos.com.br>
> > > > > >Sent: Thursday, April 06, 2006 2:35 PM
> > > > > >Subject: [oracle_br] Re: Performance Horrivel
> > > > > >
> > > > > >
> > > > > >Ae chiappa, da uma ajuda ai.
> > > > > >Jemerson
> > > > > >--- Em oracle_br@yahoogrupos.com.br, "Jemerson Dutra" 
> > > > > >escreveu
> > > > > >>

[oracle_br] Re: Performance Horrivel

[Jemerson Dutra]

Raphael, Obrigado. Tentarei essa alternativa tambem e postarei os 
resultados para que os senhores saibam das melhorias.
Jemerson

--- Em oracle_br@yahoogrupos.com.br, "Phael" <[EMAIL PROTECTED]> escreveu
>
> Jemerson,
> 
> Também não sou nenhum especialista em AIX.
> Na verdade quando tive problemas de performance no AIX
> fiz varios tunings na base e se esgotaram as
> tentativas de melhoras, tendo pouco sucesso. Chamei um
> tecnico para otimizar o AIX e ele me disse que esse parametro
> controla a distribuição da memória Cache da máquina sendo que
> por default ele libera 80% do recurso para o SO e 20% para
> demais softwares... vai entende isso???...se estiver falando 
besteira
> alguem me corrija por facor.enfim  mudei esse parametro!!!
> Como estavam tendo bastante paginação e swap a mudança
> dessa configuração pra 10% e 5% foi otima acabando com
> os problemas de paginações e swap.
> Esse procedimento foi feito em um AIX 4.3.3 mas acho que
> serve para o AIX 5.2.
> Não custa tentar, caso não der certo é só remover a linha e
> entrar em contato com algum especialista em AIX para
> entender melhor esses reajuste.
> 
> atc
> 
> Raphael
> 
> 
> - Original Message - 
> From: "Jemerson Dutra" <[EMAIL PROTECTED]>
> To: 
> Sent: Monday, April 10, 2006 10:45 AM
> Subject: [oracle_br] Re: Performance Horrivel
> 
> 
> Raphael, desculpe minha ignorancia mas o que esses parametros
> controlam? e o que eles farao??
> Jemerson
> 
> --- Em oracle_br@yahoogrupos.com.br, "Phael" <[EMAIL PROTECTED]> escreveu
> >
> > aff...
> > errei o caminho.
> > /usj troque para  /usr...
> >
> > vmtune:2:once:/usr/samples/kernel/vmtune -p5 -P10 -r8 -R16 -f128 -
> F144
> >
> > Raphael
> >
> > - Original Message - 
> > From: "Phael" <[EMAIL PROTECTED]>
> > To: 
> > Sent: Monday, April 10, 2006 8:48 AM
> > Subject: Re: [oracle_br] Re: Performance Horrivel
> >
> >
> > > Jemerson,
> > >
> > > Adicione esssa linha no seu arquivo /etc/inittab
> > >
> > > vmtune:2:once:/usj/samples/kernel/vmtune -p5 -P10 -r8 -R16 -
f128 -
> F144
> > >
> > > reinicie a maquina!
> > >
> > > E rode de novo o vmtune para ver se as alterações foram feitas:
> > > esses parametros deverão ser reajustados...
> > > minperm% = 20   para 5
> > > maxperm% = 80  para 10
> > >
> > > Atc
> > >
> > > Raphael
> > >
> > >
> > > - Original Message - 
> > > From: "Jemerson Dutra" <[EMAIL PROTECTED]>
> > > To: 
> > > Sent: Friday, April 07, 2006 7:57 AM
> > > Subject: [oracle_br] Re: Performance Horrivel
> > >
> > >
> > > Raphael, segue o resultado do vmtune
> > >
> > > memory_frames = 1048576
> > > pinnable_frames = 940632
> > > maxfree = 128
> > > minfree = 120
> > > minperm% = 20
> > > minperm = 19
> > > maxperm% = 80
> > > maxperm = 773332
> > > strict_maxperm = 0
> > > maxpin% = 80
> > > maxpin = 838861
> > > maxclient% = 80
> > > lrubucket = 131072
> > > defps = 1
> > > nokilluid = 0
> > > numpsblks = 1081344
> > > npskill = 8448
> > > npswarn = 33792
> > > v_pinshm = 0
> > > pta_balance_threshold = 0
> > > pagecoloring = 0
> > > framesets = 2
> > > mempools = 1
> > > lgpg_size = 0
> > > lgpg_regions = 0
> > > num_spec_dataseg = 0
> > > spec_dataseg_int = 512
> > > memory_affinity = 1
> > > htabscale = -1
> > > force_relalias_lite = 0
> > > relalias_percentage = 0
> > > data_stagger_interval = 161
> > > large_page_heap_size = 0
> > > kernel_heap_psize = 4096
> > > soft_min_lgpgs_vmpool = 0
> > > vmm_fork_policy = 0
> > > low_ps_handling = 1
> > > mbuf_heap_psize = 4096
> > > strict_maxclient = 1
> > > cpu_scale_memp = 8
> > > lru_poll_interval = 0
> > > lru_file_repage = 1
> > > memory_frames = 1048576
> > > minpgahead = 2
> > > memory_frames = 1048576
> > > minpgahead = 2
> > > maxpgahead = 8
> > > pd_npages = 65536
> > > maxrandwrt = 0
> > > numclust = 1
> > > numfsbufs = 196
> > > sync_release_ilock = 0
> > > lvm_bufcnt = 9
> > > j2_minPageReadAhead = 2
> > > j2_maxPageReadAhead = 128
> > > j2_nBufferPer

Re: [oracle_br] Re: Performance Horrivel

[Phael]

Jemerson,

Também não sou nenhum especialista em AIX.
Na verdade quando tive problemas de performance no AIX
fiz varios tunings na base e se esgotaram as
tentativas de melhoras, tendo pouco sucesso. Chamei um
tecnico para otimizar o AIX e ele me disse que esse parametro
controla a distribuição da memória Cache da máquina sendo que
por default ele libera 80% do recurso para o SO e 20% para
demais softwares... vai entende isso???...se estiver falando besteira
alguem me corrija por facor.enfim  mudei esse parametro!!!
Como estavam tendo bastante paginação e swap a mudança
dessa configuração pra 10% e 5% foi otima acabando com
os problemas de paginações e swap.
Esse procedimento foi feito em um AIX 4.3.3 mas acho que
serve para o AIX 5.2.
Não custa tentar, caso não der certo é só remover a linha e
entrar em contato com algum especialista em AIX para
entender melhor esses reajuste.

atc

Raphael


- Original Message - 
From: "Jemerson Dutra" <[EMAIL PROTECTED]>
To: 
Sent: Monday, April 10, 2006 10:45 AM
Subject: [oracle_br] Re: Performance Horrivel


Raphael, desculpe minha ignorancia mas o que esses parametros
controlam? e o que eles farao??
Jemerson

--- Em oracle_br@yahoogrupos.com.br, "Phael" <[EMAIL PROTECTED]> escreveu
>
> aff...
> errei o caminho.
> /usj troque para  /usr...
>
> vmtune:2:once:/usr/samples/kernel/vmtune -p5 -P10 -r8 -R16 -f128 -
F144
>
> Raphael
>
> - Original Message - 
> From: "Phael" <[EMAIL PROTECTED]>
> To: 
> Sent: Monday, April 10, 2006 8:48 AM
> Subject: Re: [oracle_br] Re: Performance Horrivel
>
>
> > Jemerson,
> >
> > Adicione esssa linha no seu arquivo /etc/inittab
> >
> > vmtune:2:once:/usj/samples/kernel/vmtune -p5 -P10 -r8 -R16 -f128 -
F144
> >
> > reinicie a maquina!
> >
> > E rode de novo o vmtune para ver se as alterações foram feitas:
> > esses parametros deverão ser reajustados...
> > minperm% = 20   para 5
> > maxperm% = 80  para 10
> >
> > Atc
> >
> > Raphael
> >
> >
> > - Original Message - 
> > From: "Jemerson Dutra" <[EMAIL PROTECTED]>
> > To: 
> > Sent: Friday, April 07, 2006 7:57 AM
> > Subject: [oracle_br] Re: Performance Horrivel
> >
> >
> > Raphael, segue o resultado do vmtune
> >
> > memory_frames = 1048576
> > pinnable_frames = 940632
> > maxfree = 128
> > minfree = 120
> > minperm% = 20
> > minperm = 19
> > maxperm% = 80
> > maxperm = 773332
> > strict_maxperm = 0
> > maxpin% = 80
> > maxpin = 838861
> > maxclient% = 80
> > lrubucket = 131072
> > defps = 1
> > nokilluid = 0
> > numpsblks = 1081344
> > npskill = 8448
> > npswarn = 33792
> > v_pinshm = 0
> > pta_balance_threshold = 0
> > pagecoloring = 0
> > framesets = 2
> > mempools = 1
> > lgpg_size = 0
> > lgpg_regions = 0
> > num_spec_dataseg = 0
> > spec_dataseg_int = 512
> > memory_affinity = 1
> > htabscale = -1
> > force_relalias_lite = 0
> > relalias_percentage = 0
> > data_stagger_interval = 161
> > large_page_heap_size = 0
> > kernel_heap_psize = 4096
> > soft_min_lgpgs_vmpool = 0
> > vmm_fork_policy = 0
> > low_ps_handling = 1
> > mbuf_heap_psize = 4096
> > strict_maxclient = 1
> > cpu_scale_memp = 8
> > lru_poll_interval = 0
> > lru_file_repage = 1
> > memory_frames = 1048576
> > minpgahead = 2
> > memory_frames = 1048576
> > minpgahead = 2
> > maxpgahead = 8
> > pd_npages = 65536
> > maxrandwrt = 0
> > numclust = 1
> > numfsbufs = 196
> > sync_release_ilock = 0
> > lvm_bufcnt = 9
> > j2_minPageReadAhead = 2
> > j2_maxPageReadAhead = 128
> > j2_nBufferPerPagerDevice = 512
> > j2_nPagesPerWriteBehindCluster = 32
> > j2_maxRandomWrite = 0
> > j2_nRandomCluster = 0
> > j2_non_fatal_crashes_system = 0
> > j2_syncModifiedMapped = 1
> > jfs_clread_enabled = 0
> > jfs_use_read_lock = 1
> > hd_pvs_opn = 6
> > hd_pbuf_cnt = 1280
> > j2_inodeCacheSize = 400
> > j2_metadataCacheSize = 400
> > j2_dynamicBufferPreallocation = 16
> > j2_maxUsableMaxTransfer = 512
> > pgahd_scale_thresh = 0
> > hd_pendqblked = 0
> > psbufwaitcnt = 347632
> > fsbufwaitcnt = 1541572
> > rfsbufwaitcnt = 0
> > xpagerbufwaitcnt = 0
> > --- Em oracle_br@yahoogrupos.com.br, "Phael" <[EMAIL PROTECTED]>
escreveu
> >>
> >> Ola Jemerson,
> >>
> >> Ja tive problemas com performance com AIX.
> >> No meu caso o problema era co

[oracle_br] Re: Performance Horrivel

[Jemerson Dutra]

Raphael, desculpe minha ignorancia mas o que esses parametros 
controlam? e o que eles farao??
Jemerson

--- Em oracle_br@yahoogrupos.com.br, "Phael" <[EMAIL PROTECTED]> escreveu
>
> aff...
> errei o caminho.
> /usj troque para  /usr...
> 
> vmtune:2:once:/usr/samples/kernel/vmtune -p5 -P10 -r8 -R16 -f128 -
F144
> 
> Raphael
> 
> - Original Message - 
> From: "Phael" <[EMAIL PROTECTED]>
> To: 
> Sent: Monday, April 10, 2006 8:48 AM
> Subject: Re: [oracle_br] Re: Performance Horrivel
> 
> 
> > Jemerson,
> >
> > Adicione esssa linha no seu arquivo /etc/inittab
> >
> > vmtune:2:once:/usj/samples/kernel/vmtune -p5 -P10 -r8 -R16 -f128 -
F144
> >
> > reinicie a maquina!
> >
> > E rode de novo o vmtune para ver se as alterações foram feitas:
> > esses parametros deverão ser reajustados...
> > minperm% = 20   para 5
> > maxperm% = 80  para 10
> >
> > Atc
> >
> > Raphael
> >
> >
> > - Original Message - 
> > From: "Jemerson Dutra" <[EMAIL PROTECTED]>
> > To: 
> > Sent: Friday, April 07, 2006 7:57 AM
> > Subject: [oracle_br] Re: Performance Horrivel
> >
> >
> > Raphael, segue o resultado do vmtune
> >
> > memory_frames = 1048576
> > pinnable_frames = 940632
> > maxfree = 128
> > minfree = 120
> > minperm% = 20
> > minperm = 19
> > maxperm% = 80
> > maxperm = 773332
> > strict_maxperm = 0
> > maxpin% = 80
> > maxpin = 838861
> > maxclient% = 80
> > lrubucket = 131072
> > defps = 1
> > nokilluid = 0
> > numpsblks = 1081344
> > npskill = 8448
> > npswarn = 33792
> > v_pinshm = 0
> > pta_balance_threshold = 0
> > pagecoloring = 0
> > framesets = 2
> > mempools = 1
> > lgpg_size = 0
> > lgpg_regions = 0
> > num_spec_dataseg = 0
> > spec_dataseg_int = 512
> > memory_affinity = 1
> > htabscale = -1
> > force_relalias_lite = 0
> > relalias_percentage = 0
> > data_stagger_interval = 161
> > large_page_heap_size = 0
> > kernel_heap_psize = 4096
> > soft_min_lgpgs_vmpool = 0
> > vmm_fork_policy = 0
> > low_ps_handling = 1
> > mbuf_heap_psize = 4096
> > strict_maxclient = 1
> > cpu_scale_memp = 8
> > lru_poll_interval = 0
> > lru_file_repage = 1
> > memory_frames = 1048576
> > minpgahead = 2
> > memory_frames = 1048576
> > minpgahead = 2
> > maxpgahead = 8
> > pd_npages = 65536
> > maxrandwrt = 0
> > numclust = 1
> > numfsbufs = 196
> > sync_release_ilock = 0
> > lvm_bufcnt = 9
> > j2_minPageReadAhead = 2
> > j2_maxPageReadAhead = 128
> > j2_nBufferPerPagerDevice = 512
> > j2_nPagesPerWriteBehindCluster = 32
> > j2_maxRandomWrite = 0
> > j2_nRandomCluster = 0
> > j2_non_fatal_crashes_system = 0
> > j2_syncModifiedMapped = 1
> > jfs_clread_enabled = 0
> > jfs_use_read_lock = 1
> > hd_pvs_opn = 6
> > hd_pbuf_cnt = 1280
> > j2_inodeCacheSize = 400
> > j2_metadataCacheSize = 400
> > j2_dynamicBufferPreallocation = 16
> > j2_maxUsableMaxTransfer = 512
> > pgahd_scale_thresh = 0
> > hd_pendqblked = 0
> > psbufwaitcnt = 347632
> > fsbufwaitcnt = 1541572
> > rfsbufwaitcnt = 0
> > xpagerbufwaitcnt = 0
> > --- Em oracle_br@yahoogrupos.com.br, "Phael" <[EMAIL PROTECTED]> 
escreveu
> >>
> >> Ola Jemerson,
> >>
> >> Ja tive problemas com performance com AIX.
> >> No meu caso o problema era com um parametro do SO.
> >> Distrubuição da memória cache.
> >>
> >> executa esse arquivo ai:
> >>
> >> # /usjr/samples/kernel/vmtune
> >>
> >> colo o resultado ai.
> >>
> >> Raphael
> >>
> >>
> >>
> >> - Original Message - 
> >> From: "Jemerson Dutra" <[EMAIL PROTECTED]>
> >> To: 
> >> Sent: Thursday, April 06, 2006 2:35 PM
> >> Subject: [oracle_br] Re: Performance Horrivel
> >>
> >>
> >> Ae chiappa, da uma ajuda ai.
> >> Jemerson
> >> --- Em oracle_br@yahoogrupos.com.br, "Jemerson Dutra" 
<[EMAIL PROTECTED]>
> >> escreveu
> >> >
> >> > Senhores, estamos com um servidor em producao que foi criado 
com
> >> > alguns parametros default por causa de um ERP. Nos deparamos 
apos
> >> 35
> >> > dias, que o servidor esta com uma performance horrivel. 
Gostaria
> > da
>

[oracle_br] Re: Performance Horrivel

[Jemerson Dutra]

Chiappa, segue os dados solicitados, desde ja agradeco a atencao.

Deu uma melhor distribuida das tablespaces nos discos
- Tirei o Rbs do disco 5 e coloquei junto com o Software Oracle. 
- Algumas tablespaces de dados coloquei no Disco 3 juntamente com o 
ERP.
- o Disco 5 continua o mais pesado.
Atualmente tenho 5 discos.
Segue a distribuição. 
1) S.O 
2) Software Oracle + RBS
3) ERP  + Dados1
4) Indices + dic + Dados 2
5) Dados 3 (esse é o disco mais pesado) 
rollback segments:
tenho 5 rollback segs de 

A aplicação roda no proprio servidor e os usuarios(cerca de 130 
usuarios) acessam via telnet, consumindo cerca de 20mb cada.
Coloquei cerca de 10 usuarios em MTS

Segue os parametros alterados.
obs: Ainda não estou utilizando os parametros sga_max_size e 
workarea_size_policy(nao tenho detalhes de como usar).

# Sort_area_size 
# session_cached_cursors
# timed_statistics
# log_checkpoint_interval
===
Db_cache_size 
  Aumentei o Db_cache_size de 17825792 para 5000
   DB_CACHE_SIZE = 5000 #17825792 06/04/2006
===
 session_cached_cursors
 aumentei o session_cached_cursors de 100 para 300
 

# Sort_area_size 
Aumentei o Sort_area_size de 262144 para 1048576
  sort_area_size = 1048576 #262144 
  sort_area_retained_size = 1048576 #262144 


tenho um servidor IBM AIX 5.2L
COM 2 CPUs 1.2GHZ 
TOPAS 
S.O 
  KERNEL 10 
  USER   13
  WAIT   75
  IDLE2

Memory 
real,Mb  4096
% comp 71 
% nocomp   29.9 

paging space 
Size,MB 4096
% used53
% free46


--- Em oracle_br@yahoogrupos.com.br, "jlchiappa" <[EMAIL PROTECTED]> 
escreveu
>
> Colega, SE isto ainda é importante pra vc, releia aí a minha msg 
> anterior e manda a info que é pedida nela (ie, valor dos params, 
> workarea_size_policy, sga_max_size), diga EXATAMENTE o que vc mudou 
> que obteve aí esses tais 10% de melhoria, e como pedido manda a 
> config de rollback/undo e do seu , a distribuição de I/O de modo 
> geral, especs do hardware de I/O,  e ajunta com mais info de SO e 
> hardware (ie, RAM livre e usada , CPU usada, taxa de uso de swap), 
> que a gente pode tentar te ajudar.
>  Também seria legal vc fazer e mandar pra lista um testes fora da 
> aplicação, tipo : cria uma tabela "pequena", uma tabela "média" e 
uma 
> tabela "grande", faz alguns SQLs diretamente em cima delas, se nem 
> isso ir bem a gente suspeita de configs de So e banco e de hardware 
> sub-dimensionado...
> 
> []s
> 
>   Chiappa
> 
> --- Em oracle_br@yahoogrupos.com.br, "Jemerson Dutra" 
<[EMAIL PROTECTED]> 
> escreveu
> >
> > Meu banco de dados continua horrivel, melhorou cerca de uns 10%. 
> > porem acho que nao esta como eu gostaria.
> > 
> > --- Em oracle_br@yahoogrupos.com.br, "jkdutra" <[EMAIL PROTECTED]> 
> > escreveu
> > >
> > > Srs Meu banco é 9i creio que o awrrpt.sql é somente do 10g ne?
> > > Chiappa, O pessoal do E.R.P tinha um init.ora basico e eu 
acabei 
> > > fazendo algumas poucas alteracoes, porem minha experiencia 7 
anos 
> > é 
> > > toda no 8i. e lendo algumas coisas acabei alterando alguns 
> > > parametros, tenho autonomia para alterar o que quiser desde que 
> > nao 
> > > altere as tabelas.
> > > Vou estar respondendo os senhores amanha da empresa com calma 
> > desde 
> > > ja agradeco a colaboração e espero poder contar com os 
senhores. 
> > > Chiappa, Sergio e Raphael Abraços.
> > > 
> > > --- Em oracle_br@yahoogrupos.com.br, Sergio Leandro Ghellere 
> > > <[EMAIL PROTECTED]> escreveu
> > > >
> > > > Ola Jemerson,
> > > > 
> > > >é difícil achar encontrar um problema assim...
> > > >só pra termos uma idéia, cola o resultado do AWR...
> > > >executa no sqlplus.
> > > >@$ORACLE_HOME/rdbms/admin/awrrpt.sql
> > > > 
> > > > pega aí um intervalo de algumas horas... normalmente o AWR 
> colhe 
> > > estatísticas a cada 
> > > > 60min..
> > > > 
> > > >cola as primeiras 100 linhas só pra termos uma idéia.
> > > > 
> > > > 
> > > > Grande abraço.
> > > > 
> > > > 
> > > > Sergio Leandro Ghellere
> > > > DBA Oracle
> > > > +55 (41) 9906-4813
> > > > 
> > > > On Thu Apr  6 15:19 , 'Phael' <[EMAIL PROTECTED]> sent:
> > > > 
> > > > >Ola Jemerson,
> > > > >
> > > > >Ja tive problemas com performance com AIX.
> > > > >No meu caso o problema era com um parametro do SO.
> > > > >D

Re: [oracle_br] Re: Performance Horrivel

[Phael]

aff...
errei o caminho.
/usj troque para  /usr...

vmtune:2:once:/usr/samples/kernel/vmtune -p5 -P10 -r8 -R16 -f128 -F144

Raphael

- Original Message - 
From: "Phael" <[EMAIL PROTECTED]>
To: 
Sent: Monday, April 10, 2006 8:48 AM
Subject: Re: [oracle_br] Re: Performance Horrivel


> Jemerson,
>
> Adicione esssa linha no seu arquivo /etc/inittab
>
> vmtune:2:once:/usj/samples/kernel/vmtune -p5 -P10 -r8 -R16 -f128 -F144
>
> reinicie a maquina!
>
> E rode de novo o vmtune para ver se as alterações foram feitas:
> esses parametros deverão ser reajustados...
> minperm% = 20   para 5
> maxperm% = 80  para 10
>
> Atc
>
> Raphael
>
>
> - Original Message - 
> From: "Jemerson Dutra" <[EMAIL PROTECTED]>
> To: 
> Sent: Friday, April 07, 2006 7:57 AM
> Subject: [oracle_br] Re: Performance Horrivel
>
>
> Raphael, segue o resultado do vmtune
>
> memory_frames = 1048576
> pinnable_frames = 940632
> maxfree = 128
> minfree = 120
> minperm% = 20
> minperm = 19
> maxperm% = 80
> maxperm = 773332
> strict_maxperm = 0
> maxpin% = 80
> maxpin = 838861
> maxclient% = 80
> lrubucket = 131072
> defps = 1
> nokilluid = 0
> numpsblks = 1081344
> npskill = 8448
> npswarn = 33792
> v_pinshm = 0
> pta_balance_threshold = 0
> pagecoloring = 0
> framesets = 2
> mempools = 1
> lgpg_size = 0
> lgpg_regions = 0
> num_spec_dataseg = 0
> spec_dataseg_int = 512
> memory_affinity = 1
> htabscale = -1
> force_relalias_lite = 0
> relalias_percentage = 0
> data_stagger_interval = 161
> large_page_heap_size = 0
> kernel_heap_psize = 4096
> soft_min_lgpgs_vmpool = 0
> vmm_fork_policy = 0
> low_ps_handling = 1
> mbuf_heap_psize = 4096
> strict_maxclient = 1
> cpu_scale_memp = 8
> lru_poll_interval = 0
> lru_file_repage = 1
> memory_frames = 1048576
> minpgahead = 2
> memory_frames = 1048576
> minpgahead = 2
> maxpgahead = 8
> pd_npages = 65536
> maxrandwrt = 0
> numclust = 1
> numfsbufs = 196
> sync_release_ilock = 0
> lvm_bufcnt = 9
> j2_minPageReadAhead = 2
> j2_maxPageReadAhead = 128
> j2_nBufferPerPagerDevice = 512
> j2_nPagesPerWriteBehindCluster = 32
> j2_maxRandomWrite = 0
> j2_nRandomCluster = 0
> j2_non_fatal_crashes_system = 0
> j2_syncModifiedMapped = 1
> jfs_clread_enabled = 0
> jfs_use_read_lock = 1
> hd_pvs_opn = 6
> hd_pbuf_cnt = 1280
> j2_inodeCacheSize = 400
> j2_metadataCacheSize = 400
> j2_dynamicBufferPreallocation = 16
> j2_maxUsableMaxTransfer = 512
> pgahd_scale_thresh = 0
> hd_pendqblked = 0
> psbufwaitcnt = 347632
> fsbufwaitcnt = 1541572
> rfsbufwaitcnt = 0
> xpagerbufwaitcnt = 0
> --- Em oracle_br@yahoogrupos.com.br, "Phael" <[EMAIL PROTECTED]> escreveu
>>
>> Ola Jemerson,
>>
>> Ja tive problemas com performance com AIX.
>> No meu caso o problema era com um parametro do SO.
>> Distrubuição da memória cache.
>>
>> executa esse arquivo ai:
>>
>> # /usjr/samples/kernel/vmtune
>>
>> colo o resultado ai.
>>
>> Raphael
>>
>>
>>
>> - Original Message - 
>> From: "Jemerson Dutra" <[EMAIL PROTECTED]>
>> To: 
>> Sent: Thursday, April 06, 2006 2:35 PM
>> Subject: [oracle_br] Re: Performance Horrivel
>>
>>
>> Ae chiappa, da uma ajuda ai.
>> Jemerson
>> --- Em oracle_br@yahoogrupos.com.br, "Jemerson Dutra" <[EMAIL PROTECTED]>
>> escreveu
>> >
>> > Senhores, estamos com um servidor em producao que foi criado com
>> > alguns parametros default por causa de um ERP. Nos deparamos apos
>> 35
>> > dias, que o servidor esta com uma performance horrivel. Gostaria
> da
>> > ajuda dos senhores, comentando/incluindo e ou alterando meu
>> init.ora.
>> > Servidor IBM AIX 5.2
>> > 4GB RAM
>> > 4GB SWAP
>> > 2 CPUS DE 1.2GHZ
>> > ORACLE 10GB DE BANCO
>> > CRIADO BLOCK_SIZE 4096KB
>> > # initMFGPRO.ora - oracle instance parameter file
>> > # include database configuration parameters
>> > ifile = /Hdados2/admin/MFGPRO/config.MFGPRO
>> > open_cursors = 512
>> > # NLS Parameters
>> >   NLS_LANGUAGE = "AMERICAN"
>> >   NLS_TERRITORY = "AMERICA"
>> >   NLS_NUMERIC_CHARACTERS = ".,"
>> > # tuning parameters
>> >   db_files = 200
>> >   db_file_multiblock_read_count = 32   # LARGE
>> > # --- Autor : Jemerson - Data: 20/02/2006
>> > # 
&

Re: [oracle_br] Re: Performance Horrivel

[Phael]

Jemerson,

Adicione esssa linha no seu arquivo /etc/inittab

vmtune:2:once:/usj/samples/kernel/vmtune -p5 -P10 -r8 -R16 -f128 -F144

reinicie a maquina!

E rode de novo o vmtune para ver se as alterações foram feitas:
esses parametros deverão ser reajustados...
minperm% = 20   para 5
maxperm% = 80  para 10

Atc

Raphael


- Original Message - 
From: "Jemerson Dutra" <[EMAIL PROTECTED]>
To: 
Sent: Friday, April 07, 2006 7:57 AM
Subject: [oracle_br] Re: Performance Horrivel


Raphael, segue o resultado do vmtune

memory_frames = 1048576
pinnable_frames = 940632
maxfree = 128
minfree = 120
minperm% = 20
minperm = 19
maxperm% = 80
maxperm = 773332
strict_maxperm = 0
maxpin% = 80
maxpin = 838861
maxclient% = 80
lrubucket = 131072
defps = 1
nokilluid = 0
numpsblks = 1081344
npskill = 8448
npswarn = 33792
v_pinshm = 0
pta_balance_threshold = 0
pagecoloring = 0
framesets = 2
mempools = 1
lgpg_size = 0
lgpg_regions = 0
num_spec_dataseg = 0
spec_dataseg_int = 512
memory_affinity = 1
htabscale = -1
force_relalias_lite = 0
relalias_percentage = 0
data_stagger_interval = 161
large_page_heap_size = 0
kernel_heap_psize = 4096
soft_min_lgpgs_vmpool = 0
vmm_fork_policy = 0
low_ps_handling = 1
mbuf_heap_psize = 4096
strict_maxclient = 1
cpu_scale_memp = 8
lru_poll_interval = 0
lru_file_repage = 1
memory_frames = 1048576
minpgahead = 2
memory_frames = 1048576
minpgahead = 2
maxpgahead = 8
pd_npages = 65536
maxrandwrt = 0
numclust = 1
numfsbufs = 196
sync_release_ilock = 0
lvm_bufcnt = 9
j2_minPageReadAhead = 2
j2_maxPageReadAhead = 128
j2_nBufferPerPagerDevice = 512
j2_nPagesPerWriteBehindCluster = 32
j2_maxRandomWrite = 0
j2_nRandomCluster = 0
j2_non_fatal_crashes_system = 0
j2_syncModifiedMapped = 1
jfs_clread_enabled = 0
jfs_use_read_lock = 1
hd_pvs_opn = 6
hd_pbuf_cnt = 1280
j2_inodeCacheSize = 400
j2_metadataCacheSize = 400
 j2_dynamicBufferPreallocation = 16
 j2_maxUsableMaxTransfer = 512
pgahd_scale_thresh = 0
hd_pendqblked = 0
psbufwaitcnt = 347632
fsbufwaitcnt = 1541572
rfsbufwaitcnt = 0
xpagerbufwaitcnt = 0
--- Em oracle_br@yahoogrupos.com.br, "Phael" <[EMAIL PROTECTED]> escreveu
>
> Ola Jemerson,
>
> Ja tive problemas com performance com AIX.
> No meu caso o problema era com um parametro do SO.
> Distrubuição da memória cache.
>
> executa esse arquivo ai:
>
> # /usjr/samples/kernel/vmtune
>
> colo o resultado ai.
>
> Raphael
>
>
>
> - Original Message - 
> From: "Jemerson Dutra" <[EMAIL PROTECTED]>
> To: 
> Sent: Thursday, April 06, 2006 2:35 PM
> Subject: [oracle_br] Re: Performance Horrivel
>
>
> Ae chiappa, da uma ajuda ai.
> Jemerson
> --- Em oracle_br@yahoogrupos.com.br, "Jemerson Dutra" <[EMAIL PROTECTED]>
> escreveu
> >
> > Senhores, estamos com um servidor em producao que foi criado com
> > alguns parametros default por causa de um ERP. Nos deparamos apos
> 35
> > dias, que o servidor esta com uma performance horrivel. Gostaria
da
> > ajuda dos senhores, comentando/incluindo e ou alterando meu
> init.ora.
> > Servidor IBM AIX 5.2
> > 4GB RAM
> > 4GB SWAP
> > 2 CPUS DE 1.2GHZ
> > ORACLE 10GB DE BANCO
> > CRIADO BLOCK_SIZE 4096KB
> > # initMFGPRO.ora - oracle instance parameter file
> > # include database configuration parameters
> > ifile = /Hdados2/admin/MFGPRO/config.MFGPRO
> > open_cursors = 512
> > # NLS Parameters
> >   NLS_LANGUAGE = "AMERICAN"
> >   NLS_TERRITORY = "AMERICA"
> >   NLS_NUMERIC_CHARACTERS = ".,"
> > # tuning parameters
> >   db_files = 200
> >   db_file_multiblock_read_count = 32   # LARGE
> > # --- Autor : Jemerson - Data: 20/02/2006
> > # 
> >   shared_pool_size = 3  ## 4
> > # 
> > sort_area_size = 262144 ## 1048576  #
LARGE
> > sort_area_retained_size = 262144 ##
> 1048576
> > # LARGE
> > large_pool_size = 15500 #25000 #15500 ## 1  #
> > 80MIL   large_pool_size = 614400
> > java_pool_size  = 20971520 ##1
> > # 
> >   log_checkpoint_interval = 1
> >   processes = 450 #500 # 600  #
> LARGE
> >   log_buffer = 2048000 # 1048576 #
LARGE
> >   max_dump_file_size = 10240 # limit trace file size to 5M ea
> >   compatible=9.2.0
> >   UTL_FILE_DIR=*   # if you want to use SQL Loader
> > optimizer_mode = CHOOSE
> > # 
> > # liberado em 19/09/2005
> > CURSOR_SHARING = FORCE ##EXACT ##FORCE
> &g

[oracle_br] Re: Performance Horrivel

[jlchiappa]

Colega, SE isto ainda é importante pra vc, releia aí a minha msg 
anterior e manda a info que é pedida nela (ie, valor dos params, 
workarea_size_policy, sga_max_size), diga EXATAMENTE o que vc mudou 
que obteve aí esses tais 10% de melhoria, e como pedido manda a 
config de rollback/undo e do seu , a distribuição de I/O de modo 
geral, especs do hardware de I/O,  e ajunta com mais info de SO e 
hardware (ie, RAM livre e usada , CPU usada, taxa de uso de swap), 
que a gente pode tentar te ajudar.
 Também seria legal vc fazer e mandar pra lista um testes fora da 
aplicação, tipo : cria uma tabela "pequena", uma tabela "média" e uma 
tabela "grande", faz alguns SQLs diretamente em cima delas, se nem 
isso ir bem a gente suspeita de configs de So e banco e de hardware 
sub-dimensionado...

[]s

  Chiappa

--- Em oracle_br@yahoogrupos.com.br, "Jemerson Dutra" <[EMAIL PROTECTED]> 
escreveu
>
> Meu banco de dados continua horrivel, melhorou cerca de uns 10%. 
> porem acho que nao esta como eu gostaria.
> 
> --- Em oracle_br@yahoogrupos.com.br, "jkdutra" <[EMAIL PROTECTED]> 
> escreveu
> >
> > Srs Meu banco é 9i creio que o awrrpt.sql é somente do 10g ne?
> > Chiappa, O pessoal do E.R.P tinha um init.ora basico e eu acabei 
> > fazendo algumas poucas alteracoes, porem minha experiencia 7 anos 
> é 
> > toda no 8i. e lendo algumas coisas acabei alterando alguns 
> > parametros, tenho autonomia para alterar o que quiser desde que 
> nao 
> > altere as tabelas.
> > Vou estar respondendo os senhores amanha da empresa com calma 
> desde 
> > ja agradeco a colaboração e espero poder contar com os senhores. 
> > Chiappa, Sergio e Raphael Abraços.
> > 
> > --- Em oracle_br@yahoogrupos.com.br, Sergio Leandro Ghellere 
> > <[EMAIL PROTECTED]> escreveu
> > >
> > > Ola Jemerson,
> > > 
> > >é difícil achar encontrar um problema assim...
> > >só pra termos uma idéia, cola o resultado do AWR...
> > >executa no sqlplus.
> > >@$ORACLE_HOME/rdbms/admin/awrrpt.sql
> > > 
> > > pega aí um intervalo de algumas horas... normalmente o AWR 
colhe 
> > estatísticas a cada 
> > > 60min..
> > > 
> > >cola as primeiras 100 linhas só pra termos uma idéia.
> > > 
> > > 
> > > Grande abraço.
> > > 
> > > 
> > > Sergio Leandro Ghellere
> > > DBA Oracle
> > > +55 (41) 9906-4813
> > > 
> > > On Thu Apr  6 15:19 , 'Phael' <[EMAIL PROTECTED]> sent:
> > > 
> > > >Ola Jemerson,
> > > >
> > > >Ja tive problemas com performance com AIX.
> > > >No meu caso o problema era com um parametro do SO.
> > > >Distrubuição da memória cache.
> > > >
> > > >executa esse arquivo ai:
> > > >
> > > ># /usjr/samples/kernel/vmtune
> > > >
> > > >colo o resultado ai.
> > > >
> > > >Raphael
> > > >
> > > >
> > > >
> > > >- Original Message - 
> > > >From: "Jemerson Dutra" [EMAIL PROTECTED]>
> > > >To: oracle_br@yahoogrupos.com.br>
> > > >Sent: Thursday, April 06, 2006 2:35 PM
> > > >Subject: [oracle_br] Re: Performance Horrivel
> > > >
> > > >
> > > >Ae chiappa, da uma ajuda ai.
> > > >Jemerson
> > > >--- Em oracle_br@yahoogrupos.com.br, "Jemerson Dutra" 
> > > >escreveu
> > > >>
> > > >> Senhores, estamos com um servidor em producao que foi criado 
> com
> > > >> alguns parametros default por causa de um ERP. Nos deparamos 
> > apos
> > > >35
> > > >> dias, que o servidor esta com uma performance horrivel. 
> > Gostaria da
> > > >> ajuda dos senhores, comentando/incluindo e ou alterando meu
> > > >init.ora.
> > > >> Servidor IBM AIX 5.2
> > > >> 4GB RAM
> > > >> 4GB SWAP
> > > >> 2 CPUS DE 1.2GHZ
> > > >> ORACLE 10GB DE BANCO
> > > >> CRIADO BLOCK_SIZE 4096KB
> > > >> # initMFGPRO.ora - oracle instance parameter file
> > > >> # include database configuration parameters
> > > >> ifile = /Hdados2/admin/MFGPRO/config.MFGPRO
> > > >> open_cursors = 512
> > > >> # NLS Parameters
> > > >>   NLS_LANGUAGE = "AMERICAN"
> > > >>   NLS_TERRITORY = "AMERICA"
> > > >

[oracle_br] Re: Performance Horrivel

[Jemerson Dutra]

Meu banco de dados continua horrivel, melhorou cerca de uns 10%. 
porem acho que nao esta como eu gostaria.

--- Em oracle_br@yahoogrupos.com.br, "jkdutra" <[EMAIL PROTECTED]> 
escreveu
>
> Srs Meu banco é 9i creio que o awrrpt.sql é somente do 10g ne?
> Chiappa, O pessoal do E.R.P tinha um init.ora basico e eu acabei 
> fazendo algumas poucas alteracoes, porem minha experiencia 7 anos 
é 
> toda no 8i. e lendo algumas coisas acabei alterando alguns 
> parametros, tenho autonomia para alterar o que quiser desde que 
nao 
> altere as tabelas.
> Vou estar respondendo os senhores amanha da empresa com calma 
desde 
> ja agradeco a colaboração e espero poder contar com os senhores. 
> Chiappa, Sergio e Raphael Abraços.
> 
> --- Em oracle_br@yahoogrupos.com.br, Sergio Leandro Ghellere 
> <[EMAIL PROTECTED]> escreveu
> >
> > Ola Jemerson,
> > 
> >é difícil achar encontrar um problema assim...
> >só pra termos uma idéia, cola o resultado do AWR...
> >executa no sqlplus.
> >@$ORACLE_HOME/rdbms/admin/awrrpt.sql
> > 
> > pega aí um intervalo de algumas horas... normalmente o AWR colhe 
> estatísticas a cada 
> > 60min..
> > 
> >cola as primeiras 100 linhas só pra termos uma idéia.
> > 
> > 
> > Grande abraço.
> > 
> > 
> > Sergio Leandro Ghellere
> > DBA Oracle
> > +55 (41) 9906-4813
> > 
> > On Thu Apr  6 15:19 , 'Phael' <[EMAIL PROTECTED]> sent:
> > 
> > >Ola Jemerson,
> > >
> > >Ja tive problemas com performance com AIX.
> > >No meu caso o problema era com um parametro do SO.
> > >Distrubuição da memória cache.
> > >
> > >executa esse arquivo ai:
> > >
> > ># /usjr/samples/kernel/vmtune
> > >
> > >colo o resultado ai.
> > >
> > >Raphael
> > >
> > >
> > >
> > >- Original Message - 
> > >From: "Jemerson Dutra" [EMAIL PROTECTED]>
> > >To: oracle_br@yahoogrupos.com.br>
> > >Sent: Thursday, April 06, 2006 2:35 PM
> > >Subject: [oracle_br] Re: Performance Horrivel
> > >
> > >
> > >Ae chiappa, da uma ajuda ai.
> > >Jemerson
> > >--- Em oracle_br@yahoogrupos.com.br, "Jemerson Dutra" 
> > >escreveu
> > >>
> > >> Senhores, estamos com um servidor em producao que foi criado 
com
> > >> alguns parametros default por causa de um ERP. Nos deparamos 
> apos
> > >35
> > >> dias, que o servidor esta com uma performance horrivel. 
> Gostaria da
> > >> ajuda dos senhores, comentando/incluindo e ou alterando meu
> > >init.ora.
> > >> Servidor IBM AIX 5.2
> > >> 4GB RAM
> > >> 4GB SWAP
> > >> 2 CPUS DE 1.2GHZ
> > >> ORACLE 10GB DE BANCO
> > >> CRIADO BLOCK_SIZE 4096KB
> > >> # initMFGPRO.ora - oracle instance parameter file
> > >> # include database configuration parameters
> > >> ifile = /Hdados2/admin/MFGPRO/config.MFGPRO
> > >> open_cursors = 512
> > >> # NLS Parameters
> > >>   NLS_LANGUAGE = "AMERICAN"
> > >>   NLS_TERRITORY = "AMERICA"
> > >>   NLS_NUMERIC_CHARACTERS = ".,"
> > >> # tuning parameters
> > >>   db_files = 200
> > >>   db_file_multiblock_read_count = 32   # LARGE
> > >> # --- Autor : Jemerson - Data: 20/02/2006
> > >> # 
> > >>   shared_pool_size = 3  ## 4
> > >> # 
> > >> sort_area_size = 262144 ## 1048576  # 
> LARGE
> > >> sort_area_retained_size = 262144 ##
> > >1048576
> > >> # LARGE
> > >> large_pool_size = 15500 #25000 #15500 ## 
1  
> #
> > >> 80MIL   large_pool_size = 614400
> > >> java_pool_size  = 20971520 ##1
> > >> # 
> > >>   log_checkpoint_interval = 1
> > >>   processes = 450 #500 # 600  
#
> > >LARGE
> > >>   log_buffer = 2048000 # 1048576 
# 
> LARGE
> > >>   max_dump_file_size = 10240 # limit trace file size to 5M ea
> > >>   compatible=9.2.0
> > >>   UTL_FILE_DIR=*   # if you want to use SQL Loader
> > >> optimizer_mode = CHOOSE
> > >> # ---

[oracle_br] Re: Performance Horrivel

[Jemerson Dutra]

Raphael, segue o resultado do vmtune

memory_frames = 1048576 
pinnable_frames = 940632  
maxfree = 128 
minfree = 120 
minperm% = 20  
minperm = 19  
maxperm% = 80  
maxperm = 773332  
strict_maxperm = 0   
maxpin% = 80  
maxpin = 838861  
maxclient% = 80  
lrubucket = 131072  
defps = 1   
nokilluid = 0   
numpsblks = 1081344 
npskill = 8448
npswarn = 33792   
v_pinshm = 0   
pta_balance_threshold = 0   
pagecoloring = 0  
framesets = 2  
mempools = 1  
lgpg_size = 0  
lgpg_regions = 0  
num_spec_dataseg = 0  
spec_dataseg_int = 512
memory_affinity = 1  
htabscale = -1 
force_relalias_lite = 0  
relalias_percentage = 0  
data_stagger_interval = 161
large_page_heap_size = 0  
kernel_heap_psize = 4096   
soft_min_lgpgs_vmpool = 0  
vmm_fork_policy = 0  
low_ps_handling = 1  
mbuf_heap_psize = 4096   
strict_maxclient = 1  
cpu_scale_memp = 8  
lru_poll_interval = 0  
lru_file_repage = 1  
memory_frames = 1048576
minpgahead = 2  
memory_frames = 1048576   
minpgahead = 2 
maxpgahead = 8 
pd_npages = 65536 
maxrandwrt = 0 
numclust = 1 
numfsbufs = 196   
sync_release_ilock = 0 
lvm_bufcnt = 9 
j2_minPageReadAhead = 2 
j2_maxPageReadAhead = 128   
j2_nBufferPerPagerDevice = 512   
j2_nPagesPerWriteBehindCluster = 32
j2_maxRandomWrite = 0 
j2_nRandomCluster = 0 
j2_non_fatal_crashes_system = 0 
j2_syncModifiedMapped = 1 
jfs_clread_enabled = 0 
jfs_use_read_lock = 1 
hd_pvs_opn = 6 
hd_pbuf_cnt = 1280  
j2_inodeCacheSize = 400   
j2_metadataCacheSize = 400   
 j2_dynamicBufferPreallocation = 16
 j2_maxUsableMaxTransfer = 512 
pgahd_scale_thresh = 0   
hd_pendqblked = 0   
psbufwaitcnt = 347632  
fsbufwaitcnt = 1541572 
rfsbufwaitcnt = 0   
xpagerbufwaitcnt = 0   
--- Em oracle_br@yahoogrupos.com.br, "Phael" <[EMAIL PROTECTED]> escreveu
>
> Ola Jemerson,
> 
> Ja tive problemas com performance com AIX.
> No meu caso o problema era com um parametro do SO.
> Distrubuição da memória cache.
> 
> executa esse arquivo ai:
> 
> # /usjr/samples/kernel/vmtune
> 
> colo o resultado ai.
> 
> Raphael
> 
> 
> 
> - Original Message - 
> From: "Jemerson Dutra" <[EMAIL PROTECTED]>
> To: 
> Sent: Thursday, April 06, 2006 2:35 PM
> Subject: [oracle_br] Re: Performance Horrivel
> 
> 
> Ae chiappa, da uma ajuda ai.
> Jemerson
> --- Em oracle_br@yahoogrupos.com.br, "Jemerson Dutra" <[EMAIL PROTECTED]>
> escreveu
> >
> > Senhores, estamos com um servidor em producao que foi criado com
> > alguns parametros default por causa de um ERP. Nos deparamos apos
> 35
> > dias, que o servidor esta com uma performance horrivel. Gostaria 
da
> > ajuda dos senhores, comentando/incluindo e ou alterando meu
> init.ora.
> > Servidor IBM AIX 5.2
> > 4GB RAM
> > 4GB SWAP
> > 2 CPUS DE 1.2GHZ
> > ORACLE 10GB DE BANCO
> > CRIADO BLOCK_SIZE 4096KB
> > # initMFGPRO.ora - oracle instance parameter file
> > # include database configuration parameters
> > ifile = /Hdados2/admin/MFGPRO/config.MFGPRO
> > open_cursors = 512
> > # NLS Parameters
> >   NLS_LANGUAGE = "AMERICAN"
> >   NLS_TERRITORY = "AMERICA"
> >   NLS_NUMERIC_CHARACTERS = ".,"
> > # tuning parameters
> >   db_files = 200
> >   db_file_multiblock_read_count = 32   # LARGE
> > # --- Autor : Jemerson - Data: 20/02/2006
> > # 
> >   shared_pool_size = 3  ## 4
> > # 
> > sort_area_size = 262144 ## 1048576  # 
LARGE
> > sort_area_retained_size = 262144 ##
> 1048576
> > # LARGE
> > large_pool_size = 15500 #25000 #15500 ## 1  #
> > 80MIL   large_pool_size = 614400
> > java_pool_size  = 20971520 ##1
> > # 
> >   log_checkpoint_interval = 1
> >   processes = 450 #500 # 600  #
> LARGE
> >   log_buffer = 2048000 # 1048576 # 
LARGE
> >   max_dump_file_size = 10240 # limit trace file size to 5M ea
> >   compatible=9.2.0
> >   UTL_FILE_DIR=*   # if you want to use SQL Loader
> > optimizer_mode = CHOOSE
> > # -

[oracle_br] Re: Performance Horrivel

[jkdutra]

Srs Meu banco é 9i creio que o awrrpt.sql é somente do 10g ne?
Chiappa, O pessoal do E.R.P tinha um init.ora basico e eu acabei 
fazendo algumas poucas alteracoes, porem minha experiencia 7 anos é 
toda no 8i. e lendo algumas coisas acabei alterando alguns 
parametros, tenho autonomia para alterar o que quiser desde que nao 
altere as tabelas.
Vou estar respondendo os senhores amanha da empresa com calma desde 
ja agradeco a colaboração e espero poder contar com os senhores. 
Chiappa, Sergio e Raphael Abraços.

--- Em oracle_br@yahoogrupos.com.br, Sergio Leandro Ghellere 
<[EMAIL PROTECTED]> escreveu
>
> Ola Jemerson,
> 
>é difícil achar encontrar um problema assim...
>só pra termos uma idéia, cola o resultado do AWR...
>executa no sqlplus.
>@$ORACLE_HOME/rdbms/admin/awrrpt.sql
> 
> pega aí um intervalo de algumas horas... normalmente o AWR colhe 
estatísticas a cada 
> 60min..
> 
>cola as primeiras 100 linhas só pra termos uma idéia.
> 
> 
> Grande abraço.
> 
> 
> Sergio Leandro Ghellere
> DBA Oracle
> +55 (41) 9906-4813
> 
> On Thu Apr  6 15:19 , 'Phael' <[EMAIL PROTECTED]> sent:
> 
> >Ola Jemerson,
> >
> >Ja tive problemas com performance com AIX.
> >No meu caso o problema era com um parametro do SO.
> >Distrubuição da memória cache.
> >
> >executa esse arquivo ai:
> >
> ># /usjr/samples/kernel/vmtune
> >
> >colo o resultado ai.
> >
> >Raphael
> >
> >
> >
> >- Original Message - 
> >From: "Jemerson Dutra" [EMAIL PROTECTED]>
> >To: oracle_br@yahoogrupos.com.br>
> >Sent: Thursday, April 06, 2006 2:35 PM
> >Subject: [oracle_br] Re: Performance Horrivel
> >
> >
> >Ae chiappa, da uma ajuda ai.
> >Jemerson
> >--- Em oracle_br@yahoogrupos.com.br, "Jemerson Dutra" 
> >escreveu
> >>
> >> Senhores, estamos com um servidor em producao que foi criado com
> >> alguns parametros default por causa de um ERP. Nos deparamos 
apos
> >35
> >> dias, que o servidor esta com uma performance horrivel. 
Gostaria da
> >> ajuda dos senhores, comentando/incluindo e ou alterando meu
> >init.ora.
> >> Servidor IBM AIX 5.2
> >> 4GB RAM
> >> 4GB SWAP
> >> 2 CPUS DE 1.2GHZ
> >> ORACLE 10GB DE BANCO
> >> CRIADO BLOCK_SIZE 4096KB
> >> # initMFGPRO.ora - oracle instance parameter file
> >> # include database configuration parameters
> >> ifile = /Hdados2/admin/MFGPRO/config.MFGPRO
> >> open_cursors = 512
> >> # NLS Parameters
> >>   NLS_LANGUAGE = "AMERICAN"
> >>   NLS_TERRITORY = "AMERICA"
> >>   NLS_NUMERIC_CHARACTERS = ".,"
> >> # tuning parameters
> >>   db_files = 200
> >>   db_file_multiblock_read_count = 32   # LARGE
> >> # --- Autor : Jemerson - Data: 20/02/2006
> >> # 
> >>   shared_pool_size = 3  ## 4
> >> # 
> >> sort_area_size = 262144 ## 1048576  # 
LARGE
> >> sort_area_retained_size = 262144 ##
> >1048576
> >> # LARGE
> >> large_pool_size = 15500 #25000 #15500 ## 1  
#
> >> 80MIL   large_pool_size = 614400
> >> java_pool_size  = 20971520 ##1
> >> # 
> >>   log_checkpoint_interval = 1
> >>   processes = 450 #500 # 600  #
> >LARGE
> >>   log_buffer = 2048000 # 1048576 # 
LARGE
> >>   max_dump_file_size = 10240 # limit trace file size to 5M ea
> >>   compatible=9.2.0
> >>   UTL_FILE_DIR=*   # if you want to use SQL Loader
> >> optimizer_mode = CHOOSE
> >> # 
> >> # liberado em 19/09/2005
> >> CURSOR_SHARING = FORCE ##EXACT ##FORCE
> >> # 
> >> dispatchers="(PROTOCOL=TCP) (dispatchers=20)"
> >> service_names= MFGPRO
> >> instance_name= MFGPRO
> >> # 
> >> # melhoria no servicos MTS 10/10/2005
> >> # Autor: Jemerson Dutra
> >> mts_max_servers=100
> >> mts_servers=40
> >> mts_max_dispatchers=40
> >> O7_DICTIONARY_ACCESSIBILITY=TRUE
> >> GLOBAL_NAMES = TRUE
> >> dml_locks = 3408# LARGE
> >> open_links = 4
> >> sort_multiblock_read_count = 4
> &g

[oracle_br] Re: Performance Horrivel

[jlchiappa]

jemerson, além do ponto de config de SO, vamos ver se consigo te 
ajudar dando umas sugestões de config , mas antes delas porém observo 
que :

a) o seu param compatible=9.2.0 indica banco 9i, MAS o default do 9i 
é um spfile, e vc está mostrando um initfile, vc TEM CERTEZA que é 
esse init mesmo que o banco está usando ?? Outra coisa, o param 
sort_multiblock_read_count só existia no 8i, no 9i ele passou a ser 
_sort_multiblock_read_count , com um "_" , o que ele está fazendo aí 
sem o "_" ??? Já DB_CACHE_SIZE parece indicar 9i, afinal, é 8i ou 
9i ???

b) já que é uma aplicação de terceiros, vc TERÁ QUE "pedir a benção" 
deles pra qquer alterações, a não ser que eles não tenham nenhuma 
exigência a nível de banco (raro, mas já vi alguns casos assim)

c) o que eu vou dar é uma distribuição GENÉRICA, dicas o mais 
genéricas possíveis, só mesmo um dba experiente, estando no local e 
vivenciando o sistema, é que pode fazer um tunning direito

d) e o mais importante, performance ** não ** começa e acaba só 
alterando params de banco, isso é o trabalho mais "GROSSO" de 
performance, vc vai tentar garantir que não há má-distribuição dos 
recursos já presentes, mas via de regra isso é insuficiente


==> isso posto : SUPONDO banco 9i, cadê o param workarea_size_policy, 
ele é vital pra se dizer se o teu  sort_area_size = 262144 , que é 
ridiculamente pequeno (250 Kb é coisa de palmtop!!) , está sendo 
usado ou não. E o sga_max_size, como está ?
 Quanto aos demais params (SE é mesmo esses que vc está usando) :
  
 - DB_CACHE_SIZE = 17825792 (coisa de 17 Mb) : extremamente pequeno , 
subir issp pra casa de algumas poucas centenas de M
 - large_pool_size = 15500 (coisa de 150 Mb) : isso só é util *** 
SE *** vc está usando SQL paralelo, RMAN  ou features extras, é o 
caso ??
 - shared_pool_size = 3 (cerca de 300 Mb) : em vista da 
qtdade de RAM, e sendo sistema ERP que provavelmente deve fazer 
bastante massagem de dados em PL/SQL, não é desproporcionado
 -  session_cached_cursors=100 : valor inicial pra testes, se preciso 
depois pode subir aos poucos
 - timed_statistics = false; : sugiro botar pra true (se for 9i, 
junto com statistics_level=TYPICAL ao menos), o overhead é mínimo e 
as infos que esses caras nos dão são muitas vezes CRUCIAIS no tunning
 
 - log_checkpoint_interval = 1 : valor extremamente pequeno SE vc 
estiver configurando o seu log de modo que haja menos log file 
switches , manda aí a config dos seus logs (ie, qtdade de arqs, 
distribuição nos grupos, tamanhos, demais params de log), que a gente 
pode palpitar mais.
 ==> falando em arquivos de estrutura, se vc mandar a confoguração do 
seu rollback e do seu temp (ie, quantos arqs são, de que tamanho, 
onde estão, storage deles), e a distribuição de I/O de modo geral 
(ie, quantos e quais discos/volumes/filesystems/controladoras, se há 
vários arqs de tipos diferentes no mesmo filesystem/grupo atenddidos 
pela mesma controladora, ou ao menos dados gerais se for RAID) 
podemos palpitar também.
 
 []s
 
  Chiappa
  
--- Em oracle_br@yahoogrupos.com.br, "Phael" <[EMAIL PROTECTED]> escreveu
>
> Ola Jemerson,
> 
> Ja tive problemas com performance com AIX.
> No meu caso o problema era com um parametro do SO.
> Distrubuição da memória cache.
> 
> executa esse arquivo ai:
> 
> # /usjr/samples/kernel/vmtune
> 
> colo o resultado ai.
> 
> Raphael
> 
> 
> 
> - Original Message - 
> From: "Jemerson Dutra" <[EMAIL PROTECTED]>
> To: 
> Sent: Thursday, April 06, 2006 2:35 PM
> Subject: [oracle_br] Re: Performance Horrivel
> 
> 
> Ae chiappa, da uma ajuda ai.
> Jemerson
> --- Em oracle_br@yahoogrupos.com.br, "Jemerson Dutra" <[EMAIL PROTECTED]>
> escreveu
> >
> > Senhores, estamos com um servidor em producao que foi criado com
> > alguns parametros default por causa de um ERP. Nos deparamos apos
> 35
> > dias, que o servidor esta com uma performance horrivel. Gostaria 
da
> > ajuda dos senhores, comentando/incluindo e ou alterando meu
> init.ora.
> > Servidor IBM AIX 5.2
> > 4GB RAM
> > 4GB SWAP
> > 2 CPUS DE 1.2GHZ
> > ORACLE 10GB DE BANCO
> > CRIADO BLOCK_SIZE 4096KB
> > # initMFGPRO.ora - oracle instance parameter file
> > # include database configuration parameters
> > ifile = /Hdados2/admin/MFGPRO/config.MFGPRO
> > open_cursors = 512
> > # NLS Parameters
> >   NLS_LANGUAGE = "AMERICAN"
> >   NLS_TERRITORY = "AMERICA"
> >   NLS_NUMERIC_CHARACTERS = ".,"
> > # tuning parameters
> >   db_files = 200
> >   db_file_multiblock_read_count = 32   # LARGE
> > # --- Autor : Jemerson - Data: 20/02/2006
> > # 
> >   shared_poo

Re: [oracle_br] Re: Performance Horrivel

[Sergio Leandro Ghellere]

Ola Jemerson,

   é difícil achar encontrar um problema assim...
   só pra termos uma idéia, cola o resultado do AWR...
   executa no sqlplus.
   @$ORACLE_HOME/rdbms/admin/awrrpt.sql

pega aí um intervalo de algumas horas... normalmente o AWR colhe estatísticas a 
cada 
60min..

   cola as primeiras 100 linhas só pra termos uma idéia.


Grande abraço.


Sergio Leandro Ghellere
DBA Oracle
+55 (41) 9906-4813

On Thu Apr  6 15:19 , 'Phael' <[EMAIL PROTECTED]> sent:

>Ola Jemerson,
>
>Ja tive problemas com performance com AIX.
>No meu caso o problema era com um parametro do SO.
>Distrubuição da memória cache.
>
>executa esse arquivo ai:
>
># /usjr/samples/kernel/vmtune
>
>colo o resultado ai.
>
>Raphael
>
>
>
>- Original Message - 
>From: "Jemerson Dutra" [EMAIL PROTECTED]>
>To: oracle_br@yahoogrupos.com.br>
>Sent: Thursday, April 06, 2006 2:35 PM
>Subject: [oracle_br] Re: Performance Horrivel
>
>
>Ae chiappa, da uma ajuda ai.
>Jemerson
>--- Em oracle_br@yahoogrupos.com.br, "Jemerson Dutra" 
>escreveu
>>
>> Senhores, estamos com um servidor em producao que foi criado com
>> alguns parametros default por causa de um ERP. Nos deparamos apos
>35
>> dias, que o servidor esta com uma performance horrivel. Gostaria da
>> ajuda dos senhores, comentando/incluindo e ou alterando meu
>init.ora.
>> Servidor IBM AIX 5.2
>> 4GB RAM
>> 4GB SWAP
>> 2 CPUS DE 1.2GHZ
>> ORACLE 10GB DE BANCO
>> CRIADO BLOCK_SIZE 4096KB
>> # initMFGPRO.ora - oracle instance parameter file
>> # include database configuration parameters
>> ifile = /Hdados2/admin/MFGPRO/config.MFGPRO
>> open_cursors = 512
>> # NLS Parameters
>>   NLS_LANGUAGE = "AMERICAN"
>>   NLS_TERRITORY = "AMERICA"
>>   NLS_NUMERIC_CHARACTERS = ".,"
>> # tuning parameters
>>   db_files = 200
>>   db_file_multiblock_read_count = 32   # LARGE
>> # --- Autor : Jemerson - Data: 20/02/2006
>> # 
>>   shared_pool_size = 3  ## 4
>> # 
>> sort_area_size = 262144 ## 1048576  # LARGE
>> sort_area_retained_size = 262144 ##
>1048576
>> # LARGE
>> large_pool_size = 15500 #25000 #15500 ## 1  #
>> 80MIL   large_pool_size = 614400
>> java_pool_size  = 20971520 ##1
>> # 
>>   log_checkpoint_interval = 1
>>   processes = 450 #500 # 600  #
>LARGE
>>   log_buffer = 2048000 # 1048576 # LARGE
>>   max_dump_file_size = 10240 # limit trace file size to 5M ea
>>   compatible=9.2.0
>>   UTL_FILE_DIR=*   # if you want to use SQL Loader
>> optimizer_mode = CHOOSE
>> # 
>> # liberado em 19/09/2005
>> CURSOR_SHARING = FORCE ##EXACT ##FORCE
>> # 
>> dispatchers="(PROTOCOL=TCP) (dispatchers=20)"
>> service_names= MFGPRO
>> instance_name= MFGPRO
>> # 
>> # melhoria no servicos MTS 10/10/2005
>> # Autor: Jemerson Dutra
>> mts_max_servers=100
>> mts_servers=40
>> mts_max_dispatchers=40
>> O7_DICTIONARY_ACCESSIBILITY=TRUE
>> GLOBAL_NAMES = TRUE
>> dml_locks = 3408# LARGE
>> open_links = 4
>> sort_multiblock_read_count = 4
>> dbwr_io_slaves = 2
>> DB_WRITER_PROCESSES = 2
>> DB_CACHE_SIZE = 17825792
>> session_cached_cursors=100
>> timed_statistics = false;
>>
>
>
>
>
>
>
>--

>Atenção! As mensagens deste grupo são de acesso público e de inteira 
>responsabilidade de seus remetentes.
>Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/
>--

__
>
>Este Grupo recebe o apoio da SQL Magazine - www.devmedia.com.br/sqlmagazine
>__
>O grupo Oracle_br não aceita anexos. Quando oferecer algum arquivo, tenha o 
>link do mesmo para evitar trafego(pedidos) desnecessário.
>Links do Yahoo! Grupos
>
>
>
>
>
>
>
>
>
>
>--
--