Migrazione dal sistema Oracle® OLTP a Spanner

Questo articolo spiega come eseguire la migrazione del tuo database dai sistemi Oracle® Online Transaction Processing (OLTP) a Spanner.

Spanner utilizza alcuni concetti in modo diverso da altri strumenti di gestione dei database aziendali; per questo motivo, potrebbe essere necessario modificare l'applicazione per sfruttare appieno le sue funzionalità. Potresti anche dover integrare Spanner con altri servizi di Google Cloud per soddisfare le tue esigenze.

Vincoli di migrazione

Quando esegui la migrazione della tua applicazione a Spanner, devi tenere conto delle diverse funzionalità disponibili. Probabilmente dovrai riprogettare l'architettura dell'applicazione per adattarla al set di funzionalità di Spanner e per integrarla con i servizi aggiuntivi di Google Cloud.

Stored procedure e trigger

Spanner non supporta l'esecuzione del codice utente a livello di database; di conseguenza, nell'ambito della migrazione devi spostare nell'applicazione la logica di business implementata da trigger e procedure archiviate a livello di database.

Sequenze

Ti consigliamo di utilizzare UUID versione 4 come metodo predefinito per generare coppie chiave-valore primarie. La funzione GENERATE_UUID() (GoogleSQL, PostgreSQL) restituisce valori UUID versione 4 come tipo STRING.

Se devi generare valori interi a 64 bit, Spanner supporta sequenze con bit invertite positive (GoogleSQL, PostgreSQL), che producono valori che si distribuiscono in modo uniforme nello spazio numerico positivo a 64 bit. Puoi usare questi numeri per evitare problemi di hotspot.

Per saperne di più, consulta le strategie per i valori predefiniti della chiave principale.

Controlli di accesso

Spanner supporta solo i controlli dell'accesso a livello di database con autorizzazioni e ruoli IAM. I ruoli predefiniti possono concedere l'accesso in lettura/scrittura o in sola lettura al database.

Se hai bisogno di autorizzazioni più granulari, devi implementarle a livello di applicazione. In uno scenario normale, solo l'applicazione deve poter leggere e scrivere nel database.

Se devi esporre il database agli utenti per la generazione di report e vuoi utilizzare autorizzazioni di sicurezza granulari (ad esempio autorizzazioni a livello di tabella e vista), devi esportare il database in BigQuery.

Vincoli di convalida dei dati

Spanner può supportare un insieme limitato di vincoli di convalida dei dati nel livello database.

Se hai bisogno di vincoli dei dati più complessi, implementali nel livello dell'applicazione.

La seguente tabella descrive i tipi di vincoli comunemente presenti nei database Oracle® e come implementarli con Spanner.

Vincolo Implementazione con Spanner
Non null NOT NULLVincolo di colonna
Univoco Indice secondario con vincolo UNIQUE
Chiave esterna (per tabelle normali) Vedi Creare e gestire relazioni di chiave esterna.
Azioni della chiave esterna ON DELETE/ON UPDATE Possibile solo per le tabelle con interleaving, altrimenti implementate nel livello dell'applicazione
Controlli e convalida dei valori tramite vincoli o attivatori CHECK Implementata a livello di applicazione

Tipi di dati supportati

I database Oracle® e Spanner supportano set di tipi di dati diversi. La tabella seguente elenca i tipi di dati Oracle e i relativi equivalenti in Spanner. Per definizioni dettagliate di ogni tipo di dati Spanner, consulta Tipi di dati.

Potrebbe anche essere necessario eseguire trasformazioni aggiuntive sui dati come descritto nella colonna Note per adattare i dati Oracle al database di Spanner.

Ad esempio, puoi archiviare un oggetto BLOB di grandi dimensioni come oggetto in un bucket Cloud Storage anziché nel database e quindi archiviare il riferimento URI all'oggetto Cloud Storage nel database come STRING.

Tipo di dati Oracle Equivalente di Spanner Note
Tipi di caratteri (CHAR, VARCHAR, NCHAR, NVARCHAR) STRING Nota: Spanner utilizza stringhe Unicode.
Oracle supporta una lunghezza massima di 32.000 byte o caratteri (a seconda del tipo), mentre Spanner supporta fino a 2.621.440 caratteri.
BLOB, LONG RAW, BFILE BYTES o STRING contenente l'URI dell'oggetto. Gli oggetti di piccole dimensioni (meno di 10 MiB) possono essere archiviati come BYTES.
Valuta l'utilizzo di offerte Google Cloud alternative come Cloud Storage per archiviare oggetti più grandi.
CLOB, NCLOB, LONG STRING (contenente dati o URI dell'oggetto esterno) Gli oggetti di piccole dimensioni (meno di 2.621.440 caratteri) possono essere archiviati come STRING. Valuta la possibilità di utilizzare offerte Google Cloud alternative come Cloud Storage per archiviare oggetti più grandi.
NUMBER, NUMERIC, DECIMAL STRING, FLOAT64, INT64 Il tipo di dati Oracle NUMBER supporta fino a 38 cifre di precisione, mentre il tipo di dati Spanner FLOAT64 supporta fino a 16 cifre di precisione. Consulta la pagina relativa all'archiviazione di dati numerici con precisione arbitraria per i meccanismi alternativi.
INT, INTEGER, SMALLINT INT64
BINARY_FLOAT, BINARY_DOUBLE FLOAT64
DATE DATE La rappresentazione STRING predefinita del tipo DATE di Spanner è yyyy-mm-dd, diversa da quella di Oracle, quindi fai attenzione quando esegui la conversione automatica da e verso STRING delle rappresentazioni delle date. Le funzioni SQL vengono fornite per convertire le date in una stringa formattata.
DATETIME TIMESTAMP Spanner archivia l'ora indipendentemente dal fuso orario. Se devi archiviare un fuso orario, devi utilizzare una colonna STRING separata. Le funzioni SQL consentono di convertire i timestamp in una stringa formattata utilizzando i fusi orari.
XML STRING (contenente dati o URI dell'oggetto esterno) Gli oggetti XML di piccole dimensioni (meno di 2.621.440 caratteri) possono essere archiviati come STRING. Valuta la possibilità di utilizzare offerte alternative di Google Cloud come Cloud Storage per archiviare oggetti più grandi.
URI, DBURI, XDBURI e HTTPURI STRING
ROWID PRIMARY KEY Spanner utilizza la chiave primaria della tabella per ordinare le righe e fare riferimento internamente, perciò in Spanner è di fatto uguale al tipo di dati ROWID.
SDO_GEOMETRY, SDO_TOPO_GEOMETRY_SDO_GEORASTER   Spanner non supporta i tipi di dati geospaziali. Dovrai archiviare questi dati utilizzando tipi di dati standard e implementare qualsiasi logica di ricerca e filtro nel livello dell'applicazione.
ORDAudio, ORDDicom, ORDDoc, ORDImage, ORDVideo e ORDImageSignature Spanner non supporta i tipi di dati multimediali. Valuta la possibilità di utilizzare Cloud Storage per archiviare i dati multimediali.

Processo di migrazione

Di seguito sono riportate le tempistiche generali del processo di migrazione:

  1. Converti lo schema e il modello dei dati.
  2. Traduci qualsiasi query SQL.
  3. Esegui la migrazione della tua applicazione per utilizzare Spanner oltre a Oracle.
  4. Esporta in blocco i tuoi dati da Oracle e importali in Spanner utilizzando Dataflow.
  5. Mantieni la coerenza tra i due database durante la migrazione.
  6. Esegui la migrazione della tua applicazione da Oracle.

Passaggio 1: converti il database e lo schema

Converti lo schema esistente in uno schema Spanner per archiviare i dati. Questo dovrebbe corrispondere il più possibile allo schema Oracle esistente per semplificare le modifiche all'applicazione. Tuttavia, a causa delle differenze nelle funzionalità, saranno necessarie alcune modifiche.

L'utilizzo delle best practice per la progettazione dello schema può aiutarti ad aumentare la velocità effettiva e ridurre gli hotspot nel database di Spanner.

Chiavi primarie

In Spanner, ogni tabella che deve archiviare più di una riga deve avere una chiave primaria composta da una o più colonne della tabella. La chiave primaria della tabella identifica in modo univoco ogni riga in una tabella e le righe della tabella sono ordinate per chiave primaria. Poiché Spanner è altamente distribuito, è importante scegliere una tecnica di generazione chiave primaria che si adatti bene alla crescita dei dati. Per ulteriori informazioni, consulta le strategie di migrazione delle chiavi principali consigliate.

Tieni presente che, dopo aver designato la chiave primaria, non puoi aggiungere o rimuovere una colonna di chiave primaria né modificare un valore di chiave primaria in un secondo momento senza eliminare e ricreare la tabella. Per ulteriori informazioni su come designare la chiave primaria, consulta Schema e modello dei dati - chiavi primarie.

Esegui interfoliazione delle tabelle

Spanner include una funzionalità in cui puoi definire due tabelle con una relazione padre-figlio. In questo modo le righe di dati figlio vengono interfogliate con la riga padre nello spazio di archiviazione, unendo efficacemente la tabella precedente e migliorando l'efficienza di recupero dei dati quando le query padre e figlio vengono eseguite insieme.

La chiave primaria della tabella figlio deve iniziare con le colonne di chiave primaria della tabella padre. Dal punto di vista della riga figlio, la chiave primaria della riga padre è definita come chiave esterna. Puoi definire fino a 6 livelli di relazioni padre-figlio.

Puoi definire azioni al momento dell'eliminazione per le tabelle figlio per determinare cosa succede quando viene eliminata la riga padre: tutte le righe figlio vengono eliminate oppure l'eliminazione della riga padre viene bloccata quando esistono le righe figlio.

Ecco un esempio di creazione di una tabella Album con interleaving nella tabella Singers principale definita in precedenza:

CREATE TABLE Albums (
  SingerId     INT64 NOT NULL,
  AlbumId      INT64 NOT NULL,
  AlbumTitle   STRING(MAX),
) PRIMARY KEY (SingerId, AlbumId)
INTERLEAVE IN PARENT (Singers)
ON DELETE CASCADE;

Crea indici secondari

Puoi anche creare indici secondari per indicizzare i dati all'interno della tabella al di fuori della chiave primaria.

Spanner implementa gli indici secondari come le tabelle, pertanto i valori delle colonne da utilizzare come chiavi di indice hanno gli stessi vincoli delle chiavi primarie delle tabelle. Ciò significa anche che gli indici hanno le stesse garanzie di coerenza delle tabelle Spanner.

Le ricerche di valori che utilizzano indici secondari sono di fatto le stesse di una query con un join di tabella. Puoi migliorare le prestazioni delle query utilizzando gli indici archiviando le copie dei valori della colonna della tabella originale nell'indice secondario tramite la clausola STORING, rendendolo un indice di copertura.

Lo strumento di ottimizzazione delle query di Spanner utilizza automaticamente indici secondari solo quando l'indice stesso archivia tutte le colonne oggetto delle query (una query coperta). Per forzare l'utilizzo di un indice durante l'esecuzione di query sulle colonne nella tabella originale, devi utilizzare un'istruzione FORCE INDEX nell'istruzione SQL, ad esempio:

SELECT *
FROM MyTable@{FORCE_INDEX=MyTableIndex}
WHERE IndexedColumn=@value

Gli indici possono essere utilizzati per applicare valori univoci all'interno di una colonna della tabella, definendo un indice UNIQUE per quella colonna. L'aggiunta di valori duplicati verrà bloccata dall'indice.

Ecco un'istruzione DDL di esempio che crea un indice secondario per la tabella Album:

CREATE INDEX AlbumsByAlbumTitle ON Albums(AlbumTitle);

Tieni presente che se crei indici aggiuntivi dopo il caricamento dei dati, il completamento dell'indice potrebbe richiedere del tempo. Dovresti limitare la frequenza con cui li aggiungi a una media di tre al giorno. Per ulteriori indicazioni sulla creazione di indici secondari, consulta Indici secondari. Per ulteriori informazioni sulle limitazioni relative alla creazione degli indici, consulta Aggiornamenti dello schema.

Passaggio 2: traduci eventuali query SQL

Spanner utilizza il dialetto ANSI 2011 di SQL con estensioni e ha molti funzioni e operatori che consentono di tradurre e aggregare i dati. Devi convertire tutte le query SQL che utilizzano sintassi, funzioni e tipi specifici di Oracle per essere compatibili con Spanner.

Sebbene Spanner non supporti i dati strutturati come definizioni di colonna, i dati strutturati possono essere utilizzati nelle query SQL utilizzando i tipi ARRAY e STRUCT.

Ad esempio, potresti scrivere una query per restituire tutti gli album di un artista utilizzando un ARRAY di STRUCTs in una singola query (sfruttando i dati precedentemente uniti). Per ulteriori informazioni, consulta la sezione Note sulle sottoquery della documentazione.

Le query SQL possono essere profilate utilizzando la pagina di Spanner Studio nella Google Cloud Console per eseguire la query. In generale, le query che eseguono scansioni di tabelle complete su tabelle di grandi dimensioni sono molto costose e devono essere utilizzate con parsimonia.

Consulta la documentazione sulle best practice SQL per ulteriori informazioni sull'ottimizzazione delle query SQL.

Passaggio 3: esegui la migrazione dell'applicazione per utilizzare Spanner

Spanner offre una serie di librerie client per vari linguaggi e la possibilità di leggere e scrivere dati utilizzando chiamate API specifiche di Spanner, nonché utilizzando query SQL e istruzioni DML (Data editing Language). L'utilizzo delle chiamate API potrebbe essere più rapido per alcune query, ad esempio le letture di righe dirette per chiave, poiché non è necessario tradurre l'istruzione SQL.

Puoi anche utilizzare il driver Java Database Connectivity (JDBC) per connetterti a Spanner, sfruttando gli strumenti e l'infrastruttura esistenti che non hanno integrazione nativa.

Nell'ambito del processo di migrazione, le funzionalità non disponibili in Spanner devono essere implementate nell'applicazione. Ad esempio, un trigger per verificare i valori dei dati e aggiornare una tabella correlata deve essere implementato nell'applicazione utilizzando una transazione di lettura/scrittura per leggere la riga esistente, verificare il vincolo e scrivere le righe aggiornate in entrambe le tabelle.

Spanner offre transazioni di lettura/scrittura e di sola lettura, che garantiscono la coerenza esterna dei dati. Inoltre, alle transazioni di lettura possono essere applicati limiti di timestamp, in cui stai leggendo una versione coerente dei dati specificati nei seguenti modi:

  • A un'ora esatta nel passato (fino a un'ora fa).
  • In futuro (dove la lettura verrà bloccata fino a quel momento).
  • Con una quantità accettabile di inattività limitata, che restituirà una visualizzazione coerente fino a un certo periodo di tempo senza dover verificare che i dati successivi siano disponibili su un'altra replica. Ciò può migliorare le prestazioni a scapito di dati potenzialmente inattivi.

Passaggio 4: trasferisci i dati da Oracle a Spanner

Per trasferire i dati da Oracle a Spanner, devi esportare il database Oracle in un formato file portatile, ad esempio CSV, quindi importare i dati in Spanner utilizzando Dataflow.

Il processo di estrazione, trasformazione e caricamento in Dataflow

Esportazione collettiva da Oracle

Oracle non fornisce utilità integrate per esportare o eseguire l'unload dell'intero database in un formato file portatile.

Alcune opzioni per eseguire un'esportazione sono elencate nelle Domande frequenti su Oracle.

Queste includono:

  • Utilizzo di SQL*plus o SQLcl per eseguire lo spooling di una query su un file di testo.
  • Scrittura di una funzione PL/SQL utilizzando UTL_FILE per annullare il caricamento di una tabella in parallelo ai file di testo.
  • Utilizzo delle funzionalità di Oracle APEX o Oracle SQL Developer per annullare il caricamento di una tabella in un file CSV o XML.

Ognuna di queste ha lo svantaggio che può essere esportata una sola tabella alla volta. Ciò significa che devi mettere in pausa l'applicazione o mettere in pausa il database in modo che il database rimanga in uno stato coerente per l'esportazione.

Altre opzioni includono gli strumenti di terze parti elencati nella pagina delle domande frequenti su Oracle, alcuni dei quali possono annullare una visualizzazione coerente dell'intero database.

Una volta eseguito l'unload, devi caricare questi file di dati in un bucket Cloud Storage in modo che siano accessibili per l'importazione.

Importazione collettiva in Spanner

Poiché gli schemi del database probabilmente sono diversi tra Oracle e Spanner e Spanner, potresti dover effettuare alcune conversioni dei dati durante il processo di importazione.

Il modo più semplice per eseguire queste conversioni dei dati e importarli in Spanner è utilizzare Dataflow.

Dataflow è il servizio ETL (Distributed Extract Transform and Load) distribuito di Google Cloud. Fornisce una piattaforma per l'esecuzione di pipeline di dati scritte utilizzando l'SDK Apache Beam al fine di leggere ed elaborare grandi quantità di dati in parallelo su più macchine.

L'SDK Apache Beam richiede la scrittura di un semplice programma Java per impostare la lettura, la trasformazione e la scrittura dei dati. I connettori Beam esistono per Cloud Storage e Spanner, pertanto l'unico codice che deve essere scritto è la trasformazione dei dati.

Guarda un esempio di una semplice pipeline che legge dai file CSV e scrive in Spanner nel repository di codice di esempio che accompagna questo articolo.

Se nello schema Spanner vengono utilizzate tabelle con interleaving padre-figlio, è necessario prestare attenzione durante il processo di importazione in modo che la riga padre venga creata prima della riga figlio. Il codice pipeline di importazione di Spanner gestisce questa operazione importando prima tutti i dati per le tabelle di livello principale, quindi tutte le tabelle figlio di livello 1, poi tutte le tabelle di livello 2 e così via.

La pipeline di importazione di Spanner può essere utilizzata direttamente per importare in blocco i dati,ma ciò richiede che i dati esistano nei file Avro utilizzando lo schema corretto.

Passaggio 5: mantieni la coerenza tra entrambi i database

Molte applicazioni hanno requisiti di disponibilità che impediscono di mantenere l'applicazione offline per il tempo necessario per esportare e importare i dati. Durante il trasferimento dei dati su Spanner, l'applicazione continua a modificare il database esistente. Devi duplicare gli aggiornamenti al database Spanner mentre l'applicazione è in esecuzione.

Esistono vari metodi per mantenere sincronizzati i due database, tra cui Change Data Capture (CDC) e implementare aggiornamenti simultanei nell'applicazione.

Change Data Capture (CDC)

Oracle GoldenGate può fornire uno stream CDC (Change Data Capture) per il tuo database Oracle. Oracle LogMiner o Oracle XStream Out sono interfacce alternative per il database Oracle per ottenere un flusso CDC che non coinvolga Oracle GoldenGate.

Puoi scrivere un'applicazione che si abbona a uno di questi flussi e che applichi le stesse modifiche (ovviamente dopo la conversione dei dati) al tuo database Spanner. Un'applicazione di elaborazione dei flussi di dati deve implementare diverse funzionalità:

  • Connessione al database Oracle (database di origine).
  • Connessione a Spanner (database di destinazione).
  • Ripetizione ripetuta delle seguenti operazioni:
    • Ricezione dei dati prodotti da uno dei flussi CDC del database Oracle.
    • Interpretazione dei dati prodotti dal flusso CDC.
    • Conversione dei dati in istruzioni INSERT di Spanner.
    • Esecuzione delle istruzioni INSERT di Spanner.

La tecnologia di migrazione dei database è una tecnologia middleware che ha implementato le funzionalità richieste come parte della propria funzionalità. La piattaforma di migrazione del database viene installata come componente separato nella posizione di origine o di destinazione, in base ai requisiti del cliente. La piattaforma di migrazione dei database richiede solo la configurazione della connettività dei database coinvolti per specificare e avviare il trasferimento continuo di dati dall'origine al database di destinazione.

Striim è una piattaforma tecnologica per la migrazione dei database disponibile su Google Cloud. Fornisce connettività ai flussi CDC da Oracle GoldenGate oltre che da Oracle LogMiner e Oracle XStream Out. Striim fornisce uno strumento grafico che consente di configurare la connettività dei database e le regole di trasformazione necessarie per trasferire i dati da Oracle a Spanner.

Puoi installare Striim da Google Cloud Marketplace connettendoti ai database di origine e di destinazione, implementare eventuali regole di trasformazione e iniziare a trasferire i dati senza dover creare autonomamente un'applicazione di elaborazione dei flussi.

Aggiornamenti simultanei a entrambi i database dall'applicazione

Un metodo alternativo è modificare l'applicazione per eseguire le scritture su entrambi i database. Un database (inizialmente Oracle) è considerato l'origine attendibile e, dopo ogni scrittura del database, l'intera riga viene letta, convertita e scritta nel database Spanner.

In questo modo, l'applicazione sovrascrive costantemente le righe di Spanner con i dati più recenti.

Dopo aver verificato che tutti i dati sono stati trasferiti correttamente, puoi passare l'origine attendibile al database Spanner.

Questo meccanismo fornisce un percorso di rollback se vengono rilevati problemi durante il passaggio a Spanner.

Verificare la coerenza dei dati

Durante il flusso di dati nel database Spanner, puoi eseguire periodicamente un confronto tra i dati Spanner e quelli Oracle per assicurarti che siano coerenti.

Puoi convalidare la coerenza eseguendo query su entrambe le origini dati e confrontando i risultati.

Puoi utilizzare Dataflow per eseguire un confronto dettagliato su set di dati di grandi dimensioni utilizzando la trasformazione di join. Questa trasformazione richiede 2 set di dati con chiave e corrisponde ai valori in base alla chiave. I valori corrispondenti possono quindi essere confrontati per ottenere l'uguaglianza.

Puoi eseguire regolarmente questa verifica finché il livello di coerenza non soddisfa i requisiti della tua attività.

Passaggio 6: passa a Spanner come fonte attendibile dell'applicazione

Se hai fiducia nella migrazione dei dati, puoi impostare la tua applicazione in modo che utilizzi Spanner come fonte attendibile. Continua a scrivere le modifiche al database Oracle per mantenere aggiornato il database Oracle fornendoti un percorso di rollback in caso di problemi.

Infine, puoi disabilitare e rimuovere il codice di aggiornamento del database Oracle e arrestare il database Oracle.

Esporta e importa i database Spanner

Facoltativamente, puoi esportare le tabelle da Spanner in un bucket Cloud Storage utilizzando un modello Dataflow per eseguire l'esportazione. La cartella risultante contiene un insieme di file Avro e file manifest JSON contenenti le tabelle esportate. Questi file possono avere diversi scopi, tra cui:

  • Backup del tuo database per la conformità ai criteri di conservazione dei dati o il ripristino di emergenza.
  • Importazione del file Avro in altre offerte Google Cloud come BigQuery.

Per ulteriori informazioni sul processo di esportazione e importazione, consulta Esportazione e importazione di database e Importazione di database.

Passaggi successivi