本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # SQL 服务器现代化工作流程 本节分步演示了使用 AWS 转换完成的 SQL Server 现代化过程。 ## 步骤 1：创建 SQL Server 现代化作业 在 Trans AWS form 控制台中创建新的转型任务，开始您的现代化之旅。 1. 登录到 T AWS ransform 控制台 1. 选择**创建现代化任务 ** 1. 选择 ** Windows 现代化**作业，然后选择 ** SQL Server 现代化改造 ** 1. 输入工作详情： + **职位名称**：项目的描述性名称 + **描述**：可选描述 + **目标 AWS 区域**：部署区域 1. 选择 **Create job (创建作业）**。 **重要** 请勿在职位名称中包含个人身份信息 (PII)。 ## 步骤 2：连接到 SQL Server 数据库 将 T AWS ransform 连接到您的 SQL Server 数据库以启用架构分析和转换。 ### 创建数据库连接器 1. 在您的 SQL Server 现代化任务中，导航到 “连接资源” 1. 选择 “**连接到 SQL Server 数据库” ** 1. 选择 “**创建新连接器” ** 1. 输入连接器信息： + C ** 连接器名称**：描述性名称 + **AWS 账户 ID**：托管 SQL Server 的帐户 1. 确认后，您将收到批准链接。复制批准链接以获得 AWS 管理员对该账户的批准。他们批准后，您可以继续下一步。 1. 管理员批准连接器请求后，单击 “提交” 继续进行源代码连接设置。 ## 第 3 步：连接源代码存储库 AWS Transform 需要访问您的.NET 应用程序源代码来分析和转换与 SQL Server 数据库交互的代码。 AWS Transform 支持三种提供源代码的方法。 ### 选择您的身份验证方法 个人访问令牌 (PAT) 连接器（推荐） 最适合需要自定义权限范围、自托管提供商支持或访问提供商专用 API（例如 Secrets）的团队。 GitHub 您可以在具有自定义权限的源代码提供商中创建 PAT，将其存储在中 AWS Secrets Manager，然后 T AWS ransform 在需要时检索它。您负责管理代币的轮换和到期。 AWS CodeConnections 最适合需要自动凭据管理的团队。 AWS CodeConnections 使用托管提供商集成，通过 OAuth 2.0 授权流程处理身份验证。 AWS 管理整个凭证生命周期，包括自动令牌刷新和轮换。无需手动凭据管理。 Amazon S3 将您的源代码直接上传到 Amazon S3 存储桶。 AWS Transform 在转换任务期间访问存储桶中的代码。 | 功能 | PAT 连接器（推荐） | AWS CodeConnections | | --- | --- | --- | | 凭证管理 | 手动（客户管理） | 自动（AWS-管理） | | 代币生命周期 | 需要手动旋转 | 自动刷新 | | 权限灵活性 | 完全可定制的范围 | 固定权限 | | Self-hosted 提供商支持 | 支持 | 不可用 | | 设置复杂性 | 中等（手动创建和存储令牌） | 低（一次性授权） | | 代币存储 | 客户的 AWS Secrets Manager | AWS托管式 | ### 设置 PAT 连接器（推荐） 使用 PAT 连接器，您可以在源代码提供商中创建具有自定义权限的个人访问令牌，将其安全地存储在 T AWS ransform 中 AWS Secrets Manager，并在需要时检索。您负责管理代币生命周期，包括轮换和到期。 AWS Transform 会自动创建必要的 IAM 角色，该角色具有访问您的密钥的权限。 PAT 连接器支持以下提供商，包括自托管版本和自定义 DNS/URL 版本： + GitHub 和 GitHub 企业服务器 + GitLab.com 和 GitLab Self-Managed + Bitbucket 云和 Bitbucket 数据中心 + Azure DevOps 和天蓝色 DevOps 服务器 #### 创建个人访问令牌 在源代码提供商中创建 PAT。所需的权限因提供商而异。为您的提供商选择选项卡。 **重要** 创建后立即复制令牌。您无法再次查看。设置转换任务持续时间的到期时间。不要将过期时间设置为永不过期。 **警告** 切勿将 PAT 令牌提交到代码存储库或通过不安全的渠道共享。务必将它们存放在里面 AWS Secrets Manager。 ##### GitHub 导航到 “**设置” **、“**开发者设置” **、“**个人访问令牌” **、“**Fine-grained 令牌” **。选择要转换的存储库并授予以下权限。 **存储库权限 ** | 权限 | 访问 | 用途 | | --- | --- | --- | | 内容 | 读取和写入 | 读取源代码并将转换后的代码写回存储库 | | 元数据 | Read-only | 访问基本存储库信息 | **组织权限（组织仓库必需）** | 权限 | 访问 | 用途 | | --- | --- | --- | | 成员 | Read-only | 列出令牌可访问的用于存储库发现的组织 | ##### GitLab 导航到 “**编辑配置文件” **、“**访问令牌” **。选择以下范围。 | Scope | 用途 | | --- | --- | | read\_api | 读取存储库元数据、项目信息、用户详细信息，并列出群组和分支 | | read\_repository | 读取源代码文件和存储库结构以进行分析 | | write\_repository | 将转换后的代码写回存储库 | ##### Bitbucket 导航到 “**账户设置” **、“**安全” **、“**创建和管理 API 令牌” **。所需的范围取决于您的代币类型。 **Workspace/Repository 代币（ATCT — 持有者身份验证，无需用户名）** | 权限 | 访问 | 用途 | | --- | --- | --- | | Repositories | 读取和写入 | 通过 git push 列出存储库、读取分支和写入转换后的代码 | **账户 API 令牌（ATAT — 使用电子邮件进行基本身份验证）或应用程序密码（ATBB — 带用户名的基本身份验证）** | Scope | 用途 | | --- | --- | | read:account | 识别经过身份验证的用户以解析存储库成员资格 | | read:workspace:bitbucket | 列出令牌可以访问的工作空间，以便 T AWS ransform 可以枚举其存储库。如果您在密钥中指定工作空间列表，则不需要。 | | read:repository:bitbucket | 列出存储库并读取元数据和分支信息 | | write:repository:bitbucket | 通过 git push 将转换后的代码写回存储库 | ##### 天蓝色 DevOps 导航到**用户设置**，**个人访问令牌**。选择 “**自定义**范围”。对于组织范围，选择**所有可访问的组织**（推荐）或指定一个组织。 | Scope | 访问 | 用途 | | --- | --- | --- | | 代码 | 读取和写入 | 读取源代码，列出存储库和分支，并将转换后的代码写回去 | | 用户档案 | 读取 | 验证令牌访问权限并发现用户身份以进行组织查询 | | 会员权限管理 | 读取 | 列出令牌可访问的用于存储库发现的组织 | #### 将 PAT 存储在 AWS Secrets Manager 1. 打开控制 AWS Secrets Manager 台。 1. 选择**存储新密钥**。 1. 对于**密钥类型**，请选择**其他密钥类型**。 1. 根据您的提供商和托管类型添加键值对： + **Cloud-hosted 提供商 **-添加一个以您的 PAT 作为值命名的`token`密钥。 + 对于 DevOps 具有特定组织的 Azure，还要添加一个`organization`以您的组织名称命名的密钥。 + 对于 Bitbucket 应用程序密码 (ATBB)，还要添加一个以您的 Bitbucket 用户名命名的`username`密钥。对于 Bitbucket 账户 API 代币 (ATAT)，添加一个以您的 Bitbucket `email` 电子邮件地址命名的密钥。 + **Self-hosted 和自定义 DNS/URL 提供商 ** — 添加以下密钥：`host`（例如，您的服务器 URL`https://github.mycompany.com`）、`provider_type`（`github`、`gitlab``bitbucket`、或`ado`）和`token`（您的 PAT）。 + 对于 DevOps 具有特定组织的 Azure，还要添加一个`organization`以您的组织名称命名的密钥。 + 对于 Bitbucket 应用程序密码 (ATBB)，还要添加一个以您的 Bitbucket 用户名命名的`username`密钥。对于 Bitbucket 账户 API 代币 (ATAT)，添加一个以您的 Bitbucket `email` 电子邮件地址命名的密钥。 以下示例显示了如何查看 GitHub 云托管提供商 AWS Secrets Manager 的密钥： ``` { "token": "{{your-github-personal-access-token}}" } ``` 以下示例显示了 Bitbucket 应用程序密码 (ATBB)： ``` { "token": "{{your-bitbucket-app-password}}", "username": "my-bitbucket-username" } ``` 以下示例显示了一个自托管 GitLab 实例： ``` { "host": "https://gitlab.mycompany.com", "provider_type": "gitlab", "token": "{{your-gitlab-personal-access-token}}" } ``` 1. 选择**下一步**。 1. 例如，输入密钥名称`github-pat-myproject`。 1. （可选）选择客户管理的 KMS 密钥进行加密。 1. 完成向导并选择**存储**。 1. 复制秘密 ARN。配置 AWS 转换作业时需要此值。 如果您使用客户管理的 KMS 密钥来加密您的密钥（而不是默认的 AWS托管密钥），则必须更新 KMS 密钥策略以允许 T AWS ransform 解密密钥。将以下语句添加到您的客户管理的 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 密钥策略，请执行以下操作： 1. 在以下位置打开 AWS KMS 控制台`https://console.aws.amazon.com/kms`。 1. 在导航窗格中，选择**客户托管密钥**。 1. 选择您的 KMS 密钥。 1. 在**密钥策略**选项卡上，选择**编辑**。 1. 将政策声明添加到现有策略中。 1. 选择**保存更改**。 **注意** 如果您使用默认 AWS-managed 密钥 (`aws/secretsmanager`)，则无需修改任何 KMS 密钥策略。 #### 配置 AWS 转变工作 1. 在您的 AWS 转换任务中，导航到 “**连接资源” **。 1. 选择 “**连接源代码存储库” **。 1. 选择 ** PAT 连接器**作为身份验证方法。 1. 输入步骤 2 中的密钥 ARN。 1. （可选）如果您使用客户管理的 KMS 密钥，请输入 KMS 密钥 ARN。 1. 选择您的存储库和分支。 1. 选择**继续**。 AWS Transform 会自动创建一个 IAM 角色，该角色具有访问您的密钥所需的权限。 #### 代币轮换和维护 您有责任在 PAT 代币到期之前对其进行轮换。要轮换代币，请执行以下操作： 1. 在源代码提供商中生成具有相同权限的新 PAT。 1. 更新中的密钥值 AWS Secrets Manager。 1. 验证您的 T AWS ransform 任务是否可以使用新令牌访问存储库。 1. 撤销源代码提供商中的旧 PAT。 #### 排除 PAT 连接器问题 访问被拒绝 — PAT 无效 确认 PAT 尚未过期。确认 PAT 具有您的提供商所需的范围。检查 PAT 是否正确存储在中 AWS Secrets Manager。 无法检索密钥 验证密钥 ARN 是否正确。检查任务日志以确认 T AWS ransform 创建了 IAM 角色。如果您使用的是客户管理的 KMS 密钥，请验证密钥策略。 权限不足 PAT 可能缺乏所需的操作范围。使用所需范围重新生成 PAT，并在中 AWS Secrets Manager更新密钥值。 ### 设置 AWS CodeConnections AWS CodeConnections 使用托管提供商集成，通过 OAuth 2.0 授权流程自动检索临时 OAuth 证书。权限在提供商应用程序中配置并完全由管理 AWS。您对应用程序进行一次授权，然后 AWS 处理所有凭据管理。 1. 在您的 SQL Server 现代化任务中，导航到 “**连接资源” **。 1. 选择 “**连接源代码存储库” **。 1. 如果您没有现有连接，请选择**创建连接**。 1. 选择您的存储库提供商： + GitHub / GitHub 企业 + GitLab.com + Bitbucket Cloud + Azure 存储 1. 遵循提供商的授权流程。 1. 授权后，选择 “**连接” **。 ### 选择您的存储库和分支 1. 从列表中选择您的存储库。 1. 选择要转换的分支（通常是主分支、主分支或开发分支）。 1. （可选）如果您的 .NET 应用程序不在存储库根目录中，请指定子目录。 1. 选择**继续**。 **注意** AWS Transform 为转换后的代码创建一个新分支。您可以通过正常的代码审查流程来审查和合并更改。 ### 仓库访问批准 对于 GitHub 其他一些平台，存储库管理员必须批准连接请求： 1. AWS Transform 显示验证链接。 1. 与您的仓库管理员共享此链接。 1. 管理员在其存储库设置中审阅和批准请求。 1. 管理员批准请求后，连接状态更改为 “*已批准” *。 **重要** 批准过程可能需要时间，具体取决于您组织的政策。相应地做好计划。 ## 步骤 4：创建部署连接器（可选） 如果您想将转换后的应用程序部署到您的 AWS 账户，则可以选择部署连接器。 ### 设置部署连接器 1. **如果要部署应用程序，请选择 “**是”。选择 “**否” ** 将跳过此步骤。 1. 将您的 AWS 帐户添加到要部署转换后的应用程序的位置。 1. 添加一个可以帮助您轻松记住连接器的名称 1. 提交连接器请求以供批准。 ### 部署连接器批准 您的 AWS 账户管理员必须批准部署连接器的连接请求。 1. AWS Transform 显示验证链接 1. 与您的 AWS 账户管理员分享此链接 1. 管理员在其存储库设置中审阅和批准请求 1. 批准后，连接状态更改为*已批准 * **重要** 批准过程可能需要时间，具体取决于您组织的政策。相应地做好计划。 ## 第 5 步：确认您的资源 连接到您的数据库和存储库后，T AWS ransform 会验证所有必需的资源均可访问并准备好进行转换。 ### 内容 AWS 转换验证 + **数据库连接：**连接处于活动状态，用户具有所需的权限，可以访问数据库，支持版本 + **存储库访问权限：**存储库可访问、分支存在、检测到.NET 项目文件、可发现数据库连接 + **环境就绪：**VPC 配置支持 DMS，存在所需的 AWS 服务角色，网络连接已建立，区域兼容性已确认 ### 查看飞行前清单 1. 导航至 “**确认工作计划**中的资源” 1. 查看清单项目： + ✅ 数据库连接已验证 + ✅ 存储库访问权限已确认 + ✅ 支持.NET 版本 + ✅ 实体框架或 ADO.NET 已检测 + ✅ 网络配置有效 + ✅ 已授予所需权限 1. 如果所有项目都显示为已完成，请选择 “继续” 1. 如果有任何项目显示警告或错误，请在继续操作之前解决这些问题 ## 第 6 步：发现和评估 AWS Transform 会分析您的 SQL Server 数据库和.NET 应用程序，以了解现代化的范围和复杂性。 ### 发现了什么 + **数据库对象：**表、视图、索引、存储过程、函数、触发器、约束、数据类型、计算列、标识列、外键关系 + **应用程序代码：**.NET 项目结构、实体框架模型和配置、 ADO.NET 数据访问代码、数据库连接字符串、存储过程调用、代码中的 SQL 查询 + **依赖关系：**哪些应用程序使用哪些数据库、跨数据库依赖关系、共享存储过程、常见数据访问模式 ### 发现过程 + AWS 确认资源后，Transform 会自动开始发现 + 发现通常需要 5-15 分钟，具体取决于数据库大小和应用程序的复杂性 + 监控工作日志中的进度 + AWS Transform 会在发现对象时显示实时更新 ### 查看发现结果 发现完成后，导航到 “**发现和评估” ** 以查看： **数据库分析：** + **对象数**：表、视图、存储过程、函数、触发器的数量 + **复杂度分数**：评估转换复杂度（低、中、高） + **操作项目**：可能需要人类注意的物体 + **支持的功能**：将自动转换的数据库功能 + **不支持的功能**：需要变通办法的功能 **应用分析：** + **项目类型**： ASP.NET 核心、控制台应用程序、类库等 + **.NET 版本**：检测到的 .NET Core 版本 + **数据访问框架**：实体框架版本或 ADO.NET + **数据库连接**：找到的连接字符串的数量 + **代码复杂性**：评估转换复杂性 **依赖关系图：** + 应用程序与数据库关系的可视化表示 + Cross-database 依赖关系 + 共享组件 ### 了解复杂性评估 AWS Transform 将您的现代化分为三类： | 复杂度 | 特性 | 预期结果 | | --- | --- | --- | | 低（A 级） | 标准 SQL 模式 (ANSI SQL)、简单存储过程、基本数据类型、具有标准配置的实体框架 | 预计人工干预最少，自动化成功率高 | | 中型（B 级） | 高级 T-SQL 模式、带有业务逻辑的复杂存储过程、用户定义的函数、计算列 | 需要一些人工干预，建议进行专家审查 | | 高级（C 级） | CLR 程序集、链接服务器、服务代理、复杂的全文搜索 | 需要大量的人工重构，考虑分阶段的方法 | ### 评测报告 AWS Transform 会生成一份详细的评估报告，其中包括： + 包含高级概述的执行摘要 + 完成数据库清单 + 应用程序清单 + 转型准备百分比 + 工作量估算 + 风险评估和缓解策略 + 推荐方法 您可以下载评估报告以供离线审查并与利益相关者共享。 ## 第 7 步：生成和审查波浪计划 对于拥有多个数据库和应用程序的大型庄园，T AWS ransform 会生成波浪计划，按逻辑组对现代化进行排序。 ### 什么是波浪计划？ Wave 计划基于以下内容将您的现代化改造分为几个阶段（波浪）： + 数据库和应用程序之间的依赖关系 + 业务优先事项 + 风险承受能力 + 资源可用性 + 技术复杂性 每波都包含一组数据库和应用程序，这些数据库和应用程序可以在不破坏依赖关系的情况下一起进行现代化改造。 ### 查看波浪计划 1. 导航到工作计划**中的 ** Wave 规划 1. 查看拟议的波浪 1. 对于每波浪潮，请查看： + 包括数据库 + 包括应用程序 + 对其他波浪的依赖 + 预计转换时间 + 复杂性级别 + 可部署的应用程序 ### 自定义波浪计划 您可以通过两种方式自定义 Wave 计划以满足您的业务需求： **使用 JSON：** 1. 选择 “**下载所有波次” ** 以获取包含所有波次的 JSON 文件 1. 通过以下方式修改 JSON 中的波浪： + 在波次之间移动数据库 + 将波浪分成较小的组 + 将波浪融合在一起 + 改变波浪顺序 + 在作用域中添加或移除数据库 1. 选择上传波次计划，将 JSON 文件**上传回控制台 ** 1. AWS Transform 会验证您的更改并在违反依赖关系时发出警告 1. 选择 “**确认波动” ** 以更新波次计划 **使用聊天：** 您可以通过与代理聊天并要求其将存储库和数据库移至特定波次来修改波次计划。如果你需要对波浪进行细微的编辑，这种方法效果很好。 **重要** 在自定义波次时确保尊重依赖关系。在依赖应用程序的数据库之前对其进行转换可能会导致问题。 ### 单一数据库现代化 如果您要对单个数据库和应用程序进行现代化改造，T AWS ransform 只需一次即可创建一个简单的计划。无需波浪规划，即可直接进行转型。 ### 批准波浪计划 1. 审查和自定义（如果需要）后，选择**批准波动计划 ** 1. AWS Transform 锁定波浪计划并继续转型 1. 稍后您仍然可以通过选择 “**编辑波动计划” 来修改计划 ** ## 第 8 步：架构转换 AWS Transform 将您的 SQL Server 数据库架构转换为 Aurora PostgreSQL，包括表、视图、存储过程、函数和触发器。 ### 架构转换的工作原理 AWS Transform 使用生成式 AI 增强的 AWS DMS 架构转换来： + 分析 SQL Server 架构和关系 + 将数据类型从 SQL Server 映射到 PostgreSQL 等效项 + 转换 T-SQL 为 PL/pgSQL + 处理标识列、计算列和约束 + 验证转换和引用完整性 + 为需要人工审查的对象生成操作项 ### 支持的转换 **自动转换：** + 表、视图和索引 + 主键和外键 + 检查约束条件和默认值 + 最常见的数据类型 + 简单的存储过程 + 基本功能和触发器 + 标识列（转换为 SERIAL 或 GENERATED） + 大多数计算列 **可能需要人工审查：** + 具有高级功能的复杂存储过程 T-SQL + SQL Server-specific 函数（GETUTCDATE、SUSER\_SNAME 等） + 带有复杂表达式的计算列 + Full-text 搜索索引 + XML 数据类型操作 + HIERARCHYID 数据类型（需要 ltree 扩展名） **未自动转换：** + CLR 程序集 + 链接服务器 + 服务代理 + SQL Server Agent 作业 ### 开始架构转换 1. 导航到工作计划中的架构转换 1. 查看转换设置： + 目标 PostgreSQL 版本 + 扩展选项（ltree、PostGIS 等） + 命名规范 1. 选择 “**开始转换” ** 1. 在工作日志中监控进度 1. 转换通常需要 10-30 分钟，具体取决于数据库对象的数量 ### 查看转换结果 转换完成后，导航到 “查看架构转换”： **转换摘要：** + **转换的对象**：成功转换的对象数 + **操作项目**：需要人类注意的物体 + **警告**：需要审查的潜在问题 + **错误**：无法转换的对象 **按对象类型查看：** + **表**：数据类型映射、约束、索引 + **存储过程**： T-SQL 转 PL/pgSQL 换 + **函数**：函数签名和逻辑更改 + **触发器**：触发器语法和时间变化 ### 查看操作项目 1. 选择 “**查看操作项目” ** 1. 对于每个操作项目，请查看： + **对象名称**：数据库对象 + **问题类型**：需要注意的问题 + **严重程度**：严重、警告或信息 + **建议**：建议的解决方案 + **原始代码**：SQL Server 版本 + **转换后的代码**：PostgreSQL 版本 1. 对于每个操作项目，您可以： + **接受**：使用转换后的代码 + **修改**：编辑转换后的代码 + **标记以备后用**：转型后标记供人工审查 ### 示例：存储过程转换 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; ``` 所做的更改： + 过程转换为返回 TABLE 的函数 + 以 p\_ 为前缀的参数名 + TOP 转换为 LIMIT + DATEDIFF 转换为 EXTRACT + GETUTCDATE () 转换为 NOW () + 列名转换为小写（PostgreSQL 惯例） ### 批准架构转换 1. 在审查了所有操作项目并进行了必要的修改之后 1. 选择 “**批准架构转换” ** 1. AWS Transform 为部署到 Aurora PostgreSQL 准备转换后的架构 **注意** 您可以将转换后的架构下载为 SQL 脚本以供离线查看或版本控制。 ## 步骤 9：数据迁移（可选） AWS Transform 提供了将数据从 SQL 服务器迁移到 Aurora PostgreSQL 的选项。数据迁移是可选的，如果您只需要架构和代码转换，则可以跳过。 ### 数据迁移选项 **选项 1：生产数据迁移 ** 使用 AWS DMS 迁移您的实际生产数据： + 所有数据的全部初始加载 + 测试期间的持续复制 (CDC) + 最少的停机时间切换 + 数据验证和完整性检查 **选项 2：跳过数据迁移 ** 仅转换架构和代码： + 对 development/testing 环境有用 + 何时单独迁移数据 + 用于概念验证项目 ### 配置数据迁移 1. 导航到工作计划**中的**数据迁移 1. 选择您的迁移选项： + **迁移生产数据 ** + **跳过数据迁移 ** 1. 如果要迁移生产数据，请配置： + **迁移类型**：满负荷或满载 \+ CDC + **验证**：启用数据验证 + **性能**：DMS 实例大小 + 选择 ** >开始迁移 ** ### 生产数据迁移流程 如果您选择迁移生产数据： 1. **初始同步**： AWS DMS 对所有表执行满负荷 1. **持续复制**：（如果启用 CDC）保持数据同步 1. **验证**：验证行数和数据完整性 1. **切换准备**：为最终同步做准备 迁移时间表： + 小型数据库 (< 10 GB)：30 分钟-2 小时 + 中型数据库 (10-100 GB)：2-8 小时 + 大型数据库 (> 100 GB)：8 小时以上 ### 数据验证 AWS Transform 通过以下检查来验证迁移的数据： + 行数比较（源与目标） + 主密钥完整性 + 外键关系 + 数据类型兼容性 + 计算列结果 + 空值处理 ## 第 10 步：应用程序代码转换 AWS Transform 将您的.NET 应用程序代码转换为与 Aurora PostgreSQL 而不是 SQL Server 一起使用。它要求在您的存储库中输入目标分支名称以提交转换后的源代码。输入分支名称后，T AWS ransform 将创建一个新分支并启动转换以匹配 PostgreSQL 数据库。 ### 什么会被改变 **实体框架变更：** + **数据库提供商**: UseSqlServer() → UseNpgsql () + **连接字符串**：SQL 服务器格式 → PostgreSQL 格式 + **数据类型映射**：SQL 服务器类型 → PostgreSQL 类型 + **DbContext 配置**：SQL Server-specific → PostgreSQL-specific + **迁移文件**：针对 PostgreSQL 兼容性进行了更新 **ADO.NET 更改：** + **连接类别**: SqlConnection → NpgsqlConnection + **命令类**: SqlCommand → NpgsqlCommand + **数据读取器**: SqlDataReader → NpgsqlDataReader + **参数**: SqlParameter → NpgsqlParameter + S ** SQL 语法**： T-SQL → PostgreSQL SQL **配置更改：** + appsettings.json 中的连接字符串 + 数据库提供商 NuGet 包 + 依赖注入配置 + Startup/Program.cs 配置 ### 开始代码转换 1. 导航到工作计划中的应用程序转换 1. 查看转换设置： + **目标 .NET 版本**（如果升级） + **PostgreSQL 提供商版本 ** + **代码风格首选项 ** 1. 选择 “**开始转换” ** 1. 在工作日志中监控进度 1. 转换通常需要 15-45 分钟，具体取决于代码库的大小 ## 步骤 11：查看转换结果 在继续部署之前，请查看完整的转换结果，确保一切准备就绪，可以进行测试。 你可以从存储库分支下载转换后的代码，用于： + 本地测试和验证 + 在 IDE 中进行代码审查 + 与您的 CI/CD 管道集成 + 版本控制提交 您还可以下载转换摘要，以查看 Transform 在 AWS 转换过程中所做的自然语言更改。 ### 转型摘要 1. 导航到工作计划**中的**转型摘要 1. 查看总体结果： + **架构转换**：已转换的对象、操作项、警告 + **数据迁移**：迁移的表、传输的行、验证状态 + **代码转换**：文件已更改、行已修改、问题已解决 + **就绪程度分数**：总体部署就绪情况 ### 生成转型报告 AWS Transform 会生成一份全面的转型报告： 1. 选择 “**生成报告” ** 1. 选择报告类型： + **内容提要**：利益相关者 High-level 概述 + **技术细节**：完整的转换文档 + **操作项目**：所需的人工任务清单 1. 选择**下载报告 ** 该报告包括： + 转型范围和目标 + 对象和代码已转换 + 遇到的问题和解决方案 + 验证结果 + 部署准备情况评估 + 测试建议 ## 第 12 步：验证和测试 在部署到生产环境之前，请验证转换后的应用程序是否可以与 Aurora PostgreSQL 一起正常运行。 ### 验证类型 **自动验证：T ** AWS ransform 执行自动检查： + 针对源数据库进行架构验证 + 数据完整性验证 + 查询等效性测试 + 连接字符串验证 + 配置验证 **人工验证：**你应该进行额外的测试： + 应用程序功能的功能测试 + 与其他系统的集成测试 + 性能测试和基准测试 + 用户验收测试 + 安全测试 ### 运行自动验证 1. 导航到工作计划**中的**验证 1. 选择 “**运行验证” ** 1. AWS Transform 执行验证测试： + 数据库连接 + 架构兼容性 + 数据完整性 + 应用程序构建 + 基本功能 1. 查看验证结果： + 通过：测试成功 + 失败：需要注意的测试 + 警告：需要审查的潜在问题 ### 测试清单 **数据库功能：** + 所有表格均可访问 + 存储过程正确执行 + 函数返回预期结果 + 触发器会正确触发 + 限制措施得到正确执行 + 索引提高了查询性能 **应用程序功能：** + 应用程序成功启动 + 数据库连接已建立 + CRUD 操作正常运行 + 存储过程调用成功 + commit/rollback 正确交易 + 错误处理按预期工作 **数据完整性：** + 行数与源匹配 + 主键是唯一的 + 外键有效 + 计算列正确 + 适当处理空值 + 数据类型兼容 **性能：** + 查询响应时间可接受 + 连接池已配置 + 索引已优化 + 没有 N\+1 查询问题 + 批量操作高效 + 资源利用率合理 ## 步骤 13：部署 成功验证后，将您的现代化应用程序和数据库部署到生产环境中。 ### 部署选项 + 亚马逊 ECS 和亚马逊 EC2 Linux ### Pre-deployment 清单 在部署到生产环境之前： + 所有验证测试均已通过 + 性能测试已完成 + 安全审查已完成 + 备份和回滚计划已记录在案 + 已配置监控和警报 + 团队接受了新环境培训 + 利益相关者已获知部署情况 + 已安排维护窗口 ### 部署到 Amazon ECS 1. 在工作计划**中导航到**部署 1. 选择 “**部署到 ECS” ** 1. 配置部署设置： + **集群**：选择或创建 ECS 集群 + **服务**：配置 ECS 服务 + **任务定义**：查看生成的任务定义 + **负载均衡器**：配置 ALB/NLB + **Auto-scaling**: 设置扩展策略 1. 查看基础设施即代码（CloudFormation 模板或 CDK 代码） AWS 1. 选择**部署** ### 监控部署 AWS Transform 会部署您的应用程序： 1. 创建奥罗拉 PostgreSQL 集群 1. 应用数据库架构 1. 加载数据（如果适用） 1. 部署应用程序容器 1. 配置负载均衡器 1. 设置自动缩放 监控部署进度并验证： + 基础设施预调配 + 数据库初始化 + 应用程序部署 + 健康检查通过 + 应用程序可访问 + 数据库连接正常 + 显示正常操作的日志 ### Post-deployment 验证 部署后： **烟雾测试：** + 验证关键功能 + 测试密钥用户工作流程 + 检查集成点 + 监控错误率 **性能监控：** + 跟踪响应时间 + 监控数据库查询 + 检查资源利用率 + 查看应用程序日志 **用户验证：** + 进行用户验收测试 + 收集反馈 + 解决任何问题 + 记录经验教训 ### 回滚程序 如果部署后出现问题： **立即回滚：** + 恢复到以前的应用程序版本 + 切换回 SQL Server（如果仍然可用） + 如果需要，从备份中恢复 **部分回滚：** + 回滚特定组件 + 保留数据库更改 + 仅还原应用程序代码 **向前修复：** + 将修补程序应用于 Aurora PostgreSQL 版本 + 部署更新的应用程序代码 + 显示分辨率 **重要** 在切换后保持 SQL Server 数据库的一段时间内可用，以便在需要时启用回滚功能。 ### Post-deployment 优化 成功部署后： **性能调整：** + 优化慢速查询 + 调整连接池设置 + Fine-tune 奥罗拉 PostgreSQL 参数 + 查看和优化索引 **成本优化：** + Right-size 奥罗拉实例 + 适当配置自动缩放 + 查看存储设置 + 优化备份保留 **监控设置：** + 配置 CloudWatch 仪表板 + 设置警报 + 启用增强监控 + 配置性能见解 **文档：** + 更新运行手册 + 文档架构变更 + 培训运营小组 + 创建疑难解答指南