Desempenho do banco de dados Oracle no Azure NetApp Arquivos vários volumes

A migração de bancos de dados de alto desempenho de nível Exadata para a nuvem está se tornando cada vez mais um imperativo para os clientes da Microsoft. Os pacotes de software da cadeia de suprimentos normalmente definem a barra alta devido às intensas demandas de E/S de armazenamento com uma carga de trabalho mista de leitura e gravação impulsionada por um único nó de computação. A infraestrutura do Azure em combinação com os Arquivos NetApp do Azure é capaz de atender às necessidades dessa carga de trabalho altamente exigente. Este artigo apresenta um exemplo de como essa demanda foi atendida para um cliente e como o Azure pode atender às demandas de suas cargas de trabalho críticas da Oracle.

Desempenho Oracle em escala empresarial

Ao explorar os limites superiores de desempenho, é importante reconhecer e reduzir quaisquer restrições que possam distorcer falsamente os resultados. Por exemplo, se a intenção for provar os recursos de desempenho de um sistema de armazenamento, o cliente deve idealmente ser configurado para que a CPU não se torne um fator atenuante antes que os limites de desempenho de armazenamento sejam atingidos. Para esse fim, os testes começaram com o tipo de instância E104ids_v5, pois essa VM vem equipada não apenas com uma interface de rede de 100 Gbps, mas com um limite de saída igualmente grande (100 Gbps).

Os testes ocorreram em duas fases:

1. A primeira fase concentrou-se nos testes usando a ferramenta SLOB2 (Silly Little Oracle Benchmark) de Kevin Closson, agora padrão da indústria - versão 2.5.4. O objetivo é direcionar o máximo possível de E/S Oracle de uma máquina virtual (VM) para vários volumes do Azure NetApp Files e, em seguida, expandir usando mais bancos de dados para demonstrar o dimensionamento linear.
2. Depois de testar os limites de escala, nossos testes mudaram para o E96ds_v5 mais barato, mas quase tão capaz, para uma fase de testes do cliente usando uma verdadeira carga de trabalho de aplicativos da cadeia de suprimentos e dados do mundo real.

Desempenho de scale-up SLOB2

Os gráficos a seguir capturam o perfil de desempenho de uma única VM do E104ids_v5 Azure executando um único banco de dados Oracle 19c em relação a oito volumes de Arquivos NetApp do Azure com oito pontos de extremidade de armazenamento. Os volumes estão distribuídos em três grupos de discos ASM: dados, log e arquivamento. Cinco volumes foram alocados para o grupo de discos de dados, dois volumes para o grupo de discos de log e um volume para o grupo de discos de arquivamento. Todos os resultados capturados ao longo deste artigo foram coletados usando regiões do Azure de produção e serviços ativos do Azure de produção.

Para implantar o Oracle em máquinas virtuais do Azure usando vários volumes do Azure NetApp Files em vários pontos de extremidade de armazenamento, use o grupo de volumes de aplicativos para Oracle.

Arquitetura de host único

O diagrama a seguir mostra a arquitetura contra a qual o teste foi concluído; observe o banco de dados Oracle espalhado por vários volumes e pontos de extremidade do Azure NetApp Files.

E/S de armazenamento de host único

O diagrama a seguir mostra uma carga de trabalho 100% selecionada aleatoriamente com uma taxa de acertos do buffer do banco de dados de cerca de 8%. O SLOB2 foi capaz de gerar aproximadamente 850.000 solicitações de E/S por segundo, mantendo uma latência de evento de leitura sequencial de arquivo de banco de dados de submilissegundos. Com um tamanho de bloco de banco de dados de 8K que equivale a aproximadamente 6.800 MiB/s de taxa de transferência de armazenamento.

Taxa de transferência de host único

O diagrama a seguir demonstra que, para cargas de trabalho de E/S sequenciais com uso intensivo de largura de banda, como verificações de tabela completa ou atividades de RMAN, os Arquivos NetApp do Azure podem fornecer os recursos completos de largura de banda da própria VM E104ids_v5.

Nota

Como a instância de computação está no máximo teórico de sua largura de banda, adicionar simultaneidade de aplicativo adicional resulta apenas em maior latência do lado do cliente. Isso resulta em cargas de trabalho SLOB2 excedendo o prazo de conclusão pretendido, portanto, a contagem de threads foi limitada a seis.

Desempenho de expansão SLOB2

Os gráficos a seguir capturam o perfil de desempenho de três VMs E104ids_v5 Azure, cada uma executando um único banco de dados Oracle 19c e cada uma com seu próprio conjunto de volumes de Arquivos NetApp do Azure e um layout de grupo de discos ASM idêntico, conforme descrito na seção Aumentar o desempenho. Os gráficos mostram que, com os Arquivos NetApp do Azure com vários volumes/vários pontos de extremidade, o desempenho é facilmente dimensionado com consistência e previsibilidade.

Arquitetura multi-host

O diagrama a seguir mostra a arquitetura contra a qual o teste foi concluído; observe os três bancos de dados Oracle espalhados por vários volumes e pontos de extremidade do Azure NetApp Files. Os endpoints podem ser dedicados a um único host, conforme mostrado com o Oracle VM 1, ou compartilhados entre hosts, como mostrado com o Oracle VM2 e o Oracle VM 3.

E/S de armazenamento de vários hosts

O diagrama a seguir mostra uma carga de trabalho 100% selecionada aleatoriamente com uma taxa de acertos do buffer do banco de dados de cerca de 8%. O SLOB2 foi capaz de gerar aproximadamente 850.000 solicitações de E/S por segundo em todos os três hosts individualmente. O SLOB2 foi capaz de fazer isso enquanto executava em paralelo um total coletivo de cerca de 2.500.000 solicitações de E/S por segundo, com cada host ainda mantendo uma latência de evento de leitura sequencial de arquivo db de submilissegundos. Com um tamanho de bloco de banco de dados de 8K, isso equivale a aproximadamente 20.000 MiB/s entre os três hosts.

Taxa de transferência de vários hosts

O diagrama a seguir demonstra que, para cargas de trabalho sequenciais, os Arquivos NetApp do Azure ainda podem fornecer todos os recursos de largura de banda da própria VM E104ids_v5, mesmo quando ela é dimensionada para fora. O SLOB2 foi capaz de conduzir E/S totalizando mais de 30.000 MiB/s nos três hosts enquanto funcionava em paralelo.

Desempenho no mundo real

Depois que os limites de dimensionamento foram testados com SLOB2, os testes foram conduzidos com um pacote de aplicativos de cadeia de suprimentos de palavra real contra Oracle em arquivos NetApp do Azure com excelentes resultados. Os dados a seguir do relatório Oracle Automatic Workload Repository (AWR) são uma visão destacada de como um trabalho crítico específico foi executado.

Este banco de dados tem E/S extra significativa acontecendo, além da carga de trabalho do aplicativo devido ao flashback estar habilitado e tem um tamanho de bloco de banco de dados de 16k. Na seção de perfil IO do relatório AWR, é evidente que há uma grande proporção de gravações em comparação com leituras.

-	Ler e escrever por segundo	Leitura por segundo	Escrever por segundo
Total (MB)	4,988.1	1,395.2	3,592.9

Apesar do evento de espera de leitura sequencial do arquivo db mostrar uma latência maior em 2,2 ms do que no teste SLOB2, esse cliente viu uma redução de quinze minutos no tempo de execução do trabalho vindo de um banco de dados RAC no Exadata para um banco de dados de instância única no Azure.

Restrições de recursos do Azure

Todos os sistemas acabam por atingir restrições de recursos, tradicionalmente conhecidas como pontos de estrangulamento. As cargas de trabalho de banco de dados, especialmente as altamente exigentes, como pacotes de aplicativos da cadeia de suprimentos, são entidades que consomem muitos recursos. Encontrar essas restrições de recursos e trabalhar com elas é vital para qualquer implantação bem-sucedida. Esta seção ilumina várias restrições que você pode esperar encontrar em tal ambiente e como trabalhar com elas. Em cada subseção, espere aprender as melhores práticas e a lógica por trás delas.

Máquinas virtuais

Esta seção detalha os critérios a serem considerados na seleção de VMs para melhor desempenho e a lógica por trás das seleções feitas para testes. Os Arquivos NetApp do Azure são um serviço NAS (Network Attached Storage, armazenamento conectado à rede), portanto, o dimensionamento adequado da largura de banda da rede é essencial para o desempenho ideal.

Chipsets

O primeiro tópico de interesse é a seleção de chipsets. Certifique-se de que qualquer SKU de VM selecionada seja construída em um único chipset por motivos de consistência. A variante Intel de E_v5 VMs é executada em uma configuração Intel Xeon Platinum 8370C (Ice Lake) de terceira geração. Todas as VMs desta família vêm equipadas com uma única interface de rede de 100 Gbps. Em contraste, a série E_v3, mencionada a título de exemplo, é construída em quatro chipsets separados, com várias larguras de banda de rede física. Os quatro chipsets usados na família E_v3 (Broadwell, Skylake, Cascade Lake, Haswell) têm velocidades de processador diferentes, o que afeta as características de desempenho da máquina.

Leia atentamente a documentação do Azure Compute, prestando atenção às opções do chipset. Consulte também as práticas recomendadas de SKUs de VM do Azure para Arquivos NetApp do Azure. Selecionar uma VM com um único chipset é preferível para melhor consistência.

Largura de banda de rede disponível

É importante entender a diferença entre a largura de banda disponível da interface de rede VM e a largura de banda limitada aplicada em relação à mesma. Quando a documentação do Azure Compute fala sobre limites de largura de banda de rede, esses limites são aplicados apenas na saída (gravação). O tráfego de entrada (leitura) não é medido e, como tal, é limitado apenas pela largura de banda física da própria placa de interface de rede (NIC). A largura de banda de rede da maioria das VMs supera o limite de saída aplicado contra a máquina.

Como os volumes de Arquivos NetApp do Azure são anexados à rede, o limite de saída pode ser entendido como sendo aplicado especificamente contra gravações, enquanto a entrada é definida como leituras e cargas de trabalho semelhantes a leitura. Embora o limite de saída da maioria das máquinas seja maior do que a largura de banda de rede da NIC, o mesmo não pode ser dito para o E104_v5 usado nos testes deste artigo. O E104_v5 tem uma NIC de 100 Gbps com o limite de saída definido em 100 Gbps também. Em comparação, o E96_v5, com sua NIC de 100 Gbps, tem um limite de saída de 35 Gbps com entrada irrestrita a 100 Gbps. À medida que as VMs diminuem de tamanho, os limites de saída diminuem, mas a entrada permanece livre de limites logicamente impostos.

Os limites de saída abrangem toda a VM e são aplicados como tal em todas as cargas de trabalho baseadas em rede. Ao usar o Oracle Data Guard, todas as gravações são dobradas para arquivar logs e devem ser fatoradas para considerações de limite de saída. Isso também é verdade para o log de arquivamento com multidestino e RMAN, se usado. Ao selecionar VMs, familiarize-se com ferramentas de linha de comando como ethtool, que expõem a configuração da NIC, pois o Azure não documenta as configurações da interface de rede.

Simultaneidade de rede

Os volumes de VMs do Azure e Arquivos NetApp do Azure vêm equipados com quantidades específicas de largura de banda. Como mostrado anteriormente, desde que uma VM tenha espaço suficiente para a CPU, uma carga de trabalho pode, em teoria, consumir a largura de banda disponibilizada para ela - ou seja, dentro dos limites da placa de rede e/ou limite de saída aplicado. Na prática, no entanto, a quantidade de taxa de transferência alcançável é baseada na simultaneidade da carga de trabalho na rede, ou seja, o número de fluxos de rede e pontos de extremidade de rede.

Leia a seção de limites de fluxo de rede do documento de largura de banda da rede VM para obter uma maior compreensão sobre. A conclusão: quanto mais fluxos de rede conectando o cliente ao armazenamento, mais rico será o desempenho potencial.

A Oracle suporta dois clientes NFS separados, Kernel NFS e Direct NFS (dNFS). O NFS do kernel, até tarde, suportava um único fluxo de rede entre dois pontos finais (computação – armazenamento). O NFS direto, o mais eficiente dos dois, suporta um número variável de fluxos de rede – os testes mostraram centenas de conexões exclusivas por ponto final – aumentando ou diminuindo conforme as demandas de carga. Devido ao dimensionamento dos fluxos de rede entre dois pontos finais, o Direct NFS é muito mais preferido do que o Kernel NFS e, como tal, a configuração recomendada. O grupo de produtos Arquivos NetApp do Azure não recomenda o uso do Kernel NFS com cargas de trabalho Oracle. Para obter mais informações, consulte os Benefícios do uso de arquivos NetApp do Azure com o Banco de Dados Oracle.

Simultaneidade de execução

Utilizar o Direct NFS, um único chipset para consistência e entender as restrições de largura de banda da rede só leva você tão longe. No final, o aplicativo impulsiona o desempenho. Provas de conceito usando SLOB2 e provas de conceito usando um pacote de aplicativos da cadeia de suprimentos do mundo real contra dados reais de clientes foram capazes de gerar quantidades significativas de taxa de transferência apenas porque os aplicativos eram executados em altos graus de simultaneidade; o primeiro usando um número significativo de threads por esquema, o segundo usando várias conexões de vários servidores de aplicativos. Em resumo, a simultaneidade gera carga de trabalho, baixa simultaneidade - baixa taxa de transferência, alta simultaneidade - alta taxa de transferência, desde que a infraestrutura esteja pronta para suportar a mesma.

Rede acelerada

A rede acelerada permite a virtualização de entrada/saída de raiz única (SR-IOV) para uma VM, o que melhora muito o desempenho da rede. Este percurso de alto desempenho ignora o anfitrião no caminho de dados, o que reduz a latência, a instabilidade e a utilização da CPU das cargas de trabalho da rede mais exigentes nos tipos de VM suportadas. Ao implantar VMs por meio de utilitários de gerenciamento de configuração, como terraform ou linha de comando, lembre-se de que a rede acelerada não está habilitada por padrão. Para um desempenho ideal, habilite a rede acelerada. Tome nota, a rede acelerada é ativada ou desativada em uma interface de rede por interface de rede. O recurso de rede acelerada é aquele que pode ser ativado ou desativado dinamicamente.

Nota

Este artigo contém referências ao termo SLAVE, um termo que a Microsoft já não utiliza. Quando o termo for removido do software, iremos removê-lo deste artigo.

Uma abordagem autoritativa para a rede acelerada subsequente é habilitada para uma NIC é através do terminal Linux. Se a rede acelerada estiver habilitada para uma NIC, uma segunda NIC virtual estará presente associada à primeira NIC. Esta segunda NIC é configurada pelo sistema com o SLAVE sinalizador ativado. Se nenhuma NIC estiver presente com o sinalizador, a rede acelerada não estará habilitada SLAVE para essa interface.

No cenário em que várias NICs são configuradas, você precisa determinar qual SLAVE interface está associada à NIC usada para montar o volume NFS. Adicionar placas de interface de rede à VM não tem efeito sobre o desempenho.

Use o processo a seguir para identificar o mapeamento entre a interface de rede configurada e sua interface virtual associada. Esse processo valida que a rede acelerada está habilitada para uma NIC específica em sua máquina Linux e exibe a velocidade de entrada física que a NIC pode alcançar.

1. Execute o ip a comando:
2. Liste o /sys/class/net/ diretório da ID da NIC que você está verificando (eth0 no exemplo) e grep para a palavra inferior:

   ls /sys/class/net/eth0 | grep lower lower_eth1
   

3. Execute o ethtool comando no dispositivo ethernet identificado como o dispositivo inferior na etapa anterior.

VM do Azure: limites de largura de banda de rede versus disco

É necessário um nível de especialização ao ler a documentação dos limites de desempenho da VM do Azure. Esteja atento a:

• A taxa de transferência de armazenamento temporário e os números IOPS referem-se aos recursos de desempenho do armazenamento efémero on-box diretamente conectado à VM.
• A taxa de transferência de disco não armazenada em cache e os números de E/S referem-se especificamente ao Disco do Azure (Premium, Premium v2 e Ultra) e não têm qualquer influência no armazenamento conectado à rede, como os Arquivos NetApp do Azure.
• Anexar NICs adicionais à VM não tem impacto nos limites de desempenho ou nos recursos de desempenho da VM (documentados e testados como verdadeiros).
• A largura de banda máxima da rede refere-se aos limites de saída (ou seja, gravações quando os Arquivos NetApp do Azure estão envolvidos) aplicados à largura de banda da rede VM. Nenhum limite de entrada (ou seja, leituras quando os Arquivos NetApp do Azure estão envolvidos) é aplicado. Com CPU suficiente, simultaneidade de rede suficiente e pontos de extremidade ricos o suficiente, uma VM poderia, teoricamente, direcionar o tráfego de entrada para os limites da NIC. Conforme mencionado na seção Largura de banda de rede disponível, use ferramentas como ethtool ver a largura de banda da NIC.

Um gráfico de exemplo é mostrado para referência:

Azure NetApp Files

O serviço de armazenamento primário do Azure Azure NetApp Files fornece uma solução de armazenamento totalmente gerenciada altamente disponível capaz de suportar as exigentes cargas de trabalho Oracle introduzidas anteriormente.

Como os limites do desempenho de armazenamento em expansão em um banco de dados Oracle são bem compreendidos, este artigo se concentra intencionalmente no desempenho de armazenamento em expansão. Dimensionar o desempenho do armazenamento implica dar a uma única instância Oracle acesso a muitos volumes do Azure NetApp Files onde esses volumes são distribuídos em vários pontos de extremidade de armazenamento.

Ao dimensionar uma carga de trabalho de banco de dados em vários volumes dessa forma, o desempenho do banco de dados fica desvinculado dos limites superiores de volume e ponto final. Com o armazenamento não impondo mais limitações de desempenho, a arquitetura da VM (limites de saída de CPU, NIC e VM) torna-se o ponto de estrangulamento a ser enfrentado. Conforme observado na seção VM, a seleção dos E104ids_v5 e E96ds_v5 instâncias foi feita tendo isso em mente.

Se um banco de dados é colocado em um único grande volume de capacidade ou distribuído por vários volumes menores, o custo financeiro total é o mesmo. A vantagem de distribuir E/S em vários volumes e pontos finais em contraste com um único volume e ponto final é evitar limites de largura de banda - você pode usar inteiramente o que paga.

Importante

Para implantar usando os Arquivos NetApp do Azure em uma multiple volume:multiple endpoint configuração, entre em contato com seu Especialista em Arquivos NetApp do Azure ou com o Arquiteto de Soluções na Nuvem para obter assistência.

Base de Dados

A versão 19c do banco de dados Oracle é a versão atual de lançamento de longo prazo da Oracle e a usada para produzir todos os resultados de teste discutidos neste artigo.

Para obter o melhor desempenho, todos os volumes de banco de dados foram montados usando o Direct NFS, o Kernel NFS é recomendado devido a restrições de desempenho. Para obter uma comparação de desempenho entre os dois clientes, consulte Desempenho do banco de dados Oracle em volumes únicos do Azure NetApp Files. Observe que todos os patches dNFS relevantes (Oracle Support ID 1495104) foram aplicados, assim como as práticas recomendadas descritas no relatório Oracle Databases on Microsoft Azure using Azure NetApp Files .

Embora o Oracle e o Azure NetApp Files ofereçam suporte a NFSv3 e NFSv4.1, como o NFSv3 é o protocolo mais maduro, geralmente é visto como tendo mais estabilidade e é a opção mais confiável para ambientes altamente sensíveis a interrupções. Os testes descritos neste artigo foram todos concluídos sobre NFSv3.

Importante

Alguns dos patches recomendados que a Oracle documenta no Support ID 1495104 são críticos para manter a integridade dos dados ao usar o dNFS. A aplicação de tais patches é fortemente aconselhada para ambientes de produção.

O gerenciamento automático de armazenamento (ASM) é suportado para volumes NFS. Embora normalmente associado ao armazenamento baseado em blocos, em que o ASM substitui o LVM (gerenciamento de volumes lógicos) e o sistema de arquivos, o ASM desempenha um papel valioso em cenários NFS de vários volumes e merece uma forte consideração. Uma dessas vantagens do ASM, a adição e o reequilíbrio on-line dinâmicos em volumes e endpoints NFS recém-adicionados, simplifica o gerenciamento, permitindo a expansão do desempenho e da capacidade à vontade. Embora o ASM por si só não aumente o desempenho de um banco de dados, seu uso evita arquivos quentes e a necessidade de manter manualmente a distribuição de arquivos - um benefício fácil de ver.

Uma configuração ASM sobre dNFS foi usada para produzir todos os resultados de teste discutidos neste artigo. O diagrama a seguir ilustra o layout do arquivo ASM nos volumes do Azure NetApp Files e a alocação de arquivos para os grupos de discos ASM.

Há algumas limitações com o uso do ASM sobre os volumes montados no Azure NetApp Files NFS quando se trata de instantâneos de armazenamento que podem ser superados com determinadas considerações de arquitetura. Entre em contato com seu especialista em Arquivos NetApp do Azure ou arquiteto de soluções de nuvem para obter uma análise aprofundada dessas considerações.

Ferramentas de teste sintéticas e sintonizáveis

Esta seção descreve a arquitetura de teste, os ajustáveis e os detalhes de configuração em detalhes. Enquanto a seção anterior é focada nas razões pelas quais as decisões de configuração são tomadas, esta seção se concentra especificamente no "quê" das decisões de configuração.

Implementação automatizada

• As VMs de banco de dados são implantadas usando scripts bash disponíveis no GitHub.
• O layout e a alocação de vários volumes e pontos de extremidade dos Arquivos NetApp do Azure são concluídos manualmente. Você precisa trabalhar com seu Especialista em Arquivos NetApp do Azure ou Arquiteto de Soluções na Nuvem para obter assistência.
• A instalação em grade, a configuração ASM, a criação e configuração do banco de dados e o ambiente SLOB2 em cada máquina são configurados usando o Ansible para consistência.
• As execuções de teste SLOB2 paralelas em vários hosts também são concluídas usando o Ansible para consistência e execução simultânea.

Configuração da VM

Configuração	Value
Região do Azure	Europa Ocidental
SKU da VM	E104ids_v5
Contagem de NIC	1 NOTA: Adicionar vNICs não tem efeito na contagem do sistema
Max largura de banda de rede de saída (Mbps)	100.000
Armazenamento (SSD) temporário GiB	3,800

Configuração do sistema

Todas as definições de configuração do sistema Oracle necessárias para a versão 19c foram implementadas de acordo com a documentação da Oracle.

Os seguintes parâmetros foram adicionados ao arquivo de /etc/sysctl.conf sistema Linux:

• sunrpc.max_tcp_slot_table_entries: 128
• sunrpc.tcp_slot_table_entries = 128

Azure NetApp Files

Todos os volumes do Azure NetApp Files foram montados com as seguintes opções de montagem NFS.

nfs rw,hard,rsize=262144,wsize=262144,sec=sys,vers=3,tcp

Parâmetros do banco de dados

Parâmetros	Value
db_cache_size	2g
large_pool_size	2g
pga_aggregate_target	3g
pga_aggregate_limit	3g
sga_target	25gr
shared_io_pool_size	500m
shared_pool_size	5g
db_files	500
filesystemio_options	SETALL
job_queue_processes	0
db_flash_cache_size	0
_cursor_obsolete_threshold	130
_db_block_prefetch_limit	0
_db_block_prefetch_quota	0
_db_file_noncontig_mblock_read_count	0

Configuração SLOB2

Toda a geração de carga de trabalho para teste foi concluída usando a ferramenta SLOB2 versão 2.5.4.

Quatorze esquemas SLOB2 foram carregados em um espaço de tabela Oracle padrão e executados contra, o que, em combinação com as definições do arquivo de configuração de slob listadas, colocou o conjunto de dados SLOB2 em 7 TiB. As configurações a seguir refletem uma execução de leitura aleatória para SLOB2. O parâmetro SCAN_PCT=0 de configuração foi alterado para durante o SCAN_PCT=100 teste sequencial.

• UPDATE_PCT=0
• SCAN_PCT=0
• RUN_TIME=600
• SCALE=450G
• SCAN_TABLE_SZ=50G
• WORK_UNIT=32
• REDO_STRESS=LITE
• THREADS_PER_SCHEMA=1
• DATABASE_STATISTICS_TYPE=awr

Para o teste de leitura aleatória, foram realizadas nove execuções SLOB2. A contagem de threads foi aumentada em seis com cada iteração de teste começando de uma.

Para testes sequenciais, foram realizadas sete execuções SLOB2. A contagem de threads foi aumentada em dois com cada iteração de teste começando de uma. A contagem de threads foi limitada a seis devido ao alcance dos limites máximos de largura de banda da rede.

Métricas AWR

Todas as métricas de desempenho foram reportadas através do Oracle Automatic Workload Repository (AWR). A seguir estão as métricas apresentadas nos resultados:

• Taxa de transferência: a soma da taxa de transferência média de leitura e gravação da seção Perfil de carga AWR
• Média de solicitações de E/S lidas da seção Perfil de carga do AWR
• tempo médio médio de espera do evento de espera de leitura sequencial do arquivo db da seção Eventos de espera em primeiro plano do AWR

Migração de sistemas projetados especificamente para a nuvem

O Oracle Exadata é um sistema projetado - uma combinação de hardware e software que é considerada a solução mais otimizada para executar cargas de trabalho Oracle. Embora a nuvem tenha vantagens significativas no esquema geral do mundo técnico, esses sistemas especializados podem parecer incrivelmente atraentes para aqueles que leram e visualizaram as otimizações que a Oracle construiu em torno de sua(s) carga de trabalho específica.

Quando se trata de executar o Oracle no Exadata, existem algumas razões comuns pelas quais o Exadata é escolhido:

• 1-2 cargas de trabalho de E/S altas que são adequadas naturalmente para os recursos do Exadata e, como essas cargas de trabalho exigem recursos significativos de engenharia do Exadata, o restante dos bancos de dados executados junto com eles foram consolidados no Exadata.
• Cargas de trabalho OLTP complicadas ou difíceis que exigem que o RAC seja dimensionado e são difíceis de arquitetar com hardware proprietário sem conhecimento profundo da otimização Oracle ou podem ser uma dívida técnica incapaz de ser otimizada.
• Exadata existente subutilizado com várias cargas de trabalho: isso existe devido a migrações anteriores, fim de vida em um Exadata anterior ou devido ao desejo de trabalhar/testar um Exadata internamente.

É essencial que qualquer migração de um sistema Exadata seja entendida da perspetiva das cargas de trabalho e quão simples ou complexa pode ser a migração. Uma necessidade secundária é entender o motivo da compra da Exadata de uma perspetiva de status. As habilidades Exadata e RAC estão em maior demanda e podem ter impulsionado a recomendação de compra de uma pelas partes interessadas técnicas.

Importante

Não importa o cenário, a conclusão geral deve ser, para qualquer carga de trabalho de banco de dados proveniente de um Exadata, quanto mais recursos proprietários do Exadata forem usados, mais complexa será a migração e o planejamento. Os ambientes que não utilizam fortemente os recursos proprietários da Exadata têm oportunidades para um processo de migração e planejamento mais simples.

Há várias ferramentas que podem ser usadas para avaliar essas oportunidades de carga de trabalho:

• O repositório automático de carga de trabalho (AWR):
  • Todos os bancos de dados Exadata são licenciados para usar relatórios AWR e recursos de desempenho e diagnóstico conectados.
  • Está sempre ativo e coleta dados que podem ser usados para exibir informações históricas da carga de trabalho e avaliar o uso. Os valores de pico podem avaliar o alto uso no sistema,
  • Relatórios AWR de janela maior podem avaliar a carga de trabalho geral, fornecendo informações valiosas sobre o uso de recursos e como migrar a carga de trabalho para não-Exadata de forma eficaz. Os relatórios AWR de pico, em contraste, são melhores para otimização de desempenho e solução de problemas.
• O relatório AWR Global (RAC-Aware) para Exadata também inclui uma seção específica do Exadata, que detalha o uso de recursos específicos do Exadata e fornece informações valiosas sobre cache flash, flash logging, IO e outros recursos por banco de dados e nó de célula.

Dissociação da Exadata

Ao identificar cargas de trabalho do Oracle Exadata para migrar para a nuvem, considere as seguintes perguntas e pontos de dados:

• A carga de trabalho está consumindo vários recursos do Exadata, além dos benefícios de hardware?
  • Digitalizações inteligentes
  • Índices de armazenamento
  • Cache Flash
  • Registro em flash
  • Compressão colunar híbrida
• A carga de trabalho usando o Exadata é descarregada de forma eficiente? Nos eventos de primeiro plano de tempo superior, qual é a proporção (mais de 10% do tempo de banco de dados) da carga de trabalho usando:
  • Verificação de tabela inteligente de célula (ideal)
  • Leitura física multibloco celular (menos ideal)
  • Leitura física de bloco único de célula (menos ideal)
• Compressão colunar híbrida (HCC/EHCC): Quais são as relações comprimidas vs. não comprimidas:
  • O banco de dados gasta mais de 10% do tempo do banco de dados compactando e descompactando dados?
  • Inspecione os ganhos de desempenho para predicados usando a compactação em consultas: o valor ganho vale a pena versus o valor economizado com a compactação?
• E/S física da célula: Inspecione as economias proporcionadas por:
  • a quantidade direcionada para o nó de banco de dados para equilibrar a CPU.
  • Identificando o número de bytes retornados pelo Smart Scan. Esses valores podem ser subtraídos em IO para a porcentagem de leituras físicas de bloco único de célula quando ele migra do Exadata.
• Observe o número de leituras lógicas do cache. Determine se o cache flash será necessário em uma solução de IaaS na nuvem para a carga de trabalho.
• Compare o total de bytes físicos de leitura e gravação com a quantidade total executada no cache. A memória pode ser aumentada para eliminar os requisitos de leitura física (é comum que alguns reduzam o SGA para forçar o descarregamento do Exadata)?
• Em Estatísticas do Sistema, identifique quais objetos são impactados por qual estatística. Se o ajuste do SQL, indexação adicional, particionamento ou outro ajuste físico pode otimizar drasticamente a carga de trabalho.
• Inspecione os parâmetros de inicialização em busca de sublinhado (_) ou parâmetros preteridos, o que deve ser justificado devido ao impacto no nível do banco de dados que eles podem estar causando no desempenho.

Configuração do servidor Exadata

No Oracle versão 12.2 e superior, uma adição específica da Exadata será incluída no relatório global do AWR. Este relatório tem seções que fornecem valor excecional para uma migração do Exadata.

• Versão do Exadata e detalhes do sistema

• Detalhes dos alertas do nó da célula

• Discos não online Exadata

• Dados atípicos para qualquer estatística do Exadata OS

  • Amarelo/Rosa: De preocupação. O Exadata não está funcionando da melhor forma.

  • Vermelho: O desempenho da Exadata é afetado significativamente.

  • Estatística da CPU do Exadata OS: células superiores

    • Estas estatísticas são recolhidas pelo SO nas células e não se restringem a esta base de dados ou instâncias
    • A v e um fundo amarelo escuro indicam um valor atípico abaixo do intervalo baixo
    • A ^ e um fundo amarelo claro indicam um valor atípico acima da faixa alta
    • As células superiores por porcentagem de CPU são exibidas e estão em ordem decrescente de porcentagem de CPU
    • Média: 39.34% CPU, 28.57% usuário, 10.77% sys

    

• Leituras de bloco físico de célula única

• Uso do cache Flash

• Temp IO

• Eficiência do cache colunar

Banco de dados superior por taxa de transferência de E/S

Embora as avaliações de dimensionamento possam ser realizadas, há algumas perguntas sobre as médias e os picos simulados que são incorporados a esses valores para grandes cargas de trabalho. Esta seção, encontrada no final de um relatório AWR, é excepcionalmente valiosa, pois mostra o uso médio de flash e disco dos 10 principais bancos de dados no Exadata. Embora muitos possam supor que desejam dimensionar bancos de dados para desempenho máximo na nuvem, isso não faz sentido para a maioria das implantações (mais de 95% está na faixa média; com um pico simulado calculado, o intervalo médio será maior que 98%). É importante pagar pelo que é necessário, mesmo para as cargas de trabalho de maior demanda da Oracle, e inspecionar os principais bancos de dados por taxa de transferência de E/S pode ser esclarecedor para entender as necessidades de recursos para o banco de dados.

Oracle do tamanho certo usando o AWR no Exadata

Ao executar o planejamento de capacidade para sistemas locais, é natural ter uma sobrecarga significativa incorporada ao hardware. O hardware provisionado em excesso precisa atender à carga de trabalho Oracle por vários anos, independentemente das adições de carga de trabalho devido ao crescimento de dados, alterações de código ou upgrades.

Um dos benefícios da nuvem é dimensionar recursos em um host de VM e o armazenamento pode ser executado à medida que as demandas aumentam. Isso ajuda a conservar os custos de nuvem e os custos de licenciamento associados ao uso do processador (pertinente ao Oracle).

O dimensionamento correto envolve a remoção do hardware da migração tradicional de elevação e turno e o uso das informações de carga de trabalho fornecidas pelo Repositório Automático de Carga de Trabalho (AWR) da Oracle para elevar e deslocar a carga de trabalho para computação e armazenamento especialmente projetados para suportá-la na nuvem de escolha do cliente. O processo de dimensionamento correto garante que a arquitetura daqui para frente remova a dívida técnica da infraestrutura, a redundância de arquitetura que ocorreria se a duplicação do sistema local fosse replicada para a nuvem e implemente serviços de nuvem sempre que possível.

Os especialistas no assunto Microsoft Oracle estimaram que mais de 80% dos bancos de dados Oracle são provisionados em excesso e experimentam o mesmo custo ou economia indo para a nuvem se dedicarem tempo para dimensionar corretamente a carga de trabalho do banco de dados Oracle antes de migrar para a nuvem. Essa avaliação exige que os especialistas em banco de dados da equipe mudem sua mentalidade sobre como eles podem ter realizado o planejamento de capacidade no passado, mas vale a pena o investimento das partes interessadas na nuvem e na estratégia de nuvem do negócio.

Próximos passos

• Execute suas cargas de trabalho Oracle mais exigentes no Azure sem sacrificar o desempenho ou a escalabilidade
• Arquiteturas de solução usando arquivos NetApp do Azure - Oracle
• Projetar e implementar um banco de dados Oracle no Azure
• Ferramenta de estimativa para dimensionar cargas de trabalho Oracle para VMs IaaS do Azure
• Arquiteturas de referência para Oracle Database Enterprise Edition no Azure
• Compreender os grupos de volumes de aplicativos do Azure NetApp Files para SAP HANA