Da AWS Exadata a strumenti di migrazione - AWS Guida prescrittiva

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Da AWS Exadata a strumenti di migrazione

Esistono più di 15 approcci Exadata alla migrazione. AWS La tabella seguente mostra gli strumenti più comunemente usati. La tabella non include Oracle Conventional Export/Import, Oracle SQL*Loader, Oracle SQL Developer Database Copy, Oracle SQL*Developer Export/Import Wizard, Oracle Transportable Tablespaces, Oracle database links che utilizzano Create Table as Select (CTAS), tabelle esterne Oracle o soluzioni di estrazione, trasformazione e caricamento (ETL).

Approccio alla migrazione

Supporta la strategia di migrazione

Fisico o logico

Supporta l'acquisizione dei dati di modifica (CDC)

Richiede una rete per AWS

AWS DMS

Tutti

Logica

Oracle GoldenGate

Tutti

Logica

Pompa dati Oracle

Rehost, ripiattaforma

Logica

No

No

Oracle Recovery Manager (RMAN)

Riospitare

Fisica

No

Se utilizzi RMAN DUPLICATE o Oracle Secure Backup su Amazon S3

Oracle Data Guard

Riospitare

Fisica

Oracle Data Guard e Oracle Recovery Manager (RMAN) sono opzioni eccellenti per la migrazione di un database Exadata su Amazon EC2. Tuttavia, Amazon RDS for Oracle non supporta nessuno di questi strumenti.

È possibile implementare Oracle Data Guard utilizzando il metodo di standby logico o di standby fisico. Un database di standby logico applica istruzioni DML (Data Manipulation Language) sul database di standby per mantenere i dati sincronizzati. I database in standby logico vengono in genere utilizzati per scaricare i report dal database principale. Tutti i riferimenti a Oracle Data Guard in questa sezione si applicano direttamente allo standby fisico. Un database fisico in standby corrisponde esattamente al database primario a livello di blocco.

AWS DMS migrazioni

AWS Database Migration Service (AWS DMS) è una soluzione di replica logica. Supporta migrazioni omogenee come la migrazione di un database Oracle locale a un database Oracle su AWS, nonché migrazioni eterogenee tra diverse piattaforme di database, ad esempio da Oracle a Microsoft SQL Server e da Oracle ad Amazon Aurora PostgreSQL Compatible Edition. AWS DMS supporta un'ampia gamma di fonti e destinazioni. AWS DMS Gli obiettivi supportati includono Amazon Simple Storage Service (Amazon S3), AmazonDynamoDB, Amazon Redshift, Amazon KinesisData Streams, Amazon DocumentDB e Redis.

Puoi utilizzarlo AWS DMS per migrare i tuoi carichi di lavoro Exadata su Amazon RDS for Oracle o su un database Oracle su Amazon EC2. AWS DMS gestisce il caricamento iniziale e gli aggiornamenti CDC (Change Data Capture) da Exadata. Exadata è pienamente operativo durante il processo di migrazione. Se si utilizza CDC, il database di destinazione rimane continuamente sincronizzato con Exadata, in modo che il cutover dell'applicazione possa avvenire in un momento opportuno.

Gli strumenti Oracle nativi come Oracle RMAN, Oracle Data Guard e Oracle Data Pump sono più flessibili e possono caricare i dati più velocemente di. AWS DMS Se stai migrando database Exadata di grandi dimensioni (multi-TIB), ti consigliamo di scegliere queste utilità Oracle native anziché per il caricamento iniziale dei AWS DMS dati.

Oracle Data Pump supporta più processi di lavoro in grado di eseguire il parallelismo tra tabelle e partizioni per caricare e scaricare tabelle in flussi multipli, paralleli o a percorso diretto. Tutte le elaborazioni di importazione ed esportazione in Data Pump, inclusa la lettura e la scrittura di file di dump, sono gestite dal server e non coinvolgono il client. Il formato di archiviazione dei file dump Data Pump è il formato di flusso interno dell'API Direct Path. Questo formato è molto simile al formato memorizzato nei file di dati di Oracle Database all'interno dei tablespace. Pertanto, Data Pump non deve eseguire la conversione lato client in variabili di associazione delle istruzioni. INSERT Inoltre, Data Pump supporta metodi di accesso ai dati, percorsi diretti e tabelle esterne, che sono più veloci del linguaggio SQL convenzionale. L'API Direct Path offre le prestazioni a flusso singolo più veloci. La funzionalità di tabelle esterne fa un uso efficiente delle query parallele e delle funzionalità DML parallele di Oracle Database. Se la migrazione da Exadata ad Amazon RDS for Oracle richiede tempi di inattività ridotti, un approccio comune alla migrazione da Exadata consiste nell'utilizzare Data Pump per il caricamento iniziale e quindi utilizzare o Oracle per CDC. AWS DMS GoldenGate

Esistono delle limitazioni quando si utilizza Exadata come fonte per. AWS DMSPer ulteriori informazioni su questi aspetti, consulta la AWS DMS documentazione. Inoltre, è necessaria la connettività di rete all'origine (Exadata on premise) e alla destinazione (Oracle database on AWS). AWS DMS

Se lo utilizzi AWS DMS per il caricamento iniziale, prendi in considerazione le seguenti best practice:

  • In genere è possibile migliorare le prestazioni selezionando un'istanza di AWS DMS replica di grandi dimensioni. Il caricamento delle tabelle di grandi dimensioni richiede più tempo e le transazioni su tali tabelle devono essere memorizzate nella cache fino al caricamento della tabella. Dopo che una tabella è stata caricata, queste transazioni memorizzate nella cache vengono applicate e non sono più mantenute sul disco. Ad esempio, se il carico richiede cinque ore e produce 6 GiB di transazioni ogni ora, assicurati che vengano allocati 30 GiB di spazio su disco per le transazioni memorizzate nella cache. Una volta completato il caricamento iniziale, prima di avviare CDC, è possibile modificare l'istanza di AWS DMS replica per utilizzare un'istanza più piccola.

  • Per migrazioni Exadata di grandi dimensioni (multi-TIB), si consiglia di utilizzare AWS DMS Binary Reader anziché Oracle LogMiner (che è l'impostazione predefinita). Binary Reader ha un rischio inferiore di impatto sull'I/O o sulla CPU perché i log vengono estratti direttamente anziché richiedere più query sul database. Tuttavia, Oracle LogMiner è migliore quando si ha un volume elevato di modifiche e si utilizza Oracle ASM. Per utilizzare Binary Reader per accedere ai redo log, aggiungi i seguenti attributi di connessione aggiuntivi per l'endpoint di origine:

    useLogMinerReader=N;useBfile=Y

    Per un confronto completo, consulta Using Oracle LogMiner o AWS DMS Binary Reader for CDC nella documentazione. AWS DMS

  • Disattiva i backup di Amazon RDS for Oracle o modifica la modalità di archiviazione in caso di migrazione NOARCHIVELOG a Oracle su Amazon EC2. Abilita i backup prima della fase CDC o dopo il caricamento iniziale dei dati.

  • Disattiva tutti i database in standby. AWS Ciò include Amazon RDS for Oracle Multi-AZ e repliche di lettura. Include anche gli standby di Oracle Data Guard o Oracle Active Data Guard se stai migrando a Oracle su Amazon EC2.

  • Elimina gli indici a chiave primaria, gli indici secondari, i vincoli di integrità referenziale e i trigger del linguaggio di manipolazione dei dati (DML) prima dei caricamenti iniziali sul database di destinazione. Abilita questi oggetti prima di iniziare la fase CDC.

  • Per tabelle di grandi dimensioni, puoi suddividere una singola tabella in più AWS DMS attività utilizzando il filtro di riga, una chiave o una chiave di partizione. Ad esempio, se il database ha un ID di chiave primaria intero compreso tra 1 e 8.000.000, crea otto attività utilizzando il filtro di riga per migrare un milione di record per ogni attività. AWS DMS Puoi utilizzare questa tecnica anche con una colonna di date.

  • Suddividi la AWS DMS migrazione in più AWS DMS attività. La coerenza transazionale viene mantenuta all'interno di un'attività, quindi le tabelle in attività separate non devono far parte di transazioni comuni.

  • Per impostazione predefinita, AWS DMS carica otto tabelle alla volta. Per migliorare le prestazioni, è possibile aumentare questo valore se si utilizza un server di replica di grandi dimensioni.

  • Per impostazione predefinita, AWS DMS elabora le modifiche in modalità transazionale, che preserva l'integrità delle transazioni. Il passaggio all'opzione di applicazione ottimizzata in batch può migliorare le prestazioni. Ti consigliamo di disattivare questi vincoli durante il caricamento iniziale e di riattivarli per il processo CDC.

  • Se l'istanza di AWS DMS replica e il database Oracle su AWS cui si trovano si trovano su cloud privati virtuali (VPC) diversi, si consiglia di utilizzare il peering VPC.

  • Abilita CloudWatch i log di Amazon quando crei o modifichi le attività di AWS DMS migrazione. Questo parametro è disponibile nella sezione Impostazioni attività quando crei un' AWS DMS attività. L'attivazione di questo parametro consente di acquisire informazioni quali lo stato dell'attività, la percentuale di completamento, il tempo trascorso e le statistiche delle tabelle durante il processo di migrazione. Per ulteriori informazioni, consulta Monitoraggio delle attività di replica con Amazon CloudWatch nella AWS DMS documentazione.

Per ulteriori best practice, consulta Usare un database Oracle come fonte AWS DMS e Best practice AWS Database Migration Service nella AWS DMS documentazione.

GoldenGate Migrazioni Oracle

Oracle GoldenGate è una soluzione di replica logica. È possibile utilizzare questo strumento per replicare, filtrare e trasformare i dati da un database all'altro. È possibile spostare le transazioni impegnate su più sistemi eterogenei e replicare i dati dai database Oracle ad altri database omogenei e database eterogenei supportati. Oracle GoldenGate condivide molte delle caratteristiche e dei limiti positivi di. AWS DMS

Entrambi gli strumenti forniscono la replica logica. Tuttavia, AWS DMS è un servizio gestito che non richiede installazione e configurazione, mentre Oracle GoldenGate deve essere installato e configurato. È possibile configurarlo in locale o in locale AWS. Puoi installare Oracle GoldenGate su AWS utilizzando una configurazione ad alta disponibilità per migrare i dati da Exadata a. AWS Non installare Oracle GoldenGate direttamente su Exadata in locale o su un nodo di database Oracle su Amazon EC2; i nodi del database devono essere dedicati all'elaborazione dei carichi di lavoro del database.

Un'altra importante differenza tra Oracle AWS DMS e Oracle è il prezzo. GoldenGate AWS DMS costi per l'utilizzo delle istanze di replica e l'archiviazione dei log. Tutti i trasferimenti di dati AWS DMS sono gratuiti, così come i dati trasferiti tra AWS DMS database su Amazon RDS e istanze Amazon EC2 nella stessa zona di disponibilità sono gratuiti. Oracle GoldenGate richiede una GoldenGate licenza Oracle per ogni core dei database di origine e di destinazione. Puoi utilizzare Oracle GoldenGate per migrare i carichi di lavoro Exadata su Amazon RDS for Oracle o Oracle su Amazon EC2, sia per il caricamento iniziale che per eseguire CDC da Exadata. Questo processo consente a Exadata di essere pienamente operativa durante il processo di migrazione.

Per migrare database Exadata di grandi dimensioni (multi-TIB) su Oracle su Amazon EC2, prendi in considerazione l'utilizzo di Oracle RMAN, Oracle Data Guard o Oracle Data Pump anziché Oracle per i seguenti motivi: GoldenGate

  • Oracle richiede GoldenGate la connettività di rete tra Exadata e. AWS

  • Oracle GoldenGate non offre le stesse prestazioni di altri strumenti di migrazione Oracle per il caricamento iniziale dei dati. Ad esempio, per migrare database Exadata di grandi dimensioni su Amazon RDS for Oracle, prendi in considerazione l'utilizzo di Oracle Data Pump, perché è più flessibile e può caricare i dati più velocemente di Oracle. GoldenGate

Se la migrazione da Exadata ad Amazon RDS for Oracle richiede tempi di inattività ridotti, un approccio di migrazione comune consiste nell'utilizzare Oracle Data Pump per il carico iniziale e Oracle o per CDC. GoldenGate AWS DMS Il vantaggio di Oracle GoldenGate è che è in grado di gestire il carico iniziale così come il CDC. CDC consente al database di destinazione di rimanere continuamente sincronizzato con Exadata, in modo da poter passare alla versione in un momento opportuno.

Esistono delle limitazioni quando si utilizza Exadata come fonte con Oracle. GoldenGate Per informazioni al riguardo, consulta Comprendere le funzionalità supportate nella GoldenGate documentazione.

Se utilizzi Oracle GoldenGate per il caricamento iniziale, prendi in considerazione le seguenti best practice:

  • Utilizza Extract in modalità di acquisizione integrata per sfruttare l'integrazione con il LogMiner server. L'acquisizione integrata consente l'estrazione senza interruzioni di più tipi di dati rispetto a Extract in modalità classica. Questi tipi di dati aggiuntivi includono dati compressi, tra cui Basic Compression, Online Transaction Processing (OLTP) e Exadata Hybrid Columnar Compression (HCC). Non è richiesta alcuna configurazione aggiuntiva per consentire a Extract di leggere i file di registro archiviati su Oracle ASM.

  • Utilizzare Integrated Replicat. Questa opzione utilizza il processo di applicazione del database. Mantiene l'integrità referenziale e applica automaticamente le operazioni DDL. Integrated Replicat offre anche il parallelismo automatico, che aumenta o diminuisce automaticamente in base al carico di lavoro corrente e alle prestazioni del database.

  • Impostato BATCHSQL nel file dei parametri Replicat. Per impostazione predefinita, Integrated Replicat tenta di riordinare e raggruppare le istruzioni DML dello stesso tipo sullo stesso oggetto all'interno di ogni transazione. L'utilizzo dei batch può ridurre la CPU e il tempo di esecuzione delle istruzioni DML.

  • Configura la tabella GoldenGate heartbeat per fornire visualizzazioni dei ritardi di end-to-end replica. Ciò consente di visualizzare la latenza di end-to-end replica visualizzando la vista del database. GG_LAG

  • Disattiva i backup di Amazon RDS for Oracle o modifica la modalità di archiviazione se utilizzi NOARCHIVELOG Oracle su Amazon EC2. Abilita i backup prima della fase CDC o dopo il caricamento iniziale dei dati.

  • Disattiva tutti i database in standby su AWS. Ciò include Amazon RDS for Oracle Multi-AZ e repliche di lettura. Include anche gli standby di Oracle Data Guard o Oracle Active Data Guard se stai migrando a Oracle su Amazon EC2.

  • Elimina gli indici a chiave primaria, gli indici secondari, i vincoli di integrità referenziale e i trigger del linguaggio di manipolazione dei dati (DML) prima dei caricamenti iniziali sul database di destinazione. Abilita questi oggetti prima di iniziare la fase CDC.

  • Se l'istanza di GoldenGate replica Oracle e il database Oracle su AWS si trovano in cloud privati virtuali (VPC) diversi, si consiglia di utilizzare il peering VPC.

Migrazioni di Oracle Data Pump

È possibile utilizzare Oracle Data Pump per spostare i dati da un database Oracle a un altro. Data Pump offre un'ampia gamma di vantaggi, come il supporto delle versioni precedenti di Oracle Database (fino alla versione 10.1) e il supporto di piattaforme con formati, architetture di database e versioni diversi. È possibile scegliere di esportare il database completo o solo schemi, tablespace o tabelle specifici.

È possibile controllare il grado di parallelismo, compressione e crittografia e specificare quali oggetti e tipi di oggetti includere o escludere. Data Pump supporta anche la modalità di rete, in cui è possibile trasferire i dati utilizzando un collegamento al database senza la necessità di archiviazione intermedia.

L'API Data Pump offre un modo rapido e affidabile per spostare dati e metadati tra database Oracle. Le utilità Data Pump Export e Data Pump Import si basano sull'API Data Pump. Non è possibile accedere a un'istanza Amazon RDS for Oracle tramite il protocollo Secure Shell (SSH), quindi l'API Data Pump è l'unico modo per importare dati se utilizzi Data Pump per migrare da Exadata ad Amazon RDS for Oracle. La Data Pump Command Line Interface (CLI) non è un'opzione per la migrazione ad Amazon RDS for Oracle.

Se utilizzi Data Pump per il carico iniziale, prendi in considerazione le seguenti best practice:

  • Prima di importare i dati, crea gli spazi di tabella necessari.

  • Se desideri importare dati in un account utente che non esiste, crea l'account utente e concedi le autorizzazioni e i ruoli necessari.

  • Se stai migrando a Oracle su Amazon EC2, disattiva i backup di Amazon RDS for Oracle o modifica la modalità di archiviazione in. NOARCHIVELOG Attiva i backup prima di iniziare la fase CDC o dopo il caricamento iniziale dei dati.

  • Disattiva tutti i database in standby. AWS Ciò include Amazon RDS for Oracle Multi-AZ e repliche di lettura. Include anche gli standby di Oracle Data Guard o Oracle Active Data Guard se stai migrando a Oracle su Amazon EC2.

  • Elimina gli indici delle chiavi primarie, gli indici secondari, i vincoli di integrità referenziale e i trigger DML prima dei caricamenti iniziali sul database di destinazione. Attiva questi oggetti prima di iniziare la fase CDC.

  • Per importare schemi e oggetti specifici, esegui importazioni in modalità schema o tabella.

  • Limita gli schemi importati a quelli richiesti dall'applicazione.

  • Carica e scarica i dati in parallelo utilizzando la compressione e più thread.

  • I file in Amazon S3 devono pesare 5 TiB o meno. Utilizza l'PARALLELopzione per creare più file di dump Data Pump per evitare questa limitazione.

  • Se hai intenzione di eseguire il CDC dopo l'esportazione di Data Pump, utilizza il codice SCN (System Change Number) di Oracle con Data Pump.

  • Se desideri caricare dati su Amazon RDS for Oracle, esegui queste attività:

    1. Crea una policy AWS Identity and Access Management (IAM) per consentire ad Amazon RDS l'accesso a un bucket S3.

    2. Crea un ruolo IAM e allega la policy.

    3. Associa il ruolo IAM all'istanza Amazon RDS for Oracle.

    4. Configura un gruppo di opzioni Amazon RDS for Oracle per l'integrazione con Amazon S3 e aggiungilo all'istanza Amazon RDS for Oracle.

    Per ulteriori informazioni, consulta l'integrazione con Amazon S3 nella documentazione di Amazon RDS.

Migrazioni Oracle RMAN

Oracle Recovery Manager (RMAN) è uno strumento per il backup e il ripristino di un database Oracle. Viene anche utilizzato per facilitare le migrazioni dei database in locale e tra database locali e cloud.

Oracle RMAN offre un approccio di migrazione fisica. Per questo motivo, supporta il rehosting (migrazione ad Amazon EC2) ma non può essere utilizzato per ripiattaforma del database Oracle su Amazon RDS for Oracle. La tolleranza ai tempi di inattività della migrazione deve essere sufficientemente ampia da consentire il backup e il ripristino di un backup incrementale Oracle RMAN.

Migrazione ad Amazon S3

Per eseguire il backup del database Exadata su Amazon S3, puoi utilizzare le seguenti opzioni:

  • Usa il modulo cloud Oracle Secure Backup (OSB) per eseguire il backup del tuo database Exadata direttamente su Amazon S3.

  • Copia i set di backup Oracle RMAN su Amazon S3 dalla posizione di backup RMAN di Exadata.

  • Usa le appliance di storage Oracle ZFS. I set di backup Oracle RMAN archiviati su Oracle ZFS Storage Appliance possono essere trasferiti direttamente su Amazon S3 utilizzando il servizio Oracle ZFS Storage Appliance S3 Object API.

  • Archivia i backup Oracle RMAN direttamente su Exadata Storage Server, Oracle Zero Loss Recovery Appliance e sulle librerie a nastro. È quindi possibile trasferire i set di backup RMAN su una qualsiasi di queste piattaforme di storage su Amazon S3.

Migrazione ad Amazon EC2

Puoi anche utilizzare RMAN per eseguire il backup del tuo database Exadata direttamente su Oracle Database su Amazon EC2 senza creare set di backup. A tale scopo, utilizza il DUPLICATE comando Oracle RMAN per eseguire un backup e un ripristino. Tuttavia, Oracle RMAN DUPLICATE non è consigliato per migrazioni Exadata di grandi dimensioni (multi-TIB).

Le impostazioni RMAN sono generalmente configurate in base a fattori quali la dimensione del backup, la CPU Exadata, la compressione e il parallelismo o il numero di canali RMAN. L'utilizzo di Oracle Service Bus (OSB) e della compressione (bassa, media e alta) con RMAN richiede le licenze Oracle Advanced Compression Option (ACO). OSB richiede anche licenze Oracle basate sul numero di canali RMAN che si desidera utilizzare con OSB.

Se desideri utilizzare RMAN per migrare Exadata a Oracle su Amazon EC2, prendi in considerazione le seguenti best practice.

Nota

I comandi forniti in questa sezione devono essere eseguiti sull'istanza Oracle on Amazon EC2.

  • Se desideri utilizzare nomi di gruppi di dischi Oracle ASM diversi su Amazon EC2, esegui il set newname comando con il processo di ripristino RMAN:

    set newname for datafile 1 to '+<disk_group>'; set newname for datafile 2 to '+<disk_group>';
  • Se i redo log online si trovano in una posizione diversa su AWS, rinomina i redo log file:

    alter database rename file '/<old_path>/redo01.log' to '+<disk_group>'; alter database rename file '/<old_path>/redo02.log' to '+<disk_group>';
  • Dopo aver aperto correttamente il database su: AWS

    • Rimuovi i gruppi di redo log per i redo thread di altre istanze:

      alter database disable thread 2; alter database drop logfile group 4; alter database clear unarchived logfile group 4;
    • Rimuovi le tablespace di annullamento di altre istanze:

      drop tablespace UNDOTBS2 including contents and datafiles;
    • Assicurati che esista solo un tablespace. TEMP Rimuovi le TEMP tablespace non necessarie e conferma che la TEMP tablespace esistente sia sufficientemente grande da gestire il carico di lavoro previsto del database.

Considerazioni sull'HCC

Se si utilizza Hybrid Columnar Compression (HCC) in Exadata, tutte le tabelle con HCC devono essere convertite in Oracle ACO o disabilitate. AWS Altrimenti, le istruzioni SQL falliranno quando accedi al tuo database Oracle su Amazon EC2. Oracle ACO richiede una licenza Oracle.

In genere, gli utenti non possono rimuovere HCC da un database di produzione Exadata locale. Puoi rimuovere HCC quando esegui la migrazione del database su. AWS Per determinare se HCC è attivato su una tabella o una partizione dopo la migrazione del database in AWS, esegui la seguente istruzione SQL:

select TABLE_NAME, COMPRESSION, COMPRESS_FOR from DBA_TABLES where OWNER like 'SCHEMA_NAME'; select TABLE_NAME, PARTITION_NAME, COMPRESSION, COMPRESS_FOR from DBA_TAB_PARTITIONS where TABLE_OWNER = 'SCHEMA_NAME';

Se il valore della compression colonna è impostato su ENABLED e la compress_for colonna ha uno dei seguenti valori, HCC è abilitato:

  • QUERY LOW

  • QUERY HIGH

  • ARCHIVE LOW

  • ARCHIVE HIGH

  • QUERY LOW ROW LEVEL LOCKING

  • QUERY HIGH ROW LEVEL LOCKING

  • ARCHIVE LOW ROW LEVEL LOCKING

  • ARCHIVE HIGH ROW LEVEL LOCKING

  • NO ROW LEVEL LOCKING

Per disattivare HCC su una tabella o una partizione, esegui la seguente istruzione SQL:

alter table table_name nocompress; alter table table_name modify partition partition_name nocompress;

Per attivare Oracle ACO AWS, segui le istruzioni nella documentazione di Oracle.

Migrazioni di Oracle Data Guard

Oracle Data Guard consente di creare e gestire uno o più database in standby per l'alta disponibilità e il disaster recovery. Data Guard mantiene i database in standby come copie del database primario (in genere di produzione). Se il database di produzione riscontra problemi di disponibilità pianificati o non pianificati, Data Guard può cambiare ruolo per garantire tempi di inattività minimi e continuità delle applicazioni.

È possibile utilizzare metodi di standby logico e di standby fisico per implementare Data Guard. In questa guida, supponiamo che tu stia utilizzando un database fisico in standby che corrisponde esattamente al database principale.

Data Guard supporta le migrazioni da Exadata a Oracle Database su Amazon EC2 per creare uno standby fisico. Non può essere usato per migrare ad Amazon RDS for Oracle, che richiede approcci di migrazione logici AWS DMS come Oracle Data Pump o Oracle. GoldenGate

Data Guard è un approccio più semplice e veloce per la migrazione di un intero database Exadata rispetto a un meccanismo CDC come o Oracle. AWS DMS GoldenGate Di solito è l'approccio consigliato se si hanno requisiti minimi di inattività (ad esempio, si ha tempo solo per il passaggio al digitale).

È possibile configurare Data Guard con trasporto sincrono o asincrono. In generale, i clienti Oracle hanno maggiore successo con il trasporto sincrono quando la latenza della rete di andata e ritorno è inferiore a 5 ms. Per il trasporto asincrono, Oracle consiglia una latenza di rete di andata e ritorno inferiore a 30 ms.

In genere, esisterebbe già uno standby Data Guard per il database locale Exadata di produzione. Oracle su Amazon EC2 di solito funge da database di standby aggiuntivo per il database locale Exadata di produzione. Si consiglia di creare il database di standby Data Guard utilizzando Oracle RMAN. AWS

Esistono molte variabili che influiscono sulle prestazioni di Data Guard. Ti consigliamo di eseguire dei test prima di trarre conclusioni sull'impatto della replica di Data Guard sul tuo carico di lavoro.

La latenza (misurata tramite un monitor ping) non è significativa per la replica di Data Guard, poiché il meccanismo utilizzato è diverso. L'utilità Oracle oratcptest aiuta a valutare le risorse di rete. È possibile scaricare oratcptest in formato JAR dalla nota My Oracle Support (MOS) 2064368.1 (richiede un account Oracle). La nota MOS fornisce anche ulteriori informazioni su questa utilità.