Material do treinamento "Treinamento RMAN Workshop 12c" promovido pela Oradata, neste treinamento, abordamos as mais variadas maneiras de se executar as operações de backup/restore/recover do banco de dados Oracle, desde as versões mais antigas onde tudo era manual, até as técnicas utilizadas nos dias atuais com o RMAN.
2. 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
3. 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
4. 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
6. Conteúdo
Variáveis de ambiente
Conexão com o Banco de Dados
Startup / Shutdown do Banco de Dados
6
7. 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
8. Definição das Variáveis
Digitadas manualmente no prompt
Definidas estáticamente no .bash_profile
8
9. 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
11. . 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.
12. 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. Conexão com o Banco de Dados
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. Conexão com o Banco de Dados
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. Conexão com o Banco de Dados
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. Conexão com o Banco de Dados
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. Conexão com o Banco de Dados
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. Conexão com o Banco de Dados
18
Métodos de conexão
Easy Connect:
Local Name:
$ sqlplus user/pass@tnsnames
19. 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
20. Startup / Shutdown
20
Comando startup:
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.
21. Startup / Shutdown
21
Comando startup:
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
22. 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
23. Startup / Shutdown
23
Comando shutdown:
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!!!
24. Startup / Shutdown
24
Comando shutdown:
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.
25. 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
27. Conteúdo
Gerenciamento de Control Files
Gerenciamento de Redo Logs
Implementando ARCHIVELOG
Gerenciamento de Tablespaces e Data Files
27
28. 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
30. Gerenciamento Control Files
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
31. Gerenciamento Control Files
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)
33. Gerenciamento Control Files
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
34. Gerenciamento Control Files
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
35. Gerenciamento Control Files
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
36. Gerenciamento Control Files
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
37. Gerenciamento Control Files
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
38. Gerenciamento Control Files
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
39. 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
40. Gerenciamento Redo logs
É composto por grupos e membros, sendo necessário ter ao
mínimo 2 grupos e pelo menos um membro cada.
40
41. Gerenciamento Redo logs
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
42. Gerenciamento Redo logs
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
44. Gerenciamento Redo logs
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
45. Gerenciamento Redo logs
Verificando os “switchs” de log.
Adicionando novos grupos de redo logs.
45
46. Gerenciamento Redo logs
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
47. Gerenciamento Redo logs
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
48. Gerenciamento Redo logs
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
49. Gerenciamento Redo logs
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
50. Gerenciamento Redo logs
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
51. Gerenciamento Redo logs
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
52. Gerenciamento Redo logs
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
53. Implementando Archivelog
53
O que é archivelog?
Continuação dos arquivos de redo log.
Responsável por fazer o recover.
54. Implementando Archivelog
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. Implementando Archivelog
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. Implementando Archivelog
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. Implementando Archivelog
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. Implementando Archivelog
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. Implementando Archivelog
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. Implementando Archivelog
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”
61. 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. Tablespaces & Datafiles
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. Tablespaces & Datafiles
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. Tablespaces & Datafiles
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. Tablespaces & Datafiles
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. Tablespaces & Datafiles
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. Tablespaces & Datafiles
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. Tablespaces & Datafiles
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:
70. Tablespaces & Datafiles
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. Tablespaces & Datafiles
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.
73. Tablespaces & Datafiles
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. Tablespaces & Datafiles
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. Tablespaces & Datafiles
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. Tablespaces & Datafiles
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. Tablespaces & Datafiles
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. Tablespaces & Datafiles
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. Tablespaces & Datafiles
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. Tablespaces & Datafiles
80
Movendo e renomeando datafiles (controlfile).
Abra o arquivo /tmp/mv.sql, altere o caminho dos datafiles
81. Tablespaces & Datafiles
81
Movendo e renomeando datafiles (controlfile).
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.
82. 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
85. 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
86. 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
87. Cold-Backup NOARCHIVELOG
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
88. Cold-Backup NOARCHIVELOG
Como fazer (Backup)?
Identifique o nome e a localização dos arquivos que
precisarão fazer parte do seu backup:
Datafiles, controlfiles, tempfiles e logfiles
88
89. Cold-Backup NOARCHIVELOG
Como fazer (Backup)?
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
90. Cold-Backup NOARCHIVELOG
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
91. Cold-Backup NOARCHIVELOG
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
92. Cold-Backup NOARCHIVELOG
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
93. Cold-Backup NOARCHIVELOG
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
95. Cold-Backup NOARCHIVELOG
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
97. 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
98. Hot Backup (archivelog)
Hot Backup in archivelog (algorítmo)
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
99. Hot Backup (archivelog)
Hot Backup in archivelog (algorítmo)
É 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
100. Hot Backup (archivelog)
Hot Backup in archivelog (algorítmo)
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
101. Hot Backup (archivelog)
Hot Backup in archivelog (algorítmo)
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
102. Hot Backup (archivelog)
Hot Backup in archivelog (algorítmo)
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
103. Hot Backup (archivelog)
Hot Backup in archivelog (algorítmo)
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
104. Hot Backup (archivelog)
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
106. Hot Backup (archivelog)
Script Hot Backup (exemplo):
O script do slide anterior, gera um script (hotback.sql)
que será o seu script de backup, vide exemplo.
106
107. Hot Backup (archivelog)
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
108. Hot Backup (archivelog)
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
109. 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
110. Recuperação Completa
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
111. Recuperação Completa
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
112. Recuperação Completa
Recuperação completa com a instancia offline:
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
113. Recuperação Completa
Recuperação completa com a instancia offline:
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
114. Recuperação Completa
Recuperação completa com a instancia offline:
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
115. Recuperação Completa
Recuperação completa com a instancia offline:
Verificando o SCN no datafile.
Verificando o SCN no controlfile.
115
116. Recuperação Completa
Recuperação completa com a instancia offline:
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
117. Recuperação Completa
Recuperação completa com a instancia offline:
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
118. Recuperação Completa
Recuperação completa com a instancia offline:
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
119. Recuperação Completa
Recuperação completa com a instancia offline:
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
120. Recuperação Completa
Recuperação completa com a instancia offline:
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
121. Recuperação Completa
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
122. 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
123. Restore de Controlfiles
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
124. Restore de Controlfiles
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
125. Restore de Controlfiles
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
126. Restore de Controlfiles
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
127. Restore de Controlfiles
Restore a partir de um backup (Exemplo).
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
128. Restore de Controlfiles
Restore a partir de um backup (Exemplo).
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
129. Restore de Controlfiles
Restore a partir de um backup (Exemplo).
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
130. Restore de Controlfiles
Restore a partir de um backup (Exemplo).
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
131. Restore de Controlfiles
Restore a partir de um backup (Exemplo).
Terminado o recover, abra a instancia com a opção
“OPEN RESETLOGS”.
131
132. 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
133. Recuperação Incompleta
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
134. Recuperação Incompleta
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
135. Recuperação Incompleta
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
136. Recuperação Incompleta
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
137. Recuperação Incompleta
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
140. 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
141. 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
143. 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
144. 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
145. 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
146. 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
147. 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
148. 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
149. 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
150. Configurações
Localização dos backups.
Localização default.
FRA.
Comando “BACKUP.... FORMAT”.
Exemplo de arquivo de backup:
150
151. 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
152. 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
153. 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
154. 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
156. 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
157. 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
158. 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
159. 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
160. 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
161. 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
162. 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
163. 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
164. 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
165. Resumo – RMAN Configurações
Neste capítulo discutimos os temas:
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
167. 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
168. Backups & Reports
Com o RMAN é possível fazer backup dos seguintes
componentes de seu banco de dados:
Datafiles
Controlfiles
Archivelogs
SPFILES
Backup Pieces
168
169. 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
170. 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
171. Backups & Reports
Backupsets x Image Copy
171
Produção
Backup
100GB 100GB
Backup
Image Copy
Produção
Backup
100GB
30GBBackup
Backupset
173. 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
174. 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
175. 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
176. 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
177. 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
178. 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
179. Backups & Reports
Opções Adicionais de Backup:
Backup de tablespaces que “ainda” não tem backup.
Excluindo tablespaces READ ONLY.
179
180. 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
181. 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
182. 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
183. 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
184. Backups & Reports
Backups Pluggable & Container Databases:
Para descobrir onde está conectado:
Conectado no “root container”, para fazer um backup
de “todo” o ambiente (incluindo PDBs):
184
185. Backups & Reports
Backups Pluggable & Container Databases:
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
186. Backups & Reports
Backups Pluggable & Container Databases:
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
188. 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
189. Backups & Reports
Backups Incrementais:
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
190. Backups & Reports
Backups Incrementais:
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
191. Backups & Reports
Backups Incrementais:
Backups incrementais, podem ser feitos tanto para todo
o banco de dados, quando para tablespaces
especificas ou por SCN (System Change Number):
191
192. 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
193. 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
194. 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
195. 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
196. Backups & Reports
Validando banco de dados & Backups.
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
197. Backups & Reports
Validando banco de dados & Backups.
Comando VALIDATE:
Outras variações do comando VALIDATE:
Validação em um PDB.
197
198. Backups & Reports
Validando banco de dados & Backups.
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
199. Backups & Reports
Validando banco de dados & Backups.
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
200. 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
201. Backups & Reports
Catálogo de Recuperação.
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
202. Backups & Reports
Catálogo de Recuperação.
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
203. Backups & Reports
Catálogo de Recuperação.
Configuração:
Conecte-se via SQL*Plus com o usuário do catálogo e veja
as tabelas que foram criadas.
203
204. Backups & Reports
Catálogo de Recuperação.
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
205. Backups & Reports
Catálogo de Recuperação.
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
206. Backups & Reports
Catálogo de Recuperação.
Eliminando um catálogo:
“Drop” o catálogo dentro do “rman”.
“Drop” o usuário dentro do banco de dados.
206
207. 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
208. Backups & Reports
Output de informações:
Redirecionando para output files.
Comando “tee”.
Comando “script”.
208
209. Backups & Reports
Output de informações:
Comando “spool log”.
Para não sobrescrever o arquivo, use “APPEND”.
Comando “log”.
V$RMAN_OUTPUT.
209
210. Backups & Reports
Output de informações:
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
211. Backups & Reports
Output de informações:
Comando LIST:
Listar informações de archivelogs e backups image copy.
Listar informações de todos backups de archivelogs.
211
212. Backups & Reports
Output de informações:
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
213. Backups & Reports
Output de informações:
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
219. 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
220. 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
221. Restore & Recover
Determinando a necessidade do “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
222. Restore & Recover
Determinando a necessidade do “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”
223. Restore & Recover
Determinando a necessidade do “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
224. 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
225. 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
226. 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
227. 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
229. Restore & Recover
Data Recovery Advisor:
Capturando sugestões de correção (Advise Failure):
229
230. Restore & Recover
Data Recovery Advisor:
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
231. Restore & Recover
Data Recovery Advisor:
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
232. Restore & Recover
Data Recovery Advisor:
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
233. 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
234. 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
235. Restore & Recover
Recuperação completa da instancia:
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
236. Restore & Recover
Recuperação completa da instancia:
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
237. Restore & Recover
Recuperação completa da instancia:
Validando a integridade dos backups:
Exemplo de restore database “preview”.
Exemplo de restore database “preview” sumarizado.
237
238. Restore & Recover
Recuperação completa da instancia:
Validando a integridade dos backups:
Verificando a integridade do cabeçalho dos arquivos:
Verificando a integridade física e logica:
Outros exemplos de validações:
238
239. Restore & Recover
Recuperação completa da instancia:
Validando a integridade dos backups:
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
240. Restore & Recover
Recuperação completa da instancia:
Validando a integridade dos backups:
Em caso de sucesso no processo de teste de restore,
uma mensagem similar será exibida na tela:
Outros exemplos de testes de recover:
240
241. Restore & Recover
Recuperação completa da instancia:
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
242. Restore & Recover
Recuperação completa da instancia:
Restaurando o banco de dados inteiro, preservando os
controlfiles:
Restaurando toda a instancia, inclusive o controlfile:
242
243. Restore & Recover
Recuperação completa da instancia:
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
244. Restore & Recover
Recuperação completa da instancia:
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
245. Restore & Recover
Recuperação completa da instancia:
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
246. Restore & Recover
Recuperação completa da instancia:
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
247. Restore & Recover
Recuperação completa da instancia:
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
248. Restore & Recover
Recuperação completa da instancia:
Restore de datafiles para localização não default:
SET NEW NAME e SWITCH
248
249. Restore & Recover
Recuperação completa da instancia:
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
250. Restore & Recover
Recuperação completa da instancia:
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
251. Restore & Recover
Recuperação completa da instancia:
Conectado com SYSDBA ou SYSBACKUP,
você pode recuperar tudo, tanto CDB
como PDB.
Na sequencia, abra todos os seus PDBs:
251
252. Restore & Recover
Recuperação completa da instancia:
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
253. Restore & Recover
Recuperação completa da instancia:
Recuperação de PDBs:
Conectado no CBD:
Conectado diretamente no PDB:
253
254. 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
255. Restore & Recover
Restaurando archivelogs:
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
256. Restore & Recover
Restaurando archivelogs:
Restaurando um range de archivelogs:
Sobrescrevendo um archivelog que está no disco.
Restaurando archivelogs para uma localização não
default:
256
257. 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
258. Restore & Recover
Restaurando controlfiles:
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
259. Restore & Recover
Restaurando controlfiles:
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
260. 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
261. 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
262. Restore & Recover
Recuperação incompleta da instancia:
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
263. Restore & Recover
Recuperação incompleta da instancia:
Recuperação incompleta, baseada em uma expressão
de data/hora:
Ao termino da execução, a mensagem abaixo deve ser
exibida:
263
264. Restore & Recover
Recuperação incompleta da instancia:
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
265. Restore & Recover
Recuperação incompleta da instancia:
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
266. Restore & Recover
Recuperação incompleta da instancia:
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
267. 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
268. Restore & Recover
Recuperação incompleta de tabela:
Criando os diretórios temporários:
Recuperando a tabela INV do usuário MV_MAINT:
268
269. 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
270. 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
271. Restore & Recover
Flashback table (DROP):
Para consultar a lixeira, use o select:
Para recuperar uma tabela:
271
272. Restore & Recover
Flashback table (DROP):
Í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
273. 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
274. Restore & Recover
Flashback table (Para o passado):
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
275. Restore & Recover
Flashback table (Para o passado):
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
276. Restore & Recover
Flashback table (Para o passado):
Flashback table baseado em uma expressão de
tempo:
Exemplo 1:
Exemplo 2:
276
277. Restore & Recover
Flashback table (Para o passado):
Flashback table baseado em um “restore point”:
Criando o “restore point”:
Executando o flashback:
277
278. 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
279. 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
280. 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
281. 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
282. 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
283. Restore & Recover
Restore & recover em outro servidor:
Execute um backup no servidor de “origem”.
Verifique os arquivos que foram gerados.
Transfira o backup para o servidor de destino.
283
284. Restore & Recover
Restore & recover em outro servidor:
Acerte as variáveis de ambiente:
Crie um “pfile” customizado com as informações
mínimas necessárias para inicializar a instancia:
284
285. Restore & Recover
Restore & recover em outro servidor:
Crie diretórios para datafiles, redo log e archivelogs.
Inicie a instancia no modo “nomount”, restaure o
backup do controlfile:
285
286. Restore & Recover
Restore & recover em outro servidor:
Coloque a instancia no modo “mount”:
Faça um “crosscheck” dos arquivos de backup:
Catalogue os arquivos de backup:
286
287. Restore & Recover
Restore & recover em outro servidor:
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
289. Restore & Recover
Restore & recover em outro servidor:
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
290. Restore & Recover
Restore & recover em outro servidor:
Conecte-se no “rman” e execute o script:
Ao término execute um “report schema”:
290
291. Restore & Recover
Restore & recover em outro servidor:
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
292. Restore & Recover
Restore & recover em outro servidor:
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
293. Restore & Recover
Restore & recover em outro servidor:
Assim como no caso dos datafiles, este script precisa
ser ajustado, para que funcione de maneira correta:
293
Caminho corrigido
Caminho original
294. Restore & Recover
Restore & recover em outro servidor:
Execute o script gerado para renomear os arquivos de
redo log:
Para confirmar, execute um select na “v$logfile”.
294
295. Restore & Recover
Restore & recover em outro servidor:
Abra a instancia com a opção “open resetlogs”.
Recrie a tablespace temporária.
295
296. Restore & Recover
Restore & recover em outro servidor:
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
297. Restore & Recover
Restore & recover em outro servidor:
Renomeando a instancia:
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
298. Restore & Recover
Restore & recover em outro servidor:
Renomeando a instancia:
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
299. Resumo - Restore & Recover
Neste capítulo discutimos os temas:
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
301. 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
302. 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 ....
303. Arquivos de Redo log
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. Arquivos de Redo log
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. Arquivos de Redo log
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:
307. Arquivos de Redo log
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. Arquivos 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. Arquivos de Redo log
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. Arquivos de Redo log
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. Arquivos de Redo log
311
Restore de um membro único:
Conteúdo do alert.log:
Verifique na v$log o status do grupo 2:
312. Arquivos de Redo log
312
Restore de um membro único:
Resultado do select na v$log:
Exclua o arquivo danificado:
Crie novamente o arquivo, outrora danificado:
313. Arquivos de Redo log
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. Arquivos de Redo log
314
Restore de todos membros de um grupo inativo:
Identifique os arquivos no alert.log:
Coloque a instancia no modo “mount”:
Verifique o status do grupo na v$log:
315. Arquivos de Redo log
315
Restore de todos membros de um grupo inativo:
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. Arquivos de Redo log
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. Arquivos de Redo log
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”: