Bagikan melalui

Performa database Oracle di Beberapa volume Azure NetApp Files

  • Artikel

Memigrasikan database kelas Exadata dengan performa tinggi ke cloud semakin menjadi penting bagi pelanggan Microsoft. Suite perangkat lunak rantai pasokan biasanya mengatur bar tinggi karena tuntutan intens pada I/O penyimpanan dengan beban kerja baca dan tulis campuran yang didorong oleh satu simpul komputasi. Infrastruktur Azure dalam kombinasi dengan Azure NetApp Files mampu memenuhi kebutuhan beban kerja yang sangat menuntut ini. Artikel ini menyajikan contoh bagaimana permintaan ini terpenuhi untuk satu pelanggan dan bagaimana Azure dapat memenuhi tuntutan beban kerja Oracle penting Anda.

Performa Oracle skala perusahaan

Saat menjelajahi batas atas performa, penting untuk mengenali dan mengurangi batasan apa pun yang dapat mengakibatkan kesalahan hasil condong. Misalnya, jika niatnya adalah untuk membuktikan kemampuan performa sistem penyimpanan, klien idealnya harus dikonfigurasi sehingga CPU tidak menjadi faktor mitigasi sebelum batas performa penyimpanan tercapai. Untuk itu, pengujian dimulai dengan jenis instans E104ids_v5 karena VM ini dilengkapi tidak hanya dengan antarmuka jaringan 100 Gbps, tetapi dengan batas keluar yang sama besarnya (100 Gbps).

Pengujian terjadi dalam dua fase:

  1. Fase pertama berfokus pada pengujian menggunakan alat SLOB2 (Silly Little Oracle Benchmark) standar industri Kevin Closson - versi 2.5.4. Tujuannya adalah untuk mendorong I/O Oracle sebanyak mungkin dari satu komputer virtual (VM) ke beberapa volume Azure NetApp Files, lalu peluasan skala menggunakan lebih banyak database untuk menunjukkan penskalaan linier.
  2. Setelah menguji batas penskalaan, pengujian kami dipivot ke yang lebih murah tetapi hampir mampu E96ds_v5 untuk fase pengujian pelanggan menggunakan beban kerja aplikasi Rantai Pasokan sejati dan data dunia nyata.

Performa peningkatan skala SLOB2

Bagan berikut menangkap profil performa satu E104ids_v5 Azure VM yang menjalankan satu database Oracle 19c terhadap delapan volume Azure NetApp Files dengan delapan titik akhir penyimpanan. Volume tersebar di tiga grup disk ASM: data, log, dan arsip. Lima volume dialokasikan ke grup disk data, dua volume ke grup disk log, dan satu volume ke grup disk arsip. Semua hasil yang diambil di seluruh artikel ini dikumpulkan menggunakan wilayah Azure produksi dan layanan Azure produksi aktif.

Untuk menyebarkan Oracle di komputer virtual Azure menggunakan beberapa volume Azure NetApp Files di beberapa titik akhir penyimpanan, gunakan grup volume aplikasi untuk Oracle.

Arsitektur host tunggal

Diagram berikut menggambarkan arsitektur tempat pengujian selesai; perhatikan database Oracle yang tersebar di beberapa volume dan titik akhir Azure NetApp Files.

Diagram subnet Oracle dengan kumpulan kapasitas Azure NetApp Files.

IO penyimpanan host tunggal

Diagram berikut menunjukkan beban kerja yang dipilih secara acak 100% dengan rasio hit buffer database sekitar 8%. SLOB2 mampu mendorong sekitar 850.000 permintaan I/O per detik sambil mempertahankan latensi peristiwa baca berurutan file DB submillisecond. Dengan ukuran blok database 8K yang berjumlah sekitar 6.800 MiB/dtk throughput penyimpanan.

Bagan memperlihatkan I/O penyimpanan acak host tunggal.

Throughput host tunggal

Diagram berikut menunjukkan bahwa, untuk beban kerja IO berurutan intensif bandwidth seperti pemindaian tabel penuh atau aktivitas RMAN, Azure NetApp Files dapat memberikan kemampuan bandwidth penuh dari E104ids_v5 VM itu sendiri.

Bagan batang memperlihatkan throughput berurutan host tunggal.

Catatan

Karena instans komputasi berada pada maksimum teoritis bandwidthnya, menambahkan hasil konkurensi aplikasi tambahan hanya dalam peningkatan latensi sisi klien. Ini menghasilkan beban kerja SLOB2 melebihi jangka waktu penyelesaian yang ditargetkan oleh karena itu jumlah utas dibatasi pada enam.

Performa peluasan skala SLOB2

Bagan berikut menangkap profil performa tiga E104ids_v5 Azure VM masing-masing menjalankan satu database Oracle 19c dan masing-masing dengan sekumpulan volume Azure NetApp Files mereka sendiri dan tata letak grup disk ASM yang identik seperti yang dijelaskan di bagian Meningkatkan performa. Grafik menunjukkan bahwa dengan multi-volume/multi-titik akhir Azure NetApp Files, performa dengan mudah diskalakan dengan konsistensi dan prediktabilitas.

Arsitektur multi-host

Diagram berikut menggambarkan arsitektur tempat pengujian selesai; perhatikan tiga database Oracle yang tersebar di beberapa volume dan titik akhir Azure NetApp Files. Titik akhir dapat didedikasikan untuk satu host seperti yang ditunjukkan dengan Oracle VM 1 atau dibagikan di antara host seperti yang ditunjukkan dengan Oracle VM2 dan Oracle VM 3.

Diagram manajemen penyimpanan otomatis Oracle untuk Azure NetApp Files.

IO penyimpanan multi-host

Diagram berikut menunjukkan beban kerja yang dipilih secara acak 100% dengan rasio hit buffer database sekitar 8%. SLOB2 mampu mendorong sekitar 850.000 permintaan I/O per detik di ketiga host satu per satu. SLOB2 dapat mencapai ini saat menjalankan secara paralel dengan total kolektif sekitar 2.500.000 permintaan I/O per detik dengan setiap host masih mempertahankan latensi peristiwa baca berurutan file db submillisecond. Dengan ukuran blok database 8K, ini berjumlah sekitar 20.000 MiB/dtk di antara ketiga host.

Grafik garis penyimpanan acak kolektif dari perspektif IO.

Throughput multi-host

Diagram berikut menunjukkan bahwa untuk beban kerja berurutan, Azure NetApp Files masih dapat memberikan kemampuan bandwidth penuh dari E104ids_v5 VM itu sendiri bahkan saat diskalakan keluar. SLOB2 mampu mendorong I/O yang berjumlah lebih dari 30.000 MiB/dtk di tiga host saat berjalan secara paralel.

Bagan batang bertumpuk dari throughput berurutan kolektif.

Performa dunia nyata

Setelah batas penskalakan diuji dengan SLOB2, pengujian dilakukan dengan rangkaian aplikasi rantai pasokan kata nyata terhadap Oracle pada file Azure NetApp dengan hasil yang sangat baik. Data berikut dari laporan Oracle Automatic Workload Repository (AWR) adalah tampilan yang disorot tentang bagaimana satu pekerjaan penting tertentu dilakukan.

Database ini memiliki IO tambahan yang signifikan selain beban kerja aplikasi karena kilas balik diaktifkan dan memiliki ukuran blok database 16k. Dari bagian profil IO dari laporan AWR, terlihat bahwa ada rasio penulisan yang berat dibandingkan dengan bacaan.

- Membaca dan menulis per detik Baca per detik Tulis per detik
Total (MB) 4,988.1 1,395.2 3,592.9

Meskipun peristiwa tunggu baca berurutan file db menunjukkan latensi yang lebih tinggi pada 2,2 ms daripada dalam pengujian SLOB2, pelanggan ini melihat pengurangan waktu eksekusi pekerjaan lima belas menit yang berasal dari database RAC di Exadata ke database instans tunggal di Azure.

Batasan sumber daya Azure

Semua sistem akhirnya mencapai batasan sumber daya, secara tradisional dikenal sebagai titik tersedak. Beban kerja database, terutama yang sangat menuntut seperti suite aplikasi rantai pasokan, adalah entitas intensif sumber daya. Menemukan batasan sumber daya ini dan mengerjakannya sangat penting untuk penyebaran yang berhasil. Bagian ini menggambarkan berbagai batasan yang mungkin Anda harapkan untuk ditemui hanya di lingkungan seperti itu dan cara mengerjakannya. Dalam setiap subbagian, harap pelajari praktik terbaik dan alasan di belakangnya.

Mesin virtual

Bagian ini merinci kriteria yang akan dipertimbangkan dalam memilih VM untuk performa terbaik dan alasan di balik pilihan yang dibuat untuk pengujian. Azure NetApp Files adalah layanan Network Attached Storage (NAS), oleh karena itu ukuran bandwidth jaringan yang sesuai sangat penting untuk performa optimal.

Chipset

Topik pertama yang menarik adalah pemilihan chipset. Pastikan bahwa SKU VM apa pun yang Anda pilih dibangun pada satu chipset karena alasan konsistensi. Varian Intel dari E_v5 VM berjalan pada konfigurasi Intel Xeon Platinum 8370C (Ice Lake) Generasi ketiga. Semua VM dalam keluarga ini dilengkapi dengan satu antarmuka jaringan 100 Gbps. Sebaliknya, seri E_v3, yang disebutkan melalui contoh, dibangun di atas empat chipset terpisah, dengan berbagai bandwidth jaringan fisik. Empat chipset yang digunakan dalam keluarga E_v3 (Broadwell, Skylake, Cascade Lake, Haswell) memiliki kecepatan prosesor yang berbeda, yang memengaruhi karakteristik performa mesin.

Baca dokumentasi Azure Compute dengan cermat memperhatikan opsi chipset. Lihat juga praktik terbaik SKU Azure VM untuk Azure NetApp Files. Memilih VM dengan satu chipset lebih disukai untuk konsistensi terbaik.

Bandwidth jaringan yang tersedia

Penting untuk memahami perbedaan antara bandwidth yang tersedia dari antarmuka jaringan VM dan bandwidth terukur yang diterapkan terhadap hal yang sama. Saat dokumentasi Azure Compute berbicara tentang batas bandwidth jaringan, batas ini diterapkan hanya pada keluar (tulis). Lalu lintas Ingress (baca) tidak diukur dan dengan demikian hanya dibatasi oleh bandwidth fisik kartu antarmuka jaringan (NIC) itu sendiri. Bandwidth jaringan sebagian besar VM melampaui batas keluar yang diterapkan terhadap komputer.

Karena volume Azure NetApp Files dilampirkan jaringan, batas keluar dapat dipahami sebagai diterapkan terhadap penulisan secara khusus sedangkan ingress didefinisikan sebagai beban kerja baca dan baca-seperti. Meskipun batas keluar sebagian besar komputer lebih besar dari bandwidth jaringan NIC, hal yang sama tidak dapat dikatakan untuk E104_v5 digunakan dalam pengujian untuk artikel ini. E104_v5 memiliki NIC 100 Gbps dengan batas keluar yang ditetapkan pada 100 Gbps juga. Sebagai perbandingan, E96_v5, dengan NIC 100 Gbps-nya memiliki batas egress 35 Gbps dengan ingress tidak terfettered pada 100 Gbps. Ketika VM berkurang ukurannya, batas keluar berkurang tetapi ingress tetap tidak terkekang oleh batas yang diberlakukan secara logis.

Batas keluar di seluruh VM dan diterapkan seperti itu terhadap semua beban kerja berbasis jaringan. Saat menggunakan Oracle Data Guard, semua penulisan digandakan untuk mengarsipkan log dan harus diperhitungkan untuk pertimbangan batas keluar. Ini juga berlaku untuk log arsip dengan multi-tujuan dan RMAN, jika digunakan. Saat memilih VM, biasakan diri Anda dengan alat baris perintah seperti ethtool, yang mengekspos konfigurasi NIC karena Azure tidak mendokumentasikan konfigurasi antarmuka jaringan.

Konkurensi jaringan

Volume Azure VM dan Azure NetApp Files dilengkapi dengan jumlah bandwidth tertentu. Seperti yang ditunjukkan sebelumnya, selama VM memiliki headroom CPU yang memadai, beban kerja dapat secara teori menggunakan bandwidth yang tersedia untuknya --yang berada dalam batas kartu jaringan dan atau batas keluar yang diterapkan. Namun, dalam praktiknya, jumlah throughput yang dapat dicapai diprediksi berdasarkan konkurensi beban kerja di jaringan, yaitu jumlah alur jaringan dan titik akhir jaringan.

Baca bagian batas alur jaringan dari dokumen bandwidth jaringan VM untuk pemahaman yang lebih besar. Takeaway: semakin banyak alur jaringan yang menghubungkan klien untuk menyimpan semakin kaya potensi performa.

Oracle mendukung dua klien NFS terpisah, Kernel NFS dan Direct NFS (dNFS). NFS Kernel, hingga terlambat, mendukung satu aliran jaringan antara dua titik akhir (komputasi – penyimpanan). NFS langsung, semakin berkinerja keduanya, mendukung jumlah variabel aliran jaringan - pengujian telah menunjukkan ratusan koneksi unik per titik akhir - meningkat atau menurun seiring permintaan beban. Karena penskalaan aliran jaringan antara dua titik akhir, NFS Langsung jauh lebih disukai daripada Kernel NFS, dan dengan demikian, konfigurasi yang direkomendasikan. Grup produk Azure NetApp Files tidak merekomendasikan penggunaan Kernel NFS dengan beban kerja Oracle. Untuk informasi selengkapnya, lihat Manfaat menggunakan Azure NetApp Files dengan Oracle Database.

Konkurensi eksekusi

Menggunakan NFS Langsung, satu chipset untuk konsistensi, dan memahami batasan bandwidth jaringan hanya membawa Anda sejauh ini. Pada akhirnya, aplikasi mendorong performa. Bukti konsep menggunakan SLOB2 dan bukti konsep menggunakan rangkaian aplikasi rantai pasokan dunia nyata terhadap data pelanggan nyata dapat mendorong jumlah throughput yang signifikan hanya karena aplikasi berjalan pada tingkat konkurensi yang tinggi; yang pertama menggunakan sejumlah besar utas per skema, yang terakhir menggunakan beberapa koneksi dari beberapa server aplikasi. Singkatnya, konkurensi mendorong beban kerja, konkurensi rendah--throughput rendah, konkurensi tinggi--throughput tinggi selama infrastruktur tersedia untuk mendukung hal yang sama.

Jaringan yang dipercepat

Jaringan terakselerasi memungkinkan virtualisasi I/O root tunggal (SR-IOV) ke VM, sangat meningkatkan performa jaringannya. Jalur berperforma tinggi ini melewati host dari jalur data, yang mengurangi latensi, jitter, dan pemanfaatan CPU untuk beban kerja jaringan yang paling menuntut pada jenis VM yang didukung. Saat menyebarkan VM melalui utilitas manajemen konfigurasi seperti terraform atau baris perintah, ketahuilah bahwa jaringan yang dipercepat tidak diaktifkan secara default. Untuk performa optimal, aktifkan jaringan yang dipercepat. Perhatikan bahwa jaringan yang dipercepat diaktifkan atau dinonaktifkan pada antarmuka jaringan berdasarkan antarmuka jaringan. Fitur jaringan yang dipercepat adalah fitur yang dapat diaktifkan atau dinonaktifkan secara dinamis.

Catatan

Artikel ini berisi referensi ke istilah SLAVE, istilah yang tidak lagi digunakan Microsoft. Ketika istilah ini dihapus dari perangkat lunak, kami akan menghapusnya dari artikel ini.

Pendekatan otoritatif untuk mengaktifkan jaringan yang dipercepat untuk NIC adalah melalui terminal Linux. Jika jaringan yang dipercepat diaktifkan untuk NIC, NIC virtual kedua ada yang terkait dengan NIC pertama. NIC kedua ini dikonfigurasi oleh sistem dengan SLAVE bendera diaktifkan. Jika tidak ada NIC yang ada dengan bendera, jaringan yang dipercepat tidak diaktifkan untuk antarmuka tersebut SLAVE .

Dalam skenario di mana beberapa NIC dikonfigurasi, Anda perlu menentukan antarmuka mana yang terkait dengan NIC yang SLAVE digunakan untuk memasang volume NFS. Menambahkan kartu antarmuka jaringan ke VM tidak berpengaruh pada performa.

Gunakan proses berikut untuk mengidentifikasi pemetaan antara antarmuka jaringan yang dikonfigurasi dan antarmuka virtual terkait. Proses ini memvalidasi bahwa jaringan yang dipercepat diaktifkan untuk NIC tertentu pada komputer Linux Anda dan menampilkan kecepatan masuk fisik yang berpotensi dicapai NIC.

  1. Jalankan ip a perintah: Cuplikan layar output perintah ip.
  2. Cantumkan /sys/class/net/ direktori ID NIC yang Anda verifikasi (eth0 dalam contoh) dan grep untuk kata yang lebih rendah: 
    ls /sys/class/net/eth0 | grep lower lower_eth1
  3. Jalankan ethtool perintah terhadap perangkat ethernet yang diidentifikasi sebagai perangkat yang lebih rendah di langkah sebelumnya. Cuplikan layar output pengaturan untuk eth1.

Azure VM: Batas bandwidth jaringan vs. disk

Tingkat keahlian diperlukan saat membaca dokumentasi batas performa Azure VM. Waspadalah terhadap:

  • Throughput penyimpanan sementara dan nomor IOPS mengacu pada kemampuan performa penyimpanan on-box sementara yang langsung dilampirkan ke VM.
  • Throughput disk dan nomor I/O yang tidak di-cache mengacu khusus ke Azure Disk (Premium, Premium v2, dan Ultra) dan tidak memiliki bearing pada penyimpanan terpasang jaringan seperti Azure NetApp Files.
  • Melampirkan NIC tambahan ke VM tidak berdampak pada batas performa atau kemampuan performa VM (didokumentasikan dan diuji menjadi benar).
  • Bandwidth jaringan maksimum mengacu pada batas keluar (yaitu, menulis ketika Azure NetApp Files terlibat) diterapkan terhadap bandwidth jaringan VM. Tidak ada batas ingress (yaitu, membaca saat Azure NetApp Files terlibat) diterapkan. Mengingat CPU yang cukup, konkurensi jaringan yang cukup, dan titik akhir yang cukup kaya, VM dapat secara teoritis mendorong lalu lintas masuk ke batas NIC. Seperti disebutkan di bagian Bandwidth jaringan yang tersedia, gunakan alat seperti ethtool untuk melihat bandwidth NIC.

Bagan sampel ditampilkan untuk referensi:

Cuplikan layar tabel yang memperlihatkan contoh data bagan.

File Azure NetApp

Layanan penyimpanan pihak pertama Azure Azure NetApp Files menyediakan solusi penyimpanan terkelola penuh yang sangat tersedia yang mampu mendukung beban kerja Oracle yang menuntut yang diperkenalkan sebelumnya.

Karena batas performa penyimpanan peningkatan skala dalam database Oracle dipahami dengan baik, artikel ini sengaja berfokus pada performa penyimpanan peluasan skala. Menskalakan performa penyimpanan menyiratkan memberikan akses instans Oracle tunggal ke banyak volume Azure NetApp Files tempat volume ini didistribusikan melalui beberapa titik akhir penyimpanan.

Dengan menskalakan beban kerja database di beberapa volume dengan cara seperti itu, performa database tidak tertaut dari batas atas volume dan titik akhir. Dengan penyimpanan tidak lagi memberlakukan batasan performa, arsitektur VM (batas keluar CPU, NIC, dan VM) menjadi titik tersedak untuk digabungkan. Seperti yang disebutkan di bagian VM, pemilihan instans E104ids_v5 dan E96ds_v5 dibuat mengingat hal ini.

Apakah database ditempatkan pada satu volume kapasitas besar atau tersebar di beberapa volume yang lebih kecil, total biaya keuangannya sama. Keuntungan mendistribusikan I/O di beberapa volume dan titik akhir berbeda dengan satu volume dan titik akhir adalah penghilangan batas bandwidth --Anda dapat menggunakan sepenuhnya apa yang Anda bayar.

Penting

Untuk menyebarkan menggunakan Azure NetApp Files dalam multiple volume:multiple endpoint konfigurasi, hubungi Spesialis Azure NetApp Files atau Arsitek Solusi Cloud Anda untuk mendapatkan bantuan.

Database

Database Oracle versi 19c adalah versi rilis jangka panjang Oracle saat ini dan yang digunakan untuk menghasilkan semua hasil pengujian yang dibahas dalam makalah ini.

Untuk performa terbaik, semua volume database dipasang menggunakan NFS Langsung, NFS Kernel direkomendasikan karena kendala performa. Untuk perbandingan performa antara kedua klien, lihat Performa database Oracle pada volume tunggal Azure NetApp Files. Perhatikan, semua patch dNFS yang relevan (ID Dukungan Oracle 1495104) diterapkan, seperti halnya praktik terbaik yang diuraikan dalam Oracle Database di Microsoft Azure menggunakan laporan Azure NetApp Files .

Sementara Oracle dan Azure NetApp Files mendukung NFSv3 dan NFSv4.1, karena NFSv3 adalah protokol yang lebih matang yang umumnya dipandang memiliki stabilitas terbanyak dan merupakan opsi yang lebih andal untuk lingkungan yang sangat sensitif terhadap gangguan. Pengujian yang dijelaskan dalam artikel ini semuanya diselesaikan melalui NFSv3.

Penting

Beberapa patch yang direkomendasikan yang didokumentasikan Oracle di ID Dukungan 1495104 sangat penting untuk mempertahankan integritas data saat menggunakan dNFS. Penerapan patch tersebut sangat disarankan untuk lingkungan produksi.

Manajemen Penyimpanan Otomatis (ASM) didukung untuk volume NFS. Meskipun biasanya dikaitkan dengan penyimpanan berbasis blok di mana ASM menggantikan manajemen volume logis (LVM) dan sistem file keduanya, ASM memainkan peran berharga dalam skenario NFS multi-volume dan patut dipertimbangkan dengan kuat. Salah satu keunggulan ASM, penambahan dan penyeimbangan ulang online dinamis di seluruh volume dan titik akhir NFS yang baru ditambahkan, menyederhanakan manajemen yang memungkinkan perluasan performa dan kapasitas sesuka hati. Meskipun ASM tidak masuk dan dari dirinya sendiri meningkatkan performa database, penggunaannya menghindari file panas dan kebutuhan untuk mempertahankan distribusi file secara manual --manfaat yang mudah dilihat.

ASM melalui konfigurasi dNFS digunakan untuk menghasilkan semua hasil pengujian yang dibahas dalam artikel ini. Diagram berikut mengilustrasikan tata letak file ASM dalam volume Azure NetApp Files dan alokasi file ke grup disk ASM.

Diagram Oracle Automatic Storage Management dengan Azure NetApp Files.

Ada beberapa batasan dengan penggunaan ASM melalui volume yang dipasang NFS Azure NetApp Files dalam hal rekam jepret penyimpanan yang dapat diatasi dengan pertimbangan arsitektur tertentu. Hubungi spesialis Azure NetApp Files atau arsitek solusi cloud Anda untuk tinjauan mendalam tentang pertimbangan ini.

Alat dan penyetelan uji sintetis

Bagian ini menjelaskan arsitektur pengujian, penyetelan, dan detail konfigurasi secara spesifik. Sementara bagian sebelumnya adalah alasan terfokus mengapa keputusan konfigurasi dibuat, bagian ini berfokus secara khusus pada "apa" keputusan konfigurasi.

Penyebaran otomatis

  • VM database disebarkan menggunakan skrip bash yang tersedia di GitHub.
  • Tata letak dan alokasi beberapa volume dan titik akhir Azure NetApp Files diselesaikan secara manual. Anda perlu bekerja dengan Spesialis Azure NetApp Files atau Arsitek Solusi Cloud untuk bantuan.
  • Penginstalan kisi, konfigurasi ASM, pembuatan dan konfigurasi database, dan lingkungan SLOB2 pada setiap komputer dikonfigurasi menggunakan Ansible untuk konsistensi.
  • Eksekusi pengujian Paralel SLOB2 di beberapa host juga diselesaikan menggunakan Ansible untuk konsistensi dan eksekusi simultan.

Konfigurasi komputer virtual

Konfigurasi Nilai
Wilayah Azure Eropa Barat
VM SKU E104ids_v5
Jumlah NIC 1 CATATAN: Menambahkan vNIC tidak berpengaruh pada jumlah sistem
Bandwidth jaringan keluar maks (Mbps) 100.000
Penyimpanan sementara (SSD) GiB 3,800

Konfigurasi sistem

Semua pengaturan konfigurasi sistem yang diperlukan Oracle untuk versi 19c diimplementasikan sesuai dengan dokumentasi Oracle.

Parameter berikut ditambahkan ke /etc/sysctl.conf file sistem Linux:

  • sunrpc.max_tcp_slot_table_entries: 128
  • sunrpc.tcp_slot_table_entries = 128

File Azure NetApp

Semua volume Azure NetApp Files dipasang dengan opsi pemasangan NFS berikut.

nfs rw,hard,rsize=262144,wsize=262144,sec=sys,vers=3,tcp

Parameter database

Parameter Nilai
db_cache_size 2g
large_pool_size 2g
pga_aggregate_target 3g
pga_aggregate_limit 3g
sga_target 25g
shared_io_pool_size 500m
shared_pool_size 5g
db_files 500
filesystemio_options SETALL
job_queue_processes 0
db_flash_cache_size 0
_cursor_obsolete_threshold 130
_db_block_prefetch_limit 0
_db_block_prefetch_quota 0
_db_file_noncontig_mblock_read_count 0

Konfigurasi SLOB2

Semua pembuatan beban kerja untuk pengujian selesai menggunakan alat SLOB2 versi 2.5.4.

Empat belas skema SLOB2 dimuat ke dalam ruang tabel Oracle standar dan dijalankan, yang dikombinasikan dengan pengaturan file konfigurasi slob yang tercantum, letakkan himpunan data SLOB2 pada 7 TiB. Pengaturan berikut mencerminkan eksekusi baca acak untuk SLOB2. Parameter SCAN_PCT=0 konfigurasi diubah menjadi SCAN_PCT=100 selama pengujian berurutan.

  • UPDATE_PCT=0
  • SCAN_PCT=0
  • RUN_TIME=600
  • SCALE=450G
  • SCAN_TABLE_SZ=50G
  • WORK_UNIT=32
  • REDO_STRESS=LITE
  • THREADS_PER_SCHEMA=1
  • DATABASE_STATISTICS_TYPE=awr

Untuk pengujian baca acak, sembilan eksekusi SLOB2 dilakukan. Jumlah utas ditingkatkan enam dengan setiap iterasi pengujian dimulai dari satu.

Untuk pengujian berurutan, tujuh eksekusi SLOB2 dilakukan. Jumlah utas ditingkatkan dua dengan setiap perulangan pengujian dimulai dari satu. Jumlah utas dibatasi pada enam karena mencapai batas maksimum bandwidth jaringan.

Metrik AWR

Semua metrik performa dilaporkan melalui Repositori Beban Kerja Otomatis Oracle (AWR). Berikut ini adalah metrik yang disajikan dalam hasil:

  • Throughput: jumlah throughput baca rata-rata dan throughput tulis dari bagian AWR Load Profile
  • Rata-rata membaca permintaan IO dari bagian AWR Load Profile
  • db file berurutan membaca waktu tunggu rata-rata peristiwa dari bagian AWR Foreground Wait Events

Migrasi dari sistem yang dibuat khusus dan direkayasa ke cloud

Oracle Exadata adalah sistem rekayasa --kombinasi perangkat keras dan perangkat lunak yang dianggap sebagai solusi paling dioptimalkan untuk menjalankan beban kerja Oracle. Meskipun cloud memiliki keuntungan signifikan dalam skema keseluruhan dunia teknis, sistem khusus ini dapat terlihat sangat menarik bagi mereka yang telah membaca dan melihat pengoptimalan yang telah dibangun Oracle di sekitar beban kerja khusus mereka.

Ketika datang untuk menjalankan Oracle di Exadata, ada beberapa alasan umum Exadata dipilih:

  • 1-2 beban kerja IO tinggi yang cocok untuk fitur Exadata dan karena beban kerja ini memerlukan fitur rekayasa Exadata yang signifikan, sisa database yang berjalan bersama dengan mereka dikonsolidasikan ke Exadata.
  • Beban kerja OLTP yang rumit atau sulit yang mengharuskan RAC untuk menskalakan dan sulit dirancang dengan perangkat keras kepemilikan tanpa pengetahuan mendalam tentang pengoptimalan Oracle atau mungkin utang teknis tidak dapat dioptimalkan.
  • Exadata yang ada kurang digunakan dengan berbagai beban kerja: ini ada baik karena migrasi sebelumnya, akhir masa pakai pada Exadata sebelumnya, atau karena keinginan untuk bekerja/menguji Exadata di rumah.

Sangat penting bagi setiap migrasi dari sistem Exadata untuk dipahami dari perspektif beban kerja dan seberapa sederhana atau kompleks migrasinya. Kebutuhan sekunder adalah untuk memahami alasan pembelian Exadata dari perspektif status. Keterampilan Exadata dan RAC memiliki permintaan yang lebih tinggi dan mungkin telah mendorong rekomendasi untuk membelinya oleh pemangku kepentingan teknis.

Penting

Tidak peduli skenarionya, take-away keseluruhan harus, untuk beban kerja database apa pun yang berasal dari Exadata, semakin banyak fitur kepemilikan Exadata yang digunakan, semakin kompleks migrasi dan perencanaannya. Lingkungan yang tidak banyak menggunakan fitur kepemilikan Exadata memiliki peluang untuk proses migrasi dan perencanaan yang lebih sederhana.

Ada beberapa alat yang dapat digunakan untuk menilai peluang beban kerja ini:

  • Repositori Beban Kerja Otomatis (AWR):
    • Semua database Exadata dilisensikan untuk menggunakan laporan AWR dan fitur performa dan diagnostik yang terhubung.
    • Selalu aktif dan mengumpulkan data yang dapat digunakan untuk melihat informasi beban kerja historis dan menilai penggunaan. Nilai puncak dapat menilai penggunaan tinggi pada sistem,
    • Laporan AWR jendela yang lebih besar dapat menilai beban kerja secara keseluruhan, memberikan wawasan berharga tentang penggunaan fitur dan cara memigrasikan beban kerja ke non-Exadata secara efektif. Laporan AWR puncak sebaliknya adalah yang terbaik untuk pengoptimalan dan pemecahan masalah performa.
  • Laporan AWR Global (RAC-Aware) untuk Exadata juga mencakup bagian spesifik Exadata, yang menelusuri penggunaan fitur Exadata tertentu dan menyediakan cache flash info wawasan yang berharga, pengelogan flash, IO dan penggunaan fitur lainnya berdasarkan database dan simpul sel.

Memisahkan dari Exadata

Saat mengidentifikasi beban kerja Oracle Exadata untuk bermigrasi ke cloud, pertimbangkan pertanyaan dan poin data berikut:

  • Apakah beban kerja menggunakan beberapa fitur Exadata, di luar manfaat perangkat keras?
    • Pemindaian cerdas
    • Indeks penyimpanan
    • Flash cache
    • Pengelogan flash
    • Kompresi kolom hibrid
  • Apakah beban kerja menggunakan offloading Exadata secara efisien? Dalam peristiwa latar depan waktu teratas, berapa rasio (lebih dari 10% waktu DB) beban kerja menggunakan:
    • Pemindaian tabel pintar sel (optimal)
    • Sel multiblock baca fisik (kurang optimal)
    • Sel satu blok baca fisik (paling tidak optimal)
  • Kompresi Kolumnar Hibrid (HCC/EHCC): Berapa rasio terkompresi vs. yang tidak dikompresi:
    • Apakah database menghabiskan lebih dari 10% waktu database untuk mengompresi dan mendekompresi data?
    • Periksa perolehan performa untuk predikat menggunakan kompresi dalam kueri: apakah nilai yang diperoleh sepadan versus jumlah yang disimpan dengan kompresi?
  • IO fisik sel: Periksa penghematan yang disediakan dari:
    • jumlah yang diarahkan ke simpul DB untuk menyeimbangkan CPU.
    • mengidentifikasi jumlah byte yang dikembalikan oleh pemindaian pintar. Nilai-nilai ini dapat dikurangi dalam IO untuk persentase baca fisik blok tunggal sel setelah memigrasikan Exadata.
  • Perhatikan jumlah bacaan logis dari cache. Tentukan apakah cache flash akan diperlukan dalam solusi IaaS cloud untuk beban kerja.
  • Bandingkan byte total baca dan tulis fisik dengan jumlah yang dilakukan total dalam cache. Dapatkah memori dinaikkan untuk menghilangkan persyaratan baca fisik (umum bagi beberapa orang untuk menyusutkan SGA untuk memaksa offloading untuk Exadata)?
  • Dalam Statistik Sistem, identifikasi objek apa yang terpengaruh oleh statistik apa. Jika menyetel SQL, pengindeksan lebih lanjut, partisi, atau penyetelan fisik lainnya dapat mengoptimalkan beban kerja secara dramatis.
  • Periksa Parameter Inisialisasi untuk parameter garis bawah (_) atau parameter yang tidak digunakan lagi, yang harus dibenarkan karena dampak tingkat database yang mungkin menyebabkan performa.

Konfigurasi server Exadata

Di Oracle versi 12.2 ke atas, penambahan spesifik Exadata akan disertakan dalam laporan global AWR. Laporan ini memiliki bagian yang memberikan nilai luar biasa untuk migrasi dari Exadata.

  • Versi exadata dan detail sistem

  • Detail pemberitahuan simpul sel

  • Disk nononline Exadata

  • Data outlier untuk statistik OS Exadata apa pun

    • Kuning/Merah Muda: Perhatian. Exadata tidak berjalan optimal.

    • Merah: Performa exadata terpengaruh secara signifikan.

    • Statistik CPU OS Exadata: sel atas

      • Statistik ini dikumpulkan oleh OS pada sel dan tidak dibatasi untuk database atau instans ini
      • Latar v belakang kuning tua dan menunjukkan nilai outlier di bawah rentang rendah
      • Latar ^ belakang kuning muda dan menunjukkan nilai outlier di atas rentang tinggi
      • Sel atas menurut persentase CPU ditampilkan dan berada dalam urutan menurun dari persentase CPU
      • Rata-rata: 39,34% CPU, 28,57% pengguna, 10,77% sys

      Cuplikan layar tabel yang memperlihatkan sel atas berdasarkan persentase CPU.

  • Bacaan blok fisik sel tunggal

  • Penggunaan cache flash

  • Temp IO

  • Efisiensi cache kolom

Database teratas menurut throughput IO

Meskipun penilaian ukuran dapat dilakukan, ada beberapa pertanyaan tentang rata-rata dan puncak simulasi yang dibangun ke dalam nilai-nilai ini untuk beban kerja besar. Bagian ini, yang ditemukan di akhir laporan AWR, sangat berharga karena menunjukkan flash rata-rata dan penggunaan disk dari 10 database teratas di Exadata. Meskipun banyak yang mungkin berasumsi bahwa mereka ingin mengukur database untuk performa puncak di cloud, ini tidak masuk akal untuk sebagian besar penyebaran (lebih dari 95% berada dalam rentang rata-rata; dengan puncak yang disimulasikan dihitung dalam, rentang rata-rata lebih besar dari 98%). Penting untuk membayar apa yang diperlukan, bahkan untuk beban kerja permintaan Oracle tertinggi dan memeriksa Database Teratas oleh Throughput IO dapat menjadi pencerahan untuk memahami kebutuhan sumber daya untuk database.

Oracle ukuran yang tepat menggunakan AWR di Exadata

Saat melakukan perencanaan kapasitas untuk sistem lokal, wajar jika memiliki overhead signifikan yang terpasang dalam perangkat keras. Perangkat keras yang disediakan berlebihan perlu melayani beban kerja Oracle selama beberapa tahun kedepan, terlepas dari penambahan beban kerja karena pertumbuhan data, perubahan kode, atau peningkatan.

Salah satu manfaat cloud adalah menskalakan sumber daya dalam host VM dan penyimpanan dapat dilakukan saat permintaan meningkat. Ini membantu menghemat biaya cloud dan biaya lisensi yang melekat pada penggunaan prosesor (berkaitan dengan Oracle).

Ukuran yang tepat melibatkan penghapusan perangkat keras dari migrasi lift dan shift tradisional dan menggunakan informasi beban kerja yang disediakan oleh Repositori Beban Kerja Otomatis (AWR) Oracle untuk mengangkat dan mengalihkan beban kerja ke komputasi dan penyimpanan yang dirancang khusus untuk mendukungnya di cloud pilihan pelanggan. Proses ukuran yang tepat memastikan bahwa arsitektur ke depan menghapus utang teknis infrastruktur, redundansi arsitektur yang akan terjadi jika duplikasi sistem lokal direplikasi ke cloud dan menerapkan layanan cloud jika memungkinkan.

Pakar subjek Microsoft Oracle telah memperkirakan bahwa lebih dari 80% database Oracle disediakan secara berlebihan dan mengalami biaya atau penghematan yang sama pergi ke cloud jika mereka meluangkan waktu untuk mengukur beban kerja database Oracle sebelum bermigrasi ke cloud. Penilaian ini mengharuskan spesialis database di tim untuk mengalihkan pola pikir mereka tentang bagaimana mereka mungkin telah melakukan perencanaan kapasitas di masa lalu, tetapi sepadan dengan investasi pemangku kepentingan di cloud dan strategi cloud bisnis.

Langkah berikutnya