Estimez la taille du moteur Amazon RDS pour une base de données Oracle à l'aide des rapports AWR - Recommandations AWS
RécapitulatifConditions préalables et limitationsArchitectureOutilsBonnes pratiquesÉpopéesRessources connexes

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.

Estimez la taille du moteur Amazon RDS pour une base de données Oracle à l'aide des rapports AWR

Créée par Abhishek Verma (AWS) et Eduardo Valentim (AWS)

Environnement : Production

Source : base de données Oracle

Cible : Amazon RDS ou Amazon Aurora

Type R : Ré-architecte

Charge de travail : Oracle

Technologies : bases de données ; migration

Services AWS : Amazon RDS ; Amazon Aurora

Récapitulatif

Lorsque vous migrez une base de données Oracle vers Amazon Relational Database Service (Amazon RDS) ou Amazon Aurora, le calcul du processeur, de la mémoire et des E/S de disque pour la base de données cible est une exigence essentielle. Vous pouvez estimer la capacité requise de la base de données cible en analysant les rapports Oracle Automatic Workload Repository (AWR). Ce modèle explique comment utiliser les rapports AWR pour estimer ces valeurs.

La base de données Oracle source peut être sur site ou hébergée sur une instance Amazon Elastic Compute Cloud (Amazon EC2), ou il peut s'agir d'une instance de base de données Amazon RDS for Oracle. La base de données cible peut être n'importe quelle base de données Amazon RDS ou Aurora.

Remarque : Les estimations de capacité seront plus précises si votre moteur de base de données cible est Oracle. Pour les autres bases de données Amazon RDS, la taille du moteur peut varier en raison des différences d'architecture de base de données.

Nous vous recommandons d'exécuter le test de performance avant de migrer votre base de données Oracle.

Conditions préalables et limitations

Prérequis

  • Une licence Oracle Database Enterprise Edition et une licence Oracle Diagnostics Pack pour télécharger les rapports AWR.

Versions du produit

  • Toutes les éditions d'Oracle Database pour les versions 11g (versions 11.2.0.3.v1 et ultérieures) et jusqu'à 12.2, et 18c,19c.

  • Ce modèle ne couvre pas les systèmes Oracle Engineered ou Oracle Cloud Infrastructure (OCI).

Architecture

Pile technologique source

L’un des éléments suivants :

  • Une base de données Oracle sur site

  • Une base de données Oracle sur une instance EC2

  • Une instance de base de données Amazon RDS pour Oracle

Pile technologique cible

  • N'importe quelle base de données Amazon RDS ou Amazon Aurora

Architecture cible

Pour plus d'informations sur le processus de migration complet, consultez le modèle Migrer une base de données Oracle vers Aurora PostgreSQL à l'aide d'AWS DMS et d'AWS SCT.

Automatisation et mise à l'échelle

Si vous avez plusieurs bases de données Oracle à migrer et que vous souhaitez utiliser des indicateurs de performance supplémentaires, vous pouvez automatiser le processus en suivant les étapes décrites dans le billet de blog Ajustement de la taille des instances Amazon RDS à grande échelle en fonction des indicateurs de performance Oracle.

Outils

  • Oracle Automatic Workload Repository (AWR) est un référentiel intégré aux bases de données Oracle. Il collecte et stocke périodiquement les données relatives à l'activité du système et à la charge de travail, qui sont ensuite analysées par Automatic Database Diagnostic Monitor (ADDM). AWR prend régulièrement des instantanés des données de performance du système (par défaut, toutes les 60 minutes) et stocke les informations (par défaut, jusqu'à 8 jours).  Vous pouvez utiliser les vues et les rapports AWR pour analyser ces données.

Bonnes pratiques

  • Pour calculer les besoins en ressources de votre base de données cible, vous pouvez utiliser un seul rapport AWR, plusieurs rapports AWR ou des vues AWR dynamiques. Nous vous recommandons d'utiliser plusieurs rapports AWR pendant la période de pointe afin d'estimer les ressources nécessaires pour gérer ces pics de charge. En outre, les vues dynamiques fournissent davantage de points de données qui vous aident à calculer les besoins en ressources avec plus de précision. 

  • Vous devez estimer les IOPS uniquement pour la base de données que vous prévoyez de migrer, et non pour les autres bases de données et processus qui utilisent le disque.

  • Pour calculer la quantité d'E/S utilisée par la base de données, n'utilisez pas les informations de la section Profil de charge du rapport AWR. Utilisez plutôt la section Profil d'E/S, si elle est disponible, ou passez directement à la section Statistiques d'activité de l'instance et examinez les valeurs totales des opérations physiques de lecture et d'écriture.

  • Lorsque vous estimez l'utilisation du processeur, nous vous recommandons d'utiliser la méthode des métriques de base de données plutôt que les statistiques du système d'exploitation (OS), car elle est basée sur le processeur utilisé uniquement par les bases de données. (Les statistiques du système d'exploitation incluent également l'utilisation du processeur par d'autres processus.) Vous devez également consulter les recommandations relatives au processeur dans le rapport ADDM afin d'améliorer les performances après la migration.

  • Tenez compte des limites de débit d'E/S (débit Amazon Elastic Block Store (Amazon EBS) et débit réseau) pour la taille spécifique de l'instance lorsque vous déterminez le type d'instance approprié.

  • Exécutez le test de performance avant la migration pour valider la cylindrée du moteur.

Épopées

TâcheDescriptionCompétences requises

Activez le rapport AWR.

Pour activer le rapport, suivez les instructions de la documentation Oracle.

DBA

Vérifiez la durée de conservation.

Pour vérifier la durée de conservation du rapport AWR, utilisez la requête suivante.

SQL> SELECT snap_interval,retention FROM dba_hist_wr_control;
DBA

Générez le cliché.

Si l'intervalle entre les instantanés AWR n'est pas suffisamment précis pour capturer le pic de charge de travail, vous pouvez générer le rapport AWR manuellement. Pour générer l'instantané AWR manuel, utilisez la requête suivante.

SQL> EXEC dbms_workload_repository.create_snapshot;
DBA

Vérifiez les instantanés récents.

Pour vérifier les instantanés AWR récents, utilisez la requête suivante.

SQL> SELECT snap_id, to_char(begin_interval_time,'dd/MON/yy hh24:mi') Begin_Interval,
 to_char(end_interval_time,'dd/MON/yy hh24:mi') End_Interval
 FROM dba_hist_snapshot
 ORDER BY 1;
DBA
TâcheDescriptionCompétences requises

Choisissez une méthode.

L'IOPS est la mesure standard des opérations d'entrée et de sortie par seconde sur un périphérique de stockage et inclut les opérations de lecture et d'écriture. 

Si vous migrez une base de données sur site vers AWS, vous devez déterminer le pic d'E/S disque utilisé par la base de données. Vous pouvez utiliser les méthodes suivantes pour estimer les E/S de disque pour votre base de données cible :

  • Section « Profil de charge » du rapport AWR

  • Section des statistiques d'activité de l'instance du rapport AWR (utilisez cette section pour Oracle Database 12c ou version ultérieure)

  • Section du profil d'E/S du rapport AWR (utilisez cette section pour les versions de base de données Oracle antérieures à 12c)

  • Vues AWR

Les étapes suivantes décrivent ces quatre méthodes.

DBA

Option 1 : utilisez le profil de charge.

Le tableau suivant montre un exemple de la section Profil de charge du rapport AWR.

Important : pour des informations plus précises, nous vous recommandons d'utiliser l'option 2 (profils d'E/S) ou l'option 3 (statistiques d'activité de l'instance) au lieu du profil de charge.

 

Par seconde

Par transaction

Par Exec

Par appel

Heure (s) de base de données :

26,6

0.2

0,00

0,02

Processeur (s) de base de données :

18,0

0.1

0,00

0,01

Processeur (s) d'arrière-plan :

0.2

0.0

0,00

0,00

Taille de rétablissement (octets) :

2 458 539,9

17 097,5

 

 

Lecture logique (blocs) :

3 371 931,5

23 449,6

 

 

Bloquer les modifications :

21 643,5

150,5

 

 

Lecture physique (blocs) :

13 575,1

94,4

 

 

Écriture physique (blocs) :

3 467,3

24.1

 

 

Lisez les demandes d'E/S :

3 586,8

24,9

 

 

Rédigez des demandes d'E/S :

574,7

4.0

 

 

Lire l'IO (Mo) :

106,1

0.7

 

 

Écrire IO (Mo) :

27.1

0.2

 

 

Lignes de numérisation par messagerie instantanée :

0.0

0.0

 

 

Messagerie instantanée de lecture logique de session :

 

 

 

 

Appels de l'utilisateur :

1 245,7

8,7

 

 

Analyses (SQL) :

4 626,2

32,2

 

 

Analyses approfondies (SQL) :

8,9

0.1

 

 

Zone de travail SQL (Mo) :

824,9

5.7

 

 

Connexions :

1,7

0.0

 

 

Exécute (SQL) :

136 656,5

950,4

 

 

Annulations :

22,9

0.2

 

 

Transactions :

143,8

 

 

 

Sur la base de ces informations, vous pouvez calculer les E/S par seconde et le débit comme suit :

IOPS = demandes d'E/S de lecture : + Demandes d'E/S d'écriture = 3 586,8 + 574,7 = 4134,5

Débit = lecture physique (blocs) + écriture physique (blocs) = 13 575,1 + 3 467,3 = 17 042,4

La taille des blocs dans Oracle étant de 8 Ko, vous pouvez calculer le débit total comme suit :

Le débit total en Mo est de 17042,4 * 8 * 1024/1024/1024 = 133,2 Mo

Avertissement : N'utilisez pas le profil de charge pour estimer la taille de l'instance. Ce n'est pas aussi précis que les statistiques d'activité des instances ou les profils d'E/S.

DBA

Option 2 : utiliser les statistiques d'activité de l'instance.

Si vous utilisez une version d'Oracle Database antérieure à 12c, vous pouvez utiliser la section Instance Activity Stats du rapport AWR pour estimer les IOPS et le débit. Le tableau suivant présente un exemple de cette section.

Statistique

Total

par seconde

par Trans

nombre total de demandes d'E/S en lecture physique

2 547 333 217

3 610,28

25,11

nombre total d'octets de lecture physique

80 776 296 124 928

114 482 426,26

796 149,98

nombre total de demandes d'E/S en écriture physique

534 198 208

757,11

5,27

nombre total d'octets en écriture physique

25 517 678 849 024

36 165 631,84

251 508,18

Sur la base de ces informations, vous pouvez calculer le total des IOPS et le débit comme suit :

Nombre total d'IOPS = 3 610,28 + 757,11 = 4 367

Mbits/s totaux = 114 482 426,26 + 36 165 631,84 = 150648058,1/1024/1024 = 143 Mbits/s

DBA

Option 3 : utiliser des profils d'E/S.

Dans Oracle Database 12c, le rapport AWR inclut une section Profils d'E/S qui présente toutes les informations dans un seul tableau et fournit des données plus précises sur les performances de la base de données. Le tableau suivant présente un exemple de cette section.

 

Lecture+écriture par seconde

Lecture par seconde

Écrire par seconde

Nombre total de demandes :

4 367,4

3 610,3

757,1

Demandes de base de données :

4 161,5

3 586,8

574,7

Demandes optimisées :

0.0

0.0

0.0

Demandes de rétablissement :

179,3

2,8

176,6

Total (Mo) :

143,7

109,2

34,5

Base de données (MB) :

133,1

106,1

27.1

Total optimisé (Mo) :

0.0

0.0

0.0

Rétablir (Mo) :

7.6

2.7

4,9

Base de données (blocs) :

17 042,4

13 575,1

3 467,3

Via le cache tampon (blocs) :

5 898,5

5 360,9

537,6

Direct (blocs) :

11 143,9

8 214,2

2 929,7

Ce tableau fournit les valeurs suivantes pour le débit et le total des IOPS :

Débit = 143 Mbits/s (à partir de la cinquième ligne, intitulée Total, deuxième colonne)

IOPS = 4 367,4 (à partir de la première ligne, intitulée Total des demandes, deuxième colonne)

DBA

Option 4 : Utiliser les vues AWR.

Vous pouvez voir les mêmes informations d'IOPS et de débit en utilisant les vues AWR. Pour obtenir ces informations, utilisez la requête suivante : 

break on report
 compute sum of Value on report
 select METRIC_NAME,avg(AVERAGE) as "Value"
 from dba_hist_sysmetric_summary
 where METRIC_NAME in ('Physical Read Total IO Requests Per Sec','Physical Write Total IO Requests Per Sec')
 group by metric_name;
DBA
TâcheDescriptionCompétences requises

Choisissez une méthode.

Vous pouvez estimer le processeur requis pour la base de données cible de trois manières :

  • En utilisant les cœurs réellement disponibles du processeur

  • En utilisant les cœurs utilisés en fonction des statistiques du système d'exploitation

  • En utilisant les cœurs utilisés sur la base des statistiques de la base de données

Si vous examinez les cœurs utilisés, nous vous recommandons d'utiliser la méthode des métriques de base de données plutôt que des statistiques du système d'exploitation, car elle est basée sur le processeur utilisé uniquement par les bases de données que vous envisagez de migrer. (Les statistiques du système d'exploitation incluent également l'utilisation du processeur par d'autres processus.) Vous devez également consulter les recommandations relatives au processeur dans le rapport ADDM afin d'améliorer les performances après la migration.

Vous pouvez également estimer les besoins en fonction de la génération de processeurs. Si vous utilisez différentes générations de processeurs, vous pouvez estimer le processeur requis pour la base de données cible en suivant les instructions du livre blanc Démystifier le nombre de vCPU pour des performances de charge de travail optimales.

DBA

Option 1 : Estimer les besoins en fonction des noyaux disponibles.

Dans les rapports de l'AWR :

  • Les processeurs font référence aux processeurs logiques et virtuels. 

  • Les cœurs sont le nombre de processeurs contenus dans un chipset de processeur physique. 

  • Un socket est un dispositif physique qui connecte une puce à une carte. Les processeurs multicœurs ont des sockets avec plusieurs cœurs de processeur.

Vous pouvez estimer les noyaux disponibles de deux manières :

  • En utilisant les commandes du système d'exploitation

  • En utilisant le rapport AWR

Pour estimer les cœurs disponibles à l'aide des commandes du système d'exploitation

Utilisez la commande suivante pour compter les cœurs du processeur.

$ cat /proc/cpuinfo |grep "cpu cores"|uniq
cpu cores    : 4
cat /proc/cpuinfo | egrep "core id|physical id" | tr -d "\n" | sed s/physical/\\nphysical/g | grep -v ^$ | sort | uniq | wc -l

Utilisez la commande suivante pour compter le nombre de sockets du processeur.

grep "physical id" /proc/cpuinfo | sort -u
  physical id     : 0
  physical id     : 1

Remarque : nous ne recommandons pas d'utiliser les commandes du système d'exploitation telles que nmon et sar pour extraire l'utilisation du processeur. Cela est dû au fait que ces calculs incluent l'utilisation du processeur par d'autres processus et peuvent ne pas refléter le processeur réel utilisé par la base de données.

Pour estimer les cœurs disponibles à l'aide du rapport AWR

Vous pouvez également déduire l'utilisation du processeur à partir de la première section du rapport AWR. Voici un extrait du rapport.

DB Name

ID de base de données

Instance

Insérer un numéro

Heure de démarrage

Version

RAC

XXXX

<DB_ID>

XXXX

1

05 sept. 20 à 23:09

12.1.0.2.0

NO

Nom d'hôte

Plateforme

Processeurs

Noyaux

Douilles

Mémoire (Go)

<host_name>

Linux x86 64 bits

80

80

2

441,78

Dans cet exemple, le nombre de processeurs est de 80, ce qui indique qu'il s'agit de processeurs logiques (virtuels). Vous pouvez également constater que cette configuration comporte deux sockets, un processeur physique sur chaque socket (pour un total de deux processeurs physiques) et 40 cœurs pour chaque processeur physique ou socket. 

DBA

Option 2 : Estimez l'utilisation du processeur à l'aide des statistiques du système d'exploitation.

Vous pouvez vérifier les statistiques d'utilisation du processeur du système d'exploitation soit directement dans le système d'exploitation (à l'aide de sar ou d'un autre utilitaire du système d'exploitation hôte), soit en consultant les valeurs IDLE/ (IDLE+BUSY) de la section Statistiques du système d'exploitation du rapport AWR. Vous pouvez voir les secondes de processeur consommées directement depuis v$osstat. Les rapports AWR et Statspack présentent également ces données dans la section Statistiques du système d'exploitation.

Si plusieurs bases de données se trouvent sur la même boîte, elles ont toutes les mêmes valeurs v$osstat pour BUSY_TIME.

Statistique

Valeur

Valeur finale

OCTETS DE MÉMOIRE GRATUITS

6 810 677 248

12 280 799 232

OCTETS DE MÉMOIRE INACTIFS

175 627 333 632

160 380 653 568

SWAP_FREE_BYTES

17 145 614 336

17 145 872 384

PÉRIODE OCCUPÉE

1 305 569 937

 

HEURE D'INACTIVITÉ

4 312 718 839

 

HEURE D'ATTENTE DE L'IOWA

53 417 174

 

NICE_TIME

29 815

 

SYS_TIME

148 567 570

 

HEURE DE L'UTILISATEUR

1 146 918 783

 

CHARGE

25

29

VM EN OCTETS

593 920

 

VM_OUT_BYTES

327 680

 

MEMOIRE_OCTETS_PHYSIQUE

474 362 417 152

 

NUM_PROCESSEURS

80

 

NOMBRE DE CPU_CORES

80

 

NUM CPU SOCKETS

2

 

TAILLE MAXIMALE DE LA RÉCEPTION GLOBALE

4 194 304

 

TAILLE MAXIMALE DE L'ENVOI GLOBAL

2 097 152

 

TCP_RECEIVE_SIZE_DEFAULT

87 380

 

TCP_RECEIVE_SIZE_MAX

6 291 456

 

TAILLE DE RÉCEPTION TCP_MIN

4 096

 

TCP_SEND_SIZE_DEFAULT

16 384

 

TCP_SEND_SIZE_MAX

4 194 304

 

TCP_SEND_SIZE_MIN

4 096

 

S'il n'y a aucun autre consommateur important de CPU dans le système, utilisez la formule suivante pour calculer le pourcentage d'utilisation du processeur :

Utilisation = Temps de charge/Temps total

Temps de pointe = exigences = V$OSSTAT.BUSY_TIME

C = Durée totale (occupé et inactif)

C = capacité = V$OSTAT.BUSY_TIME + V$OSTAT.IDLE_TIME

Utilisation = BUSY_TIME/(BUSY_TIME + IDLE_TIME)

= -1 305 569 937/(1 305 569 937 + 4 312 718 839)

= 23 % utilisés

DBA

Option 3 : Estimez l'utilisation du processeur à l'aide des métriques de base de données.

Si plusieurs bases de données sont en cours d'exécution dans le système, vous pouvez utiliser les métriques de base de données qui apparaissent au début du rapport.

 

Snap ID

Snap Time

Sessions

Curseurs/Session

Commencez Snap :

184662

28 sept. 20 h 00 : 42

1226

35,8

Fin du snap :

185446

6 octobre 2020 13:00:20

1876

41,1

Échappé :

 

11 759,64 (minutes)

 

 

Heure de base de données :

 

312 625,40 (minutes)

 

 

Pour obtenir des mesures d'utilisation du processeur, utilisez cette formule :

Utilisation du processeur de la base de données (% de la puissance CPU disponible) = temps CPU/NUM_CPUS/temps écoulé

où l'utilisation du processeur est décrite par le temps du processeur et représente le temps passé sur le processeur, et non le temps d'attente du processeur. Ce calcul aboutit à :

= 312,625,40/11,759,64/80 = 33 % du processeur est utilisé

Nombre de cœurs (33 %) * 80 = 26,4 cœurs

Nombre total de cœurs = 26,4 * (120 %) = 31,68 cœurs

Vous pouvez utiliser la plus élevée de ces deux valeurs pour calculer l'utilisation du processeur de l'instance de base de données Amazon RDS ou Aurora.

Remarque : Sur IBM AIX, l'utilisation calculée ne correspond pas aux valeurs du système d'exploitation ou de la base de données. Ces valeurs sont identiques sur les autres systèmes d'exploitation.

DBA
TâcheDescriptionCompétences requises

Estimez les besoins en mémoire à l'aide des statistiques de mémoire.

Vous pouvez utiliser le rapport AWR pour calculer la mémoire de la base de données source et la faire correspondre à celle de la base de données cible. Vous devez également vérifier les performances de la base de données existante et réduire vos besoins en mémoire pour réduire les coûts, ou augmenter vos besoins pour améliorer les performances. Cela nécessite une analyse détaillée du temps de réponse de l'AWR et du contrat de niveau de service (SLA) de l'application. Utilisez la somme de l'utilisation de la zone globale du système Oracle (SGA) et de la zone globale du programme (PGA) comme estimation de l'utilisation de la mémoire pour Oracle. Ajoutez 20 % supplémentaires pour que le système d'exploitation détermine une taille de mémoire cible requise. Pour Oracle RAC, utilisez la somme de l'utilisation de mémoire estimée sur tous les nœuds RAC et réduisez la mémoire totale, car elle est stockée sur des blocs communs.

  1. Vérifiez les indicateurs dans le tableau des pourcentages d'efficacité de l'instance. Le tableau utilise les termes suivants :

    • Le pourcentage d'impact sur la mémoire tampon est le pourcentage de fois où un bloc particulier a été trouvé dans le cache de la mémoire tampon au lieu d'effectuer une E/S physique. Pour de meilleures performances, visez 100 %. 

    • La valeur de la mémoire tampon Nowait % doit être proche de 100 %.

    • Le pourcentage de Latch Hit doit être proche de 100 %. 

    • Le pourcentage de processeur non analysable est le pourcentage du temps processeur consacré à des activités autres que l'analyse syntaxique. Cette valeur doit être proche de 100 %.

    Pourcentages d'efficacité des instances (objectif 100 %)

    Tampon Nowait % :

    99,99

    Rétablir NoWait  % :

    100,00

    % d'impact sur la mémoire tampon :

    99,84

    % de tri en mémoire :

    100,00

    % d'accès à la bibliothèque :

    748,77

    Analyse logicielle % :

    99,81

    Exécutez pour analyser % :

    96,61

    % de clics sur le verrou :

    100,00

    Analyser le processeur pour analyser Elapsd % :

    72,73

    % Processeur non analysé :

    99,21

    % d'accès au cache Flash :

    0,00

     

     

    Dans cet exemple, toutes les métriques semblent correctes. Vous pouvez donc utiliser le SGA et le PGA pour la base de données existante comme exigence de planification des capacités.

  2. Consultez la section des statistiques de mémoire et calculez le SGA/PGA.

     

    Commencer

    Fin

    Mémoire hôte (Mo) :

    452 387,3

    452 387,3

    Utilisation du SGA (Mo) :

    220 544,0

    220 544,0

    Utilisation du PGA (Mo) :

    36 874,9

    45 270,0

Mémoire d'instance totale utilisée = SGA + PGA = 220 Go + 45 Go = 265 Go

Ajoutez 20 % de mémoire tampon :

Mémoire d'instance totale = 1,2 * 265 Go = 318 Go

Étant donné que les cartes SGA et PGA représentent 70 % de la mémoire de l'hôte, la quantité totale de mémoire requise est la suivante : 

Mémoire hôte totale = 318/0,7 = 464 Go

Remarque : Lorsque vous migrez vers Amazon RDS for Oracle, le PGA et le SGA sont précalculés sur la base d'une formule prédéfinie. Assurez-vous que les valeurs précalculées sont proches de vos estimations.

DBA
TâcheDescriptionCompétences requises

Déterminez le type d'instance de base de données en fonction des estimations des E/S de disque, du processeur et de la mémoire.

Sur la base des estimations des étapes précédentes, la capacité de la base de données Amazon RDS ou Aurora cible doit être la suivante :

  • 68 cœurs de processeur

  • Débit de 143 Mbits/s  

  • 4367 IOPS pour les E/S de disque

  • 464 Go de mémoire

Dans la base de données Amazon RDS ou Aurora cible, vous pouvez mapper ces valeurs au type d'instance db.r5.16xlarge, qui a une capacité de 32 cœurs, 512 Go de RAM et un débit de 13 600 Mbit/s. Pour plus d'informations, consultez le billet de blog AWS Right size Amazon RDS instances at scale based on Oracle performance metrics.

DBA

Ressources connexes