Componentes e Arquitetura Oracle

Para iniciar os estudos, você deve começas pelas instruções SQL essa é a segunda parte para um bom entendimento do uso do Oracle chamada de Administração I.

Visão geral dos componentes principais Oracle 

Servidor Oracle:

O servidor oracle consiste em uma instância e um banco de dados, é o sistema de gerenciamento de banco de dados.








Instância Oracle:

- È uma forma de acessar um banco de dados Oracle.
- Sempre abre um único banco de dados.
- Consiste em estruturas de memória e de processos de segundo plano.

Banco de Dados Oracle: 

- È um conjunto de dados tratados como uma unidade.
- Consiste em três tipos de arquivos. ( estrutura física - Arquivo de dados, arquivos de controle e arquivos de redo log)

Obs: arquivos de dados incluem dicionário de dados

Estrutura da memória

A estrutura de memória do Oracle consiste em duas áreas denominadas:

- SGA (system global area): Alocada na inicialização de uma instância, é um componente funamental de uma instância Oracle.

- PGA ( program global area): Alocada quando o processo do servidor é iniciado.


System Global Area

- È dinamica
- È dimensionada pelo parâmetro SGA_MAX_SIZE
- È alocada e rastreada em grânulos por componentes da SGA
  (O tamanho real da SGA sempre será igual ou menor do que SGA_MAX_SIZE, nunca excedendo este limite. Se o parâmetro SGA_MAX_SIZE não for configurado, o servidor assumirá o tamanho padrão para este parâmetro, que é o tamanho da SGA no momento da inicialização da instância.

Com exceção do buffer de log, todos os outros componentes da SGA são dimensionados em grânulos. Um grânulo é uma área de memória contígua. O tamanho dos grânulos depende da plataforma utilizada (Windows, Línux, Solaris) e varia de acordo com o tamanho total da SGA.

Para descobrirmos o tamanho de grânulos que estão sendo utilizados por uma instância, podemos consultar a visão V$SGAINFO) 

Ainda dentro da SGA: 

Shared Pool:

Usado para armazenar: 

- Intruções SQL executadas recentemente

- As definições de dados mais usadas recentemente

Shared pool consiste em duas estruturas principais de memória relacionadas ao desempenho;

 - Cache de Biblioteca

 - Cache de Dicionário de Dados

È dimensionado pelo parâmentro SHARED_POOL_SIZE

Cache de Biblioteca:

- Armazena as informações dosbre as instruções SQL e PL/SQL mais usadas recentemente.

- Permite o compartilhamento de instruções usadas normalmente.

- È gerenciado por um algoritmo LRU

- Consiste em duas estruturas:

   Àrea SQL compartilhada

   Àrea PL/SQL Compartilhada

- Tamanho determindado pelo dimensionamento do Shared Pool.

Cache de Buffer do Banco de Dados:

- Armazena cópias de blocos de dados recuperados dos arquivos de dados

- Possibilita ganhos de desempenho significativos quando você extrai e atualiza os dados

- Gerenciado por um algoritmo LRU

- DB_BLOCK_SIZE determina o tamanho do bloco principal.

- Consiste em subcaches independentes:

   db_cache_size

   db_keep_cache_size

   db_recycle_cache_size

- Pode ser redimensionado dinamicamente.

- DB_CACHE_ADVICE é definido para reunir estatísticas que prevêem um outro comportamento de tamanho de cache.

- Estatística exibidas pela view V$DB_CACHE_ADVICE

Os buffers ASH (Active Session History, ou Histórico da Sessão Ativa) armazenam informações relativas às atividades recentes dos usuários. Essas informações são utilizadas para diagnósticos de desempenho do servidor e são enviadas regularmente para o AWR (Repositório Automático de Carga de Trabalho do Oracle ) no tablespace SYSAUX.

Vale reforçar que todos os componentes do pool compartilhado são dimensionados automaticamente pela instância Oracle, ou seja, não temos controle sobre o tamanho de nenhum componente a não ser definindo o tamanho limite do pool compartilhado através do parâmetro dinâmico SHARED_POOL_SIZE.

Buffer Redo Log

- Registra as alterações feitas nos blocos de dados do banco de dados.

- O objetivo principal é a recuperação

- As alterações registradas são denominadas entradas de redo.

- As entradas de redo contrm informações para recrias ou refazer as alterações 

- Tamanho definido por LOG_BUFFER.

Large Pool

- Uma área de memória opcional na SGA

- Libera a carga imposta ao Large Pool

- Usado para:

   - Memória de sessão (UGA) para o servidor compartilhado

   - Processos do servidor E/S

   - Operações de backup e restauração ou RMAN

   - Buffers de mensagens de execução paralela ( PARALLEL_AUTOMATIC_TUNING definido como TRUE) 

  - Não usa uma lista LRU.

  - Dimensionado por LARGE_POOL_SIZE.

  - Pode ser redimensionado dinamicamente.

Java Pool 

- Atende aos requisitos de parse de comandos Java

- Necessário para instalar e usar Java

- Dimensionado pelo parâmetro JAVA_POOL_SIZE

Program Global Area

- Memória reservada para cada processo do usuário que se conecta a um banco de dados Oracle.

- Alocada quando um processo é criado

- Desalocada quando o processo é encerrado.

- Usada somente por um processo

Estrutura do processo

O Oracle aproceita vários tipos de processos:

- Processo do usuário: iniciado quando um usuário do banco de dados solicita uma conexão com o servidor Oracle.

-Processo Servidor: Conecta-se à instância Oracle e é iniciado quando um usuário estabelece uma sessão.

- Processo de segundo plano: Iniciados quando uma instância Oracle é iniciada.

Processo Usuário: 

- Um programa solicita a interação com o servidor Oracle.

- Deve Estabelecer primeiro uma conexão 

- Não interage diretamente com o servidor Oracle.

Processo Servidor:

- Um programa que interage diretamente com o servidor Oracle

- Atende às chamadas geradas e retorna resultados 

- Pode usar um servidor dedicado ou compartilhado

Processo Segundo Plano

Mantem e Impõe relacionamentos entre as estruturas físicas e de memória:

Processos de segundo plano obrigatórios:

DBWn     PMON  CKPT

LGWR  SMON

 Processos de segundo plano opcionais:

ARCn      LMDn     QMNn

CJQ0        LMON    RECO

Dnnn        LMS        Snnn

LCKn       Pnnn

DBWn ( Database Writer )

Abaixo segue a definição mais simples e objetiva que encontrei;

O processo database writer (DBWR) escreve os blocos modificados do database buffer cache para os arquivos de dados físicos. O DBWR não precisa escrever os dados a cada comando COMMIT, pois é otimizado para minimizar o I/O. Geralmente o DBWR escreve os dados para o disco se muitos dados são lidos para o database buffer cache na SGA e não existe espaço livre para esses novos dados. Os dados menos recentemente usados são escritos para os arquivos de dados em primeiro lugar.

Read more: http://www.linhadecodigo.com.br/artigo/99/a-arquitetura-do-oracle.aspx#ixzz3epmpdwpW


DBWn  ou DBWr Grava quando:

- Ocorre Checkpoint
- Os Buffers sujos atingem o limite
- Não há buffers Livres
- Ocorreu timeout
- È feita uma solicitação de ping RAC
- Tablespace Offline
- Tablespace READ ONLY
- Eliminação ou truncamento de tabela
- Tablespace BEGIN BACKUP

LGWR ( Log Writer) 

O processo log writer (LGWR) escreve todas as entradas de redo log para o disco. Os dados de redo log são armazenados em memória no redo log buffer cache, na SGA. No momento em que uma transação for efetivada com o comando COMMIT e o redo log buffer estiver preenchido, o LGWR escreve as entradas de redo log nos arquivos redo log apropriados.

Read more: http://www.linhadecodigo.com.br/artigo/99/a-arquitetura-do-oracle.aspx#ixzz3epnp3K5b

Grava quando:

- No commit
- Quando 1/3 está cheio
- Quando há 1Mb de Redo
- A cada 3 segundos
- Antes que o DBWn grave


SMON (System Monitor) 

O processo system monitor (SMON) efetua a recuperação da instância em caso de falhas, durante a sua inicialização. Em um sistema com múltiplas instâncias (como na configuração Oracle Parallel Server, por exemplo), o processo SMON de uma instância também pode executar a recuperação de outras instâncias que podem ter falhado. Ele também limpa os segmentos temporários que não estão sendo usados, liberando memória, e recupera qualquer transação pendente no caso de uma falha em arquivos físicos ou mesmo no disco. O processo de recuperação dessas transações é executado pelo processo SMON quando a tablespace afetada volta a ficar disponível.

Read more: http://www.linhadecodigo.com.br/artigo/99/a-arquitetura-do-oracle.aspx#ixzz3epo3CkJC


Responsabilidades:

- Recuperação de instância
   - Efetua rollforward de alterações em arquivos de redo log on-line
   - Abre o banco de dados para o acesso dos usuários
   - Efetua Rollback de transações não submetidas a commit
   - Aglutina o espaço livre
   - Desaloca Segmentos temporários


PMON (Process Monitor)

O process monitor (PMON) executa a recuperação do processo de um usuário quando esse processo falha. Limpa a área de memória e libera os recursos que o processo do usuário estava usando. O PMON também verifica o processo despachante (dispatcher) e os processos servidores (server processes) e os reinicializa se tiver acontecido qualquer falha.

Read more: http://www.linhadecodigo.com.br/artigo/99/a-arquitetura-do-oracle.aspx#ixzz3epoBjvcN

Realiza uma limpaza após falhas de processos por meio de:

 - Rollback da transação
 - Liberação de bloqueios
 - Liberação de outros recursos
 - Reinicialização de dispatchers inativos

CKPT ( Checkpoint)

Responsável por:

 - Sinalizar o DBWn em checkpoints
 - Atualizar as informações de checkpoint nos cabeçalhos dos arquivos de dados
 - Atualizar as informações de checkpoint nos arquivos de controle


ARCn ( Archived) 

O processo archiver (ARCH) copia os arquivos redo log para fita ou mesmo outro disco, no momento em que um deles torna-se completo. Esse processo geralmente está presente quando o banco de dados está sendo utilizado no modo ARCHIVELOG. Os arquivos redo log nada têm a ver com auditoria. Eles são usados somente para a recuperação de um banco de dados.

Read more: http://www.linhadecodigo.com.br/artigo/99/a-arquitetura-do-oracle.aspx#ixzz3epoEnGs6

- Processos de segundo plano opcional
- Arquiva automaticamente os redo logs on-line qunado o modo ARCHEVELOG é definido
- Preserva o registro de todas as alterações feitas no banco de dados.



RECO   processo recoverer usado para resolver transações distribuídas pendentes causadas por uma falha na rede em um sistema de bancos de dados distribuídos. A certos intervalos de tempo, o processo RECO do banco de dados local tenta conectar-se ao banco de dados remoto para automaticamente completar e efetivar a transação (COMMIT) ou descartar (ROLLBACK) a porção local de uma transação pendente em um sistema distribuído.

Dnnn  processos em background dispatchers são opcionais e estão presentes somente quando a configuração do Oracle Multi-thread Server é usada. Pelo menos um processo dispatcher é criado para cada protocolo de comunicação em uso (D000, D0001, ..., Dnnn). Cada processo dispatcher é responsável pelo direcionamento das requisições dos processos dos usuários conectados ao banco de dados para o processo servidor disponível e pelo retorno da resposta de volta para o processo do usuário apropriado.

LCKn Processos lock são usados para controlar lock entre instâncias em uma configuração Parallel Server.