Utforma och implementera en Oracle-databas i Azure

Gäller för: ✔️ Virtuella Linux-datorer

Antaganden

• Du planerar att migrera en Oracle-databas från en lokal plats till Azure.
• Du har diagnostikpaketet eller lagringsplatsen för automatisk arbetsbelastning för Oracle Database som du vill migrera
• Du har en förståelse för de olika måtten i Oracle.
• Du har en grundläggande förståelse för programprestanda och plattformsanvändning.

Mål

• Förstå hur du optimerar oracle-distributionen i Azure.
• Utforska prestandajusteringsalternativ för en Oracle-databas i en Azure-miljö.
• Ha tydliga förväntningar mellan gränserna för fysisk justering via arkitektur och fördelar eller logisk justering av databaskod (SQL) och den övergripande databasdesignen.

Skillnaderna mellan en lokal implementering och Azure-implementering

Nedan följer några viktiga saker att tänka på när du migrerar lokala program till Azure.

En viktig skillnad är att i en Azure-implementering delas resurser som virtuella datorer, diskar och virtuella nätverk mellan andra klienter. Dessutom kan resurser begränsas baserat på kraven. I stället för att fokusera på att undvika haveri (MTBF) fokuserar Azure mer på att överleva felet (MTTR).

I följande tabell visas några av skillnaderna mellan en lokal implementering och en Azure-implementering av en Oracle-databas.

Krav

• Fastställ den verkliga CPU-användningen eftersom Oracle licensieras av kärna. Storleksändring av vCPU-behoven kan vara en viktig övning för kostnadsbesparingar.
• Fastställ databasens storlek, lagring av säkerhetskopior och ökningstakt.
• Fastställ I/O-kraven, som du kan beräkna baserat på Oracle Statspack- och AWR-rapporter eller lagringsövervakningsverktyg på OPERATIVSYSTEMnivå.

Konfigurationsalternativ

Det finns fyra potentiella områden som du kan finjustera för att förbättra prestanda i en Azure-miljö:

• Storlek för virtuell dator
• Nätverksgenomflöde
• Disktyper och konfigurationer
• Inställningar för diskcachelagring

Generera en AWR-rapport

Om du har en befintlig Oracle Enterprise Edition databas och planerar att migrera till Azure har du flera alternativ. Om du har diagnostikpaketet för dina Oracle-instanser kan du köra Oracle AWR-rapporten för att hämta måtten (IOPS, Mbit/s, GiBs och så vidare). För dessa databaser utan Diagnostics Pack-licensen eller för en Standard Edition-databas kan samma viktiga mått samlas in med en Statspack-rapport när manuella ögonblicksbilder har samlats in. Den största skillnaden mellan dessa två rapporteringsmetoder är att AWR samlas in automatiskt och ger mer information om databasen än det föregående rapporteringsalternativet i Statspack.

Du kan överväga att köra AWR-rapporten under både vanliga och högsta arbetsbelastningar, så att du kan jämföra. För att samla in den mer exakta arbetsbelastningen kan du överväga en utökad fönsterrapport på en vecka jämfört med en körning på 24 timmar och inser att AWR tillhandahåller medelvärden som en del av dess beräkningar i rapporten. För en datacentermigrering rekommenderar vi att du samlar in rapporter för storleksändring i produktionssystemen och beräknar återstående databaskopior som används för användartestning, testning, utveckling osv. efter procentandelar (UAT lika med produktion, test och utveckling 50 % av produktionsändringen osv.)

Som standard behåller AWR-lagringsplatsen 8 dagars data och tar ögonblicksbilder med timintervall. Om du vill köra en AWR-rapport från kommandoraden kan följande utföras från en terminal:

$ sqlplus / as sysdba
SQL> @$ORACLE_HOME/rdbms/admin/awrrpt.sql;

Viktiga mått

Rapporten uppmanar dig att ange följande information:

• Rapporttyp: HTML eller TEXT(HTML i 12.1 och ger ytterligare information än TEXT-formatet.)
• Antalet dagar med ögonblicksbilder som ska visas (för en timmes intervall skulle en veckas rapport vara 168 olika i ögonblicksbild-ID:n)
• Det första SnapshotID för rapportfönstret.
• Slut-SnapshotId för rapportfönstret.
• Namnet på rapporten som ska skapas av AWR-skriptet.

Om du kör AWR på ett verkligt programkluster (RAC) är kommandoradsrapporten awrgrpt.sql i stället för awrrpt.sql. "g"-rapporten skapar en rapport för alla noder i RAC-databasen i en enda rapport jämfört med om du behöver köra en på varje RAC-nod.

Följande är de mått som du kan hämta från AWR-rapporten:

• Databasnamn, instansnamn och värdnamn
• Databasversion, (support från Oracle)
• CPU/kärnor
• SGA/PGA, (och rådgivare för att meddela dig om för stor)
• Totalt minne i GB
• CPU % upptagen
• DB-processorer
• IOPs (läsa/skriva)
• MBPs (läsa/skriva)
• Nätverksgenomflöde
• Nätverksfördröjningshastighet (låg/hög)
• De viktigaste väntehändelserna
• Parameterinställningar för databas
• Är databas-RAC, Exadata, som använder avancerade funktioner eller konfigurationer

Storlek för virtuell dator

1. Beräkna vm-storlek baserat på CPU, minne och I/O-användning från AWR-rapporten

En sak du kan titta på är de fem främsta händelser i förgrunden som visar var systemets flaskhalsar finns.

I följande diagram visas till exempel loggfilsynkronisering längst upp. Den anger antalet väntetider som krävs innan LGWR skriver loggbufferten till redo-loggfilen. Dessa resultat visar att det krävs bättre prestanda för lagring eller diskar. Dessutom visar diagrammet även antalet cpu (kärnor) och mängden minne.

Följande diagram visar den totala I/O för läsning och skrivning. 59 GB läsning och 247,3 GB skrevs under rapportens tid.

2. Välj en virtuell dator

Baserat på den information som du har samlat in från AWR-rapporten är nästa steg att välja en virtuell dator med en liknande storlek som uppfyller dina krav. Du hittar en lista över tillgängliga virtuella datorer i artikeln Minnesoptimerad.

3. Finjustera VM-storleksändringen med en liknande VM-serie baserat på ACU

När du har valt den virtuella datorn bör du vara uppmärksam på den virtuella datorns ACU. Du kan välja en annan virtuell dator baserat på det ACU-värde som passar dina behov bättre. Mer information finns i Azure-beräkningsenhet.

Nätverksgenomflöde

Följande diagram visar relationen mellan dataflöde och IOPS:

Det totala nätverkets dataflöde beräknas baserat på följande information:

• SQL*Nettotrafik
• MBps x antal servrar (utgående dataström som Oracle Data Guard)
• Andra faktorer, till exempel programreplikering

Baserat på kraven på nätverksbandbredd finns det olika gatewaytyper att välja mellan. Dessa omfattar grundläggande, VpnGw och Azure ExpressRoute. Mer information finns på prissättningssidan för VPN Gateway.

Rekommendationer

• Nätverksfördröjningen är högre jämfört med en lokal distribution. Att minska nätverkets tur och retur-resor kan avsevärt förbättra prestandan.
• Du kan minska tur och retur-resor genom att konsolidera program som har stora transaktioner eller "trafikknackade" appar på samma virtuella dator.
• Använd Virtual Machines accelererat nätverk för bättre nätverksprestanda.
• Överväg att aktivera TRIM/UNMAP-stöd för vissa Linux-distributioner.
• Installera Oracle Enterprise Manager på en separat virtuell dator.
• Stora sidor är inte aktiverade på Linux som standard. Överväg att aktivera enorma sidor och konfigurera use_large_pages = ONLY på Oracle DB. Detta kan öka prestandan. Mer information finns i USE_LARGE_PAGES.

Disktyper och konfigurationer

• Standardoperativsystemdiskar: Dessa disktyper erbjuder beständiga data och cachelagring. De är optimerade för OS-åtkomst vid start och är inte utformade för antingen transaktions- eller informationslagerarbetsbelastningar (analytiska).

• Hanterade diskar: Azure hanterar de lagringskonton som du använder för dina virtuella datordiskar. Du anger disktypen (oftast Premium SSD för Oracle-arbetsbelastningar) och storleken på den disk som du behöver. Azure skapar och hanterar disken åt dig. Premium SSD-hanterad disk är endast tillgänglig för minnesoptimerade och särskilt utformade VM-serier. När du har valt en viss VM-storlek visar menyn endast tillgängliga premiumlagrings-SKU:er som baseras på vm-storleken.

När du har konfigurerat lagringen på en virtuell dator kanske du vill belastningstesta diskarna innan du skapar en databas. Att känna till I/O-frekvensen vad gäller både svarstid och dataflöde kan hjälpa dig att avgöra om de virtuella datorerna stöder det förväntade dataflödet med svarstidsmål.

Det finns ett antal verktyg för belastningstestning av program, till exempel Oracle Orion, Sysbench, SLOB och Fio.

Kör belastningstestet igen när du har distribuerat en Oracle-databas. Starta dina vanliga och högsta arbetsbelastningar så visar resultatet baslinjen för din miljö. Var realistisk i arbetsbelastningstestet – det är inte meningsfullt att köra en arbetsbelastning som inte fungerar som du kommer att köra på den virtuella datorn i verkligheten.

Eftersom Oracle är en I/O-intensiv databas för många är det mycket viktigt att ändra lagringsstorleken baserat på IOPS-hastigheten i stället för lagringsstorleken. Om den IOPS som krävs till exempel är 5 000, men du bara behöver 200 GB, kan du fortfarande få premiumdisken i P30-klassen även om den levereras med mer än 200 GB lagringsutrymme.

IOPS-frekvensen kan hämtas från AWR-rapporten. Det bestäms av frekvensen för att göra om loggen, fysiska läsningar och skrivningar. Kontrollera alltid att den valda VM-serien har möjlighet att hantera arbetsbelastningens I/O-efterfrågan. Om den virtuella datorn har en lägre I/O-gräns än lagringen anges maxgränsen av den virtuella datorn.

Gör om-storleken är till exempel 12 200 000 byte per sekund, vilket är lika med 11,63 MB/s. IOPS är 12 200 000/2 358 = 5 174.

När du har en tydlig bild av I/O-kraven kan du välja en kombination av enheter som passar bäst för att uppfylla dessa krav.

Rekommendationer

• För datatabeller sprider du I/O-arbetsbelastningen över ett antal diskar med hjälp av hanterad lagring eller Oracle ASM.
• Använd Oracle avancerad komprimering för att minska I/O (för både data och index).
• Separata redo-loggar, Temp och Undo tablespaces på separata datadiskar.
• Placera inte några programfiler på standardoperativsystemdiskar (/dev/sda). De här diskarna är inte optimerade för snabba starttider för virtuella datorer och de kanske inte ger bra prestanda för ditt program.
• När du använder virtuella datorer i M-serien Premium lagring, aktivera Skrivningsaccelerator på disk med loggar om.
• Överväg att flytta gör om-loggar med hög fördröjning till ultradisk.

Inställningar för diskcachelagring

Det finns tre alternativ för värdcachelagring, men för en Oracle-databas rekommenderas endast Skrivskyddad cachelagring för en databasarbetsbelastning. ReadWrite kan leda till betydande säkerhetsrisker i en datafil, där målet med en databasskrivning är att registrera den till datafilen, inte cachelagra informationen.

Till skillnad från ett filsystem eller program är rekommendationen för värdcachelagring skrivskyddad för en databas: Alla begäranden cachelagras för framtida läsningar. Alla skrivningar fortsätter att skrivas till disken.

Rekommendationer

För att maximera dataflödet rekommenderar vi att du börjar med ReadOnly för värdcachelagring när det är möjligt. Tänk Premium Storage att du måste inaktivera "barriärer" när du monterar filsystemet med alternativen Skrivskyddade. Uppdatera /etc/fstab filen med UUID till diskarna.

• För OS-diskar använder du Premium SSD med cachelagring av läs-/skrivvärdar.
• För Datadiskar som innehåller Oracle-datafiler, tempfiles, controlfiles, block change tracking files, BFILEs, files for external tables och flashback logs använder du Premium SSD med ReadOnly-värdcachelagring.
• För datadiskar som innehåller Oracle online gör om loggfiler använder du Premium SSD eller UltraDisk utan värdcachelagring (Ingen). Oracle-arkiverade redo-loggfiler och RMAN-säkerhetskopieringar kan också finnas med onlinereparenderingsloggfilerna. Observera att värdcachelagring är begränsad till 4 095 GiB, så allokera inte premium SSD som är större än P50 med värdcachelagring. Om du behöver mer än 4 TiB lagringsutrymme kan RAID-0 strimla flera Premium SSD med Linux LVM2 eller använda Oracle ASM.

Om arbetsbelastningarna varierar avsevärt mellan dagen och kvällen och I//arbetsbelastningen kan stödja det kan P1–P20 Premium SSD med burst-bearbetning ge den prestanda som krävs under batchbelastningar under natten eller begränsade I/O-krav.

Säkerhet

När du har konfigurerat din Azure-miljö är nästa steg att skydda nätverket. Här är några rekommendationer:

• NSG-princip: NSG kan definieras av ett undernät eller ett nätverkskort. Det är enklare att kontrollera åtkomsten på undernätsnivå, både för säkerhet och tvinga routning för exempelvis programbrandväggen.

• Jumpbox: Administratörer bör inte ansluta direkt till programtjänsten eller databasen för säkrare åtkomst. En jumpbox används som ett medium mellan administratörsdatorn och Azure-resurser.

  Administratörsdatorn bör endast erbjuda IP-begränsad åtkomst till jumpboxen. Jumpboxen ska ha åtkomst till programmet och databasen.

• Privat nätverk (undernät): Vi rekommenderar att du har programtjänsten och databasen i separata undernät, så att bättre kontroll kan anges av NSG-principen.

Mer att läsa

• Konfigurera Oracle ASM
• Konfigurera Oracle Data Guard
• Konfigurera Oracle Golden Gate
• Säkerhetskopiering och återställning av Oracle

Nästa steg

• Självstudie: Skapa virtuella datorer med hög tillgänglig
• Utforska Azure CLI-exempel för distribution av virtuella datorer