Limitazioni note e consigli

Questa pagina descrive le limitazioni note (incluse considerazioni speciali per il trattamento di entità come chiavi primarie o trigger e chiavi estranee), nonché le pratiche consigliate per le migrazioni Oracle eterogenee con Database Migration Service.

Elementi di cui non viene eseguita la migrazione

  • La migrazione di utenti e autorizzazioni non è stata eseguita.
  • Le modifiche allo schema che si verificano durante un job di migrazione attivo non vengono eseguite automaticamente. Se modifichi lo schema durante la migrazione, devi prima aggiornare l'area di lavoro di conversione con le modifiche dello schema e poi aggiornare i job di migrazione pertinenti. Per ulteriori informazioni, consulta Aggiungere lo schema o le tabelle aggiornate al job di migrazione.
  • Le istruzione 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 derivi 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.

Coerenza di database, transazioni e dati

  • La migrazione è eventualmente coerente, 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 allinea nuovamente all'origine dopo l'interruzione delle scritture nell'origine e l'eliminazione del buffer di migrazione.
  • Per le migrazioni Oracle eterogenee, Database Migration Service può eseguire la migrazione di un solo database per job di migrazione.
  • Database Migration Service supporta l'architettura multi-tenant 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 sottoposte a rollback nel database di origine durante il processo di migrazione potrebbero essere temporaneamente visibili nella destinazione (se la transazione è sufficientemente lunga).
  • Database Migration Service non supporta la connettività diretta ai database che utilizzano la funzionalità SCAN (Single Client Access Name) negli ambienti Oracle Real Application Clusters (RAC). Per potenziali soluzioni all'utilizzo della connettività della lista consentita IP con questi ambienti, consulta Risolvere gli errori di Oracle SCAN.

Codifica dei dati

  • Database Migration Service supporta solo le codifiche impostate su UTF8 per il database di destinazione. I nomi di schema e tabella che includono caratteri che non fanno parte del 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 estrarre le modifiche nell'area di lavoro di conversione, convertire il codice, ripulire la destinazione ed eseguire di nuovo il job di migrazione.
  • I nomi delle colonne della tabella che includono caratteri diversi da quelli alfanumerici 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'estensione pgtt PostgreSQL installata e creata 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.
  • La migrazione dei job pianificati utilizzando dbms_job o dbms_scheduler non viene eseguita.
  • Viene eseguita la migrazione delle definizioni delle viste materializzate, ma non dei relativi dati materializzati. Al termine della migrazione, aggiorna le viste materializzate per completarle con i dati delle tabelle di cui è stata eseguita la migrazione.
  • I valori di sequenza vengono sottoposti a migrazione, ma i relativi valori nel database di origine potrebbero continuare ad avanzare prima del completamento della migrazione. Al termine della migrazione, aggiorna i valori di sequenza nell'istanza di destinazione in modo che corrispondano a quelli nel database di origine.
  • I job di migrazione sono limitati a 10.000 tabelle.
  • Le righe hanno un limite di dimensioni di 100 MB. Per le righe che superano il limite di 100 MB non viene eseguita la migrazione e vengono visualizzate come errori nel job di migrazione.
  • La migrazione di tutte le tabelle create dopo l'inizio della migrazione non viene eseguita automaticamente. Innanzitutto, devi estrarre lo schema nello spazio 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 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 per le chiavi principali

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 e lo schema di origine.

Se utilizzi spazi di lavoro per le conversioni precedenti, devi creare manualmente vincoli di chiave primaria nelle tabelle convertite nel database di destinazione prima di avviare la migrazione. Per ulteriori informazioni, consulta Workspace di conversione legacy.

Considerazioni per chiavi esterne e attivatori

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

Trigger

I dati replicati da Database Migration Service incorporano già eventuali modifiche apportate dagli attivatori nel database di origine. Se gli 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 esegue la replica dei dati in modo transazionale, pertanto la migrazione delle tabelle potrebbe non essere eseguita in ordine. Se sono presenti chiavi esterne e viene eseguita la migrazione di una tabella figlio che utilizza una chiave esterna prima della 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 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 di modifiche al 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 la procedura di migrazione o incidere 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.