本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

SQL 服务器现代化工作流程

本节提供了使用 AWS 转换完成的 SQL Server 现代化过程的分步演练。

步骤 1：创建 SQL Server 现代化任务

在 Trans AWS form 控制台中创建新的转换任务，开始您的现代化之旅。

步骤 2：连接到 SQL Server 数据库

将 Trans AWS form 连接到 SQL Server 数据库以启用架构分析和转换。

创建数据库连接器

第 3 步：Connect 源代码存储库

AWS Transform 需要访问您的.NET 应用程序源代码，才能分析和转换与 SQL Server 数据库交互的代码。 AWS Transform 支持三种提供源代码的方法。

选择您的身份验证方法

设置 PAT 连接器（推荐）

使用 PAT 连接器，您可以在源代码提供程序中创建具有自定义权限的个人访问令牌，将其安全地存储在中 AWS Secrets Manager，然后 T AWS ransform 会在需要时对其进行检索。您负责管理代币生命周期，包括轮换和到期。 AWS Transform 会自动创建必要的 IAM 角色，该角色具有访问您的密钥的权限。

PAT 连接器支持以下提供商，包括自托管版本和自定义 DNS/URL 版本：

创建个人访问令牌

在您的源代码提供程序中创建 PAT。所需的权限因提供商而异。选择您的提供商对应的选项卡。

GitHub

导航到 “设置”、“开发者设置”、“个人访问令牌”、“Fine-grained 令牌”。选择要转换的存储库并授予以下权限。

存储库权限

组织权限（组织仓库必需）

GitLab

导航到 “编辑个人资料”、“访问令牌”。选择以下范围。

Bitbucket

导航到 “账户设置”、“安全”、“创建和管理 API 令牌”。所需的范围取决于您的令牌类型。

Workspace/Repository 令牌（ATCT — 持有者身份验证，无需用户名）

账户 API 令牌（ATAT — 使用电子邮件进行基本身份验证）或应用程序密码（ATBB — 带用户名的基本身份验证）

天蓝色 DevOps

导航到 “用户设置”、“个人访问令牌”。选择 “自定义范围”。对于组织范围，请选择所有可访问的组织（推荐）或指定单个组织。

将 PAT 存放在里面 AWS Secrets Manager

如果您使用客户管理的 KMS 密钥来加密您的密钥（而不是默认的 AWS托管密钥），则必须更新 KMS 密钥策略以允许 Tr AWS ansform 解密密钥。将以下声明添加到您的客户管理的 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 Transform 会自动创建一个 IAM 角色，该角色具有访问您的密钥所需的权限。

代币轮换和维护

您有责任在 PAT 代币到期之前进行轮换。要轮换代币，请执行以下操作：

排除 PAT 连接器问题

设置 AWS CodeConnections

AWS CodeConnections 使用托管提供商集成，该集成可通过 OAuth 2.0 授权流程自动检索临时 OAuth 凭证。权限在提供商应用程序中配置并完全由管理 AWS。您只需对应用程序进行一次授权，即可 AWS 处理所有凭据管理。

选择您的存储库和分支

仓库访问批准

对于 GitHub 和其他一些平台，存储库管理员必须批准连接请求：

步骤 4：创建部署连接器（可选）

如果要将转换后的应用程序部署到您的 AWS 帐户，则可以选择部署连接器。

设置部署连接器

部署连接器批准

您的 AWS 账户管理员必须批准部署连接器的连接请求。

第 5 步：确认您的资源

连接到数据库和存储库后，T AWS ransform 会验证所有必需的资源是否均可访问并准备好进行转换。

内容 AWS 变换验证

查看飞行前清单

第 6 步：发现和评估

AWS Transform 会分析您的 SQL Server 数据库和.NET 应用程序，以了解现代化的范围和复杂性。

发现了什么

发现过程

查看发现结果

发现完成后，导航至 “发现和评估” 以查看：

数据库分析：

应用分析：

依赖关系图：

了解复杂性评估

AWS Transform 将您的现代化改造分为三类：

评测报告

AWS Transform 会生成一份详细的评估报告，其中包括：

您可以下载评估报告，以便离线查看并与利益相关者共享。

第 7 步：生成并查看波浪计划

对于具有多个数据库和应用程序的大型房产，Trans AWS form会生成波浪计划，按逻辑组对现代化进行排序。

什么是波浪计划？

波浪计划将您的现代化改造分为几个阶段（波次），具体基于以下几点：

每个浪潮都包含一组数据库和应用程序，这些数据库和应用程序可以在不破坏依赖关系的情况下一起进行现代化改造。

查看浪潮计划

自定义波浪计划

您可以通过两种方式自定义波浪计划以满足您的业务需求：

使用 JSON：

使用聊天：

您可以通过与代理聊天并要求其将存储库和数据库移至特定波浪来修改波浪计划。如果你需要对波浪进行少量编辑，这种方法效果很好。

单一数据库现代化

如果您要对单个数据库和应用程序进行现代化 AWS 改造，Transform 会立即创建一个简单的计划。您可以直接进行转型，而无需进行波浪规划。

批准波浪计划

步骤 8：架构转换

AWS Transform 会将你的 SQL Server 数据库架构转换为 Aurora PostgreSQL，包括表、视图、存储过程、函数和触发器。

架构转换的工作原理

AWS Transform 使用通过生成式 AI 增强的 AWS DMS 架构转换来：

支持的转换

自动转换：

可能需要人工审查：

未自动转换：

开始架构转换

查看转换结果

转换完成后，导航到 “查看架构转换”：

转换摘要：

按对象类型查看：

查看行动项目

示例：存储过程转换

SQL 服务器 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 Transform 提供了将数据从 SQL Server 迁移到 Aurora PostgreSQL 的选项。数据迁移是可选的，如果您只需要架构和代码转换，则可以跳过。

数据迁移选项

选项 1：生产数据迁移

使用 AWS DMS 迁移您的实际生产数据：

选项 2：跳过数据迁移

仅转换架构和代码：

配置数据迁移

生产数据迁移流程

如果您选择迁移生产数据：

迁移时间表：

数据验证

AWS Transform 使用以下检查来验证迁移的数据：

步骤 10：应用程序代码转换

AWS Transform 会将你的.NET 应用程序代码转换为使用 Aurora PostgreSQL 而不是 SQL Server。它要求在仓库中输入目标分支名称来提交转换后的源代码。输入分支名称后，Trans AWS form 将创建一个新分支并启动转换以匹配 PostgreSQL 数据库。

什么会被改变

实体框架变更：

ADO.NET 变化：

配置更改：

开始代码转换

步骤 11：查看转换结果

在继续部署之前，请查看完整的转换结果，以确保一切准备就绪，可以进行测试。

您可以从存储库分支下载转换后的代码，用于：

您也可以下载转换摘要，以查看 Transform 在 AWS 转换过程中所做的自然语言更改。

转换摘要

生成转换报告

AWS Transform 会生成一份全面的转换报告：

该报告包括：

第 12 步：验证和测试

在部署到生产环境之前，请验证转换后的应用程序是否可以与 Aurora PostgreSQL 一起正常运行。

验证类型

自动验证：T AWS ransform 执行自动检查：

人工验证：您应该进行其他测试：

运行自动验证

测试清单

数据库功能：

应用程序功能：

数据完整性：

性能：

步骤 13：部署

成功验证后，将现代化的应用程序和数据库部署到生产环境中。

部署选项

Pre-deployment 清单

在部署到生产环境之前：

部署到 Amazon ECS

监控部署

AWS Transform 会部署您的应用程序：

监控部署进度并验证：

Post-deployment 验证

部署后：

烟雾测试：

性能监控：

用户验证：

回滚程序

如果部署后出现问题：

立即回滚：

部分回滚：

向前修复：

Post-deployment 优化

成功部署后：

性能调整：

成本优化：

监控设置：

文档：