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

Informações gerais

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 realizou testes abrangentes do serviço de backup e DR do Google Cloud e compilou as descobertas neste guia. Como resultado, mostraremos as melhores maneiras de implantar, configurar e otimizar suas opções de backup e recuperação para databases Oracle em um ambiente da Solução Bare Metal usando o serviço Backup e DR. Também compartilharemos alguns números de desempenho dos resultados de testes para que você tenha uma referência de comparação com seu próprio ambiente. Este guia é útil para administradores de backup, do Google Cloud ou de Oracle DBA.

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) deBackup e DR do Google Cloud (anteriormente conhecida comoActifio GO) para um cliente empresarial. Para atender aos critérios de sucesso, precisávamos dar suporte à recuperação do database da Oracle de 50 TB e restaurar o database 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 PoC. Sentimos que havia um risco relativamente baixo porque os dados de testes anteriores da equipe de engenharia de backup e DR mostravam 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 em prosseguir com a PoC.

Durante a PoC, aprendemos a configurar vários elementos juntos com êxito (Oracle, backup e DR do Google Cloud, armazenamento e links de extensão regionais) em um ambiente da Solução Bare Metal. Ao seguir as práticas recomendadas que aprendemos, é possível gerar bons resultados.

"Sua milhagem pode variar" é uma boa maneira de pensar nos resultados gerais deste documento. Nossa meta é compartilhar um pouco de conhecimento sobre o que aprendemos, o que você deve observar, o que precisa evitar e áreas de investigação se não está conseguindo o desempenho ou os resultados desejados. Esperamos que este guia ajude você a gerar confiança com as soluções propostas e que seus requisitos possam ser atendidos.

Arquitetura

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

Figura 1: componentes para usar o Backup e DR com databases Oracle em um ambiente de 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 databases Oracle em um data center de terceiros ao lado de um data center do Google Cloud e usar as licenças de software atuais no local.
Projeto de serviço de backup e DR: permite hospedar o dispositivo de backup/recuperação e o backup da Solução Bare Metal e das cargas de trabalho do Google Cloud nos 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: oferece o console de gerenciamento de backup e DR que permite manter os backups e a recuperação de desastres.
Projeto host: permite criar sub-redes regionais em uma VPC compartilhada que possa 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 do Google Analytics.

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 a solução funcione:

Console de gerenciamento de DR e backup: um endpoint de IU e API HTML 5 que permite criar e gerenciar backups a partir do console do Google Cloud.
Dispositivo de backup/recuperação: este dispositivo funciona como o trabalhador da tarefa para executar backups e ativa e restaura 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 (gerenciamento do Google Cloud) e implantar o dispositivo de backup/recuperação em um consumidor de serviço (lado do cliente). Para mais informações 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 Google Cloud Backup e DR Service, conclua as etapas de configuração a seguir antes de iniciar a implantação:

Ative uma conexão de acesso a serviços privados. Estabeleça essa conexão antes de iniciar a instalação. Mesmo que você já tenha uma sub-rede de acesso a serviços privados 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 privados, recomendamos adicionar uma sub-rede /23. Melhor ainda, você pode adicionar uma sub-rede /20 para garantir que possa adicionar 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 (via pesquisa privada ou pública).
Configure rotas de rede e regras de firewall padrão para permitir o tráfego de saída para *.googleapis.com (via IPs públicos) ou private.googapis.com (199.36.153.8/30) na porta TCP 443 ou uma saída explícita para 0.0.0.0/0. Novamente, é necessário configurar as rotas e o firewall na rede VPC em que você instalará 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.
Ativar as APIs a seguir no projeto do consumo:
- 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ítica da organização, configure o seguinte:
- constraints/cloudkms.allowedProtectionLevels incluem SOFTWARE ou ALL.
Configure as seguintes regras de firewall:
- Entrada do appliance de backup/recuperação na VPC do Compute Engine para o host (agente) do Linux na porta TCP-5106.
- Se você usar um disco de backup baseado em bloco com iSCSI, saia do host 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ê usa um disco de backup baseado em NFS ou dNFS, saia do host Linux (agente) na Solução Bare Metal para o dispositivo de backup/recuperação na VPC do Compute Engine nas seguintes portas:
  - 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. Assim, você garante que a resolução de nomes seja consistente nos servidores da Solução Bare Metal, VMs e 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 ela 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ço. O Google Cloud possui e mantém recursos de console de gerenciamento.
Escolha a rede VPC no projeto de consumidor do serviço que você quer conectar ao serviço de backup e DR. Esse é normalmente um projeto host ou de VPC compartilhada.
Depois de esperar até uma hora, você verá a tela a seguir 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 código gerado, visto 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 em que 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 Appliances:
```
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 quando a implantação for iniciada.
Escolha o projeto do consumidor em que você quer instalar o dispositivo de backup/recuperação.
Escolha sua região, zona e sub-rede preferidas.
Selecione um tipo de armazenamento. Recomendamos escolher Disco permanente padrão para PoCs e Disco permanente SSD para um ambiente de produção.
Clique no botão Iniciar instalação. O processo leva cerca de 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 dezembro de 2022 do Backup e DR), é 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 os objetos de máquinas virtuais (VMs) do Compute Engine (não abordadas neste documento).

Papéis da conta de serviço

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

Operador de backup e DR do Cloud Storage: atribua esse papel às contas 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 atuais baseados em agente para restaurar cargas de trabalho.
Operador de backup e DR do Compute Engine: atribua esse papel às contas 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 alternativos.

É possível encontrar 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 observando o valor da conta de serviço listado na seção de API e identidade gerenciamento.

Para fornecer as permissões apropriadas para 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 à 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 Disco permanente para os dados mais recentes (1 a 14 dias) e o Cloud Storage para retenção em 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 de 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 Refinado. Para o armazenamento padrão, aceite o modo de controle de acesso padrão de Uniforme.
5. Por fim, não configure outras opções de proteção de dados 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
 
```
Pools de armazenamento"." class="l10n-absolute-url-src" l10n-attrs-original-order="src,alt,class" src="https://cloud.google.com/static/bare-metal/docs/solutions/oracle/images/backup-and-dr-manage-storage-pools.png" />
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 Save.

Pools de snapshots de disco permanente

Se você implantou o appliance de backup/recuperação com opções padrão ou SSD, o pool de snapshots de disco permanente será de 4 TB por padrão. Se os databases de origem ou os sistemas de arquivos exigirem um pool maior, edite as configurações do dispositivo de backup/recuperação implantado, adicione um novo disco permanente 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 Save.

Acesse a página Gerenciar > Eletrodomésticos 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 no nome do appliance e selecione Configurar appliance 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 disco permanente no mesmo pool. Se estiver se expandindo, clique no ícone superior direito para o pool que você quer 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 ao pool.
2. Selecione Enviar.
3. Para continuar, digite PROCEED em maiúsculas quando solicitado.
4. Clique em Confirmar.
Agora o pool será expandido ou criado com o disco permanente.

Observação: neste ponto, não é possível mover, expandir ou excluir o disco permanente até que todas as imagens de backup armazenadas nesse pool sejam removidas. 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 que você configure dois elementos principais para fazer backup de qualquer database, VM ou sistema de arquivos. Os planos de backup incorporam perfis e modelos.

Os perfis permitem definir quando fazer o backup de algo e por quanto tempo os dados de backup devem ser retidos.
Os modelos fornecem um item de configuração que permite decidir qual dispositivo de backup/recuperação e pool de armazenamento (disco permanente, 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 de VM do Compute Engine, editá-lo e usá-lo para backups da Solução Bare Metal. É possível ter vários perfis, o que é útil se você estiver fazendo backup de muitos databases que exigem diferentes níveis de disco para backup. Por exemplo, é possível criar um pool para SSD (desempenho maior) e um 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 de disco a ser usado, onde os buckets do Cloud Storage estão localizados ou outras informações que explicam 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.
Para fazer backups de registros arquivados com frequência regular (por exemplo, a cada 15 minutos) e replicar os registros para o Cloud Storage, ative 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 armazenamento desejado.
5. Defina Replicate Logs (Use Streamsnap Technology) como No.
6. Defina Send Logs to OnVault Pool como Yes se você quiser enviar registros para o bucket do Cloud Storage. Caso contrário, selecione Não.
7. Clique em Salvar alterações.
Clique em Fazer update da política para salvar as mudanças.
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 mais 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 para 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 mantém backups por três dias no nível do disco permanente, sete dias para jobs do Vault e um total de quatro semanas. O backup semanal funciona nas noites de sábado.

Observação: no Backup e DR, os jobs diários e semanais do Vault 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 extra 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 vezes por dia e quatro vezes por semanas.

Fazer backup de um database Oracle

A arquitetura de DR e backup do Google Cloud oferece backup Oracle consistente e incremental para o Google Cloud, além de recuperação instantânea e clonagem para databases Oracle de vários terabytes.

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

API de cópia de imagens RMAN: uma cópia de imagem de um arquivo de dados é muito mais rápida de restaurar porque a estrutura física do arquivo de dados já existe. A diretiva do Recovery Manager (RMAN) BACKUP AS COPY cria cópias de imagem para todos os arquivos de dados de todo o database e mantém o formato do arquivo de dados.
API ASM e CRS: use a API Auto Storage Management (ASM) e a API Cluster Ready Services (CRS) para gerenciar o grupo de discos de backup do ASM.
API de backup de registros RMAN: essa API gera registros de backup, faz backup deles em um disco de preparo e os limpa do local do arquivo de produção.

Configurar os hosts da Oracle

As etapas para configurar os hosts da Oracle incluem instalar o agente, adicionar os hosts ao Backup e DR, configurar os hosts e descobrir os databases da Oracle. Depois que tudo estiver pronto, será possível fazer backups do database Oracle para 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 em que usar o host e, em seguida, os upgrades subsequentes poderão ser feitos na interface do usuário de backup e DR no console do Google Cloud. Você precisa estar conectado como um usuário root ou em uma sessão autenticada do sudo para executar uma instalação do 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 Gerenciar > Eletrodomésticos.
```
https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#clusters
```
Clique com o botão direito do mouse no nome do appliance de backup/recuperação e selecione Configurar o appliance. Uma nova janela do navegador será aberta.
Clique no ícone do Linux 64 bits para fazer o download do agente de backup no computador que hospeda a sessão do navegador. Use scp (cópia segura) para mover o arquivo do agente transferido por download para os hosts da 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 do agente diretamente para os hosts do Linux.
```
curl -o agent-Linux-latestversion.rpm https://storage.googleapis.com/actifio-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, você precisa 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. Execute essa tarefa menos de duas horas depois de instalar o agente de backup e de 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 adicionou a chave secreta ao host em duas horas após a criação. É possível 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 da 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.
Ao corrigir o problema, o Status do certificado mudará de N/D 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 databases Oracle e selecione Edit.
Clique em Como preparar o formato do disco e selecione NFS.

Observação: se preferir usar discos de preparo do ASM (também conhecidos como backup em discos formatados do ASM), selecione Bloquear para a configuração Como preparar o formato do disco.
Role para baixo até a seção Aplicativos descobertos e clique em Descobrir aplicativos para iniciar o processo de descoberta do appliance para o agente.
Clique em Discover para iniciar o processo. O processo de descoberta leva até cinco minutos. Quando concluídos, os sistemas de arquivos descobertos e os databases Oracle 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 iSCSI ou NFS no seu host baseado no SO Linux, é possível mapear um disco de preparo para um dispositivo que grava os dados de backup. Use os comandos a seguir 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 precisa.

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

Use iSCSI quando quiser salvar seu backup em um disco de preparo de backup baseado em bloco (faça backup no sistema de arquivos) ou quando precisar armazenar o formato de disco de teste 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 Kernel NFS, para aumentar o desempenho de backup e restauração. É possível aproveitar várias sessões TCP com NFS, mas esse método de armazenamento de arquivos é compatível apenas com a opção de disco de preparo do backup do sistema de arquivos.
Use Direct NFS (dNFS) quando quiser implantar a melhoria da Oracle no 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 do backup do sistema de arquivos. A configuração do dNFS exige que você encerre o database para que a configuração entre em vigor na 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

Este guia pressupõe que você já tenha uma instância e um database Oracle configurados. O Backup e DR do Google Cloud é compatível com a proteção de databases em execução 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 databases Oracle.

Você precisa configurar alguns itens antes de iniciar o job de backup. Algumas dessas tarefas são opcionais, mas recomendamos as seguintes configurações para um desempenho ideal:

Use SSH para se conectar ao host Linux e faça login como o 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 database 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 Oracle e RMAN que são necessárias para sua 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, poderá aumentar o número de canais para operações de backup paralelo e defini-lo como um número maior.

Para saber mais sobre configurações avançadas, consulte Definir detalhes e configurações do aplicativo para databases 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 Gerenciar > Hosts e selecione o host que você quer Editar. Marque a opção Como preparar o formato do disco como convidado. Por padrão, o formato Bloquear é selecionado. Isso mapeia o disco de preparo via iSCSI. Caso contrário, ele pode ser alterado para NFS. Em seguida, o disco de teste usa o disco Protocolo NFS.

As configurações padrão dependem do formato do database. Se você usar o ASM, o sistema usará o iSCSI para enviar ao backup um grupo de discos do ASM. Se você usar um sistema de arquivos, ele usará o iSCSI para enviar o backup a um sistema de arquivos. Se você quiser usar NFS ou Direct NFS (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 usarão 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 database 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 job de backup, acesse o menu Monitorar > Jobs e visualize o status do job. Pode levar de 5 a 10 segundos para um job aparecer na lista. Veja a seguir um exemplo de 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, junto com uma pesquisa para o host test1.
Para ver mais de perto um job específico, clique nele na coluna Job. Uma nova janela será aberta. Como você pode ver no exemplo a seguir, cada job de backup captura uma grande quantidade de informações.

Ativar e restaurar um database Oracle

O Backup e DR do Google Cloud tem vários recursos diferentes para acessar uma cópia de um database 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, você precisa selecionar qual deles quer usar, dependendo do seu caso de uso, dos requisitos de desempenho e de quanto tempo precisa manter a cópia do database. 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 ativação quando o desempenho não é crítico, e a cópia do database fica ativa por apenas algumas horas ou até alguns dias.

O principal benefício de uma ativação é que ela não consome grandes quantidades de armazenamento extra. Em vez disso, a ativação usa um snapshot do pool de discos de backup, que pode ser um pool de snapshots em um disco permanente ou um pool do OnVault no Cloud Storage. O uso do recurso de snapshot de cópia virtual minimiza o tempo de acesso aos dados porque eles não precisam ser copiados primeiro. O disco de backup processa todas as leituras, e um disco no pool de snapshots armazena todas as gravações. Como resultado, a ativação de cópias virtuais é rápida e não substitui a cópia do disco de backup. As ativações são ideais para desenvolvimento, teste e atividades de DBA em que alterações ou atualizações de esquema precisam ser validadas antes de serem implementadas 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 database que você quer ativar, clique com o botão direito do mouse no nome do database e clique em Avançar:
A visualização da Rampa do cronograma é exibida e exibe todas as imagens pontual disponíveis. Também é possível voltar para ver imagens de retenção de longo prazo se elas não aparecerem na visualização de rampa. O sistema seleciona a imagem mais recente por padrão.
Se preferir uma visualização de tabela para as imagens pontuais, clique na opção Tabela para alterá-la:
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 nessa lista se você os tiver adicionado anteriormente.
2. (Opcional) Digite um rótulo.
3. No campo SID do database de destino, insira o identificador do database 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 database para backup, o Tempo de encaminhamento ficará disponível. Clique no seletor de relógio/hora e escolha o ponto de avanço.
7. A opção Restaurar com recuperação é ativada por padrão. Essa opção ativa e abre o database para você.
Quando terminar de inserir as informações, clique em Enviar para iniciar o processo de ativação.

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.

Jobs." class="l10n-absolute-url-src" l10n-attrs-original-order="src,alt,class" src="https://cloud.google.com/static/bare-metal/docs/solutions/oracle/images/backup-and-dr-monitor-jobs.png" />
Quando o job de ativação for concluído, clique em Job Number para ver os detalhes do job:

Para visualizar os processos pmon do 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 database SCHTEST está operacional e tem um código de processo de 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

Desconectar um database Oracle

Depois de usar o database, é necessário desconectar e excluir o database. Há dois métodos para encontrar um database ativado:

Acesse a página App Manager > Ativações ativas.
```
https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#activemounts
```
Esta página contém uma visualização global de todos os aplicativos ativados (sistemas de arquivos e databases) atualmente em uso.
1. Clique com o botão direito do mouse na ativação que você quer limpar e selecione Desativar e Excluir no menu. Essa ação não exclui dados de backup. Ele remove apenas o database virtual ativado do host de destino e o disco de cache do snapshot que continha as gravações armazenadas para o database.
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, você vê um círculo cinza com um número que indica o número de ativações ativas desse momento. Clique nessa imagem para exibir 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 database do host de destino, limpa e remove todos os discos. Essa ação libera qualquer espaço em disco no pool de snapshots usado para gravações no disco de refazer em ativações ativas.
É possível monitorar jobs desconectados como qualquer outro job. Acesse o menu Monitorar > Jobs para monitorar o progresso do job que está sendo desativado e confirmar se ele foi concluído.
```
 https://bmc-PROJECT_NUMBER-GENERATED_ID-dot-REGION.backupdr.googleusercontent.com/#jobs
 
```
Se você excluir o database Oracle manualmente ou desligar o database antes de executar o job Desativar e excluir, execute novamente o job Desativar e excluir e selecione a opção Forçar desativação na tela de confirmação. Esta ação força a remoção do disco de preparo do host de destino e exclui o disco do pool de snapshots.

Restaurações

Use restaurações para recuperar databases de produção quando ocorre um problema ou corrompimento e é necessário copiar todos os arquivos do database para um host local de uma cópia de backup. Normalmente, uma restauração é executada após um evento de tipo de desastre ou em cópias de testes de não 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 databases. No entanto, o Backup e DR do Google Cloud também é compatível com um recurso de restauração (copiar arquivos e iniciar o database) e um recurso de ativação e migração, em que você ativa o database (o tempo de acesso é rápido) e é possível copiar arquivos de dados para a máquina local enquanto o database está ativado e acessível. O recurso de ativação 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 ativação de restauração fornece acesso instantâneo ao database a partir da cópia ativada.
Fase 2: a fase de migração de restauração migra o database para o local de armazenamento de produção enquanto o database está on-line.

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

Essa fase fornece acesso instantâneo ao database a partir de uma imagem selecionada apresentada pelo appliance de backup/recuperação.

Uma cópia da imagem de backup selecionada é mapeada para o servidor de database de destino e apresentada à camada do sistema de arquivos ASM ou arquivo com base no formato de imagem de backup do database 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 refazer a localização do arquivo (grupo de discos ASM ou sistema de arquivos).
- Alterne o database 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 database é executado a partir da cópia mapeada da imagem de backup apresentada pelo appliance de backup/recuperação.
O arquivo de controle e o arquivo de registro de refazer do database são colocados no local de armazenamento de produção local selecionado (ASM diskgroup ou sistema de arquivos) no destino.
Após uma operação de ativação de restauração bem-sucedida, o database fica disponível para operações de produção. É possível usar 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 ASM ou sistema de arquivos) enquanto o database e o aplicativo estão 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 pelo Backup e DR da imagem de backup para o armazenamento de database de destino selecionado (ASM diskgroup ou sistema de arquivos).
Quando o job de migração é concluído, o sistema remove e desmapeia a cópia de imagem de backup e de apresentação de backup apresentada pelo DR (grupo de arquivos ASM ou sistema de arquivos) do destino e o database é executado no armazenamento de produção.

Para mais informações sobre a recuperação de ativação e migração, consulte: Ativar e migrar uma imagem de backup da 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 Application, clique com o botão direito do mouse no nome do database que você quer restaurar e selecione Next:
A visualização da rampa do cronograma será exibida, exibindo todas as imagens disponíveis no momento. Também é possível rolar para trás caso seja necessário visualizar as imagens de retenção de longo prazo que não aparecem na rampa. Por padrão, o sistema sempre seleciona a imagem mais recente.

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 DATA LOSS para confirmar que você quer substituir o database de origem e clique em Confirm.

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 do job.

Proteger o database restaurado

Quando o job de restauração de database é concluído, o sistema não faz backup do database automaticamente após a restauração. Em outras palavras, quando você restaura um database que 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 App Manager > 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 para o database.
Para proteger o database restaurado, procure na coluna Aplicativo o database que você quer proteger. Clique com o botão direito do mouse no nome do database 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 ajudar você a solucionar problemas de backups da Oracle, otimizar o sistema e considerar ajustes para ambientes RAC e Data Guard.

Solução de problemas de backup da Oracle

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

Para verificar se o listener do Oracle para o serviço e a 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 database for executado em um modo diferente, você poderá ver jobs com falha com a mensagem Error Code 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 o funcionamento da solução, ativar o rastreamento de alteração 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 de backup do job:
```
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. Embora não seja obrigatório, se você precisar do método mais rápido de backup e restauração dos databases Oracle, o dnfs é a melhor opção. Para melhorar ainda mais a capacidade, altere o disco de preparo por host e ative o dnfs para a Oracle.

Configure tnsnames para resolução de hosts de database Oracle. Se você não incluir essa configuração, os comandos RMAN geralmente falharão. 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 anunciar o sistema para recursos externos que se comunicam com o cluster. Nas opções Detalhes e configurações do database protegido, use a Configuração avançada para o 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 database 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, crie uma entrada de nome de serviço nos servidores no arquivo tnsnames.ora localizado em $ORACLE_HOME/network/admin ou em $GRID_HOME/network/admin, adicionando o método seguinte entrada:
```
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, forneça o caminho absoluto para o arquivo na página Detalhes e configurações do aplicativo descrita em Configurar detalhes do aplicativo e para databases Oracle.
- Verifique se você configurou a entrada do nome do serviço para o database corretamente. Faça login no Oracle Linux e configure o ambiente da Oracle:
```
TNS_ADMIN=TNSNAMES.ORA_FILE_LOCATION
tnsping CLU1_S
```
- Veja a conta de usuário do database 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 databases Oracle, insira o nome do serviço que você criou (CLU1_S) no campo Oracle Service Name:
O Código de erro 870 informa que "Não há suporte para backups do ASM com ASM em discos de preparo NFS." Se você receber esse erro, significa que 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 NFS para o disco de preparo, mas o database 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 de erro 15 informa ao sistema de backup e DR "Não foi possível se conectar ao host de backup". Se você receber esse erro, ele indica um dos três problemas:

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

Para corrigir esse problema, reconfigure 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 de 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. É possível acessar os registros no host de origem em que os jobs de backup são executados. Para backups de database Oracle, há dois arquivos de registros principais disponíveis no diretório /var/act/log:
- UDSAgent.log: registro do agente de backup e DR do Google Cloud que registra solicitações de API, execução de estatísticas de job 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 o Backup e DR para databases Oracle, esteja ciente das considerações a seguir 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 databases apenas nos nós em espera, precisará usar a autenticação de database Oracle em vez da autenticação do SO ao fazer backup do database.

Considerações sobre a RAC

A solução de backup e DR não é compatível com backup simultâneo de vários nós em um database RAC se o disco de preparo estiver configurado para o modo NFS. Se o sistema exigir backup simultâneo de vários nós RAC, use Block (iSCSI) como modo de disco de preparo e defina-o para cada host.

Para um database Oracle RAC usando ASM, você precisa colocar 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 database com um "db_unique_name" de **ctdb** que use 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, é preciso mapear o arquivo de controle de snapshots para um grupo de discos 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 requisitos, talvez seja necessário tomar decisões em relação a determinados recursos que têm efeito na solução geral. Algumas decisões podem afetar o preço, o que, por sua vez, pode afetar o desempenho. Por exemplo, escolher 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 escolhas recomendadas para ajudar você a garantir o desempenho ideal para a capacidade de backup do database 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 database, é possível medir o desempenho com base na rapidez com que os dados da instância do host são transferidos entre as instâncias do Compute Engine.

As velocidades de dispositivo do disco permanente do Compute Engine são baseadas em três fatores: o tipo de máquina, a quantidade total de memória anexada à instância e a contagem de vCPU 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 DR do Google Cloud usa um 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 para a 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 reservam 40% para outros usos. Para mais informações, 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 PD-SSD oferece 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 o dispositivo de backup/recuperação. Essa opção oferece mais benefícios de desempenho no intervalo de 10 a 20%, mas tem outros custos. 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 instantâneo 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 de disco permanente no pool de snapshots.

Quando você usa o iSCSI no disco de preparo, pode fazer backup de uma única instância grande em um dispositivo de backup/recuperação com uma velocidade de gravação sustentada de aproximadamente 300-330 MB/s. Em nossos testes, isso foi válido para tudo, 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 eles estão no mesmo tamanho região e zona.

Escolher o disco de preparo correto

Se você precisar de desempenho e capacidade significativos, o NFS direto pode adicionar benefícios significativos em comparação com iSCSI como a opção de disco de preparo a ser usado para backups de database 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 database Oracle, configurar a CPU de origem suficiente (por exemplo, 8x vCPUs e 8 canais RMAN) e estabelecer um link de 10 GB entre sua extensão regional da Solução Bare Metal e o Google Cloud, você pode fazer backup de um único database Oracle com aumento de capacidade entre 700-900 MB/s. As velocidades de restauração do RMAN também se beneficiam do NFS direto, em que os níveis de capacidade alcançam 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 nos resultados da 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 a Oracle na Solução Bare Metal e os servidores de backup no Google Cloud:

Armazenamento em Flash

Assim como no disco permanente do Google Cloud, as matrizes de armazenamento em Flash que oferecem 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 provisionar pelo menos 8 TB de armazenamento em Flash.

Latência de rede

Os jobs de backup e DR do Google Cloud são sensíveis à latência de rede entre os hosts da Solução Bare Metal e o dispositivo de backup/recuperação no Google Cloud. Pequenos aumentos de latência podem criar grandes alterações nos tempos de backup e restauração. Diferentes zonas do Compute Engine oferecem diferentes latências de rede aos hosts da Solução Bare Metal. É recomendável testar cada zona para ver 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 se adequar às CPUs disponíveis, com uma velocidade maior 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 tráfego do database ou do aplicativo que pode atravessar o 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ê atenda seu objetivo de ponto de recuperação (RPO, na sigla em inglês) e objetivo de tempo de recuperação (RTO, na sigla em inglês).

Próximas etapas

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

Para ver mais etapas relacionadas à configuração do Backup e DR do Google Cloud, consulte a documentação do produto de backup e DR.
Para ver demonstrações de instalação do recurso e do produto, consulte a playlist de vídeo 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 de instâncias de database do Linux e da Oracle.
Para mais etapas sobre a proteção da Oracle Database, consulte Backup e DR para databases da Oracle e Proteger um database Oracle descoberto.
Sistemas de arquivos como NFS, CIFS, ext3 e ext4 também podem ser protegidos com o Backup e DR do Google Cloud. Para ver as opções disponíveis, consulte Aplicar um plano de backup para proteger um sistema de arquivos.
Para ativar alertas do Google Cloud Backup e DR, consulte Configurar um alerta baseado em registro e assista ao vídeo Google Cloud Backup and DR Alert Notifications (em inglês).
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

Informações gerais

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

Desconectar um database Oracle

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

Próximas etapas