Arquitetura do Oracle Database – Parte 1

2.1 – Datafiles

Todo Oracle Database tem um ou mais Datafiles, eles contém todos os dados do Banco de Dados (então pode ter certeza que você terá vários dele!).
Os dados da estrutura lógica do database, como tabela e índices, são armazenados fisicamente no disco como Datafiles.

Características:

• Os Datafiles só podem ser associados somente a um banco de dados.
• Datafiles podem ter determinadas características definidas para deixá-los estender automaticamente quando o banco de dados é executado fora do espaço.
• Um ou mais Datafiles formam uma unidade lógica de armazenamento do banco de dados chamado Tablespace (veremos mais a frente o que é)

Dados dentro de um Datafile é lido, conforme necessário, durante operações do banco de dados do qual é armazenado em um cache de memória do Oracle. Por exemplo, vamos supor que o usuário que acessar alguns dados dentro de uma tabela do banco de dados, se o dado requisitado não estiver pronto no cache do database, então esse dado é lido do datafiles apropriado e armazenado na memória.

Quando modificado ou inserido novos dados eles não são necessariamente escrito imediatamente nos datafiles. Para reduzir a quantidade de acesso ao disco e o aumento de performance, os dados são primeiramente armazenados na memória e escrito ao seus apropriados datafiles depois tudo de uma vez só. Esse processo funciona como foi determinado pelo “database writer process” (DBWn) que é um processo background do banco de dados.

2.2 - Control Files

Todo database Oracle tem um control file. O control file contém entradas que são especificadas na estrutura física do banco de dados. Ele contém as seguintes informações:

• Nome do Banco de Dados
• Nomes e locais de datafiles e redo log files
• Time stamp do database

Oracle pode multiplexar o control file, para que eles mantenham simultaneamente um número de identificação de cópias, para a proteção contra falhas envolvidas no control file.

Oracle can multiplex the control file, that is, simultaneously maintain a number of identical control file copies, to protect against a failure involving the control file.

Toda vez que uma instância do banco de dados Oracle é iniciado, é o control file que identifica o database e o redo log files que devem ser abertos para que a operação de iniciar proceda. Se a composição física do banco de dados é alterado (por exemplo, se um novo datafile ou redo log file é criado), o control file é automaticamente modificado pelo Oracle refletindo as modificações ocorridas. O control file é também utilizado no recovery de um banco de dados.

2.3 - Redo Log Files

Todo banco de dados Oracle tem um conjunto de dois ou mais redo log files. O conjunto de redo log files é normalmente chamado apenas de redo log do banco de dados. O redo log é feito de entradas de redo (também conhecidas como redo records).

A função primária do redo log é gravar todas as modificações de dados. Se ocorre uma falha e digamos que os dados já estejam permanentemente escritos nos seus datafiles,as modificações podem ser obtidas do redo log, corrigindo a o problema. Por exemplo, você altera 1000 registros no banco de dados errôenamente, todas essas modificações estarão no redo log, você não perderá seus dados.

Para proteger falhas envolvendo o próprio redo log, Oracle permite miltiplexar redo log para duas ou mais cópias podendo assim ser mantidas em diferentes discos rígidos.

A informação dentro do redo log file é utilizada somente para recuperar o banco de dados de um sistema ou mídia de uma falha que impeça os dados do database sejam escritos nos seus datafiles. Por exemplo, se uma queda de luz desliga o servidor no meio de sua operação, e não deu tempo dos dados que estavam na memória de serem escritos nos datafiles, esses dados foram perdidos. Porém… esses dados perdidos podem ser recuperados quando o banco de dados é iniciado novamente após a volta da queda de energia. Ao aplicar as informações mais recentes contidas no redo log files aos datafiles do database, Oracle restaura o banco de dados para o momento que ocorreu a queda de energia.

O processo de aplicar o redo log durante a operação de recovery é chamada de rolling forward.

2.4 - Archive Log Files

Você pode habilitar arquivamento automático do redo log. O Oracle automaticamente arquiva arquivos de log quando o banco de dados está no modo ARCHIVELOG (isso será visto mais para frente no decorrer da série, por enquanto não se preocupe com isso por enquanto).

2.5 - Parameter Files

Parameter files contém uma lista de parâmetros de configuração para a sua instância do banco de dados.

A Oracle recomenda que você crie um arquivo de parâmetro do servidor, conhecido como SPFILE (Server Parameter File) como um meio de manter a dinâmica de inicialização do parâmetro. Um SPFILE permite que você armazene e gerencie seus parâmetros de inicialização em um arquivo no disco do servidor.

2.6 - Alert e Trace Log Files

Cada servidor e processo de background pode escrever um associado trace file.Quando um erro interno é detectado pelo processo, ele despeja informações sobre o seu erro em um trace file. Algumas das informações escritas nos trace files são destinadas para adminstrados de banco de dados (DBA), enquanto outras informações são para o Serviço de Suporte Oracle (Oracle Support Services). Informações do trace file também são utilizadas para fazer tuning em aplicações e instâncias.

O alert file, ou alert log, é um trace file especial. O alert log do banco de dados é um log cronológico de mensagens e erros.

2.7 - Backup Files

Para restaurar um arquivo é necessário substitui-lo com um arquivo de backup. Geralmente, você restaura um arquivo quando tem erro no disco ou quando um erro causado pelo usuário (coisa difícil de acontecer) danifica ou deleta o arquivo original.

Backup e Recovery gerenciado por usuário requer realmente que você crie os arquivos de backup antes de você poder recupera-los, fazendo tudo manualmente.

Backup e Recovery gerenciado pelo servidor, através de processos de backup, como o scheduling of backups, e  como o recovery process, é aplicado para o correto recovery de acordo com os arquivos de backup necessário.