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 consigliate per le migrazioni eterogenee di Oracle con Database Migration Service.

Elementi di cui non viene eseguita la migrazione

  • Gli utenti e le autorizzazioni non vengono migrati.
  • Le modifiche allo schema che si verificano durante un job di migrazione attivo non vengono migrate automaticamente. Se modifichi lo schema durante la migrazione, devi prima aggiornare l'area di lavoro di conversione con le modifiche allo schema e poi 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 in base al tipo di dati VARCHAR2, i dati vengono archiviati nella destinazione come VARCHAR.

Database, transazioni e coerenza dei dati

  • La migrazione è coerente nel tempo, in quanto 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 all'origine dopo l'interruzione delle scritture nell'origine e la cancellazione del buffer di migrazione.
  • 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.
  • Eventuali transazioni di rollback nel database di origine durante il processo di migrazione potrebbero essere visibili temporaneamente nella destinazione (se la transazione è sufficientemente 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 potenziali soluzioni all'utilizzo della connettività della lista consentita IP pubblici con questi ambienti, consulta Risolvere i problemi relativi agli errori SCAN di Oracle.

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 non inclusi nel set di codifica UTF8 non sono supportati.
  • Database Migration Service supporta le seguenti codifiche dei set di caratteri per i database Oracle:
    • AL16UTF16
    • AL32UTF8
    • IN8ISCII
    • JA16SJIS
    • US7ASCII
    • UTF8
    • WE8ISO8859P1
    • WE8ISO8859P9
    • WE8ISO8859P15
    • WE8MSWIN1252
    • ZHT16BIG5

Tabelle, schemi e altri oggetti

  • Durante una migrazione, le modifiche al linguaggio di definizione dei dati (DDL) a dati, schemi e metadati non sono supportate. Se aggiorni lo schema durante la migrazione, devi trasferire le modifiche all'area di lavoro di conversione, convertire il codice, pulire la destinazione ed eseguire di nuovo il job di migrazione.
  • I nomi delle colonne della tabella che includono caratteri diversi da quelli alfanumerici o da 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 pgtt PostgreSQL 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.
  • I job pianificati utilizzando dbms_job o dbms_scheduler non vengono migrati.
  • Le definizioni delle viste materializzate vengono migrate, ma i relativi dati materializzati no. Al termine della migrazione, aggiorna le viste materializzate per popolarle con i dati delle tabelle migrate.
  • I valori di sequenza vengono migrati, ma i loro valori nel database di origine potrebbero continuare ad aumentare prima del completamento della migrazione. Al termine della migrazione, aggiorna i valori della sequenza 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 un limite di dimensioni di 100 MB. Le righe che superano il limite di 100 MB non vengono migrate e vengono visualizzate come errori nel job di migrazione.
  • Le tabelle create dopo l'inizio della migrazione non vengono migrate automaticamente. Innanzitutto, devi estrarre lo schema nell'area di lavoro di conversione, applicare le definizioni convertite alla destinazione e aggiornare il job di migrazione.

Limitazioni dei tipi di dati

I seguenti tipi di dati non sono supportati per le migrazioni 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
  • Zero date in TIMESTAMP

Considerazioni relative alle 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.

Se utilizzi spazi 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 Workspace di conversione legacy.

Considerazioni su chiavi esterne e trigger

Le chiavi esterne e i trigger presenti nel database di origine potrebbero causare problemi di integrità dei dati o persino l'esito negativo 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à o duplicazione dei dati.

Chiavi esterne

Database Migration Service non replica i dati in modo transazionale, quindi le tabelle potrebbero essere migrate in modo non sequenziale. Se sono presenti chiavi esterne e una tabella secondaria che utilizza una chiave esterna viene migrata prima della tabella padre, potresti riscontrare errori di replica.

Consigli

  • Quando crei il database Cloud SQL di destinazione, assicurati di utilizzare risorse di calcolo e memoria sufficienti per coprire le tue 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 DML (Data Manipulation Language) se necessario. Fai attenzione a non apportare modifiche alla configurazione del database o alle strutture delle tabelle che potrebbero interrompere la procedura 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.