Stima le dimensioni del motore Amazon RDS per un database Oracle utilizzando i report AWR

Creato da Abhishek Verma (AWS) e Eduardo Valentim (AWS)

Ambiente: produzione	Fonte: Oracle Database	Target: Amazon RDS o Amazon Aurora
Tipo R: Re-architect	Carico di lavoro: Oracle	Tecnologie: database; migrazione
Servizi AWS: Amazon RDS; Amazon Aurora

Riepilogo

Quando esegui la migrazione di un database Oracle ad Amazon Relational Database Service (Amazon RDS) o Amazon Aurora, il calcolo della CPU, della memoria e dell'I/O del disco per il database di destinazione è un requisito fondamentale. È possibile stimare la capacità richiesta del database di destinazione analizzando i report di Oracle Automatic Workload Repository (AWR). Questo modello spiega come utilizzare i report AWR per stimare questi valori.

Il database Oracle di origine potrebbe essere locale o ospitato su un'istanza Amazon Elastic Compute Cloud (Amazon EC2) oppure potrebbe essere un'istanza DB Amazon RDS for Oracle. Il database di destinazione potrebbe essere qualsiasi database Amazon RDS o Aurora.

Nota: le stime della capacità saranno più precise se il motore di database di destinazione è Oracle. Per altri database Amazon RDS, le dimensioni del motore possono variare a causa delle differenze nell'architettura del database.

Ti consigliamo di eseguire il test delle prestazioni prima di migrare il database Oracle.

Prerequisiti e limitazioni

Prerequisiti

• Una licenza Oracle Database Enterprise Edition e una licenza Oracle Diagnostics Pack per scaricare i report AWR.

Versioni del prodotto

• Tutte le edizioni di Oracle Database per le versioni 11g (versioni 11.2.0.3.v1 e successive) e fino a 12.2 e 18c,19c.

• Questo modello non copre Oracle Engineered Systems o Oracle Cloud Infrastructure (OCI).

Architettura

Stack tecnologico di origine

Una delle seguenti:

• Un database Oracle locale

• Un database Oracle su un'istanza EC2

• Un'istanza DB Amazon RDS per Oracle

Stack tecnologico Target

• Qualsiasi database Amazon RDS o Amazon Aurora

Architettura Target

Per informazioni sul processo di migrazione completo, consulta lo schema Migrare un database Oracle su Aurora PostgreSQL utilizzando AWS DMS e AWS SCT.

Automazione e scalabilità

Se hai più database Oracle da migrare e desideri utilizzare parametri prestazionali aggiuntivi, puoi automatizzare il processo seguendo i passaggi descritti nel post del blog Istanze Amazon RDS di dimensioni corrette su larga scala in base ai parametri delle prestazioni Oracle.

Strumenti

• Oracle Automatic Workload Repository (AWR) è un repository integrato nei database Oracle. Periodicamente raccoglie e archivia i dati sull'attività del sistema e sul carico di lavoro, che vengono poi analizzati da Automatic Database Diagnostic Monitor (ADDM). AWR acquisisce istantanee dei dati sulle prestazioni del sistema periodicamente (per impostazione predefinita, ogni 60 minuti) e archivia le informazioni (per impostazione predefinita, fino a 8 giorni).  È possibile utilizzare le viste e i report AWR per analizzare questi dati.

Best practice

• Per calcolare il fabbisogno di risorse per il database di destinazione, puoi utilizzare un singolo report AWR, più report AWR o viste AWR dinamiche. Si consiglia di utilizzare più report AWR durante il periodo di picco di carico per stimare le risorse necessarie per gestire tali carichi di picco. Inoltre, le viste dinamiche forniscono più punti dati che consentono di calcolare i requisiti di risorse in modo più preciso. 

• È necessario stimare gli IOPS solo per il database che si intende migrare, non per altri database e processi che utilizzano il disco.

• Per calcolare la quantità di I/O utilizzata dal database, non utilizzate le informazioni nella sezione Load Profile del rapporto AWR. Utilizza invece la sezione Profilo I/O, se disponibile, oppure vai alla sezione Instance Activity Stats e guarda i valori totali per le operazioni fisiche di lettura e scrittura.

• Quando stimi l'utilizzo della CPU, ti consigliamo di utilizzare il metodo delle metriche del database anziché le statistiche del sistema operativo (OS), poiché si basa sulla CPU utilizzata solo dai database. (Le statistiche del sistema operativo includono anche l'utilizzo della CPU da parte di altri processi). È inoltre necessario controllare i consigli relativi alla CPU nel rapporto ADDM per migliorare le prestazioni dopo la migrazione.

• Quando determini il tipo di istanza giusto, considera i limiti di throughput di I/O, throughput di Amazon Elastic Block Store (Amazon EBS) e throughput di rete, per la dimensione specifica dell'istanza.

• Esegui il test delle prestazioni prima della migrazione per convalidare le dimensioni del motore.

Epiche

Crea un rapporto AWR

Attività	Descrizione	Competenze richieste
Abilita il rapporto AWR.	Per abilitare il rapporto, segui le istruzioni nella documentazione Oracle.	DBA
Verifica il periodo di conservazione.	Per verificare il periodo di conservazione del rapporto AWR, utilizza la seguente query. SQL> SELECT snap_interval,retention FROM dba_hist_wr_control;	DBA
Genera l'istantanea.	Se l'intervallo delle istantanee AWR non è sufficientemente granulare per registrare il picco del carico di lavoro di picco, puoi generare il rapporto AWR manualmente. Per generare l'istantanea AWR manuale, utilizzate la seguente query. SQL> EXEC dbms_workload_repository.create_snapshot;	DBA
Controlla le istantanee recenti.	Per controllare le istantanee AWR recenti, usa la seguente query. 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

Stima dei requisiti di I/O del disco

Attività	Descrizione	Competenze richieste
Scegli un metodo.	IOPS è la misura standard delle operazioni di input e output al secondo su un dispositivo di storage e include operazioni di lettura e scrittura.  Se stai migrando un database locale in AWS, devi determinare il picco di I/O del disco utilizzato dal database. È possibile utilizzare i seguenti metodi per stimare l'I/O del disco per il database di destinazione: Sezione Load Profile del rapporto AWR Sezione Instance Activity Stats del rapporto AWR (utilizzare questa sezione per Oracle Database 12c o versione successiva) Sezione I/O Profile del rapporto AWR (utilizzare questa sezione per le versioni di Oracle Database precedenti alla 12c) Visualizzazioni AWR I passaggi seguenti descrivono questi quattro metodi.	DBA
Opzione 1: utilizzare il profilo di carico.	La tabella seguente mostra un esempio della sezione Load Profile del rapporto AWR. Importante: per informazioni più accurate, si consiglia di utilizzare l'opzione 2 (profili I/O) o l'opzione 3 (statistiche sull'attività delle istanze) anziché il profilo di carico.   Al secondo Per transazione Per dirigente Per chiamata Orario (i) DB: 26,6 0.2 0,00 0,02 CPU (e) DB: 18,0 0.1 0,00 0.01 CPU (e) in background: 0.2 0,0 0,00 0,00 Dimensione di ripristino (byte): 2.458.539,9 17.097,5     Lettura logica (blocchi): 3.371.931,5 23449,6     Blocca le modifiche: 21.643,5 150,5     Lettura fisica (blocchi): 13.575,1 94,4     Scrittura fisica (blocchi): 3.467,3 24,1     Leggi le richieste IO: 3.586,8 24,9     Scrivi richieste IO: 574,7 4.0     Leggi IO (MB): 106,1 0.7     Scrivi IO (MB): 27,1 0.2     Righe di scansione IM: 0,0 0,0     Sessione logica Read IM:         Chiamate utente: 1.245,7 8.7     Analisi (SQL): 4.626,2 32,2     Analisi rigide (SQL): 8.9 0.1     Area di lavoro SQL (MB): 824,9 5.7     Accessi: 1,7 0,0     Esegue (SQL): 136.656,5 950,4     Rollback: 22.9 0.2     Transazioni: 143,8       Sulla base di queste informazioni, è possibile calcolare gli IOP e il throughput nel modo seguente: IOPS = Richieste di I/O di lettura: + Richieste di I/O di scrittura = 3.586,8 + 574,7 = 4134,5 Throughput = lettura fisica (blocchi) +scrittura fisica (blocchi) = 13.575,1 + 3.467,3 = 17.042,4 Poiché la dimensione del blocco in Oracle è di 8 KB, puoi calcolare la velocità effettiva totale come segue: La velocità effettiva totale in MB è 17042,4 * 8 * 1024/1024/1024 = 133,2 MB Avviso: non utilizzate il profilo di carico per stimare la dimensione dell'istanza. Non è così preciso come le statistiche sull'attività delle istanze o i profili I/O.	DBA
Opzione 2: utilizza le statistiche sull'attività delle istanze.	Se utilizzi una versione del database Oracle precedente alla 12c, puoi utilizzare la sezione Instance Activity Stats del rapporto AWR per stimare gli IOPS e il throughput. La tabella seguente mostra un esempio di questa sezione. Statistic Totale al secondo per Trans richieste I/O totali di lettura fisica 2.547.333.217 3.610,28 25,11 byte totali di lettura fisica 80.776.296.124.928 114.482.426,26 796.149,98 richieste I/O totali di scrittura fisica 534.198.208 757,11 5,27 byte totali di scrittura fisici 25.517.678.849.024 36,165,631,84 251,508,18 Sulla base di queste informazioni, è possibile calcolare gli IOPS totali e il throughput nel modo seguente: IOPS totali = 3.610,28 + 757,11 = 4367 Mbps totali = 114.482.426,26 + 36.165.631,84 = 150648058,1/1024/1024 = 143 Mbps	DBA
Opzione 3: utilizzare i profili I/O.	In Oracle Database 12c, il rapporto AWR include una sezione Profili I/O che presenta tutte le informazioni in un'unica tabella e fornisce dati più accurati sulle prestazioni del database. La tabella seguente mostra un esempio di questa sezione.   Lettura+scrittura al secondo Lettura al secondo Scrivi al secondo Richieste totali: 4.367,4 3.610,3 757,1 Richieste al database: 4.161.5 3.586,8 574,7 Richieste ottimizzate: 0,0 0,0 0,0 Richieste di ripristino: 179,3 2.8 176,6 Totale (MB): 143,7 109,2 34,5 Banca dati (MB): 133,1 106,1 27,1 Totale ottimizzato (MB): 0,0 0,0 0,0 Ripeti (MB): 7.6 2.7 4.9 Database (blocchi): 17.042,4 13.575,1 3.467,3 Tramite Buffer Cache (blocchi): 5.898,5 5.360,9 537,6 Diretto (blocchi): 11.143,9 8.214,2 2.929,7 Questa tabella fornisce i seguenti valori per il throughput e gli IOPS totali: Throughput = 143 MBPS (dalla quinta riga, denominata Totale, seconda colonna) IOPS = 4.367,4 (dalla prima riga, denominata Total Requests, seconda colonna)	DBA
Opzione 4: utilizza le viste AWR.	È possibile visualizzare le stesse informazioni su IOPS e sulla velocità effettiva utilizzando le viste AWR. Per ottenere queste informazioni, utilizza la seguente query:  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

Stima dei requisiti della CPU

Attività	Descrizione	Competenze richieste
Scegli un metodo.	È possibile stimare la CPU richiesta per il database di destinazione in tre modi: Utilizzando i core effettivamente disponibili del processore Utilizzando i core utilizzati in base alle statistiche del sistema operativo Utilizzando i core utilizzati in base alle statistiche del database Se stai esaminando i core utilizzati, ti consigliamo di utilizzare il metodo delle metriche del database anziché le statistiche del sistema operativo, poiché si basa sulla CPU utilizzata solo dai database di cui intendi migrare. (Le statistiche del sistema operativo includono anche l'utilizzo della CPU da parte di altri processi). È inoltre necessario controllare i consigli relativi alla CPU nel rapporto ADDM per migliorare le prestazioni dopo la migrazione. È inoltre possibile stimare i requisiti in base alla generazione della CPU. Se utilizzi diverse generazioni di CPU, puoi stimare la CPU richiesta per il database di destinazione seguendo le istruzioni contenute nel white paper Demystifying the Number of vCPU for Optimal Workload Performance.	DBA
Opzione 1: stima i requisiti in base ai core disponibili.	Nei report AWR: Le CPU si riferiscono a CPU logiche e virtuali.  I core sono il numero di processori in un chipset CPU fisico.  Un socket è un dispositivo fisico che collega un chip a una scheda. I processori multi-core dispongono di socket con diversi core CPU. È possibile stimare i core disponibili in due modi: Utilizzando i comandi del sistema operativo Utilizzando il rapporto AWR Per stimare i core disponibili utilizzando i comandi del sistema operativo Utilizzate il comando seguente per contare i core del processore. $ 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 Utilizzate il seguente comando per contare i socket nel processore. grep "physical id" /proc/cpuinfo | sort -u physical id : 0 physical id : 1 Nota: non è consigliabile utilizzare comandi del sistema operativo come nmon e sar per estrarre l'utilizzo della CPU. Questo perché tali calcoli includono l'utilizzo della CPU da parte di altri processi e potrebbero non riflettere l'effettiva CPU utilizzata dal database. Per stimare i core disponibili utilizzando il rapporto AWR È inoltre possibile ricavare l'utilizzo della CPU dalla prima sezione del rapporto AWR. Ecco un estratto del rapporto. Nome DB ID DB Istanza Inserisci un numero Ora di avvio Versione RAC XXXX <DB_ID> XXXX 1 05 settembre - 20 23:09 12,10.2.0 NO Host Name (Nome host) Platform (Piattaforma) CPU Nuclei Prese Memoria (GB) <host_name> Linux x86 a 64 bit 80 80 2 441,78 In questo esempio, il numero di CPU è 80, il che indica che si tratta di CPU logiche (virtuali). È inoltre possibile notare che questa configurazione ha due socket, un processore fisico per socket (per un totale di due processori fisici) e 40 core per ogni processore o socket fisico.	DBA
Opzione 2: stima dell'utilizzo della CPU utilizzando le statistiche del sistema operativo.	È possibile controllare le statistiche sull'utilizzo della CPU del sistema operativo direttamente nel sistema operativo (utilizzando sar o un'altra utilità del sistema operativo host) o esaminando i valori IDLE/ (IDLE+BUSY) dalla sezione Operating System Statistics del rapporto AWR. Puoi vedere i secondi di CPU consumati direttamente da v$osstat. I report AWR e Statspack mostrano questi dati anche nella sezione Statistiche del sistema operativo. Se nella stessa casella sono presenti più database, tutti hanno gli stessi valori v$osstat per BUSY_TIME. Statistic Valore Valore finale FREE_MEMORY_BYTES 6.810.677.248 12.280,799,232 INACTIVE_MEMORY_BYTES 175.627.333.632 160,380,653,568 SWAP_FREE_BYTES 17.145.614.336 17,145,872,384 ORARIO DI LAVORO 1.305.569.937   TEMPO DI INATTIVITÀ 4.312.718.839   IOWAIT-TIME 53.417.174   BEL MOMENTO 29.815   SYS_TIME 148.567.570   TEMPO_UTENTE 1.146.918.783   CARICARE 25 29 VM_IN_BYTES 593.920   VM_OUT_BYTES 327.680   BYTE_DI MEMORIA FISICA 474.362.417.152   NUM_CPUS 80   NUM_CPU_CORES 80   NUM_CPU_SOCKETS 2   GLOBAL RECEIVE_SIZE_MAX 4.194.304   DIMENSIONE MASSIMA DI INVIO GLOBALE 2.097.152   TCP_RECEIVE_SIZE_DEFAULT 87.380   TCP_RECEIVE_SIZE_MAX 6.291.456   TCP_RECEIVE_SIZE_MIN 4,096   TCP_SEND_SIZE_DEFAULT 16,384   TCP_SEND_SIZE_MAX 4.194.304   TCP_SEND_SIZE_MIN 4,096   Se nel sistema non sono presenti altri utenti principali di CPU, utilizza la formula seguente per calcolare la percentuale di utilizzo della CPU: Utilizzo = Tempo di occupazione/Tempo totale Orario di lavoro = requisiti = V$OSStat.busy_time C = Tempo totale (occupato+inattivo) C = capacità = V$OSTAT.busy_time + V$OSTAT.idle_time Utilizzo = BUSY_TIME/(BUSY_TIME + IDLE_TIME) = -1.305.569.937/(1.305.569.937 + 4.312.718.839) = 23% utilizzato	DBA
Opzione 3: stima dell'utilizzo della CPU utilizzando le metriche del database.	Se nel sistema sono in esecuzione più database, puoi utilizzare le metriche del database visualizzate all'inizio del rapporto.   Snap Id Snap Time Sessioni Cursori/sessione Inizia Snap: 184662 28 settembre - 20 09:00:42 1226 35,8 Fine Snap: 185446 06-20 ottobre 13:00:20 1876 41,1 Trascorso:   11,759.64 (minuti)     Ora DB:   312.625.40 (minuti)     Per ottenere i parametri di utilizzo della CPU, usa questa formula: Utilizzo della CPU del database (% della potenza della CPU disponibile) = tempo CPU/NUM_CPUS /tempo trascorso dove l'utilizzo della CPU è descritto in base al tempo impiegato dalla CPU e rappresenta il tempo impiegato sulla CPU, non il tempo di attesa della CPU. Questo calcolo si traduce in: = 312.625,40/11.759,64/80 = viene utilizzato il 33% della CPU Numero di core (33%) * 80 = 26,4 core Core totali = 26,4 * (120%) = 31,68 core Puoi utilizzare il maggiore di questi due valori per calcolare l'utilizzo della CPU dell'istanza Amazon RDS o Aurora DB. Nota: su IBM AIX, l'utilizzo calcolato non corrisponde ai valori del sistema operativo o del database. Questi valori corrispondono su altri sistemi operativi.	DBA

Stima dei requisiti di memoria

Attività	Descrizione	Competenze richieste
Stima i requisiti di memoria utilizzando le statistiche sulla memoria.	È possibile utilizzare il report AWR per calcolare la memoria del database di origine e confrontarla nel database di destinazione. È inoltre necessario verificare le prestazioni del database esistente e ridurre i requisiti di memoria per risparmiare sui costi o aumentare i requisiti per migliorare le prestazioni. Ciò richiede un'analisi dettagliata del tempo di risposta AWR e del contratto sul livello di servizio (SLA) dell'applicazione. Utilizza la somma dell'utilizzo dell'area globale del sistema (SGA) e dell'area globale del programma (PGA) di Oracle come utilizzo stimato della memoria per Oracle. Aggiungi un ulteriore 20% per il sistema operativo per determinare il requisito di dimensione della memoria di destinazione. Per Oracle RAC, utilizza la somma dell'utilizzo stimato della memoria su tutti i nodi RAC e riduci la memoria totale, poiché è archiviata su blocchi comuni. Controlla le metriche nella tabella Percentuale di efficienza delle istanze. La tabella utilizza i seguenti termini: Buffer Hit% è la percentuale di volte in cui un determinato blocco è stato trovato nella buffer cache anziché eseguire un I/O fisico. Per prestazioni migliori, scegli il 100%.  Buffer Nowait% dovrebbe essere vicino al 100 percento. Latch Hit% dovrebbe essere vicino al 100 percento.  % Non-Parse CPU è la percentuale del tempo di CPU impiegato in attività non di analisi. Questo valore dovrebbe essere vicino al 100 percento. Percentuali di efficienza delle istanze (obiettivo 100%) Buffer Nowait%: 99,99 Ripeti%: NoWait 100,00 % di successo al buffer: 99,84 Ordinamento% in memoria: 100,00 % di visite alla libreria: 748,77 Analisi morbida%: 99,81 Esegui per analizzare%: 96,61 Percentuale di blocco: 100,00 Analizza la CPU per Parse Elapsd%: 72,73 % CPU non analizzata: 99,21 % di accessi alla cache Flash: 0,00     In questo esempio, tutte le metriche sembrano corrette, quindi puoi utilizzare SGA e PGA per il database esistente come requisito di pianificazione della capacità. Controllate la sezione delle statistiche sulla memoria e calcolate il valore SGA/PGA.   Inizia Fine Memoria ospitante (MB): 452.387,3 452.387,3 Uso SGA (MB): 220.544,0 220544,0 Uso PGA (MB): 36.874,9 45.270,0 Memoria totale dell'istanza in uso = SGA + PGA = 220 GB+ 45 GB = 265 GB Aggiungi il 20 percento del buffer: Memoria totale dell'istanza = 1,2 * 265 GB = 318 GB Poiché SGA e PGA rappresentano il 70 percento della memoria host, il fabbisogno totale di memoria è:  Memoria host totale = 318/0,7 = 464 GB Nota: quando esegui la migrazione ad Amazon RDS for Oracle, PGA e SGA vengono precalcolati in base a una formula predefinita. Assicurati che i valori precalcolati siano vicini alle tue stime.	DBA

Determina il tipo di istanza DB del database di destinazione

Attività	Descrizione	Competenze richieste
Determina il tipo di istanza DB in base alle stime di I/O del disco, CPU e memoria.	In base alle stime dei passaggi precedenti, la capacità del database Amazon RDS o Aurora di destinazione dovrebbe essere: 68 core di CPU 143 MBPS di velocità effettiva   4367 IOPS per I/O su disco 464 GB di memoria Nel database Amazon RDS o Aurora di destinazione, puoi mappare questi valori al tipo di istanza db.r5.16xlarge, che ha una capacità di 32 core, 512 GB di RAM e 13.600 Mbps di velocità effettiva. Per ulteriori informazioni, consulta il post sul blog di AWS: istanze Amazon RDS di dimensioni corrette su larga scala in base ai parametri delle prestazioni Oracle.	DBA

Risorse correlate

• Classe di istanza Aurora DB (documentazione Amazon Aurora)

• Storage di istanze database Amazon RDS (documentazione Amazon RDS)

• Strumento AWS Miner (GitHub repository)