Implantação de banco de dados Oracle de Máquinas Virtuais do Azure para carga de trabalho SAP

Este documento abrange várias áreas diferentes a serem consideradas ao implantar a carga de trabalho do Oracle Database for SAP na IaaS do Azure. Antes de ler este documento, recomendamos que você leia Considerações sobre a implantação do DBMS de Máquinas Virtuais do Azure para carga de trabalho SAP. Também recomendamos que você leia outros guias na documentação da carga de trabalho SAP no Azure.

Você pode encontrar informações sobre as versões do Oracle e as versões correspondentes do sistema operacional que são suportadas para executar o SAP no Oracle no Azure no SAP Note 2039619.

Informações gerais sobre a execução do SAP Business Suite no Oracle podem ser encontradas em SAP on Oracle. A Oracle oferece suporte para executar bancos de dados Oracle no Microsoft Azure. Para obter mais informações sobre o suporte geral para Windows Hyper-V e Azure, consulte as Perguntas frequentes sobre Oracle e Microsoft Azure.

As seguintes notas SAP são relevantes para uma instalação do Oracle

Número da nota Título da nota
1738053 Instalação do SAPinst for Oracle ASM SAP ONE Support Launchpad
2896926 Compatibilidade com grupo de discos ASM NetWeaver SAP ONE Support Launchpad
1550133 Usando o Oracle Automatic Storage Management (ASM) com produtos baseados no SAP NetWeaver SAP ONE Support Launchpad]
888626 Refazer layout de log para sistemas high-end SAP ONE Support Launchpad
105047 Suporte para funções Oracle no ambiente SAP SAP ONE Support Launchpad
2799920 Patches para 19c: Base de dados SAP ONE Support Launchpad
974876 Oracle Transparent Data Encryption (TDE) Barra inicial de suporte do SAP One
2936683 Oracle Linux 8: Instalação e atualização do SAP ONE Support Launchpad
1672954 Oracle 11g, 12c, 18c e 19c: Uso de páginas enormes no Linux
1171650 Verificação automatizada de parâmetros do banco de dados Oracle
2936683 Oracle Linux 8: Instalação e atualização SAP

Especificidades do Oracle Database no Oracle Linux

A Oracle oferece suporte para executar suas instâncias de banco de dados no Microsoft Azure com o Oracle Linux como sistema operacional convidado. Para obter mais informações sobre o suporte geral para Windows Hyper-V e Azure, consulte as Perguntas frequentes do Azure e do Oracle.

O cenário específico de aplicativos SAP usando bancos de dados Oracle também é suportado. Os detalhes são discutidos na próxima parte do documento.

Recomendações gerais para executar SAP no Oracle no Azure

Instalando ou migrando SAP existente em sistemas Oracle para o Azure, o seguinte padrão de implantação deve ser seguido:

  1. Use a versão mais recente disponível do Oracle Linux (Oracle Linux 8.6 ou superior).
  2. Use a versão mais recente do Oracle Database disponível com o mais recente SAP Bundle Patch (SBP) (Oracle 19 Patch 15 ou superior) 2799920 - Patches for 19c: Database.
  3. Use o gerenciamento automático de armazenamento (ASM) para bancos de dados de pequeno, médio e grande porte no armazenamento em bloco.
  4. O SSD de Armazenamento Premium do Azure deve ser usado. Não use Standard ou outros tipos de armazenamento.
  5. O ASM remove o requisito de Mirror Log. Siga as orientações da Oracle na Nota 888626 - Refazer layout de log para sistemas high-end.
  6. Use ASMLib e não use udev.
  7. As implantações do Azure NetApp Files devem usar o Oracle dNFS (a própria solução Direct NFS de alto desempenho da Oracle).
  8. Grandes bancos de dados Oracle se beneficiam muito de grandes tamanhos de SGA (System Global Area). Os grandes clientes devem implantar no Azure M-series com 4 TB ou mais de RAM
    • Defina Linux Huge Pages para 75% do tamanho da RAM física
    • Defina a área global do sistema (SGA) para 90% do tamanho da página enorme
    • Defina o parâmetro Oracle USE_LARGE_PAGES = ONLY - O valor ONLY é preferido sobre o valor TRUE, pois o valor ONLY deve oferecer um desempenho mais consistente e previsível. O valor TRUE pode alocar páginas grandes de 2MB e 4K padrão. O valor ONLY vai sempre forçar grandes páginas de 2MB. Se o número de páginas enormes disponíveis não for suficiente ou não estiver configurado corretamente, a instância do banco de dados falhará ao iniciar com o código de erro: ora-27102 : falta de memória Linux_x86_64 Erro 12: não é possível alocar memória. Se não houver memória contígua suficiente, o Oracle Linux pode precisar ser reiniciado e/ou os parâmetros da página enorme do sistema operacional reconfigurados.
  9. O Oracle Home deve estar localizado fora do volume ou disco "raiz". Use um disco ou volume ANF separado. O disco que contém o Oracle Home deve ter 64 Gigabytes de tamanho ou mais.
  10. O tamanho do disco de inicialização para grandes servidores de banco de dados Oracle de alto desempenho é importante. No mínimo, um disco P10 deve ser usado para as séries M ou E. Não use discos pequenos como P4 ou P6. Um disco pequeno pode causar problemas de desempenho.
  11. A Rede Acelerada deve estar habilitada em todas as Máquinas Virtuais. Atualize para a versão mais recente do Oracle Linux se houver algum problema ao ativar o Accelerated Networking.
  12. Verifique se há atualizações nesta documentação e na nota SAP 2039619 - Aplicativos SAP no Microsoft Azure usando o banco de dados Oracle: produtos e versões suportados - SAP ONE Support Launchpad.

Para obter informações sobre quais versões do Oracle e versões correspondentes do sistema operacional são suportadas para executar o SAP no Oracle em máquinas virtuais do Azure, consulte SAP Note 2039619.

Informações gerais sobre a execução do SAP Business Suite no Oracle podem ser encontradas na página da comunidade SAP on Oracle. O SAP on Oracle no Azure só é suportado no Oracle Linux (e não no Suse ou Red Hat) para servidores de aplicativos e bancos de dados. Os servidores ASCS/ERS podem usar RHEL/SUSE porque o cliente Oracle não está instalado ou usado nessas VMs. Os servidores de aplicativos (PAS/AAS) não devem ser instalados nessas VMs. Consulte SAP Note 3074643 - OLNX: FAQ: se o Pacemaker for Oracle Linux for suportado no SAP Environment. O Oracle Real Application Cluster (RAC) não é suportado no Azure porque o RAC exigiria rede Multicast.

Configuração do armazenamento

Há dois padrões de implantação de armazenamento recomendados para SAP no Oracle no Azure:

  1. Gerenciamento Automático de Armazenamento (ASM) Oracle
  2. Arquivos NetApp do Azure (ANF) com Oracle dNFS (Direct NFS)

Os clientes que atualmente executam bancos de dados Oracle em sistemas de arquivos EXT4 ou XFS com LVM (Logical Volume Manager) são incentivados a migrar para o ASM. Há vantagens consideráveis de desempenho, administração e confiabilidade na execução em ASM em comparação com LVM. O ASM reduz a complexidade, melhora a capacidade de suporte e simplifica as tarefas administrativas. Esta documentação contém links para DBAs (Oracle Database Administrators) aprenderem a instalar e gerenciar o ASM.

O Azure fornece várias soluções de armazenamento. A tabela abaixo detalha o status do suporte

Tipo de armazenamento Suporte Oracle Dimensão do Sector Oracle Linux 8.x ou superior Windows Server 2019
Tipo de armazenamento em bloco
SSD Premium Suportado Artigo 512.º ASM recomendado. LVM suportado Sem suporte para ASM no Windows
SSD Premium v2 Suportado 4K nativo ou 512e1 ASM recomendado. LVM suportado Não há suporte para ASM no Windows. Alterar discos de arquivo de log de 4K nativo para 512e
SSD Standard Não suportado
HDD Standard Não suportado
Disco Ultra Suportado 4K nativo ASM recomendado. LVM suportado Não há suporte para ASM no Windows. Alterar discos de arquivo de log de 4K nativo para 512e
Tipos de armazenamento de rede
Serviço NetApp do Azure (ANF) Suportado - Oracle dNFS necessário Não suportado
Azure Files NFS Não suportado
Arquivos do Azure SMB Não suportado

1 512e é suportado no SSD Premium v2 para sistemas Windows. As configurações 512e não são recomendadas para clientes Linux. Migrar para 4K Native usando o procedimento no tamanho do setor MOS 512/512e para 4K Native Review (ID do documento 1133713.1)

Outras considerações que se aplicam à lista como:

  1. Não há suporte para DIRECTIO com tamanho de setor nativo 4K. Configurações recomendadas para FILESYSTEMIO_OPTIONS para configurações LVM:
    • LVM - Se forem utilizados discos com geometria 512/512e, FILESYSTEMIO_OPTIONS = SETALL
    • LVM - Se forem utilizados discos com geometria nativa 4K, FILESYSTEMIO_OPTIONS = ASYNC
  2. O Oracle 19c e superior suporta totalmente o tamanho do setor nativo 4K com ASM e LVM
  3. Oracle 19c e superior no Linux – ao mudar do armazenamento 512e para o armazenamento nativo 4K Os tamanhos dos setores de log devem ser alterados
  4. Para migrar do tamanho do setor 512/512e para o 4K Native Review (Doc ID 1133713.1) – consulte a seção "Migração offline para discos de setor de 4KB"
  5. SAPInst grava no pfile durante a instalação. Se o $ORACLE_HOME/dbs estiver em um conjunto de discos 4K filesystemio_options=asynch e consulte a seção "Suporte a arquivos de dados de discos de setor 4kB" em MOS Suportando discos de setor 4K (ID do documento 1133713.1)
  6. Sem suporte para ASM em plataformas Windows
  7. Não há suporte para o tamanho do setor nativo 4K para o volume de log em plataformas Windows. SSDv2 e Ultra Disk devem ser alterados para 512e através do ícone de lápis "Editar Disco" no Portal do Azure
  8. O tamanho do setor 4K Native é suportado apenas em volumes de dados para plataformas Windows. 4K não é suportado para volumes de log no Windows
  9. Recomendamos a revisão destes artigos do MOS:
    • Oracle Linux: Cache de buffer do sistema de arquivos versus E/S direta (ID do documento 462072.1)
    • Suporte a discos de setor 4K (ID do documento 1133713.1)
    • Usando 4k Redo Logs em Flash, 4k-Disk e armazenamento baseado em SSD (ID do documento 1681266.1)
    • Coisas a considerar para definir filesystemio_options e disk_asynch_io (Doc ID 1987437.1)

Recomendamos o uso do Oracle ASM no Linux com ASMLib. O desempenho, a administração, o suporte e a configuração são otimizados com o padrão de implantação. O Oracle ASM e o Oracle dNFS definirão os parâmetros corretos ou os parâmetros de bypass (como FILESYSTEMIO_OPTIONS) e, portanto, oferecerão melhor desempenho e confiabilidade.

Gerenciamento Automático de Armazenamento (ASM) Oracle

Lista de verificação para Oracle Automatic Storage Management:

  1. Todos os sistemas SAP on Oracle no Azure estão executando ASM , incluindo Desenvolvimento, Garantia de Qualidade e Produção. Bancos de dados pequenos, médios e grandes
  2. ASMLib é usado e não UDEV. O UDEV é necessário para várias SANs, um cenário que não existe no Azure
  3. O ASM deve ser configurado para redundância externa. O armazenamento SSD Premium do Azure fornece redundância tripla. O SSD Premium do Azure corresponde à fiabilidade e integridade de qualquer outra solução de armazenamento. Para segurança opcional, os clientes podem considerar redundância normal para o grupo de discos de log
  4. O espelhamento de arquivos Redo Log é opcional para ASM 888626 - Layout de log Redo para sistemas high-end
  5. Grupos de discos ASM configurados de acordo com a Variante 1, 2 ou 3 abaixo
  6. Tamanho da unidade de alocação ASM = 4MB (padrão). Os sistemas OLAP de bancos de dados muito grandes (VLDB), como o BW, podem se beneficiar de um tamanho maior da unidade de alocação ASM. Alterar somente após confirmação com suporte Oracle
  7. Tamanho do setor ASM e tamanho do setor lógico = padrão (UDEV não é recomendado, mas requer 4k)
  8. Se o COMPATÍVEL. O atributo de grupo de discos ASM é definido como 11.2 ou superior para um grupo de discos, você pode criar, copiar ou mover um Oracle ASM SPFILE para o sistema de arquivos ACFS. Analise a documentação do Oracle sobre como mover o pfile para o ACFS. O SAPInst não está criando o pfile no ACFS por padrão
  9. É utilizada a variante ASM apropriada. Os sistemas de produção devem utilizar as Variantes 2 ou 3

Grupos de discos do Oracle Automatic Storage Management

A Parte II do Guia Oráculo oficial descreve a instalação e o gerenciamento do ASM:

Os seguintes limites ASM existem para o Oracle Database 12c ou posterior:

511 grupos de discos, 10.000 discos ASM em um grupo de discos, 65.530 discos ASM em um sistema de armazenamento, 1 milhão de arquivos para cada grupo de discos. Mais informações aqui: Considerações sobre desempenho e escalabilidade para grupos de discos (oracle.com)

Consulte a documentação do ASM no Guia de Instalação SAP para Oracle relevante, disponível em https://help.sap.com/viewer/nwguidefinder

Variante 1 – volumes de dados pequenos a médios de até 3 TB, tempo de restauração não crítico

O cliente tem bancos de dados de pequeno ou médio porte onde o backup e/ou restauração + A recuperação de todos os bancos de dados pode ser realizada usando RMAN em tempo hábil. Exemplo: Quando um grupo de discos Oracle ASM completo, com arquivos de dados, de um ou mais bancos de dados é quebrado e todos os arquivos de dados de todos os bancos de dados precisam ser restaurados para um grupo de discos Oracle ASM recém-criado usando RMAN.

Recomendação do grupo de discos Oracle ASM:

Nome do grupo de discos ASM Lojas Armazenamento do Azure
+DADOS Todos os ficheiros de dados 3-6 x P 30 (1 TiB)
Arquivo de controle (primeira cópia) Para aumentar o tamanho do banco de dados, adicione discos P30 extras
Logs de refazer online (primeira cópia)
+ARCO Arquivo de controle (segunda cópia) 2 x P20 (512 GiB)
Logs de refazer arquivados
+RECO Arquivo de controle (terceira cópia) 2 x P20 (512 GiB)
Backups de RMAN (opcional)
área de recuperação (opcional)

Variante 2 – volumes de dados médios a grandes entre 3 TB e 12 TB, tempo de restauração importante

O cliente tem bancos de dados de médio a grande porte onde backup e/ou restauração +

A recuperação de todos os bancos de dados não pode ser realizada em tempo hábil.

Normalmente, os clientes estão usando RMAN, Backup do Azure para Oracle e/ou técnicas de snap de disco em combinação.

As principais diferenças em relação à Variante 1 são:

  1. Separe o Oracle ASM Disk Group para cada banco de dados
  2. <DBNAME>+"_" é usado como um prefixo para o nome do grupo de discos DATA
  3. O número do grupo de discos DATA será acrescentado se o banco de dados se estender por mais de um grupo de discos DATA
  4. Nenhum log de refazer online está localizado nos grupos de discos de "dados". Em vez disso, um grupo de disco extra é usado para o primeiro membro de cada grupo de log de refazer online.
Nome do grupo de discos ASM Lojas Armazenamento do Azure
+<DBNAME>_DATA[#] Todos os ficheiros de dados 3-12 x P 30 (1 TiB)
Todos os ficheiros temporários Para aumentar o tamanho do banco de dados, adicione discos P30 extras
Arquivo de controle (primeira cópia)
+OLOG Logs de refazer online (primeira cópia) 3 x P20 (512 GiB)
+ARCO Arquivo de controle (segunda cópia) 3 x P20 (512 GB)
Logs de refazer arquivados
+RECO Arquivo de controle (terceira cópia) 3 x P20 (512 GiB)
Backups de RMAN (opcional)
Área de recuperação rápida (opcional)

Variante 3 – enormes volumes de dados e alteração de dados superiores a 5 TB, tempo de restauro crucial

O cliente tem um enorme banco de dados onde o backup e/ou restauração + recuperação de um único banco de dados não pode ser realizado em tempo hábil.

Normalmente, os clientes estão usando RMAN, Backup do Azure para Oracle e/ou técnicas de snap de disco em combinação. Nesta variante, cada tipo de arquivo de banco de dados relevante é separado para diferentes grupos de discos Oracle ASM.

Nome do grupo de discos ASM Lojas Armazenamento do Azure
+<DBNAME>_DATA[#] Todos os ficheiros de dados 5-30 ou mais x P30 (1 TiB) ou P40 (2 TiB)
Todos os arquivos temporários Para aumentar o tamanho do banco de dados, adicione discos P30 extras
Arquivo de controle (primeira cópia)
+OLOG Logs de refazer online (primeira cópia) 3-8 x P20 (512 GiB) ou P30 (1 TiB)
Para maior segurança, a "Redundância Normal" pode ser selecionada para este Grupo de Discos ASM
+ARCO Arquivo de controle (segunda cópia) 3-8 x P20 (512 GiB) ou P30 (1 TiB)
Logs de refazer arquivados
+RECO Arquivo de controle (terceira cópia) 3 x P30 (1 TiB), P40 (2 TiB) ou P50 (4 TiB)
Backups de RMAN (opcional)
Área de recuperação rápida (opcional)

Nota

O Cache de Disco do Host do Azure para o Grupo de Discos ASM DATA pode ser definido como Somente Leitura ou Nenhum. Todos os outros grupos de discos ASM devem ser definidos como Nenhum. Em BW ou SCM, um grupo de discos ASM separado para TEMP pode ser considerado para sistemas grandes ou ocupados.

Adicionando espaço ao ASM + Azure Disks

Os grupos de discos Oracle ASM podem ser estendidos adicionando discos extras ou estendendo os discos atuais. Recomendamos adicionar discos extras em vez de estender discos existentes. Revise estes artigos e links do MOS Notas 1684112.1 e 2176737.1

O ASM adiciona um disco ao grupo de discos: asmca -silent -addDisk -diskGroupName DATA -disk '/dev/sdd1'

O ASM reequilibra automaticamente os dados. Para verificar o rebalanceamento, execute este comando.

ps -ef | grep rbal

oraasm 4288 1 0 Jul28 ? 00:04:36 asm_rbal_oradb1

A documentação está disponível com:

Monitorando SAP em sistemas Oracle ASM no Azure

Execute um relatório Oracle AWR como a primeira etapa ao solucionar um problema de desempenho. As métricas de desempenho do disco são detalhadas no relatório AWR.

O desempenho do disco pode ser monitorado de dentro do Oracle Enterprise Manager e por meio de ferramentas externas. A documentação, que pode ajudar, está disponível aqui:

As ferramentas de monitoramento no nível do sistema operacional não podem monitorar discos ASM, pois não há um sistema de arquivos reconhecível. O monitoramento do espaço livre deve ser feito de dentro da Oracle.

Recursos de treinamento sobre Oracle Automatic Storage Management (ASM)

Os DBAs Oracle que não estão familiarizados com o Oracle ASM seguem os materiais e recursos de treinamento aqui:

Arquivos NetApp do Azure (ANF) com Oracle dNFS (Direct NFS)

A combinação de VMs do Azure e ANF é uma combinação robusta e comprovada implementada por muitos clientes em uma escala excepcionalmente grande.

Bancos de dados de 100+ TB já estão sendo produtivos nessa combinação. Para começar, escrevemos um blog detalhado sobre como configurar essa combinação:

Mais informações gerais

O Mirror Log é necessário em sistemas dNFS ANF Production.

Embora o ANF seja altamente redundante, o Oracle ainda requer um volume de arquivo de log redo-espelhado. A recomendação é criar dois volumes separados e configurar origlogA juntamente com mirrlogB e origlogB juntamente com mirrlogA. Nesse caso, você faz uso de um balanceamento de carga distribuído dos redo-logfiles.

A opção de montagem "nconnect" não é recomendada quando o cliente dNFS está configurado. O dNFS gerencia o canal de E/S e faz uso de várias sessões, portanto, essa opção é obsoleta e pode causar vários problemas. O cliente dNFS vai ignorar as opções de montagem e vai lidar com o IO diretamente.

Ambas as versões NFS (v3 e v4.1) com ANF são suportadas para binários, dados e arquivos de log do Oracle.

É altamente recomendável usar o cliente Oracle dNFS para todos os volumes Oracle.

As opções de montagem recomendadas são:

Versão NFS Opções de montagem
NFSv3 rw,vers=3,rsize=262144,wsize=262144,hard,timeo=600,noatime
NFSv4.1 rw,vers=4.1,rsize=262144,wsize=262144,hard,timeo=600,noatime

ANF Backup

Com o ANF, alguns recursos importantes estão disponíveis, como backups consistentes baseados em snapshot, baixa latência e desempenho notavelmente alto. A partir da versão 6 da nossa ferramenta AzAcSnap Azure Application Consistent Snapshot tool for ANF, os bancos de dados Oracle podem ser configurados para instantâneos de banco de dados consistentes.

Esses snapshots permanecem no volume de dados real e devem ser copiados usando ANF, CRR (Cross Region Replication), replicação entre regiões de ANF ou outras ferramentas de backup.

SAP no Oracle no Azure com LVM

ASM é a recomendação padrão da Oracle para todos os sistemas SAP de qualquer tamanho no Azure. Desempenho, confiabilidade e suporte são melhores para os clientes que usam ASM. A Oracle fornece documentação e treinamento para DBAs fazerem a transição para ASM. Nos casos em que a equipe de DBA Oracle não segue a recomendação da Oracle, Microsoft e SAP para usar ASM, a seguinte configuração LVM deve ser usada.

Observe que: ao criar LVM, a opção "-i" deve ser usada para distribuir uniformemente os dados pelo número de discos no grupo LVM.

O Mirror Log é necessário ao executar o LVM.

Configuração mínima Linux:

Componente Disk Host Cache Listras1
/oracle/<SID>/origlogaA & mirrlogB Premium Nenhuma Não necessário
/oracle/<SID>/origlogaB & mirrlogA Premium Nenhuma Não necessário
/oracle/<SID>/sapdata1... n Premium Somente leitura2 Recomendado
/oracle/<SID>/oraarch3 Premium Nenhuma Não necessário
Oracle Home, saptrace, ... Premium Nenhuma Nenhuma
  1. Striping: Faixa LVM usando RAID0
  2. Durante as migrações do R3Load, a opção Host Cache para SAPDATA deve ser definida como Nenhum
  3. oraarch: LVM é opcional

A seleção de disco para hospedar os logs de refazer on-line da Oracle é orientada pelos requisitos de IOPS. É possível armazenar todos os sapdata1... n (espaços de tabela) em um único disco montado, desde que o volume, IOPS e taxa de transferência satisfaçam os requisitos.

Configuração de desempenho Linux:

Componente Disk Host Cache Listras1
/oracle/<SID>/origlogaA Premium Nenhuma Pode ser usado
/oracle/<SID>/origlogaB Premium Nenhuma Pode ser usado
/oracle/<SID>/mirrlogAB Premium Nenhuma Pode ser usado
/oracle/<SID>/mirrlogBA Premium Nenhuma Pode ser usado
/oracle/<SID>/sapdata1... n Premium Somente leitura2 Recomendado
/oracle/<SID>/oraarch3 Premium Nenhuma Não necessário
Oracle Home, saptrace, ... Premium Nenhuma Nenhuma
  1. Striping: Faixa LVM usando RAID0
  2. Durante as migrações do R3load, a opção Host Cache para SAPDATA deve ser definida como Nenhum
  3. oraarch: LVM é opcional

Azure Infra: Limites de Taxa de Transferência da Máquina Virtual & Opções de Armazenamento em Disco do Azure

O Oracle Automatic Storage Management (ASM)## pode avaliar estas tecnologias de armazenamento:

  1. Armazenamento Premium do Azure – atualmente a opção padrão
  2. Bursting de disco gerenciado - Bursting de disco gerenciado - Máquinas Virtuais do Azure | Documentos Microsoft
  3. Azure Write Accelerator
  4. A extensão de disco online para armazenamento SSD Premium do Azure ainda está em andamento

Os tempos de gravação de log podem ser aprimorados em VMs do Azure M-Series habilitando o Acelerador de Gravação. Habilite o Azure Write Accelerator para os discos de Armazenamento Premium do Azure usados pelo ASM Disk Group para arquivos de log de refazer online. Para obter mais informações, consulte Acelerador de gravação.

O uso do Acelerador de Gravação é opcional, mas pode ser habilitado se o relatório AWR indicar tempos de gravação de log superiores ao esperado.

Limites de taxa de transferência da máquina virtual do Azure

Cada tipo de máquina virtual (VM) do Azure tem limites para CPU, disco, rede e RAM. Esses limites estão documentados nos links abaixo

As seguintes recomendações devem ser seguidas ao selecionar um tipo de VM:

  1. Verifique se a taxa de transferência de disco e IOPS é suficiente para a carga de trabalho e pelo menos igual à taxa de transferência agregada dos discos
  2. Considere habilitar o bursting pago especialmente para o(s) disco(s) Redo Log
  3. Para ANF, a taxa de transferência de rede é importante, pois todo o tráfego de armazenamento é contado como "Rede" em vez de taxa de transferência de disco
  4. Revise este blog para Ajuste de rede para a série M Otimizando a taxa de transferência de rede no Azure M-series VMs HCMT (microsoft.com)
  5. Analise este link que descreve como usar um relatório AWR para selecionar a VM do Azure correta
  6. Azure Intel Ev5 Edv5 e Edsv5-series - Máquinas Virtuais do Azure |Documentos Microsoft
  7. Azure AMD Eadsv5 Easv5 e Eadsv5-series - Máquinas Virtuais do Azure |Documentos Microsoft
  8. Azure M-series/Msv2-series M-series - Máquinas Virtuais do Azure |Microsoft Docs e Msv2/Mdsv2 Medium Memory Series - Máquinas Virtuais do Azure | Documentos Microsoft
  9. Azure Mv2 Mv2-series - Máquinas Virtuais do Azure | Documentos Microsoft

Cópia de segurança/restauro

Para a funcionalidade de backup/restauração, o SAP BR*Tools for Oracle é suportado da mesma forma que no bare metal e no Hyper-V. O Oracle Recovery Manager (RMAN) também é suportado para backups em disco e restaurações a partir do disco.

Para obter mais informações sobre como você pode usar os serviços de Backup e Recuperação do Azure para bancos de dados Oracle, consulte:

Elevada disponibilidade

O Oracle Data Guard é suportado para fins de alta disponibilidade e recuperação de desastres. Para obter failover automático no Data Guard, você precisa usar o Fast-Start Failover (FSFA). A funcionalidade Observador (FSFA) aciona o failover. Se você não usa o FSFA, só pode usar uma configuração manual de failover. Para obter mais informações, consulte Implementar o Oracle Data Guard em uma máquina virtual Linux do Azure.

Os aspetos de recuperação de desastres para bancos de dados Oracle no Azure são apresentados no artigo Recuperação de desastres para um banco de dados Oracle Database 12c em um ambiente do Azure.

Outro bom whitepaper da Oracle Configurando o Oracle 12c Data Guard para clientes SAP

Páginas enormes & Grandes configurações do Oracle SGA

O VLDB SAP on Oracle em implantações do Azure aplica tamanhos SGA superiores a 3 TB. As versões modernas do Oracle lidam bem com grandes tamanhos de SGA e reduzem significativamente a E/S. Revise o relatório AWR e aumente o tamanho do SGA para reduzir a E/S de leitura. 

Como orientação geral, o Linux Huge Pages deve ser configurado para aproximadamente 75% do tamanho da RAM da VM. O tamanho SGA pode ser definido como 90% do tamanho da página enorme. Um exemplo aproximado seria uma VM M192ms com 4 TB de RAM teria Huge Pages definido proximamente 3 TB.  O SGA pode ser definido para um valor um pouco menor, como 2,95 TB.

Grandes clientes SAP que executam VMs do Azure de alta memória se beneficiam muito do HugePages, conforme descrito neste artigo

Os sistemas NUMA vm.min_free_kbytes devem ser definidos como 524288 * <# dos nós> NUMA. Consulte Oracle Linux : Valor recomendado de vm.min_free_kbytes parâmetro de ajuste do kernel (ID do documento 2501269.1...

 

O Oracle Linux fornece um utilitário de gerenciamento de GUI útil:

Oracle Linux tem uma nova ferramenta de gerenciamento de pacotes – DNF

Oracle Linux 8: Gerenciamento de pacotes facilitado com vídeos gratuitos | Oracle Linux Blog

Oracle® Linux 8 Managing Software em Oracle Linux - Capítulo 1 Yum DNF

As configurações de memória e NUMA podem ser testadas e comparadas com uma ferramenta útil - Oracle Real Application Testing (RAT)

Oracle Real Application Testing: O que é e como usá-lo? (aemcorp.com)

Informações sobre o problema de corrupção de log UDEV Oracle Redolog corrupção no Azure | Oracle no campo (wordpress.com)

Oracle ASM na corrupção do Azure - acompanhamento (dbaharrison.blogspot.com)

Corrupção de dados no Hyper-V ou Azure ao executar o Oracle ASM - Red Hat Customer Portal

Configurar o Oracle ASM em uma máquina virtual Linux do Azure - Máquinas Virtuais do Azure | Documentos Microsoft

Diretrizes de configuração do Oracle para instalações SAP em VMs do Azure no Windows

O SAP on Oracle no Azure também suporta Windows. As recomendações para implantações do Windows estão resumidas abaixo:

  1. As seguintes versões do Windows são recomendadas: Windows Server 2022 (somente do Oracle Database 19.13.0 em diante) Windows Server 2019 (somente do Oracle Database 19.5.0 em diante)
  2. Não há suporte para ASM no Windows. Os Espaços de Armazenamento do Windows devem ser usados para agregar discos para um desempenho ideal
  3. Instale o Oracle Home em um disco independente dedicado (não instale o Oracle Home na unidade C:)
  4. Todos os discos devem ser formatados NTFS
  5. Siga o guia de Ajuste do Windows da Oracle e habilite páginas grandes, bloqueie páginas na memória e outras configurações específicas do Windows

No momento, não há suporte para escrever ASM para clientes Windows no Azure. O SAP Software Provisioning Manager (SWPM) para Windows não suporta ASM atualmente.

Configurações de armazenamento para SAP no Oracle no Windows

Configuração mínima do Windows:

Componente Disk Host Cache Listras1
E:\oracle\<SID>\origlogaA & mirrlogB Premium Nenhuma Não necessário
F:\oracle\<SID>\origlogaB & mirrlogA Premium Nenhuma Não necessário
G:\oracle\<SID>\sapdata1... n Premium Somente leitura2 Recomendado
H:\oracle\<SID>\oraarch3 Premium Nenhuma Não necessário
I:\Oracle Home, saptrace, ... Premium Nenhuma Nenhuma
  1. Striping: Espaços de armazenamento do Windows
  2. Durante as migrações do R3load, a opção Host Cache para SAPDATA deve ser definida como Nenhum
  3. oraarch: Espaços de Armazenamento do Windows é opcional

A seleção de disco para hospedar os logs de refazer on-line da Oracle é orientada pelos requisitos de IOPS. É possível armazenar todos os sapdata1... n (espaços de tabela) em um único disco montado, desde que o volume, IOPS e taxa de transferência satisfaçam os requisitos.

Configuração de desempenho do Windows:

Componente Disk Host Cache Listras1
E:\oracle\<SID>\origlogaA Premium Nenhuma Pode ser usado
F:\oracle\<SID>\origlogaB Premium Nenhuma Pode ser usado
G:\oracle\<SID>\mirrlogAB Premium Nenhuma Pode ser usado
H:\oracle\<SID>\mirrlogBA Premium Nenhuma Pode ser usado
I:\oracle\<SID>\sapdata1... n Premium Somente leitura2 Recomendado
J:\oracle\<SID>\oraarch3 Premium Nenhuma Não necessário
K:\Oracle Home, saptrace, ... Premium Nenhuma Nenhuma
  1. Striping: Espaços de armazenamento do Windows
  2. Durante as migrações do R3load, a opção Host Cache para SAPDATA deve ser definida como Nenhum
  3. oraarch: Espaços de Armazenamento do Windows é opcional

Próximos passos

Leia o artigo