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
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
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
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
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
[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
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,
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,
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
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,
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 - é
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
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
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
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
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
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
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,
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
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
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
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
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
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
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 :
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
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
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
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
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 é
--- 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
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
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 -
:* 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
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
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
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
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.
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)
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
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 é
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
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
]
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
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,
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
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
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,
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
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
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,
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
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
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
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
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
Thiago,
Incremente o parametro db_cache_size para utilizar mais memória
Marcos Campos
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
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
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
--- 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
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
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
-
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
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
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
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
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
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
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 %
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,
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
/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
:
# /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
+ 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
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
.
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
: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
- 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
: [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
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
% = 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
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
-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
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
.
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
]
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
:
# /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
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
]
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
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
** 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
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
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
94 matches
Mail list logo
