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à. # Flusso di lavoro di modernizzazione di SQL Server Questa sezione fornisce una panoramica dettagliata del processo completo di modernizzazione di SQL Server tramite Transform. AWS ## Passaggio 1: creare un processo di modernizzazione di SQL Server Inizia il tuo percorso di modernizzazione creando un nuovo processo di trasformazione nella console AWS Transform. 1. Accedi alla console AWS Transform 1. Scegli ** Crea processo di modernizzazione ** 1. Seleziona il ** processo ** di modernizzazione di Windows, quindi seleziona la modernizzazione di ** SQL Server ** 1. Inserisci i dettagli del lavoro: + **Nome del lavoro**: nome descrittivo per il tuo progetto + **Descrizione**: descrizione opzionale + **Regione di destinazione**: AWS regione per la distribuzione 1. Selezionare **Create job (Crea attività)**. **Importante** Non includere informazioni di identificazione personale (PII) nel nome della tua professione. ## Fase 2: Connessione al database di SQL Server Connetti AWS Transform al tuo database SQL Server per abilitare l'analisi e la conversione degli schemi. ### Crea un connettore di database 1. Nel processo di modernizzazione di SQL Server, vai a Connetti alle risorse 1. Scegli ** Connetti al database SQL Server ** 1. Scegli ** Crea nuovo connettore ** 1. Inserisci le informazioni sul connettore: + Nome del ** connettore**: nome descrittivo + **AWS ID account**: account in cui è ospitato SQL Server 1. Una volta confermato, riceverai un link per l'approvazione. Copia il link di approvazione per ottenere l'approvazione dell'account dal tuo AWS amministratore. Una volta approvati, puoi procedere al passaggio successivo. 1. Dopo che l'amministratore ha approvato la richiesta del connettore, fai clic su Invia per procedere alla configurazione della connessione con il codice sorgente. ## Fase 3: Connetti il repository del codice sorgente AWS Transform richiede l'accesso al codice sorgente dell'applicazione.NET per analizzare e trasformare il codice che interagisce con il database SQL Server. AWS Transform supporta tre metodi per fornire il codice sorgente. ### Scegli il tuo metodo di autenticazione Connettore Personal Access Token (PAT) (consigliato) Ideale per i team che necessitano di ambiti di autorizzazione personalizzati, supporto di provider ospitati autonomamente o accesso ad API specifiche del provider come Secrets. GitHub Crei un PAT nel tuo provider di codice sorgente con autorizzazioni personalizzate, lo memorizzi e Transform lo recupera AWS Secrets Manager quando necessario. AWS Sei responsabile della gestione della rotazione e della scadenza dei token. AWS CodeConnections Ideale per i team che desiderano una gestione automatizzata delle credenziali. AWS CodeConnections utilizza un'integrazione con provider gestiti che gestisce l'autenticazione tramite un flusso di autorizzazione OAuth 2.0. AWS gestisce l'intero ciclo di vita delle credenziali, incluso l'aggiornamento e la rotazione automatici dei token. Non è richiesta la gestione manuale delle credenziali. Simple Storage Service (Amazon S3) Carica il codice sorgente direttamente in un bucket Amazon S3. AWS Transform accede al codice dal bucket durante il processo di trasformazione. | Funzionalità | Connettore PAT (consigliato) | AWS CodeConnections | | --- | --- | --- | | Gestione delle credenziali | Manuale (gestito dal cliente) | Automatico (gestito)AWS | | Ciclo di vita dei token | È richiesta la rotazione manuale | Aggiornamento automatico | | Flessibilità dell'autorizzazione | Ambiti completamente personalizzabili | Autorizzazioni fisse | | Self-hosted supporto del provider | Supportata | Non disponibile | | Complessità della configurazione | Moderato (creazione e archiviazione manuali dei token) | Basso (autorizzazione una tantum) | | Conservazione dei token | Del cliente AWS Secrets Manager | Gestito da AWS | ### Configurare un connettore PAT (consigliato) Con un connettore PAT, puoi creare un token di accesso personale nel tuo fornitore di codice sorgente con autorizzazioni personalizzate, archiviarlo in AWS Secrets Manager modo sicuro e AWS Transform lo recupera quando necessario. Sei responsabile della gestione del ciclo di vita del token, comprese la rotazione e la scadenza. AWS Transform crea automaticamente il ruolo IAM necessario con le autorizzazioni per accedere al tuo segreto. Il connettore PAT supporta i seguenti provider, incluse le versioni self-hosted e personalizzate: DNS/URL + GitHub ed GitHub Enterprise Server + GitLab.com e GitLab Self-Managed + Bitbucket Cloud e Bitbucket Data Center + Azure e Azure Server DevOps DevOps #### Crea un token di accesso personale Crea un PAT nel tuo fornitore di codice sorgente. Le autorizzazioni richieste variano in base al provider. Scegli la scheda relativa al tuo provider. **Importante** Copia il token subito dopo la creazione. Non puoi visualizzarlo nuovamente. Imposta la scadenza per la durata del processo di trasformazione. Non impostate la scadenza in modo che non scada mai. **avvertimento** Non salvare mai i token PAT in archivi di codice né condividerli tramite canali non sicuri. Conservali sempre in. AWS Secrets Manager ##### GitHub Vai su ** Impostazioni**, Impostazioni ** sviluppatore**, Token di accesso ** personali**, ** Fine-grained token**. Seleziona i repository da trasformare e concedi le seguenti autorizzazioni. **Autorizzazioni del repository ** | Autorizzazione | Accesso | Scopo | | --- | --- | --- | | Indice | Leggere e scrivere | Legge il codice sorgente e riscrive il codice trasformato nel repository | | Metadati | Read-only | Accede alle informazioni di base del repository | **Autorizzazioni organizzative (richieste per i repository dell'organizzazione) ** | Autorizzazione | Accesso | Scopo | | --- | --- | --- | | Membri | Read-only | Elenca le organizzazioni accessibili al token per l'individuazione dei repository | ##### GitLab Vai a ** Modifica profilo**, Token ** di ** accesso. Seleziona i seguenti ambiti. | Scope | Scopo | | --- | --- | | read\_api | Legge i metadati del repository, le informazioni sul progetto, i dettagli degli utenti ed elenca gruppi e filiali | | read\_repository | Legge i file di codice sorgente e la struttura del repository per l'analisi | | write\_repository | Riscrive il codice trasformato nel repository | ##### Bitbucket Vai a Impostazioni ** dell'account**, ** Sicurezza**, ** Crea e gestisci token ** API. Gli ambiti richiesti dipendono dal tipo di token. **Workspace/Repository Token (ATCT — Bearer auth, nessun nome utente richiesto) ** | Autorizzazione | Accesso | Scopo | | --- | --- | --- | | Repositories | Leggi e scrivi | Elenca i repository, legge i rami e scrive codice trasformato tramite git push | **Token API dell'account (ATAT — autenticazione di base con email) o password dell'app (ATBB — autenticazione di base con nome utente) ** | Scope | Scopo | | --- | --- | | read:account | Identifica l'utente autenticato per risolvere l'appartenenza al repository | | read:workspace:bitbucket | Elenca gli spazi di lavoro a cui il token può accedere in modo che AWS Transform possa enumerare i propri repository. Non richiesto se si specifica un elenco di aree di lavoro nel segreto. | | read:repository:bitbucket | Elenca i repository e legge i metadati e le informazioni sulle filiali | | write:repository:bitbucket | Scrive il codice trasformato nel repository tramite git push | ##### Azure DevOps Vai a Impostazioni ** utente**, Token ** di accesso ** personali. Seleziona ** Ambiti definiti ** personalizzati. Per l'ambito dell'organizzazione, scegli ** Tutte le organizzazioni accessibili ** (consigliato) o specifica una singola organizzazione. | Scope | Accesso | Scopo | | --- | --- | --- | | Codice | Leggi e scrivi | Legge il codice sorgente, elenca i repository e i branch e riscrive il codice trasformato | | Profilo utente | Lettura | Convalida l'accesso tramite token e scopre l'identità dell'utente per la ricerca nell'organizzazione | | Gestione dei diritti dei membri | Lettura | Elenca le organizzazioni accessibili al token per l'individuazione del repository | #### Memorizza il PAT in AWS Secrets Manager 1. Apri la AWS Secrets Manager console. 1. Scegli **Archivia un nuovo segreto**. 1. Per **Secret type** (Tipo di segreto), scegli **Other type of secret** (Altro tipo di segreto). 1. Aggiungi coppie chiave-valore in base al tuo provider e al tipo di hosting: + **Cloud-hosted provider**: aggiungi una chiave denominata `token` con il tuo PAT come valore. + Per Azure DevOps con un'organizzazione specifica, aggiungi anche una chiave denominata `organization` con il nome della tua organizzazione. + Per le password delle app Bitbucket (ATBB), aggiungi anche una chiave denominata `username` con il tuo nome utente Bitbucket. Per i token API degli account Bitbucket (ATAT), aggiungi una chiave denominata con il tuo indirizzo email Bitbucket. `email` + **Self-hosted e DNS/URL provider personalizzati**: aggiungi le seguenti chiavi: `host` (l'URL del tuo server, ad esempio`https://github.mycompany.com`), `provider_type` (, `github` `gitlab``bitbucket`, o) e (il tuo PAT`ado`). `token` + Per Azure DevOps con un'organizzazione specifica, aggiungi anche una chiave denominata `organization` con il nome della tua organizzazione. + Per le password delle app Bitbucket (ATBB), aggiungi anche una chiave denominata `username` con il tuo nome utente Bitbucket. Per i token API degli account Bitbucket (ATAT), aggiungi una chiave denominata con il tuo indirizzo email Bitbucket. `email` L'esempio seguente mostra come un segreto cerca un provider ospitato nel cloud: AWS Secrets Manager GitHub ``` { "token": "{{your-github-personal-access-token}}" } ``` L'esempio seguente mostra una password per l'app Bitbucket (ATBB): ``` { "token": "{{your-bitbucket-app-password}}", "username": "my-bitbucket-username" } ``` L'esempio seguente mostra un'istanza ospitata autonomamente: GitLab ``` { "host": "https://gitlab.mycompany.com", "provider_type": "gitlab", "token": "{{your-gitlab-personal-access-token}}" } ``` 1. Scegli **Next (Successivo)**. 1. Inserisci un nome segreto, ad esempio`github-pat-myproject`. 1. (Facoltativo) Seleziona una chiave KMS gestita dal cliente per la crittografia. 1. Completa la procedura guidata e scegli Store. ** ** 1. Copia l'ARN segreto. Questo valore è necessario quando si configura il processo di AWS trasformazione. Se utilizzi una chiave KMS gestita dal cliente per crittografare il tuo segreto (anziché la chiave AWS gestita predefinita), devi aggiornare la politica delle chiavi KMS per consentire AWS a Transform di decrittografare il segreto. Aggiungi la seguente dichiarazione alla tua policy sulle chiavi KMS gestita dal cliente: ``` { "Sid": "Allow AWS Transform to decrypt secrets", "Effect": "Allow", "Principal": { "Service": "transform.amazonaws.com" }, "Action": [ "kms:Decrypt", "kms:DescribeKey" ], "Resource": "*", "Condition": { "StringEquals": { "kms:ViaService": "secretsmanager.{{REGION}}.amazonaws.com", "kms:EncryptionContext:SecretARN": "{{YOUR-SECRET-ARN}}" } } } ``` Sostituiscila {{REGION}} con la tua AWS regione (ad esempio`us-east-1`) e {{YOUR-SECRET-ARN}} con l'ARN del tuo segreto. La `kms:ViaService` condizione garantisce che la chiave KMS possa essere utilizzata solo tramite il AWS Secrets Manager servizio. La `kms:EncryptionContext:SecretARN` condizione limita la decrittografia al tuo segreto specifico. Per aggiornare la politica relativa alle chiavi del KMS: 1. Apri la console AWS KMS all'indirizzo. `https://console.aws.amazon.com/kms` 1. Nel riquadro di navigazione, scegli **Chiavi gestite dal cliente**. 1. Seleziona la tua chiave KMS. 1. Nella scheda **Policy della chiave**, seleziona **Modifica**. 1. Aggiungi la dichiarazione politica alla politica esistente. 1. Scegli **Save changes** (Salva modifiche). **Nota** Se si utilizza la chiave predefinita AWS gestita (`aws/secretsmanager`), non è necessario modificare alcuna politica chiave KMS. #### Configura il AWS Trasforma il lavoro 1. Nel tuo processo di AWS trasformazione, vai a ** Connetti alle risorse**. 1. Scegli ** Connect source code repository. ** 1. Seleziona ** PAT Connector ** come metodo di autenticazione. 1. Inserisci l'ARN segreto del passaggio 2. 1. (Facoltativo) Inserisci l'ARN della chiave KMS se hai utilizzato una chiave KMS gestita dal cliente. 1. Seleziona il tuo repository e la tua filiale. 1. Scegli **Continua**. AWS Transform crea automaticamente un ruolo IAM con le autorizzazioni necessarie per accedere al tuo segreto. #### Rotazione e manutenzione dei token Sei responsabile della rotazione dei token PAT prima che scadano. Per ruotare un token: 1. Genera un nuovo PAT nel tuo fornitore di codice sorgente con le stesse autorizzazioni. 1. Aggiorna il valore segreto in. AWS Secrets Manager 1. Verifica che il tuo job AWS Transform possa accedere al repository con il nuovo token. 1. Revoca il vecchio PAT nel tuo fornitore di codice sorgente. #### Risolvi i problemi relativi al connettore PAT Accesso negato: PAT non valido Verifica che il PAT non sia scaduto. Verifica che il PAT abbia gli ambiti richiesti per il tuo provider. Verificate che il PAT sia memorizzato correttamente in. AWS Secrets Manager Impossibile recuperare il segreto Verifica che l'ARN segreto sia corretto. Controlla i log dei job per confermare che AWS Transform ha creato il ruolo IAM. Se stai utilizzando una chiave KMS gestita dal cliente, verifica la policy chiave. Autorizzazioni insufficienti Il PAT potrebbe non avere gli ambiti richiesti per l'operazione. Rigenera il PAT con gli ambiti richiesti e aggiorna il valore segreto in. AWS Secrets Manager ### Configurazione AWS CodeConnections AWS CodeConnections utilizza un'integrazione con provider gestiti che recupera automaticamente le credenziali OAuth temporanee tramite un flusso di autorizzazione OAuth 2.0. Le autorizzazioni sono configurate nell'app del provider e gestite interamente da. AWS L'app viene autorizzata una sola volta e si AWS gestisce tutta la gestione delle credenziali. 1. Nel processo di modernizzazione di SQL Server, vai a ** Connetti alle risorse. ** 1. Scegli ** Connect source code repository**. 1. Se non disponi di una connessione esistente, scegli ** Crea connessione. ** 1. Seleziona il tuo provider di repository: + GitHub /Enterprise GitHub + GitLab.com + Bitbucket Cloud + Repository di Azure 1. Segui il flusso di autorizzazione per il tuo provider. 1. Dopo l'autorizzazione, scegli ** Connetti**. ### Seleziona il tuo repository e la tua filiale 1. Seleziona il tuo repository dall'elenco. 1. Scegli il ramo che desideri trasformare (in genere principale, master o sviluppo). 1. (Facoltativo) Specificate una sottodirectory se l'applicazione.NET non si trova nella radice del repository. 1. Scegli **Continua**. **Nota** AWS Transform crea un nuovo ramo per il codice trasformato. È possibile rivedere e unire le modifiche tramite il normale processo di revisione del codice. ### Approvazione dell'accesso al repository Per GitHub e alcune altre piattaforme, l'amministratore del repository deve approvare la richiesta di connessione: 1. AWS Transform visualizza un link di verifica. 1. Condividi questo link con l'amministratore del tuo repository. 1. L'amministratore esamina e approva la richiesta nelle impostazioni del proprio repository. 1. Dopo l'approvazione della richiesta da parte dell'amministratore, lo stato della connessione diventa Approvato. * * **Importante** Il processo di approvazione può richiedere del tempo a seconda delle politiche dell'organizzazione. Pianifica le attività di conseguenza. ## Fase 4: creazione del connettore di distribuzione (opzionale) Se desideri distribuire le applicazioni trasformate nel tuo AWS account, hai la possibilità di selezionare un connettore di distribuzione. ### Configura il connettore di distribuzione 1. Seleziona ** Sì ** se desideri distribuire le tue applicazioni. Selezionando ** No ** si salterà questo passaggio. 1. Aggiungi il tuo AWS account nel punto in cui desideri distribuire le applicazioni trasformate. 1. Aggiungi un nome che ti aiuti a ricordare facilmente il connettore 1. Invia la richiesta di approvazione del connettore. ### Approvazione del connettore di distribuzione L'amministratore AWS dell'account deve approvare la richiesta di connessione per il connettore di distribuzione. 1. AWS Transform visualizza un link di verifica 1. Condividi questo link con l'amministratore AWS del tuo account 1. L'amministratore esamina e approva la richiesta nelle impostazioni del proprio repository 1. Una volta approvata, lo stato della connessione diventa Approvato * * **Importante** Il processo di approvazione può richiedere del tempo a seconda delle politiche dell'organizzazione. Pianifica le attività di conseguenza. ## Fase 5: Conferma le tue risorse Dopo la connessione al database e al repository, AWS Transform verifica che tutte le risorse richieste siano accessibili e pronte per la trasformazione. ### What AWS Transform verifica + **Connettività al database: ** la connessione è attiva, l'utente ha le autorizzazioni richieste, i database sono accessibili, la versione è supportata + **Accesso al repository: il ** repository è accessibile, esiste una filiale, sono stati rilevati i file di progetto.NET, sono rilevabili le connessioni al database + **Prontezza per l'ambiente: la configurazione ** VPC supporta il DMS, esistono i ruoli di AWS servizio richiesti, è stata stabilita la connettività di rete, è stata confermata la compatibilità regionale ### Consulta la lista di controllo prima del volo 1. Vai a ** Conferma le tue risorse ** nel piano di lavoro 1. Rivedi gli elementi della lista di controllo: + ✅ Connessione al database verificata + ✅ Accesso al repository confermato + ✅ Versione .NET supportata + ✅ Entity Framework o ADO.NET rilevata + ✅ Configurazione di rete valida + ✅ Autorizzazioni richieste concesse 1. Se tutti gli elementi vengono visualizzati come completi, scegli Continua 1. Se alcuni elementi mostrano avvisi o errori, risolvili prima di procedere ## Fase 6: Scoperta e valutazione AWS Transform analizza il database SQL Server e l'applicazione.NET per comprendere l'ambito e la complessità della modernizzazione. ### Cosa viene scoperto + **Oggetti del database: ** tabelle, viste, indici, stored procedure, funzioni, trigger, vincoli, tipi di dati, colonne calcolate, colonne di identità, relazioni di chiave esterna + **Codice dell'applicazione: struttura del ** progetto.NET, modelli e configurazioni di Entity Framework, codice di accesso ai ADO.NET dati, stringhe di connessione al database, chiamate di stored procedure, query SQL in codice + **Dipendenze: ** quali applicazioni utilizzano quali database, dipendenze tra database, procedure memorizzate condivise, modelli di accesso ai dati comuni ### Processo di scoperta + AWS Transform avvia il rilevamento automaticamente dopo la conferma della risorsa + L'individuazione richiede in genere 5-15 minuti a seconda delle dimensioni del database e della complessità dell'applicazione + Monitora i progressi nel registro di lavoro + AWS Transform visualizza gli aggiornamenti in tempo reale man mano che gli oggetti vengono scoperti ### Esamina i risultati del rilevamento Una volta completata la scoperta, accedi a ** Discovery e assessment ** per esaminare: **Analisi del database: ** + **Numero di oggetti**: numero di tabelle, visualizzazioni, procedure memorizzate, funzioni, trigger + **Punteggio di complessità**: valutazione della complessità della trasformazione (bassa, media, alta) + **Elementi d'azione**: oggetti che possono richiedere l'attenzione umana + **Funzionalità supportate**: funzionalità del database che verranno convertite automaticamente + **Funzionalità non supportate**: funzionalità che richiedono soluzioni alternative **Analisi delle applicazioni: ** + **Tipo di progetto**: ASP.NET Core, Console App, Class Library, ecc. + **Versione.NET**: è stata rilevata la versione .NET Core + **Framework di accesso ai dati**: versione Entity Framework o ADO.NET + **Connessioni al database**: numero di stringhe di connessione trovate + **Complessità del codice**: valutazione della complessità della trasformazione **Mappa delle dipendenze: ** + Rappresentazione visiva delle relazioni tra applicazioni e database + Cross-database dipendenze + Componenti condivisi ### Comprendere la valutazione della complessità AWS Transform classifica la modernizzazione in tre categorie: | Complessità | Caratteristiche | Risultato previsto | | --- | --- | --- | | Basso (classe A) | Schemi SQL standard (ANSI SQL), procedure memorizzate semplici, tipi di dati di base, Entity Framework con configurazioni standard | Intervento umano minimo previsto, elevata percentuale di successo nell'automazione | | Medio (classe B) | T-SQL Schemi avanzati, procedure memorizzate complesse con logica aziendale, funzioni definite dall'utente, colonne calcolate | È richiesto un intervento umano, si consiglia la revisione di un esperto | | Alta (classe C) | Assiemi CLR, server collegati, Service Broker, ricerca completa nel testo complesso | È necessario un significativo refactoring umano, si consideri un approccio graduale | ### Report di valutazione AWS Transform genera un rapporto di valutazione dettagliato che include: + Riepilogo esecutivo con panoramica di alto livello + Inventario completo del database + Inventario delle applicazioni + Percentuale di preparazione alla trasformazione + Stima dello sforzo + Strategie di valutazione e mitigazione del rischio + Approccio consigliato È possibile scaricare il rapporto di valutazione per la revisione offline e la condivisione con le parti interessate. ## Fase 7: Generazione e revisione del piano d'ondata Per aziende di grandi dimensioni con più database e applicazioni, AWS Transform genera un piano d'onda che sequenzia la modernizzazione in gruppi logici. ### Cos'è un piano d'onda? Un piano d'onda organizza la modernizzazione in fasi (ondate) in base a: + Dipendenze tra database e applicazioni + Priorità aziendali + Tolleranza al rischio + Disponibilità delle risorse + Complessità tecnica Ogni ondata contiene un gruppo di database e applicazioni che possono essere modernizzati insieme senza interrompere le dipendenze. ### Rivedi il piano d'ondata 1. Vai a ** Wave planning ** nel piano di lavoro 1. Esamina le ondate proposte 1. Per ogni ondata, rivedi: + Database inclusi + Applicazioni incluse + Dipendenze da altre onde + Tempo di trasformazione stimato + Livello di complessità + Applicazioni implementabili ### Personalizza il piano d'onda Puoi personalizzare il piano d'ondata in base alle tue esigenze aziendali in 2 modi: **Utilizzando JSON: ** 1. Scegli ** Scarica tutte le onde ** per ottenere un file JSON con tutte le onde 1. Modifica le onde nel JSON tramite: + Spostamento dei database tra le onde + Suddivisione delle onde in gruppi più piccoli + Unire le onde + Modifica della sequenza delle onde + Aggiungere o rimuovere database dall'ambito 1. Carica nuovamente il file JSON sulla console scegliendo ** Carica piano d'onda ** 1. AWS Transform convalida le modifiche e avvisa se le dipendenze vengono violate 1. Scegli ** Conferma ondate per aggiornare ** il piano d'onda **Usare la chat: ** Puoi modificare i piani d'ondata chattando con l'agente e chiedendogli di spostare i repository e i database su ondate specifiche. Questo approccio funziona bene se è necessario apportare modifiche minori alle onde. **Importante** Assicuratevi che le dipendenze siano rispettate durante la personalizzazione delle onde. La trasformazione di un'applicazione dipendente prima del relativo database può causare problemi. ### Modernizzazione di un singolo database Se stai modernizzando un singolo database e una singola applicazione, AWS Transform crea un piano semplice con un'unica ondata. È possibile procedere direttamente alla trasformazione senza pianificazione delle ondate. ### Approva il piano d'ondata 1. Dopo aver esaminato e personalizzato (se necessario), scegli ** Approva il piano d'ondata ** 1. AWS La trasformazione blocca il piano d'onda e procede alla trasformazione 1. Puoi comunque modificare il piano in un secondo momento scegliendo ** Modifica piano d'onda ** ## Fase 8: conversione dello schema AWS Transform converte lo schema del database SQL Server in Aurora PostgreSQL, incluse tabelle, viste, stored procedure, funzioni e trigger. ### Come funziona la conversione dello schema AWS Transform utilizza la conversione dello schema AWS DMS migliorata con intelligenza artificiale generativa per: + Analizza gli schemi e le relazioni di SQL Server + Mappa i tipi di dati da SQL Server agli equivalenti di PostgreSQL + Trasforma T-SQL in PL/pgSQL + Gestisci colonne di identità, colonne calcolate e vincoli + Convalida la conversione e l'integrità referenziale + Genera azioni per oggetti che richiedono una revisione umana ### Conversioni supportate **Convertito automaticamente: ** + Tabelle, viste e indici + Chiavi primarie e chiavi esterne + Controlla i vincoli e i valori predefiniti + I tipi di dati più comuni + Procedure memorizzate semplici + Funzioni e trigger di base + Colonne di identità (convertite in SERIAL o GENERATED) + Colonne più calcolate **Può richiedere una revisione umana: ** + Procedure archiviate complesse con funzionalità avanzate T-SQL + Server-specific Funzioni SQL (GETUTCDATE, SUSER\_SNAME, ecc.) + Colonne calcolate con espressioni complesse + Full-text indici di ricerca + operazioni sui tipi di dati XML + Tipo di dati HIERARCHYID (richiede l'estensione ltree) **Non convertito automaticamente: ** + Assiemi CLR + Server collegati + Service Broker + Lavori di SQL Server Agent ### Avvia la conversione dello schema 1. Passa alla conversione dello schema nel piano di lavoro 1. Rivedi le impostazioni di conversione: + Versione PostgreSQL di destinazione + Opzioni di estensione (ltree, PostGIS, ecc.) + Convenzioni di denominazione 1. Scegli Avvia conversione ** ** 1. Monitora i progressi nel registro di lavoro 1. La conversione richiede in genere 10-30 minuti a seconda del numero di oggetti del database ### Rivedi i risultati della conversione Al termine della conversione, vai a Rivedi la conversione dello schema: **Riepilogo della conversione: ** + **Oggetti convertiti**: numero di oggetti convertiti correttamente + **Elementi d'azione**: oggetti che richiedono l'attenzione umana + **Avvertenze**: potenziali problemi da esaminare + **Errori**: oggetti che non possono essere convertiti **Revisione per tipo di oggetto: ** + **Tabelle**: mappature, vincoli, indici dei tipi di dati + **Procedure memorizzate: alla conversione ** T-SQL PL/pgSQL + **Funzioni**: firma delle funzioni e modifiche logiche + **Trigger**: modifica della sintassi e della tempistica dei trigger ### Rivedi gli elementi d'azione 1. Scegli ** Visualizza elementi d'azione ** 1. Per ogni azione, esamina: + **Nome dell'oggetto**: l'oggetto del database + **Tipo di problema**: cosa richiede attenzione + **Gravità**: critica, avviso o informazioni + **Raccomandazione**: risoluzione consigliata + **Codice originale**: versione SQL Server + **Codice convertito**: versione PostgreSQL 1. Per ogni azione, puoi: + **Accetta**: usa il codice convertito + **Modifica**: modifica il codice convertito + **Contrassegna per dopo**: Contrassegna per la revisione umana dopo la trasformazione ### Esempio: conversione della procedura memorizzata SQL Server T-SQL: ``` CREATE PROCEDURE GetProductsByCategory @CategoryId INT, @PageSize INT = 10 AS BEGIN SET NOCOUNT ON; SELECT TOP (@PageSize) ProductId, Name, Price, DATEDIFF(DAY, CreatedDate, GETUTCDATE()) AS DaysOld FROM Products WHERE CategoryId = @CategoryId ORDER BY Name END ``` PostgreSQL convertito: PL/pgSQL ``` CREATE OR REPLACE FUNCTION get_products_by_category( p_category_id INTEGER, p_page_size INTEGER DEFAULT 10 ) RETURNS TABLE ( product_id INTEGER, name VARCHAR(255), price NUMERIC(18,2), days_old INTEGER ) AS $$ BEGIN RETURN QUERY SELECT p.product_id, p.name, p.price, EXTRACT(DAY FROM (NOW() - p.created_date))::INTEGER AS days_old FROM products p WHERE p.category_id = p_category_id ORDER BY p.name LIMIT p_page_size; END; $$ LANGUAGE plpgsql; ``` Modifiche apportate: + Procedura convertita in funzione che restituisce TABLE + Nomi dei parametri preceduti da p\_ + TOP convertito in LIMIT + DATEDIFF convertito in EXTRACT + GETUTCDATE () convertito in NOW () + Nomi di colonna convertiti in lettere minuscole (convenzione PostgreSQL) ### Approva la conversione dello schema 1. Dopo aver esaminato tutte le azioni e apportato le modifiche necessarie 1. Scegli ** Approva la conversione dello schema ** 1. AWS Transform prepara lo schema convertito per la distribuzione in Aurora PostgreSQL **Nota** È possibile scaricare lo schema convertito come script SQL per la revisione offline o il controllo della versione. ## Fase 9: migrazione dei dati (opzionale) AWS Transform offre opzioni per la migrazione dei dati da SQL Server ad Aurora PostgreSQL. La migrazione dei dati è facoltativa e può essere ignorata se è necessaria solo la trasformazione dello schema e del codice. ### Opzioni di migrazione dei dati **Opzione 1: migrazione dei dati di produzione ** Esegui la migrazione dei tuoi dati di produzione effettivi tramite AWS DMS: + Caricamento iniziale completo di tutti i dati + Replica continua durante i test (CDC) + Riduzione minima dei tempi di inattività + Validazione dei dati e controlli di integrità **Opzione 2: salta la migrazione dei dati ** Trasforma solo schema e codice: + Utile per development/testing gli ambienti + Quando i dati verranno migrati separatamente + Per progetti proof-of-concept ### Configurare la migrazione dei dati 1. Passa a Migrazione ** dei dati ** nel piano di lavoro 1. Scegli la tua opzione di migrazione: + **Migrazione dei dati di produzione ** + **Salta la migrazione dei dati ** 1. Se stai migrando i dati di produzione, configura: + **Tipo di migrazione**: a pieno carico o a pieno carico \+ CDC + **Convalida**: abilita la convalida dei dati + **Prestazioni**: dimensione dell'istanza DMS + Scegli ** >Avvia migrazione ** ### Processo di migrazione dei dati di produzione Se scegli di migrare i dati di produzione: 1. **Sincronizzazione iniziale**: AWS DMS esegue il caricamento completo di tutte le tabelle 1. **Replica continua**: (se CDC è abilitato) mantiene i dati sincronizzati 1. **Convalida**: verifica il conteggio delle righe e l'integrità dei dati 1. **Preparazione del cutover**: prepara per la sincronizzazione finale Cronologia della migrazione: + Database di piccole dimensioni (< 10 GB): 30 minuti - 2 ore + Database di medie dimensioni (10-100 GB): 2-8 ore + Database di grandi dimensioni (> 100 GB): oltre 8 ore ### Convalida dei dati AWS Transform convalida i dati migrati con i seguenti controlli: + Confronto del numero di righe (origine e destinazione) + Integrità della chiave primaria + Relazioni con chiave esterna + Compatibilità dei tipi di dati + Risultati delle colonne calcolate + Gestione dei valori nulli ## Fase 10: trasformazione del codice dell'applicazione AWS Transform trasforma il codice dell'applicazione.NET in modo che funzioni con Aurora PostgreSQL anziché con SQL Server. Richiede il nome del ramo di destinazione nei tuoi repository per eseguire il commit del codice sorgente trasformato. Una volta inserito il nome del ramo, AWS Transform creerà un nuovo ramo e avvierà la trasformazione in modo che corrisponda al database PostgreSQL. ### Cosa viene trasformato **Modifiche al framework delle entità: ** + **Fornitore di database**: UseSqlServer () → UseNpgsql () + **Stringhe di connessione**: formato SQL Server → formato PostgreSQL + **Mappature dei tipi di dati**: tipi di SQL Server → tipi PostgreSQL + **DbContext **configurazioni Server-specific : SQL → PostgreSQL-specific + **File di migrazione**: aggiornati per la compatibilità con PostgreSQL **ADO.NET Modifiche: ** + **Classi di connessione**: SqlConnection → NpgsqlConnection + **Classi di comando**: SqlCommand → NpgsqlCommand + **Lettore di dati**: SqlDataReader → NpgsqlDataReader + **Parametri**: SqlParameter → NpgsqlParameter + Sintassi ** SQL S**: T-SQL → PostgreSQL SQL **Modifiche alla configurazione: ** + Stringhe di connessione in appsettings.json + Pacchetti NuGet del provider di database + Configurazioni di iniezione delle dipendenze + Startup/Program.cs configurazioni ### Avvia la trasformazione del codice 1. Passa a Trasformazione delle applicazioni nel piano di lavoro 1. Rivedi le impostazioni di trasformazione: + **Versione .NET di destinazione ** (in caso di aggiornamento) + **Versione del provider PostgreSQL ** + **Preferenze relative allo stile del codice ** 1. Scegli ** Avvia trasformazione ** 1. Monitora i progressi nel registro di lavoro 1. La trasformazione richiede in genere 15-45 minuti a seconda delle dimensioni della base di codice ## Fase 11: Rivedi i risultati della trasformazione Prima di procedere all'implementazione, rivedi i risultati completi della trasformazione per assicurarti che tutto sia pronto per il test. Puoi scaricare il codice trasformato dal ramo del repository per: + Test e convalida locali + Revisione del codice nel tuo IDE + Integrazione con la tua CI/CD pipeline + Commit di controllo della versione Puoi anche scaricare il riepilogo della trasformazione per esaminare le modifiche al linguaggio naturale apportate da AWS Transform come parte della trasformazione. ### Riepilogo della trasformazione 1. Passa al riepilogo della ** trasformazione ** nel piano di lavoro 1. Rivedi i risultati complessivi: + **Conversione dello schema**: oggetti convertiti, azioni, avvisi + **Migrazione dei dati**: tabelle migrate, righe trasferite, stato di convalida + **Trasformazione del codice**: file modificati, righe modificate, problemi risolti + **Punteggio di prontezza**: disponibilità complessiva per l'implementazione ### Genera un report di trasformazione AWS Transform genera un report completo sulla trasformazione: 1. Scegli ** Genera rapporto ** 1. Seleziona il tipo di rapporto: + **Riepilogo**: High-level panoramica per le parti interessate + **Dettagli tecnici**: documentazione completa sulla trasformazione + **Elementi d'azione**: Elenco delle attività umane richieste 1. Scegli ** Scarica rapporto ** Il rapporto include: + Ambito e obiettivi della trasformazione + Oggetti e codice trasformati + Problemi riscontrati e soluzioni + Risultati della convalida + Valutazione della disponibilità all'implementazione + Raccomandazioni per i test ## Fase 12: Validazione e test Prima di passare alla produzione, verificate che l'applicazione trasformata funzioni correttamente con Aurora PostgreSQL. ### Tipi di convalida **Convalida automatica: ** AWS Transform esegue controlli automatici: + Convalida dello schema rispetto al database di origine + Verifica dell'integrità dei dati + Test di equivalenza delle interrogazioni + Convalida della stringa di connessione + Convalida della configurazione **Convalida umana: ** è necessario eseguire test aggiuntivi: + Test funzionale delle funzionalità dell'applicazione + Test di integrazione con altri sistemi + Test e benchmarking delle prestazioni + Test di accettazione da parte degli utenti + Test di sicurezza ### Esegui una convalida automatica 1. Passa a ** Convalida ** nel piano di lavoro 1. Scegli ** Esegui convalida ** 1. AWS Transform esegue i test di convalida: + Connettività del database + Compatibilità dello schema + Integrità dei dati + Creazione dell'applicazione + Funzionalità di base 1. Rivedi i risultati della convalida: + Superati: test con esito positivo + Fallito: test che richiedono attenzione + Avvertenze: potenziali problemi da esaminare ### Lista di controllo per i test **Funzionalità del database: ** + Tutte le tabelle sono accessibili + Le stored procedure vengono eseguite correttamente + Le funzioni restituiscono i risultati previsti + I trigger si attivano in modo appropriato + Vincoli applicati correttamente + Gli indici migliorano le prestazioni delle query **Funzionalità dell'applicazione: ** + L'applicazione viene avviata correttamente + Connessioni al database stabilite + Le operazioni CRUD funzionano correttamente + Le chiamate in procedura memorizzata hanno esito positivo + Transazioni commit/rollback corrette + La gestione degli errori funziona come previsto **Integrità dei dati: ** + Il conteggio delle righe corrisponde alla fonte + Chiavi primarie uniche + Chiavi esterne valide + Le colonne calcolate sono corrette + Gestione dei valori Null appropriata + Tipi di dati compatibili **Prestazioni: ** + Tempi di risposta alle domande accettabili + Il pool di connessioni è configurato + Indici ottimizzati + Nessun problema con le interrogazioni N\+1 + Operazioni in batch efficienti + Utilizzo delle risorse ragionevole ## Fase 13: Implementazione Una volta completata la convalida, implementate l'applicazione e il database modernizzati in produzione. ### Opzioni di implementazione + Amazon ECS e Amazon EC2 Linux ### Pre-deployment lista di controllo Prima della distribuzione in produzione: + Tutti i test di convalida sono stati superati + Test delle prestazioni completato + Revisione della sicurezza completata + Piano di backup e rollback documentato + Monitoraggio e avvisi configurati + Team formato sul nuovo ambiente + Le parti interessate sono state informate dell'implementazione + Finestra di manutenzione programmata ### Esegui la distribuzione su Amazon ECS 1. Passa a ** Deployment ** nel piano di lavoro 1. Scegli ** Deploy to ECS ** 1. Configura le impostazioni di distribuzione: + **Cluster**: seleziona o crea un cluster ECS + **Servizio**: configura il servizio ECS + **Definizione dell'attività**: rivede la definizione dell'attività generata + **Load balancer**: configura ALB/NLB + **Auto-scaling**: Imposta le politiche di scalabilità 1. Rivedi l'infrastruttura come codice (modello o codice CDK) CloudFormation AWS 1. **Scegli Deploy ** ### Monitora l'implementazione AWS Transform implementa la tua applicazione: 1. Crea un cluster Aurora PostgreSQL 1. Applica lo schema del database 1. Carica i dati (se applicabile) 1. Distribuisce contenitori di applicazioni 1. Configura il sistema di bilanciamento del carico 1. Imposta il ridimensionamento automatico Monitora l'avanzamento dell'implementazione e verifica: + Fornitura dell'infrastruttura + Inizializzazione del database + Distribuzione delle applicazioni + Superamento dei controlli sanitari + Applicazione accessibile + Connessioni al database funzionanti + Registri che mostrano il normale funzionamento ### Post-deployment convalida Dopo la distribuzione: **Test del fumo: ** + Verifica le funzionalità critiche + Testa i principali flussi di lavoro degli utenti + Controlla i punti di integrazione + Monitora i tassi di errore **Monitoraggio delle prestazioni: ** + Tieni traccia dei tempi di risposta + Monitora le interrogazioni del database + Controlla l'utilizzo delle risorse + Esamina i log delle applicazioni **Convalida dell'utente: ** + Effettuare test di accettazione degli utenti + Raccogli feedback + Risolvi eventuali problemi + Documenta le lezioni apprese ### Procedure di rollback In caso di problemi dopo la distribuzione: **Rollback immediato: ** + Ripristina la versione precedente dell'applicazione + Tornare a SQL Server (se ancora disponibile) + Effettua il ripristino dal backup, se necessario **Rollback parziale: ** + Ripristina componenti specifici + Mantieni le modifiche al database + Ripristina solo il codice dell'applicazione **Correzione successiva: ** + Applica l'hotfix alla versione Aurora PostgreSQL + Implementa il codice dell'applicazione aggiornato + Monitor per la risoluzione **Importante** Mantieni il database di SQL Server disponibile per un periodo dopo il cutover per abilitare il rollback, se necessario. ### Post-deployment ottimizzazione Dopo una corretta implementazione: **Ottimizzazione delle prestazioni: ** + Ottimizza le query lente + Modifica le impostazioni del pool di connessioni + Fine-tune Parametri Aurora PostgreSQL + Rivedi e ottimizza gli indici **Ottimizzazione dei costi: ** + Right-size Istanza Aurora + Configura il ridimensionamento automatico in modo appropriato + Rivedi le impostazioni di archiviazione + Ottimizza la conservazione dei backup **Configurazione del monitoraggio: ** + Configurare i CloudWatch dashboard + Configura gli avvisi + Enable Enhanced Monitoring (Abilita il monitoraggio avanzato) + Configura Performance Insights **Documentazione:** + Aggiorna i runbook + Modifiche all'architettura del documento + Addestrare il team operativo + Crea guide per la risoluzione dei problemi