Perkirakan ukuran mesin Amazon RDS untuk database Oracle dengan menggunakan laporan AWR - AWS Prescriptive Guidance
RingkasanPrasyarat dan batasanArsitekturAlatPraktik terbaikEpikSumber daya terkait

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Perkirakan ukuran mesin Amazon RDS untuk database Oracle dengan menggunakan laporan AWR

Abhishek Verma dan Eduardo Valentim, Amazon Web Services

Ringkasan

Saat Anda memigrasikan database Oracle ke Amazon Relational Database Service (Amazon RDS) atau Amazon Aurora, menghitung CPU, memori, dan disk I/O untuk database target adalah persyaratan utama. Anda dapat memperkirakan kapasitas database target yang diperlukan dengan menganalisis laporan Oracle Automatic Workload Repository (AWR). Pola ini menjelaskan cara menggunakan laporan AWR untuk memperkirakan nilai-nilai ini.

Basis data Oracle sumber dapat berada di lokasi atau di-host di instans Amazon Elastic Compute Cloud EC2 (Amazon), atau bisa juga berupa Amazon RDS for Oracle DB instans. Basis data target bisa berupa database Amazon RDS atau Aurora.

catatan

Perkiraan kapasitas akan lebih tepat jika mesin database target Anda adalah Oracle. Untuk database Amazon RDS lainnya, ukuran mesin dapat bervariasi karena perbedaan arsitektur database.

Kami menyarankan Anda menjalankan uji kinerja sebelum memigrasikan database Oracle Anda.

Prasyarat dan batasan

Prasyarat

  • Lisensi Oracle Database Enterprise Edition dan lisensi Oracle Diagnostics Pack untuk mengunduh laporan AWR.

Versi produk

  • Semua edisi Oracle Database untuk versi 11g (versi 11.2.0.3.v1 dan yang lebih baru) dan hingga 12.2, dan 18c, 19c.

  • Pola ini tidak mencakup Oracle Engineered Systems atau Oracle Cloud Infrastructure (OCI).

Arsitektur

Tumpukan teknologi sumber

Salah satu dari yang berikut:

  • Database Oracle lokal

  • Database Oracle pada sebuah instance EC2

  • Instans Amazon RDS for Oracle DB

Tumpukan teknologi target

  • Basis data Amazon RDS atau Amazon Aurora apa pun

Arsitektur target

Untuk informasi tentang proses migrasi lengkap, lihat pola Memigrasikan database Oracle ke Aurora PostgreSQL menggunakan AWS DMS dan AWS SCT.

Otomatisasi dan skala

Jika Anda memiliki beberapa database Oracle untuk dimigrasi dan Anda ingin menggunakan metrik kinerja tambahan, Anda dapat mengotomatiskan proses dengan mengikuti langkah-langkah yang dijelaskan dalam posting blog Instans Amazon RDS ukuran kanan pada skala berdasarkan metrik kinerja Oracle.

Alat

  • Oracle Automatic Workload Repository (AWR) adalah repositori yang dibangun ke dalam database Oracle. Ini secara berkala mengumpulkan dan menyimpan aktivitas sistem dan data beban kerja, yang kemudian dianalisis oleh Automatic Database Diagnostic Monitor (ADDM). AWR mengambil snapshot data kinerja sistem secara berkala (secara default, setiap 60 menit) dan menyimpan informasi (secara default, hingga 8 hari).  Anda dapat menggunakan tampilan dan laporan AWR untuk menganalisis data ini.

Praktik terbaik

  • Untuk menghitung persyaratan sumber daya untuk database target, Anda dapat menggunakan satu laporan AWR, beberapa laporan AWR, atau tampilan AWR dinamis. Kami menyarankan Anda menggunakan beberapa laporan AWR selama periode beban puncak untuk memperkirakan sumber daya yang diperlukan untuk menangani beban puncak tersebut. Selain itu, tampilan dinamis memberikan lebih banyak titik data yang membantu Anda menghitung kebutuhan sumber daya dengan lebih tepat. 

  • Anda harus memperkirakan IOPS hanya untuk database yang Anda rencanakan untuk dimigrasi, bukan untuk database dan proses lain yang menggunakan disk.

  • Untuk menghitung berapa banyak yang I/O digunakan oleh database, jangan gunakan informasi di bagian Load Profile pada laporan AWR. Gunakan bagian I/O Profil sebagai gantinya, jika tersedia, atau lewati ke bagian Statistik Aktivitas Instance dan lihat nilai total untuk operasi baca dan tulis fisik.

  • Saat Anda memperkirakan pemanfaatan CPU, sebaiknya gunakan metode metrik basis data alih-alih statistik sistem operasi (OS), karena didasarkan pada CPU yang hanya digunakan oleh database. (Statistik OS juga mencakup penggunaan CPU oleh proses lain.) Anda juga harus memeriksa rekomendasi terkait CPU dalam laporan ADDM untuk meningkatkan kinerja setelah migrasi.

  • Pertimbangkan batas I/O throughput―Amazon Elastic Block Store (Amazon EBS) throughput dan throughput jaringan―untuk ukuran instans tertentu saat Anda menentukan jenis instans yang tepat.

  • Jalankan uji kinerja sebelum migrasi untuk memvalidasi ukuran mesin.

Epik

TugasDeskripsiKeterampilan yang dibutuhkan

Aktifkan laporan AWR.

Untuk mengaktifkan laporan, ikuti instruksi dalam dokumentasi Oracle.

DBA

Periksa periode retensi.

Untuk memeriksa periode retensi laporan AWR, gunakan kueri berikut.

SQL> SELECT snap_interval,retention FROM dba_hist_wr_control;
DBA

Hasilkan snapshot.

Jika interval snapshot AWR tidak cukup terperinci untuk menangkap lonjakan beban kerja puncak, Anda dapat membuat laporan AWR secara manual. Untuk menghasilkan snapshot AWR manual, gunakan kueri berikut.

SQL> EXEC dbms_workload_repository.create_snapshot;
DBA

Periksa snapshot terbaru.

Untuk memeriksa snapshot AWR terbaru, gunakan kueri berikut.

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
TugasDeskripsiKeterampilan yang dibutuhkan

Pilih metode.

IOPS adalah ukuran standar operasi input dan output per detik pada perangkat penyimpanan, dan mencakup operasi baca dan tulis. 

Jika Anda memigrasikan database lokal ke AWS, Anda perlu menentukan disk puncak yang I/O digunakan oleh database. Anda dapat menggunakan metode berikut untuk memperkirakan disk I/O untuk database target Anda:

  • Muat bagian Profil dari laporan AWR

  • Bagian Statistik Aktivitas Instance dari laporan AWR (gunakan bagian ini untuk Oracle Database 12c atau yang lebih baru)

  • Bagian Profil I/O dari laporan AWR (gunakan bagian ini untuk versi Oracle Database sebelum 12c)

  • Tampilan AWR

Langkah-langkah berikut menjelaskan keempat metode ini.

DBA

Opsi 1: Gunakan profil beban.

Tabel berikut menunjukkan contoh bagian Load Profile dari laporan AWR.

penting

Untuk informasi yang lebih akurat, kami sarankan Anda menggunakan opsi 2 (profil I/O) atau opsi 3 (statistik aktivitas instance) alih-alih profil pemuatan.

 

Per Detik

Per Transaksi

Per Exec

Per Panggilan

Waktu DB:

26.6

0,2

0.00

0,02

CPU DB:

18.0

0,1

0.00

0,01

Latar Belakang CPU:

0,2

0.0

0.00

0.00

Ulangi ukuran (byte):

2,458.539.9

17,097,5

 

 

Bacaan logis (blok):

3,371,931,5

23,449,6

 

 

Perubahan blok:

21,643,5

150,5

 

 

Bacaan fisik (blok):

13,575,1

94.4

 

 

Tulis fisik (blok):

3,467,3

24.1

 

 

Baca permintaan IO:

3,586.8

24.9

 

 

Tulis permintaan IO:

574,7

4.0

 

 

Baca IO (MB):

106.1

0,7

 

 

Tulis IO (MB):

27.1

0,2

 

 

Baris pemindaian IM:

0.0

0.0

 

 

Sesi Logis Baca IM:

 

 

 

 

Panggilan pengguna:

1,245,7

8.7

 

 

Parses (SQL):

4,626,2

32.2

 

 

Parse keras (SQL):

8.9

0,1

 

 

Area Kerja SQL (MB):

824.9

5.7

 

 

Logon:

1.7

0.0

 

 

Mengeksekusi (SQL):

136,656,5

950,4

 

 

Rollback:

22.9

0,2

 

 

Transaksi:

143,8

 

 

 

Berdasarkan informasi ini, Anda dapat menghitung IOPs dan throughput sebagai berikut:

IOPS = Baca I/O permintaan: + I/O Permintaan tulis = 3,586,8 + 574,7 = 4134,5

Throughput = Bacaan fisik (blok) +Tulis fisik (blok) = 13,575,1 + 3,467,3 = 17,042,4

Karena ukuran blok di Oracle adalah 8 KB, Anda dapat menghitung total throughput sebagai berikut:

Total throughput dalam MB adalah 17042.4 * 8 * 1024/1024/1024 = 133,2 MB

Awas

Jangan gunakan profil pemuatan untuk memperkirakan ukuran instans. Ini tidak setepat statistik aktivitas instance atau I/O profil.

DBA

Opsi 2: Gunakan statistik aktivitas instance.

Jika Anda menggunakan versi Oracle Database sebelum 12c, Anda dapat menggunakan bagian Statistik Aktivitas Instance dari laporan AWR untuk memperkirakan IOPS dan throughput. Tabel berikut menunjukkan contoh bagian ini.

Statistik

Total

per detik

per Trans

permintaan IO total baca fisik

2,547,333,217

3,610.28

25.11

total byte baca fisik

80,776,296,124,928

114,482,426,26

796,149.98

tulis fisik total permintaan IO

534,198,208

757.11

5.27

fisik menulis total byte

25.517,678,849,024

36,165,631.84

251,508.18

Berdasarkan informasi ini, Anda dapat menghitung total IOPS dan throughput sebagai berikut:

Total IOPS = 3,610.28 + 757.11 = 4367

Total Mbps = 114,482,426.26 + 36,165,631.84 = 150648058.1/1024/1024 = 143 Mbps

DBA

Opsi 3: Gunakan I/O profil.

Dalam Oracle Database 12c, laporan AWR mencakup bagian I/O Profil yang menyajikan semua informasi dalam satu tabel dan memberikan data yang lebih akurat tentang kinerja database. Tabel berikut menunjukkan contoh bagian ini.

 

Baca+Tulis Per Detik

Baca per Detik

Menulis Per Detik

Jumlah Permintaan:

4,367,4

3,610.3

757.1

Permintaan Database:

4,161,5

3,586.8

574,7

Permintaan yang Dioptimalkan:

0.0

0.0

0.0

Permintaan Ulangi:

179.3

2.8

176.6

Jumlah (MB):

143,7

109.2

34,5

Database (MB):

133.1

106.1

27.1

Total yang Dioptimalkan (MB):

0.0

0.0

0.0

Ulangi (MB):

7.6

2.7

4.9

Database (blok):

17,042,4

13,575,1

3,467,3

Melalui Buffer Cache (blok):

5,898,5

5,360,9

537,6

Langsung (blok):

11,143,9

8,214,2

2,929,7

Tabel ini memberikan nilai-nilai berikut untuk throughput dan total IOPS:

Throughput = 143 MBPS (dari baris kelima, berlabel Total, kolom kedua)

IOPS = 4.367.4 (dari baris pertama, berlabel Total Permintaan, kolom kedua)

DBA

Opsi 4: Gunakan tampilan AWR.

Anda dapat melihat IOPS dan informasi throughput yang sama dengan menggunakan tampilan AWR. Untuk mendapatkan informasi ini, gunakan kueri berikut: 

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
TugasDeskripsiKeterampilan yang dibutuhkan

Pilih metode.

Anda dapat memperkirakan CPU yang diperlukan untuk database target dengan tiga cara:

  • Dengan menggunakan inti prosesor yang tersedia sebenarnya

  • Dengan menggunakan core yang digunakan berdasarkan statistik OS

  • Dengan menggunakan core yang digunakan berdasarkan statistik database

Jika Anda melihat inti yang digunakan, kami sarankan Anda menggunakan metode metrik database alih-alih statistik OS, karena didasarkan pada CPU yang hanya digunakan oleh database yang Anda rencanakan untuk dimigrasikan. (Statistik OS juga mencakup penggunaan CPU oleh proses lain.) Anda juga harus memeriksa rekomendasi terkait CPU dalam laporan ADDM untuk meningkatkan kinerja setelah migrasi.

Anda juga dapat memperkirakan persyaratan berdasarkan generasi CPU. Jika Anda menggunakan generasi CPU yang berbeda, Anda dapat memperkirakan CPU yang diperlukan dari database target dengan mengikuti instruksi di whitepaper Mengungkap Jumlah v CPUs untuk Kinerja Beban Kerja Optimal.

DBA

Opsi 1: Perkirakan persyaratan berdasarkan inti yang tersedia.

Dalam laporan AWR:

  • CPUs mengacu pada logis dan virtual CPUs. 

  • Core adalah jumlah prosesor dalam chipset CPU fisik. 

  • Soket adalah perangkat fisik yang menghubungkan chip ke papan. Prosesor multi-core memiliki soket dengan beberapa core CPU.

Anda dapat memperkirakan core yang tersedia dengan dua cara:

  • Dengan menggunakan perintah OS

  • Dengan menggunakan laporan AWR

Untuk memperkirakan core yang tersedia dengan menggunakan perintah OS

Gunakan perintah berikut untuk menghitung inti dalam prosesor.

$ 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

Gunakan perintah berikut untuk menghitung soket di prosesor.

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

  Kami tidak menyarankan menggunakan perintah OS seperti nmon dan sar untuk mengekstrak pemanfaatan CPU. Ini karena perhitungan tersebut mencakup pemanfaatan CPU oleh proses lain dan mungkin tidak mencerminkan CPU aktual yang digunakan oleh database.

Untuk memperkirakan core yang tersedia dengan menggunakan laporan AWR

Anda juga dapat memperoleh pemanfaatan CPU dari bagian pertama laporan AWR. Berikut kutipan dari laporan tersebut.

Nama DB

Id DB

Instans

Inst num

Waktu Startup

Rilis

RAC

XXXX

<DB_ID>

XXXX

1

05-Sep-20 23:09

12.1.0.2.0

TIDAK

Nama Host

Platform

CPUs

Inti

Soket

Memori (GB)

<host_name>

Linux x86 64-bit

80

80

2

441.78

Dalam contoh ini, CPUs hitungannya adalah 80, yang menunjukkan bahwa ini logis (virtual) CPUs. Anda juga dapat melihat bahwa konfigurasi ini memiliki dua soket, satu prosesor fisik pada setiap soket (untuk total dua prosesor fisik), dan 40 core untuk setiap prosesor fisik atau soket. 

DBA

Opsi 2: Perkirakan pemanfaatan CPU dengan menggunakan statistik OS.

Anda dapat memeriksa statistik penggunaan CPU OS baik secara langsung di OS (menggunakan sar atau utilitas OS host lain) atau dengan meninjau nilai IDLE/ (IDLE+BUSY) dari bagian Statistik Sistem Operasi dari laporan AWR. Anda dapat melihat detik-detik CPU yang dikonsumsi langsung dari v$osstat. Laporan AWR dan Statspack juga menunjukkan data ini di bagian Statistik Sistem Operasi.

Jika ada beberapa database pada kotak yang sama, semuanya memiliki nilai v$osstat yang sama untuk BUSY_TIME.

Statistik

Nilai

Nilai Akhir

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

SIBUK_WAKTU

1,305,569,937

 

IDLE_TIME

4,312,718,839

 

IOWAIT_WAKTU

53,417,174

 

BAGUS_WAKTU

29,815

 

SYS_WAKTU

148,567,570

 

USER_TIME

1,146,918.783

 

BEBAN

25

29

VM_IN_BYTES

593.920

 

VM_OUT_BYTES

327.680

 

PHYSICAL_MEMORY_BYTES

474,362,417.152

 

NUM_CPU

80

 

NUM_CPU_CORES

80

 

NUM_CPU_SOCKETS

2

 

GLOBAL_RECEIVE_SIZE_MAX

4,194,304

 

GLOBAL_SEND_SIZE_MAX

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

 

Jika tidak ada konsumen CPU utama lainnya dalam sistem, gunakan rumus berikut untuk menghitung persentase pemanfaatan CPU:

Pemanfaatan = Waktu sibuk/Total waktu

Waktu sibuk = persyaratan = v$osstat.Busy_time

C = Total waktu (Sibuk+Menganggur)

C = kapasitas = v$ostat.Busy_time + v$ostat.idle_time

Pemanfaatan = BUSY_TIME/(BUSY_TIME + IDLE_TIME)

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

= 23% digunakan

DBA

Opsi 3: Perkirakan pemanfaatan CPU dengan menggunakan metrik database.

Jika beberapa database berjalan di sistem, Anda dapat menggunakan metrik database yang muncul di awal laporan.

 

Snap Id

Waktu Jepret

Sesi

Kursor/Sesi

Mulai Snap:

184662

28-Sep-20 09:00:42

1226

35.8

Akhiri Snap:

185446

06-Okt-20 13:00:20

1876

41.1

Berlalu:

 

11.759.64 (menit)

 

 

Waktu DB:

 

312.625.40 (menit)

 

 

Untuk mendapatkan metrik pemanfaatan CPU, gunakan rumus ini:

Penggunaan CPU basis data (% dari daya CPU yang tersedia) = Waktu CPU/NUM_CPUS/waktu berlalu

di mana penggunaan CPU dijelaskan oleh waktu CPU dan mewakili waktu yang dihabiskan untuk CPU, bukan waktu menunggu CPU. Perhitungan ini menghasilkan:

= 312.625.40/ 11,759.64/80 = 33% CPU sedang digunakan

Jumlah core (33%) * 80 = 26,4 core

Total inti = 26,4 * (120%) = 31,68 inti

Anda dapat menggunakan yang lebih besar dari dua nilai ini untuk menghitung pemanfaatan CPU dari instans Amazon RDS atau Aurora DB.

catatan

Di IBM AIX, pemanfaatan yang dihitung tidak sesuai dengan nilai dari sistem operasi atau database. Nilai-nilai ini memang cocok pada sistem operasi lain.

DBA
TugasDeskripsiKeterampilan yang dibutuhkan

Perkirakan kebutuhan memori dengan menggunakan statistik memori.

Anda dapat menggunakan laporan AWR untuk menghitung memori database sumber dan mencocokkannya di database target. Anda juga harus memeriksa kinerja database yang ada dan mengurangi kebutuhan memori Anda untuk menghemat biaya, atau meningkatkan kebutuhan Anda untuk meningkatkan kinerja. Itu membutuhkan analisis rinci tentang waktu respons AWR dan perjanjian tingkat layanan (SLA) aplikasi. Gunakan jumlah penggunaan Oracle system global area (SGA) dan program global area (PGA) sebagai estimasi pemanfaatan memori untuk Oracle. Tambahkan tambahan 20 persen untuk OS untuk menentukan persyaratan ukuran memori target. Untuk Oracle RAC, gunakan jumlah estimasi pemanfaatan memori pada semua node RAC dan kurangi total memori, karena disimpan di blok umum.

  1. Periksa metrik dalam tabel Persentase Efisiensi Instans. Tabel menggunakan istilah-istilah berikut:

    • Buffer Hit% adalah persentase kali blok tertentu ditemukan di cache buffer alih-alih melakukan I/O fisik. Untuk kinerja yang lebih baik, targetkan 100 persen. 

    • Buffer Nowait% harus mendekati 100 persen.

    • Latch Hit% harus mendekati 100 persen. 

    • % Non-Parse CPU adalah persentase waktu CPU yang dihabiskan dalam aktivitas non-parsing. Nilai ini harus mendekati 100 persen..

    Persentase Efisiensi Instance (target 100%)

    Penyangga Nowait%:

    99,99

    Ulangi NoWait %:

    100.00

    Penyangga Hit%:

    99,84

    Urutan% dalam memori:

    100.00

    Pustaka Hit%:

    748.77

    Soft Parse%:

    99,81

    Jalankan ke Parse%:

    96,61

    Kait Hit%:

    100.00

    Parse CPU untuk Parse Elapsd%:

    72,73

    % CPU Non-Parse:

    99,21

    Flash Cache Hit%:

    0.00

     

     

    Dalam contoh ini, semua metrik terlihat bagus, sehingga Anda dapat menggunakan SGA dan PGA untuk database yang ada sebagai persyaratan perencanaan kapasitas.

  2. Periksa bagian statistik memori dan hitung SGA/PGA.

     

    Mulailah

    Akhiri

    Tuan Rumah Mem (MB):

    452,387.3

    452,387.3

    Penggunaan SGA (MB):

    220,544,0

    220,544,0

    Penggunaan PGA (MB):

    36,874,9

    45,270,0

Total memori instance yang digunakan = SGA+PGA = 220 GB+45 GB = 265 GB

Tambahkan 20 persen buffer:

Total memori instance = 1,2 * 265 GB = 318 GB

Karena SGA dan PGA menyumbang 70 persen dari memori host, kebutuhan memori total adalah: 

Total memori host = 318/0,7 = 464 GB

catatan

Saat Anda bermigrasi ke Amazon RDS for Oracle, PGA dan SGA dihitung sebelumnya berdasarkan rumus yang telah ditentukan sebelumnya. Pastikan nilai yang telah dihitung sebelumnya mendekati perkiraan Anda.

DBA
TugasDeskripsiKeterampilan yang dibutuhkan

Tentukan jenis instans DB berdasarkan disk I/O, CPU, dan estimasi memori.

Berdasarkan perkiraan pada langkah sebelumnya, kapasitas target Amazon RDS atau database Aurora harus:

  • 68 core dari CPU

  • 143 MBPS throughput  

  • 4367 IOPS untuk disk I/O

  • Memori 464 GB

Dalam database Amazon RDS atau Aurora target, Anda dapat memetakan nilai-nilai ini ke tipe instans db.r5.16xlarge, yang memiliki kapasitas 32 core, 512 GB RAM, dan 13.600 Mbps throughput. Untuk informasi selengkapnya, lihat posting blog AWS Instans Amazon RDS ukuran kanan pada skala berdasarkan metrik kinerja Oracle.

DBA

Sumber daya terkait