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

Activez le AWR rapport.

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

Vérifiez la durée de conservation.

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

SQL> SELECT snap_interval,retention FROM dba_hist_wr_control;

Générez le cliché.

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

SQL> EXEC dbms_workload_repository.create_snapshot;

Vérifiez les instantanés récents.

Pour vérifier les AWR instantanés 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;

Choisissez une méthode.

IOPSest 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 locale versAWS, 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 :

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

Option 1 : utilisez le profil de charge.

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

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.

Sur la base de ces informations, vous pouvez calculer IOPs le débit comme suit :

IOPS= Lire les demandes d'E/S : + Écrire des demandes d'E/S = 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.

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 Statistiques d'activité des instances du AWR rapport pour estimer IOPS le débit. Le tableau suivant présente un exemple de cette section.

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

Total IOPS = 3 610,28 + 757,11 = 4367

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

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

Dans Oracle Database 12c, le AWR rapport 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.

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

Débit = 143 MBPS (à 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)

Option 4 : Utiliser les AWR vues.

Vous pouvez voir les mêmes informations IOPS et les informations de débit à l'aide des AWR vues. 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;

Choisissez une méthode.

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

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 les données CPU utilisées uniquement par les bases de données que vous envisagez de migrer. (Les statistiques du système d'exploitation incluent également CPU l'utilisation par d'autres processus.) Vous devez également consulter les CPU recommandations connexes du ADDM rapport afin d'améliorer les performances après la migration.

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

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

Dans AWR les rapports :

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

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 CPU l'utilisation. Cela est dû au fait que ces calculs incluent CPU l'utilisation par d'autres processus et peuvent ne pas refléter l'utilisation réelle CPU de la base de données.

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

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

Dans cet exemple, le CPUs nombre est de 80, ce qui indique qu'ils sont logiques (virtuels)CPUs. 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. 

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

Vous pouvez vérifier les statistiques CPU d'utilisation 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 valeursIDLE/(IDLE+BUSY) de la section Statistiques du système d'exploitation du AWR rapport. Vous pouvez voir les secondes CPU consommées directement depuis v$osstat. Les rapports AWR et Statspack affichent é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

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

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

Option 3 : Estimez CPU l'utilisation à 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.

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

CPUUtilisation de la base de données (% de l'CPUénergie disponible) = CPU temps/NUM_CPUS/temps écoulé

où CPU l'utilisation est décrite en CPUfonction du temps et représente le temps passéCPU, et non le temps d'attenteCPU. Ce calcul aboutit à :

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

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'CPUutilisation de l'instance de base de données Amazon RDS ou Aurora.

Remarque : Activé IBMAIX, 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.

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

Vous pouvez utiliser le AWR rapport 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 AWR réponse et de l'accord 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 OracleRAC, utilisez la somme de l'utilisation estimée de la mémoire sur tous les RAC nœuds et réduisez la mémoire totale, car elle est stockée sur des blocs communs.

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 SGA 70 % de la mémoire de l'hôte représente 70 %, la quantité totale de mémoire requise est la suivante : PGA 

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

Remarque : Lorsque vous migrez vers Amazon RDS pour Oracle, les PGA et 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.

Déterminez le type d'instance de base de données en fonction des E/S du disque et CPU des estimations de 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 :

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 et 13 600 Mbits/s de débitRAM. Pour plus d'informations, consultez le billet de AWS blog Right-size Amazon RDS instances at scale based on Oracle performance metrics.