Skip to main content
Enterprise applications
O português é fornecido por meio de tradução automática para sua conveniência. O inglês precede o português em caso de inconsistências.

Backups online

Colaboradores jfsinmsp
PDFs

Dois conjuntos de dados são necessários para proteger e recuperar um banco de dados Oracle no modo de backup. Note que esta não é a única opção de backup Oracle, mas é a mais comum.

  • Um instantâneo dos arquivos de dados no modo de backup

  • Os logs de arquivo criados enquanto os datafiles estavam no modo de backup

Se a recuperação completa, incluindo todas as transações confirmadas, é necessário um terceiro item:

  • Um conjunto de registos de refazer atuais

Existem várias maneiras de impulsionar a recuperação de um backup on-line. Muitos clientes restauram snapshots usando a CLI do ONTAP e, em seguida, usando o Oracle RMAN ou sqlplus para concluir a recuperação. Isso é especialmente comum com grandes ambientes de produção em que a probabilidade e a frequência de restaurações de banco de dados são extremamente baixas e qualquer procedimento de restauração é Tratado por um DBA qualificado. Para automação completa, soluções como o NetApp SnapCenter incluem um plug-in Oracle com interfaces gráficas e de linha de comando.

Alguns clientes de grande escala adotaram uma abordagem mais simples, configurando scripts básicos nos hosts para colocar os bancos de dados no modo de backup em um momento específico, em preparação para um snapshot agendado. Por exemplo, programe o comando alter database begin backup às 23:58, alter database end backup às 00:02 e, em seguida, programe instantâneos diretamente no sistema de armazenamento à meia-noite. O resultado é uma estratégia de backup simples e altamente dimensionável que não requer software ou licenças externos.

Layout de dados

A configuração mais simples consiste em isolar os arquivos de dados em um ou mais volumes dedicados, LUNs ou namespaces NVMe. Os recursos de storage devem estar livres de qualquer outro tipo de arquivo. Isso garante que os arquivos de dados possam ser restaurados rapidamente durante uma operação SnapRestore sem comprometer um importante redo log, arquivo de controle ou log de arquivamento.

A SAN possui requisitos semelhantes para isolamento de arquivos de dados em recursos dedicados. Com um sistema operacional como Microsoft Windows usando armazenamento AFF, um único volume pode conter múltiplos LUNs de arquivos de dados, cada um com um sistema de arquivos NTFS. Em outros sistemas operacionais, geralmente existe um gerenciador de volumes lógico. Por exemplo, com Oracle ASM, a opção mais simples seria confinar os LUNs de um grupo de discos ASM a um único volume que possa ser copiado e restaurado como uma unidade. Se volumes adicionais forem necessários por motivos de desempenho ou gerenciamento de capacidade, a criação de um grupo de discos adicional no novo volume resulta em um gerenciamento mais simples.

ASA não possui a abstração em nível de volume que em um sistema AFF pode hospedar múltiplos LUNs. Em vez disso, ASA utiliza grupos de consistência. Em muitos casos, um único LUN ou namespace NVMe pode atender aos requisitos de gerenciamento e desempenho de um banco de dados. Se forem necessários múltiplos LUNs ou namespaces, recursos adicionais podem ser adicionados e agrupados como um grupo de consistência que se torna o contêiner de arquivos de dados.

Se essas diretrizes forem seguidas, os snapshots podem ser agendados diretamente no sistema de storage.

Atenção: Verifique se o ASM spfile e passwd os arquivos não estão no grupo de discos que hospeda os arquivos de dados. Isso interfere na capacidade de restaurar seletivamente datafiles e apenas datafiles.

Procedimento de recuperação local – NFS

Este procedimento pode ser conduzido manualmente ou através de uma aplicação como o SnapCenter. O procedimento básico é o seguinte:

  1. Encerre o banco de dados.

  2. Recupere os volumes NFS do arquivo de dados para o snapshot imediatamente anterior ao ponto de restauração desejado.

  3. Reproduza registos de arquivo até ao ponto pretendido.

  4. Repita os logs atuais de refazer se a recuperação completa for desejada.

Este procedimento pressupõe que os registos de arquivo desejados ainda estão presentes no sistema de ficheiros ativo. Se não estiverem, os logs do arquivo devem ser restaurados ou rman/sqlplus podem ser direcionados para os dados no diretório instantâneo.

Além disso, para bancos de dados menores, os arquivos de dados podem ser recuperados por um usuário final diretamente .snapshot do diretório sem a ajuda de ferramentas de automação ou administradores de armazenamento para executar um snaprestore comando.

Procedimento de recuperação local – SAN

Este procedimento pode ser conduzido manualmente ou através de uma aplicação como o SnapCenter. O procedimento básico é o seguinte:

  1. Encerre o banco de dados.

  2. Quiesce o(s) grupo(s) de discos que hospedam os arquivos de dados. O procedimento varia consoante o gestor de volume lógico escolhido. Com ASM, o processo requer a desmontagem do grupo de discos. Com o Linux, os sistemas de arquivos devem ser desmontados e os volumes lógicos e grupos de volumes devem ser desativados. O objetivo é parar todas as atualizações no grupo de volume alvo a serem restauradas.

  3. Restaure as LUNs que hospedam os grupos de discos de arquivos de dados para o snapshot imediatamente anterior ao ponto de restauração desejado.

  4. Reative os grupos de discos recentemente restaurados.

  5. Reproduza registos de arquivo até ao ponto pretendido.

  6. Repita todos os logs de refazer se a recuperação completa for desejada.

Este procedimento pressupõe que os logs de arquivamento desejados ainda estejam presentes no sistema de arquivos ativo. Caso contrário, os logs de arquivamento devem ser restaurados colocando os LUNs/namespaces de log de arquivamento totalmente offline e realizando uma restauração (ou criando um clone de um snapshot anterior, o que pode ser difícil devido à criação de UUIDs ou nomes LVM duplicados no mesmo host). Este também é um exemplo em que separar os logs de arquivamento em recursos de storage dedicados é útil. Se os logs de arquivamento compartilharem um grupo de volume com os logs de redo, os logs de redo deverão ser copiados para outro local antes da restauração do conjunto completo de LUNs. Esta etapa evita a perda das transações finais registradas.