RMAN Workshop 12c Overview

RMAN (Recovery Manager) - Workshop 12c
RMAN
Workshop
12c

Visão Geral
 Este workshop destina-se a profissionais que
buscam “aprimorar” seus conhecimentos com o
RMAN (Recovery Manager).
 É desejável que se tenha o mínimo de conhecimento
da arquitetura de banco de dados Oracle, nas
versões 11g ou 12c.
 O workshop visa mostrar as principais
funcionalidades do RMAN e as respectivas ocasiões
para seu devido uso no ambiente de banco de
dados.
2

Agenda
3
 Overview
 Arquivos Suportados
 Backups & Restore Gerenciados por usuário
 Configurando o RMAN
 Backup & Relatórios
 Recovey & Relatórios
 Manipulando Falhas nos REDO Logs
 Data Pump

Instrutor
 Douglas Paiva de Sousa
 Oracle Instructor – Oradata Cons. e Treinamentos
 Oracle WDP Instructor – KaSolution
 Oracle WDP Instructor – Grupo Impacta
 http://douglasdba.wordpress.com
 http://douglasdba.profissionaloracle.com.br
 http://www.oradata.com.br/blog
http://br.linkedin.com/in/dpsdba/ @oradatact
4
/oradata

RMAN Workshop 12c
Overview

Conteúdo
 Variáveis de ambiente
 Conexão com o Banco de Dados
 Startup / Shutdown do Banco de Dados
6

Variáveis de Ambiente
Variáveis de ambiente
ORACLE_HOME (binários oracle dbca, sqlplus, netca e etc)
ORACLE_SID (“site identifier”, nome do banco de dados)
LD_LIBRARY_PATH (localização libs Linux/Unix)
PATH (Localização dos comandos executados)
7

Definição das Variáveis
 Digitadas manualmente no prompt
 Definidas estáticamente no .bash_profile
8

Arquivo oratab
 Funções:
Automatizar fornecimento das variáveis de
ambiente.
Automatizar a inicialização do banco de
dados.
 Localização:
Linux: /etc/oratab
Solaris: /var/opt/oracle
9

Arquivo oratab
10
 Formato:
<ORACLE_SID>:<ORACLE_HOME>:Y|N
Y = Banco de dados inicia-se automaticamente
N = Banco de dados inicia-se manual

. oraenv
11
 Utilitário para definir e/ou alternar as variáveis de
ambiente.
 Localização default: $ORACLE_HOE/bin
 Execução: $ . oraenv
Modo não interativo.

Conexão com o Banco de Dados
12
2 métodos de autenticação:
Sistema operacional
Arquivo de senhas
 Tipos de conexão:
Local Name
Easy Connect

13
Autenticação via SO
 Usuários privilegiados (DBAs) precisam ter seu usuário
de SO atribuídos ao grupo “dba”
 Permissão para execução de tarefas administrativas,
startup e shutdown do banco de dados.
 Somente usuários privilegiados podem usar o RMAN
 Para saber se um usuário é privilegiado, use o
comando “id” do sistema operacional (Linux).

14
Autenticação via SO
 Não é necessário informar login e senha, use apenas a
barra “/”. O usuário SYS sempre será atribuído como o
usuário da conexão.

15
Autenticação via SO (Grupos)
Grupo SO Privilegiado? Operações Permitidas
dba SIM Startup, shutdown, create e drop
database, archivelog, backup e recover
database
oinstall NÃO Instalação e Upgrade de software
oper SIM Startup, shutdown, archivelog, backup e
recover database
backupdba SIM Disponível apenas da versão 12c, pode
executar startup, shutdown e todas as
operacões de backup, restore e recover

16
Arquivo de senhas
 Utilizado quando não se faz autenticação via SO
 Utilizado para conexões de usuários privilegiados
 remote_login_password=exclusive
 Pode ser criado e recriado com o orapw

17
Arquivo de senhas
 Todo usuário com grant de sys* fica registrado no
arquivo de senhas
 A view v$pwfile_users demonstra esses usuários

18
Métodos de conexão
 Easy Connect:
 Local Name:
$ sqlplus user/pass@tnsnames

Startup / Shutdown
19
 Comando startup:
 Banco de dados passa por três etapas:
 NOMOUNT: Memória e inicia-se os processos de background
 MOUNT: Os controlfiles são validados
 OPEN: Checa-se a integridade dos redologs e datafiles
 É possível ver a alocação de memória para a SGA

Startup / Shutdown
20
 Também pode ser feito em etapas:
 Para operações de backup/restore/recover pode ser
necessário usar algumas outras opções conforme o
quando do próximo slide.

Startup / Shutdown
21
Parâmetro Razão para uso
FORCE Após um SHUTDOWN ABORT, é aconselhável um STARTUP FORCE para
que a instancia tente automaticamente executar o recover.
RESTRICT Permite conexões apenas de usuários com grant RESTRICT SESSION
PFILE Inicia a instancia a partir de um PFILE especifico
QUIET Oculta as informações da SGA na hora do STARTUP
OPEN RECOVER Tenta executar um RECOVER antes de abrir a instancia
OPEN READ ONLY Abrir o banco de dados somente para leituras
UPGRADE Abrir o banco de dados para processos de upgrade de versões
DOWNGRADE Abrir o banco de dados para processos de downgrade de versões

Startup / Shutdown
22
 Comando shutdown:
 Passa por dois processos:
 CLOSE: Descarrega todas as informações da memória para
os arquivos do disco (datafiles e redologs)
 DISMOUNTED: Encerra todos os processos de background
 Pode se ver o feed back da execução destes processos

Startup / Shutdown
23
 Para que um banco de dados seja desligado de
maneira correta (sem corromper dados), é preciso
executar um shutdown “limpo”, onde se garanta que
todas as informações da memória sejam persistidas em
disco, então pode se usar alguma destas opções
IMMEDIATE, TRANSACTIONAL [LOCAL] ou NORMAL.
 A opção ABORT não é recomendada! O uso desta
opção é o mesmo que desligar o cabo de energia de
seu servidor. Cuidado!!!

Startup / Shutdown
24
Parâmetro Efeito
NORMAL Aguarda todas as sessões ativas se
desconectarem-se do banco de dados.
TRANSACTIONAL Aguarda o término das transações das sessões
ativas
TRANSACTIONAL LOCAL Aguarda o término das transações somente da
instancia local
IMMEDIATE Termina todas as sessões ativas imediatamente e
executa rollback das transações pendentes
ABORT Termina as transações imediatamente e não
executa rollback das transações pendentes.

Resumo – Overview
25
 Neste capítulo discutimos os temas:
Variáveis de ambiente
Conexão com o Banco de Dados
Startup / Shutdown do Banco de Dados

RMAN Workshop 12c
Arquivos
Suportados

Conteúdo
 Gerenciamento de Control Files
 Gerenciamento de Redo Logs
 Implementando ARCHIVELOG
 Gerenciamento de Tablespaces e Data Files
27

Gerenciamento Control Files
 Arquivo binário que armazena informações
do banco de dados como:
Nome do banco de dados
Nome e localização (datafiles e REDO log)
Nome e localização de arquivos RMAN
 Informações podem ser consultados na view
v$controlfile_record_section.
28

29

 Considerações Importantes:
É preciso no mínimo 1 control file por instancia
A localização dos control files é obtida no
spfile, no parâmetro CONTROL_FILES
A todo momento a instancia de banco de
dados escreve no control file (checkpoints,
alterações físicas, operações de backup e
etc...)
30

 Processo de inicialização da instancia:
31
Neste momento é lido o parâmetro CONTROL_FILES no spfile
para que se encontre os control files, uma vez encontrados, os
processos de background são iniciados
Aqui o control file é aberto para leitura, para que se obtenha a
localização exata dos datafiles e arquivos de REDO logs.
Neste momento é verificada a consistência de datafiles,
REDO logs e do próprio control file, todos precisam estar no
mesmo SCN (System change number)

 Nome e localização:
 Via SQL*Plus:
32

 Adicionando Control Files:
 Copiar, recriar ou restaurar um control file existente.
 O arquivo original deve estar integro.
 Parâmetro CONTROL_FILES (spfile) deve ser atualizado.
 A operação deve ser feita com a instancia em shutdown.
 A cópia pode ser feita via comandos de SO.
 Recriação e restauração feitos com RMAN.
33

 Adicionando Control Files (SPFILE):
1. Determine a localização do control file:
2. Informe a localização do novo control file:
3. Desligue a instancia de banco de dados:
34

 Adicionando Control Files (SPFILE):
4. Faça a cópia do control file (via SO):
5. Inicialize o banco de dados:
6. Veja os resultados:
35

 Adicionando Control Files (init.ora):
 O procedimento com init.ora é o mesmo que se usa com
spfile, exceto o passo 2 que deve ser feito conforme
abaixo:
1. Abra o init.ora com um editor de texto:
2. Atualize a informações do parâmetro CONTROL_FILES:
 Os demais passos permanecem os mesmos.
36

 Removendo Control File:
 Certas vezes pode ser preciso remover um control file,
quando por exemplo o mesmo estiver corrompido ou você
perder a sua unidade de storage onde ele estiver
armazenado. Uma mensagem de erro será exibida ao
tentar inicializar o banco de dados:
37

 Removendo Control File:
 Para resolver esse tipo de problema, remova a
informação do control file do arquivo de parâmetros, ou
altere para uma nova localização dentro de seu servidor
e inicialize o banco de dados.
38

Gerenciamento Redo logs
 Arquivos de log que registram as transações ocorridas na
instancia.
 Garante a recuperabilidade das transações que sofreram
commit em caso de falha total da instância, mesmo que as
informações não tenham sido gravadas nos datafiles.
 Permite aos DBAs investigarem histórico de transações
através de ferramentas como LogMiner.
 Utilizado por outras ferramentas da Oracle como Golden
Gate e Oracle Streams para replicação de dados.
39

 É composto por grupos e membros, sendo necessário ter ao
mínimo 2 grupos e pelo menos um membro cada.
40

 São alimentados com informações vindas do log buffer
(buffer de redo log).
 O processo de background LGWR (log writer) retira as
informações do log buffer e envia aos arquivos de redo log
quando:
 Há um commit ou rollback.
 Um switch log ocorre.
 A cada três segundos.
 Um terço do log buffer está cheio.
 Um MB de informações no log buffer.
41

 Arquivos de redo log são cíclicos, ou seja, têm seu uso pelo
banco de dados sempre variando em três estados.
 ACTIVE (Ativo – Sendo usado no momento)
 INACTIVE (Inativo – Nunca foi usado, ocorre somente após a
criação da instância)
 CURRENT (Corrente – Está com informações de transações
ocorridas, mas ainda não virou archivelog)
42

 Exibindo informações dos arquivos de redo log.
43

 Encontrando o tamanho/quantidade ideal de redo logs.
 Na média é recomendado que ocorra a cada hora de duas a
seis “switchs” de log.
 Nunca use as configurações padrão se possível aumente para 4
grupos com 3 membros cada.
 A view v$LOG_HISTORY é muito útil para investigar quantas
vezes houveram os “switchs” de log ao longo de determinado
período.
 Para resolver eventuais problemas de falta arquivos de redo log,
você pode adicionar mais arquivos (grupos e membros) ou
aumentar a capacidade de armazenamento dos arquivos já
existentes.
44

 Verificando os “switchs” de log.
 Adicionando novos grupos de redo logs.
45

 Aumentando a capacidade de armazenamento dos
arquivos de redo log:
 Todos os arquivos de redo log devem ter o mesmo tamanho,
sendo assim se você adicionar arquivos com tamanhos
diferentes dos arquivos já existentes, deve excluir os
arquivos antigos.
46

 Excluindo arquivos de redo log:
 Para excluir um grupo de arquivos de redo log o mesmo deve
estar com seu status como INACTIVE.
 Consulte a view v$log para checar o status do grupo que deseja
excluir:
 Se o grupo desejado estiver como INACTIVE execute:
 Se receber um erro ORA-1623, significa que o grupo ainda é
necessário para um processo de media recovery, para resolver
este problema execute um checkpoint e volte a excluir o arquivo:
47

 Excluindo arquivos de redo log:
 Excluir um grupo de redo log, via Sql*Plus, não significa excluir
os arquivos no sistema operacional, apenas no banco de dados.
 Para excluir os arquivos no sistema operacional (após excluir no
banco de dados) execute algumas vezes o comando “alter
system switch logfile”, seguida vá ao diretório onde os arquivos
estão, e execute o comando de SO “$ ls -altr”, então vá ao
diretório e apague o arquivo com data de alteração mais
antiga.
48

 Adicionando e removendo membros:
 É possível adicionar e remover membros os grupos de redo log
a qualquer tempo.
 Para adicionar use ALTER DATABASE ADD LOGFILE MEMBER.
 Para remover use ALTER DATABASE DROP LOGFILE MEMBER.
 Antes de excluir um membro tenha certeza de que o mesmo
não está com o status como ACTIVE ou CURRENT.
49

 Adicionando um novo membro a um grupo já existente:
 Removendo um membro de um grupo já existente:
 Se receber o erro ORA-01623, significa que o membro
pertence a um grupo ativo:
 Execute um “switch” de log e tente novamente:
50

 Movendo redo logs:
 Alternativamente você pode precisar mover seus arquivos de
redo log para algum outro ponto de montagem dentro de seu
servidor.
 Esta operação só pode ser feita com o banco no modo
“closed” e “mount”.
 DICA: Caso não tenha oportunidade para o downtime
necessário, adicione novos grupos nos locais necessários e
exclua os grupos remanescentes em seguida, na prática, o
resultado será o mesmo.
51

 Movendo redo logs:
 Desligue a instancia de banco de dados:
 Mova o arquivo para o destino final:
 Coloque o banco no modo “mount”:
 Renomeie o arquivo no SPFILE:
 Abra a instancia de banco de dados:
52

Implementando Archivelog
53
 O que é archivelog?
 Continuação dos arquivos de redo log.
 Responsável por fazer o recover.

54
 Localização dos archivelogs (non-FRA):
 LOG_ARCHIVE_DEST_n: Local fixo onde seus archivelogs
serão gerados pelo banco de dados.
 LOG_ARCHIVE_FORMAT: Nome que terão seus archivelogs.
Boas práticas recomendam o uso das variáveis de
substituição.

55
 Definindo a localização exemplo (non-FRA):
 Você pode consultar as informações com o comando
“show parameter”.
 A partir do Oracle 11g, você pode ter 31locais
distintos para gerar os archivelogs.

56
 Se você tiver mais de um local definido para gerar os
archivelogs, você pode usar um parâmetro auxiliar
chamado LOG_ARCHIVE_MIN_SUCCED_DEST:
 Este parâmetro vai garantir o mínimo de localizações
necessárias para considerar que um archivelog foi
gerado com sucesso.
 Opcionalmente você pode consultar o status de cada
localização:

57
 Fast Recovery Area (FRA)
 Localização no servidor onde se define um limite de
armazenamento de informações que o banco de dados
pode gerar.
 Neste local geram-se os archivelogs, arquivos de backup,
logs de flashback e etc.
 Define-se a FRA com dois parâmetros no SPFILE:
 DB_RECOVERY_FILE_DEST (Local)
 DB_RECOVERT_FILE_DEST_SIZE (Limite de armazenamento)

58
 Nota: Se você estiver usando a FRA e definir o parâmetro
LOG_ARCHIVE_DEST_n com algum valor, os archivelogs
não mais serão gerados na FRA.

59
 Para colocar o banco de dados no modo archivelog, faça um
shutdown limpo (immeditate), coloque o banco no modo mount,
execute o comando “alter database archivelog” e na sequencia
abra o banco de dados:
 Você pode checar se o banco de dados está no modo archivelog
com o comando “archive log list”.
 Automatic archivel Enables (O modo archivelog está ativo)
 USE_DB_RECOVERY_FILE_DEST (FRA está sendo usada)

60
 Também é possível consultar se o modo archive está
ativo através de um select na view v$database.
 Para ver a localização e a capacidade máxima de
storage da FRA use o SQL*Plus com o comando
“sho parameter db_recovery_file_dest”

Tablespaces & Datafiles
61
 Unidade lógica para armazenamento de segmentos.
 Segmentos: Tabelas, índices, LOB, undo e etc.
 É composta por um ou mais datafiles.
 Visualizadas através da view DBA_TABLESPACES.
 Datafiles visualizados pela view DBA_DATA_FILES.
 Por padrão há 5 tablespaces default.
 SYSTEM
 SYSAUX
 UNDO
 USERS
 TEMP

62
 SYSTEM: Objetos do dicionário de dados, todos os
objetos do usuário SYS. O usuário SYS é o único que
pode persistir dados nesta tablespace.
 SYSAUX: (System Auxiliary) usada para ferramentas
auxiliares, Enterprise Manager, Statspack, LogMiner,
Logical Standby e etc.
 UNDO: Segmentos de UNDO, utilizados para leituras
consistentes e execução de ROLLBACK.
 TEMP: Persiste objetos temporários e transações que
não cabem na PGA do usuário.
 USERS: Tablespace default do banco de dados.

63
 1 Banco de dados : N tablespaces
 1 Tablespace : N datafiles
 1 Datafile : N segmentos (segments)
 1 Segmento : N extenções (extents)
 1 extenção : N blocos (data blocks)

64
 Boas Práticas:
 Use tablespaces distintas para cada usuário.
 Separe-as em três tipos: DADOS, ÍNDICES e LOB.
 Separe os datafiles em discos distintos com controladoras
distintas.
 Tablespaces para LOB normalmente precisam de blocksize
diferenciado, por razões de performance.
 Não use datafiles muito grandes (dificulta o gerenciamento
e a performance pode não ficar boa)
 Regra: Uma tablespace pode ter N datafiles, mas um
datafile pode pertencer somente a uma tablespace!

65
 Criando tablespaces:
 Use o comando CREATE TABLESPACE, informando o nome
que será usado, mais a localização do datafile e seu
respectivo tamanho:
 SEGMENT SPACE MANAGEMENT AUTO|MANUAL: Informa
aa instancia como gerenciar a ocupação dos datablocks, ao
utilizar AUTO dispensa-se o uso dos parametros PCTUSED,
FREELISTS e FREELISTS GROUPS. (Boa prática).

66
 Em determinado momento uma tablespace atingirá
100% de ocupação, para resolver essa situação,
pode-se:
 Aumentar o tamanho do datafile:
ALTER DATABASE DATAFILE ‘/data/users_01.dbf’ resize 5G;
 Adicionar um novo datafile:
ALTER TABLESPACE X ADD DATAFILE ‘/data/users_01.dbf’ size
5G;
 Criar a tablespace como AUTOEXTEND:
CREATE TABLESPACE TOOLS DATAFILE ‘/data/tools_01.dbf’
size 100M AUTOEXTEND ON NEXT 100M MAXSIZE 8G;

67
 Capturando DDLs de uma tablespace:
 Package DBMS_METADATA.GET_DDL
 Via SQL*Plus:
 Renomeando uma tablespace:
 Nome da tablespace é atualizado no dicionário de dados,
controlfiles e no cabeçalho dos próprios datafiles.
 Não é possível renomear as tablespaces SYSTEM e SYSAUX

68
 Controlando a geração de REDO:
 Utiliza-se da clausúla NOLOGGING.
 Recomendável para casos de “direct paht” e “SQL*Loader”
 Não gera REDO, não tem archive e não há recover!!!
 Para uma tablespace já existente:
 Para consultar uma tabela:

69
 Operações que suportam NOLOGGING:

70
 Uma tablespace pode ter três estágios.
 Read Write: Disponível para escrita e leitura, tabelas
podem receber qualquer tipo de DDL e DML (estágio
normal):
 Read Only: Disponível apenas para leitura, tabelas não
podem receber DDL e DML, apenas queries:
 Offline: Não pode receber leitura nem escrita, este estágio
é utilizado apenas para atividades de manutenção:

71
 Eliminando uma tablespace (DROP TABLESPACE)
 Usa-se o comando DROP TABLESPACE
 Recomenda-se colocar a tablespace offline
 Se alguém tentar usá-la receberá o erro ORA-00376
 Execute o comando “drop tablespace xxxx”
 Elimine os arquivos no sistema operacional
 Opcionalmente use INCLUDING CONTENTS AND DATAFILES
 Se usado não é preciso eliminar os datafiles no SO.

72
 Boas práticas:

73
 Oracle Managed Files (OMF)
 Automatiza o gerenciamento de arquivos no SO.
 Definido pelo parâmetro DB_CREATE_FILE_DEST no spfile.
 Vale também para arquivos de redo log.

74
 Compressão dados em tablespaces:
 Bancos de dados muito grandes.
 Economia de espaço em disco (storage).
 Queries tornam-se mais rápidas.
 Os dados são compactados e descompactados (I/O).
 Não se compacta a tablespace, mas sim se sinaliza a ela que
todas as tabelas ali persistidas devem ter seus dados
compactados:
 No 11g use COMPRESS FOR OLTP no lugar de STORE COMPRESS
ADVANCED

75
 Compressão dados em tablespaces:
 Consulte se uma tablespace está tem compactação definida:
 Defina compressão para uma tablespace já criada:
 Altere o modo de compressão:
 Desabilite o modo de compressão de uma tablespace:

76
 Datafiles online e offline:
 Até a versão 11g usado para operações de manutenção, restore e
recover.
 Há duas opções OFFLINE IMMEDIATE | NORMAL (default).
 OFFLINE NORMAL: Executa-se um checkpoint e as informações em
memória são persistidas nos datafiles. Não precisa de “Media
Recovery”.
 OFFLINE IMMEDIATE: Não há checkpoint, antes de voltar para o
modo online é preciso executar “Media Recovery” (instancia precisa
estar no modo archivelog).
 Se a instancia não estiver no modo archive um erro será exibido:

77
 Movendo e renomeando datafiles.
 Operação online (12c).
 Não precisa mais baixar a instancia.
 Transações continuam ocorrendo normalmente.
 Renomeando um datafile:
 Movendo um datafile:
 Pode-se usar ao invés do nome, o número do datafile:

78
 Movendo e renomeando datafiles.
 Operação offline (11g).
 Necessário baixar a instancia.
 Downtime para os usuários.
 Coloque a instancia no modo mount:
 Mova o datafile no sistema operacional:
 Mova o datafile dentro da instancia:

79
 Movendo e renomeando datafiles (controlfile).
 Se existir muitos arquivos para serem movimentados, talvez
pode ser mais fácil fazer uma alteração diretamente no
controlfile:
 Crie um backup do controlfile no modo TO TRACE:
 Baixe a instancia de banco de dados.
 Movimente os arquivos no sistema operacional.

80
 Abra o arquivo /tmp/mv.sql, altere o caminho dos datafiles

81
 Inicie a instancia no modo NOMOUNT.
 Re-crie o controlfile executando o arquivo “mv.sql”.
 Coloque a instancia no modo MOUNT.
 Abra o banco de dados.

Resumo – Arquivos Suportados
82
Neste capítulo discutimos os temas:
 Gerenciamento de Control Files
 Gerenciamento de Redo Logs
 Implementando ARCHIVELOG
 Gerenciamento de Tablespaces e Data
Files

RMAN Workshop 12c
User
Managed
Backups

Conteúdo
 Cold-Backup NOARCHIVELOG
 Hot-Backup (arquivelog)
 Database Complete Recovery
 Database Incomplete Recovery
84

Overview
 Maneiras de executar um backup:
 RMAN (Ferramenta oficial da Oracle Corporation)
 User-Managed Backup (Tarefas manuais)
 Porque saber sobre user-managed backups hoje?
 Muitas empresas ainda usam (Logo você será exigido)
 Solidifica seus conhecimentos em backup, restore e recover.
 Ajuda muito no tshoot de ferramentas como RMAN e Data
Guard
 Você vai apreciar ainda mais o RMAN e suas habilidades
85

Cold-Backup NOARCHIVELOG
 O que é?
 Uma cópia do banco de dados desligado.
 Datafiles, Controlfiles, arquivos de redo log.
 Gera indisponibilidade (Downtime)
 Pra que serve?
 Cópia de segurança de seu banco de dados.
 Ter um ponto de restauração (Flashback DB é melhor)
 Ambientes de Dev, Homologação e QA.
86

 Como fazer (Backup)?
 Determine o espaço necessário para o backup:
 Verifique se você tem este espaço no servidor com o
comando “df -h”:
87

 Identifique o nome e a localização dos arquivos que
precisarão fazer parte do seu backup:
 Datafiles, controlfiles, tempfiles e logfiles
88

 Execute um shutdown limpo (NORMAL, TRANSCTIONAL
ou IMMEDIATE) de seu banco de dados:
 Copie os arquivos (via sistema operacional) para o
local onde ficará seu backup:
 Inicie o banco de dados novamente:
89

 Como fazer (Restore)?
 Para fazer o restore de um backup cold, com o banco
de dados no modo NOARCHIVELOG, basta fazer a
engenharia reversa:
 Desligue a instancia (caso a mesma não tenha parado):
 Copie os arquivos de backup, para o local original:
 Inicie o banco de dados novamente:
90

 Como fazer (Restore sem redo logs)?
 Para fazer o restore de um backup cold, sem os
arquivos de redo log, siga o mesmo procedimento
anterior, porém coloque o banco no modo “mount”:
 Abra o banco de dados com OPEN RESETLOGS:
 Se aparecer a mensagem “Database altered”, significa
que tudo está ok, porém uma mensagem de erro pode
aparecer:
91

 Como fazer (Restore sem redo logs)?
 Caso a mensagem apareça, execute um “recover until
cancel”.
 O resultado deve ser:
 Na sequencia, execute “alter database open resetlogs”
92

 Script Cold-Backup (algoritmo):
 Automatiza o processo de backup (junto com crontab):
 ORACLE_SID
 ORACLE_HOME
 cbdir (local do backup)
 Conecta no SQL*Plus
 Captura o nome e local dos arquivos necessários
 Executa um “shutdown” do banco de dados
 Copia os arquivos para o local do backup
 Inicializa o banco de dados novamente.
93

 Script Cold-Backup (exemplo):
94

 Script Cold-Restore (algoritimo):
 Executa a engenria reversa do backup
 Conecta no SQL*Plus
 Captura o nome dos arquivos
 Copia os arquivos do backup para o local original
 Inicializa o banco de dados novamente
 Para realizar o processo execute o script “coldrest.sql”
95

 Script Cold-Restore (exemplo):
96

Hot Backup (archivelog)
 Hot Backup in archivelog (algorítmo)
 Garantir que a instancia esteja no modo archivelog.
 Determinar os arquivos que necessitam de backup.
 Colocar tablespace/banco no modo de backup.
 Copiar os arquivos via SO.
 Voltar banco/tablespace no modo normal.
 Copiar redologs (current) e o máximo de archivelogs.
 Backup do controlfile.
97

 Verifique se o banco está no modo archivelog.
 Verifique o tamanho de seu banco de dados, para
saber o quanto de espaço em disco será preciso.
 Identifique os datafiles que precisam de backup.
98

 É preciso estabelecer uma relação entre tablespaces e
datafiles na hora de colocá-los no modo de backup,
para isso execute o select abaixo:
 Para executar o recover da instancia, você precisa de
todos archivelogs gerados desde o inicio até o termino
de seu backup, para isso execute o select:
99

 Coloque sua instancia ou determinada tablespace no
modo de backup.
 Copie os datafiles através de comandos do sistema
operacional, para o local onde será armazenado seu
backup.
100

 Terminado o backup, volte sua instancia ou tablespaces
para o modo normal.
 Ao terminar a cópia dos arquivos e você tirá-los do
modo de backup, certifique-se de que nenhum foi
esquecido para não tenha problemas de performance,
para isso execute o select abaixo.
OBS: Este select não deve retornar registros.
101

 Execute um “switch” nos seus arquivos de redo log para
que você tenha um ponto de corte “limpo” no seu
banco de dados, na sequencia veja qual é a maior
sequencia de redo log para que possa recuperar
totalmente seu banco de dados em caso de falhas.
102

 Para garantir a recuperabilidade de seus controlfiles,
também é preciso fazer um backup dos mesmos. Para
isso use o SQL*Plus:
 Faça um backup de todos os seus archivelogs via
comandos de sistema operacional para o local de seus
backups.
103

 Script Hot Backup (exemplo):
 Você pode criar um script para automatizar este
processo. Com isso você não precisará ficar executando
os comandos um a um. O único pré-requisito é definir
três variáveis de ambiente:
 ORACLE_SID
 ORACLE_HOME
 hbdir
Veja o exemplo do script no próximo slide
104

105

 O script do slide anterior, gera um script (hotback.sql)
que será o seu script de backup, vide exemplo.
106

 Script Hot Restore (exemplo):
 Em caso de falhas no seu banco de dados, você pode
usar o backup feito outrora para restaurar os arquivos
danificados, para isso você pode usar o script:
107

 Script Hot Restore (exemplo):
 O script anterior vai gerar um script (hotrest.sql) que
executará o restore dos arquivos a partir da
localização do backup para o local de origem, vide
exemplo:
108

Recuperação Completa
 O que é?
 Fazer uma recuperação completa, significa recuperar o
banco de dados (ou parte dele) até a última transação
que sofreu “commit”.
 O que é necessário?
 No mínimo um backup integro e a instancia de banco
de dados deve estar no modo ARCHIVELOG.
 Como se faz?
 Via RMAN (Recomendável)
 Backups Gerenciados por usuário.
109

 Procedimento básico:
1. Colocar o banco no modo “MOUNT” ou a tablespace
envolvida “OFFLINE”.
2. Restaurar o(s) arquivo(s) danificados (via SO).
3. Executar o comando “RECOVER” apropriado no
SQL*Plus
4. Colocar a tablespace “ONLINE” novamente ou abrir
o banco de dados.
110

 Recuperação completa com a instancia offline:
 Crie uma tabela na tablespace users, insira alguns
registros (com commit).
 Faça alguns “switchs de log” para gerar “archivelogs”.
111

 Localize o datafile sua tablespace “users” para
apagá-lo e simular uma falha.
 Renomeie o datafile para outra pasta, para simular a
perda do mesmo.
112

 Execute um “shutdown immediate”, pode ser que um
erro aconteça (devido a falta do datafile), em caso
positivo, execute um “shutdown abort”.
 Após a instancia desligar, coloque-a em modo “mount”.
113

 Restaure o datafile danificado (via comando de SO).
 Antes de abrir a instancia, o Oracle compara o SCN
do cabeçalho do datafile com o SCN registrado no
controlfile para garantir a integridade. Faça isso
manualmente e veja se o SCN registrado no datafile é
o mesmo SCN que consta registrado no controlfile. Para
isso execute os dois próximos selects.
114

 Verificando o SCN no datafile.
 Verificando o SCN no controlfile.
115

 O datafile foi restaurado, mas repare que os SCNs são
diferentes, então se você tentar abrir a instancia um erro
será lançado.
 Isso acontece porque o datafile foi restaurado, mas não
recuperado ainda, ou seja outras transações ocorreram
desde o término do último backup.
116

 O processo de recover, pode ser feito em três níveis.
 Como em nosso exemplo supostamente perdemos uma
tablespace o nosso recover será direto na tablespace.
 Se as transações necessárias estiverem nos arquivos de
redo, o recover será executado normalmente.
117

 No momento do recover o Oracle analisa o cabeçalho
do datafile para determinar quais archivelogs
precisam ser aplicados. Caso você queira ver isso
manualmente, execute a query.
118

 Se as transações necessárias para fazer o recover não
estiverem nos arquivos de redo, o Oracle vai lhe sugerir o(s)
archives necessários para a recuperação do datafile.
 Você pode dar um “Enter” e deixar o processo aplicar o
archive sugerido, AUTO para que o Oracle
automaticamente aplique os archives ou CANCEL para
cancelar o processe de recover.
119

 Em nosso exemplo selecione a opção AUTO.
 O recover ocorrendo com sucesso, você pode abrir o
banco e checar se a tabela criada no inicio está
integra.
120

 Recuperação completa com a instancia online:
 Qualquer tablespaces exceto SYSTEM e UNDO.
 Coloque a tablespace/datafile offline.
 Restore datafile(s) (via comandos de SO).
 Recover do(s) datafile(s) via SQL*Plus.
 Coloque a tablespace/datafile online novamente.
121

Restore de Controlfiles
 Restore a partir de uma cópia sobrevivente:
 Veja no spfile como estão distribuídos seus controlfiles.
 Imagine que você perdeu o controlfile “control02.ctl”
 Dê um “shudown abort” na sua instancia.
122

 Restore a partir de uma cópia sobrevivente:
 Via comandos de SO, faça uma cópia do controlfile
sobrevivente para a localização do controlfile
danificado.
 Pronto! Instancia recuperada, agora é só subi-la
novamente com o comando “startup” (Neste caso não é
necessário “Recover”).
123

 Restore a partir de um backup.
 Este tipo de restore só é necessário quando se perde
todos os controlfiles.
 A mensagem de erro é a mesma de quando se perde
somente um controlfile.
 É preciso fazer o restore (via comandos de SO).
 É preciso fazer o recover (via SQL*Plus).
124

 Restore a partir de um backup (Algoritmo).
 Dê um “shutdown abort” na instancia.
 Restaure os controlfiles (a partir de um backup).
 Coloque a instancia no modo “mount” e faça o recover.
 Para um recover completo, aplique todos os archives.
 Abra a instancia no modo “OPEN RESETLOGS”
125

 Restore a partir de um backup (Exemplo).
 Ao perder todos os controlfiles de sua instancia, a
seguinte mensagem de erro deve aparecer.
 Primeiro passo, dar um “shutdown abort” na instancia.
 Restaure o backup de seu controlfile.
 Inicie a instancia no modo “mount”.
126

 Após fazer o restore de um controlfile, é preciso fazer
o recover, indicando que você vai recuperar um
controlfile a partir de um backup.
 Após a execução do “recover”, o Oracle irá lhe
perguntar como executar este recover, escolha a opção
“AUTO”.
127

 Pode ser que um erro seja exibido, informando que
determinado archivelog não foi encontrado, você pode
ignorar essa mensagem e tentar abrir a instancia.
Porém pode dar certo, ou outro erro pode surgir.
128

 Este erro significa que é preciso aplicar mais
transações do que há nos archives logs, sendo assim é
preciso aplicar transações que ainda estão nos
arquivos de redo log.
 Localize seus arquivos de redo log, pois a partir de
agora eles serão necessários.
129

 Agora ao executar o recover, quando o Oracle lhe
perguntar qual archivelog aplicar, vá informando o
caminho dos seus arquivos de redo log, até que a
mensagem de que o recover foi executado com sucesso.
130

 Terminado o recover, abra a instancia com a opção
“OPEN RESETLOGS”.
131

Recuperação Incompleta
 O que é?
 Fazer uma recuperação incompleta, significa recuperar
o banco de dados (ou parte dele) até determinado
período do passado.
 O que é necessário?
 No mínimo um backup integro e a instancia de banco
de dados deve estar no modo ARCHIVELOG.
 Como se faz?
 Via RMAN (Recomendável)
 Backups Gerenciados por usuário.
132

 Porque fazer uma recuperação incompleta?
 Recuperar a instancia até certo ponto, onde se perdeu um
archivelog.
 Restaurar o banco de dados até determinado período do
tempo de antecedeu uma falha, como por exemplo deletes
e drops indevidos.
 Criar um ambiente de testes guiado por um baseline.
 Uma recuperação incompleta pode ser feita em:
 Cancel Based.
 SCN Based.
 Time Based.
133

 CANCEL BASED:
 Restaurar o banco de dados até onde for possível
(tecnicamente). Imagine que você perdeu um archivelog e
quer restaurar seu banco até o último archivelog integro
que você tenha.
 SCN BASED:
 Restaurar o banco de dados até determinado SCN (system
change number). Para essa opção use a clausula UNTIL
CHANGE.
 TIME BASED:
 Restaurar o banco até determinado periodo no tempo,
onde se conheça exatamente a data/hora/minuto/segundo.
134

 Recuperação incompleta (Algoritmo).
 Dê um “shutdown” na instancia.
 Restaure todos os seus datafiles.
 Inicie a instancia em modo “mount”.
 Execute o recover baseado em cancel, SCN ou time.
 Abra o banco com a opção “OPEN RESETLOGS”.
135

 Recuperação incompleta (Exemplo).
 Shutdown na instancia.
 Restore dos datafiles.
 Inicie a instancia em modo “mount” e faça o recover
com a opção desejada.
136

 Recuperação incompleta (Exemplo).
 Como já é conhecido, o Oracle vai perguntar até onde
você deseja recuperar o sua instancia. Seguindo nosso
exemplo, informe CANCEL.
 Terminado o recover, abra a instancia com a opção
“OPEN RESETLOGS”.
137

Resumo – User Managed Backups
Neste capítulo discutimos os temas:
 Cold-Backup NOARCHIVELOG
Hot-Backup (arquivelog)
Database Complete Recovery
Database Incomplete Recovery
138

RMAN Workshop 12c
Configurações

Conteúdo
 Arquitetura Geral
 Acesso ao RMAN
 Definições de local de armazenamento
 Configurações Persistentes
 Paralelismo de operações
 Backup de archivelogs
 Políticas de retenção
 Compactação e encriptação
140

Visão Geral
 RMAN: Ferramenta de backup oficial da Oracle,
vem por default em todas as versões, com
características robustas e flexíveis.
 Comandos fácies e intuitivos.
 Gerenciamento automático de backups obsoletos.
 Backups incrementais, criptografados e compactados.
 Backups: Tablespace, datafile, tabelas e blocos.
 Conversão de plataformas (Linux x Windows etc...)
 Detecção automática de blocos corrompidos.
 Data Recover Advisor (Detecção automática de falhas).
141

Visão Geral
 DBA: Profissional responsável pela operação.
 Target Database: Banco de dados que sofre a operação de
backup.
 RMAN Client: Utilitário responsável pela execução das tarefas.
 Server processes: 2 processos de servidor, um responsável pela
interação PL/SQL e outro para coordenar as atualizações do
dicionário de dados.
 Channel: Número de threads responsáveis pelo I/O nas operações
de backup/restore.
 PL/SQL Packages: DBMS_RCVMAN e
DBMS_BACKUP_RESTORE.DBMS_RCVMAN responsáveis pelas
operações de backup/restore e recover.
 Buffers de Memória: PGA e SGA, buffers responsáveis pelas
operações de cópia dos blocos nas operações de backup/restore.
143

Visão Geral
 Auxiliar Database: Instancia de banco de dados utilizadas para as
operações de replicação de dados.
 Backup Piece: Arquivo que faz parte de um conjunto de arquivos
formando logicamente um backup.
 Backup Set: Conjunto de backup pieces que logicamente formam um
backup.
 Image Copy: Cópia exata de um datafile/banco de dados (similar
ao comando de cópia do SO “scp”)
 Recover Catalog: Banco de dados opcional, para armazenar os
metadados de todas as operações de backup.
 Media Manager: Software de terceiros, responsável por conectar o
banco de dados ao hardware para backups em fita.
 FRA: Um disco opcional para armazenar os arquivos de backup e
archivelogs além das cópias multiplexadas do controlfile e dos
arquivos de redo log.
144

Visão Geral
 Snapshot control file: Imagem integra de um controlfile, utilizada
para as operações de backup.
 Backup Full: Todos os blocos do banco de dados, que não estejam
vazios.
 Backup incremental level 0: O mesmo que um backup full, porém
serve para ser utilizado como base para um backup incremental.
 Backup incremental level 1: Backup que contém somente os blocos
de dados que tiveram alterações desde o ultimo backup de level 0.
 Backup incrementado: Backup de image copy que sofre um
processo de recover para se manter atualizado de acordo com as
modificações do banco de dados de produção.
 Block change tracking: Arquivo que registra o endereço dos blocos
que são alterados após a execução de um backup de level 0. Este
processo serve para acelerar o processo de backups incrementais.
145

Acessando o RMAN
 Localmente (direto do servidor) 
 Informando login e senha 
 Remotamente (Protocolo Oracle Net):
 Por dentro do aplicativo 
 Quando conectado, é exibido o output:
 Para Sair do RMAN:
146

Acessando o RMAN
 Comandos de SQL*Plus por dentro do RMAN:
 Antes da versão 12c 
 Na versão 12c 
 Backup / Restore / Recover:
 Backup de seu banco de dados:
 Restore de seu banco de dados:
 Recover de seu banco de dados 
147

Configurações
 Backups via RMAN podem ser feitos de 2 formas:
 Cold Backup (Offline).
 É preciso executar um “shutdown” e colocar a instancia em
modo “mount” para executar o backup.
 Hot Backup (Online).
 Não é preciso executar um “shutdown”.
 A instancia precisa estar no modo “archivelog”.
 Archivelogs, podem ser gerados na FRA ou em outro local.
 O parâmetro LOG_ARCHIVE_DEST_n define o local.
 Se omitir a FRA e o local adicional os archives serão
gerados em $ORACLE_HOME/dbs
148

Configurações
 Formato dos archivelogs:
 Quando na FRA:
 Quando em outra localidade (Destino):
 Quando em outra localidade (Formato):
 Por default a extensão dos archivelogs é “.dbf”, mas
para não confundir com os datafiles recomenda-se
trocar para “.arc”.
149

Configurações
 Localização dos backups.
 Localização default.
 FRA.
 Comando “BACKUP.... FORMAT”.
Exemplo de arquivo de backup:
150

Configurações
 Comando “CONFIGURE CHANNEL... FORMAT”
Após essa configuração, o backup que será executado,
vai gerar os backup pieces nos diretórios, especificados
acima (uma thread para cada canal), você pode também
especificar um canal único com três threads, o que é
melhor recomendado.
 Comando para executar o backup:
151

Configurações
 Backup automático do controlfile:
 É preciso um backup do controlfile quando:
 Se adiciona/remove uma tablespace.
 Se altera algo na estrutura física do banco.
 Para configurar, use o RMAN.
 Formatos de backup:
152

Configurações
 Backup dos archivelogs:
 É preciso ter seus archives para executar o “recover”.
 Você basicamente precisa dos “archives” até o próximo
backup integro.
 Se não houver necessidades especiais, você deve
removê-los.
 Para incluir seus “archives” no seu backup, use o
seguinte comando:
153

Configurações
 Snapshot Control File:
 Sincronização com o catálogo de recuperação.
 Backup do controlfile corrente.
 Localização padrão:
 Verificar a configuração atual:
 Alterar a configuração atual:
154

Configurações
 CONTROL_FILE_RECORD_KEEP_TIME
 Parâmetro do SPFILE.
 Responsável por informar quanto tempo (em dias) os
metadados do backups devem ser mantidos no disco.
 Valor default é 7.
 Pode ir de 0 a 365.
155

Configurações
 Política de retenção de backup:
 Por janela de recuperação:
Quantidade de dias que você deve manter seus backups
em disco, para que se faça um restore/recover se
necessário.
 Por redundância:
Número de cópias (exatamente iguais) que você deve ter
no disco de cada backup.
156

Configurações
 Deletando backups obsoletos.
 Backups fora da sua politica de retenção, seja ela por
janela ou redundância.
 Você pode consultar os backups obsoletos:
 E na sequencia, excluí-los:
 Você pode excluir os arquivos, sem ser questionado:
157

Configurações
 Tipos de backup:
 Image Copy:
Uma cópia fiel de seus datafile e archivelogs, similar a
um comando do SO (cp ou copy). Desvantagem: Alto
consumo de disco.
 Backup Set:
Backup somente dos blocos que possuem informações
(blocos vazios, não são incluídos), arquivo em formato
binário, encriptado e compactado: Vantagem: Economia
de storage.
158

Configurações
 Compactação de Backups:
 Backups do tipo backup set, já compactados por
padrão, porém podem ser compactados em um nível
mais elevado.
 Pode ser compactados em dois momentos distintos:
 No comando BACKUP
 Nas configurações persistentes, com o comando CONFIGURE
159

Configurações
 Compactação de Backups:
 Compactação direta no comando backup:
 Definindo compactação nas configurações persistentes:
 Verificando as configurações de compactação:
 Definindo as opções de compactação:
160

Configurações
 Encriptação de Backups:
 Por questões de segurança, você pode criptografar seu
backup, isso é transparente para as operações de
backup/restore.
 Habilitando a encriptação:
 Desabilitando a encriptação:
 Redefinindo as opções de encriptação:
161

Configurações
 Comandos SQL no RMAN:
 Antes da versão 12c:
 Na versão 12c:
Antes da versão 12c, era preciso a palavra chave “sql” e
“selects” não retornavam resultados. Agora não há mais
essa necessidade, para nenhum tipo de comando.
162

Configurações
 Configurações Adicionais:
 Tamanho máximo dos backupsets:
 Tamanho máximo dos backup pieces:
 Tamanho do buffer de leitura (em MB de 0 a 200):
 Número máximo de arquivos abertos:
163

Configurações
 Configurações Adicionais:
 Formato de exibição da data e hora.
“.bash_profile” configure a variável NLS_DATE_FORMAT
 Coloque a clausula SET ECHO ON dentro do seu script:
 Útil na hora de fazer tshoot, para se saber a data e
hora exata de cada evento nos arquivos de log das
operações do RMAN.
164

Resumo – RMAN Configurações
 Arquitetura Geral
 Acesso ao RMAN
 Definições de local de armazenamento
 Configurações Persistentes
 Paralelismo de operações
 Backup de archivelogs
 Políticas de retenção
 Compactação e encriptação
165

RMAN Workshop 12c
Backups e
Reports

Conteúdo
 Executando operações de backups
 Backup de pluggable Databases
 Backups incrementais
 Verificação de arquivos corrompidos
 RMAN Catalogo de recuperação
 Logs do RMAN
 Relatórios do RMAN
167

Backups & Reports
Com o RMAN é possível fazer backup dos seguintes
componentes de seu banco de dados:
 Datafiles
 Controlfiles
 Archivelogs
 SPFILES
 Backup Pieces
168

Backups & Reports
Configurações básicas.
 Backup automático de controlfile.
 Configurações de localização e formato dos arquivos.
 Operação de backup.
169

Backups & Reports
Backup Full x Backup Incremental.
 Não fazem backup de 100% dos blocos.
 Backup somente dos blocos não vazios (necessários
para uma recuperação em caso de falhas).
 São praticamente a mesma coisa. A diferença é
que após de um backup level 0, pode se fazer um
backup de level 1.
170
Backup FULL
Backup INCREMENTAL
Level 0

Backups & Reports
Backupsets x Image Copy
171
Produção
Backup
100GB 100GB
Backup
Image Copy
Produção
Backup
100GB
30GBBackup
Backupset

Backups & Reports
Níveis de Backup.
 Banco de dados.
 Tablespaces.
 Datafiles (Nome/Path).
 Datafiles (números file# v$datafile).
172
Database
Backup
RMAN

Backups & Reports
Backup do controlfile & SPFILE:
 Pode ser automatizado via comando CONFIGURE.
 Pode ser feito manualmente com o comando BACKUP.
OBS: Quando se configura o backup do controlfile para ser
feito de maneira automática, ó mesmo comando já vale para
o backup automático do SPFILE.
173

Backups & Reports
Backup do controlfile & SPFILE (Porque?):
 Controlfiles: armazenam metadados de seu banco de
dados, ou seja, a localização de datafiles, arquivos de
redo log e archivelogs. Essas informações são
necessárias em caso de uma perda total de seu banco
de dados.
 SPFILE: armazena parâmetros de configuração da
instancia, é lido no momento do “STARTUP”, pode ser
recuperado da memória da instancia também, caso a
mesma esteja ativa.
174

Backups & Reports
Backup de Archive Redo Logs.
 Pode ser incluído diretamente no backup dos datafiles.
 Pode ser separadamente.
 Pode ser feito de um archive especifico ou um range de
sequences ou de tempo.
175

Backups & Reports
Backup de Archive Redo Logs.
 Pode ser feito e na sequencia, já se apagar os
arquivos de input (para economizar disco).
 Se algum archive for manualmente excluído do disco,
via comando de SO o seguinte erro pode ocorrer.
 É recomendável se executar sempre um CROSSCHECK,
checagem cruzada disco vs dicionário de dados.
176

Backups & Reports
Backup da FRA (Fast Recovery Area):
 A FRA é um DISKGROUP como qualquer outro, embora
seu papel seja prover a recuperabilidade da instancia,
sendo assim é recomendável executar um backup dela
preferencialmente para fita ou para algum outro disco.
 Backup em fita.
 Backup em disco.
177

Backups & Reports
Excluindo Tablespaces do Backup:
 Você pode explicitamente excluir tablespaces de seu
backup caso elas não tenham informações relevantes.
 Verificando se há tablespaces marcadas como EXCLUDE.
 Excluindo uma tablespace (users) das operações de backup.
 Ignorando a opção EXCLUDE.
 Desabilitando a opção EXCLUDE.
178

Backups & Reports
Opções Adicionais de Backup:
 Backup de tablespaces que “ainda” não tem backup.
 Excluindo tablespaces READ ONLY.
179

Backups & Reports
Ignorando Datafiles Inacessiveis.
 Se algum datafile estiver danificado a instancia não
irá iniciar e um erro será lançado:
 O correto é um restore/recover do banco de dados,
mas se não houver backup para tal, é possível abrir a
instancia ignorando o datafile danificado.
180

Backups & Reports
Ignorando Datafiles Inacessiveis (Backup).
 Se algum datafile estiver danificado no momento do
backup um erro será lançado:
 Você pode usar a clausula “SKIP INACCESSIBLE”.
 Pode se excluir tablespaces off-line.
 Ou todos juntos.
181

Backups & Reports
Backups para datafiles grandes (Multsection)
 Backups de datafiles muito grandes, podem demorar
demais para executar.
 O arquivo de backup pode ficar muito grande.
 Pode se acelerar este processo de duas formas,
aumentando o paralelismo e dividindo o tamanho do
arquivo de backup, com isso se otimiza o tempo e
ganha-se performance.
182

Backups & Reports
Backups Pluggable & Container Databases:
Na versão 12c é possível trabalhar com o conceito de
bancos de dados “Multitenant”, ou seja, uma instancia
para “N” banco de dados. Com isso você pode:
 Conectado no “root container” fazer backup de todos os
datafiles de todos os bancos de dados, ou apenas do
“container”.
 Conectado a um “pluggable” database, executar backups
somente de datafiles associados ao mesmo.
183

Backups & Reports
 Para descobrir onde está conectado:
 Conectado no “root container”, para fazer um backup
de “todo” o ambiente (incluindo PDBs):
184

Backups & Reports
 Conectado no “root container” para fazer um backup
somente dos datafiles associados ao mesmo.
 Conectado no “root container” pode se fazer o backup
de um “plugglable database”.
 Ou até mesmo de uma tablespace em especifico.
 Ou um datafile diretamente.
185

Backups & Reports
 Quando conectado diretamente em um “pluggable
database”, só é possível fazer backup dos datafiles
associados ao próprio PDB, mesmo que esteja
conectado com SYSDBA ou SYSBACKUP.
186

Backups & Reports
Pluggable & Container Databases (Overview):
187

Backups & Reports
Backups Incrementais:
No Oracle, é possível fazer backups incrementais de
três maneiras distintas:
 Backup incremental level=0.
 Backup incremental level=1.
 Cumulativo.
 Diferencial.
 Backups incrementados.
188

Backups & Reports
 Backups incrementais level=0: Todos os blocos do
bancos de dados/tablespace (quando explicitamente
informada), desde que os blocos tenham informações
armazenadas.
 Backups incrementais level=1: Todos os blocos que
tiveram alterações, desde o ultimo backup (level 0 ou 1
dependendo da estratégia utilizada).
189

Backups & Reports
 Backup incremental level=1 CUMULATIVO: Backup de
todos os blocos de dados com alterações desde o
ultimo backup de level 0.
 Backup incremental leve=1 DIFERENCIAL (default):
Backup de todos os blocos de dados com alterações
desde o ultimo backup de level 1 ou level 0.
190

Backups & Reports
 Backups incrementais, podem ser feitos tanto para todo
o banco de dados, quando para tablespaces
especificas ou por SCN (System Change Number):
191

Backups & Reports
Backups Incrementados:
 Backup de “image copy” uma vez executado e
consequentemente incrementado (recuperado) dentro
de intervalos regulares.
 1ª Vez: Um backup de “image copy” é criado.
 2ª Vez: Um backup incremental é criado.
 3ª Vez: O backup incremental outrora criado executa
um recover no backup de “image copy”.
 E assim sucessivamente...
192

Backups & Reports
Block Change Tracking:
 Para executar um backup incremental level 1, é preciso
ler todos os blocos não vazios do banco de dados e
verificar se houveram alterações deste o último backup.
 Esta tarefa consome tempo e recursos computacionais
do seu servidor de banco de dados, para resolver este
problema, implementa-se uma feature chamada “block
change tracking”.
 Os blocos que tiveram alterações têm seu endereço
físico registrados em um arquivo que faz um papel
similar a um índice, para facilitar a localização no
momento do backup.
193

Backups & Reports
Block Change Tracking:
 Para utilizar “block change tracking” com OMF.
 Habilitando “block change tracking”.
 Para utilizar “block change tracking” sem OMF.
 Para verificar se “block change tracking” está “on”.
 Para desabilitar “block change tracking”.
194

Backups & Reports
Validando banco de dados & Backups.
 Usualmente é recomendável que se faça uma
checagem no banco de dados, arquivos de
backup e controlfiles para verificar a integridade.
Para isso usa-se os comandos:
 VALIDADE
 BACKUP ... VALIDATE
 RESTORE ... VALIDATE
195

Backups & Reports
 Comando VALIDATE:
 Validando a integridade do banco de dados.
 Validando a integridade do controlfile.
 Validando a integridade dos archivelogs.
 Todas as verificações em um comando único.
196

Backups & Reports
 Comando VALIDATE:
 Outras variações do comando VALIDATE:
 Validação em um PDB.
197

Backups & Reports
 Comando BACKUP ... VALIDATE:
 Verificando a integridade do backup.
 Verificando a integridade física e logica do backup.
 Outras variações do comando BACKUP ... VALIDATE.
 Caso algum tipo de corrupção seja encontrado, será
registrado na view v$database_block_corruption.
198

Backups & Reports
 Comando RESTORE ... VALIDATE:
 Verificando se seus arquivos de backup, podem ser
utilizados com sucesso em um processo de restore de
seu banco de dados.
199

Backups & Reports
Catálogo de Recuperação.
 O que é?
 Repositório centralizador de meta-dados de seus backups,
onde se executa o gerenciamento de todas as atividades e
administrativas dos backups do seus ambiente.
 Uma instancia de banco de dados, dedicada para tal.
Preferencialmente instalada em um servidor também
dedicado para este fim.
 Vantagens:
 Maior período de retenção dos meta-dados dos backups,
gerenciamento centralizado, scripts individuais e
compartilhados, relatórios sumarizados com maior nível de
detalhes também podendo ser customizados.
200

Backups & Reports
 Configuração:
 Criar uma instancia de banco de dados, que vai lhe
consumir aproximadamente o seguinte:
 Uma tablespace dedicada para o usuário do catálogo.
201

Backups & Reports
 Configuração:
 Um usuário dedicado ao catálogo, com os devidos grants.
 Acesse o “rman” com o usuário criado e crie o catálogo.
202

Backups & Reports
 Configuração:
 Conecte-se via SQL*Plus com o usuário do catálogo e veja
as tabelas que foram criadas.
203

Backups & Reports
 Registrando targets:
 Conecte-se via “rman” na instancia “target” e no catálogo.
 Registre a instancia “target” no catálogo.
 A partir de então, os backups podem ser executados.
204

Backups & Reports
 Backup da instancia do catálogo.
 Deve ser feito somente como “target” (fora do catálogo).
 Também pode ser feito via Data Pump.
 Se você perder o catálogo, pode continuar fazendo
backup de seus bancos de dados “targets” normalmente.
 Re-sincronização do catálogo.
 Quando você fizer uma backup sem o catálogo.
 Estrutura física do banco de dados for alterada.
205

Backups & Reports
 Eliminando um catálogo:
 “Drop” o catálogo dentro do “rman”.
 “Drop” o usuário dentro do banco de dados.
206

Backups & Reports
Output de informações:
Dentro do “rman” é muito importante que você
acompanhe o que se passa, essas informações podem
ser acompanhadas a partir das seguintes fontes:
 Linux/Unix output files.
 Linux/Unix logging commands.
 RMAN SPOOL LOG command.
 View V$RMAN_OUTPUT
207

Backups & Reports
 Redirecionando para output files.
 Comando “tee”.
 Comando “script”.
208

Backups & Reports
 Comando “spool log”.
 Para não sobrescrever o arquivo, use “APPEND”.
 Comando “log”.
 V$RMAN_OUTPUT.
209

Backups & Reports
 Comando LIST:
 Listar na tela, informações completas de todos os backups.
 Listar na tela somente informações resumidas de backups.
 Listar na tela, informações de backups de image copy.
 Listar na tela, os backups por datafile.
210

Backups & Reports
 Comando LIST:
 Listar informações de archivelogs e backups image copy.
 Listar informações de todos backups de archivelogs.
211

Backups & Reports
 Comando REPORT:
 Relatório de backups obsoletos.
 Relatório de arquivos que precisam de backup.
 Relatório de arquivos que precisam de backup
considerando critérios de redundância.
212

Backups & Reports
 Comando REPORT:
 Relatório de arquivos que não tem backups, ou então
sofreram operações com a clausula NOLOGGIN. Para que
não gerem redo log.
213

Backups & Reports
Views de monitoramento:
214

Backups & Reports
Scripts de monitoramento:
 Backup piece por datafiles:
215

Backups & Reports
Scripts de monitoramento:
 Tempo de execução dos backups:
216

Resumo - Backups & Reports
 Neste Capítulo, discutimos os temas.
 Executando operações de backups
 Backup de pluggable Databases
 Backups incrementais
 Verificação de arquivos corrompidos
 RMAN Catalogo de recuperação
 Logs do RMAN
 Relatórios do RMAN
217

RMAN workshop 12c
Restore e
Recover

Conteúdo
 Determinando a necessidade do “Recover”.
 Determinando o que fazer o “Restore”
 RMAN para “start” “stop” da instancia.
 Recuperação completa
 “Restore” de archivelogs.
 “Restore” de controlfiles.
 “Restore” de SPFILEs.
 Recuperação incompleta.
 Flashback table
 Flashback database
 “Restore” e “Recover” em um novo servidor.
219

Restore & Recover
Determinando a necessidade do “recover”:
O termo “media recovery” significa recuperar algum
arquivo necessário para o funcionamento da instancia
e isso pode ser notado em algumas situações como:
 Start/Stop da instancia.
 Registros no “alert.log”.
 Diretamente para o usuário final.
220

Restore & Recover
 Recuperar um datafile, significa deixá-lo com o
mesmo SCN (System Change Number) que os
demais datafiles e o controlfile, aplicando os
registros dor archivelogs.
 O inverso também é verdadeiro, ou seja, se você
perder um controlfile, pode ser necessário, atualizar
o SCN do controlfile com o SCN dos datafiles.
 Isso pode e deve ser feito via RMAN.
221

Restore & Recover
222
Este select pode ser útil para determinar
quais arquivos (datafiles / controlfiles) pre-
cisam de recover. Basta observar a coluna
chamada DATA_FILE_STATUS, Quem estiver
Diferente de “Startup Normal”, necessita de
passar um processo de “recover”

Restore & Recover
 Pode-se usar também a view v$datafile_header.
 As colunas “error” e “recover” indicam se há algum
problema com seus datafiles.
223

Restore & Recover
Determinando a necessidade do “restore”:
O comando “restore” do RMAN é utilizado para
reconstruir um datafile/controlfile, você pode
necessitar desta característica quando:
 Houver problemas de hardware.
 Um arquivo (datafile/controlfile) for removido.
 Um arquivo (datafile/controlfile) estiver corrompido.
 Quando houver algum tipo de “crash” na instancia.
224

Restore & Recover
Determinando a necessidade do “restore”:
Para reconstruir um arquivo, seja ele datafile ou
controlfile, basicamente é preciso antes de qualquer
coisa, que seu banco de dados atenda alguns pré-
requisitos como:
 Instancia no modo “archivelog”.
 Possuir um backup integro.
 Possuir todos os archivelogs desde o último backup.
225

Restore & Recover
Recuperando-se da perda de um arquivo:
Para recuperar a instancia, você basicamente precisa
seguir os passos:
 Determine qual arquivo precisa ser restaurado.
 Coloque a instancia no modo correto para tal
(nomount, mount ou open).
 Use o comando “RESTORE” para reconstruir o arquivo.
 Use o comando “RECOVER” para atualizar o arquivo.
 Abra o seu banco de dados novamente.
226

Restore & Recover
Data Recovery Advisor:
Introduzida no Oracle 11g, é uma ferramenta auxiliar
na administração da instancia (atua dentro do
RMAN), permite de maneira proativa executar
atividades como:
 Listar possíveis falhas.
 Sugerir opções de correções.
 Executar os comandos para correção.
 Alterar o “status” das falhas.
227

Restore & Recover
 Listando falhas:
 Ou então:
228

Restore & Recover
 Capturando sugestões de correção (Advise Failure):
229

Restore & Recover
 Capturando sugestões de correção (Advise Failure):
 Com o comando “advise failure”, o DRA gera um script
de correção para a falha outrora encontrada.
 O caminho do script é informado na tela, é um arquivo
com a extensão “.hm”, pode ser aberto por qualquer
editor de texto.
230

Restore & Recover
 Executando as correções (Repair Failure):
 Você pode ver o que um script de “repair” vai fazer,
sem executá-lo:
 Ou executar o script diretamente, você será
perguntado se realmente deseja prosseguir, ao
confirmar o script entra em execução.
231

Restore & Recover
 Alterando o nível das falhas (Change Failure):
 As falhas encontradas pelo DRA, podem ter níveis:
LOW, HIGH e CRITICAL.
 Você pode altera-las com o comando “change failure”,
exceto as falhas classificadas como CRITICAL.
232

Restore & Recover
RMAN para “start” “stop” da instancia.
 Com o RMAN, você pode executar operações de
“startup”, “shutdown” e “alter database” dentro da
sua instancia assim como se faz no SQL*Plus:
233

Restore & Recover
Recuperação completa da instancia:
Recuperação completa: significa recuperar sua
instancia até o ultimo “commit” executado antes do
momento da falha. Mas não quer dizer recuperar o
banco de dados inteiro. Esse cenário pode ocorrer
também caso você perca apenas um datafile, por
exemplo.
234

Restore & Recover
Para executar uma recuperação completa, a instancia
deve possuir alguns pré-requisitos, antes do momento
da falha:
 Instancia em modo archivelog.
 Um backup integro.
 Todos os archivelogs desde o ultimo backup.
 Todos os arquivos de redo log.
 Backups incrementais (se necessário).
235

Restore & Recover
Validando a integridade dos backups:
Para validar a integridade de seus backups, você
pode executar o comando de “restore” seguido da
palavra “preview”.
 Este comando não recupera nem restaura nada,
apenas checa se os arquivos necessários para tal estão
íntegros e presente.
 As informações podem ser exibidas de maneira
completa ou sumarizada.
236

Restore & Recover
 Exemplo de restore database “preview”.
 Exemplo de restore database “preview” sumarizado.
237

Restore & Recover
 Verificando a integridade do cabeçalho dos arquivos:
 Verificando a integridade física e logica:
 Outros exemplos de validações:
238

Restore & Recover
Da mesmo maneira que validamos as opções de
“restore”, também é possível validar as opções de
“recover”.
 Testando o “recover” de uma tablespace:
 Caso haja algum problema, o Oracle lança um erro:
239

Restore & Recover
 Em caso de sucesso no processo de teste de restore,
uma mensagem similar será exibida na tela:
 Outros exemplos de testes de recover:
240

Restore & Recover
Restaurando o banco de dados inteiro: Todos os
datafiles serão restaurados, exceto aqueles que não
foram danificados, porém você pode ingnorar essa
situação com a palavra “FORCE”, caso queira, neste
cenário você vai precisar de:
 Um backup FULL, ou incremental level 0 e/ou level 1.
 Todos archivelogs desde o ultimo backup.
 Todos os arquivos de redo log (current e unarchived).
241

Restore & Recover
 Restaurando o banco de dados inteiro, preservando os
controlfiles:
 Restaurando toda a instancia, inclusive o controlfile:
242

Restore & Recover
Restaurando tablespaces: é possível restaurar somente
uma tablespace, caso se preciso, isso pode ser feito com o
banco no modo “open” e no modo “mount” dependendo
da tablespace:
 Restaurando uma tablespace com a instancia “open”:
OBS: Na versão 12c, pode se retirar a palavra chave “sql”
243

Restore & Recover
 Restaurando tablespaces SYSTEM e UNDO:
 Se o processo ocorrer com sucesso, a seguinte
mensagem será exibida:
 Tablespaces “read-only” não é necessário executar o
processo de “recover”, basta somente o “restore”.
244

Restore & Recover
Restaurando tablespaces temporárias: Para restaurar
tablespaces temporárias, você pode executar:
 “shutdown” e “startup” da instancia, a tablespace será
recriada automaticamente.
 Alterar a tablespace, recriando o tempfile.
 Recriar a tablespace por completo.
245

Restore & Recover
Restore e recover de datafiles: Você pode restaurar e
recuperar um datafile somente caso só o mesmo
esteja danificado:
 Restore de datafile com referencia numérica:
 Restore de datafile com referencia pelo caminho:
246

Restore & Recover
Restore e recover de datafiles: Para as tablespaces
SYSTEM e UNDO a instancia deve estar em “mount”:
 Restore de datafile com referencia numérica:
 Restore de datafile com referencia pelo caminho:
247

Restore & Recover
Restore de datafiles para localização não default:
 SET NEW NAME e SWITCH
248

Restore & Recover
Restore de blocos corrompidos: Blocos de dados
corrompidos, sempre serão registrados na view
v$database_block_corruption:
 Recuperar você pode fazer:
 Ou recuperar um bloco especifico:
249

Restore & Recover
Na versão 12c, é possível ter um contai-
ner database, onde dentro deste contai-
ner temos os plugglable databases, sendo assim:
 Você pode perder todos os datafiles
(container/pluggable) databases.
 Você pode perder somente os datafiles do container.
 Você pode perder somente os datafiles de um
pluggable database.
250

Restore & Recover
 Conectado com SYSDBA ou SYSBACKUP,
você pode recuperar tudo, tanto CDB
como PDB.
 Na sequencia, abra todos os seus PDBs:
251

Restore & Recover
 Recuperação dos datafiles do CDB:
 Na sequencia, abra todos os PDBs:
 Repare que o procedimento é basicamente o mesmo,
bastando adicionar a palavra chave “root”.
 Você pode consultar o status dos PDBs na view “v$pdbs”.
252

Restore & Recover
Recuperação de PDBs:
 Conectado no CBD:
 Conectado diretamente no PDB:
253

Restore & Recover
Restaurando archivelogs:
Quando executa-se “BACKUP ... PLUS ARCHIVELOG”,
seus archivelogs estão incluídos no backup corrente.
Sendo assim, na hora do recover, estes archives são
restaurados automaticamente, mas você pode
também restaurá-los manualmente, normalmente
quando:
 Antecipa-se o processo de restore dos archives.
 Precisa-se restaurar os archives em outro local.
 Precisa-se de um archivelog especifico (LogMiner).
254

Restore & Recover
Por padrão, o restore acontece na FRA, ou no local
definido no parâmetro LOG_ARCHIVE_DEST_N. Você
pode pegar informações adicionais nas views
V$LOG_HISTORY e V$ARCHIVED_LOG.
 Para informações adicionais, na v$log_history:
 Restaurando um archivelog em especifico:
 Restaurando todos os archivelogs:
255

Restore & Recover
 Restaurando um range de archivelogs:
 Sobrescrevendo um archivelog que está no disco.
 Restaurando archivelogs para uma localização não
default:
256

Restore & Recover
Restaurando controlfiles:
Quando sua instancia perde um controlfile, na hora
ela para de funcionar. Se você tiver uma cópia
integra pode restaurá-la via SO, mas caso não tenha,
você pode recuperar a partir de:
 Um catálogo de recuperação.
 Um backup automático do controlfile.
 Um backup especifico de seu controlfile.
257

Restore & Recover
Usando o catálogo de recuperação:
 Mesmo com a instancia “target” em modo “nomount”,
você pode listar informações a respeito do backup de
seus controlfiles:
 Para restaurar o backup de um controlfile:
258

Restore & Recover
Usando o auto backup e backup file name:
 A instancia deve estar no modo “nomount”.
 Restore a partir de um backup especifico:
 Ao termino dessas operações a mensagem abaixo será
exibida:
259

Restore & Recover
Restaurando o SPFILE:
Sempre que se faz um backup do controlfile, um
backup do SPFILE é executado junto, para restaurar o
procedimento também e muito similar:
 Restore do SPFILE com o catálogo de recuperação:
 Restore para um diretório não default:
260

Restore & Recover
Recuperação incompleta da instancia:
Opostamente a recuperação completa, a
recuperação incompleta, não volta sua instancia até o
ultimo “commit” recebido, mas sim até um ponto que
você determinar e esse ponto pode ser:
 Uma expressão de data/hora.
 SCN (System Change Number).
 Sequence de archivelog.
 Restore point.
261

Restore & Recover
Para executar uma recuperação incompleta de sua
instancia, basicamente você precise de:
 Um bacukp full ou level 0;
 Backups incrementais level 1 (se necessário);
 Backups de “image copy” (se for o caso);
 Archivelogs necessários para o processo de recover;
 Colocar a instancia no modo “mount”
262

Restore & Recover
 Recuperação incompleta, baseada em uma expressão
de data/hora:
 Ao termino da execução, a mensagem abaixo deve ser
exibida:
263

Restore & Recover
 Recuperação incompleta, em uma sequence de
archivelog:
 Caso não exista alguma sequence de archivelog
necessária para esse processo de recover, um erro
pode ser exibido:
264

Restore & Recover
 Recuperação incompleta, baseada em SCN:
 Você pode capturar o SCN nas seguintes fontes:
 Alert.log
 Coluna FISRT_CHANGE# na view V$LOG_HISTORY
 Arquivos de trace
 LogMiner
265

Restore & Recover
Recuperação incompleta, baseada restore point:
 Um restore point, nada mais é do que traduzir um SCN
para um “aliás” informado pelo usuário.
 Você pode consulta-los na view “v$restore_point”.
 Recuperação baseada em restore point.
266

Restore & Recover
Recuperação incompleta de tabela:
O comando RECOVER TABLE, restaura e
recupera uma tabela para determinado
período do passado. Essa tarefa é feita por uma
instancia auxiliar juntamente com o Data Pump, para
isso é preciso dois diretórios temporários para:
 Instancia auxiliar  auxiliary destination
 Data Pump  datapump destination
267

Restore & Recover
Recuperação incompleta de tabela:
 Criando os diretórios temporários:
 Recuperando a tabela INV do usuário MV_MAINT:
268

Restore & Recover
Tecnologia de Flashback:
Tecnologias de flashback, possibilitam voltar a
tabela, para determinado período no tempo, para
recuperar-se de eventuais acidentes como um “drop”
acindental, um “update” sem a clausula “where” e etc.
 Para recuperar tabelas há os seguintes flashbacks:
 Flashback DROP
 Flashback TABLE
 Flashback DATABASE
269

Restore & Recover
Flashback table (DROP):
 Quando uma tabela for dropada, agora você pode
recupera-la. Essa feature depende do parâmetro
“recyclebin” do SPFILE que deve estar como “ON”.
 Quando há um “drop” a tabela renomada e não
excluída.
270

Restore & Recover
 Para consultar a lixeira, use o select:
 Para recuperar uma tabela:
271

Restore & Recover
 Índices retornam com o nome que estava na lixeira:
 Porém é possível renomea-los:
 Também é possível, recuperar a tabela e renomear no
mesmo comando:
272

Restore & Recover
Flashback table (Para o passado):
É possível recuperar uma tabela para determinado
período do passado, para isso usa-se o “flashback
table” onde você pode voltar uma tabela baseado
em:
 Um SCN.
 Uma expressão de data e hora.
 Um restore point.
273

Restore & Recover
Para fazer um “flashback table”, é preciso utilizar os
segmentos da tablespace de UNDO. Logo, só é
possível fazer flashback dentro do valor estabelecido
no parâmetro UNDO_RETENTION, ou então um erro
será exibido:
O período possível de fazer um “flashback table”,
pode ser estendido se você usar a tecnologia de
“flashback data archive”.
274

Restore & Recover
Flashback table baseado em um SCN:
 Capturando o SCN atual:
 Executando o flashback table:
 Na primeira vez que uma tabela sofrer um flashback, é
preciso antes executar o comando “enable row movement”.
275

Restore & Recover
Flashback table baseado em uma expressão de
tempo:
 Exemplo 1:
 Exemplo 2:
276

Restore & Recover
Flashback table baseado em um “restore point”:
 Criando o “restore point”:
 Executando o flashback:
277

Restore & Recover
Flashback Database:
O mais abrangente dos “flashbacks”, que possibilita
voltar o banco de dados inteiro para o passado,
porém não vem habilitado por default, e possui
alguns pré-requisitos como:
 A instancia deve estar no modo “archivelog”
 É preciso estar usando a FRA (Fast Recovery Area)
 O flashback database deve estar habilitado.
278

Restore & Recover
Flashback Database (Preparação):
 Verifique se a instancia está no modo “archive” e se
possui a FRA (Fast Recovery Area) habilitada.
 Habilite a feature “flashback database”.
 Veja se o flashback database está habilitado
juntamente com seus logs de flashback:
279

Restore & Recover
Flashback Database (Execução):
 Verificando até que ponto pode se voltar a instancia:
 Assim como o “flashback table”, o “flashback database”
pode ser feito a partir de:
 SCN
 Timestamp
 Restore Point
 Expressão de data e hora
280

Restore & Recover
Flashback Database (Execução):
Executando um flashback database:
 Criando um restore point:
 Executando o flashback database:
Após a execução do “flashback database”, a instancia
deve ser aberta no modo “open resetlogs”.
281

Restore & Recover
Restore & recover em outro servidor:
Em caso de perda total de seu servidor, ou processos
de testes de restore ou até mesmo atualização,
migração de ambientes, pode-se restaurar e
recuperar um backup diretamente em outro servidor
diferente do original, para isso você precisa:
 Um backup level 0 ou full.
 Um backup do controlfile/SPFILE.
 Backup dos archivelogs necessários.
282

Restore & Recover
 Execute um backup no servidor de “origem”.
 Verifique os arquivos que foram gerados.
 Transfira o backup para o servidor de destino.
283

Restore & Recover
 Acerte as variáveis de ambiente:
 Crie um “pfile” customizado com as informações
mínimas necessárias para inicializar a instancia:
284

Restore & Recover
 Crie diretórios para datafiles, redo log e archivelogs.
 Inicie a instancia no modo “nomount”, restaure o
backup do controlfile:
285

Restore & Recover
 Coloque a instancia no modo “mount”:
 Faça um “crosscheck” dos arquivos de backup:
 Catalogue os arquivos de backup:
286

Restore & Recover
 Para verificar se está tudo certo, execute o comando
“list backup” e na sequencia um “restore database”:
 Caso o caminho onde os datafiles serão restaurados
não seja o mesmo, deve-se usar o comando “set new
name”. Um script pode ser gerado para fazer isso
dinamicamente:
287

Restore & Recover
288

Restore & Recover
 A execução do script, gera um outro script com o
caminho dos datafiles originais, basta agora fazer um
replace acertando o caminho:
289
Caminho original
Caminho corrigido

Restore & Recover
 Conecte-se no “rman” e execute o script:
 Ao término execute um “report schema”:
290

Restore & Recover
 Agora que o processo de “restore” foi completado,
execute o “recover database”:
 Um erro pode ocorrer, é normal, pois a instancia vai
procurar por mais “archivelogs” para continuar
executando o “recover”, porém esses “archivelogs” não
existem, pois não foram gerados.
291

Restore & Recover
 Para saber até que momento, sua instancia foi
recuperada, execute o select:
 Arquivos de redo log, não fazem parte do backup, por
tanto eles ainda não existem, sendo assim devemos
cria-los, para isso use o script:
292

Restore & Recover
 Assim como no caso dos datafiles, este script precisa
ser ajustado, para que funcione de maneira correta:
293
Caminho corrigido
Caminho original

Restore & Recover
 Execute o script gerado para renomear os arquivos de
redo log:
 Para confirmar, execute um select na “v$logfile”.
294

Restore & Recover
 Abra a instancia com a opção “open resetlogs”.
 Recrie a tablespace temporária.
295

Restore & Recover
Renomeando a instancia:
 Faça um backup do controlfile:
 Dê um shutdown na instancia:
 Renomeie o valor da propriedade “SET DATABASE”
para o novo nome da instancia:
296

Restore & Recover
 Acerte o nome do “init.ora”, de acordo com o nome da
instancia:
 Acerte o valor do parâmetro “db_name” e a variável
de ambiente $ORACLE_HOME
297

Restore & Recover
 Inicie a instancia no modo “nomount”.
 Execute o script que renomeia a instancia:
 Abra a instancia com “open resetlogs”
 Acerte a tablespace temporária:
298

Resumo - Restore & Recover
 Determinando a necessidade do “Recover”.
 Determinando o que fazer o “Restore”
 RMAN para “start” “stop” da instancia.
 Recuperação completa
 “Restore” de archivelogs.
 “Restore” de controlfiles.
 “Restore” de SPFILEs.
 Recuperação incompleta.
 Flashback table
 Flashback database
 “Restore” e “Recover” em um novo servidor.
299

RMAN workshop 12c
Arquivos de
Redo log

Conteúdo
 Determinando o curso da ação.
 Restore de um membro único.
 Restore de todos membros de um grupo inativo.
 Dropando um grupo de redo log.
 Adicionando um grupo de redo log.
 Restore de todos membros de um grupo ativo.
 Restore de todos membros de um grupo corrente.
301

Arquivos de Redo log
302
Membro A
Membro B
Membro A
Membro B
Membro A
Membro B
Membro A
Membro B
Grupo A Grupo B Grupo C Grupo D
Log Buffer
LG
WR
/Disk2
/Disk1
Inser into....
Update emp set ...
Delete from emp ....

Quando houver problemas nos seus arquivos de redo
log, você deve saiba que:
 No alert.log você pode saber onde e quando foi a
falha.
 V$LOG e V$LOGFILE você pode saber em qual
grupo/membro.
 Se houver um membro sobrevivente, você pode
restaurar o membro danificado a partir dele.
303

304
Tipo de falha Status na V$LOG Ação
Um membro perdido Não há Drop/Recrie o membro
Um grupo inteiro INACTIVE “Clear logfile” ou
Drop e recrie o membro
Um grupo inteiro ACTIVE Tente executar um “check
point,” se der certo “clear
logfile”, caso contrário
execute um “PIT”
Um grupo inteiro CURRENT Tente um “clear logfile”
caso não de certo,
execute um “PIT”.

305
Dentro do alert.log, quando houver problemas com os
arquivos de redo log, uma mensagem similar a essa
será exibida:
Pode-se também consultar as views v$log e v$logfile:

306
Grupos Status Arquivos Tamanho MB

307
 Views de troubleshooting:
View Descrição
V$LOG Informações sobre os “grupos” de arquivos de redo log.
V$LOG_FILE Informações sobre os “membros” dos redo logs
V$LOG_HISTORY Histórico de informações a respeito dos “grupo” de redo log.

308
 Coluna “STATUS” da view V$LOG.
Status Descrição
CURRENT Grupo de redo log que atualmente está sendo usado pelo
processo de log writer (LGWR)
ACTIVE Grupo necessário em caso de recover ou ainda não arquivado
CLEARING Grupo que está sendo limpo pelo comando “clear logfile”
CLEARING_CURRENT Grupo corrente que está sendo limpo pelo comando “clear
logfile”
INACTIVE Grupo que já foi arquivado e/ou não é necessário para o
“recover”
UNUSED Grupo que nunca foi utilizado, até então pelo processo de “log
writer”

309
 Coluna “STATUS” da view V$LOGFILE.
Status Descrição
INVALID Arquivo está inacessível ou foi recentemente limpo (“clear logfile”)
DELETED Arquivo que não está mais em uso
STALE Arquivo ainda não está 100% complete (ainda sendo escrito)
NULL Arquivo está em uso pelo banco de dados

310
Restore de um membro único:
Em sua rotina de trabalho, ao analisar o alert.log
você se depara com a seguinte mensagem:
Para resolver esse erro siga:
 Identifique a falha no alert.log
 Garanta que o arquivo não é parte de um grupo
corrente.
 Drope o arquivo danificado.
 Recrie o arquivo novamente.

311
 Conteúdo do alert.log:
 Verifique na v$log o status do grupo 2:

312
 Resultado do select na v$log:
 Exclua o arquivo danificado:
 Crie novamente o arquivo, outrora danificado:

313
Restore de todos membros de um grupo inativo:
Caso sua instancia de banco de dados perca todo um
grupo de redo log, siga este caminho:
 Identifique os membros do grupo danificado no
alert.log
 Verifique se o status do grupo é INACTIVE
 Recrie o grupo inteiro com o comando “clear logfile”
 Se o grupo danificado não havia sido arquivado,
imediatamente execute um backup

314
 Identifique os arquivos no alert.log:
 Coloque a instancia no modo “mount”:
 Verifique o status do grupo na v$log:

315
 Se o grupo estiver como INACTIVE, limpe o com o
comando “clear logfile”:
 Caso o grupo de redo log não tenha sido arquivado,
use “clear unarchived log file” (E na sequencia faça um
backup de seu banco de dados):

316
Dropando um grupo de redo log:
Em algumas situações pode ser preciso explicitamente
excluir um grupo de redo log, para isso siga as
etapas:
 Identifique o grupo na view v$log:
 Execute o comando para o “drop”:
 Caso um erro ORA-01623 apareça, execute:

317
Adicionando um grupo de redo log:
Você pode adicionar mais grupos de redo log.
 Você pode especificar o grupo e o tamanho dos
arquivos:
 Caso os arquivos já existam use a palavra chave
“REUSE”:

RMAN Workshop 12c Overview

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a RMAN Workshop 12c Overview

Semelhante a RMAN Workshop 12c Overview (20)

RMAN Workshop 12c Overview