POC

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.?

FAQ

1)  What levels of documentation are required ?

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 .

2)  How to  run the tests?

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.

3)  What type of tests should be run?

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

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