Recover no Oracle
O backup e recuperação de dados em um SGBD é de grande importância para a manutenção dos dados. Dando continuidade a nossos artigos, apresentamos abaixo formas diferentes de se fazer uma restauração de dados no Oracle.
Verificando a Necessidade de Recuperação
Quando um banco de dados é iniciado, este passa por três fases:
• Fase NoMount – É a primeira fase, onde é lido o arquivo de parâmetros init.ora para determinar o tamanho do SGA, criar e inicializar os processos de background. Também é lido o endereço do arquivo de controle (control files), que será aberto na próxima fase.
• Fase Mount – Nesta fase é montado o banco de dados, onde o arquivo de controle (control files) é aberto e os endereços dos datafiles e redo log files são lidos.
• Fase Open – Durante esta fase, caso um dos arquivos referenciados no arquivo de controle (SCN) não seja encontrado, ou esteja fora de sincronismo, o banco de dados não é aberto.
No caso de erros nos arquivos de referências e falta de sincronismo do arquivo de controle, será necessária uma recuperação de mídia. (Media Recovery). Também é verificado se o último checkpoint foi realizado com sucesso, e caso positivo o banco de dados será liberado, senão procederá a um Instance Recovery.
Crash/Instance Recovery
Crash recovery é similar ao instance recovery, onde o primeiro referencia ambientes de instância exclusiva e o segundo ambientes parallel server.
Rodando em configuração parallel server, com no mínimo duas instâncias, o instance recovery é automaticamente realizado por uma das instâncias que se mantiveram ativas após a falha.
Nenhum comando é necessário para a execução do Instance Recovery, todo o processo é disparado automaticamente pelo Oracle. O que o DBA deverá fazer é descobrir quais as causas que levaram à falha.
Media Recovery
O media recovery só é executado através de um comando realizado pelo DBA. Este comando é executado com o objetivo de trazer um determinado data file a uma posição de atualização ou para restaurar alterações perdidas quando este foi colocado off-line sem um prévio checkpoint.
Um data file recuperado a partir de um backup sempre vai precisar de media recovery. Podemos fazer uma operação de recovery enquanto o banco está aberto e o datafile a ser recuperado está em estado off-line.
Só podemos fazer a recuperação completa até o ponto de falha, se trabalharmos em modo ARCHIVELOG.
Fases do Recovery
Qualquer tipo de recovery é composto de duas fases:
• Roll Forward
• Roll Backward
Aplicando o Roll Forward
O roll forward consiste em aplicar seqüencialmente as alterações de blocos (redo records) contidas nos registros do redo log.
O Processo lê os redo records existentes no arquivo de redo log e obtém os blocos originais correspondentes às modificações nos datafiles, movendo-os para o database buffer cache.
A tabela interna undo$ contém informações sobre as transações pendentes, até que redo records, contendo a informação de commit, sejam encontrados. Neste caso, a informação é retirada da tabela undo$ e das entradas do segmento de rollback.
Aplicando Roll Backward
Após a aplicação de todos os redo records correspondentes, começa a segunda parte do processo de recuperação, que é o rollback das transações não confirmadas. Esta parte do processo também é chamada de recuperação da transação.
As transações pendentes são localizadas através da tabela undo$ que contém as transaction tables armazenadas no segmento de rollback.
Uma vez localizadas, estas são seguidas até o fim da cadeia de forma a desfazer todas as transações pendentes.
As Opções do Media Recovery
Existem basicamente três opções para se efetuar um “media recovery”.
• Database Recovery
• Tablespace Recovery
• Data file Recovery
Todos são executados a partir da recuperação das cópias de backups correspondentes, adicionando-se os redo logs arquivados (archives).
Database Recovery
O Database Recovery é a opção de Recovery mais abrangente, pois recupera todos os redo records contidos nos redo logs arquivados. Mas também ele é o mais custoso, consumindo muito mais tempo de execução e com maior risco, visto que sua abrangência atinge praticamente todos os datafiles pertencentes ao banco de dados.
Um database recovery só pode ser executado com o banco de dados off-line.
Tablespace Recovery
O método Tablespace Recovery só pode ser utilizado com o banco de dados aberto, visto que uma tablespace é um objeto lógico e só existe internamente no banco de dados. Ele é um método de recuperação on-line, à medida que só funciona com o banco de dados aberto. Ele é tem menos custo e é mais rápido do que o Database Recovery.
Datafile Recovery
Para o método Datafile Recovery, podemos trabalhar com o banco de dados aberto, ele é o método com maior nível de granularidade, podendo ser o mais eficiente quando feito com um ou poucos datafiles.
O Comando Recovery
O comando Recovery deverá ser executado quando em uma das fases de inicialização do Oracle forem encontrados erros (Fase NoMount, Fase Mount, Fase Open).
Sintaxe do comando Recovery:
recover [automatic] [from < LOCAL>]
[database database_name]
[tablespace < TABLESPACE_NAME>]
[until cancel]
[until time ]
[until change < SCN>]
[using backup controlfile];
• Automatic – A recuperação será executada sem que o DBA precise informar o nome e o caminho dos arquivos de redo a serem aplicados.
• From < LOCAL>- Irá buscar os redos arquivados na localização específica.
• Database_Name – Nome do banco de dados se o db_name não for especificado no arquivo de parâmetros.
• Tablespace_name – Nome da tablespace que será recuperada.
• Datafile_name – Nome do datafile que será recuperado.
O default do comando é recovery database.
O Recovery Incompleto
A recuperação de um banco de dados obtido de uma falha de armazenamento sem nenhuma perda de dados é identificado de “Complete Recovery”, caso uma parte dos dados tenha sido perdido temos um caso de “Incomplete Recovery”.
Quando possuímos todos os arquivos de redo logs necessários, os datafiles de backup e o arquivo controle corrente, devemos fazer uma recuperação completa.
Uma recuperação incompleta só deverá ser feita quando não possuirmos um dos itens necessários para tal, ou se um dos redos estiver corrompido e não trabalharmos com múltiplos destinos.
Uma recuperação incompleta também pode ser utilizada para trazer o banco de dados até um determinado ponto no tempo.
Quando executamos um recovery incompleto devemos abrir o banco de dados com o comando “alter database open resetlogs”. Após este comando devemos fazer um backup full imediatamente, de modo que se mantenha o novo conjunto de arquivos sincronizados pelo novo valor do log sequence number.Este comando marca o banco de dados de forma que jamais poderemos aplicar os arquivos de redo que foram descartados.
A recuperação incompleta é realizada a partir de um dos seguintes comandos:
recover database until cancel;
recover database until time ;
recover database until chance < SCN>;
• Until cancel – é utilizado quando desejamos fazer a recuperação até um determinado arquivo de redo, seguido do cancelamento da execução com o comando “cancel”.
• Until time – é utilizado quando desejamos recuperar nosso banco até um determinado ponto no tempo. Todas as transações que estiverem pendentes de confirmação naquele momento do tempo serão desfeitas através do processo de roll backwards.
• Until change – funciona basicamente da mesma forma que a opção until time, com a diferença de que nesta opção é aplicado um determinado SCN (system change number).
• os arquivos de redo log serão :
Recuperação em NOARCHIVELOG
Nestes casos a recuperação só pode ser da imagem anterior do último backup. Ocasionalmente há perda de todas as transações subseqüêntes.
Recuperação Completa
Para realizar uma recuperação completa do banco de dados, ele tem que estar rodando em modo ARCHIVELOG. Deve-se estar de posse também dos datafiles a serem recuperados, control files e redo logs arquivados.
Recuperação Incompleta
Antes de fazer uma recuperação incompleta do banco de dados Oracle, temos que deixar prontos todos os arquivos já copiados, para o momento certo de recuperação, garantindo que todos os arquivos contenham modificações (SCNs) anteriores ao momento em que queremos para a recuperação.
Ao final de uma recuperação incompleta abrimos o banco de dados com RESETLOGS, e o número seqüencial dos redo logs volta a 1. Cuidado pois, todo o conjunto de redos anteriores ficará inválido. Veja o comando abaixo:
alter database open resetlogs;
Utilizando o Utilitário The Recovery Manager do Oracle
Podemos utilizar diversos tipos de utilitários para fazermos recovery no Oracle, mostraremos o funcionamento do utilitário padrão do Oracle.
Caixa de Diálogo do Oracle Recovery Manager
• Automatic Recovery - Executa uma recuperação automática.
• Restore From Full Database Backup - Restabelece a base de dados a partir de um arquivo de backup full. Se você utilizou seu banco de dados em modo de NOARCHIVELOG, esta é sua única opção.
• Restore Data, then Do Recovery - Restabelece o dados selecionados arquivados e executa uma recuperação automática.
• Data file list Box - Indica o local do banco de dados arquivado para restabelecer.
• Restore Control File, then Do Recovery - Restabelece o arquivo de controle e executa uma recuperação automática.
• Recover - Inicia o procedimento de recuperação.
Caixa de Diálogo Database Files
• Data Files – Quando selecionado, exibe a lista de arquivos de dados em seu banco de dados.
• Log Files – Quando selecionado, exibe a lista de arquivos de log e o grupo deles numerado, associado com seu banco de dados.
• Control Files – Quando selecionado, exibe a lista de arquivos de controle do seu banco de dados.
• File List - Exibe a lista válida de arquivos, dependendo de como são selecionados Data, Log, ou Control Files.
• File name Box - Entre com um caminho e o filename para um arquivo que você quer acrescentar à lista de arquivos em seu banco de dados.
• Add - Acrescenta o arquivo especificado na caixa de Filename à Lista de Arquivo.
• Remove - Remove o arquivo selecionado da Lista de Arquivo.
• Group Number - Só é habilitado quando o a opção log files é selecionada. Isto indica o grupo do log file e sua sucessão para a qual o arquivo de log atualmente selecionado pertence.
Procuramos apresentar neste artigo um material de fácil compreensão onde o usuário será capaz de recuperar da melhor maneira os seus dados.
Fiquem à vontade para nos escrever em Recover no Oracle O backup e recuperação de dados em um SGBD é de grande importância para a manutenção dos dados. Dando continuidade a nossos artigos, apresentamos abaixo formas diferentes de se fazer uma restauração de dados no Oracle. Verificando a Necessidade de Recuperação Quando um banco de dados é iniciado, este passa por três fases: • Fase NoMount – É a primeira fase, onde é lido o arquivo de parâmetros init.ora para determinar o tamanho do SGA, criar e inicializar os processos de background. Também é lido o endereço do arquivo de controle (control files), que será aberto na próxima fase. • Fase Mount – Nesta fase é montado o banco de dados, onde o arquivo de controle (control files) é aberto e os endereços dos datafiles e redo log files são lidos. • Fase Open – Durante esta fase, caso um dos arquivos referenciados no arquivo de controle (SCN) não seja encontrado, ou esteja fora de sincronismo, o banco de dados não é aberto. No caso de erros nos arquivos de referências e falta de sincronismo do arquivo de controle, será necessária uma recuperação de mídia. (Media Recovery). Também é verificado se o último checkpoint foi realizado com sucesso, e caso positivo o banco de dados será liberado, senão procederá a um Instance Recovery. Crash/Instance Recovery Crash recovery é similar ao instance recovery, onde o primeiro referencia ambientes de instância exclusiva e o segundo ambientes parallel server. Rodando em configuração parallel server, com no mínimo duas instâncias, o instance recovery é automaticamente realizado por uma das instâncias que se mantiveram ativas após a falha. Nenhum comando é necessário para a execução do Instance Recovery, todo o processo é disparado automaticamente pelo Oracle. O que o DBA deverá fazer é descobrir quais as causas que levaram à falha. Media Recovery O media recovery só é executado através de um comando realizado pelo DBA. Este comando é executado com o objetivo de trazer um determinado data file a uma posição de atualização ou para restaurar alterações perdidas quando este foi colocado off-line sem um prévio checkpoint. Um data file recuperado a partir de um backup sempre vai precisar de media recovery. Podemos fazer uma operação de recovery enquanto o banco está aberto e o datafile a ser recuperado está em estado off-line. Só podemos fazer a recuperação completa até o ponto de falha, se trabalharmos em modo ARCHIVELOG. Fases do Recovery Qualquer tipo de recovery é composto de duas fases: • Roll Forward • Roll Backward Aplicando o Roll Forward O roll forward consiste em aplicar seqüencialmente as alterações de blocos (redo records) contidas nos registros do redo log. O Processo lê os redo records existentes no arquivo de redo log e obtém os blocos originais correspondentes às modificações nos datafiles, movendo-os para o database buffer cache. A tabela interna undo$ contém informações sobre as transações pendentes, até que redo records, contendo a informação de commit, sejam encontrados. Neste caso, a informação é retirada da tabela undo$ e das entradas do segmento de rollback. Aplicando Roll Backward Após a aplicação de todos os redo records correspondentes, começa a segunda parte do processo de recuperação, que é o rollback das transações não confirmadas. Esta parte do processo também é chamada de recuperação da transação. As transações pendentes são localizadas através da tabela undo$ que contém as transaction tables armazenadas no segmento de rollback. Uma vez localizadas, estas são seguidas até o fim da cadeia de forma a desfazer todas as transações pendentes. As Opções do Media Recovery Existem basicamente três opções para se efetuar um “media recovery”. • Database Recovery • Tablespace Recovery • Data file Recovery Todos são executados a partir da recuperação das cópias de backups correspondentes, adicionando-se os redo logs arquivados (archives). Database Recovery O Database Recovery é a opção de Recovery mais abrangente, pois recupera todos os redo records contidos nos redo logs arquivados. Mas também ele é o mais custoso, consumindo muito mais tempo de execução e com maior risco, visto que sua abrangência atinge praticamente todos os datafiles pertencentes ao banco de dados. Um database recovery só pode ser executado com o banco de dados off-line. Tablespace Recovery O método Tablespace Recovery só pode ser utilizado com o banco de dados aberto, visto que uma tablespace é um objeto lógico e só existe internamente no banco de dados. Ele é um método de recuperação on-line, à medida que só funciona com o banco de dados aberto. Ele é tem menos custo e é mais rápido do que o Database Recovery. Datafile Recovery Para o método Datafile Recovery, podemos trabalhar com o banco de dados aberto, ele é o método com maior nível de granularidade, podendo ser o mais eficiente quando feito com um ou poucos datafiles. O Comando Recovery O comando Recovery deverá ser executado quando em uma das fases de inicialização do Oracle forem encontrados erros (Fase NoMount, Fase Mount, Fase Open). Sintaxe do comando Recovery: recover [automatic] [from < LOCAL>] [database database_name] [tablespace < TABLESPACE_NAME>] [until cancel] [until time ] [until change < SCN>] [using backup controlfile]; • Automatic – A recuperação será executada sem que o DBA precise informar o nome e o caminho dos arquivos de redo a serem aplicados. • From < LOCAL>- Irá buscar os redos arquivados na localização específica. • Database_Name – Nome do banco de dados se o db_name não for especificado no arquivo de parâmetros. • Tablespace_name – Nome da tablespace que será recuperada. • Datafile_name – Nome do datafile que será recuperado. O default do comando é recovery database. O Recovery Incompleto A recuperação de um banco de dados obtido de uma falha de armazenamento sem nenhuma perda de dados é identificado de “Complete Recovery”, caso uma parte dos dados tenha sido perdido temos um caso de “Incomplete Recovery”. Quando possuímos todos os arquivos de redo logs necessários, os datafiles de backup e o arquivo controle corrente, devemos fazer uma recuperação completa. Uma recuperação incompleta só deverá ser feita quando não possuirmos um dos itens necessários para tal, ou se um dos redos estiver corrompido e não trabalharmos com múltiplos destinos. Uma recuperação incompleta também pode ser utilizada para trazer o banco de dados até um determinado ponto no tempo. Quando executamos um recovery incompleto devemos abrir o banco de dados com o comando “alter database open resetlogs”. Após este comando devemos fazer um backup full imediatamente, de modo que se mantenha o novo conjunto de arquivos sincronizados pelo novo valor do log sequence number.Este comando marca o banco de dados de forma que jamais poderemos aplicar os arquivos de redo que foram descartados. A recuperação incompleta é realizada a partir de um dos seguintes comandos: recover database until cancel; recover database until time ; recover database until chance < SCN>; • Until cancel – é utilizado quando desejamos fazer a recuperação até um determinado arquivo de redo, seguido do cancelamento da execução com o comando “cancel”. • Until time – é utilizado quando desejamos recuperar nosso banco até um determinado ponto no tempo. Todas as transações que estiverem pendentes de confirmação naquele momento do tempo serão desfeitas através do processo de roll backwards. • Until change – funciona basicamente da mesma forma que a opção until time, com a diferença de que nesta opção é aplicado um determinado SCN (system change number). • os arquivos de redo log serão : Recuperação em NOARCHIVELOG Nestes casos a recuperação só pode ser da imagem anterior do último backup. Ocasionalmente há perda de todas as transações subseqüêntes. Recuperação Completa Para realizar uma recuperação completa do banco de dados, ele tem que estar rodando em modo ARCHIVELOG. Deve-se estar de posse também dos datafiles a serem recuperados, control files e redo logs arquivados. Recuperação Incompleta Antes de fazer uma recuperação incompleta do banco de dados Oracle, temos que deixar prontos todos os arquivos já copiados, para o momento certo de recuperação, garantindo que todos os arquivos contenham modificações (SCNs) anteriores ao momento em que queremos para a recuperação. Ao final de uma recuperação incompleta abrimos o banco de dados com RESETLOGS, e o número seqüencial dos redo logs volta a 1. Cuidado pois, todo o conjunto de redos anteriores ficará inválido. Veja o comando abaixo: alter database open resetlogs; Podemos utilizar diversos tipos de utilitários para fazermos recovery no Oracle, mostraremos o funcionamento do utilitário padrão do Oracle. Caixa de Diálogo do Oracle Recovery Manager • Automatic Recovery - Executa uma recuperação automática. • Restore From Full Database Backup - Restabelece a base de dados a partir de um arquivo de backup full. Se você utilizou seu banco de dados em modo de NOARCHIVELOG, esta é sua única opção. • Restore Data, then Do Recovery - Restabelece o dados selecionados arquivados e executa uma recuperação automática. • Data file list Box - Indica o local do banco de dados arquivado para restabelecer. • Restore Control File, then Do Recovery - Restabelece o arquivo de controle e executa uma recuperação automática. • Recover - Inicia o procedimento de recuperação. Caixa de Diálogo Database Files • Data Files – Quando selecionado, exibe a lista de arquivos de dados em seu banco de dados. • Log Files – Quando selecionado, exibe a lista de arquivos de log e o grupo deles numerado, associado com seu banco de dados. • Control Files – Quando selecionado, exibe a lista de arquivos de controle do seu banco de dados. • File List - Exibe a lista válida de arquivos, dependendo de como são selecionados Data, Log, ou Control Files. • File name Box - Entre com um caminho e o filename para um arquivo que você quer acrescentar à lista de arquivos em seu banco de dados. • Add - Acrescenta o arquivo especificado na caixa de Filename à Lista de Arquivo. • Remove - Remove o arquivo selecionado da Lista de Arquivo. • Group Number - Só é habilitado quando o a opção log files é selecionada. Isto indica o grupo do log file e sua sucessão para a qual o arquivo de log atualmente selecionado pertence. Procuramos apresentar neste artigo um material de fácil compreensão onde o usuário será capaz de recuperar da melhor maneira os seus dados. Fiquem à vontade para nos escrever em atendimento@keepok.com.br onde responderemos a todas as dúvidas. Abraços, Entre em contato direto com os autores através do site do Grupo KeepOk Technologies em: http://www.keepok.com.br Bibliografia SGBD Relacional Oracle: com uma abordagem teórica e prática - KNEIPP, Ricardo Esteves e ALBUQUERQUE Rodney Cezar de — Rio de Janeiro – 2003 –Ed. SENAI/RJ-CETEC Gráfica e Design. ISBN 85-903883-1-X - 201 p. Utilizando o Utilitário The Recovery Manager do Oracle
Prof. Ricardo E. Kneipp
Prof. Rodney C. de Albuquerque
atendimento@keepok.com.br onde responderemos a todas as dúvidas.
Abraços,
Prof. Ricardo E. Kneipp
Prof. Rodney C. de Albuquerque
Entre em contato direto com os autores através do site do Grupo KeepOk Technologies em: http://www.keepok.com.br
Bibliografia
SGBD Relacional Oracle: com uma abordagem teórica e prática - KNEIPP, Ricardo Esteves e ALBUQUERQUE Rodney Cezar de — Rio de Janeiro – 2003 –Ed. SENAI/RJ-CETEC Gráfica e Design. ISBN 85-903883-1-X - 201 p.
- Oracle 8i – SQL Reference – www.oracle.com
- Oracle 9i – SQL Reference – www.oracle.com
