Recupera????o com rolagem para frente

O Derby suporta a recupera????o com rolagem para frente (roll-forward recovery) para restaurar um banco danificado para o estado mais recente anterior ?? ocorr??ncia da falha.

O Derby restaura o banco de dados a partir da c??pia de seguran??a completa, e refaz todas as transa????es posteriores ?? c??pia de seguran??a. S??o necess??rios todos os arquivos de log posteriores ?? c??pia de seguran??a, para refazer as transa????es posteriores ?? c??pia de seguran??a. Por padr??o, o banco de dados mant??m apenas os logs requeridos para a recupera????o de queda. Para a recupera????o com rolagem para frente ser bem-sucedida, todos os arquivos de log posteriores ?? c??pia de seguran??a devem ser guardados. Os arquivos de log podem ser guardados utilizando chamadas de fun????o de c??pia de seguran??a que habilitam guardar o log.

Na recupera????o com rolagem para frente o modo que guarda o log garante que todos os arquivos de log antigos ficam dispon??veis. Os arquivos de log ficam dispon??veis somente a partir do momento em que o modo que guarda o log ?? habilitado.

O Derby utiliza as seguinte informa????es para restaurar o banco de dados:

A c??pia de seguran??a do banco de dados
O conjunto de logs guardados
O log em linha ativo no momento

A recupera????o com rolagem para frente n??o pode ser utilizada para restaurar tabelas individuais. A recupera????o com rolagem para frente recupera todo o banco de dados.

Para restaurar um banco de dados utilizando a recupera????o com rolagem para frente dever?? existir uma c??pia de seguran??a do banco de dados, todos os logs guardados desde que a c??pia de seguran??a foi criada, e os arquivos de log ativos. Todos os arquivos de log dever??o estar no diret??rio de log do banco de dados.

Existem dois tipos de arquivo de log no Derby: os logs ativos e os logs em linha guardados.

Logs ativos: Os logs ativos s??o utilizados durante a recupera????o de queda para evitar que uma falha que deixe o banco de dados em um estado inconsistente. A recupera????o com rolagem para frente tamb??m pode utilizar os logs ativos para recuperar at?? o final dos arquivos de log. Os logs ativos est??o localizados no diret??rio de caminho de log do banco de dados.
Logs em linha guardados: Arquivos de log guardados para uso pela recupera????o com rolagem para frente, ap??s n??o serem mais necess??rios para recupera????o de queda. Os logs em linha guardados tamb??m s??o mantidos no diret??rio de caminho de log do banco de dados.

Habilita????o do modo que guarda o log

Os logs em linha guardados estar??o dispon??veis somente se o banco de dados for habilitado para o modo de guarda o log. Pode ser utilizado o seguinte procedimento do sistema para habilitar o banco de dados no modo que guarda o log:

SYSCS_UTIL.SYSCS_BACKUP_DATABASE_AND_ENABLE_LOG_ARCHIVE_MODE
(IN BACKUPDIR VARCHAR(32672), IN SMALLINT DELETE_ARCHIVED_LOG_FILES)

Os par??metros de entrada para a chamada do exemplo anterior especificam o local onde a c??pia de seguran??a dever?? ser armazenada, e especifica se o banco de dados dever?? manter os logs em linha guardados para a c??pia de seguran??a. Os arquivos de log em linha guardados existentes, criados antes desta c??pia de seguran??a, ser??o eliminados se o valor do par??metro de entrada para o par??metro deleteOnlineArchivedLogFiles for diferente de zero. Os arquivos de log s??o eliminados somente ap??s a c??pia de seguran??a ter sido bem-sucedida.

Nota: Tenha certeza de armazenar a c??pia de seguran??a do banco de dados em um local seguro ao escolher a op????o de remo????o do arquivo de log.

O procedimento SYSCS_UTIL.SYSCS_BACKUP_DATABASE_AND_ENABLE_LOG_ARCHIVE_MODE emite uma mensagem de erro quando existem opera????es n??o registradas na mesma transa????o do procedimento de c??pia de seguran??a.

Caso exista no sistema, quando a c??pia de seguran??a iniciar, opera????es n??o registradas em andamento em outras transa????es, este procedimento ficar?? bloqueado at?? que estas transa????es completem, antes de realizar a c??pia de seguran??a. O Derby converte, automaticamente, as opera????es n??o registradas para o modo registrado, quando estas s??o iniciadas quando a c??pia de seguran??a est?? em andamento (exceto as opera????es que fazem manuten????o de arquivos jar de aplicativo no banco de dados). Os procedimentos que instalam, substituem e removem arquivos jar no banco de dados s??o bloqueadas quando a c??pia de seguran??a est?? em andamento.

Se n??o for desejado que a c??pia de seguran??a fique bloqueada at?? que as opera????es n??o registradas em outras transa????es completem, deve ser utilizado o procedimento SYSCS_UTIL.SYSCS_BACKUP_DATABASE_AND_ENABLE_LOG_ARCHIVE_MODE_NOWAIT. Esse procedimento emite um erro logo no in??cio da c??pia de seguran??a caso existam transa????es em andamento com opera????es n??o registradas, em vez de aguardar estas transa????es completarem.

Desabilita????o do modo que guarda o log

Ap??s o modo que guarda o log ter sido habilitado, o banco de dados ficar?? para sempre com o modo que guarda o log habilitado, mesmo que posteriormente seja recarregado ou seja feita uma c??pia de seguran??a. A ??nica maneira de desabilitar o modo que guarda o log ?? executar o seguinte procedimento:

SYSCS_UTIL.SYSCS_DISABLE_LOG_ARCHIVE_MODE(IN SMALLINT DELETE_ARCHIVED_LOG_FILES)

Este procedimento do sistema desabilita o modo que guarda o log, e remove todos os arquivos de log guardados existentes, se o par??metro de entrada DELETE_ARCHIVED_LOG_FILES for diferente de zero.

Realiza????o da recupera????o com rolagem para frente:

Utilizando a c??pia de seguran??a completa, os logs guardados, e os logs ativos, o banco de dados pode ser restaurado at?? seu estado mais recente realizando a recupera????o com rolagem para frente. A recupera????o com rolagem para frente ?? realizada especificando o atributo da URL de conex??o rollForwardRecoveryFrom=<caminho-da-c??pia-de-seguran??a> em tempo de inicializa????o. Com isto o banco de dados retorna ao seu estado mais recente utilizando a c??pia de seguran??a completa, os logs guardados e os logs ativos. Todos os arquivos de log dever??o estar no diret??rio do caminho de log do banco de dados.

C??pia de seguran??a do banco de dados:

No exemplo a seguir ?? realizada a c??pia de seguran??a do banco de dados chamado wombat no diret??rio d:/backup com o modo que guarda arquivo de log habilitado:

connect 'jdbc:derby:wombat;create=true';

create table t1(a int not null primary key);
------------------DML/DDL Operations
CALL SYSCS_UTIL.SYSCS_BACKUP_DATABASE_AND_ENABLE_LOG_ARCHIVE_MODE
('d:/backup', 0);
insert into t1 values(19);
create table t2(a int);
-----------------Opera????es de DML/DDL
-----------------Queda do banco de dados (M??dia corrompida nos discos de dado)

Restaura????o do banco de dados utilizando a recupera????o com rolagem para frente:

No exemplo a seguir, o banco de dados ?? restaurado utilizando a recupera????o com rolagem para frente ap??s uma falha da m??dia:

connect 'jdbc:derby:wombat;rollForwardRecoveryFrom=d:/backup/wombat';
select * from t1;
-----------------Opera????es de DML/DDL

Pode ser especificado o seguinte atributo na URL de conex??o em tempo de carga do JDBC:

rollForwardRecoveryFrom=caminho

Para obter mais informa????es deve ser consultada a se????o rollForwardRecoveryFrom=caminho no Manual de Refer??ncia do Derby.

Ap??s o banco de dados ser restaurado a partir da c??pia de seguran??a completa, as transa????es dos logs em linha arquivados e dos logs ativos s??o refeitas.