Treinamento RMAN Workshop 12c

2,455 views

Published on

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.

Published in: Technology

Treinamento RMAN Workshop 12c

  1. 1. RMAN (Recovery Manager) - Workshop 12c RMAN Workshop 12c
  2. 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. 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. 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
  5. 5. RMAN (Recovery Manager) - Workshop 12c RMAN Workshop 12c Overview
  6. 6. Conteúdo  Variáveis de ambiente  Conexão com o Banco de Dados  Startup / Shutdown do Banco de Dados 6
  7. 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. 8. Definição das Variáveis  Digitadas manualmente no prompt  Definidas estáticamente no .bash_profile 8
  9. 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
  10. 10. Arquivo oratab 10  Formato: <ORACLE_SID>:<ORACLE_HOME>:Y|N Y = Banco de dados inicia-se automaticamente N = Banco de dados inicia-se manual
  11. 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. 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. 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. 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. 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. 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. 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. 18. Conexão com o Banco de Dados 18 Métodos de conexão  Easy Connect:  Local Name: $ sqlplus user/pass@tnsnames
  19. 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. 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. 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. 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. 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. 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. 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
  26. 26. RMAN (Recovery Manager) - Workshop 12c RMAN Workshop 12c Arquivos Suportados
  27. 27. Conteúdo  Gerenciamento de Control Files  Gerenciamento de Redo Logs  Implementando ARCHIVELOG  Gerenciamento de Tablespaces e Data Files 27
  28. 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
  29. 29. Gerenciamento Control Files 29
  30. 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. 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)
  32. 32. Gerenciamento Control Files  Nome e localização:  Via SQL*Plus: 32
  33. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
  43. 43. Gerenciamento Redo logs  Exibindo informações dos arquivos de redo log. 43
  44. 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. 45. Gerenciamento Redo logs  Verificando os “switchs” de log.  Adicionando novos grupos de redo logs. 45
  46. 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. 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. 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. 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. 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. 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. 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. 53. Implementando Archivelog 53  O que é archivelog?  Continuação dos arquivos de redo log.  Responsável por fazer o recover.
  54. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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:
  69. 69. Tablespaces & Datafiles 69  Operações que suportam NOLOGGING:
  70. 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. 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.
  72. 72. Tablespaces & Datafiles 72  Boas práticas:
  73. 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. 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. 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. 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. 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. 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. 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. 80. Tablespaces & Datafiles 80  Movendo e renomeando datafiles (controlfile).  Abra o arquivo /tmp/mv.sql, altere o caminho dos datafiles
  81. 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. 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
  83. 83. RMAN (Recovery Manager) - Workshop 12c RMAN Workshop 12c User Managed Backups
  84. 84. Conteúdo  Cold-Backup NOARCHIVELOG  Hot-Backup (arquivelog)  Database Complete Recovery  Database Incomplete Recovery 84
  85. 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. 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. 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. 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. 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. 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. 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. 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. 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
  94. 94. Cold-Backup NOARCHIVELOG  Script Cold-Backup (exemplo): 94
  95. 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
  96. 96. Cold-Backup NOARCHIVELOG  Script Cold-Restore (exemplo): 96
  97. 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. 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. 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. 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. 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. 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. 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. 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
  105. 105. Hot Backup (archivelog)  Script Hot Backup (exemplo): 105
  106. 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. 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. 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. 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. 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. 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. 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. 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. 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. 115. Recuperação Completa  Recuperação completa com a instancia offline:  Verificando o SCN no datafile.  Verificando o SCN no controlfile. 115
  116. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
  138. 138. Resumo – User Managed Backups Neste capítulo discutimos os temas:  Cold-Backup NOARCHIVELOG Hot-Backup (arquivelog) Database Complete Recovery Database Incomplete Recovery 138
  139. 139. RMAN (Recovery Manager) - Workshop 12c RMAN Workshop 12c Configurações
  140. 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. 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
  142. 142. Visão Geral 142
  143. 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. 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. 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. 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. 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. 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. 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. 150. Configurações  Localização dos backups.  Localização default.  FRA.  Comando “BACKUP.... FORMAT”. Exemplo de arquivo de backup: 150
  151. 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. 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. 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. 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
  155. 155. 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
  156. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
  166. 166. RMAN (Recovery Manager) - Workshop 12c RMAN Workshop 12c Backups e Reports
  167. 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. 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. 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. 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. 171. Backups & Reports Backupsets x Image Copy 171 Produção Backup 100GB 100GB Backup Image Copy Produção Backup 100GB 30GBBackup Backupset
  172. 172. Backups & Reports Níveis de Backup.  Banco de dados.  Tablespaces.  Datafiles (Nome/Path).  Datafiles (números file# v$datafile). 172 Database Backup RMAN
  173. 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. 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. 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. 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. 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. 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. 179. Backups & Reports Opções Adicionais de Backup:  Backup de tablespaces que “ainda” não tem backup.  Excluindo tablespaces READ ONLY. 179
  180. 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. 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. 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. 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. 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. 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. 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
  187. 187. Backups & Reports Pluggable & Container Databases (Overview): 187
  188. 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. 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. 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. 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. 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. 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. 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. 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. 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. 197. Backups & Reports Validando banco de dados & Backups.  Comando VALIDATE:  Outras variações do comando VALIDATE:  Validação em um PDB. 197
  198. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 208. Backups & Reports Output de informações:  Redirecionando para output files.  Comando “tee”.  Comando “script”. 208
  209. 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. 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. 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. 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. 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
  214. 214. Backups & Reports Views de monitoramento: 214
  215. 215. Backups & Reports Scripts de monitoramento:  Backup piece por datafiles: 215
  216. 216. Backups & Reports Scripts de monitoramento:  Tempo de execução dos backups: 216
  217. 217. 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
  218. 218. RMAN (Recovery Manager) - Workshop 12c RMAN workshop 12c Restore e Recover
  219. 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. 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. 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. 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. 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. 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. 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. 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. 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
  228. 228. Restore & Recover Data Recovery Advisor:  Listando falhas:  Ou então: 228
  229. 229. Restore & Recover Data Recovery Advisor:  Capturando sugestões de correção (Advise Failure): 229
  230. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 248. Restore & Recover Recuperação completa da instancia: Restore de datafiles para localização não default:  SET NEW NAME e SWITCH 248
  249. 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. 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. 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. 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. 253. Restore & Recover Recuperação completa da instancia: Recuperação de PDBs:  Conectado no CBD:  Conectado diretamente no PDB: 253
  254. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 271. Restore & Recover Flashback table (DROP):  Para consultar a lixeira, use o select:  Para recuperar uma tabela: 271
  272. 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. 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. 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. 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. 276. Restore & Recover Flashback table (Para o passado): Flashback table baseado em uma expressão de tempo:  Exemplo 1:  Exemplo 2: 276
  277. 277. Restore & Recover Flashback table (Para o passado): Flashback table baseado em um “restore point”:  Criando o “restore point”:  Executando o flashback: 277
  278. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
  288. 288. Restore & Recover Restore & recover em outro servidor: 288
  289. 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. 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. 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. 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. 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. 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. 295. Restore & Recover Restore & recover em outro servidor:  Abra a instancia com a opção “open resetlogs”.  Recrie a tablespace temporária. 295
  296. 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. 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. 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. 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
  300. 300. RMAN workshop 12c Arquivos de Redo log RMAN (Recovery Manager) - Workshop 12c
  301. 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. 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. 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. 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. 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:
  306. 306. Arquivos de Redo log 306 Grupos Status Arquivos Tamanho MB
  307. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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”:

×