Menu de navegação

[mpvargasParticipante]

Qual o parâmetro do Oracle que mostra quantas tabelas eu posso colocar em paralelismo? Ou como o Oracle gerencia a quantidade de paralelismo…

[IshiiParticipante]

Olá,

Existe uma atributo na all_tables chamado degree que configura o paralelismo. Mas sempre será necessário uma alteração nas queries para que isso funcione bem. Veja a Documentação:

http://download.oracle.com/docs/cd/B19306_01/server.102/b14223/usingpe.htm#sthref2217

E verifique também os parametros de inicialização:

SQL>show parameter parallel

Para a sua configuração.

[]s Ishii
ps. A performance do DB ainda continua lenta?

[mpvargasParticipante]

Caro Amigo, … mais uma vez, obrigado pela dica.
Vamos aos fatos…
Como eu falei anteriormente, tínhamos uma máquina que ficava com o hdisk0 100% full time… essa máquina era provisória até fazermos a migração… ontem 19/03, fizemos a migração para a máquina que usávamos antes, e agora o problema é outro… Essa máquina também está com AIX 5L, 12Gb RAM, 2 Hds Internos para o SO e um RAID de 10 discos X 36,4Gb… dessa vez são os processadores que ficam entre 95 e 100% o tempo todo… e o hdisk2 que é o RAID, trabalha tranquilo. Observamos que a outra máquina tinha 4 proc de 2 núcleos (leia-se 8 proc) sendo cada um de 1.745 Mhz, e esse máquina tem 6 proc de 745Mhz. Os parâmetros são praticamente os mesmos da outra máquina. Minha SGA está com 9.2Gb, e o Oracle está gerenciando a SGA_TARGET. O que vc acha? Pode ser lentidão dos processadores.
Obrigado.

[IshiiParticipante]

Olá,

É realmente pode ser o processador, mas seria muito útil mesmo se você conseguisse mapear os processos lentos para podermos analisar melhor. O fato do hdisk está ok agora pode demonstrar que no servidor anterior devia ter algum problema no hd mesmo…ou até fragmentação de dados. Se a utilização está alta mas somente no processamento, fica mais lógico agora procurar os processos mais problemáticos uma vez que estes podem estar consumindo muito do processador. Como ERP sempre tem processos mais pesados, identificando os mesmos pode-se agendar os mesmos para um horário alternativo.

[]s Ishii

[mpvargasParticipante]

Na verdade os processos são relativos aquelas tabelas grandes (SE5, CT2, SE1, SRD) que quandos são acessadas, principalmente para fazer filtros, exigem bastante da máquina.

[IshiiParticipante]

Pelo que me lembro destas tabelas o problema está no lock mesmo pois são feitos updates nestas tabelas e eles acabam gerando um ‘gargalo’ pois as transações somente são liberadas uma a uma… acho que o paralelismo vai te ajudar mas não vai resolver muito não….

Se for mesmo nas consultas tente isolar algumas delas e crie alguns indíces para ajudar mesmo que seja tipo bitmap pois isso pode ajudar muito na performance das consultas, mas se for nos DMLs mesmo aí o problema é outro….

[]s Ishii

[mpvargasParticipante]

Caro Amigo,
Instalei o spotlight da quest e observei algumas coisas que talvez possam ajudar:

• A minha área de Flashback Recovery tem 60Gb e 55,3Gb usados (ou em uso), mas não me lembro de ter habilitado isso… ou o Oracle habilita por default?

• A minha área de Archive Log também tem 60Gb e somente 4,71Gb livre. É importante liberar mais espaço para que não fique tão cheia? Isso pode afetar na performance do banco?

• A Shared Pool está atualmente com 480Mb e 83% em uso.

Hoje de manhã o banco estava uma beleza, agora a tarde “engargalou” de novo… Sinceramente não sei mais o que fazer…

[IshiiParticipante]

Olá,

FlashBack: O Oracle 10g configura isso por default na sua criação deve ter mencionado o tamanho para utilização. Com isso é possível retornar um DROP numa tabela recuperando além dos dados triggers associadas…

Archive: Lembro que vc havia mencionado que os archives ficavam em outro device, então acho que isso não iria atrapalhar;

Shared Pool : Como estava configurado para o Gerenciamento pelo Oracle (SGA_TARGET e SGA_MAX_SIZE) acho que o controle deve estar ok.

Na parte da tarde o número de users é maior? Verifique as queries mais acessadas neste momento e se elas são muito demoradas. Verifique se há locks ocorrendo…

afff…

Sei que eh dificil mas como já dito anteriormente o trabalho é de formiguinha….

[]s Ishii

[mpvargasParticipante]

O REDO LOG BUFFER ESTÁ COM 14Mb …
VALE A PENA AUMENTAR?

[Marcio68AlmeidaParticipante]

[quote=”mpvargas”:ddyeqyx2]O REDO LOG BUFFER ESTÁ COM 14Mb …
VALE A PENA AUMENTAR?[/quote]
Eu creio que 50MB ou 100MB são valores mais interessantes para esse tipo de aplicação.
O que você vai ter que fazer é acompanhar o desempenho da máquina na hora que o banco for gravar os logs, pois isso costuma dar uma degradada por causa do I/O
Números muito pequenos costumam ser apropriados apenas para bancos com poucas transações…

[mpvargasParticipante]

Caro Amigo,
Aumentei o REDO LOG BUFFER para 60Gb… o banco até deu uma melhorada, pelo menos diminuiram as reclamações…
Meu grande problema agora é com a tabela SE5010…
Já coloquei a tabela e os índices em tablespaces separadas, já tentei usar paralelismo (não adiantou muito), e o acesso a tabela é realmente muito demorado…
Tem um analista tentando rodar uma query que até roda rapidinho, mas quando ele coloca a expressão NOT IN, aí demora muito…
Estou rodando uma estatística nesse momento, o que é aquela opção de percentual que tem no script da estatística?
Valeu pela ajuda.

[IshiiParticipante]

Olá,

Subqueries nestas tabelas somente prejudicam a performance… se você notar verá que os índíces são ignorados, o ideal seria levantar estas queries e colocar hints de qual o melhor índice a ser utilizado. Ficaria mais ou menos assim:

select /* INDEX */ from ...

[]s Ishii

[Marcio68AlmeidaParticipante]

A opção de estatística é para auxiliar o banco para tomar decisão de qual a melhor forma de resolver a sua solicitação…
Quando você usa opções como maior, menor, diferente ou alguma outra função, você mata a utilização de índices…
Dependendo da forma que você faz suas consultas, você degrada muito a aplicação…
O bom é ver com o fornecedor do produto…

[mpvargasParticipante]

Desculpe, mas não consegui entender…
Você diz colocar essa query (select /* INDEX */ from …) no lugar do NOT IN?

[Marcio68AlmeidaParticipante]

Quando você coloca o HINT :
Select /*+ index (a, indice) */ colunas... from tabela a where...
Você indicando ao banco que você deseja que ele use determinado índice, só que nem sempre o banco aceita a sua sugestão…

Usar o código :
where codigo not in ('a', 'b', 'c')
é semelhante a :
where codigo 'a' and codigo 'b' and codigo 'c'

Estas opções costumam detonar o uso do índice…
O bom uso do índice é quando você procura por um código específico ou um range de códigos…
where codigo = 'a'
ou
where codigo between 'a' and 'c'
Quanto ao uso de NOT IN não é algo recomendado, mas nem sempre possível fugir…

[Autor]

Posts