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

# 使用转化评估报告进行迁移规划
<a name="assessment-reports-planning"></a>

转换评估报告是数据库迁移旅程的第一步。组织使用该报告来评估迁移的复杂性，并在承诺实施全面迁移项目之前做出明 go/no智的决策。

## 计算总迁移工作量
<a name="assessment-reports-planning-effort"></a>

`Action_Items_Summary`CSV 文件为用于估算工作量的每种操作项类型提供了三个值：
+ **学习曲线工作量 ** — 了解不兼容性并为该操作项类型设计转换方法的一次性成本。无论有多少数据库对象受到影响，每种操作项类型都要承担一次此费用。
+ **转换某一事件的努力量 ** — 在您已经设计了转化方法之后，解决此操作项的单个事件的成本。
+ **出现次数 **-受此操作项类型影响的单个数据库对象的数量。

**注意**  
CSV 中的努力值是加权量表上的相对单位，而不是小时数。要转换为工时或人日，请乘以根据团队执行类似迁移工作的历史速度得出的校准系数。

最简单的估计将每一次事件视为同样困难。使用此公式作为最坏情况的上限：

```
Effort for one action item type =
    Learning curve effort + (Effort per occurrence × Number of occurrences)
```

将所有操作项类型相加，得出总的上限估算值：

```
Total effort (upper bound) =
    Sum of [ Learning curve effort + (Effort per occurrence × Occurrences) ]
    for every action item type
```

例如，样本 Oracle-to-PostgreSQL 评估中的操作项目 5028 的学习曲线努力度为 40，每次出现的努力为 8，并有 12 次出现。它的上限总数为 40 \+ (8 × 12) = 136。

上限公式夸大了工作量，因为它假设每次发生都需要相同的工作量。实际上，一旦您的团队解决了操作项类型的前几次出现的问题，后续出现的速度就会变得更快——解决方案已知，转换是例行的。更现实的模型可以抵消大多数事件。

将出现的事件分成两组：一个领导小组，你在建立解决方案时全力以赴地完成工作；另一个小组，在模式建立后你半心半意地解决这个问题。根据球队的信心水平选择分组：

```
Realistic effort for one action item type =
    (Leading% × Occurrences × Effort per occurrence)
  + (Remaining% × Occurrences × (Effort per occurrence ÷ 2))
```

下表显示了三种场景供迁移团队选择：


**工作量估算情景**  

| 场景 | 领导小组 | 剩下的群组 | 何时使用 | 
| --- | --- | --- | --- | 
| 乐观 | 10% | 90% | 经验丰富的团队，广为人知的目标引擎，大多数不兼容之处都是机械的，而且高度重复。 | 
| 中 | 30% | 70% | 混合经验水平，一些动作项目类型对团队来说是新颖的，典型的迁移项目。 | 
| 保守 | 50% | 50% | 新团队、首次迁移到此目标引擎或操作项涵盖许多不同的数据库对象类型。 | 

例如，操作项 5127（“在 PostgreSQL 中使用交叉连接可能会导致性能降低”）有 8 次出现，每次出现的努力为 160 次。上限估计值为 16 \+ (160 × 8) = 1,296。使用中等情景（30/70 拆分）：（0.30 × 8 × 160）\+（0.70 × 8 × 80）= 384 \+ 448 = 832 — 减少了36％。使用乐观情景（10/90 拆分）：（0.10 × 8 × 160）\+（0.90 × 8 × 80）= 128 \+ 576 = 704 — 下降了46％。

**注意**  
CSV 中的学习曲线是固定的一次性成本，不会随着重复而减少。在基于场景的发生成本的基础上，为每种操作项目类型添加一次。场景折扣仅适用于每次出现的努力，不适用于学习曲线的努力。

要计算实际迁移的总工作量，请将您选择的场景应用于每种操作项类型，并对结果求和：

```
Total realistic effort =
    Sum of [ Learning curve effort
             + (Leading% × Occurrences × Effort per occurrence)
             + (Remaining% × Occurrences × (Effort per occurrence ÷ 2)) ]
    for every action item type
```

## 对行动项目进行优先排序
<a name="assessment-reports-planning-prioritization"></a>

使用每个操作项的复杂性类别和出现次数来决定解决这些操作项的顺序。以这种方式确定行动项目的优先顺序有助于您首先解决对迁移时间表影响最大的工作。

1. **出现次数高的复杂操作 **-首先解决这些操作项目。它们每次出现需要最多的人工劳动，而高发生次数会使整个架构中的工作量成倍增加。

1. **Medium-complexity 操作 ** — 接下来处理这些操作项目。与复杂的操作相比，它们设计转换方法所需的精力通常更少，但仍需要手动转换工作。

1. **简单操作 **-在需要手动操作的措施项中，将这些操作项的优先级设为最低。它们通常需要最少的努力来解决。

1. **自动转换的数据库对象 **-这些数据库对象无需执行任何操作。DMS 架构转换无需任何手动干预即可对其进行转换。

要查找操作项的复杂性类别，请在 Amazon DMS 控制台中查看**操作项**选项卡，或查看摘要 CSV 文件中的`Objects with medium-complexity actions`、和`Objects with complex actions`列。`Objects with simple actions`要查找操作项类型的出现次数，请参阅 `Action_Items_Summary` CSV 文件中的`Number of occurrences`列。

## 评估迁移风险和范围
<a name="assessment-reports-planning-scope"></a>

除了计算工作量和确定各个操作项目的优先顺序外，还可以使用转化评估报告来评估迁移项目的总体风险和范围。
+ **识别高风险数据库对象 ** — DMS Schema Conversion 分类的具有中等复杂度或复杂操作的数据库对象需要手动转换，对迁移时间表来说风险最大。DMS Schema Conversion 自动转换或仅具有简单操作的数据库对象的风险相对较低。有关 DMS 架构转换如何分配这些类别的更多信息，请参阅。[复杂性类别](assessment-reports-understanding.md#assessment-reports-understanding-complexity)
+ **估算总体迁移范围和时间表 **-使用 ** “**摘要” 选项卡或 “摘要 CSV 文件” 中的数据库对象计数，估算您的架构中有多少需要手动转换。将具有中等复杂性和复杂操作的数据库对象的数量与数据库对象总数进行比较，以评估迁移的总体范围。将此范围与您计算的总迁移工作量（参见[计算总工作量](#assessment-reports-planning-effort)）和团队的可用能力相结合，以预测完成手动转换工作的时间表。
+ **规划手动转换任务的顺序 **-** 操作项**选项卡和操作项目 CSV 文件为每种操作项类型提供建议的操作。使用这些建议以及您制定的优先顺序（参见[对行动项目进行优先排序](#assessment-reports-planning-prioritization)）来规划团队解决操作项的顺序。对影响相关数据库对象的操作项（例如同一架构中的对象或相互依赖的数据库对象）进行分组，以便您的团队可以共同解决相关问题。