[oracle_br] Re: Performance do ODA virtualizado
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
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
[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
RES: [oracle_br] Re: performance em função
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
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 ?? Plz detalhes []s Chiappa
RES: RES: [oracle_br] Re: performance em função
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 ?? Plz detalhes
[]s
Chiappa
[oracle_br] Re: Performance pacotes dbms ????
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
[oracle_br] Re: Performance
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
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 da maquina irá depender do tamanho do datafile ?
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 rstoever@... 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 tamanho do
[oracle_br] Re: Performance da maquina irá depender do tamanho do datafile ?
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 jlchiappa@... 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.br, Rafael Stoever rstoever@ escreveu Boa tarde a todos,
Re: [oracle_br] Re: Performance da maquina irá depender do tamanho do datafile ?
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 jlchia...@yahoo.com.brescreveu: ** 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 jlchiappa@... 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
Re: [oracle_br] Re: Performance índice PK String x Number
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 jlchia...@yahoo.com.br 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 djnmello@... 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
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 djnmello@... 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
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 jlchiappa@...
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 neto.longhi@ escreveu
Vlw pessoal
ja mudei a compressão pra BASIC, aparentemente esta mas rapido mesmo.
Vlw
--- Em oracle_br@yahoogrupos.com.br, Wadson Ramon wramon@ 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 vitorjr81@escreveu:
Experimentou usar compressed?
Em 16/02/2013 14:09, netodba neto.longhi@ 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
[oracle_br] Re: Performance RMAN
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 neto.longhi@... 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 jlchiappa@ 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ó
[oracle_br] Re: Performance RMAN
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 neto.longhi@... escreveu
Vlw pessoal
ja mudei a compressão pra BASIC, aparentemente esta mas rapido mesmo.
Vlw
--- Em oracle_br@yahoogrupos.com.br, Wadson Ramon wramon@ 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 vitorjr81@escreveu:
Experimentou usar compressed?
Em 16/02/2013 14:09, netodba neto.longhi@ 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
[oracle_br] Re: Performance RMAN
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 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 neto.longhi@ escreveu Vlw pessoal ja mudei a compressão pra BASIC, aparentemente esta mas rapido mesmo. Vlw --- Em oracle_br@yahoogrupos.com.br, Wadson Ramon wramon@ 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 vitorjr81@escreveu: Experimentou usar compressed? Em 16/02/2013 14:09, netodba neto.longhi@ 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';
Re: [oracle_br] Re: Performance RMAN
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 ederson200...@yahoo.com.br:
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 neto.longhi@... escreveu
Vlw pessoal
ja mudei a compressão pra BASIC, aparentemente esta mas rapido mesmo.
Vlw
--- Em oracle_br@yahoogrupos.com.br, Wadson Ramon wramon@ 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 vitorjr81@escreveu:
Experimentou usar compressed?
Em 16/02/2013 14:09, netodba neto.longhi@ 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
[oracle_br] Re: Performance RMAN
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 ivanrs79@... 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 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 neto.longhi@ escreveu Vlw pessoal ja mudei a compressão pra BASIC, aparentemente esta mas rapido mesmo. Vlw --- Em oracle_br@yahoogrupos.com.br, Wadson Ramon wramon@ 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 vitorjr81@escreveu: Experimentou usar compressed? Em 16/02/2013 14:09, netodba
[oracle_br] Re: Performance RMAN
Hmm blzz pensava que era no maximo 2 com 1 processador. Vlw =) --- Em oracle_br@yahoogrupos.com.br, Ivan Ricardo Schuster ivanrs79@... 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 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 neto.longhi@ escreveu Vlw pessoal ja mudei a compressão pra BASIC, aparentemente esta mas rapido mesmo. Vlw --- Em oracle_br@yahoogrupos.com.br, Wadson Ramon wramon@ 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 vitorjr81@escreveu: Experimentou usar compressed? Em 16/02/2013 14:09, netodba neto.longhi@ 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
[oracle_br] Re: Performance RMAN
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 neto.longhi@... escreveu
Vlw pessoal
ja mudei a compressão pra BASIC, aparentemente esta mas rapido mesmo.
Vlw
--- Em oracle_br@yahoogrupos.com.br, Wadson Ramon wramon@ 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 vitorjr81@escreveu:
Experimentou usar compressed?
Em 16/02/2013 14:09, netodba neto.longhi@ 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;
[oracle_br] Re: Performance RMAN
Opa Wadson vlw pela resposta.
qual seria o parametro pra mudar?
--- Em oracle_br@yahoogrupos.com.br, Wadson Ramon wramon@... 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 neto.longhi@...
**
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 RMAN
Vlw pessoal
ja mudei a compressão pra BASIC, aparentemente esta mas rapido mesmo.
Vlw
--- Em oracle_br@yahoogrupos.com.br, Wadson Ramon wramon@... 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 vitorjr81@...escreveu:
Experimentou usar compressed?
Em 16/02/2013 14:09, netodba neto.longhi@... 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/
Links do Yahoo! Grupos
[As partes desta mensagem que não continham texto foram removidas]
[oracle_br] Re: performance query
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
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 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
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 jlchiappa@... 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 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 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, Rosivaldo Ramalho rosiva...@... 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 francisco.porfi...@...: 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
RE: [oracle_br] Re: Performance IS NULL
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 rosiva...@... 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 francisco.porfi...@...: 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 com Synonym Privados
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 fontana.mar...@... 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 francisco.porfi...@... 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
--- Em oracle_br@yahoogrupos.com.br, gibajr gib...@... 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
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 gib...@... 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
[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, Yahoo_Jefferson jefferson_s...@... 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 e Tunning
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 brunomaximom...@hotmail.com *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 jefferson_s...@... 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
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 oracle_br%40yahoogrupos.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]
[oracle_br] Re: Performance dos relatorios-ajuda
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
[oracle_br] Re: Performance dos relatorios-ajuda
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
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]
Re: [oracle_br] Re: Performance dos relatorios-ajuda
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]
Re: [oracle_br] Re: Performance dos relatorios-ajuda
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]
Res: [oracle_br] Re: Performance COBOL x ORACLE 10G
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 servidornbsp; 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
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 servidornbsp; 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
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)
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 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
[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 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,
[oracle_br] Re: Performance ( Insert Select via dblink)
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 PROTECTED] pr INNER JOIN [EMAIL PROTECTED] pj ON pj.IDPrinter = pr.IDPrinter INNER JOIN [EMAIL PROTECTED] pa ON pa.IDPAApp = pj.IDPAApp INNER JOIN [EMAIL PROTECTED] ac ON ac.IDAccount = pj.IDAccount INNER JOIN [EMAIL PROTECTED] ps ON ps.IDPAPaperSize = pj.IDPAPaperSize
[oracle_br] Re: Performance Oracle 9i - Podem me ajudar?
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]:SQLset timing on [EMAIL PROTECTED]:SQLselect * 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
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 oracle_br%40yahoogrupos.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
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
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
[oracle_br] Re: Performance no Oracle com SQL ANSI
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]andre.psantos.ti%40gmail.com 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] mralisson%40gmail.commralisson%40gmail.com 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 ao utilizar um ou outro padrão? Abraco, Alisson [As partes desta mensagem que não continham texto foram removidas]
Re: [oracle_br] Re: Performance no Oracle com SQL ANSI
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 oracle_br%40yahoogrupos.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]andre.psantos.ti%40gmail.com 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] mralisson%40gmail.commralisson%40gmail.com 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
[oracle_br] Re: Performance no Oracle com SQL ANSI
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 oracle_br%40yahoogrupos.com.br, Andre Santos andre.psantos.ti@ 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 mralisson@ 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 andre.psantos.ti@andre.psantos.ti%40gmail.com 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
Re: [oracle_br] Re: Performance do banco de dados!
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 mailto:oracle_br%40yahoogrupos.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 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/ 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!
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 mailto:oracle_br%40yahoogrupos.com.br, Thiago Lazzarotto 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 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/ 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!
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 mailto:oracle_br%40yahoogrupos.com.br, Thiago Lazzarotto 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
[oracle_br] Re: Performance do banco de dados!
Thiago, Incremente o parametro db_cache_size para utilizar mais memória Marcos Campos
[oracle_br] Re: Performance do banco de dados!
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]
Re: [oracle_br] Re: Performance do banco de dados!
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 mailto:oracle_br%40yahoogrupos.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]
Re: [oracle_br] Re: Performance do banco de dados!
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 mailto:oracle_br%40yahoogrupos.com.br mailto:oracle_br%40yahoogrupos.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 desta mensagem que não continham texto foram removidas]
[oracle_br] Re: Performance do banco de dados!
--- 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
[oracle_br] Re: Performance do Banco
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_create_file_dest db_create_online_log_dest_1 db_create_online_log_dest_2 db_create_online_log_dest_3
[oracle_br] Re: Performance em Insert
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 em Insert
*** 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]
Re: [oracle_br] Re: Performance de máquina
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
[oracle_br] Re: Performance de Query
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/2006/02/practical-learning-oracle.html [As partes desta mensagem que não continham texto foram removidas] -- Atenção! As
[oracle_br] Re: Performance de Query
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
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
Re: [oracle_br] Re: Performance de Query
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/ __ 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:
[oracle_br] Re: Performance de Query
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 máquina
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
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
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. 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
Re: [oracle_br] Re: Performance Horrivel
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. 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
[oracle_br] Re: Performance Horrivel
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: oracle_br@yahoogrupos.com.br 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: oracle_br@yahoogrupos.com.br 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: oracle_br@yahoogrupos.com.br 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: oracle_br@yahoogrupos.com.br 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
[oracle_br] Re: Performance Horrivel
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 --- -- -- -- -- - -- Atenção! As mensagens deste grupo são de acesso público e de inteira responsabilidade de seus remetentes. Acesse: http
Re: [oracle_br] Re: Performance Horrivel
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: oracle_br@yahoogrupos.com.br 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. The optimal value may be different for different databases on the same system, so keep this in mind when tuning the VMM and choose values 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
Re: [oracle_br] Re: Performance Horrivel
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: oracle_br@yahoogrupos.com.br 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. The optimal value may be different for different databases on the same system, so keep this in mind when tuning the VMM and choose values 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
[oracle_br] Re: Performance Horrivel
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: oracle_br@yahoogrupos.com.br 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
[oracle_br] Re: Performance Horrivel
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 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
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: oracle_br@yahoogrupos.com.br 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: 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 [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 # 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
Re: [oracle_br] Re: Performance Horrivel
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: oracle_br@yahoogrupos.com.br 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: oracle_br@yahoogrupos.com.br 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: 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 [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 # dispatchers=(PROTOCOL=TCP) (dispatchers=20) service_names= MFGPRO instance_name= MFGPRO
[oracle_br] Re: Performance Horrivel
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. 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
[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: oracle_br@yahoogrupos.com.br 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: oracle_br@yahoogrupos.com.br 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: 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 [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
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: oracle_br@yahoogrupos.com.br 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: oracle_br@yahoogrupos.com.br 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: oracle_br@yahoogrupos.com.br 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: 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 [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
[oracle_br] Re: Performance Horrivel
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 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
Re: [oracle_br] Re: Performance Horrivel
. 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: oracle_br@yahoogrupos.com.br 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: oracle_br@yahoogrupos.com.br 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: oracle_br@yahoogrupos.com.br 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: oracle_br@yahoogrupos.com.br 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
[oracle_br] Re: Performance Horrivel
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 # # 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] 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 # 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 * 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 Horrivel
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 [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 # 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 -- 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: http://br.yahoo.com/info/utos.html
Re: [oracle_br] Re: Performance Horrivel
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 -- 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
[oracle_br] Re: Performance
** Provavelmente ** deve ter a ver com os params view-merge e com as
estatísticas ou falta dela (algumas sub-queries podem ser processadas
como se fossem views) - pra gente poder tentar reproduzir e dizer
algo mais a respeito, nos diga : versão EXATA do banco, se for 9i ou
superior o valor dos params _complex_view_merging ,
_project_view_columns e _push_join_union_view , o texto do SQL e um
script de criação das tabelas e de alguns dados (se vc puder mandar
uma versão resumida disso mas onde ainda ocorra o comportamento,
melhor ainda).
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, Genivaldo Silva [EMAIL PROTECTED]
escreveu
Me desculpe a insistência. Mas me ajudem no por que da diferença de
performance:
Query lenta:
Select tab1.campo1
tab2.campo1
From tab2,
tab1
Where tab1.data = to_date('data qualquer','dd/mm/')
And tab2.campo1 = tab1.campo1;
Query rápida:
Select tab1.campo 1
,(Select tab2.campo1
From tab2
Where tab2.campo1 = tab1.campo1)
From tab1
Where tab1.data = to_date('data qualquer','dd/mm/');
Grato,
Genivaldo
[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
__
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 com o Connect BY !!!
Valeu pela dica Thiago. Já vai ajudar. Carlos Alberto [EMAIL PROTECTED] --- Em oracle_br@yahoogrupos.com.br, Thiago Lazzarotto [EMAIL PROTECTED] escreveu Faz assim: Select b.campos From (select a.campos from tabela a where a.campo = :x) b Connect by b.filho = prior b.pai Vc tem que colocar um subselect no from, pois o connect by é executado antes do where... Thiago. zalbertos escreveu: Bom Dia Pessoal, Estou com um problema em um processo e o gargalo está na seguinte query : SELECT DTPAI.EFFECTIVITY_DATE, DTPAI.DISABLE_DATE FROM CUM.CUM_FRCT_BOM_EXPLOD DTPAI WHERE ORGANIZATION_ID = :b1 AND SHOP_ORDER = :b2 CONNECT BY DTPAI.PART_NUMBER_FILHO = PRIOR DTPAI.PART_NUMBER_PAI START WITH DTPAI.COMPONENT_SEQUENCE_ID = :b3 ORDER BY DTPAI.SORT_CODE DESC Estou com a liberdade para criar o melhor indice nessa tabela, já fiz algumas tentativas mas o gargalo continua acontecendo ... alguém tem alguma idéia do que pode ser feito para melhorar a performance dessa query, a versão do banco aqui é 8.1.7.3. Vejam as tentativas de indices que criei : Create Index Cum.Cum_Frct_Bom_Explod_idx2 on Cum.Cum_Frct_Bom_Explod (organization_id, shop_order) / Create Index Cum.Cum_Frct_Bom_Explod_idx3 on Cum.Cum_Frct_Bom_Explod (component_sequence_id) / Create Index Cum.Cum_Frct_Bom_Explod_idx4 on Cum.Cum_Frct_Bom_Explod (part_number_pai) / Create Index Cum.Cum_Frct_Bom_Explod_idx5 on Cum.Cum_Frct_Bom_Explod (part_number_filho) / Desde já agradeço Obrigado. Carlos Alberto [EMAIL PROTECTED] - - 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/ - - _ Area de download do grupo - http://www.4shared.com/dir/101727/a4dcc423 *Yahoo! Grupos, um serviço oferecido por:* PUBLICIDADE - --- *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] mailto:[EMAIL PROTECTED] subject=Unsubscribe * O uso que você faz do Yahoo! Grupos está sujeito aos Termos do Serviço do Yahoo! http://br.yahoo.com/info/utos.html. -- Thiago Lazzarotto da Costa Database Administrator / TI Sistemas Áreas Atendidas: Tecnologia / Projetos Especiais STEMAC S/A GRUPOS GERADORES Fone: (51) 3358-3800 ramal 2711 e-mail: [EMAIL PROTECTED] -- 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/ --_ Area de download do grupo - http://www.4shared.com/dir/101727/a4dcc423 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 Oracle x RM Labore
Nós usamos o RM. Banco 8.1.7.4. SO: HP-UX Funcionários da empresa? 1500 Eventos: 559 Tempo de cálculo: 40-45 minutos --- Em oracle_br@yahoogrupos.com.br, Emerson Martins [EMAIL PROTECTED] escreveu PessoALL, Alguém do grupo de discussão trabalha com o sistema de folha de pagamento RMLabore da RM ? Se afirmativo, gostaria de obter algumas informações sobre o ambiente, exemplo: Versão do Oracle + patcheSet SO Número de funcionários Número de eventos cadastrados no RMLabore Tempo para calcula da Folha Qualquer informação será muito bem vinda. Obrigado. EMERSON [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/ --_ Area de download do grupo - http://www.4shared.com/dir/101727/a4dcc423 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
