Progettazione e prestazioni per le migrazioni Oracle

Questo articolo è la prima parte di una serie in sette parti che fornisce indicazioni su come eseguire la migrazione da Oracle ad Azure Synapse Analytics. L'obiettivo di questo articolo è illustrare le procedure consigliate per progettazione e prestazioni.

Panoramica

A causa dei costi e della complessità della gestione e dell'aggiornamento di ambienti Oracle locali legacy, molti utenti Oracle esistenti vogliono sfruttare le innovazioni offerte dagli ambienti cloud moderni. Gli ambienti cloud IaaS (Infrastructure-as-a-Service) e PaaS (Platform-as-a-Service) consentono di delegare attività come la manutenzione dell'infrastruttura e lo sviluppo della piattaforma al provider di servizi cloud.

Anche se Oracle e Azure Synapse Analytics sono entrambi database SQL che usano tecniche di elaborazione parallela elevata (MPP) per ottenere prestazioni di query elevate su volumi di dati di dimensioni eccezionali, esistono alcune differenze di base nell'approccio:

• I sistemi Oracle legacy vengono spesso installati in locale e usano hardware relativamente costoso, mentre Azure Synapse è basato sul cloud e usa archiviazione e risorse di calcolo di Azure.

• L'aggiornamento di una configurazione Oracle è un'operazione impegnativa, che richiede hardware fisico aggiuntivo e processi di dump e ricaricamento o di riconfigurazione del database potenzialmente lunghi. Poiché le risorse di archiviazione e calcolo sono separate nell'ambiente Azure e hanno funzionalità di scalabilità elastica, tali risorse possono essere ridimensionate verso l'alto o verso il basso in modo indipendente.

• È possibile sospendere o ridimensionare Azure Synapse in base alle esigenze per ridurre l'utilizzo e i costi delle risorse.

Microsoft Azure è un ambiente cloud disponibile a livello globale, altamente sicuro e scalabile, che include Azure Synapse all'interno di un ecosistema di strumenti e funzionalità di supporto. Il diagramma seguente riepiloga l'ecosistema Azure Synapse.

Azure Synapse offre prestazioni ottimali del database relazionale usando tecniche come MPP e di memorizzazione nella cache automatizzata in memoria. I risultati di queste tecniche possono essere verificati in benchmark indipendenti, ad esempio quello eseguito di recente da GigaOm, che confronta Azure Synapse con altre offerte diffuse di data warehouse sul cloud. I clienti che eseguono la migrazione all'ambiente Azure Synapse ottengono molti vantaggi, tra cui:

• Prestazioni più elevate e rapporto prezzo/prestazioni migliorato.

• Maggiore agilità e time-to-value più breve.

• Procedure più rapide di distribuzione di server e sviluppo di applicazioni.

• Scalabilità elastica, pagando solo per l'utilizzo effettivo.

• Sicurezza e conformità migliorate.

• Riduzione dei costi di archiviazione e ripristino di emergenza.

• Riduzione del costo totale di proprietà, migliore controllo dei costi e riduzione delle spese operative (OPEX).

Per ottimizzare questi vantaggi, eseguire la migrazione di dati e applicazioni nuovi o esistenti alla piattaforma Azure Synapse. In molte organizzazioni la migrazione include lo spostamento di un data warehouse esistente da una piattaforma locale legacy, ad esempio Oracle, ad Azure Synapse. A livello generale, il processo di migrazione include questi passaggi:

Questo articolo fornisce informazioni generali e linee guida per l'ottimizzazione delle prestazioni durante la migrazione di un data warehouse da un ambiente Oracle esistente ad Azure Synapse. L'obiettivo dell'ottimizzazione delle prestazioni è ottenere le stesse prestazioni del data warehouse in Azure Synapse dopo la migrazione.

Considerazioni relative alla progettazione

Ambito migrazione

Quando si prepara la migrazione da un ambiente Oracle, prendere in considerazione le opzioni di migrazione seguenti.

Scegliere il carico di lavoro per la migrazione iniziale

In genere, gli ambienti Oracle legacy si sono evoluti nel tempo per includere più aree soggette e carichi di lavoro misti. Quando si decide dove iniziare un progetto di migrazione, scegliere un'area in cui sarà possibile:

• Dimostrare l'efficacia della migrazione ad Azure Synapse concretizzando rapidamente i vantaggi del nuovo ambiente.

• Consentire al personale tecnico interno di acquisire esperienza pertinente con i processi e gli strumenti che userà per eseguire la migrazione di altre aree.

• Creare un modello per altre migrazioni specifiche per l'ambiente Oracle di origine e gli strumenti e i processi correnti già presenti.

Un buon candidato per una migrazione iniziale da un ambiente Oracle supporta gli elementi precedenti e:

• Implementa un carico di lavoro BI/Analytics anziché un carico di lavoro OLTP (Online Transaction Processing).

• Dispone di un modello di dati, ad esempio uno schema star o snowflake, di cui è possibile eseguire la migrazione con una modifica minima.

Il volume dei dati trasferiti in una migrazione iniziale deve essere sufficientemente grande da illustrare le funzionalità e i vantaggi dell'ambiente Azure Synapse, ma non troppo grande da dimostrare rapidamente il valore. Una dimensione nell'intervallo da 1 a 10 terabyte è tipica.

Un approccio iniziale a un progetto di migrazione consiste nel ridurre al minimo il rischio, il lavoro e il tempo necessario in modo da poter visualizzare rapidamente i vantaggi dell'ambiente cloud di Azure. I seguenti approcci limitano l'ambito della migrazione iniziale solo ai data mart e non affrontano aspetti di migrazione più ampi, ad esempio la migrazione ETL e la migrazione cronologica dei dati. Tuttavia, è possibile risolvere questi aspetti nelle fasi successive del progetto dopo che il livello data mart migrato viene riempito di dati e dei processi di compilazione necessari.

Migrazione "Lift and shift" e approccio in più fasi

In generale, esistono due tipi di migrazione indipendentemente dallo scopo e dall'ambito della migrazione pianificata: "lift and shift" (così com'è) e un approccio in più fasi che incorpora le modifiche.

Modalità lift-and-shift

In una migrazione "lift and shift", un modello di dati esistente, come uno schema star, viene sottoposto a migrazione senza modifiche alla nuova piattaforma Azure Synapse. Questo approccio riduce al minimo i rischi e i tempi di migrazione diminuendo il lavoro necessario per sfruttare i vantaggi del passaggio all'ambiente cloud di Azure. La migrazione lift-and-shift è ideale per questi scenari:

• È disponibile un ambiente Oracle esistente con un singolo data mart di cui eseguire la migrazione o
• Si dispone di un ambiente Oracle esistente con dati già presenti in uno schema star o snowflake ben progettato oppure
• Si hanno pressioni in termini di tempo e costi per passare a un ambiente cloud moderno.

Approccio in più fasi che incorpora le modifiche

Se un data warehouse legacy si è evoluto in un lungo periodo di tempo, potrebbe essere necessario riprogettarlo per mantenere i livelli di prestazioni necessari. Potrebbe anche essere necessario riprogettare per supportare nuovi dati, ad esempio flussi IoT (Internet delle cose). Come parte del processo di re-engineering, eseguire la migrazione ad Azure Synapse per ottenere i vantaggi di un ambiente cloud scalabile. La migrazione può includere una modifica nel modello di dati sottostante, ad esempio uno spostamento da un modello Inmon a un insieme di credenziali dei dati.

Microsoft consiglia di spostare il modello di dati esistente così com'è in Azure e di sfruttare le prestazioni e la flessibilità dell'ambiente Azure per applicare le modifiche di nuova progettazione. In questo modo, è possibile usare le funzionalità di Azure per apportare le modifiche senza influire sul sistema di origine esistente.

Usare le strutture Microsoft per implementare una migrazione basata sui metadati

È possibile automatizzare e orchestrare il processo di migrazione usando le funzionalità dell'ambiente Azure. Questo approccio riduce al minimo l'impatto sulle prestazioni nell'ambiente Oracle esistente, che potrebbe essere già aver quasi raggiunto il limite di capacità.

SQL Server Migration Assistant (SSMA) per Oracle può automatizzare molte parti del processo di migrazione, tra cui in alcuni casi funzioni e codice procedurale. SSMA supporta Azure Synapse come ambiente di destinazione.

SSMA per Oracle consente di eseguire la migrazione di un data warehouse o un data mart di Oracle ad Azure Synapse. SSMA è progettato per automatizzare il processo di migrazione di tabelle, viste e dati da un ambiente Oracle esistente.

Azure Data Factory è un servizio di integrazione di dati basato sul cloud che consente di creare flussi di lavoro basati sui dati nel cloud che orchestrano e automatizzano lo spostamento e la trasformazione dei dati stessi. È possibile usare Data Factory per creare e pianificare flussi di lavoro basati sui dati (pipeline) che inseriscono dati da archivi dati diversi. Data Factory può elaborare e trasformare i dati usando servizi di calcolo, ad esempio Azure HDInsight Hadoop, Spark, Azure Data Lake Analytics e Azure Machine Learning.

Data Factory può essere usato per eseguire la migrazione dei dati all'origine alla destinazione SQL di Azure. Questo spostamento dei dati offline consente di ridurre significativamente i tempi di inattività della migrazione.

Servizi Migrazione del database di Azure consente di pianificare ed eseguire una migrazione da ambienti come Oracle.

Quando si prevede di usare le funzionalità di Azure per gestire il processo di migrazione, creare metadati che elenchino tutte le tabelle di dati di cui eseguire la migrazione e la relativa posizione.

Differenze di progettazione tra Oracle e Azure Synapse

Come accennato in precedenza, esistono alcune differenze di base nell'approccio tra i database Oracle e Azure Synapse Analytics. SSMA per Oracle non solo consente di colmare queste lacune, ma automatizza anche la migrazione. Anche se SSMA non è l'approccio più efficiente per volumi molto elevati di dati, è utile per le tabelle più piccole.

Più database rispetto a un singolo database e schemi

L'ambiente Oracle spesso contiene più database separati. Ad esempio, potrebbero essere presenti database separati per: tabelle di inserimento dati e gestione temporanea, tabelle di core warehouse e data mart (talvolta definiti livello semantico). I processi di pipeline ETL o ELT possono implementare join tra database e spostare i dati tra i database separati.

Al contrario, l'ambiente Azure Synapse contiene un singolo database e usa schemi per separare le tabelle in gruppi separati logicamente. È consigliabile usare una serie di schemi all'interno del database di Azure Synapse di destinazione per simulare i database separati migrati dall'ambiente Oracle. Se si usano già schemi nell'ambiente Oracle, potrebbe essere necessario usare una nuova convenzione di denominazione per spostare le tabelle e le viste Oracle esistenti nel nuovo ambiente. Ad esempio, è possibile concatenare i nomi di tabella e schema Oracle esistenti nel nuovo nome della tabella Azure Synapse e quindi usare i nomi dello schema nel nuovo ambiente per mantenere i nomi originali dei database distinti. Sebbene sia possibile usare viste SQL sopra le tabelle sottostanti per gestire le strutture logiche, esistono potenziali svantaggi per questo approccio:

• Le viste in Azure Synapse sono di sola lettura. È quindi necessario apportare eventuali aggiornamenti ai dati nelle tabelle di base sottostanti.

• Potrebbero essere già presenti uno o più livelli di visualizzazioni e l'aggiunta di un ulteriore livello potrebbe influire sulle prestazioni.

Considerazioni sulle tabelle

Quando si esegue la migrazione di tabelle tra ambienti diversi, in genere vengono trasferiti solo i dati non elaborati e i metadati che li descrivono fisicamente. Altri elementi di database del sistema di origine, ad esempio gli indici, in genere non vengono trasferiti perché potrebbero non essere necessari o potrebbero essere implementati in modo diverso nel nuovo ambiente.

Le ottimizzazioni delle prestazioni nell'ambiente di origine, ad esempio gli indici, indicano dove è possibile aggiungere l'ottimizzazione delle prestazioni nel nuovo ambiente. Ad esempio, se le query nell'ambiente Oracle di origine usano spesso indici bitmap, ciò suggerisce che debba essere creato un indice non cluster all'interno di Azure Synapse. Altre tecniche di ottimizzazione delle prestazioni native, ad esempio la replica di tabelle, possono essere più applicabili rispetto alla creazione di indici simili a quelle di tipo semplice. SSMA per Oracle può essere usato per fornire raccomandazioni sulla migrazione per la distribuzione e l'indicizzazione delle tabelle.

Tipi di oggetto di database Oracle non supportati

Le funzionalità specifiche di Oracle possono spesso essere sostituite dalle funzionalità di Azure Synapse. Tuttavia, alcuni oggetti di database Oracle non sono supportati direttamente in Azure Synapse. L'elenco seguente di oggetti di database Oracle non supportati descrive come ottenere una funzionalità equivalente in Azure Synapse.

• Varie opzioni di indicizzazione: in Oracle, diverse opzioni di indicizzazione, ad esempio indici bitmap, indici basati sulle funzioni e indici di dominio, non hanno equivalenti diretti in Azure Synapse.

  È possibile individuare le colonne indicizzate e il tipo di indice:

  • Eseguendo query su tabelle e viste del catalogo di sistema, ad esempio ALL_INDEXES, DBA_INDEXES, USER_INDEXES e DBA_IND_COL. È possibile usare le query predefinite in Oracle SQL Developer, come illustrato nello screenshot seguente.

    

    In alternativa, eseguire la query seguente per trovare tutti gli indici di un determinato tipo:

    SELECT * FROM dba_indexes WHERE index_type LIKE 'FUNCTION-BASED%';
    

  • Eseguendo query sulle viste dba_index_usage o v$object_usage quando il monitoraggio è abilitato. È possibile eseguire query su tali viste in Oracle SQL Developer, come illustrato nello screenshot seguente.

    

  Gli indici basati sulle funzioni, in cui l'indice contiene il risultato di una funzione nelle colonne di dati sottostanti, non hanno equivalenti diretti in Azure Synapse. È consigliabile eseguire prima di tutto la migrazione dei dati, quindi in Azure Synapse eseguire le query Oracle che usano indici basati sulle funzioni per misurare le prestazioni. Se le prestazioni di tali query in Azure Synapse non sono accettabili, è consigliabile creare una colonna contenente il valore precalco calcolato e quindi indicizzare tale colonna.

  Quando si configura l'ambiente Azure Synapse, è opportuno implementare solo gli indici in uso. Azure Synapse supporta attualmente i tipi di indice illustrati di seguito:

  

  Le funzionalità di Azure Synapse, ad esempio l'elaborazione parallela delle query e la memorizzazione nella cache dei dati e dei risultati, rendono probabile la necessità di un minor numero di indici per le applicazioni di data warehouse per raggiungere gli obiettivi di prestazioni. È consigliabile usare i tipi di indice seguenti in Azure Synapse:

  • Indici columnstore cluster: quando non vengono specificate opzioni di indice per una tabella, Azure Synapse per impostazione predefinita crea un indice columnstore cluster. Le tabelle columnstore cluster offrono il massimo livello di compressione dei dati, le migliori prestazioni generali delle query e in genere offrono prestazioni migliori rispetto agli indici cluster o alle tabelle heap. Un indice columnstore cluster è in genere la scelta migliore per le tabelle di grandi dimensioni. Quando si crea una tabella, scegliere columnstore cluster se non si è certi di come indicizzare la tabella. Esistono tuttavia alcuni scenari in cui gli indici columnstore cluster non sono l'opzione migliore:

    • Le tabelle con dati preordinati in base a una o più chiavi di ordinamento possono trarre vantaggio dall'eliminazione dei segmenti consentita dagli indice columnstore cluster ordinati.
    • Tabelle con tipi di dati varchar(max), nvarchar(max) o varbinary(max), perché un indice columnstore cluster non supporta tali tipi di dati. Prendere invece in considerazione l'uso di un heap o di un indice cluster.
    • Le tabelle con dati temporanei, perché le tabelle columnstore potrebbero risultare meno efficienti rispetto alle tabelle heap o temporanee.
    • Tabelle di piccole dimensioni con meno di 100 milioni di righe. In alternativa, valutare la possibilità di usare le tabelle heap.

  • Indici columnstore cluster ordinati: abilitando l'eliminazione efficiente dei segmenti, gli indici columnstore cluster ordinati nei pool SQL dedicati di Azure Synapse offrono prestazioni molto più veloci ignorando grandi quantità di dati ordinati che non corrispondono al predicato di query. Il caricamento dei dati in una tabella con CCI ordinato può richiedere più tempo rispetto a una tabella con CCI non ordinato a causa dell'operazione di ordinamento dei dati, tuttavia le query possono essere eseguite più velocemente in seguito con un CCI ordinato. Per altre informazioni sugli indici columnstore cluster ordinati, vedere Ottimizzazione delle prestazioni con indici columnstore cluster ordinati.

  • Indici cluster e non cluster: gli indici cluster possono offrire prestazioni migliori rispetto agli indici columnstore cluster quando è necessario recuperare rapidamente una singola riga. Per le query in cui la ricerca di una singola riga o di un numero ridotto di righe deve essere eseguita in modo estremamente rapido, è consigliabile usare un indice cluster o un indice secondario non cluster. Lo svantaggio dell'uso di un indice cluster è che solo le query con un filtro altamente selettivo sulla colonna dell'indice cluster saranno utili. Per migliorare il filtro in base ad altre colonne, è possibile aggiungere un indice non cluster alle altre colonne. Tuttavia, ogni indice aggiunto a una tabella usa più spazio e aumenta il tempo di elaborazione necessario per il caricamento.

  • Tabelle heap: quando si inseriscono temporaneamente i dati in Azure Synapse, è possibile che l'uso di una tabella heap renda più veloce il processo complessivo. Ciò è dovuto al fatto che il caricamento dei dati nelle tabelle heap è più veloce del caricamento dei dati nelle tabelle di indicizzazione e in alcuni casi è possibile eseguire letture successive dalla cache. Se si caricano i dati solo per inserirli temporaneamente prima di eseguire altre trasformazioni, è molto più rapido caricarli in una tabella heap rispetto a una tabella columnstore cluster. Inoltre, il caricamento dei dati in una tabella temporanea risulta più veloce del caricamento di una tabella in un archivio permanente. Per le tabelle di ricerca di piccole dimensioni con meno di 100 milioni di righe, le tabelle heap sono in genere la scelta giusta. Le tabelle columnstore cluster iniziano a raggiungere la compressione ottimale quando contengono oltre 100 milioni di righe.

• Tabelle cluster: le tabelle Oracle possono essere organizzate in modo che le righe della tabella a cui si accede di frequente (in base a un valore comune) vengano archiviate fisicamente insieme per ridurre l'I/O del disco quando vengono recuperati i dati. Oracle offre anche un'opzione hash-cluster per le singole tabelle, che applica un valore hash alla chiave del cluster e archivia fisicamente le righe con lo stesso valore hash insieme. Per elencare i cluster all'interno di un database Oracle, usare la query SELECT * FROM DBA_CLUSTERS;. Per determinare se una tabella si trova all'interno di un cluster, usare la query SELECT * FROM TAB;, che mostra il nome della tabella e l'ID cluster per ogni tabella.

  In Azure Synapse è possibile ottenere risultati simili usando tabelle materializzate e/o replicate, perché tali tipi di tabella riducono al minimo l'I/O necessario in fase di esecuzione della query.

• Viste materializzate: Oracle supporta le viste materializzate e consiglia di usarne una o più per le tabelle di grandi dimensioni con molte colonne in cui solo poche colonne vengono usate regolarmente nelle query. Le viste materializzate vengono aggiornate automaticamente dal sistema quando i dati nella tabella di base vengono aggiornati.

  Nel 2019 Microsoft ha annunciato che Azure Synapse supporterà le viste materializzate con le stesse funzionalità di Oracle. Le viste materializzate sono ora una funzionalità di anteprima in Azure Synapse.

• Trigger nel database: in Oracle un trigger può essere configurato per l'esecuzione automatica quando si verifica un evento di attivazione. Gli eventi di attivazione possono essere:

  • Viene eseguita un'istruzione DML (Data Manipulation Language), ad esempio INSERT, UPDATE o DELETE, in una tabella. Se è stato definito un trigger che viene generato prima di un'istruzione INSERT in una tabella Customer, il trigger verrà generato una volta prima che venga inserita una nuova riga nella tabella Customer.

  • Viene eseguita un'istruzione DDL, ad esempio CREATE o ALTER. Questo trigger viene spesso usato a scopo di controllo per registrare le modifiche dello schema.

  • Un evento di sistema, ad esempio l'avvio o l'arresto del database Oracle.

  • Un evento utente, ad esempio l'accesso o l'uscita.

  È possibile ottenere un elenco dei trigger definiti in un database Oracle eseguendo una query sulle viste ALL_TRIGGERS, DBA_TRIGGERS o USER_TRIGGERS. Lo screenshot seguente mostra una query DBA_TRIGGERS in Oracle SQL Developer.

  

  Azure Synapse non supporta i trigger di database Oracle. Tuttavia, è possibile aggiungere funzionalità equivalenti usando Data Factory, anche se in questo modo sarà necessario effettuare il refactoring dei processi che usano trigger.

• Sinonimi: Oracle supporta la definizione di sinonimi come nomi alternativi per diversi tipi di oggetto di database. Tali tipi di oggetto includono: tabelle, viste, sequenze, procedure, funzioni archiviate, pacchetti, viste materializzate, oggetti dello schema di classe Java, oggetti definiti dall'utente o un altro sinonimo.

  Azure Synapse attualmente non supporta la definizione di sinonimi, anche se un sinonimo in Oracle fa riferimento a una tabella o a una vista, è possibile definire una vista in Azure Synapse in modo che corrisponda al nome alternativo. Se un sinonimo in Oracle fa riferimento a una funzione o a una stored procedure, in Azure Synapse è possibile creare un'altra funzione o una stored procedure con un nome che corrisponda al sinonimo, che chiama la destinazione.

• Tipi definiti dall'utente: Oracle supporta oggetti definiti dall'utente che possono contenere una serie di singoli campi, ognuno con la propria definizione e valori predefiniti. È possibile fare riferimento a tali oggetti all'interno di una definizione di tabella allo stesso modo dei tipi di dati predefiniti, ad esempio NUMBER o VARCHAR. È possibile ottenere un elenco di tipi definiti dall'utente all'interno di un database Oracle eseguendo una query sulle viste ALL_TYPES, DBA_TYPES o USER_TYPES.

  Azure Synapse attualmente non supporta i tipi definiti dall'utente. Se i dati di cui è necessario eseguire la migrazione includono tipi di dati definiti dall'utente, "appiattirli" in una definizione di tabella convenzionale o se sono matrici di dati, normalizzarli in una tabella separata.

Mapping dei tipi di dati Oracle

La maggior parte dei tipi di dati Oracle ha un equivalente diretto in Azure Synapse. La tabella seguente illustra l'approccio consigliato per il mapping dei tipi di dati Oracle ad Azure Synapse.

Oracle supporta anche la definizione di oggetti definiti dall'utente che possono contenere una serie di singoli campi, ognuno con la propria definizione e valori predefiniti. È quindi possibile fare riferimento a tali oggetti all'interno di una definizione di tabella allo stesso modo dei tipi di dati predefiniti, ad esempio NUMBER o VARCHAR. Azure Synapse attualmente non supporta i tipi definiti dall'utente. Se i dati di cui è necessario eseguire la migrazione includono tipi di dati definiti dall'utente, "appiattirli" in una definizione di tabella convenzionale o se sono matrici di dati, normalizzarli in una tabella separata.

I fornitori di terze parti offrono strumenti e servizi per automatizzare la migrazione, incluso il mapping dei tipi di dati. Se uno strumento ETL di terze parti è già in uso nell'ambiente Oracle, usarlo per implementare le trasformazioni dei dati necessarie.

Differenze di sintassi SQL DML

Esistono differenze di sintassi SQL DML tra Oracle SQL e Azure Synapse T-SQL. Tali differenze sono descritte in dettaglio in Ridurre al minimo i problemi di SQL per le migrazioni di Oracle. In alcuni casi, è possibile automatizzare la migrazione DML usando strumenti Microsoft come SSMA per Oracle e Servizio Migrazione del database di Azure oppure prodotti e servizi di migrazione di terze parti.

Funzioni, stored procedure e sequenze

Quando si esegue la migrazione di un data warehouse da un ambiente maturo come Oracle, è probabile che sia necessario eseguire la migrazione di elementi diversi da tabelle e viste semplici. Controllare se gli strumenti all'interno dell'ambiente Azure possono sostituire le funzionalità di funzioni, stored procedure e sequenze perché in genere è più efficiente usare gli strumenti predefiniti di Azure rispetto a ricodificarli per Azure Synapse.

Come parte della fase di preparazione, creare un inventario di oggetti di cui è necessario eseguire la migrazione, definire un metodo per gestirli e allocare risorse appropriate nel piano di migrazione.

Strumenti Microsoft come SSMA per Oracle e Servizio Migrazione del database di Azure oppure prodotti e servizi di migrazione di terze parti possono automatizzare la migrazione di funzioni, stored procedure e sequenze.

Le sezioni seguenti illustrano ulteriormente la migrazione di funzioni, stored procedure e sequenze.

Funzioni

Come per la maggior parte dei prodotti di database, Oracle supporta funzioni definite dall'utente e di sistema all'interno di un'implementazione SQL. Quando si esegue la migrazione di una piattaforma di database legacy ad Azure Synapse, è in genere possibile eseguire la migrazione di funzioni di sistema comuni senza modifiche. Alcune funzioni di sistema potrebbero avere una sintassi leggermente diversa, ma tutte le modifiche necessarie possono essere automatizzate. È possibile ottenere un elenco di funzioni all'interno di un database Oracle eseguendo una query sulla vista ALL_OBJECTS con la clausola WHERE appropriata. È possibile usare Oracle SQL Developer per ottenere un elenco di funzioni, come illustrato nello screenshot seguente.

Per le funzioni di sistema Oracle o le funzioni arbitrarie definite dall'utente che non hanno equivalenti in Azure Synapse, ricodificarle usando un linguaggio di ambiente di destinazione. Le funzioni definite dall'utente Oracle vengono codificate in PL/SQL, Java o C. Azure Synapse usa il linguaggio Transact-SQL per implementare funzioni definite dall'utente.

Stored procedure

La maggior parte dei prodotti di database moderni supporta l'archiviazione delle procedure all'interno del database. Oracle offre il linguaggio PL/SQL a questo scopo. Una stored procedure contiene in genere istruzioni SQL e logica procedurale e restituisce dati o uno stato. È possibile ottenere un elenco di stored procedure all'interno di un database Oracle eseguendo una query sulla vista ALL_OBJECTS con la clausola WHERE appropriata. È possibile usare Oracle SQL Developer per ottenere un elenco di stored procedure, come illustrato nello screenshot successivo.

Azure Synapse supporta stored procedure con T-SQL, quindi sarà necessario codificare tutte le stored procedure sottoposte a migrazione in tale linguaggio.

Sequenze

In Oracle una sequenza è un oggetto di database denominato, creato tramite CREATE SEQUENCE. Una sequenza offre valori numerici univoci tramite i metodi CURRVAL e NEXTVAL. È possibile usare i numeri univoci generati come valori di chiave surrogata per le chiavi primarie.

Azure Synapse non implementa CREATE SEQUENCE, ma è possibile implementare sequenze usando colonne IDENTITY o codice SQL che genera il numero di sequenza successivo in una serie.

Estrazione di metadati e dati da un ambiente Oracle

Generazione di Data Definition Language

Lo standard SQL ANSI definisce la sintassi di base per i comandi DDL (Data Definition Language). Alcuni comandi DDL, ad esempio CREATE TABLE e CREATE VIEW, sono comuni sia a Oracle che ad Azure Synapse, ma forniscono anche funzionalità specifiche dell'implementazione, ad esempio l'indicizzazione, la distribuzione delle tabelle e le opzioni di partizionamento.

È possibile modificare gli script CREATE TABLE e CREATE VIEW di Oracle esistenti per ottenere definizioni equivalenti in Azure Synapse. A tale scopo, potrebbe essere necessario usare tipi di dati modificati e rimuovere o modificare clausole specifiche di Oracle, ad esempio TABLESPACE.

All'interno dell'ambiente Oracle, le tabelle del catalogo di sistema specificano la definizione di tabella e vista corrente. A differenza della documentazione gestita dall'utente, le informazioni sul catalogo di sistema sono sempre complete e sincronizzate con le definizioni di tabella correnti. È possibile accedere alle informazioni del catalogo di sistema usando utilità come Oracle SQL Developer. Oracle SQL Developer può generare istruzioni DDL CREATE TABLE che è possibile modificare per creare tabelle equivalenti in Azure Synapse.

In alternativa, è possibile usare SSMA per Oracle per eseguire la migrazione di tabelle da un ambiente Oracle esistente ad Azure Synapse. SSMA per Oracle applicherà i mapping dei tipi di dati appropriati e i tipi di tabella e distribuzione consigliati, come illustrato nello screenshot seguente.

È anche possibile usare strumenti di migrazione ed ETL di terze parti che elaborano le informazioni del catalogo di sistema per ottenere risultati simili.

Estrazione dei dati da Oracle

È possibile estrarre dati di tabella non elaborati da tabelle Oracle a file delimitati flat, ad esempio file CSV, usando utilità Oracle standard come Oracle SQL Developer, SQL*Plus e SCLcl. È quindi possibile comprimere i file delimitati flat usando gzip e caricare i file compressi in Archiviazione BLOB di Azure usando AzCopy o strumenti di trasporto dati di Azure come Azure Data Box.

Estrarre i dati della tabella nel modo più efficiente possibile, soprattutto quando si esegue la migrazione di tabelle dei fatti di grandi dimensioni. Per le tabelle Oracle, usare il parallelismo per ottimizzare la velocità effettiva di estrazione. È possibile ottenere il parallelismo eseguendo più processi che estraggono singolarmente segmenti discreti di dati o usando strumenti in grado di automatizzare l'estrazione parallela tramite il partizionamento.

Se è disponibile una larghezza di banda di rete sufficiente, è possibile estrarre i dati da un sistema Oracle locale direttamente in tabelle di Azure Synapse o in Archiviazione dati BLOB di Azure. A tale scopo, usare processi di Data Factory, il Servizio Migrazione del database di Azure o la migrazione dei dati di terze parti o prodotti ETL.

I file di dati estratti devono contenere testo delimitato in formato CSV, ORC (Optimized Row Columnar) o Parquet.

Per altre informazioni sulla migrazione dei dati e dell'ETL da un ambiente Oracle, vedere Migrazione dei dati, ETL e caricamento per le migrazioni Oracle.

Consigli per le prestazioni per le migrazioni Oracle

L'obiettivo dell'ottimizzazione delle prestazioni è far sì che queste siano identiche o migliori dopo la migrazione ad Azure Synapse.

Analogie nei concetti relativi all'approccio di ottimizzazione delle prestazioni

Molti concetti di ottimizzazione delle prestazioni per i database Oracle sono veri anche per i database di Azure Synapse. Ad esempio:

• Usare la distribuzione dei dati per collocare i dati da aggiungere allo stesso nodo di elaborazione.

• Usare il tipo di dati più piccolo per una determinata colonna per risparmiare spazio di archiviazione e accelerare l'elaborazione delle query.

• Assicurarsi che le colonne da unire abbiano lo stesso tipo di dati per ottimizzare l'elaborazione dei join e ridurre la necessità di trasformazioni di dati.

• Per aiutare l'utilità di ottimizzazione a produrre il piano di esecuzione migliore, assicurarsi che le statistiche siano aggiornate.

• Monitorare le prestazioni usando le funzionalità predefinite del database per assicurarsi che le risorse vengano usate in modo efficiente.

Differenze nell'approccio di ottimizzazione delle prestazioni

Questa sezione illustra le differenze di implementazione dell'ottimizzazione delle prestazioni di basso livello tra Oracle e Azure Synapse.

Opzioni di distribuzione dei dati

Per le prestazioni, Azure Synapse è stato progettato con l'architettura a più nodi e usa l'elaborazione parallela. Per ottimizzare le prestazioni delle tabelle in Azure Synapse, è possibile definire un'opzione di distribuzione dei dati nelle istruzioni CREATE TABLE usando l'istruzione DISTRIBUTION. Ad esempio, è possibile specificare una tabella con distribuzione hash, che distribuisce le righe di tabella tra i nodi di calcolo usando una funzione hash deterministica. Molte implementazioni di Oracle, in particolare i sistemi locali meno recenti, non supportano questa funzionalità.

A differenza di Oracle, Azure Synapse supporta i join locali tra una tabella di piccole dimensioni e una tabella di grandi dimensioni tramite la replica di tabelle di piccole dimensioni. Si consideri, ad esempio, una tabella di piccole dimensioni e una tabella dei fatti di grandi dimensioni all'interno di un modello di schema star. Azure Synapse può replicare la tabella delle dimensioni più piccole in tutti i nodi per garantire che il valore di qualsiasi chiave di join per la tabella di grandi dimensioni abbia una riga di dimensione corrispondente disponibile in locale. Il sovraccarico della replica della tabella delle dimensioni è relativamente basso per una di piccole dimensioni. Per le tabelle di grandi dimensioni, un approccio alla distribuzione hash è più appropriato. Per altre informazioni sulle opzioni di distribuzione dei dati, vedere Linee guida sulla progettazione per l'uso di tabelle replicate e Linee guida per la progettazione di tabelle distribuite.

La distribuzione hash può essere applicata a più colonne per una distribuzione più uniforme della tabella di base. La distribuzione a più colonne consentirà di scegliere fino a otto colonne per la distribuzione. Ciò non solo riduce l'asimmetria dei dati nel tempo, ma migliora anche le prestazioni delle query.

Distribution Advisor

In Azure Synapse SQL è possibile personalizzare ogni tabella. La strategia di distribuzione della tabella influisce sostanzialmente sulle prestazioni delle query.

Distribution Advisor è una nuova funzionalità di Synapse SQL che analizza le query e consiglia le migliori strategie di distribuzione per le tabelle per migliorare le prestazioni delle query. Le query che devono essere considerate da Advisor possono essere fornite dall'utente o estratte dalle query cronologiche disponibili nella DMV.

Per informazioni dettagliate ed esempi su come usare Distribution Advisor, visitare Distribution Advisor in Azure Synapse SQL.

Indicizzazione dei dati

Azure Synapse supporta diverse opzioni di indicizzazione definibili dall'utente con un'operazione e un utilizzo diversi rispetto alle mappe delle zone gestite dal sistema in Oracle. Per altre informazioni sulle diverse opzioni di indicizzazione in Azure Synapse, vedere Indici nelle tabelle del pool SQL dedicato.

Le definizioni di indici all'interno di un ambiente Oracle di origine forniscono un'indicazione utile dell'utilizzo dei dati e delle colonne candidate per l'indicizzazione nell'ambiente Azure Synapse. In genere, non è necessario eseguire la migrazione di ogni indice da un ambiente Oracle legacy perché Azure Synapse non si basa sugli indici e implementa le funzionalità seguenti per ottenere prestazioni eccezionali:

• Elaborazione parallela di query.

• Memorizzazione nella cache dei dati in memoria e del set di risultati.

• Distribuzione dei dati, ad esempio la replica di tabelle di piccole dimensioni, per ridurre le operazioni di I/O.

Partizionamento dei dati

In un data warehouse aziendale le tabelle dei fatti possono contenere miliardi di righe. Il partizionamento ottimizza la manutenzione e l'esecuzione di query di queste tabelle suddividendole in parti separate per ridurre la quantità di dati elaborati. In Azure Synapse l'istruzione CREATE TABLE definisce la specifica di partizionamento per una tabella.

È possibile usare un solo campo per tabella per il partizionamento. Questo campo è spesso un campo data perché molte query vengono filtrate in base alla data o a un intervallo di date. È possibile modificare il partizionamento di una tabella dopo il caricamento iniziale usando l'istruzione CREATE TABLE AS (CTAS) per ricreare la tabella con una nuova distribuzione. Per una descrizione dettagliata del partizionamento in Azure Synapse, vedere Tabelle di partizionamento nel pool SQL dedicato.

PolyBase o COPY INTO per il caricamento dei dati

PolyBase supporta un caricamento efficiente di grandi quantità di dati in un data warehouse usando flussi di caricamento paralleli. Per altre informazioni, vedere Strategia di caricamento dei dati PolyBase.

COPY INTO supporta anche l'inserimento dati con velocità effettiva elevata e:

• Recupero dei dati da tutti i file all'interno di una cartella e sottocartelle.
• Recupero dei dati da più posizioni nello stesso account di archiviazione. È possibile specificare più posizioni usando percorsi delimitati da virgole.
• Azure Data Lake Storage (ADLS) e Archiviazione BLOB di Azure.
• Formati di file CSV, PARQUET e ORC.

Gestione dei carichi di lavoro

L'esecuzione di carichi di lavoro misti può causare problemi di risorse nei sistemi sovraccarichi. Uno schema corretto di gestione del carico di lavoro comporta una gestione efficace delle risorse, ne assicura l'utilizzo altamente efficiente e massimizza il ritorno sugli investimenti. Classificazione del carico di lavoro, importanza del carico di lavoro e isolamento del carico di lavoro per dare maggiore controllo sul modo in cui il carico di lavoro usa le risorse di sistema.

La guida alla gestione del carico di lavoro descrive le tecniche per analizzare il carico di lavoro, gestire e monitorare l'importanza del carico di lavoro e i passaggi per convertire una classe di risorse in un gruppo di carico di lavoro. Usare il portale di Azure e le query T-SQL in DMV per monitorare il carico di lavoro e garantire che le risorse applicabili vengano usate in modo efficiente.

Passaggi successivi

Per informazioni su ETL e caricamento per la migrazione di Oracle, vedere l'articolo successivo di questa serie: Migrazione dei dati, ETL e caricamento per le migrazioni Oracle.