Estruturas físicas de armazenamento

Veremos abaixo um pouquinho sobre cada uma das estruturas físicas de armazenamento do Oracle Database.

Datafiles

  • Um datafile corresponde a um único arquivo de sistema operacional no disco;
  • Cada datafile é membro de um tablespace, porém cada tablespace pode ter vários datafiles;
  • Um datafile pode expandir automaticamente quando atingir seu espaço alocado, através do parâmetro AUTOEXTEND;
  • Esta expansão pode ser limitada pelo parâmetro MAXSIZE;
  • Independente do caso acima, o tamanho de um datafile é limitado pelo espaço disponível do disco físico no qual ele reside;
  • O datafile é o local de armazenamento definitivo de todos os dados contidos no banco de dados;
  • Os blocos mais acessados em um datafile são armazenados em cache na memória (obviamente, somente enquanto a instância está aberta);
  • A gravação dos blocos alterados no cache da memória são gravados de forma assíncrona nos datafiles, e somente quando o processo database writer estiver ativo.

Redo Log Files

Sempre que forem adicionados, removidos ou alterados dados em uma tabela, índice ou outro objeto do Oracle, uma entrada será gravada no redo log file atual. O Oracle deve possuir pelo menos dois arquivos de redo log, porque ele utiliza de forma circular. Quando um redo log é preenchido até o limite, o próximo arquivo é reutilizado.

Quando ocorre alguma falha (por exemplo, falta de energia no servidor), alguns blocos de dados que foram atualizados no database buffer cache podem não ter sido gravados nos datafiles. Quando a instância for reinicializada, as entradas no redo log serão aplicadas aos datafiles do banco de dados em uma operação de roll-forward para restaurar o estado do banco de dados até o ponto em que a falha ocorreu.

É altamente recomendado que os arquivos de redo log sejam multiplexados, ou seja, tenham uma ou mais cópias ativas para garantir disponibilidade e integridade dos dados. A perda de um redo log que não tenha cópia pode causar perda de dados.

Archive Logs

O Oracle Database pode funcionar de dois modos: ARCHIVELOG ou NOARCHIVELOG.

O modo ARCHIVELOG envia um arquivo de redo log preenchido (após o mesmo sofrer um switch automático, quando o arquivo é totalmente preenchido, ou quando ocorre um switch log de forma manual) para um ou mais destinos especificados e podem ficar disponíveis para recuperação do banco de dados a qualquer momento – caso ocorra uma falha na mídia do banco de dados.

Se uma unidade de disco contendo datafiles falhar, o conteúdo do banco de dados pode ser recuperado até um determinado ponto no tempo antes da falha. Para isto é necessário: um backup recente dos datafiles, os arquivos de redo log e os archive logs gerados a partir do backup.

Em contrapartida, o modo NOARCHIVELOG não garante integridade do banco de dados na ocorrência de uma falha de instância ou de sistema. As trasanções que sofreram commit mas que ainda não foram gravadas nos datafiles estão disponíveis apenas nos arquivos de redo log online. Sendo assim, a recuperação de uma falha estará limitada às entradas existentes atualmente nos redo logs online. Se o último backup foi realizado antes do primeiro arquivo de redo log, então não será possível recuperar o banco de dados – os dados gerados após este backup serão perdidos.

Control Files

O Oracle tem pelo menos um controlfile que mantém os metadados do banco de dados. Metadados são os dados sobre a estrutura física do próprio banco de dados (as definições de tabelas e campos). Entre outros aspectos, o controlfile contém o nome do banco de dados, a data de criação do banco de dados, os nomes e localizações de todos os datafiles e redo log files. O controlfile também preserva informações utilizadas pelo RMAN (Recovery Manager), como configurações persistentes do RMAN e tipos de backups realizados.Sempre que ocorrem alterações na estrutura do banco de dados, as informações sobre essas mudanças serão imediatamente refletidas no controlfile.

O controlfile é um arquivo muito crítico para a operação do banco de dados, e por isso pode (e deve) ser multiplexado e copiado para backup com frequência.

Parameter Files

Os parameter files especificam as localizações dos trace logs, dos archive logs, entre outros arquivos. Também definem os limites para os tamanhos das diversas estruturas de memória existentes na SGA, a quantidade de usuários que podem se conectar simultaneamente ao banco de dados, dentre várias outras configurações.

São dois os tipos de parameter files:

  • PFILE: arquivo baseado em texto, comumente conhecido como init.ora (por padrão é definido como init<SID>.ora);
  • SPFILE: arquivo binário, por padrão é definido como spfile<SID>.ora;
Ao executar um startup, a instância procura primeiro um SPFILE na localização padrão do sistema operacional – $ORACLE_HOME/dbs no Unix ou Linux, por exemplo, como spfile<SID>.ora ou spfile.ora. Se nenhum dos dois for encontrado, a instância procura um PFILE chamado init<SID>.ora. Como alternativa, o comando STARTUP pode especificar explicitamente um PFILE a ser usado na inicialização do Oracle.
O PFILE, por ser um arquivo texto, pode ser manipulado sem maiores complicações. Pode ser editado manualmente para setar novos parâmetros, ou alterar valores de parâmetros já existentes.
O SPFILE é um arquivo binário, e jamais deve ser alterado manualmente – qualquer alteração irá danificar o arquivo. Apesar disto, o SPFILE é muito vantajoso pois torna mais eficaz o gerenciamento de parâmetros para o DBA. Se um SPFILE estiver sendo usado na instância em execução, qualquer comando ALTER SYSTEM que altere um parâmetro de inicialização poderá mudar automaticamente o parâmetro de inicialização no SPFILE, ou então mudar somente a instância em memória, ou ambos.
O SPFILE pode ser backupeado usando o RMAN. Além disso, é possível gerar um PFILE a partir de um SPFILE, e vice-versa. Esta tarefa é importante e deve ser feita com frequência, para efeitos de backup.

Alert Log e Trace Log

Quando algum tipo de problema ocorre na instância, o Oracle grava mensagens de erro no Alert Log. No caso de processos background ou sessões de usuário a gravação é feita em trace log.

Os trace logs e também o alert log são gravados no diretório especificado pelo parâmetro BACKGROUND_DUMP_DEST.

Alguns eventos que são gravados no Alert Log:

  • STARTUP ou SHUTDOWN do banco de dados;
  • lista dos parâmetros de inicialização que são carregados com valores diferentes do padrão;
  • comandos ALTER DATABASE  e comandos ALTER SYSTEM emitidos pelo DBA;
  • operações relacionadas aos tablespaces e aos respectivos datafiles;
  • condições de erro, como falta de espaço num tablespace, redo logs danificados,dentre quaisquer outras condições críticas.
Também são criados trace logs para sessões individuais dos usuários ou para conexões com o banco de dados. Esses trace logs estão localizados no diretório especificado pelo parâmetro USER_DUMP_DEST. Esses arquivos são criados em duas situações: quando ocorre algum tipo de erro em uma sessão do usuário (como um problema de privilégio, esgotamento de espaço, dentre outros); ou podem ser criados explicitamente com o comando:
ALTER SESSION SET SQL_TRACE=TRUE;
A informação de rastreamento é gerada para cada instrução SQL executada pelo usuário, o que pode ser útil para se ajustar a instrução SQL do usuário.

Backup Files

Os arquivos de backup podem se originar em algumas fontes, como os comandos de cópia do sistema operacional ou do Oracle RMAN. Se o DBA fizer um backup “a frio”, os arquivos de backup serão apenas cópias dos datafiles do sistema operacional, dos redo logs, dos controfiles, dos archive logs e de outros arquivos.

Além das cópias idênticas dos datafiles (padrão), o RMAN também pode gerar backups completos e incrementais dos datafiles, controlfiles, archive logs e spfiles em um formato especial, denominado backup sets, legível somente no RMAN.

Os backup sets geralmente são menores do que os arquivos originais de dados, pois o RMAN não copia os blocos não utilizados.

Posts relacionados:

OCP 11g – Arquitetura do Banco de Dados: Noções Básicas (parte 1)

OCP 11g – Arquitetura do Banco de Dados: Noções Básicas (parte 2)

OCP 11g – Arquitetura do Banco de Dados: Noções Básicas (parte 3)

OCP 11g – Arquitetura do Banco de Dados: Noções Básicas (parte 4)

Referência Bibliográfica

Este post, assim como todos os posts sobre Certificação OCP deste blog, são trechos do livro “OCP Oracle Database 11g – Administração II (Guia do Exame 1Z0-053)”, da editora Bookman – www.bookman.com.br
Recomendo este livro a todos que pretendem estudar para o exame. Meus posts são apenas algumas dicas para quem já está estudando por outros materiais, e por isso exige uma base de conhecimento anterior em cada um dos capitulos. Para uma referência completa de estudos é recomendado a compra do livro correspondente, bem como a documentação oficial da Oracle.