適用於:Azure SQL 資料庫
本文回顧了 Azure SQL 資料庫彈性工作的能力與細節。
- 如需一些設定彈性作業的教學課程,請參閱彈性作業教學課程。
- 深入了解 Azure 資料庫平台中的自動化概念。
彈性作業概觀
你可以建立並排程彈性工作,定期針對一個或多個 Azure SQL 資料庫執行。 這些工作執行 Transact-SQL(T-SQL)查詢並執行維護任務。
你可以定義目標資料庫或工作執行的資料庫群組。 你也可以定義執行工作的 排程 。 彈性工作中的所有日期和時間均採用 UTC 時區。
任務負責驗證身分,以連接到目標資料庫。 你還要定義、維護並持續保存 Transact-SQL 腳本,讓它們能跨越一組資料庫執行。
每個工作都會記錄執行狀態,若發生失敗則自動重試操作。
何時使用彈性作業
在以下情境下使用彈性工作自動化:
-
例如,自動化管理任務,並排程在每個平日或非下班時間執行。
- 部署架構變更並管理憑證。
- 收集績效資料或租戶(客戶)日誌。
- 更新參考資料 (所有資料庫通用的資訊)。
- 從 Azure Blob 儲存體載入資料。
-
設定工作能定期在多個資料庫執行,例如在非尖峰時段。
- 將查詢結果持續地從一組資料庫收集至中央資料表中。
- 查詢可以持續執行並設定以觸發額外任務。
-
收集資料以供報告
- 將資料庫集合中的資料彙總到單一目的地資料表中。
- 在大量資料庫中執行資料處理查詢,例如客戶日誌的收集。 結果會收集到單一目標資料表中,以做進一步的分析。
-
資料移動
- 針對自訂方案開發、商務自動化或其他作業管理。
- ETL 處理,用於在資料庫中資料表間擷取、轉換及載入資料。
當出現以下情況時,請考慮彈性作業:
有一個任務需要定期按排程執行,目標是一個或多個資料庫。
有一個任務需要執行一次,但要跨多個資料庫。
需要對任何資料庫組合執行的作業:一或多個個別資料庫、伺服器上的所有資料庫、彈性集區中的所有資料庫,並新增可納入或排除任何特定資料庫的彈性。 作業可以在多部伺服器上、多個集區中執行,甚至可以在不同訂用帳戶中的資料庫上執行。 伺服器和集區都會以動態方式列舉在執行階段,因此作業會針對在執行階段存在於目標群組的所有資料庫執行。
- 這項功能與 SQL Agent 有顯著差異,SQL Agent 無法動態列舉目標資料庫,尤其是在 SaaS 客戶情境中,資料庫會動態新增或刪除。
彈性作業元件
| 元件 | 描述 |
|---|---|
| 彈性作業代理程式 | 你建立的 Azure 資源,用來執行和管理工作。 |
| 作業資料庫 | 一個位於 Azure SQL 資料庫中的資料庫,工作代理用來儲存與工作相關的資料、工作定義等。 |
| 工作 | 作業是由一或多個作業步驟所組成的工作單位。 工作步驟會指定要執行的 T-SQL 腳本及其他必要細節。 |
| 目標群組 | 執行作業所需的伺服器、集區和資料庫的集合。 |
彈性作業代理程式
彈性作業代理程式是用於建立、執行和管理作業的 Azure 資源。 你可以在入口網站建立彈性工作代理作為 Azure 資源(也支援使用 PowerShell 和 REST API 建立和管理彈性工作 )。
建立彈性作業代理程式時需要 Azure SQL 資料庫中現有的資料庫。 此代理程式會將此現有 Azure SQL 資料庫設定為作業資料庫。
您可以透過 Azure 入口網站啟動、停用或取消作業。 Azure 入口網站也可讓您檢視作業定義和執行歷程記錄。
彈性作業代理程式的成本
作業資料庫的費率與 Azure SQL Database 中的任何資料庫相同。 彈性工作代理人的價格是根據你為職務代理人選擇的服務等級所訂定的固定價格。 欲了解更多資訊,請參閱 Azure SQL 資料庫定價頁面。
彈性作業資料庫
利用 工作資料庫 定義工作,並追蹤工作執行的狀態與歷史。 工作是在目標資料庫中執行。 工作資料庫同時儲存代理的元資料、日誌、結果及工作定義。 它包含許多有用的儲存程序及其他資料庫物件,用於使用 T-SQL 建立、執行及管理工作。
你需要 Azure SQL 資料庫來建立彈性工作代理。 工作代理會把所有與工作相關的元資料儲存在 工作資料庫中,而該資料庫應該是新的、空的 Azure SQL 資料庫。
工作資料庫推薦的服務目標為 DTU S1 或更高,但最佳選擇取決於您工作的效能需求:工作步驟數、工作目標數,以及工作執行的頻率。
如果對作業資料庫執行的作業速度比預期慢,則使用 Azure 入口網站或 sys.dm_db_resource_stats DMV 來監視慢速期間內作業資料庫的資料庫效能和資源使用率。 如果資源的使用率 (例如 CPU、資料 IO 或記錄寫入) 接近 100% 並與慢速期間相互關聯,請考慮以累加方式將資料庫調整為更高的服務目標 (在 以 DTU 為基礎的購買模型 或 vCore 購買模型 中),直到作業資料庫效能獲得充分改善為止。
工作資料庫本身可以成為彈性作業的目標。 在這種情況下,將工作資料庫視為其他目標資料庫。 你必須建立工作使用者,並在工作資料庫中授予足夠的權限。 工作使用者的資料庫範圍認證也必須存在於工作資料庫中,就像其他目標資料庫一樣。
當工作資料庫成為某個工作目標時,請確保你的工作不會修改或刪除該資料庫中任何工作代理專屬的元資料。 只使用 作業儲存程序 或 工作檢視 來修改或查詢與工作相關的資訊。
重要
不要修改現有物件或在 工作資料庫中建立新物件,但你可以從資料表讀取資料以進行報告和分析。
彈性作業和作業步驟
工作是一種按時間表或一次性工作進行的工作單位。 一項作業包含一或多個「作業步驟」。
每個工作步驟指定執行一個 T-SQL 腳本、一個或多個目標群組來執行 T-SQL 腳本,以及工作代理連接目標資料庫所需的憑證。 每個作業步驟都有可自訂的逾時和重試原則,而且可以選擇性地指定輸出參數。
彈性作業目標
彈性工作 可以平行執行一個或多個 T-SQL 腳本,跨越大量資料庫、排程或按需執行。 目標可以是 Azure SQL 資料庫的任何層級。
你可以對任意組合的資料庫執行排程工作:一個或多個獨立資料庫、伺服器上的所有資料庫,或彈性池中的所有資料庫,並可額外彈性包含或排除任何特定資料庫。 工作可以跨越多台伺服器和多個資源池,甚至能執行於不同訂閱帳戶的資料庫中。 伺服器和集區都會以動態方式列舉在執行階段,因此作業會針對在執行階段存在於目標群組的所有資料庫執行。
下圖顯示跨不同類型的目標群組執行作業的作業代理程式:
目標群組
目標群組定義了工作步驟執行的資料庫集合。 目標群可以包含以下類型中任意數量及組合:
邏輯 SQL 伺服器:如果你指定一個伺服器,工作執行時伺服器中存在的所有資料庫都會屬於該群組。 您必須提供
master資料庫憑證,以便在工作執行前能夠列舉並更新群組。 如需邏輯伺服器的詳細資訊,請參閱什麼是 Azure SQL 資料庫和 Azure Synapse Analytics 中的邏輯伺服器?。彈性池:如果你指定彈性池,所有在工作執行時屬於彈性池的資料庫都會歸入該群組。 與伺服器一樣,您必須提供
master資料庫憑證,以便在工作執行前更新群組。單一資料庫:指定一個或多個獨立資料庫作為群組的一部分。
提示
在工作執行的瞬間, 動態列舉 會重新評估包含伺服器或池的目標群組中的資料庫集合。 動態列舉可確保作業會在執行階段跨越伺服器或集區中所有現有的資料庫執行。 在執行時重新評估資料庫清單對於池或伺服器成員頻繁變動的情況非常有用。
資源池和單一資料庫可以被包含或排除在群組中。 你可以用任意組合的資料庫建立目標群組。 例如,您可以將伺服器新增至目標群組,但是在彈性集區中排除特定資料庫 (或排除整個集區)。
目標群可以包含多個訂閱系統及跨區域的資料庫。 跨區域執行比在同區域內執行的延遲較高。
以下範例展示了如何在工作執行時動態列舉不同的目標群組定義,以決定影響哪些資料庫:
範例 1 顯示由一系列個別資料庫組成的目標群組。 當工作步驟使用此目標群組時,該工作步驟的動作會在這些資料庫中執行。
範例 2 顯示包含目標伺服器的目標群組。 當工作步驟使用此目標群組時,伺服器會動態列舉以決定目前伺服器中資料庫的清單。 工作步驟的動作會在這些資料庫中執行。
範例 3 顯示與範例 2 類似的目標群組,但特別排除個別資料庫。 該工作步驟 的動作不會 在排除的資料庫中執行。
範例 4 顯示包含以彈性集區作為目標的目標群組。 與 範例二類似,池會在作業運行時動態列舉以決定池中資料庫的清單。
- 範例 5 和範例 6 顯示進階案例,其中伺服器、彈性集區和資料庫都可使用包含及排除規則來結合。
彈性工作排程
彈性工作是雲端優先的產品。 它們設計成即使出現臨時網路或服務可用性問題,也能在排程時啟動。 彈性工作排程會考慮排程開始時間及請求的間隔。 當你建立彈性工作排程時,工作會在每個排程間隔事件後盡快執行。
重要
作為最佳實務,制定未來開始的工作排班。
工作排程能偵測錯過的事件。 如果你建立一個從過去開始的新工作排程,啟用後該工作會立即執行。 若被停用或無法使用,工作會在啟用或可用後立即執行。
舉例來說,現在是 1 月 2 日,UTC 時間上午 9 點。 你設定了一個新工作,設定在今晚1月2日晚上10:30(UTC)開始,並每日執行。 該工作於晚上 10:30(UTC)執行。
為了防止工作意外開始,請制定未來開始的排程。 舉個可能導致無意間啟動工作的例子,你設定了一個新工作,每天在 UTC 晚上 10:30 執行。 你停用這個工作一週。 接著,如果你在 UTC 時間上午 8:30 啟用該工作,該工作會 立即執行,以補上昨晚錯過的區間事件。 執行結束後,工作代理直到下一次排程執行(UTC 晚上 10:30)才會再次執行。 為避免在此情境下於 UTC 上午 8:30 執行,請將工作排程開始時間更新為 1 月 8 日晚上 10:30 UTC,然後啟用該工作。 或者,在工作能立即執行時啟用該工作。
驗證
為彈性作業代理程式的所有目標選擇一種方法。 舉例來說,對於單一彈性工作代理程式,你不能為一個目標伺服器設定使用資料庫範圍的憑證,並為另一個設定使用 Microsoft Entra ID 驗證。
彈性工作代理可透過兩種認證選項連接目標群組指定的伺服器與資料庫:
透過使用者指派的受控識別 (UMI) 進行驗證
透過使用者指派管理身份(UMI)進行 Microsoft Entra 認證,是將彈性工作連接到 Azure SQL 資料庫的推薦選項。 透過 Microsoft Entra ID 支援,工作代理程式可透過 UMI 連接目標資料庫(資料庫、伺服器、彈性池)及輸出資料庫。
你可以選擇性地在包含彈性工作資料庫的邏輯伺服器上啟用 Microsoft Entra ID 認證,透過 Microsoft Entra ID 連線存取與查詢該資料庫。 然而,工作代理會使用內部憑證驗證來連接其工作資料庫。
您可以建立一個 UMI,或使用現有的 UMI,並將相同的 UMI 指派給多個作業代理程式。 每個工作代理只支援一個 UMI。 當你將 UMI 指派給工作代理後,工作代理會利用這個身份來連接並在目標資料庫執行 T-SQL 工作。 工作代理不會對目標伺服器或資料庫使用 SQL 認證。
UMI 名稱必須以字母或數字開頭,長度介於 3 到 128 個字元之間。 它可以包含連字號(-)和底線(_)字元。
欲了解更多關於 Azure SQL 資料庫中 UMI 的資訊,請參閱 Azure SQL 的管理身份,包括使用 UMI 作為 Azure SQL 資料庫邏輯伺服器身份所需的步驟與好處。 如需詳細資訊,請參閱 Azure SQL 的 Microsoft Entra 驗證。
重要
使用 Microsoft Entra ID 驗證時,請在每個目標資料庫中根據 Microsoft Entra ID 建立您的 jobuser 使用者。 授予該使用者執行每個目標資料庫工作所需的權限。
不支援使用系統指派的管理身份(SMI)。
透過資料庫範圍的憑證進行身份驗證
雖然推薦使用 Microsoft Entra(前身為 Azure Active Directory)認證,但你可以設定工作使用 資料庫範圍的憑證 ,在執行時連接到目標群組指定的資料庫。 在 2023 年 10 月之前,資料庫範圍的憑證是唯一的認證選項。
若目標群組包含伺服器或池,這些資料庫範圍的憑證會連結至 master 資料庫以列舉可用資料庫。
在任務資料庫中建立資料庫範圍憑證。
所有目標資料庫都必須以足夠的權限登入,作業才能順利完成 (下圖中的
jobuser)。你在目標資料庫(
LOGIN及PASSWORD,依下圖中masteruser及jobuser所示)中建立的憑證應該與你在職缺資料庫中建立的IDENTITY及SECRET的憑證相符。你可以在不同工作間重複使用憑證。 憑證密碼會被加密並保護,以防止擁有只讀權限的使用者存取作業物件。
下圖幫助你了解如何設定正確的工作憑證,以及彈性工作代理如何利用資料庫憑證作為目標伺服器與資料庫中的登入者和使用者的認證。
注意
使用資料庫範圍認證時,請記得要在每個目標資料庫中建立您的 jobuser 使用者。
彈性作業私人端點
彈性作業代理程式支援彈性作業私人端點。 建立彈性作業私人端點,即可建立彈性作業與目標伺服器之間的私人連結。 彈性作業私人端點功能與 Azure Private Link 不同。
彈性工作私有端點功能支援私有連線至目標伺服器及輸出伺服器,因此即使啟用拒絕 公開存取 選項,工作代理仍能存取這些伺服器。 如果你想關閉 「允許 Azure 服務與資源存取該伺服器 」選項,使用私有端點也是一個可能的解決方案。
彈性作業私人端點支援彈性作業代理程序驗證的所有選項。
彈性工作私有端點功能允許你選擇一個服務管理的私有端點,建立工作代理與其目標及輸出伺服器之間的安全連線。 服務受控私人端點為特定虛擬網路和子網路內的私人 IP 位址。 當你選擇在工作代理的目標伺服器上使用私有端點並輸出時,Azure 會建立一個服務管理的私有端點。 此私有端點則專門由作業代理用於連接與執行工作,或在該目標及輸出資料庫上寫入工作輸出。
你可以透過 Azure 入口網站建立並允許彈性工作私有端點。 透過私人連結連線的目標伺服器可以是 Azure 中的任何位置,即使在不同的地理位置和訂用帳戶中。 您必須為每個所需的目標伺服器和作業輸出伺服器建立私人端點,才能啟用此通訊。
如需一些為彈性作業設定全新服務受控私人端點的教學課程,請參閱設定 Azure SQL 彈性作業私人端點。
彈性作業私人端點的需求
要使用彈性工作私有端點,工作代理和目標伺服器或資料庫都必須托管在 Azure(相同或不同區域)且同一雲端類型(例如兩者皆在公共雲或政府雲中)。
Microsoft.Network資源提供者必須同時註冊工作代理及目標與輸出伺服器的主機訂閱。Azure 為每個目標和輸出伺服器建立彈性工作私有端點。 你必須先批准這些資源,然後彈性作業代理才能使用它們。 你可以透過該邏輯伺服器的 網路 面板或你偏好的客戶端來核准它們。 接著,彈性工作代理可以透過私有連線連接到該伺服器下的任何資料庫。
從彈性工作代理到工作資料庫的連線並不使用私有端點。 作業代理程式本身會使用內部憑證式驗證來連線到其作業資料庫。
- 如果你把工作資料庫加為目標群組成員,它就會像一般目標一樣運作。 你需要依需求設定私有端點。
彈性作業資料庫權限
在作業代理程式建立期間,會在作業資料庫中建立結構描述、資料表,以及名為 jobs_reader 的角色。 此角色會具有下列權限,而且旨在賦予系統管理員更細微的存取控制以便監視作業。 管理員可以將使用者新增到jobs_reader工作資料庫中的角色,以便讓他們能夠監控工作執行。
| 角色名稱 |
jobs 結構描述權限 |
jobs_internal 模式權限 |
|---|---|---|
jobs_reader |
SELECT |
無 |
警告
不要更新 職缺資料庫中的內部目錄視圖,例如 jobs.target_group_members。 手動變更這些目錄檢視可能會損毀作業資料庫並導致失敗。 這些檢視僅適用於唯讀查詢。 你可以利用 工作資料庫 中的儲存程序來新增或刪除目標群組和成員,例如 jobs.sp_add_target_group_member。
在授與作業資料庫任何提高權限的存取權之前,請考慮安全性含意。 擁有建立或編輯工作權限的惡意使用者,可能會建立或編輯使用儲存憑證連接其控制的資料庫的工作。 此漏洞可能讓惡意使用者得知憑證密碼或執行惡意指令。
監視彈性作業
彈性工作代理與 Azure Alerts 整合,用於工作狀態通知,簡化了監控工作執行狀態與歷史的解決方案。
Azure 入口網站包含額外功能,支援彈性工作與工作監控。 在 Elastic job agent 的 「概覽 」頁面,會顯示最近的工作執行,如下圖所示。
您可以使用 Azure 入口網站、Azure CLI、PowerShell 和 REST API 來建立 Azure 監視器警示規則。 失敗的彈性作業計量是監視和接收彈性作業執行警示的良好起點。 此外,您可以選擇透過 Azure 警示設施的可設定動作 (例如簡訊或電子郵件) 來發出警示。 如需詳細資訊,請參閱在 Azure 入口網站中建立 Azure SQL 資料庫的警示。
如需相關範例,請參閱建立、設定及管理彈性作業。
作業輸出
每個目標資料庫中作業步驟的結果會詳細記錄,腳本輸出可被擷取到指定資料表。 您可以指定要儲存作業所傳回資料的資料庫。
作業歷程記錄
你可以透過查詢工作資料庫中的資料表來檢視彈性工作執行歷史jobs.job_executions。 系統清理作業會清除超過 45 天的執行歷史。 若要手動移除少於 45 天的歷史紀錄,請在sp_purge_jobhistory中執行儲存程序。
工作狀態
您可以透過查詢資料表 jobs.job_executions,在工作資料庫中監控彈性作業執行。
最佳作法
使用彈性資料庫作業時,請考慮下列最佳做法。
安全性最佳做法
將 API 的使用限制為受信任的個人。
授予執行工作步驟所需的最少權限。 如需詳細資訊,請參閱授權和權限。
使用伺服器或池目標群組成員時,請建立一個具有權限的獨立憑證以在
master資料庫中瀏覽和列出資料庫。 此憑證會在工作執行前擴充伺服器與池的資料庫清單。
彈性作業效能
彈性作業在等待長時間執行的作業完成時,會使用最少的運算資源。
視資料庫的目標群組大小和作業所需的執行時間 (並行背景工作數目) 而定,代理程式需要不同的計算量和作業資料庫效能 (目標愈多和作業數目較高,所需的計算量就愈高)。
並行容量層
從 2023 年 10 月開始,彈性作業代理程式具有多個效能層,可允許增加容量。
容量增量表示,作業代理程式可以連線並啟動作業的並行目標資料庫總數。 為了獲得更多並行目標連線以執行工作,請將作業代理的階層從預設的 JA100 階層升級,該階層限制為 100 個同時進行目標連線。
大部分的環境隨時都需要少於 100 個並行作業,因此 JA100 是預設值。
| 彈性工作代理人等級 | 並行作業數上限 |
|---|---|
JA100 |
100 |
JA200 |
200 |
JA400 |
400 |
JA800 |
800 |
超過工作代理與工作目標的並行容量層級,會對某些目標資料庫和伺服器造成排隊延遲。 舉例來說,如果你在 JA100 層開始一個任務時有 110 個目標,10 個目標會等待其他目標完成後才開始。
你可以透過 Azure 入口網站、 PowerShell 或 Job Agents REST API 修改彈性工作代理的層級或服務目標。 如需範例,請參閱調整作業代理程式。
限制作業對彈性池的影響
為了確保在 Azure SQL 資料庫彈性池中對資料庫執行工作時不會過載資源,請設定工作限制同時執行的資料庫數量。
藉由在 T-SQL 中設定sp_add_jobstep預存程序@max_parallelism的參數,以設定作業執行所在的並行資料庫數目。
等冪指令碼
彈性作業的 T-SQL 腳本必須是 冪等的,也就是說,如果腳本成功並再次執行,結果會相同。 指令碼會因為暫時性網路問題而失敗。 在這種情況下,工作會自動重複執行腳本預設次數後才停止執行。 冪등腳本即使成功執行兩次(或更多次)也會有相同的結果。
簡單的策略是在建立物件之前,測試其是否存在。 以下範例為假設性:
IF NOT EXISTS (SELECT *
FROM sys.objects
WHERE [name] = N'some_object')
PRINT 'Object does not exist'; -- Create the object
ELSE
PRINT 'Object exists'; -- If it exists, drop the object before recreating it.
同樣地,指令碼必須以邏輯方式測試並反駁它所找到的任何條件,才能夠順利執行。
限制
這些是彈性作業服務目前的限制。 產品團隊正積極努力消除盡可能多的這些限制。
| 問題 | 描述 |
|---|---|
| 彈性工作代理需要在故障轉移或移動到新 Azure 區域後重新建立並啟動。 | 彈性作業服務會將其所有作業代理程式與作業中繼資料儲存在工作資料庫中。 任何 Azure 資源的故障轉移或移動到新 Azure 區域,也會將工作資料庫、工作代理程式和工作元資料移到新的 Azure 區域。 然而,彈性工作代理是一個僅用於計算的資源,必須在新區域明確重建並啟動,工作才會再次執行。 一旦啟動,彈性工作代理會依照先前定義的工作排程在新區域繼續執行工作。 |
| 來自工作資料庫的過度 SQL 稽核日誌 | 彈性作業代理程式會持續輪詢工作資料庫,以檢查新作業與其他 CRUD 作業的到達。 若在存放工作資料庫的伺服器啟用稽核,工作資料庫可產生大量稽核日誌。 你可以透過使用帶有謂詞表達式的 Set-AzSqlServerAudit 指令過濾掉這些稽核日誌來緩解這個問題。例如: Set-AzSqlServerAudit -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -BlobStorageTargetState Enabled -StorageAccountResourceId "/subscriptions/7fe3301d-31d3-4668-af5e-211a890ba6e3/resourceGroups/resourcegroup01/providers/Microsoft.Storage/storageAccounts/mystorage" -PredicateExpression "application_name <> 'Microsoft Azure SQL Database elastic jobs'"這個指令只會過濾作業代理到作業資料庫的稽核日誌,不會過濾作業代理到任何目標資料庫的稽核日誌。 |
| 使用超大規模資料庫作為作業資料庫 | 不支援使用超大規模資料庫作為作業資料庫。 不過,彈性作業可以將目標設為超大規模資料庫,方法與 Azure SQL Database 中的任何其他資料庫相同。 |
| 具有彈性作業的無伺服器資料庫和自動暫停。 | 已啟用自動暫停的無伺服器資料庫不支援作為作業資料庫。 彈性工作針對的無伺服器資料庫確實支援自動暫停,且工作連線會恢復自動暫停功能。 |
| 將工作資料庫匯出至 BACPAC 檔案 | 不支援將 工作資料庫 匯出成 BACPAC 檔案。 如果包含 工作資料庫 的 SQL Server 需要匯出,請先丟棄 工作資料庫 再匯出伺服器。 |