Distribuzione del database Oracle di Azure Macchine virtuali per il carico di lavoro SAP

Il presente documento illustra le numerose aree da valutare quando si distribuisce Oracle Database per un carico di lavoro SAP in IaaS di Azure. Prima di leggere questo documento, è consigliabile leggere Considerazioni sulla distribuzione DBMS di macchine virtuali di Azure per un carico di lavoro SAP. È anche consigliabile leggere altre guide nella documentazione di Azure per il carico di lavoro SAP.

È possibile trovare informazioni sulle versioni di Oracle e le versioni corrispondenti dei sistemi operativi supportati per l'esecuzione di SAP in Oracle su Azure nella nota SAP 2039619.

Informazioni generali sull'esecuzione di SAP Business Suite in Oracle sono disponibili in SAP on Oracle (SAP in Oracle). Oracle supporta l'esecuzione di database Oracle in Microsoft Azure. Per altre informazioni sul supporto generale per Windows Hyper-V e Azure, vedere Oracle and Microsoft Azure FAQ (Domande frequenti su Oracle e Microsoft Azure).

Per un'installazione Oracle sono rilevanti le note SAP seguenti

Numero della nota Titolo nota
1738053 SAPinst for Oracle ASM installation SAP ONE Support Launchpad
2896926 ASM disk group compatibility NetWeaver SAP ONE Support Launchpad
1550133 Using Oracle Automatic Storage Management (ASM) with SAP NetWeaver based Products SAP ONE Support Launchpad]
888626 Redo log layout for high-end systems SAP ONE Support Launchpad
105047 Support for Oracle functions in the SAP environment SAP ONE Support Launchpad
2799920 Patches for 19c: Database SAP ONE Support Launchpad
974876 Oracle Transparent Data Encryption (TDE) SAP ONE Support Launchpad
2936683 Oracle Linux 8: SAP Installation and Upgrade SAP ONE Support Launchpad
1672954 Oracle 11g, 12c, 18c and 19c: Usage of hugepages on Linux
1171650 Automated Oracle DB parameter check
2936683 Oracle Linux 8: SAP Installation and Upgrade

Specifiche per Oracle Database in Oracle Linux

Oracle supporta l'esecuzione delle istanze di database in Microsoft Azure con Oracle Linux come sistema operativo guest. Per altre informazioni sul supporto generale per Windows Hyper-V e Azure, vedere Azure and Oracle FAQ (Domande frequenti su Azure e Oracle).

È supportato anche lo scenario specifico delle applicazioni SAP che usano i database Oracle. I dettagli sono descritti nella parte successiva del documento.

Raccomandazioni generali per l'esecuzione di SAP in Oracle in Azure

Installare o eseguire la migrazione di SAP esistenti nei sistemi Oracle in Azure, è necessario seguire il modello di distribuzione seguente:

  1. Usare la versione più recente di Oracle Linux disponibile (Oracle Linux 8.6 o versione successiva).
  2. Usare la versione più recente di Oracle Database disponibile con la versione più recente di SAP Bundle Patch (SBP) (Oracle 19 Patch 15 o versione successiva) 2799920 - Patch per 19c: Database.
  3. Usare Gestione automatica Archiviazione (ASM) per database di piccole, medie e grandi dimensioni nell'archiviazione a blocchi.
  4. È consigliabile usare l'unità SSD di Archiviazione Premium di Azure. Non usare standard o altri tipi di archiviazione.
  5. ASM rimuove la necessità di log di mirror. Seguire le indicazioni fornite da Oracle in Note 888626 - Redo log layout for high-end systems (Nota 888626 - Rollforward log layout for high-end systems).
  6. Usare ASMLib e non usare udev.
  7. Le distribuzioni di Azure NetApp Files devono usare Oracle dNFS (soluzione Direct NFS a prestazioni elevate di Oracle).
  8. I database Oracle di grandi dimensioni traggono grande vantaggio dalle dimensioni SGA (System Global Area). I clienti di grandi dimensioni devono eseguire la distribuzione in serie M di Azure con dimensioni pari o superiori a 4 TB di RAM
    • Impostare le hugepage di Linux sul 75% delle dimensioni della RAM fisica
    • Impostare L'area globale del sistema (SGA) sul 90% delle dimensioni di pagina enormi
    • Impostare il parametro Oracle U edizione Standard_LARGE_PAGES = ONLY - Il valore ONLY è preferibile rispetto al valore TRUE perché il valore ONLY dovrebbe offrire prestazioni più coerenti e prevedibili. Il valore TRUE può allocare sia pagine 2 MB di grandi dimensioni che pagine standard 4K. Il valore ONLY forza sempre pagine di 2 MB di grandi dimensioni. Se il numero di pagine di grandi dimensioni disponibili non è sufficiente o non è configurato correttamente, l'istanza del database non inizierà con codice errore: ora-27102 : memoria insufficiente Linux_x86_64 Errore 12 : non può allocare memoria. Se la memoria contigua non è sufficiente, potrebbe essere necessario riavviare Oracle Linux e/o riconfigurare i parametri Della pagina enorme del sistema operativo.
  9. Oracle Home deve trovarsi all'esterno del volume o del disco "radice". Usare un disco o un volume ANF separato. Il disco che contiene Oracle Home deve avere dimensioni pari o superiori a 64 gigabyte.
  10. Le dimensioni del disco di avvio per server di database Oracle con prestazioni elevate sono importanti. Come minimo, è consigliabile usare un disco P10 per serie M o serie E. Non usare dischi di piccole dimensioni, ad esempio P4 o P6. Potrebbero causare problemi di prestazioni.
  11. La rete accelerata deve essere abilitata in tutte le Macchine virtuali. Eseguire l'aggiornamento alla versione più recente di Oracle Linux in caso di problemi durante l'abilitazione della rete accelerata.
  12. Verificare la disponibilità di aggiornamenti in questa documentazione e la nota SAP 2039619 - Applicazioni SAP in Microsoft Azure tramite Oracle Database: Prodotti e versioni supportati - Launchpad supporto SAP ONE.

Per informazioni sulle versioni di Oracle e le corrispondenti versioni del sistema operativo supportate per l'esecuzione di SAP in Oracle nelle macchine virtuali di Azure, vedere la nota SAP 2039619.

Informazioni generali sull'esecuzione di SAP Business Suite in Oracle sono disponibili nella pagina della community SAP on Oracle. SAP in Oracle in Azure è supportato solo in Oracle Linux (e non Suse o Red Hat) per server applicazioni e database. I server ASCS/ERS possono usare RHEL/SU edizione Standard perché il client Oracle non è installato o usato in queste macchine virtuali. I server applicazioni (PAS/AAS) non devono essere installati in queste macchine virtuali. Fare riferimento alla nota SAP 3074643 - OLNX: domande frequenti: se Pacemaker per Oracle Linux è supportato nell'ambiente SAP. Oracle Real Application Cluster (RAC) non è supportato in Azure perché RAC richiederebbe la rete multicast.

Configurazione dell'archiviazione

Esistono due criteri di distribuzione di archiviazione consigliati per SAP in Oracle in Azure:

  1. Oracle Automatic Storage Management (ASM)
  2. Azure NetApp Files (ANF) con Oracle dNFS (Direct NFS)

I clienti che eseguono database Oracle in file system EXT4 o XFS con Gestione volumi logici (LVM) sono invitati a passare ad ASM. Ci sono notevoli vantaggi di prestazioni, amministrazione e affidabilità per l'esecuzione in ASM rispetto a LVM. ASM riduce la complessità, migliora il supporto e semplifica le attività di amministrazione. Questa documentazione contiene collegamenti per Oracle Database Amministrazione istrators (DBAs) per informazioni su come installare e gestire ASM.

Azure offre più soluzioni di archiviazione. La tabella seguente illustra in dettaglio lo stato del supporto

Tipo di archiviazione Supporto oracle Dimensioni settore Oracle Linux 8.x o versione successiva Windows Server 2019
Tipo di blocco Archiviazione
SSD Premium Supportata 512e ASM consigliato. LVM supportata Nessun supporto per ASM in Windows
SSD Premium v2 Supportata 4K Nativo o 512e1 ASM consigliato. LVM supportata Nessun supporto per ASM in Windows. Modificare i dischi dei file di log da 4K native a 512e
SSD Standard Non supportato
Unità disco rigido Standard Non supportato
Disco Ultra Supportata Nativo 4K ASM consigliato. LVM supportata Nessun supporto per ASM in Windows. Modificare i dischi dei file di log da 4K native a 512e
Tipi di Archiviazione di rete
Azure Net servizio app (ANF) Supportata - Oracle dNFS obbligatorio Non supportato
File di Azure NFS Non supportato
File di Azure SMB Non supportato

1 512e è supportato in SSD Premium v2 per i sistemi Windows. Le configurazioni 512e non sono consigliate per i clienti Linux. Eseguire la migrazione a 4K Native usando la procedura nelle dimensioni del settore MOS 512/512e alla revisione nativa 4K (ID documento 1133713.1)

Altre considerazioni che si applicano all'elenco, ad esempio:

  1. Nessun supporto per DIRECTIO con dimensioni del settore nativo 4K. Impostazioni consigliate per FILESYSTEMIO_OPTIONS per le configurazioni LVM:
    • LVM: se vengono usati dischi con geometria 512/512e, FILESYSTEMIO_OPTIONS = edizione Standard TALL
    • LVM: se vengono usati dischi con geometria nativa 4K, FILESYSTEMIO_OPTIONS = ASYNC
  2. Oracle 19c e versioni successive supportano completamente le dimensioni del settore nativo 4K con ASM e LVM
  3. Oracle 19c e versioni successive in Linux: quando si passa da 512e storage a 4K Native storage Log sizes must be changed
  4. Per eseguire la migrazione dalle dimensioni del settore 512/512e alla revisione nativa 4K (ID documento 1133713.1), vedere la sezione "Migrazione offline a dischi di settore da 4 KB"
  5. SAPInst scrive nel file pfile durante l'installazione. Se il $ORACLE_HOME/dbs si trova in un set di dischi 4K filesystemio_options=asincrona e vedere la sezione "Supporto dei file di dati dei dischi di settore 4KB" in Mos che supporta dischi di settore 4K (ID documento 1133713.1)
  6. Nessun supporto per ASM nelle piattaforme Windows
  7. Nessun supporto per le dimensioni del settore nativo 4K per il volume di log nelle piattaforme Windows. SSDv2 e Ultra Disk devono essere modificati in 512e tramite l'icona a forma di matita "Modifica disco" nel portale di Azure
  8. Le dimensioni del settore nativo 4K sono supportate solo nei volumi di dati per le piattaforme Windows. 4K non è supportato per i volumi di log in Windows
  9. È consigliabile esaminare questi articoli relativi al Mos:
    • Oracle Linux: Cache buffer del file system e I/O diretto (ID documento 462072.1)
    • Supporto di dischi di settore 4K (ID documento 1133713.1)
    • Uso dei log di rollforward 4k su Flash, su disco 4k e su Archiviazione unità SSD (ID documento 1681266.1)
    • Aspetti da considerare per l'impostazione di filesystemio_options e disk_asynch_io (ID documento 1987437.1)

È consigliabile usare Oracle ASM in Linux con ASMLib. Le prestazioni, l'amministrazione, il supporto e la configurazione sono ottimizzate con il modello di distribuzione. Oracle ASM e Oracle dNFS impostano i parametri corretti o ignorano i parametri (ad esempio FILESYSTEMIO_OPTIONS) e quindi offrono prestazioni e affidabilità migliori.

Oracle Automatic Storage Management (ASM)

Elenco di controllo per Oracle Automatic Storage Management:

  1. Tutti i sistemi SAP in Oracle in Azure eseguono ASM , tra cui Sviluppo, Controllo qualità e Produzione. Database di piccole, medie e grandi dimensioni
  2. Viene usato ASMLib e non UDEV. UDEV è necessario per più SAN, uno scenario che non esiste in Azure
  3. ASM deve essere configurato per la ridondanza esterna. L'archiviazione SSD Premium di Azure offre una ridondanza triplica. SSD Premium di Azure offre la stessa affidabilità e la stessa integrità di qualsiasi altra soluzione di archiviazione. Per la sicurezza facoltativa, i clienti possono prendere in considerazione la ridondanza normale per il gruppo di dischi di log
  4. Il mirroring dei file di log di rollforward è facoltativo per 888626 ASM - Layout del log di rollforward per sistemi di fascia alta
  5. Gruppi di dischi ASM configurati in base alle varianti 1, 2 o 3 di seguito
  6. Dimensioni unità di allocazione ASM = 4 MB (impostazione predefinita). I sistemi OLAP (VLDB) molto grandi, ad esempio BW, possono trarre vantaggio dalle dimensioni maggiori dell'unità di allocazione ASM. Modificare solo dopo la verifica con il supporto Oracle
  7. Dimensioni settore ASM e Dimensioni settore logico = impostazione predefinita (UDEV non è consigliato ma richiede 4k)
  8. Se compatibile. L'attributo del gruppo di dischi ASM è impostato su 11.2 o versione successiva per un gruppo di dischi, è possibile creare, copiare o spostare un SPFILE Di Oracle ASM nel file system ACFS. Esaminare la documentazione di Oracle sullo spostamento di pfile in ACFS. SAPInst non crea il pfile in ACFS per impostazione predefinita
  9. Viene usata la variante ASM appropriata. I sistemi di produzione devono usare la variante 2 o 3

Gruppi di dischi Oracle Automatic Storage Management

La parte II della guida ufficiale di Oracle descrive l'installazione e la gestione di ASM:

Per Oracle Database 12c o versione successiva esistono i limiti ASM seguenti:

511 gruppi di dischi, 10.000 dischi ASM in un gruppo di dischi, 65.530 dischi ASM in un sistema di archiviazione, 1 milione di file per ogni gruppo di dischi. Altre informazioni sono disponibili qui: Performance and Scalability Considerations for Disk Groups (oracle.com)

Esaminare la documentazione di ASM nella guida all'installazione SAP pertinente per Oracle disponibile su https://help.sap.com/viewer/nwguidefinder

Variante 1: volumi di dati da piccole a medie dimensioni fino a 3 TB, tempo di ripristino non critico

Il cliente dispone di database di piccole o medie dimensioni in cui è possibile eseguire il backup e/o il ripristino + Ripristino di tutti i database usando RMAN in modo tempestivo. Esempio: quando un gruppo di dischi Oracle ASM completo, con file di dati, di uno o più database viene interrotto e tutti i file di dati di tutti i database devono essere ripristinati in un gruppo di dischi Oracle ASM appena creato usando RMAN.

Raccomandazione per il gruppo di dischi Oracle ASM:

Nome del gruppo di dischi ASM Stores Archiviazione di Azure
+DATA Tutti i file di dati 3-6 x P 30 (1 TiB)
File di controllo (prima copia) Per aumentare le dimensioni del database, aggiungere dischi P30 aggiuntivi
Log di rollforward online (prima copia)
+ARCH File di controllo (seconda copia) 2 x P20 (512 GiB)
Log di rollforward archiviati
+RECO File di controllo (terza copia) 2 x P20 (512 GiB)
Backup RMAN (facoltativo)
Area di recupero (facoltativa)

Variante 2: volumi di dati da medie a grandi dimensioni tra 3 TB e 12 TB, tempo di ripristino importante

Il cliente ha database di medie o grandi dimensioni in cui il backup e/o il ripristino +

il recupero di tutti i database non può essere eseguito in modo tempestivo.

In genere i clienti usano RMAN, Backup di Azure per le tecniche di ancoraggio su disco e/o Oracle in combinazione.

Le differenze principali rispetto alla variante 1 sono:

  1. Gruppo di dischi Oracle ASM separato per ogni database
  2. <DBNAME>+“_” è usato come prefisso per il nome del gruppo del disco DATA
  3. Il numero del gruppo del disco DATA viene aggiunto se il database si estende su più gruppi di dischi DATA
  4. Nessun log di rollforward online si trova nei gruppi di dischi "dati". Viene invece usato un gruppo di dischi aggiuntivo per il primo membro di ogni gruppo di log di rollforward online.
Nome del gruppo di dischi ASM Stores Archiviazione di Azure
+<DBNAME>_DATA[#] Tutti i file di dati 3-12 x P 30 (1 TiB)
Tutti i file temporanei Per aumentare le dimensioni del database, aggiungere dischi P30 aggiuntivi
File di controllo (prima copia)
+OLOG Log di rollforward online (prima copia) 3 x P20 (512 GiB)
+ARCH File di controllo (seconda copia) 3 x P20 (512 GB)
Log di rollforward archiviati
+RECO File di controllo (terza copia) 3 x P20 (512 GiB)
Backup RMAN (facoltativo)
Area di recupero rapido (facoltativa)

Variante 3: enormi volumi di dati e modifiche ai dati di più di 5 TB, tempo di ripristino cruciale

Il cliente ha un database enorme in cui non è possibile eseguire il backup e/o il ripristino + ripristino di un singolo database in modo tempestivo.

In genere i clienti usano RMAN, Backup di Azure per le tecniche di ancoraggio su disco e/o Oracle in combinazione. In questa variante ogni tipo di file di database pertinente è separato rispetto ai diversi gruppi di dischi Oracle ASM.

Nome del gruppo di dischi ASM Stores Archiviazione di Azure
+<DBNAME>_DATA[#] Tutti i file di dati 5-30 o più x P30 (1 TiB) o P40 (2 TiB)
Tutti i file temporanei Per aumentare le dimensioni del database, aggiungere dischi P30 aggiuntivi
File di controllo (prima copia)
+OLOG Log di rollforward online (prima copia) 3-8 x P20 (512 GiB) o P30 (1 TiB)
Per una maggiore sicurezza è possibile selezionare "Ridondanza normale" per questo gruppo di dischi ASM
+ARCH File di controllo (seconda copia) 3-8 x P20 (512 GiB) o P30 (1 TiB)
Log di rollforward archiviati
+RECO File di controllo (terza copia) 3 x P30 (1 TiB), P40 (2 TiB) o P50 (4 TiB)
Backup RMAN (facoltativo)
Area di recupero rapido (facoltativa)

Nota

La cache del disco host di Azure per il gruppo di dischi ASM DATA può essere impostata su Sola lettura o Nessuno. Tutti gli altri gruppi di dischi ASM devono essere impostati su Nessuno. In BW o SCM è possibile prendere in considerazione un gruppo di dischi ASM separato per TEMP per i sistemi di grandi dimensioni o sovraccarichi.

Aggiunta di spazio ad ASM e dischi di Azure

I gruppi di dischi Oracle ASM possono essere estesi aggiungendo dischi o estendendo i dischi correnti. È consigliabile aggiungere dischi aggiuntivi anziché estendere i dischi esistenti. Consultare questi articoli e collegamenti MOS: Note 1684112.1 e 2176737.1

ASM aggiunge un disco al gruppo di dischi: asmca -silent -addDisk -diskGroupName DATA -disk '/dev/sdd1'

ASM ribilancia automaticamente i dati. Per controllare il ribilanciamento, eseguire questo comando.

ps -ef | grep rbal

oraasm 4288 1 0 Jul28 ? 00:04:36 asm_rbal_oradb1

La documentazione è disponibile con:

Monitoraggio di SAP nei sistemi Oracle ASM in Azure

Come primo passaggio nella risoluzione di un problema di prestazioni, eseguire un report Oracle AWR. Le metriche delle prestazioni del disco sono descritte in dettaglio nel report AWR.

Le prestazioni del disco possono essere monitorate dall'interno di Oracle Enterprise Manager e tramite strumenti esterni. La documentazione, che potrebbe essere utile, è disponibile qui:

Gli strumenti di monitoraggio a livello di sistema operativo non possono monitorare i dischi ASM perché non esiste un file system riconoscibile. Il monitoraggio dello spazio libero deve essere eseguito dall'interno di Oracle.

Risorse di training su Oracle Automatic Storage Management (ASM)

Gli amministratori di database Oracle che non hanno familiarità con Oracle ASM seguono qui i materiali e le risorse di training:

Azure NetApp Files (ANF) con Oracle dNFS (Direct NFS)

La combinazione di macchine virtuali di Azure e ANF è una combinazione affidabile e collaudata implementata da molti clienti su larga scala.

I database di oltre 100 TB sono già in esecuzione in questa combinazione. Per iniziare, abbiamo scritto un blog dettagliato su come configurare questa combinazione:

Altre informazioni di carattere generale

Il log di mirror è obbligatorio nei sistemi di produzione dNFS ANF.

Anche se ANF è altamente ridondante, Oracle richiede comunque un volume di file di log di rollforward con mirroring. È consigliabile creare due volumi separati e configurare origlogA insieme a mirrlogB, origlogB insieme a mirrlogA. In questo caso si usa un bilanciamento del carico distribuito dei file di log di rollforward.

L'opzione di montaggio "nconnect" non è consigliata quando il client dNFS è configurato. dNFS gestisce il canale I/O e usa più sessioni, quindi questa opzione è obsoleta e può causare vari problemi. Il client dNFS ignorerà le opzioni di montaggio e gestirà direttamente l'I/O.

Entrambe le versioni NFS (v3 e v4.1) con ANF sono supportate per i file binari, i dati e i file di log Oracle.

È consigliabile usare il client Oracle dNFS per tutti i volumi Oracle.

Le opzioni di montaggio consigliate sono:

Versione NFS Opzioni di montaggio
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

Backup di ANF

Con ANF, sono disponibili alcune funzionalità chiave, come backup coerenti basati su snapshot, bassa latenza e prestazioni notevolmente elevate. Dalla versione 6 dello strumento AzAcSnap app Azure lication Consistent Snapshot per ANF, i database Oracle possono essere configurati per snapshot di database coerenti.

Tali snapshot rimangono nel volume di dati effettivo e devono essere copiati in un'altra posizione tramite ANF CRR (replica tra più aree) Replica tra più aree di ANF o altri strumenti di backup.

SAP in Oracle in Azure con LVM

ASM è la raccomandazione predefinita di Oracle per tutti i sistemi SAP di qualsiasi dimensione in Azure. Prestazioni, affidabilità e supporto sono migliori per i clienti che usano ASM. Oracle fornisce documentazione e formazione per gli amministratori di database per la transizione ad ASM. Nei casi in cui il team oracle DBA non segue la raccomandazione da Oracle, Microsoft e SAP per usare ASM, è consigliabile usare la configurazione LVM seguente.

Si noti che quando si crea LVM è necessario usare l'opzione "-i" per distribuire uniformemente i dati nel numero di dischi nel gruppo LVM.

Quando si esegue LVM, è necessario il log di mirror.

Configurazione minima in Linux:

Componente Disco Cache dell'host Striping1
/oracle/<SID>/origlogaA & mirrlogB Premium None Non necessaria
/oracle/<SID>/origlogaB & mirrlogA Premium None Non necessaria
/oracle/<SID>/sapdata1...n Premium Sola lettura2 Consigliato
/oracle/<SID>/oraarch3 Premium None Non necessaria
Oracle Home, saptrace,... Premium None None
  1. Striping: striscia LVM con RAID0
  2. Durante le migrazioni R3Load, l'opzione Cache host per SAPDATA deve essere impostata su Nessuno
  3. oraarch: LVM è facoltativo

La selezione del disco per l'hosting dei log di rollforward online di Oracle è basata sui requisiti di IOPS. È possibile archiviare tutti gli spazi di tabella sapdata1... n in un unico disco montato, purché il volume, le operazioni di I/O al secondo e la velocità effettiva soddisfino i requisiti.

Configurazione delle prestazioni in Linux:

Componente Disco Cache dell'host Striping1
/oracle/<SID>/origlogaA Premium None Può essere usato
/oracle/<SID>/origlogaB Premium None Può essere usato
/oracle/<SID>/mirrlogAB Premium None Può essere usato
/oracle/<SID>/mirrlogBA Premium None Può essere usato
/oracle/<SID>/sapdata1...n Premium Sola lettura2 Consigliato
/oracle/<SID>/oraarch3 Premium None Non necessaria
Oracle Home, saptrace,... Premium None None
  1. Striping: striscia LVM con RAID0
  2. Durante le migrazioni R3load, l'opzione Cache host per SAPDATA deve essere impostata su Nessuno
  3. oraarch: LVM è facoltativo

Infrastruttura di Azure: Limiti della velocità effettiva della macchina virtuale e Opzioni di Archiviazione dischi di Azure

Oracle Automatic Storage Management (ASM)## può valutare queste tecnologie di archiviazione:

  1. Archiviazione Premium di Azure: attualmente la scelta predefinita
  2. Bursting dei dischi gestiti: Bursting dei dischi gestiti - Macchine virtuali di Azure | Microsoft Docs
  3. Acceleratore di scrittura di Azure
  4. L'estensione del disco online per l'archiviazione SSD Premium di Azure è ancora in corso

I tempi di scrittura dei log possono essere migliorati nelle macchine virtuali serie M di Azure abilitando l'acceleratore di scrittura. Abilitare l'acceleratore di scrittura di Azure per i dischi di Archiviazione Premium di Azure usati dal gruppo di dischi ASM per i file di log di rollforward online. Per altre informazioni, vedere Acceleratore di scrittura.

L'uso dell'acceleratore di scrittura è facoltativo, ma può essere abilitato se il report AWR indica tempi di scrittura del log superiori al previsto.

Limiti di velocità effettiva della macchina virtuale di Azure

Ogni tipo di macchina virtuale di Azure ha limiti per CPU, disco, rete e RAM. Questi limiti sono documentati nei collegamenti seguenti

Quando si seleziona un tipo di macchina virtuale, è necessario seguire le raccomandazioni seguenti:

  1. Verificare che la velocità effettiva e le operazioni di I/O al secondo del disco siano sufficienti per il carico di lavoro e almeno uguali alla velocità effettiva aggregata dei dischi
  2. Valutare la possibilità di abilitare il bursting a pagamento, in particolare per i dischi di log di rollforward
  3. Per ANF, la velocità effettiva di rete è importante perché tutto il traffico di archiviazione viene conteggiato come "Rete" anziché come velocità effettiva del disco
  4. Per l'ottimizzazione della rete per la serie M Ottimizzazione della velocità effettiva di rete nelle macchine virtuali serie M di Azure HCMT (microsoft.com), vedere questo blog
  5. Fare riferimento a questo collegamento che descrive come usare un report AWR per selezionare la macchina virtuale di Azure corretta
  6. Azure Intel Ev5 Serie Edv5 e Edsv5-- Macchine virtuali di Azure | Microsoft Docs
  7. Azure AMD Eadsv5 Serie Easv5 e Eadsv5 - Macchine virtuali di Azure | Microsoft Docs
  8. Serie M/Serie Msv2 di Azure Serie M - Macchine virtuali di Azure | Microsoft Docs e Serie di memoria media Msv2/Mdsv2 - Macchine virtuali di Azure | Microsoft Docs
  9. Azure Mv2 Serie Mv2 - Macchine virtuali di Azure | Microsoft Docs

Backup/ripristino

Per la funzionalità di backup/ripristino, BR*Tools di SAP per Oracle è supportato esattamente come in bare metal e Hyper-V. Anche Oracle Recovery Manager (RMAN) è supportato per i backup su disco e per il ripristino da disco.

Per altre informazioni su come è possibile usare i servizi di backup e recupero di Azure per i database Oracle, vedere:

Disponibilità elevata

Oracle Data Guard è supportato per motivi di disponibilità elevata e ripristino di emergenza. Per ottenere il failover automatico in Data Guard, è necessario usare FSFA (Fast-Start Failover). La funzionalità osservatore (FSFA) attiva il failover. Se non si usa FSFA, è possibile usare solo una configurazione di failover manuale. Per altre informazioni, vedere Implementare Oracle Data Guard su una macchina virtuale Linux di Azure.

Gli aspetti relativi al ripristino di emergenza dei database Oracle in Azure sono illustrati nell'articolo Ripristino di emergenza per un'istanza di Oracle Database 12c in un ambiente Azure.

Un altro ottimo whitepaper Oracle Setting up Oracle 12c Data Guard for SAP Customers

Grandi pagine e configurazioni SGA Oracle di grandi dimensioni

Le distribuzioni di VLDB SAP in Oracle in Azure applicano dimensioni di SGA superiori a 3 TB. Le versioni moderne di Oracle gestiscono bene SGA di grandi dimensioni e riducono significativamente le operazioni di I/O. Per ridurre le operazioni di I/O di lettura, esaminare il report AWR e aumentare le dimensioni di SGA. 

Come indicazione generale, è necessario che le hugepage di Linux siano configurate all'incirca sul 75% delle dimensioni della RAM della macchina virtuale. Le dimensioni dell'SGA possono essere impostate sul 90% delle dimensioni della hugepage. Un esempio approssimativo sarebbe una macchina virtuale M192ms con 4 TB di RAM con enormi pagine impostate a un massimo di 3 TB.  L'SGA può essere impostato su un valore leggermente inferiore, ad esempio 2,95 TB.

I clienti SAP di grandi dimensioni che eseguono macchine virtuali di Azure dalla memoria alta traggono molti vantaggi dalle hugepage, come descritto in questo articolo

I sistemi NUMA vm.min_free_kbytes devono essere impostati su 524288 * <numero di nodi NUMA>. Vedere Oracle Linux : Recommended Value of vm.min_free_kbytes Kernel Tuning Parameter (Doc ID 2501269.1...

 

Oracle Linux offre un'utile utilità di gestione dell'interfaccia utente grafica:

Oracle Linux ha un nuovo strumento di gestione dei pacchetti: DNF

Oracle Linux 8: Package Management made easy with free videos | Oracle Linux Blog

Oracle® Linux 8 Managing Software on Oracle Linux - Chapter 1 Yum DNF

Le configurazioni di memoria e NUMA possono essere testate e sottoposte a benchmarking con un utile strumento: Oracle Real Application Testing (RAT)

Oracle Real Application Testing: What Is It and How Do You Use It? (aemcorp.com)

Informazioni sul problema di danneggiamento del log UDEV Oracle Redolog corruption on Azure | Oracle in the field (wordpress.com)

Oracle ASM in Azure corruption - follow up (dbaharrison.blogspot.com)

Data corruption on Hyper-V or Azure when running Oracle ASM - Red Hat Customer Portal

Configurare Oracle ASM in una macchina virtuale di Azure Linux - Macchine virtuali di Azure | Microsoft Docs

Linee guida per la configurazione di Oracle per le installazioni di SAP nelle macchine virtuali di Azure su Windows

SAP in Oracle in Azure supporta anche Windows. Di seguito sono riepilogate le raccomandazioni per le distribuzioni di Windows:

  1. Sono consigliate le versioni di Windows seguenti: Windows Server 2022 (solo da Oracle Database 19.13.0 in poi), Windows Server 2019 (solo da Oracle Database 19.5.0 in poi)
  2. Non è disponibile alcun supporto per ASM in Windows. Per ottenere prestazioni ottimali, occorre usare gli spazi di archiviazione di Windows per aggregare i dischi
  3. Installare Oracle Home in un disco indipendente dedicato (non installare Oracle Home nell'unità C:
  4. Tutti i dischi devono essere formattati come NTFS
  5. Seguire la guida all'ottimizzazione di Windows di Oracle e abilitare pagine di grandi dimensioni, bloccare le pagine in memoria e altre impostazioni specifiche di Windows

Al momento, la scrittura di ASM per i clienti Windows in Azure non è supportata. SAP Software Provisioning Manager (SWPM) per Windows attualmente non supporta ASM.

Configurazioni di archiviazione per SAP in Oracle in Windows

Configurazione minima in Windows:

Componente Disco Cache dell'host Striping1
E:\oracle\<SID>\origlogaA & mirrlogB Premium None Non necessaria
F:\oracle\<SID>\origlogaB & mirrlogA Premium None Non necessaria
G:\oracle\<SID>\sapdata1...n Premium Sola lettura2 Consigliato
H:\oracle\<SID>\oraarch3 Premium None Non necessaria
I:\Oracle Home, saptrace, ... Premium None None
  1. Striping: spazi di archiviazione di Windows
  2. Durante le migrazioni R3load, l'opzione Cache host per SAPDATA deve essere impostata su Nessuno
  3. oraarch: spazi di archiviazione di Windows facoltativi

La selezione del disco per l'hosting dei log di rollforward online di Oracle è basata sui requisiti di IOPS. È possibile archiviare tutti gli spazi di tabella sapdata1... n in un unico disco montato, purché il volume, le operazioni di I/O al secondo e la velocità effettiva soddisfino i requisiti.

Configurazione delle prestazioni in Windows:

Componente Disco Cache dell'host Striping1
E:\oracle\<SID>\origlogaA Premium None Può essere usato
F:\oracle\<SID>\origlogaB Premium None Può essere usato
G:\oracle\<SID>\mirrlogAB Premium None Può essere usato
H:\oracle\<SID>\mirrlogBA Premium None Può essere usato
I:\oracle\<SID>\sapdata1...n Premium Sola lettura2 Consigliato
J:\oracle\<SID>\oraarch3 Premium None Non necessaria
K:\Oracle Home, saptrace, ... Premium None None
  1. Striping: spazi di archiviazione di Windows
  2. Durante le migrazioni R3load, l'opzione Cache host per SAPDATA deve essere impostata su Nessuno
  3. oraarch: spazi di archiviazione di Windows facoltativi

Passaggi successivi

Leggi l'articolo