Menu de navegação

[jspaulonciParticipante]

Bom dia pessoal, tudo certo no final de semana ? espero q sim……vamos lá né…começar mais uma semana.

Gostaria de saber como os Srs. utilizam os parametros SGA_MAX_SIZE e SGA_TARGET, vocês usam os dois definidos, vocês usam os dois com valores diferentes de Zero ? um independe do outro ?, eu li uma referência sobre isso, porem gostaria de uma opinião de vocês.

Obraços
João Paulo Spaulonci

[Ricardo Portilho ProniParticipante]

Oi João Paulo.

Eu deixo os dois definidos em 50% da RAM so server, com valores iguais, a não ser que eu encontre algum problema com o gerenciamento automático (por exemplo, excesso de fragmentação da Shared Pool em decorrência da falta de binds).

[jspaulonciParticipante]

Obrigado Ricardo, também vou deixar os dois compartilhados.

[LoadingXpParticipante]

Eu deixei tudo setado manualmente.

Segue abaixo:

SQL> show sga

Total System Global Area 3120562176 bytes
Fixed Size 2075976 bytes
Variable Size 1593836216 bytes
Database Buffers 1509949440 bytes
Redo Buffers 14700544 bytes

SQL> show parameters db_cache

NAME TYPE VALUE

---

db_cache_advice string ON
db_cache_size big integer 1440M
SQL> show parameters shared_pool

NAME TYPE VALUE

---

shared_pool_reserved_size big integer 72M
shared_pool_size big integer 1440M
SQL> show parameters large_pool

NAME TYPE VALUE

---

large_pool_size big integer 80M
SQL> show parameters java_pool

NAME TYPE VALUE

---

java_pool_size big integer 0
SQL> show parameters streams_pool

NAME TYPE VALUE

---

streams_pool_size big integer 0

SQL> show parameters SGA

NAME TYPE VALUE

---

lock_sga boolean FALSE
pre_page_sga boolean FALSE
sga_max_size big integer 2976M
sga_target big integer 0

[Rodrigo AlmeidaParticipante]

Costumo deixar os dois parâmetros ZERADOS!

Trabalho com todos de forma manual, assim, consigo estudar o comportamento da aplicação e fornecer mais recursos em momentos de pico e recursos específicos conforme a aplicação vai necessitando.

Sempre acompahando com AWR, ASH e ADDM.

Abraços,

Rodrigo Almeida

[Ricardo Portilho ProniParticipante]

Aêêê, o Rodrigo é das antigas ! This is Esparta !!!

[CleitonHanzenParticipante]

Opá…

Costumava usar sempre o SGA_TARGET no 10g, porém nas versões mais novas tem tanto BUG (que causam latches, consumo de processamento e até mesmo erros de alocação de memória ORA-4031) que passei a colocar tudo manual….

Tem de ser avaliado bem, caso o teu ambiente possua MUUUUITA diferença de comportamento durante o dia, pode até utilizar, porém se vc já tem a tua aplicação bem desenvolvida e testada e conhece bem o comportamento, deixa no manual, com certeza vai te evitar algumas dores de cabeça… 🙂

[Rodrigo AlmeidaParticipante]

THIS IS ESPARTA!!!! kkkkk…

Eu só não controlo os FREELISTs pq realmente não precisa mais mesmo. No 10g isso ficou bem melhor.

Se tu tem um APP pequeno, coisa mínima, aí tu pode até colocar para o gerenciamento automático para não ter dor de cabeça! Para passar mais tempo tomando café e vendo o globoesporte.com!!! kkkk…

Mas de resto, prefiro tudo manualmente ainda… é bem melhor na hora de detectar erros!!!

Abraços,

Rodrigo Almeida

[LoadingXpParticipante]

Aqui tambem nós já tive problemas com a memoria automática.

Por isso deixo tudo manual mesmo, é bem tranquilo de monitorar ainda coloco uma KEEP e RECYCLE bem alto das tabelas mais fortes do sistema.

Lembrando que se você ativar monitoramento automático e importante setar SGA_TARGET e o SGA_MAX com no máximo 90% da memoria disponivel do server.

Alguem sabe se esses problemas de memoria já foram corrigidos no 11G?

[CleitonHanzenParticipante]

[quote=”LoadingXp”:3clchj8v]Aqui tambem nós já tive problemas com a memoria automática.

Por isso deixo tudo manual mesmo, é bem tranquilo de monitorar ainda coloco uma KEEP e RECYCLE bem alto das tabelas mais fortes do sistema.

Lembrando que se você ativar monitoramento automático e importante setar SGA_TARGET e o SGA_MAX com no máximo 90% da memoria disponivel do server.

Alguem sabe se esses problemas de memoria já foram corrigidos no 11G?[/quote]

Li algumas coisas q no 11G tem o parâmetro MEMORY_TARGET que vai servir tanto pra PGA quanto pra SGA, agora se num ambiente maior nem o SGA_TARGET funciona adequadamente, imagina o gerenciamento automático de tudo…Deus me livre dessa bomba….Não quero mais os nós do RAC caindo por causa de erro ORA-4031….hehehe

[LoadingXpParticipante]

Cleiton,
esse problema faz seus nós cairem???

Imagino que o problema é grave, você ainda continua com esse tipo de memoria??

[CleitonHanzenParticipante]

Desabilitamos por completo..

Também estávamos com uma quantidade absurda de latches, colocamos o statistics_level=basic, ou seja, passamos o banco para trabalhar da forma mais simples possível e tivemos ganhos tanto de estabilidade quanto de performance…

As desvantagens é perder as “estatísticas” do próprio banco (afinal, awr, os advisors e tudo relacionado, está desabilitado)….Mas como diria nosso DBA Sr, o banco de dados é feito pra aplicação funcionar 100%, não pro DBA clicar em dois botões e ter tudo resolvido… 🙂

[wagnerbianParticipante]

Pessoal,

Primeiramente um “OLÁ” para todos, já que é a minha primeira participação cá com vocês.

Achei bastante interessante tanto a visão do Ricardo de configuração com parâmetros equilibrados em relação ao número de memória do servidor para controle automático da SGA, que podemos também controlar no ORACLE 11g através da variável MEMORY_TARGET, quanto a visão do Alphamek que visa o controle por parte do DBA em relação a liberação de mais recurso para processos “esses” e/ou “aqueles”.

Agora, quanto ao problema físico, quando tratamos de tablespaces, como vocês costumam trabalhar? Com o autoextend é interessante ou utilizar este recurso de crescimento automático aliado a um valor máximo do tablespace para melhor visualização em relação ao tamanho total do disco?

Enfim, como vocês trabalham a estratégia de crescimento da informação em meio físico?

Obrigado e um grande abraço à todos.

[Rodrigo AlmeidaParticipante]

Wagner,

Particularmente eu não gosto de trabalhar com os datafiles em autoextend, pois eu configuro um monitoramente sobre as tablespaces, os thresoulds são configurados de acordo com a criticidade de cada um.

Gosto sempre de manter um padrão de crescimento para os datafiles, seja ela 2GB, 4GB ou 6GB, porém, trabalhando sempre com esse tamanho nos datafiles, pois isso ajuda a diminuir o meu tempo de recuperação de datafile.

Outra, caso esse banco seja necessário realizar cópias para ambientes de desenvolvimento ou homologação, seja por Cópia fria ou RMAN, grandes datafiles costumam trazer problemas, pois, nunca se sabe se no servidor de destino vai ter o espaço necessário, e pode ocorrer de você ter que refazer o seu controlfile e distribuir os datafiles em FileSystem ou Discos diferentes do original.

Sobre o controle de informação, a monitoração deve estar bem adequada na sua base, controlar o crescimento das tablespaces, realizar um projeto de volumetria, analisar os dias de pico da base, analisar os I/Os dos datafiles e sua distribuição física ajuda nesse requisito.

Abraços,

Rodrigo Almeida

[wagnerbianParticipante]

Alphamek,

Interessante e obrigado pela sua resposta. Desde outros SGBD’s com os quais também trabalho, tentei preservar o que vejo no ORACLE também é bem interessante: manter os tablespaces separados por mount points singulares, de acordo com a finalidade de cada um (avaliando segmentos grandes ou pequenos, dados e índices, os mais utilizados e menos utilizados…), na medida do possível, com atenção especial ao time recovery e outros pontos.

O tal tablespace bigfile seria bastante arriscado para grandes bases, embora seja interessante para certos casos.

🙂 [/i]

[Autor]

Posts