Conheça as características de um banco de dados

O Banco é formado por dois componentes principais: a instância que é o componente lógico e o banco de dados que é o componente físico. A instância é uma estrutura em memória composta por processos de segundo plano e pela System Global Area (SGA), que trata-se de uma área de memória compartilhada alocada na inicialização do BD. Ela contém também as estruturas de memória utilizadas para armazenar blocos de dados que são frequentemente acessados, além de controlar informações.

De forma geral, a SGA apresenta três estruturas de dados principais:

• a database buffer cache, que contém blocos de dados obtidos a partir dos arquivos de dados, sendo um recurso compartilhado e acessado por todos os usuários, onde, ao executar uma consulta, o Banco de Dados busca a informação nesta área e somente caso não a encontre, acessará os arquivos de dados. Com isso temos uma redução de acesso ao disco;
• a redo log buffer, que é um buffer circular que contém as mudanças efetuadas no Banco de Dados, ou seja, cada operação DML (Data Manipulation Language) está registrada nesse buffer e posteriormente é gravada no arquivo redo log. Com isso permite que essas informações possam ser utilizadas para executar a recuperação de um ou mais arquivos de dados;
• a shared pool contém informações do Dicionário de Dados (DD), as últimas instruções executadas e o plano de execução. Esses pools melhoram consideravelmente o desempenho do banco, pois ao executarmos uma operação repetidas vezes, não é necessário recriar o plano de execução durante a fase de parse. Este buffer é composto por pelo menos duas áreas distintas: o library cache e o data dictionary cache.

A SGA também possui estruturas de memória opcionais como a Large pool que é utilizada quando há a necessidade de tratarmos operações que envolvam mais de um banco de dados, atuando assim como um buffer de mensagens para processos, executando consultas paralelas, operações paralelas de backup e recuperação, usando o software RMAN.

O Java pool é utilizado pela Java Virtual Machine (JVM) da Oracle em todos os dados e códigos Java de uma sessão do usuário. O Streams pool é utilizado para gerenciar o compartilhamento de dados e eventos em um ambiente distribuído.

Agora que falamos da SGA podemos falar dos processos de segundo plano, ou também chamados de processos de background, pois estes também partem das estruturas de memória e monitoram processos específicos do banco de dados. Cada instância do banco executa pelo menos cinco processos em segundo plano: CKPT, DVWR, LGWR, SMON e PMON. Porém, podem haver processos adicionais. Os processos de segundo plano concentram diferentes funções que são compartilhadas por todos os usuários, o que evita a carga e a execução de vários programas pelos usuários.

O Banco de dados também é representado pelo componente físico que consiste nos seguintes arquivos:

• datafile ou arquivo de dados é quem armazena dados das tabelas, índices, entre outros;
• control file ou arquivo de controle é quem armazena informações para manter e verificar a integridade do banco de dados, como o seu nome, o timestamp, nomes e local de arquivos de dados e de redo log. As informações que estão nos arquivos de controle são utilizadas para identificar os arquivos de dados e de redo log;
• o redo log file representa um conjunto de arquivos que tem a função de registrar todas as alterações realizadas no banco de dados e são utilizados para a recuperação do banco de dados em caso de alguma falha. Uma obrigação que é imposta aos redo log files é que estes sejam multiplexados em discos diferentes para evitar a sua perda, assim é necessário que tenhamos no mínimo dois arquivos redo log. A instância do banco de dados trata os grupos de redo log on-line como um buffer circular, ou seja, é preenchido um grupo e, depois, passa-se para o próximo grupo. Depois que todos os grupos já foram gravados, a instância passa a sobregravar as informações no primeiro grupo de logs. No entanto, se o banco estiver em modo archivelog (ou modo de arquivamento), o banco fará uma cópia do grupo de redo log antes de ser sobre gravado.

Ainda existem outros arquivos essenciais para o bom funcionamento do banco de dados, mas que não são considerados como arquivos do banco. São eles:

• o parameter file é um arquivo texto (chamado PFILE) ou um arquivo binário (chamado SPFILE) essencial para iniciar uma instância Oracle que é responsável pelas características e comportamento da instância, sendo usado para trabalhar diretamente com a memória da máquina e com as estruturas físicas do banco de dados;
• o password file é responsável por conter a senha dos administradores;
• o archivelog file é responsável por manter o histórico de todos os arquivos de redo log gerados pela instância, e com o uso destes arquivos, além de um arquivo de backup, podemos recuperar todos os dados de um ou mais arquivos perdidos;
• os trace file e o alert file são responsáveis por manter o registro sequencial de todas as operações consideradas críticas no banco de dados, assim como alterações na estrutura física do banco, alternância de arquivos de redo log, parada, início do banco de dados e condições de erro.

Uma última característica importante do banco de dados são as variáveis de ambientes criadas automaticamente na instalação do banco de dados. São elas:

• ORACLE_BASE que contém a árvore de diretórios para o Oracle e arquivos de dados do banco de dados
• ORACLE_HOME que contém a localização do Oracle e os arquivos de configuração.

Essas variáveis de ambiente possibilitam ao administrador o acesso a importantes informações para a administração do banco de dados.

Privilégios e Operações

O DBA precisa de um usuário com permissão de administrador para executar as tarefas necessárias no banco de dados. Assim, o BD cria automaticamente os usuários SYS e SYSTEM, que já possuem os privilégios suficientes e necessários para a administração do banco. Também é permitido que seja utilizado o SYS com o tipo de conexão SYSDBA ou SYSOPER.

Segue na Listagem 1 exemplos de como podemos nos conectar ao banco de dados através do CMD. Não esqueça de executar o CMD como administrador.

  C:\> sqlplus
  SQL> connect system
  SQL> password> *****

Outra forma também é chamando diretamente o sqlplus definindo o usuário SYSTEM e a respectiva senha:

C:\> sqlplus system/senha

Além disso, outra forma é utilizando o usuário SYS e se conectando ao banco como sysdba conforme abaixo:

C:\> sqlplus sys/senha as sysdba

Por fim, também podemos abrir uma sessão e se conectar como sysoper conforme abaixo:

C:\> sqlplus sys/senha as sysoper

Podemos verificar acima dois tipos de conexão, uma como sysoper e outra como sysdba, e também dois tipos de usuários SYS e SYSTEM. O usuário SYS tem poderes para executar qualquer função administrativa no banco de dados. O usuário SYSTEM pode ser usado para operações rotineiras do DBA, além de possuir os mesmos privilégios do usuário SYS, porém não pode executar operações de upgrade, backup e recuperação. As tabelas base e as views do DD são armazenadas no schemaSYS e são críticas para o funcionamento do banco de dados; podendo ser manipuladas apenas pelo próprio banco de dados.

Quando realizamos a conexão como sysoper apenas é permitido executarmos os comandos:

• STARTUP - para iniciar a instância do banco de dados podendo inclusive montar e abrir o banco de dados na inicialização através de parâmetros;
• SHUTDOWN - para encerrar a instância, desmontar e fechar o banco de dados;
• ALTER DATABASE ou TABLESPACE - para modificar, recuperar ou realizar manutenções no banco de dados;
• RECOVER - para recuperar a mídia de uma ou mais tablespaces, de um ou mais arquivos de dados ou do banco de dados inteiro;
• e RESTRICTED SESSION - para colocar o banco de dados em modo restrito para realizarmos a manutenção na base de dados sem a possibilidade de acesso de novos usuários na instância corrente.

Um procedimento bastante importante que deve ser realizado pelos DBAs são as instruções referentes ao backup. A instrução ALTER DATABASE [BEGIN ou END] BACKUP ou ALTER TABLESPACE [BEGIN ou END] BACKUP permite a execução de um backup gerenciado pelo usuário, ou seja, utilizando comandos do sistema operacional. Por exemplo, a instrução ALTER TABLESPACE users BEGIN BACKUP permite a realização de uma cópia do arquivo USERS01.BDF por meio de comandos do sistema operacional com o banco de dados aberto. A instrução ALTER TABLESPACE users END BACKUP indica que o arquivo USERS01.BDF foi copiado por meio de comandos do sistema operacional com o banco de dados aberto. A instrução ALTER DATABASE BEGIN BACKUP permite criar uma cópia de todos os arquivos do banco de dados por meio de comandos do sistema operacional, sem que seja necessário encerrar as operações do banco. Por fim, a instrução ALTER DATABASE END BACKUP indica que todos os arquivos do banco de dados foram copiados por meio de comandos do sistema operacional.

Para efetuar o backup do banco de dados com o banco aberto precisamos que ele esteja em modo archive, para isso utilizamos a instrução ARCHIVE LOG LIST.

Caso o banco de dados não esteja em modo archive, colocamos em modo archive utilizando a sequência de instruções da Listagem 2.

  SHUTDOWN IMMEDIATE;
  STARTUP MOUNT;
  ALTER DATABASE ARCHIVELOG;
  ALTER DATABASE OPEN;

Outra instrução muito importante e utilizada pelos administradores de banco de dados é a RECOVER que recupera a mídia de uma ou mais tablespaces, de um ou mais arquivos de dados ou do banco de dados inteiro.

Se quisermos recuperar o banco de dados inteiro precisamos que ele esteja em estado MOUNT, ou fechado, e todas as tablespaces devem estar on-line. Porém, para recuperar uma tablespace, o banco de dados deve estar em modo MOUNT ou OPEN e a tablespace a ser recuperada deve estar em modo off-line. Para realizarmos a recuperação de um arquivo de dados danificado, o banco também deve estar em modo MOUNT ou OPEN e o arquivo de dados em modo off-line. Não é possível colocar um arquivo da tablespace SYSTEM em modo off-line, pois os arquivos de dados devem ser restaurados do backup antes do processo de restauração.

Dessa forma:

• A instrução RECOVER DATABASE é responsável por recuperar o banco de dados inteiro;
• A instrução RECOVER TABLESPACE tablespace_um recupera a tablespace de nome tablespace_um;
• A instrução RECOVER TABLESPACE tablespace_um, tablespace_dois recupera as duas tablespaces e;
• A instrução RECOVER DATABASE UNTIL TIME '2015-02-15:14:00:00' recupera o banco de dados até um determinado ponto no tempo.

Todas essas operações descritas acima podem ser realizadas com sysoper. Porém, uma conexão com sysdba também permite executar todos os comandos realizados com sysoper, além de possibilitar restauração incompleta do banco de dados e criação de novos bancos de dados e de novos usuários com os privilégios de sysoper e sysdba.

Inicializando o Banco de Dados

Sempre que o Banco de dados está no modo SHTDOWN, todos os arquivos encontram-se fechados e a instância não existe. Apenas quando o banco for aberto é que o usuário poderá estabelecer uma conexão e acessar os dados do banco de dados.

Para iniciar o banco necessitamos do privilégio sysdba ou sysoper. Com isso, podemos utilizar a instrução STARTUP que inicia o banco de dados, passando por todos os estados automaticamente.

A sintaxe do STARTUP é dada por:

STARTUP [FORCE] [RESTRICT] [PFILE=arquivo] [NOMOUNT | MOUNT | OPEN] 
[opções_de_abertura] [nome_banco] 

A instrução STARTUP inicia a instância, monta e abre o banco de dados. A instrução STARTUP RESTRICT inicia o banco em modo restrito onde apenas os administradores do banco de dados que tenham o privilégio RESTRICTED SESSION podem estabelecer uma conexão com o banco de dados. Também é permitido colocar o banco em modo restrito por meio da instrução ALTER SYSTEM ENABLE RESTRICTED SESSION ou ainda voltar o banco ao comportamento normal através da instrução ALTER SYSTEM DISABLE RESTRICTED SESSION. Os usuários que não possuírem o privilégio RESTRICTED SESSION permanecerão conectados ao banco até encerrarem suas conexões e novas conexões serão permitidas apenas para aqueles que tiverem essa permissão. A opção PFILE=arquivo permite iniciar a instância usando o arquivo de parâmetros INITTAXI.ORA. A instrução STARTUP NOMOUNT inicia a instância sem montar ou abrir o banco de dados, enquanto que STARTUP MOUNT inicia a instância e monta o banco de dados, porém não abre. Quando utilizamos STARTUP opcoes_de_abertura temos como opções de abertura READ {ONLY | WRITE [RECOVER]} | RECOVER.

Estados do Banco de Dados

O banco de dados pode estar em quatro estados: SHUTDOWN, NOMOUNT, MOUNT ou OPEN.

O processo de inicialização do banco parte do estado SHUTDOWN para o estado NOMOUNT. No estado NOMOUNT, o arquivo de parâmetros é lido, a instância e os processos de segundo plano são criados na memória. Quando estamos neste estágio, podemos recriar o arquivo de controle ou criar o banco de dados.

Se o banco já estiver no estado NOMOUNT precisamos executar a instrução ALTER DATABASE MOUNT para que ele passe para o próximo estado MOUNT.

Estando no estado MOUNT a instância localiza e lê os arquivos de controle que contém informações sobre o nome do banco de dados, o timestamp da criação do banco de dados, o nome e a localização dos arquivos de dados, o nome e a localização dos arquivos de redo log on-line, os arquivos de redo log arquivados, o número sequencial do arquivo de redo log corrente, informações sobre as tablespaces do banco, os backups gerados, as informações dos checkpoints, além de outras informações.

As informações lidas neste arquivo de controle são utilizadas pelo banco de dados para verificar se todos os arquivos estão presentes e sincronizados para o seu funcionamento. Quando estamos neste estágio podemos renomear um arquivo de dados, ativar e desativar as opções de arquivamento dos redo logs on-line e efetuar a recuperação completa do banco de dados. Se o banco já estiver no estado MOUNT, necessitamos executar a instrução ALTER DATABASE OPEN para que passamos para o próximo estado.

Quando estamos no estado OPEN a instância está iniciada e o banco de dados está montado e aberto. Nesse estado qualquer usuário pode estabelecer conexão com o banco de dados e utilizar os comandos de acordo com a sua permissão. Obteremos um erro caso algum arquivo de dados ou de redo log on-line não estiver disponível.

Exemplificando a Iniciação do Banco de Dados

Normalmente os bancos de dados são criados em modo sem arquivamento, isso ocorre por motivos de desempenho. Porém, após a criação do banco esse modo deve ser alterado para a opção com arquivamento, garantindo a recuperação do banco caso alguma falha venha a ocorrer. Dessa forma, a primeira coisa a ser feita é verificar o modo de arquivamento atual do banco através da instrução ARCHIVE LOG LIST. Com isso podemos nos autenticar como SYS ou SYSTEM e executar a instrução SHUTDOWN IMMEDIATE conforme mostra o exemplo abaixo:

C:\> sqlplus sys/senha as sysdba
SQL> SHUTDOWN IMMEDIATE

Como o banco de dados está fechado não podemos acessar dados, dicionário de dados e as informações relativas à instância. Por isso se executarmos as operações SELECT * FROM meubd.emp; sendo emp uma tabela que eu criei no meu banco de dados chamado meubd ou se executarmos SELECT name FROM v$database; ou então SELECT * FROM v$instance; teremos um erro porque o banco de dados está em modo SHUTDOWN ou CLOSE. Isso ocorre porque na primeira consulta tentamos acessar os dados da tabela EMP do schema meubd e os dados apenas têm seu acesso permitido no estado OPEN. Na segunda instrução tentamos acessar o nome do banco de dados através de uma consulta, sendo que ela é uma view do dicionário de dados v$database, e o acesso ao dicionário de dados somente é permitido se o banco de dados estiver, pelo menos, no estado MOUNT. Na última instrução tentamos obter informações sobre a instância tentando consultar mais uma vez a view do dicionário de dados v$instance e, nesse caso, o banco deveria estar pelo menos no estado NOMOUNT.

A instrução STARTUP NOMOUNT lê as definições existentes no arquivo de parâmetro (PFILE ou SPFILE), e usa essas definições para criar a instância do banco de dados. A instância é alocada na memória do servidor e é usada para acessar os dados armazenados na parte física do banco de dados. Com o banco de dados no estado NOMOUNT já podemos acessar informações da instância que antes não era permitido, mas ainda assim não podemos acessar dados ou o dicionário de dados.

Executando as mesmas instruções que executamos anteriormente SELECT * FROM meubd.emp; ou SELECT name FROM v$database; ou então SELECT * FROM v$instance; temos que apenas a terceira linha será executada com sucesso, pois a instância foi carregada na memória durante a fase NOMOUNT.

Dessa forma, primeiro executamos a instrução STARTUP MOUNT, caso o banco estiver fechado, ou ALTER DATABASE MOUNT se o banco estiver no estado NOMOUNT. Com isso o banco de dados lerá o arquivo de controle que entre outras informações possui o nome e a localização dos arquivos de dados, assim como o nome e a localização dos arquivos de redo log que são usados para verificar a existência e a consistência dos arquivos de dados e de redo log.

Agora com o banco no estado MOUNT já podemos acessar os dados da instância e do dicionário de dados, porém ainda não podemos acessar os dados. Esse é um momento recomendado para colocarmos o banco em modo ARCHIVE LOG, pois agora temos acesso a todos os componentes do banco de dados, apenas não temos acesso aos dados. Assim sendo, utilizamos a instrução ALTER DATABASE ARCHIVELOG que altera o modo do banco de dados de sem arquivamento para com arquivamento. Novamente executando as mesmas instruções que executamos anteriormente SELECT * FROM meubd.emp; ou SELECT name FROM v$database; ou então SELECT * FROM v$instance; temos que apenas a primeira instrução nos apresentará um erro, pois a instância foi carregada na memória na fase NOMOUNT, o dicionário de dados pode ser acessado no estado MOUNT, no entanto os dados somente estarão disponíveis no estado OPEN.

Utilizando a instrução STARTUP ou STARTUP OPEN abriremos o banco caso ele esteja fechado, ou ainda podemos utilizar ALTER DATABASE OPEN se o banco de dados estiver em modo MOUNT. Com isso podemos acessar os dados e as informações do dicionário de dados. Executando as mesmas instruções que executamos anteriormente SELECT * FROM meubd.emp; ou SELECT name FROM v$database; ou então SELECT * FROM v$instance; temos que todos os comandos funcionam.

Interrompendo o Banco de Dados

O usuário com o privilégio de sysdba ou sysoper pode interromper o funcionamento do banco de dados ao executar a instrução SHUTDOWN que possui quatro modos diferentes, são eles: NORMAL, TRANSACTIONAL, IMMEDIATE e ABORT.

1. A opção default é a NORMAL, assim podemos executar apenas a instrução SHUTDOWN ou SHUTDOWN NORMAL para encerrar as operações do banco de dados. A opção NORMAL não permite novas conexões de usuários, as conexões ativas permanecerão abertas até o usuário se desconectar, os dados presentes nos buffers de memória são descarregados para o disco, processos de segundo plano e SGA são removidos da memória e o banco é fechado e desmontado.
2. A opção TRANSACTIONAL é executada com a instrução SHUTDOWN TRANSACTIONAL que encerra as operações do banco de dados, não permite novas conexões de usuário, seções sem transações abertas são encerradas, conexões ativas permanecem abertas até todos os usuários encerrarem as transações, dados presentes nos buffers de memória são descarregados para o disco, processos de segundo plano e SGA são removidos da memória e o banco é fechado e desmontado.
3. A opção IMMEDIATE é executada com a instrução SHUTDOWN IMMEDIATE que encerra as opções do banco de dados de forma imediata, não permite novas conexões de usuários, não aguarda a desconexão dos usuários, transações ativas sofrem rollback, dados presentes nos buffers de memória são descarregados para o disco, processos de segundo plano e SGA são removidos da memória, o banco é fechado e desmontado. A opção IMMEDIATE tem sido a mais utilizada para desativar o banco de dados pelos DBAs.
4. Por fim, a opção ABORT é executada através da instrução SHUTDOWN ABORT que aborta as operações do banco de dados Essa opção é como se desligássemos o servidor no botão liga/desliga. A instrução ABORT não causa maiores danos ao banco de dados, porém operações de backup são desaconselhadas após um ABORT. O ABORT encerra imediatamente instruções SQL em execução, não aguarda a desconexão dos usuários, não faz rollback nas transações ativas, não descarrega para o disco dados presentes nos buffers de memória, o banco não é fechado nem desmontado, e a próxima inicialização executará a recuperação automática da instância.