# 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.

Tópico pai: Cópia de segurança e restauração do banco de dados
Conceitos relacionados
Cópia de segurança do banco de dados
Tarefas relacionadas
Restauração do banco de dados a partir da cópia de segurança
Criação de um banco de dados a partir de uma cópia de segurança