Share via


Azure Virtual Machines Oracle-databasdistribution för SAP-arbetsbelastning

Det här dokumentet beskriver flera olika områden att tänka på när du distribuerar Oracle Database for SAP-arbetsbelastningar i Azure IaaS. Innan du läser det här dokumentet rekommenderar vi att du läser Överväganden för AZURE Virtual Machines DBMS-distribution för SAP-arbetsbelastning. Vi rekommenderar också att du läser andra guider i SAP-arbetsbelastningen i Azure-dokumentationen.

Du hittar information om Oracle-versioner och motsvarande OS-versioner som stöds för att köra SAP på Oracle på Azure i SAP Note 2039619.

Allmän information om hur du kör SAP Business Suite på Oracle finns i SAP på Oracle. Oracle har stöd för att köra Oracle-databaser på Microsoft Azure. Mer information om allmän support för Windows Hyper-V och Azure finns i Vanliga frågor och svar om Oracle och Microsoft Azure.

Följande SAP-anteckningar är relevanta för en Oracle-installation

Anteckningsnummer Anteckningsrubrik
1738053 SAPinst för Oracle ASM-installation SAP ONE Support Launchpad
2896926 ASM-diskgruppskompatibilitet NetWeaver SAP ONE Support Launchpad
1550133 Använda Oracle Automatic Storage Management (ASM) med SAP NetWeaver-baserade produkter SAP ONE Support Launchpad]
888626 Gör om logglayouten för avancerade system sap one support launchpad
105047 Stöd för Oracle-funktioner i SAP-miljön SAP ONE Support Launchpad
2799920 Korrigeringar för 19c: Sap ONE-databasstöd launchpad
974876 Oracle transparent datakryptering (TDE) SAP ONE Support Launchpad
2936683 Oracle Linux 8: SAP-installation och uppgradering av SAP ONE Support Launchpad
1672954 Oracle 11g, 12c, 18c och 19c: Användning av enorma sidor i Linux
1171650 Automatiserad Oracle DB-parameterkontroll
2936683 Oracle Linux 8: SAP-installation och uppgradering

Detaljer för Oracle Database på Oracle Linux

Oracle har stöd för att köra sina databasinstanser på Microsoft Azure med Oracle Linux som gästoperativsystem. Mer information om allmän support för Windows Hyper-V och Azure finns i vanliga frågor och svar om Azure och Oracle.

Det specifika scenariot med SAP-program som använder Oracle Databases stöds också. Information beskrivs i nästa del av dokumentet.

Allmänna Rekommendationer för att köra SAP på Oracle i Azure

När du installerar eller migrerar befintliga SAP på Oracle-system till Azure bör följande distributionsmönster följas:

  1. Använd den senaste Oracle Linux-versionen (Oracle Linux 8.6 eller senare).
  2. Använd den senaste Oracle Database-versionen som är tillgänglig med den senaste SAP Bundle Patch (SBP) (Oracle 19 Patch 15 eller senare) 2799920 – Patchar för 19c: Database.
  3. Använd Automatisk lagringshantering (ASM) för små, medelstora och stora databaser på blocklagring.
  4. Azure Premium Storage SSD bör användas. Använd inte Standard eller andra lagringstyper.
  5. ASM tar bort kravet på speglingslogg. Följ riktlinjerna från Oracle i Note 888626 – Gör om logglayouten för avancerade system.
  6. Använd ASMLib och använd inte udev.
  7. Azure NetApp Files-distributioner bör använda Oracle dNFS (Oracles egen högpresterande Direct NFS-lösning).
  8. Stora Oracle-databaser drar stor nytta av stora SGA-storlekar (System Global Area). Stora kunder bör distribueras i Azure M-serien med 4 TB eller mer RAM-storlek
    • Ange Stora Linux-sidor till 75 % av den fysiska RAM-storleken
    • Ange System Global Area (SGA) till 90 % av storleken på stora sidor
    • Ange Oracle-parametern USE_LARGE_PAGES = ONLY – Värdet ONLY föredras framför värdet TRUE eftersom värdet ONLY ska ge mer konsekventa och förutsägbara prestanda. Värdet TRUE kan allokera både stora 2MB- och standardsidor på 4 000 sidor. Värdet ONLY kommer alltid att framtvinga stora 2MB-sidor. Om antalet tillgängliga stora sidor inte är tillräckligt eller inte är korrekt konfigurerat kommer databasinstansen inte att börja med felkoden: ora-27102 : slut på minne Linux_x86_64 Fel 12 : kan inte allokera minne. Om det inte finns tillräckligt med sammanhängande minne kan Oracle Linux behöva startas om och/eller parametrarna för operativsystemets enorma sida konfigureras om.
  9. Oracle Home bör finnas utanför "rotvolymen" eller disken. Använd en separat disk eller ANF-volym. Disken som innehåller Oracle Home ska vara 64 Gigabyte i storlek eller större.
  10. Storleken på startdisken för stora Oracle-databasservrar med höga prestanda är viktigt. Minst en P10-disk ska användas för M-serien eller E-serien. Använd inte små diskar som P4 eller P6. En liten disk kan orsaka prestandaproblem.
  11. Accelererat nätverk måste vara aktiverat på alla virtuella datorer. Uppgradera till den senaste Oracle Linux-versionen om det finns problem med att aktivera accelererat nätverk.
  12. Sök efter uppdateringar i den här dokumentationen och SAP-anteckningen 2039619 – SAP-program på Microsoft Azure med hjälp av Oracle Database: Produkter och versioner som stöds – SAP ONE Support Launchpad.

Information om vilka Oracle-versioner och motsvarande OS-versioner som stöds för att köra SAP på Oracle på Azure Virtual Machines finns i SAP Note 2039619.

Allmän information om hur du kör SAP Business Suite på Oracle finns på sidan SAP på Oracle Community. SAP på Oracle på Azure stöds endast på Oracle Linux (och inte Suse eller Red Hat) för program- och databasservrar. ASCS/ERS-servrar kan använda RHEL/SUSE eftersom Oracle-klienten inte är installerad eller används på dessa virtuella datorer. Programservrar (PAS/AAS) bör inte installeras på dessa virtuella datorer. Se SAP Note 3074643 – OLNX: Vanliga frågor och svar: om Pacemaker för Oracle Linux stöds i SAP-miljön. Oracle Real Application Cluster (RAC) stöds inte i Azure eftersom RAC skulle kräva Multicast-nätverk.

Storage-konfiguration

Det finns två rekommenderade lagringsdistributionsmönster för SAP på Oracle i Azure:

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

Kunder som för närvarande kör Oracle-databaser på EXT4- eller XFS-filsystem med Logical Volume Manager (LVM) uppmanas att flytta till ASM. Det finns betydande prestanda-, administrations- och tillförlitlighetsfördelar med att köra på ASM jämfört med LVM. ASM minskar komplexiteten, förbättrar supporten och gör administrationsuppgifterna enklare. Den här dokumentationen innehåller länkar för Oracle Database-administratörer (DBA) för att lära dig hur du installerar och hanterar ASM.

Azure tillhandahåller flera lagringslösningar. Tabellen nedan beskriver supportstatusen

Lagringstyp Oracle-stöd Sektorstorlek Oracle Linux 8.x eller senare Windows Server 2019
Blocklagringstyp
Premium SSD Stöds 512e ASM rekommenderas. LVM stöds Inget stöd för ASM i Windows
Premium SSD v2 Stöds 4K Native eller 512e1 ASM rekommenderas. LVM stöds Inget stöd för ASM i Windows. Ändra loggfildiskar från 4K Native till 512e
Standard SSD Stöds inte
Standard HDD Stöds inte
Ultradisk Stöds 4 000 inbyggt ASM rekommenderas. LVM stöds Inget stöd för ASM i Windows. Ändra loggfildiskar från 4K Native till 512e
Nätverkslagringstyper
Azure NetApp Service (ANF) Stöds - Oracle dNFS krävs Stöds inte
Azure Files NFS Stöds inte
Azure files SMB Stöds inte

1 512e stöds på Premium SSD v2 för Windows-system. 512e-konfigurationer rekommenderas inte för Linux-kunder. Migrera till 4K Native med hjälp av proceduren i MOS 512/512e-sektorstorlek till 4K Intern granskning (Doc ID 1133713.1)

Andra överväganden som gäller för listan, till exempel:

  1. Inget stöd för DIRECTIO med 4K Intern sektorstorlek. Rekommenderade inställningar för FILESYSTEMIO_OPTIONS för LVM-konfigurationer:
    • LVM – Om diskar med 512/512e geometri används, FILESYSTEMIO_OPTIONS = SETALL
    • LVM – Om diskar med 4K intern geometri används, FILESYSTEMIO_OPTIONS = ASYNC
  2. Oracle 19c och högre har fullt stöd för 4K Intern sektorstorlek med både ASM och LVM
  3. Oracle 19c och senare i Linux – när du flyttar från 512e Storage till 4K Native Storage Log-sektorstorlekar måste ändras
  4. Om du vill migrera från 512/512e-sektorstorlek till 4K Intern granskning (Doc ID 1133713.1) – se avsnittet "Offlinemigrering till 4KB-sektordiskar"
  5. SAPInst skriver till pfile under installationen. Om $ORACLE_HOME/dbs finns på en 4K-diskuppsättning filesystemio_options=asynch och se avsnittet "Datafile Support of 4kB Sector Disks" i MOS Supporting 4K Sector Disks (Doc ID 1133713.1)
  6. Inget stöd för ASM på Windows-plattformar
  7. Inget stöd för 4K Intern sektorstorlek för loggvolym på Windows-plattformar. SSDv2 och Ultra Disk måste ändras till 512e via pennikonen "Redigera disk" i Azure-portalen
  8. 4K Intern sektorstorlek stöds endast på datavolymer för Windows-plattformar. 4K stöds inte för loggvolymer i Windows
  9. Vi rekommenderar att du läser dessa MOS-artiklar:
    • Oracle Linux: Filsystemets buffertcache jämfört med direkt I/O (Doc ID 462072.1)
    • Stöd för 4K-sektordiskar (Doc ID 1133713.1)
    • Använda 4k Gör om loggar på Flash, 4k-Disk och SSD-baserad lagring (Doc ID 1681266.1)
    • Saker att tänka på när du ställer in filesystemio_options och disk_asynch_io (Doc ID 1987437.1)

Vi rekommenderar att du använder Oracle ASM på Linux med ASMLib. Prestanda, administration, support och konfiguration optimeras med distributionsmönster. Oracle ASM och Oracle dNFS kommer att ange rätt parametrar eller kringgå parametrar (till exempel FILESYSTEMIO_OPTIONS) och därmed ge bättre prestanda och tillförlitlighet.

Oracle Automatic Storage Management (ASM)

Checklista för oracles automatiska lagringshantering:

  1. Alla SAP på Oracle i Azure-system kör ASM , inklusive utveckling, kvalitetssäkring och produktion. Små, medelstora och stora databaser
  2. ASMLib används och inte UDEV. UDEV krävs för flera SAN, ett scenario som inte finns i Azure
  3. ASM bör konfigureras för extern redundans. Azure Premium SSD-lagring ger trippelredundans. Azure Premium SSD matchar tillförlitligheten och integriteten för alla andra lagringslösningar. För valfri säkerhet kan kunderna överväga normal redundans för loggdiskgruppen
  4. Spegling Gör om loggfiler är valfritt för ASM-888626 – Gör om logglayouten för avancerade system
  5. ASM-diskgrupper som konfigurerats enligt variant 1, 2 eller 3 nedan
  6. STORLEK på ASM-allokeringsenhet = 4 MB (standard). Mycket stora databaser (VLDB) OLAP-system som BW kan dra nytta av större ASM-allokeringsenhetsstorlek. Ändra endast efter bekräftelse med Oracle-stöd
  7. ASM-sektorstorlek och logisk sektorstorlek = standard (UDEV rekommenderas inte men kräver 4k)
  8. Om KOMPATIBEL. ASM-diskgruppsattributet är inställt på 11.2 eller senare för en diskgrupp. Du kan skapa, kopiera eller flytta en Oracle ASM SPFILE till ACFS-filsystemet. Läs Oracle-dokumentationen om hur du flyttar pfile till ACFS. SAPInst skapar inte pfile i ACFS som standard
  9. Lämplig ASM-variant används. Produktionssystem bör använda variant 2 eller 3

Oracles diskgrupper för automatisk lagringshantering

I del II av den officiella Oracle-guiden beskrivs installation och hantering av ASM:

Följande ASM-gränser finns för Oracle Database 12c eller senare:

511 diskgrupper, 10 000 ASM-diskar i en diskgrupp, 65 530 ASM-diskar i ett lagringssystem, 1 miljon filer för varje diskgrupp. Mer information här: Prestanda- och skalbarhetsöverväganden för diskgrupper (oracle.com)

Läs ASM-dokumentationen i den relevanta SAP-installationsguiden för Oracle som är tillgänglig från https://help.sap.com/viewer/nwguidefinder

Variant 1 – små till medelstora datavolymer upp till 3 TB, återställningstiden är inte kritisk

Kunden har små eller medelstora databaser där säkerhetskopiering och/eller återställning + återställning av alla databaser kan utföras med RMAN i tid. Exempel: När en fullständig Oracle ASM-diskgrupp, med datafiler, från en eller flera databaser bryts och alla datafiler från alla databaser måste återställas till en nyskapad Oracle ASM-diskgrupp med RMAN.

Oracle ASM-diskgruppsrekommendations:

NAMN på ASM-diskgrupp Stores Azure Storage
+DATA Alla datafiler 3-6 x P 30 (1 TiB)
Kontrollfil (första kopian) Om du vill öka databasens storlek lägger du till extra P30-diskar
Gör om loggar online (första kopian)
+ARCH Kontrollfil (andra kopian) 2 x P20 (512 GiB)
Arkiverade omloggar
+RECO Kontrollfil (tredje kopian) 2 x P20 (512 GiB)
RMAN-säkerhetskopior (valfritt)
återställningsområde (valfritt)

Variant 2 – medelstora till stora datavolymer mellan 3 TB och 12 TB, återställningstid viktig

Kunden har medelstora till stora databaser där säkerhetskopiering och/eller återställning +

återställning av alla databaser kan inte utföras i tid.

Vanligtvis använder kunderna RMAN, Azure Backup för Oracle och/eller snaptekniker för diskar i kombination.

Större skillnader i variant 1 är:

  1. Separera Oracle ASM-diskgrupp för varje databas
  2. <DBNAME>+"_" används som prefix för namnet på datadiskgruppen
  3. Antalet DATA-diskgrupper läggs till om databasen sträcker sig över mer än en DATA-diskgrupp
  4. Inga onlineloggar finns i diskgrupperna "data". I stället används en extra diskgrupp för den första medlemmen i varje online-omlogggrupp.
NAMN på ASM-diskgrupp Stores Azure Storage
+<DBNAME>_DATA[#] Alla datafiler 3-12 x P 30 (1 TiB)
Alla temporära filer Om du vill öka databasens storlek lägger du till extra P30-diskar
Kontrollfil (första kopian)
+OLOG Gör om loggar online (första kopian) 3 x P20 (512 GiB)
+ARCH Kontrollfil (andra kopian) 3 x P20 (512 GB)
Arkiverade omloggar
+RECO Kontrollfil (tredje kopian) 3 x P20 (512 GiB)
RMAN-säkerhetskopior (valfritt)
Snabbt återställningsområde (valfritt)

Variant 3 – enorma data- och dataändringsvolymer på mer än 5 TB, återställningstid avgörande

Kunden har en enorm databas där säkerhetskopiering och/eller återställning + återställning av en enskild databas inte kan utföras i tid.

Vanligtvis använder kunderna RMAN, Azure Backup för Oracle och/eller snaptekniker för diskar i kombination. I den här varianten separeras varje relevant databasfiltyp till olika Oracle ASM-diskgrupper.

NAMN på ASM-diskgrupp Stores Azure Storage
+<DBNAME>_DATA[#] Alla datafiler 5–30 eller fler x P30 (1 TiB) eller P40 (2 TiB)
Alla temporära filer För att öka databasens storlek lägger du till extra P30-diskar
Kontrollfil (första kopian)
+OLOG Gör om loggar online (första kopian) 3-8 x P20 (512 GiB) eller P30 (1 TiB)
För mer säkerhet kan "Normal redundans" väljas för den här ASM-diskgruppen
+ARCH Kontrollfil (andra kopian) 3-8 x P20 (512 GiB) eller P30 (1 TiB)
Arkiverade omloggar
+RECO Kontrollfil (tredje kopian) 3 x P30 (1 TiB), P40 (2 TiB) eller P50 (4 TiB)
RMAN-säkerhetskopior (valfritt)
Snabbt återställningsområde (valfritt)

Kommentar

Azure Host Disk Cache för DATA ASM-diskgruppen kan anges till skrivskyddad eller Ingen. Alla andra ASM-diskgrupper ska vara inställda på Ingen. På BW eller SCM kan en separat ASM-diskgrupp för TEMP övervägas för stora eller upptagna system.

Lägga till utrymme i ASM + Azure Disks

Oracle ASM-diskgrupper kan antingen utökas genom att lägga till extra diskar eller genom att utöka aktuella diskar. Vi rekommenderar att du lägger till extra diskar i stället för att utöka befintliga diskar. Granska dessa MOS-artiklar och länkar MOS Notes 1684112.1 och 2176737.1

ASM lägger till en disk i diskgruppen: asmca -silent -addDisk -diskGroupName DATA -disk '/dev/sdd1'

ASM balanserar automatiskt om data. Om du vill kontrollera ombalansering kör du det här kommandot.

ps -ef | grep rbal

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

Dokumentation finns tillgänglig med:

Övervaka SAP på Oracle ASM-system i Azure

Kör en Oracle AWR-rapport som det första steget när du felsöker ett prestandaproblem. Prestandamått för diskar beskrivs i AWR-rapporten.

Diskprestanda kan övervakas inifrån Oracle Enterprise Manager och via externa verktyg. Dokumentation som kan vara till hjälp finns här:

Övervakningsverktyg på operativsystemnivå kan inte övervaka ASM-diskar eftersom det inte finns något igenkännbart filsystem. Övervakning av ledigt utrymme måste göras inifrån Oracle.

Utbildningsresurser på Oracle Automatic Storage Management (ASM)

Oracle DBA:er som inte är bekanta med Oracle ASM följer utbildningsmaterialen och resurserna här:

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

Kombinationen av virtuella Azure-datorer och ANF är en robust och beprövad kombination som implementeras av många kunder i exceptionellt stor skala.

Databaser på över 100 TB körs redan produktiva i den här kombinationen. Till att börja med skrev vi en detaljerad blogg om hur du konfigurerar den här kombinationen:

Mer allmän information

Speglingslogg krävs på dNFS ANF-produktionssystem.

Även om ANF är mycket redundant kräver Oracle fortfarande en speglad redo-logfile-volym. Rekommendationen är att skapa två separata volymer och konfigurera origlogA tillsammans med mirrlogB och origlogB tillsammans med mirrlogA. I det här fallet använder du en distribuerad belastningsutjämning av de omgjorda loggfilerna.

Monteringsalternativet "nconnect" rekommenderas inte när dNFS-klienten har konfigurerats. dNFS hanterar I/O-kanalen och använder flera sessioner, så det här alternativet är föråldrat och kan orsaka många problem. dNFS-klienten kommer att ignorera monteringsalternativen och kommer att hantera I/O direkt.

Både NFS-versioner (v3 och v4.1) med ANF stöds för Oracle-binärfiler, data- och loggfiler.

Vi rekommenderar starkt att du använder Oracle dNFS-klienten för alla Oracle-volymer.

Rekommenderade monteringsalternativ är:

NFS-version Monteringsalternativ
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

ANF-säkerhetskopiering

Med ANF är vissa viktiga funktioner tillgängliga som konsekventa ögonblicksbildbaserade säkerhetskopior, låg svarstid och anmärkningsvärt höga prestanda. Från version 6 av vårt AzAcSnap-verktyg Azure Application Consistent Snapshot-verktyg för ANF kan Oracle-databaser konfigureras för konsekventa databasögonblicksbilder.

Dessa ögonblicksbilder finns kvar på den faktiska datavolymen och måste kopieras bort med anf CRR-replikering (replikering mellan regioner) mellan regioner av ANF eller andra säkerhetskopieringsverktyg.

SAP på Oracle i Azure med LVM

ASM är standardrekommendationsen från Oracle för alla SAP-system av valfri storlek i Azure. Prestanda, tillförlitlighet och support är bättre för kunder som använder ASM. Oracle tillhandahåller dokumentation och utbildning för dbas för att övergå till ASM. I de fall då Oracle DBA-teamet inte följer rekommendationen från Oracle, Microsoft och SAP att använda ASM bör följande LVM-konfiguration användas.

Observera att när du skapar LVM måste alternativet "-i" användas för att fördela data jämnt över antalet diskar i LVM-gruppen.

Speglingslogg krävs när LVM körs.

Lägsta konfiguration av Linux:

Komponent Disk Värdcachen Striping1
/oracle/<SID>/origlogaA & mirrlogB Premium Ingen Krävs inte
/oracle/<SID>/origlogaB & mirrlogA Premium Ingen Krävs inte
/oracle/<SID>/sapdata1... N Premium Skrivskyddad2 Rekommenderat
/oracle/<SID>/oraarch3 Premium Ingen Krävs inte
Oracle Home, saptrace, ... Premium Ingen Ingen
  1. Striping: LVM stripe med RAID0
  2. Under R3Load-migreringar ska alternativet Värdcache för SAPDATA anges till Ingen
  3. oraarch: LVM är valfritt

Diskvalet för att vara värd för Oracles onlineloggar drivs av IOPS-krav. Det går att lagra alla sapdata1... n (tabellutrymmen) på en enda monterad disk så länge volymen, IOPS och dataflödet uppfyller kraven.

Prestandakonfiguration i Linux:

Komponent Disk Värdcachen Striping1
/oracle/<SID>/origlogaA Premium Ingen Kan användas
/oracle/<SID>/origlogaB Premium Ingen Kan användas
/oracle/<SID>/mirrlogAB Premium Ingen Kan användas
/oracle/<SID>/mirrlogBA Premium Ingen Kan användas
/oracle/<SID>/sapdata1... N Premium Skrivskyddad2 Rekommenderat
/oracle/<SID>/oraarch3 Premium Ingen Krävs inte
Oracle Home, saptrace, ... Premium Ingen Ingen
  1. Striping: LVM stripe med RAID0
  2. Under R3load-migreringar ska alternativet Värdcache för SAPDATA vara inställt på Ingen
  3. oraarch: LVM är valfritt

Azure Infra: Dataflödesgränser för virtuell dator och Lagringsalternativ för Azure Disk

Oracle Automatic Storage Management (ASM)## kan utvärdera dessa lagringstekniker:

  1. Azure Premium Storage – för närvarande standardalternativet
  2. Managed Disk Bursting – Bursting för hanterade diskar – Virtuella Azure-datorer | Microsoft Docs
  3. Azure Write Accelerator
  4. Onlinedisktillägget för Azure Premium SSD-lagring pågår fortfarande

Loggskrivningstider kan förbättras på virtuella Datorer i Azure M-serien genom att aktivera skrivaccelerator. Aktivera Azure Write Accelerator för De Azure Premium Storage-diskar som används av ASM-diskgruppen för att göra om loggfiler online. Mer information finns i Skriva accelerator.

Att använda skrivacceleratorn är valfritt men kan aktiveras om AWR-rapporten anger högre loggskrivningstider än förväntat.

Dataflödesgränser för virtuella Azure-datorer

Varje typ av virtuell Azure-dator (VM) har gränser för cpu, disk, nätverk och RAM-minne. Dessa gränser dokumenteras i länkarna nedan

Följande rekommendationer bör följas när du väljer en typ av virtuell dator:

  1. Se till att diskens dataflöde och IOPS är tillräckliga för arbetsbelastningen och minst lika med det aggregerade dataflödet för diskarna
  2. Överväg att aktivera betald bursting , särskilt för Att göra om loggdiskar
  3. För ANF är nätverkets dataflöde viktigt eftersom all lagringstrafik räknas som "Nätverk" i stället för diskdataflöde
  4. Läs den här bloggen för Nätverksjustering för M-serien Optimera nätverksdataflöde på virtuella datorer i Azure M-serien HCMT (microsoft.com)
  5. Granska den här länken som beskriver hur du använder en AWR-rapport för att välja rätt virtuell Azure-dator
  6. Azure Intel Ev5 Edv5 och Edsv5-serien – Azure Virtual Machines |Microsoft Docs
  7. Azure AMD Eadsv5 Easv5 och Eadsv5-serien – Azure Virtual Machines |Microsoft Docs
  8. Azure M-serien/Msv2-serien M-serien – Azure Virtual Machines |Microsoft Docs och Msv2/Mdsv2 Medium Memory Series – Azure Virtual Machines | Microsoft Docs
  9. Azure Mv2 Mv2-serien – Azure Virtual Machines | Microsoft Docs

Säkerhetskopiera och återställa

För säkerhetskopierings-/återställningsfunktioner stöds SAP BR*Tools for Oracle på samma sätt som de är i bare metal och Hyper-V. Oracle Recovery Manager (RMAN) stöds också för säkerhetskopieringar till diskar och återställningar från disk.

Mer information om hur du kan använda Azure Backup- och Recovery-tjänster för Oracle-databaser finns i:

Hög tillgänglighet

Oracle Data Guard stöds för hög tillgänglighet och haveriberedskap. För att uppnå automatisk redundans i Data Guard måste du använda snabbstartsredundans (FSFA). Funktionen Observer (FSFA) utlöser redundansväxlingen. Om du inte använder FSFA kan du bara använda en manuell redundanskonfiguration. Mer information finns i Implementera Oracle Data Guard på en virtuell Azure Linux-dator.

Haveriberedskapsaspekter för Oracle-databaser i Azure visas i artikeln Haveriberedskap för en Oracle Database 12c-databas i en Azure-miljö.

Ett annat bra Oracle-white paper som konfigurerar Oracle 12c Data Guard för SAP-kunder

Stora sidor och stora Oracle SGA-konfigurationer

VLDB SAP på Oracle i Azure-distributioner tillämpar SGA-storlekar som överstiger 3 TB. Moderna versioner av Oracle hanterar stora SGA-storlekar väl och minskar I/O avsevärt. Granska AWR-rapporten och öka SGA-storleken för att minska läs-I/O. 

Som allmän vägledning bör Linux Huge Pages konfigureras till cirka 75 % av VM RAM-storleken. SGA-storleken kan ställas in på 90 % av storleken På stora sidor. Ett ungefärligt exempel skulle vara en virtuell M192ms-dator med 4 TB RAM-minne som skulle ha enorma sidor inställda på 3 TB.  SGA kan anges till ett värde som är lite mindre, till exempel 2,95 TB.

Stora SAP-kunder som körs på virtuella Azure-datorer med högt minne drar stor nytta av HugePages enligt beskrivningen i den här artikeln

NUMA-system vm.min_free_kbytes ska anges till 524288 * <antal NUMA-noder>. Se Oracle Linux: Rekommenderat värde för vm.min_free_kbytes kerneljusteringsparameter (Doc ID 2501269.1...

 

Oracle Linux är ett användbart verktyg för GUI-hantering:

Oracle Linux har ett nytt pakethanteringsverktyg – DNF

Oracle Linux 8: Pakethantering enkelt med kostnadsfria videor | Oracle Linux-blogg

Oracle® Linux 8 Hantera programvara på Oracle Linux – Kapitel 1 Yum DNF

Minnes- och NUMA-konfigurationer kan testas och jämföras med ett användbart verktyg – Oracle Real Application Testing (RAT)

Oracle Real Application Testing: Vad är det och hur använder du det? (aemcorp.com)

Information om problem med skadade UDEV-loggar i Oracle Redolog på Azure | Oracle i fältet (wordpress.com)

Oracle ASM i Azure-korruption – uppföljning (dbaharrison.blogspot.com)

Skadade data i Hyper-V eller Azure när oracle ASM körs – Red Hat-kundportalen

Konfigurera Oracle ASM på en virtuell Azure Linux-dator – Azure Virtual Machines | Microsoft Docs

Riktlinjer för Oracle-konfiguration för SAP-installationer på virtuella Azure-datorer i Windows

SAP på Oracle i Azure har också stöd för Windows. Rekommendationerna för Windows-distributioner sammanfattas nedan:

  1. Följande Windows-versioner rekommenderas: Windows Server 2022 (endast från Oracle Database 19.13.0 på) Windows Server 2019 (endast från Oracle Database 19.5.0 på)
  2. Det finns inget stöd för ASM i Windows. Windows Lagringsutrymmen ska användas för att aggregera diskar för optimala prestanda
  3. Installera Oracle Home på en dedikerad oberoende disk (installera inte Oracle Home på C: Drive)
  4. Alla diskar måste formateras med NTFS
  5. Följ Windows Tuning-guiden från Oracle och aktivera stora sidor, låsa sidor i minnet och andra Windows-specifika inställningar

Vid den tidpunkten stöds inte att skriva ASM för Windows-kunder i Azure. SAP Software Provisioning Manager (SWPM) för Windows stöder för närvarande inte ASM.

Lagringskonfigurationer för SAP på Oracle i Windows

Minsta konfiguration av Windows:

Komponent Disk Värdcachen Striping1
E:\oracle\<SID>\origlogaA & mirrlogB Premium Ingen Krävs inte
F:\oracle\<SID>\origlogaB & mirrlogA Premium Ingen Krävs inte
G:\oracle\<SID>\sapdata1... N Premium Skrivskyddad2 Rekommenderat
H:\oracle\<SID>\oraarch3 Premium Ingen Krävs inte
I:\Oracle Home, saptrace, ... Premium Ingen Ingen
  1. Striping: Windows Lagringsutrymmen
  2. Under R3load-migreringar ska alternativet Värdcache för SAPDATA vara inställt på Ingen
  3. oraarch: Windows Lagringsutrymmen är valfritt

Diskvalet för att vara värd för Oracles onlineloggar drivs av IOPS-krav. Det går att lagra alla sapdata1... n (tabellutrymmen) på en enda monterad disk så länge volymen, IOPS och dataflödet uppfyller kraven.

Prestandakonfiguration Windows:

Komponent Disk Värdcachen Striping1
E:\oracle\<SID>\origlogaA Premium Ingen Kan användas
F:\oracle\<SID>\origlogaB Premium Ingen Kan användas
G:\oracle\<SID>\mirrlogAB Premium Ingen Kan användas
H:\oracle\<SID>\mirrlogBA Premium Ingen Kan användas
I:\oracle\<SID>\sapdata1... N Premium Skrivskyddad2 Rekommenderat
J:\oracle\<SID>\oraarch3 Premium Ingen Krävs inte
K:\Oracle Home, saptrace, ... Premium Ingen Ingen
  1. Striping: Windows Lagringsutrymmen
  2. Under R3load-migreringar ska alternativet Värdcache för SAPDATA vara inställt på Ingen
  3. oraarch: Windows Lagringsutrymmen är valfritt

Nästa steg

Läs artikeln