本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

SQL Server 現代化工作流程

本節提供使用 AWS 轉換完成 SQL Server 現代化程序的step-by-step演練。

步驟 1：建立 SQL Server 現代化任務

在轉換 AWS 主控台中建立新的轉換任務，開始您的現代化旅程。

步驟 2：連線至 SQL Server 資料庫

將 AWS 轉換連接至 SQL Server 資料庫，以啟用結構描述分析和轉換。

建立資料庫連接器

步驟 3：連接原始程式碼儲存庫

AWS 轉換需要存取您的 .NET 應用程式原始程式碼，以分析和轉換與 SQL Server 資料庫互動的程式碼。 AWS 轉換支援提供原始程式碼的三種方法。

選擇您的身分驗證方法

設定 PAT 連接器 （建議）

使用 PAT 連接器，您可以在具有自訂許可的原始碼提供者中建立個人存取字符，將其安全地存放在 中 AWS Secrets Manager，並視需要 AWS 轉換擷取它。您負責管理字符生命週期，包括輪換和過期。 AWS Transform 會自動建立具有存取秘密許可的必要 IAM 角色。

PAT 連接器支援下列提供者，包括自我託管和自訂 DNS/URL 版本：

建立個人存取字符

在原始碼提供者中建立 PAT。所需的許可因提供者而異。選擇供應商的索引標籤。

GitHub

導覽至設定、開發人員設定、個人存取字符、精細字符。選取要轉換的儲存庫，並授予下列許可。

儲存庫許可

組織許可 （組織儲存庫需要）

GitLab

導覽至編輯設定檔、存取字符。選取下列範圍。

Bitbucket

導覽至帳戶設定、安全性、建立和管理 API 權杖。所需的範圍取決於您的字符類型。

工作區/儲存庫字符 (ATCT — 承載身分驗證，不需要使用者名稱）

帳戶 API 字符 (ATAT — 含電子郵件的基本身分驗證） 或應用程式密碼 (ATBB — 含使用者名稱的基本身分驗證）

Azure DevOps

導覽至使用者設定、個人存取字符。選取自訂定義的範圍。針對組織範圍，選擇所有可存取的組織 （建議） 或指定單一組織。

將 PAT 存放在 AWS Secrets Manager

如果您使用客戶受管 KMS 金鑰來加密秘密 （而非預設受管金鑰），則必須更新 KMS AWS金鑰政策，以允許 AWS Transform 解密秘密。將下列陳述式新增至客戶管理的 KMS 金鑰政策：

{
  "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"
    }
  }
}

將 REGION 取代為您的 AWS 區域 （例如 us-east-1)，並將 YOUR-SECRET-ARN 取代為您秘密的 ARN。kms:ViaService 條件可確保 KMS 金鑰只能透過 AWS Secrets Manager 服務使用。kms:EncryptionContext:SecretARN 條件會將解密限制為您的特定秘密。

若要更新您的 KMS 金鑰政策：

設定 AWS 轉換任務

AWS 轉換會自動建立具有存取秘密所需許可的 IAM 角色。

權杖輪換和維護

您有責任在 PAT 權杖過期之前輪換它們。若要輪換權杖：

故障診斷 PAT 連接器問題

設定 AWS CodeConnections

AWS CodeConnections 使用受管提供者整合，透過 OAuth 2.0 授權流程自動擷取臨時 OAuth 登入資料。許可是在提供者應用程式中設定，並完全由 管理 AWS。您授權應用程式一次，並 AWS 處理所有登入資料管理。

選取您的儲存庫和分支

儲存庫存取核准

對於 GitHub 和其他一些平台，儲存庫管理員必須核准連線請求：

步驟 4：建立部署連接器 （選用）

如果您想要將轉換的應用程式部署到 AWS 您的帳戶，您可以選擇部署連接器。

設定部署連接器

部署連接器核准

AWS 您的帳戶管理員必須核准部署連接器的連線請求。

步驟 5：確認您的資源

連線至資料庫和儲存庫後， AWS Transform 會驗證所有必要的資源是否可存取並準備好進行轉換。

AWS 轉換驗證的內容

檢閱飛行前檢查清單

步驟 6：探索和評估

AWS Transform 會分析 SQL Server 資料庫和 .NET 應用程式，以了解現代化的範圍和複雜性。

探索的內容

探索程序

檢閱探索結果

探索完成後，導覽至探索和評估以檢閱：

資料庫分析：

應用程式分析：

相依性映射：

了解複雜性評估

AWS 轉換會將現代化分為三個類別：

評估報告

AWS 轉換會產生詳細的評估報告，其中包括：

您可以下載評估報告，以便離線檢閱並與利益相關者共用。

步驟 7：產生和檢閱波動計畫

對於具有多個資料庫和應用程式的大型資產， AWS Transform 會產生波動計畫，在邏輯群組中序列化現代化。

什麼是波動計畫？

波動計畫會根據下列項目將您的現代化組織成階段 （波動）：

每個波動都包含一組資料庫和應用程式，這些資料庫和應用程式可以一起現代化，而不會中斷相依性。

檢閱波動計畫

自訂波動計畫

您可以透過 2 種方式自訂波動計畫，以符合您的業務需求：

使用 JSON：

使用聊天：

您可以與客服人員聊天，並要求其將儲存庫和資料庫移至特定波，以修改波計畫。如果您需要對波浪進行次要編輯，則此方法可正常運作。

單一資料庫現代化

如果您要現代化單一資料庫和應用程式， AWS Transform 會以一波波建立簡單的計劃。您可以直接進行轉換，無需波浪規劃。

核准波動計畫

步驟 8：結構描述轉換

AWS 轉換會將您的 SQL Server 資料庫結構描述轉換為 Aurora PostgreSQL，包括資料表、檢視、預存程序、函數和觸發。

結構描述轉換的運作方式

AWS 轉換使用透過生成式 AI 增強的 AWS DMS 結構描述轉換來：

支援的轉換

自動轉換：

可能需要人工審核：

未自動轉換：

開始結構描述轉換

檢閱轉換結果

轉換完成後，導覽至檢閱結構描述轉換：

轉換摘要：

依物件類型檢閱：

檢閱動作項目

範例：預存程序轉換

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：

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;

所做的變更：

核准結構描述轉換

步驟 9：資料遷移 （選用）

AWS 轉換提供將資料從 SQL Server 遷移至 Aurora PostgreSQL 的選項。資料遷移是選用的，如果您只需要結構描述和程式碼轉換，則可以略過。

資料遷移選項

選項 1：生產資料遷移

使用 DMS AWS 遷移實際生產資料：

選項 2：略過資料遷移

僅轉換結構描述和程式碼：

設定資料遷移

生產資料遷移程序

如果您選擇遷移生產資料：

遷移時間軸：

資料驗證

AWS 轉換會使用下列檢查來驗證遷移的資料：

步驟 10：應用程式程式碼轉換

AWS 轉換會將您的 .NET 應用程式程式碼轉換為使用 Aurora PostgreSQL 而非 SQL Server。它會要求儲存庫中的目標分支名稱遞交轉換後的原始程式碼。輸入分支名稱後， AWS Transform 將建立新的分支，並啟動轉換以符合 PostgreSQL 資料庫。

要轉換的內容

實體架構變更：

ADO.NET 變更：

組態變更：

開始程式碼轉換

步驟 11：檢閱轉換結果

在繼續部署之前，請檢閱完整的轉換結果，以確保一切已準備好進行測試。

您可以從儲存庫分支下載轉換後的程式碼，用於：

您也可以下載轉換摘要，以檢閱 AWS Transform 在轉換過程中所做的自然語言變更。

轉換摘要

產生轉換報告

AWS 轉換會產生全面的轉換報告：

報告包括：

步驟 12：驗證和測試

在部署到生產環境之前，請驗證轉換的應用程式是否與 Aurora PostgreSQL 正常運作。

驗證類型

自動化驗證： AWS Transform 會執行自動化檢查：

人工驗證：您應該執行其他測試：

執行自動驗證

測試檢查清單

資料庫功能：

應用程式功能：

資料完整性：

效能：

步驟 13：部署

驗證成功後，將您的現代化應用程式和資料庫部署到生產環境。

部署選項

部署前檢查清單

在部署到生產環境之前：

部署至 Amazon ECS

監控部署

AWS 轉換會部署您的應用程式：

監控部署進度並驗證：

部署後驗證

部署之後：

煙霧測試：

效能監控：

使用者驗證：

轉返程序

如果在部署之後發生問題：

立即轉返：

部分轉返：

轉送修正：

部署後最佳化

成功部署後：

效能調校：

成本最佳化：

監控設定：

文件：