專利名稱：經(jīng)由自適應(yīng)分割來為并發(fā)查詢執(zhí)行分派資源的制作方法
技術(shù)領(lǐng)域：
本申請大體上涉及計算機(jī)和軟件系統(tǒng)。更具體地，本申請涉及并行數(shù)據(jù)庫系統(tǒng)。
背景技術(shù)：
在典型的商業(yè)智能(Bi)環(huán)境中，數(shù)據(jù)庫系統(tǒng)處理具有廣泛復(fù)雜度的大量查詢。查 詢的復(fù)雜度的范圍從訪問數(shù)據(jù)庫表中的少數(shù)幾行的小型查詢、到處理成百萬行的中等查 詢、到處理億萬行的大型查詢。這種類型的并發(fā)混合工作負(fù)荷給BI和企業(yè)數(shù)據(jù)倉庫(EDW) 系統(tǒng)提出了挑戰(zhàn)。這些系統(tǒng)通常包括為處理工作負(fù)荷而協(xié)同工作的大量處理器。


圖1是示出依據(jù)本發(fā)明實施例的系統(tǒng)的各個部件以及請求流序列的示意圖。圖2是依據(jù)本發(fā)明實施例的更詳細(xì)地描繪請求流序列的流程圖。圖3A是依據(jù)本發(fā)明實施例的用于計算查詢所需的估計存儲器資源的過程的流程 圖。圖3B是依據(jù)本發(fā)明實施例的用于計算查詢所需的估計CPU資源的過程的流程圖。圖3C是依據(jù)本發(fā)明實施例的用于計算查詢的最大并行度的過程的流程圖。圖4描繪了針對所有子集大小的示例16個CPU系統(tǒng)的CPU子集并且示出依據(jù)本 發(fā)明實施例的示例親和力(affinity)組。圖5是示出依據(jù)本發(fā)明實施例的放置執(zhí)行服務(wù)器過程(ESP)層的方面和特征的圖
7J\ ο圖6是示出用于在系統(tǒng)中的CPU超集之中選擇CPU子集的兩個分布方案的 圖示。依據(jù)本發(fā)明實施例，第一方案是CPU的鄰接子集而第二方案是CPU的交織排序 (interleaved ordering)0圖7是用于確定親和力組內(nèi)的哪個CPU子集由親和力值與層中的ESP數(shù)量指定的 過程的流程圖。圖8描繪了依據(jù)本發(fā)明實施例示出不用循環(huán)放置和利用循環(huán)放置的ESP層放置的 差別的示例。圖9是描繪可以被配置成執(zhí)行 依據(jù)本發(fā)明實施例的方法的示例計算機(jī)設(shè)備的示 意圖。
具體實施例方式考慮要在具有大量中央處理單元(CPU)的BI或EDW系統(tǒng)上執(zhí)行的查詢。為了使 一個查詢在該系統(tǒng)的所有CPU上運行，往往需要在這些CPU上(即對于每個CPU)重新劃分并且在某些情況下復(fù)制查詢數(shù)據(jù)。根據(jù)查詢的大小和CPU的數(shù)量，這樣的劃分可能造成巨 大的開銷。該開銷有時可能甚至超過BI或EDW系統(tǒng)的大規(guī)模并行性的好處。如此，以全并 行度(即在該系統(tǒng)的所有CPU上)運行所有查詢通常將導(dǎo)致系統(tǒng)資源的低效使用。因此，有益的是具有基于逐個查詢以不同的并行度執(zhí)行不同查詢的能力。例如，小型查詢可以最高效地運行在單個CPU上，而大型查詢可以很好地利用所有系統(tǒng)CPU以便有 效地處理大量數(shù)據(jù)。在那些極端之間，中等大小的查詢可以更高效地運行在系統(tǒng)CPU的子 集上O然而，如申請人所確定的，在系統(tǒng)CPU的子集上運行小型和中等查詢引入其它挑 戰(zhàn)，包括如下挑戰(zhàn)。1)系統(tǒng)需要算出該查詢潛在需要的資源以確保減小并行度不會導(dǎo)致資源不足。2)查詢/工作負(fù)荷需要在系統(tǒng)CPU上均勻平衡以確保查詢執(zhí)行的公平性和系統(tǒng)資 源的高效利用。3)對于查詢的CPU分配需要最小化或限制CPU正在執(zhí)行的查詢的數(shù)量以便最小化 或限制資源競爭和上下文切換。而且，查詢執(zhí)行時間可以顯著不同。因此，即使查詢在系統(tǒng)CPU上的均勻分布也不 保證工作負(fù)荷的平衡分布。照此，申請人認(rèn)為CPU上的良好工作負(fù)荷平衡通常要求來自運 行時系統(tǒng)的反饋以指示哪些CPU相比其它CPU被更少地利用。與把CPU節(jié)點劃分成組的現(xiàn)有解決方案不同，本文所公開的解決方案不依賴于用 戶所建立的劃分方案。本文所公開的解決方案改為基于查詢的相關(guān)屬性來選擇CPU的數(shù) 量，并且其使用自適應(yīng)分割來自動平衡系統(tǒng)上的查詢。為了并行執(zhí)行查詢，數(shù)據(jù)被分布到每個參與CPU，其中將使用執(zhí)行服務(wù)器過程 (ESP)來執(zhí)行查詢的一部分。根據(jù)查詢計劃步驟，可能需要多次把數(shù)據(jù)重新分布到不同的 ESP集以進(jìn)行后續(xù)的執(zhí)行步驟。(對數(shù)據(jù)的不同部分)執(zhí)行查詢的相同任務(wù)的每組ESP被 稱作ESP層。根據(jù)執(zhí)行步驟，查詢可以具有一個或多個ESP層。在查詢的ESP層中的任一 ESP層中的ESP的最大數(shù)量確定該查詢所需的CPU的總數(shù)，我們將其稱為并行度。圖1是示出依據(jù)本發(fā)明實施例的系統(tǒng)的各個部件以及請求流序列的示意圖。如所 示，圖1的系統(tǒng)包括ODBC/JDBC (開放式數(shù)據(jù)庫連接或Java數(shù)據(jù)庫連接)客戶端102，該客 戶端102可以包括應(yīng)用程序104和驅(qū)動程序106。當(dāng)然，該系統(tǒng)可以包括一個以上這樣的客 戶端102。該系統(tǒng)還包括企業(yè)數(shù)據(jù)倉庫(EDW)服務(wù)器112和工作負(fù)荷管理服務(wù)(WMS)系統(tǒng) 122。WMS在本發(fā)明的這個實施例中的作用是收集來自運行時系統(tǒng)的反饋以及基于這個反饋 來生成親和力值。例如下面關(guān)于圖4進(jìn)一步描述親和力值。本發(fā)明的其它實施例可以具有 生成親和力值的替換方法。這些可以是在EDW服務(wù)器的外部或內(nèi)部。例如，EDW服務(wù)器可 以使用隨機(jī)數(shù)發(fā)生器來生成親和力值，或者EDW服務(wù)器可以基于查詢源生成親和力值。由 這些系統(tǒng)部件進(jìn)行的和這些系統(tǒng)部件之間的請求流序列由箭頭示出并且以從1到11的順 序進(jìn)行編號。圖2是依據(jù)本發(fā)明實施例的更詳細(xì)地描繪請求流序列的流程圖。如所示，第一方 框1涉及應(yīng)用程序104準(zhǔn)備數(shù)據(jù)庫查詢以及把該查詢發(fā)送到EDW服務(wù)器112。依據(jù)本發(fā)明的實施例，EDff服務(wù)器112可以使用查詢優(yōu)化器模塊來確定該查詢的 最大并行度(MDOP)。查詢優(yōu)化器通?？梢钥紤]從一個CPU至高達(dá)系統(tǒng)中的CPU總數(shù)目的任一并行度。在具有適度數(shù)量的并發(fā)查詢的環(huán)境中，可以通過安全地減小大多數(shù)查詢的并行 度來實現(xiàn)較好的資源利用。這可以通過逐個查詢地確定MDOP來完成。查詢優(yōu)化器可以被 配置成僅考慮具有不超過為該查詢所計算的MDOP的并行度的查詢計劃。下面關(guān)于圖3A-3C 描述一種用于確定查詢的MDOP的技術(shù)。在第二方框2中，EDW服務(wù)器112請求由其查詢編譯器準(zhǔn)備該查詢。在第三方框3中，查詢編譯器返回編譯的查詢。此時，所編譯的查詢在指定每個 ESP層處的ESP數(shù)量的同時不受限于任何特定的CPU子集。此后，EDW服務(wù)器112按照方框 4給應(yīng)用程序104返回“成功”指示或通知。按照方框5，應(yīng)用程序104然后請求執(zhí)行該查詢，并且在接收到該請求后，按照方 框6，服務(wù)器112向WMS 122發(fā)送對容許執(zhí)行該查詢的請求。在適當(dāng)時，按照方框7，WMS 122 允許服務(wù)器112執(zhí)行該查詢。依據(jù)本發(fā)明的實施例，WMS 122基于當(dāng)前運行時狀態(tài)確定親和力值并且按照方框 7給EDW服務(wù)器112返回親和力值。親和力值指定要用于放置執(zhí)行服務(wù)器過程(ESP)的CPU 子集(自適應(yīng)分割)的選擇并且可以被有利地用來實現(xiàn)負(fù)荷平衡。WMS可以獲得關(guān)于系統(tǒng) 的當(dāng)前狀態(tài)的某些全局信息，其可以用于確定親和力值。這通過圖1中WMS系統(tǒng)訪問系統(tǒng) 信息(System Info)和運行時系統(tǒng)(RTS)而示出。這個全局信息包括分配給當(dāng)前正在執(zhí)行 的查詢的親和力值的集合。下面例如關(guān)于圖4進(jìn)一步描述親和力值。按照方框8，服務(wù)器112請求由執(zhí)行器(EXE)執(zhí)行該查詢。在該請求中包括供執(zhí)行 器(EXE)使用的親和力值。執(zhí)行器使用親和力值把ESP放置到CPU上。下面關(guān)于圖5到8 進(jìn)一步描述本文所公開的用于使用親和力值把ESP放置到CPU上的技術(shù)。按照方框9，執(zhí)行器(EXE)基于親和力值把編譯的查詢放置到CPU上，執(zhí)行查詢并 且返回結(jié)果。此后，服務(wù)器112按照方框10向WMS請求釋放親和力值，并且按照方框11還 把結(jié)果返回給應(yīng)用程序104。圖3A是依據(jù)本發(fā)明實施例的用于計算查詢所需的估計存儲器資源的過程300的 流程圖。首先，構(gòu)造301初始查詢計劃。這個步驟在優(yōu)化的早期階段提供良好的總查詢計 劃。優(yōu)選地基于使訪問查詢中的最大表的成本最小化并且使遍及連接樹的記錄過程數(shù)量最 小化來構(gòu)造初始查詢計劃。注意，此時查詢計劃是邏輯算子樹。一旦形成了初始查詢計劃， 通過訪問302每個樹節(jié)點、計算304與該樹節(jié)點對應(yīng)的邏輯算子的潛在存儲器消耗以及累 計306節(jié)點的潛在存儲器消耗，來遍歷該查詢計劃。一旦遍歷了 308整個查詢計劃樹，則潛 在存儲器消耗的累計總和可以被輸出310為查詢計劃所需的估計存儲器資源(EMR)。類似地，圖3B是依據(jù)本發(fā)明實施例的用于計算查詢所需的估計CPU資源的過程的 流程圖。再次，一旦形成了 321初始查詢計劃，通過訪問322每個樹節(jié)點、計算324與該樹 節(jié)點對應(yīng)的邏輯算子的估計工作以及累計326節(jié)點的估計工作，來遍歷該查詢計劃。一旦 遍歷了 328整個查詢計劃樹，則估計工作的累計總和可以被輸出330為查詢計劃所需的估 計CPU資源(ECR)。圖3C是依據(jù)本發(fā)明實施例的用于計算查詢的最 大并行度的過程的流程圖。如上 面關(guān)于圖3A和3B所描述的，計算300查詢所需的EMR，并且計算320查詢所需的ECR。然后將EMR除以350常數(shù)Memory_Unit (存儲器單元)，該Memory_Unit表示對于 任何查詢而言每個CPU可用的存儲器量。這確保了并行度不限于由于在執(zhí)行查詢的CPU上缺乏可用存儲器而使得該查詢執(zhí)行將遭受的程度。類似地，將ECR除以352常數(shù)Work_ Unit (工作單元)，該Work_Unit表示對于任何不以全系統(tǒng)并行性運行的查詢而言可接受的 每個CPU所分配的工作量。這確保了處理大量數(shù)據(jù)的查詢將以足夠的并行度運行。然后選擇354EMR/Memory_Unit和ECR/Work_Unit的最大值并且將該值調(diào)高到最 近的2MX自適應(yīng)段塊大小(ASBS)，直到系統(tǒng)中的CPU總數(shù)(其中M = 0、1、2、3· · ·)。ASBS 的值表示可以被分配給單個查詢的最小CPU數(shù)量。這是系統(tǒng)配置并且可以被設(shè)定為低至1 個CPU。調(diào)高的值然后被輸出為最大并行度(MDOP)。這個過程導(dǎo)致使用各種并行度來優(yōu)化 不同的查詢，所述各種并行度的范圍從針對小型查詢的最小ASBS、到針對中等大小查詢的 2M倍的ASBS、到針對很大型查詢的系統(tǒng)中CPU的總數(shù)。
圖4描繪了針對所有子集大小404的示例16個CPU系統(tǒng)的CPU子集402并且示 出依據(jù)本發(fā)明實施例的示例親和力組。如每行中所示，CPU以交織次序{0，8，4，12，2，10，6， 14,1,9,5,13,3,11,7,15}進(jìn)行編號。雖然為討論相對簡單起見這個示例并行計算系統(tǒng)具有 16個CPU，但是本申請考慮了實際的并行計算系統(tǒng)可以具有多得多的CPU，例如128個CPU、 或256個CPU、或512個CPU等等。CPU子集大小為16的第一(頂)行由具有所有16個CPU的單個CPU子集402組 成。CPU子集大小為8的第二行由兩個CPU子集402組成，每個CPU子集402具有8個CPU。 第一子集具有偶數(shù)編號的CPU，而第二子集具有奇數(shù)編號的CPU。類似地，CPU子集大小為4 的第三行由四個CPU子集402組成，每個CPU子集402具有4個CPU ；CPU子集大小為2的 第四行由八個CPU子集402組成，每個CPU子集402具有2個CPU，而CPU子集大小為1的 第五行由十六個CPU子集402組成，每個CPU子集402具有單個CPU。在這個示例中，示出由親和力值=5指定的CPU子集。灰色陰影的CPU子集是那 些由親和力值=5指定的CPU子集。如所示，親和力值指定每個子集大小404的一個CPU子集402 (即，每行中的一個 子集)。由于親和力值是5，每個指定子集包括CPU號碼5。因此，為CPU子集大小1(底行) 指定(灰色陰影)CPU子集{5}，為CPU子集大小2指定CPU子集{5，13}，為CPU子集大小4 指定CPU子集{1，9，5，13}，為CPU子集大小8指定CPU子集{1，9，5，13，3，11，7，15}，并且 為 CPU 子集大小 16 指定 CPU 子集{0,8,4,12, 2,10,6,14,1,9, 5,13, 3,11, 7,15} ο 由給定的 親和力值定義的CPU子集的集合被稱作親和力組。圖5是示出依據(jù)本發(fā)明實施例的放置執(zhí)行服務(wù)器過程(ESP)層的方面和特征的圖 示。每個查詢可以具有一個或多個需要被放置到CPU上以在其上執(zhí)行的執(zhí)行服務(wù)器過程 (ESP)層，并且每個ESP層可以具有一個或多個ESP。首先，將給定的ESP層中的ESP分布在整個系統(tǒng)上。該分布可以通過對CPU子集 使用CPU的交織排序來實現(xiàn)。在圖6中通過示例圖解了通過交織排序所實現(xiàn)的分布，這在 下面進(jìn)行進(jìn)一步的描述。其次，基于由麗S或者某個其它用于生成親和力值的部件所返回的親和力值，將 每個ESP層放置在2n個不同的CPU子集之一上。下面關(guān)于圖7進(jìn)一步描述該第一方面的 一種實施方式。最后，在第三任選的方面，可以基于不同的親和力值來放置查詢的每個ESP層。下 面關(guān)于圖8進(jìn)一步描述該第三方面的一種實施方式。
圖6是圖解依據(jù)本發(fā)明實施例的用于使用CPU的鄰接排序和交織排序來選擇CPU 子集以進(jìn)行ESP分配的兩個分布方案的圖示。頂圖示出其中ESP層的ESP被放置在CPU的 鄰接集上的示例。相比而言，底圖示出其中ESP層的ESP被放置在CPU的交織集上的示例。交織排序方案在整個本文件中將被用作本發(fā)明的優(yōu)選實施例。 圖7是用于確定親和力組內(nèi)的哪個CPU子集由親和力值指定的過程的流程圖。按 照方框702，進(jìn)行關(guān)于要在每個放置之間跳過(skip)的CPU數(shù)量的計算。該數(shù)字skip等于 系統(tǒng)中的CPU數(shù)量除以給定的ESP層中的ESP數(shù)量。在一個實施方式中，這一除法的結(jié)果 必須是大于或等于一的整數(shù)。按照方框704，確定用于開始放置的偏移。這個偏移值等于親和力值模(％ )skip 數(shù)字。這個模操作的結(jié)果是零和(skip-Ι)之間的數(shù)字。按照方框706，要使用的CPU的子集由i乘以skip數(shù)字加上偏移值給出，其中i從 0變化到ESP層中的ESP數(shù)量減1。圖8描繪依據(jù)本發(fā)明實施例示出不用循環(huán)放置和利用循環(huán)放置的ESP層放置的 差別的示例?？紤]如下示例系統(tǒng)具有16個CPU，查詢具有三個ESP層，每個ESP層有四個 ESP。此外，考慮親和力值是數(shù)字6。在不啟用循環(huán)放置選項的情況下，則ESP層的放置將是依據(jù)A)，其中查詢的所有 ESP層基于單個親和力值(在這種情況下，親和力數(shù)字6)放置。因此，所有四個ESP層將被 放置在CPU子集{2，6，10，14}上。因此，在這個示例中，在非循環(huán)放置的情況下僅使用四分 之一的CPU。另一方面，在啟用循環(huán)放置選項的情況下，則ESP層的放置將是依據(jù)B)，其中根據(jù) 親和力數(shù)字6來放置第一 ESP層。然而，對于第二 ESP層的放置，親和力數(shù)字從6遞增一到 7，而對于第三ESP層的放置，親和力數(shù)字進(jìn)一步從7遞增一到8。因而，在第一 ESP層被放 置在CPU子集{2，6，10，14}上時，第二 ESP層被放置在CPU子集{3，7，11，15}上并且第三 ESP層被放置在CPU子集{0，4，8，12}上。因此，在這個示例中，在循環(huán)放置的情況下使用四 分之三的CPU。有利地，這一循環(huán)放置提供更好的負(fù)荷平衡。圖9是描繪可以被配置成執(zhí)行依據(jù)本發(fā)明實施例的方法的示例計算機(jī)設(shè)備的示 意圖。在這個示例中，該計算機(jī)設(shè)備包括大規(guī)模并行處理系統(tǒng)。在一個實施例中，該計算機(jī) 設(shè)備可以被配置成具有多個節(jié)點906，每個節(jié)點包括處理器902和相關(guān)存儲器904。這些節(jié) 點由互連網(wǎng)絡(luò)908進(jìn)行互連?？梢栽诳商鎿Q實施例中使用計算機(jī)設(shè)備的其它體系結(jié)構(gòu)。依據(jù)本發(fā)明的實施例，上面所討論的步驟被實施為存儲在計算機(jī)可讀介質(zhì)上的或 者存儲在計算機(jī)可讀存儲器中的處理器可執(zhí)行指令。例如，這些處理器可執(zhí)行指令可以例 如在比如圖9所描繪的計算機(jī)設(shè)備上運行。在上面的描述中，給出了許多特定細(xì)節(jié)以提供對本發(fā)明實施例的完全理解。然而， 上面對所圖解的本發(fā)明實施例的描述不打算是窮舉的或者將本發(fā)明限制成所公開的確切 形式。相關(guān)領(lǐng)域的技術(shù)人員將會認(rèn)識到可以沒有一個或多個特定細(xì)節(jié)或者利用其他方法、 部件等等來實踐本發(fā)明。在其他情況中，為了避免模糊本發(fā)明的各方面，沒有詳細(xì)描述或示 出公知的結(jié)構(gòu)或操作。盡管為了說明的目的而在本文中描述了本發(fā)明的特定實施例和本發(fā) 明的示例，但是如相關(guān)領(lǐng)域技術(shù)人員將會認(rèn)識到的那樣，在本發(fā)明的范圍內(nèi)各種等同的修 改是可能的。
鑒于上面的詳細(xì)描述可以對本發(fā)明做出這些修改。在所附權(quán)利要求書中所使用的術(shù)語不應(yīng)該被解釋為將本發(fā)明限制成在說明書和權(quán)利要求書中所公開的特定實施例。相 反，本發(fā)明的范圍由所附權(quán)利要求書確定，其中依據(jù)所建立的權(quán)利要求闡釋原則來解釋本 發(fā)明的范圍。
權(quán)利要求
一種為處理數(shù)據(jù)庫查詢而分派高度并行計算系統(tǒng)的資源的自動化方法，該方法包括接收來自客戶端系統(tǒng)處的應(yīng)用程序的數(shù)據(jù)庫查詢；編譯該查詢并且計算該查詢的每個執(zhí)行服務(wù)器過程ESP層中的ESP數(shù)量；生成親和力值；執(zhí)行該查詢，其中使用該親和力值來確定該查詢的ESP層到所述計算系統(tǒng)的處理器上的放置；以及將執(zhí)行的結(jié)果返回給該應(yīng)用程序。
2.權(quán)利要求1的方法，還包括計算查詢的最大并行度。
3.權(quán)利要求2的方法，其中所述計算最大并行度包括計算該查詢所需的估計存儲器資 源和該查詢所需的估計CPU資源。
4.權(quán)利要求1的方法，其中處理器的交織排序用于形成CPU子集。
5.權(quán)利要求1的方法，其中該親和力值為一系列處理器子集大小指定處理器的子集。
6.權(quán)利要求5的方法，其中由親和力值指定的處理器的子集由變量乘以跳過值加上偏 移值給出，其中該變量從零變化到ESP層中的執(zhí)行服務(wù)器過程的數(shù)量減一。
7.權(quán)利要求1的方法，其中在將ESP層放置到CPU子集上時使用循環(huán)放置。
8.權(quán)利要求1的方法，其中該親和力值基于該系統(tǒng)的當(dāng)前運行時狀態(tài)。
9.權(quán)利要求1的方法，其中該親和力值是隨機(jī)生成的。
10.權(quán)利要求1的方法，其中該親和力值基于查詢源。
11.一種用于企業(yè)數(shù)據(jù)倉庫系統(tǒng)或商業(yè)智能系統(tǒng)的高度并行計算設(shè)備，該設(shè)備包括 所述高度并行計算設(shè)備中的多個處理器；所述高度并行計算設(shè)備中的存儲器資源；數(shù)據(jù)庫服務(wù)器，被配置成接收來自數(shù)據(jù)庫客戶端系統(tǒng)處的應(yīng)用程序的數(shù)據(jù)庫查詢； 查詢編譯器，被配置成準(zhǔn)備該查詢的執(zhí)行計劃并且計算該查詢的每個執(zhí)行服務(wù)器過程 ESP層中的ESP數(shù)量；工作負(fù)荷管理系統(tǒng)，被配置成基于所述設(shè)備的當(dāng)前運行時狀態(tài)來生成親和力值；以及 查詢執(zhí)行器，被配置成執(zhí)行該查詢，其中使用該親和力值來確定該查詢的ESP層到所 述計算系統(tǒng)的處理器上的放置。
12.權(quán)利要求11的設(shè)備，還包括被配置成計算查詢的最大并行度的查詢優(yōu)化器模塊。
13.權(quán)利要求12的設(shè)備，其中所述計算最大并行度包括計算該查詢所需的估計存儲器 資源和該查詢所需的估計處理器資源。
14.權(quán)利要求11的設(shè)備，其中處理器的交織排序用于形成處理器子集。
15.權(quán)利要求11的設(shè)備，其中該親和力值為一系列處理器子集大小指定處理器的子集。
全文摘要
具有多個處理器和存儲器資源的企業(yè)數(shù)據(jù)倉庫或商業(yè)智能系統(tǒng)。該系統(tǒng)至少包括數(shù)據(jù)庫服務(wù)器(112)、工作負(fù)荷管理系統(tǒng)(122)、查詢編譯器和查詢執(zhí)行器。數(shù)據(jù)庫服務(wù)器(112)被配置成接收來自數(shù)據(jù)庫客戶端系統(tǒng)(102)處的應(yīng)用程序(104)的數(shù)據(jù)庫查詢。查詢編譯器被配置成準(zhǔn)備該查詢的執(zhí)行計劃并且計算該查詢的每個執(zhí)行服務(wù)器過程(ESP)層中的ESP數(shù)量。工作負(fù)荷管理系統(tǒng)(122)被配置成生成親和力值，并且查詢執(zhí)行器被配置成執(zhí)行該查詢。如本文所公開的，使用該親和力值來確定該查詢的執(zhí)行服務(wù)器過程層到計算系統(tǒng)的處理器上的放置。還公開了其他實施例、方面和特征。
文檔編號G06F17/00GK101868792SQ200880117052
公開日2010年10月20日 申請日期2008年11月13日 優(yōu)先權(quán)日2007年11月21日
發(fā)明者A·K·阿爾-奧馬里, H·策勒, K·A·西迪奎, P·弗里登巴赫, R·M·維爾梅斯特, S·卡卡拉穆迪, Z·奧曼斯基 申請人:惠普開發(fā)有限公司