View a markdown version of this page

Flusso di lavoro di modernizzazione di SQL Server - AWS Trasformazione
Passaggio 1: creare un processo di modernizzazione di SQL ServerFase 2: Connessione al database di SQL ServerFase 3: Connetti il repository del codice sorgenteFase 4: creazione del connettore di distribuzione (opzionale)Fase 5: Conferma le tue risorseFase 6: Scoperta e valutazioneFase 7: Generazione e revisione del piano d'ondataFase 8: conversione dello schemaFase 9: migrazione dei dati (opzionale)Fase 10: trasformazione del codice dell'applicazioneFase 11: Rivedi i risultati della trasformazioneFase 12: Validazione e testFase 13: Implementazione

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

  2. Scegli Crea processo di modernizzazione

  3. Seleziona il processo di modernizzazione di Windows, quindi seleziona la modernizzazione di SQL Server

  4. 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

  5. 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

  2. Scegli Connetti al database SQL Server

  3. Scegli Crea nuovo connettore

  4. Inserisci le informazioni sul connettore:

    • Nome del connettore: nome descrittivo

    • AWS ID account: account in cui è ospitato SQL Server

  5. 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.

  6. 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.

  2. Scegli Archivia un nuovo segreto.

  3. Per Secret type (Tipo di segreto), scegli Other type of secret (Altro tipo di segreto).

  4. 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 esempiohttps://github.mycompany.com), provider_type (, github gitlabbitbucket, o) e (il tuo PATado). 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"
}

  5. Scegli Next (Successivo).

  6. Inserisci un nome segreto, ad esempiogithub-pat-myproject.

  7. (Facoltativo) Seleziona una chiave KMS gestita dal cliente per la crittografia.

  8. Completa la procedura guidata e scegli Store.

  9. 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 esempious-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

  2. Nel riquadro di navigazione, scegli Chiavi gestite dal cliente.

  3. Seleziona la tua chiave KMS.

  4. Nella scheda Policy della chiave, seleziona Modifica.

  5. Aggiungi la dichiarazione politica alla politica esistente.

  6. 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.

  2. Scegli Connect source code repository.

  3. Seleziona PAT Connector come metodo di autenticazione.

  4. Inserisci l'ARN segreto del passaggio 2.

  5. (Facoltativo) Inserisci l'ARN della chiave KMS se hai utilizzato una chiave KMS gestita dal cliente.

  6. Seleziona il tuo repository e la tua filiale.

  7. 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.

  2. Aggiorna il valore segreto in. AWS Secrets Manager

  3. Verifica che il tuo job AWS Transform possa accedere al repository con il nuovo token.

  4. 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.

  2. Scegli Connect source code repository.

  3. Se non disponi di una connessione esistente, scegli Crea connessione.

  4. Seleziona il tuo provider di repository:

    • GitHub /Enterprise GitHub

    • GitLab.com

    • Bitbucket Cloud

    • Repository di Azure

  5. Segui il flusso di autorizzazione per il tuo provider.

  6. Dopo l'autorizzazione, scegli Connetti.

Seleziona il tuo repository e la tua filiale

  1. Seleziona il tuo repository dall'elenco.

  2. Scegli il ramo che desideri trasformare (in genere principale, master o sviluppo).

  3. (Facoltativo) Specificate una sottodirectory se l'applicazione.NET non si trova nella radice del repository.

  4. 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.

  2. Condividi questo link con l'amministratore del tuo repository.

  3. L'amministratore esamina e approva la richiesta nelle impostazioni del proprio repository.

  4. 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.

  2. Aggiungi il tuo AWS account nel punto in cui desideri distribuire le applicazioni trasformate.

  3. Aggiungi un nome che ti aiuti a ricordare facilmente il connettore

  4. 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

  2. Condividi questo link con l'amministratore AWS del tuo account

  3. L'amministratore esamina e approva la richiesta nelle impostazioni del proprio repository

  4. 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

  2. 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

  3. Se tutti gli elementi vengono visualizzati come completi, scegli Continua

  4. 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

  2. Esamina le ondate proposte

  3. 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

  2. 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

  3. Carica nuovamente il file JSON sulla console scegliendo Carica piano d'onda

  4. AWS Transform convalida le modifiche e avvisa se le dipendenze vengono violate

  5. 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

  2. AWS La trasformazione blocca il piano d'onda e procede alla trasformazione

  3. 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

  2. Rivedi le impostazioni di conversione:

    • Versione PostgreSQL di destinazione

    • Opzioni di estensione (ltree, PostGIS, ecc.)

    • Convenzioni di denominazione

  3. Scegli Avvia conversione

  4. Monitora i progressi nel registro di lavoro

  5. 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

  2. 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

  3. 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

  2. Scegli Approva la conversione dello schema

  3. 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

  2. Scegli la tua opzione di migrazione:

    • Migrazione dei dati di produzione

    • Salta la migrazione dei dati

  3. 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

  2. Replica continua: (se CDC è abilitato) mantiene i dati sincronizzati

  3. Convalida: verifica il conteggio delle righe e l'integrità dei dati

  4. 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

  2. Rivedi le impostazioni di trasformazione:

    • Versione .NET di destinazione (in caso di aggiornamento)

    • Versione del provider PostgreSQL

    • Preferenze relative allo stile del codice

  3. Scegli Avvia trasformazione

  4. Monitora i progressi nel registro di lavoro

  5. 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

  2. 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

  2. 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

  3. 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

  2. Scegli Esegui convalida

  3. AWS Transform esegue i test di convalida:

    • Connettività del database

    • Compatibilità dello schema

    • Integrità dei dati

    • Creazione dell'applicazione

    • Funzionalità di base

  4. 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

  2. Scegli Deploy to ECS

  3. 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à

  4. Rivedi l'infrastruttura come codice (modello o codice CDK) CloudFormation AWS

  5. Scegli Deploy

Monitora l'implementazione

AWS Transform implementa la tua applicazione:

  1. Crea un cluster Aurora PostgreSQL

  2. Applica lo schema del database

  3. Carica i dati (se applicabile)

  4. Distribuisce contenitori di applicazioni

  5. Configura il sistema di bilanciamento del carico

  6. 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