Penyebaran database Azure Virtual Machines Oracle untuk beban kerja SAP
Dokumen ini mencakup beberapa jenis area yang perlu dipertimbangkan saat menyebarkan Oracle Database untuk beban kerja SAP di Azure IaaS. Sebelum Anda membaca dokumen ini, sebaiknya Anda membaca Pertimbangan untuk penyebaran DBMS Azure Virtual Machines untuk beban kerja SAP. Kami juga menyarankan Anda membaca panduan lain di beban kerja SAP di dokumentasi Azure.
Anda dapat menemukan informasi tentang versi Oracle dan versi OS terkait yang didukung untuk menjalankan SAP di Oracle di Azure di SAP Note 2039619.
Informasi umum tentang menjalankan SAP Business Suite di Oracle dapat ditemukan di SAP di Oracle. Oracle mendukung untuk menjalankan database Oracle di Microsoft Azure. Untuk informasi selengkapnya tentang dukungan umum untuk Windows Hyper-V dan Azure, periksa Tanya Jawab Umum Oracle dan Microsoft Azure.
Catatan SAP berikut ini relevan untuk Penginstalan Oracle
Spesifik untuk Oracle Database di Oracle Linux
Oracle mendukung untuk menjalankan instans database mereka di Microsoft Azure dengan Oracle Linux sebagai OS tamu. Untuk informasi selengkapnya tentang dukungan umum untuk Windows Hyper-V dan Azure, lihat FAQ Azure dan Oracle.
Skenario spesifik aplikasi SAP menggunakan Oracle Databases juga didukung. Informasi detailnya dibahas di bagian dokumen berikutnya.
Rekomendasi Umum untuk menjalankan SAP di Oracle di Azure
Menginstal atau memigrasikan SAP yang ada pada sistem Oracle ke Azure, pola penyebaran berikut harus diikuti:
- Gunakan versi Oracle Linux terbaru yang tersedia (Oracle Linux 8.6 atau yang lebih tinggi).
- Gunakan versi Oracle Database terbaru yang tersedia dengan Patch Bundel SAP (SBP) (Oracle 19 Patch 15 atau yang lebih tinggi) terbaru 2799920 - Patch untuk 19c: Database.
- Gunakan Manajemen Penyimpanan Otomatis (ASM) untuk database berukuran kecil, sedang, dan besar pada penyimpanan blok.
- SSD Penyimpanan Premium Azure harus digunakan. Jangan gunakan Jenis penyimpanan Standar atau lainnya.
- ASM menghapus persyaratan untuk Log Cermin. Ikuti panduan dari Oracle di Catatan 888626 - Ulangi tata letak log untuk sistem kelas atas.
- Gunakan ASMLib dan jangan gunakan udev.
- Penyebaran Azure NetApp Files harus menggunakan Oracle dNFS (solusi NFS Langsung performa tinggi Oracle sendiri).
- Database Oracle besar mendapat manfaat besar dari ukuran System Global Area (SGA) yang besar. Pelanggan besar harus menyebarkan pada Seri M Azure dengan ukuran RAM 4 TB atau lebih
- Setel Halaman Besar Linux menjadi 75% dari ukuran RAM Fisik
- Atur System Global Area (SGA) ke 90% dari ukuran Halaman Besar
- Atur parameter Oracle USE_LARGE_PAGES = ONLY - Nilai HANYA lebih disukai daripada nilai TRUE karena nilai HANYA seharusnya memberikan performa yang lebih konsisten dan dapat diprediksi. Nilai TRUE dapat mengalokasikan halaman 2MB besar dan standar 4K. Nilai HANYA akan selalu memaksa halaman besar 2MB. Jika jumlah halaman besar yang tersedia tidak cukup atau tidak dikonfigurasi dengan benar, instans database akan gagal dimulai dengan kode kesalahan: ora-27102 : kehabisan memori Linux_x86_64 Kesalahan 12 : tidak dapat mengalokasikan memori. Jika memori yang berdekatan tidak memadai, Oracle Linux mungkin perlu dimulai ulang dan/atau parameter Halaman Besar Sistem Operasi dikonfigurasi ulang.
- Oracle Home harus terletak di luar volume atau disk "root". Gunakan disk terpisah atau volume ANF. Disk yang memegang Oracle Home harus berukuran 64 Gigabyte atau lebih besar.
- Ukuran disk boot untuk server database Oracle performa tinggi yang besar adalah penting. Minimal disk P10 harus digunakan untuk seri M atau seri E. Jangan gunakan disk kecil seperti P4 atau P6. Disk kecil dapat menyebabkan masalah performa.
- Jaringan terakselerasi harus diaktifkan pada semua Komputer Virtual. Tingkatkan ke rilis Oracle Linux terbaru jika ada masalah saat mengaktifkan Jaringan Terakselerasi.
- Periksa pembaruan dalam dokumentasi ini dan catatan SAP 2039619 - Aplikasi SAP di Microsoft Azure menggunakan Oracle Database: Produk dan Versi yang Didukung - Launchpad Dukungan SAP ONE.
Untuk informasi tentang versi Oracle dan versi OS terkait mana yang didukung untuk menjalankan SAP di Oracle di Azure Virtual Machines, lihat Catatan SAP 2039619.
Informasi umum tentang menjalankan SAP Business Suite di Oracle dapat ditemukan di halaman komunitas SAP di Oracle. SAP di Oracle di Azure hanya didukung di Oracle Linux (dan bukan Suse atau Red Hat) untuk server aplikasi dan database. Server ASCS/ERS dapat menggunakan RHEL/SUSE karena klien Oracle tidak diinstal atau digunakan pada VM ini. Server Aplikasi (PAS/AAS) tidak boleh diinstal pada VM ini. Lihat SAP Note 3074643 - OLNX: FAQ: jika Pacemaker untuk Oracle Linux didukung di Lingkungan SAP. Oracle Real Application Cluster (RAC) tidak didukung di Azure karena RAC akan memerlukan jaringan Multicast.
Konfigurasi penyimpanan
Ada dua pola penyebaran penyimpanan yang direkomendasikan untuk SAP di Oracle di Azure:
- Manajemen Penyimpanan Otomatis (ASM) Oracle
- Azure NetApp Files (ANF) dengan Oracle dNFS (NFS Langsung)
Pelanggan yang saat ini menjalankan database Oracle pada sistem file EXT4 atau XFS dengan Logical Volume Manager (LVM) didorong untuk pindah ke ASM. Ada keuntungan performa, administrasi, dan keandalan yang cukup besar untuk berjalan pada ASM dibandingkan dengan LVM. ASM mengurangi kompleksitas, meningkatkan dukungan, dan membuat tugas administrasi lebih sederhana. Dokumentasi ini berisi tautan untuk Oracle Database Administrators (DBA) untuk mempelajari cara menginstal dan mengelola ASM.
Azure menyediakan beberapa solusi penyimpanan. Tabel di bawah ini merinci status dukungan
| Jenis penyimpanan | Dukungan Oracle | Ukuran Sektor | Oracle Linux 8.x atau lebih tinggi | Server Windows 2019 |
|---|---|---|---|---|
| Jenis Penyimpanan Blok | ||||
| SSD Premium | Didukung | 512e | ASM Direkomendasikan. LVM Didukung | Tidak ada dukungan untuk ASM di Windows |
| SSD v2 Premium | Didukung | 4K Asli atau 512e1 | ASM Direkomendasikan. LVM Didukung | Tidak ada dukungan untuk ASM di Windows. Mengubah disk File Log dari 4K Native ke 512e |
| SSD Standar | Tidak didukung | |||
| HDD Standar | Tidak didukung | |||
| Ultra disk | Didukung | 4K Asli | ASM Direkomendasikan. LVM Didukung | Tidak ada dukungan untuk ASM di Windows. Mengubah disk File Log dari 4K Native ke 512e |
| Jenis Penyimpanan Jaringan | ||||
| Azure NetApp Service (ANF) | Didukung | - | Oracle dNFS Diperlukan | Tidak didukung |
| Azure Files NFS | Tidak didukung | |||
| Azure files SMB | Tidak didukung |
1 512e didukung pada SSD Premium v2 untuk sistem Windows. Konfigurasi 512e tidak direkomendasikan untuk pelanggan Linux. Migrasi ke 4K Native menggunakan prosedur dalam ukuran sektor MOS 512/512e ke 4K Native Review (DOC ID 1133713.1)
Pertimbangan lain yang menerapkan daftar seperti:
- Tidak ada dukungan untuk DIRECTIO dengan ukuran sektor Asli 4K. Pengaturan yang direkomendasikan untuk FILESYSTEMIO_OPTIONS untuk konfigurasi LVM:
- LVM - Jika disk dengan geometri 512/512e digunakan, FILESYSTEMIO_OPTIONS = SETALL
- LVM - Jika disk dengan geometri Asli 4K digunakan, FILESYSTEMIO_OPTIONS = ASYNC
- Oracle 19c dan yang lebih tinggi sepenuhnya mendukung ukuran sektor Asli 4K dengan ASM dan LVM
- Oracle 19c dan yang lebih tinggi di Linux - ketika berpindah dari penyimpanan 512e ke ukuran sektor Log penyimpanan asli 4K harus diubah
- Untuk bermigrasi dari ukuran sektor 512/512e ke 4K Native Review (DOC ID 1133713.1) – lihat bagian "Migrasi Offline ke Disk Sektor 4KB"
- SAPInst menulis ke pfile selama penginstalan. Jika $ORACLE_HOME/dbs berada di kumpulan disk 4K filesystemio_options=asinkron dan lihat Bagian "Dukungan Datafile Disk Sektor 4kB" di MOS Mendukung Disk Sektor 4K (ID Dokumen 1133713.1)
- Tidak ada dukungan untuk ASM pada platform Windows
- Tidak ada dukungan untuk ukuran sektor Asli 4K untuk volume Log pada platform Windows. SSDv2 dan Ultra Disk harus diubah menjadi 512e melalui ikon pensil "Edit Disk" di Portal Microsoft Azure
- Ukuran sektor Asli 4K hanya didukung pada Volume data untuk platform Windows. 4K tidak didukung untuk volume Log di Windows
- Sebaiknya tinjau artikel MOS ini:
- Oracle Linux: Cache Buffer Sistem File versus I/O Langsung (ID Dokumen 462072.1)
- Mendukung Disk Sektor 4K (ID Dokumen 1133713.1)
- Menggunakan Log Pengulangan 4k pada Flash, Penyimpanan berbasis Disk 4k, dan SSD (ID Dokumen 1681266.1)
- Hal-hal yang Perlu Dipertimbangkan untuk mengatur filesystemio_options dan disk_asynch_io (ID Dokumen 1987437.1)
Sebaiknya gunakan Oracle ASM di Linux dengan ASMLib. Performa, administrasi, dukungan, dan konfigurasi dioptimalkan dengan pola penyebaran. Oracle ASM dan Oracle dNFS akan mengatur parameter atau parameter bypass yang benar (seperti FILESYSTEMIO_OPTIONS) dan karenanya memberikan performa dan keandalan yang lebih baik.
Manajemen Penyimpanan Otomatis (ASM) Oracle
Daftar periksa untuk Manajemen Penyimpanan Otomatis Oracle:
- Semua SAP di Oracle pada sistem Azure menjalankan ASM termasuk Pengembangan, Jaminan Kualitas, dan Produksi. Database Kecil, Sedang, dan Besar
- ASMLib digunakan dan bukan UDEV. UDEV diperlukan untuk beberapa WAN, skenario yang tidak ada di Azure
- ASM harus dikonfigurasi untuk Redundansi Eksternal. Penyimpanan Azure Premium SSD menyediakan redundansi tiga kali lipat. SSD Premium Azure cocok dengan keandalan dan integritas solusi penyimpanan lainnya. Untuk keamanan opsional, pelanggan dapat mempertimbangkan Redundansi Normal untuk Grup Disk Log
- Mencerminkan file Log Fase Pengulangan bersifat opsional untuk 888626 ASM - Ulangi tata letak log untuk sistem kelas atas
- Grup Disk ASM dikonfigurasi sesuai Varian 1, 2, atau 3 di bawahnya
- Ukuran Unit Alokasi ASM = 4MB (default). Sistem OLAP Database Sangat Besar (VLDB) seperti BW dapat memperoleh manfaat dari ukuran Unit Alokasi ASM yang lebih besar. Ubah hanya setelah mengonfirmasi dengan dukungan Oracle
- Ukuran Sektor ASM dan Ukuran Sektor Logis = default (UDEV tidak disarankan tetapi memerlukan 4k)
- Jika KOMPATIBEL. Atribut grup disk ASM diatur ke 11.2 atau lebih besar untuk grup disk, Anda dapat membuat, menyalin, atau memindahkan Oracle ASM SPFILE ke dalam sistem file ACFS. Tinjau dokumentasi Oracle tentang memindahkan pfile ke ACFS. SAPInst tidak membuat pfile di ACFS secara default
- Varian ASM yang sesuai digunakan. Sistem produksi harus menggunakan Varian 2 atau 3
Grup Disk Manajemen Penyimpanan Otomatis Oracle
Bagian II dari Panduan Oracle resmi menjelaskan penginstalan dan manajemen ASM:
- Panduan Administrator Manajemen Penyimpanan Otomatis Oracle, 19c
- Panduan Pemasangan dan Peningkatan Infrastruktur Oracle Grid, 19c untuk Linux
Batas ASM berikut ada untuk Oracle Database 12c atau yang lebih baru:
511 grup disk, 10.000 disk ASM dalam Grup Disk, 65.530 disk ASM dalam sistem penyimpanan, 1 juta file untuk setiap Grup Disk. Info selengkapnya di sini: Pertimbangan Performa dan Skalabilitas untuk Grup Disk (oracle.com)
Tinjau dokumentasi ASM di Panduan Instalasi SAP yang relevan untuk Oracle yang tersedia dari https://help.sap.com/viewer/nwguidefinder
Varian 1 – volume data kecil hingga sedang hingga 3 TB, waktu pemulihan tidak kritis
Pelanggan memiliki database berukuran kecil atau menengah di mana pencadangan dan/atau pemulihan + Pemulihan semua database dapat dicapai menggunakan RMAN secara tepat waktu. Contoh: Ketika grup disk Oracle ASM lengkap, dengan file data, dari satu atau beberapa database rusak dan semua file data dari semua database perlu dipulihkan ke grup disk Oracle ASM yang baru dibuat menggunakan RMAN.
Rekomendasi grup disk Oracle ASM:
| Nama Grup Disk ASM | Menyimpan | Azure Storage |
|---|---|---|
| +DATA | Semua file data | 3-6 x P 30 (1 TiB) |
| File kontrol (salinan pertama) | Untuk meningkatkan ukuran database, tambahkan disk P30 tambahan | |
| Log pengulangan online (salinan pertama) | ||
| +ARCH | File kontrol (salinan kedua) | 2 x P20 (512 GiB) |
| Log fase pengulangan yang diarsipkan | ||
| +RECO | File kontrol (salinan ketiga) | 2 x P20 (512 GiB) |
| Pencadangan RMAN (opsional) | ||
| area pemulihan (opsional) |
Varian 2 – volume data menengah hingga besar antara 3 TB dan 12 TB, waktu pemulihan penting
Pelanggan memiliki database berukuran sedang hingga besar di mana pencadangan dan/atau pemulihan +
pemulihan semua database tidak dapat dicapai secara tepat waktu.
Biasanya pelanggan menggunakan teknik RMAN, Azure Backup untuk Oracle dan/atau snap disk dalam kombinasi.
Perbedaan utama untuk Varian 1 adalah:
- Pisahkan Grup Disk Oracle ASM untuk setiap database
- <DBNAME>+“_” digunakan sebagai awalan untuk nama grup disk DATA
- Jumlah grup disk DATA ditambahkan jika database mencakup lebih dari satu grup disk DATA
- Tidak ada log pengulangan online yang terletak di grup disk "data". Sebagai gantinya, grup disk tambahan digunakan untuk anggota pertama dari setiap grup logpengulangan online.
| Nama Grup Disk ASM | Menyimpan | Azure Storage |
|---|---|---|
| +<DBNAME>_DATA[#] | Semua file data | 3-12 x P 30 (1 TiB) |
| Semua file sementara | Untuk meningkatkan ukuran database, tambahkan disk P30 tambahan | |
| File kontrol (salinan pertama) | ||
| +OLOG | Log pengulangan online (salinan pertama) | 3 x P20 (512 GiB) |
| +ARCH | File kontrol (salinan kedua) | 3 x P20 (512 GB) |
| Log fase pengulangan yang diarsipkan | ||
| +RECO | File kontrol (salinan ketiga) | 3 x P20 (512 GiB) |
| Pencadangan RMAN (opsional) | ||
| Area pemulihan cepat (opsional) |
Varian 3 – data besar dan volume perubahan data lebih dari 5 TB, waktu pemulihan sangat penting
Pelanggan memiliki database besar di mana pencadangan dan/atau pemulihan + pemulihan database tunggal tidak dapat dicapai secara tepat waktu.
Biasanya pelanggan menggunakan teknik RMAN, Azure Backup untuk Oracle dan/atau snap disk dalam kombinasi. Dalam varian ini, setiap jenis file database yang relevan dipisahkan ke grup disk Oracle ASM yang berbeda.
| Nama Grup Disk ASM | Menyimpan | Azure Storage |
|---|---|---|
| +<DBNAME>_DATA[#] | Semua file data | 5-30 atau lebih x P30 (1 TiB) atau P40 (2 TiB) |
| Semua file sementara Untuk meningkatkan ukuran database, tambahkan disk P30 tambahan | ||
| File kontrol (salinan pertama) | ||
| +OLOG | Log pengulangan online (salinan pertama) | 3-8 x P20 (512 GiB) atau P30 (1 TiB) |
| Untuk keamanan lebih lanjut "Redundansi Normal" dapat dipilih untuk Grup Disk ASM ini | ||
| +ARCH | File kontrol (salinan kedua) | 3-8 x P20 (512 GiB) atau P30 (1 TiB) |
| Log fase pengulangan yang diarsipkan | ||
| +RECO | File kontrol (salinan ketiga) | 3 x P30 (1 TiB), P40 (2 TiB) atau P50 (4 TiB) |
| Pencadangan RMAN (opsional) | ||
| Area pemulihan cepat (opsional) |
Catatan
Cache Disk Azure Host untuk Grup Disk ASM DATA dapat diatur ke Baca Saja atau Tidak Ada. Semua Grup Disk ASM lainnya harus diatur ke Tidak Ada. Pada BW atau SCM, Grup Disk ASM terpisah untuk TEMP dapat dipertimbangkan untuk sistem besar atau sibuk.
Menambahkan Ruang ke ASM + Disk Azure
Grup Disk Oracle ASM dapat diperluas dengan menambahkan disk tambahan atau dengan memperluas disk saat ini. Sebaiknya tambahkan disk tambahan daripada memperluas disk yang ada. Tinjau artikel MOS dan tautan Catatan MOS 1684112.1 dan 2176737.1 ini
ASM menambahkan disk ke grup disk: asmca -silent -addDisk -diskGroupName DATA -disk '/dev/sdd1'
ASM secara otomatis menyeimbangkan ulang data. Untuk memeriksa penyeimbangan ulang, jalankan perintah ini.
ps -ef | grep rbal
oraasm 4288 1 0 Jul28 ? 00:04:36 asm_rbal_oradb1
Dokumentasi tersedia dengan:
- Cara Mengubah Ukuran Grup Disk ASM Antara Beberapa Zona (aemcorp.com)
- MENGUBAH UKURAN - Mengubah Grup Disk (oracle.com)
Memantau SAP pada Sistem Oracle ASM di Azure
Jalankan laporan Oracle AWR sebagai langkah pertama saat memecahkan masalah performa. Metrik performa disk dirinci dalam laporan AWR.
Performa disk dapat dipantau dari dalam Oracle Enterprise Manager dan melalui alat eksternal. Dokumentasi, yang mungkin membantu tersedia di sini:
- Menggunakan Tampilan untuk Menampilkan Informasi Oracle ASM
- Perintah Manajemen Grup Disk ASMCMD (oracle.com)
Alat pemantauan tingkat OS tidak dapat memantau disk ASM karena tidak ada sistem file yang dapat dikenali. Pemantauan ruang bebas harus dilakukan dari dalam Oracle.
Sumber Daya Pelatihan tentang Manajemen Penyimpanan Otomatis (ASM) Oracle
Oracle DBA yang tidak terbiasa dengan Oracle ASM mengikuti materi pelatihan dan sumber daya di sini:
- SAP di Oracle dengan ASM di Microsoft Azure - Part1 - Komunitas Teknologi Microsoft
- Penginstalan Oracle19c DB [ ASM ] di [ Oracle Linux 8.3 ] [ Grid | ASM | UDEV | OEL 8.3 ] [ VMware ] - YouTube
- Panduan Administrator ASM (oracle.com)
- Oracle untuk Pembaruan Pengembangan SAP (Mei 2022)
- Pertimbangan Performa dan Skalabilitas untuk Grup Disk (oracle.com)
- Migrasi ke Oracle ASM dengan Oracle Enterprise Manager
- Menggunakan RMAN untuk bermigrasi ke ASM | Mentor Oracle (wordpress.com)
- Apa itu Oracle ASM ke Azure IaaS? - Obrolan Sederhana (red-gate.com)
- Utilitas Baris Perintah ASM (ASMCMD) (oracle.com)
- Perintah asmcmd yang berguna - DBACLASS DBACLASS
- Menginstal dan Mengonfigurasi Perangkat Lunak Oracle ASMLIB
Azure NetApp Files (ANF) dengan Oracle dNFS (NFS Langsung)
Kombinasi Azure VM dan ANF adalah kombinasi yang kuat dan terbukti yang diterapkan oleh banyak pelanggan dalam skala yang sangat besar.
Database 100+ TB sudah berjalan produktif pada kombinasi ini. Untuk memulai, kami menulis blog terperinci tentang cara menyiapkan kombinasi ini:
Informasi umum lainnya
- Arsitektur solusi menggunakan Azure NetApp Files | Oracle
- Arsitektur solusi menggunakan Azure NetApp Files | SAP pada anyDB
Log Cermin diperlukan pada sistem Produksi ANF dNFS.
Meskipun ANF sangat berlebihan, Oracle masih memerlukan volume redo-logfile yang dicerminkan. Rekomendasinya adalah membuat dua volume terpisah dan mengonfigurasi origlogA bersama dengan mirrlogB dan origlogB bersama dengan mirrlogA. Dalam hal ini, Anda menggunakan penyeimbangan beban terdistribusi dari redo-logfiles.
Opsi pemasangan "nconnect" tidak disarankan saat klien dNFS dikonfigurasi. dNFS mengelola saluran IO dan menggunakan beberapa sesi, sehingga opsi ini usang dan dapat menyebabkan masalah manifold. Klien dNFS akan mengabaikan opsi pemasangan dan akan menangani IO secara langsung.
Versi NFS (v3 dan v4.1) dengan ANF didukung untuk biner, data, dan file log Oracle.
Sebaiknya gunakan klien Oracle dNFS untuk semua volume Oracle.
Opsi pemasangan yang direkomendasikan adalah:
| Versi NFS | Opsi pemasangan |
|---|---|
| NFSv3 | rw,vers=3,rsize=262144,wsize=262144,hard,timeo=600,noatime |
| NFSv4.1 | rw,vers=4.1,rsize=262144,wsize=262144,hard,timeo=600,noatime |
Pencadangan ANF
Dengan ANF, beberapa fitur utama tersedia seperti pencadangan berbasis snapshot yang konsisten, latensi rendah, dan performa yang sangat tinggi. Dari versi 6 alat AzAcSnap alat Azure Application Consistent Snapshot untuk ANF, database Oracle dapat dikonfigurasi untuk rekam jepret database yang konsisten.
Snapshot tersebut tetap berada di volume data aktual dan harus disalin menggunakan ANF CRR (Replikasi Lintas Wilayah) Replikasi lintas-wilayah ANF atau alat pencadangan lainnya.
SAP di Oracle di Azure dengan LVM
ASM adalah rekomendasi default dari Oracle untuk semua sistem SAP dengan ukuran apa pun di Azure. Performa, keandalan, dan dukungan lebih baik untuk pelanggan yang menggunakan ASM. Oracle menyediakan dokumentasi dan pelatihan bagi DBA untuk transisi ke ASM. Dalam kasus di mana tim Oracle DBA tidak mengikuti rekomendasi dari Oracle, Microsoft, dan SAP untuk menggunakan ASM, konfigurasi LVM berikut harus digunakan.
Perhatikan bahwa: saat membuat LVM, opsi "-i" harus digunakan untuk mendistribusikan data secara merata di seluruh jumlah disk dalam grup LVM.
Log Cermin diperlukan saat menjalankan LVM.
Konfigurasi minimum:
| Komponen | Hard | Cache Host | Striping1 |
|---|---|---|---|
| /oracle/<SID>/origlogaA & mirrlogB | Premium | Tidak | Tidak diperlukan |
| /oracle/<SID>/origlogaB & mirrlogA | Premium | Tidak | Tidak diperlukan |
| /oracle/<SID>/sapdata1...n | Premium | Baca-saja2 | Disarankan |
| /oracle/<SID>/oraarch3 | Premium | Tidak | Tidak diperlukan |
| Oracle Home, saptrace, ... | Premium | Tidak | Tidak |
- Striping: Stripe LVM menggunakan RAID0
- Selama migrasi R3Load, opsi Cache Host untuk SAPDATA harus diatur ke Tidak Ada
- oraarch: LVM bersifat opsional
Pilihan disk untuk menghosting log pengulangan online Oracle didorong oleh persyaratan IOPS. Semua sapdata1...n (ruang tabel) dapat disimpan pada satu disk yang terpasang selama volume, IOPS, dan throughput memenuhi persyaratan.
Konfigurasi performa Linux:
| Komponen | Hard | Cache Host | Striping1 |
|---|---|---|---|
| /oracle/<SID>/origlogaA | Premium | Tidak | Dapat digunakan |
| /oracle/<SID>/origlogaB | Premium | Tidak | Dapat digunakan |
| /oracle/<SID>/mirrlogAB | Premium | Tidak | Dapat digunakan |
| /oracle/<SID>/mirrlogBA | Premium | Tidak | Dapat digunakan |
| /oracle/<SID>/sapdata1...n | Premium | Baca-saja2 | Disarankan |
| /oracle/<SID>/oraarch3 | Premium | Tidak | Tidak diperlukan |
| Oracle Home, saptrace, ... | Premium | Tidak | Tidak |
- Striping: Stripe LVM menggunakan RAID0
- Selama migrasi R3load, opsi Cache Host untuk SAPDATA harus diatur ke Tidak Ada
- oraarch: LVM bersifat opsional
Azure Infra: Batas Throughput komputer virtual & Opsi Azure Disk Storage
Manajemen Penyimpanan Otomatis (ASM) Oracle## dapat mengevaluasi teknologi penyimpanan ini:
- Penyimpanan Premium Azure – saat ini menjadi pilihan default
- Peledakan Disk Terkelola - Penyimpanan disk terkelola - Mesin Virtual Azure | Microsoft Docs
- Akselerator Tulis Azure
- Ekstensi disk online untuk penyimpanan SSD Azure Premium masih berlangsung
Waktu penulisan log dapat ditingkatkan pada VM Azure Seri-M dengan mengaktifkan Akselerator Tulis. Aktifkan Akselerator Tulis Azure untuk disk Penyimpanan Premium Azure yang digunakan oleh Grup Disk ASM untuk file log fase pengulangan online. Untuk informasi selengkapnya, lihat Akselerator Tulis.
Menggunakan Akselerator Tulis bersifat opsional tetapi dapat diaktifkan jika laporan AWR menunjukkan waktu penulisan log yang lebih tinggi dari yang diharapkan.
Batas Throughput Azure Virtual Machine
Setiap jenis komputer Virtual (VM) Azure memiliki batasan untuk CPU, Disk, Jaringan, dan RAM. Batas ini didokumenkan dalam tautan di bawah ini
Rekomendasi berikut harus diikuti saat memilih jenis VM:
- Pastikan Throughput Disk dan IOPS cukup untuk beban kerja dan setidaknya sama dengan throughput agregat disk
- Pertimbangkan untuk mengaktifkan bursting berbayar terutama untuk disk Log Fase pengulangan
- Untuk ANF, throughput Jaringan penting karena semua lalu lintas penyimpanan dihitung sebagai "Jaringan" daripada throughput Disk
- Tinjau blog ini untuk Penyetelan jaringan untuk Seri M Mengoptimalkan Throughput Jaringan pada HCMT VM seri-M Azure (microsoft.com)
- Tinjau tautan ini yang menjelaskan cara menggunakan laporan AWR untuk memilih Azure VM yang benar
- Azure Intel Ev5 Seri Edv5 dan Edsv5 - Azure Virtual Machines |Microsoft Docs
- Azure AMD Eadsv5 Seri Easv5 and Eadsv5 - Azure Virtual Machines |Microsoft Docs
- Seri M Azure seri M/seri Msv2 - Seri M Azure Virtual Machines |Microsoft Docs dan Seri Memori Medium Msv2/Mdsv2 - Mesin Virtual Azure | Microsoft Docs
- Azure Mv2 Seri Mv2 - Azure Virtual Machines | Microsoft Docs
Pencadangan/pemulihan
Untuk fungsionalitas pencadangan/pemulihan, SAP BR*Tools untuk Oracle didukung dengan cara yang sama seperti pada bare metal dan Hyper-V. Oracle Recovery Manager (RMAN) juga didukung untuk pencadangan ke disk dan pemulihan dari disk.
Untuk informasi selengkapnya tentang cara menggunakan layanan Azure Backup dan Pemulihan untuk database Oracle, lihat:
- Cadangkan dan pulihkan database Oracle Database 12c di mesin virtual Azure Linux
- Layanan Azure Backup juga mendukung pencadangan Oracle seperti yang dijelaskan dalam artikel Mencadangkan dan memulihkan database Oracle Database 19c pada VM Azure Linux menggunakan Azure Backup.
Ketersediaan tinggi
Oracle Data Guard didukung untuk tujuan ketersediaan tinggi dan pemulihan bencana. Untuk mencapai failover otomatis di Data Guard, Anda perlu menggunakan Fast-Start Failover (FSFA). Fungsionalitas Observer (FSFA) memicu kegagalan. Jika tidak menggunakan FSFA, Anda hanya dapat menggunakan konfigurasi failover manual. Untuk informasi selengkapnya, lihat Menerapkan Oracle Data Guard pada mesin virtual Azure Linux.
Aspek Pemulihan Bencana untuk database Oracle di Azure disajikan dalam artikel Pemulihan bencana untuk database Oracle Database 12c di lingkungan Azure.
Laporan resmi Oracle lainnya yang bermanfaat Menyiapkan Oracle 12c Data Guard untuk Pelanggan SAP
Halaman Besar & Konfigurasi SGA Oracle Besar
VLDB SAP di Oracle pada penyebaran Azure menerapkan ukuran SGA lebih dari 3 TB. Versi modern Oracle menangani ukuran SGA besar dengan baik dan secara signifikan mengurangi IO. Tinjau laporan AWR dan tingkatkan ukuran SGA untuk mengurangi IO baca.
Sebagai panduan umum Halaman Besar Linux harus dikonfigurasi hingga sekitar 75% dari ukuran RAM VM. Ukuran SGA dapat diatur ke 90% dari ukuran Halaman Besar. Contoh perkiraan adalah VM M192ms dengan RAM 4 TB akan memiliki Halaman Besar yang ditetapkan secara proksimatis 3 TB. SGA dapat diatur ke nilai yang sedikit lebih sedikit seperti 2,95 TB.
Pelanggan SAP besar yang berjalan di VM Azure Memori Tinggi sangat mendapat manfaat dari HugePages seperti yang dijelaskan dalam artikel ini
Sistem NUMA vm.min_free_kbytes harus diatur ke 524288 * <# dari node NUMA>. Lihat Oracle Linux : Nilai yang Disarankan dari Parameter Pengaturan Kernel vm.min_free_kbytes (ID Dokumen 2501269.1...
Tautan & Utilitas Oracle Linux lainnya
Oracle Linux menyediakan utilitas manajemen GUI yang berguna:
- Oracle konsol web Oracle Linux: Menginstal Konsol Web Cockpit di Oracle Linux
- Upstram Proyek Cockpit — Proyek Cockpit (cockpit-project.org)
Oracle Linux memiliki alat manajemen paket baru - DNF
Oracle Linux 8: Manajemen Paket menjadi mudah dengan video gratis | Blog Oracle Linux
Oracle® Linux 8 Mengelola Perangkat Lunak di Oracle Linux - Bab 1 Yum DNF
Konfigurasi Memori dan NUMA dapat diuji dan ditolok ukur dengan alat yang berguna - Pengujian Aplikasi Nyata (RAT) Oracle
Pengujian Aplikasi Nyata Oracle: Apa itu dan bagaimana Anda menggunakannya? (aemcorp.com)
Informasi tentang masalah Korupsi Log UDEV Kerusakan Redolog Oracle di Azure | Oracle di bidang (wordpress.com)
Oracle ASM dalam korupsi Azure - tindak lanjut (dbaharrison.blogspot.com)
Korupsi data pada Hyper-V atau Azure saat menjalankan Oracle ASM - Portal Pelanggan Red Hat
Menyiapkan Oracle ASM di mesin virtual Azure Linux - Azure Virtual Machines | Microsoft Docs
Panduan Konfigurasi Oracle untuk penginstalan SAP di Azure VM di Windows
SAP di Oracle di Azure juga mendukung Windows. Rekomendasi untuk penyebaran Windows dirangkum di bawah ini:
- Rilis Windows berikut direkomendasikan: Windows Server 2022 (hanya dari Oracle Database 19.13.0 aktif) Windows Server 2019 (hanya dari Oracle Database 19.5.0 aktif)
- Tidak ada dukungan untuk ASM di Windows. Ruang Penyimpanan Windows harus digunakan untuk mengagregasi disk untuk performa optimal
- Instal Oracle Home pada disk independen khusus (jangan instal Oracle Home di C: Drive)
- Semua disk harus diformat NTFS
- Ikuti panduan Penyetelan Windows dari Oracle dan aktifkan halaman besar, kunci halaman dalam memori, dan pengaturan spesifik Windows lainnya
Pada saat itu, menulis ASM untuk pelanggan Windows di Azure tidak didukung. SAP Software Provisioning Manager (SWPM) untuk Windows saat ini tidak mendukung ASM.
Konfigurasi Penyimpanan untuk SAP di Oracle di Windows
Konfigurasi minimum Windows:
| Komponen | Hard | Cache Host | Striping1 |
|---|---|---|---|
| E:\oracle\<SID>\origlogaA & mirrlogB | Premium | Tidak | Tidak diperlukan |
| F:\oracle\<SID>\origlogaB & mirrlogA | Premium | Tidak | Tidak diperlukan |
| G:\oracle\<SID>\sapdata1...n | Premium | Baca-saja2 | Disarankan |
| H:\oracle\<SID>\oraarch3 | Premium | Tidak | Tidak diperlukan |
| I:\Oracle Home, saptrace, ... | Premium | Tidak | Tidak |
- Striping: Ruang Penyimpanan Windows
- Selama migrasi R3load, opsi Cache Host untuk SAPDATA harus diatur ke Tidak Ada
- oraarch: Ruang Penyimpanan Windows bersifat opsional
Pilihan disk untuk menghosting log pengulangan online Oracle didorong oleh persyaratan IOPS. Semua sapdata1...n (ruang tabel) dapat disimpan pada satu disk yang terpasang selama volume, IOPS, dan throughput memenuhi persyaratan.
Konfigurasi performa Windows:
| Komponen | Hard | Cache Host | Striping1 |
|---|---|---|---|
| E:\oracle\<SID>\origlogaA | Premium | Tidak | Dapat digunakan |
| F:\oracle\<SID>\origlogaB | Premium | Tidak | Dapat digunakan |
| G:\oracle\<SID>\mirrlogAB | Premium | Tidak | Dapat digunakan |
| H:\oracle\<SID>\mirrlogBA | Premium | Tidak | Dapat digunakan |
| I:\oracle\<SID>\sapdata1...n | Premium | Baca-saja2 | Disarankan |
| J:\oracle\<SID>\oraarch3 | Premium | Tidak | Tidak diperlukan |
| K:\Oracle Home, saptrace, ... | Premium | Tidak | Tidak |
- Striping: Ruang Penyimpanan Windows
- Selama migrasi R3load, opsi Cache Host untuk SAPDATA harus diatur ke Tidak Ada
- oraarch: Ruang Penyimpanan Windows bersifat opsional
Tautan untuk Oracle di Windows
- Gambaran Umum Penyetelan Windows (oracle.com)
- Tugas Konfigurasi Pascapemasangan di Windows (oracle.com)
- SAP di Windows Presentation (oracle.com)2823030 - Oracle di MS WINDOWS Halaman Besar
Langkah berikutnya
Baca artikel