Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Besoins en ressources pour la plateforme cible

Nous vous recommandons de dimensionner l'environnement de base de données cible en AWS fonction de l'utilisation d'Exadata source, et non de la configuration. De nombreux clients achètent des systèmes Exadata dotés d'une capacité supplémentaire pour faire face à la croissance prévue pour les trois à cinq prochaines années. Généralement, lorsque les charges de travail Exadata sont migrées vers Exadata AWS, moins de ressources sont déployées par rapport à la configuration du système Exadata source. Il est donc trompeur d'utiliser cette configuration d'origine pour prévoir les ressources AWS.

Pour estimer les ressources requises dans l'instance cible, vous pouvez utiliser les outils décrits dans la section précédente, tels que AWR, les vues de base de données, OEM et CellCLI. Activé AWS, vous pouvez augmenter ou diminuer les ressources plus facilement par rapport à la plateforme Exadata source. Les sections suivantes décrivent les meilleures pratiques pour estimer les ressources telles que le processeur, la mémoire et les IOPS pour la plate-forme cible. En outre, les équipes chargées des comptes AWS et les spécialistes des bases de données qui ont une vaste expérience en matière d'assistance aux clients dans le cadre de leurs migrations avec Exadata peuvent vous aider à dimensionner votre environnement cible. AWS dispose d'outils internes que l'équipe chargée des comptes AWS peut utiliser pour estimer les ressources requises et dimensionner correctement votre environnement cible sur AWS.

Exigences en matière de processeur et de mémoire

Lorsque vous migrez vos charges de travail Exadata vers une option de déploiement de base de données Oracle AWS, telle qu'Amazon RDS for Oracle, vous ne devez pas baser les ressources de la couche de calcul (processeur et mémoire) uniquement sur les statistiques d'utilisation des serveurs de base de données Exadata. La charge de travail bénéficie également de fonctionnalités spécifiques à ExADATA, telles que le Smart Scan et les index de stockage, qui déchargent le traitement vers les cellules de stockage et utilisent les ressources des serveurs de stockage. Par conséquent, vous devez doter la couche de calcul de l'instance cible de ressources de processeur et de mémoire supplémentaires en fonction de votre utilisation des fonctionnalités spécifiques à Exadata et du degré d'optimisation de la charge de travail qui pourrait être possible pendant la migration.

Il est difficile d'estimer avec précision les ressources CPU supplémentaires requises. Utilisez les résultats de la découverte comme point de départ pour dimensionner l'environnement cible. Pour un calcul approximatif, pensez à inclure un vCPU supplémentaire pour 500 charges MBps de travail Smart Scan au total v CPUs requis pour la couche de calcul.

Une autre approche consiste à prendre en compte l'utilisation du processeur sur les serveurs de stockage. Vous pouvez ajouter environ 20 % du total utilisé CPUs sur les serveurs de stockage au total v CPUs requis pour la couche de calcul comme point de départ. Vous pouvez ajuster ce pourcentage en fonction de votre utilisation des fonctionnalités d'Exadata, conformément à des outils tels que AWR et CellCLI. Par exemple, pour une faible utilisation, vous pouvez ajouter 10 % pour une utilisation faible, 20 % pour une utilisation moyenne et 40 % pour une utilisation élevée. Si vous utilisez un nombre total de 20 threads CPU sur tous les serveurs de stockage et que l'utilisation des fonctionnalités Exadata est considérée comme moyenne, vous pouvez envisager 4 v supplémentaires CPUs pour compenser les fonctionnalités Exadata manquantes dans l'environnement cible.

Après ces estimations initiales, vous devez également effectuer des tests de performance sur l'environnement cible afin de déterminer s'il est nécessaire de dimensionner les ressources allouées. Les tests de performance pourraient également révéler d'autres opportunités d'optimisation de la charge de travail susceptibles de réduire les ressources requises.

Vous devrez peut-être augmenter l'allocation de mémoire à l'instance Oracle pour améliorer le taux de réussite du cache et réduire l' I/O encombrement. Il se peut que votre plateforme Exadata source ne dispose pas de suffisamment de mémoire pour des allocations SGA importantes, en particulier dans un scénario consolidé. Cela peut ne pas entraîner de problèmes de performances dans Exadata, car les I/O opérations sont généralement rapides. Nous vous recommandons de commencer par une instance qui prend en charge l'allocation de mémoire suivante :

Target memory required = larger of (8 GB per vCPUs required, two times the SGA+PGA allocation in the source)

SGA+PGA allocation = ~80% of available memory on the instance

Lors des tests de performances, vous pouvez utiliser les fonctionnalités Oracle telles que l'avis de pool de mémoire tampon, l'avis de cible SGA et l'avis de mémoire PGA pour affiner l'allocation SGA et PGA afin de répondre aux exigences de votre charge de travail.

L'instance Amazon EC2 ou Amazon RDS doit disposer du processeur, de la mémoire et des I/O ressources adéquats pour gérer la charge de travail de base de données prévue. Nous vous recommandons d'utiliser une classe d'instance de génération actuelle pour héberger votre charge de travail AWS. Les types d'instances de la génération actuelle, tels que les instances créées sur le système Nitro, prennent en charge les machines virtuelles matérielles (HVMs). Pour tirer parti d'une mise en réseau améliorée et d'une sécurité accrue, vous pouvez utiliser Amazon Machine Images (AMIs) pour HVMs. Amazon RDS for Oracle prend actuellement en charge jusqu'à 128 vCPU et GBs 3 904 unités de mémoire. Consultez les classes d'instance de base de données dans la documentation Amazon RDS pour obtenir des informations sur les spécifications matérielles des classes d'instances disponibles pour Amazon RDS for Oracle. Consultez les types d'instances EC2 Amazon pour obtenir une liste des instances avec le EC2 détail des ressources.

Exigences en matière d'E/S

L'utilisation des rapports AWR pour estimer les besoins en ressources nécessite de connaître les modèles de charge de travail en période de pointe, en dehors des heures de pointe et en période de charge moyenne. Pour estimer les besoins en IOPS pour votre charge de travail sur la base d'un rapport AWR collecté pendant les périodes de pointe, procédez comme suit :

Les statistiques de l'AWR relatives I/O aux demandes de lecture physiques, aux I/O demandes d'écriture physiques, aux octets de lecture physiques et aux octets d'écriture physiques reflètent les I/O activités de la charge de travail, à l'exclusion de la I/O contribution des composants non applicatifs tels que la sauvegarde RMAN et d'autres utilitaires tels que expdp ou sqlldr. Dans ces cas, vous pouvez prendre en compte les statistiques AWR relatives au nombre total de I/O demandes de lecture physique, au nombre total de I/O demandes d'écriture physique, au nombre total d'octets physiques en lecture et au nombre total d'octets en écriture physique pour estimer les IOPs besoins en débit.

Les bases de données exécutées sur Exadata produisent généralement des centaines de milliers d'IOPS et un débit très élevé (plus de 50 Gbit/s) en raison des facteurs décrits dans les sections précédentes. Cependant, dans la plupart des cas, les techniques de réglage et d'optimisation de la charge de travail réduisent considérablement l' I/O encombrement de la charge de travail.

Si les I/O exigences sont très élevées, soyez conscient des limites d'Amazon EC2 et d'Amazon RDS. Pour un débit de volume Amazon EBS élevé, pensez à utiliser des classes d' EC2 instances Amazon telles que x2iedn, x2idn et r5b, qui prennent en charge jusqu'à 260 000 IOPS avec un débit de 10 000. MBps Consultez les instances optimisées pour Amazon EBS dans la EC2 documentation Amazon pour connaître les IOPS et le débit maximaux pris en charge par les différentes instances. Pour Amazon RDS for Oracle, la classe d'instance rb5 prend en charge jusqu'à 256 000 IOPS avec un débit de 4 000. MBps Consultez les classes d'instances de base de données pour consulter les instances optimisées pour Amazon EBS disponibles pour Amazon RDS for Oracle.

Vous devez également comprendre comment les IOPS et le débit sont mesurés dans le cas de différents volumes EBS disponibles pour l'environnement cible. Dans certains cas, Amazon EBS divise ou fusionne les I/O opérations pour optimiser le débit. Pour en savoir plus, consultez les caractéristiques et le suivi des E/S dans la EC2 documentation Amazon et dans la section Comment optimiser les performances de mes volumes d'IOPS provisionnés par Amazon EBS ? dans le AWS Knowledge Center.