本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 使用轉換評估報告進行遷移規劃
轉換評估報告是您資料庫遷移旅程的第一步。組織使用 報告來評估遷移複雜性，並在遞交完整規模的遷移專案之前做出明智的正式/不正式決策。
## 計算總遷移工作量
`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 中使用 CROSS JOIN 可能會導致效能變慢」) 有 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
```
## 排定動作項目的優先順序
使用每個動作項目的複雜性類別和發生次數，來決定您解決問題的順序。以這種方式排定動作項目的優先順序，可協助您先處理對遷移時間表影響最大的工作。
1. **具有高出現次數的複雜動作** — 首先處理這些動作項目。它們在每次出現時需要最多的手動工作量，而高出現次數會乘以整個結構描述的工作量。
1. **中複雜度動作** — 接著處理這些動作項目。相較於複雜的動作，它們通常需要較少的精力來設計轉換方法，但仍需要手動轉換工作。
1. **簡單動作** — 在需要手動工作的動作項目中，將這些動作項目列為最低優先順序。通常需要最少的努力才能解決。
1. **自動轉換資料庫物件** — 這些資料庫物件不需要任何動作。DMS 結構描述轉換會進行轉換，無需任何手動介入。
若要尋找動作項目的複雜性類別，請在 AWS DMS 主控台中檢視**動作項目**索引標籤，或在摘要 CSV 檔案中檢視 `Objects with simple actions`、 `Objects with medium-complexity actions`和 `Objects with complex actions`資料欄。若要尋找動作項目類型的出現計數，請參閱 `Action_Items_Summary` CSV 檔案中的 `Number of occurrences` 欄。
## 評估遷移風險和範圍
除了計算工作量並排定個別動作項目的優先順序之外，請使用轉換評估報告來評估遷移專案的整體風險和範圍。
+ **識別高風險資料庫物件** — DMS 結構描述轉換分類為中等複雜度或複雜動作的資料庫物件需要手動轉換，並代表遷移時間軸的最高風險。DMS 結構描述轉換自動轉換或只有簡單動作的資料庫物件具有相對較低的風險。如需 DMS 結構描述轉換如何指派這些類別的詳細資訊，請參閱 [複雜性類別](assessment-reports-understanding.md#assessment-reports-understanding-complexity)。
+ **估計整體遷移範圍和時間軸** — 使用**摘要**索引標籤或摘要 CSV 檔案中的資料庫物件計數，來估計有多少結構描述需要手動轉換。將具有中複雜度和複雜動作的資料庫物件數量與資料庫物件總數進行比較，以測量遷移的整體範圍。將此範圍與您計算的總遷移工作量 （請參閱[計算總工作量](#assessment-reports-planning-effort)) 和您團隊的可用容量合併，以投影完成手動轉換工作的時間表。
+ **規劃手動轉換任務的順序** — **動作項目**索引標籤和動作項目 CSV 檔案會為每個動作項目類型提供建議的動作。使用這些建議，以及您建立的優先順序 （請參閱[排定動作項目的優先順序](#assessment-reports-planning-prioritization))，來規劃您的團隊解決動作項目的順序。將影響相關資料庫物件的動作項目分組，例如相同結構描述中的物件或彼此相依的資料庫物件，讓您的團隊可以一起解決相關問題。