segunda-feira, 22 de junho de 2009

Troubleshooting XE – Parte IV – ARCHIVELOG mode

Como prometi no artigo anterior, nesta quarta parte da série vou falar sobre o ARCHIVELOG mode. Antes, porém, observe atentamente a figura a seguir.

Database Storage Structure
Flash Recovery Area

Na figura abaixo podemos ver a estrutura de armazenamento do Oracle 10g Express Edition. Podemos ver as estruturas lógicas (as Tablespaces); as estruturas físicas (Datafiles, Tempfile, Password file, Control file e Server Parameter file); e a Flash Recovery Area.

Inicialmente, a flash recovery area (FRA) armazena os Online Redo Logs. Mas ela também é destinada ao armazenamento dos backups e dos Archived Redo Logs, na medida em que você faz os backups e ativa o modo de Archive Log.


Online Redo Log Files

A estrutura mais crucial para a recuperação do banco de dados é um grupo de redo log files. Este grupo de arquivos é coletivamente conhecido como redo log. Um redo log é feito de redo entries, que são também chamados de redo records.

A função principal do redo log é registrar todas as alterações de dados em um banco de dados. Se uma instância Oracle falhar ou o sistema operacional por alguma razão impedir que os dados modificados sejam permanentemente escritos nos arquivos de dados, as alterações podem ser recuperadas do redo log, de modo que as atualizações de dados enviadas (commited) não sejam perdidas.

O banco de dados escreve no redo log em um modo circular. Existem arquivos físicos associados ao redo log. Um redo logcurrent) e os outros inativos. Deste modo, os logs de arquivamento são registrados sempre no grupo ativo. Quando o grupo de redo log ativo é preenchido, o banco de dados começa a escrever no próximo grupo de redo log disponível. Quando o último grupo de redo log disponível é preenchido, o banco de dados retorna ao primeiro grupo de redo log e escreve nele (sobrescrevendo as entradas anteriores), reiniciando o ciclo.
está sempre associado a, no mínimo, dois grupos. Destes, sempre um está ativo (ou

Percebe-se que há um limite para o arquivamento das operações realizadas pelo banco de dados pois, quando ele tem que reiniciar o ciclo, os logs anteriores à um certo período (indeterminado) começam a ser sobrescritos.

O ARCHIVELOG mode

O Oracle Database XE pode ser configurado de modo que um processo de arquivamento em background faça cópias dos redo log files inativos para a FRA, antes deles poderem ser reutilizados. Este processo de copiar os Redo log files é chamado de archived redo log files. Desta forma, praticamente não há limite para o arquivamento das operações realizadas sobre o banco de dados.

Um banco de dados configurado para arquivar redo logs é dito estar no ARCHIVELOG mode. (Um banco de dados não configurado para arquivar redo logs é dito estar no NOARCHIVELOG mode).

Antes de prosseguirmos, é preciso saber em que o modo o XE está neste momento: se está ou não no modo ARCHIVELOG. Uma das maneiras para fazer isto é abrir a interface HTML do XE e verificar o painel Usage Monitor.

Na figura acima, podemos ver que o modo de arquivamento não está ativo (Log Archiving: Off).

Ativando o ARCHIVELOG mode

Vamos ver os procedimentos necessários para colocar o XE no ARCHIVELOG mode.

SHUTDOWN IMMEDIATE

Se o comando for bem sucedido, a tela irá exibir:

Database closed.
Database dismounted.
ORACLE instance shut down.

  • Agora digite:
STARTUP MOUNT

ORACLE instance started.
Total System Global Area 599785472 bytes
Fixed Size 1220804 bytes
Variable Size 180358972 bytes
Database Buffers 415236096 bytes
Redo Buffers 2969600 bytes
Database mounted.
(os números podem ser diferentes na tua tela)

  • Agora digite o próximo comando:
ALTER DATABASE ARCHIVELOG;

Database altered.

  • Agora digite o próximo comando, para abrr o banco de dados e deixá-lo operacional:

ALTER DATABASE OPEN;

Database altered.

  • Pronto, o banco de dados agora está rodando no ARCHIVELOG mode!

Agora vem a próxima recomendação: aumente o tamanho da FRA para pelo menos 15GB, para ter espaço extra de armazenamento para os redo log files.

Alterando o tamanho da FRA

Para alterar o tamanho da FRA para 15G Bytes, conecte como SYSDBA e digite o seguinte comando:

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE = 15G;

Movendo a FRA

A FRA, como sabemos, fica dentro da pasta de instalação do XE. Isto não é um inconveniente tão grande assim. Mas se você for uma pessoa que leva segurança ao extremo, pode querer transferí-la para outro lugar, por uma simples razão: ela é usada pelo XE para garantir a segurança e a integridade dos dados, em caso de “crash”. Além disso, todos os backups e archive logs são guardados dentro dela. Aí é que “mora o perigo”, pois se ocorrer uma pane catastrófica no HD, tudo, inclusive os backups e archive logs, será perdido para sempre!

Além disto, a depender do tamanho da partição destinada ao sistema operacional, o XE e seus datafiles, que ocupam mais de 5GB, adicionados aos 15GB em média que a FRA termina ocupando, pode deixar pouco espaço para outras necessidades do sistema operacional, como arquivos temporários e etc. É só lembrar que no windows o XE é instalado por default em C:\OracleXE e no linux em /usr/lib/oracle/xe, ambos na partição do sistema operacional. É certo que no windows você ainda tem a possibilidade de alterar o diretório de instalação e consequentemente o HD de destino.

Mover a FRA para outro lugar (outro HD, de preferência), além de dar maior segurança, termina por liberar 15GB de espaço na partição do sistema.

Planejando o local de destino

Para mover a FRA para outro lugar, um detalhe precisa ser lembrado, principalmente no linux: o usuário oracle precisa ter direito de leitura e escrita no local de destino. Assim, é preciso certificar-se de que dar as permissões adequadas ao usuário oracle e ao grupo dba (ORA_DBA, no windows) sobre a pasta.

A título de exemplo, digamos que eu, no linux, transferi a FRA para o seguinte caminho:

/bigfoot/BACKUP_XE/flash_recovery_area

/bigfoot é uma partição montada em outro HD. Nesta partição, criei uma pasta chamada BACKUP_XE e dentro dela a pasta flash_recovery_area, para onde irei transferir a FRA.

A principio, bastaria dar os privilégios necessários, assim (como su):

chown -R oracle:dba /bigfoot/BACKUP_XE

desta forma, BACKUP_XE e tudo dentro dela passa a pertencer ao usuário oracle, sob o grupo dba. Mas há um pequeno detalhe: o usuário oracle não faz parte do grupo users (o grupo secundário default para todo usuário linux) e isto o impedirá de ter acesso à partição /bigfoot!

Para corrigir isto, basta incluir o usuário oracle também no grupo users.

Quem trabalho com o XE no windows, precisa contornar estas “pegadinhas” à sua maneira.

Informando ao XE o novo local da FRA

Para ter certeza de que as coisas correram bem, verifique as configurações atuais de FRA, usando o comando SQL abaixo. Conecte-se com SYSDBA e rode a seguinte SELECT:

SELECT
NAME,
TO_CHAR(SPACE_LIMIT, '999,999,999,999') AS SPACE_LIMIT,
TO_CHAR(SPACE_LIMIT - SPACE_USED + SPACE_RECLAIMABLE, '999,999,999,999')
AS SPACE_AVAILABLE,
ROUND((SPACE_USED - SPACE_RECLAIMABLE)/SPACE_LIMIT * 100, 1)
AS PERCENT_FULL
FROM V$RECOVERY_FILE_DEST;


Na figura acima, o resultado da SELECT em meu computador de testes (para este exemplo, usei o SQL Developer, pois queria capturar uma tela mais “elegante”). Podemos ver que ainda se encontra na localização padrão.

Para alterar o local da FRA, use o comando abaixo, conectado como SYSDBA:

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST = 'new_path';

new_path deve ser o caminho completo para a nova localização da FRA. Neste exemplo, o comando foi

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST = '/bigfoot/BACKUP_XE/flash_recovery_area';

Movendo os on-line redo log files para a nova localização

Após mudar a localização da FRA, é necessário rodar um script oferecido pelo XE para mover os Online redo log files para a nova localização. Ainda no SQL*Plus, basta rodar o seguinte comando:

@?/sqlplus/admin/movelogs

Este script (movelogs.sql) fica na pasta ORACLE_HOME/sqlplus/admin. No SQL*Plus, a interrogação é uma abreviação para ORACLE_HOME. O comando deve ser executado inteiramento em letras minúsculas no linux.

ATENÇÃO USUÁRIOS LINUX.: Quando executei este script, recebi uma mensagem de erro informando que não foi possível apagar determinado grupo de redo log, pois ele se encontrava em uso. Certamente, é por causa do "excesso" de segurança do Linux. :-)

Você pode ignorar esta mensagem, por enquanto!

Não apague ainda os arquivos da FRA antiga

Em hipótese alguma apague manualmente os arquivos da FRA antiga. Os scripts de backup e restore, e o mecanismo de restauração do banco de dados (se for necessário) do XE, continuarão usando os dados da velha FRA até que eles se tornem obsoletos.

Uma forma de torná-los logo obsoletos é fazer dois backups seguidos do XE (três, se você não tiver feito nenhum, ainda). Somente depois de certificar-se de que o XE não precisará mais da FRA antiga é que você poderá apagar algum arquivo remanescente.

Verificando o resultado

Para verificar se as coisas deram certo, rode mais uma vez a SELECT que acessa V$RECOVERY_FILE_DEST e veja a nova localização da FRA.


Além disto, abra a interface HTML do XE, conectado como SYSTEM, e verifique a localização dos redo log files. Para isto, você deve clicar no link Log Archiving: On, que fica na parte inferior do painel Usage Monitor.


Note na figura acima que os dois grupos de redo logs já apontam para a nova FRA.


Somente para usuários Linux

Quando a gente escreve um tutorial, muitas vezes passa a impressão de que tudo dá sempre certo. Mas isto não é bem verdade! Comigo as coisas não deram tão certo assim :-(!

Lembram do erro que falei que pode ocorrer quando rodar o script movelogs.sql? Certamente ele vai acontecer. E pior ainda: você continuará com um grupo de redo log na velha FRA!

Caso isto realmente aconteça com você, vou dizer o que fiz para “corrigir” este pequeno inconveniente.

Rodei o script movelogs.sql mais duas vezes! Ao fazer isto, terminei com cinco grupos de on-line redo logs.

Após isto, segui a “sugestão” do manual do XE e fiz dois backups consecutivos, para o XE tornar obsoletos os arquivos da velha FRA.

Ainda assim, um dos (agora cinco) grupos de Online redo log ficava sempre na velha FRA. Dam!

Foi quando percebi que tinha que remover o danado “na unha”!

Dropping Log Groups

O manual da Oracle é categórico quando o assunto é apagar grupos de log. Vejamos algumas recomendações:

Antes de apagar um grupo de redo log, considere as seguintes restrições e precauções (Extraído do Oracle® Database Administrator's Guide, capítulo 6, item Dropping Redo Log Groups and Members):

  • Uma instância Oracle requer, ao menos, dois grupos de redo log, independentemente do número de membros de cada grupo (um grupo pode ter vários membros [arquivos]);
  • Você só pode apagar um grupo de redo log se ele estiver inativo. Se você precisar apagar um grupo que esteja ativo (current), primeiro force uma comutação (switch);
  • Certifique-se de que o grupo tenha sido arquivado antes de apagá-lo.

Para saber o estado de grupos de redo log, você pode fazer uma consulta via interface HTML do XE, como mostrado na figura anterior ou consultar a view V$LOG, com o seguinte comando:

SQL> SELECT GROUP#, ARCHIVED, STATUS FROM V$LOG;

GROUP# ARCHIVED STATUS
---------- --------- --------
1 YES INACTIVE
2 NO CURRENT

SQL>

Você vai precisar usar a interface HTML, pois além destas informações, ela mostra o arquivo associado ao grupo. Só assim você saberá se ele se encontra na antiga ou na nova FRA.

Caso o grupo que você deseja apagar esteja ativo, você pode forçar uma comutação (switch) com o seguinte comando:

ALTER SYSTEM SWITCH LOGFILE;

Com estas informações, agora dá para você se livrar do grupo de redo log indesejável. Tudo o que você precisa fazer é se certificar que ele está arquivado (ARCHIVED) e inativo (INACTIVE). A boa notícia é que ao fazer os dois backups subseqüentes, todos os redo log passaram a assumir este estado, exceto o que está ativo (CURRENT).

Para apagar um grupo de redo log, basta usar o seguinte comando:

ALTER DATABASE DROP LOGFILE GROUP N;

Onde N é o número do redo log que você quer apagar. Identifique qual o grupo que deseja apagar, usando os métodos já descritos e execute o comando;

Finalmente, faça um novo backup, para que o estado atual seja mantido.

-X-

4 comentários:

  1. Você tem os instaladores do server e do client nas versões windows e linux? é que no site da oracle não tem mais, se puder disponibilizar, eu agradeço, pois perdi os meus instaladores.

    ResponderExcluir
  2. Sim, tenho uma cópia da versão 10g XE R2 (10.2.0.1)

    OracleXE.exe
    OracleXEClient.exe
    oracle-xe-10.2.0.1-1.0.i386.rpm

    Assim que puder, vou colocar estes arquivos em algum lugar na NET e disponibilizo os links aqui.

    ResponderExcluir
  3. Olá!

    Coloquei os arquivos no 4Shared. Eis o link:
    http://www.4shared.com/folder/ArljA8R-/Arquivos.html

    ResponderExcluir
  4. Acabei de baixá-los.
    Muito obrigado.

    ResponderExcluir