19 September,2011 by Tom Collins
The usual Proof of Concept (POC) is :
a) a new data centre build
b) a new SAN ,SVC , or any other aspect of the substorage system
c) new hardware
d) new virtualized environment
As the DBA you’ll be asked to validate these new systems. Why?
1) You’re responsible for the operational and performance SLAs of the Database servers.
2) Database servers tend to be IO intensive and require storage tuning, which means they must be tested on any new system for acceptance.
A POC can become political . Different managers have already made decisions. It’s not uncommon for an Infrastructure manager to decide on a new disk speed , without consulting Application teams. Or deciding to switch to a virtualized database server environment to satisfy Disaster Recovery requirements without performance testing the virtualized environment with some real-world data.
The POC purpose is the opportunity to test different scenarios and measure the results. Ideally this should be done prior to purchases from vendors.
The aim should be to define some questions and test those questions. Typical questions could be:
a) Is the IO performance on the new system equal or better than the current production system?
b) Is the proposed Virtual Server sufficient to deal with the database server loads.?
The key advice to remember during the POC is “document everything” . This means measuring and recording all data. Avoid anecdotal comments such as “it feels slower” .
Team meetings need to focus on facts. Facts should be figures in a spreadsheet. It may be necessary to pass these figures onto a vendor and rerun the tests in their laboratory.
Vendors can be demanding when requesting test data , be prepared to test different scenarios and configurations .
All tests should be repeatable and measurable. If a change occurs on the performance stack , tests will need to rerun and gauge the performance impact.
Scripting the tests is easier in the long run. This allows you to repeat the tests on different platforms efficiently.
It depends how thorough you need to be. If the environment is changing substantially, such as a new Data Centre with new hardware, then a wider scope is required. If you’re adding some more memory – then the tests can be more limited.
An example test pattern for moving the Database server inventory to a new Data Centre would start from synthetic IO testing and progress to real-world workloads. The workloads should include as many connections as possible and the workload approximating Production level.
a) Use tools such as SQLIO
8kb |
random writes |
8kb |
random reads |
8kb |
sequential writes |
8kb |
sequential read |
64kb |
sequential writes |
64kb |
sequential reads |
128kb |
sequential writes |
128kb |
sequential read |
256kb |
sequential writes |
256kb |
sequential reads |
1024kb |
sequential writes |
1024kb |
sequential reads |
b) TPC-H benchmark testing
Read TPC-H generate test data , test queries and sql database benchmark
c) Operational and Application level tests
File Copy
Backup and Restore
Bulk Insert
Maintenance jobs such as Reindexing
ETL
Transactions on extracted data from real – world systems. If relevant , run in an isolated network, to avoid corrupting production data
This is only a preview. Your comment has not yet been posted.
As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.
Having trouble reading this image? View an alternate.
Posted by: |