Esegui la migrazione dal sistema Oracle® OLTP a Spanner

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

Spanner utilizza determinati concetti in modo diverso rispetto ad altri strumenti di gestione dei database aziendali, pertanto potresti dover modificare la tua applicazione per sfruttare al meglio le sue funzionalità. Potresti anche dover integrare Spanner con altri servizi Google Cloud per soddisfare le tue esigenze.

Vincoli di migrazione

Quando esegui la migrazione dell'applicazione a Spanner, devi tenere conto delle diverse funzionalità disponibili. Probabilmente dovrai riprogettare l'architettura dell'applicazione in modo che sia compatibile con il set di funzionalità di Spanner e per integrarla con altri servizi Google Cloud.

Stored procedure e trigger

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

Sequenze

Ti consigliamo di utilizzare la versione 4 di UUID come metodo predefinito per generare i valori della chiave primaria. La funzione GENERATE_UUID() (GoogleSQL, PostgreSQL) restituisce i valori UUID versione 4 come tipo STRING.

Se devi generare valori interi a 64 bit, Spanner supporta le sequenze con inversione dei bit positive (GoogleSQL, PostgreSQL), che producono valori distribuiti uniformemente nello spazio numerico positivo a 64 bit. Puoi utilizzare questi numeri per evitare problemi di hotspotting.

Per ulteriori informazioni, consulta le strategie per i valori predefiniti delle chiavi principali.

Controlli di accesso

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

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

Se devi esporre il database agli utenti per i report e vuoi utilizzare autorizzazioni di sicurezza granulari (ad esempio autorizzazioni a livello di tabella e visualizzazione), 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 del database.

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

La tabella seguente illustra 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 le tabelle normali) Consulta l'articolo Creare e gestire relazioni con le chiave esterna esterne.
Azioni ON DELETE/ON UPDATE della chiave esterna Possibile solo per tabelle interlacciate, altrimenti implementato nel livello di applicazione
Controlli e convalida dei valori tramite vincoli o attivatori CHECK Implementato nel livello di applicazione

Tipi di dati supportati

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

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

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

Tipo di dati Oracle Equivalente Spanner Note
Tipi di caratteri (CHAR, VARCHAR, NCHAR, NVARCHAR) STRING Nota: Spanner utilizza sempre 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 la possibilità di utilizzare offerte Google Cloud alternative come Cloud Storage per archiviare oggetti di dimensioni maggiori.
CLOB, NCLOB, LONG STRING (contenente dati o URI a un 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 di dimensioni maggiori.
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. Per meccanismi alternativi, consulta Memorizzazione di dati numerici di precisione arbitraria.
INT, INTEGER, SMALLINT INT64
BINARY_FLOAT, BINARY_DOUBLE FLOAT64
DATE DATE La rappresentazione STRING predefinita del tipo DATE di Spanner è yyyy-mm-dd, che è diversa da quella di Oracle, quindi fai attenzione quando esegui la conversione automatica da e verso le rappresentazioni STRING delle date. Le funzioni SQL sono fornite per convertire le date in una stringa formattata.
DATETIME TIMESTAMP Spanner memorizza il tempo indipendentemente dal fuso orario. Se devi memorizzare un fuso orario, devi utilizzare una colonna STRING separata. Sono disponibili funzioni SQL per convertire i timestamp in una stringa formattata utilizzando i fusi orari.
XML STRING (contenente dati o URI a un 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 Google Cloud alternative come Cloud Storage per archiviare oggetti di dimensioni maggiori.
URI, DBURI, XDBURI, HTTPURI STRING
ROWID PRIMARY KEY Spanner utilizza la chiave primaria della tabella per ordinare e fare riferimento alle righe internamente, quindi in Spanner è praticamente lo stesso del tipo di dato ROWID.
SDO_GEOMETRY, SDO_TOPO_GEOMETRY_SDO_GEORASTER   Spanner non supporta i tipi di dati geospaziali. Dovrai memorizzare questi dati utilizzando tipi di dati standard e implementare qualsiasi logica di ricerca e filtro nel livello di applicazione.
ORDAudio, ORDDicom, ORDDoc, ORDImage, ORDVideo, ORDImageSignature Spanner non supporta i tipi di dati multimediali. Valuta la possibilità di utilizzare Cloud Storage per archiviare i dati multimediali.

Processo di migrazione

Una sequenza temporale complessiva della procedura di migrazione è la seguente:

  1. Converti lo schema e modello dei dati.
  2. Tradurre eventuali query SQL.
  3. Esegui la migrazione dell'applicazione in modo che utilizzi Spanner oltre a Oracle.
  4. Esporta collettivamente i dati da Oracle e importali in Spanner utilizzando Dataflow.
  5. Mantieni la coerenza tra i due database durante la migrazione.
  6. Esegui la migrazione dell'applicazione da Oracle.

Passaggio 1: converti il database e lo schema

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

L'utilizzo delle best practice nella progettazione dello schema può aiutarti ad aumentare la velocità effettiva e a ridurre gli hot spot nel database Spanner.

Chiavi primarie

In Spanner, ogni tabella che deve memorizzare 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 di una tabella e le righe della tabella sono ordinate in base alla chiave primaria. Poiché Spanner è altamente distribuito, è importante scegliere una tecnica di generazione della 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 della chiave primaria né modificare un valore della 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 principali.

Intercala le tabelle

Spanner dispone di una funzionalità che consente di definire due tabelle come aventi una relazione padre-figlio uno a molti. In questo modo, le righe di dati figlio vengono interlacciate con la riga padre nello spazio di archiviazione, pre-unire efficacemente la tabella e migliorare l'efficienza del recupero dei dati quando vengono eseguite query su padre e figli 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 è indicata come chiave esterna. Puoi definire fino a 6 livelli di relazioni tra elementi principali e secondari.

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

Ecco un esempio di creazione di una tabella Album interlacciata nella tabella principale Cantanti 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;

Creare 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 nello stesso modo delle 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 dei valori che utilizzano gli indici secondari sono in pratica le stesse di una query con una join di tabelle. Puoi migliorare le prestazioni delle query che utilizzano gli indici memorizzando le copie dei valori delle colonne della tabella originale nell'indice secondario utilizzando la clausola STORING, rendendolo un indice che copre.

L'ottimizzatore delle query di Spanner utilizzerà automaticamente gli indici secondari solo quando l'indice stesso memorizza tutte le colonne su cui viene eseguita la query (una query coperta). Per forzare l'utilizzo di un indice durante l'esecuzione di query sulle colonne della 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 in quella colonna. L'indice impedirà l'aggiunta di valori duplicati.

Di seguito è riportato un esempio di istruzione DDL che crea un indice secondario per la tabella Albums:

CREATE INDEX AlbumsByAlbumTitle ON Albums(AlbumTitle);

Tieni presente che se crei altri indici dopo aver caricato i dati, l'inserimento dell'indice potrebbe richiedere del tempo. Dovresti limitare la frequenza di aggiunta 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 di indici, consulta Aggiornamenti dello schema.

Passaggio 2: traduci eventuali query SQL

Spanner utilizza il dialetto ANSI 2011 di SQL con estensioni, e dispone di molte funzioni e operatori per aiutarti a tradurre e aggregare i dati. Devi convertire le query SQL che utilizzano tipi, funzioni e sintassi specifici di Oracle in modo che siano 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, è possibile scrivere una query per restituire tutti gli album di un artista utilizzando un ARRAY di STRUCTs in una singola query (sfruttando i dati precombinati). Per ulteriori informazioni, consulta la sezione Note sulle sottoquery della documentazione.

Per eseguire il profiling delle query SQL, puoi utilizzare la pagina Spanner Studio nella Google Cloud Console. In generale, le query che eseguono scansioni complete delle tabelle su tabelle di grandi dimensioni sono molto costose e devono essere utilizzate con parsimonia.

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

Passaggio 3: esegui la migrazione dell'applicazione per l'utilizzo di Spanner

Spanner fornisce un insieme di librerie client per vari linguaggi e la possibilità di leggere e scrivere dati utilizzando chiamate API specifiche di Spanner, nonché query SQL e istruzioni Data Manipulation Language (DML). L'utilizzo delle chiamate API potrebbe essere più veloce per alcune query, come le letture di righe dirette per chiave, perché l'istruzione SQL non deve essere tradotta.

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

Nell'ambito del processo di migrazione, le funzionalità non disponibili in Spanner devono essere implementate nell'applicazione. Ad esempio, nell'applicazione deve essere implementato un attivatore per verificare i valori dei dati e aggiornare una tabella correlata 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, se stai leggendo una versione coerente dei dati specificati in questi modi:

  • In un momento esatto nel passato (fino a 1 ora fa).
  • In futuro (in cui la lettura verrà bloccata fino a quel momento).
  • Con un livello accettabile di inattualità limitata, che restituirà una visualizzazione coerente fino a un determinato momento nel passato senza dover verificare che i dati più recenti siano disponibili su un'altra replica. Ciò può offrire vantaggi in termini di prestazioni a scapito di dati potenzialmente obsoleti.

Passaggio 4: trasferisci i dati da Oracle a Spanner

Per trasferire i dati da Oracle a Spanner, dovrai esportare il database Oracle in un formato file portatile, ad esempio CSV, quindi importarli 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 scaricare l'intero database in un formato file portatile.

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

Queste includono:

Ognuno di questi ha lo svantaggio di poter esportare una sola tabella alla volta, il che significa che devi mettere in pausa l'applicazione o mettere in stato di riposo il database in modo che rimanga in uno stato coerente per l'esportazione.

Altre opzioni includono gli strumenti di terze parti elencati nella pagina Domande frequenti su Oracle, alcuni dei quali possono scaricare una vista coerente dell'intero database.

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

Importazione collettiva in Spanner

Poiché gli schemi di database probabilmente sono diversi tra Oracle e Spanner, potrebbe essere necessario eseguire alcune conversioni dei dati nell'ambito del processo di importazione.

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

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

L'SDK Apache Beam richiede di scrivere un semplice programma Java per impostare la lettura, la trasformazione e la scrittura dei dati. Esistono connettori Beam per Cloud Storage e Spanner, quindi l'unico codice da scrivere è la trasformazione degli stessi dati.

Consulta un esempio di una pipeline semplice che legge da file CSV e scrive in Spanner nel repository di codice di esempio allegato a questo articolo.

Se nello schema di Spanner vengono utilizzate tabelle interlacciate padre-figlio, è necessario prestare attenzione durante il processo di importazione in modo che la riga principale venga creata prima della riga secondaria. Il codice della pipeline di importazione di Spanner gestisce questo problema importando prima tutti i dati per le tabelle di primo livello, poi tutte le tabelle secondarie di primo livello, poi tutte le tabelle secondarie di secondo livello e così via.

La pipeline di importazione di Spanner può essere utilizzata direttamente per importare collettivamente i dati,ma è necessario che i dati esistano in file Avro che utilizzano lo schema corretto.

Passaggio 5: mantieni la coerenza tra i due database

Molte applicazioni hanno requisiti di disponibilità che rendono impossibile mantenere l'applicazione offline per il tempo necessario per esportare e importare i dati. Mentre trasferisci i dati a Spanner, la tua applicazione continua a modificare il database esistente. Devi duplicare gli aggiornamenti al database Spanner durante l'esecuzione dell'applicazione.

Esistono vari metodi per mantenere sincronizzati i due database, tra cui la funzionalità di acquisizione dei dati modificati e l'implementazione di aggiornamenti simultanei nell'applicazione.

Change Data Capture (CDC)

Oracle GoldenGate può fornire uno stream di acquisizione dei dati modificati (CDC) per il tuo database Oracle. Oracle LogMiner o Oracle XStream Out sono interfacce alternative per il database Oracle per ottenere uno stream CDC che non coinvolge Oracle GoldenGate.

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

  • Connessione al database Oracle (database di origine).
  • Connessione a Spanner (database di destinazione).
  • Esegui ripetutamente quanto segue:
    • Ricevere i dati prodotti da uno degli stream CDC del database Oracle.
    • Interpretazione dei dati prodotti dallo stream CDC.
    • Conversione dei dati in istruzioni INSERT di Spanner.
    • Eseguire le istruzioni INSERT di Spanner.

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

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

Puoi installare Striim da Google Cloud Marketplace, collegarti 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 dello stream.

Aggiornamenti simultanei di entrambi i database dall'applicazione

Un metodo alternativo consiste nel modificare l'applicazione in modo da eseguire scritture in entrambi i database. Un database (inizialmente Oracle) viene considerato la fonte di verità e, dopo ogni scrittura nel 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.

Una volta accertato che tutti i dati sono stati trasferiti correttamente, puoi cambiare l'origine attendibile nel database Spanner.

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

Verifica la coerenza dei dati

Quando i dati vengono inseriti nel database Spanner, puoi eseguire periodicamente un confronto tra i dati di Spanner e quelli di 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 Join. Questa trasformazione prende due set di dati con chiave e abbina i valori in base alla chiave. I valori corrispondenti possono quindi essere confrontati per verificare se sono uguali.

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

Passaggio 6: passa a Spanner come origine attendibile della tua applicazione

Quando hai la certezza che la migrazione dei dati sia andata a buon fine, puoi impostare la tua applicazione in modo che utilizzi Spanner come origine attendibile. Continua a scrivere le modifiche nel database Oracle per mantenerlo aggiornato, in modo da avere un percorso di rollback in caso di problemi.

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

Esportare e importare 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 vari scopi, tra cui:

  • Esegui il backup del database per la conformità alle norme sulla conservazione dei dati o per il recupero di emergenza.
  • Importazione del file Avro in altre offerte Google Cloud come BigQuery.

Per ulteriori informazioni sulla procedura di esportazione e importazione, consulta Esportare i database e Importare i database.

Passaggi successivi