Limitazioni note e consigli

Questa pagina descrive le limitazioni note (incluse le considerazioni speciali per la gestione di entità come chiavi primarie o chiavi esterne e trigger), nonché le best practice per le migrazioni eterogenee di Oracle con Database Migration Service.

Elementi di cui non viene eseguita la migrazione

  • Non viene eseguita la migrazione di utenti e autorizzazioni.
  • Non viene eseguita automaticamente la migrazione delle modifiche dello schema che si verificano durante un job di migrazione attivo. Se modifichi lo schema durante la migrazione, devi prima aggiornare l'area di lavoro di conversione con le modifiche dello schema, quindi aggiornare i job di migrazione pertinenti. Per ulteriori informazioni, vedi Aggiungere schemi o tabelle aggiornati al job di migrazione.
  • Le istruzioni SAVEPOINT non sono supportate e possono causare discrepanze nei dati in caso di rollback.
  • Database Migration Service replica i tipi di dati definiti dall'utente, ma memorizza solo il tipo di dati di base da cui derivano i tipi definiti dall'utente. Ad esempio, se definisci un tipo di dati USERNAME basato sul VARCHAR2 tipo di dati, i dati vengono archiviati nella destinazione come VARCHAR.

Database, transazioni e coerenza dei dati

  • La migrazione è coerente alla fine, poiché Database Migration Service non replica ogni transazione in tempo reale. La migrazione importa i dati da più tabelle. L'ordine in cui i dati vengono caricati nella destinazione può variare, ma si riallinea con l'origine dopo che le scritture sull'origine vengono interrotte e il buffer di migrazione viene svuotato.
  • Per le migrazioni eterogenee di Oracle, Database Migration Service può eseguire la migrazione di un solo database per job di migrazione.
  • Database Migration Service supporta l'architettura multitenant Oracle (CDB/PDB), ma puoi eseguire la migrazione di un solo database modulare per job di migrazione.
  • Oracle Label Security (OLS) non viene replicato.
  • Le transazioni di cui viene eseguito il rollback nel database di origine durante il processo di migrazione potrebbero essere visibili temporaneamente nella destinazione (se la transazione è abbastanza lunga).
  • Database Migration Service non supporta la connettività diretta ai database utilizzando la funzionalità Single Client Access Name (SCAN) negli ambienti Oracle Real Application Clusters (RAC). Per le potenziali soluzioni per l'utilizzo della connettività con elenco consentito di indirizzi IP pubblici con questi ambienti, vedi Risolvere i problemi relativi agli errori di Oracle SCAN.

Codifica dei dati

  • Database Migration Service supporta solo le codifiche del set UTF8 per il database di destinazione. I nomi di schemi e tabelle che includono caratteri che non fanno parte del set di codifica UTF8 non sono supportati.
  • Database Migration Service supporta le seguenti codifiche del set di caratteri per i database Oracle :
    • AL16UTF16
    • AL32UTF8
    • IN8ISCII
    • IW8ISO8859P8
    • JA16SJIS
    • JA16SJISTILDE
    • KO16MSWIN949
    • US7ASCII
    • UTF8
    • WE8ISO8859P1
    • WE8ISO8859P9
    • WE8ISO8859P15
    • WE8MSWIN1252
    • ZHT16BIG5

Tabelle, schemi e altri oggetti

  • Durante una migrazione, le modifiche del linguaggio di definizione dei dati (DDL) a dati, schemi, e metadati non sono supportate. Se aggiorni lo schema durante la migrazione, devi eseguire il pull delle modifiche nell'area di lavoro di conversione, convertire il codice, pulire la destinazione ed eseguire di nuovo il job di migrazione.
  • I nomi delle colonne delle tabelle che includono caratteri diversi da caratteri alfanumerici caratteri o un trattino basso (_) non sono supportati.
  • La lunghezza massima del nome per tabelle o colonne è di 30 caratteri. Database Migration Service non può replicare le tabelle che superano questo limite o le tabelle che contengono colonne i cui nomi superano questo limite.
  • Le tabelle organizzate per indice (IOT) non sono supportate.
  • Le tabelle temporanee globali richiedono l'installazione e la creazione dell'estensione PostgreSQL pgtt nella destinazione.
  • Per le colonne di tipo BFILE, verrà replicato solo il percorso del file. I contenuti del file non verranno replicati.
  • Per Oracle 11g, le tabelle con colonne di tipi di dati ANYDATA o UDT non sono supportate e l'intera tabella non verrà replicata.
  • Non viene eseguita la migrazione dei job pianificati utilizzando dbms_job o dbms_scheduler.
  • Viene eseguita la migrazione delle definizioni delle viste materializzate, ma non dei dati materializzati. Al termine della migrazione, aggiorna le viste materializzate per popolarle con i dati delle tabelle migrate.
  • Viene eseguita la migrazione dei valori delle sequenze, ma i relativi valori nel database di origine potrebbero continuare ad aumentare prima del completamento della migrazione. Al termine della migrazione, aggiorna i valori delle sequenze nell'istanza di destinazione in modo che corrispondano a quelli del database di origine.
  • I job di migrazione sono limitati a 10.000 tabelle.
  • Le righe hanno una limitazione di dimensione di 100 MB. Non viene eseguita la migrazione delle righe che superano il limite di 100 MB e vengono visualizzate come errori nel job di migrazione.
  • Non viene eseguita automaticamente la migrazione delle tabelle create dopo l'avvio della migrazione automaticamente. Innanzitutto, devi eseguire il pull dello schema nell'area di lavoro di conversione, applicare le definizioni convertite alla destinazione e aggiornare il job di migrazione.
  • Le tabelle di origine che contengono colonne binarie e non hanno chiavi primarie non sono non supportate per la migrazione dei dati nelle migrazioni continue.

Limitazioni dei tipi di dati

I seguenti tipi di dati non sono supportati per le migrazioni di Oracle:

  • ANYDATA (per Oracle 11g, le tabelle con ANYDATA non sono supportate e non vengono replicate)
  • BFILE
  • INTERVAL DAY TO SECOND
  • INTERVAL YEAR TO MONTH
  • LONG/LONG RAW
  • SDO_GEOMETRY
  • UDT
  • UROWID
  • XMLTYPE
  • Date zero in TIMESTAMP

Considerazioni sulle chiavi primarie

Le tabelle senza chiavi primarie non garantiscono una replica coerente. Database Migration Service esegue la migrazione solo delle tabelle con chiavi primarie. Se il database di origine include tabelle senza chiavi primarie, le aree di lavoro di conversione di Database Migration Service creano automaticamente le chiavi primarie mancanti nelle tabelle di destinazione quando converti il codice sorgente e lo schema. Puoi anche disabilitare la generazione automatica della chiave primaria con la GENERATE_MISSING_PK direttiva di conversione.

Per le migrazioni continue: le tabelle di origine che contengono colonne binarie e non hanno chiavi primarie non sono supportate per la migrazione dei dati nelle migrazioni continue.

Se utilizzi le aree di lavoro di conversione legacy, devi creare manualmente i vincoli di chiave primaria nelle tabelle convertite nel database di destinazione prima di avviare la migrazione. Per ulteriori informazioni, vedi Aree di lavoro di conversione legacy.

Considerazioni sulle chiavi esterne e sui trigger

Le chiavi esterne e i trigger presenti nel database di origine potrebbero causare problemi di integrità dei dati o persino causare il fallimento del job di migrazione. Puoi evitare questi problemi se ignori le chiavi esterne e i trigger utilizzando l'opzione REPLICATION per l'utente di migrazione. In alternativa, puoi anche eliminare tutte le chiavi esterne e i trigger nel database di destinazione e ricrearli al termine della migrazione.

Trigger

I dati replicati da Database Migration Service incorporano già le modifiche apportate dai trigger nel database di origine. Se i trigger sono abilitati nella destinazione, possono essere attivati di nuovo e potenzialmente manipolare i dati, causando problemi di integrità dei dati o duplicazione.

Chiavi esterne

Database Migration Service non replica i dati in modo transazionale, quindi le tabelle potrebbero essere migrate in ordine diverso. Se sono presenti chiavi esterne e viene eseguita la migrazione di una tabella secondaria che utilizza una chiave esterna prima della relativa tabella principale, potresti riscontrare errori di replica.

Consigli

  • Quando crei il database Cloud SQL di destinazione, assicurati di utilizzare risorse di calcolo e memoria sufficienti per soddisfare le esigenze di migrazione. Consigliamo di utilizzare un tipo di macchina con almeno una CPU dual-core.

    Ad esempio, se il nome della tua macchina è db-custom, e ha 2 CPU e 3840 MB di RAM, il formato del nome del tipo di macchina è db-custom-2-3840.

  • Il database Cloud SQL di destinazione è scrivibile durante la migrazione per consentire l'applicazione delle modifiche del linguaggio di manipolazione dei dati (DML), se necessario. Fai attenzione a non apportare modifiche alla configurazione del database o alle strutture delle tabelle che potrebbero interrompere il processo di migrazione o influire sull'integrità dei dati.

Quote

  • In qualsiasi momento, possono esistere fino a 2000 profili di connessione e 1000 job di migrazione. Per creare spazio, è possibile eliminare i job di migrazione (compresi quelli completati) e i profili di connessione.