Load-Oriented Waits

Saudações pessoal, segue breves explicações sobre waits no Oracle RAC:

gc current block congested
gc cr block congested
gc current grant congested
gc cr grant congested

Indica que ocorreu um delay de processamento no GCS, geralmente causado por uma saturação de CPU.
Possíveis soluções:
– Aumentar a quantidade/poder de processamento de CPU’s no DB Server
– Implementar balanceamento do cluster no nível de serviço
– Adição de mais nós no cluster

O tempo de espera desse evento engloba, desde o momento que a sessão inicia a wait, até o recebimento do bloco.Sempre que a requisição por um block/message transfer, demorar mais que 1ms na internal queue, o Oracle irá considerar um overload.
Isso pode acontecer quando o processo background LMS não consegue realizar todo processamento da sua fila de solicitações. Um possível workaround é aumentar o número de processos background LMS. Para isso, é necessário aumentar o parâmetro GCS_SERVER_PROCESSES.O calculo da quantidade de processos LMS é baseado na quantidade de core dividido por dois. Se um servidor possui oito cores, então o parâmetro GCS_SERVER_PROCESSES será 4 (8 cores/2).Então, teremos quatro processos background LMS.
A view X$KJMSDP mantém informações preciosas quanto a carga de trabalho dos processos LMS.
Em um ambiente RAC bem balanceado, raramente veremos esses tipos de espera.

Referência: Gopalakrishnan, K . Oracle Database 11g. Oracle Real Application Clusters Handbook Second Edition. Oracle Press, 2011.

Contention-Oriented Waits

Saudações pessoal, terça feira chuvosa na cidade de São Paulo, fora o calor. Hoje estou postando mais eventos de esperas que podem ocorrer no Oracle RAC.

– gc current bock busy
– gc cr block busy
– gc current buffer busy

Essas esperas indicam que o envio de um bloco foi adiado porque alguma alteração no bloco não foi liberado para disco, ou, devido a alta concorrência no bloco sendo requisitado.
Isso pode acontecer quando uma instância está alterando um bloco de indice, e outra sessão está aguardando a liberação desse bloco para inserir ou atualizar o bloco. Nesse caso a espera “gc current block busy” pode ser seguida das esperas “gc current split” ou “gc buffer busy”.
Um buffer pode também estar estar em status busy na instância local, ou, por uma sessão que iniciou uma operação do tipo cache fusion e, está aguardando a conclusão da operação quando outra sessão, no mesmo nó, solicita o bloco para ler ou modifica-lo.
Isso pode ocorrer no Oracle RAC 11g, quando um processo foreground está esperando por um antilock broadcast, para atualizar um objeto que é alterado frequentemente.
O evento “block busy” significa que uma sessão está solicitando acesso a um bloco , que no momento é considerado busy em um outro nó remoto. A espera “buffer busy”, indica que várias sessões estão aguardando por um bloco que é considerado busy em um nó remoto.

Abração, e até próxima.

Referência: Gopalakrishnan, K . Oracle Database 11g. Oracle Real Application Clusters Handbook Second Edition. Oracle Press, 2011.

Message-Oriented Waits

Saudações pessoal, uma breve explicação sobre as esperas abaixo.

-gc current grant 2-way
-gc current grant 3-way
-gc cr grant 2-way
-gc cr grant 3-way

Essas esperas indicam que nenhum bloco foi recebido porque o bloco não estava em memória. Em vez disso, uma permissão de leitura (grant global) foi enviado para a instância que solicitou o bloco, para ler ou modica-lo em disco. Essas esperas podem ser seguidas das waits “db file sequential read” e “db file scattered read”. Elas podem indicar gargalo de I/O (cr grant), ou muitas inserções de dados que necessitam encontrar e formatar novos blocos (current grant).

Fonte: Gopalakrishnan, K . Oracle Database 11g. Oracle Real Application Clusters Handbook Second Edition. Oracle Press, 2011.

Block-Oriented Waits

Saudações pessoal, uma breve explicação referente ao eventos de espera abaixo.

– gc current block 2-way
– gc current block 3-way
– gc cr block 2-way
– gc cr block 3-way

São os eventos mais comuns de espera em um ambiente em RAC. Essa estatística significa que o bloco solicitado foi servido por outra instância que não aquela onde foi solicitada. O tempo dessa espera é determinado pelo processamento na camada de rede, o tempo para o processamento na instância que servirá o bloco, e por fim, o tempo de processamento pelo processo que solicitou o bloco quando ele chegar. Normalmente a causa para essas esperas podem ser  interconnect , cargas ou  execuções de SQL.

Fonte: Gopalakrishnan, K . Oracle Database 11g. Oracle Real Application Clusters Handbook Second Edition. Oracle Press, 2011.

Logs do srvctl

Saudações pessoal. Nem sempre alguns erros indicam a causa raiz do problema. Para erros referente ao srvctl (server control utility) , procurar a causa raiz nos logs que estão no diretório:

$ORACLE_HOME/log/hostname/racg/*

Alguns erros:

$ srvctl start service -d DB -s S01 -i DB4
PRKP-1030 : Failed to start the service S01.
CRS-0215: Could not start resource ‘ora.DB.S01.DB4.srv’

$ srvctl stop  service -d DB -s S01 -i DB4
PRKP-1065 : Service S01 is already stopped on instance DB4.

$ srvctl stop  service -d DB -s S01 -i DB4 -f
PRKP-1065 : Service S01 is already stopped on instance DB4.

$ srvctl start service -d DB -s S01 -i DB4
PRKP-1030 : Failed to start the service S01.
CRS-0215: Could not start resource ‘ora.DB.S01.DB4.srv’

Abraços

Desabilitando triggers de sistema

Saudações pessoal, existe outra maneira de desabilitar triggers de sistema.

A técnica segue abaixo:

 

ALTER SYSTEM SET “_system_trig_enabled” = TRUE SCOPE=BOTH;

Para verificar se triggers de sistema estão ativas ou não, executar o select.

set linesize 150
col NAME format a30
col VALUE format a20
col DESCRIPTION format a60
SELECT x.ksppinm NAME, y.ksppstvl VALUE, ksppdesc DESCRIPTION
FROM x$ksppi x, x$ksppcv y
WHERE x.inst_id = userenv(‘Instance’)
AND y.inst_id = userenv(‘Instance’)
AND x.indx = y.indx
AND x.ksppinm = ‘_system_trig_enabled’;

Abração .

Variável de ambiente CV_JDKHOME e o cluvfy

Saudações pessoal.

Se vocês encontrarem o erro java: not found quando estiverem tentando executar o cluvfy, zerem a variável de ambiente CV_JDKHOME.

./cluvfy stage -pre crsinst -n servidor1, servidor2 -verbose
./cluvfy: /u01/jdk/bin/java: not found

unset CV_JDKHOME

Tentem executar novamente o cluvfy, talvez resolva.

Abraços

Verificando em qual bloco está armazenda determinada linha

Saudações pessoal, como verificar em qual bloco encontra-se determinada linha ?

1 – Crie uma tabela qualquer com no mínimo uma coluna, no meu caso o nome da tabela é TB_VENDAS, possui três colunas, id (number), nome varchar2 e cidade varchar2. Em seguida  insira algumas linhas.

2 – Localize o rowid da linha

SQL> select rowid,id,nome from vendas.tb_clientes where id=987;
                   ROWID             ID         NOME
AACnayAAFAAAAaeAAk    987     PRISCILLA

3 – O ID da linha é AACnayAAFAAAAaeAAk, em seguida, descrobriemos o bloco no qual a linha está armazenada

SQL> select dbms_rowid.rowid_block_number(‘AACnayAAFAAAAaeAAk’) bloco from dual;
  BLOCO
———-
      1694

4 – O código do bloco é 1694, com a função abaixo, descobriremos o id do datafile. Depois disso fazer um select na DBA_DATA_FILES.

SQL> select dbms_rowid.rowid_relative_fno(‘AACnayAAFAAAAaeAAk’) datafile from dual;
   DATAFILE
———-
         5

Conclusão:

Particularmente, não me lembro de uma situação onde precisei de uma análise nesse nível, porem, acredito que todo conhecimento é bem vindo.

Abraços e até a próxima.

DB Smart Flash Cache

I – Introdução

Saudações pessoal, esse artigo é um pouco diferente dos outros, ele aborda a feature DB Smart Flash Cache sob uma perspectiva teórica em relação a prática. Esse recurso está disponível a partir da versão Oracle 11gR2. Nós sabemos que I/O, consome tempo, ciclos de CPU e memória. Sabemos também que o I/O na memória é mais rápido, porem mais caro para as empresas. E se tivermos um meio termo ? melhor, mudo a pergunta, e se tivermos um db_cache_size  estendido ? O DB Smart Flash Cache amplia a discussão referente a flexibilidade de um recurso tão discutido, a memória.

II – O que é ?

Conceitualmente, o DB Smart Flash Cache é a extensão do buffer cache, residindo em um flash disk. Inclusive, com a mesma hierarquia do cache utilizado pelas CPUs atuais, onde, o dado com a maior frequência de acesso, será mantido no nível 1 do cache, entenda-se na memória. O dado com menor frequência de acesso será mantido no nível 2 do cache, entenda-se flash disk.

Podemos concluir que, poderemos ter um buffer cache maior que a memória do servidor. Um flash disk , juntamente com seus devices, possue maior capacidade de armazenamento comparado a DRAM (tipo de memória RAM), e melhor throughput e menor latência comparado aos discos comuns, mesmo os fiber channel.

Essas vantagens resultam em uma grande melhoria de performance com custo moderado. O melhor tipo de flash disk, para ser utilizado em banco de dados, são aqueles que oferecem maior IOPs em escrita, em relação a  IOPs em leitura.

OBS: IOPs é a capacidade de processamento de I/O por segundo.

III – Utilização e custo

O DB Smart Flash Cache fornece melhor performance. Em um sistema de banco de dados, quando o uso de memória chega perto do máximo, o gargalo de I/O em disco é inevitável, nessa situação, a única opção é comprar mais memória. Mas, o preço por GB/$ não é barato e outro agravante, pode ser a limitação de slots do servidor para estender a memória. Então, a empresa é forçada a adquirir novos servidores.

Flash disks são perfeitos nessa situação. Pelo mesmo preço a ser gasto em memória DRAM, é possível adquirir 5 ou 10 vezes mais em memória flash. Configurando memória flash, juntamente com a memória do servidor, é possível maximizar a quantidade de memória para o buffer cache do banco.Sob a perspectiva da administração e manutenção, basta a configuração de apenas dois parâmetros.

Essa feature fornece, uma interface para ajustar o controle de granularidade em nível de objeto, através do mecanismo LRU no flash cache.

É possível também , controlar o mecanismo da LRU, especificando clausulas no nível de objeto.

 

IV – Arquitetura

Quando um processo tenta acessar um bloco e, esse bloco não está na memória, (buffer cache), uma leitura no disco será realizada, em seguida o bloco será carregado no buffer cache (physical read). Depois que esse bloco é acessado, provavelmente ele será retirado da memória para dar lugar a outros blocos que necessitam ser acessados por outros processos. Quem controla a retirada do bloco na memória é o algoritmo LRU (list recently used).

Com o DB Flash Cache, quando um bloco sai da memória (buffer cache) para dar lugar a outro bloco, seu conteúdo é escrito no flash cache pelo processo background Database Writer (DBWR), e o cabeçalho do bloco em questão, será mantido como metadado no flash DEFAULT ou na KEEP LRU list. Isso dependerá do valor definido no atributo FLASH_CACHE.

Se o valor do atributo FLASH_CACHE for KEEP, os blocos que estiverem na KEEP LRU, serão mantidos para que outros blocos não os sobrescrevam. Se o valor do atributo FLASH_CACHE for DEFAULT, então, os blocos que estiverem na KEEP LRU poderão ser sobrescritos para dar lugar a outros blocos.

Quando um bloco estiver fora do buffer_cache e ele for requisitado para leitura, o Oracle tentará ler o bloco da memória flash, caso contrário o bloco será lido do disco (physical read).

A consistência de um bloco na memória flash em ambientes Oracle RAC, é garantida da mesma forma que a consistência que qualquer outro bloco no do Cache Fusion.

Um dirty block nunca é colocado na memória flash. Dirty blocks são tratados dessa maneira por que o checkpoint no bloco continuará sendo no buffer cache.

Para efeito de comparação, é claro que tudo dependerá do hardware e configuração de melhores práticas, o tempo de leitura de um bloco em disco demora em média 10ms, enquanto que a leitura de um bloco no flash cache, leva em média de 1ms, ou seja, compensa.

 

V – Configurando o DB Smart Flash Cache

Dois parâmetros são utilizados na configuração do DB Smart Flash Cache

DB_FLASH_CACHE_FILE e DB_FLASH_CACHE_SIZE.

 

Parâmetro DB_FLASH_CACHE_FILE

DB_FLASH_CACHE_FILE= ‘/dev/flash1’

DB_FLASH_CACHE_FILE= ‘/u03/flash1.dbf ‘

DB_FLASH_CACHE_FILE= ‘+DGFLASHCACHE/flash_cache’

 

Esse parâmetro especifica o nome do arquivo presente no sistema operacional. Caso o arquivo não existir no momento do startup, o Oracle criá-la o arquivo.

Como podemos ver, o db_flash_cache_file pode ser apresentado para a instância, como uma raw device, um file system ou um diskgroup na ASM. O flash cache não é compartilhado entre instâncias do Oracle RAC, cada instância tem sua própria memória flash. Esse parâmetro precisa definido antes do startup da instância e não pode ser alterado depois que instância foi startada.

 

Parâmetro DB_FLASH_CACHE_SIZE

Esse parâmetro especifica o tamanho da memória flash. Ele precisa ser definido antes do startup da instância e pode ser alterado apenas para 0 (isso desabilita a utilização da memória flash).  Quando o flash cache é desabilitado, ele poderá somente ser habilitado com o restartup da instância. O resizing dinâmico desse parâmetro não é suportado, ou seja, ele não é gerenciado pelo automatic shared memory management (memory_target <> 0).

Os demais blocos pertencentes a outros pools de memória como large_pool, java_pool, shared_pool, streams_pool não são suportados na memória flash.

 

VI – Melhores práticas

 

Por regra geral, o tamanho a ser configurado para a memória flash, deverá ser entre duas a dez vezes o tamanho do buffer cache, qualquer configuração abaixo disso não haverá ganho de performance.

Se o banco estiver configurado com automatic shared memory management, considerar no mínimo 80% do tamanho da SGA_TARGET para a definição do tamanho da memória flash.

Para cada bloco que é movido do buffer cache para a memória flash, a quantidade de bytes para manutenção do metadado do bloco, será de 100 bytes para single instance e, aproximadamente 200 bytes para o Oracle RAC. Essa informação é mantida no buffer_cache logo, é necessário considerar esse overhead da seguinte maneira.

Se estiver utilizando gerenciamento de memória manual: O tamanho do db_cache_size deverá ser aumentado respeitando o seguinte algoritmo:

 

Single instance:

DB_CACHE_SIZE=DB_CACHE_SIZE+Qtde de blocos da memória flash X 100 bytes

Oracle RAC:

DB_CACHE_SIZE=DB_CACHE_SIZE +Qtde de blocos da memória flash X 200 bytes

 

Exemplo de calculo para single instance:

DB_CACHE_SIZE= 2G ou 2147483648 bytes

Tamanho da memória flash= 10 Gb ou 10737418240 bytes

Tamanho do bloco= 8K ou 8192 bytes

Overhead do bloco = 100 bytes

DB_CACHE_SIZE= 2147483648+((10737418240/8192)*100)

DB_CACHE_SIZE= 2147483648+(1310720*100)

DB_CACHE_SIZE= 2147483648+131072000

O tamanho do DB_CACHE_SIZE deverá ser acrescido em 125mb, ou seja, seu valor deverá ser 2.125 mb.

Se o ambiente for RAC, alterar o valor do overhead do bloco para 200 bytes.

Se estiver utilizando automatic shared memory management, considerar o mesmo algoritmo acima, porem o parâmetro a ser aumentado não será o DB_CACHE_SIZE e sim  SGA_TARGET.

 

VII – Especificação do DB Smart Flash Cache no nível de objeto

É possível especificar o DB Smart Flash Cache em uma tabela utilizando a opção FLASH_CACHE na clausula storage.

 

Exemplo:

CREATE TABLE TB_CLIENTES …… STORAGE (FLASH_CACHE KEEP|NONE|DEFAULT);

Onde:

DEFAULT – Quando um bloco se “tornar velho” no buffer cache, o bloco será escrito na memória flash. Os blocos que estão na memória flash são mantidos algoritmo pelo flash LRU list, logo, esses blocos podem ficar velhos na memória flash e serão retirados da memória flash para acomodar outros blocos.

KEEP = Possui as mesmas características da opção DEFAULT, porem esses blocos serão mantidos separados dos blocos com  a opção DEFAULT na memória flash. O Oracle tentará manter sempre os blocos com a opção KEEP na memória flash.

NONE = Blocos com essa opção nunca serão colocados na memória flash.

Por questões de consistência, o Oracle considera leituras físicas para as leituras realizadas na memória flash . Os relatórios AWR possuem estatísticas específicas para a memória flash.

 

VIII – Conclusão

Vejo essa feature sob duas ópticas: tecnicamente,  a possibilidade de estender o cache do banco independentemente a quantidade de slots de memória suportada pelo servidor, e financeiramente pois discos SDD são mais baratos que memória DRAM.  Sempre lembrando da velha máxima, para qualquer ambiente de produção, desenvolver, testar, homologar e implementar.

 

Forte abraço e até a próxima

 

IX – Referências bibligráficas

ORACLE University. Oracle Database 11g New Features for Administrators: 16-Performance Enhacements . California USA. 2.1 ed. Setembro 2010. v.II, p.105-111

Disponível em : http://www.oracle.com/technetwork/middleware/bi-foundation/exadata-smart-flash-cache-twp-v5-1-128560.pdf. Acessado em 04/11/2011

PRKP-1030 : Failed to start the service servprod

Saudações pessoal, em algumas situações passei por esse tipo erro – não conseguir startar o serviço do RAC pelo utilitário srvctl na versão 10g.
Nesses casos existe um workaround. Já que não consigo pelo srvctl, podemos resolver stopando do serviço pelo pacote DBMS_SERVICE.

Vejam:
[oracle@producao1 /u01/app/oracle/base10g/admin/dbprod1/bdump]$srvctl start service -d dbprod1 -s servprod -i dbprod11
PRKP-1030 : Failed to start the service servprod.
CRS-0215: Could not start resource ‘ora.dbprod1.servprod.dbprod12.srv’.

Status dos serviços:
[oracle@producao1 /u01/app/oracle/base10g/admin/dbprod1/bdump]$crs_stat -t
Name           Type           Target    State     Host
————————————————————
ora….11.inst application    ONLINE    ONLINE     producao1
ora….12.inst application    ONLINE    ONLINE     producao2
ora….s11.srv application    ONLINE    UNKNOW  producao1
ora….s12.srv application    ONLINE    ONLINE     producao2
ora.dbprod1.db  application    ONLINE    ONLINE    producao1
ora….11.inst application    ONLINE    ONLINE     producao1
ora….12.inst application    ONLINE    ONLINE     producao2
ora….servprod.cs application    ONLINE    ONLINE producao1
ora….l11.srv application    ONLINE    ONLINE     producao1
ora….l12.srv application    ONLINE    ONLINE     producao2

Reparem, o serviço referente a instância dbprod11 está com status de UNKNOW.

Solução:
[oracle@producao1 /u01/app/oracle/base10g/admin/dbprod1/bdump]$export ORACLE_SID=dbprod11
[oracle@producao1 /u01/app/oracle/base10g/admin/dbprod1/bdump]$sqlplus
SQL*Plus: Release 10.2.0.4.0 – Production on Mon Oct 24 09:41:27 2011
Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.
Enter user-name: sys as sysdba
Enter password:
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 – Production
With the Partitioning, Real Application Clusters, Data Mining Scoring Engine and Real Application Testing options
SQL> show parameter service_name
NAME                                 TYPE        VALUE
———————————— ———– ——————————
service_names                        string      servprod

SQL> exec DBMS_SERVICE.STOP_SERVICE(service_name =>’servprod’ ,instance_name => ‘dbprod11’);
PL/SQL procedure successfully completed.

Depois disso, podemos realizar o startup pelo srvctl

[oracle@producao1 /u01/app/oracle/base10g/admin/dbprod1/bdump]$srvctl start service -d dbprod1 -s servprod -i dbprod11

[oracle@producao1 /u01/app/oracle/base10g/admin/dbprod1/bdump]$crs_stat -t
Name           Type           Target    State     Host
————————————————————
ora….11.inst application    ONLINE    ONLINE   producao1
ora….12.inst application    ONLINE    ONLINE    producao2
ora….s11.srv application    ONLINE    ONLINE   producao1
ora….s12.srv application    ONLINE    ONLINE    producao2
ora.dbprod1.db  application    ONLINE    ONLINE    producao1
ora….11.inst application    ONLINE    ONLINE    producao1
ora….12.inst application    ONLINE    ONLINE    producao2
ora….servprod.cs application    ONLINE    ONLINE    producao1
ora….l11.srv application    ONLINE    ONLINE    producao1
ora….l12.srv application    ONLINE    ONLINE    producao2
ora….11.inst application    ONLINE    ONLINE    producao1
ora….12.inst application    ONLINE    ONLINE    producao2
ora….p11.srv application    ONLINE    ONLINE    producao1
ora….p12.srv application    ONLINE    ONLINE    producao2
ora….21.inst application    ONLINE    ONLINE    producao1
ora….22.inst application    ONLINE    ONLINE    producao2
ora….p21.srv application    ONLINE    ONLINE    producao1
ora….p22.srv application    ONLINE    ONLINE    producao2
ora….SM1.asm application    ONLINE    ONLINE    producao1
ora….SM2.asm application    ONLINE    ONLINE    producao2

 Tudo online.

Abraços e até o próximo erro.