【正文】 于 TPC_C 基準(zhǔn)數(shù)據(jù)庫(kù)設(shè)計(jì) SQL Server 2022 中表的設(shè)計(jì)通過(guò) 節(jié)的介紹，TPC_C 的邏輯結(jié)構(gòu)圖表明了 TPC_C 的總體操作流程，為了實(shí)現(xiàn)這一結(jié)構(gòu)，TPC_C 設(shè)計(jì)了九個(gè)相關(guān)的數(shù)據(jù)表，ER 關(guān)系圖如下：圖 32 TPC_C 基準(zhǔn) ER 圖表框里的數(shù)據(jù)表示該表存放的記錄數(shù)，倉(cāng)庫(kù)數(shù) W 體現(xiàn)了數(shù)據(jù)庫(kù)中的數(shù)據(jù)規(guī)模，表間的數(shù)據(jù)表示各表中記錄條數(shù)的比例關(guān)系，k 表示 1000。要求生成一個(gè)長(zhǎng)度為固定長(zhǎng)度 N、字符為任意字符的文本。 表的結(jié)構(gòu)關(guān)系TPC_C 基準(zhǔn)數(shù)據(jù)庫(kù)的九張表通過(guò)主鍵引用聯(lián)系起來(lái)，各個(gè)表都有各自的用途，且各表之間的結(jié)構(gòu)關(guān)系（主鍵）為：圖 35 各表關(guān)系圖各張表的使用將在事務(wù)的使用中進(jìn)行詳細(xì)介紹。random astring [x .. y] 隨機(jī)產(chǎn)生一個(gè)字符串，其最小長(zhǎng)度為 x，最大長(zhǎng)度為y，平均長(zhǎng)度為(x+y)/2。這個(gè)長(zhǎng)度為4 的字符串通過(guò) 0 到 9999 隨機(jī)數(shù)產(chǎn)生，這就是說(shuō)總共可以產(chǎn)生 10000 個(gè)編碼。其主要內(nèi)容就是模仿在線用戶的訂單請(qǐng)求，用戶輸入一份完整的訂單（這一切在實(shí)現(xiàn)過(guò)程中都是隨機(jī)數(shù)生成） ，提交系統(tǒng)的過(guò)程。這一功能的實(shí)現(xiàn)可以采用隨機(jī)數(shù) 1 到 100 加以實(shí)現(xiàn)。 Totalamount=sum(OL_AMOUNT)*(1C_DISCOUNT)*(1+W_TAX+D_TAX) PAYMENT（支付）事務(wù)的實(shí)現(xiàn)Payment 事務(wù)主要是更新用戶的賬戶并反映出地區(qū)和倉(cāng)庫(kù)的銷售狀況。H_DATE 是當(dāng)前的系統(tǒng)時(shí)間。在 ORDER_T 表里找到匹配的 O_W_ID=W_ID, O_D_ID=D_ID, O_ID=NO_O_ID 的行，返回 O_C_ID，并將對(duì)應(yīng)的顧客號(hào)的 O_CARRIER_ID進(jìn)行更新。 ORDER STATUS（訂單狀況查詢）事務(wù)的實(shí)現(xiàn)該事務(wù)查詢客戶上一次訂單的狀態(tài)，是一個(gè)只讀事務(wù)，執(zhí)行頻率低，對(duì)系統(tǒng)的響應(yīng)時(shí)間要求不是很嚴(yán)格。 測(cè)試方案在本項(xiàng)目的測(cè)試過(guò)程中，一個(gè)完成執(zhí)行的事務(wù)可以被定義為成功提交的事務(wù)。比如 Payment 事務(wù)圖 45 事務(wù)開(kāi)始在事務(wù)結(jié)束時(shí)采用 try ，catch 語(yǔ)句，圖 46 事務(wù)結(jié)束LoadRunner 不支持 Random 隨機(jī)函數(shù)，其隨機(jī)數(shù)的生成有其特有的機(jī)制，其是把某一個(gè)值替代為隨機(jī)數(shù)，方法是選中需要替代的變量值，選擇用變量來(lái)替代：圖 47 隨機(jī)變量修改（a）類型選擇為 Random Number：（b）對(duì)隨機(jī)數(shù)的屬性進(jìn)行編輯，確定好每一個(gè)變量的值范圍和類型。場(chǎng)景設(shè)置一般有兩類：一種是基于用戶實(shí)際使用情況的場(chǎng)景測(cè)試；另一種是為了特殊項(xiàng)目測(cè)試而設(shè)計(jì)的場(chǎng)景。測(cè)試場(chǎng)景設(shè)置（方案一）：采用百分配比的方法，通過(guò)實(shí)際設(shè)置各事務(wù)所占的配比：NEW ORDER %,PAYMENT %, DELIVERY 。對(duì)于本系統(tǒng)的場(chǎng)景設(shè)置，主要是為了驗(yàn)證該系統(tǒng)是否能否滿足用戶的基本需求，屬于驗(yàn)證性場(chǎng)景設(shè)置。在本系統(tǒng)的測(cè)試中，測(cè)試步驟主要為：加載數(shù)據(jù) 載入腳本程序測(cè)試分析結(jié)果數(shù)據(jù)庫(kù)備份恢復(fù)數(shù)據(jù)與基準(zhǔn)是否相符不相符輸出測(cè)試結(jié)果相符圖 48 測(cè)試步驟具體為： 執(zhí)行 Dataload 源程序，項(xiàng) TPC_CWarehouse 加載初始數(shù)據(jù)，因?yàn)檫@個(gè)數(shù)據(jù)量比較大，每次加載都需要 1 個(gè)多小時(shí)才能完成，為了程序執(zhí)行的方便，同時(shí)也使得測(cè)試具有橫向比較性，將數(shù)據(jù)做一個(gè)備份，以備后用。在未錄入 LoadRunner 腳本之前，這五個(gè)事務(wù)構(gòu)成一個(gè)完整的系統(tǒng)，各事務(wù)的選擇采用 CASE 語(yǔ)句實(shí)現(xiàn)，Payment:1，Neworder:2,Delivery :3， Order Status :4，Stock Level :5，用戶可以通過(guò) 1 到 5 選擇需要執(zhí)行的事務(wù)，當(dāng)然每個(gè)事務(wù)執(zhí)行完畢用戶也可通過(guò) Y/N 進(jìn)行選擇是否需要繼續(xù)進(jìn)行別的事務(wù)。事務(wù)具體執(zhí)行步驟：情況一（60%）：用戶是采用 C_LAST，則在 CUSTOMER 表中選擇與（C_W_ID,C_D_ID,C_LAST）相匹配的所有行。CUSTOMER 表里找到符合 C_W_ID=W_ID, C_D_ID=D_ID, C_ID=O_C_ID 的行并將 C_BALANCE 增加 ORDER_LINE 里的 OL_AMOUNT數(shù) STOCK LEVEL（庫(kù)存狀況查詢）事務(wù)實(shí)現(xiàn)該事務(wù)模擬的是用戶從固定的倉(cāng)庫(kù)和地區(qū)中選取最后 20 條記錄，檢查訂單中所有貨物的庫(kù)存，計(jì)算并且把所有庫(kù)存數(shù)低于用戶指定域的商品數(shù)量。 從 DISTRICT 表中選擇出 D_W_ID=W_ID,D_ID 與隨機(jī)生成 D_ID 的相等的項(xiàng)，并返回 D_NAME, D_STREET_1, D_STREET_2, D_CITY, D_STATE,和 D_ZIP，且 D_YTD+=H_AMOUNT. 情況一：當(dāng)顧客的查詢是按 C_ID 是，從 CUSTOMER 表中找到與C_W_ID,C_D_ID,C_ID 相符的項(xiàng)，返回 C_FIRST, C_MIDDLE, C_LAST, C_STREET_1, C_STREET_2, C_CITY, C_STATE, C_ZIP, C_PHONE, C_SINCE, C_CREDIT, C_CREDIT_LIM, C_DISCOUNT, and C_BALANCE，且C_BALANCE+=H_AMOUNT,C_YTD_PAYMENT+=H_AMOUNT, C_PAYMENT_CNT+=1。這個(gè)事務(wù)要求高頻讀寫(xiě)，所以響應(yīng)時(shí)間必須要快才能滿足在線用戶的需求。O_ENTRY_D 是當(dāng)前的系統(tǒng)時(shí)間。tmpC 越大，說(shuō)明系統(tǒng)的性能越好，系統(tǒng)對(duì)用戶的響應(yīng)時(shí)間也就越短。定義完這些重要的數(shù)據(jù)類型，通過(guò)表 對(duì)應(yīng)的各表的數(shù)量關(guān)系，將數(shù)據(jù)庫(kù)進(jìn)行初始化。采用的算法是通過(guò)產(chǎn)生隨機(jī)數(shù)來(lái)的到字符串的長(zhǎng)度 N，然后再隨機(jī)產(chǎn)生長(zhǎng)度為 N 的字符串。對(duì)于國(guó)產(chǎn)數(shù)據(jù)庫(kù)，有一部分廠商提供了比較高效的數(shù)據(jù)加載工具，例如可以將具有一定格式的文本數(shù)據(jù)文件加載到數(shù)據(jù)庫(kù)的表中，但同時(shí)一些廠商沒(méi)有提供或是提供的加載工具效率不高，如果采用這些加載工具就很浪費(fèi)時(shí)間。要求生成一個(gè)日期。還需要注意的是，無(wú)論 Warehouse 表記錄為多少， item 表總數(shù)為 100000 條記錄，并不隨Warehouse 的記錄數(shù)增加而變化。STOCK LEVEL 事務(wù)模擬的是用戶從固定的倉(cāng)庫(kù)和地區(qū)中選取最后 20 條記錄，檢查訂單中所有貨物的庫(kù)存，計(jì)算并且把所有庫(kù)存數(shù)低于用戶指定域的商品數(shù)量。 性價(jià)比(Price/Performance，簡(jiǎn)稱Price/tpmC) 即測(cè)試系統(tǒng)價(jià)格（指在美國(guó)的報(bào)價(jià)）與流量指標(biāo)的比值。d) 每個(gè)客戶平均一個(gè)訂單有10 項(xiàng)產(chǎn)品。 通過(guò)主鍵和外鍵能夠識(shí)別出分配高低優(yōu)先級(jí)數(shù)據(jù)訪問(wèn) 數(shù)據(jù)庫(kù)由一些具有各種大小、屬性和關(guān)聯(lián)的基本表組成TPC_C 基準(zhǔn)的目標(biāo)就是要減少應(yīng)用層面的多變性，而保留一些重要的應(yīng)用特征，也即系統(tǒng)的實(shí)用性和復(fù)雜性。利用虛擬用戶，可以在Windows上同時(shí)產(chǎn)生成千上萬(wàn)個(gè)用戶訪問(wèn)。（五）、TPS (Transactions Per Second)是應(yīng)用系統(tǒng)每秒鐘完成交易的數(shù)量，是估算應(yīng)用系統(tǒng)性能的重要依據(jù)。它介于功能測(cè)試和性能測(cè)試之間，是在功能實(shí)現(xiàn)的基礎(chǔ)上更接近模擬現(xiàn)實(shí)環(huán)境下的測(cè)試。這些需求指標(biāo)一般體現(xiàn)為響應(yīng)時(shí)間、交易容量、并發(fā)容量、資源使用率等。第五章對(duì)全文進(jìn)行總結(jié)和展望，指出項(xiàng)目的不足和改進(jìn)的空間。DataFactory 是數(shù)據(jù)自動(dòng)生成工具，通過(guò)它可以生成任意的結(jié)構(gòu)數(shù)據(jù)庫(kù)，并實(shí)現(xiàn)對(duì)數(shù)據(jù)庫(kù)的填充，可以根據(jù)需要產(chǎn)生大量的數(shù)據(jù)以幫助驗(yàn)證數(shù)據(jù)庫(kù)中的各種功能是否正確。其主要考慮的是內(nèi)容包括數(shù)據(jù)項(xiàng)的修改操作、數(shù)據(jù)項(xiàng)的增加操作、數(shù)據(jù)項(xiàng)的刪除操作、數(shù)據(jù)表空、數(shù)據(jù)表滿、刪除空表中的記錄、數(shù)據(jù)表的并發(fā)操作、針對(duì)存儲(chǔ)過(guò)程的接口測(cè)試、結(jié)合業(yè)務(wù)邏輯做關(guān)聯(lián)表的接口測(cè)試。另一方面，軟件的測(cè)試是貫穿整個(gè)軟件開(kāi)發(fā)的生命周期中，所以軟件的需求設(shè)計(jì)、規(guī)格說(shuō)明書(shū)以及程序等都要包含測(cè)試的相關(guān)內(nèi)容。但是這一項(xiàng)目?jī)H對(duì)數(shù)據(jù)庫(kù)的正確性和可用性進(jìn)行了相關(guān)設(shè)計(jì)和實(shí)現(xiàn)，如果要想形成像 TPC_C 那樣通用的且能對(duì)數(shù)據(jù)庫(kù)的各方面性能都能進(jìn)行測(cè)試的方案，還需要進(jìn)一步的研究?；谇叭说慕?jīng)驗(yàn)，本文具體分析和實(shí)現(xiàn)了基于 TPC_C 基準(zhǔn)的數(shù)據(jù)庫(kù)性能測(cè)試。本 科 生 畢 業(yè) 論 文（設(shè) 計(jì)）中文題目：基于 TPC_C 基準(zhǔn)數(shù)據(jù)庫(kù)系統(tǒng)性能測(cè)試的實(shí)現(xiàn)外文題目：The Implementation of Database System Performance Testing Based on TPC_C Benchmark 基于 TPC_C 基準(zhǔn)數(shù)據(jù)庫(kù)系統(tǒng)性能測(cè)試的實(shí)現(xiàn)摘 要數(shù)據(jù)庫(kù)系統(tǒng)是目前 web 系統(tǒng)普遍使用的系統(tǒng)，當(dāng)前有很多流行的數(shù)據(jù)庫(kù)，比如 DB2,Oracle、SQL 等大型數(shù)據(jù)庫(kù)，數(shù)據(jù)庫(kù)系統(tǒng)的性能決定著系統(tǒng)的總體性能，數(shù)據(jù)庫(kù)的性能如何評(píng)價(jià)，評(píng)價(jià)的指標(biāo)都包含哪些內(nèi)容等問(wèn)題都是對(duì)數(shù)據(jù)庫(kù)進(jìn)行整體評(píng)價(jià)必須做出回答的。目前，有各種各樣的功能強(qiáng)大的數(shù)據(jù)庫(kù)測(cè)試工具，但是能正確的使用工具開(kāi)發(fā)合適的腳本、創(chuàng)建測(cè)試場(chǎng)景和正確的根據(jù)自己需要的測(cè)試參數(shù)選擇合適的測(cè)試工具是需要豐富的經(jīng)驗(yàn)與技巧的。這說(shuō)明，在國(guó)內(nèi)我們也開(kāi)始慢慢尋找出更加符合實(shí)際的標(biāo)準(zhǔn)來(lái)對(duì)數(shù)據(jù)庫(kù)進(jìn)行測(cè)試。所謂的軟件測(cè)試一般看來(lái)就是根據(jù)軟件開(kāi)發(fā)各階段的制約和軟件的內(nèi)部結(jié)構(gòu)，精心設(shè)計(jì)很多的測(cè)試用例，包括一些極端的測(cè)試用例，這些用例的內(nèi)容包括輸入數(shù)據(jù)以及預(yù)期的輸出結(jié)果，應(yīng)用這些測(cè)試用例來(lái)不斷地運(yùn)行程序，發(fā)現(xiàn)其中不符合質(zhì)量的特性要求，亦即軟件的缺陷和錯(cuò)誤。二、集成測(cè)試集成測(cè)試主要是對(duì)接口進(jìn)行的測(cè)試工作。QTP 是一款自動(dòng)測(cè)試工具，其通過(guò)對(duì)對(duì)象的捕捉和識(shí)別，模擬用戶的操作流程，并通過(guò)校驗(yàn)方法或結(jié)合數(shù)據(jù)庫(kù)后臺(tái)的監(jiān)控對(duì)整個(gè)數(shù)據(jù)庫(kù)的數(shù)據(jù)進(jìn)行測(cè)試。第四章提出測(cè)試方案，并對(duì)測(cè)試的結(jié)果進(jìn)行分析，與TPC_C提供的標(biāo)準(zhǔn)進(jìn)行對(duì)比，找出系統(tǒng)的瓶頸。負(fù)載測(cè)試的預(yù)期結(jié)果是用戶的性能需求得到滿足?？煽啃詼y(cè)試可以有效的暴露在實(shí)際使用過(guò)程中影響可靠性要求的缺陷。（四）、同時(shí)在線用戶數(shù)量同時(shí)在想用戶對(duì)本系統(tǒng)來(lái)說(shuō)就是在同一時(shí)刻，執(zhí)行各個(gè)事務(wù)的用戶數(shù)量總和。通過(guò)這個(gè)虛擬用戶產(chǎn)生器，可以虛擬用戶并模擬真實(shí)用戶的業(yè)務(wù)操作行為。它模擬的是被復(fù)雜話了的聯(lián)機(jī)事務(wù)處理應(yīng)用環(huán)境的創(chuàng)建活動(dòng)，其主要是把許多系統(tǒng)組成部件和特定環(huán)境關(guān)聯(lián)起來(lái)實(shí)現(xiàn)的 [1]，這種環(huán)境具有如下的一些表現(xiàn)： 能夠并行執(zhí)行的事務(wù)是有一定復(fù)雜度的 具有可在線處理事務(wù)執(zhí)行的模式 支持多個(gè)線終端活動(dòng) 較好地協(xié)調(diào)系統(tǒng)運(yùn)行和應(yīng)用程序執(zhí)行時(shí)間 通過(guò) ACID 特性保證事務(wù)處理的正確性。c) 每個(gè)銷售點(diǎn)為3000個(gè)客戶提供服務(wù) 。流量指標(biāo)值越大越好。ORDER STATUS 事務(wù)查詢客戶上一次訂單的狀態(tài)，是一個(gè)只讀事務(wù)，執(zhí)行頻率低，對(duì)系統(tǒng)的響應(yīng)時(shí)間要求不是很嚴(yán)格。換句話說(shuō)，給數(shù)據(jù)庫(kù)加載數(shù)據(jù)時(shí)，如果給數(shù)據(jù)表 Warehouse 表裝入 l 條記錄的話，那么District 須裝入 10 條記錄，Customer 須裝入 3000 條記錄，history 須裝入 30000條記錄，Order 須裝入 30000 條記錄，NewOrder 須裝入 9000 條記錄，OrderLine 須裝入 300000 條記錄， Stock 須裝入 100000 條記錄。 and time 型。 TPC_C 基準(zhǔn)數(shù)據(jù)錄入大多數(shù)的數(shù)據(jù)庫(kù)提供有專門的數(shù)據(jù)加載工具，這些加載工具具有快速高效的性能，比如說(shuō) Oracle 的 Sql*Loader，SQL Sever 的 DTS 等工具?？梢允亲帜缸址部梢允菙?shù)字字符串。例如，隨機(jī)字符串 0970，那么郵編碼就是 30，000 位顧客，但編碼只有 10，000 個(gè)，所以平均有三位顧客是使用同一個(gè)郵編。在測(cè)試過(guò)程中，每分鐘生成的訂單數(shù) tmpC 是整個(gè)系統(tǒng)性能的重要參考和評(píng)價(jià)指標(biāo)。即當(dāng) X1 時(shí)，OL_SUPPLY_W_ID=W_ID,而 X=1 時(shí)，OL_SUPPLY_W_ID 是從可用倉(cāng)庫(kù)中隨機(jī)選擇的一個(gè)，而不是 W_ID.OL_QUANTITY 是 1 到 10 的隨機(jī)數(shù)。對(duì)于任意一個(gè)客戶，在固定的倉(cāng)庫(kù)中隨機(jī)選取一個(gè)地區(qū)及其內(nèi)用戶，采用隨機(jī)的金額支付一筆訂單，并作相應(yīng)的歷史記錄，修改用戶的金額。二、事務(wù)實(shí)現(xiàn)具體步驟： 從 WAREHOUSE 表中選出與輸入的 W_ID 相符的項(xiàng)，并返回W_NAME, W_STREET_1, W_STREET_2, W_CITY, W_STATE,和 W_ZIP，并且 W_YTD+=H_AMOUNT。在 ORDER_LINE 里找到所有 OL_W_ID=W_ID, OL_D_ID=D_ID, OL_O_ID=C_OD ，并將 OL_DELIVERY_D 改為當(dāng)前的系統(tǒng)時(shí)間，并將OL_AMOUNT 數(shù)更新。數(shù)據(jù)的輸入要求輸入倉(cāng)庫(kù)編號(hào) W_ID.地區(qū)編號(hào) D_ID 是 1 到 10 的一個(gè)隨機(jī)數(shù)。比如說(shuō) NEW ORDER 新訂單、PAYMENT 支付、ORDER STATUS 訂單查詢、STOCK LEVEL 庫(kù)存查詢等事務(wù)在終端顯示，也可是 DELIVERY 發(fā)貨事務(wù)成功在相應(yīng)的文件中添加了正確的內(nèi)容。如：（c ）接著對(duì)錄入的程序的一些值創(chuàng)建關(guān)聯(lián)，替代掉所有其對(duì)應(yīng)的值，并將未錄入的程序代碼在 LoadRunner 里補(bǔ)充完整，運(yùn)行程序，不斷改正程序里的BUG，直至正確運(yùn)行。第一種是為了驗(yàn)證目的而進(jìn)行，為了滿足顧客的基本需求；第二種是為了測(cè)試系統(tǒng)的擴(kuò)展性、穩(wěn)定