Compreendendo as seções do AWR

Neste artigo iremos repassar as várias seções do AWR e os significados de cada uma das seções.

O relatório AWR é dividido em várias seções.

1)    Instance Information: Nesta seção são apresentadas as informações do nome da instância, número da instância, os id’s dos “snapshots” (intervalo que o relatório foi gerado), o tempo total para a geração do relatório e o tempo de execução no banco de dados.

Tempo decorrido = (tempo final - tempo inicial)

Tempo do banco de dados = É o trabalho realizado pelo banco de dados durante o tempo decorrido (CPU e I/O). Se o tempo for menor que o tempo decorrido por uma margem muito grande e o banco de dados estiver ocioso. Tempo de banco de dados não inclui o tempo utilizado pelos processos de “background”.

2)       Cache Sizes: Essa seção mostra o tamanho de cada região SGA. Esta informação pode ser comparada aos parâmetros do arquivo de inicialização “init.ora” que são apresentados no final do relatório.

3)       Load Profile: Esta seção apresenta as taxas de sobrecarga no banco de dados, as unidades são expressas em unidades de transações por segundo por segundo. Isto é muito importante para a compreensão de como a instância está se comportando. Essa informação deve ser comparada ao relatório de (baseline) para que se possa compreender as sobrecargas esperadas do servidor e sua variação (DELTA) dentro dos piores tempos (possibilidade de previsão de sobrecargas).

4)     Instance Efficiency Percentages (Target 100%): Esta seção apresenta informações sobre as relações vitais do “buffer cache”, da “library cache”, e dos “parses” entre outros. Estes valores podem ser tomados como indicadores, mas não devem ser uma causa de preocupação, se eles estiverem baixos. As atividades do banco de dados podem ser menores ou maiores que esses indicadores o que não representam um problema real de desempenho.

5)   Shared Pool Statistics: Sessão que resume as alterações na área de “shared pool” durante o intervalo solicitado no relatório.

6)     Top 5 Timed Events: Esta é a seção mais relevante para a análise. Nesta seção pode-se verificar o percentual de tempo no banco de dados e quais os eventos estão gerando espera.

7)     RAC Statistics: Nesta seção somente é utilizada para bases de dados em cluster (RAC). As informações fornecidas nessa seção indicam o tempo médio para a transferência de blocos entre os nós, o recebimento de mensagens entre os nós que podem apontar problemas de desempenho do cluster em vez de banco de dados.

8)      Wait Class: Esta seção apresenta as classes de espera no banco de dados, que apresentam  contenções e onde é necessário foco para os ajustes. As classes de esperas informadas são referente à rede, concorrência, ao cluster,  I/O,  aplicações, configurações.

9)    Wait Events Statistics Section: Esta seção apresenta os eventos principais espera do banco de dados incluindo processos de “background” e “foreground” e também o tempo de espera pelo sistema operacional, serviços e estatísticas das classes de espera.

10)    Wait Events: Esta seção fornece os detalhes sobre as informações dos eventos de espera dos processos em “foreground” a sessão inclui também os eventos de espera (Top 5) e muitos outros eventos gerados durante o intervalo especificado para a geração do relatório.

11)   Background Wait Events: Esta seção apresenta os eventos dos processos de “background” relevantes.

12)    Time Model Statistics: Relata como o tempo de processamento do banco de dados é gasto. Esta seção contém informações detalhadas de tempo e determinados componentes que participam no processamento de banco de dados. Fornece informações sobre o tempo dos processos em “background” e também dos tempos que não estão incluídos no tempo do banco de dados.

13)   Operating System Statistics: Esta seção é importante porque apresenta a contenção sob a ótica do sistema operacional. Esta seção mostra os principais recursos externos, incluindo I/O, CPU, memória e uso de rede.

14)   Service Statistics: Fornece informações sobre as estatísticas dos serviços e as cargas correspondentes em termos de segundos de CPU, segundos de I/O, número de buffers lidos, etc.

15)   SQL Section: Esta seção exibe as consultas de SQL com maior consumo no banco de dados (Top SQL), ordenado por métricas importantes.

a.      SQL Ordered by Elapsed Time: Apresenta os comandos SQL que tiveram um tempo significativo de execução durante o processamento.

b.    SQL Ordered by CPU Time: Apresenta os comandos SQL que consumiram tempo significativo de CPU durante o processamento.

c.      SQL Ordered by Gets: Apresenta os comandos SQL com grande número de leituras lógicas.

d.    SQL Ordered by Reads: Apresenta os comandos SQL com um elevado número de leituras físicas em disco.

e.      SQL Ordered by Parse Calls: Apresenta os comandos SQL com um elevado número de operações de “reparsing”.

f.    SQL Ordered by Sharable Memory: Apresenta os comandos SQL, incluindo os cursores que consumiram uma grande quantidade de SGA (shared pool area).

g.    SQL Ordered by Version Count: Apresenta os comandos SQL que têm um grande número de versões na “shared pool area”.

16) Instance Activity Stats: Esta seção contém informações estatísticas que descrevem como o banco de dados está operando durante o intervalo especificado para a geração do relatório.

17) I/O Section: Nesta seção são apresentados as atividades de I/O. Fornece o tempo para realizar uma operação de I/O que equivale dizer Av Rd(ms) e o I/O por segundo equivale dizer Av Rd/s. As informações devem ser comparadas com as informações do relatório de  (baseline) para verificar se a taxa de I/O mantém uma constância ou se houve uma divergência.

18) Advisory Section: Esta seção mostra detalhes dos alertas sobre o “buffer”, “shared pool”  PGA da Java Pool.

19) Buffer Wait Statistics: Esta seção apresenta as estatísticas do “buffer cache”.

20) Enqueue Activity: Esta seção apresenta as atividades das filas de operações do banco de dados. As filas de operações são estruturas internas especiais que fornecem acesso simultâneo a vários recursos de banco de dados.

21) Undo Segment Summary: Esta seção apresenta um resumo sobre como os segmentos de UNDO são utilizados pelo banco de dados. Esta seção mostra informações históricas sobre a atividade do segmento de UNDO.

22) Latch Activity: Nesta seção apresenta detalhes sobre as estatísticas de “latchs”. Os “latchs” são um mecanismo de serialização usado para acesso de um “thread” nas estruturas internas do banco de dados. Os “latchs” devem ser verificados por seus processos.

23) Segment Section: Esta seção é importante para a verificação das contenções no banco de dados. Eventos de espera - TOP 5.

-    Segments by Logical Reads: Inclui os segmentos com maior número de leituras lógicas (logical disk reads).

-    Segments by Physical Reads: Inclui os segmentos com alto número de leituras físicas (physical disk reads).

-      Segments by Buffer Busy Waits: Apresenta os segmentos com o maior número de espera por “buffers”, causado pelo acesso dos blocos de dados.

-      Segments by Row Lock Waits: Inclui os segmentos que possuem um grande número de bloqueios de linha em seus dados.

-    Segments by ITL Waits: Inclui os segmentos que tem grande contenção (ITL). A contenção de ITL (Interested Transaction List) que pode ser reduzida aumentando INITRANS parâmetro de armazenamento da tabela.

24) Dictionary Cache Stats: Esta seção apresenta os detalhes sobre o funcionamento do dicionário de cache.

25) Library Cache Activity: Inclui as estatísticas da “library cache” que estão sendo utilizadas nos eventos de espera TOP 5. Pode-se verificar se as recargas ou invalidações estão causando contenções ou se há algum outro problema com a “library cache”.

26) SGA Memory Summary: Essa seção apresenta os resumos de utilização de memória da SGA. Este indicador define o valor mínimo para cada um, quando o parâmetro SGA_TARGET está sendo usado.

27) Init.ora Parameters: Esta seção mostra os parâmetros que estão configurados para o banco de dados. 

MSc. Rubens Oliveira

DBA Oracle Consultor

olivert.dba@consultant.com

Oracle NoSQL

Neste artigo introdutório, estarei abordando sobre o Oracle NoSQL.

Oracle NOSQL, o que é?

O termo “NoSQL” surgiu em 1998, a partir de uma solução de banco de dados que não oferecia uma interface SQL, mas esse sistema ainda era baseado na arquitetura relacional.

O termo passou a representar soluções que promoviam uma alternativa ao Modelo Relacional, tornando-se uma abreviação de Not Only SQL (não apenas SQL).

O propósito das soluções NoSQL não é substituir  o Modelo Relacional como um todo, mas apenas em casos nos quais  seja  necessária  uma  maior  flexibilidade  da  estruturação do  banco. 

Em português já existe o acrônimo MRNN para Modelo Relacional Não-Normalizado.

Os gerenciadores de banco de dados de larga escala têm sido caracterizados pelas propriedades ACID transacionais de Atomicidade, Consistência, Isolamento e Durabilidade. Em contraste, NoSQL, por vezes, é caracterizada pela sigla BASE, que aceita os conflitos acontecerão durante as transações.

Características:

§     Disponibilidade básica: Utiliza a replicação para reduzir a probabilidade de indisponibilidade de dados e utiliza a fragmentação (denominada “sharding”) para particionar os dados entre vários servidores diferentes, permitindo que no caso de qualquer falha entre os servidores a informação possa ser disponibilizada parcialmente. Esta característica apresenta um sistema sempre disponível, mesmo que os subconjuntos de dados se tornem indisponíveis por curtos períodos de tempo.

§     Estado SOFT: Enquanto bancos de dados relacionais assumem que a consistência dos dados que é um requisito difícil. Nos bancos NoSQL é possível ter dados inconsistentes e relegar a concepção em torno das inconsistências.

§   Consistência eventual: Embora aplicativos trabalhem com consistência instantânea, sistemas NoSQL certificam-se que, em algum momento futuro os dados serão consistidos. Em contraste com bancos de dados relacionais a consistência deve ser confirmação da transação, o banco NoSQL garante consistência apenas em algum momento futuro indefinido.

O banco de dados NoSQL Oracle é um banco de dados baseado em “valores-chave” distribuídos. Foi projetado para fornecer armazenamento de dados altamente confiável, escalável e disponível através de um conjunto configurável de sistemas que funcionam como nós de armazenamento.

O “driver” de acesso ao banco de dados NoSQL inclui os algoritmos de “hash” para garantir a distribuição adequada de dados, bem como informações de desempenho e de estado sobre cada nó de armazenamento que lhe permitam fornecer balanceamento de carga ideal e processamento da consulta. O banco de dados NoSQL fornece fácil administração por meio de uma interface de linha de comando ou console web.

O Oracle NoSQL, possui uma arquitetura " No Single Point of Failure " que é uma solução que permite acessar os dados de modo direto e rápido sem exigir latência de soluções de gerenciamento de dados tradicional.

Por exemplo, dados de sites da “web” com alto volume, processamento de eventos de alta produtividade e redes de comunicações sociais representam domínios de aplicativos que produzem volumes extraordinários de dados com chaves simples.

Os dados são armazenados como pares de “valores-chave”, que são escritos para nós de armaze-namento específico, com base no valor de “hash” da chave primária. Nós de armazenamento são replicados para garantir alta disponibilidade, para executar um “failover” rápido no caso de uma falha de nó e o balanceamento cargas nas consultas.

ARQUITETURA

Principais características:

§  Simplicidade no modelo de dados

§  Escalabilidade

§  Comportamento previsível

§  Alta disponibilidade

§  Fácil administração

O banco de dados Oracle NoSQL possui um serviço de administração, acessível a partir de uma interface de linha de comando ou por uma “console web”. Através do serviço de administração os DBAs podem configurar uma instância de banco de dados, iniciá-lo, pará-lo e monitorar o desempenho, sem necessitar editar arquivos de configuração manualmente, escrever “shell scripts” ou executar consultas no banco de dados.

Além de fornecer um ponto único de registro operações, o Oracle NoSQL tem a capacidade de reunir uma coleção de operações usando o método “execute”, fornecendo uma semântica transacional entre várias atualizações em registros com o mesmo “Major Key Path”.

O Oracle NoSQL usa a replicação de dados para garantir a disponibilidade dos dados em caso de falha. A arquitetura propaga a partir de um nó mestre. Para o caso de falhas do nó mestre, os nós do grupo de replicação automaticamente escolhem novo nó para tornar-se o replicador (usando o protocolo de Paxos).

Rubens Oliveira

DBA Oracle Consultor

olivert.dba@consultant.com