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 guida dettagliata dell'intero processo di modernizzazione di SQL Server utilizzando Transform. AWS

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

Passaggio 2: Connect al database SQL Server

Connect AWS Transform al database SQL Server per abilitare l'analisi e la conversione dello schema.

Crea un connettore per il database

Passaggio 3: Connect 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

Configurare un connettore PAT (consigliato)

Con un connettore PAT, crei un token di accesso personale nel tuo provider di codice sorgente con autorizzazioni personalizzate, lo memorizzi 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, comprese le versioni self-hosted e personalizzate: DNS/URL

Crea un token di accesso personale

Crea un PAT nel tuo provider di codice sorgente. Le autorizzazioni richieste variano in base al provider. Scegli la scheda relativa al tuo provider.

GitHub

Vai a Impostazioni, Impostazioni sviluppatore, Token di accesso personali, Fine-grained token. Seleziona i repository da trasformare e concedi le seguenti autorizzazioni.

Autorizzazioni per il repository

Autorizzazioni organizzative (richieste per gli archivi dell'organizzazione)

GitLab

Vai a Modifica profilo, Accedi ai token. Seleziona i seguenti ambiti.

Bitbucket

Vai a Impostazioni 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)

Account API Token (ATAT — Autenticazione di base con e-mail) o password dell'app (ATBB — Autenticazione di base con nome utente)

Azure DevOps

Vai a Impostazioni utente, Token di accesso personali. Seleziona Ambiti definiti su misura. Per l'ambito dell'organizzazione, scegli Tutte le organizzazioni accessibili (consigliato) o specifica una singola organizzazione.

Memorizza il PAT in AWS Secrets Manager

Se utilizzi una chiave KMS gestita dal cliente per crittografare il tuo segreto (anziché la chiave AWS gestita predefinita), devi aggiornare la politica della chiave KMS per consentire AWS a Transform di decrittografare il segreto. Aggiungi la seguente dichiarazione alla politica delle 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"
    }
  }
}

Sostituisci 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 tua politica sulle chiavi KMS:

Configura il AWS Trasforma il lavoro

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:

Risolvi i problemi relativi al connettore PAT

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 Autorizzi l'app una sola volta e AWS gestisci tutta la gestione delle credenziali.

Seleziona il tuo repository e la tua filiale

Approvazione dell'accesso al repository

Per GitHub alcune altre piattaforme, l'amministratore del repository deve approvare la richiesta di connessione:

Fase 4: Creare un 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

Approvazione del connettore di distribuzione

L'amministratore AWS dell'account deve approvare la richiesta di connessione per il connettore di distribuzione.

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

Consulta la lista di controllo prima del volo

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

Processo di scoperta

Rivedi i risultati della scoperta

Una volta completata la scoperta, accedi a Discovery and assessment per esaminare:

Analisi del database:

Analisi delle applicazioni:

Mappa delle dipendenze:

Comprendere la valutazione della complessità

AWS Transform classifica la modernizzazione in tre categorie:

Report di valutazione

AWS Transform genera un rapporto di valutazione dettagliato che include:

Puoi scaricare il rapporto di valutazione per la revisione offline e la condivisione con le parti interessate.

Fase 7: Generazione e revisione del piano ondulatorio

Per aree di grandi dimensioni con più database e applicazioni, AWS Transform genera un piano d'ondata che sequenzia la modernizzazione in gruppi logici.

Cos'è un piano d'onda?

Un piano ondulatorio organizza la modernizzazione in fasi (ondate) basate su:

Ogni ondata contiene un gruppo di database e applicazioni che possono essere modernizzati insieme senza interrompere le dipendenze.

Rivedi il piano d'ondata

Personalizza il piano d'ondata

Puoi personalizzare il piano tariffario per adattarlo alle tue esigenze aziendali in 2 modi:

Utilizzando JSON:

Usare la chat:

Puoi modificare i piani d'onda 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.

Modernizzazione di un singolo database

Se stai modernizzando un singolo database e un'unica applicazione, AWS Transform crea un piano semplice in un'unica fase. Puoi procedere direttamente alla trasformazione senza una pianificazione ondata.

Approva il piano ondulatorio

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 l'intelligenza artificiale generativa per:

Conversioni supportate

Convertito automaticamente:

Potrebbe richiedere una revisione umana:

Non convertito automaticamente:

Avvia la conversione dello schema

Rivedi i risultati della conversione

Al termine della conversione, vai a Rivedi la conversione dello schema:

Riepilogo della conversione:

Revisione per tipo di oggetto:

Rivedi gli elementi di azione

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 PL/pgSQL convertito:

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:

Approva la conversione dello schema

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

Migra i dati di produzione effettivi utilizzando AWS DMS:

Opzione 2: ignora la migrazione dei dati

Trasforma solo schema e codice:

Configura la migrazione dei dati

Processo di migrazione dei dati di produzione

Se scegli di migrare i dati di produzione:

Cronologia della migrazione:

Convalida dei dati

AWS Transform convalida i dati migrati con i seguenti controlli:

Fase 10: trasformazione del codice dell'applicazione

AWS Transform trasforma il codice dell'applicazione.NET per utilizzarlo con Aurora PostgreSQL anziché con SQL Server. Richiede il nome del ramo di destinazione nei repository per eseguire il commit del codice sorgente trasformato. Dopo aver 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à:

ADO.NET Modifiche:

Modifiche alla configurazione:

Inizia la trasformazione del codice

Fase 11: Rivedere i risultati della trasformazione

Prima di procedere all'implementazione, esamina i risultati completi della trasformazione per assicurarti che tutto sia pronto per il test.

Puoi scaricare il codice trasformato dal ramo del repository per:

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

Genera un rapporto sulla trasformazione

AWS Transform genera un rapporto di trasformazione completo:

Il rapporto include:

Fase 12: Validazione e test

Prima di passare alla produzione, verifica che l'applicazione trasformata funzioni correttamente con Aurora PostgreSQL.

Tipi di convalida

Convalida automatizzata: AWS Transform esegue controlli automatici:

Validazione umana: è necessario eseguire test aggiuntivi:

Esegui la convalida automatica

Lista di controllo per i test

Funzionalità del database:

Funzionalità dell'applicazione:

Integrità dei dati:

Prestazioni:

Fase 13: Implementazione

Dopo una convalida riuscita, distribuisci l'applicazione e il database modernizzati in produzione.

Opzioni di implementazione

Pre-deployment lista di controllo

Prima della distribuzione in produzione:

Esegui la distribuzione su Amazon ECS

Monitora l'implementazione

AWS Transform implementa la tua applicazione:

Monitora l'avanzamento dell'implementazione e verifica:

Post-deployment convalida

Dopo la distribuzione:

Analisi del fumo:

Monitoraggio delle prestazioni:

Convalida utente:

Procedure di rollback

Se sorgono problemi dopo la distribuzione:

Rollback immediato:

Rollback parziale:

Correzione avanzata:

Post-deployment ottimizzazione

Dopo una corretta implementazione:

Ottimizzazione delle prestazioni:

Ottimizzazione dei costi:

Configurazione del monitoraggio:

Documentazione: