Esta página foi traduzida pela API Cloud Translation.

Guia de soluções: backup do Google Cloud e DR para Oracle na solução Bare Metal

Visão geral

Para fornecer resiliência aos databases Oracle em um ambiente da Solução Bare Metal, você precisa ter uma estratégia clara de backups de database e recuperação de desastres. Para ajudar você com esse requisito, a equipe de arquitetos de soluções do Google Cloud fez alguns testes extensivos do serviço de backup e DR do Google Cloud e compilou as descobertas neste guia. Portanto, mostraremos as melhores maneiras de implantar, configurar e otimizar suas opções de backup e recuperação para bancos de dados Oracle em um ambiente da Solução Bare Metal usando o serviço de backup e DR. Além disso, vamos compartilhar alguns valores de desempenho dos resultados de testes para você ter uma referência e comparar com seu ambiente. Este guia será útil se você for um administrador de backup, administrador do Google Cloud ou um DBA da Oracle.

Experiência

Em junho de 2022, a equipe de arquitetos de soluções iniciou uma demonstração de prova de conceito (PoC, na sigla em inglês) do backup e DR do Google Cloud para um cliente corporativo. Para atender aos critérios de sucesso, precisávamos apoiar a recuperação do banco de dados Oracle de 50 TB e restaurá-lo em até 24 horas.

Essa meta apresentou vários desafios, mas a maioria das pessoas envolvidas na PoC acreditava que poderíamos alcançar esse resultado e que deveríamos prosseguir com a prova de conceito. Sentimos que o risco era relativamente baixo, porque tínhamos dados de testes anteriores da equipe de engenharia de backup e DR mostrando que era possível alcançar esses resultados. Também compartilhamos os resultados do teste com o cliente para que ele se sinta confortável para prosseguir com a prova de conceito.

Durante a PoC, aprendemos a configurar vários elementos juntos, como Oracle, Backup do Google Cloud e DR, armazenamento e links de extensão regional, em um ambiente da Solução Bare Metal. Seguindo as práticas recomendadas que aprendemos, você pode alcançar seus próprios resultados.

"Sua quilometragem pode variar" é uma ótima maneira de pensar sobre os resultados gerais deste documento. Nosso objetivo é compartilhar alguns conhecimentos sobre o que aprendemos, no que você deve se concentrar, o que deve evitar e o que investigar se não estiver conseguindo o desempenho ou os resultados desejados. Esperamos que este guia ajude você a ganhar confiança em relação às soluções propostas e que seus requisitos possam ser atendidos.

Arquitetura

A Figura 1 mostra uma visualização simplificada da infraestrutura que você precisa criar ao implantar o backup e o DR para proteger os bancos de dados Oracle em execução em um ambiente da Solução Bare Metal.

Figura 1: componentes para usar backup e DR com bancos de dados Oracle em um ambiente da Solução Bare Metal

Mostra como uma extensão regional da Solução Bare Metal se conecta a todos os componentes na arquitetura, incluindo um projeto host, um projeto de produtor de Backup e DR que contém o console de gerenciamento de Backup e DR, um projeto de consumidor de Backup e DR que contém o dispositivo de backup/recuperação, outros projetos de serviço que contêm VMs do Compute Engine e o Cloud Storage.

Como você pode ver no diagrama, esta solução requer os seguintes componentes:

Extensão regional da Solução Bare Metal: permite executar bancos de dados Oracle em um data center de terceiros adjacente a um data center do Google Cloud e usar suas licenças de software atuais no local.
Projeto de serviço de backup e DR: permite hospedar seu dispositivo de backup/recuperação e fazer backup da Solução Bare Metal e das cargas de trabalho do Google Cloud em buckets do Cloud Storage.
Projeto de serviço do Compute: fornece um local para executar as VMs do Compute Engine.
Serviço de backup e DR: fornece o console de gerenciamento de backup e DR que permite manter seus backups e a recuperação de desastres.
Projeto host: permite criar sub-redes regionais em uma VPC compartilhada que pode conectar a extensão regional da Solução Bare Metal ao serviço de backup e DR, ao dispositivo de backup/recuperação, aos buckets do Cloud Storage e às VMs do Compute Engine.

Instalar o Backup e DR do Google Cloud

A solução de backup e DR exige, no mínimo, os dois componentes principais a seguir para que ela funcione:

Console de gerenciamento de backup e DR: UI de usuário HTML 5 e um endpoint de API que permite criar e gerenciar backups no console do Google Cloud.
Dispositivo de backup/recuperação: este dispositivo atua como o worker da tarefa na execução de backups, além de ativar e restaurar tarefas de tipo.

O Google Cloud gerencia o console de gerenciamento de backup e DR. Você precisa implantar o console de gerenciamento em um projeto de produtor de serviço (lado de gerenciamento do Google Cloud) e implantar o dispositivo de backup/recuperação em um projeto de consumidor de serviço (lado do cliente). Para saber mais sobre backup e DR, consulte Configurar e planejar uma implantação de backup e DR. Para ver a definição de um produtor e um consumidor de serviço, consulte o glossário do Google Cloud.

Antes de começar

Para instalar o serviço de backup e DR do Google Cloud, conclua as etapas de configuração a seguir antes de iniciar a implantação:

Ative uma conexão de acesso a serviços privados. Você precisa estabelecer essa conexão antes de iniciar a instalação. Mesmo que você já tenha uma sub-rede de acesso a serviços particulares configurada, ela precisa ter no mínimo uma sub-rede /23. Por exemplo, se você já configurou uma sub-rede /24 para a conexão de acesso a serviços particulares, recomendamos adicionar uma sub-rede /23. Melhor ainda, é possível adicionar uma sub-rede /20 para garantir a inclusão de mais serviços posteriormente.
Configure o Cloud DNS para que ele possa ser acessado na rede VPC em que você implanta o dispositivo de backup/recuperação. Isso garante a resolução adequada de googleapis.com (por pesquisa particular ou pública).
Configure rotas padrão de rede e regras de firewall para permitir o tráfego de saída para *.googleapis.com (por IPs públicos) ou private.googleapis.com (199.36.153.8/30) na porta TCP 443 ou uma saída explícita para 0.0.0.0/0. Novamente, você precisa configurar as rotas e o firewall na rede VPC em que instala o dispositivo de backup/recuperação. Também recomendamos usar o Acesso privado do Google como uma opção preferencial. Consulte Configurar o Acesso privado do Google para mais informações.
Ative as seguintes APIs no projeto de consumidor:
- API Compute Engine
- API Cloud Key Management Service (KMS)
- API Cloud Resource Manager (para projetos de host e de serviço, se estiverem em uso)
- API Identity and Access Management
- API Workflows
- API Cloud Logging
Se você tiver ativado alguma políticas da organização, configure o seguinte:
- constraints/cloudkms.allowedProtectionLevels incluem SOFTWARE ou ALL.
Configure as seguintes regras de firewall:
- Entrada do dispositivo de backup/recuperação na VPC do Compute Engine para o host do Linux (agente) na porta TCP-5106.
- Se você usar um disco de backup baseado em blocos com iSCSI, a saída do host do Linux (agente) na Solução Bare Metal para o dispositivo de backup/recuperação na VPC do Compute Engine na porta TCP-3260
- Se você usar um disco de backup baseado em NFS ou dNFS, a saída do host do Linux (Agent) na Solução Bare Metal para o dispositivo de backup/recuperação na VPC do Compute Engine nas seguintes portas será usada:
  - TCP/UDP-111 (rpcbind)
  - TCP/UDP-756 (status)
  - TCP/UDP-2049 (nfs)
  - TCP/UDP-4001 (mountd)
  - TCP/UDP-4045 (nlockmgr)
Configure o Google Cloud DNS para resolver nomes de host e domínios da Solução Bare Metal e garantir que a resolução de nomes seja consistente entre os servidores, as VMs e os recursos da Solução Bare Metal e os recursos baseados no Compute Engine, como o serviço de backup e DR.

Instalar o console de gerenciamento de backup e DR

Ative a API Backup and DR Service, se ainda não estiver ativada.
No console do Google Cloud, use o menu de navegação para acessar a seção Operações e selecione Backup e DR:
Selecione a conexão de acesso a serviços particulares que você criou anteriormente.
Escolha o local do console de gerenciamento de backup e DR. Essa é a região em que você implanta a interface do usuário do console de gerenciamento de backup e DR em um projeto de produtor de serviços. O Google Cloud é proprietário e mantém os recursos do console de gerenciamento.
Escolha a rede VPC no projeto de consumidor de serviço que você quer conectar ao serviço de backup e DR. Geralmente, é uma VPC compartilhada ou projeto host.
Depois de aguardar até uma hora, a tela a seguir será exibida quando a implantação for concluída.
Observação:o URL de cada página do console de gerenciamento de backup e DR usa o seguinte formato:
https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com
Substitua as variáveis pelo seguinte:
- O número do projeto do Google Cloud que hospeda o console de gerenciamento de backup e DR.
- O ID gerado, que aparece entre o número do projeto e a palavra dot no URL da API para o console de gerenciamento de backup e DR.
- A região onde o console de gerenciamento de backup e DR está localizado.

Instalar o appliance de backup/recuperação

Na página Backup e DR, clique em Fazer login no console de gerenciamento:

https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/

Na página principal do console de gerenciamento de backup e DR, acesse a página Dispositivos:
```
https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#clusters
```
Observação: encontre o número do projeto no painel do console do Google Cloud. Use o número do projeto em que você ativou o serviço de backup e DR.
Digite o nome do appliance de backup/recuperação. O Google Cloud adiciona automaticamente outros números aleatórios no final do nome assim que a implantação é iniciada.
Escolha o projeto de consumidor em que deseja instalar o dispositivo de backup/recuperação.
Escolha sua região, zona e sub-rede preferidas.
Selecione um tipo de armazenamento. Recomendamos escolher o disco permanente padrão para as PoCs e o disco permanente SSD para um ambiente de produção.
Clique no botão Iniciar instalação. O processo pode levar uma hora para implantar o console de gerenciamento de backup e DR e o primeiro dispositivo de backup/recuperação.
É possível adicionar outros dispositivos de backup/recuperação em outras regiões ou zonas após a conclusão do processo de instalação inicial.

Configurar backup e DR do Google Cloud

Nesta seção, você aprenderá as etapas necessárias para configurar o serviço de backup e DR e proteger suas cargas de trabalho.

Configurar uma conta de serviço

A partir da versão 11.0.2 (lançamento de backup e DR de dezembro de 2022), é possível usar uma única conta de serviço para executar o dispositivo de backup/recuperação para acessar buckets do Cloud Storage e proteger suas máquinas virtuais (VMs) do Compute Engine, não abordadas neste documento.

Papéis da conta de serviço

O Backup e DR do Google Cloud usa o Identity and Access Management (IAM) do Google Cloud para autorização e autenticação de conta de serviço e usuários. É possível usar papéis predefinidos para ativar vários recursos de backup. As duas mais importantes são as seguintes:

Operador do Cloud Storage de backup e DR: atribua esse papel às conta de serviço usadas por um dispositivo de backup/recuperação que se conecta aos buckets do Cloud Storage. O papel permite a criação de buckets do Cloud Storage para backups de snapshots do Compute Engine e o acesso a buckets com dados de backup baseados em agente atuais para restaurar cargas de trabalho.
Operador de backup e DR do Compute Engine: atribua esse papel às conta de serviço usadas por um dispositivo de backup/recuperação para criar snapshots do Persistent Disk para máquinas virtuais do Compute Engine. Além de criar snapshots, esse papel permite que a conta de serviço restaure VMs no mesmo projeto de origem ou em projetos alternativos.

Encontre sua conta de serviço visualizando a VM do Compute Engine que executa o dispositivo de backup/recuperação no projeto de consumidor/serviço e analisando o valor da conta de serviço listado na seção API e gerenciamento de identidade.

Para conceder as permissões adequadas aos seus dispositivos de backup/recuperação, acesse a página Gerenciamento de identidade e acesso e conceda os seguintes papéis do Identity and Access Management à sua conta de serviço do dispositivo de backup/recuperação.

Operador de backup e DR do Cloud Storage
Operador de DR e backup do Compute Engine (opcional)

Configurar pools de armazenamento

Os pools armazenam dados em locais físicos. Use o Persistent Disk para os dados mais recentes (de 1 a 14 dias) e o Cloud Storage para uma retenção de longo prazo (dias, semanas, meses e anos).

Cloud Storage

Crie um bucket padrão regional ou multirregional no local em que você precisa armazenar os dados de backup.

Siga estas instruções para criar um bucket do Cloud Storage:
1. Na página "Buckets do Cloud Storage", nomeie o bucket.
2. Selecione seu local de armazenamento.
3. Escolha uma classe de armazenamento: padrão, nearline ou coldline.
4. Se você escolher o armazenamento Nearline ou Coldline, defina o modo Controle de acesso como Detalhado. Para o armazenamento padrão, aceite o modo de controle de acesso padrão Uniforme.
5. Por fim, não configure opções de proteção de dados adicionais e clique em Criar.
Em seguida, adicione esse bucket ao appliance de backup/recuperação. Acesse o console de gerenciamento de backup e DR.
```
 https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/
 
```

Selecione o item de menu Gerenciar > Pools de armazenamento.

 https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#pools

Página do console de gerenciamento de backup e DR que mostra o menu "Gerenciar > Pools de armazenamento".

Clique na opção do lado direito + Adicionar OnVault Pool.
```
 https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#addonvaultpool
 
```
1. Digite um nome para o Nome do pool.
2. Escolha Google Cloud Storage para o Tipo de pool.
3. Selecione o dispositivo que você quer anexar ao bucket do Cloud Storage.
4. Digite o nome do bucket do Cloud Storage.
5. Clique em Salvar.

Pools de snapshots de disco permanente

Se você implantou o dispositivo de backup/recuperação com opções padrão ou SSD, o pool de snapshots do Persistent Disk será de 4 TB por padrão. Se os bancos de dados de origem ou os sistemas de arquivos exigirem um pool de tamanho maior, edite as configurações do dispositivo de backup/recuperação implantado, adicione um novo Persistent Disk e crie um novo pool personalizado ou configure outro pool padrão.

Acesse a página Gerenciar > Eletrodomésticos.

https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#clusters

Edite a instância do servidor de backup e clique em +Adicionar novo disco.
1. Dê um nome ao disco.
2. Selecione um tipo de disco Em branco.
3. Escolha "Padrão", "Equilibrada" ou "SSD", dependendo das suas necessidades.
4. Digite o tamanho do disco necessário.
5. Clique em Salvar.

Acesse a página Gerenciar > Dispositivos no console de gerenciamento de backup e DR.

https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#clusters

Clique com o botão direito do mouse no nome do dispositivo e selecione Configurar dispositivo no menu.
É possível adicionar o disco ao pool de snapshots atual (expansão) ou criar um novo pool. No entanto, não misture tipos de Persistent Disk no mesmo pool. Se expandir, clique no ícone superior direito do pool que deseja expandir.
Neste exemplo, você cria um novo pool com a opção Clique para adicionar pool. Depois de clicar nesse botão, aguarde 20 segundos para que a próxima página seja aberta.
Nesta etapa, configure o novo pool.
1. Dê um nome ao pool e clique no ícone verde + para adicionar o disco a ele.
2. Clique em Enviar.
3. Digite PROCEED em letras maiúsculas quando solicitado para confirmar que quer continuar.
4. Clique em Confirmar.
Agora o pool será expandido ou criado com o disco permanente.

Observação: nesse momento, não é possível mover, expandir ou excluir o Persistent Disk até remover as imagens de backup armazenadas nesse pool. Entre em contato com o Cloud Customer Care se precisar de ajuda. Caso contrário, feche a guia do navegador.

Configurar planos de backup

Os planos de backup permitem configurar dois elementos principais para fazer backup de qualquer banco de dados, VM ou sistema de arquivos. Os planos de backup incorporam perfis e modelos.

Os Perfis permitem definir quando fazer backup de algo e por quanto tempo os dados de backup serão mantidos.
Os modelos fornecem um item de configuração que permite decidir qual dispositivo de backup/recuperação e pool de armazenamento (Persistent Disk, Cloud Storage etc.) deve ser usado para a tarefa de backup.

criar um perfil

No console de gerenciamento de backup e DR, acesse a página Planos de backup > Perfis.

https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#manageprofiles

Dois perfis já serão criados. É possível usar um perfil para snapshots da VM do Compute Engine e editar o outro perfil para backups da Solução Bare Metal. É possível ter vários perfis, o que é útil se você estiver fazendo backup de muitos bancos de dados que exigem diferentes níveis de disco para backup. Por exemplo, é possível criar um pool para SSD (melhor desempenho) e outro para discos permanentes padrão (desempenho padrão). Para cada perfil, é possível escolher um pool de snapshots diferente.
Clique com o botão direito do mouse no perfil padrão chamado LocalProfile e selecione Editar.
Faça as mudanças a seguir:
1. Atualize as configurações de Perfis com um nome e uma descrição de perfil mais significativos. É possível especificar o nível do disco a ser usado, onde os bucket do Cloud Storage estão localizados ou outras informações que expliquem a finalidade desse perfil.
2. Altere o pool de snapshots para o novo pool expandido ou criado anteriormente.
3. Selecione um pool do OnVault (bucket do Cloud Storage) para esse perfil.
4. Clique em Salvar perfil.

Criar um modelo

No console de gerenciamento de backup e DR, acesse o menu Planos de backup > Modelos.

https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#managetemplates

Clique em +Criar modelo.
1. Dê um nome ao modelo.
2. Selecione Sim em Permitir modificações de configurações de política.
3. Adicione uma descrição deste modelo.
4. Clique em Salvar modelo.
No seu modelo, configure o seguinte:
1. Na seção Políticas à direita, clique em +Adicionar.
2. Forneça um nome para a política.
3. Marque a caixa de seleção dos dias em que a política será executada ou deixe o padrão como Todos os dias.
4. Edite a janela dos jobs que você quer executar nesse período.
5. Selecione um horário de retenção.
6. Clique em Configurações avançadas da política.
Se você quiser fazer backups de registros arquivados com frequência regular (por exemplo, a cada 15 minutos) e replicar os registros arquivados no Cloud Storage, será necessário ativar as seguintes configurações de política:
1. Defina Truncate/Purge Log after Backup como Truncate se você quiser.
2. Defina Enable Database Log Backup como Yes se quiser.
3. Defina RPO (Minutes) como o intervalo de backup do registro do arquivo.
4. Defina Período de retenção do backup de registros (em dias) como o período de retenção que você quer.
5. Defina Replicate Logs (Use Streamsnap Technology) como No.
6. Defina Enviar registros para o pool OnVault como Sim se quiser enviar registros para o bucket do Cloud Storage. Caso contrário, selecione Não.
7. Clique em Salvar alterações.
Clique em Atualizar política para salvar as alterações.
Para OnVault à direita, execute as seguintes ações:
1. Clique em +Add.
2. Adicione o nome da política.
3. Defina a Retenção em dias, semanas, meses ou anos.
4. Clique em Atualizar política.
(Opcional) Se você precisar adicionar mais opções de retenção, crie outras políticas para retenção semanal, mensal e anual. Para adicionar outra política de retenção, siga estas etapas:
1. Em OnVault à direita, clique em +Adicionar.
2. Adicione um nome de política.
3. Altere o valor de Nestes dias para o dia em que você quer acionar esse job.
4. Defina a Retenção em Dias, Semanas, Meses ou Anos.
5. Clique em Atualizar política.
Clique em Salvar modelo. No exemplo a seguir, você verá uma política de snapshot que retém backups por três dias no nível do Persistent Disk, sete dias para jobs do OnVault e quatro semanas no total. O backup semanal funciona nas noites de sábado.

Observação: no backup e DR, os jobs diários e semanais do OnVault não são diferentes. Um job semanal é simplesmente o job diário enviado pelo Backup e DR ao Cloud Storage. O job semanal recebe um valor de retenção adicional para que os dados não expirem. O backup e a DR mantêm as imagens dos sábados à noite no Cloud Storage por oito dias e quatro vezes por semanas.

Fazer backup de um database Oracle

A arquitetura de backup e DR do Google Cloud oferece backup incremental permanente do aplicativo para o Google Cloud e recuperação e clonagem instantâneas para bancos de dados Oracle de vários terabytes.

O Backup e DR do Google Cloud usa as seguintes APIs da Oracle:

API RMAN image copy: é muito mais rápido restaurar uma cópia de imagem de um arquivo de dados porque a estrutura física do arquivo de dados já existe. A diretiva BACKUP AS COPY do Recovery Manager (RMAN) cria cópias de imagens para todos os arquivos de dados de todo o banco de dados e mantém o formato do arquivo de dados.
API ASM e CRS: use a API de gerenciamento automático de armazenamento (ASM, na sigla em inglês) e serviços prontos de cluster (CRS, na sigla em inglês) para gerenciar o grupo de discos de backup do ASM.
API RMAN Archive Log Backup: essa API gera registros do arquivo, faz backup deles em um disco de preparo e limpa-os do local do arquivo de produção.

Configurar os hosts da Oracle

As etapas para configurar os hosts do Oracle incluem a instalação do agente, a adição dos hosts ao backup e DR, a configuração dos hosts e a descoberta dos bancos de dados da Oracle. Depois que tudo estiver pronto, faça backups do banco de dados Oracle em backup e DR.

Instalar o agente de backup

A instalação do agente de backup e DR é relativamente simples. Você só precisa instalar o agente na primeira vez que usar o host. Os upgrades subsequentes poderão ser feitos na interface do usuário de backup e DR no console do Google Cloud. É preciso fazer login como usuário root ou em uma sessão autenticada sudo para executar uma instalação de agente. Não é necessário reiniciar o host para concluir a instalação.

Faça o download do agente de backup na interface do usuário ou na página Manage > Appliances.
```
https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#clusters
```
Clique com o botão direito do mouse no nome do dispositivo de backup/recuperação e selecione Configurar appliance. Uma nova janela do navegador será aberta.
Clique no ícone do Linux 64 bits para fazer o download do agente de backup para o computador que hospeda a sessão do navegador. Use o scp (cópia segura) para mover o arquivo do agente transferido por download para os hosts do Oracle para instalação.
Como alternativa, é possível armazenar o agente de backup em um bucket do Cloud Storage, ativar downloads e usar os comandos wget ou curl para fazer o download diretamente para os hosts do Linux.
```
curl -o agent-Linux-latestversion.rpm https://storage.googleapis.com/backup-agent-images/connector-Linux-11.0.2.9595.rpm
```

Use o comando rpm -ivh para instalar o agente de backup.

É muito importante copiar a chave secreta gerada automaticamente. Usando o console de gerenciamento de backup e DR, é preciso adicionar a chave secreta aos metadados do host.

A saída deste comando é semelhante a:

[oracle@host `~]# sudo rpm -ivh agent-Linux-latestversion.rpm
Verifying... ################################# [100%]
Preparing... ################################# [100%]
Updating / installing…
  1:udsagent-11.0.2-9595 ################################# [100%]
Created symlink /etc/systemd/system/multi-user.target.wants/udsagent.service → /usr/lib/systemd/system/udsagent.service.
Action Required:
-- Add this host to Backup and DR management console to backup/recover workloads from/to this host. You can do this by navigating to Manage->Hosts->Add Host on your management console.
-- A secret key is required to complete this process. Please use b010502a8f383cae5a076d4ac9e868777657cebd0000000063abee83 (valid for 2 hrs) to register this host.
-- A new secret key can be generated later by running: '/opt/act/bin/udsagent secret --reset --restart

Se você usar o comando iptables, abra as portas do firewall do agente de backup (TCP 5106) e dos serviços da Oracle (TCP 1521):

sudo iptables -A INPUT -p tcp --dport 5106 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 1521 -j ACCEPT
sudo firewall-cmd --permanent --add-port=5106/tcp
sudo firewall-cmd --permanent --add-port=1521/tcp
sudo firewall-cmd --reload

Adicionar hosts a backup e DR

No console de gerenciamento de backup e DR, acesse Manage > Hosts.
```
https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#hosts
```
1. Clique em +Adicionar host.
2. Adicione o nome do host.
3. Adicione um endereço IP para o host e clique no botão + para confirmar a configuração.
4. Clique nos appliances em que você quer adicionar o host.
5. Cole a chave secreta. Essa tarefa precisa ser executada menos de duas horas depois de instalar o agente de backup e gerar a chave secreta.
6. Clique em Adicionar para salvar o host.
Se você receber um erro ou uma mensagem de Sucesso parcial, tente as seguintes soluções alternativas:
1. A chave secreta da criptografia do agente de backup pode ter expirado. Se você não tiver adicionado a chave secreta ao host até duas horas após a criação. Você pode gerar uma nova chave secreta no host Linux usando a seguinte sintaxe de linha de comando:
```
/opt/act/bin/udsagent secret --reset --restart
```
2. O firewall que permite a comunicação entre o dispositivo de backup/recuperação e o agente instalado no host pode não estar configurado corretamente. Siga as etapas para abrir as portas do firewall do agente de backup e dos serviços do Oracle.
3. A configuração do Network Time Protocol (ntp) para seus hosts do Linux pode estar configurada incorretamente. Verifique se as configurações de NTP estão corretas.
Após corrigir o problema, o Status do certificado vai mudar de N/A para Válido.

Configurar os hosts

No console de gerenciamento de backup e DR, acesse Manage > Hosts.

https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#hosts

Clique com o botão direito do mouse no host do Linux em que você quer fazer backup dos bancos de dados Oracle e selecione Editar.
Clique em Como preparar o formato do disco e selecione NFS.

Observação :se você preferir usar discos de preparo do ASM (também conhecidos como backup em discos formatados do ASM), selecione Bloquear para a configuração Formato do disco de preparo.
Role a tela para baixo até a seção Aplicativos descobertos e clique em Descobrir aplicativos para iniciar o processo de descoberta de appliance para agente.
Clique em Discover para iniciar o processo. O processo de descoberta leva até cinco minutos. Quando concluído, os sistemas de arquivos e os bancos de dados Oracle descobertos aparecem na janela de aplicativos.
Clique em Salvar para atualizar as alterações nos hosts.

Preparar o host Linux

Ao instalar pacotes de utilitários de iSCSI ou NFS no host baseado em SO Linux, é possível mapear um disco de preparo para um dispositivo que grava os dados de backup. Use os seguintes comandos para instalar os utilitários iSCSI e NFS. Embora seja possível usar um ou ambos os conjuntos de utilitários, esta etapa garante que você tenha o que precisa quando precisar.

Dica: quando devo usar iSCSI, NFS ou Oracle Direct NFS (dNFS)?

Use iSCSI quando quiser salvar seu backup em um disco de preparo de backup baseado em bloco (pense em backup no sistema de arquivos) ou quando precisar armazenar o formato de disco de preparo de backup em um grupo de discos ASM (em que você usa o dispositivo de backup/recuperação para armazenar, criar e gerenciar backups).
Use o NFS, também conhecido como NFS do kernel, para aumentar o desempenho de backup e restauração. É possível aproveitar várias sessões TCP com NFS, mas este método de armazenamento de arquivos só é compatível com a opção de disco de preparo de backup do sistema de arquivos.
Use o Direct NFS (dNFS) quando quiser implantar o aprimoramento do Oracle para NFS, que é mais rápido que o NFS padrão e melhora a capacidade de backup e restauração. No entanto, o dNFS só é compatível com a opção de disco de preparo de backup do sistema de arquivos. A configuração do dNFS exige que você encerre o banco de dados para permitir que a configuração entre em vigor após a reinicialização.

Para instalar os utilitários iSCSI, execute o seguinte comando:
```
sudo yum install -y iscsi-initiator-utils
```
Para instalar os utilitários NFS, execute o seguinte comando:
```
sudo yum install -y nfs-utils
```
Preparar o database Oracle

Neste guia, pressupomos que você já tenha uma instância e um banco de dados Oracle configurados e configurados. O Backup e DR do Google Cloud oferece suporte à proteção de bancos de dados executados em sistemas de arquivos, ASM, clusters de aplicativos reais (RAC, na sigla em inglês) e muitas outras configurações. Para mais informações, consulte Backup e DR para bancos de dados do Oracle.

Você precisa configurar alguns itens antes de iniciar o job de backup. Algumas delas são opcionais. No entanto, recomendamos as configurações a seguir para um desempenho ideal:

Use o SSH para se conectar ao host do Linux e faça login como usuário Oracle com privilégios su.

Defina o ambiente Oracle como sua instância específica:

. oraenv
ORACLE_SID = [ORCL] ?
The Oracle base remains unchanged with value /u01/app/oracle

Conecte-se ao SQL*Plus com a conta sysdba:
```
sqlplus / as sysdba
```

Use os seguintes comandos para ativar o modo ARCHIVELOG. A saída deste comando é semelhante a:

SQL> shutdown

Database closed.
Database dismounted.
ORACLE instance shut down.

SQL> startup mount

ORACLE instance started.

Total System Global Area 2415918600 bytes
Fixed Size 9137672 bytes
Variable Size 637534208 bytes
Database Buffers 1761607680 bytes
Redo Buffers 7639040 bytes
Database mounted.

SQL> alter database archivelog;

Database altered.

SQL> alter database open;

Database altered.

SQL> archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /u01/app/oracle/product/19c/dbhome_1/dbs/arch
Oldest online log sequence 20
Next log sequence to archive 22
Current log sequence 22

SQL> alter pluggable database ORCLPDB save state;

Pluggable database altered.

Configure o NFS direto para o host Linux:

cd $ORACLE_HOME/rdbms/lib
make -f [ins_rdbms.mk](http://ins_rdbms.mk/) dnfs_on

Configure o acompanhamento de alterações em blocos. Primeiro, verifique se ele está ativado ou desativado. O exemplo a seguir mostra o acompanhamento de alterações em blocos como desativado:

SQL> select status,filename from v$block_change_tracking;

STATUS     FILENAME
---------- ------------------------------------------------------------------
DISABLED

Emita o seguinte comando ao usar o ASM:

SQL> alter database enable block change tracking using file +ASM_DISK_GROUP_NAME/DATABASE_NAME/DBNAME.bct;

Database altered.

Emita o seguinte comando ao usar um sistema de arquivos:

SQL> alter database enable block change tracking using file '$ORACLE_HOME/dbs/DBNAME.bct';;

Database altered.

Verifique se o rastreamento de alterações de bloqueio está ativado:

SQL> select status,filename from v$block_change_tracking;

STATUS     FILENAME
---------- ------------------------------------------------------------------
ENABLED    +DATADG/ORCL/CHANGETRACKING/ctf.276.1124639617

Proteger um database Oracle

No console de gerenciamento de backup e DR, acesse a página Gerenciador de apps > Aplicativos.

https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#applications

Clique com o botão direito do mouse no nome do banco de dados Oracle que você quer proteger e selecione Gerenciar plano de backup no menu.
Selecione o modelo e o perfil que você quer usar e clique em Aplicar plano de backup.
Quando solicitado, defina as Configurações avançadas específicas para o Oracle e o RMAN necessárias para a configuração. Quando terminar, clique em Aplicar plano de backup.

Número de canais, por exemplo, o padrão é 2. Portanto, se você tiver um número maior de núcleos de CPU, aumente o número de canais para operações de backup paralelas e defina esse número como um número maior.

Para saber mais sobre configurações avançadas, consulte Configurar detalhes e configurações do aplicativo para bancos de dados Oracle.

Caixa de diálogo de backup e DR que mostra como selecionar a conversão do formato ASM para o formato do sistema de arquivos.

Além dessas configurações, é possível alterar o protocolo que o disco de preparo usa para mapear o disco do Backup Appliance para o host. Acesse a página Manage > Hosts e selecione o host que você quer Editar. Marque a opção de Preparação do formato do disco para convidado. Por padrão, o formato Bloco é selecionado, o que mapeia o disco de preparo via iSCSI. Caso contrário, ele pode ser alterado para NFS e o disco de preparo vai usar o protocolo NFS.

As configurações padrão dependem do formato do database. Se você usar o ASM, o sistema usará o iSCSI para enviar um grupo de discos do ASM ao backup. Se você usar um sistema de arquivos, ele utiliza o iSCSI para enviar o backup a um sistema de arquivos. Se você quiser usar NFS ou NFS direto (dNFS), altere as configurações de Hosts do disco de preparo para NFS. Em vez disso, se você usar a configuração padrão, todos os discos de preparo de backup vão usar o formato de armazenamento em blocos e o iSCSI.

Iniciar o job de backup

No console de gerenciamento de backup e DR, acesse a página Gerenciador de apps > Aplicativos.

https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#applications

Clique com o botão direito do mouse no banco de dados Oracle que você quer proteger e escolha Gerenciar plano de backup no menu.
Clique no menu Instantâneo à direita e clique em Executar agora. Isso inicia um job de backup sob demanda.
Para monitorar o status do trabalho de backup, acesse o menu Monitorar > Jobs e veja o status da tarefa. Pode levar de 5 a 10 segundos para um job aparecer na lista. Veja a seguir um exemplo de um job em execução:
Quando um job é bem-sucedido, você pode usar metadados para visualizar os detalhes de um job específico.
- Aplique filtros e adicione termos de pesquisa para encontrar vagas de seu interesse. O exemplo a seguir usa os filtros Succeeded e Past Day, além de uma pesquisa pelo host test1.
Para ver mais detalhes sobre um job específico, clique nele na coluna Job. Uma nova janela será aberta. Como mostrado no exemplo a seguir, cada job de backup captura uma grande quantidade de informações.

Ativar e restaurar um database Oracle

O backup e a DR do Google Cloud têm vários recursos diferentes para acessar uma cópia de um banco de dados Oracle. Os dois métodos principais são os seguintes:

Ativações compatíveis com apps
Restaurações (ativação e migração e restauração tradicional)

Cada um desses métodos tem benefícios diferentes. Portanto, é necessário selecionar qual você quer usar dependendo do caso de uso, dos requisitos de desempenho e de quanto tempo você precisa manter a cópia do banco de dados. As seções a seguir contêm algumas recomendações para cada recurso.

Ativações compatíveis com apps

Use ativações para ter acesso rápido a uma cópia virtual de um database Oracle. É possível configurar uma montagem quando o desempenho não é crítico e a cópia do banco de dados permanece por apenas algumas horas ou alguns dias.

O principal benefício de uma montagem é que ela não consome grandes quantidades de armazenamento adicional. Em vez disso, a montagem usa um snapshot do pool de discos de backup, que pode ser um pool de snapshots em um Persistent Disk ou um pool do OnVault no Cloud Storage. Ele minimiza o tempo de acesso aos dados porque eles não precisam ser copiados antes. O disco de backup processa todas as leituras, e um disco no pool de snapshots armazena todas as gravações. Como resultado, é rápido acessar cópias virtuais e não substituir a cópia do disco de backup. As montagens são ideais para atividades de desenvolvimento, teste e DBA em que as alterações ou atualizações de esquema precisam ser validadas antes de serem lançadas na produção.

Ativar um database Oracle

No console de gerenciamento de backup e DR, acesse a página Backup e recuperação > Recuperar.

https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#recover/selectapp

Na lista Aplicativo, encontre o banco de dados que você quer ativar, clique com o botão direito do mouse no nome dele e clique em Próximo:
A Visualização de ampliação da linha do tempo aparece e mostra todas as imagens pontuais disponíveis. Também é possível rolar para trás e conferir imagens de retenção de longo prazo caso elas não apareçam na visualização O sistema seleciona a imagem mais recente por padrão.
Se preferir ter uma visualização em tabela das imagens pontuais, clique na opção Tabela para alterar a visualização:
Encontre a imagem desejada e selecione Ativar:
Escolha as Opções de aplicativo do database ativado.
1. Selecione Target Host no menu suspenso. Os hosts aparecerão nesta lista se você os tiver adicionado anteriormente.
2. (Opcional) Digite um rótulo.
3. No campo SID do banco de dados de destino, insira o identificador do banco de dados de destino.
4. Defina o Nome de usuário como Oracle. Esse nome se torna o nome de usuário do SO para autenticação.
5. Digite o Diretório principal da Oracle. Neste exemplo, use /u01/app/oracle/product/19c/dbhome_1.
6. Se você configurar os registros do banco de dados para fazer backup, o Tempo de avanço fica disponível. Clique no seletor de relógio/tempo e escolha o ponto de avanço.
7. A opção Restaurar com recuperação é ativada por padrão. Essa opção monta e abre o banco de dados para você.
Quando terminar de inserir as informações, clique em Enviar para iniciar o processo de montagem.

Monitorar o progresso e o sucesso do job

Para monitorar o job em execução, acesse a página Monitorar > Jobs.
```
https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#jobs
```
A página mostra o status e o tipo de job.
Quando o job de montagem for concluído, será possível visualizar os detalhes dele clicando no Número do job:

Para ver os processos pmon para o SID que você criou, faça login no host de destino e emita o comando ps -ef |grep pmon. No exemplo de saída a seguir, o banco de dados SCHTEST está operacional e tem o ID de processo 173953.

[root@test2 ~]# ps -ef |grep pmon oracle 1382 1 0 Dec23 ? 00:00:28 asmpmon+ASM oracle 56889 1 0 Dec29 ? 00:00:06 ora_pmon_ORCL oracle 173953 1 0 09:51 ? 00:00:00 ora_pmon_SCHTEST root 178934 169484 0 10:07 pts/0 00:00:00 grep --color=auto pmon

Unmount an Oracle database

After you finish using the database, you should unmount and delete the database. There are two methods to find a mounted database:

Go to App Manager > Active Mounts page.
```
https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#activemounts
```
Esta página contém uma visão global de todos os aplicativos montados (sistemas de arquivos e bancos de dados) atualmente em uso.
1. Clique com o botão direito do mouse na montagem que você quer limpar e selecione Unmount and Delete no menu. Essa ação não excluirá os dados de backup. Isso só remove do host de destino o banco de dados montado virtualmente e o disco de cache de snapshots que continha as gravações armazenadas no banco de dados.
Acesse a página App Manager > Aplicativos.
```
 https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#applications
 
```
1. Clique com o botão direito do mouse no app de origem (database) e selecione Acessar.
2. Na rampa à esquerda, há um círculo cinza com um número dentro, que indica o Número de suportes ativos a partir deste momento. Clique na imagem para abrir um novo menu.
3. Clique em Ações.
4. Clique em Desconectar e excluir.
5. Clique em Enviar e confirme essa ação na próxima tela.
6. Alguns minutos depois, o sistema remove o banco de dados do host de destino, limpa e remove todos os discos. Essa ação libera qualquer espaço em disco no pool de snapshots que está sendo usado para gravações no disco de refazer para montagens ativas.
É possível monitorar jobs desconectados como qualquer outro job. Acesse o menu Monitorar > Jobs para monitorar o progresso do job que está sendo desmontado e confirmar se ele foi concluído.
```
 https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#jobs
 
```
Se você excluir acidentalmente o banco de dados Oracle manualmente ou encerrá-lo antes de executar o job Unmount and Delete, execute o job Unmount and Delete novamente e selecione a opção Force Unmount na tela de confirmação. Esta ação força a remoção do disco de preparação para refazer do host de destino e exclui o disco do pool de snapshots.

Restaurações

As restaurações são usadas para recuperar bancos de dados de produção quando ocorre um problema ou uma corrupção e é necessário copiar todos os arquivos do banco de dados de uma cópia de backup para um host local. Normalmente, uma restauração é feita após um evento de tipo de desastre ou para cópias de teste que não sejam de produção. Nesse caso, os clientes normalmente precisam esperar que você copie os arquivos anteriores de volta para o host de origem antes de reiniciar os bancos de dados deles. No entanto, o backup e a DR do Google Cloud também são compatíveis com um recurso de restauração (copiar arquivos e iniciar o banco de dados) e um recurso de montagem e migração, em que você monta o banco de dados (o tempo de acesso é rápido) e pode copiar arquivos de dados para a máquina local enquanto o banco de dados está montado e acessível. O recurso de montagem e migração é útil para cenários de baixo objetivo de tempo de recuperação (RTO, na sigla em inglês).

Ativar e migrar

A recuperação com base em migração e ativação tem duas fases:

Fase 1: a fase de montagem de restauração fornece acesso instantâneo ao banco de dados começando pela cópia montada.
Fase 2: a fase de migração da restauração migra o banco de dados para o local de armazenamento de produção enquanto ele está on-line.

Ativação de restauração: fase 1

Esta fase oferece acesso instantâneo ao banco de dados a partir de uma imagem selecionada apresentada pelo dispositivo de backup/recuperação.

Uma cópia da imagem de backup selecionada é mapeada para o servidor de banco de dados de destino e apresentada ao ASM ou à camada do sistema de arquivos com base no formato da imagem de backup do banco de dados de origem.
Use a API RMAN para realizar as seguintes tarefas:
- Restaure o arquivo de controle e o arquivo de registro de refazer para o arquivo de controle local especificado e o local do arquivo de refazer (grupo de discos ou sistema de arquivos ASM).
- Alterne o banco de dados para a cópia da imagem apresentada pelo dispositivo de backup/recuperação.
- Avançar todos os registros de arquivo disponíveis para o ponto de recuperação especificado.
- Abra o database no modo de leitura e gravação.
O banco de dados é executado a partir da cópia mapeada da imagem de backup apresentada pelo dispositivo de backup/recuperação.
Os arquivos de controle e de registro de refazer do banco de dados são colocados no local de armazenamento de produção local selecionado (grupo de discos ou sistema de arquivos do ASM) no destino.
Após uma operação de montagem de restauração bem-sucedida, o banco de dados fica disponível para operações de produção. Use a API de movimentação de arquivos de dados on-line da Oracle para mover os dados de volta para o local de armazenamento de produção (grupo de discos ou sistema de arquivos do ASM) enquanto o banco de dados e o aplicativo estiverem em execução.

Ativação de migração: fase 2

Move o arquivo de dados do database on-line para o armazenamento de produção:

A migração de dados é executada em segundo plano. Use a API de movimentação de arquivos de dados on-line da Oracle para migrar os dados.
Mova os arquivos de dados da cópia apresentada de backup e DR da imagem de backup para o armazenamento do banco de dados de destino selecionado (grupo de discos ou sistema de arquivos do ASM).
Quando o job de migração é concluído, o sistema remove e desmapeia a cópia da imagem de backup de backup e DR apresentada (grupo de discos ASM ou sistema de arquivos) do destino e o banco de dados é executado no armazenamento de produção.

Para mais informações sobre a recuperação de ativação e migração, consulte: Montar e migrar uma imagem de backup do Oracle para recuperação instantânea para qualquer destino.

Restaurar um database Oracle

No console de gerenciamento de backup e DR, acesse a página Backup e recuperação > Recuperar.

https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#recover/selectapp

Na lista Aplicativo, clique com o botão direito do mouse no nome do banco de dados que você quer restaurar e selecione Próximo:
A Visualização de rampa da linha do tempo aparece, mostrando todas as imagens pontuais disponíveis. Também é possível rolar para trás se precisar conferir as imagens de retenção de longo prazo que não aparecem na ampliação. O sistema sempre seleciona a imagem mais recente por padrão.

Para restaurar uma imagem, clique no menu Ativar e selecione Restaurar:
Escolha as opções de restauração.
1. Selecione o Tempo de avanço. Clique no relógio e escolha o momento desejado.
2. Digite o nome de usuário que você planeja usar na Oracle.
3. Se o sistema usa autenticação de database, insira uma senha.
4. Para iniciar o job, clique em Enviar.
Digite PERDA DE DADOS para confirmar que você quer substituir o banco de dados de origem e clique em Confirmar.

Monitorar o progresso e o sucesso do job

Para monitorar o job, acesse a página Monitorar > Jobs.

https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#jobs

Quando o job for concluído, clique no Número do job para revisar os detalhes e metadados dele.

Proteger o database restaurado

Quando o job de restauração do banco de dados é concluído, o sistema não faz backup do banco de dados automaticamente após a restauração. Em outras palavras, quando você restaura um banco de dados que já tinha um plano de backup, esse plano não é ativado por padrão.

Para verificar se o plano de backup não está em execução, acesse a página Gerenciador de apps > Aplicativos.
```
https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#applications
```
Encontre o database restaurado na lista. O ícone de proteção muda de verde para amarelo, o que indica que o sistema não está programado para executar jobs de backup do banco de dados.
Para proteger o banco de dados restaurado, procure na coluna Aplicativo o banco de dados a ser protegido. Clique com o botão direito do mouse no nome do banco de dados e selecione Gerenciar plano de backup.
Reativar o job de backup programado para o database restaurado.
1. Clique no menu Aplicar e selecione Ativar.
2. Confirme as configurações avançadas da Oracle e clique em Ativar plano de backup.

Solução de problemas e otimização

Esta seção fornece algumas dicas úteis para solucionar problemas de backups da Oracle, otimizar o sistema e considerar ajustes nos ambientes RAC e Data Guard.

Solução de problemas de backup da Oracle

As configurações do Oracle contêm várias dependências para garantir que a tarefa de backup seja bem-sucedida. As etapas a seguir oferecem várias sugestões para configurar instâncias, listeners e bancos de dados da Oracle para garantir o sucesso.

Para verificar se o listener do Oracle do serviço e da instância que você quer proteger está configurado e em execução, emita o comando lsnrctl status:

[oracle@test2 lib]$ lsnrctl status

LSNRCTL for Linux: Version 19.0.0.0.0 - Production on 29-DEC-2022 07:43:37

Copyright (c) 1991, 2021, Oracle. All rights reserved.

Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 19.0.0.0.0 - Production
Start Date                23-DEC-2022 20:34:17
Uptime                    5 days 11 hr. 9 min. 20 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   /u01/app/19c/grid/network/admin/listener.ora
Listener Log File         /u01/app/oracle/diag/tnslsnr/test2/listener/alert/log.xml
Listening Endpoints Summary...
 (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=test2.localdomain)(PORT=1521)))
 (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))
Services Summary...
Service "+ASM" has 1 instance(s).
 Instance "+ASM", status READY, has 1 handler(s) for this service...
Service "+ASM_DATADG" has 1 instance(s).
 Instance "+ASM", status READY, has 1 handler(s) for this service...
Service "ORCL" has 1 instance(s).
 Instance "ORCL", status READY, has 1 handler(s) for this service...
Service "ORCLXDB" has 1 instance(s).
 Instance "ORCL", status READY, has 1 handler(s) for this service...
Service "f085620225d644e1e053166610ac1c27" has 1 instance(s).
 Instance "ORCL", status READY, has 1 handler(s) for this service...
Service "orclpdb" has 1 instance(s).
 Instance "ORCL", status READY, has 1 handler(s) for this service...
The command completed successfully

Verifique se você configurou o database Oracle no modo ARCHIVELOG. Se o banco de dados for executado em um modo diferente, você poderá ver jobs com falha com a mensagem do código do erro 5556 da seguinte maneira:

Caixa de diálogo "Backup e DR" que mostra os detalhes do job que contêm o código de erro 5556.

export ORACLE_HOME=ORACLE_HOME_PATH
export ORACLE_SID=DATABASE_INSTANCE_NAME
export PATH=$ORACLE_HOME/bin:$PATH

sqlplus / as sysdba
SQL> set tab off
SQL> archive log list;

Database log mode             Archive Mode
Automatic archival            Enabled
Archive destination           +FRA
Oldest online log sequence    569
Next log sequence to archive  570
Current log sequence          570

Ative o rastreamento de alterações de bloqueio no database Oracle. Embora isso não seja obrigatório para a solução funcionar, ativar o rastreamento de alterações de bloco evita a necessidade de executar uma quantidade significativa de trabalho de pós-processamento para calcular blocos alterados e ajuda a reduzir o tempo das tarefas de backup:
```
SQL> select status,filename from v$block_change_tracking;

STATUS     FILENAME
---------- ------------------------------------------------------------------
ENABLED    +DATADG/ORCL/CHANGETRACKING/ctf.276.1124639617
```

Verifique se o database usa o spfile:

sqlplus / as sysdba

SQL> show parameter spfile

NAME               TYPE        VALUE
------------------ ----------- ------------
spfile             string      +DATA/ctdb/spfilectdb.ora

Ative Direct NFS (dnfs) para os hosts de database Oracle. Não é obrigatório, mas se você precisa do método mais rápido para fazer backup e restaurar os bancos de dados Oracle, o dnfs é a melhor opção. Para melhorar ainda mais a capacidade, é possível alterar o disco de preparo por host e ativar o dnfs para o Oracle.

Configure tnsnames para resolução de hosts de database Oracle. Se você não incluir essa configuração, os comandos do RMAN geralmente falham. Veja a seguir uma amostra da saída:

[oracle@test2 lib]$ tnsping ORCL

TNS Ping Utility for Linux: Version 19.0.0.0.0 - Production on 29-DEC-2022 07:55:18

Copyright (c) 1997, 2021, Oracle. All rights reserved.

Used parameter files:

Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = test2.localdomain)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = ORCL)))
OK (0 msec)

O campo SERVICE_NAME é importante para configurações de RAC. O nome do serviço representa o alias usado para divulgar o sistema aos recursos externos que se comunicam com o cluster. Nas opções Detalhes e configurações do banco de dados protegido, use a Configuração avançada do nome do serviço Oracle. Digite o nome do serviço específico que você quer usar nos nós que executam o job de backup.

O database Oracle usa o nome do serviço apenas para autenticação do database. O database não usa o nome do serviço para autenticação do SO. Por exemplo, o nome do banco de dados pode ser CLU1_S e o nome da instância pode ser CLU1_S.
- Se o nome do serviço Oracle não estiver listado, adicione a seguinte entrada para criar uma entrada de nome de serviço nos servidores do arquivo tnsnames.ora localizado em $ORACLE_HOME/network/admin ou $GRID_HOME/network/admin:
```
CLU1_S =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = )(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = CLU1_S)
) )
```
- Se o arquivo tnsnames.ora estiver em um local não padrão, informe o caminho absoluto para o arquivo na página Detalhes e configurações do aplicativo descrita em Configurar detalhes e configurações do aplicativo para bancos de dados Oracle.
- Verifique se você configurou a entrada do nome do serviço para o banco de dados corretamente. Faça login no Oracle Linux e configure o ambiente da Oracle:
```
TNS_ADMIN=TNSNAMES.ORA_FILE_LOCATION
tnsping CLU1_S
```
- Revise a conta de usuário do banco de dados para garantir uma conexão bem-sucedida com o aplicativo de Backup e DR:
```
sqlplus act_rman_user/act_rman_user@act_svc_dbstd as sysdba
```
- Na página Detalhes e configurações do aplicativo descrita em Detalhes e configurações do aplicativo para bancos de dados Oracle, digite o nome do serviço que você criou (CLU1_S) no campo Nome do serviço Oracle:
O código de erro 870 diz que "não há suporte para backups do ASM com ASM em discos de preparo NFS ". Se você receber esse erro, não tem a configuração correta definida em Detalhes e configurações para a instância que quer proteger. Nessa configuração incorreta, o host usa o NFS para o disco de preparo, mas o banco de dados de origem é executado no ASM.

Para corrigir esse problema, defina o campo Convert ASM Format to Filesystem Format como Yes. Depois de alterar essa configuração, execute novamente o job de backup.

O código do erro 15 informa ao sistema de backup e DR a mensagem "Não foi possível se conectar ao host de backup". Esse erro indica um destes três problemas:

O firewall entre o dispositivo de backup/recuperação e o host em que o agente foi instalado não permite a porta TCP 5106 (a porta de detecção do agente).
Você não instalou o agente.
O agente não está em execução.

Para corrigir esse problema, redefina as configurações do firewall conforme necessário e verifique se o agente está funcionando. Depois de corrigir a causa subjacente, execute o comando service udsagent status. O exemplo de saída a seguir mostra que o serviço do agente de backup e DR está sendo executado corretamente:

[root@test2 ~]# service udsagent status
Redirecting to /bin/systemctl status udsagent.service
udsagent.service - Google Cloud Backup and DR service
Loaded: loaded (/usr/lib/systemd/system/udsagent.service; enabled; vendor preset: disabled)
Active: active (running) since Wed 2022-12-28 05:05:45 UTC; 2 days ago
Process: 46753 ExecStop=/act/initscripts/udsagent.init stop (code=exited, status=0/SUCCESS)
Process: 46770 ExecStart=/act/initscripts/udsagent.init start (code=exited, status=0/SUCCESS)
Main PID: 46789 (udsagent)
Tasks: 8 (limit: 48851)
Memory: 74.0M
CGroup: /system.slice/udsagent.service
 ├─46789 /opt/act/bin/udsagent start   
 └─60570 /opt/act/bin/udsagent start

Dec 30 05:11:30 test2 su[150713]: pam_unix(su:session): session closed for user oracle
Dec 30 05:11:30 test2 su[150778]: (to oracle) root on none

As mensagens de registro dos seus backups podem ajudar você a diagnosticar problemas. Acesse os registros no host de origem em que os jobs de backup são executados. Para os backups do banco de dados Oracle, há dois arquivos de registros principais disponíveis no diretório /var/act/log:
- UDSAgent.log: registro do agente de DR e backup do Google Cloud que registra solicitações de API, estatísticas de jobs em execução e outros detalhes.
- SID_rman.log: registro do RMAN do Oracle que registra todos os comandos do RMAN.

Considerações adicionais sobre a Oracle

Ao implementar backup e DR para bancos de dados Oracle, esteja ciente das seguintes considerações ao implantar o Data Guard e o RAC.

Considerações sobre o Data Guard

É possível fazer backup dos nós principal e de espera do Data Guard. No entanto, se você optar por proteger os bancos de dados apenas dos nós de espera, será necessário usar a autenticação do banco de dados Oracle, em vez da autenticação do SO, ao fazer backup do banco de dados.

Considerações sobre a RAC

A solução de backup e DR não aceita backup simultâneo de vários nós em um banco de dados RAC se o disco de preparo está configurado no modo NFS. Se o sistema exigir backup simultâneo de vários nós RAC, use Block (iSCSI) como o modo de disco de preparo e configure por host.

Para um banco de dados Oracle RAC usando ASM, coloque o arquivo de controle de snapshot nos discos compartilhados. Para verificar essa configuração, conecte-se ao RMAN e execute o comando show all:

rman target /

RMAN> show all

Se o arquivo de controle de snapshot não estiver no local correto, reconfigure-o. Por exemplo, use os seguintes parâmetros de configuração do RMAN para um banco de dados com um "db_unique_name" de **ctdb** que usa o sistema de arquivos local:

CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default

CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/mnt/ctdb/snapcf_ctdb.f';

Em um ambiente RAC, você precisa mapear o arquivo de controle de snapshot para um grupo de discos do ASM compartilhado. Para atribuir o arquivo ao grupo de discos do ASM, use o comando Configure Snapshot Controlfile Name:

CONFIGURE SNAPSHOT CONTROLFILE NAME TO '+/snap_.f';

Recomendações

Dependendo dos seus requisitos, talvez seja necessário tomar decisões sobre determinados recursos que afetam a solução como um todo. Algumas decisões podem afetar o preço, o que, por sua vez, afeta o desempenho, como a escolha de discos permanentes padrão (pd-standard) ou discos permanentes de desempenho (pd-ssd) para os pools de snapshots do dispositivo de backup/recuperação.

Nesta seção, compartilhamos nossas opções recomendadas para ajudar você a garantir o desempenho ideal para a capacidade de processamento do backup do banco de dados Oracle.

Selecionar o tipo de máquina ideal e o tipo de disco permanente

Ao usar um dispositivo de backup/recuperação com um aplicativo, como um sistema de arquivos ou um banco de dados, é possível medir o desempenho com base na velocidade com que as transferências de dados da instância do host entre as instâncias do Compute Engine são realizadas.

As velocidades de dispositivos de disco permanente do Compute Engine são baseadas em três fatores: tipo de máquina, quantidade total de memória anexada à instância e contagem de vCPUs da instância.
O número de vCPUs em uma instância determina a velocidade de rede alocada para uma instância do Compute Engine. A velocidade varia de 1 Gbps para uma vCPU compartilhada até 16 Gbps para 8 ou mais vCPUs.
Combinando esses limites, o Backup e recuperação de desastres do Google Cloud usa e2-standard-16 como tipo de máquina de tamanho padrão para um dispositivo de backup/recuperação. A partir desse ponto, você tem três opções de alocação de disco:

Escolha	Disco do pool	Máximo de gravações sustentadas	Máximo de leituras sustentadas
Mínimo	10 GB	N/A	N/A
Padrão	4.096 GB	400 MiB/s	1200 MiB/s
SSD	4.096 GB	1000 MiB/s	1200 MiB/s

As instâncias do Compute Engine usam até 60% da rede alocada para E/S nos discos permanentes anexados e reserva 40% para outros usos. Para mais detalhes, consulte Outros fatores que afetam o desempenho.

Recomendação: a seleção de um tipo de máquina e2-standard-16 e um mínimo de 4096 GB de DP-SSD proporciona o melhor desempenho para dispositivos de backup/recuperação. Como segunda opção, você pode selecionar um tipo de máquina n2-standard-16 para seu dispositivo de backup/recuperação. Essa opção oferece outros benefícios de desempenho na faixa de 10% a 20%, mas apresenta custos adicionais. Se isso corresponder ao seu caso de uso, entre em contato com o Cloud Customer Care para fazer essa alteração.

Otimizar seus snapshots

Para aumentar a produtividade de um único dispositivo de backup/recuperação, é possível executar jobs de snapshot simultâneos de várias fontes. A velocidade de cada job diminui. No entanto, com jobs suficientes, é possível atingir o limite de gravação sustentada para os volumes do Persistent Disk no pool de snapshots.

Ao usar o iSCSI para o disco de preparo, é possível fazer o backup de uma única instância grande em um dispositivo de backup/recuperação com velocidade de gravação sustentada de aproximadamente 300 a 330 MB/s. Em nossos testes, constatamos isso para qualquer item, de 2 TB a 80 TB em um snapshot, supondo que você configurou o host de origem e o dispositivo de backup/recuperação em um tamanho ideal e que eles estejam na mesma região e zona.

Escolher o disco de preparo correto

Se você precisar de desempenho e capacidade significativos, o Direct NFS pode adicionar benefícios significativos em relação ao iSCSI como a opção de disco de preparo a ser usado para backups de banco de dados Oracle. O NFS direto consolida o número de conexões TCP, o que melhora a escalonabilidade e o desempenho da rede.

Ao ativar o NFS direto para um banco de dados Oracle, configure uma CPU de origem suficiente (por exemplo, 8x vCPUs e 8 canais RMAN) e estabeleça um link de 10 GB entre a extensão regional da Solução Bare Metal e o Google Cloud. É possível fazer backup de um único banco de dados Oracle com maior capacidade de processamento entre 700 a 900 MB/s. As velocidades de restauração do RMAN também se beneficiam do NFS direto, em que é possível ver os níveis de capacidade atingirem o intervalo de 850 MB/s ou mais.

Equilibrar o custo e a capacidade

Também é importante entender que todos os dados de backup são armazenados em formato compactado no pool de snapshots do dispositivo de backup/recuperação, o que é feito para reduzir custos. A sobrecarga de desempenho para esse benefício da compactação é marginal. No entanto, para dados criptografados (TDE, na sigla em inglês) ou conjuntos de dados muito compactados, provavelmente haverá algum impacto mensurável, embora marginal, nos valores de capacidade.

Entender os fatores que afetam o desempenho da rede e dos servidores de backup

Os itens a seguir afetam a E/S de rede entre o Oracle na Solução Bare Metal e os servidores de backup no Google Cloud:

Armazenamento em Flash

Assim como o Persistent Disk do Google Cloud, as matrizes de armazenamento flash que fornecem armazenamento para sistemas da Solução Bare Metal aumentam os recursos de E/S com base na quantidade de armazenamento atribuída ao host. Quanto mais armazenamento você alocar, melhor será a E/S. Para resultados consistentes, recomendamos que você provisione pelo menos 8 TB de armazenamento flash.

Latência de rede

Os jobs de backup e DR do Google Cloud são sensíveis à latência da rede entre os hosts da Solução Bare Metal e o dispositivo de backup/recuperação no Google Cloud. Pequenos aumentos na latência podem criar grandes mudanças nos tempos de backup e restauração. Diferentes zonas do Compute Engine oferecem diferentes latências de rede para os hosts da Solução Bare Metal. É uma boa ideia testar cada zona para verificar o posicionamento ideal do dispositivo de backup/recuperação.

Número de processadores usados

Os servidores da Solução Bare Metal têm vários tamanhos. Recomendamos que você escalone seus canais RMAN para que se adaptem às CPUs disponíveis, com a maior velocidade possível em sistemas maiores.

Cloud Interconnect

A interconexão híbrida entre a Solução Bare Metal e o Google Cloud está disponível em vários tamanhos, como 5 Gbps, 10 Gbps e 2x10 Gbps, com desempenho total da opção dupla de 10 GB. Também é possível configurar um link de interconexão dedicado que será usado exclusivamente para operações de backup e restauração. Essa opção é recomendada para clientes que querem isolar o tráfego de backup do banco de dados ou de aplicativos que pode passar pelo mesmo link ou garantir largura de banda total em que as operações de backup e restauração são essenciais para garantir que você atinja seu objetivo de ponto de recuperação (RPO) e objetivo de tempo de recuperação (RTO).

A seguir

Veja alguns links e informações adicionais sobre backup e DR do Google Cloud que podem ser úteis.

Para ver etapas adicionais sobre a configuração de backup e DR do Google Cloud, consulte a documentação do produto de backup e DR.
Para ver a instalação do produto e demonstrações de recursos, consulte a playlist de vídeos de DR e backup do Google Cloud.
Para ver informações de compatibilidade do backup e DR do Google Cloud, consulte Matriz de suporte: backup e DR. É importante verificar se você está executando versões compatíveis das instâncias de banco de dados Linux e Oracle.
Para conferir mais etapas relacionadas à proteção do Oracle Database, consulte Backup e DR para bancos de dados Oracle e Proteger um banco de dados Oracle descoberto.
Sistemas de arquivos como NFS, CIFS, ext3 e ext4 também podem ser protegidos com Backup e DR do Google Cloud. Para acessar as opções disponíveis, consulte Aplicar um plano de backup para proteger um sistema de arquivos.
Para ativar alertas para backup e DR do Google Cloud, consulte Configurar um alerta com base em registros e assista ao vídeo Configuração de notificações de alerta de DR e backup do Google Cloud.
Para abrir um caso de suporte, entre em contato com o Cloud Customer Care.

Guia de soluções: backup do Google Cloud e DR para Oracle na solução Bare Metal

Visão geral

Experiência

Arquitetura

Instalar o Backup e DR do Google Cloud

Antes de começar

Instalar o console de gerenciamento de backup e DR

Instalar o appliance de backup/recuperação

Configurar backup e DR do Google Cloud

Configurar uma conta de serviço

Papéis da conta de serviço

Configurar pools de armazenamento

Cloud Storage

Pools de snapshots de disco permanente

Configurar planos de backup

criar um perfil

Criar um modelo

Fazer backup de um database Oracle

Configurar os hosts da Oracle

Instalar o agente de backup

Adicionar hosts a backup e DR

Configurar os hosts

Preparar o host Linux

Preparar o database Oracle

Proteger um database Oracle

Iniciar o job de backup

Ativar e restaurar um database Oracle

Ativações compatíveis com apps

Ativar um database Oracle

Monitorar o progresso e o sucesso do job

Unmount an Oracle database

Restaurações

Ativar e migrar

Ativação de restauração: fase 1

Ativação de migração: fase 2

Restaurar um database Oracle

Monitorar o progresso e o sucesso do job

Proteger o database restaurado

Solução de problemas e otimização

Solução de problemas de backup da Oracle

Considerações adicionais sobre a Oracle

Considerações sobre o Data Guard

Considerações sobre a RAC

Recomendações

Selecionar o tipo de máquina ideal e o tipo de disco permanente

Otimizar seus snapshots

Escolher o disco de preparo correto

Equilibrar o custo e a capacidade

Entender os fatores que afetam o desempenho da rede e dos servidores de backup

Armazenamento em Flash

Latência de rede

Número de processadores usados

Cloud Interconnect

A seguir