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.
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.
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.
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).
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.
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:
Se vocês encontrarem o erro java: not found quando estiverem tentando executar o cluvfy, zerem a variável de ambiente CV_JDKHOME.
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.
3 – O ID da linha é AACnayAAFAAAAaeAAk, em seguida, descrobriemos o bloco no qual a linha está armazenada
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
É possível especificar o DB Smart Flash Cache em uma tabela utilizando a opção FLASH_CACHE na clausula storage.
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.
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.
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.
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.