Curso de Pós Graduação em Banco de Dados Procedimentos de Contigência e Alta Disponibilidade Prof.: MSc Flávio Gonçalves da Rocha

Curso de Pós Graduação em Banco de Dados

Procedimentos deContigência

e Alta Disponibilidade

Prof.: MSc Flávio Gonçalves da Rocha

Conteúdo Programático

1. Conceitos Iniciais

2. Backup: Princípios e Estratégias

3. Considerações sobre Recuperação

4. Recuperação: Princípios e Estratégias

5. Backup Gerenciado pelo Usuário

6. Ferramenta RMAN (Recovery Manager)

7. Backup com o RMAN

Conteúdo Programático

8. Recuperação Gerenciada pelo Usuário

9. Recuperação usando o RMAN

10.Utilitários Export e Import

11.Conceitos e Recursos Adicionais para Alta Disponibilidade

12.RAC

13.Data Guard

CAPÍTULO 1

Conceitos Iniciais

Conceitos Iniciais

É função básica do DBA manter a integridade e disponibilidade do banco de dados em caso de falhas e erros (hardware ou software).

Falhas/erros podem acarretar perda de dados ou até mesmo do banco de dados.

Uso de políticas de backup adequadas podem minimizar ou até mesmo eliminar problemas resultantes de falhas/erros.

Conceitos IniciaisVisão Geral da Instância

Oracle

Conceitos Iniciais Sincronização de Banco de

Dados

Todos os arquivos de dados (datafiles), exceto os off-line e somente para leitura, deverão estar sincronizados, ou seja, estarem no mesmo instante, para que o banco de dados possa ser aberto

A sincronização baseia-se no número do checkpoint atual

Conceitos Iniciais Sincronização de Banco de

Dados

A aplicação de alterações registradas nos arquivos de redo log (redo log files) sincroniza os arquivos de dados

Os redo log files são solicitados automaticamente pelo servidor Oracle

Tipos de Erros e Falhas

Erro do usuário Falha de instrução Falha de processo do usuário Falha de rede Falha de instância Falha de mídia

Erro do Usuário

SQL> DROP TABLE employees;

SQL> TRUNCATE TABLE employees;

SQL> UPDATE employees

2> SET salary = salary * 1,5;

SQL> COMMIT;

SQL> DELETE FROM employees;

SQL> COMMIT;

Falha de Instrução

Erro lógico em uma aplicação Tentativa de informar dados inválidos em uma

tabela Tentativa de executar uma operação com

privilégios insuficientes Tentativa de criar uma tabela, mas o limite da

cota alocada foi excedido Tentativa de aumentar tamanho de uma tabela

mas sem área disponível na tablespace.

Falha de Processo do Usuário

O usuário efetuou uma desconexão anormal durante a sessão

A sessão do usuário foi encerrada de forma anormal

O programa do usuário detectou uma exceção de endereço que encerrou a sessão

Falha de Rede

Conexões abortadas

Falha de Instância

Falha de Instância

Falta de energia

Problemas de hardware (CPU, memória) e Sistema Operacional

Falha em um dos processos de segundo plano do servidor Oracle (DBWR, LGWR, PMON, SMON, CKPT).

Falha de Mídia

Falha no cabeçote de uma unidade de disco

Problema físico durante a leitura ou gravação de arquivos de banco de dados

O arquivo foi acidentalmente apagado

Falha de Mídia

A falha de mídia é o tipo mais grave de falha, pois geralmente requer a intervenção do DBA.

A estratégia de recuperação depende do método de backup escolhido e dos arquivos afetados

Orientações

Proteja o banco de dados dos diversos tipos de falhas

Aumente o MTBF (Mean-Time-Between-Failures, tempo médio entre falhas)

Diminua o MTTR (Mean-Time-To-Recover, tempo médio para recuperação)

Minimize a perda dos dados

.

CAPÍTULO 2Backup:

Princípios e Estratégias

Backup: Princípios

Backups Físicos e Lógicos Backups Completos ou Incompletos Backups Consistentes e Inconsistentes Backups Online e Offline Backups com RMAN ou gerenciados pelo

usuário

Backup: Princípios

Backups Físicos

São backups dos arquivos físicos do banco de dados : datafiles, control files e redo log arquivados (se houver).

Redo log online não é suportado no RMAN

Categorías: cópias imagem e backup proprietário (RMAN)

Backup: Princípios

Backups Lógicos

São exportações dos objetos de esquemas (tabelas, stored procedures, etc) para um arquivo binário do sistema operacional (.dmp).

Comandos: export (realiza o backup) e import (restaura o backup)

Não use apenas backup lógico para proteger seu banco de dados!

Backup: Princípios

Backups Completos

Backup mais comum Inclue o control file e todos os datafiles Pode ser feito no modo ARCHIVELOG e

NOARCHIVELOG Pode ser consistente (não necessita de redo

log após restauração) ou inconsistente

Backup: Princípios

Backups Incompletos ou Parciais

Backups de partes do banco de dados: Tablespaces (ARCHIVELOG) Datafiles (ARCHIVELOG) Control file (Arquivo de controle) Redo log arquivados

Backup: Princípios


Tablespaces Backup

É o backup dos datafiles que constituem a tablespace

Backup pode ser feito com a tablespace online ou offline

Válido apenas no modo ARCHIVELOG (exceção: tablespace read-only ou offline-normal)

Backup: Princípios


Tablespaces Backup

MODO NOARCHIVELOG

Backup: Princípios


Datafile Backup

É o backup de um único datafile.

O backup é válido no modo ARCHIVELOG

No modo NOARCHIVELOG é válido se: For feito backup de cada datafile da tablespace Os datafiles estiverem no modo read-only e offline-

normal

Backup: Princípios


Control file Backup

Sem um control file válido não é possível montar ou abrir o banco

Backup automático pelo RMAN via comando:

CONFIGURE CONTROLFILE AUTOBACKUP ON

Backup: Princípios


Redo Log Arquivado

Essencial para recuperar um backup inconsistente.

Sem redo log arquivados, apenas com backups incrementais do RMAN é que se pode recurperar um backup inconsistente.

Backup: Princípios

Backup Consistente

É um backup de um ou mais arquivos do banco de dados após ele ter sido fechado de forma normal, limpa

Diferente do backup inconsistente, um backup completo consistente não necessita de redo log para recuperá-lo

Backup: Princípios

Backup Consistente

Todos os datafiles e control files tem o mesmo SCN (System Change Number) – estão sincronizados.

Tablespace read-only ou offline-normal

Backup completo consistente precisa de um shutdwon do banco com opção normal, immediate ou transactional.

Exceção: bancos read-only

Backup: Princípios

Backup Inconsistente

É um backup de um ou mais arquivos do banco de dados enquanto o banco está aberto ou após ele ter sido fechado de forma anormal

Todos os datafile e control files não tem o mesmo SCN

Backup: Princípios


O banco não poderá ser aberto até que todos os SCN estejam consistentes (banco sincronizado), ou seja, até que sejam aplicados todos os redos nos datafiles.

Para backups completos de bancos 24X7 é a única opção

Banco deve estar em modo ARCHIVELOG para garantir a recuperação e consistência após a restauração do backup

Backup: Princípios


Backups completos em banco fechado após shutdown abort ou um chash de sistema é inconsistente

Oracle recomenda que não seja feito backup de banco fechado inconsistente no modo

NOARCHIVELOG.

Backup: Princípios


Se você estiver com o seu banco operando no modo NOARCHIVELOG, sempre tenha um backup que possa ser usado sem precisar de recuperação.

Backup: Princípios

Backup: Princípios

Backup Online

É o backup de datafiles online

Backup de um ou mais datafiles ou tablespace completa desde que o banco aberto esteja no modo ARCHIVELOG

Backup: Princípios

Backup Offline

É o backup em que a tablespace ou datafile está offline

Pode-se colocar a tablespace offline com o comando ALTER TABLESPACE OFFLINE seguido por uma das três opções: NORMAL, TEMPORARY OU IMMEDIATE

Backup: Princípios

Backups com RMAN

Utiliza formato proprietário para armazenar dados

Comandos: BACKUP COPY RESTORE

Backup: Princípios

Backups com RMAN

Na cópia ou backup com RMAN as ações são gravadas no control file (arquivo de controle) do banco de dados de destino ou no catálogo de recuperação

Backup: Princípios

Backups Gerenciados pelo Usuário

As ferramentas usadas são os utilitários do Sistema Operacional

O registro dos backups deve ser feito manualmente

Backup: Estratégias

1. Siga a Regra de Ouro do Backup/Recovery

2. Escolha o Modo de Arquivamento do Banco

3. Multiplexe control files, redo log online e redo logs arquivados

4. Realize Backups frequentemente

5. Realize Backups antes e depois de mudanças Estruturais

6. Realize Backups de Tablespaces usadas frequentemente


7. Realize Backups após operações sem recuperação

8. Realize Backups após Banco Aberto com RESETLOGS

9. Arquive Backups Antigos

10. Conheça as restrições de Backups para Bancos Distribuídos

11. Exporte Dados para aumentar a Flexibilidade e Proteção

12. Evite Backups de Redo log online

13. Mantenha Registro da Configuração de Hardware e Software do Servidor


1) Siga a Regra de Ouro do Backup/Recovery

Os discos que contém o backup devem

ser diferentes dos discos que contém os datafiles, online redo logs e control files.


Guia para implementar a Regra de Ouro

Multiplexe os arquivos redo log online e os control files

Use espelhamento de hardware ou de SO para o control file e datafiles

Mantenha pelo menos uma cópia de backup no disco rígido


Guia para implementar a Regra de Ouro

Se o banco estiver armazenado em um dispositivo RAID, o backup deve estar em outro dispositivo RAID

No caso de fitas, mantenha sempre mais de uma cópia.

Mantenha cópias do mesmo dado em diferentes pontos no tempo


2) Escolha o Modo de Arquivamento do Banco

Se ocorrer uma falha que danifique algum dos arquivos do banco, é aceitável a perda de dados desde o último backup? Sim (NOARCHIVELOG) e Não (ARCHIVELOG)

Pode haver necessidade de retroceder o banco? Sim (ARCHIVELOG) e Não (NOARCHIVELOG)

O banco de dados deve estar disponível sempre? Sim (ARCHIVELOG) e Não (NOARCHIVELOG)



Modo NOARCHIVELOG O redo log online não é arquivado A única proteção contra falha de disco é backup completo

do banco

Estratégias: Faça backups completos regularmente de acordo com a

perda de dados aceitável Faça backups completos sempre que a estrutura física do

banco de dados seja alterada



Modo ARCHIVELOG O redo log online é arquivado

Estratégias:

Faça um backup completo do banco após sua criação

Faça backup de tablespaces com o banco aberto ou fechado freqüentemente para reduzir o tempo de recuperação



Modo ARCHIVELOG

Estratégias (continuação)

Copie o arquivo de controle sempre após uma mudança estrutural no banco

Faça cópia do redo logs arquivados frequentemente. Pelo menos duas cópias em dispositivos diferentes.



Coloque o banco no modo de arquivamento

LOG_ARCHIVE_MAX_PROCESSES – Define o máximo de processos que participaram do arquivamento

Backup: Estratégias2) Escolha o Modo de Arquivamento do Banco

Arquivamento automático

LOG_ARCHIVE_START

Visões dinâmicas: V$ARCHIVED_LOG

Informações sobre logs arquivados a partir do controlfile V$ARCHIVE_DEST

Descreve todos os destinos dos logs de arquivamento V$LOG_HISTORY

Informações de arquivos de log obtidas do controlfile



Visões dinâmicas: V$DATABASE

Estado atual do arquivamento

V$ARCHIVE_PROCESSES Informações sobre o estado de vários processos ARCH para a

instância


3) Multiplexe control files, redo log online e

redo logs arquivados

Mantenha pelo menos duas cópias do arquivo de controle em discos diferentes, com diferentes controladoras

Mantenha duas ou mais cópias dos arquivos de redo log online em discos diferentes

Mantenha duas ou mais cópias dos redo logs arquivados: diferentes discos e diferentes mídias


Como multiplexar arquivos de controle

Desative o banco de dados

Faça uma cópia do arquivo de controle existente em outro dispositivo usando os comandos do SO

Edite ou adicione o parâmetro CONTROL_FILES e especifique nomes para todos os arquivos de controle

Inicie o banco de dados


4) Realize Backups frequentemente

Baseie a frequencia do backup de acordo com a taxa de mudança do banco tais como:

Adição e deleção de tabelas Inserção e deleção de linhas em tabelas existentes Atualização de dados das tabelas

Muitos comandos DML – Maior frequencia


5) Realize Backups antes e depois de

mudanças Estruturais

Criação ou eliminação de tablespaces

Adição ou alteração no nome de arquivos de dados

Adição, mudança de nome ou eliminação de grupos ou membros de redo log online


5) Realize Backups antes e depois de

mudanças Estruturais

A parte do banco de dados em que deve ser feito backup depende do modo de arquivamento:

Modo ARCHIVELOG - backup do controlfile

Modo NOARCHIVELOG - backup consistente completo do banco de dados antes e depois da mudança


6) Realize Backups de Tablespaces usadas frequentemente

No modo ARCHIVELOG pode-se fazer backup dos datafiles de uma tablespace ou até mesmo de um único datafile.

Fazer backup de arquivos de dados usados extensivamente reduz o tempo necessário para recuperação do banco de dados


7) Realize Backups após operações sem recuperação (Unrecoverable Operations)

Após criar tabelas e indices com a opção UNRECOVERABLE faça backup porque o Oracle não armazerna dados no redo o que impossibilita a sua recuperação em caso de falha.


8) Realize Backups após Banco Aberto com RESETLOGS

Após abertura do banco com o RESETLOGS é criada uma nova encarnação do banco

Se não for feito backup e uma falha ocorrer é possível perder todas as mudanças após a abertura do banco.

Alternativa: usar backup do controlfile antes e após o resetlogs (operação complicada)


9) Arquive Backups Antigos

Razões:

Backup atual corrompido (NOARCHIVELOG ou ARCHIVELOG)

Realizar recuperação incompleta em um tempo passado (ARCHIVELOG)


10) Conheça as restrições de Backups para Bancos Distribuídos

Todos os bancos devem ter o mesmo modo de arquivamento

Se os bancos forem fechados normalmente:

ARCHIVELOG, backup em cada nó (banco) de forma autônima

NOARCHIVELOG, todos os nó devem realizar um backup completo e consistente no mesmo momento


11) Exporte Dados para aumentar a Flexibilidade e Proteção

Um export fornece um snapshot dos dados lógicos (tabelas, stored procedures, etc) podendo exportar objetos específicos


12) Evite Backups de Redo log online Melhor multiplexar membros em cada grupo em

diferentes discos e controladoras

No modo ARCHIVELOG os grupos cheios já estão sendo armazenados

No modo NOARCHIVELOG, o backup é completo e consistente do banco fechado

Pode-se danificar o banco restaurando dados deste tipo de backup


13) Mantenha Registro da Configuração de Hardware e Software do Servidor

Hardware

Nome do nó, fornecedor e modelo da máquina, versão e patch do sistema operacional, capacidade do disco do servidor, quantidade de discos e controladoras, capacidade e espaço livre no disco, fornecedor do gerenciador de mídia e tipos de dispositivos

Backup: Estratégias13) Mantenha Registro da Configuração de

Hardware e Software do Servidor

SoftwareNome do nó, fornecedor e modelo da máquina, versão e patch do sistema operacional, capacidade do disco do servidor, quantidade de discos e controladoras, capacidade e espaço livre no disco, fornecedor do gerenciador de mídia e tipos de dispositivos, o método de restauração e recuperação usado (RMAN ou não) e os pontos de montagem dos arquivos de dados


Orientações Antes de criar um banco de dados Oracle,decida

como protegê-lo contra potenciais falhas.

Se você não desenvolver uma estratégia de backup apropriada, talvez não seja possível realizar uma eventual recuperação se uma falha de disco danificar os arquivos importantes ao banco como os datafiles, arquivos do redo log online ou os controlfiles.

CAPÍTULO 3Considerações sobre

Recuperação

Considerações sobre Recuperação

Recuperação (Recovery) consiste na atualização dos arquivos restaurados do backup


Estruturas de Recuperação

Redo Logs

Segmentos de Rollback ou Undo

Arquivos de controle


Estruturas de Recuperação - Redo Logs

Armazenam todas as mudanças feitas no Banco de dados

Redo Logs online possuem pelo menos 2 grupos de redo, onde cada possui pelo menos 1 membro que trata-se de um arquivo que armazena os registros de redo


Estruturas de Recuperação - Redo Logs

LGWR grava as mudanças da instância no grupos de redo de forma circular

São armazenados valores antigos e novos das transações

Podem ser arquivados


Redo Logs durante a Recuperação Recuperação de Cache (Cache Recovery)

Rolling forward com o redo log

Visões sobre os Redo Logs V$LOG (número de membros, status, número do grupo etc) V$LOGFILE (número do grupo de cada membro, status, nomes

dos membros) V$LOG_HISTORY (informações sobre histórico de logs do

controlfile)


Redo Logs durante a Recuperação

Parâmetros de definição LOG_ARCHIVE_START LOG_ARCHIVE_FORMAT (incluir o número de sequencia de

log e o número do thread como parte do arquivo)


Estruturas de Recuperação - Segmentos de Rollback ou Undo

Armazenam os valores antigos dos dados nas transações não efetivadas (commit)

Modo de Funcionamento do Banco de Dados Manual Undo Management Mode

Segmentos de Rollback

Automatic Undo Management Mode Tablespace Undo


Segmentos de Rollback ou Undo durante a Recuperação

Recuperação de transação (Recovery Transaction)

Rolling back com os segmentos de rollback ou undo

São os blocos de undo que desfazem os efeitos de transações não efetivadas aplicadas previamente na fase de rolling forward


Estruturas de Recuperação - Arquivos de Controle

Armazenam o status da estrutura física do banco de dados

Informações sobre checkpoints, redo log online atual são uteis para a recuperação


Estruturas de Recuperação - Arquivos de Controle

Visões: V$PARAMETER V$CONTROLFILE

CAPÍTULO 4Recuperação: Princípios

e Estratégias

Recuperação: Princípios

Tipos de Recuperação

Recuperação Durante Aplicação de Redo

Recuperação de Mídia Completa ou Incompleta

Restauração e Recuperação pelo RMAN ou Gerenciada pelo Usuário


Antes de recuperar o banco, consulte a visão V$RECOVER_FILE para descobrir quais arquivos precisam de recuperação


Tipos de Recuperação

Recuperação de Crash (Crash Recovery) Falha na instância de um banco ou todas em um

banco em RAC

Recuperação de Instância (Instance Recovery) A instância sobrevivente recupera as outras

Recuperação de Mídia (Midia Recovery) Termo refere-se a recuperação de datafiles.

Recuperação de Blocos é uma operação mais especializada via RMAN


Recuperação de Crash e instância – Características comuns

Usa apenas redo log online e datafiles para recuperar após o crash ou shutdown abort do banco. Não precisa de redo log arquivados.

A recuperação é automática, ou seja, redo logs são aplicados automaticamente

Tempo de recuperação depende da quantidade de instâncias paradas, da quantidade de redo a ser aplicado e das configurações do usuário


Recuperação de Crash e Instância

Como controlar o tempo?

Ajuste a duração da recuperação

Ajuste as fases da recuperação


Ajuste a duração da recuperação da instância nos limites especificados pelo usuário...

V$INSTANCE_RECOVERY


Ajuste a duração da recuperação da instância

Procedimentos

Defina os parâmetros de iniciação a fim de influenciar o número de registros de redo log e de blocos de dados a serem lidos na recuperaçãoFAST_START_MTTR_TARGET

Defina o tamanho dos arquivos de redo logs para influenciar a frequência de checkpoints


Ajuste a duração da recuperação da instância

Procedimentos

Execute instruções SQL para iniciar os checkpoints

Paralelize as operações de recuperação da instância


Recuperação de Crash e instância

Duas operações:

Rolling Forward

Atualiza os datafiles online aplicando as transações que foram comitadas ou não que estão no registro do redo

Rolling Back

As transações que não foram comitadas são desfeitass.


Recuperação de Crash e Instância

Quando e como ocorre?

Arquivos Fora de Sincronia

Rollforward (redo)

Dados efetivados ou não nos arquivos de dados

Rollback (undo)

Apenas dados efetivados nos arquivos


Fase de rollback

Rollback de inicialização rápida por demanda

Rollback de inicialização rápida em paralelo


Rollback de inicialização rápida sob Demanda

Estas são as ações de um processo do servidor que encontra dados a serem submetidos a rollback

Efetua rollback do bloco que contém a linha necessária

Entrega outras operações de recuperação, que podem estar ocorrendo em paralelo, ao SMON


Rollback de inicialização rápida em paralelo

Parâmetro:

FAST_START_PARALLEL_ROLLBACK


Recuperação de Mídia

Quando é necessária ?

Recuperar o banco de um arquivo de dados ou de controle perdido ou danificado

Recuperar mudanças que foram perdidas quando a tablespace foi colocada offline sem a opção normal



Tipos:

Completa

Incompleta



Recuperação de Mídia Completa

Utiliza dados de redo online e arquivados ou backups incrementais

Backup de um banco de dados, de tablespace ou de arquivos de dados para atualizá-lo



Recuperação de todo o banco. Passos:

Monte o banco Garanta que os arquivos de dados a serem recuperados

estão online Recupere o backup Aplique os redo logs necessários



Recuperação de uma tablespace ou arquivo de dados. Passos:

Coloque o tablespace ou o arquivo de dados offline (se banco aberto)

Restaure o backup desejado Aplique os redo logs necessários


Recuperação de Mídia Incompleta

Utiliza backup (redo log arquivados) para produzir uma versão antiga do banco de dados



Quando usar:

Algum ou todos os redo logs online foram destruídos

Erro do usuário destruiu algum objeto Falta de algum redo log arquivado Perda do arquivo de controle



Opções: Baseada no tempo Até cancelamento Até um SCN específico Até uma sequência específica de log (RMAN)



Quando a recuperação incompleta terminar, o banco sempre deverá ser aberto com a opção RESETLOGS



Usos:

Recuperação de datafiles

Recuperação de blocos (RMAN)

TSPITR


Recuperação de Mídia – Recuperação de

arquivo de dados

Características:

Recupera as informações a partir dos arquivos de dados restaurados

Pode usar redo logs online ou arquivados Execução disparada pelo usuário Tempo de recuperação configurável


Recuperação de Mídia - Recuperação de blocos de dados

Características:

Restaura e recupera blocos com todos os arquivos online e disponíveis

Util quando há poucos blocos corrompidos


Recuperação de Mídia – Recuperação

TSPITR

Consiste em recuperar uma tablespace até um momento anterior ao do restante do banco


Recuperação de Mídia – Recuperação

TSPITR

Quando usar:

Recuperar uma tabela truncada ou eliminada Recuperar uma tabela logicamente corrompida Recuperar uma parte do banco que foi alterada

por alguma operação DML ou job Recuperar um único esquema

Recuperação: Estratégias

1. Teste as Estratégias de Backup e Recuperação

2. Valide Backups e Restaurações usando o RMAN

3. Planeje uma Resposta para Falhas de Mídia

4. Planeje uma Resposta para Recuperação de Blocos Corrompidos de Arquivos de Dados

5. Planeje uma Reposta para outras Falhas que não são de Mídia

6. Recuperação de Redo Log Online


1. Teste as Estratégias de Backup e

Recuperação

Pratique as técnicas de backup e recuperação em um banco de teste

No RMAN, use o comando DUPLICATE para criar o banco de teste

Se gerenciado pelo usuário, crie um novo banco de dados, um banco standby ou uma cópia do banco com comando do SO e SQL*Plus


2. Valide Backups e Restaurações usando o RMAN

Use a palavra VALIDATE com os comandosBACKUP e RESTORE.

BACKUP VALIDATE - é possível fazer um backup válido dos arquivos de dados?

RESTORE VALIDATE - é possível restaurar um backup feito pelo RMAN?


3. Planeje uma Resposta para Falhas de Mídia

Identifique os arquivos a serem recuperados Determine o tipo de recuperação possível e

necessária Restaure os backups ou cópias dos arquivos Aplique os redos gravados para recuperar os

arquivos de dados Abra o banco. Use RESETLOGS se recuperação

incompleta ou restauração de arquivo de controle


4. Planeje uma Resposta para Recuperação de Blocos Corrompidos de Arquivos de Dados

Recupere o bloco com o RMAN

O comando BLOCKRECOVER restaura e recupera os blocos com o banco aberto e o respectivo arquivo de dados online


5. Planeje uma Reposta para outras Falhas

que não são de Mídia

Falha de Instrução Falha na instância Erro do usuário - TSPITR ou DBPITR


DBPITR Restaure um backup completo do banco Recupere o banco para um tempo antes da falha Abra o banco com RESETLOGS

TSPITR

Crie uma instância auxiliar Recupere o tablespace no banco auxiliar até o ponto

desejado Importe os dados de volta para o banco principal

Soluções Oracle

Dúvidas?

Documents

Curso de Pós Graduação em Banco de Dados Procedimentos de Contigência e Alta Disponibilidade Prof.: MSc Flávio Gonçalves da Rocha