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.
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.
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)
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:
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:
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.