ESTRUTURAS DE ARMAZENAMENTO

No banco existe uma abstração entre o armazenamento físico e o armazenamento lógico. O armazenamento lógico é feito em segmentos, um exemplo de segmento são as tabelas. Os segmentos são armazenados fisicamente em arquivos de dados, no disco. A abstração entre esses armazenamentos é feita pelas tablespaces, os relacionamentos entre as estruturas físicas e lógicas são mantidos no dicionário de dados.

As Estruturas Físicas

Os arquivos obrigatórios no banco de dados Oracle são: Arquivo de Controle (Controlfile), os Arquivos de Redo Log Online e os Arquivos de Dados (Datafile).

Os arquivos externos que normalmente estão presentes são: o Arquivo de Parâmetros de Inicialização, o Arquivo de Senha e os Arquivos de Redo Log Arquivados, além dos arquivos de log e de rastreamento.

Arquivo de Controle

É responsável pelos ponteiros para o restante do banco de dados: a localização do redo log online e dos arquivos de dados, e dos redo log arquivados mais recentes, se o banco estiver no modo archivelog. O arquivo de controle pode ser multiplexado, ou seja, pode ter várias cópias, essa é uma boa prática, a manutenção dos arquivos de cópia é o próprio banco que faz, você apenas definirá quantas cópias existirão.

Qualquer dano em qualquer cópia do arquivo de controle, fará com que a instância seja finalizada imediatamente. A Oracle não permite um banco funcionando com menor quantidade de arquivos de controle do que o que foi definido.

Arquivos de Redo Log Online

Armazena cada vetor de alteração que foi aplicado ao banco de dados, na ordem em que ocorreram. Se houver falha nos arquivos de dados ou todo o banco for danificado, os vetores poderão ser aplicados aos backups. O redo log é composto de dois tipos de arquivos: os arquivos de redo log online (que são obrigatórios) e os arquivos de redo log arquivados (que são opcionais). Cada banco de dados deve ter ao menos dois grupos de arquivos de redo log online para funcionar. Cada grupo deve ter ao menos dois membros por questão de segurança.

O LGWR grava o log de buffer no grupo de redo log online em uso (current), quando arquivo atual fica “cheio”, o LGWR passa a gravar no segundo grupo, que se torna então o atual. O outro redo log passa então a ser arquivado pelo ARCn, se o banco estiver o modo archivelog. E assim por diante, os grupos vão sendo revezados.

Arquivos de Dados

Deve haver no mínimo dois arquivos de dados, criados no momento da criação do banco de dados. Os arquivos de dados são o repositório de dados, as estruturas físicas visíveis para os administradores do sistema. Onde guardam-se os segmentos lógicos, em outras palavras é onde estão guardados de fato os dados do banco, fisicamente falando. Tudo o que você guarda no banco, nas tabelas, todos as entradas, tudo está guardado lá, o resultado final.

Os arquivos de dados podem ser renomeados, redimensionados, movidos, adicionados ou deletados a qualquer momento no tempo de vida do banco de dados, mas lembre-se de que algumas operações em alguns arquivos de dados podem requerer tempo de inatividade.

Outros Arquivos de Dados (Arquivos Externos)

São arquivos necessários, mas estão externos ao banco de dados, são eles: Arquivo de Parâmetros da Instância, Arquivo de Senhas (Password File), Arquivo de Redo Log Arquivado e o Arquivo de Rastreamento e Log de Alerta.

Arquivo de Parâmetro da Instância: defini os parâmetros para inicialização da instância, o único parâmetro requerido é o DB_NAME, para todos os outros existem valores padrões.

Arquivo de Senhas: Contém um pequeno número (normalmente, menor do que meia dúzia) de nomes de usuário e senhas existentes fora do dicionário de dados e que podem, portanto, ser usados para conectar a uma instância antes do dicionário ficar disponível.

Arquivo de Redo Log Arquivado: Arquivo que recebe o backup do redo log online.

Arquivo de Rastreamento e Log de Alerta: O log de alerta é um fluxo de gravação contínuo de mensagens referente a certas operações críticas que afetam a instância e o banco de dados. Nem tudo é registrado em log: somente os eventos considerados realmente importantes, como inicialização e shutdown, alterações às estruturas físicas do banco de dados e alterações aos parâmetros que controlam a instância. Os arquivos de rastreamento são gerados pelos processos de segundo plano quando eles detectam condições de erro e, às vezes, para reportar certas ações.

Estruturas Lógicas do Banco de Dados

São as estruturas com as quais o usuário interage, são os segmentos, que podem ser: Segmentos de Tabelas, Segmentos de Índices e Segmento de Undo.

As tabelas possuem as linhas de informações, os índices são mecanismos para fornecer acesso rápido a alguma linha específica e os segmentos de undo são estruturas de dados usadas para armazenar as informações necessárias para realizar o rollback de uma transação. Portanto, os administradores de sistema veem os arquivos de dados físicos e os programadores veem os segmentos lógicos, é por meio das tablespaces que acontece a abstração entre lógico e físico.

A Figura abaixo mostra a hierarquia de armazenamento de dados do Oracle, com a separação entre o armazenamento lógico e o físico.

O Dicionário de Dados

É um conjunto de metadados: dados sobre dados. Todo o banco é descrito no dicionário, tanto física quanto logicamente e sobre o seu conteúdo. Um conjunto de segmentos armazenados nas tablespaces SYSTEM e SYSAUX. Não é possível manipular o dicionário com instruções DML, apenas é possível consultar suas visões, a nível de DBA_, ALL_ ou USER_. O que será visto, depende do nível de permissões do usuário que está pesquisando (GRANT). A criação de um dicionário de dados é parte do processo de criação do banco de dados. Ele é mantido subsequentemente pelos comandos de linguagem de definição de dados. Quando você̂ emite o comando CREATE TABLE, está inserindo linhas nas tabelas do dicionário de dados, como quando emite comandos como CREATE USER ou GRANT.

Quem armazena as informações de relacionamento entre as tablespaces e os arquivos de dados é o arquivo de controle do banco, ele que lista os datafiles, e diz a qual tablespace pertencem, sem o Controlfile, não tem como localizar os arquivos que compõem a SYSTEM, por isso que o Controlfile é vital.

Qualquer consulta, bloco PL/SQL, fará acesso ao dicionário de dados. Verificando as estruturas mencionadas pelo código, validando, verificando a existência de grants, etc.

As Estruturas de Processos do Oracle

Um breve "olá"

Faz tempo que não posto nada, no entanto, objetivo é o exame 1Z0-052. Eu sei, já deveria ter feito, mas... Não deu, até agora. Estou voltando aos estudos, e vou tentar postar aqui o que eu puder acerca do conteúdo da segunda prova. O texto abaixo vai dar uma "explicada" nos principais processos de segundo plano do banco de dados. Espero que ajude, boa leitura.

Estrutura de Processos de Segundo Plano

O que são?

Os processos em segundo plano são aqueles que são iniciados juntamente quando a instância é iniciada e executados até que esta seja finalizada. Existem cinco processos que eu diria que são os principais: SMON – System Monitor, PMON – Process Monitor, DBWn – Database Writer, LGWRn – Log Writer, CKPT – Checkpoint Process. Em releases recentes, novos processos foram adicionados, tais como MMON – Manageability Monitor e o MMAN – Memory Manager. Outros não são essenciais, mas existirão em quase todas as instâncias, o ARCn – Archiver e o RECO – Recoverer.

SMON (System Monitor)

É responsável por montar e abrir o banco de dados. Monta o banco, localizando e validando o arquivo de controle. Depois, abre o banco, localizando e validando os arquivos de dados e os arquivos de log. Após aberto, o SMON cuida da organização doméstica da instância, como organizar o espaço no arquivo de dados.

PMON (Process Monitor)

O PMON monitora todos os processos de servidor e detecta os problemas com as sessões. Se uma sessão terminar de maneira anormal, o PMON destruirá o processo de servidor, retornará sua memória ao pool de memória livre do sistema operacional e executará rollback de todas as transações incompletas que possam estar em andamento.

DBWn (Database Writer)

As sessões não têm como regra geral gravar no disco, elas gravam em buffers no cache de buffer do banco, o DBWn que grava os dados no disco.

O DBWn grava os buffers sujos do cache de buffer no banco de dados, mas não assim que são “sujos”, pelo contrário, gravam o menor número de buffers possível, o suficiente para resolver o problema. Pois acessar ao disco prejudica o desempenho, quando uma sessão modifica em bloco é possível que o mesmo bloco seja modificado novamente, pela mesma sessão ou por uma sessão diferente. Em geral, serão gravados no disco buffers que tenham sido pouco acessados ou modificados recentemente. Gravar a menor quantidade possível, o mais raramente possível. Os DBWn gravaram caso não existam mais buffers livres, um excesso de buffer sujo, um tempo limite de 3 segundos quando o DBWn gravará alguns buffers e quando há um checkpoint, quando ocorre um checkpoint todos os buffers sujos serão gravados, o que causará uma diminuição no desempenho e os usuários reclamarão, o ideal é não utilizar checkpoints. Checkpoints automáticos ocorrem em processos de shutdown, quando a instância está sendo fechada, então os buffers são gravados a fim de que os arquivos de dados estejam sincronizados. O checkpoint forçado pode ser realizado com a instrução: alter system checkpoint.

Também existem os checkpoints parciais, que é quando um arquivo de dados ou tablespace é colocado em Offline, quando o tablespace é colocado no modo backup, quando o tablespace é configurado para somente leitura. São menos drásticos do que um checkpoint total e ocorrem apenas nessas circunstâncias.

LGWRn – Log Writer

O LGWRn grava o conteúdo do buffer de log nos arquivos de log no disco. Uma gravação do do buffer de log nos arquivos de redo log online é geralmente referenciada como fazer flush do buffer de log.

Quando você aplica uma alteração a um bloco no cache de buffer, o vetor dessa alteração é gravado o log de buffer, o LGWRn grava o conteúdo do buffer do log no redo log online no disco, praticamente em tempo real. Quando uma sessão emite um COMMIT, a sessão é suspensa enquanto o LGWRn grava o buffer no disco, após gravar, o commit é confirmado e a transação se torna irreversível. Existem três circunstancias que obrigarão o LGWR a fazer flush para o buffer de log: se uma sessão emitir um comando COMMIT, se o buffer de log estiver 1/3 completo e se o DBWn estiver para gravar buffers sujos.

CKPT (Checkpoint Process)

CKPT sinalização quando os buffers sujos devem ser gravados no disco. A partir da versão 8i passam a ser possíveis fazer checkpoints incrementais. O mecanismo de checkpoint incremental instrui o DBWn a gravar os buffers sujos a uma taxa constante, para que haja sempre um intervalo previsível entre o DBWn (que grava os blocos usando um algoritmo preguiçoso) e o LGWR (que grava os vetores de alteração praticamente em tempo real). Os checkpoints incrementais resultam em um desempenho muito mais suave e tempos de recuperação mais previsíveis do que o mecanismo de checkpoint completo mais antigo. Os checkpoints totais só ocorreram se houver uma solicitação do DBA ou como parte de uma processo de shutdown do banco de dados.

MMON (Manageability Monitor)

Processo introduzido após a versão 10g, é o processo de ativação de grande parte dos recursos de automonitoramento e autoajuste do banco de dados. O MMON guarda no dicionário de dados, informações que captura as estatísticas da SGA. Podem ser armazenadas indefinidamente, mas em geral ficam oito dias. O MMON também monitora o banco de dados e a instância para verificar se alertas devem ser disparados.

MMAN (Memory Manager)

O MMAN permite o gerenciamento automático de memória. Antes da versão 9i do banco de dados, o gerenciamento de memória no ambiente Oracle estava longe de ser satisfatório. A memória PGA associada aos processos de servidor de sessão era não transferível: o processo de servidor ocupava a memória do pool de memória livre do sistema operacional e nunca a retornava – mesmo que ela só́ fosse necessária por um curto período de tempo. As estruturas da memória SGA eram estáticas: definidas na hora da inicialização da instância e inalteráveis a menos que a instância fosse desligada e reiniciada.

A versão 9i mudou isso: as PGAs podem crescer e encolher, com o servidor passando memória para as sessões sob demanda, ao mesmo tempo garantindo que a memória PGA total alocada permaneça dentro de certos limites. A SGA e seus componentes (com a notável exceção do buffer de log) também pode ser redimensionada. A versão 10g automatizou o redimensionamento da SGA: o MMAN monitora a demanda por estruturas de memória SGA e pode redimensioná-las conforme o necessário. A versão 11g leva o gerenciamento de memória mais adiante: tudo o que o DBA precisa é definir um objetivo global para o uso da memória e o MMAN observará a de "manda pela memória PGA e a memória SGA e alocará a memória para as sessões e para as estruturas SGA conforme o necessário, mantendo o total de memória alocada dentro de um limite definido pelo DBA.

ARCn (Archiver)

Processo opcional do Oracle, mas geralmente muito utilizado no dia-a-dia empresarial. Todos os vetores de alteração aplicados aos blocos de dados são gravados no buffer de log (pelas sessões que fazem as alterações) e, em seguida, nos arquivos de redo log online (pelo LGWR). Os arquivos de redo log online são de número e tamanho fixos: uma vez que tenham sido preenchidos, o LGWR os sobrescreverá com mais dados de redo. O tempo decorrido antes que isso aconteça depende do tamanho e do número de arquivos de log online e da quantidade de atividade DML (e, portanto, a quantidade de informações de redo gerada) no banco de dados. Isso significa que o redo log online só́ armazena vetores de alteração de atividade recente. Para preservar um histórico completo de todas as alterações, os arquivos de log online devem ser copiados à medida que forem preenchidos e antes de serem reutilizados. O ARCn é responsável por isso. Desde que essas cópias, conhecidas como arquivos de redo log arquivados, estejam disponíveis, será́ sempre possível recuperar o banco de dados de qualquer dano restaurando os backups do arquivo de dados e aplicando neles os vetores de alteração extraídos de todos os arquivos de redo log arquivados gerados desde que os backups foram criados. Então, a recuperação final, que irá recuperar o backup atualizado, virá dos arquivos de redo log online. A maioria dos bancos de dados transacionais de produção executarão no modo archive log, o que significa que o ARCn é iniciado automaticamente e que o LGWR não pode sobrescrever um arquivo de log online até que o ARCn o tenha arquivado com êxito em um arquivo de log arquivado.

RECO (Recoverer Process)

Uma transação distribuída é uma transação que envolve atualizações a dois ou mais bancos de dados, é projetada por programadores e opera por meio de links de bancos de dados.

Considere este exemplo:

update employees set salary=salary * 1.1 where employee_id=1000;

update employees@dev set salary=salary * 1.1 where employee_id=1000;
commit;

A primeira atualização é aplicada a uma linha no banco de dados local. A segunda, a uma linha em um banco de dados remoto identificado pelo link de banco de dados DEV.

O comando COMMIT instrui os dois bancos de dados a confirmar a transação, que consiste em ambas as instruções. As transações distribuídas requerem um commit de duas fases (two phase commit). O commit em cada banco de dados deve ser coordenado: se um falhar e o outro for bem-sucedido, os dados globais estariam em um estado inconsistente. Um commit de duas fases prepara cada banco de dados instruindo seus LGWRs para fazer flush do buffer de log para o disco (a primeira fase) e uma vez que isso é confirmado, a transação é marcada como confirmada em todos os lugares (a segunda fase). Se algo sair errado em algum lugar entre as duas fases, o RECO assume o controle para cancelar o commit e fazer um rollback do trabalho em todos os bancos de dados.

Existem outros vários processos de segundo plano, os quais podem ser consultados com a instrução:

select program from v$process order by program;