Dela via


Migrera Oracle-arbetsbelastningar till Azure

Som en del av molnimplementeringsresan måste du migrera dina befintliga arbetsbelastningar till molnet. Oracle-arbetsbelastningar liknar andra arbetsbelastningar och kräver en metodisk metod för att säkerställa en lyckad migrering. Mer information om migreringsmetod finns i Molnmigrering i Cloud Adoption Framework. Den här artikeln beskriver unika begränsningar och överväganden som är specifika för Oracle-arbetsbelastningar.

Oracle-migreringsprocessen

Du bör kontinuerligt omvärdera dina infrastrukturkrav för att förbättra prestanda och minska kostnaderna med hjälp av relevant typ av tjänst för din arbetsbelastning. Om du till exempel planerar att flytta din arbetsbelastning till Oracle Database@Azure kontrollerar du att den SKU som du väljer uppfyller dina krav. Om du flyttar arbetsbelastningen till Oracle på virtuella Azure-datorer ser du på samma sätt till att storleken på den virtuella datorn uppfyller dina krav. Mer information finns i Kapacitetsplanering för migrering av Oracle-arbetsbelastningar till Azure-landningszoner.

Granska migreringsresurserna för att definiera din Oracle-till Azure-migreringsprocess. Du kan även:

  • Verifiera kvotgränser för Azure-prenumeration: Kontrollera att kvotgränserna i din Azure-prenumeration passar de vm-målstorlekar som du väljer om du migrerar till Oracle på virtuella Azure-datorer.

  • Identifiera en distributionsmodell: Automatisera distributionen av lösningskomponenter så mycket som möjligt med hjälp av infrastruktur som kod (IaaS), CI/CD-pipelines (kontinuerlig integrering och kontinuerlig leverans) och andra DevOps-metoder.

  • Fastställa programberoenden: Se till att migreringsaktiviteterna är minimalt störande.

  • Identifiera datakapacitet: Identifiera mängden data som ska migreras och utvärdera den aktuella tillgängliga nätverksanslutningskapaciteten från lokala miljöer till Azure. Använd den här informationen för att avgöra om du kan kopiera data direkt från lokala miljöer till Azure. Du kan behöva en fysisk dataöverföringsenhet som Azure Data Box för den första datainläsningen.

  • Fastställ tillgänglighetskrav: Fastställa tillgänglighetskraven för arbetsbelastningen eftersom de kan påverka de migreringsverktyg som du kan använda.

För Oracle Database@Azure ser du till att:

  • Kontrollera att Oracle Database@Azure-lösningen är tillgänglig i den region där du vill distribuera lösningen. Mer information finns i Tillgängliga regioner.

  • Överväg att använda Oracle Zero Downtime Migration för migreringsprocessen. Utvärdera migreringsstrategierna för att fastställa den lämpligaste metoden för dina specifika migreringskrav. Mer information finns i Noll stilleståndstidsmigrering.

Arbetsbelastningsspecifika aktiviteter för Oracle-migrering

I följande avsnitt beskrivs migreringsprocessen mer detaljerat. Stegen är inte nödvändigtvis sekventiella. Du kan utföra vissa steg parallellt.

  • Utvärdera käll- och målsystemversionerna: Utvärdera om de lokala operativsystemversionerna, programversionerna och databasversionerna är desamma som de versioner som du planerar att använda i Azure.

    • Om du behöver uppdatera en eller flera resurser uppdaterar du dem före migreringen för att undvika att komplicera migreringsprocessen.

    • Om din lokala databas körs på ett storslutsoperativt operativsystem, till exempel Oracle Solaris, IBM Advanced Interactive eXecutive eller Hewlett Packard Unix, innehåller databasmigreringsprocessen en endiansk konvertering. Azure Support endast små endianska operativsystem. Den här begränsningen minskar antalet tillgängliga verktyg för migreringen. Mer specifikt kan du inte använda Oracle Data Guard eller någon annan filkopieringsmetod. Migreringsmetoder som är kompatibla med endiansk konvertering inkluderar Oracle Data Pump Export eller Import, Oracle cross-platform transportable tablespaces (XTTS) eller datareplikeringsverktyg som Oracle GoldenGate, Quest SharePlex och Striim.

    • Du kan modernisera eller migrera lokala programservrar beroende på krav och kompatibilitet. Mer information finns i Scenarier för molnimplementering.

  • Utvärdera kraven på arbetsbelastningstillgänglighet under migreringsprocessen: Om du behöver minimera arbetsbelastningens stilleståndstid kanske migreringsmetoder som Data Pump Export eller Import inte passar din arbetsbelastning. I så fall kan du följa den här fyrastegsprocessen:

    • Använd Oracle Recovery Manager (RMAN) för att säkerhetskopiera och sedan återställa hela databasen i Azure. Utför en endiansk konvertering via XTTS om det behövs. Resultatet är en databas som är en tidpunktskopia av den lokala källdatabasen. Mer information finns i Transportera data mellan plattformar.

    • Använd Oracle Data Guard för att synkronisera den nyligen återställda databasen i Azure med källdatabasen om båda källorna är lite endianskt format. Du kan inte använda Data Guard om migreringen omfattar storslutskonvertering till liten slutpunktskonvertering. Använd i stället ett SQL-baserat datareplikeringsverktyg som Oracle GoldenGate, Quest SharePlex eller Striim för att synkronisera den nyligen återställde databasen i Azure med källdatabasen.

    • När du har synkroniserat måldatabasen i Azure med den lokala källdatabasen kan du schemalägga en snabb uppdatering. En snabb information stänger av den lokala källdatabasen och rensar de senaste transaktionerna till måldatabasen i Azure. Sedan kan du öppna måldatabasen i Azure som den nya källdatabasen. En snabb användning kan ta så lite som några minuter, beroende på vilken synkroniseringsmetod du använder.

    • Beroende på vilken migreringsmetod du väljer för programtjänster kan du behöva utföra flera programtjänstuppgifter innan du helt migrerar programmet till Azure.

  • Utvärdera nödvändiga licenser: Databasen kan kräva olika licenser beroende på migreringsverktyget. Till exempel:

    • Oracle Data Guard kräver Oracle Database Enterprise Edition.

    • Oracle GoldenGate kräver Oracle GoldenGate-licenser.

    Mer information om Oracle-licensiering i Azure finns i Licensiering av Oracle-programvara i molnbaserad databehandlingsmiljö.

Nästa steg