匯出 (0) 列印
全部展開

Azure SQL Database 節流

更新日期: 2015年2月

本主題詳細說明引擎節流機制、相關的錯誤碼,以及如何處理您可能遇到的錯誤。

下表提供有關引擎節流機制、傳回之對應錯誤碼以及如何解決錯誤之建議的資訊。

 

引擎節流機制 傳回的錯誤碼 建議

引擎節流會依照下列步驟來減少負載及保護系統健全狀況:

  1. 判斷讓系統回到健全狀態所需減少的負載。

  2. 將耗用過多資源的訂戶資料庫標示為節流候選項目。如果引擎節流因為僅稍微超過的類型而發生節流,則某些資料庫可能不適合被考量為候選項目。如果引擎節流是因為大量超過的類型而導致,則所有訂戶資料庫都可以是節流的候選項目,除了在目前節流週期之前未收到節流週期之任何負載的訂戶資料庫以外。

  3. 藉由評估候選資料庫的歷程記錄資源使用模式,計算必須節流多少個候選資料庫,才能讓系統回到健全狀態。

  4. 在系統負載回到所需的程度之前,針對計算的候選資料庫數目進行節流。根據節流為「硬節流」(Hard Throttling) 或「軟節流」(Soft Throttling),套用的節流程度或節流模式可能有所不同。您可以使用錯誤訊息中的事件識別碼和代碼值,查明所套用之節流的程度和模式。任何節流的資料庫至少會在一個節流週期的持續期間 (10 秒) 維持節流狀態,但是節流通常可能會持續多個節流週期,好讓系統回到健全狀態。

40501:服務目前忙碌中。請在 10 秒後重試一次要求。事件識別碼:<ID>。程式碼:<code>。

note附註
事件識別碼代碼值可用來判斷哪些要求已節流,以及這是軟節流還是硬節流。如需詳細資訊,請參閱本主題稍後的<節流事件識別碼>和<解碼原因代碼>章節。

在 10 秒後退出並重試一次要求。

錯誤 40501 的節流事件識別碼是 GUID 值,可唯一識別節流事件。

40501: The service is currently busy. Retry the request after 10 seconds. Incident ID: <ID>. Code: <code>.

如果您無法判斷節流發生的原因,或是節流一直持續而您不知道如何解決,請連絡 Microsoft 支援服務並向受理人員陳述錯誤訊息中的事件識別碼 (<識別碼>)。Microsoft 支援服務將使用此事件識別碼,擷取更多您的節流事件相關資訊。事件識別碼可用來取得下列資訊:

  • 節流事件的開始時間。

  • 節流的類型 (軟節流相對於硬節流)。

  • 資源類型 (例如 CPU),節流事件因此資源而發生。

  • 發生此節流事件時,使用者正在執行什麼?

與 Microsoft 客戶支援部門連絡了解造成事件的根本原因之後,您可以在應用程式中進行適當的變更。

下一節描述如何解碼以下引擎節流錯誤碼所傳回的原因代碼。

40501: The service is currently busy. Retry the request after 10 seconds. Incident ID: <ID>. Code: <code>.

錯誤訊息中的原因代碼 (<code>) 是十進位數字,其中包含「節流模式」和超過的「資源類型」的相關資訊。

  • 「節流模式」會列舉拒絕的陳述式類型。

  • 「資源類型」會指定超過的資源。節流可以在多個資源類型上同時進行,例如 CPU 及 IO。

以下列範例錯誤訊息為例,其中的原因代碼為 131075。

40501: The service is currently busy. Retry the request after 10 seconds. Incident ID: {5DE17AB8-A6E34BE5-A2E95BB5D4CC4155}. Code: 131075.

下圖示範如何解碼原因代碼。

解碼原因代碼

若要取得節流模式,您也可以將模數 4 套用至原因代碼。模數作業會傳回某個數值除以另一個數值的餘數。若要取得節流類型和資源類型,請將原因代碼除以 256,如步驟 1 所示。然後,將結果的商數轉換成其等效二進制數,如步驟 2 和 3 所示。此圖列出所有節流類型和資源類型。請將您的節流類型與資源類型位元相比較,如圖中所示。

下表提供調整模式的清單。

 

調整模式代碼 描述 拒絕的陳述式類型 仍然可以處理的陳述式

0

無節流

全部

1

拒絕更新 / 插入

INSERT、UPDATE、CREATE TABLE | INDEX

DELETE、DROP TABLE | INDEX、TRUNCATE

2

拒絕所有寫入

INSERT、UPDATE、DELETE、CREATE、DROP

SELECT

3

全部拒絕

全部

若要取得節流模式,您也可以將模數 4 套用至原因代碼。131075 % 4 = 3。結果 3 表示節流模式是「全部拒絕」。

若要取得節流類型及資源類型,請將原因代碼除以 256。然後將結果的商數轉換為其等效二進制數。131075 / 256 = 512 (十進位) and 512 (十進位) = 10 00 00 00 00 (二進位)。這表示資料庫因 CPU (資料類型 4) 及硬節流 (10) 而受到節流。

下列範例程式碼會使用 Enterprise Library Integration Pack for Azure 中暫時性錯誤處理應用程式區塊 (也稱為 “Topaz”) 內的 ThrottlingCondition 類別,以解碼引擎節流錯誤中的原因代碼 (40501)。若要下載暫時性錯誤處理應用程式區塊組件和原始程式碼來使用 ThrottlingCondition 類別,請參閱 Enterprise Library 5.0 Integration Pack for Azure

下列範例程式碼會提示您輸入您在引擎節流錯誤中取得的原因代碼 (40501),然後針對指定的原因代碼顯示節流模式、節流類型和資源類型。

using System;
using Microsoft.Practices.EnterpriseLibrary.TransientFaultHandling.Data;

namespace ThrottlingDecoder
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.Write("Enter a throttling code to be decoded: ");
            var rawCode = Console.ReadLine();
            int reasonCode;

            if (Int32.TryParse(rawCode, out reasonCode))
            {
                var throttlingCode = ThrottlingCondition.FromReasonCode(reasonCode);

                Console.WriteLine("\nBreakdown for throttling reason code {0}:\n", reasonCode);

                Console.WriteLine("Throttling mode: {0}", throttlingCode.ThrottlingMode);
                Console.WriteLine("Throttled On CPU: {0}", throttlingCode.IsThrottledOnCpu);
                Console.WriteLine("Throttled On DB Size: {0}", throttlingCode.IsThrottledOnDatabaseSize);
                Console.WriteLine("Throttled On DB Reads: {0}", throttlingCode.IsThrottledOnDataRead);
                Console.WriteLine("Throttled On DB Free space: {0}", throttlingCode.IsThrottledOnDataSpace);
                Console.WriteLine("Throttled On Log Free Size: {0}", throttlingCode.IsThrottledOnLogSpace);
                Console.WriteLine("Throttled On Log Writes: {0}", throttlingCode.IsThrottledOnLogWrite);
                Console.WriteLine("Throttled On Worker Threads: {0}", throttlingCode.IsThrottledOnWorkerThreads);
                
                Console.WriteLine("\nThrottled resources:");

                foreach (var res in throttlingCode.ThrottledResources)
                {
                   if (res.Item2 != ThrottlingType.None) Console.ForegroundColor = ConsoleColor.Red;
                    Console.WriteLine("Resource type {0} is throttled on {1}", res.Item1, res.Item2);
                    if (res.Item2 != ThrottlingType.None) Console.ResetColor();
                }
            }
            else
            {
                Console.WriteLine("Sorry, but the input you provided does not seem to be a valid number.");
            }
            Console.Read();
        }
    }
}

SQL Database TDS 閘道在報告失敗之前重試連接大約 30 秒。如果您預期應用程式流量很高,請在您的應用程式中建立重試邏輯。如果連接失敗,請執行下列步驟:

  • 處理閒置和暫時性中斷連接。

    note附註
    安裝 .NET Framework 4.0 的可靠性更新 1,以修復 SqlClient 傳回與應用程式之間的無效連接問題。有了這項更新,SqlClient 會先檢查集區中的連接是否無效,然後再將它傳回應用程式。如果連接無效,SqlClient 會先重新連接,再將它傳回應用程式。如需有關此問題的詳細資訊,請參閱將 SQL Database 中的連接集區錯誤最小化

  • 在 10 秒的間隔內重試連接 SQL Database,直到資源可供使用且再次建立您的連接為止。根據您的應用程式、資料庫和網路工作負載,您必須視需要增加延遲時間。

  • 如果連接再次終止,請變更您的工作負載。如果連接再次終止,請查閱錯誤碼、查明真正的問題所在,然後嘗試變更您的工作負載。您可以在用戶端應用程式中實作佇列或延遲機制,以降低您的工作負載。

    另一個解決方案可能是重新設計您的應用程式和資料庫,以移除資源瓶頸。請確定您的應用程式不會經由過多的 DDL 或 DML 作業而多載 tempdb。此外,請確定交易不會封鎖任何資源。請在適當的情況下,考慮將您的資料庫分割成多個資料庫。

  • 確定您的程式碼可以從節流情況中復原。使用者應該假設,連接可以隨時在應用程式內中斷連接。因此,請盡可能在單一交易中進行批次要求。如此會讓批次可能部分完成並將資料庫置於非預期/非測試狀態的情況降到最低。若要這樣做,您可能會想要針對每個隨選批次及每個預存程序的開頭/結尾執行 BEGIN TRANS/COMMIT TRANS。

  • 了解重試邏輯如何影響應用程式 (等冪) 的正確性。當執行更新或插入時,請務必了解傳回成功之前,中斷連接時會發生什麼事。如果交易中止,則重試連接是正確的步驟。如果交易實際上已認可,則再次執行交易可能不正確。執行非等冪性之變更的使用者可能需要修改其邏輯資料庫結構描述,以便能夠根據使用的重試邏輯來偵測重複的交易認可,以避免中斷連接。

使用重試程式碼來記錄節流錯誤,以區分暫時性連接、節流和嚴重失敗語法、遺漏預存程序等等。如果您無法連接到 SQL Database,這對於疑難排解案例特別實用。在此情況下,疑難排解工作將會著重於記錄的資訊,而且有效疑難排解的能力將會與已記錄之資訊的品質相關聯。如需有關實作 SQL Database 應用程式中記錄的詳細資訊,請參閱實作 Azure SQL Database 應用程式的記錄

另請參閱

Microsoft 正展開一份線上問卷調查,了解您對於 MSDN 網站的看法。 如果您選擇參加,您離開 MSDN 網站時即會顯示線上問卷調查。

您是否想要參加?
顯示:
© 2015 Microsoft