Menu de navegação

[darcioreineParticipante]

Ola galera
Tenho um servidor com 1300 sesseos
Preciso aumentar mais 500 porque esta estourando os usuários. Só que preciso esta
redimensionando a memória do oracle 8.1.7. E nao sei muito de oracle 8.
Como posso fazer esses cálculos? quais parâmetros posso esta mexendo?
Segue abaixo as confiraçoes do meu oracle
Desde já agradeço

Att
Darcio

# in accordance to the OS block size on the HP…
db_block_size = 8192
ROLLBACK_SEGMENTS = (r01,r02,r03, r04,r05,r06, r07,r08,r09, r10)
db_file_multiblock_ read_count = 32
db_block_buffers = 65000
shared_pool_ size = 600000000
shared_pool_ reserved_ size = 30000000
large_pool_size = 83886080
pre_page_sga = yes
transactions_ per_rollback_ segment = 25
log_checkpoint_ interval = 999999999
distributed_ transactions = 350
processes = 900
dml_locks = 4860
log_buffer = 1048576
max_dump_file_ size = 302000 # limit trace file size to 5 Meg each
max_enabled_ roles = 50
CORE_DUMP_DEST = /tools/oracle/ admin/D03MB1/ cdump
USER_DUMP_DEST = /tools/oracle/ admin/D03MB1/ udump
AUDIT_FILE_DEST = /tools/oracle/ admin/D03MB1/ audit
BACKGROUND_DUMP_ DEST = /tools/oracle/ admin/D03MB1/ bdump
# The following three parms are required for automatic archiving …
#log_archive_ start = true # if you want automatic archiving
log_archive_ start = false # if you do not want automatic archiving
log_archive_ dest = /tools/oracle/ admin/D03MB1/ arch/
log_archive_ format = archD03MB1_% s.dbf
timed_statistics = false
# On the recommendation of Oracle in regards to an ORA-600 abend:
# For remote os login using ops$ …
# remote_os_authent = true remarks by Ledu 19-jun-2001
# remote_os_roles = true remarks by Ledu 19-jun-2001
resource_limit = true
open_cursors = 455
parallel_min_ servers = 2 # For parallel Query
parallel_max_ servers =150
_trace_files_ public = true
sort_area_size = 1048576
sort_area_retained_ size = 262144
db_writer_processes = 4
recovery_parallelis m = 2 # novo valor – antigo era default
db_block_lru_ latches = 8 # novo valor – antigo era default 8
hash_join_enabled = false
NLS_DATE_FORMAT= “DD-MON-RR”
enqueue_resources = 2500
open_links = 50
distributed_ transactions = 350
compatible=8. 1.7.4
optimizer_mode = rule
max_rollback_ segments= 50
job_queue_processes =3
sessions = 1300
processes = 1000

[Marcio68AlmeidaParticipante]

Antes de você sair arrancando os cabelos para aumentar o número de conecções, é importante ver por que está estourando mais de mil conecções simultâneas.
Que tipo de aplicativo está sendo executado ???
É possível que se esteja abrindo novas conecções sem fechar as anteriores ou, o que seria ideal, reaproveitar as conecções ?
Você não pode ir aumentando indiscriminadamente o número de conecções, isso tem impacto direto na memória, pode vir a travar o banco.
Quanto você tem de memória ? Qual o sistema operacional ?
Que tipo de transação é a mais executada ?
Que aplicativo está sendo utilizado para acessar o banco ? (Delphy, VB, WEB, etc)
Qual a duração média de uma conecção ?
É um banco em RAC ou individual ?
Qual a possibilidade de migrar para uma versão mais nova ? A 8i está descontinuada faz tempo…

[darcioreineParticipante]

Oi Mario

O problema q cai de para quedas nao sei muito sobre as aplicaçoes que rodam . O Banco de dados esta rodando no Unix e tenho as 2084M de memoria livre. Por enquanto nao tem previsao de migração. Tem como eu descobri alguma informaçoes q vc necessita via comando?

Obrigado!

[Marcio68AlmeidaParticipante]

Bom…
Você pode usar a seguinte consulta para verificar o que está acontecendo no banco :
Select p.spid, s.sid, s.serial#, s.username, s.osuser, s.status, s.server, s.logon_time,
TO_CHAR (TRUNC (last_call_et / 3600), '009') || ':' ||
Case When TRUNC (last_call_et / 3600) >= 1 Then
TO_CHAR (MOD ((last_call_et - (3600 * TRUNC (last_call_et / 3600))) / 3600, 2) * 60, '09')
Else
TO_CHAR (MOD (last_call_et / 3600, 2) * 60, '09')
End inatividade, s.machine, s.program, sql.sql_text,
p.pga_used_mem, p.pga_alloc_mem, p.pga_freeable_mem, pga_max_mem
From v$session s, v$process p,
(Select distinct sql_text, address
From v$sql sql ) sql
Where s.username is not null
And s.status = 'ACTIVE'
And s.paddr = p.addr (+)
And s.sql_address = sql.address (+)
Order by s.last_call_et desc

Esta outra consulta vai te ajudar a ver de onde estão vindo as conexões :
Select machine, terminal, status, count(*) conexoes
From v$session s
Where username is not null
Group by machine, terminal, status

É bom falar com os analistas e programadores para rever os processos…

[Rodrigo AlmeidaParticipante]

Olá Darcioreine,

Seguinte, o numéro de sessões está no Limite na configuração da sua instância, para resolver BASTA aumentar o valor dos parâmetros:

sessions =
processes =
transactions =

Existe uma regra certinha que faz o cálculo exato para cada parâmetro, exemplo:

processes = 2000
sessions = procesess * 1.10
transactions = sessions * 1.25

Mas tem que confirmar, não lembro de cabeça.

Agora, verifique o tamanho total da sua SGA, pelo que vi nos parâmetros está com aproximadamente 605MB, e seu servidor está com 2GB, então existem algumas soluções para ti, veja:

• Diminua o valor de SORT_AREA_SIZE, de 1MB para 500KB, assim, aceitará mais sessões no modo DEDICADO.
• Aumente sua SGA, e principalmente o SHARED_POOL_SIZE.

Como está trabalhando com UNIX (Aix, HP-UX, Tru64, Solaris e etc), veja como trabalhar com SGA acima de 2GB para plataforma de 32-Bits (deve ser o seu hardware), e as configurações necessárias para 8i.

Talves, muitos problemas sejam resolvidos ao aumentar os parâmetros mencionados no início, ou apenas redimensionando os valores de SORT e SHARED_POOL. (Acredito que sua base atualmente não esteja aceitando as 1.300 pelo motivo de processes estar igual a 1.000, e ainda tem os processos internos do Oracle).

Se continuar pense em utilizar o MTS para gerenciar um grande POOL de conexões (melhora em muito) e caso não tenha saida, utilizar o orastack no último caso para reduzir o consumo do listener de 1MB para 500K por processo.

Qualquer coisa, poste as dúvidas.

Abraços,

Rodrigo Almeida

[darcioreineParticipante]

ola alphamek

Primeiramente obrigado pela ajuda .

Entao alphamek o meu servidor ele nao tem 2GB de memoria ele tem livre 2gb de memoria.

Se vc poder confirmar a regra certa de aumento sessions processes, trasactions.
Mais nao entendi no começo se vc falou que o numero de sessoes esta no limite da configuração da minha instancia entao nao basta so adicionar session, processes, transaction ? Né?

Desde ja agraço pela atenção

att
Darcio

[Rodrigo AlmeidaParticipante]

Darcio,

Melhor ainda que tenha 2GB de memória livre. Isso já um bom sinal, ainda mais por estar em Unix (Em Windows teria problemas.. =D).

Porque eu falei que se banco de dados hoje não aceitaria os 1300 conexões, pelo simples motivo, no INIT que você postou, os últimos parâmetros PROCESSES e SESSIONS estão respectivamente com 1000 e 1300. (Fora que estão duplicados, mas o que vale é a última publicação).

Os parâmetros SESSIONS e TRANSACTIONS são derivados do parâmetro PROCESSES, esse parâmetro é o que diz quantos processos de usuários a sua instância poderá aceitar simultâneo. Então, se processes está com 1000, logicamente, sua instância não consegue ter 1.300 acessos simultâneos, e sim apenas 1.105. Porém o banco de dados pode ter mais que uma SESSÃO com o mesmo SPID (Processo) e diferente SID e SERIAL#, é o caso de aplicações FORMS/REPORTS, onde utiliza uma sessão adicional ao processo para criar o menu, report e etc..

Por esse motivo, para realizar o calculo para o parâmetro SESSIONS, use essa formula:

SESSIONS = (1.1 * processes) + 5

e para utilizar em transactions, basta usar a fórmula seguinte:

TRANSACTIONS = (1.1 * sessions)

Esse parâmetro é utilizado para transações concorrentes.

Então, no seu caso, aumente esses valores seguindo essa orientação, que resolverá seu problema. Aumente o SHARED_POOL (se estiver trabalhando no modo DEDICADO) para não ter problemas ao conectar, como erros TNS, onde diz que não é possível criar uma sessão dedicada no banco de dados.

Abraços,

Rodrigo Almeida

[Autor]

Posts