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

# SQL Server 資料庫遷移策略
<a name="strategies"></a>

在高階，有兩種選項可將 SQL Server 資料庫從內部部署遷移至 AWS 雲端：保持在 SQL Server (*[同質遷移](homogeneous-migration.md)*) 上或移出 SQL Server *[（異質遷移](heterogeneous-migration.md)*)。在同質遷移中，您不會變更資料庫引擎。也就是說，您的目標資料庫也是 SQL Server 資料庫。在異質遷移中，您可以將 SQL Server 資料庫切換為開放原始碼資料庫引擎，例如 MySQL、PostgreSQL 或 MariaDB，或切換為 AWS 雲端原生資料庫，例如 Amazon Aurora、Amazon DynamoDB 或 Amazon Redshift。

將 SQL Server 資料庫遷移到以下三種常見策略 AWS：重新託管、轉換和重新架構 （重構）。這些是[應用程式遷移策略 7 R](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-database-migration/planning-phase.html) 的一部分，如下表所述。


****  

| 策略 | Type | 何時選擇 | 範例 | 
| --- | --- | --- | --- | 
| **重新託管** | 同質 | 您想要依原狀遷移 SQL Server 資料庫，無論是否變更作業系統、資料庫軟體或組態。 | SQL Server 到 Amazon EC2 | 
| **平台重建** | 同質 | 您想要減少使用全受管資料庫產品來管理資料庫執行個體的時間。 | SQL Server 到 Amazon RDS for SQL Server | 
| **重新架構師 （重構）** | 異質性 | 您想要重組、重寫和重新建構資料庫和應用程式，以利用開放原始碼和雲端原生資料庫功能。 | SQL Server 到 Amazon Aurora PostgreSQL、MySQL 或 MariaDB | 

如果您嘗試在重新託管或轉換 SQL Server 資料庫之間做出決定，請參閱本指南稍後的[在 Amazon EC2 和 Amazon RDS 之間進行選擇](comparison.md)，以取得支援的功能的side-by-side比較。

## 選擇正確的遷移策略
<a name="choose-strategy"></a>

選擇正確的策略取決於您的業務需求、資源限制、遷移時間範圍和成本考量。下圖顯示遷移涉及的工作量和複雜性，包括所有七種策略。

 ![\[Comparison of SQL Server migration strategies\]](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/migration-sql-server/images/migration-strategy-comparison.png) 

重構 SQL Server 資料庫並遷移至開放原始碼或 AWS 雲端原生資料庫，例如 Amazon Aurora PostgreSQL 相容版本或 Aurora MySQL 相容版本，可協助您現代化和最佳化資料庫。透過移至開放原始碼資料庫，您可以避免昂貴的授權 （導致成本降低）、廠商鎖定期間和稽核。不過，根據您工作負載的複雜性，重構 SQL Server 資料庫可能是一項複雜、耗時和資源密集的工作。

若要降低複雜性，而不是在單一步驟中遷移資料庫，您可以考慮分階段方法。在第一個階段中，您可以專注於核心資料庫功能。在下一個階段中，您可以將其他服務整合 AWS 到您的雲端環境、降低成本，以及最佳化效能、生產力和合規性。例如，如果您的目標是將內部部署 SQL Server 資料庫取代為 Aurora MySQL 相容，您可能會考慮在 Amazon EC2 上重新託管資料庫，或在 Amazon RDS for SQL Server 上複寫資料庫，然後在後續階段重構為 Aurora MySQL 相容。此方法有助於降低遷移階段期間的成本、資源和風險，並專注於第二階段的最佳化和現代化。

## 線上和離線遷移
<a name="online-offline"></a>

根據您的遷移時間表和允許的停機時間，您可以使用兩種方法將 SQL Server 資料庫從內部部署或其他雲端環境遷移至 AWS 雲端：離線遷移或線上遷移。
+ **離線遷移：**當您的應用程式可以負擔計劃的停機時間時，就會使用此方法。在離線遷移中，來源資料庫會在遷移期間離線。當來源資料庫離線時，它會遷移到其上的目標資料庫 AWS。遷移完成後，會執行驗證和驗證檢查，以確保與來源資料庫的資料一致性。當資料庫通過所有驗證檢查時，您可以透過將應用程式連接到目標資料庫 AWS 來執行切換 AWS。
+ **線上遷移：**當您的應用程式需要接近零到最短的停機時間時，就會使用此方法。在線上遷移中，來源資料庫會以多個步驟遷移至 AWS。在初始步驟中，來源資料庫中的資料會在來源資料庫仍在執行時複製到目標資料庫。在後續步驟中，來源資料庫的所有變更都會傳播到目標資料庫。當來源和目標資料庫同步時，它們已準備好進行切換。在切換期間，應用程式會將其連線切換到開啟的目標資料庫 AWS，不留下與來源資料庫的連線。您可以使用 AWS Database Migration Service (AWS DMS) 或 提供的工具 [AWS Marketplace](https://aws.amazon.com/marketplace/)（例如 Attunity) 來同步來源和目標資料庫。