本申請涉及計算機領域，尤其涉及一種建立模型數據庫的方法以及客戶端。
背景技術：
：：數據庫(database)是按照數據結構來組織、存儲和管理數據的倉庫，它產生于距今六十多年前，隨著信息技術和市場的發展，特別是二十世紀九十年代以后，數據管理不再僅僅是存儲和管理數據，而轉變成用戶所需要的各種數據管理的方式。數據模型是數據庫的核心，當前廣泛使用的是關系數據庫管理系統(relationaldatabasemanagementsystem，rdbms)，比較知名的如oracle、db2、sqlserver、sybase等。在機構、企業中，數據庫系統一般存放著重要的業務數據，用于支撐日常運營業務，提供經營報表，決策服務等。像企業資源計劃系統(enterpriseresourceplanning，erp)、客戶關系管理系統(customerrelationshipmanagement，crm)、網上商城等交易型系統在業務高峰期出現許多用戶同時并發訪問系統、且要求系統能快速返回查詢或操作結果；在海關風險分析、財務系統中，決策者希望盡快拿到分析報告以對后續商業行為做決策。這些都要求運行在信息技術(informationtechnology，it)硬件架構之上的數據庫系統性能能夠滿足業務需求。因此，在購買it設備或者業務上線之前進行真實業務負載的性能測試就顯得非常重要。隨著科學技術的不斷發展，不同行業企業的業務系統也越來越多。業務系統的性能受組成系統的每一個組件性能的影響。不同數據庫類型、數據庫版本、操作系統類型、操作系統版本、服務器型號及配置、存儲網絡、存儲系統都可能導致整個系統性能出現差異。盡管業界提出了一些代表常規數據庫業務類型的tpc-c、tpc-h測試工具，但這些測試工具是建立在預定義的模型基礎上實現的。這些測試工具能夠反映數據庫系統的基本運作流程和反映系統大致的性能表現情況。但真實性還比較欠缺，當前能夠比較真實反映數據庫操作的數據庫測試工具都需要搭建真實的數據庫環境來進行測試，這種測試對測試人員技能要求高、測試周期較長。技術實現要素：本申請實施例提供了一種建立模型數據庫的方法以及客戶端，用于客戶端根據實際的生產環境中關于存儲的i/o特征和i/o負載，以及所述生產環境中目標數據庫的配置參數得到模型數據庫的配置文件，再根據模型數據庫對目標數據庫進行性能測試，得到準確性比較高的測試報告。本申請實施例第一方面提供了一種建立模型數據庫的方法，可以包括：客戶端可以通過ge網絡或者fc網絡與生產環境中的存儲系統相連，客戶端的i/o跟蹤工具獲取生產環境中關于存儲的i/o特征和i/o負載，以及該生產環境中目標數據庫的配置參數；對該i/o特征和該i/o負載進行分析，確定分析報告；根據該分析報告和該目標數據庫的配置參數，確定模型數據庫的配置文件。需要說明的是，生產環境包括存儲系統和目標數據庫，客戶端的i/o跟蹤工具獲取的是關于存儲系統的i/o特征和i/o負載。在本申請實施例中，客戶端可以通過i/o跟蹤工具，獲取關于存儲系統的i/o特征和i/o負載，以及獲取該生產環境中目標數據庫的配置參數；再對i/o特征和i/o負載進行分析，確定分析報告；最后根據該分析報告和該目標數據庫的配置參數，建立模型數據庫。這里的模型數據庫是根據實際生產環境的相關數據確定的，所以，再根據這個模型數據庫對目標數據庫進行測試的時候，得到的測試報告的真實性就比較高。可選的，在本申請的一些可能的實現方式中，該生產環境中關于存儲的i/o特征和i/o負載，可以包括：獲取生產環境中在預置時長內，關于存儲的各個邏輯單元號lun的i/o特征和i/o負載；需要說明的是，這里的預置時長是可以體現生產環境的當前屬性，不能太少，太少的話，作為參考依據就不夠準確，生產環境的當前屬性可以是高負載的工作環境，中負載的工作環境，或者，低負載的工作環境。該對該i/o特征和該i/o負載進行分析，確定分析報告之前，該方法還可以包括：獲取該生產環境中關于存儲的每個邏輯單元號標識lunid和每個lun的大小。應理解，上述的存儲系統中的存儲空間是以lun體現的，所以，這里獲取每個lun的標識和大小，用來對應的模擬模型數據庫。在本申請實施例中，對客戶端獲取生產環境中關于存儲的i/o特征和i/o負載作了一個細化，是獲取生產環境在預置市場內，關于存儲的i/o特征和i/o負載，因為這個預置時長是具有代表性的一段時長，時間太少，得到的數據可靠性有待商榷，時間太長，工作量比較大。所以，這里的預置時長是根據生產環境的實際情況得到的。該對該i/o特征和該i/o負載進行分析，確定分析報告之前，該方法還可以包括：獲取該生產環境中關于存儲的每個邏輯單元號標識lunid和每個lun的大小，用于進行模型數據庫的模擬。可選的，在本申請的一些可能的實現方式中，該i/o特征包括i/o大小、偏移量和時間戳，該i/o負載包括讀i/o次數和寫i/o次數；該對該i/o特征和該i/o負載進行分析，確定分析報告，可以包括但不限于以下幾種分析方式：(1)根據時間戳、讀i/o次數、寫i/o次數和每個lunid，確定每個lun的讀百分比(lun的讀i/o次數/lun的i/o總數)、寫百分比(lun的寫i/o次數/lun的i/o總數)、負載百分比(lun的i/o總數/所有lun的i/o總數)、讀負載百分比(lun的讀i/o總數/所有lun的讀i/o總數)和寫負載百分比(lun的寫i/o總數/所有lun的寫i/o總數)；(2)根據預先確定的i/o大小的類別、時間戳、讀i/o次數、寫i/o次數和每個lunid，確定每個lun中每種i/o大小的負載百分比(lun在每種i/o大小時的i/o次數/lun的i/o總數)、讀負載百分比(lun在每種i/o大小時的讀次數/lun的讀i/o總數)和寫負載百分比(lun在每種i/o大小時的寫次數/lun的寫i/o總數)；(3)根據偏移量、每個lunid和每個lun的大小，確定每個lun的lba地址；將預置時長均分為n等份，將每個lun的lba地址均分為m等份，n和m為正整數；根據預先確定的i/o大小的類別、時間戳、讀i/o次數、寫i/o次數和每個lunid，確定每個lun中每種i/o大小在每個1/n時間單元內的讀負載百分比(在每種i/o大小中某時間單元內的讀i/o總數/lun的讀i/o總數)和寫負載百分比(在每種i/o大小中某時間單元內的寫i/o總數/lun的寫i/o總數)，以及每個lun中每種i/o大小在每個1/m地址單元內的讀負載百分比(在每種i/o大小中某lba地址單元內的讀i/o總數/lun的讀i/o總數)和寫負載百分比(在每種i/o大小中某lba地址單元內的讀i/o總數/lun的讀i/o總數)。在本申請實施例中，提供的是幾種根據i/o特征和i/o負載進行分析，確定分析報告的具體實現過程，增加了方案的可行性，對分析報告有了具體的了解。可選的，在本申請的一些可能的實現方式中，該方法還可以包括：若該分析報告的配置文件格式與該模型數據庫的目標文件格式不同，則將該分析報告的配置文件格式轉換為該目標文件格式；還可以是，若該分析報告和生產環境中目標數據庫的配置參數的配置文件格式與該模型數據庫的目標文件格式不同，則將該分析報告和生產環境中目標數據庫的配置參數的配置文件格式轉換為該目標文件格式。在本申請實施例中，若客戶端確定的分析報告的配置文件格式與該模型數據庫的目標文件格式不同，則將該分析報告的配置文件格式轉換為該目標文件格式。那么，該模型數據庫就可以根據對應的目標文件格式，對生產環境的目標數據庫進行性能測試了。可選的，在本申請的一些可能的實現方式中，該方法還可以包括：根據該模型數據庫對該目標數據庫進行性能測試，得到測試結果；根據該測試結果，生成測試報告。在本申請實施例中，客戶端可以根據建立的模型數據庫，對目標數據庫進行性能測試了，因為該模型數據庫是根據實際的生產環境的相關數據建立的，所以，根據該模型數據庫對目標數據庫進行性能測試，得到的測試報告就接近于目標數據庫的真實性了，這樣的測試報告對于用戶來說，更有參考價值。可選的，在本申請的一些可能的實現方式中，根據該模型數據庫對目標數據庫進行性能測試之后，該方法還可以包括：獲取日志段編號lsn日志文件；根據該lsn日志文件，對該目標數據庫中的數據進行一致性檢查。在本申請實施例中，在對目標數據庫的測試過程中，還會生成lsn日志文件，根據該lsn日志文件，對該目標數據庫中的數據進行一致性檢查。使得本申請技術方案更加完整。本申請實施例第二方面提供一種客戶端，具有實現對應于上述第一方面提供的客戶端根據實際的生產環境中關于存儲的i/o特征和i/o負載，以及該生產環境中目標數據庫的配置參數，得到模型數據庫的功能。該功能可以通過硬件實現，也可以通過硬件執行相應的軟件實現。該硬件或軟件包括一個或多個與上述功能相對應的模塊。本申請實施例第三方面提供一種發送設備，可以包括：收發器，處理器，存儲器和總線，該收發器、該處理器和該存儲器通過該總線連接；該存儲器，用于存儲操作指令；該收發器，用于獲取生產環境中關于存儲的i/o特征和i/o負載，以及該生產環境中目標數據庫的配置參數；該處理器，用于對該i/o特征和該i/o負載進行分析，確定分析報告；根據該分析報告和該目標數據庫的配置參數，確定模型數據庫的配置文件。本發明實施例第四方面提供一種存儲介質，需要說明的是，本發的技術方案本質上或者說對現有技術做出貢獻的部分或者該技術方案的全部或部分可以以軟件產口的形式體現出來，該計算機軟件產品存儲在一個存儲介質中，用于儲存為上述設備所用的計算機軟件指令，其包含用于執行上述第一方面、第二方面、第三方面或第四方面為客戶端所設計的程序。該存儲介質包括：u盤、移動硬盤、只讀存儲器(rom，read-onlymemory)、隨機存取存儲器(ram，randomaccessmemory)、磁碟或者光盤等各種可以存儲程序代碼的介質。本發明實施例第五方面提供一種包含指令的計算機程序產品，當其在計算機上運行時，使得計算機執行如本申請第一方面或第一方面任一可選實現方式中該的方法。從以上技術方案可以看出，本申請實施例具有以下優點：在本申請實施例中，獲取生產環境中關于存儲的i/o特征和i/o負載，以及該生產環境中目標數據庫的配置參數；對該i/o特征和該i/o負載進行分析，確定分析報告；根據該分析報告和該目標數據庫的配置參數，確定模型數據庫的配置文件。那么，客戶端就可以根據模型數據庫對目標數據庫進行性能測試了，因為該模型數據庫的配置文件是根據實際的生產環境中關于存儲的i/o特征和i/o負載，以及該生產環境中目標數據庫的配置參數得到的，所以，相對于現有的通用型模型數據庫來說，進行性能測試確定的測試報告的準確性更高，接近于目標數據庫的實際性能。附圖說明為了更清楚地說明本申請實施例技術方案，下面將對實施例和現有技術描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本申請的一些實施例，還可以根據這些附圖獲得其它的附圖。圖1為本申請實施例中現有數據庫業務系統的一個結構框架圖；圖2為本申請實施例中db2系統架構的一個示意圖；圖3為本申請實施例中所應用的一個流程圖；圖4為本申請實施例中建立模型數據庫的方法的一個實施例示意圖；圖5為本申請實施例中提出的模型數據庫的架構示意圖；圖6為本申請實施例中模型數據庫支持不共享存儲的集群數據庫的一個示意圖；圖7為本申請實施例中模型數據庫支持共享存儲的集群數據庫的一個示意圖；圖8為本申請實施例中關于表空間和表的一個示意圖；圖9為本申請實施例中關于區域的一個示意圖；圖10為本申請實施例中一致性檢查的示意圖；圖11為本申請實施例中生產環境為db2v95的數據庫生產環境示意圖；圖12為本申請實施例中跟蹤工具跟蹤存儲系統的一個示意圖；圖13為本申請實施例中客戶端的一個實施例示意圖；圖14為本申請實施例中客戶端的另一個實施例示意圖；圖15為本申請實施例中客戶端的另一個實施例示意圖；圖16為本申請實施例中客戶端的另一個實施例示意圖；圖17為本申請實施例中客戶端的另一個實施例示意圖。具體實施方式本申請實施例提供了一種建立模型數據庫的方法以及客戶端，用于客戶端根據實際的生產環境中關于存儲的i/o特征和i/o負載，以及所述生產環境中目標數據庫的配置參數得到模型數據庫的配置文件，再根據模型數據庫對目標數據庫進行性能測試，得到準確性比較高的測試報告。為了使本
技術領域：
：的人員更好地理解本申請方案，下面將結合本申請實施例中的附圖，對本申請實施例中的技術方案進行描述，顯然，所描述的實施例僅僅是本申請一部分的實施例，而不是全部的實施例。基于本申請中的實施例，都應當屬于本申請保護的范圍。數據庫業務系統是一個硬件和軟件的集合，主要包含it基礎架構和數據庫軟件。如圖1所示，為數據庫業務系統的一個結構框架圖，由這些部件一起協同工作，提供連續的數據服務。通常rdbms的系統架構基本元素基本一致，有實例、數據庫的概念。實例是進程或線程加上內存的集合。數據庫是存放在磁盤上用于存放數據的文件的集合。數據庫的文件有控制文件、日志文件、數據文件、歸檔日志文件、備份文件等。如圖2所示，為db2系統架構的一個示意圖，基本描述了大部分rdbms系統的處理機制。db2的所有活動都是由線程處理。db2代理(agent)線程處理大部分的結構化查詢語言(structuredquerylanguage，sql)操作。在db2應用系統中，每個用戶應用程序(clientapplication)可能會分配多個副代理(subagents)。agent處理客戶的事務請求，將數據更改日志寫入日志緩沖區(logbuffer)，并等待記錄器(logger)將logbuffer中的記錄寫入到日志文件，同時將處理事務需要的數據讀入到緩沖池(bufferpool)，并對某些數據進行更改。bufferpool中被更改的數據稱為臟數據，當bufferpool的使用率超過特定水位之后，這些臟數據由頁面清理(pagecleaner)寫入到表空間(tablespaces)。在某些情況下，agent會對數據進行順序讀(例如表掃描tablescan操作)，此時實例將對數據頁進行異步預取，agent將異步預取請求放入預取隊列，由預取器(prefetcher)整合之后對表空間發起并發大數據塊讀取操作。死鎖探測器(deadlockdetector)是一個數據庫死鎖檢測編碼的數據單元(encodingdataunit，edu)，每隔一段時間，deadlockdetector會對數據庫鎖進行檢測，發現有死鎖發生時通知agent進行處理。當前數據庫性能測試中，大多數采用通用輸入/輸出(input/output，i/o)端口測試工具、數據庫i/o模擬工具和數據庫腳本進行業務模擬測試。諸如iometer、iozone、vdbench通用i/o測試工具可以根據預設的i/o特征(i/o大小、隨機度、讀寫比例等)對存儲子系統進行負載測試，通過實時界面或者文本輸出，觀察存儲子系統的性能情況。現在通用的數據庫i/o測試工具是采用swingbench、tpcc等工具對數據庫系統進行業務模擬測試。這些測試工具可以模擬預設業務對數據庫進行負載測試，通過實時界面或者文本輸出，觀察數據庫系統的性能情況。另外一種數據庫業務模擬測試是通過sql語句編寫具有類似結構的表、索引、處理邏輯等的腳本來模擬測試數據庫業務。但是，通用i/o測試工具雖然通用性高，但不支持i/o建模、無法模擬熱點區域、與生產環境相比真實性極低、不支持數據一致性檢測，與真實數據庫業務相差很大。數據庫i/o測試工具常常是針對定義的特定系統的模擬，無法自定義i/o建模，熱點區域較粗略，大部分只針對部分數據庫環境，通用性低，不支持數據一致性檢測，由于是固定模型的i/o，與生產環境相比真實性較低。數據庫腳本模擬可以做到數據庫層建模、可以模擬熱點區域、與生產環境相比真實性較高，但通用性很低，數據一致性檢測依賴于數據庫，對測試人員技能要求比較高。如下述表1所示，為各個測試工具特性的對比表：分類通用i/o測試工具數據庫i/o模擬工具數據庫腳本i/o建模不支持無法自定義數據庫層建模熱點區域無法模擬較粗略可以模擬真實性極低較低較高通用性高低很低一致性檢測不支持不支持依賴于數據庫表1如圖3所示，為本申請實施例中所應用的一個系統架構圖，采樣分析主機通過千兆以太網(gagabitethernet，ge)或光纖通道(fiberchannel，fc)網絡與生產環境的存儲系統相連，通過i/o跟蹤工具跟蹤并采集生產環境中數據庫業務的i/o特征和i/o負載，以及獲取生產環境中數據庫的配置參數；再對i/o特征和i/o負載進行分析，確定分析報告；根據分析報告和目標數據庫的配置參數，確定模型數據庫的配置文件，建立模型數據庫。這里建立的模型數據庫是根據實際生產環境的相關參數確定的，進而，根據該模擬數據庫對目標數據庫進行性能測試的時候，得到的測試報告準確性相對比較高，那么，所得到的測試報告的可靠性也比較高了，參考價值也就比較高。下面以實施例的方式對本申請技術方案中建立模型數據庫的方法進行具體說明，如圖4所示，為本申請實施例中建立模型數據庫的方法的一個實施例示意圖，包括：401、獲取生產環境中關于存儲的i/o特征和i/o負載，以及生產環境中目標數據庫的配置參數；在本申請實施例中，客戶端(也可稱為采樣分析主機)可以通過ge網絡或者fc網絡與生產環境中的存儲系統相連，使用i/o跟蹤工具跟蹤并采集生產系統中數據庫業務的i/o特征和i/o負載，以及獲取生產環境中目標數據庫的配置參數和備份策略等信息。需要說明的是，生產環境包括存儲系統和目標數據庫，在存儲系統中，包括多個邏輯單元號lun，在實際應用中，客戶端除了獲取上述信息之外，還需要獲取生產環境中關于存儲系統的每個邏輯單元號標識lunid和每個lun的大小。具體的，獲取生產環境中關于存儲的i/o特征和i/o負載，可以包括：獲取生產環境中在預置時長內，關于存儲的各個邏輯單元號lun的i/o特征和i/o負載；這里的預置時長，可以是生產環境業務高峰期的一段時間，也可以是生產環境業務低峰期的一段時間，具體可根據實際應用需求而定。其中，i/o特征可以包括偏移量、i/o大小、時間戳、隨機度和順序度等信息；i/o負載可以包括讀i/o次數、寫i/o次數、響應時間和隊列深度等信息；目標數據庫的配置參數可以包括：1.歸檔模式(歸檔，非歸檔)；2.備份策略(備份時間間隔，備份線程數，備份源和目的文件，備份目的文件存放位置)；3.每秒最大事務數(tps)；4.數據庫緩沖區大小，日志緩沖區的大小；5.redo日志文件大小，日志文件個數；6.歸檔文件大小。應理解，上述所提及的跟蹤工具可以多種多樣，比如linux中的“blktrace”、windows中的“filemon”。一些存儲系統提供i/o跟蹤命令，也可以用這些存儲命令來跟蹤i/o。下面列舉了一些i/o跟蹤工具，可選擇合適的i/o跟蹤工具來跟蹤生產環境的相關信息：blktrace–linux塊i/o跟蹤工具；strace–linux系統調用跟蹤命令；filemon–windows文件i/o跟蹤工具(主機)；vxtrace–veritasstoragefoundationtm卷管理器i/o跟蹤命令；可用于hp-ux環境和其他任何使用vxvm軟件的操作系統；trace–aix系統調用跟蹤命令；truss–solaris系統調用跟蹤命令；prex–solaris跟蹤命令；cacheshowlogio–huaweisymantecoceansapcetmturbo存儲的高速緩沖存儲器(cache)i/o跟蹤命令；swat–sunstoragetektm工作負載分析工具，可用于windows和solaris，該工具不僅跟蹤i/o屬性，還跟蹤i/o數據。因此，必須留足夠的空間給跟蹤日志，分析工作也比其他跟蹤工具花的時間長。i/o跟蹤需在具有業務負載代表性時段跟蹤，且跟蹤時間應足夠長。如果生產環境負載具有完全不同的特性，則需要針對不同特性的負載進行單獨i/o跟蹤，并建模為不同的模型數據庫配置文件。在unix和linux系統中可以使用“iostat”或者“sar”命令，在windows系統中可以使用“perfmon”來跟蹤i/o負載。i/o負載更新周期應非常小，比如每秒一次或者更小的時間單位。在跟蹤階段，實際應用中，對于目標數據庫的參數、活動報告和目標數據庫的備份策略也應該采集，因為這些信息對于模型數據庫建模很有必要。402、對i/o特征和i/o負載進行分析，確定分析報告；在本申請實施例中，客戶端可以對i/o特征和i/o負載進行分析，確定分析報告；i/o特征可以包括i/o大小、偏移量和時間戳，i/o負載可以包括讀i/o次數和寫i/o次數，讀i/o次數和寫i/o次數之和為i/o總數。需要說明的是，還可以將上述步驟中獲取的lun的大小轉換為扇區(sector)的數量，若獲取的lun的單位是mb，一個扇區的大小是512字節(byte)，1kb＝512字節*2，所以，將lun轉換為扇區的數量是：lun大小(mb)*1024*2。再通過偏移量和扇區就可以確定lun的lba地址了。可以根據生產環境的頁面(page)的大小，來確定i/o大小的范圍，若page的大小為4kb，則i/o大小的范圍為4kb-512kb，且每種i/o大小都是4kb的整數倍，所以，這種情況下共有128種i/o大小；那么，客戶端獲取的i/o大小的實際范圍可以為0kb-512kb。示例性的，那么，這128種i/o大小就是下述所說的預先確定的i/o大小的類別。假設，跟蹤工具跟蹤的時長為30分鐘，若每隔1s對各個lun跟蹤一次，那么，對于每一個lun來說，總共會跟蹤到1800個跟蹤信息，這里的跟蹤信息是上述的i/o大小、偏移量、時間戳、讀i/o次數和寫i/o次數等信息。具體的，對i/o特征和i/o負載進行分析，可以包括但不限于以下幾種分析：(1)根據時間戳、讀i/o次數、寫i/o次數和每個lunid，確定每個lun的讀百分比(lun的讀i/o次數/lun的i/o總數)、寫百分比(lun的寫i/o次數/lun的i/o總數)、負載百分比(lun的i/o總數/所有lun的i/o總數)、讀負載百分比(lun的讀i/o總數/所有lun的讀i/o總數)和寫負載百分比(lun的寫i/o總數/所有lun的寫i/o總數)；(2)根據預先確定的i/o大小的類別、時間戳、讀i/o次數、寫i/o次數和每個lunid，確定每個lun中每種i/o大小的負載百分比(lun在每種i/o大小時的i/o次數/lun的i/o總數)、讀負載百分比(lun在每種i/o大小時的讀次數/lun的讀i/o總數)和寫負載百分比(lun在每種i/o大小時的寫次數/lun的寫i/o總數)；(3)根據偏移量、每個lunid和每個lun的大小，確定每個lun的lba地址；將預置時長均分為n等份，將每個lun的lba地址均分為m等份，n和m為正整數；根據預先確定的i/o大小的類別、時間戳、讀i/o次數、寫i/o次數和每個lunid，確定每個lun中每種i/o大小在每個1/n時間單元內的讀負載百分比(在每種i/o大小中某時間單元內的讀i/o總數/lun的讀i/o總數)和寫負載百分比(在每種i/o大小中某時間單元內的寫i/o總數/lun的寫i/o總數)，以及每個lun中每種i/o大小在每個1/m地址單元內的讀負載百分比(在每種i/o大小中某lba地址單元內的讀i/o總數/lun的讀i/o總數)和寫負載百分比(在每種i/o大小中某lba地址單元內的讀i/o總數/lun的讀i/o總數)。需要說明的是，在上述的分析過程中，對于每個lba地址盡可能分為小的單元，因為越小，那么，得到的分析報告也就越準確。分析每個小單元的負載，并可以將具有相似負載且相鄰的lba地址單元合并為一個較大的lba地址單元。可以將預置時長也可以分為盡可能小的時間單元，分析每個時間單元的每秒進行讀寫(i/o)操作的次數(input/outputoperationspersecond，iops)，還可以將具有相似負載且相鄰的時間單元合并為一個較大的時間單元。通過以上分析，可以得到每個表的大小百分比、讀/寫比例、負載百分比等信息，作為分析報告。403、根據分析報告和目標數據庫的配置參數，確定模型數據庫的配置文件。在本申請實施例中，客戶端確定分析報告之后，根據分析報告和目標數據庫的配置參數，確定模型數據庫的配置文件。示例性的，存儲系統對象的每個數據庫文件的lba地址會根據表、索引和分區的大小劃分為段(segment)。將生產環境數據庫中的物理數據庫文件建模為模型數據庫中的容器(container)，container的容量可以通過頁面數量來表示。將段(segment)建模為模型數據庫中的表(table)，table可以包括3個屬性：頁面數量(由大小百分比計算得到)、負載百分比、讀比例。segment中較大的lba地址單元建模為模型數據庫中的區域area，area可以有3個屬性：大小百分比、讀負載百分比、寫負載百分比。將較大的時間單元建模為模型數據庫中的工作負載(負載百分比、讀/寫百分比)。目標數據庫的參數會建模為模型數據庫的屬性。目標數據庫的備份策略會被建模為模型數據庫的備份任務，且會被備份調度器(backupschedulers)線程調度。將分析結果建模為模型數據庫的配置文件是一個簡單的工作，但需要注意每個參數的準確性。示例性的，如圖5所示，為本申請實施例中提出的模型數據庫的架構示意圖，該模型數據庫可以支持oracle、db2、sqlserver等數據庫的測試。該模型模擬了：數據庫組件(數據文件、數據容器、表空間、緩存池、日志文件、歸檔空間、備份目標、頁面、日志緩存等)。數據庫線程(服務器線程、日志刷盤線程、歸檔線程、頁面清理線程、任務調度線程、備份線程等)。數據庫機制(事務、讀寫i/o、日志隊列、日志刷盤、緩存隊列、鎖、臟數據刷盤、性能計數器、校驗和、一致性檢查等)。需要說明的是，模型數據庫不僅支持單實例數據庫，也支持共享存儲的集群數據庫(例如oracle數據庫)和非共享存儲的集群數據庫(例如db2數據庫)。如圖6所示，為模型數據庫支持存儲不共享的集群數據庫的一個示意圖，如圖7所示，為模型數據庫支持共享存儲的集群數據庫一個示意圖。當模擬共享存儲集群數據庫時，每個模型數據庫都有一個獨立的日志文件、歸檔文件，共享containers。當模擬非共享存儲集群數據庫時，每個模型數據庫都有自己獨立的數據庫文件，containers不共享。這兩種情況下，模型數據庫將性能數據上報給監測器(monitor)線程，monitor線程再記錄和匯總這些性能數據。404、根據模型數據庫對目標數據庫進行性能測試，得到測試結果；在本申請實施例中，客戶端根據模型數據庫對目標數據庫進行性能測試，得到測試結果之前，還可以包括：若分析報告的配置文件格式與模型數據庫的目標文件格式不同，則將分析報告的配置文件格式轉換為目標文件格式。可選的，當分析報告的配置文件格式與模型數據庫的目標文件格式相同時，不需要轉換分析報告的配置文件格式。還可以是，若分析報告和生產環境中目標數據庫的配置參數的配置文件格式與模型數據庫的目標文件格式不同，則將分析報告和生產環境中目標數據庫的配置參數的配置文件格式轉換為目標文件格式。405、根據測試結果，生成測試報告。在本申請實施例中，客戶端根據測試結果，生成測試報告。根據模型數據庫對目標數據庫進行性能測試之后，還可以包括：獲取日志段編號lsn日志文件；根據lsn日志文件，對目標數據庫中的數據進行一致性檢查。在本申請實施例中，客戶端獲取模型數據庫，模型數據庫為客戶端根據獲取的生產環境中關于存儲的i/o特征和i/o負載，以及生產環境中目標數據庫的配置參數得到的；再根據模型數據庫對目標數據庫進行性能測試，確定測試報告。因為該模型數據庫的配置文件是根據實際的生產環境中關于存儲的i/o特征和i/o負載，以及生產環境中目標數據庫的配置參數得到的，所以，相對于現有的通用型模型數據庫來說，進行性能測試確定的測試報告的準確性更高，接近于目標數據庫的實際性能。需要說明的是，在上述圖5所示的模型數據庫的架構示意圖中，該通用數據庫架構模型是一系列線程和數據結構的集合。每一個線程模擬一種特定的關系型數據庫管理系統(rdbms)的進程或線程，處理特定的功能，下面可對其做一個說明：main線程：用于加載從生產環境跟蹤、分析和建模得到的配置文件并啟動模型數據庫，定期地提交模型數據庫的性能數據給監測器(monitor)線程；數據庫(database)線程：執行負載，控制agents、pagecleaners的數量以及最大tps。agents線程：負責產生和執行事務，從容器containers中讀取pages，寫臟pages到bufferpool中，寫logrecord到logbuffer中，并等待logwriter同步logbuffer中的日志記錄到logsegments中。該線程模擬rdbms中sql處理線程，例如oracle中的專用服務器和db2中的服務器代理。在事務處理中，agents首先生成和發布特定數目的頁面。頁面的位置和i/o類型基于table和area的負載百分比隨機生成。如果頁面類型是讀，則agents直接從container中讀該頁面；如果頁面類型為寫，則agents將該頁面寫入到bufferpool中，并添加一個項目(item)到日志記錄中。i/o操作完成后，agent將日志記錄寫到logbuffer中，并等待直到logwriter完成日志記錄到日志文件的同步。當每個事務處理完成后，性能數據就被更新。當一個事務執行時，有三種類型的時延：讀頁面時延、日志文件同步時延、緩沖池等待時延。這三種時延共同組成了事務時延。事務產生速度由最大tps配置決定。每個事務產生的頁面數量在database的配置文件中配置。配置的agents數量影響到存儲的i/o并發。page：頁面page是i/o操作的單元。tablespace，container，table和area是以pages計算大小而不是字節數。頁面有三個屬性：所屬的container，在container中的偏移位置，i/o類型(讀/寫)。當處理事務時，會產生隨機頁面。table、area和i/o類型頁面的選擇都是基于tables和areas中定義的負載百分比。bufferpool：緩沖池(bufferpool)是一個具有最大長度限制的塊先進先出(firstinfirstout，fifo)隊列。兩種線程會對其進行操作：agents線程和pagecleaners線程。agents將寫頁面放到緩沖池的頭部，pagecleaners線程從緩沖池的尾部取頁面并寫到containers中。當緩沖池為空，pagecleaners將等待，直到agents向隊列里面放入頁面。當緩沖池已滿，agents需要等待，直到pagecleaners從隊列中取出頁面。當緩沖池已滿，agents需要等待一個新的空間。這將導致事務時延，我們稱之為空閑緩沖區等待等待時間(freebufferbusywaitlatency)。緩沖池簡單地模擬了rdbms中的cache。大多數常用rdbmscache是通過具有水位(waterlevel)的lru算法實現的。當cache使用低于waterlevel時，沒有頁面會被同步。當cache使用超過了waterlevel時，pagecleaners(或者叫dbwriters)選擇最近最少使用的臟頁面進行同步和清除。當低于waterlevel時，模型數據庫和rdbms是不同的；但當高于waterlevel時，模型數據庫和rdbms是完全相同的，因為跟蹤日志是在塊設備上采樣而不是在cache中采樣。實際上，緩沖池模擬了rdbms的cache中最近最少使用的頁面。模型數據庫中的寫頁面(writtenpages)模擬了rdbms中被pagecleaners線程從cache中換出的頁面。因此，一個模型數據庫配置只能模擬被跟蹤的生產環境，生產環境的任何改變將導致不同的i/o。例如給數據庫服務器增加內存將導致施加到存儲的物理i/o更少，因此，前面建模的模型數據庫不再能夠衡量新環境的性能了。logrecord：日志記錄(logrecord)是一個數據結構，記錄事務中產生的所有寫pages。每個事務有一個日志記錄。當事務結束時，日志記錄被寫到日志緩沖區中，此時，agents線程需要等待logwriter線程將日志記錄同步到日志文件中后才產生下一個事務。日志記錄模擬了rdbms中的重做日志記錄redologrecord，但模型數據庫中的日志記錄并沒有記錄類似于rdbms中的pagechanges。模型數據庫中的日志記錄只記錄寫頁面的位置，該記錄不能用于數據恢復只能用于一致性檢查。雖然存在差異，但i/o影響是相同的。模型數據庫中日志記錄的大小是恒定的，其值可以在database的配置文件中定義。一個事務中寫頁面的位置存放在日志記錄的前面，日志記錄的剩余空間用于填充隨機數據。日志記錄大小恒定并不意味著日志i/o大小恒定。在一個同步操作中，logwriter可以同步多個日志記錄，因此，日志i/o大小是一個或者多個日志記錄的大小，這取決于很多因素，例如事務負載和同步操作的速度。事實上，rdbms中的日志操作也存在這種現象。logbuffer：日志緩沖區(logbuffer)是一個具有最大長度限制的塊先進先出(fifo)隊列。兩種線程可對其進行操作：agents和logwriter。agents將日志記錄放到日志緩沖區的頭部，logwriter從日志緩沖區的尾部取出日志記錄并同步日志記錄到日志文件中。當日志緩沖區為空，logwriter將等待直到日志記錄被agents放入緩沖區中；當日志緩沖區已滿，agents將等待直到日志記錄被logwriter取出。當隊列為空時，取出線程需要等待放入線程。當隊列已滿時，放入線程需要等待取出線程。因此，模型數據庫中一個事務執行可能有四種時延：讀page時延，日志記錄同步時延，日志buffer等待時延和bufferpool等待時延。模型數據庫將日志記錄同步時延和日志buffer等待時延之和稱為日志文件同步時延。logwriter能從日志緩沖區中取出多個日志記錄。但每次同步操作同步的日志記錄數不會超過日志記錄的最大數，日志記錄最大數可在database配置文件中定義。logwriter線程：負責同步logbuffer中的log記錄到log文件的logsegments中。該線程模擬了關系型數據庫管理系統(rdbms)中的日志記錄同步線程。模型數據庫中只有一個logwriter線程。日志文件由多個日志段(logsegment)組成。logwriter順序寫日志記錄到logsegment中。在歸檔模式下，當一個logsegment已滿，logwriter會將該logsegment放到歸檔隊列中(archivequeue)，并切換日志到下一個logsegment進行順序寫操作。在非歸檔模式下，當一個logsegment已滿，logwriter只切換到下一個logsegment，并寫一個lsn記錄到lsnjournal文件中。當最后一個logsegment已滿，logwriter切換日志操作到第一個logsegment。logwriter每次從logbuffer中取出一個或者多個日志記錄。如果取出多個日志記錄，logwriter會將這多個日志記錄合并為一個大i/o并寫到日志文件中。pagecleaners線程：負責將bufferpool中的臟頁面dirtypages寫到containers中。該線程模擬了rdbms中臟頁寫線程，比如模擬了oracle數據庫中的dbwriter以及db2中的pageclearner線程。當關閉數據庫時，需要等到pagecleaners線程將bufferpool中所有臟頁都寫到containers中后才會終止數據庫進程。歸檔archiver線程：在模型數據庫為歸檔模式下，將所有的logsegments拷貝到歸檔文件archivefile中。當一個logsegment被歸檔了，logarchiver就會寫一個日志段編號lsn(logsegmentnumber，一個lsn定義了3個屬性：dbfileid、起始偏移地址、結束偏移地址，當logsegment切換時，會寫lsn到lsnjournal文件，且一致性檢查中也會用到lsn)記錄到lsnjournal文件。備份調度器backupschedulers線程：負責調度備份任務，一旦到了備份時間，backupschedulers調用backup線程將備份源文件拷貝到備份目的文件中。備份源文件可以是container文件、日志文件或者歸檔文件。備份任務定義了6個屬性：第一次備份時間、備份時間間隔、備份線程數、備份源、備份目錄、備份目錄的偏移。當執行備份任務時，backupscheduler啟動多個線程進行備份i/o操作。備份操作的性能記錄在“bkupmbps”性能計數器中。dbfile：數據庫文件(dbfile)可以是本地文件系統的常規文件、網絡文件系統上的文件或者裸(raw)設備。模型數據庫沒有模擬rdbms的自動擴展特性。數據庫文件大小必須是恒定的，可在database的配置文件中定義。當一個文件被用作模型數據庫的數據庫文件時，必須初始化該文件的大小。在模型數據庫中有四種數據庫文件：日志文件(logfile)、歸檔文件(archivefile)、容器(container)和備份目標(backupdestination)。日志文件：用于存儲事務日志記錄，每個日志文件由多個日志段(logsegments)組成；日志段被循環覆蓋寫：日志記錄被順序地寫入第一個日志段，如果第一個日志段已滿，則切換日志操作到下一個日志段，直到切換到最后一個日志段；如果最后一個日志段已滿，則日志切換到第一個日志段。當切換了日志段就寫一個lsn到lsnjournal中來記錄日志位置，用于一致性檢查。lsn表示日志段編號(logsegmentnumber)，有3個屬性：數據庫文件id，起始偏移，結束偏移。在一致性檢查操作中，checker線程從lsnjournal中讀取預寫入日志記錄的位置信息。歸檔文件：用于歸檔模式下歸檔所有已寫的日志段。容器：用于存放表數據。一系列的container組成一個條帶化的表空間(tablespace)，表數據存放在表空間中。備份目標：用于存放備份集。備份集是一系列數據庫文件的完全拷貝。數據庫文件大小必須小心配置：日志文件被循環寫，因此日志段的數量必須大于2，且每個日志段的大小不能太小。推薦日志段數量為大于或等于5，每個日志段配置大于100mb空間。monitor線程與database線程相互獨立。monitor監聽一個特定的端口。所有databases可以連接到這個端口。monitor周期性地發送命令給所有連接到這個端口的databases。當database接收到一個命令，database就提交其相應的性能數據給monitor。monitor計算所有數據庫的性能計數器，并打印到屏幕上，同時將性能數據記錄到性能日志文件中。當database提交性能數據時，database打印性能數據到本地終端屏幕上，同時也將性能數據記錄到本地日志文件中。monitor線程監控的性能計數器有：timestamp–性能數據的時間戳tps–每秒事務數avgtlat–平均事務處理時延maxtlat–最大事務處理時延avgrlat–平均page讀操作時延maxrlat–最大page讀操作時延avglfsync–平均日志文件同步時延maxlfsync–最大日志文件同步時延avgfbwait–平均空閑buffer等待時延maxfbwait–最大空閑buffer等待時延rps–每秒page讀操作次數wps–每秒臟page寫操作次數bkupmbps–每秒備份兆字節數(mb/s)下面對本申請實施例中的表空間(tablespace)、表(table)和容器(container)分別進行說明：如圖8所示，為本申請實施例中表空間和表的一個示意圖；表空間用于存放表數據。一個表空間包含一個或者多個containers。表空間中的containers的條帶單元為區(extent)。同一個表空間中的container的大小必須相同。其中，模型數據庫中的表空間可以有不同的頁面大小，這與rdbms相似。在rdbms系統中，每個頁面大小必須至少有一個緩沖池或者cache。但在模型數據庫中不必要為每個頁面大小分配至少一個緩沖池，因為模型數據庫中的緩沖池只是一個簡單的fifo隊列，該種隊列能傳輸不同大小的頁面。table是tablespace中一組連續的頁面。table實際上模擬了rdbms中的數據段(datasegment)，table是一個非分區表或者非分區索引或者是表/索引分區。rdbms中的數據段只能使用一個表空間的空間，在模型數據庫中也是如此。每個table都有一個特定的負載百分比和讀/寫百分比。當模型數據庫中agents線程發布事務時，會生成一組隨機頁面。agents線程基于table的負載百分比選擇table頁面，并基于讀寫百分比選擇頁面的讀/寫屬性。如圖9所示，為本申請實施例中區域的一個示意圖；分析跟蹤生產環境得到的跟蹤日志文件得到表的負載百分比，再根據這些負載百分比將表分為多個區域。在模型數據庫中，當agents線程產生和發起一個事務時，會根據負載百分比選擇區域頁面。區域模擬了rdbms中datasegment的一部分。區域有特定的讀、寫負載百分比。具有高負載百分比的區域稱為熱點區域，具有低負載百分比的區域稱為冷區域。從上述圖9中可以看出各區域從熱到冷分別為：area3>area1>area2>area0。熱點區域被應用頻繁訪問的概率更大。區域的定義是模型數據庫的重點之處。通過跟蹤和分析真實rdbms生產環境中的每個段的i/o操作，并建模形成模型數據庫中的區域。在分析階段，每個段的lba地址被分成非常小的單元(可能1％)，再計算每個lba單元的負載，最終將具有相似負載的連續lba地址單元合并為一個area。模擬的精確性依賴于area的定義。area定義得越小，模擬的精確性越高。但最重要的是：i/o跟蹤必須正確且能反應真實的工作負載。如圖10所示，為本申請實施例中一致性檢查的示意圖，一致性檢查器(consistencychecker)線程負責檢查被測存儲數據的一致性。在模型數據庫中，每個扇區的最后一個字節用作預留。當寫一個頁面時，會計算該頁面所包含的所有扇區的一個校驗和字節，并存儲在每個扇區的預留字節中。當進行一致性檢查時，checker線程從lsnjournal中讀取lsns來查找預寫入的日志記錄。從預寫入的日志段中讀出日志記錄，定位到預寫入的頁面。checker線程從container中讀出預寫入的頁面，并重新計算校驗和，同時與扇區中保存的校驗和進行比較。如果兩個校驗和不相等，就發生一個一致性錯誤。該錯誤會被寫到checkerjournal中。如果錯誤數量超過了最大設置值，則一致性檢查失敗。下面以實際應用場景對本發明技術方案做進一步的說明，如圖11所示，為本申請實施例中生產環境為db2v95的數據庫生產環境示意圖。在db2v95的數據庫生產環境中，運行tpccrunner工具產生tpcc-like的工作負載。該生產環境中有9個表，每個表存放在獨立的表空間上。每個表空間只包含一個container。每個container由存儲系統上單獨的一個lun創建。索引與其對應的表存放在同樣的表空間中。另外，一個lun用于存放日志文件，一個lun存放歸檔文件，兩個lun用作備份目標。所以，在存儲系統上總共有13個lun，在實際應用中，這里對于備份目標的lun的數量不作具體限定。下面結合本申請實施例中所提出的方案對上述的生產環境進行跟蹤，(1)將跟蹤客戶端(tracingclient)通過ge交換機與存儲系統相連，在tracingclient上運行遠程控制腳本trace.pl調用存儲系統命令進行i/o跟蹤。trace.pl跟蹤腳本使用expect工具和調用ssh命令登陸到存儲系統上并發送“cacheshowlogio”跟蹤命令。所有發送給cache和從cache返回的i/o都會被跟蹤。在存儲系統上共有13個lun，該跟蹤腳本會每隔一秒鐘以輪詢方式跟蹤每個lun。假設，在tpc-c測試穩定階段跟蹤30分鐘，這樣跟蹤的數據能代表tpc-c工作負載。如圖12所示，為跟蹤工具跟蹤存儲系統的一個示意圖；跟蹤時記錄每個i/o的時間戳、lunid、lun大小、i/o操作碼、i/o扇區和i/o大小、偏移量等信息。雖然對存儲cache的操作有很多，但我們只需分析代表來自于主機系統的兩種操作：cachefrontread和cachefrontwrite。所有跟蹤數據保存在跟蹤日志文件trace.log中。(2)對跟蹤日志文件進行分析，確定分析報告。主要分析獲取所有lunid、lun大小、將lun大小轉換為扇區(sector)數量(lun大小(mb)*1024*2)，根據扇區數量和偏移量，可以確定每個lun的lba地址。由于db2中page的大小為4kb，所以i/o大小范圍為：4kb-512kb，且每種i/o大小都是4kb的整數倍，所以，這種情況下共有128種i/o大小。在上述跟蹤工具跟蹤的時候，還會獲取db2環境的參數、活動日志、tpccrunner測試性能數據(tps)、存儲系統性能數據(iops)，并根據db2參數和活動日志設置模型數據庫的配置。需要說明的是，還可以將跟蹤時間按照每4ms為一個瞬時時間進行劃分，對跟蹤時間做一個更細致的分析，那么，得到的分析報告來說，也就越準確，但是，相對應的工作量也會增加，所以，可結合實際需求而定。①統計分析每個lun的讀百分比(lun的讀i/o總數/lun的i/o總數)、寫百分比(lun的寫i/o總數/lun的i/o總數)、負載百分比(lun的i/o總數/所有lun的i/o總數)、讀負載百分比(lun的讀i/o總數/所有lun的讀i/o總數)、寫負載百分比(lun的寫i/o總數/所有lun的寫i/o總數)。②統計分析每個lun每種i/o大小的負載百分比(lun在某種i/o大小時的i/o總數/lun的i/o總數)、讀負載百分比(lun在某種i/o大小時的讀i/o總數/lun的讀i/o總數)、寫負載百分比(lun在某種i/o大小時的寫i/o總數/lun的寫i/o總數)。③將每個lun的lba地址和時間劃分為100份，統計分析每個lun每種i/o大小在每個lba地址單元內的讀負載百分比(lun在某種i/o大小某lba地址單元內的讀i/o總數/lun的讀i/o總數)、寫負載百分比(lun在某種i/o大小某lba地址單元內的寫i/o總數/lun的寫i/o總數)。統計分析每個lun每種i/o大小在每個時間單元內的讀負載百分比(lun在某種i/o大小某時間單元內的讀i/o總數/lun的讀i/o總數)、寫負載百分比(lun在某種i/o大小某時間單元內的寫i/o總數/lun的寫i/o總數)。(3)根據分析報告和目標數據庫的參數進行建模，得到模型數據庫的配置文件。配置文件中可以包括：數據庫的名稱、monitor線程所在主機的ip地址、monitor監聽端口、每事務產生的i/o數(iops/tps)、歸檔和備份操作中順序i/o的大小、checkseed(進行扇區checksum計算的8位無符號整型數)、數據庫是否開啟歸檔模式。數據文件的文件id和文件路徑。文件路徑可以是裸設備盤符路徑或者常規文件路徑。tablespace的id、頁面大小、擴展頁面數。表空間是由多個container組成，需設置表空間中包含的容器id、每個容器對應的文件id、容器頁面數量。同一表空間中所有容器的頁面數量需設置一樣。容器的數量和頁面數量由db2的containers已使用容量建模得到。table的id、表所在表空間的id、表在表空間中起始頁面數、表的頁面數量、負載百分比、讀百分比、表包含的區域、區域的容量百分比、讀負載百分比、寫負載百分比。table的數量由db2的tables建模得到，容量百分比和負載百分比太小的表可以忽略不用建模。實際中只對order_line、stock、customer、history、order、new_order進行了建模。表的頁面數量根據分析得到表的容量百分比計算得到。由于每個lun上只存放了一個表，所以，表所在lun的負載百分比即為表的負載百分比。每個表中具有相似負載的相鄰lba地址單元合并為一個較大的lba地址單元，該較大的lba地址單元建模為模型數據庫中表的area。緩沖池的大小(以頁面數量表示)、日志緩沖區的大小(以日志記錄數表示)。logwriter的日志文件id、日志段大小、日志段個數、日志記錄大小、每次同步操作能夠同步的最大日志記錄數。這里的日志文件id即為數據文件的文件id。日志段大小*日志段個數的結果必須小于日志文件的大小。archive的歸檔文件id、歸檔文件大小、每次歸檔可掛起的最大日志段數。backupschedulers的數據庫啟動后開始進行第一次備份的時間、以后每次備份的時間間隔、備份線程數、備份源文件id、備份目標文件id、備份目標文件偏移地址。工作負載workload的名稱、測試運行時間、agents線程數、pagecleaners線程數、每秒最大事務數。db2中agents和cleaners建模為模型數據庫中的workload。tpccrunner測試的tps建模為模型數據庫配置文件的每秒最大事務數。按照這種定義，可以模擬高中低等各種負載測試。(4)啟動模型數據庫進行模擬測試。database線程會順序地執行配置文件中定義的工作負載workload。main線程與monitor程序進行通信。main線程每次收到monitor發送的獲取性能數據的命令后，會計算所有agents線程的性能數據并反饋給monitor；同時，將性能數據打印到屏幕上以及保存到性能日志文件中。模擬測試過程中，還會產生lsn日志文件，用于數據一致性檢查。(5)運行monitor監控程序對所有連接到該monitor的數據庫性能進行統計。monitor可以每隔10s向每個數據庫發送獲取性能數據的命令，并統計性能數據，將其打印到屏幕上和保存到性能日志文件中。模型數據庫可以在任何時間連接或者退出monitor。所以，只有當workload更改時才需要關閉monitor。monitor對于模型數據庫是必要的。如果模型數據庫連接到一個不存在的monitor，則數據庫啟動失敗；如果模型數據庫連接到的monitor已經關閉，則數據庫會退出并報連接錯誤。(6)當模擬測試完成后，可通過重啟存儲或者主機模擬發生故障。然后使用checker程序進行數據的一致性檢查。上面對本申請實施例中的建立模型數據庫的方法進行了說明，下面對本申請實施例中的客戶端進行說明，如圖13所示，為本申請實施例中客戶端的一個實施例示意圖，包括：獲取模塊1301，用于獲取生產環境中關于存儲的i/o特征和i/o負載，以及生產環境中目標數據庫的配置參數；分析模塊1302，用于對i/o特征和i/o負載進行分析，確定分析報告；確定模塊1303，用于根據分析報告和目標數據庫的配置參數，確定模型數據庫的配置文件。可選的，在本申請的一些實施例中，獲取模塊1301，具體用于獲取生產環境中在預置時長內，關于存儲的各個邏輯單元號lun的i/o特征和i/o負載；還用于獲取生產環境中關于存儲的每個邏輯單元號標識lunid和每個lun的大小。可選的，在本申請的一些實施例中，i/o特征包括i/o大小、偏移量和時間戳，i/o負載包括讀i/o次數和寫i/o次數；分析模塊1302，具體用于根據時間戳、讀i/o次數、寫i/o次數和每個lunid，確定每個lun的讀百分比、寫百分比、負載百分比、讀負載百分比和寫負載百分比；具體用于根據預先確定的i/o大小的類別、時間戳、讀i/o次數、寫i/o次數和每個lunid，確定每個lun中每種i/o大小的負載百分比、讀負載百分比和寫負載百分比；具體用于根據偏移量、每個lunid和每個lun的大小，確定每個lun的lba地址；將預置時長均分為n等份，將每個lun的lba地址均分為m等份；根據預先確定的i/o大小的類別、時間戳、讀i/o次數、寫i/o次數和每個lunid，確定每個lun中每種i/o大小在每個1/n時間單元內的讀負載百分比和寫負載百分比，以及每個lun中每種i/o大小在每個1/m地址單元內的讀負載百分比和寫負載百分比。可選的，在本申請的一些實施例中，在上述圖13所示的基礎上，如圖14所示，為本申請實施例中客戶端的另一個實施例示意圖，該客戶端還包括：轉換模塊1304，用于若分析報告的配置文件格式與模型數據庫的目標文件格式不同，則將分析報告的配置文件格式轉換為目標文件格式。可選的，在本申請的一些實施例中，在上述圖13所示的基礎上，如圖15所示，為本申請實施例中客戶端的另一個實施例示意圖，該客戶端還包括：得到模塊1305，用于根據模型數據庫對目標數據庫進行性能測試，得到測試結果；生成模塊1306，用于根據測試結果，生成測試報告。可選的，在本申請的一些實施例中，在上述圖15所示的基礎上，如圖16所示，為本申請實施例中客戶端的另一個實施例示意圖，該客戶端還包括：獲取模塊1301，用于獲取日志段編號lsn日志文件；檢查模塊1307，用于根據lsn日志文件，對目標數據庫中的數據進行一致性檢查。如圖17所示，為本申請實施例中客戶端的一個實施例示意圖，可以包括：該客戶端可因配置或性能不同而產生比較大的差異，可以包括一個或一個以上中央處理器(centralprocessingunits，cpu)1722(例如，一個或一個以上處理器)和存儲器1732，一個或一個以上存儲應用程序1742或數據1744的存儲介質1730(例如一個或一個以上海量存儲設備)。其中，存儲器1732和存儲介質1730可以是短暫存儲或持久存儲。存儲在存儲介質1730的程序可以包括一個或一個以上模塊(圖示沒標出)，每個模塊可以包括對客戶端中的一系列指令操作。更進一步地，中央處理器1722可以設置為與存儲介質1730通信，在客戶端上執行存儲介質1730中的一系列指令操作。客戶端還可以包括一個或一個以上電源1726，一個或一個以上有線或無線網絡接口1750，一個或一個以上輸入輸出接口1758，和/或，一個或一個以上操作系統1741，例如windowsservertm，macosxtm，unixtm,linuxtm，freebsdtm等等。上述各個實施例中由客戶端所執行的步驟可以基于該圖17所示的客戶端結構。在上述實施例中，可以全部或部分地通過軟件、硬件、固件或者其任意組合來實現。當使用軟件實現時，可以全部或部分地以計算機程序產品的形式實現。所述計算機程序產品包括一個或多個計算機指令。在計算機上加載和執行所述計算機程序指令時，全部或部分地產生按照本發明實施例所述的流程或功能。所述計算機可以是通用計算機、專用計算機、計算機網絡、或者其他可編程裝置。所述計算機指令可以存儲在計算機可讀存儲介質中，或者從一個計算機可讀存儲介質向另一個計算機可讀存儲介質傳輸，例如，所述計算機指令可以從一個網站站點、計算機、服務器或數據中心通過有線(例如同軸電纜、光纖、數字用戶線(dsl))或無線(例如紅外、無線、微波等)方式向另一個網站站點、計算機、服務器或數據中心進行傳輸。所述計算機可讀存儲介質可以是計算機能夠存取的任何可用介質或者是包含一個或多個可用介質集成的服務器、數據中心等數據存儲設備。所述可用介質可以是磁性介質，(例如，軟盤、硬盤、磁帶)、光介質(例如，dvd)、或者半導體介質(例如固態硬盤solidstatedisk(ssd))等。所屬領域的技術人員可以清楚地了解到，為描述的方便和簡潔，上述描述的系統，裝置和單元的具體工作過程，可以參考前述方法實施例中的對應過程，在此不再贅述。在本申請所提供的幾個實施例中，應該理解到，所揭露的系統，裝置和方法，可以通過其它的方式實現。例如，以上所描述的裝置實施例僅僅是示意性的，例如，所述單元的劃分，僅僅為一種邏輯功能劃分，實際實現時可以有另外的劃分方式，例如多個單元或組件可以結合或者可以集成到另一個系統，或一些特征可以忽略，或不執行。另一點，所顯示或討論的相互之間的耦合或直接耦合或通信連接可以是通過一些接口，裝置或單元的間接耦合或通信連接，可以是電性，機械或其它的形式。所述作為分離部件說明的單元可以是或者也可以不是物理上分開的，作為單元顯示的部件可以是或者也可以不是物理單元，即可以位于一個地方，或者也可以分布到多個網絡單元上。可以根據實際的需要選擇其中的部分或者全部單元來實現本實施例方案的目的。另外，在本申請各個實施例中的各功能單元可以集成在一個處理單元中，也可以是各個單元單獨物理存在，也可以兩個或兩個以上單元集成在一個單元中。上述集成的單元既可以采用硬件的形式實現，也可以采用軟件功能單元的形式實現。所述集成的單元如果以軟件功能單元的形式實現并作為獨立的產品銷售或使用時，可以存儲在一個計算機可讀取存儲介質中。基于這樣的理解，本申請的技術方案本質上或者說對現有技術做出貢獻的部分或者該技術方案的全部或部分可以以軟件產品的形式體現出來，該計算機軟件產品存儲在一個存儲介質中，包括若干指令用以使得一臺計算機設備(可以是個人計算機，服務器，或者網絡設備等)執行本申請各個實施例所述方法的全部或部分步驟。而前述的存儲介質包括：u盤、移動硬盤、只讀存儲器(rom，read-onlymemory)、隨機存取存儲器(ram，randomaccessmemory)、磁碟或者光盤等各種可以存儲程序代碼的介質。以上所述，以上實施例僅用以說明本申請的技術方案，而非對其限制；盡管參照前述實施例對本申請進行了詳細的說明，本領域的普通技術人員應當理解：其依然可以對前述各實施例所記載的技術方案進行修改，或者對其中部分技術特征進行等同替換；而這些修改或者替換，并不使相應技術方案的本質脫離本申請各實施例技術方案的精神和范圍。當前第1頁12當前第1頁12