Memory_Target

Com as novas opções do Automatic Memory Management (AMM) do oracle 11g surgiu os novos para metros Memory_max_target eMemory_target.A estrutura dos paramentros de memória ficaram da seguinte forma hierarquica acima mostrada .

Vale a pena pensar como essa novas opções irão influenciar os parametros PGA_AGGREGATE_TARGET ( chamarei de PAT) e SGA_TARGET (chamarei de SGAT)

Considerando o Memory_Target definido com um valor acima de 0 :

Caso o SGAT e PAT estajam com valores definidos ,o comportamento do oracle será considerar o Memory_Target_max = SGAT + PAT

Caso SGAT esteja definido e PAT nao esteja definido ,o comportamento do oracle será considerar a PAT = memory_target - SGAT.

Caso SGAT nao esteja definido e PAT esteja definido, o comportamento do oracle será considerar SGA_target inicialmente min(memory_target - PAT , Sga_max_size) .

Caso SGAT e PAT nao estejam definidos estes valores serão auto ajustado para SGAT com 60 % da memory_target e PAT com 40 % da memory_target.

como estaos meu parametros nesse momento ? Veja com a View abaixo :

Sql > Show Parameter target ;

ADR - Automatic Diagnostic Repository

Uma funcionalidade muito útil para um DBA que vejo ser pouco comentada é o ADR.Ele se trata de uma repositório automatico do Oracle (só utilizei na versao 11G) que guarda os log do seu SGDB.

Para descobrir as pastas onde ficam os seu log segue um select em uma view :

Select name,value from v$diag_info ;

Onde podemos considerar :

adr_home = endereco

adr_home/trace - Arquivos que armazenam informações de processos de primeiro e segundo plano.

adr_home/alert - Guarda os logs de alerta no formato XML.

adr_home/trace - Guarda os logs de alerta no formato TXT.

adr_home/cdump - informações sobre dumps de memória.

adr_home/incident/incdir_n - guarda informamoes sobre dumps de incidentes.

Existe uma ferramenta chamda ADRCI que você pode chamar pelo terminal do linux ou prompt do DOS que te auxilia a leitura dos arquivos existentes nestas pastas.Essa ferramenta fica para um post futuro.

Cursor_Sharing

Nesta semana estive diante de um problema de uma aplicação com o uso de "literais" como parametros em alguns select como um exemplo :

Select COD_PAIS , DS_PAIS FROM PAISES WHERE COD_CONT = 'EU' ;

Com isso estou com problema de uma queries simples como essa acima ter para cada execução ,um plano de execução em memória no Oracle.Como não é fácil "convencer" a um desenvolvedor que esse tipo de escrita de select não é a melhor e que ao invés de usar uma literal como parâmetro ele poderia utilizar a nossa Bind variable .Resolvi procurar algo que diminuísse o estrago que estava acontecendo.

O parâmetro Cursor_Sharing trabalha nessa direção .Ele aceita 3 valores, sendo eles: FORCE, SIMILAR e EXACT.

EXACT – é o padrão para banco de dados Oracle. O parâmetro EXACT envia ao otimizador do Oracle que toda e qualquer instrução deve ser igual inclusive os valores literais.Este é o parametro do meu SGDB e com isso fico dependendo da boa vontade do desenvolvedor.

FORCE – O parâmetro troca as variáveis literais por valores bind, em sua execução, fazendo com que o HARD-PARSE se transforme em SOFT. O valor FORCE no parametro CURSOR_SHARING, gera apenas 1 plano de execução.Porem não consegui identificar em que esta opção pode nos trazer problemas.Pense bem.Se ela fosse livre de riscos ,poque não seria a opção default ??

SIMILAR – O parâmetro troca as variáveis literais por valores bind, em sua execução.

O valor SIMILAR no parametro CURSOR_SHARING, parece agir da mesma forma que o valor FORCE,mas diferente do FORCE , o SIMILAR gera mais de um plano de execução (se a tabela estiver com a coleta de estatísticas atualizada).

O CURSOR_SHARING é um cara meio problemático. Se você fizer uma busca no

Metalink, vai ver vários problemas associados. Quando migramos para o 11g

onde eu trabalho, houve um ORA-0600 .Porem ,pode ser uma alternativa.