oracle_ocp

Fazer um recovery a partir de um arquivo temporário perdido

  • Um arquivo temporário pode ser recuperado com o banco de dados aberto.
  • O impacto de um arquivo temporário perdido é percebdo quando os usuários tentam ordenar grandes conjuntos de resultados.
  • Quando um arquivo temporário desaparece, é possível recriá-lo na localização original ou informar uma nova localização.
  • Se o banco de dados for inicializado sem os arquivos temporários, ele os criará na localização especificada no controlfile.

Fazer um recovery a partir de um grupo de redo logs perdido

  • Um grupo de redo logs pode ter seis status: CURRENT, ACTIVE, INACTIVE, UNUSED, CLEARING ou CLEARING_CURRENT. Os status mais comuns são CURRENT, ACTIVE e INACTIVE.
  • É possível usar a view dinâmica de desempenho V$LOG para consultar o status de cada grupo de redo logs.
  • Se um membro de um grupo de redo logs for danificado ou desaparecer, o processo LGWR (Log Writer) continuará gravando no membro não-danificado, e não ocorrerá qualquer perda de dados ou interrupção de serviço.
  • A view dinâmica de desempenho V$LOGFILE informa o status de cada membro individual de cada grupo de arquivos de log.
  • Se o status de um membro de um grupo de arquivo de log for INVALID na view V$LOGFILE, ele está danificado ou indisponível e deverá ser recriado.
  • Muito provavelmente, a perda de um grupo de arquivos de log com o status INACTIVE não acarretará a perda de transações com commit, desde que os outros membros desse grupo permaneçam intactos.
  • A perda de um grupo de arquivos de redo log com um status ACTIVE não acarretará a perda das transações com commit se você conseguir executar com êxito o comando ALTER SYSTEM CHECKPOINT. Se o checkpoint falhar, você deverá fazer uma recuperação incompleta.
  • A perda de um grupo de arquivos de redo log com o status CURRENT acarretará uma falha na instância, e você deverá fazer uma recuperação incopleta.

Fazer um recovery a partir da perda do arquivo de senhas

  • A perda de um arquivo de senhas impede que os DBA’s se conectem com uma instância aberta ou fechada com o privilégio SYSDBA, SYSOPER ou SYSASM.
  • Use um arquivo de senhas se estiver estabelecendo conexão remota e a conexão não for segura.
  • Conectar-se usando o privilégio SYSDBA ou SYSASM estabelece conexão com o banco de dados como o usuário SYS. O privilégio SYSOPER conecta como PUBLIC.
  • Use o comando orapwd em um prompt do sistema operacional para recriar o arquivo de senhas,
  • A localização padrão do arquivo de senhas é $ORACLE_HOME/dbs no Unix ou Linux, e %ORACLE_HOME%database no Windows.
  • A view dinâmica de desempenho V$PWFILE_USERS lista todos os usuários do banco de dados que possuem os privilégios SYSDBA, SYSOPER ou SYSASM.

Fazer um recovery incompleto do banco de dados, gerenciado pelo usuário

  • Se ocorrer uma falha de mídia em seu banco de dados, em geral você irá preferir usar uma recuperação completa para restaurá-lo ao estado que se encontrava  antes da falha, o que inclui todas as transações com commit.
  • Em uma recuperação de banco de dados aberto ou fechado, é possível recuperar o banco de dados inteiro de uma só vez, um tablespace de cada vez ou um datafile por vez.
  • Você pode consultar a view dinâmica de desempenho V$RECOVER_FILE para saber quais arquivos necessitam de recuperação de mídia, e a view V$RECOVER_LOG para conhecer os archivelogs necessários para recuperar os datafiles restaurados no recovery completo do banco de dados.
  • Faça um recovery completo, gerenciado pelo usuário, depois que o banco de dados for restaurado no modo MOUNT.
  • Todos os archivelogs necessários para recuperar os datafiles restaurados devem estar disponíveis na localização padrão a fim de automatizar o processo de recovery com a cláusula AUTOMATIC do comando RECOVER.
  • Se os archivelogs necessários para o recovery residem em diversas localizações, você poderá especificá-las manualmente durante o processo de recuperação quando você não incluir a palavra-chave AUTOMATIC.
  • Você pode fazer o recovery completo de um ou mais tablespaces danificados com o banco de dados aberto, colocando os tablespaces no modo offline com o comando ALTER TABLESPACE ... OFFLINE TEMPORARY.
  • Para recuperar um tablespace enquanto estiver no modo offline e o restante do banco estiver online, use o comando RECOVER AUTOMATIC TABLESPACE ... depois de restaurar os datafiles do tablespace a partir da localização do backup.

Referência Bibliográfica

Este post, assim como todos os posts sobre Certificação OCP deste blog, são trechos do livro “OCP Oracle Database 11g – Administração II (Guia do Exame 1Z0-053)”, da editora Bookman – www.bookman.com.br
Recomendo este livro a todos que pretendem estudar para o exame. Meus posts são apenas algumas dicas para quem já está estudando por outros materiais, e por isso exige uma base de conhecimento anterior em cada um dos capitulos. Para uma referência completa de estudos é recomendado a compra do livro correspondente, bem como a documentação oficial da Oracle.

Milton Bastos é DBA Oracle e Desenvolvedor PL/SQL, dividido entre Apucarana/PR e Curitiba/PR. Certificações: OCA (Oracle 11g DBA Certified Associate), Oracle Database 11g Data Warehousing Certified Implementation Specialist, Oracle Database 11g Sales Specialist Assessment, Oracle Database Appliance PreSales Specialist Assessment, Oracle Database Appliance Sales Specialist Assessment