測試基準資料的準備

在很多時候我們都需要做一些對比測試，比如我們的機器換了一個平臺，比如機器做了較大的硬體升級和改造，或者引入了第三方的軟體服務等等，很多時候就需要做一個基準測試，想根據測試結果然後對比做了一些變更之後，效能是提升了還是下降了，或者提升了，提升幅度有多少，這個單純來估算一個值既不科學也不準確。這個時候還是想做一個基準測試，來得到一個資料包告，讓資料來說話。
當然絕大多數的時候，如果想做這樣一個測試，出發點是好的，但是說實話，落實起來真是難上加難，一來要推動業務部門配合，來從前端發起相應的資料處理請求，來進行基本真實的模擬場景，或者說根據以往的經驗來透過第三方的工具來實現，類似於壓力測試的方式。這樣也可以模擬出一個業務高峰來。
上面的兩種方法都是目前主要採用的一些方法，如果從系統的角度來看，從DBA的工作量來看，都需要做很多的前期工作，比如我們要模擬業務高峰期的情況，總得有資料吧。很多時候都是從生產環境中去抽取，然後加上開發部門的配合，可能有些job,damon都有一定的環境依賴，可能需要調整一些引數等等。如果是壓力測試這種方式，如果讓專門的效能測試團隊來做，對於他們來說，一個前提就是對於業務很熟悉，要不很難短時間模擬出很多有效的資料來。然後把這些資料和業務流程結合起來。
上面兩種方式都可以實現，都需要熟悉業務和需求。
如果我們把這個工作解耦，交給第三方的獨立結構來做，那麼上面兩種方式就徹底不可用了。
第三方測試可能更具有說服力，完全都是依照資料來說話，沒有半點含糊或者水分的東西。比如我們確實需要這麼做，不過一個最重要的顧慮就是資料的安全性，我們不希望把自己的所有系統都完全暴露給第三方，我們還是需要保留一些東西的。所以第三方的測試有優點但是有顧慮。怎麼去合理把握這個度呢。
比如我們有10套應用系統對應10個獨立的資料庫例項，那麼我們想把他們做一個整合，然後想看看硬體升級之後是否在效能上能夠提升。
這個時候我們可以按照下面的思路來考慮。我們可以根據討論來初步決定一個資料的基準範圍，比如我們得到了近兩個星期的資料負載資訊，然後我們就運用這個資料庫級的負載資訊來做分析，比如我們抓取幾個有代表性的時間段，比如在負載高峰時段+幾個業務正常時間段，然後得到對應的awr報告。
透過這些報告我們就能夠基本得到一些基礎資料，比如在高峰時段，tps是多少，事務的大小，都能夠做到心中有數。
比如一個awr報告是這樣的。

Load Profile

	Per Second	Per Transaction
Redo size:	247,989.92	1,042.04
Logical reads:	25,633.20	107.71
Block changes:	1,861.72	7.82
Physical reads:	28.45	0.12
Physical writes:	128.67	0.54
User calls:	1,346.26	5.66
Parses:	521.36	2.19
Hard parses:	0.10	0.00
Sorts:	33.26	0.14
Logons:	0.26	0.00
Executes:	851.94	3.58
Transactions:	237.99

我們就可以清楚的看到tps在238左右。每個事務的大小在1k左右。每秒鐘的資料呼叫次數在1000多
然後我們進行篩選，根據這些資料得到一個整體的概念，然後在awr中嘗試抓取一些典型的sql語句，比如某些sql語句執行頻率特別高，哪些sql佔用的IO資源特別高等。
根據這個我們就可以基本得到一個sql清單，比如sql控制在20個以內，20條sql語句是我們需要關注的，可以列入基準範圍內，
然後根據sql來得到訪問的表，這樣既進一步來分析表的資料情況，比如涉及的表有10個，3個大表資料在億級，3箇中級表，資料量在百萬，3個小表資料量在幾千
我們得到了這些資料情況，就可以進一步來提供種子資料，比如我們拿出表中的幾條資料來作為種子資料，然後提供一個基準，比如那些欄位的值需要唯一，那些欄位的值是列舉型別的，選擇的值需要在一定的範圍之內，或者說哪些表有特定關聯關係等等。
比如可以提供如下的資料方式

TEST_DATA
列名	種子資料1	種子資料2
CID	7	8
CN	xxxxxxx@aaaaa.com	xxxxxxx@bbbbb.com
CN_TYPE	1	3
UIN	xxxxxxx001	xxxxxx002
ENABLED	Y	N

然後我們可以提供資料的翻倍規則，比如表test_data資料量有1000萬，我們就可以根據翻倍規則得到資料應該怎樣去擴充套件，那些值的範圍是有效的。

TEST_DATA
列名	基本約束	翻倍規則
CID	NOT NULL NUMBER(16)	唯一
CN	NOT NULL VARCHAR2(50)	唯一
CN_TYPE	NOT NULL NUMBER(5)	1-1000
UIN	NOT NULL NUMBER(16)	唯一
ENABLED	NOT NULL CHAR(1)	Y/N

然後在此基礎上我們需要提供一些效能指標，比如某些sql語句在10分鐘內執行頻率在100萬次。那麼我們就可以提供這些資料來嘗試模擬這種情況。多條sql有采用這樣的方式就可以得到一個基本的概覽圖，然後結合事務做一個評估，那些語句放入在一個事務內，最大事務包含多少sql語句等等。
最後提供一個基準資料，比如下面的這種方式。

sql1:	100~150萬次
sql2:	100萬
sql3:	100~150萬次
sql4:	100~150萬次
sql5:	100~150萬次

最後提出我們的期望，這樣基礎資料的提供就有了一些依據，而不是根據自己的感覺來做了。儘管在評估中還是有一些誤差甚至大的差別但是很多時候我們能夠把一些重要的指標給過濾出來，集中分析。