Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Fase 3. EseguiAWS SCT report
In questo passaggio, si utilizza l'output del passaggio 2 (formattato come file CSV) come input per l'esecuzione del AWS SCTvalutatore multiserver. È necessario aggiungere le credenziali di accesso (ID utente e password), i nomi dei database e le descrizioni del database al file CSV prima di fornirlo come input alAWS SCT valutatore multiserver. Segui ilAWS SCT formato fornito nell'esempio nellaAWS documentazione.
Il valutatore multiserver viene eseguitoAWS SCT su ogni schema del database elencato nel file CSV. Produce un rapporto dettagliato che riflette la complessità della conversione per ogni schema. Questo calcolo si basa sulla percentuale di oggetti di codice, oggetti di archiviazione ed elementi di sintassi cheAWS SCT possono essere convertiti automaticamente e sul codice che è necessario correggere manualmente durante la migrazione. I valori di complessità vanno da 1 (meno complesso) a 10 (il più complesso).
AWS SCTspecifica il livello di complessità della conversione in base allo sforzo di conversione e migrazione del codice. Il numero 1 rappresenta il livello più basso di complessità e il numero 10 rappresenta il livello più alto di complessità. L'ordinamento in base al livello di complessità della conversione e il filtraggio in base a valori inferiori a 2 producono un elenco di database candidati alla migrazione al motore di database di destinazione. È possibile includere altre proprietà, come la dimensione del database e il numero totale di oggetti, per ottimizzare l'elenco dei candidati, come illustrato negli esempi seguenti.
Esempi di valutatori multiserver
Gli esempi seguenti utilizzanoAWS SCT multiserver assessor per valutare gli schemi di database Oracle e SQL Server. La valutazione viene eseguita su PostgreSQL e MySQL come motori di database di destinazione.
IlAWS SCT valutatore multiserver produce un rapporto aggregato riepilogativo che mostra la complessità stimata per ogni obiettivo di migrazione. Puoi ordinare questo rapporto nella colonna Complessità delle conversioni per Amazon Relational Database Service (Amazon RDS) per PostgreSQL o Amazon RDS per i motori di destinazione MySQL. Ciò fornisce un elenco di database facili da migrare verso motori di database open source come PostgreSQL o MySQL con uno sforzo minimo o nullo, in base ai requisiti di conversione del codice, alla complessità dell'archiviazione e alla complessità della sintassi.
La tabella seguente mostra un elenco di esempi di database SQL Server che sono i primi candidati alla migrazione a motori di database open source come PostgreSQL e MySQL. La tabella include anche le colonne Oggetti totali e Dimensione in GB dall'output del passaggio 2.
I dati vengono ordinati nelle colonne Complessità di conversione (per Amazon RDS for PostgreSQL o MySQL) in ordine crescente. Puoi anche ordinare ulteriormente la tabella per Dimensione in GB e Oggetti totali, in ordine crescente in base alle tue esigenze. Ciò si traduce in un elenco di schemi di database di dimensioni più ridotte, con meno oggetti e con la minore complessità di conversione. La tabella mostra l'elenco degli schemi di database di SQL Server con una complessità di conversione pari a 1 (meno complesso), per Amazon RDS for PostgreSQL e Amazon RDS for MySQL. Questi risultati mostrano che sarà necessario uno sforzo minimo per migrare questi schemi su motori di database open source attiviAWS.
La tabella seguente mostra un elenco simile di database Oracle che sono i primi candidati alla migrazione verso database open source PostgreSQL e MySQL.
Le tabelle Oracle e SQL Server forniscono inoltre informazioni fondamentali come il nome dello schema, la versione del database, il numero totale di oggetti, la dimensione dello schema e la sua complessità di conversione. Puoi utilizzare questi dati per esaminare e pianificare la migrazione in base alle tue esigenze.
