Serviço de cópia de segurança e RD para Oracle

A base de dados Oracle é uma base de dados de classe empresarial popular que suporta aplicações críticas. Esta página apresenta o serviço de cópia de segurança e recuperação de desastres para ambientes de base de dados Oracle. A arquitetura associada oferece uma cópia de segurança incremental para sempre consistente com a aplicação para o Google Cloud, bem como recuperação instantânea e clonagem para bases de dados Oracle de vários TB.

Como funciona

As secções seguintes descrevem o processo de captura e recuperação de dados.

Captura de dados

  1. O agente de cópias de segurança e RD está implementado no servidor Oracle.

  2. Monte o disco de preparação no servidor de base de dados.

  3. Invocar a API incremental do RMAN para copiar blocos alterados.

  4. Invocar a união incremental do RMAN para criar uma cópia de segurança completa virtual nova.

  5. Desmonte o disco de preparação do servidor de base de dados.

  6. A cópia de segurança e a RD tiram um instantâneo interno. A cópia de segurança completa sintética num determinado momento está pronta.

Recuperação de dados

A cópia de segurança e a recuperação de desastres montam instantaneamente um disco de preparação reescrevível através de ISCSI ou NFS e colocam a base de dados online.

APIs de cópia de segurança da Oracle

A cópia de segurança e a RD usam as seguintes APIs Oracle:

  • Cópia de imagem do RMAN: uma cópia de imagem de um ficheiro de dados é muito mais rápida de restaurar porque a estrutura física do ficheiro de dados já existe. A diretiva RMAN BACKUP AS COPY cria cópias de imagens para todos os ficheiros de dados de toda a base de dados e retém o formato do ficheiro de dados.

  • API ASM e CRS: o grupo de discos de cópia de segurança do ASM é gerido através da API ASM e CRS.

  • API de cópia de segurança do registo de arquivo do RMAN: os registos de arquivo gerados são copiados para o disco de preparação e eliminados da localização do arquivo de produção.

Minimize os conflitos quando usa o serviço de cópia de segurança e RD com outros produtos de cópia de segurança

O serviço de cópia de segurança e recuperação de desastres pode coexistir com produtos antigos que capturam dados de bases de dados de produção. As seguintes práticas recomendadas podem ajudar a melhorar a sua experiência:

Programação da cópia de segurança da base de dados Oracle

Prática recomendada Agende tarefas de cópia de segurança da base de dados do serviço de cópia de segurança e recuperação de desastres para começarem quando o software de cópia de segurança antigo estiver concluído. Não agende a execução do software de cópia de segurança antigo imediatamente após a conclusão normal de uma tarefa de cópia de segurança da base de dados do serviço de cópia de segurança e recuperação de desastres.
Motivo Se as tarefas de cópia de segurança antigas e as tarefas de cópia de segurança da base de dados do serviço de cópia de segurança e recuperação de desastres forem executadas em simultâneo, pode haver um impacto sério no desempenho do servidor da base de dados, o que pode levar à instabilidade e, possivelmente, a uma indisponibilidade. Além disso, para o Oracle, isto pode resultar em imagens de cópia de segurança inválidas para uma ou ambas as soluções.

Gestão de registos de arquivo da Oracle

A Oracle usa registos de arquivo gerados durante uma cópia de segurança da base de dados para garantir a consistência e a capacidade de recuperação dessa cópia de segurança. Consequentemente, se os registos de arquivo forem limpos durante uma tarefa de cópia de segurança da base de dados, não é possível recuperar essa cópia de segurança.

Requisito Apenas um sistema pode gerir (capturar e/ou truncar/eliminar) registos, quer seja o software de cópia de segurança antigo ou o serviço de cópia de segurança e recuperação de desastres.
Prática recomendada Não permita que os registos de arquivo da Oracle sejam anulados durante uma tarefa de Backup and DR e não permita que o serviço de Backup and DR anule os registos de arquivo durante uma tarefa de cópia de segurança RMAN antiga.
Se o software antigo estiver a gerir o registo de arquivo, desative as tarefas de anulação de registos de arquivo no software de cópia de segurança antigo no início da tarefa de cópia de segurança do Backup and DR e retome as tarefas de anulação no final ou retenha o registo de arquivo durante, pelo menos, 24 horas antes da anulação.
Motivo Se os registos de arquivo forem removidos durante uma tarefa de cópia de segurança da base de dados, a imagem de cópia de segurança da base de dados pode ser irrecuperável.

Conflito de metadados do RMAN com cópias de segurança antigas que tornam as cópias de segurança do serviço de cópia de segurança e RD obsoletas

Por predefinição, o parâmetro DO NOT UNCATALOG nos detalhes e nas definições da aplicação do serviço de cópia de segurança e recuperação de desastres está definido como Não. É catalogada uma cópia de segurança de ficheiros de dados de cópia de segurança e recuperação de desastres no início da cópia de segurança e é retirada do catálogo no final da tarefa. Se definir esta opção como Sim, otimiza o tempo de cópia de segurança para bases de dados com um grande número de ficheiros de dados, mantendo o catálogo de cópias de segurança de ficheiros de dados do RMAN catalogado após cada tarefa de cópia de segurança. No entanto, interfere com outros produtos de cópia de segurança.

Requisito Defina os detalhes da aplicação de cópia de segurança e recuperação de desastres e o parâmetro de definições Do not uncatalog como Não.
Prática recomendada As cópias de segurança da base de dados do serviço de cópia de segurança e RD são incrementais para sempre. Isto é conseguido através da utilização da cópia de imagem do RMAN com a API de união incremental do RMAN. A primeira cópia de segurança do RMAN é uma cópia de imagem completa do ficheiro de dados da base de dados no disco de cópia de segurança do Backup and DR com uma captura instantânea interna do disco de cópia de segurança. As execuções de cópias de segurança incrementais do RMAN subsequentes com a união incremental do RMAN no disco de cópia de segurança do Backup and DR atualizam a última cópia de segurança completa com alterações incrementais antes da captura de ecrã. No entanto, se for feita uma cópia de segurança de base de dados de terceiros ou uma verificação cruzada de execuções de cópias de segurança após a cópia de segurança de base de dados do Backup and DR, todos os ficheiros de dados de cópias de segurança do Backup and DR são marcados como obsoletos nos metadados do RMAN. Os detalhes da aplicação de cópia de segurança e recuperação de desastres e o parâmetro de definições Do not uncatalog definido como Sim resultam no seguinte erro: Falha ao catalogar cópias de imagens do dispositivo de preparação e falha na cópia de segurança. Mantenha a opção Do not uncatalog definida como Não para coexistir com outros produtos de cópia de segurança antigos.
Motivo Por predefinição, o parâmetro Do not uncatalog> in Backup and DR application details & settings is set to No. Setting this to Yes interferes with other backup products.

Acompanhamento de alterações de blocos (BCT) da base de dados Oracle

A monitorização de alterações de blocos da Oracle permite fazer cópias de segurança rápidas da base de dados, identificando os blocos que foram alterados. A operação de cópia de segurança inclui apenas os blocos alterados.

  • O serviço de cópia de segurança e recuperação de desastres incremental-forever suporta bases de dados em execução com o BCT ativado ou desativado. Com o BCT não ativado, o tempo de cópia de segurança incremental aumenta.

  • O acompanhamento de alterações de blocos está ativado ao nível da base de dados.

  • A Oracle regista os blocos alterados em cada ficheiro de dados num ficheiro de acompanhamento, que é um pequeno ficheiro binário armazenado na área da base de dados.

  • Com o BCT ativado, o RMAN usa o ficheiro BCT para obter os blocos alterados para a cópia de segurança incremental.

  • O RMAN analisa cada bloco num ficheiro de dados para todos os ficheiros de dados na base de dados durante a cópia de segurança incremental quando o acompanhamento de blocos de alterações na base de dados não está ativado.

Proteja bases de dados Oracle num grupo de consistência de cópia de segurança e recuperação de desastres

Na maioria das configurações, um grupo de consistência pode conter uma única aplicação de base de dados Oracle e qualquer número de aplicações do sistema de ficheiros do servidor Oracle. Um grupo de consistência é a opção recomendada para bases de dados Oracle em ambientes de teste/desenvolvimento e outros exemplos de utilização de agilidade empresarial.

Bases de dados Oracle com TDE

O serviço de cópia de segurança e recuperação de desastres suporta vários métodos de captura e apresentação para bases de dados Oracle em várias configurações. Isto inclui operações de cópia de segurança, recuperação e montagem com reconhecimento de aplicações da base de dados Oracle com a encriptação de dados transparente (TDE) configurada.

Para bases de dados Oracle com TDE, os ficheiros de carteira do anfitrião de cópia de segurança de origem têm de estar disponíveis para o anfitrião de destino de quaisquer montagens conscientes da aplicação. Isto pode ser feito de várias formas.

  • Os ficheiros de carteira podem ser copiados do servidor de origem da cópia de segurança para o servidor de montagem de destino e o Oracle configurado para aceder aos mesmos.
  • Se os ficheiros da carteira Oracle estiverem armazenados num dispositivo central partilhado na rede, a instância Oracle do destino de montagem do Appaware deve ser configurada para aceder aos mesmos.

  • Se os ficheiros da carteira da Oracle foram capturados durante a cópia de segurança do serviço de cópia de segurança e recuperação de desastres definindo a definição avançada de localização do ficheiro de configuração da Oracle, os ficheiros da carteira podem ser obtidos com os seguintes passos:

    1. Faça uma montagem padrão da base de dados no anfitrião de destino.
    2. Copie os ficheiros de carteira da montagem da base de dados padrão para o anfitrião de destino e configure o Oracle para os usar.
    3. Desmonte a base de dados do anfitrião de destino.
    4. Efetue uma montagem com reconhecimento da aplicação da base de dados no anfitrião de destino.

Cópia de segurança e RD com a base de dados Oracle Exadata ou o Oracle ExaCC

Os dispositivos de cópia de segurança/recuperação suportam a captura e a apresentação de dados do Exadata através dos protocolos iSCSI ou Oracle dNFS.

  • O dispositivo de cópia de segurança/recuperação está ligado através de iSCSI ou Oracle dNFS na rede (não no caminho de dados).

  • A cópia de segurança do RMAN usa o RMAN para escrever diretamente no arquivo de dados de cópia apresentado pelo Backup and DR como um sistema de ficheiros ou como um grupo de discos ASM.

  • Formatos de captura de dados: em grupo de discos ASM (apenas iSCSI) ou em sistema de ficheiros (dNFS ou iSCSI).

  • A cópia de segurança incremental permanente de cópias de segurança e RD usa cópias de segurança atualizadas incrementalmente do RMAN, avançando as cópias de segurança de cópias de imagens.

Cópia de segurança e captura de RD de dados do Exadata e do ExaCC

O agente de cópia de segurança e recuperação de desastres tem de ser instalado no servidor Exadata para facilitar a comunicação com o dispositivo de cópia de segurança/recuperação e invocar a API RMAN para a cópia de segurança da base de dados.

O agente de cópia de segurança e RD expõe e mapeia os discos de cópia de segurança e RD para o servidor Exadata como um destino iSCSI. O formato de captura de dados pode estar em ASM disk group ou no Sistema de ficheiros.

Instale o agente de cópia de segurança e recuperação de desastres em cada anfitrião do Exadata no espaço do utilizador para facilitar a comunicação com o dispositivo de cópia de segurança/recuperação e invocar a API RMAN para a cópia de segurança da base de dados.

Formato de captura no grupo de discos do ASM

Durante uma cópia de segurança, o agente de cópia de segurança e RD faz o seguinte:

  1. Mapeie e exponha o disco lógico ao servidor Exadata como um destino iSCSI.

  2. Adicione o caminho do disco de cópia de segurança e recuperação de desastres à string do disco ASM.

  3. Certifique-se de que a string do disco do ASM é adicionada ao ficheiro de parâmetros e não existe no perfil do CRS.

  4. Crie um grupo de discos ASM como uma redundância externa através do disco do Backup and DR.

    • Cópia de segurança do RMAN através do RMAN para escrever diretamente no arquivo de dados de cópia apresentado pelo dispositivo de cópia de segurança/recuperação como grupo de discos ASM ou como sistema de ficheiros.

    • Cópia de segurança incremental permanente com cópias de segurança atualizadas incrementalmente do RMAN, cópias de segurança de cópias de imagens progressivas.

Formato de captura no sistema de ficheiros através do dNFS

O NFS direto (dNFS) da Oracle é um cliente NFS (sistema de arquivos de rede) otimizado que oferece um acesso mais rápido e escalável ao armazenamento NFS localizado em dispositivos de armazenamento NAS (acessíveis através de TCP/IP). O NFS direto está integrado diretamente no kernel da base de dados, tal como o ASM.

O protocolo dNFS pode ser usado para cópias de segurança baseadas no sistema de ficheiros como uma partilha NFS.

O agente de cópia de segurança e RD expõe e mapeia os discos de cópia de segurança e RD para o servidor Exadata como uma partilha NFS.

Pré-requisitos para o dNFS no servidor Exadata:

  • Ative o dNFS no servidor Exadata:

    cd $ORACLE_HOME/rdbms/lib make -f ins_rdbms.mk nfs on

  • Reinicie a base de dados.

    Use a API RMAN para fazer uma cópia de segurança da base de dados para o sistema de ficheiros na partilha dNFS apresentada pelo dispositivo de cópia de segurança/recuperação.

Volte a colocar online os grupos de discos do ASM protegidos por cópias de segurança e recuperação de desastres após o reinício de um servidor de BD de destino

Após qualquer reinício do servidor de base de dados em que a cópia de segurança e recuperação de desastres esteja montada ou as cópias de segurança e recuperação de desastres estejam em curso para a base de dados no momento do reinício/falha do sistema, siga estes passos para voltar a montar o grupo de discos de cópia de segurança e recuperação de desastres:

  1. Verifique se o servidor da base de dados de destino está novamente em funcionamento e se o sistema ASM e RAC também estão em funcionamento.

  2. Reinicie o agente do Backup and DR (a partir da raiz).

  3. Defina o ambiente do ASM.

  4. Inicie sessão no ASM sqlplus e verifique o estado do grupo de discos:

    select name, state from v$asm_diskgroup where name = '<dg name>';)

  5. Se estiver desmontado, monte o grupo de discos: alter diskgroup <dg name> mount;

  6. Inicie sessão no SO Oracle, defina o ambiente da base de dados e, em seguida, inicie a base de dados.

O que se segue?

Leia acerca dos pré-requisitos para fazer uma cópia de segurança de uma base de dados Oracle.

Outra documentação para o Backup and DR for Oracle