匯出 (0) 列印
全部展開

Azure SQL Database 的效能考量

更新日期: 2014年1月

本文為使用已移轉至 Microsoft Azure SQL Database 之資料庫的應用程式,提供改善應用程式效能的應用程式最佳作法。當資料庫伺服器與應用程式伺服器位在相同機架上時,這些最佳作法影響不大。不過,當資料庫伺服器移至遠端資料中心時,這些相同的最佳作法對維護良好效能就變得非常重要。此外,Microsoft Azure 是共用環境,因為所有資源都會與其他應用程式、角色和資料庫共用。透過網路負載平衡和閘道元件,Azure 維護規模經濟 (Economy of Scale),並且最有效率地提供整體環境計算與網路資源。在設計應用程式和部署應用程式至 Azure 時,請考慮這些因素。

本文涵蓋最佳化 Microsoft Azure SQL Database 環境效能的設計和實作最佳作法。具體而言,本文針對在內部部署資料庫移轉至 Microsoft Azure SQL Database 時,可能會導致所見效能問題的兩個區域,檢閱解決的最佳作法:

有關 Azure 資料庫效能的一些其他文章如下所述:

Azure SQL Database Premium Edition 提供了保留資料庫資源的功能,這項功能目前是透過預覽計畫提供。<Azure SQL Database 效能指引>文件提供了指引,協助您決定透過預覽計畫取得的高階資料庫是否適合您的應用程式,並提供微調應用程式以充分利用這項功能的建議。

Windows Azure SQL Database 和 SQL Server -- 效能與延展性的比較和對比>文件中描述一些 SQL Database 的效能模式、適切評估 SQL 資料庫執行個體效能的幾項技術,並且包括幾個 SQL 指令碼,可幫助您評估 SQL 資料庫執行個體及進行疑難排解。

  • 連接管理

  • 在應用程式層和資料庫層之間的網路延遲

作者: Silvano Coriani、Steve Howard
審稿者:Mark Simms、Valery Mizonov、Kun Cheng、Paolo Salvatori、Jaime Alva Bravo

當資料庫裝載於 Microsoft Azure SQL Database 時,資料庫連接可能比內部部署環境更常結束。如果應用程式不會快速偵測到連接遺失,並在發生暫時性錯誤時重新連接,使用者可能會感覺這些結束是效能問題。做為在共用資源上提供大規模、多租用戶資料庫服務的提供者,Microsoft Azure SQL Database 跨三個節點叢集每個資料庫,並在叢集節點之間取得資源平衡,以提供更好的經驗給所有租用戶。暫時性錯誤的一個範例是 Microsoft Azure SQL Database 偵測到裝載多個資料庫的伺服器使用量大。在此情況下,Microsoft Azure SQL Database 可能將其中一個資料庫容錯移轉至處理負載較低的次要叢集節點。容錯移轉會結束資料庫的所有開啟連接,並回復未完成的交易。應用程式必須快速偵測此錯誤,重新連接到資料庫,並重試其上次交易。

下列清單概述 Microsoft Azure SQL Database 可能會結束連接的某些原因:

  • 整體 Microsoft Azure SQL Database 網路拓撲包含防火牆、負載平衡器和表格式資料流 (TDS) 閘道。其中每個拓撲元件都會在資料存取程式碼和資料庫節點之間加入一層。在這些額外層的錯誤會結束連接。

  • Microsoft Azure SQL Database 持續收集和分析資料庫使用量統計資料。根據這些統計資料,Microsoft Azure SQL Database 可能會在需要時結束連接,以保持服務健全狀態。

  • 拒絕服務的攻擊會導致 Microsoft Azure SQL Database 在一段時間內封鎖特定 IP 位址的連接。

  • 某些容錯移轉事件可能會導致 Microsoft Azure SQL Database 突然結束工作階段 (請注意,在容錯移轉事件之前節點上開啟的任何連接,在容錯移轉之後將無法在新的節點上使用)。

上述清單只是某些連接結束的原因。如需有關連接錯誤的詳細資訊和如何管理 Microsoft Azure SQL Database 連接的詳細資料,請參閱下列文件:

為了協助管理 Microsoft Azure SQL Database 連接問題,Microsoft 努力提供下列功能:

  • 有關如何指定基本資訊,例如伺服器名稱和安全性認證,或完整不失真地使用工具 (例如大量複製程式 (bpc.exe)) 的一致方式。例如,從 SQL Server Native Client 11、JDBC 4.0 版,以及來自 .NET Framework 4.0 版的 .NET Framework Data Provider for SQL Server (System.Data.SqlClient) 開始,當您存取 Microsoft Azure SQL Database 時不需要指定 username@server。

  • 專注確保所有連接技術可以維護連接,即使在閒置期間也一樣。例如,不同於 Windows,Java 平台不會原生管理資料庫連接的「保持連線」間隔。因此,連接到 Microsoft Azure SQL Database 的 JDBC 元件需要登錄設定的某些變更,確保不會卸除閒置連接。
    如需詳細資訊,請參閱 MSDN Library 主題<連接到 Azure SQL Database 的資料庫>。

此外,Microsoft 持續在最常見的資料存取程式庫和 Microsoft Azure SQL Database Service Release 中部署一些更新。這些更新中最顯著的可能是暫時性錯誤處理應用程式區塊,此應用程式庫提供強固的暫時性錯誤處理邏輯 (暫時性錯誤是因為某個暫時情況如網路連接問題或服務無法使用而發生的錯誤)。下一節提供有關如何將暫時性錯誤處理應用程式區塊套用至應用程式的高階檢視。

暫時性錯誤處理應用程式區塊會封裝有關在您的應用程式使用下列 Azure 服務時,可能發生之暫時性錯誤的資訊:

  • Microsoft Azure SQL Database

  • Azure 服務匯流排

  • Azure 儲存體

  • Azure 快取服務

其中每個服務都可能有不同的暫時性錯誤。因此,暫時性錯誤處理應用程式區塊針對每個服務使用特定的錯誤偵測原則。同樣地,不同的應用程式需要不同的錯誤處理策略。為了包容這些差異,暫時性錯誤處理應用程式區塊提供了不同的重試邏輯方法,來處理各種暫時性錯誤狀況。這些現成的原則可擴充,方法是建立公開定義完善之介面的自訂類別。

在現有應用程式內使用暫時性錯誤處理應用程式區塊的影響非常少。根據其設計,暫時性錯誤處理應用程式區塊提供數個模擬一般 ADO.NET 資料存取層之行為的類別和擴充方法。

為了示範此應用程式庫易於使用,接下來的幾個段落說明如何將暫時性錯誤處理應用程式區塊套用至某些現有的程式碼。下列範例示範查詢資料庫並使用結果集的簡單方法:

        public static void ReadFromDB()
        {

            using (SqlConnection conn = new SqlConnection(connString))
            {
                try
                {
                    conn.Open();

                    SqlCommand selectCommand = 
new SqlCommand(@"SELECT SOH.SalesOrderID
                         FROM SalesLT.SalesOrderHeader SOH 
                         JOIN SalesLT.SalesOrderDetail SOD ON SOH.SalesOrderID = SOD.SalesOrderID
                         JOIN SalesLT.Product P ON SOD.ProductID = P.ProductID
                         JOIN SalesLT.Customer C ON SOH.CustomerID = C.CustomerID
                         JOIN SalesLT.CustomerAddress CA on C.CustomerID = CA.CustomerID
                         JOIN SalesLT.Address A on CA.AddressID = A.AddressID
                         WHERE A.City=@City", conn);

                    selectCommand.Parameters.Add(new SqlParameter("@City", SqlDbType.VarChar, 20, ParameterDirection.Input, false, 0, 0, "", DataRowVersion.Current, "London"));
                    selectCommand.CommandType = CommandType.Text;

                    IDataReader dataReader = selectCommand.ExecuteReader();

                    while (dataReader.Read())
                    {
                        Console.WriteLine("OrderID: {0}", dataReader["SalesOrderID"]);
                    }
                }
                catch (Exception e)
                {
                    Console.WriteLine("Exception: {0}",e.Message);
                }
            }

為了讓程式碼更強固,請先定義一個適當的重試策略。累加重試策略是最佳的。為了實作此策略,請先使用 Microsoft.Practices.EnterpriseLibrary.WindowsAzure.TransientFaultHandling.SqlAzure.SqlAzureTransientErrorDetectionStrategy 類別。這個類別會攔截與暫時性錯誤狀況相關的錯誤碼。然後,將類別 System.Data.SqlClient SqlConnection 取代為 Microsoft.Practices.EnterpriseLibrary.WindowsAzure.TransientFaultHandling.SqlAzure.ReliableSqlConnection 類別,如下列程式碼範例所示:

        public static void ReadFromDBWithReliableConnection()
        {

            // Define retry Strategy and Policy
            var retryStrategy = new Incremental(5, TimeSpan.FromSeconds(1), TimeSpan.FromSeconds(2));
            var retryPolicy = new RetryPolicy<SqlAzureTransientErrorDetectionStrategy>(retryStrategy);

            // Receive notifications about retries.
            retryPolicy.Retrying += new EventHandler<RetryingEventArgs>(retryPolicy_Retrying);

            using (ReliableSqlConnection conn = new ReliableSqlConnection(connString,retryPolicy))
            {
                try
                {
                    conn.Open();

                    SqlCommand selectCommand = new SqlCommand(@"SELECT SOH.SalesOrderID
                                        FROM SalesLT.SalesOrderHeader SOH 
                                        JOIN SalesLT.SalesOrderDetail SOD ON SOH.SalesOrderID = SOD.SalesOrderID
                                        JOIN SalesLT.Product P ON SOD.ProductID = P.ProductID
                                        JOIN SalesLT.Customer C ON SOH.CustomerID = C.CustomerID
                                        JOIN SalesLT.CustomerAddress CA on C.CustomerID = CA.CustomerID
                                        JOIN SalesLT.Address A on CA.AddressID = A.AddressID
                                        WHERE A.City=@City");

                    selectCommand.Parameters.Add(new SqlParameter("@City", SqlDbType.VarChar, 20, ParameterDirection.Input, false, 0, 0, "", DataRowVersion.Current, "London"));
                    selectCommand.CommandType = CommandType.Text;

                    IDataReader dataReader = conn.ExecuteCommand<IDataReader>(selectCommand);

                    while (dataReader.Read())
                    {
                        Console.WriteLine("OrderID: {0}", dataReader["SalesOrderID"]);
                    }
                }
                catch (Exception e)
                {
                    Console.WriteLine("Exception: {0}", e.Message);
                }
            }
        
        }

上述程式碼範例加入了適當的重試邏輯,同時也將現有的 SQLConnection 程式碼取代為 ReliableSQLConnection 程式碼。有替代方法可將重寫的程式碼數量降到最低,就是使用暫時性錯誤處理應用程式區塊所提供的擴充方法。這個方法不僅將所需的重寫數量降到最低,也提供在 ADO.Net 應用程式新增重試功能的一般方式。若要使用擴充方法,請將 Open() 和各種 Execute 方法 (例如 ExecuteScalar()、ExecuteReader() 或 ExecuteNonQuery()) 取代為其具重試功能的對等項目,例如 OpenWithRetry() 或 ExecuteScalarWithRetry()。作法如下列的程式碼範例所示:

        public static void ReadFromDBWithExecute()
        {

            // Define retry Strategy and Policy
            var retryStrategy = new Incremental(5, TimeSpan.FromSeconds(1), TimeSpan.FromSeconds(2));
            var retryPolicy = new RetryPolicy<SqlAzureTransientErrorDetectionStrategy>(retryStrategy);

            // Receive notifications about retries.
            retryPolicy.Retrying += new EventHandler<RetryingEventArgs>(retryPolicy_Retrying);

            try
            {
                retryPolicy.ExecuteAction(
                  () =>
                  {
                      using (SqlConnection conn = new SqlConnection(connString))
                      {
                          conn.OpenWithRetry();

                          SqlCommand selectCommand = new SqlCommand(@"SELECT SOH.SalesOrderID
                                                FROM SalesLT.SalesOrderHeader SOH 
                                                JOIN SalesLT.SalesOrderDetail SOD ON SOH.SalesOrderID = SOD.SalesOrderID
                                                JOIN SalesLT.Product P ON SOD.ProductID = P.ProductID
                                                JOIN SalesLT.Customer C ON SOH.CustomerID = C.CustomerID
                                                JOIN SalesLT.CustomerAddress CA on C.CustomerID = CA.CustomerID
                                                JOIN SalesLT.Address A on CA.AddressID = A.AddressID
                                                WHERE A.City=@City",conn);

                          selectCommand.Parameters.Add(new SqlParameter("@City", SqlDbType.VarChar, 20, ParameterDirection.Input, false, 0, 0, "", DataRowVersion.Current, "London"));
                          selectCommand.CommandType = CommandType.Text;

                          // Execute the above query using a retry-aware ExecuteCommand method which will
                          // automatically retry if the query has failed (or connection was dropped)
                          IDataReader dataReader = selectCommand.ExecuteReaderWithRetry(retryPolicy);
                          
                            while (dataReader.Read())
                            {
                                Console.WriteLine("OrderID: {0}", dataReader["SalesOrderID"]);
                            }                          
                      }
                  });
            }
            catch (Exception e)
            {
                Console.WriteLine("Exception: {0}", e.Message );
            }

        }

暫時性錯誤處理應用程式區塊支援可設定重試原則的宣告。如需有關宣告重試原則的詳細資訊,請參閱<在組態中指定重試策略>。

此處顯示的程式碼範例提供如何使用暫時性錯誤處理應用程式區塊的一瞥。如需有關如何使用這個應用程式庫的詳細資訊,請參閱 TechNet Wiki 教學課程:Azure SQL Database 中暫時性失敗的重試邏輯

除了連接錯誤以外,網路延遲是另一個目前 Microsoft Azure SQL Database 使用者最常遇到的效能問題。

雖然網際網路延遲的影響是已知的,但人們傾向於低估應用程式和 Microsoft Azure SQL Database 之間延遲的影響。即使同一個資料中心裝載應用程式和資料庫,延遲通常高於傳統的內部部署環境。這個較高延遲是源自 Azure 多個租用戶本質。此外,這個較高延遲會放大「多話」應用程式行為的影響,因為對資料庫的每個呼叫都會發生額外的延遲,可能累積造成整體效能降低。因此,相較於存取內部部署裝載的 Microsoft Azure SQL Database 資料庫,「多話」應用程式存取 SQL Server 裝載的資料庫的所需時間明顯更多。

除了應用程式和 Microsoft Azure SQL Database 之間的延遲之外,您的方案中各種分散式元件之間也會增加通訊延遲。這種類型的延遲可能是內部部署與雲端應用程式之間的最大差異之一。這種類型的延遲存在於使用者與應用程式之間的通訊,以及應用程式與 Microsoft Azure SQL Database 之間的通訊。

從使用者的觀點而言,所有這些網路延遲的原因對應到使用者所見的下列回應時間:

回應時間 = 2 x (Latency_1 + Latency_2) + Application_Processing_Time + Query_Exec_Time

其中

  • Latency_1 是使用者與裝載應用程式的資料中心之間的延遲。(也可以在內部部署環境中找到這種類型的延遲)。

  • Latency_2 是應用程式與 Microsoft Azure SQL Database 資料庫之間的延遲。

為確保效能最佳化,我們建議您先執行下列基本的動作:

  • 透過選取最接近多數使用者的資料中心,將 Latency_1 降到最低。

  • 透過將資料與 Azure 應用程式共置,讓網路往返數目最小化,以將 Latency_2 降到最低。

  • 透過遵循當您存取資料層、處理效能及撰寫最佳化程式碼時,針對內部部署資料庫使用的一般最佳作法,將 Application_Processing_TimeQuery_Exec_Time 降到最低。

資料庫的裝載位置盡可能接近應用程式的執行位置是很重要的。如果您的應用程式在美國中北部資料中心執行,則在美國中北部資料中心裝載資料庫,將會讓您的網路往返最短,因此距離相關的延遲也是最短。

雖然內部部署裝載的應用程式可以存取 Azure 裝載的資料庫,但請記住這會導致資料存取的較高延遲,也會導致資料中心收取資料出站費用。

在多個地理位置需要存取資料的情況下,請使用內容傳遞網路將靜態資料分散到多個站台。或者,在不同的資料中心,建立多個資料庫副本,並且使用 SQL 資料同步 (預覽)同步處理其資料。這些方法可協助在多個地理位置執行的應用程式,尋找最接近應用程式不同執行個體的資料,並減少整體延遲。

note附註
SQL 資料同步 (預覽)目前僅供預覽,只是為了收集未來版本的產品回函,不應該用於生產環境。

將網路往返降到最低,對內部部署應用程式來說很重要,對 Azure 特別重要。Microsoft Azure SQL Database 處理的查詢必須經過網路負載平衡層,以及 TDS 通訊協定閘道,然後 Microsoft Azure SQL Database 才會接收查詢。雖然此抽象化可讓 Microsoft Azure SQL Database 提供延展性和可用性給使用者,但此抽象化也需要一定數量的處理,導致每個往返的小量延遲。在許多循序往返中傳送資料到 Microsoft Azure SQL Database 的應用程式可能會注意到顯著的效能衝擊。

為了讓往返的影響減至最少,請遵循用於內部部署應用程式相同的最佳作法:

  • 使用預存程序,尤其是用於封裝複雜資料存取邏輯和交易式行為 - 在進行循序呼叫時,如果第二個呼叫相依於第一個呼叫傳回的資料,使用預存程序來執行第二個呼叫的邏輯,可排除一個或多個往返並提升效能。這個方法會自然減少往返和伺服器端的資源鎖定與使用量。

  • 將資料指標或逐列存取的使用降至最低 - 在可能的情況下使用集合為基礎的作業。如果必須使用資料指標,請使用用戶端資料指標。

  • 在每個往返中使用資料表值參數,傳送多個資料列給 Microsoft Azure SQL Database - Microsoft Azure SQL Database 使用資料表值參數,就如同內部部署版本的 SQL Server Database Engine 一樣。資料表值參數有助於減少對處理一組記錄/值的相同預存程序的多次呼叫。您也可以將表格式參數傳遞至單一參數化查詢,例如 SELECT、INSERT、UPDATE 或 DELETE 命令。
    如需詳細資訊,請參閱下列《線上叢書》主題<使用資料表值參數>。

  • 在可能的情況下使用本機快取 - 本機快取可讓您重複使用相同的結果,而不需要與 Microsoft Azure SQL Database 之間的多個往返。此外,請記住您可以快取預存程序的呼叫,在相同條件下會傳回相同的值。

  • 在可能的情況下使用 Azure 快取 - 對唯讀查閱資料使用 Azure 快取,可將 Microsoft Azure SQL Database 的網路流量降至最低。如需詳細資訊,請參閱<使用 Azure 快取減少網路往返>。

  • 在可能的情況下快取中繼資料和資料。

  • 在可能的情況下避免在執行階段時擷取中繼資料。

  • 避免類別如 SqlCommandBuilder - 這些類別會在執行階段時查詢中繼資料,造成額外的往返。

  • 在可能的情況下一起批次處理 SQL 陳述式 - 您可以在單一批次命令中串連多個 Transact-SQL 陳述式,以擷取多個結果集或在單一網路往返中執行多個 DML 作業。在處理連續大量 INSERT 作業時,這個方法特別有用。

  • 避免應用程式型交易管理 - 將交易管理作業(BEGIN TRAN、COMMIT/ROLLBACK) 封裝到預存程序,可以減少網路往返與鎖定。

將資料與使用者之間的距離降到最低,並讓網路往返降到最低之後,下一個步驟就是確保您的應用程式遵循內部部署資料庫的一般最佳作法。藉由在應用程式的資料存取層中套用已知的最佳作法和建議,以及效能與最佳化最佳作法,您應該會注意到高度延遲環境 (如雲端) 中的「相乘」效益。

內部部署資料庫之資料庫互動的一般最佳作法包含下列建議:

  • 晚期開啟連接並盡快關閉連接 - 為了將資源使用量降到最低和節流的可能性降至最低,請只在程式碼需要該連接的時間點,在應用程式中開啟連接。此外,在程式碼完成使用連接之後,透過處置連接物件立即將連接傳回至集區 (這個傳回原則的例外是有較立即的工作要完成時。在此情況下,只有當所有最立即的工作已完成時,才傳回連接)。

  • 運用連接共用 - 在處理層級,連接集區包含針對相同的資料庫和使用相同安全性內容的連接。在可能的情況下,針對擁有相同特性的所有連線使用相同的連接字串。

  • 只擷取您所需的資料 - 請小心地定義 SELECT 清單和 WHERE 子句。此方法可讓您將網路頻寬的使用量降到最低,同時也可讓您有效編制資料庫索引,以提高效能。

  • 讓交易越短越好,而且避免包含不必要的資料 - 不理想的資料模型設計,以及應用程式程式碼與資料庫之間的過度往返是常見問題,但在內部部署中,由於是低度延遲連接環境,可能不重要。由於下列原因,這些應用程式可能也難以修改:

    • 現有的架構限制。

    • 資料存取和商務邏輯緊密連接且彼此相依的僵化設計。

    • 應用程式邏輯本身所需,而且不大幅重寫就難以修改的某些層面,例如逐列資料處理。

除了這些一般最佳作法之外,還有與應用程式中所用技術相關的其他最佳作法。例如,使用 .NET Framework 的應用程式可以使用技術如 ADO.NET、Entity Framework 和 WCF Data Services。這些技術提供減少的開發時間,以及為任何應用程式模式實作資料存取層的較高彈性。這些技術會分離各層、提供結構描述彈性、使用開放式資料架構 (例如,OData),以及本質上提供「中斷連接」的設計,也非常符合服務導向。不過,不論其優點,如果您不考慮到適當的資料設計和作業最佳化 (這包括最佳資料表示、快取使用,以及批次資料相關的作業以減少不必要的往返),這些技術也可能會產生針對舊版應用程式所述的相同問題類型,例如多話。

下列章節描述這些技術的一些最佳作法,以及對 Azure 應用程式使用非同步程式設計的最佳作法。

對於智慧作業 (例如排序、篩選等) 用戶端支援有限的資料存取程式庫,例如 ODBC 和 JDBC,您仍然可以套用現有的最佳化技術,如減少以資料指標為基礎的作業和逐列處理。必須使用資料指標時,使用唯讀、順向資料指標以擷取值,而且使用 SQL 命令進行資料修改,而不要在資料指標中使用定點更新。

對於 ADO.NET,可套用數個最佳化作法,讓您的資料存取程式碼效率最大化:

  • 使用 SqlCommand 選擇適當的執行模式 - 例如,如果您只需要擷取純量值,則使用 ExecuteScalar() 方法,如果不需要擷取結果集,則使用 ExecuteNonQuery()。

  • 使用 SqlDataAdapter 類別執行多個作業時,使用 UpdateBatchSize 屬性 - 這會在網路傳輸時批次處理多個命令,而將網路往返降到最低。

  • 使用 SqlDataAdapter,透過使用 SELECT、INSERT、UPDATE 和 DELETE 作業的預存程序來實作直接資料庫互動。

  • 當您使用資料集做為用戶端快取時,將 SerializationFormat 屬性設定為二進位 - 如此可減少在線上傳送的資料量。

在資料存取開發方面,Entity Framework 引起許多關注,原因如下:

  • 提供豐富的物件關聯式對應環境,可大幅減少開發時間。

  • 透過分離實體資料庫結構描述定義與應用程式資料的概念性表示,導入了更大彈性。

  • 提供一組完整服務來處理保存。

  • 透過將 Microsoft Azure SQL Database 的結果集載入應用程式記憶體中的物件集之能力,減少網路往返,並以中斷連接的方式重複使用,而不需要針對每個作業與後端互動。

不過,如同其他任何程式設計工具,如果您無法特別處理資料庫互動,Entity Framework 可能會產生一些效能問題。此外,Azure 環境放大這些效能問題。

若要最佳化 Entity Framework 搭配 Microsoft Azure SQL Database 使用方式,請遵循下列最佳作法指導方針:

  • 在 ObjectStateManager 層級,針對實體和關聯性明確停用物件狀態追蹤 - 如果由於一般唯讀的使用方式,您的應用程式不需要追蹤物件狀態,請套用這個指導方針。

  • 停用延遲載入以有效控制程式碼和資料庫之間的互動 - 為了減少往返,您可以預先載入單一互動中所需的所有項目。您可以在載入時及在保存資料至資料存放區中時批次處理多個命令,可透過特定方法擴充物件內容進行套用。

  • 在可能的情況下使用預存程序進行資料存放區互動 - 在無法使用預存程序的情況下,使用參數化查詢和索引檢視表來改善效能。

  • 透過整合資料表值參數以及將物件集對應至預存程序的表格式參數,在單次往返中執行多個資料庫作業 - 即使設計工具不直接支援,您也可以使用這種方式。

  • 在可能的情況下,將多個結果集對應至單一作業中的物件。

  • 針對大量資料插入活動,將物件集對應至 System.Data.SqlClient.SqlBulkCopy.WriteToServer() 方法 - SQLBulkCopy 方法允許 SQL Server Database Engine 和 Microsoft Azure SQL Database 使用大量作業記錄最佳化,在許多情況下可更快速地執行大量插入。

如需詳細資訊,請參閱<使用 Entity Framework 降低 Azure SQL Database 網路延遲>。

某些資料庫作業 (例如命令執行) 可能需要花相當多的時間才能完成。在這些情況下,單一執行緒的應用程式必須封鎖其他作業並等候命令完成,才會繼續其他作業。相反地,將長時間執行的作業指定給背景執行緒,允許前景執行緒在整個作業期間保持使用中。

ADO.NET 在它的 SqlCommand 類別中支援這些相同的設計模式。具體而言,分別配對 BeginExecuteNonQuery()、BeginExecuteReader() 和 BeginExecuteXmlReader() 方法以及 EndExecuteNonQuery()、EndExecuteReader() 和 EndExecuteXmlReader() 方法,以提供非同步支援。

這些非同步方法不會讓您免除套用先前各節中所提及的最佳化和最佳作法。不過,透過允許其他作業與 Microsoft Azure SQL Database 查詢平行執行,這些非同步方式有助於減少資料存取層中長時間執行資料庫作業的影響。

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

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