雲端中的新 DBA - 在移轉之後管理 Azure SQL Database

適用於：Azure SQL 資料庫

從自我管理環境移轉至 Azure SQL 資料庫等 PaaS 可能很複雜。本文重點介紹 Azure SQL 資料庫適用於單一資料庫和集區資料庫的主要功能，可協助您保持應用程式的可用性、效能、安全性和復原能力。

Azure SQL 資料庫的核心特性包括：

使用 Azure 入口網站進行資料庫監視
業務持續性和災害復原 (BCDR)
安全性與合規性
智慧型資料庫監視和維護
資料移動

注意

Microsoft Entra ID 先前稱為 Azure Active Directory (Azure AD)。

使用 Azure 入口網站監視資料庫

如需 Azure Monitor 計量和警示，請參閱使用計量和警示監視 Azure SQL 資料庫。如需服務層級的詳細資訊，請參閱 DTU 型購買模型概觀和虛擬核心型購買模型。

您可以在效能度量中設定警示。選取度量視窗中的 新增警示 按鈕。遵循精靈的指示以設定警示。如果度量超過特定臨界值，或度量低於特定臨界值，您可以發出警示。

例如，如果您預期資料庫中的工作負載會成長，可以選擇設定電子郵件警示，以便在資料庫的任何效能度量達到 80% 時收到警示。您可以使用此警示作為早期警告，協助您判斷何時需要切換至更高的計算大小。

效能度量也可協助您判斷您是否能夠降級至較低的計算大小。不過，在您決定將資料庫移至較低計算大小前，請先注意暴增或大幅變動的工作負載。

業務持續性和災害復原 (BCDR)

業務連續性和災難恢復能力使您能夠在發生災難時繼續業務。災害可以是資料庫層級事件 (例如，某人不小心卸除重要資料表) 或資料中心層級事件 (區域性災難，例如海嘯)。

如何在 SQL Database 上建立和管理備份？

Azure SQL 資料庫會自動為您備份資料庫。該平台每週進行一次完整備份，每隔幾個小時進行一次差異備份，每 5 分鐘進行一次日誌備份，以確保災難恢復高效，數據丟失最小。在您建立資料庫時，就會開始進行第一個完整備份。這些備份可在稱為 保留期間的特定期間內使用，該期間會根據您選擇的服務層級而有所不同。您可以使用『時間點復原（PITR）』功能，還原至此保留期間內的任何時間點。

此外，長期保留備份功能可讓您將備份檔案保留長達 10 年，並在該期間內的任何時間點從這些備份還原資料。資料庫備份會保留在異地複寫的儲存體中，以提供區域性災害的復原能力。您也可以在保留期限內於任何時間點還原任何 Azure 區域的這些備份。如需詳細資訊，請參閱 Azure SQL 資料庫中的商務持續性。

如何在發生資料中心層級災害或區域性災害時確保商務持續性？

因為您的資料庫備份是儲存在異地複寫儲存體，以確保發生地區性災難時，您可以將備份還原到另一個 Azure 區域。這稱為異地還原。如需異地恢復的詳細資訊和時間，請參閱 Azure SQL Database 的異地恢復。

對於任務關鍵性資料庫，Azure SQL 資料庫提供主動式異地複寫，這會在另一個區域中建立原始資料庫的異地複寫次要複本。例如，如果資料庫最初裝載於 Azure 美國西部地區，而且您想要擁有地區性的災害恢復功能，則應該在美國西部到美國東部創建一個資料庫的活動地理副本。當美國西部遭遇災難時，您可以容錯移轉至美國東地區。

除了作用中異地複寫之外，容錯移轉群組還可協助您管理資料庫群組的複寫和容錯移轉。您可以建立故障轉移群組，其中包含相同或不同區域中的多個資料庫。接著，您可以起始故障轉移群組中所有資料庫的故障轉移至次要區域。如需詳細資訊，請參閱容錯群組概觀與最佳做法（Azure SQL 資料庫）。

若要達到高可用性和復原能力，請為 SQL Database 或彈性集區啟用區域備援。

主動監視您的應用程式是否有災害，並起始故障轉移至次要複本。您可以在不同 Azure 區域中建立最多四個此類主動式異地複本。這麼做更好。您也可以以唯讀存取權來存取這些次要主動式異地複本。這有助於減少異地分散式應用程式案例的延遲。

SQL 資料庫的災害復原是什麼樣子？

當您使用作用中異地複寫或容錯移轉群組時，只要在 Azure SQL 資料庫中採取幾個步驟，即可設定和管理災害復原。您仍然需要監視應用程式及其資料庫是否有任何區域性災害，並故障轉移至次要區域以還原商務持續性。

如需詳細資訊，請參閱 Azure SQL 資料庫災害復原 101。

安全性與合規性

SQL Database 內的安全性可在資料庫層級和平臺層級使用。您可以控制應用程式並提供最佳安全性，如下所示：

身分識別 & 驗證（SQL 驗證和使用 Microsoft Entra ID 進行驗證）。
監視活動 (稽核和威脅偵測)。
保護實際資料（透明資料加密 [TDE] 和 Always Encrypted）。
控制對敏感性和特權資料的存取（資料列層級安全性和動態資料遮罩）。

適用於雲端的 Microsoft Defender 提供跨越在 Azure、內部部署和其他雲端中執行之工作負載的集中式安全性管理。您可以檢視是否在所有資源上設定了必要的 SQL Database 保護，例如稽核和透明資料加密 [TDE] ，並根據您自己的需求建立原則。

SQL Database 提供哪些使用者驗證方法？

SQL Database 提供兩個驗證方法：

不支援 Windows 驗證。 Microsoft Entra ID 是雲端式身分識別和存取管理服務。 Microsoft Entra ID 提供單一登入（SSO）存取權給組織中的人員。這表示認證會在 Azure 服務之間共用，以便更輕鬆地進行驗證。

Azure AD 支援 Azure AD 多重要素驗證，因此 Azure AD 可輕鬆與 Windows Server Active Directory 整合。這也可讓 SQL Database 和 Azure Synapse Analytics，在 Azure AD 網域內提供多重要素驗證和來賓使用者帳戶。如果您已使用內部部署 Active Directory，則可以讓它與 Azure Active Directory 結成同盟，將目錄延伸至 Azure。

SQL 驗證僅支援使用者名稱和密碼，以對指定伺服器上的任何資料庫驗證使用者。

如果你...	SQL 資料庫/Azure Synapse Analytics
已在內部部署 SQL Server 上使用 AD	使用 Microsoft Entra 識別符同盟 AD，並使用 Microsoft Entra 驗證。同盟可讓您使用單一登入。
需要強制執行多重要素驗證	透過條件式存取要求多重要素驗證作為原則，並使用 Microsoft Entra 多重要素驗證。
使用聯盟網域中的 Microsoft Entra 認證資訊登入 Windows	使用 Microsoft Entra 驗證。
使用來自未與 Azure 同盟的網域的認證登入 Windows	使用 Microsoft Entra ID 進行驗證。
具有需要連線到 SQL Database 或 Azure Synapse Analytics 的中介層服務	使用 Microsoft Entra ID 進行驗證。
具備使用 SQL 驗證的技術需求	使用 SQL 驗證

如何限制或控制資料庫的連線存取？

有多個技術隨時可供您用來讓應用程式達到最佳連線能力。

防火牆規則
虛擬網路服務端點
保留的 IP

防火牆

根據預設，不允許與伺服器內資料庫的所有連線，但（選擇性）來自其他 Azure 服務的連線除外。使用防火牆規則，您可以允許該電腦的 IP 位址通過防火牆，只對您核准的實體（例如開發人員電腦）開放對伺服器的存取。也可讓您指定想要允許存取伺服器的某個範圍 IP。比方說，可以在 [防火牆設定] 頁面中指定範圍，一次新增您組織中開發人員電腦的 IP 位址。

您可以在伺服器層級或資料庫層級建立防火牆規則。可以使用 Azure 入口網站或 SSMS 建立伺服器層級 IP 防火牆規則。如需如何設定伺服器層級和資料庫層級防火牆規則的詳細資訊，請參閱在 SQL Database 中建立 IP 防火牆規則。

服務端點

根據預設，您的資料庫會設定為 允許 Azure 服務和資源存取此伺服器，這表示 Azure 中的任何虛擬機器都可能嘗試連線到您的資料庫。這些嘗試仍需要取得驗證。如果您不想讓任何 Azure IP 存取資料庫，您可以停用 [允許 Azure 服務和資源存取此伺服器]。 此外，您可以設定虛擬網路服務端點。

服務端點可讓您只將重要的 Azure 資源公開給 Azure 中您自己的私人虛擬網路。此選項可消除對您資源的公開存取。您的虛擬網路與 Azure 之間的流量會保持在 Azure 骨幹網路上。如果沒有服務端點，您會獲得強制隧道封包路由。您的虛擬網路會強制對您的組織的網際網路流量與 Azure 服務流量通過相同的路由。使用服務端點，您可以優化此動作，因為封包會直接從虛擬網路流向 Azure 骨幹網路上的服務。

保留的 IP

另一個選項就是為您的 VM 佈建保留 IP，並新增伺服器防火牆設定中的特定 VM IP 位址。藉由指派保留的 IP，即可免去必須以不斷變更的 IP 位址更新防火牆規則的麻煩。

我該在哪個埠連線到 SQL 資料庫？

SQL Database 會透過連接埠 1433 進行通訊。若要從公司網路內連結，您必須在組織的防火牆設定中新增輸出規則。一般來說，請避免公開超出 Azure 界限的連接埠 1433。

如何在 SQL Database 中監視和規範伺服器和資料庫上的活動？

SQL Database 稽核

Azure SQL 資料庫稽核會記錄資料庫事件，並將其寫入 Azure 儲存體帳戶中的稽核記錄檔。如果您打算深入了解潛在的安全性和策略違規行為、維護法規遵從性等，則稽核特別有用。它可讓您定義及設定您認為需要稽核的特定類別事件，並在此基礎上取得預先設定的報告和儀表板，以取得資料庫上發生的事件概觀。

您可以在資料庫層級或伺服器層級套用這些稽核原則。如需詳細資訊，請啟用 SQL Database 稽核。

威脅偵測

透過威脅偵測，您可以針對稽核所發現的安全性或原則違規採取行動。您不需要是安全性專家，也能解決您系統中的潛在威脅或違規。威脅偵測也具有一些內建功能，例如 SQL 注入偵測，這是攻擊資料庫應用程式的一種非常常見的方式。威脅偵測會執行多組演算法，以偵測潛在的弱點和 SQL 插入式攻擊，以及異常的資料庫存取模式（例如從不尋常的位置或由不熟悉的主體存取）。

如果在資料庫上偵測到威脅，安全性人員或其他指定的管理員會收到一封電子郵件通知。每個通知都會提供可疑活動的詳細資料，以及建議如何進一步調查並減輕威脅。若要瞭解如何開啟威脅偵測，請參閱啟用威脅偵測。

如何保護 SQL Database 上的一般資料？

加密提供強式機制來保護及保全您的敏感性資料不被入侵者侵害。若沒有解密金鑰，加密的資料對入侵者是沒有用處的。因此，它會在 SQL Database 中建立的現有安全性層級之上新增一層額外的保護。在 SQL Database 中保護資料有兩個層面：

您在資料和日誌檔中靜止不動的資料
您的數據傳輸中

在 SQL Database 中，根據預設，儲存體子系統上資料和記錄檔中的待用資料會透過透明資料加密 [TDE] 完全且一律加密。也會加密您的備份。使用 TDE，存取此資料的應用程式端不需要進行任何變更。加密與解密會透明地進行，因此以此為名。

為了保護傳輸中和靜止的敏感性資料，SQL Database 提供名為 Always Encrypted 的功能。 Always Encrypted 是用戶端加密的一種形式，可加密資料庫中的敏感資料行（因此它們會以密文形式提供給資料庫系統管理員和未經授權的使用者）。伺服器會接收加密的資料來開始處理。

Always Encrypted 金鑰也會儲存在用戶端，因此只有獲得授權的用戶端可以將敏感性資料行解密。伺服器和資料管理員無法查看敏感性資料，因為加密金鑰存放在用戶端上。 Always Encrypted 會端對端加密資料表中的敏感資料行，從未經授權的用戶端到實體磁碟。

Always Encrypted 支援相等比較，因此 DBA 可以繼續查詢加密資料行，作為其 SQL 命令的一部分。 Always Encrypted 可以搭配各種金鑰存放區選項使用，例如 Azure Key Vault、Windows 憑證存放區和本機硬體安全性模組。

特性	永遠加密	透明資料加密
加密範圍	端對端	待用資料
伺服器可以存取敏感性資料	No	是，因為加密用於待用資料
允許的 T-SQL 作業	相等比較	所有 T-SQL 介面區域可供使用
使用此功能需要進行應用程式變更	最小	最小
加密資料細微度	資料行層級	資料庫層級

如何限制對資料庫中敏感資料的存取？

每個應用程式的資料庫中都有敏感資料，需要保護這些資料，以免對所有人可見。組織內的特定人員可能需要檢視此資料，但其他人卻不應該能夠檢視此資料。在這種情況下，您的敏感資料需要遮罩，或根本不公開。 SQL Database 提供兩個這類方法來防止未經授權的使用者檢視敏感性資料：

動態資料遮罩是一種資料遮罩功能，可讓您將敏感資料遮罩給應用程式層上的非特殊許可權使用者，以限制敏感資料的暴露。您可以定義遮罩規則來建立遮罩模式（例如，只顯示國家識別碼 SSN 的最後四位數，並使用 X 字元遮罩大部分內容），並識別需要從遮罩規則中排除的使用者。遮罩會快速發生，並且有各種不同遮罩函數可供各種資料類別使用。動態資料遮罩可讓您自動偵測資料庫中的敏感性資料，並對其套用遮罩。
資料列層級安全性可讓您在資料列層級控制存取。這表示，根據執行查詢之使用者 (群組成員資格或執行環境)，會隱藏資料庫資料表中的某些資料列。在應用程式層 (而非資料庫層) 上進行存取限制，可簡化您的應用程式邏輯。您可以從建立篩選述詞開始，篩選掉不要公開的資料列，接著使用安全性原則來定義可以存取這些資料列的使用者。最後，終端使用者執行查詢，並且，根據使用者的權限，他們可以檢視這些受限制的資料列或完全無法看到這些資料。

如何管理雲端中的加密金鑰？

Always Encrypted （用戶端加密）和透明資料加密（待用加密）都有金鑰管理選項。建議您定期輪替使用加密金鑰。輪替頻率應符合您的組織內部法規和合規性需求。

透明資料加密 (TDE)

TDE 有雙重金鑰階層 – 每個使用者資料庫中的資料是由對稱 AES-256 資料庫唯一的資料庫加密金鑰 (DEK) 加密，接著由伺服器唯一的非對稱 RSA 2048 主要金鑰加密。主要金鑰的管理方式可以是以下兩個方式之一：

由 Azure SQL 資料庫自動化執行
或使用 Azure 金鑰保存庫作為金鑰存放區

根據預設，TDE 的主要金鑰是由 Azure SQL 資料庫管理。如果您的組織想要控制主要金鑰，您可以使用 Azure 金鑰保存庫作為金鑰存放區。使用 Azure Key Vault，您的組織即可取得金鑰佈建、輪替和權限控制權。輪替或切換 TDE 主索引鍵的類型很快速，因為它只會將 DEK 重新加密。若為區隔安全性與資料管理之間角色的組織，安全性管理員可以為 Azure Key Vault 中的 TDE 主要金鑰佈建金鑰內容，並將 Azure Key Vault 金鑰識別碼提供給資料庫管理員，以便用於在伺服器上進行待用資料加密。 Key Vault 的設計能使得 Microsoft 無法看見或擷取您的加密金鑰。您也可以因此集中管理組織的金鑰。

永遠加密

Always Encrypted 中也有雙重金鑰階層 - 敏感性資料的資料行是由 AES 256 資料行加密金鑰 (CEK) 加密，接著由資料行主要金鑰 (CMK) 加密。針對 Always Encrypted 提供的用戶端驅動程式沒有 CMK 長度限制。 CEK 的加密值會儲存在資料庫中，而 CMK 會儲存在受信任的金鑰存放區中，例如 Windows 憑證存放區、Azure Key Vault 或硬體安全性模組。

CEK 和 CMK可以輪替。
CEK 輪替是資料作業的大小，並視含有加密資料行的資料表大小而定，可能花費大量時間。因此，最好據此規劃 CEK 輪替。
不過，CMK 輪替不會干擾資料庫效能，可以透過區隔的角色完成。

下圖顯示 Always Encrypted 中資料行主要金鑰的金鑰存放區選項：

如何優化和保護組織與 SQL Database 之間的流量？

組織與 SQL Database 之間的網路流量通常會透過公用網路路由傳送。不過，您可以使用 Azure ExpressRoute 優化此路徑，並使其更安全。 ExpressRoute 會透過私人連線將您的公司網路延伸至 Azure 平台。如此一來，您不會經過公用網際網路。您還可以獲得更高的安全性、可靠性和路由優化，這意味著比您通常通過公共互聯網體驗到的更低的網絡延遲和更快的速度。如果您計劃在組織與 Azure 之間傳輸大量資料區塊，使用 ExpressRoute 可以產生成本優勢。您可以從您的組織連線至 Azure 的三種不同的連線模型中選擇：

ExpressRoute 也允許您將頻寬暫時突增至所購買頻寬限制的兩倍，且無需支付額外費用。您也可以使用 ExpressRoute 設定跨區域連線。如需 ExpressRoute 連線提供者的清單，請參閱 ExpressRoute 合作夥伴和對等互連位置。下列文章更詳細說明 Express Route：

SQL Database 是否符合任何法規需求，這如何有助於我自己的組織合規性？

SQL Database 符合各種法規規範。若要檢視 SQL Database 已符合的最新合規性集，請流覽 Microsoft 信任中心，並檢閱對組織很重要的合規性，以查看 SQL Database 是否包含在相容的 Azure 服務下。雖然 SQL Database 已認證為合規服務，但它有助於組織服務的合規性，但不會自動保證。

移轉之後的智慧型資料庫監視及維護

將資料庫移轉至 SQL 資料庫之後，您應該監視資料庫（例如，檢查資源使用率或 DBCC 檢查），並執行定期維護（例如，重建或重組索引、統計資料等）。 SQL Database 會使用歷程記錄趨勢和記錄的計量和統計資料，主動協助您監視和維護資料庫，讓您的應用程式一律以最佳狀態執行。在某些情況下，Azure SQL Database 可以根據組態設定自動執行維護工作。有三個 Facet 可用來來監視 SQL Database 中的資料庫：

效能監控與最佳化
安全性最佳化
成本最佳化

效能監控與最佳化

透過 Query Performance Insights，您可以取得資料庫工作負載的量身打造建議，讓您的應用程式能夠以最佳層級持續執行。您也可加以設定，使得這些建議會自動套用，讓您不必擔心執行維護工作。使用 SQL 資料庫顧問，您可以根據工作負載自動實作索引建議。這稱為自動調整。建議會隨著您的應用程式工作負載變更而發展，以為您提供最相關的建議。您也可以選擇手動檢閱這些建議，並依您的判斷將其套用。

安全性最佳化

SQL Database 提供可採取動作的安全性建議，以幫助您保護您的資料，以及威脅偵測可用來識別及調查會對資料庫造成潛在威脅的可疑資料庫活動。漏洞評估是一項資料庫掃描和報告服務，可讓您大規模監視資料庫的安全性狀態，以及找出安全性風險和您所定義的安全性基準偏離。每次掃描之後，都會提供可採取動作步驟和補救腳本的自訂清單，以及可用來協助符合合規性需求的評估報告。

透過適用於雲端的 Microsoft Defender，您可以全面識別安全性建議，然後快速套用。

成本最佳化

SQL Azure 平台會分析伺服器中不同資料庫的使用量歷程記錄，以為您評估並建議成本最佳化選項。此分析通常需要幾週的時間來分析及建立可採取動作的建議。

您可能會在 Azure SQL Server 中收到關於成本建議的橫幅通知。如需詳細資訊，請參閱彈性集區可協助您在 Azure SQL 資料庫中管理和調整多個資料庫，以及規劃和管理 Azure SQL 資料庫的成本。

如何監視 SQL Database 中的效能和資源使用率？

您可以在 SQL Database 中使用下列方法監視效能與資源使用率：

資料庫監看員

資料庫監看員會收集深入的工作負載監視資料，為您提供資料庫效能、組態和健康情況的詳細資料檢視。 Azure 入口網站中的儀表板提供 Azure SQL 資產的單一窗格檢視，以及每個監視資源的詳細資料檢視。資料會被收集到 Azure 訂用帳戶中的中央資料存放區。您可以查詢、分析、匯出、視覺化收集的資料，並將其與下游系統整合。

如需資料庫監看員的詳細資訊，請參閱下列文章：

Azure 入口網站

選取資料庫，然後選取 [概觀] 窗格中的圖表，Azure 入口網站即可顯示資料庫的使用率。您可以修改此圖表來顯示多種計量，包括 CPU 百分比、DTU 百分比、資料 IO 百分比、工作階段百分比，以及資料庫大小百分比。

透過這個圖表，您也可以依照資源設定警示。這些警示可讓您透過電子郵件回應資源條件、寫入至 HTTPS/HTTP 端點或執行動作。如需詳細資訊，請參閱使用 Azure 入口網站建立 Azure SQL 資料庫和 Azure Synapse Analytics 的警示。

動態管理檢視

您可以查詢 sys.dm_db_resource_stats 動態管理檢視，以傳回過去一小時的資源耗用量統計資料歷程記錄，而查詢 sys.resource_stats 系統目錄檢視，可傳回過去 14 天的歷程記錄。

查詢效能深入解析

查詢效能深入解析可讓您針對特定的資料庫，查看前幾名資源耗用查詢和長時間執行查詢的歷程記錄。您可以依資源使用率、持續時間和執行頻率快速識別 TOP 查詢。您可以追蹤查詢並偵測迴歸。這項功能需要啟用查詢存放區，而且對資料庫有作用。

我注意到效能問題：我的 SQL Database 疑難排解方法與 SQL Server 有何不同？

您用來診斷查詢和資料庫效能問題的主要疑難排解技術部分保持不變：相同的資料庫引擎為雲端提供支援。 Azure SQL 資料庫可協助您更輕鬆地針對效能問題進行疑難排解和診斷。它還可以代表您執行其中一些糾正措施，並在某些情況下主動自動修復它們。

運用智慧型功能（例如查詢效能深入解析（QPI）和資料庫顧問）來解決效能問題的方式可以大大受益，也因此，您在這方面的方法會有所不同——您不再需要手動整理可能有助於疑難排解眼前問題的基本細節。平台會為您完成困難的工作。其中的一個範例是 QPI。使用 QPI，您可以向下切入直到查詢層級，並查看歷史趨勢，以及找出查詢迴歸的確切時間。資料庫顧問會針對可能協助您改善整體效能的專案提供建議，例如遺漏索引、捨棄索引、參數化查詢等。

對效能進行疑難排解時，請務必找出影響應用程式效能的是否只是應用程式或是後端資料庫。往往效能問題會出在應用程式層。可能是架構或資料存取模式。例如，假設您有一個對網路延遲敏感的聊天應用程式。在此情況下，您的應用程式會受到影響，因為在應用程式與伺服器之間的短請求來回次數頻繁（「閒聊」）且網路壅塞，這些回程延時會快速累積。若要改善此情況下的效能，您可以使用批次查詢，這有助於減少來回延遲並改善應用程式的效能。

此外，如果您發現資料庫整體效能降低，您可以監視 sys.dm_db_resource_stats 和 sys.resource_stats 動態管理檢視，以便了解 CPU、IO 和記憶體耗用量。如果您的資料庫資源不足，您的效能可能會受到影響。您可能需要根據成長和縮小的工作負載需求來變更計算大小和/或服務層級。

如需調整效能問題的完整建議，請參閱調整資料庫。

如何確保我使用適當的服務層級和計算大小？

SQL Database 提供兩種不同的購買模型：較舊的 DTU 模型和適應性較強的虛擬核心購買模型。如需詳細資訊，請參閱比較以虛擬核心和以 DTU 為基礎的 Azure SQL Database 購買模型。

您可以在任一購買模型中監視查詢和資料庫資源耗用量。如需詳細資訊，請參閱監視和效能微調。如果您發現您的查詢/資料庫持續高度執行，可以考慮向上增加至更高的計算大小。同樣地，如果您在尖峰時段似乎沒有充分利用資源，請考慮縮減目前的運算規模。您可以考慮使用 Azure 自動化依排程調整 SQL Database。

如果您有 SaaS 應用程式模式或資料庫彙總情節，為了成本最佳化，請考慮使用彈性集區。彈性集區是達到資料庫合併和成本最佳化的好方法。如需使用彈性集區管理多個資料庫的詳細資訊，請參閱管理集區和資料庫。

我需要多久對我的資料庫執行一次資料庫完整性檢查？

SQL Database 可以自動處理某些類別的資料損毀，而不會遺失任何資料。當需要時，服務會使用這些內建技術。您的資料庫備份會在整個服務中定期進行測試，方法是透過還原它們並執行 DBCC CHECKDB 。如果有問題，SQL Database 會主動解決它們。

自動頁面修復用於修復損壞或存在資料完整性問題的頁面。資料庫頁面一律會使用驗證頁面完整性的預設 CHECKSUM 設定來驗證。 SQL Database 會主動監視和檢閱資料庫的資料完整性，並在出現問題時解決問題。您可以選擇視需要執行自己的完整性驗證。如需詳細資訊，請參閱 SQL Database 中的資料完整性。

移轉後的資料移動

如何使用 Azure 入口網站將資料從 SQL 資料庫匯出和匯入為 BACPAC 檔案？

匯出：您可以從 Azure 入口網站將 Azure SQL 資料庫中的資料庫匯出為 BACPAC 檔案：
匯入：您也可以使用 Azure 入口網站，將資料作為 BACPAC 檔案匯入 Azure SQL 資料庫中的資料庫：

如何在 SQL Database 和 SQL Server 之間同步處理資料？

您有幾種方式來達到此目的：

資料同步：此功能可協助您在多個 SQL Server 資料庫和 SQL 資料庫之間雙向同步處理資料。若要與 SQL Server 資料庫同步，您需要在本機電腦或虛擬機器上，安裝並設定同步處理代理程式，以及開放輸出 TCP 連接埠 1433。
交易複寫：透過交易複寫，您可以將資料從 SQL Server 資料庫同步處理至 Azure SQL Database，其中 SQL Server 執行個體是發行者，而 Azure SQL Database 是訂閱者。目前僅支援此安裝程式。如需如何以最短停機時間將資料從 SQL Server 資料庫移轉至 Azure SQL 的詳細資訊，請參閱使用交易複寫

Azure SQL 資料庫和 Azure SQL 受控執行個體的監視和效能微調

意見反應

此頁面對您有幫助嗎？

Last updated on 2025-09-17